Satan’s Computer - Revisited

1. Satan’s Computer - Revisited Ross Anderson December 2005

2. 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

3. 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: {TA, B, KAB}KAS S -> B: {TS, A, KAB}KBS • Errors kept being found in protocols, often years after the fact!

4. 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

5. 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

6. Hardware Security Modules

7. 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 Host PC or Mainframe Security Module PCI Card or Separate Module I/O Devs Network Security API

8. 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

9. 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)

10. 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.

11. ATM Network HSM Use in Banks Acquiring Bank Issuing Bank HSM HSM HSM HSM HSM HSM with keypad HSM Issuing Bank Regional HQ ATM HSM HSM

12. 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 Chop off the (B->1) End 2213 (D->3) decimalise

13. 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 0123456789ABCDEF digit out 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

14. Collecting Frequency Distributions

15. Example Distribution : HSBC Sample size: 45 people (just large enough to prove non-uniform hypothesis with 1% conf)

16. How do I change my PIN? • Most store an offset between the original derived PIN and your chosen PIN • Example bank record… • PAN 5641 8233 6453 2229 • Name Mr M K Bond • Balance £1234.56 • PIN Offset 0000 • If I change PIN from 4426 to 1979, offset stored is 7553 (digit-by-digit modulo 10)

17. 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

18. 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 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

19. 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

20. 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 ATM 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 Master Key TMK-ATM - used for everything but how? { TC1 }TMK-ATM { TC1 }TC

21. 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

22. VSM Type Diagram

23. How Type-System Attack Was Found

24. 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

25. IBM 4758 Key Hierarchy

26. 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.

27. 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!

28. Collision-Search Attacks • A thief walks into a car park and tries to steal a car... • How many keys must he try?

29. Car Park 1934

30. Car Park 2004

31. 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

32. 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 Search Machine’s Effort 16 bits 40 bits 56 bit key space

33. Collision Search on 3DES EK(DK(EK( KEY ) = EK(KEY) Single Length Key A A A Double Length “Replicate” Double Length X Y A A B B A B

35. The PRISM Security Module

36. 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

37. 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

38. Example Key Entry Security Officer 1 SM?IK 86 08F8E3983E3BDF26SM!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

39. 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

40. 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

41. 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)

42. Decimalisation Table Attack (1) Encrypted PMK 48CCA975F4B2C8A5 PAN 5641820334282218 Trial PIN 0000 0123456789ABCDEF 0123456789012345 PIN_Verify 1. Encrypt PAN Raw PIN = 22BD 2. Decimalise Natural PIN = 2213 3. Verify 0000 != 2213 Yes/No (eliminates 1 combination)

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

44. 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

45. 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)

46. Other API Attacks (1) • Eli Biham – the GSM key management scheme creates a comms key Kc from a master key Ki and a challenge RAND • Attack: observe RAND when phone using strong crypto, then replay it when weak crypto is in use • Chris Mitchell: some HSMs allow MAC verification transactions to have variable-length MACs • Attack: incremental guessing

47. Other API Attacks (2) • Recent HSM transaction defined by VISA for EMV support • Send key from HSM1 to HSM2 as {text | key} – where text is variable-length • Attack – encrypt {text |00}, {text |01}, etc to get first byte of key, and so on • Vulnerability turned up in multiple products!

48. 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?

49. 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

50. 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