Analyse des API de sécurité

Graham Steel

Conférences de rentrée 2009

1/51

First Half

What is a Security API

Crypto 101

Use of APIs in the cash machine network

Attacks on the Visa security module

Formal modelling

2/51

3/51

Security APIs

4/51

Crypto Basics

We consider only symmetric key crypto

Problem is now the security of key K

5/51

Cash Machine Network

ATMMaestro UK

HSBCParibasBanque

6/51

HSMs

Manufacturers include IBM, VISA, nCipher, Thales, Utimaco, HP

Cost around $10 000

7/51

Master Key Scheme

8/51

A Word About Your PIN

IPIN derived by:

Write account number (PAN) as 0000AAAAAAAAAAAA

8/51

A Word About Your PIN

IPIN derived by:

Write account number (PAN) as 0000AAAAAAAAAAAA

3DES encrypt under a PDK (PIN Derivation Key)

8/51

A Word About Your PIN

IPIN derived by:

Write account number (PAN) as 0000AAAAAAAAAAAA

3DES encrypt under a PDK (PIN Derivation Key)

PIN = IPIN + Offset (modulo 10 each digit)

Offset NOT secure!

9/51

Example: Print Customer PIN

Host → HSM : PAN, { PDK1 } Km

HSM → Printer : { PAN } PDK1

10/51

Example: Send PDK to Terminal

Host → HSM : { PDK1 } Km,{ TMK1 } Km

HSM → Host : { PDK1 } TMK1

11/51

Terminal Comms Key

12/51

Managing Key Types

13/51

Example: Enter TC key

Host → HSM : TC

HSM → Host : { TC } Km2

14/51

Example: Send TC to Terminal

Host → HSM : { TC } Km2, { TMK1 } Km

HSM → Host : { TC } TMK1

15/51

Attack - Step 1

Spy → HSM : PAN

HSM → Spy : { PAN } Km2

16/51

Attack - Step 2

Spy → HSM : { PAN } Km2, { PDK1 } Km

HSM → Host : { PAN } PDK1

17/51

Dolev-Yao Modelling

Bitstrings modelled as terms in an abstract algebra

Cryptographic algorithms modelled as function on terms

Attack modelled as derivation of secret term

18/51

Dolev-Yao Modelling 2

Atomic terms: pdk1,km,km2,pan, . . .

Functions: {.}.

Intruder rules:

e.g. x,y→{x}y

API rules:

e.g. {x}km,{y}km→{x}y

19/51

Attack Search

Start with ‘initial knowledge’ of intruder

e.g. pan,{pdk1}km,{tmk1}km

apply rules

Note: intruder knowledge increases monotonically, no need to backtrack in

search

Goal is to derive term {pan}pdk1

Can automate search with model checker, theorem prover, or custom tool

20/51

Example - using First Order Theorem Provers

API and intruder modelled in 13 FOL rules (Horn clauses), 12 terms in

initial knowledge

Appears as problem SWV237 (www.tptp.org)

Attack found in < 1 sec by several provers (Vampire, E,. . .)

VSM now has clear TC entry instruction disabled - problem SWV238

Only E can find a model (problem has no finite models)

www.tptp.org

21/51

Next half

A much more complex API - IBM 4758 CCA

Modelling XOR

More attacks

Proving decidability of security for certain APIs

PKCS#11

22/51

IBM 4758 CCA API

23/51

CCA Types

24/51

CCA API - Examples

Encrypt Data:

Host → HSM : { d1 } km⊕data, message

HSM → Host : { message } d1

24/51

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

25/51

Importing Key Parts

‘Separation of duty’

Key k = k1 ⊕ k2

Host → HSM : k1, TYPE

HSM → Host : { k1 } km⊕kp⊕TYPE

25/51

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)

26/51

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

27/51

Attack (Bond, 2001) (part 1)

PIN derivation key: { pdk } kek⊕pin

Have key part { kek⊕k2 } km⊕imp⊕kp for known k2

27/51

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

28/51

Attack (Bond, 2001) (part 2)

Key Import

Host → HSM : { pdk } kek⊕pin, data, { kek⊕pin⊕data } km⊕imp

HSM → Host : { pdk } km⊕data

28/51

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!)

29/51

Formal Modelling

Encrypt data:

x,{d1} km⊕data → {x } d1

29/51

Formal Modelling

Encrypt data:

x,{d1} km⊕data → {x } d1

Intruder rules:

x,y → {x } y

{x } y,y → x

x,y → x⊕ y

29/51

Formal Modelling

Encrypt data:

x,{d1} km⊕data → {x } d1

Intruder rules:

x,y → {x } y

{x } y,y → x

x,y → x⊕ y

Also need

x⊕ (y⊕ z) = (x⊕ y)⊕ z

x⊕ y = y⊕ x

x⊕ x = 0

30/51

Using TPTP

Problem SWV234 in TPTP

Only 11 rules, 15 items in knowledge set

However, only most recent version of Vampire can find the attack

‘Combinatorial explosion’ caused by XOR is the problem

Cannot verify fixes using TPTP provers (yet..)

31/51

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

32/51

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.

32/51

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

33/51

Decision Procedure

212 possible unencrypted terms

224 possible encrypted terms ({ . } .)

33/51

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 ← 0 0 1 0 0 1 1

33/51

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 ← 0 0 1 0 0 1 1

Each rule is a partial function f : ℕk→ ℕ for k inputs

e.g. f1 : x1,x2→ x1⊕ x2 ≡ x1,x2→ x1⊕ x2

33/51

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 ← 0 0 1 0 0 1 1

Each rule is a partial function f : ℕk→ ℕ for k inputs

e.g. f1 : x1,x2→ x1⊕ x2 ≡ x1,x2→ x1⊕ x2

f2 : [xkey∣x],xtype, [xkek∣q]→ [xkey∣q⊕ xtype] IF x = xkek⊕ xtype

34/51

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

34/51

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

Details in [Cortier, Keighren, Steel, TACAS’07]

34/51

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

Details in [Cortier, Keighren, Steel, TACAS’07]

Now we can verify fixes..

35/51

IBM Recommendations

Published in response to attacks

35/51

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

35/51

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

35/51

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

35/51

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

2 and 3 verified in a few seconds, but 1 has a simple attack (see [CKS 07])

36/51

37/51

Key Management - 1

KeyGenerate :new n,k−−−−→ h(n,k);L

Where L= ¬extractable(n),¬wrap(n),¬unwrap(n),

¬encrypt(n),¬decrypt(n),¬sensitive(n)

38/51

Key Management - 2

Wrap :

h(x1,y1),h(x2,y2); wrap(x1), → {y2}y1

extract(x2)

Unwrap :

h(x2,y2),{y1}y2 ; unwrap(x2)new n1−−−−→ h(n1,y1); extract(n1), L

where L=

¬wrap(n1),¬unwrap(n1),¬encrypt(n1),¬decrypt(n1),¬sensitive(n1).

39/51

40/51

Key Management - 3

Set Wrap : h(x1,y1); ¬wrap(x1) → ;wrap(x1)

Set Encrypt : h(x1,y1); ¬encrypt(x1) → ;encrypt(x1)...

...

UnSet Wrap : h(x1,y1); wrap(x1) → ;¬wrap(x1)

UnSet Encrypt : h(x1,y1); encrypt(x1) → ;¬encrypt(x1)...

...

Some restrictions, e.g. can’t unset sensitive

41/51

Key Usage

Encrypt :

h(x1,y1),y2; encrypt(x1) → {y2}y1

Decrypt :

h(x1,y1),{y2}y1 ; decrypt(x1) → y2

42/51

Key Separation Attack (Clulow, 2003)

Intruder knows: h(n1,k1), h(n2,k2).

State: wrap(n2), decrypt(n2), sensitive(n1), extract(n1)

Wrap: h(n2,k2), h(n1,k1)→ {k1}k2

Decrypt: h(n2,k2), {k1}k2 → k1

43/51

44/51

Formal Model

Rules:

T ;Lnew ñ−−−→ T ′;L′

44/51

Formal Model

Rules:

T ;Lnew ñ−−−→ T ′;L′

Important difference between this and previous and APIs:

State L,L′,L′′, . . . not monotonic, and may contain loops

45/51

Modes

h : Nonce×Key→ Handle

senc : Key×Key→ Cipher

aenc : Key×Key→ Cipher

pub : Seed→ Key

priv : Seed→ Key

a : Nonce→ Attribute for all a ∈ A

x1,x2,n1,n2 : Nonce

y1,y2,k1,k2 : Key

z,s : Seed

46/51

Implementation

Bound fresh material

finite vocabulary of terms for acyclic modes

Propositional encoding

one prop each I(term), att(nonce)

NuSMV

search for I(k) for sensitive k

47/51

Fix decrypt/wrap attack..

47/51

Fix decrypt/wrap attack..

Set Wrap : h(x1,y1); ¬wrap(x1),¬decrypt(x1) → wrap(x1)

Set Decrypt : h(x1,y1); ¬wrap(x1),¬decrypt(x1) → decrypt(x1)

47/51

Fix decrypt/wrap attack..

Set Wrap : h(x1,y1); ¬wrap(x1),¬decrypt(x1) → wrap(x1)

Set Decrypt : h(x1,y1); ¬wrap(x1),¬decrypt(x1) → decrypt(x1)

Unset Wrap

Unset Decrypt

48/51

Another Attack

Intruder knows: h(n1,k1), h(n2,k2), k3State: sensitive(n1),extract(n1), unwrap(n2), encrypt(n2)

SEncrypt: h(n2,k2), k3 → senc(k3,k2)

Unwrap: h(n2,k2), senc(k3,k2)newn3−−−−→ h(n3,k3)

Set wrap: h(n3,k3) → wrap(n3)

Wrap: h(n3,k3), h(n1,k1) → senc(k1,k3)

Intruder: senc(k1,k3), k3 → k1

49/51

Fix decrypt/wrap, encrypt/unwrap..

49/51

Fix decrypt/wrap, encrypt/unwrap..

Intruder knows: h(n1,k1), h(n2,k2), k3

State: sensitive(n1),extract(n1), extract(n2)

Set wrap: h(n2,k2) → wrap(n2)

Wrap: h(n2,k2),h(n2,k2) → senc(k2,k2)

Set unwrap: h(n2,k2) → unwrap(n2)

Unwrap: h(n2,k2),senc(k2,k2)newn4−−−−→ h(n4,k2)

Wrap: h(n2,k2),h(n1,k1) → senc(k1,k2)

Set decrypt: h(n4,k2) → decrypt(n4)

SDecrypt: h(n2,k2),senc(k1,k2) → k1

50/51

Trusted Keys

Introduced in V2.20 of PKCS#11 (after Clulow’s attacks)

SO can mark keys as trusted

Keys can be marked wrap with trusted

Can show security of this in our model

Full story in [Delaune, Kremer, Steel, CSF’08]

51/51

Summary

Security APIs critical part of system design

Have seen attacks on VSM, CCS, PKCS#11

Formal analysis can find attaks, verify fixes

More info at:

http://www.lsv.ens-cachan.fr/∼steel/

(links to publications, security APIs FAQ, ASA Workshop, other

researchers in API analysis, etc.)

http://www.lsv.ens-cachan.fr/~steel/