ISA 562 Information System Security

ISA 562 Information System Security Key Management Chapter 10 from Bishop’s Book

Overview • Session and Interchange Keys • Key Exchange • Key Generation • Key Infrastructure • Storing and Revoking Keys • Digital Signatures

Notation • {Z}k: message Z enciphered by key k • Z||W: concatenation of messages Z and W • kA,T : a (secret) key shared by A and T • kA: A’s (public or private) key • r1, r2 nonces (nonrepeating random numbers) • Example: • X  Y : { Z || W } kX,Y • A  T : { Z } kA || { W ||r1} kA,T

Session Key and Interchange Key • Always encrypt message with a one-time use key • Alice wants to send a message m to Bob • Alice generates a random cryptographic key ks and uses it to encipher m • ks is to be used for this message only • Called a session key • She enciphers ks with Bob’s public key kB • kB is used to encipher all session keys (that Alice uses to communicate with Bob) • Called an interchange key • Could also be a secret key shared by Alice and Bob • Alice sends {m}ks || {ks} kB

Why? • To limit the amount of traffic enciphered with the same key • Standard practice, to decrease the amount of ciphertext an attacker can obtain • Compared to encrypting all messages with interchange key • Prevents some attacks • Forward search attack • Question 8 of your midterm exam • Secret key cryptosystem not vulnerable to forward search attack • Establish a one-time use secret key via public-key cryptosystem

Key Exchange Protocols • Goal: Alice and Bob want to establish a shared key • Key cannot be sent in clear • Attacker can be listening • Alice and Bob trust some third party • Always true (who do you trust in a public-key cryptosystem?) • Protocols publicly known • Security by obscurity is a bad idea • Anything transmitted is assumed known to attacker

Classical Key Exchange • Bootstrap problem: how do Alice, Bob begin? • If you trust nobody at all, you can never establish trust • Assume both Alice and Bob trust Cathy • Alice and Cathy share secret key kA,C • Bob and Cathy share secret key kB,C • Use this to exchange shared key ks

Simple Protocol { request for session key to Bob } kA,C Alice Cathy 7:15 { ks } kA,C || { ks } kB,C Alice Cathy 7:20 Okay, Alice. This is your session key ks And tell Bob I got him a session key ks { ks } kB,C Alice Bob 7:25 Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk { message } ks Alice Bob 7:30 Hey, Bob, here’s the message

Replay Attack • Alice knows she is talking to Bob; Why? • But, Bob is now sure who he is talking to • Eve records the last message, and later replays it to Bob • Bob re-uses the session key (none keeps history of keys) • Eve then replays messages encrypted with that key { ks } kB,C 7:35 Eve Bob He must be Alice again Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk { message } ks 7:40 Eve Bob He must be Alice again Hey, Bob, here’s the message

Replay Attack (Cont’d) • Why is replaying (a valid) message a problem? • Think about this scenario • By SOD principle, Alice takes deposit and Bob credits the corresponding account • Alice sends Bob a message “Eve just deposited $50k” • Eve replays it… • Protocols must defense against such replay attack • Adds considerable complexity • Basic idea is “challenge-response” • Eve: “Hey, bob, this is Alice” • Bob: “Hmm, then you must have Alice’s key” • Bob: (Bob generates r1 ) “Now encrypt this!” • Eve: ……

{Alice || Bob || r1|| ks ||{ Alice || ks } kB,C}kA,C Alice Cathy this is your key ks Hey, Alice, this is Cathy And tell Bob I got him a session key ks { Alice || ks } kB,C Alice Bob Hey, Bob, this is Alice. Cathy wants me to forward you a session key ks with which we can talk { r2 } ks Alice Bob You’re Alice? So you must have ks. Prove it! { r2 – 1 } ks Alice Bob Here’s the proof that I have ks Needham-Schroeder Alice || Bob || r1 Alice Cathy Hey, Cathy, I need to talk to Bob.

{ Alice || ks } kB,C Alice Bob Alice’s Point of View • Second message • Encrypted with a key kA,C that only Alice and Cathy know, so only Cathy can create the message • Containing a challenge r1, so the message is not a replay • Third message • Encrypted with a key kB,Cthat only Bob and Cathy know, so only Bob can read it and extract the session key {Alice || Bob || r1|| ks ||{ Alice || ks } kB,C}kA,C Alice Cathy

{ Alice || ks } kB,C Alice Bob { r2 } ks Alice Bob { r2 – 1 } ks Alice Bob Bob’s Point of View • Third message • Encrypted with a key that only Bob and Cathy know, so the message can only be created by Cathy • The name Alice is in the message, so Cathy says the session key is to be used while talking to Alice • Fourth and fifth message • Determine if it is a replay from someone other than Alice

Denning-Sacco Modification • What if after some time, Eve obtains the session key ks? • More likely to be compromised than kA,C or kB,C • Eve replays the third message { Alice || ks } kB,C Eve Bob Hey, Bob, this is Alice (replay) { r2 } ks Eve Bob You’re Alice? So you must have ks. Prove it! { r2 – 1 } ks Eve Bob Here’s the proof that I have ks

Denning-Sacco Modification (Cont’d) • Solution: use time stamp T to detect replay • Weakness: clocks must be synchronized Alice || Bob || r1 Alice Cathy { Alice || Bob || r1 || ks || { Alice || T || ks } kB,C } kA,C Alice Cathy 7:35 { Alice || T || ks } kB,C Alice Bob 7:36 { r2 } ks Alice Bob { r2 – 1 } ks Alice Bob

Otway-Rees Protocol • Key-idea: always challenges • n is both a session identifier and a challenge • n in clear (e.g., in 4th msg) provides no security! Typo? n || Alice || Bob || { r1 || n || Alice || Bob } kA,C Alice Bob Alice challenges Bob via r1 n || Alice || Bob || { r1 || n || Alice || Bob } kA,C || { r2 || n || Alice || Bob } kB,C Cathy Bob Cathy verifies Bob’s response via n Bob challenges Cathy n|| { r1 || ks } kA,C || { r2 || ks } kB,C Cathy Bob Bob verifies Cathy’s response via r2 n|| { r1 || ks } kA,C Alice Bob Alice verifies Bob’s response via r1

Kerberos • Authentication system • Based on Needham-Schroeder with Denning-Sacco modification • Central server plays role of trusted third party (“Cathy”) • Ticket • Issuer vouches for identity of requester of service • Similar to Bob sending { r1 || ks } kA,C to Alice on behalf of Cathy • Authenticator • Identifies sender

Overview • Authentication - user u authenticates to Kerberos server • Obtains ticket Tu,TGS for ticket granting service (TGS) • Only at time of logon • Request for service - user u wants to use service s • User sends authenticator Au, ticket Tu,TGS to TGS server • TGS server sends user a ticket Tu,s to use service • User sends Au, Tu,s to service provider • Service provider grants services

Ticket and Authenticator • Example ticket issued to user u for service s Tu,s = s || { u || u’s address || valid time || ku,s } ks • A voucher issued for user u to be authenticated by server s, with a session key ku,s • Example authenticator user u generates for service s Au,s = { u || generation time } ku,s • An authentication request to be sent by user u to server s

Protocol user || TGS user Cathy { ku,TGS } ku || Tu,TGS user Cathy service || Au,TGS || Tu,TGS user TGS user || { ku,s } ku,TGS || Tu,s user TGS Au,s || Tu,s user service

Public Key Key Exchange • Here interchange keys known • eA, eB Alice and Bob’s public keys known to all • dA, dB Alice and Bob’s private keys known only to owner • Simple protocol • ks is desired session key • Answer to midterm question 8(d) { ks } eB Alice Bob

Problem and Solution • Vulnerable to forgery or replay • Because eB known to anyone, Bob has no assurance that Alice sent message • Simple fix uses Alice’s private key • ks is desired session key • One of you’s answer to midterm 8(d) – although we consider only the forward search attack • What if the public key is forged? { { ks } dA } eB Alice Bob

Man-in-the-Middle Attack Eve intercepts request send Bob’s public key Alice Cathy send Bob’s public key Cathy Eve eB Cathy Eve eE Eve Alice { ks } eE Eve intercepts message Bob Alice { ks } eB Bob Eve To solve this, key must be bound to identity – key infrastructure

Key Generation • Goal: generate keys that are difficult to guess • Problem statement: given a set of K potential keys, choose one randomly • Equivalent to generating a random number between 0 and K–1 inclusive

What is “Random”? • Sequence of cryptographically random numbers: a sequence of numbers n1, n2, … such that for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known • Best: physical source of randomness • Random pulses • Electromagnetic phenomena • Characteristics of computing environment such as disk latency • Ambient background noise

What is “Pseudorandom”? • Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm • Very difficult to do this well • Linear congruential generators [nk = (ank–1 + b) mod n] broken • Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0) mod n] broken too • Here, “broken” means next number in sequence can be determined

Best Pseudorandom Numbers • Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits • Examples: DES, MD5, SHA-1 • Use on UNIX-based systems: (date; ps gaux) | md5 where “ps gaux” lists all information about all processes on system

Key Infrastructure • Goal: bind identity to public key • To thwart the man-in-the-middle attack • To provide a reliable channel Plain- text Plain- text Ciphertext Encryption Algorithm Decryption Algorithm INSECURE CHANNEL A B B's Public Key B's Private Key RELIABLE CHANNEL B's Public Key

Certificates • A token (message) containing • Identity of principal (e.g., Alice) • His/her public key • Timestamp (when issued) • Other information (perhaps identity of issuer) signed by trusted authority (here, Cathy) CA = { eA || Alice || T } dC

The Role of Trust • Bob gets Alice’s certificate • If he knows (and trusts) Cathy’s public key, he can decipher the certificate • When was certificate issued? • Is the principal Alice? • Now Bob has Alice’s public key • Problem: Bob needs (to trust) Cathy’s public key to validate certificate • Problem pushed “up” a level • Two approaches: Merkle’s tree, signature chains

Merkle’s Tree Scheme • Keep certificates in a file • Define hashes recursively • h is hash function • Ci is certificate i • Signature on h(1,4) known to all • Changing any Ci changes the signature h(1,4) h(1,2) h(3,4) h(1,1) h(2,2) h(3,3) h(4,4) C1C2C3C4 h(1,4)=h(1,2)h(3,4)

Validation • The signature can be verified with any Ci • To validate C1: • Compute h(1, 1) • Obtain h(2, 2) • Compute h(1, 2) • Obtain h(3, 4) • Compute h(1,4), signature • Compare to known signature • Only need to know hashes of child nodes on path h(1,4) h(1,2) h(3,4) h(1,1) h(2,2) h(3,3) h(4,4) C1C2C3C4

Problem • Changing any certificate changes the signature • Not practical in most circumstances • Too many certificates and users • Users and certificates distributed over widely separated systems

X.509 Certificate Chains • Some certificate components in X.509v3: • Version • Serial number • Signature algorithm identifier: hash algorithm • Issuer’s name; uniquely identifies issuer • Interval of validity • Subject’s name; uniquely identifies subject • Subject’s public key • Signature: enciphered hash

X.509 Certificate Validation • Obtain issuer’s public key • Decipher signature • Gives hash of certificate • Recompute hash from certificate and compare • If they differ, there’s a problem • Check interval of validity • This confirms that certificate is current

Issuers • Certification Authority (CA): entity that issues certificates • Multiple issuers pose validation problem • Alice’s CA is Cathy; Bob’s CA is Dan; how can Alice validate Bob’s certificate? • Have Cathy and Dan cross-certify • Each issues certificate for the other • Why does Alice trust Cathy? • Root CA built-in (e.g., IE)

Validation and Cross-Certifying • Certificates: • Cathy<<Alice>> • Cathy<<Dan>> • Dan<<Bob> • (Dan<<Cathy>>) • Alice validates Bob’s certificate • Alice obtains Cathy<<Dan>> • Alice uses (known) public key of Cathy to validate Cathy<<Dan>> • Alice uses Cathy<<Dan>> to validate Dan<<Bob>>

PGP Chains • OpenPGP certificates structured into packets • One public key packet • Zero or more signature packets • Public key packet: • Version (3 or 4; 3 compatible with all versions of PGP, 4 not compatible with older versions of PGP) • Creation time • Validity period (not present in version 3) • Public key algorithm, associated parameters • Public key

Signing • Single certificate may have multiple signatures • Notion of “trust” embedded in each signature • Range from “untrusted” to “ultimate trust” • Signer defines meaning of trust level (no standards!) • All version 4 keys signed by subject • Called “self-signing”

Validating Certificates • Alice needs to validate Bob’s OpenPGP cert • Does not know Fred, Giselle, or Ellen • Alice gets Giselle’s cert • Knows Henry slightly, but his signature is at “casual” level of trust • Alice gets Ellen’s cert • Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s Arrows show signatures Self signatures not shown Jack Henry Ellen Irene Giselle Fred Bob Are you sure this will work in real world?

Storing Keys • Depending on OS security? • In multi-user or networked systems attackers may defeat OS access control mechanisms • Encrypt files containing keys • Malware can monitor keystrokes to capture keys • Use physical devices like “smart card” • Smart card does encryption/decryption • Keys never enter system • Card can be stolen – combined with password

Key Escrow • Encryption Dilemma • Public’s need for secure communication • Government’s need for lawful access to information • Key escrow system allows authorized third party to recover key (from ciphertext) • Business: recovery of backup keys • Law enforcement: recovery of keys that authorized parties require access to • Goal: provide key escrow without weakening cryptosystem • Very controversial

Clipper Chip • In 1993, Clinton administration proposed the clipper chip key escrow initiative • Objectives • Make strong encryption technology widely available • Built-in decryption capability for law enforcement agencies • Clipper chip has the essential key escrow property — It ensures that the key needed to decrypt the data is bound to the ciphertext • Key-recovery requires cooperation of one or more trusted party

Clipper Chip (Cont’d) • Encryption requires clipper chip • Clipper chip is temper proof and uses a secret-key encryption algorithm, called Skipjack • Skipjack was designed by NSA and is classified until 1998 • It uses 80 bit keys (24 bits longer than DES)

Key Escrow in Clipper Chip • Each clipper chip has a unique K and a unique 32-bit ID • For each key K, two numbers K1 and K2 are determined as follows • K1 is an 80 bit random number • K2 = K  K1 • K1 and K2 (with the unique chip ID) are given to independent federal agencies • In the initial proposal, National Institute of Standards and Technology (NIST) and Dept of Treasury were to be the escrow agents

Key Recovery in Clipper Chip • Bob talks to Alice via clipper chip-equipped devices • The devices generate a session key and send to clipper chip, which uses the key to encrypt/decrypt • Before encrypting, the chip transmits a string of bits called the law enforcement access field (LEAF) • LEAF is computed as follows • Session key is first encrypted using the chip-unique K • Result together with the chip ID are then encrypted using a family key F common to all chips • Note that access to F allows recovery of the chip ID, but not the session key since it is encrypted using the chip-unique key

ISA 562 Information System Security