Satans Computer Revisited Ross Anderson 22 nd March

Satan’s Computer Revisited Ross Anderson 22 nd March 2005

Talk Structure • Programming Satan’s Computer • Discovering Security APIs: ATM security – – ATM Security Basics Early attacks on HSMs Finding Faults in Type Systems Information Leakage Attacks • The Future of Security APIs : Trusted Computing – Digital Battlefields – Feature Interaction – Getting Formal • Conclusions

Background • Security protocols used for 25 years to authenticate users, authorize 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 Nat. West and others, until early 1990 s: 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 Oct 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 PCI Card or Separate Module Security API Host PC or Mainframe 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 about dishonest insiders, the fourth 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 with keypad 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) 22 BD 4677 F 1 FF 34 AC Chop off the End decimalise 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 0123456789 ABCDEF 0123456789012345 e. g. 22 BD -> 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 – 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 KP 1 Source HSM Dest HSM KP 2 Repeat twice… User->HSM : Generate Key Component HSM->Printer : KP 1 HSM->User : { KP 1 }ZCMK Repeat twice… User->HSM : KP 1 HSM->User : { KP 1 }ZCMK Combine components… User->HSM : { KP 1 }ZCMK , { KP 2 }ZCMK HSM->User : { KP 1 xor KP 2 }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 : { KP 1 }ZCMK , { KP 1 }ZCMK HSM->User : { KP 1 xor KP 1 }ZCMK KP 1 xor KP 1 = 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 TC 1 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 { TC 1 }TC but how? ATM Master Key TMK-ATM - used for everything { TC 1 }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 : TC 1 HSM->User : { TC 1 }TC User->HSM : { TC 1 }TC , { TMK-ATM }TMK HSM->User : { TC 1 }TMK-ATM The attack: User->HSM : PAN HSM->User : { PAN }TC User->HSM : { PAN }TC , { PDK 1 }TMK HSM->User : { PAN }PDK 1

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 • 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 KEK 1 = KORIG KEK 2 = KORIG Å (old_CV Å new_CV) Normally. . . DKEK 1Åold_CV(EKEK 1Åold_CV(KEY)) = KEY Attack. . . DKEK 2Ånew_CV(EKEK 1Å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 3 DES (EK 1, DK 2, EK 1) allow 3 DES key halves to be attacked individually

Collision Search Attack on HSMs • Generate 216 keys • Encrypt test vectors U->C : { KEY 1 }KM C->U : { 00000000 }KEY 1 • Do 240 search Cryptoprocessor’s Effort 16 bits Search Machine’s Effort 40 bits 56 bit key space

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

The PRISM Security Module

The Prism HSM Application • 2 million South African pre-payment electricity meters credited using magic numbers bought from vending machines at local shops • Vending machines use security modules to protect vend 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 3 DES key • Each half loaded in three parts, which are exclusive-or’ed 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 08 F 8 E 3983 E 3 BDF 26 SM!IK 00 916 BA 78 B 3 F 290101 SM? IK 87 E 92 F 67 BFEADF 91 D 9 SM!IK 00 0 D 7604 EBA 10 AC 7 F 3 Security Officer 2 (. . . n) SM? AK 86 FD 29 DA 10029726 DC SM!AK 00 EDB 2812 D 704 CDC 34 SM? AK 87 48 CCA 975 F 4 B 2 C 8 A 5 SM!AK 00 0 B 52 ED 2705 DDF 0 E 4

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 = 000000001 to 0000001 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) Encrypted PMK 48 CCA 975 F 4 B 2 C 8 A 5 PAN 5641820334282218 Trial PIN 0000 0123456789 ABCDEF 0123456789012345 1. Encrypt PAN Raw PIN = 22 BD 2. Decimalise Natural PIN = 2213 3. Verify 0000 != 2213 PIN_Verify Yes/No (eliminates 1 combination)

Decimalisation Table Attack (2) Encrypted PMK 48 CCA 975 F 4 B 2 C 8 A 5 PAN 5641820334282218 Trial PIN 0000 0123456789 ABCDEF 000000010000 1. Encrypt PAN Raw PIN = 22 BD 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 Ring 2+ Ring 1 Ring 0 Hardware NCA 1 App 2 Services NCA 2 Drivers O/S Nexus TPM / SSC

The Future Digital Battlefield Ring 2+ Ring 1 Ring 0 Hardware DRM NCA DRM App 2 Services NCA 2 Drivers O/S Nexus TPM / SSC

The Future Digital Battlefield Ring 2+ Ring 1 Ring 0 Hardware DRM NCA DRM App My. App Services My. NCA Drivers O/S Nexus TPM / SSC

The Future Digital Battlefield Ring 2+ Ring 1 Ring 0 Hardware DRM NCA DRM App My. App Services O/S My. NCA Drivers (hacked) Nexus TPM / SSC

The Future Digital Battlefield Ring 2+ Ring 1 Ring 0 Hardware DRM NCA DRM App My. App Services O/S My. NCA Drivers (hacked) Nexus TPM / SSC

Feature Interaction • Big security problem for telcos … e. g. ringback on pub payphones • Detecting potential feature interaction is the same problem as API security analysis! • ‘If I add these three new transactions to an interface that already has 57, will an existing security policy assertion fail? ’ • It’s the old composition problem, but in a modern industrial context • See subscriber = server, telco = HSM

Getting Formal • How are we going to survive on these battlefields 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”) • We have a CMI project to formalise specification of security APIs, which could make properties clearer • Semi-automated analysis of specifications could help in gaining assurance, locating vulnerabilities, and enumerating 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 CMI project to develop ways to cope with API problems. These might be useful for feature interaction too • The problem is actually 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/~rja 14/ http: //www. cl. cam. ac. uk/~mkb 23/research. html http: //www. cl. cam. ac. uk/~jc 407/ Attacks on IBM 4758 CCA & Hardware Cracker http: //www. cl. cam. ac. uk/~rnc 1/descrack/ Trusted Computing http: //www. cl. cam. ac. uk/~rja 14/tcpa-faq. html Cambridge-MIT Institute Pervasive Computing KIC http: //www. pervasive-cmi. csail. mit. edu/