TECS Week 2005 Key Management Options Key Management Protocols � Out of band and Compositionality • Can set up some keys this way (Kerberos) � Public-key infrastructure (PKI) • Leverage small # of public signing keys � Protocols for session keys John Mitchell • Generate short-lived session key Stanford • Avoid extended use of important secret • Don’t use same key for encryption and signing • Forward secrecy Cryptography reduces many problems to key management Internet Standardization Process Key Distribution: Kerberos Idea Shared symmetric key Kc � All standards published as RFC (Request for Comment) • Available: http://www.ietf.org KeyCenter • Not all RFCs are Internet Standards ! } Kc {Kcs, {Kcs} � Typical path to standardization Ks • Internet Drafts Shared • RFC symmetric Client • Proposed Standard key Ks { K c s • Draft Standard (requires 2 working implementation) } K s { • Internet Standard (declared by IAB) m s g } � David Clark, MIT, 1992: "We reject: kings, K c s presidents, and voting. We believe in: rough Server consensus and running code.” Key Center generates session key Kcs and distributes using shared long-term keys Kerberos Protocol Public-Key Infrastructure C TGS Kc KDC Known public signature verification key Ka 1 Certificate e } t K k t Ktgs Certificate T i c C , { {Kt} Kc Ktgs Sign(Ka, Ks) Authority Ks {C} Kt S {C, Kt} Ktgs Ticket 1 TGS Client Client Sign(Ka, Ks), Sign(Ks, msg) Server {Ks} Kt {C, Ks} Kv Ticket 2 { C } Server certificate can be verified K { T C s i , c k K e s Kv } t 2 by any client that has CA key Ka K v Service Certificate authority is “off line” 1
Key Exchange Diffie-Hellman Key Exchange � Parties may have initial information � Assume finite group G = 〈 S, • 〉 � Generate and agree on session key • Generator g so every x ∈ S is x = g n • Authentication – know ID of other party • Example: integers modulo prime p • Secrecy – key not known to any others � Protocol • Avoid replay attack ga mod p • Forward secrecy A B • Avoid denial of service gb mod p • Identity protection – disclosure to others • Other properties you can think of??? Alice, Bob share gab mod p not known to anyone else Diffie-Hellman Key Exchange IKE subprotocol from IPSEC m1 ga mod p A, (g a mod p) A B gb mod p B, (g b mod p) , signB(m1,m2) A B m2 Authentication? signA(m1,m2) Secrecy? Replay attack Forward secrecy? Result: A and B share secret g ab mod p Denial of service? Identity protection? Signatures provide authentication, as long as signature verification keys are known IPSec: Network Layer Security IKE: Many modes � Authentication Header (AH) � Main mode • Access control and authenticate data origins • Authentication by pre-shared keys • replay protection • No confidentiality • Auth with digital signatures � Encapsulated Secure Payload (ESP) • Auth with public-key encryption • Encryption and/or authentication � Internet Key management (IKE) • Auth with revised public-key encryption • Determine and distribute secret keys � Quick mode • Oakley + ISAKMP • Algorithm independent • Compress number of messages � Security policy database (SPD) • Also four authentication options • discarded, or bypass 2
Aug 2001 Position Statement How to study complex protocol � In the several years since the standardization of the IPSEC protocols (ESP, AH, and ISAKMP/IKE), … several security problems…, most notably IKE. � Formal and semi-formal analyses by Meadows, Schneier et al, and Simpson, have shown … security problems in IKE stem directly from its complexity. � It seems … only a matter of time before serious *implementation* problems become apparent, again due to the complex nature of the protocol, and the complex implementation that must surely follow. � The Security Area Directors have asked the IPSEC working group to come up with a replacement for IKE. General Problem in Security Example protocol � Divide-and-conquer is fundamental Protocol P1 • Decompose system requirements into parts A → B : {message} KB • Develop independent software modules A → B : KA -1 • Combine modules to produce required system � Common belief: � This satisfies basic requirements • Security properties do not compose • Message is transmitted under encryption • Revealing secret key KA -1 does not reveal Difficult system development problem message Similar protocol Composition P1; P2 Protocol P2 � Sequential composition of two protocols A → B : {message} KB B → A : {message’} KA A → B : KA -1 B → A : KB -1 B → A : {message’} KA B → B : KB -1 � Transmits msg securely from B to A • Message is transmitted under encryption � Definitely not secure • Revealing secret key KB -1 does not reveal • Eavesdropper learns both keys, decrypts message messages 3
Protocol Derivation Framework STS family � Protocols are constructed from: JFK (Just Fast Keying) • components cookie STS 0H STS 0 and RFK (our name) by applying a series of: distribute were proposed certificates • composition, refinement and transformation open successors to IKE responder operations. STS a STS aH JFK 0 � Incrementally achieve design goals m=g x, n=g y k=g xy • Properties accumulate as a derivation proceeds STS STS H JFK 1 � Examples in papers: protect identities • STS, ISO-9798-3, JFKi, JFKr, IKE, … STS PH JFK STS P symmetric Acknowledgement: Dusko Pavlovic [Kestrel] hash RFK Example Component 1 � Diffie-Hellman � Construct protocol with properties: A → B: g a • Shared secret B → A: g b • Authenticated • Identity Protection • Shared secret (with someone) • DoS Protection – A deduces: � Design requirements for IKE, JFK, Knows(Y, g ab) ⊃ (Y = A) ٧ Knows(Y,b) • Authenticated IKEv2 (IPSec key exchange protocol) • Identity Protection • DoS Protection m := g a Component 2 Composition n := g b � Challenge Response: � ISO 9798-3 protocol: A → B: m, A A → B: g a , A B → A: n, sig B {m, n, A} B → A: g b , sig B {g a , g b , A} A → B: sig A {m, n, B} A → B: sig A {g a , g b , B} • Shared secret (with someone) • Shared secret: gab • Authenticated • Authenticated – A deduces: Received (B, msg1) Λ Sent (B, msg2) • Identity Protection • Identity Protection • DoS Protection • DoS Protection 4
Refinement Transformation � Encrypt signatures: � Use cookie: JFK core protocol A → B: g a , A A → B: g a , A B → A: g b , E K {sig B {g a , g b , A}} B → A: g b , hash KB {g b , g a } A → B: E K {sig A {g a , g b , B}} A → B: g a , g b , hash KB {g b , g a } E K {sig A {g a , g b , B}} • Shared secret: gab B → A: g b , E K {sig B {g a , g b , A}} • Authenticated • Shared secret: gab • Identity Protection • Authenticated • DoS Protection • Identity Protection • DoS Protection (Here B must store b in step 2, but we’ll fix this later…) Cookie transformation Cookie in JFK � Typical protocol � Protocol susceptible to DOS • Client sends request to server eh1 A → B: g a , A • Server sets up connection, responds B → A: g b , E K {sig B {g a , g b , A}} • Client may complete session or not (DOS) A → B: E K {sig A {g a , g b , B}} � Cookie version eh2 • Client sends request to server � Use cookie: JFK core protocol • Server sends hashed data back A → B: g a , A – Send message #2 later after client confirms B → A: g b , hash KB {g b , g a } • Client confirms by returning hashed data • Need extra step to send postponed message A → B: g a , g b , hash KB {g b , g a }, eh2 B → A: g b , eh1 Efficiency: Reuse D-H key Conclusion � Costly to compute g a , g b , g ab � Many protocol properties � Solution • Authentication Secrecy • Keep medium-term g a , g b (change ~10 min) • Prevent replay Forward secrecy • Replace g a by pair g a , nonce • Denial of service Identity protection � JFKi, JFKr protocols (except cert or grpinfo, …) � Systematic understanding is possible A → B: Na, g a , A • But be careful; easy to make mistakes B → A: Nb, g b , hash KB {Nb, Na, g b , g a } • State of the art A → B: Na, Nb, g a , g b , hash KB {Nb, Na, g b , g a }, – need to analyze complete protocol E K {sig A {Na, Nb, g a , g b , B}} B → A: g b , E K {sig B {Na, Nb, g a , g b , A}} – research will produce compositional methods Note: B does not need to store any short-term data in step 2 5
Recommend
More recommend
