Satan’s Computer Revisited
Ross Anderson
17th June 2004
Talk Structure
• Programming Satan’s Computer
• Discovering Security APIs: ATM security
–
–
–
–
–
ATM Security Basics
Early attacks on HSMs
Finding Faults in Type Systems
Problems with DES
Information Leakage Attacks
• The Future of Security APIs : Trusted Computing
– Digital Battlefields
– Getting formal
• Conclusions
Background
• Security protocols used for 25 years to
authenticate users, authorise transactions
• E.g. ‘wide-mouthed frog’ protocol - Alice and Bob
each share a key with Sam, and use him as a keytranslation service
A -> S: {TA, B, KAB}KAS
S -> B: {TS, A, KAB}KBS
• Errors kept being found in protocols, often years
after the fact!
Background (2)
• Example in banking - offline PIN verification as
used by NatWest and others, until early 1990s:
A/c no, {PIN}KATM, Limit, Exp
• First attack - clone the cards
• Second attack - cut and splice your encrypted PIN
value with other people’s account numbers
• Led UK banks to move to online-only processing
from about 1993
Satan’s Computer
• We usually assume ‘computer good, program
probably bad’
• Yet a network under an adversary’s control seems
the most hostile computer there is
• Unlike ‘Murphy’s computer’, the adversary causes
the worst possible things to go wrong - hence
‘Satan’s computer’
• What can we do? Well, 25 years of protocol
analysis work have left us with many useful rules
of thumb and papers on applying formal methods
Hardware Security Modules
What is a Security API ?
• An API that allows users to work with sensitive
data and keys, and uses cryptography to enforce
a policy on the usage of data
VDU
Security Module
Host
PCI Card or Separate Module
PC or Mainframe
Security API
I/O Devs
Network
Applications
• Enforcing access policies to sensitive information
Example: granting signing permission at a CA
• Protecting critically sensitive data
Example: PIN generation keys at banks
• Protecting data in hostile environments
Example: making it harder for operators to tamper with token
vending machines (electricity, national lottery etc…)
• Coping with high crypto throughput requirements
Example: SSL acceleration for web servers
… the first three are all about dishonest insiders, the fourth often
partly so
Hardware Security Modules
• An instantiation of a security API
• Often physically tamper-resistant
(epoxy potting, temperature & x-ray sensors)
• May have hardware crypto acceleration
(not so important with speed of modern PC)
• May have special ‘trusted’ peripherals
(key switches, smartcard readers, key pads)
(referred to as HSMs subsequently)
ATM Network Security
• ATM security was the “killer app” that brought
cryptography into the commercial mainstream
• Concrete security policy for APIs:
“Only the customer should know her PIN”
• Standard PIN processing transactions, but multiple
implementations from different vendors using
hardware to keep PINs / keys from bank staff
• IBM made CCA manual available online
– Excellent detailed description of API
– Good explanation of background to PIN processing APIs
– Unfortunately: lots of uncatalogued weaknesses.
HSM Use in Banks
Acquiring
Bank
Issuing
Bank
ATM Network
HSM
HSM
HSM
HSM
HSM with
keypad
HSM
HSM
HSM
ATM
HSM
Issuing Bank
Regional HQ
How are PINs Generated ?
Start with your bank account number (PAN)
5641 8203 3428 2218
Encrypt with PIN Derivation Key
(aka PMK – Pin Master Key)
22BD 4677 F1FF 34AC
decimalise
Chop off the
End
2213
(B->1)
(D->3)
The Decimalisation Table
• Remember encrypted result was in hexadecimal
• Encryption produces output that looks uniformly
distributed, so 0-F are all equally likely
• Decimalisation Table used to map 0-F back to 0-9
digit in
digit out
0123456789ABCDEF
0123456789012345
e.g. 22BD -> 2213
• Because some numbers have several hexadecimal
digits mapped to them, they are more likely to occur
in issued PINs than others
Collecting Frequency Distributions
Example Distribution : HSBC
24
22
20
18
16
14
12
10
8
6
4
2
0
0
1
2
3
4
5
6
7
8
9
Sample size: 45 people (just large enough to prove non-uniform hypothesis with 1% conf)
How do I change my PIN?
• Most store an offset between the original
derived PIN and your chosen PIN
• Example bank record…
–
–
–
–
PAN
Name
Balance
PIN Offset
5641 8233 6453 2229
Mr M K Bond
£1234.56
0000
• If I change PIN from 4426 to 1979, offset
stored is 7553 (digit-by-digit modulo 10)
Offset Calculation Attack (1989)
• Bank adds a new command to the API to calculate the
offset between a new generated PIN and the customer’s
chosen PIN
• Possessing a bank account gives knowledge of one
generated PIN. Any customer PIN could be revealed by
calculating the offset between it and the known PIN
U->C : Old PAN, Old offset, New PAN
C->U : New offset
VSM Attack (2000)
• Top-level crypto keys exchanged between banks in
several parts carried by separate couriers, which are
recombined using the exclusive-OR function
KP1
Source
HSM
Dest
HSM
KP2
Repeat twice…
User->HSM
: Generate Key Component
HSM->Printer : KP1
HSM->User
: { KP1 }ZCMK
Repeat twice…
User->HSM
: KP1
HSM->User
: { KP1 }ZCMK
Combine components…
Combine components…
User->HSM
: { KP1 }ZCMK ,{ KP2 }ZCMK
User->HSM
: { KP1 }ZCMK ,{ KP2 }ZCMK
HSM->User
: { KP1 xor KP2 }ZCMK
HSM->User
: { KP1 xor KP2 }ZCMK
Idea: XOR To Null Key
• A single operator could feed in the same part twice,
which cancels out to produce an ‘all zeroes’ test key.
PINs could be extracted in the clear using this key
Combine components…
User->HSM
: { KP1 }ZCMK , { KP1 }ZCMK
HSM->User
: { KP1 xor KP1 }ZCMK
KP1 xor KP1 = 0
Type System Attack (2001)
• ATMs are simpler than HSMs and have only one master
key. ATMs need to be sent Terminal Communications
keys (session keys) for link cryptography.
HSM
TC1
Master Keys
TC – terminal communications
TMK – terminal master keys & PIN derivation keys
ZCMK – zone control master keys (between HSMs)
WK – working keys (session keys)
LP – local PIN storage key
{ TC1 }TC
but how?
ATM
Master Key
TMK-ATM - used for everything
{ TC1 }TMK-ATM
Type System Attack (2)
• PIN derivation keys (PDKs) share the same type as Terminal
Master Keys (TMKs), and encrypting communication keys for
transfer to an ATMs uses exactly the same process as calculating a
customer PIN – encryption with single DES.
User->HSM
: TC1
HSM->User
: { TC1 }TC
User->HSM
: { TC1 }TC , { TMK-ATM }TMK
HSM->User
: { TC1 }TMK-ATM
The attack:
User->HSM
: PAN
HSM->User
: { PAN }TC
User->HSM
: { PAN }TC , { PDK1 }TMK
HSM->User
: { PAN }PDK1
VSM Type Diagram
How Type-System Attack Was Found
Control Vectors
• IBM implementation, across many products since
1992, of the concept of ‘type’
• An encrypted key token looks like this :
EKmTYPE( KEY ), TYPE
IBM 4758 Key Hierarchy
Key Part Import
• Thee key-part holders, each have KPA, KPC, KPC
• Final key K is
KPA KPB KPC
• All must collude to find K, but any one key-part holder can
choose difference between desired K and actual value.
4758 Key Import Attack
KEK1 = KORIG
KEK2 = KORIG  (old_CV  new_CV)
Normally ...
DKEK1old_CV(EKEK1old_CV(KEY)) = KEY
Attack ...
DKEK2new_CV(EKEK1old_CV(KEY)) = KEY
IBM had known about this attack, documented it
obscurely, and then forgotten about it!
Collision-Search Attacks
• A thief walks into a car park and tries to
steal a car...
• How many keys must he try?
Car Park 1934
Car Park 2004
Collision-Search Attacks (2)
• Capture-recapture statistics; also ‘meet in the
middle’
• Attack multiple keys in parallel, given a ‘test
vector’ (same plaintext encrypted under each key)
• Typical case: A 256 search for one key becomes a
240 search for any one of 216 keys
• Any one key of a given type is usually enough typical HSMs translate between keys of one type
• Poor implementations of 3DES (EK1, DK2, EK1)
allow 3DES key halves to be attacked individually
Collision Search Attack on HSMs
• Generate 216 keys
• Encrypt test vectors
U->C : { KEY1 }KM
C->U : { 0000000000000000 }KEY1
• Do 240 search
Cryptoprocessor’s Effort
16 bits
Search Machine’s Effort
40 bits
56 bit key space
Collision Search on 3DES
EK(DK(EK( KEY ) = EK(KEY)
A
Single Length Key
A
A
Double Length “Replicate”
X
Y
Double Length
A
A
B
A
B
B
The PRISM Security Module
The Prism HSM Application
• 2 million South African pre-payment electricity
meters credited not with coins but with magic
numbers bought from vending machines at local
shops
• Vending machines use Prism security module to
protect vending keys from shop owners/burglars
• Discovering a vending key allows unlimited token
manufacture = free electricity (until local meters
are rekeyed)
• Vending keys stored in a hierarchy, with a
manually loaded master key at top
Master Key Entry
When vending machine first initialised…
• Three “trusted” security officers arrive with key
• Master key Km is a two-key 3DES key
• Each half loaded in three parts, which are
exclusive-ored together
• Each security officer loads one part of each key
• Check digits returned per keypart after each load
Check_Digitsi = { 0 }Kmi
Example Key Entry
Security Officer 1
SM?IK 86 08F8E3983E3BDF26
SM!IK 00 916BA78B3F290101
SM?IK 87 E92F67BFEADF91D9
SM!IK 00 0D7604EBA10AC7F3
Security Officer 2 (... n)
SM?AK 86 FD29DA10029726DC
SM!AK 00 EDB2812D704CDC34
SM?AK 87 48CCA975F4B2C8A5
SM!AK 00 0B52ED2705DDF0E4
The Faults
• Check digits are given on each half of the master
key, so we can attack each half separately
• After master key is loaded, anyone can continue to
exclusive-or in new parts to the master key
• We can load new parts and extract check values at
line speed - unlike some other HSMs where you
must use a trusted keyboard
• We can thus make a large set of related keys,
discovery of any one of which lets us work back to
find the master key
Making the Related Key Set
For I = 0000000000000001
to 000000000001FFFF
{
SM?AK 87 I xor (I-1)
SM!AK 00 (result)
store the pair ( I , result )
}
Result : 2 x ½ MB files of test vectors
Information Leakage Attacks
• Remember PINs derived from account numbers
• Hexadecimal raw PIN is converted to decimal using
decimalisation table
• Most APIs allow the decimalisation table to be specified
with each PIN verification command
• A normal verification command eliminates one of
10,000 combinations of PIN for the attacker
• If the table is altered, whether or not the alteration
affects correct verification leaks much more information
about the PIN
examples…
(Bond/Clulow 2002)
Decimalisation Table Attack (1)
Encrypted PMK
48CCA975F4B2C8A5
PAN
5641820334282218
Trial PIN
0000
0123456789ABCDEF
0123456789012345
1. Encrypt PAN
Raw PIN = 22BD
2. Decimalise
Natural PIN = 2213
3. Verify
0000 != 2213
PIN_Verify
Yes/No
(eliminates 1 combination)
Decimalisation Table Attack (2)
Encrypted PMK
48CCA975F4B2C8A5
PAN
5641820334282218
Trial PIN
0000
0123456789ABCDEF
0000000100000000
1. Encrypt PAN
Raw PIN = 22BD
2. Decimalise
Natural PIN = 0000
3. Verify
0000 = 0000
PIN_Verify
Yes/No
(eliminates all PINs containing digit 7)
Decimalisation Table Attack (3)
• A surprising number of different attacks can be
carried out by playing around with the
decimalisation table and offset
• It seems everyone who understood HSMs thought
up a different one once the basic idea was known!
• Generally, it’s a ‘differential protocol attack’ on a
distributed computation. Can you tweak some
(untrusted) inputs of a computation so that other
(private) inputs are leaked?
• Very hard to stop in legacy systems
PAN Modification Attack (1)
• Encrypted PINs transferred from ATM to issuing bank
via ATM network using point to point encryption
• At each node PIN block must be decrypted with
incoming key, and re-encrypted with outgoing key
• Common ISO standard “binds” PIN to particular
customer by exclusive-ORing PAN with PIN before
encryption
• Attack: specifying incorrect PAN may make deduced
PIN contain hexadecimal digit ‘A’-’F’, which causes
formatting error. Conditions under which formatting
error arises leaks information about PIN
(Clulow 2002)
The Last Word on ATM Security?
• The current ATM security architecture is fairly
thoroughly broken, i.e. open to insider attack
• Banking security is concerned as much with
liability as with cryptographic security – HSMs
were bought so that customers could be blamed
• In Europe, banks are now switching to EMV
(“Chip and PIN”) and rewriting their terms and
conditions so that fraud is the customer’s fault
• ATM security mechanisms were adapted to all
sorts of other applications, such as prepayment
electricity metering, that are now being fixed
• What next for security API research?
The First Word on Trusted Computing?
• ‘Trusted Computing’ proposals put simple
hardware security modules in every PC
• Also known as ‘Trustworthy Computing’ and
‘Treacherous Computing’ - see my TC FAQ
• TC also encourages compartmentalisation of
applications into trusted and untrusted components
– just like ATM systems
• Security API research may be able to help the
interface designers avoid exploitable mistakes
• Or maybe help you break into your PC after you
buy it, to make it run the software you want
A double-edged sword?
• IRM – Information Rights Management
– Organisations - from Barclays to the Mafia - can stop
leaks
– Microsoft can lock customers in tighter, and thus push
up the price of Office
– Software business could become more ‘normal’ but at a
cost in innovation, growth?
•
•
•
•
•
DRM – Digital Rights Management
Trusted IO – Enter your ATM PIN at your PC
Global PKI – All devices potentially indentifiable
Darknets and trusted anonymity systems
Trusted viruses
Example: Information Rights Management
• Microsoft Office 2003 with
Microsoft Rights Management Server
• Will it be secure when supported by TC?
The “restrict” button
The Future Digital Battlefield
NCA1
App1
Ring 2+
Ring 1
Ring 0
Hardware
App2
Services
NCA2
Drivers
O/S
Nexus
TPM / SSC
The Future Digital Battlefield
DRM NCA
DRM App
Ring 2+
Ring 1
Ring 0
Hardware
App2
Services
NCA2
Drivers
O/S
Nexus
TPM / SSC
The Future Digital Battlefield
DRM NCA
DRM App
Ring 2+
Ring 1
Ring 0
Hardware
MyApp
Services
MyNCA
Drivers
O/S
Nexus
TPM / SSC
The Future Digital Battlefield
DRM NCA
DRM App
Ring 2+
Ring 1
Ring 0
Hardware
MyApp
Services
O/S
MyNCA
Drivers
(hacked)
Nexus
TPM / SSC
The Future Digital Battlefield
DRM NCA
DRM App
Ring 2+
Ring 1
Ring 0
Hardware
MyApp
Services
O/S
MyNCA
Drivers
(hacked)
Nexus
TPM / SSC
Getting Formal
• How are we going to survive on this ‘battlefield’ if
all our technology is for attack, not defence?
• So far we have heuristics for understanding how to
design security APIs, but there are important
properties we would like to gain assurance about
(in formal speak: “prove”)
• Formalising the specification of security APIs could
help make properties clearer
• Semi-automated analysis of specifications could
help in gaining assurance, locating vulnerabilities,
and enumerating all instances of them
Conclusions
• We extended protocol analysis to security APIs, and
broke almost every cryptoprocessor on the market
• If and when Trusted Computing arrives on our
desktops, security APIs will become an integral part
of secure application design
• We have a Cambridge-MIT Institute project with
Ron Rivest to develop formal methods to cope with
API problems. Other FM people should have a go
• But the problem is much wider and deeper than that.
Differential protocol analysis is also new, and there
are fascinating links emerging with composability
and multiparty computation
More Information
Papers, Links & Resources
http://www.cl.cam.ac.uk/~rja14/
http://www.cl.cam.ac.uk/~mkb23/research.html
http://www.cl.cam.ac.uk/~jc407/
Attacks on IBM 4758 CCA & Hardware Cracker
http://www.cl.cam.ac.uk/~rnc1/descrack/
Trusted Computing
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
Cambridge-MIT Institute Pervasive Computing KIC
http://www.pervasive-cmi.csail.mit.edu/