Automated Analysis of the Security of XOR-Based Key Management - PowerPoint PPT Presentation

Automated Analysis of the Security of XOR-Based Key Management Schemes V´ eronique Cortier, Gavin Keighren, Graham Steel I V N E U R S E I H T Y T O H F G R E U D B I N

1 Automated Teller Machines Graham Steel Security API Analysis March 2007

2 Graham Steel Security API Analysis March 2007

3 Criticality of Key Management PIN derived by: Write account number (PAN) as 0000AAAAAAAAAAAA Graham Steel Security API Analysis March 2007

3 Criticality of Key Management PIN derived by: Write account number (PAN) as 0000AAAAAAAAAAAA 3DES encrypt under a PDK (PIN Derivation Key) Decimalise first 4 digits of result Graham Steel Security API Analysis March 2007

3 Criticality of Key Management PIN derived by: Write account number (PAN) as 0000AAAAAAAAAAAA 3DES encrypt under a PDK (PIN Derivation Key) Decimalise first 4 digits of result PIN = IPIN + Offset (modulo 10 each digit) Offset NOT secure! Graham Steel Security API Analysis March 2007

4 Graham Steel Security API Analysis March 2007

4 data, pin, imp,... Graham Steel Security API Analysis March 2007

4 data, pin, imp,... { | d1 } | km ⊕ data { | pdk1 } | km ⊕ pin Graham Steel Security API Analysis March 2007

5 CCA API - Examples Encrypt Data: → { | D1 } | km ⊕ data , Message Host HSM : → { | Message } | D1 HSM Host : Graham Steel Security API Analysis March 2007

5 CCA API - Examples Encrypt Data: → { | D1 } | km ⊕ data , Message Host HSM : → { | Message } | D1 HSM Host : Verify PIN: → { | PINBlock } | p1 , PAN, { | pdk1 } | km ⊕ pin , Host HSM : OFFSET, { | p1 } | km ⊕ ipinenc → HSM Host : yes/no Graham Steel Security API Analysis March 2007

6 Importing Key Parts ‘Separation of duty’ Key k = k1 ⊕ k2 → Host HSM : k1, TYPE → { | k1 } | km ⊕ kp ⊕ TYPE HSM Host : Graham Steel Security API Analysis March 2007

6 Importing Key Parts ‘Separation of duty’ Key k = k1 ⊕ k2 → Host HSM : k1, TYPE → { | k1 } | km ⊕ kp ⊕ TYPE HSM Host : → { | k1 } | km ⊕ kp ⊕ TYPE , k2, TYPE Host HSM : → { | k1 ⊕ k2 } | km ⊕ TYPE HSM Host : Usually used to import a ‘key encrypting key’ ( { | KEK } | km ⊕ imp ) Graham Steel Security API Analysis March 2007

7 Importing Encrypted Keys Exported from another 4758 encrypted under KEK ⊕ TYPE Key Import: → { | KEY1 } | KEK ⊕ TYPE , TYPE, { | KEK } | km ⊕ imp Host HSM : → { | KEY1 } | km ⊕ TYPE HSM Host : Graham Steel Security API Analysis March 2007

8 Attack (Bond, 2001) (part 1) PIN derivation key: { | pdk } | kek ⊕ pin Have key part { | kek ⊕ k2 } | km ⊕ imp ⊕ kp for known k2 Graham Steel Security API Analysis March 2007

8 Attack (Bond, 2001) (part 1) PIN derivation key: { | pdk } | kek ⊕ pin Have key part { | kek ⊕ k2 } | km ⊕ imp ⊕ kp for known k2 → { | kek ⊕ k2 } | km ⊕ kp ⊕ imp , k2 ⊕ pin ⊕ data , imp Host HSM : → { | kek ⊕ pin ⊕ data } | km ⊕ imp HSM Host : Graham Steel Security API Analysis March 2007

9 Attack (Bond, 2001) (part 2) Key Import → { | pdk } | kek ⊕ pin , data, { | kek ⊕ pin ⊕ data } | km ⊕ imp Host HSM : → { | pdk } | km ⊕ data HSM Host : Graham Steel Security API Analysis March 2007

9 Attack (Bond, 2001) (part 2) Key Import → { | pdk } | kek ⊕ pin , data, { | kek ⊕ pin ⊕ data } | km ⊕ imp Host HSM : → { | pdk } | km ⊕ data HSM Host : Encrypt data → { | pdk } | km ⊕ data , pan Host HSM : → { | pan } | pdk (= PIN!) HSM Host : Graham Steel Security API Analysis March 2007

10 IBM Recommendations Published in response to attacks Graham Steel Security API Analysis March 2007

10 IBM Recommendations Published in response to attacks 1. Use asymmetric key crypto for key import – 2 officer protocol to generate key pair at destination, transfer public key to source – PKA S YMMETRIC K EY I MPORT command Graham Steel Security API Analysis March 2007

10 IBM Recommendations Published in response to attacks 1. Use asymmetric key crypto for key import – 2 officer protocol to generate key pair at destination, transfer public key to source – PKA S YMMETRIC K EY I MPORT command 2. More access control – security officers access fewer commands Graham Steel Security API Analysis March 2007

10 IBM Recommendations Published in response to attacks 1. Use asymmetric key crypto for key import – 2 officer protocol to generate key pair at destination, transfer public key to source – PKA S YMMETRIC K EY I MPORT command 2. More access control – security officers access fewer commands 3. Procedural controls to check entered key parts Graham Steel Security API Analysis March 2007

10 IBM Recommendations Published in response to attacks 1. Use asymmetric key crypto for key import – 2 officer protocol to generate key pair at destination, transfer public key to source – PKA S YMMETRIC K EY I MPORT command 2. More access control – security officers access fewer commands 3. Procedural controls to check entered key parts Not to be confused with Bond’s own recommendations Graham Steel Security API Analysis March 2007

11 Formal Modelling Following the classical ‘Dolev-Yao’ style: Bitstrings modelled as terms Cryptography modelled as function on terms Graham Steel Security API Analysis March 2007

11 Formal Modelling Following the classical ‘Dolev-Yao’ style: Bitstrings modelled as terms Cryptography modelled as function on terms API rules modelled as Horn clauses Graham Steel Security API Analysis March 2007

11 Formal Modelling Following the classical ‘Dolev-Yao’ style: Bitstrings modelled as terms Cryptography modelled as function on terms API rules modelled as Horn clauses Security problem modelled as derivability of a secret term Graham Steel Security API Analysis March 2007

12 Examples Encrypt data: x , { | xd1 } | km ⊕ data → { | x } | xd1 Graham Steel Security API Analysis March 2007

12 Examples Encrypt data: x , { | xd1 } | km ⊕ data → { | x } | xd1 Intruder rules: → { | x } | y x , y { | x } | y , y → x → x ⊕ y x , y Graham Steel Security API Analysis March 2007

12 Examples Encrypt data: x , { | xd1 } | km ⊕ data → { | x } | xd1 Intruder rules: → { | x } | y x , y { | x } | y , y → x → x ⊕ y x , y Secrecy problem undecidable in general Graham Steel Security API Analysis March 2007

13 Characterisation of Class Finite set of atoms (km, imp, data, pin, ... ) XOR term ::= atom atom ⊕ XOR term { | XOR term } | XOR term Encryption term ::= Well Formed Term ::= Encryption term XOR term WFT, ... , WFT → WFT Well Formed Rule ::= Graham Steel Security API Analysis March 2007

14 Theorem If: R finite set of well-formed rules S finite set of well-formed ground terms u some ground well-formed term Then: S ⊢ R u ⇐ ⇒ S ⊢ R u using only well-formed terms. Graham Steel Security API Analysis March 2007

14 Theorem If: R finite set of well-formed rules S finite set of well-formed ground terms u some ground well-formed term Then: S ⊢ R u ⇐ ⇒ S ⊢ R u using only well-formed terms. Corollary: The question of whether S ⊢ R u is decidable Graham Steel Security API Analysis March 2007

15 Decision Procedure 2 12 possible unencrypted terms 2 24 possible encrypted terms ( { | . } | . ) Graham Steel Security API Analysis March 2007

15 Decision Procedure 2 12 possible unencrypted terms 2 24 possible encrypted terms ( { | . } | . ) Encode terms as integers kek ⊕ pin ⊕ data → km kp kek imp exp data pin ← 19 0 0 1 0 0 1 1 Graham Steel Security API Analysis March 2007

15 Decision Procedure 2 12 possible unencrypted terms 2 24 possible encrypted terms ( { | . } | . ) Encode terms as integers kek ⊕ pin ⊕ data → km kp kek imp exp data pin ← 19 0 0 1 0 0 1 1 Each rule is a partial function f : N k → N for k inputs e.g. f 1 : x 1 , x 2 → x 1 ⊕ x 2 x 1 , x 2 → x 1 ⊕ x 2 ≡ Graham Steel Security API Analysis March 2007

15 Decision Procedure 2 12 possible unencrypted terms 2 24 possible encrypted terms ( { | . } | . ) Encode terms as integers kek ⊕ pin ⊕ data → km kp kek imp exp data pin ← 19 0 0 1 0 0 1 1 Each rule is a partial function f : N k → N for k inputs e.g. f 1 : x 1 , x 2 → x 1 ⊕ x 2 x 1 , x 2 → x 1 ⊕ x 2 ≡ f 2 : [ xky | x ] , xtype , [ xkek | km ⊕ imp ] → [ xky | km ⊕ xtype ] IF x = xkek ⊕ xtype Graham Steel Security API Analysis March 2007

16 Decision Procedure 1. Allocate sufficient memory for all possible terms 2. Set to 1 locations corresponding to initial knowledge, rest to 0 3. Exhaustively apply each rule, setting newly discovered terms to 1 4. Repeat 3 until no new terms are discovered Graham Steel Security API Analysis March 2007

16 Decision Procedure 1. Allocate sufficient memory for all possible terms 2. Set to 1 locations corresponding to initial knowledge, rest to 0 3. Exhaustively apply each rule, setting newly discovered terms to 1 4. Repeat 3 until no new terms are discovered Some optimisations used Graham Steel Security API Analysis March 2007