Understanding Security APIs - CrySyS Lab

More documents

Recommendations

Info

3.3 Development of the Attack Toolkit 3.3.1 Meet-in-the-Middle Attack The author began a systematic exploration of the VSM API, and also examined the financial API for IBM’s 4758 HSM, called the Common Cryptographic Architecture (CCA). The CCA manual was available on the web [26], and when the author studied it, a number of new attack techniques rapidly emerged. The author observed that both the CCA and the VSM had transactions to generate ‘check values’ for keys – a number calculated by encrypting a fixed string under the key. When keys were exchanged between financial institutions in components, these check values were used to ensure that no typing mistakes had been made during key entry. The input to the check value encryption was usually a block of binary zeroes. Host -> HSM : { TMK1 }Km (Generate Check Value) HSM -> Host : { 0000000000000000 }TMK1 Another intriguing feature was that both HSMs stored their keys on the host computer, and only held master keys internally. Due to this external storage, a user could generate an almost unlimited number of conventional keys of a particular type. It was well known that the check values could be used as known plaintext for a brute force search to find a key, but a full search of the 56-bit DES key space was considered prohibitively expensive. But what if the attacker did not need to search for a particular key, but if any one of a large set would suffice? The attack went as follows: 1. Generate a large number of terminal master keys, and collect the check value of each. 2. Store all the check values in a hash table 3. Perform a brute force search, by guessing a key and encrypting the fixed test pattern with it 4. Compare the resulting check value against all the stored check values by looking it up in the hash table (an O(1) operation). With a 2 56 keyspace, and 2 16 target keys, a target key should be hit by luck with roughly 2 56 /2 16 = 2 40 effort. The author named the attack the ‘meet-in-the-middle’ attack with reference to how the effort spent by the HSM generating keys and the effort spent by the brute force search checking keys meet-in-the-middle 1 . The timememory trade-off has of course been described several decades ago, for example 1 The “meet-in-the-middle” terminology is not to be confused with cryptographic meet-in-themiddle attacks on block ciphers. More appropriate terminology from published literature includes ‘key collision’ and ‘parallel key search’. 26
in the attack against 2DES proposed by Diffie and Hellman [19], neither is the idea of parallel search for multiple keys new (Desmedt describes parallel key search machine in [18]). However, it seems the author was the first to apply the technique to HSMs. It was extremely successful, and compromised almost every HSM analysed – sections 7.2.2, 7.3.3 and 7.3.7 have more details. 3.3.2 3DES Key Binding Attack In the nineties, financial API manufacturers began to upgrade their <strong>APIs</strong> to use triple-DES (3DES) as advancing computing power undermined the security of single DES. IBM’s CCA supported two-key 3DES keys, but stored each half separately, encrypted under the master key in ECB mode. A different variant of the master key was used for the left and right halves – achieved by XORing constants representing the types left and right with the master key Km. Host -> HSM : { KL }Km⊕left , { KR }Km⊕right , data (Encrypt) HSM -> Host : { data }KL|KR The CCA also had support for single DES in a special legacy mode: a ‘replicate’ 3DES key could be generated, with both halves the same. 3DES is encryption with K1, followed by decryption with K2, then encryption with K1, so if K1 = K2 then E(K1, D(K1, E(K1, data))) = E(K1, data), and a replicate key performs exactly as a single DES key. Host -> HSM : (Generate Replicate) HSM -> Host : { X }Km⊕left , { X }Km⊕right The flaw was that the two halves of 3DES keys were not bound together with each other properly, only separated into left and right. There was a clear CRC of the key token, but this was easily circumvented. A large set of replicate keys could be generated and cracked using the meet-in-the-middle attack, then a known 3DES key could be made by swapping the halves of two replicate keys. This known key could then be used to export other more valuable keys. Host -> HSM : (Generate Replicate) HSM -> Host : { X }Km⊕left , { X }Km⊕right Host -> HSM : (Generate Replicate) HSM -> Host : { Y }Km⊕left , { Y }Km⊕right Known key : { X }Km⊕left , { Y }Km⊕right 27
Page 1 and 2: Understanding Security APIs Michael
Page 3: Dedication To Philip Barnes, who co
Page 6 and 7: Understanding Security APIs Michael
Page 8 and 9: 4.3 Certification Authorities . . .
Page 10 and 11: 7.3.1 VSM Compatibles - XOR to Null
Page 12 and 13: Chapter 1 Introduction In today’s
Page 14 and 15: Whatever you intend to get out of t
Page 16 and 17: The aspects of the research relatin
Page 18 and 19: it spawned the development of contr
Page 20 and 21: 2.4 Key Dates Year Events 1960 Deve
Page 22 and 23: ciphertext into a four digit number
Page 24 and 25: service engineer). In order for the
Page 28 and 29: This key binding attack effectively
Page 30 and 31: Chapter 4 Applications of Security
Page 32 and 33: Higher-level goals maybe to achieve
Page 34 and 35: VISA. It also permits end-to-end co
Page 36 and 37: There are three sorts of threat to
Page 38 and 39: control - and would typically be is
Page 40 and 41: Secure Computing Base (NGSCB), prev
Page 42 and 43: Chapter 5 The Security API Industry
Page 44 and 45: • Individuals, Customers, Clients
Page 46 and 47: 5.2.2 1990 to 2000 Year Events 1991
Page 48 and 49: 5.3 Summary of HSM Manufacturers 5.
Page 50 and 51: pose crypto platform market, and si
Page 52 and 53: 5.3.8 Baltimore http://www.baltimor
Page 54 and 55: The Trusted Computing Group will li
Page 56 and 57: available, but should be carefully
Page 58 and 59: Chapter 6 Hardware Security Modules
Page 60 and 61: an increasing concern as the device
Page 62 and 63: • Potting is nowadays one of the
Page 64 and 65: • Light Sensors can be coupled wi
Page 66 and 67: 6.2.1 Tamper-Evidence Hardware Secu
Page 68 and 69: 6.3 HSM Summary This section introd
Page 70 and 71: 6.3.3 nCipher nForce API nCore API
Page 72 and 73: 6.3.5 nCipher netHSM API nCore API
Page 74 and 75: 6.3.7 Thales RG7000 API Proprietary
Page 76 and 77:
6.3.9 Chrysalis-ITS Luna CA3 API PK
Page 78 and 79:
Chapter 7 Analysis of Security APIs
Page 80 and 81:
First Command: Key Part Import User
Page 82 and 83:
achieve the same functionality as o
Page 84 and 85:
Figure 7.5 shows a common key manag
Page 86 and 87:
7.2 The Attacker’s Toolkit This s
Page 88 and 89:
early HSMs actually used this techn
Page 90 and 91:
PIN numbers are often stored in enc
Page 92 and 93:
operating systems. Naively implemen
Page 94 and 95:
The supervisor key switch is turned
Page 96 and 97:
7.3.4 4758 CCA - Key Import Attack
Page 98 and 99:
7.3.6 4758 CCA - 3DES Key Binding A
Page 100 and 101:
Bank Home Bank Home Bank Home Test
Page 102 and 103:
the number of operations the HSM wo
Page 104 and 105:
Implementation Overview The DES cra
Page 106 and 107:
7.3.8 4758 CCA - Weak Key Timing At
Page 108 and 109:
which is a many-to-one mapping betw
Page 110 and 111:
Digits Possibilities A AAAA(1) AB A
Page 112 and 113:
No # Poss. pins Decimalisation tabl
Page 114 and 115:
tables in a generic way will be har
Page 116 and 117:
Security Officer 1 -> HSM : SM?IK 8
Page 118 and 119:
in. Consider the example below, whi
Page 120 and 121:
Indeed it now seems that many conve
Page 122 and 123:
• Search Tools - such as PROLOG -
Page 124 and 125:
\% these are the commands provided
Page 126 and 127:
--------------------------SPASS-STA
Page 128 and 129:
Problem Specification The API is sp
Page 130 and 131:
UI Decisions Figure 7.23: The MIMse
Page 132 and 133:
Figure 7.25: The MIMsearch ‘Watch
Page 134 and 135:
2. If the Security API prevents cer
Page 136 and 137:
it can be enabled and disabled, the
Page 138 and 139:
• When the host machine sends dat
Page 140 and 141:
8.2.5 Legacy Issues • Isolate you
Page 142 and 143:
The Visa Security Module had a seri
Page 144 and 145:
Class I Passive tokens, which prese
Page 146 and 147:
Smartcards Figure 8.2: Chrysalis Lu
Page 148 and 149:
link to the authorisation process f
Page 150 and 151:
To minimise the risk of breach, eac
Page 152 and 153:
When no privileged operations are r
Page 154 and 155:
8.4.3 How Many Security Officers ar
Page 156 and 157:
Chapter 9 The Future of Security AP
Page 158 and 159:
e unable to assure themselves that
Page 160 and 161:
9.4 The Bottom Line Whilst it is ex
Page 162 and 163:
10.1 Roles and Responsibilities Sec
Page 164 and 165:
Chapter 11 Glossary 4753 IBM Crypto
Page 166 and 167:
PKCS#11 Public Key Cryptography Sta
Page 168 and 169:
[14] J. Clulow, “On the Security
Page 170:
[53] http://www.cl.cam.ac.uk/~rnc1/
show all

Understanding Security APIs - CrySyS Lab

Create successful ePaper yourself

Delete template?

Save as template?