Security

Security

 

 

Subject: a physical person, in some role

 

Person: a subject or a “legal person” (a company, the government etc.)

 

Principal: an entity which participates in a security system, e.g.

  • a person

  • a role

  • a piece of equipment

  • compound of other principals

    • group

    • conjunction (multiple principals acting together)

    • compound role (e.g. a presidency, several people filling the same role in succession)

    • delegation (Bob acting as Alice in her absence)

 

System: denotes

  1. A product or component, such as a cryptographic protocol, a smartcard, or PC hardware

  2. A collection of the above plus an operating system, communications, and other things that make up an organization’s infrastructure.

  3. The above plus one or more applications (accounts, payroll, design and so on).

  4. Any or all of the above plus IT staff.

  5. Any or all of the above plus internal users and management.

  6. Any or all of the above plus customers and other external users.

  7. Any or all of the above plus the surrounding environment including the media, competitors, regulators, and politicians.

 

Trusted system or component: one whose failure can break the security policy

 

Trustworthy system or component: one that won’t fail.

 

Secrecy:

  • the effect of the mechanisms used to limit the number of principals who can access information

  • e.g. cryptography or computer access controls.

 

Confidentiality: an obligation to protect some other person’s or organization’s secrets if you know them

 

Privacy:

  • the ability and/or right to protect your personal secrets

  • extends to the ability and/or right to prevent invasions of your personal space

  • can extend to families but not to legal persons such as corporations

 

Authenticity: identity + freshness

 

Vulnerability: a property of a system or its environment which, with an internal or external threat, can lead to a security failure

 

Security failure: a state of affairs contrary to the system’s security policy

Security policy:

  • a succinct statement of a system’s protection strategy

  • e.g. “each credit must be matched by an equal and opposite debit, and all transactions over $1,000 must be authorized by two managers”

 

Security target:

  • a more detailed specification

  • sets out the means by which a security policy will be implemented in a particular product – encryption and digital signature mechanisms, access controls, audit logs, and so on

  • will be used as the yardstick to evaluate whether the designers and implementers have done a proper job

 

Fault tolerance:

  • the amount of failure within out system before the system breaks

  • e.g. Byzantine problem

    • there are n generals defending Byzantium

    • t generals have been bribed by the Turks to cause as much confusion as possible in the command structure

    • Each general can exchange confidential and authentic communications with each other general

    • what is the maximum number t of traitors that can be tolerated?

    • answer: solution iff

 

Naming (in distributed systems)

  • the function of names is to facilitate sharing of information

  • naming information may not be all in one place, so resolution has all the normal issues of a distributed system

  • it is bad to assume that only so many names will be needed (IPv4)

  • global names are not as powerful as would be expected

    • often, especially in local contexts, will have costs and no benefits

  • names may be used as passwords, and there are inherent issues with that

  • bind names as late as possible (DNS rather than hard coding addresses)

 

TCB: set of components whose failure could cause a breach of the security policy

 

Mandatory access control: system is built to enforce the security policy, independent of user actions

Bell-LaPadula model

  • a security policy model

  • military model in the 1970s

  • introduced reference monitor

    • mediates all access control decisions

    • small enough to be completely verified

    • like a TCB

  • classification levels

    • top secret (could endanger many lives)

    • secret (could endanger lives)

    • confidential

    • (restricted)

    • open

  • write up (no write down), read down (no read up)

  • explicitly doesn't deal with

    • covert channels

    • networking implementation

  • uses mandatory access control

  • tranquillity property

    • strong tranquillity: security labels never change during system operation

    • weak tranquillity: security labels never change during system operation in a way that breaks the security policy

  • high water mark principle

    • can use if using weak tranquillity

    • start at unrestricted

    • upgrade clearance up to that person's actual clearance, if they access files requiring it

    • do not go down once having gone up

 

Non-interference: where High's actions have no effect on what Low can see

 

Nondeducibility:

  • Low cannot deduce anything about High's input

  • Low can see High's actions, just not understand them

  • any string of high level inputs is compatible with every string of low level inputs

  • we want this in order to find a model that can deal with applications such as a LAN on which there are machines at both Low and High, with the High machines encrypting their LAN traffic

 

 

Lattice model

  • restrict access to information by level and by codeword (e.g. Ultra for anything to do with the broken Enigma machine)

  • combination of codewords (e.g. Desert Storm and Umbra) gives a compartment

    • codewords are pre-computer way of doing access control groups

  • classifications, with classification level, form a lattice

    • A and B may be incomparable, but will have least upper bound and and greatest lower bound

  • information flows from High to Low, where High is a compartment that dominates Low

    • if two compartments are incomparable then there should be no information flow

 

Composability

  • information flow, nondeducibility and noninterference do not compose

  • e.g. if H3 is attached to H2 then H1 would come out of L

 

 

 

Cascade problem

  • Assume we don't want any system to span all three levels

    • e.g. to help deal with covert channels

  • can join two A systems in the way (right) to breaks the security policy

 

 

 

 

Covert channels

  • e.g. signalling by some shared resource (position of head on disk, memory access times, etc.)

  • is always a trade off between reducing bandwidth of covert channel (cannot eliminate), and being able to get anything done

  • reduce by

    • introducing noise into actions

    • allocating space on disks in fixed sized blocks at specific times

    • schedulers to reduce ability to signal through, e.g., CPU being busy

  • DoD target is 1bps possible bandwidth for covert channels

    • protects large files like photos, but not keys

    • hence military does cryptographic key things in purpose built hardware

 

Polyinstantiation

  • what if Low tries to create a file called X when there is already one of that name owned by High?

  • is easily resolved by different folders (etc.), but hard in databases

    • e.g. problem of using a ship for a S mission

  • UK method

    • prevents mistakes and covert channels

      • covert channel: attempt to add shipment of ammo for Cyprus

    • everyone needs highest clearance to get anything done

  • US method

    • don't have everyone need highest clearance to get anything done

 

 

Non-monotonicity

  • if a piece of equipment classified S has in it a component classified TS, system is non-monotonic, and the system needs to be built to deal with this

 

Chinese Wall model

  • used with companies to prevent conflicts of interest

  • for each object c

    • y(c) is c's company

    • x(c) is c's conflict of interest set

  • simple security property:

    • subject s has access to c iff for all c' that s can read, y(c) not-in x(c') or y(c)=y(c')

  • the *- property

    • a subject s can write to c only if s cannot read any c' with

 

Compartmented system

  • a compartmented system is one where a single user can access high and low level data at the same time

  • e.g. have two windows, one S and one TS

    • can paste from S to TS but not vice versa, etc.

 

Medical security

  • how not to do it:

Aids Database

Highly sensitive

No network link

Medical records

Sensitive

Password access

Admin (e.g. prescription)

Non sensitive

Dialback

 

  •  
    • But certain prescriptions indicate if the person has Aids

 

“Electronic trust structures should mirror those in existing professional practice”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BMA security policy principles

  1. access controls for all records

  2. record opening: a clinician may open a record with herself and the patient on the access control list

  3. one of the clinicians on the ACL must be marked as responsible, and only they can change the ACL

  4. consent and notification: must notify patient of the names on the list (when the file is first opened), and all relevant additions and change of responsibility

  5. persistence: files shall not be deletable until after a fixed time period has elapsed

  6. attribution: audit information of when and by whom each file access is made, and audit trail of deletions

  7. Information flow: from A to B iff

  •  
    • i.e. can move from more general file to more private, but not vice versa

  1. aggregation control: no large targets

  2. TCB shall be minimal

 

Secondary uses of medical records

  • for research/bureaucrats

  • needs to be de-identified

 

Inference control

  • “statistical security”

  • query set control

    • every query must from at least n records (e.g. 6 in NZ)

    • max limits to query

      • cannot allow “everyone” and “everyone - Fred”

  • how to deal with: tracker attacks

    • averaging attacks can pick up outliers

      • can move outliers from local to national regions

    • contextual knowledge hard to deal with

      • e.g. prescription data for doctors in areas

        • instead of anonymised sales numbers, give percentage of quarterly totals

        • otherwise could identify by one week one set of values down, know someone was on holiday then

    • add random noise

    • random sampling

      • query has to specify no of records it needs

      • from 70 000 results give 1000 (pseudo)randomly selected

 

Active attacks

  • if the attacker can add records to the database then can get anything they want

  • can do on metadata (price of prescriptions, etc.)

 

 

Information hiding

  • want to make difficult to detect/jam/decode

    • otherwise, if received undecipherable message from an area, just shell it

  • methods

    • spread spectrum

    • burst keys

    • meteor scatter: bounce radio waves off ion trails left by meteors

    • hide in gif file

  • introduction of noise (e.g. through compression) will damage hidden signal

  • “criminal” methods

    • prepaid mobiles: remember to

      • change sim and handset

      • not buy several at the same time

    • hacked emails

    • free ISPs

 

Banking

  • 1% of staff go bad each year: fraud issues

  • loss of public confidence could cause ruin

    • only around 8% in assets, the rest has been leant out

  • double entry book keeping

    • every debit must have matching credit elsewhere

    • branch must balance

    • different staff keep cash, loan book, etc.

 

Clark-Wilson model

  • is a formal model of security

  • Constrained Data Items (CDIs) can only be accessed by approved TPs

  • Transformation Procedures (TPs) are functions which leave an audit trail and preserve specified invariants

  • rules:

  1. there is a procedure to validate the integrity of any CDI

  2. applying a TP to a CDI preserves integrity

  3. CDIs can only be changed by TPs

  4. subjects can initiate only certain TPs on certain CDIs

  5. triples (User, CDI, TP) enforce separation of duty

  6. there are TPs which take in UDIs and output CDIs

  7. each application of a TP writes enough audit info to roll back (using append only CDI)

  8. subjects initiating a TP are authenticated

  9. only security officers can change authentication lists

 

Separation of duty

  • sequential separation

    • there are a series of steps

    • hoops to jump through to make it harder

  • parallel separation (shared control)

    • e.g. use for a bank guarantee of millions of pounds

 

 

Hybrid

  • Swift model

    • banks have accounts in each other

    • to transfer money is out of your account with them

    • send daily statements to allow daily reconciliation:

      • early detection of any fraud

 

Theory of internal control

  • people optimise their own utility

  • other abuses

    • nepotism

    • empire building

    • rent seeking

 

Service denial attacks

 

Research effort

Industry effort

confidentiality

90%

1%

integrity/authentication

9%

9%

availability

1%

90%

  • Banks use 30% of budget to build redundant systems

  • big enc/dec handshaking uses up resources and can be used for DoS attack

 

Burglar alarms

  • availability, not authentication or confidentiality matters

  • lots of different systems: homes to nuclear power plants

 

How to steal a painting:

  • in major security system there are many overlapping systems

    • difficult to defeats on all of them

  • deter – detect – alarm – delay – response

  • ways of doing it it

    • hide in cupboard, at 1am snatch and run

      • if can get out and to bike before response force gets there, you're good

    • stormy night method

      • on stormy night, cause lots of false alarms

      • keep doing until guards don't respond

      • take the thing

  • feature interaction

    • a fire alarm has precedence over burglar alarm

      • chuck in a smoke grenade

    • power cuts?

  • Break communications

    • cut wire from sensor to controller

    • spoof alarm controller to phone line (as often the crypto is poor, like serial number as key)

    • cut communications

      • wait for guards to come and go then break in

      • should have multiple channels

    • large scale attacks on communications

      • set off all alarms in an entire block of jewellers

      • melt router which handles alarm information using DoS attack

 

Alarms: lessons learned

  • false/real alarm ration is importance

  • trade off between outer and inner alarms

    • outer more likely to be spoofed, but give more delay if responded to

  • important thing is not alarms going off but personnel arriving and not leaving

  • designed around limitations of human response

    • e.g. airports, deliberately overlay (using software) a gun into someone's bag to check if paying attention

    • normally 65-70% of threats missed

    • some places don't have the software

      • do by asking a random passenger “hello, I'm from airport security”

      • easy way to try to get a gun through without risk

 

The three factors for authenticating individual are:

  • 'Something you know', such as a password, PIN or an out of wallet response.

  • 'Something you have', such as a mobile phone, credit card or hardware security token.

  • 'Something you are', such as a fingerprint, a retinal scan, or other biometric.

 

Usability and psychology

  • password concerns

    • 80s

      • technical defeat of password storage

      • technical defeat of password transmission and entry

      • LAN sniffers

      • technical defeat of password retry counter

        • guess one letter at a time

        • can do measuring current on the chip

    • 90s

      • weak defaults

      • attack at point of entry

      • can a user choose a good one, enter it and remember it?

    • mnemonic phrases are good

    • what about password reuse?

  • social engineering

    • plausible/sob story

    • steal purse, pretend to be a bank and ask for pin

    • operational security

      • seen as rules and bureaucracy

      • only phone published, not given, numbers

      • never give out details over the phone

  • social psychology insights

    • 60-70% of people will disbelieve their own eyes to agree with the group

    • ~70% of people will do immoral things if told to do so by authority figure

    • Stanford prison experiment (abuse of “prisoners” by “guards”)

 

  • phishing

    • started properly in 2003

    • two channel authentication prevention

      • get a text “if you want to send £600 to X then enter 4921 in your browser now”

      • still have man in the middle attack

    • laundering

      • if you can't get the money somewhere to launder it, the details aren't worth having

      • bank which aggressively chase potential phishing aren't phished

      • used to use E-gold

      • now use mules:

        • money arrives from “overseas company” to mule, e.g. old person

        • you keep 10%, wire the rest using western union

        • a month later the bank takes it all from your account

    • banks' approach

      • “blame and train”

        • the money loss (in UK) is on the customer

        • leads to banks not being aggressive chasing phishing, and hence worth phishing

      • instead, send more emails!

      • gives instructions by geeks for geeks

  • the IT industry abandoned manuals in the mid '90s

    • people learn by doing

    • the banks are training people in unsafe behaviour, by giving them more information after clicking on links in emails

 

Biometrics

  • iris recognition

    • several hundred degrees of freedom

    • Gabor transform for eye into 256 byte code

    • ~90% of bit match in successive observations of the same eye

    • can be fooled by contact lens

    • unattended use would be difficult

    • in right situations can do automatic recognition with 0% false acceptance

  • manuscript signature

    • computerised versions error rate at 5%

    • useful as screening mechanism to ask for more authentication, no more

  • voice prints

    • error rate of 1-2%

      • worse for older people/manual workers

    • voice print changes suddenly (not a scale) after two or three drinks

      • use to prevent drunk driving?

  • fingerprints

    • 1-2% error rate for automatic recognition

      • not even distribution of errors

    • widely used, e.g. forensics

    • used by welfare systems in the US

      • found that if they used it 1/3 of people stopped claiming

  • common characteristics

    • trade off between fraud rate and insult rate

    • issues with freshness, e.g. fingerprints

    • can be replicated (contact lenses, forgery, etc.)

  • don't necessarily scale in forensics

    • 1 in 1 billion error rate could not be enough

    • how explain to judge or policeman?

 

Phone system security

  • history of attacks

    • 1960s

      • 2600Hz whistle gives you free phone calls

      • could buy a whistle to do it

      • spoofing of paying circuits in payphones

    • 1970s

      • blue boxes

        • took advantage of multi-tone dialling, for free

      • service denial for bookmakers

        • get result first

        • deny service to racetrack to off-track bookies

        • make bets and clean up

    • 1980s

      • switching done by Unix computers

      • if log on can

        • redirect calls

        • tap phone

    • 1990s

      • deregulation and premium services

        • phone fraud on 900 numbers

      • mobile phone cloning

        • analogue phones only used username + password at setup

        • harvest these, create a phone which changed username (and hence number) each time

      • PBX hacking

        • service switched on by default, default password well known

        • phone to local switch and it allows you to phone long distance at its expense

    • 2000s

      • feature interaction

        • ringback + payphones

          • landlord ends up paying

          • bypasses paying facility

 

Phone system lessons

  • hacks for fun lead to criminal uptake

  • attacks all layers 1-7

  • weak foundations exploited

 

cramming

  • consumers are billed for optional services (such as voice mail or paging) they never ordered

 

slamming

  • switch your long distance phone service to their company without your permission

 

 

Service denial attacks

  • dealing with these is generally the hardest part of a secure system design

  • prefer to prevent the attacker mounting a selective attack

    • e.g. if principle is anonymous/there is no name service

  • where this doesn't work have to resort to other things

    • TCP/IP has few defences against flooding attack: fix by tracking down and arresting person

  • internet worm, '88

    • 3 mechanisms

      • tried 432 common passwords

      • used rhosts (gives trusted hosts it could migrate to)

      • stack smashing attack on known Berkley vulnerability

  • syn-flooding

A -> B syn M

B -> A ack M+1

syn N

A -> B ack N+1

  •  
    • need to keep state for each M

    • lesson: don't let anyone force your use of resource(s) early in the protocol

  • bot-nets

    • recruitment via root kits

    • lots of money renting out

 

Memory overwriting attacks

  • many programs don't check length of arguments

  • could

    • rewrite in a safe language

    • use nonces

    • test with strange values

 

Other type-safety values

  • printf with %n : can allow writing to stack

  • integer overflow

  • SQL coersion attack

    • careless web development

    • not sanitise inputs

  • what if it is a safe value in one language but it is passed to another where it is not?

    • need “language lawyer” who understands and owns the APIs

 

Viruses

  • invented in a PhD thesis

  • a worm embedded into another program

  • arms race between virus and anti-virus writers

    • check file size unaltered

      • hide in middle of file or compress it

    • search for tell-tale strings

      • encrypt virus

      • use different key each time (polymorphic decryption)

      • change code by adding junk code each time

    • compute crypto on checksums of all the exes

      • hide in the boot sector/partition table

    • check these too

      • watch for scans and hide self when they are happening

      • attack the anti-virus itself

  • unless have built the whole toolchain cannot be certain of a program being safe

 

Malware

  • professional setup of bad-guys

    • testing against the anti-virus

    • ship patches to the anti-virus patches

 

Firewalls

  • what is authorised traffic?

  • packet filter

    • prevent IP address spoofing

    • filter everything except ports 25 & 80?

    • gets in the way of apps

    • can't deal with fragmentation attacks

      • initial fragment is overwritten by a later one in a way which violates the firewall's security policy

  • circuit gateways

    • reassemble and examine each packet in each TCP circuit

    • can't deal with application level attacks (malicious code)

  • application gateway/relay

    • acts as proxy for telnet/mail/Web etc.

    • can enforce, e.g.

      • stripping macros from Word documents

      • removing active content from a web page

    • problems

      • how differentiate spyware from licensed server traffic?

      • Allow .doc files, which are effectively (scripting) programs?

      • custom proxy for each application?

  • censorship?

  • proxies and anonymisers?

  • malware through programs users shouldn't be using?

 

Intrusion detection

  • goals

    • make bad things less likely

    • draw attention to authority when they do

  • methods:

    • thresholds

      • expenditure > twice moving average

      • phone call > 6 hours

      • 3 failed login attempts

    • misuse detection

      • e.g. ATM card maxed out two days in a row

      • need to have domain specific knowledge

    • “anomaly detection”: look for patterns

  • don't want to cut the service off too much, arbitrarily

 

Cryptography

  • to protect

    • confidentiality

    • authenticity

    • availability

  • possible desirable properties

    • information hiding

    • unpredictability

    • redundancy

  • first principles 1883

    • hard to break in practice even if not in theory

    • the method should be public

    • the security should be in the choice of key

    • key easy to remember and change (HCI)

    • ciphertexts capable of being transmitted by telegraph

    • single person can carry and operate apparatus/documents

  • Vigenere cipher

  •  
    • add key word, e.g. “run” to the plaintext, repeatedly

    • use index of coincidence to find the key word length

    • then can break the encryption by monoalphabetic substitution

  • One time pad

  •  
    • Vigenere cipher with “infinite” key

    • perfectly secure

      • gives confidentiality but no authenticity

    • if you reuse one time pads then the system can be (and was) broken

  • Playfair block cipher

P

A

L

M

E

R

S

T

O

N

B

C

D

F

G

H

I

K

Q

U

V

W

X

Y

Z

 

  •  
    • take the keyword, “Palmerston” and then follow by the rest of the alphabet (omitting J)

    • split plaintext up into pairs

      • if there is a pair which has double letter in it, insert an x and push the second of the double too the next pair

      • if J comes up use I

      • pad with a z at the end if necessary to make a complete pair

      • for each pair

        • if the pair is in the same column/row, replace each letter with the following one (AM becomes LE)

        • otherwise replace with the letters which form the other corner to the 'rectangle' (FI becomes CQ)

    • but if change one letter in plaintext normally changes just one letter in ciphertext: can use to break the key word

  • Test key systems

    • one way function

    • used by banking to authenticate a message (like a MAC)

    • add together the numbers

    • do for account no too?

  • Stream cipher

    • take short key and expand to long keystream

    • secure iff an opponent who knows a lot of keystream cannot guess any more of it

      • number of 1's and number of 0's but be equal

    • similar issue to one time pad: don't want to use the same key twice

      • add message number/other pre-agreed nonce to the short key

    • Linear recurrence relations

      • can be used to implement stream ciphers

      • lagged Fibonacci generator:

    • shift register sequences

      • Fibonacci linear feedback shift registers (LFSR)

        • characteristic polynomial

        • for n bits have a cycle of 2n values

        • starting value in the shift register is the seed

      • multiplexer generator

        • use one LFSR to select the keystream bit from another LFSM using a multiplexer

        • long period

        • resists algebraic attack

      • DVD CSS

        • use summation generator

          • SG is secure with around 5 LFSRs of different length

        • uses two LFSRs of length 17 and 25

        • breakable in 225

      • A5

        • three shift registers, lengths 19, 22, 23

        • each register has a clock bit Cn

        • at each step only let register n step if

        • attacks:

          • divide and conquer: guess the two shorter registers + 5 bits of the longest

          • protocol attack: convince it to switch to weaker encryption

            • weak enc is included because must use in places like France

    • RC4

      • based on tables rather than LFSRs

    • WEP

      • use RC4 stream cipher + IV and CRC for an integrity check

      • problem:

        • CRC(X xor Y) = CRC(X) xor CRC(Y)

        • CRC(plain XOR tweak XOR key) = CRC(plain XOR key) XOR CRC(tweak)

    • cycle length

      • the length of keystream before we see sections repeating

      • in many applications is 2n/2 due to the birthday theorem

  • theoretical models of ciphers

    • normally do not use absolute, provable security

      • reason assuming is absolutely secure “if X is secure then Y based on it is secure”

    • random oracle

      • demon in a box generating arbitrary length random o/p for each input

      • if give same input again get same output as before

  • hash functions and block ciphers

    • to create a hash function from a block cipher, use feed-forward mode

 

 

 

 

 

 

 

 

  • cipher properties (by Shannon)

    • confusion: adding unknown symbols to confuse the attacker as the the value of the plaintext symbol

    • diffusion: spreading the plaintext information through the ciphertext

  • S-box

    • takes m bits of input and gives n bits of output (m*n box)

    • is effectively a lookup table

    • is used for confusion

    • need to be chosen so that

      • no bits are propagated through the SP-network unchanged

      • no information about the key can leak out

  • Serpent

    • 32 rounds of 32 S-boxes

    • s boxes are the same in each round

      • can do efficiently in software (on processor)

  • AES

    • 16 bytes in square table to get efficient linear transforms

    • S not “optimised random” but algebraic

    • 10 rounds for 128 bit keys

    • very secure

      • only attacks have been in implementation defects

  • DES

    • 64 bit block

    • 56 bit key

    • 16 round Feistal

    • function fi

      • takes 32 bits input

      • expands to 48 bits

      • passes through eight 6*4 S-boxes

 

Cryptanalysis

  • linear cryptanalysis

    • collect a series of relations

      • e.g. “bit 2 plus bit 5 of the input to the first S-box is equal to bit 1 plus bit 8 of the output, with probability 13/16,”

    • find a way to unite them into a relation between input, output and key bits, which holds with a probability > ½

    • given a linear relationship holds over the whole cipher with can expect to start recovering keybits once we have about M2 known texts

  • differential cryptanalysis

    • chosen plaintext attack

    • have a plaintext and a difference ΔP (determined by examining the algorithm)

    • look at the difference ΔC in the ciphertext between S(X) and S(X xor ΔP), where

      • S(X) is the S block applied to X

      • difference is done by xor'ing the two operands

      • ΔC = S(X) xor S(X xor ΔP)

    • try to find statistical relations between ΔP and ΔC

 

 

 

Modes of operation

  • electronic code book

    • encrypt each block of plaintext with block cipher to get the ciphertext

    • patterns show through with redundant data

    • vulnerable to cut and splice attacks

  • cipher block chaining

    • hides patterns of redundant data

    • propagates errors for only two blocks

    • hence vulnerable to cut and paste attacks

    • cycle length of 2n/2 (by the birthday theorem)

  • output feedback mode

    • used to create a keystream (for a stream cipher)

    • do by repeatedly encrypting the IV

      •  

          where K is the encryption key

      • K1 = {IV}K

        Ki = {Ki-1}K

    • cycle length of 2n/2 (by the birthday theorem)

  • counter encryption

    • used to create a keystream (for a stream cipher)

      Ki = {IV + i}K

    • has a guaranteed cycle length of 2n (rather than probable one of 2n/2)

  • cipher feedback mode

    • used to create a keystream (for a stream cipher)

    • not used very much

      • silicon is cheaper so do synchronisation in another layer

  • MAC

    • encrypt message with CBC using 0 as IV

    • throw away all but the last ciphertext block

      • otherwise could be vulnerable to cut and splice

    • message length must be fixed

    • use to ensure integrity and privacy

      • calculate MAC using one key

      • CBC-encrypt it with another key

 

Feed forward for hash function

  •  

      h0 = constant

      hi = hi-1 xor BC(hi-1)

  • the feed forward (XORing with the input hi-1) is used to make the function non-invertible

  • for an n bit underlying block cipher one can find

    •  

        in 2n/2 messages

    • M1 ≠ M2

      h(M1) = h(M2)

  • computing MACs with hash functions

    • HMACK (M) = h(k xor A, h(k xor B), M)

      where

        A and B are constants

        k is the key

  • backward security

    • at pre-agreed times pass the key through a hash function and use that as the new key, i.e.

        Ki = h(Ki-1)

    • this means that if the present key is compromised then back traffic cannot be decrypted

  • forward security

    • Ki-1 = h(Ki, Mi 1 , ... , Mi n)

    • if an attacker compromises one party's system and steals the key then as soon as parties exchange a message the attacker can't see then security is restored for future messages

 

Simple block cipher applications

  • fixed code car locks

  • cryptography from key fob to GMU

    • e.g. counter used encryption

      • if counter out of sync wait a couple times to see if the numbers are

  • when put the key in the car

E -> F : N

F -> E : {F, N}KF

  • one time password generators

 

Friend or foe

  • naïve protocol

    • fighter or SAM radar challenges

    • expects response with key of the day

F -> B : N

B -> F : {N}K

  •  
    • “mig in the middle” attack

    • reflection attack

F -> B : N

B -> F : N

F -> B : {N}K

B -> F : {N}K

 

 

 

 

 

 

 

 

Swift

  • used by banks to transfer funds

  • each link besides those between branch and bank are encrypted

  • end to end MAC keys not known to Swift

  • a log is kept at each of the RGPs and Swift of the transaction forwarded (making it harder to forge a transaction)

  • the keys for the MACs are exchanged by senior bank personnel either in person or by sending to personal addresses (intercepting mail at two private addresses being considered to be suitable difficult)

 

ATM (automatic teller machine) networks

  • IBM PIN management method

    • PAN 8807012345691715

    • KP FEFEFEFEFEFEFEFE

    • {PAN}KP A2CE126C69AEC82D

    • PIN 0224...

  • policy: no single employee should be able to get a customer's PAN and PIN, or keys giving same access

  • do all the cryptography in “tamper proof” hardware

  • set up master keys for bank-ATM and bank-bank using multiple trusted staff

 

Attacks on local key storage

  • security module design concept: have a small number of on-board keys in tamper resistant storage

  • use these master keys to protect large numbers of working keys

 

Needham Schroder protocol

A -> S : A, B, NA

S -> A : {NA, B, KAB, {KAB, A}KBS}KAS

A -> B : {KAB, A}KBS

B -> A : {NB}KAB

A -> B : {NB – 1}KAB

  • “bug”

    • no way to tell if the third message is fresh

    • no way to revoke

 

Kerberos

  • derived from Needham-Schroeder

A -> S : A, B

S -> A : {TS , L, KAB, B, {TS , L, KAB, A} KBS } KAS

A -> B : {TS , L, KAB, A} KBS {A, TA} KAB

B -> A : {TA+1} KAB

  • S gives A a ticket {TS , L, KAB, A} KBS which includes a timestamp and a time to live

  • a similar problem of revocation occurs during the lifetime of the ticket

 

Otways Rees

A -> B : M, A, B, {NA, M, A, B}KAS

B -> S : M, A, B, {NA, M, A, B}KAS, {M, A, B, NB}KBS

S -> B : M, {NA, KAB}KAS, {NA, KAB}KBS

B -> A : M, {NA, KAB}KAS

 

Formal verification

  • reason about beliefs

  • authenticity = integrity + freshness

  • pivots on whether A and B share a symmetric key

  • BAN logic

A |≡ X A believes X

A |~ X A once said X

A |=> X A has jurisdiction over X (A is the authority on X and is to be entrusted on it)

A <| X someone sent a message A to X in such a way that X can read and repeat it

#X X is fresh

{X}K X is encrypted under K

A <->K B A and B share key K

  •  
    • message meaning rule:

 

  •  
    • nonce-verification rule

  •  
    • jurisdiction rule

  • example: simplified protocol for electronic cheque

customer C, retailer R

C -> R : {C, NC}K

R -> C : {R, NR, C, NC}K

C -> R : {R, NR, C, NC, X}K

  •  
    • verification

  1.  
    1. R |≡ C |=> X by hardware constraint, that no-one besides C could have said {C,..}K

    2. #X by it's appearance in {R, NR, C, NC, X}K and its sequence number NR

    3. R |≡ C |~ X by hardware constraint

    4. R |≡ C |≡ X by nonce verification rule on 2 and 3

    5. R |≡ X by jurisdiction rule on 1 and 4

  •  
    • method useful to check to make sure haven't forgotten anything

GSM

 

 

 

 

  • protocol

SIM -> HLR IMSI

HLR -> BSC (rand, SRES, KC),...

BSC -> SIM RAND

SIM -> BSC SRES

BSC -> mobile {traffic}KC

where IMSI is the International Mobile Subscriber Number (unique ID mapped to phone)

Ki is a key randomly generated and stored in a database at the HLR, and on the SIM

KC is a ciphering key

{rand}KC = SRES concat KC

(rand, SRES, KC),... is five such triples, bound by the above constraints

  • vulnerabilities

    • BSC-VLR traffic is cleartext over microwave link

    • phone doesn't authenticate the server (can be spoofed, e.g. by police)

    • capture triples on the backbone

 

3gpp

  • third generation mobile phones

  • fixes GSM vulnerabilities like

    • the triples being sent in cleartext

    • vulnerability to rogue base-stations

  • provides end to end encryption between the two mobiles

  • payment issues

    • cannot do the “drop the call after 6 hours” thing because people could use it for on-all-the-time internet

    • billing for other services (e.g. multimedia), not just by phone provider

 

Public key algorithms

  • RSA

    • take large primes p, q

    • n = p*q

    • e*d = 1 (mod phi(n))

    • public key is (n,e)

    • C = Me (mod n)

    • M = Cd (mod n)

    • hazards

      • encoding is a multiplicative homomorphism

        • C1*C2 = (M1*M2)e (mod n)

        • if decoding fails and plaintext is leaked can expose the key

      • small e chosen for quicker encryption

        • can lead to attacks if not properly padded with nonces and random numbers

        • never encrypt the same message twice!

      • using same key for encryption and signing can break the system

  • Diffie Hellman

A -> B : gra

B -> A : grb

A -> B : {M}gra*rb

  •  
    • no authentication

      • man in the middle attack

  • El Gamal signatures

private key X

public signature verification key Y = gX

random key k

r = gk (mod p)

message signature s

r*X + s*k = M (mod p-1)

the El Gamal signature is (r, s)

 

Semi group: a pair (S, .S) s.t.

  • (x . y) . z = (z . (y . z)

  • there is an identity function s.t.

    • x = x . 1 = 1 . x

    • technically this is not a requirement, and when this is true the semi group is also a monoid

 

Group

  • semi group

 

Discrete logarithm

  • easy to compute y given x

y = gx (mod p)

  • hard to compute x given y

    • can solve in any group G in O(G0.5)

Elliptic curve cryptosystems

  • another group (the previous was arithmetic)

  • difficult to choose suitable curve and suitable base point

 

Identity based encryption

  • work out public key from name

  • can use certain elliptic curves

 

Blind signatures

  • Alice wants Bob to sign M without knowing its value

M' = M * Re (mod n)

where R is a random number

  • Bob signs M'

S = M' d (mod n)

  • Alice can then recover Md

  • used for digital cash systems

 

SSL

C -> S : C, C#, NC

S -> C : S, S#, NS, CS

client checks CS with root certificate issued by Verisign etc.

C -> S : {K0}KS

C -> S : {finished, MAC(K1, everything_to_date)}KCS

S -> C : {finished, MAC(K1, everything_to_date)}KSC, {data}KSC

 

C# is client transaction serial number

S# is server transaction serial number

CS is certificate containing KS

KS is server public key

K1 = h(K0, NC, NS)

 

IT economics

  • Metcalfe's law: value of a network α n2

    • where n is the number of users

  • high fixed costs (development and marketing, etc.)

  • low marginal costs (few pence to print a CD)

  • time to market is critical

    • “ship it Tuesday, get it right by version 3”

  • have a lack of security in ramp up to market dominance

    • dump costs on user

  • want to make it so there is a high switching cost

 

Products can be worse than useless

  • websites with Etrust certificate are two times more likely to be malicious

 

Conflict theory

  • defence of a country could depend on

    • least effort (of laziest citizen)

    • best effort (of champion)

    • sum of efforts

  • software is a mix

    • least effort of the worst programmer

    • best effort of the system architect

    • sum of effort of the testers

 

 

Open vs. Closed: which does it help more, the programmer or the hacker?

  • openness helps both equally if the bugs are

    • random

    • standard dependability model assumptions apply

  • if you argue that open is better then have to show that the variations of the actual distribution of bugs from the random distribution => you can fix more bugs than are exploited

 

Dining cryptographers problem solution

  • each cryptographer picks a random number in private and shows it to the cryptographer to his right

  • each cryptographer computes the difference between their own number and the number they were shown by their neighbour to the left, adding a 1 if they want to indicate that they bought the dinner

  • each cryptographer publicly announces their result.

  • add up the published numbers

    • if the sum is 0 the NSA paid

    • if the sum is 1 then a cryptographer paid

  • (assuming one cryptographer transmitted a message then it was paid for by a cryptographer)

 

Surveillance

  • by legal requirements on ISPs etc. to include a tap (UK)

    • displacement activity

    • large, expensive system which is rarely used

  • sophisticated hardware (US) which has to have court order to put in place

 

Peer to peer systems

  • an anonymous, non-jammable channel could be used to send out libellous/blasphemous/copyrighted data without getting caught

  • peer to peer systems a reaction to attempts to litigations attempting to prevent, e.g. one man publishing details about the “inside” of Scientology

  • participating machines are all equal and can all talk to one another

 

Censorship resilient systems

  • when coalesce with file sharing get peer to peer networks

  • decentralised for survivability

 

Type of attackers

  • class 1: clever outsiders

    • intelligent but little knowledge of the system

    • only moderate tools

    • generally take advantage of weaknesses rather than creating them

  • class 2: knowledgeable insider

    • substantial specialised technical education and understanding

    • access to most of the system

    • sophisticated tools

  • class 3: funded organisations

    • able to assemble teams of specialists

    • top of the range tools

    • can use class 2 attackers as part of the team

 

 

Tamper resistance

 

FIPS

  • US government standard for cryptography modules

  • Level 1

    • requires no specific secure hardware besides being production grade components

    • can use an unevaluated operating system

  • Level 2

    • requires tamper-evidence (e.g. through tamper-evident coatings or seals)

      • intruder must break seals to get to keys and Critical Security Parameters (CSPs)

    • requires a role-based authentication in which a cryptographic module authenticates the authorization of an operator

  • Level 3

    • requires attempt to prevent the intruder from accessing CSPs in the module with high probability of success

    • authenticates the identity of an operator and verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of services

    • requires the entry or output of plaintext CSPs be performed using ports that are physically separated from other ports

  • Level 4

    • physical security mechanisms provide a complete envelope of protection around the cryptographic module

    • penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroing of all plaintext CSPs.

    • modules are useful for operation in physically unprotected environments

    • required to either include special environmental protection features designed to detect fluctuations and zero the CSPs, or to undergo rigorous environmental failure testing

 

How to hack a cryptoprocessor (each one is a way of doing it where the previous security hole has been filled)

  • steal the key

    • from paper as it's being inputted

    • from components on the cryptoprocessor

  • disable switches (which wipe the keys on opening) on the first visit and steal key on the second

  • scrape away potting and put a probe from a logical analyser on the bus

    • is prevented by placing wire in the potting so circuit is broken when scraped away

  • use sand blasting to slowly remove the potting, when the wire shows create another path for the circuit then cut the original one

  • use memory remanence: bits being in the same place get “burned into” RAM, ROM and hard disks

  • use freezing or ionising radiation to burn the data into memory then remove the memory chip

  • monitor electromagnetic and RF signals from the device

    • called Tempest/power analysis

    • prevent by shielding/Faraday cage

 

 

Smart cards

  • primary use is in GSM SIM cards

  • self-contained microcontroller, with a microprocessor, memory and a serial interface integrated on a single chip packaged in a plastic card

  • concept

    • cheap smartcard provides authentication

    • more expensive device provides other functions

  • advantage of concept

    • more expensive device produced in bulk, each unit the same

    • smart card can be replaced relatively easily in case of successful attack

 

Security engineering

  • like software engineering

    • understand the problem

    • choose/design the system security policy

    • build and test

  • failure models

    • solve wrong problem

    • adopt wrong security policy

    • inability with evolving systems that present a moving target

 

Threat tree: two options

  1. start from a bad thing, work out what allows it to happen (see right)

  2. start from an individual failure node, see what it implies

 

 

 

 

 

 

 

Why cryptosystems fail

  • case study of ATM fraud

  • liability

    • US: bank's have to prove their system was correct

    • UK/Europe: bank can basically assume their system is infallible

      • risk transference

  • hence US banks spend less money on security and have less fraud

 

Moral hazard effect

  • remove incentives for people to take care

  • that causes a lack of investment in appropriate risk management strategies

 

Due diligence

  • managers would prefer a check-list to a process: requires less effort

  • must make continued effort to prevent it becoming such

  • security policy “following the herd”

    • prefer expensive solutions from well known companies to good solutions

 

 

Risk reduction: minimalise the probability a risk will occur

Risk avoidance: perform a task to eliminate risk caused by another task

Risk transference: shift impact of risk to a third party

 

Security management is hard because

  • balancing risk and reward

    • note risk in context of the rest of business

    • e.g. if 15% of profit lost by theft, could focus on reducing this or on increasing market share, so it may still be 15% of profit, but you could have 50% more profit before so it is eaten up

  • if in public sector, often have to comply with (arbitrary) standards

  • organisational issues

    • don't want to defend against insider attacks as that appears to disrepudiate your staff

      • ask for lots of money to defend against non-existent hackers, use it for internal defence

    • introduce mechanisms and processes so they don't look arbitrary and bureaucratic

      • e.g. dual-control safe locks as they reduce risk a manager's family is held hostage

  • complacency cycle:

    • lots of attacks

    • focus hard

    • fix the system

    • become lax (repeat)

  • risk thermostat

    • e.g. seat belts make people feel safer so they drive faster

      • casualties are transferred from drivers to pedestrians and cyclists

  • incompetent security managers (it's not a desirable job)

  • moral hazards

 

Insurance

  • of some help for managing large but improbable risks

  • basically do for due diligence

 

 

Trusted Computer Systems Evaluation Criteria (TCSEC)

  • “the orange book”

  • systematic set of standards for secure computer systems

  • C1:

    • discretionary access control by groups of users (considered to be equal to no protection)

  • C2:

    • discretionary access control by single users; object reuse; audit

    • corresponds to carefully configured commercial systems

  • B1:

    • mandatory access control.

    • all objects carry security labels, and the security policy (Bell-LaPadula or a variant)

  • B2:

    • requires a formal model of the security policy & it to be proved consistent with security axioms

    • TCB must be properly structured and its interface clearly defined

    • Covert channel analysis must be performed

  • B3:

    • TCB must be minimal

    • it must mediate all access requests, be tamper-resistant, and be able to withstand formal analysis and testing

    • real-time monitoring and alerting mechanisms

  • A1:

    • formal techniques must be used to prove the equivalence between the TCB specification and the security policy model

 

ITSEC

  • European version of TCSEC

  • bureaucratically designed

    • evaluated by private companies: vendors search around for one which gives them the easiest ride

 

Common Criteria

  • rather than expecting all systems to conform to Bell-LaPadula, evaluate against a protection profile

    • in theory that profile can be defined by the vendor

  • again evaluation done by private companies

  • protection profile

    • set of security requirements

    • supposed to be implementation-independent

  • security target

    • refinement of a protection profile for a given target of evaluation

  • overly focused on technical aspects of the design

 

regulatory environment

  • Regulation of Investigatory Powers (RIP) act

    • can demand IP or telephone data or mobile phone locations at note from a senior police officer (i.e. without a warrant)

    • can demand any crypto key that has been in your possession

  • export control

  • data protection

 

 

copyright

  • software

    • a programmer leaves the company and soon some of your features are in the competitor's software

  • books

    • libraries where people could get books for free helped make publishing a mass industry

  • audio

    • technical measures to enforce

      • “no copy” bits on CDs or cassettes

      • encryption of data until it reaches the sound card

      • sue web sites

  • video and pay-TV

    • cassettes, which worried Hollywood, ended up leading to increased sales, both from video stores and even though people recorded off TV

    • pay-TV scrambled, used cheap tokens (same model as smart cards) to allow quick upgrade after attack, etc.

  • DVD

    • CSS encryption used

    • had a series of keys on a DVD which could be read by a DVD key; if the manufacturer didn't implement protection properly just don't include their key in the next movie DVD

      • once you have broken one key you can break all of them though

    • was broken and put on the internet, Hollywood tried to suppress with lawyers but it just moved to other countries

 

Accessory control

  • challenge response protocols which prevent a competitor's product from being used

  • e.g. if competitor's cartridge loaded into a printer, downgrade quality from 1200dpi to 300dpi

 

Security economics

  • using proprietary and complex encryption algorithm can delay (increase the expense) for an attacker to weeks or months

    • useful if you replace your system once a year, e.g. pay-TV

  • want to leave pirates until their system has built up a user base so they will be discredited

    • but not so long they've made enough money to build a decent crack

 

Economics

  • “ship Tuesday, fix by version three”

    • first to market