1
ISA 562 Information System Security
Key ManagementChapter 10 from Bishop’s Book
2
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
3
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
4
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
5
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
6
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
7
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
8
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
9
Simple ProtocolAlice Cathy
{ request for session key to Bob } kA,C
Alice Cathy{ ks } kA,C || { ks } kB,C
Alice Bob{ ks } kB,C
Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk
Okay, Alice. This is your session key ks
And tell Bob I got him a session key ks
7:25
7:20
7:15
Alice Bob{ message } ks
Hey, Bob, here’s the message
7:30
10
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
Eve Bob{ message } ks
Eve Bob{ ks } kB,C7:35
7:40Hey, Bob, here’s the message He must
be Alice again
Hey, Bob, Cathy wants me to forward you a session key ks with which we can talk
He must be Alice again
11
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: ……
12
Needham-SchroederAlice Cathy
Alice || Bob || r1
Hey, Cathy, I need to talk to Bob.
Alice Bob{ Alice || ks } kB,C
Hey, Bob, this is Alice. Cathy wants me to forward you a session key ks with which we can talk
Alice Bob{ r2 } ks
You’re Alice? So you must have ks. Prove it!
Alice Cathy{ Alice || Bob || r1|| ks ||{ Alice || ks } kB,C } kA,C
Hey, Alice, this is Cathy
And tell Bob I got him a session key ks
this is your key ks
Alice Bob{ r2 – 1 } ks
Here’s the proof that I have ks
13
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,C that only Bob and Cathy
know, so only Bob can read it and extract the session key
Alice Bob{ Alice || ks } kB,C
Alice Cathy{ Alice || Bob || r1|| ks ||{ Alice || ks } kB,C } kA,C
14
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
Alice Bob{ Alice || ks } kB,C
Alice Bob{ r2 } ks
Alice Bob{ r2 – 1 } ks
15
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
Eve Bob{ Alice || ks } kB,C
Eve Bob{ r2 } ks
Eve Bob{ r2 – 1 } ks
Hey, Bob, this is Alice (replay)
You’re Alice? So you must have ks. Prove it!
Here’s the proof that I have ks
16
Denning-Sacco Modification (Cont’d)
Solution: use time stamp T to detect replay Weakness: clocks must be synchronized
Alice CathyAlice || Bob || r1
Alice Cathy{ Alice || Bob || r1 || ks || { Alice || T || ks } kB,C } kA,C
Alice Bob{ Alice || T || ks } kB,C
Alice Bob{ r2 } ks
Alice Bob{ r2 – 1 } ks
7:35
7:36
17
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?
Alice Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA,C
Cathy Bobn || Alice || Bob || { r1 || n || Alice || Bob } kA,C ||
{ r2 || n || Alice || Bob } kB,C
Cathy Bobn || { r1 || ks } kA,C || { r2 || ks } kB,C
Alice Bobn || { r1 || ks } kA,C
Alice challenges Bob via r1
Cathy verifies Bob’s response via n
Bob verifies Cathy’s response via r2
Alice verifies Bob’s response via r1
Bob challenges Cathy
18
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
19
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
20
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
21
Protocol
user Cathyuser || TGS
user Cathy{ ku,TGS } ku || Tu,TGS
user TGSservice || Au,TGS || Tu,TGS
user TGSuser || { ku,s } ku,TGS || Tu,s
user serviceAu,s || Tu,s
22
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)
Alice Bob{ ks } eB
23
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?
Alice Bob{ { ks } dA } eB
24
Man-in-the-Middle AttackAlice Cathysend Bob’s public key
Eve Cathysend Bob’s public key
Eve CathyeB
AliceeE Eve
Alice Bob{ ks } eE
Eve Bob{ ks } eB
Eve intercepts request
Eve intercepts message
To solve this, key must be bound to identity – key infrastructure
25
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
26
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
27
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
28
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
29
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
30
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
31
Key Infrastructure Goal: bind identity to public key
To thwart the man-in-the-middle attack To provide a reliable channel
B's Public Key B's Private KeyRELIABLE CHANNEL
EncryptionAlgorithm
DecryptionAlgorithm
Plain-text
Plain-textCiphertext
INSECURE CHANNEL
A B
B's Public Key
32
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
33
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
34
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)
C1 C2 C3 C4
h(1,4)=h(1,2)h(3,4)
35
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)
C1 C2 C3 C4
36
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
37
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
38
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
39
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)
40
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>>
41
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
42
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”
43
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 Bob
Fred
Giselle
EllenIrene
Henry
Jack
Arrows show signaturesSelf signatures not shown
Are you sure this will work in real world?
44
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
45
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
46
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
47
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
48
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)
49
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
50
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
51
Key Revocation Certificates invalidated before expiration
Usually due to compromised key May be due to change in circumstance (e.g.,
someone leaving company) Problems
Need to ensure the entity revoking certificate is authorized to do so
Revocation information circulates to everyone fast enough
Network delays, infrastructure problems may delay information
52
CRLs Certificate revocation list lists certificates
that are revoked X.509: only certificate issuer can revoke
certificate Added to CRL
PGP: signers can revoke signatures; owners can revoke certificates, or allow others to do so
53
Overview Session and Interchange Keys Key Exchange Key Generation Key Infrastructure Storing and Revoking Keys Digital Signatures
54
Digital Signature Construct that authenticated origin, contents
of message in a manner provable to a disinterested third party (“judge”)
Sender cannot deny having sent message (service is “nonrepudiation”) Limited to technical proofs
Legal proofs, etc., probably required; not dealt with here
55
Common Error Classical: Alice, Bob share key k
Alice sends m || { m }kA,B to Bob This is not a digital signature, because a
third party cannot determine whether Alice or Bob generated message
56
Public Key Digital Signatures Alice’s keys are dAlice, eAlice
Alice sends Bobm || { m } dAlice
In case of dispute, judge computes{ { m } dAlice } eAlice
and if it is m, Alice signed message She’s the only one who knows dAlice!
57
RSA Digital Signatures Need to be careful
Never sign documents directly, but sign its hash Mathematical properties can be turned against signer
Sign then encrypt instead of the other way around
Changing public keys causes forgery
58
Attack #1 Example: Alice, Bob communicating
Alice: nA = 95, eA = 59, dA = 11 Bob: nB = 77, eB = 53, dB = 17
26 contracts, numbered 00 to 25 Alice has Bob sign 05 (overtime) and 17 (more
overtime) c = mdB mod nB = 0517 mod 77 = 3 c = mdB mod nB = 1717 mod 77 = 19
Alice computes 0517 mod 77 = 08 (raising salary) corresponding signature is 0319 mod 77 = 57; claims Bob signed 08 (raising salary)
Judge computes ceB mod nB = 5753 mod 77 = 08 Signature validated; Bob is toast
59
Attack #2: Bob’s Revenge Bob, Alice agree to sign contract 06 (OT +
raising salary) Alice enciphers, then signs:
(meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63 Bob now changes his public key
Computes r such that 13r mod 77 = 6; say, r = 59 Computes reB mod (nB) = 5953 mod 60 = 7 Replace public key eB with 7, private key dB = 43
Bob claims contract was 13 (OT + half salary). Judge computes: (6359 mod 95)43 mod 77 = 13 Verified; now Alice is toast
60
El Gamal Digital Signature Relies on discrete log problem Choose p prime, g, d < p; compute y = gd mod p Public key: (y, g, p); private key: d To sign contract m:
Choose k relatively prime to p–1, and not yet used Compute a = gk mod p Find b such that m = (da + kb) mod p–1 Signature is (a, b)
To validate, check that yaab mod p = gm mod p
61
Example Alice chooses p = 29, g = 3, d = 6
y = 36 mod 29 = 4 Alice wants to send Bob signed contract 23
Chooses k = 5 (relatively prime to 28) This gives a = gk mod p = 35 mod 29 = 11 Then solving 23 = (611 + 5b) mod 28 gives b =
25 Alice sends message 23 and signature (11, 25)
Bob verifies signature: gm mod p = 323 mod 29 = 8 and yaab mod p = 4111125 mod 29 = 8 They match, so Alice signed
62
Key Points Key management critical to effective use of
cryptosystems Keys need infrastructure to bind holders,
allow revoking Key escrowing complicates infrastructure
Digital signatures provide integrity of origin and content