x1 - Département informatique de l`ENS Cachan

Analyse des API de sécurité
Graham Steel
Conférences de rentrée 2009
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
1/51
2/51
Security APIs
3/51
Crypto Basics
We consider only symmetric key crypto
Problem is now the security of key K
4/51
Cash Machine Network
ATM
Maestro UK
Banque
Paribas
HSBC
5/51
HSMs
Manufacturers include IBM, VISA, nCipher, Thales, Utimaco, HP
Cost around $10 000
6/51
Master Key Scheme
7/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!
8/51
Example: Print Customer PIN
Host
→
HSM
:
PAN, { PDK1 } Km
HSM
→
Printer
:
{ PAN } PDK1
9/51
Example: Send PDK to Terminal
Host
→
HSM
:
{ PDK1 } Km , { TMK1 } Km
HSM
→
Host
:
{ PDK1 } TMK1
10/51
Terminal Comms Key
11/51
Managing Key Types
12/51
Example: Enter TC key
Host
→
HSM
:
TC
HSM
→
Host
:
{ TC } Km2
13/51
Example: Send TC to Terminal
Host
→
HSM
:
{ TC } Km2 , { TMK1 } Km
HSM
→
Host
:
{ TC } TMK1
14/51
Attack - Step 1
Spy
→
HSM
:
PAN
HSM
→
Spy
:
{ PAN } Km2
15/51
Attack - Step 2
Spy
→
HSM
:
{ PAN } Km2 , { PDK1 } Km
HSM
→
Host
:
{ PAN } PDK1
16/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
17/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
18/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
19/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)
20/51
Next half
A much more complex API - IBM 4758 CCA
Modelling XOR
More attacks
Proving decidability of security for certain APIs
PKCS#11
21/51
IBM 4758 CCA API
22/51
CCA Types
23/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
HSM
:
{ PINBlock } p1 , PAN, { pdk1 } km⊕pin ,
Verify PIN:
Host
→
OFFSET, { p1 } km⊕ipinenc
HSM
→
Host
:
yes/no
24/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 )
25/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
26/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
27/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!)
28/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
29/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..)
30/51
Characterisation of Class
Finite set of atoms (km, imp, data, pin, . . .)
XOR term
::=
atom
atom ⊕ XOR term
Encryption term
Well Formed Term
::=
::=
{ XOR term } XOR term
Encryption term
XOR term
Well Formed Rule
::=
WFT, . . ., WFT → WFT
31/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
32/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
33/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..
34/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 S YMMETRIC K EY I MPORT 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 S YMMETRIC K EY I MPORT 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 S YMMETRIC K EY I MPORT 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 S YMMETRIC K EY I MPORT 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])
35/51
36/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)
37/51
Key Management - 2
Wrap :
h(x1 , y1 ), h(x2 , y2 ); wrap(x1 ),
→
{y2 }y1
extract(x2 )
Unwrap :
new n
1
h(n1 , y1 ); extract(n1 ), L
h(x2 , y2 ), {y1 }y2 ; unwrap(x2 ) −−−−→
where L =
¬wrap(n1 ), ¬unwrap(n1 ), ¬encrypt(n1 ), ¬decrypt(n1 ), ¬sensitive(n1 ).
38/51
39/51
Key Management - 3
Set Wrap :
Set Encrypt :
h(x1 , y1 ); ¬wrap(x1 ) → ; wrap(x1 )
h(x1 , y1 ); ¬encrypt(x1 ) → ; encrypt(x1 )
..
.
UnSet Wrap :
UnSet Encrypt :
..
.
h(x1 , y1 ); wrap(x1 ) → ; ¬wrap(x1 )
h(x1 , y1 ); encrypt(x1 ) → ; ¬encrypt(x1 )
..
.
..
.
Some restrictions, e.g. can’t unset sensitive
40/51
Key Usage
Encrypt :
h(x1 , y1 ), y2 ; encrypt(x1 ) → {y2 }y1
Decrypt :
h(x1 , y1 ), {y2 }y1 ; decrypt(x1 ) → y2
41/51
Key Separation Attack (Clulow, 2003)
Intruder knows: h(n1 , k1 ), h(n2 , k2 ).
State: wrap(n2 ), decrypt(n2 ), sensitive(n1 ), extract(n1 )
Wrap:
Decrypt:
h(n2 , k2 ), h(n1 , k1 ) → {k1 }k2
h(n2 , k2 ), {k1 }k2 → k1
42/51
43/51
Formal Model
Rules:
new ñ
T ; L −−−→ T ′ ; L′
44/51
Formal Model
Rules:
new ñ
T ; L −−−→ T ′ ; L′
Important difference between this and previous and APIs:
State L, L′ , L′′ , . . . not monotonic, and may contain loops
44/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
45/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
46/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
47/51
Another Attack
Intruder knows: h(n1 , k1 ), h(n2 , k2 ), k3
State: sensitive(n1 ), extract(n1 ), unwrap(n2 ), encrypt(n2 )
SEncrypt:
h(n2 , k2 ), k3
→
senc(k3 , k2 )
new n3
Unwrap: h(n2 , k2 ), senc(k3 , k2 ) −
−−−→ h(n3 , k3 )
Set wrap:
Wrap:
Intruder:
h(n3 , k3 )
→
wrap(n3 )
h(n3 , k3 ), h(n1 , k1 )
→
senc(k1 , k3 )
senc(k1 , k3 ), k3
→
k1
48/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:
Wrap:
Set unwrap:
Unwrap:
h(n2 , k2 )
→
wrap(n2 )
h(n2 , k2 ), h(n2 , k2 )
→
senc(k2 , k2 )
h(n2 , k2 )
→
unwrap(n2 )
new n
4
h(n4 , k2 )
h(n2 , k2 ), senc(k2 , k2 ) −−−−→
h(n2 , k2 ), h(n1 , k1 )
→
senc(k1 , k2 )
h(n4 , k2 )
→
decrypt(n4 )
SDecrypt: h(n2 , k2 ), senc(k1 , k2 )
→
k1
Wrap:
Set decrypt:
49/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]
50/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.)
51/51