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

▶
automated analysis of the security of xor based key
SMART_READER_LITE
LIVE PREVIEW

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

Jan 28, 2023 275 likes •737 views

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

slide-1
SLIDE 1

Automated Analysis of the Security

  • f XOR-Based Key Management Schemes

V´ eronique Cortier, Gavin Keighren, Graham Steel

T H E U N I V E R S I T Y O F E D I N B U R G H

slide-2
SLIDE 2

1

Automated Teller Machines

Graham Steel Security API Analysis March 2007

slide-3
SLIDE 3

2

Graham Steel Security API Analysis March 2007

slide-4
SLIDE 4

3

Criticality of Key Management

PIN derived by: Write account number (PAN) as 0000AAAAAAAAAAAA

Graham Steel Security API Analysis March 2007

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

4

Graham Steel Security API Analysis March 2007

slide-8
SLIDE 8

4

data, pin, imp,...

Graham Steel Security API Analysis March 2007

slide-9
SLIDE 9

4

data, pin, imp,...

{ | d1 } | km⊕data { | pdk1 } | km⊕pin

Graham Steel Security API Analysis March 2007

slide-10
SLIDE 10

5

CCA API - Examples

Encrypt Data: Host

→

HSM :

{ | D1 } | km⊕data, Message

HSM

→

Host :

{ | Message } | D1

Graham Steel Security API Analysis March 2007

slide-11
SLIDE 11

5

CCA API - Examples

Encrypt Data: Host

→

HSM :

{ | D1 } | km⊕data, Message

HSM

→

Host :

{ | Message } | D1

Verify PIN: Host

→

HSM :

{ | PINBlock } | p1, PAN, { | pdk1 } | km⊕pin,

OFFSET, {

| p1 } | km⊕ipinenc

HSM

→

Host : yes/no

Graham Steel Security API Analysis March 2007

slide-12
SLIDE 12

6

Importing Key Parts

‘Separation of duty’ Key k = k1 ⊕ k2 Host

→

HSM : k1, TYPE HSM

→

Host :

{ | k1 } | km⊕kp⊕TYPE

Graham Steel Security API Analysis March 2007

slide-13
SLIDE 13

6

Importing Key Parts

‘Separation of duty’ Key k = k1 ⊕ k2 Host

→

HSM : k1, TYPE HSM

→

Host :

{ | k1 } | km⊕kp⊕TYPE

Host

→

HSM :

{ | k1 } | km⊕kp⊕TYPE, k2, TYPE

HSM

→

Host :

{ | k1 ⊕ k2 } | km⊕TYPE

Usually used to import a ‘key encrypting key’ ({

| KEK } | km⊕imp)

Graham Steel Security API Analysis March 2007

slide-14
SLIDE 14

7

Importing Encrypted Keys

Exported from another 4758 encrypted under KEK⊕TYPE Key Import: Host

→

HSM :

{ | KEY1 } | KEK⊕TYPE, TYPE, { | KEK } | km⊕imp

HSM

→

Host :

{ | KEY1 } | km⊕TYPE

Graham Steel Security API Analysis March 2007

slide-15
SLIDE 15

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

slide-16
SLIDE 16

8

Attack (Bond, 2001) (part 1)

PIN derivation key: {

| pdk } | kek⊕pin

Have key part {

| kek⊕k2 } | km⊕imp⊕kp for known k2

Host

→

HSM :

{ | kek⊕k2 } | km⊕kp⊕imp, k2⊕pin⊕data, imp

HSM

→

Host :

{ | kek⊕pin⊕data} | km⊕imp

Graham Steel Security API Analysis March 2007

slide-17
SLIDE 17

9

Attack (Bond, 2001) (part 2)

Key Import Host

→

HSM :

{ | pdk } | kek⊕pin, data, { | kek⊕pin⊕data } | km⊕imp

HSM

→

Host :

{ | pdk } | km⊕data

Graham Steel Security API Analysis March 2007

slide-18
SLIDE 18

9

Attack (Bond, 2001) (part 2)

Key Import Host

→

HSM :

{ | pdk } | kek⊕pin, data, { | kek⊕pin⊕data } | km⊕imp

HSM

→

Host :

{ | pdk } | km⊕data

Encrypt data Host

→

HSM :

{ | pdk } | km⊕data, pan

HSM

→

Host :

{ | pan } | pdk (= PIN!)

Graham Steel Security API Analysis March 2007

slide-19
SLIDE 19

10

IBM Recommendations

Published in response to attacks

Graham Steel Security API Analysis March 2007

slide-20
SLIDE 20

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 SYMMETRIC KEY IMPORT command

Graham Steel Security API Analysis March 2007

slide-21
SLIDE 21

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 SYMMETRIC KEY IMPORT command

  • 2. More access control

– security officers access fewer commands

Graham Steel Security API Analysis March 2007

slide-22
SLIDE 22

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 SYMMETRIC KEY IMPORT 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

slide-23
SLIDE 23

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 SYMMETRIC KEY IMPORT 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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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

slide-26
SLIDE 26

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

slide-27
SLIDE 27

12

Examples

Encrypt data:

x,{ | xd1} | km⊕data → { | x } | xd1

Graham Steel Security API Analysis March 2007

slide-28
SLIDE 28

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

slide-29
SLIDE 29

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

slide-30
SLIDE 30

13

Characterisation of Class

Finite set of atoms (km, imp, data, pin, ...) XOR term ::= atom atom ⊕ XOR term Encryption term ::=

{ | XOR term } | XOR term

Well Formed Term ::= Encryption term XOR term Well Formed Rule ::= WFT, ..., WFT → WFT

Graham Steel Security API Analysis March 2007

slide-31
SLIDE 31

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

slide-32
SLIDE 32

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

slide-33
SLIDE 33

15

Decision Procedure 212 possible unencrypted terms 224 possible encrypted terms ({ | . } | .)

Graham Steel Security API Analysis March 2007

slide-34
SLIDE 34

15

Decision Procedure 212 possible unencrypted terms 224 possible encrypted terms ({ | . } | .)

Encode terms as integers

kek⊕pin⊕data →

km kp kek imp exp data pin 19

←

1 1 1

Graham Steel Security API Analysis March 2007

slide-35
SLIDE 35

15

Decision Procedure 212 possible unencrypted terms 224 possible encrypted terms ({ | . } | .)

Encode terms as integers

kek⊕pin⊕data →

km kp kek imp exp data pin 19

←

1 1 1 Each rule is a partial function f : Nk → N for k inputs e.g. f1 : x1,x2 → x1⊕x2

≡ x1,x2 → x1⊕x2

Graham Steel Security API Analysis March 2007

slide-36
SLIDE 36

15

Decision Procedure 212 possible unencrypted terms 224 possible encrypted terms ({ | . } | .)

Encode terms as integers

kek⊕pin⊕data →

km kp kek imp exp data pin 19

←

1 1 1 Each rule is a partial function f : Nk → N for k inputs e.g. f1 : x1,x2 → x1⊕x2

≡ x1,x2 → x1⊕x2 f2 : [xky|x],xtype,[xkek|km⊕imp] → [xky|km⊕xtype] IF x = xkek⊕xtype

Graham Steel Security API Analysis March 2007

slide-37
SLIDE 37

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

slide-38
SLIDE 38

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

slide-39
SLIDE 39

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 Possible attack on recommendation 1!

Graham Steel Security API Analysis March 2007

slide-40
SLIDE 40

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 Possible attack on recommendation 1! After fix, verifies all recommendations in a few seconds

Graham Steel Security API Analysis March 2007

slide-41
SLIDE 41

17

Evaluation

Attack As serious as the original Bond attack API Modelling Methodology Works well for this ‘stateless’ API, will need further work to broaden scope XOR/integer representation trick Highly efficient, but requires finite vocabulary of terms

Graham Steel Security API Analysis March 2007

slide-42
SLIDE 42

18

Related Work

Decidable classes for protocols using XOR: Comon and Cortier 03, Verma et al. 05 – incomparable Otter work, Youn et. al 05: Rediscovered old attacks, used heuristics without proof Courant & Monin 06: Verified Bond’s proposed fixes

Graham Steel Security API Analysis March 2007

slide-43
SLIDE 43

19

Summary

Found a new attack on the CCA API Proved decidability for a class containing the API Devised new representation and decision procedure Verified a fixed version of the API More to do (key conjuring, parallel key search...)

Graham Steel Security API Analysis March 2007

slide-44
SLIDE 44

19

Summary

Found a new attack on the CCA API Proved decidability for a class containing the API Devised new representation and decision procedure Verified a fixed version of the API More to do (key conjuring, parallel key search...) EPSRC Project “Automated Analysis of Security Critical Systems” http://dream.inf.ed.ac.uk/projects/aascs/

Graham Steel Security API Analysis March 2007