Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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/