November 2010
Key Management Protocols
Opening Pandora's Box
Value, Cost, and Future Proofing
Robert Moskowitz
ICSAlabs an Independent Division
Of Verizon Business
Dallas, TX
November 8, 2010
Slide 1
November 2010
Agenda
Why are we here?
The Problem
 What is a Key Management System
 Why is it important
 The role of the Key Management Protocol
Delving into choices
 When to do what
 With whom
What next?

Slide 2
November 2010
Why are we here?


Why Pandora's box?
 We will cover the ills that security has visited
upon our precious networks.
 And how the cure can be as bad as the
disease.
Security is as hard to make sense of by a nonsecurity designer as RF is to make of by a nonRF designer!
 And not all security designers agree on how to
construct a security system.
Slide 3
November 2010
Why are we here?



As we move into the “Internet Of Things” (or
your choice of buzz-term) the problems get
harder.
Time to set a tone for security that works across
many problems and limit complexity
 Complexity for the sake of technology reuse is
bad
Not to present a solution, but to focus efforts
 I may raise more questions than answers
 I have MY answers but they are NOT the
only answers
Slide 4
November 2010
The Problem
Slide 5
November 2010
What is a Key Management System?



It controls the keys used in a security system
A security system is only as good as the
weakest part, frequently, the KMS.
 Good Keys and Key Management is essential
to good security.
A Key Management System is a:
 Set of technologies and human procedures
that insure that the keys needed for a security
system are available and trustworthy up to the
risk claims for a system.
Slide 6
November 2010
Components of a Key Management
System?

A Key Management System consists of:

Key Management Protocol

Key Derivation Function

Key Storage
Slide 7
November 2010
Components of a Key Management
System?

A Key Management System parties are:

Key users (at least two!)

Trust Provider
Slide 8
November 2010
Why so many Key Management
Systems?

One for each layer
 Network, Internetwork, and Transport
 Leave data aside for now.
 Based on the assumption that it is the only
one available or needed
 And each has a different reach
 Each layer has a unique risk and liability
 What works for one many not for another
Slide 9
November 2010
Why so many Key Management
Systems?

One for each technology
 “Mine is a unique technology with a unique
problem.”
 Not necessarily a false concern
 Evolutionary development
 Later efforts build on earlier experiences
Slide 10
November 2010
Some basic thoughts on Key
Management Systems


Claim: Key establishment is a outcome of
authentication
 But authentication must be secured
 There is always a boot-strap process
 E.G. Root certificate list is a manually
installed ACL
Or Claim: Authentication a step within key
establishment to qualify the value of the keys
established
Slide 11
November 2010
Some basic thoughts on Key
Management Systems


Authentication costs in
 Human setup
 And/or computation resources
 In cryptographic elements
 And/or number of datagrams exchanged
 This equates to time to authenticate
 Choose some sub-optimization
This is controlled via the Key Management
Protocol, working in tandem with the trust
system.
Slide 12
November 2010
Key Management Protocol


Perhaps the most visible component of a KMS
A set of
 Data packets
 Here is where the cryptography lurks
 State machine(s)
 Assumed to be complete
 Human procedures
 E.G. “If you really care, only initiate this in a
Faraday cage!”
Slide 13
November 2010
Key Derivation Function


Often not viewed as a separate component
from the KMP
 But can impact the complexity and usability of
the KMS
The key protocol places a “Master Key” and the
KDF creates all the many use keys actually
needed by the other security systems.
 If done this protects the MK and limits attack
opportunity
Slide 14
November 2010
Key Storage





Where do you keep your car keys at night?
Can someone clone your driver's license?
 Or your Paypass chip?
Key Storage attacks make for 'good' press
Should keys survive a power cycle?
 Is power cycling even meaningful for a
device?
 Thus features of the Key Storage impact the
KMP.
Respect Key Storage boundaries
Slide 15
November 2010
Delving into Choices
Slide 16
November 2010
Choices
There are always choices



Focus on 802 technologies
 But cognizant of higher layers
The cost of establishing trust (i.e.
authentication)
 (e.g. timings, computational resources)
 Which is primary, Key Establishment or
Authentication?
What comes first, networking or security?
 Juggling risks against resources
Slide 17
November 2010
Choices
There are always choices

Cryptographic components
 Crypto-agility versus simplicity
 Future-proofing
 Against what future?
 And optimizing code size or computation
cost
Slide 18
November 2010
Network and Security Setup
At Odds

At what point in network establishment
(between networking parties) are security
systems activated?
 Starting with key establishment via a KMP.
 Prior to any physical network setup via ACL
deployment (e.g. password files)
 As the first step in network resource
allocation
 After networking services functioning, as
the first allowed data traffic
Slide 19
November 2010
Network and Security Setup
At Odds

Claim:
 Earliest is best.
 The fewer resources committed prior to
security actuation, the fewer the
opportunities for attacks.
 Accepting delaying the KMS may impede
new applications
Slide 20
November 2010
Network and Security Setup
At Odds

Corollary:
 Leaving KMS to a higher layer data path
 Dictates a higher layer model
 Exposes networking services
Slide 21
November 2010
Anonymity and Trust
At Odds


Two anonymous parties CANNOT secure their
communications
One anonymous party CAN converse securely
with a known party
 The basic SSL model
 Assumption on the known parties part that
the anonymous party performed some
identity validation
 The HTTPS click-through syndrome
Slide 22
November 2010
Anonymity

Demanding “mutual authentication” in a KMS
excludes anonymity
 Mitigated with ephemeral identities
 “I don't know who you really are, but I
can work with this ephemeral identity
and trust you have no cause to share it.”
Slide 23
November 2010
Establishing Trust

With today's technologies it is impossible to
establish a secure environment without a trust
process.
 Access Control Lists (ACLs)
 Digital Certificates (X.509)
 Public Key Infrastructure (PKI)
 Authentication Server (RADIUS)
Slide 24
November 2010
Trust in ACLs



ACLs are as old as password files
And as relevant as trusted Digital Certificate
lists in web browsers.
 Frequented by self-signed and expired
certificates
ACLs are appropriate for networks large and
small where a human directed trust initiation
exists.
Slide 25
November 2010
When do Digital Certificates
Help and when hinder

Digital Certificates and a Public Key
Infrastructure (PKI) provides strong identities
 At what cost?
 Good for identifying a network
 Inadequate to establish membership in a
network
 ACL or other authentication still needed!
 Some human process for registration
 Does a 'client' certificate really improve
security?
Slide 26
November 2010
Authentication Servers


Other than using their own authentication
protocol, are they anything more than a
complex ACL mechanism?
 So what?
 Does leverage prior efforts.
 Provides choices for authentication methods
Is the AS protocol run over a secure channel or
provides its own internal security?
 Can an AS 'know' there IS a secure channel in
place?
Slide 27
November 2010
Building trust in the KMS

There are many choices, few are clear good
choices
 Unfortunately, beyond simple ACLs, trust
systems are outside of 802.
 We can't fix them here
Slide 28
November 2010
Where do Key Derivation Functions
fit in?


Long history of deriving actual use keys from
negotiate keys
 Often more than one key needed
 E.G. Encrypt and Authenticate
 Extend key lifetime
 Save on KMP costs
Recent developments to formalize KDFs
 Simplify KMS design efforts
 Inventing your own requires extensive peer
review
Slide 29
November 2010
Cryptography in the KMS

We have learned the need for agility, but
 We have no choice for basic symmetric
cryptography
 Some push Camellia
 Many 'modes of operation' to choose from
 RSA is dying, can we use ECC
 RSA key size recommendations are
exceeding cost value over ECC.
 IPR issues
Slide 30
November 2010
Cryptography in the KMS

Cryptographic hash choices unclear
 Digital Certificates MANDATE cryptographic
hashes
 KDF can use cryptographic MAC in place of
hash
 NIST competition DUE complete in 2012
 What until then?
 Some efforts to create a KMP without a
cryptographic hash
Slide 31
November 2010
Where to go from here?
Slide 32
November 2010
Key early and infrequently



The Key Management Protocol should be one,
if not the first first step in network establishment.
Leverage the Key Derivation Function to
minimize the use of the KMP
 May need a lightweight 'nonce refresh'
mechanism
Design the Key Storage to prolong key life
 Keys that survive system reboot
 Keys for multiple networks
Slide 33
November 2010
Authentication is subservient to the
KMP

Minimize the cost of authentication within the
KMP
 Where possible follow the SSL model to start a
secure channel for an authentication
exchange of a 'client'.
 Certificate or ACL based
 Place risk in the appropriate part of the
network
 E.G. In a hub-spoke network the hub is at
risk if the spoke is not properly
authenticated.
Slide 34
November 2010
Define a minimum Cryptographic
subset


Not all devices can support all practical
cryptographic suite.
 Or even a 'typical' single suite.
 The Internet Of Things (IoT) has both large
and small Things.
 This may require some innovative designs.
Future-proofing for quantum computing is still a
research project.
Slide 35
November 2010
Evaluating state of 802


Should each 802 technology's security features
be reviewed?
By whom and to what criteria?
Slide 36
November 2010
Thank You !
Any Questions ?
Slide 37