Lecture 3: Cryptography Support Services: Key Management Anish Arora CSE5473 Introduction to Network Security

Outline Distribution via symmetric keys Distribution via public keys of public keys of session keys Group Key Management Physical delivery (1 & 2) is simplest - but only applicable when there is personal contact between recipient and key issuer. Is fine for link encryption where devices & keys occur in pairs, but does not scale as number of parties who wish to communicate grows. A third party is a trusted intermediary, whom all parties trust, to mediate the establishment of secure communications between them. Must trust intermediary not to abuse the knowledge of all session keys. As number of parties grow, some variant of 4 is only practical solution.

A. Key distribution assuming symmetric keys how to securely distribute this key is an issue often security failure is due to a break in key distribution scheme given parties A and B have various key distribution alternatives: A can select key and physically deliver to B third party can select & deliver key to A & B if A & B have communicated previously can use previous key to encrypt a new key if A & B have secure communications with a third party C, C can relay key between A & B Physical delivery (1 & 2) is simplest - but only applicable when there is personal contact between recipient and key issuer. Is fine for link encryption where devices & keys occur in pairs, but does not scale as number of parties who wish to communicate grows. A third party is a trusted intermediary, whom all parties trust, to mediate the establishment of secure communications between them. Must trust intermediary not to abuse the knowledge of all session keys. As number of parties grow, some variant of 4 is only practical solution.

A key distribution protocol Stallings Fig 7.9. Based on concept of having a “Key Distribution Center” (KDC) which shares a unique key with each party (user). See text for details of steps in distribution process. This is based on the Needham Shroeder protocol which has the flaw that the third message can be replayed by an adversary. Denning/Sacco fixed this by letting B propose a nonce that was forwarded by A to KDC and included in the authenticator from KDC to A.

Another protocol (for connection-oriented networks)

A decentralized key distribution protocol Assume a master key is known to principals j and k : j  k : request, n k  j : Smaster ‹ S , request , k , n+1 , m › j  k : S ‹m+1›

Merkle’s puzzles Each puzzle requires O(n) work Alice sends O(n) puzzles to Bob, puzzle=EP(“message”) Bob chooses one, and spends O(n) effort to break it and get key Bob communicates choice index (which was encrypted by Alice) to Alice Eve has to perform O(n2) work to guess the key

More on Merkle’s Puzzle Alice: for i=1, …, 232 choose random Pi ∈{0,1}32 ; xi,ki∈{0,1}128 set puzzlei ⟵ E096 ll Pi (“Puzzle # xi” ll ki) Send puzzle1 , … , puzzle232 to Bob Bob: choose a random puzzlej and solve it. Obtain (xj, kj ) . Send xj to Alice Alice: lookup puzzle with number xj, use kj as shared secret [Dan Boneh]

B. Public key management public-key encryption helps address key distribution problems two aspects: distribution of public keys use of public-key encryption to distribute secret keys

I. Distribution of public keys via one of: public announcement publicly available directory public-key authority public-key certificates

Public announcement users distribute public keys to recipients or broadcast to community at large e.g. append PGP keys to email messages or post to news groups or email list major weakness is forgery: anyone can create a key claiming to be someone else and broadcast it masquerade as claimed user until forgery is discovered

Publicly available directory users obtain greater security by registering keys with a public directory directory must be trusted, and with these properties: contains {name, public-key} entries participants register securely with directory participants can replace key at any time directory is periodically published directory can be accessed electronically still vulnerable to tampering or forgery, if channel or access to directory is vulnerable

Public-key authority improves security by tightening control over distribution of keys from directory has same properties as directory + requires users to know public key for the directory users interact with directory to obtain any desired public key securely requires real-time access to directory when keys are needed

Deriving a protocol for authority based distribution Consider the basic protocol: j  k : B.j k  j : B.k j  k : B.k ‹m› k  j : B.j ‹m’› Subject to man-in-the-middle attack

Man-in-the-middle attack Recall the attack j  k : B.j intercepted by Mal Mal  k : B.Mal k  j : B.k intercepted by Mal Mal  j : B.Mal j  k : B.Mal ‹m› “Mallory”-in-the-middle can now passively receive the messages sent by j to k and vice versa To foil attack: get Trent to sign & send public keys of one to other

Foiling the attack: use signatures One solution: get Trent to sign and send public keys of the one to the other T  k : R.T ‹ B.j › T  j : R.T ‹ B.k › But freshness of exchange remains an issue: how to tolerate replay attacks

Public-key authority Stallings Fig 10.3. See text for details of steps in protocol.

Public-key certificates certificates allow key exchange without real-time access to public-key authority users contact authority only on behalf of self as opposed to others a certificate binds identity to public key usually with other info such as period of validity with all contents signed by a trusted Public-Key or Certificate Authority (CA) certificates can be verified by anyone who knows the public-key authorities public-key

Public-key certificates Stallings Fig 10.4. See text for details of steps in protocol.

Light-weight public key certificates

CA structures One universally trusted authority issues: monopoly pricing, risk of all eggs in one basket, cost of getting certificate in first place could have local registration authorities (RAs) to simplify getting certificate initially could replace one with many (monopoly -> oligarchy; as in trusted roots of IE) but less secure, since one “weak” CA compromises all Top-down hierarchy, starting from universally trusted authority certificate chains, a CA certifies a public key to below to subordinate CA need to verify multiple certificates at user end but don’t have to go to original CA to get certificate in first place

Organizing CAs Many independent CAs: configure which ones to trust alternatively, assume name subordination: each CA only responsible for its name subspace more secure in practice bottom-up version (as opposed to building trust from the top-down): extend to traverse up and down intranet namespace hierarchy & across extranet namespaces security within organization (intranet) is controlled by organization easy configuration: start with own public key Many independent CAs: configure which ones to trust issue: anarchy doesn’t scale either X.509 is an IEEE standard for certificate syntax, PKIX is an extension to this standard, SPKI is a competing IETF standard

Revoking certificates If certificate compromised, notify CA and ask for a new certificate How to revoke certificate: Supplement certificate lifetimes with certificate revocation lists (CRLs) or a black list server (OLRS) These can be maintained on-line

II. Public-key distribution of secret keys use previous methods to obtain public-key then use public-key for secrecy or authentication is slow so use private-key encryption to protect message contents hence need a session key have several alternatives for negotiating a suitable session

Simple secret key distribution proposed by Merkle in 1979 j generates a new temporary public key pair j sends k the public key and its identity k generates a session key S & sends it to j encrypted using the supplied public key j decrypts the session key and both use the key j  k : B.j k  j : B.j ‹ S ›

Man-in-the-middle attack Here’s one attack: j  k : B.j intercepted by Mal Mal  j : B.j ‹S› Mal  k : B.Mal k  j : B.Mal ‹S’› intercepted by Mal j  k : S‹m› intercepted by Mal Mal  k : S’‹m› “Mallory”-in-the-middle can now actively receive the messages sent by j to k and vice versa

Foiling the attack: use signatures One solution: get Trent to sign and send public keys of the one to the other T  k : R.T ‹ B.j › T  j : R.T ‹ B.k › j  k : R.j ‹ S.jk ‹m›, B.k ‹S.jk› › But freshness of exchange remains an issue !

Foiling replay attacks: use nonce exchange To deal with freshness, assuming securely exchanged public-keys: Stallings Fig 10.6. See text for details of steps in protocol. Note that these steps correspond to final 3 of Fig 10.3, hence can get both secret key exchange and authentication in a single protocol.

Diffie-Hellman key exchange first public-key scheme proposed by Diffie & Hellman in 1976, along with exposition of public key concepts is a practical method for public exchange of a secret key as opposed to secure communication of messages used in a number of commercial products The idea of public key schemes, and the first practical scheme, which was for key distribution only, was published in 1977 by Diffie & Hellman. The concept had been previously described in a classified report in 1970 by James Ellis (UK CESG) - and subsequently declassified in 1987. See History of Non-secret Encryption (at CESG).

Diffie-Hellman key exchange shared session key for users A & B is KAB: KAB = αxA.xB mod q = yAxB mod q (which B can compute) = yBxA mod q (which A can compute) KAB is used as session key in private-key encryption scheme between Alice and Bob if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys attacker needs an x, must solve discrete log The actual key exchange for either party consists of raising the others "public key' to power of their private key. The resulting number (or as much of as is necessary) is used as the key for a block cipher or other private key scheme. For an attacker to obtain the same value they need at least one of the secret numbers, which means solving a discrete log, which is computationally infeasible given large enough numbers

Diffie-Hellman key exchange value of key depends on the participants (and their private and public key information) based on exponentiation in a finite (Galois) field (modulo a prime or a polynomial) – easy security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard i.e., given α, q, y = αx mod q computing x is hard discrete log computation takes more time than factoring a composite of magnitude of q

Diffie-Hellman setup all users agree on global parameters: large prime q α a primitive root mod q powers of α generate all numbers 1..q-1 each user (e.g. A) generates their key chooses a secret key (number): xA < q Computes its public key: yA = αxA mod q each user makes public that key yA The prime q and primitive root α can be common to all using some instance of the D-H scheme. Note that the primitive root α is a number whose powers successively generate all the elements mod q. Alice and Bob choose random secrets x's, and then "protect" them using exponentiation to create the y's. For an attacker monitoring the exchange of the y's to recover either of the x's, they'd need to solve the discrete logarithm problem, which is hard.

Diffie-Hellman example Users Alice & Bob who wish to swap keys: agree on prime q=353 and α=3 select random secret keys: A chooses xA=97, B chooses xB=233 compute public keys: yA=397 mod 353 = 40 (Alice) yB=3233 mod 353 = 248 (Bob) compute shared session key as: KAB= yBxA mod 353 = 24897 = 160 (Alice) KAB= yAxB mod 353 = 40233 = 160 (Bob)

Man-in-the-Middle attack for D-H Mallory intercepts exchange with Alice and sets up key with her, likewise sets up key with Bob traps all exchanges of data and faithfully forwards after decrypting with one key and then re-encrpyting with other key can now actively enable communications between Alice and Bob j  k : αxj mod q intercepted by Mal Mal  j : αxMal mod q Mal  k : αxMal mod q k  j : αxk mod q intercepted by Mal j  k : α xj xMal mod q ‹m› intercepted by Mal Mal  k : α xk xMal mod q ‹m›

Dealing with Man-in-the-Middle attack for D-H Avoided by sending messages not in the clear, but encrypted: with private keys with public keys and signed (in reverse order) by only one side But if private keys already exist, then why have D-H to begin with? “Forward secrecy”: if former private key compromised, latter keys not deducible

Denial-of-Service protection for D-H Mallory may send too many request for key exchanges to Bob To avoid this, add a preliminary message Bob first sends a cookie Alice’s response includes her public key and the cookie Bob verifies cookie before sending his public key in response

Key distribution systems issues hierarchies of KDC’s required for large networks, but must trust each other session key lifetimes should be limited for greater security use of automatic key distribution on behalf of users, but must trust system controlling purposes keys are used for

C. Group Key Management Distribution via symmetric keys Distribution via public keys of public keys of session keys Distribution via “group” key The key-tree approach The grid approach (for sensor networks) Physical delivery (1 & 2) is simplest - but only applicable when there is personal contact between recipient and key issuer. Is fine for link encryption where devices & keys occur in pairs, but does not scale as number of parties who wish to communicate grows. A third party is a trusted intermediary, whom all parties trust, to mediate the establishment of secure communications between them. Must trust intermediary not to abuse the knowledge of all session keys. As number of parties grow, some variant of 4 is only practical solution.

The Key Tree Approach (Wong, Gouda, Lam) Keys represented as nodes Group key is the root Auxiliary keys are internal nodes Individual keys are leaves Member u holds all keys in ancestor nodes Example: u1 holds keys k1 and kG A key tree is a data structure representing the set of keys held by each group member. Keys are represented as nodes in the tree. The group key is the root of the tree, auxiliary keys are internal nodes, and group members (with their individual keys) are the leaves. A member holds the keys in all ancestor nodes. So for example, member u1 holds keys k1 and kG. kG k1 u2 u1 u3 k2 u5 u4 u6 k3 u8 u7 u9

Scalability of Key Trees Reduces DELETE(u) communication costs from O(n) to O(log n) Example: DELETE(u9) Must change 2 shared keys: kG and k3 Keys are changed bottom up in the tree Change k3 with 2 messages: E(k’3,u7), E(k’3,u8) kG The hierarchical tree structure allows a reduction in the cost for removing a member from linear to log. As an example, consider removing member u9 from the group represented by this tree. This means we have to change KG and K3 since these are the keys that u9 shares with other members. The keys are changed bottom-up in the following fashion. We first change k3 by sending two messages to distribute the new key to members u7 and u8. k1 k2 k3 u1 u2 u3 u4 u5 u6 u7 u8 u9

Scalability of Key Trees Change kG with 3 messages: E(k’G,k1), E(k’G,k2), E(k’G,k’3) kG The resulting key tree is shown here, member u9 that is being removed now only holds the group key. We change the group key by distributing it to the remaining members using subgroup keys. k1 k2 k’3 u9 u1 u2 u3 u4 u5 u6 u7 u8

User-Oriented Rekeying Encryption Cost Join: 1 + 2 + … + h-1 + h-1 Leave: (d-1)(1+2+…+h-1) Rekey Messages Join: h Leave: (d-1)(h-1) Join rekey messages Leave rekey messages

Key-Oriented Rekeying u9 Encryption Cost Join: 2(h-1) Leave: d(h-1) Rekey Messages Leave: (d-1)(h-1) Join rekey messages Leave rekey messages

Group-Oriented Rekeying Two rekey messages for join: Encryption cost : 2(h-1) Leave Operation: Encryption cost: d(h-1) Rekey messages: 1

Grid Protocol (Kulkarni, Gouda, Arora) Arrange the secrets in a grid Each user is also assigned to some location in the grid Each user gets secrets in its row and in its column = user + secret

Grid Protocol (Continued) When two users in different rows and different columns communicate Consider the rectangle formed by those two users Choose secrets at the other two corners of the rectangle When users is same row (or column) communicate Maintain a secret that is shared between only those two users = user + secret = communicating users = secrets used