Get documents about "Introduction Ticket
Description
Introduction Ticket
Document Sample
Key Management
CS461/ECE422
1
Reading
• Chapter 10 in Computer Security: Art and
Science
• Handbook of Applied Cryptography
http://www.cacr.math.uwaterloo.ca/hac/
– Section 11.3.2 attack on RSA signature
– Section 13.8.3 Key Escrow
2
Key Management Motivation
• Cryptographic security depends on keys
– Size
– Generation
– Retrieval and Storage
• Example
– House security system no good if key or code is
under the mat
3
Overview
• Key Generation
• Key Exchange and management
– Classical (symmetric)
– Public/private
• Digital Signatures
• Key Storage
4
Key Management
Processes associated with
– Distribution of keys
– Binding identities to keys
– Generation, maintenance, and revoking keys
Notation
• X Y : { Z || W } kX,Y
– X sends Y the message produced by concatenating Z
and W encrypted by key kX,Y, which is shared by users X
and Y
• A T : { Z } kA || { W } kA,T
– A sends T a message consisting of the concatenation of
Z encrypted using kA, A’s key, and W encrypted using
kA,T, the key shared by A and T
• r1, r2 nonces (nonrepeating random numbers)
6
Session and Interchange Keys
• Long lived Interchange Keys only exist to boot strap
– Associated with a principal to the communication, e.g.
public keys Kb,Ka below
• Short lived session keys used for bulk encryption,
e.g. Ka,b
Ka,b Ka,b
Kb,Ka Ka,Kb
{Ka,b}Ka {m1}Ka,b
7
Session and Interchange Keys
• Another view---key and message in one shot
• Alice wants to send a message m to Bob
– Assume public key encryption
– Alice generates a random cryptographic key ks and uses
it to encrypt m
• To be used for this message only, not used for authentication
• Called a session key
– She encrypts ks with key kB
• kB encrypts all session keys Alice uses to communicate with
Bob : known by Bob, shared with Alice
• Called an interchange key. Used for authentication
– Alice sends { m } ks ||{ ks } kB
Message m coded with ks Message ks coded with kB
8
Benefits
• Limits amount of traffic encrypted with single key
– Standard practice, to decrease the amount of traffic an
attacker can obtain
• Prevents some attacks. e.g.,
– Suppose long lived key (public, or broken) kB
– Suppose set of possible messages is small, e.g. “BUY”
or “SELL”
– Attack can pre-compute possible ciphertexts, observe,
compare
– Example: Alice will send Bob message that is either
“BUY” or “SELL”. Eve computes possible ciphertexts
{ “BUY” } kB and { “SELL” } kB. Eve intercepts
encrypted message, compares, and gets plaintext at
9
once
Key Generation
• Goal: generate keys that are difficult to guess
• Problem statement: given a set of K potential keys,
choose one randomly
– Equivalent to selecting a random number between 0 and
K–1 inclusive
• Why is this hard: generating random numbers
– Actually, numbers are usually pseudo-random, that is,
generated by an algorithm
10
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
11
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
12
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 (mixes key and data), MD5,
SHA-1, (multi-stage functions in hashing)
avalanche effect
• Inputs need to be unpredictable
13
Key Exchange
Principals to communication need to agree on
key to be used. Criteria
– Key should not be transmitted in the clear
• Solutions : encrypt when sent, derive from public
keys (e.g. Diffie-Hellman)
• Assume attacker can view EVERYTHING that is
transmitted
– Permissible to use a trusted third party
– All protocols, mechanisms, algorithms should
be assumed known. The only secrets are the
keys involved
Separate Channel
• Ideally you have separate secure channel for
exchanging keys
– Direct secret sharing grows at N2
Telephone, separate data network, ESP, sneaker net
Regular data network
15
Shared Channel
• Generally separate channel is not practical
– No trustworthy separate channel
– Want to scale linearly with additional users
KA,KB, … KZ
KB
Key Exchange
Regular data network KA
16
Classical Key Exchange
• “Classical” means “no public key
infrastructure”
• Bootstrap problem: how do Alice, Bob
begin?
– Alice can’t send it to Bob in the clear!
• Assume trusted third party, Cathy
– Alice and Cathy share secret key kA
– Bob and Cathy share secret key kB
• Use this to exchange shared key ks
17
Simple Protocol
{ request for session key with Bob } kA
Alice Cathy
{ ks } kA || { ks } kB
Alice Cathy
{ ks } kB
Alice Bob
Notice : Cathy gives Alice the job of sending key to Bob
{ ks } kB
Eve Bob
Notice : Eve might break key, and entice Bob to use it with her or
might simply replay the communication Alice had with Bob using
that key 18
Problems
• How does Bob know he is talking to Alice?
– Replay attack: Eve records message from Alice
to Bob, later replays it; Bob may think he’s
talking to Alice, but he isn’t
• e.g. message is “buy 100 shares of GE stock”
– Session key reuse: Eve replays message from
Alice to Bob, so Bob re-uses session key
• If Eve has cracked session key off-line, she can say
anything she likes in the communication
• Protocols must provide authentication and
defense against replay
19
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
owners
• Simple protocol
– ks is desired session key
{ ks } eB
Alice Bob
42
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
{ { ks } dA } eB
Alice Bob
43
Notes
• Can include message enciphered with ks
• Assumes Bob has Alice’s public key, and vice
versa
– If not, each must get it from public server
– If keys not bound to identity of owner, attacker Eve can
launch a man-in-the-middle attack (next slide; Cathy is
public server providing public keys)
• Solution to this (binding identity to keys) discussed later as
public key infrastructure (PKI)
44
Man-in-the-Middle Attack
Alice Pls send Bob’s public key Eve intercepts request
Cathy
send Bob’s public key
Eve Cathy
eB
Eve Cathy
eE
Alice Eve
Alice believes that eE is Bob’s public key. It isn’t….
{ k s } eE
Eve intercepts message
Alice Bob
{ ks } eB 45
Eve Bob
Cryptographic Key Infrastructure
• Goal: bind identity to key
• Classical: not possible as all keys are shared
– Use protocols to agree on a shared key (see earlier)
• Public key: bind identity to public key
– Crucial as people will use key to communicate with
principal whose identity is bound to key
– Erroneous binding means no secrecy between principals
– Assume principal identified by an acceptable name
46
Certificates
• Create token (message) containing
– Identity of principal (here, Alice)
– Corresponding public key
– Timestamp (when issued)
– Other information (perhaps identity of signer)
– Compute hash (message digest) of token
Hash encrypted by trusted authority (here, Cathy)
using private key: called a “signature”
CA = eA || Alice || T || {h(eA || Alice || T )} dC
OBSERVE : public key, Alice and T are in the clear; hash is signed. Why?
47
Use
• Bob gets Alice’s certificate
– If he knows Cathy’s public key, he can validate the
certificate
• Decrypt encrypted hash using Cathy’s public key
• Re-compute hash from certificate and compare
• Check validity
• Is the principal Alice?
– Now Bob has Alice’s public key
• Problem: Bob needs Cathy’s public key to validate
certificate
– That is, secure distribution of public keys
– Solution: Public Key Infrastructure (PKI) using trust
anchors called Certificate Authorities (CAs) that issue
certificates
48
X.509 Certificates
• 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: encrypted hash
49
Transitive Trust
• If user U1 has a public-key certificate C issued by
certificate authority CA1, then CA1 trusts that the identity
on C is user U1’s
– Some validation used before C is issued
– U1 also trusts validity of other certs issued by CA1
• If CA1 has a certificate D issued by CA2, then CA2 trusts
that the identity on D is CA1’s, and that CA1 does due
diligence in checking identities on certs that CA1 issues…
– CA1 trusts other certs that CA2 issues to certificate authorities and
(possibly) users
50
Transitive Trust Illustrated
cert issued
Trusts CA3’s identity
and trustworthiness
of certs issued
CA2 CA3
Trusts certs
signed by CA2
Trusts CA1’s identity Trusts CA4’s identity
and trustworthiness and trustworthiness
Trusts certs Trusts certs of certs issued
of certs issued signed by CA2 signed by CA3
CA1 CA4
Trusts Bob’s
Trusts Alice’s identity
identity Trusts certs
Trusts certs signed by CA4
signed by CA1
Bob
Alice
Suppose Alice has every cert implied in this diagram
she trusts the key on Bob’s cert---
Why? She trusts CA2, and CA2 trusts Bob
PKI Trust Models
• A Single Global CA • Hierarchical CAs (Tree)
– Unmanageable, inflexible
– There is no universally Root CA
trusted organization
Level I CA … Level I CA
Level n CA
User
– Offloads burden on multiple CAs
– Need to verify a chain of
certificates
– Still depends on a single trusted
root CA 52
PKI Trust Models
• Hierarchical CAs with cross-certification
– Multiple root CAs that are cross-certified
– Cross-certification at lower levels for efficiency
• Web Model
– Browsers come pre-configured with multiple trust
anchor certificates
– New certificates can be added
• Distributed (e.g., PGP)
– No CA; instead, users certify each other to build a “web
of trust”
53
Validation and Cross-Certifying
• 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
• Certificates:
– Cathy<<Alice>> (Cathy issues cert for Alice)
– Dan<<Bob> (Dan issues cert for Bob)
– Cathy<<Dan>> (Cathy issues cert for Dan)
– Dan<<Cathy>> (Dan issues cert for Cathy) Cross-certification
54
Cross-Certification
Cert binds dest ID
to dest PK, signed by src
CA
Alice gets cert from Bob :
Cathy is there a common CA ancestor
CA CA in the directed CA graph?
Alice
CA CA
Dan
Cross-certification
Bob
–Alice gets Bob’s cert, signed by Dan
–Sees Dan’s cert is signed by Cathy
–Trusts Cathy as her own CA
–Alice uses (known) public key of Cathy to validate Dan’s cert
–Alice uses Dan’s public key (from cert) to validate Bob’s cert
PGP Chains
• OpenPGP certificates structured into packets
– One public key packet
– Zero or more signature packets
– See http://www.ietf.org/rfc/rfc4880.txt
• 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
56
OpenPGP Signature Packet
• Version 3 signature packet
– Version (3)
– Signature type (level of trust)
– Creation time
– Signer’s key identifier (identifies key to encrypt hash)
– Public key algorithm (used to encrypt hash)
– Hash algorithm
– Part of signed hash (used for quick check)
– Signature (encrypted hash)
• Version 4 packet more complex
57
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”
58
Validating Certificates
• Alice needs to validate Arrows show signatures
Bob’s OpenPGP cert Self signatures not shown
– Does not know Fred,
Giselle, or Ellen Jack
• Alice gets Giselle’s cert
– Knows Henry slightly, but Henry
Ellen
his signature is at “casual”
level of trust Irene
Giselle
• Alice gets Ellen’s cert
– Knows Jack, so uses his cert Fred
to validate Ellen’s, then hers
to validate Bob’s Bob
59
Key Revocation
• Certificates invalidated before expiration
– Usually due to compromised key
– May be due to change in circumstance (e.g., someone
leaving company)
• Problems
– Verify that entity revoking certificate authorized to do
so
– Revocation information circulates to everyone fast
enough
• Network delays, infrastructure problems may delay
information
60
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
– Revocation message placed in PGP packet and signed
– Flag marks it as revocation message
61
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 “non-repudiation”)
– Limited to technical proofs
• Inability to deny one’s cryptographic key was used to sign
– One could claim the cryptographic key was stolen or
compromised
• Legal proofs, etc., probably required; not dealt with here
62
Simple Approach
• Classical: Alice, Bob share key k
– Alice sends m || { m } k to Bob
This is a digital signature
WRONG
This is not a digital signature
– Why? Third party cannot determine whether
Alice or Bob generated message
63
Public Key Digital Signatures
• Alice’s keys are (private) dAlice, (public) eAlice
• Alice sends Bob
m || { m } dAlice
• In case of dispute, judge computes
{ { m } dAlice } eAlice
• and if it is m, Alice’s private key signed message
– She’s the only one who knows dAlice, so we infer Alice
did the signing action
64
RSA Digital Signatures
• Use private key to encrypt message
– Protocol for use is critical
• Key points:
– Never sign random documents, and when
signing, always sign hash and never document
• Mathematical properties can be turned against signer
– Sign message first, then encrypt
• Changing public keys causes forgery
65
Attack #1
Given Bob’s signatures on messages m1 and m2
Alice can compute his signature on message m m1 m2
so the attack is to create evil message m, find factors
(with appropriate modulus) and get Bob to sign them
• (m1 x m2 ) mod nb = m
• Get Bob to sign m1 and m2
• m1d mod nb x m2d mod nb =
(m1d x m2d ) mod nb =
(m1 x m2 )d mod nb
= md mod nb 66
Attack #1 example
• Example: Alice, Bob communicating
– nA = 95, eA = 59, dA = 11
– nB = 77, eB = 53, dB = 17
– note that ops using Alice’s key are mod nA,, using Bob’s are nB
• 26 contracts, numbered 00 to 25
– Alice has Bob sign 05 and 17:
• c = mdB mod nB = 0517 mod 77 = 3
• c = mdB mod nB = 1717 mod 77 = 19
– Alice computes 0517 mod 77 = 08; corresponding signature is
(08)17 mod 77 = (0319) mod 77 = 57;
– claims Bob signed 08
– Judge computes ceB mod nB = 5753 mod 77 = 08
• Signature validated; Bob is toast
67
Attack #2: Bob’s Revenge
• Bob, Alice agree to sign contract m but Bob wants
it to appear that she signed contract M
– Alice encrypts with Bob’s public key (e.g. for
confidentiality), then signs with her private key:
c = (meB mod nB)dA mod nA
• Bob now changes his public key
– Computes r such that Mr mod nB = m
– Replace public key with product reB and computes a new matching
private key d'B
• What exactly is the math problem to be solved?
• Bob claims contract was M. Judge computes:
– (ceA mod nA)d'B mod nB = M
68
Attack #2: Bob’s Revenge (cont’d)
• Document is c = (meB mod nB)dA mod nA
• Bob’s new key pair is (r eB, d’B)
– M and r satisfy Mr mod nB = m
• What happens if M is encoded using new public key?
– (M r eB mod nB) = (M r )eB mod nB
» = m mod nB
• Bob claims contract was M. Judge computes:
– (ceA mod nA)d'B mod nB = M
– Verify Alice signed
– Decode using new public key
– Busted
• Illustrates dangers of encrypt-then-sign
– Recipient can pull a fast one on you
69
Attack #2 Example
• Bob, Alice agree to sign contract 06
• Alice encrypts, 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 r eB mod (nB) = 5953 mod 60 = 7
– Replace public key eB with 7, private key dB = 43
• Bob claims contract was 13. Judge computes:
– (6359 mod 95)43 mod 77 = 13
– Verified; now Alice is toast
70
Digital Signature Algorithm (DSA)
Is a FIPS standard (186-3) proposed by NIST, 1991
See this link
http://www.itl.nist.gov/fipspubs/fip186.htm
Is a bit more technical than it is interesting
That has never stopped us before….
Three phases
– Key generation
– Signing
– Verification
DSA Key Generation
Algorithmic parameters
– Hash function h
– Key lengths (L, N) 186-3 specifies options
(1024,160), (2048,224), (2048,256), and (3072,256).
– Choose an N-bit prime q.
– Choose an L-bit prime modulus p such that p–1 is a
multiple of q.
– Choose g, with multiplicative order modulo p equal to q.
– (p, q, g) may be shared
Key generation---public and private keys
– Choose random x, with 0 < x < q.
– Calculate y = (g x ) mod p.
– Public key is (p, q, g, y). Private key is x.
DSA Signature
• Generate a random per-message value k where 0 < k < q
• Calculate r = ((g k) mod p) mod q
• Calculate s = (k’(H(m) + x*r)) mod q
– where k’ is the multiplicative inverse mod q of k
– Remember that x is private key
• Recalculate the signature in the unlikely case that r = 0 or s =
0
• The signature is (r, s)
DSA Verification
Given legal signature (r, s)
• Calculate w = (s’) mod q
• s’ multiplicative inverse mod q
• Calculate u1 = (h(m)*w) mod q
– m is message whose signature we’re checking
• Calculate u2 = (r*w) mod q
• Calculate v = ((gu1 * yu2) mod p) mod q
• The signature is valid if v = r
Storing Keys
• Multi-user or networked systems: attackers may
defeat access control mechanisms
– Encrypt file containing key
• Attacker can monitor keystrokes to decrypt files
• Key will be resident in memory that attacker may be able to
read
– Use physical devices like “smart card”
• Key never enters system
• Card can be stolen, so have 2 devices combine bits to make
single key
75
Key Escrow
• Key escrow system allows authorized third party to
recover key
– Useful when keys belong to roles, such as system
operator, rather than individuals
– Business: recovery of backup keys
– Law enforcement: recovery of keys that authorized
parties require access to
• Goal: provide this without weakening
cryptosystem
• Very controversial
76
Desirable Properties
• Escrow system should not depend on encryption
algorithm
• Privacy protection mechanisms must work from
end to end and be part of user interface
• Requirements must map to key exchange protocol
• System supporting key escrow must require all
parties to authenticate themselves
• If message to be observable for limited time, key
escrow system must ensure keys valid for that
period of time only
77
Beth, Knobloch, Otten, Simmons, Wichmann 94
Components
• User security component
– Does the encryption, decryption
– Supports the key escrow component
• Key escrow component
– Manages storage, use of data recovery keys
• Data recovery component
– Does key recovery
78
Example: ESS, Clipper Chip
• Escrow Encryption Standard
– FIPS 185 (http://www.itl.nist.gov/fipspubs/fip185.htm)
– Set of interlocking components
– Designed to balance need for law enforcement access to
enciphered traffic with citizens’ right to privacy
• Clipper chip given to user with prepared per-
message escrow information
– Each chip numbered uniquely by UID
– Special facility programs each chip
• Key Escrow Decrypt Processor (KEDP)
– Available to agencies authorized to read messages
79
User Security Component
• Unique device key kunique
• Non-unique family key kfamily
• Cipher is Skipjack
– Classical cipher: 80 bit key (ksession ), 64 bit input,
output blocks
• Attaches Law Enforcement Access Field (LEAF)
of 128 bits:
– { UID || { ksession } kunique || hash } kfamily
– hash: 16 bit authenticator from session key and
initialization vector
80
User Security Component
message Programmed at initialization
UID kunique
64 bits
80 bit session key
skipjack
ksession Based on session key and
Initialization vector
64 bits k family
Law Enforcement {UID|| ksession }kunique || hash}k family
Access Field
(32) (80) (16)
Field sizes (in bits)
ciphertext
Initialization of User Security Component
Seed1, Key1, Fam1 Secure Facility
Escrow
Agent I {ku1}kcomp •Creates ku1,ku2
•Combine Fam1, Fam2
to obtain kfamily UID, kunique,
•Combine Key1,Key2 kfamily User
to obtain kcomp “Clipper”
Seed2, Key2, Fam2 •Combine Seed1, Seed2 Chip
Escrow
{ku2}kcomp to generate sequence
Agent II kunique = ku1 ku2
Essential points
• Key that encrypts session key requires both ku1 and ku2
• k family depends on input from both Escrow agents
• Returned encoding of ku1,ku2 uses key derived from both
Escrow agents 82
Obtaining Access
• Alice obtains legal authorization to read message
• She runs message LEAF through KEDP
– LEAF is
{ UID || { ksession } kunique || hash } kfamily
• KEDP uses (known) kfamily to validate LEAF (think
hash(UID)), obtain sending device’s UID
• Authorization, LEAF taken to escrow agencies
– To get session key she needs to get kunique
83
Agencies’ Role
• Each validates authorization offered by Alice
• Each supplies { kui } kcomp and key number Keyi
• KEDP takes these and LEAF:
{ UID || { ksession } kunique || hash } kfamily
– Key numbers produce kcomp
– kcomp produces ku1 and ku2
– ku1 and ku2 produce kunique
– kunique and LEAF produce ksession
84
Problems
• Clipper would not decode messages with an invalid
hash
– So naturally the attack is to replace the real LEAF with
one that has a valid hash!
• hash too short
– LEAF 128 bits, 16-bit “checksum” (hash)
– 2112 LEAFs have a valid hash, e.g., would validate
• 1 has actual session key, UID
• Takes about 42 minutes to find a randomly generated LEAF with
a valid hash but meaningless session key and UID
– Turns out deployed devices would prevent this attack
– Scheme does not meet temporal requirement
• As kunique fixed for each unit, once message is read, any future
messages can be read
85
Yaksha Key Escrow
Main ideas:
– Session keys obtained from a Yaksha server
• Server escrows generated keys
– Only messages encoded with the session key
are recoverable
Key Points
• Key management critical to effective use of cryptosystems
– Different levels of keys (session vs. interchange)
• Exchange algorithms can be vulnerable to attacks
– Replay
– Identity integrity
• Digital signatures provide integrity of origin and content
Much easier with public key cryptosystems than with classical
cryptosystems
• Keys need infrastructure to identify holders, allow
revoking and possible escrow
88
