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 key-translation service A -> S: {T A, B, K AB }K AS S -> B: {T S, A, K AB }K BS 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}K ATM, 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 Host PC or Mainframe Security Module PCI Card or Separate Module Security API VDU 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 Issuing Bank Regional HQ HSM ATM Acquiring Bank Issuing Bank ATM Network HSM HSM with keypad HSM

Start with your bank account number (PAN) Encrypt with PIN Derivation Key (aka PMK – Pin Master Key) 22BD 4677 F1FF 34AC Chop off the (B->1) End 2213(D->3) How are PINs Generated ? decimalise

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 ABCDEF digit out 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 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 Mr M K Bond –Balance £ –PIN Offset 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 Source HSM Dest HSM KP1 KP2 Repeat twice… User->HSM : Generate Key Component HSM->Printer : KP1 HSM->User : { KP1 } ZCMK Combine components… User->HSM : { KP1 } ZCMK,{ KP2 } ZCMK HSM->User : { KP1 xor KP2 } ZCMK Repeat twice… User->HSM : KP1 HSM->User : { KP1 } ZCMK Combine components… User->HSM : { KP1 } ZCMK,{ 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. HSMATM 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 Master Key TMK-ATM - used for everything { TC1 } TC { TC1 } TMK-ATM but how? TC1

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 : E Km  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... D KEK1  old_CV (E KEK1  old_CV (KEY)) = KEY Attack... D KEK2  new_CV (E KEK1  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 2 56 search for one key becomes a 2 40 search for any one of 2 16 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 40 bits16 bits Generate 2 16 keys Encrypt test vectors U->C : { KEY1 } KM C->U : { } KEY1 Do 2 40 search Cryptoprocessor’s EffortSearch Machine’s Effort 56 bit key space

Collision Search on 3DES E K (D K (E K ( KEY ) = E K (KEY) AA XY AABB AB A Single Length Key Double Length “Replicate” Double Length

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_Digits i = { 0 } Kmi

Example Key Entry Security Officer 1 SM?IK 86 08F8E3983E3BDF26 SM!IK BA78B3F SM?IK 87 E92F67BFEADF91D9 SM!IK 00 0D7604EBA10AC7F3 Security Officer 2 (... n) SM?AK 86 FD29DA DC 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 = to FFFF { 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) PIN_Verify Yes/No (eliminates 1 combination) ABCDEF Trial PIN 0000 PAN Encrypted PMK 48CCA975F4B2C8A5 1. Encrypt PAN Raw PIN = 22BD 2. Decimalise Natural PIN = Verify 0000 != 2213

Decimalisation Table Attack (2) PIN_Verify Yes/No (eliminates all PINs containing digit 7) ABCDEF Trial PIN 0000 PAN Encrypted PMK 48CCA975F4B2C8A5 1. Encrypt PAN Raw PIN = 22BD 2. Decimalise Natural PIN = Verify 0000 = 0000

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 O/SNexus App1 App2 NCA1 NCA2 DriversServices TPM / SSC Hardware Ring 1 Ring 0 Ring 2+

The Future Digital Battlefield O/SNexus DRM App App2 DRM NCA NCA2 DriversServices TPM / SSC Hardware Ring 1 Ring 0 Ring 2+

The Future Digital Battlefield O/SNexus DRM App MyApp DRM NCA MyNCA DriversServices TPM / SSC Hardware Ring 1 Ring 0 Ring 2+

The Future Digital Battlefield O/S (hacked) Nexus DRM App MyApp DRM NCA MyNCA DriversServices TPM / SSC Hardware Ring 1 Ring 0 Ring 2+

The Future Digital Battlefield O/S (hacked) Nexus DRM App MyApp DRM NCA MyNCA DriversServices TPM / SSC Hardware Ring 1 Ring 0 Ring 2+

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 Attacks on IBM 4758 CCA & Hardware Cracker Trusted Computing Cambridge-MIT Institute Pervasive Computing KIC