Valid Policies for
Secure Key
Management
GUILLAUME SCERRI AND RYAN STANLEY-OAKES,
UNIVERSITY OF BRISTOL
Headlines

Generic key wrapping API

Simple proof in the symbolic model

Computational guarantees
Overview

Background



Methodology



The Bana, Comon-Lundh model (BC14)
Our symbolic key management API
Our Results



What are key management APIs?
Computational vs Symbolic Cryptography
Valid API Policies
Symbolic and Computational Security Theorems
Ongoing Work
What is Key Management?




Different keys in a large
cryptographic system have
different properties
Keys may have
relationships between
them e.g. derived keys,
wrapped keys
Keys need to be stored and
used in multiple locations
How do we safely move
keys around?
Cryptographic Tokens
• Tamper Resistant Devices used to securely store keys
• Can carry out cryptographic operations
What is a Cryptographic API?
User
e.g. not allowed
to symmetrically
wrap a sensitive
key under a nonsensitive key
• Asks to perform
cryptographic operation
API
• Checks a policy
Token
• Carries out operation using
internally stored keys
PKCS#11

Widely-used, standardised API

Key Management commands including key wrapping


Also general cryptography including encryption of
data
Keys are pointed to by handles and handles have
attributes

e.g. “the key pointed to by this handle is sensitive”
Security of PKCS#11



Claim: “sensitive keys cannot be revealed in plaintext
off the token”
BUT (Clulow, 2003):
1) WRAP(𝒉, 𝒉′)
receive 𝑐 = {𝑘}𝑘′
2) DECRYPT(𝒄, 𝒉′)
receive 𝑘
PKCS#11’s policy allows this if ℎ′ has attributes wrap
and decrypt, even if ℎ has attribute sensitive
Conflicting Attributes



Wrap/decrypt obviously bad combination of
attributes (there are others)
PKCS#11 doesn't bind the attributes to a key when
wrapping
Different handles pointing to same key can have
different attributes
Even with attribute binding, how can we guarantee
our API policy doesn't allow for attacks?
Security Models
Symbolic Cryptography

Bitstrings are modelled as terms in a term algebra

Attacker specified by finite list of deduction rules, e.g.





Encryption 𝑚, 𝑘 ⊢ {𝑚}𝑘
Decryption {𝑚}𝑘 , 𝑘 ⊢ 𝑚
Encryption is a black box: {𝑚}𝑘 reveals nothing about
𝑚 unless you have 𝑘
Security is of the form “in any combination of the
rules, the attacker never gets …”
Ideal for describing APIs!
Symbolic Cryptography
PROS
•
Short(ish), simple(ish)
proofs
•
Less error-prone
•
Proofs can be automated
•
Security statements are
intuitive; we abstract away
details e.g. of probabilities
CONS
•
Security is usually a
reachability property, not
indistinguishability property
•
List of attacker rules might
miss real attacks – how do you
know you've thought of
everything?
Computational Cryptography



Realistic adversary (arbitrary PPT)
Attacker against a protocol / API can do anything
except break security of underlying primitives (e.g.
encryption scheme)
Security is of the form “for any attacker, the
probability of … is negligible”
Computational Cryptography
PROS
•
Concrete statements about
realistic attackers
•
Easy to formulate
indistinguishability
properties
CONS
•
•
•
•
Complicated security
statements (games,
reductions)
Proofs are usually long
and hard to read
Proofs are error-prone
Very hard to automate
proofs
BC14



Bana, Comon-Lundh (2014): A Computationally
Complete Symbolic Attacker for Equivalence Properties
(CCS 2014)
Symbolic model with computational guarantees
Used to express indistinguishability properties of
protocols
BC14



Like computational model, attacker is any polynomialtime Turing machine with finitely many restrictions
(not finitely many abilities).
Restrictions are axioms: formulae expressing what is
not possible
Axioms come with computational soundness proofs
(computational security property implies axiom)
BC14

Main Theorem: if the axioms imply that the outputs
of two protocols, given an arbitrary symbolic
adversary, are symbolically indistinguishable


i.e. the axioms logically imply the formula 𝑜𝑢𝑡𝑝𝑢𝑡1 ~
𝑜𝑢𝑡𝑝𝑢𝑡2
then the protocols themselves are computationally
indistinguishable in any model for the axioms
How an API Works
• Sends
𝑂(ℎ1 , ℎ2 , 𝑚)
• Receives 𝑐′
User
API
• Receives
𝑂(ℎ1 , ℎ2 , 𝑚)
• Checks properties
of ℎ1 , ℎ2 , 𝑚
• Sends
𝑂′(𝑘1 , 𝑘2 , 𝑚′)
• Receives 𝑐
• Updates state
• Sends 𝑐′
• Receives
𝑂′(𝑘1 , 𝑘2 , 𝑚′)
• Computes 𝑐
• Sends 𝑐
Token
Our API




Symbolic API with commands for (symmetric)
wrapping, unwrapping and corruption
Handle ℎ points to pair 𝑘𝑒𝑦 ℎ , 𝑎𝑡𝑡 ℎ . Policy is a
function P: 𝑎𝑡𝑡1 , 𝑎𝑡𝑡2 ↦ 𝑏 where 𝑏 ∈ ⊤, ⊥
Attributes contains subset called External. External
keys are those not supposed to be used for wrapping:
they could be used to encrypt data, etc.
The aim is that external keys are indistinguishable
from random. Keys used for wrapping cannot be
indistinguishable from random.
Our API


Corruption, C(ℎ,-,-)
Output 𝑘𝑒𝑦 ℎ
Wrap, W(ℎ, ℎ′ , −)
If P 𝑎𝑡𝑡 ℎ , 𝑎𝑡𝑡 ℎ′ = ⊤, output
𝑘𝑒𝑦 ℎ , 𝑎𝑡𝑡 ℎ 𝑘𝑒𝑦
ℎ′
Our API

Unwrap more complicated to reason about because
we do not know what the adversary’s input will look
like – if this is the 𝑖th operation then the adversary
submits 𝑔𝑖 (𝜙𝑖 )



𝜙𝑖 is the list of terms output so far
𝑔𝑖 is a free function symbol.
Unwrap, U(ℎ, −, 𝑔𝑖 (𝜙𝑖 ))
If 𝑔𝑖 (𝜙𝑖 ) can be unwrapped under 𝑘𝑒𝑦(ℎ), parse the
result as 𝑘, 𝑎
Then if 𝑃 𝑎, 𝑎𝑡𝑡 ℎ = ⊤, choose new handle ℎ’ and
output ℎ′ , 𝑎
In new state, ℎ′ points to 𝑘, 𝑎
Sacrifice Function


API security parameterised by sacrifice function
𝑠𝑎𝑐𝑟 which maps an attribute 𝑎 to the set of
attributes an organisation expects to lose if 𝑎 is
compromised
Sacrifice function should derive from organisational
structure (example on next slide)
Example of Sacrifice Function
Attribute of employee
1’s key is in the
sacrifice set of the
attribute of the Boss’s
key, but not the
attribute of the Head
of Team B’s key.
Employee 1
Boss
Head of
Team A
Head of
Team B
Employee 2
Employee 3
Compromised Handles



If C(ℎ,-,-) has been performed then 𝑎𝑡𝑡(ℎ) is called
corrupt attribute
If 𝑎𝑡𝑡 ℎ′ ∈ 𝑠𝑎𝑐𝑟(𝑎𝑡𝑡(ℎ)) and 𝑎𝑡𝑡(ℎ) is corrupt
attribute, then ℎ′ is called a compromised handle.
In this way we can view 𝑘𝑒𝑦 ℎ′ as trivially
compromised due to the corruption of 𝑘𝑒𝑦 ℎ
Valid API Policies

Policy is called valid with respect to the sacrifice
function if it satisfies three criteria:
1. If 𝑃 𝑎, 𝑎′ = ⊤ then 𝑎′ ∉ External
2. If 𝑃 𝑎, 𝑎′ = ⊤ then 𝑎 ∈ 𝑠𝑎𝑐𝑟 𝑎′
3. It forms a directed acyclic graph on attributes
(forbids creation of key cycles)
Symbolic Security
Axioms & valid policy yield:
For any a* in External and any M > 0, no adversary
who
•
•
•
is given the key k* at the start
performs M operations using the API
does not compromise h*
can distinguish between:
•
API1, where h* points to (k*, a*)
•
API2, where h* points to ($, a*), for a random key $.
Computational Security

In any computational API where policy is valid and
wrapping is IND-CCA and INT-CTXT secure, keys that
are


Not trivially compromised
Not used to wrap other keys
are indistinguishable from random.
Ongoing Work



Add more commands to the model
Prove soundness of our axioms with respect to more
modern computational security notions e.g. AE-AD
Investigate modifications to BC14 that allow the
adversary to use an unbounded number of operations
(in particular, so the number of corruptions can
increase with the security parameter)
Recap



A generic symbolic key wrapping API with strong
computational security guarantees and a fairly simple
proof
Keys not trivially compromised and not used to wrap
other keys are indistinguishable from random
The adversary is an active and adaptive polynomialtime Turing Machine using a bounded number of
operations (and hence number of corruptions doesn’t
depend on security parameter)