370 likes | 707 Views
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
E N D
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?
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 non-security designer as RF is to make of by a non-RF designer! • And not all security designers agree on how to construct a security system.
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
November 2010 The Problem
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.
November 2010 Components of a Key Management System? • A Key Management System consists of: • Key Management Protocol • Key Derivation Function • Key Storage
November 2010 Components of a Key Management System? • A Key Management System parties are: • Key users (at least two!) • Trust Provider
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
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
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
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.
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!”
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
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
November 2010 Delving into Choices
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
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
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
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
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
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
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.”
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)
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.
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?
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?
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
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
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
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
November 2010 Where to go from here?
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
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.
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.
November 2010 Evaluating state of 802 • Should each 802 technology's security features be reviewed? • By whom and to what criteria?
November 2010 Thank You ! Any Questions ?