1. Lecture 12 Overview

2. Key Management
public-key encryption helps address key distribution problems
have two aspects of this:
distribution of public keys
use of public-key encryption to distribute secret keys
One of the major roles of public-key encryption has been to address the problem of key distribution, with two distinct aspects: the distribution of public keys, and the use of public-key encryption to distribute secret keys.
CS 450/650 Lecture 12: Key Exchange

3. Distribution of Public Keys
can be considered as using one of:
public announcement
publicly available directory
public-key authority
public-key certificates
Several techniques have been proposed for the distribution of public keys, which can mostly be grouped into the categories shown.
CS 450/650 Lecture 12: Key Exchange

4. Public Announcement
users distribute public keys to recipients or broadcast to community at large
append PGP keys to messages or post to news groups or list
major weakness is forgery
anyone can create a key claiming to be someone else and broadcast it
until forgery is discovered attacker can masquerade as claimed user
The point of public-key encryption is that the public key is public, hence any participant can send his or her public key to any other participant, or broadcast the key to the community at large. Its major weakness is forgery, anyone can create a key claiming to be someone else and broadcast it, and until the forgery is discovered they can masquerade as the claimed user.
CS 450/650 Lecture 12: Key Exchange

5. Publicly Available Directory
can obtain greater security by registering keys with a public directory
directory must be trusted with 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
A greater degree of security can be achieved by maintaining a publicly available dynamic directory of public keys. Maintenance and distribution of the public directory would have to be the responsibility of some trusted entity or organization. This scheme is clearly more secure than individual public announcements but still has vulnerabilities to tampering or forgery.
CS 450/650 Lecture 12: Key Exchange

6. Public-Key Authority
improve security by tightening control over distribution of keys from directory
has properties of 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
Stronger security for public-key distribution can be achieved by providing tighter control over the distribution of public keys from the directory. It requires users to know the public key for the directory, and that they interact with directory in real-time to obtain any desired public key securely. Note that a total of seven messages are required, as shown next.
CS 450/650 Lecture 12: Key Exchange

7. Public-Key Authority
Stallings Figure 10.3 “Public-Key Authority” illustrates a typical protocol interaction. See text for details of steps in protocol.
CS 450/650 Lecture 12: Key Exchange

8. Public-Key Certificates
certificates allow key exchange without real-time access to public-key authority
a certificate binds identity to public key
usually with other info such as period of validity, rights of use
all contents signed by a trusted Public-Key or Certificate Authority (CA)
can be verified by anyone who knows the public-key authority’s public-key
An further improvement is to use certificates, which can be used to exchange keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a public-key authority. A certificate binds an identity to public key, with all contents signed by a trusted Public-Key or Certificate Authority (CA). This can be verified by anyone who knows the public-key authorities public-key.
One scheme has become universally accepted for formatting public-key certificates: the X.509 standard. X.509 certificates are used in most network security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME.
CS 450/650 Lecture 12: Key Exchange

9. Public-Key Certificates
Stallings Figure 10.4 “Public-Key Certificates” illustrates such a scheme. See text for details of steps in protocol.
CS 450/650 Lecture 12: Key Exchange

10. Distribution of Secret Keys
use previous methods to obtain public-key
can use for secrecy or authentication
public-key algorithms are slow
usually prefer to use private-key encryption to protect message contents
hence need a session key
have several alternatives for negotiating a suitable session
Once public keys have been distributed or have become accessible, secure communication that thwarts eavesdropping, tampering, or both, is possible. However, few users will wish to make exclusive use of public-key encryption for communication because of the relatively slow data rates that can be achieved. Accordingly, public-key encryption provides for the distribution of secret keys to be used for conventional encryption.
CS 450/650 Lecture 12: Key Exchange

11. Public-Key Distribution of Secret Keys
if have securely exchanged public-keys:
Stallings Figure 10.6 “Public-Key Distribution of Secret Keys” illustrates such an exchange. See text for details of steps in protocol. Note that these steps correspond to final 3 of Figure 10.3, hence can get both secret key exchange and authentication in a single protocol.
CS 450/650 Lecture 12: Key Exchange

12. Diffie-Hellman Key Exchange
public-key type scheme
proposed in 1976
note: now know that Williamson (UK CESG) secretly proposed the concept in 1970
A practical method for public exchange of a secret key
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 Williamson (UK CESG) - and subsequently declassified in 1987, see [ELLI99].
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

13. Diffie-Hellman Key Exchange
public-key distribution scheme
cannot be used to exchange an arbitrary message
rather it can establish a common key
known only to the two participants
based on exponentiation in a finite field
modulo a prime or a polynomial
security relies on the difficulty of computing discrete logarithms
The purpose of the algorithm is to enable two users to securely exchange a key that can then be used for subsequent encryption of messages. The algorithm itself is limited to the exchange of secret values, which depends on the value of the public/private keys of the participants. The Diffie-Hellman algorithm uses exponentiation in a finite (Galois) field (modulo a prime or a polynomial), and depends for its effectiveness on the difficulty of computing discrete logarithms.
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

14. Diffie-Hellman Setup all users agree on global parameters:
large prime integer or polynomial p
g = primitive root mod p
for every integer a that has gcd(a, p) = 1, there is an integer k such that gk ≡ a (mod p)
each user generates their key
chooses a secret key (number): a < p
compute their public key: A = ga mod p
In the Diffie-Hellman key exchange algorithm, there are two publicly known numbers: a prime number p and an integer g that is a primitive root of p. The prime p and primitive root g can be common to all using some instance of the D-H scheme. Note that the primitive root g is a number whose powers successively generate all the elements mod p. Users Alice and Bob choose random secrets a's, and then "protect" them using exponentiation to create their public A's. For an attacker monitoring the exchange of the A's to recover either of the a's, they'd need to solve the discrete logarithm problem, which is hard.
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

15. Diffie-Hellman Key Exchange
shared session key for users is KAB:
KAB = gab mod p
= Ab mod p (which B can compute)
= Ba mod p (which A can compute)
g can be small
2 or 5 is common
a, b, p should be large
attacker needs a or b to obtain the session key
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. Note that if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys.
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

16. Diffie-Hellman Example
users Alice & Bob who wish to swap keys
agree on prime p=353 and g=3
select random secret keys:
A chooses a=97, B chooses b=233
compute respective public keys:
A=397 mod 353 = 40 (Alice)
B=3233 mod 353 = 248 (Bob)
compute shared session key as:
KAB = Ba mod 353 = = 160 (Alice)
KAB = Ab mod 353 = = 160 (Bob)
Here is an example of Diffie-Hellman from the text.
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

17. Key Exchange Protocols
users could create random Diffie-Hellman keys each time they communicate
users could create a known Diffie-Hellman key and publish in a directory,
then consult and use to securely communicate with them
both of these are vulnerable to a man-in-the-middle attack
authentication of the keys is needed
Detail a couple of possible Key Exchange Protocols based on Diffie-Hellman. Note that these are vulnerable to a meet-in-the-Middle Attack, and that authentication of the keys is needed.
CS 450/650 Lecture 12: Diffie-Hellman Key Exchange

18. Lecture 13 Digital Certificates
CS 450/650
Fundamentals of
Integrated Computer Security
Slides are modified from Robin Burke

19. Trusting a Public Key We can't trust We might trust
the public key associated with a message
We might trust
an authoritative source to vouch for Alice
CS 450/650 Lecture 13: Digital Certificates

20. Digital Certificates
A digital certificate is a digital file that certifies the identity of
an individual
an institution
a server
a router seeking access to computer- based information
It is issued by a Certification Authority (CA)
CS 450/650 Lecture 13: Digital Certificates

21. Digital certificates wolfmail.unr.edu name public key X.509
CS 450/650 Lecture 13: Digital Certificates

22. Trusted third party Certification authority (CA) CA can CA will then
issue digital certificates and validate holders’ identity and authority
CA can
meet with Alice
look at her driver's license / birth certificate / etc
take her fingerprints
CA will then
sign her public key
CS 450/650 Lecture 13: Digital Certificates

23. Man-in-the-middle?
When Trudy tries to substitute her public key for Alice's
Bob will either notice that the key isn't certified or
notice that it is certified but not for Alice
CS 450/650 Lecture 13: Digital Certificates

24. Masquerading as CA? Trudy could falsely issue a certificate
sign the certificate pretending to be the CA
but
strong interest in making CA’s correct public key well known
Multiple sources to access the CA's public key
some public keys are actually bundled with the browser
CS 450/650 Lecture 13: Digital Certificates

25. Public key certificate
A public key
An identifier
Certificate by the CA
Embed public key along with other identifying information
cryptographically sign it as a tamper-proof seal
verifying the integrity of the data within the certificate
validating its use
CS 450/650 Lecture 13: Digital Certificates

26. Benefits of certification
Alice and Bob can exchange certificates directly
no need for a separate way to communicate public keys
certificate is self-protecting
Many users can participate
only need to know CA's public key
CS 450/650 Lecture 13: Digital Certificates

27. Uses of Digital Certificates
In a number of Internet applications that include:
Secure Socket Layer (SSL) developed by Netscape Communications Corporation
Secure Multipurpose Internet Mail Extensions (S/MIME) Standard for securing and electronic data interchange (EDI).
Secure Electronic Transactions (SET) protocol for securing electronic payments
Internet Protocol Secure Standard (IPSec) for authenticating networking devices
CS 450/650 Lecture 13: Digital Certificates

28. Issues Trust in the CA Security of the CA's private key
issuance policies
Security of the CA's private key
very important!!!
CS 450/650 Lecture 13: Digital Certificates

29. Multiple CAs If there is only one CA Multiple CAs
all is simple
Multiple CAs
Alice's public key is signed by C1
Bob's public key is signed by C2
How can Bob be confident?
maybe C1 is really Trudy in disguise
CS 450/650 Lecture 13: Digital Certificates

30. Solutions Full distribution Cross certification
every user has the public key for every CA
Impractical
Cross certification
Suppose Alice presents Bob with C1's public key
Signed by C2
Bob can verify the certificate C2
C1's public key can be trusted
Therefore Alice's public key can be trusted
CS 450/650 Lecture 13: Digital Certificates

31. Hierarchical trust model
Root CA
a generally-trusted CA
e.g. Federal Reserve Bank
all parties trust root
Non-root CAs
have certificates signed by root CA, or
signed by another non-root CA
closer to the root CA
Certification path
the chain of certifications from the root to a particular public key certificate
CS 450/650 Lecture 13: Digital Certificates

32. CA relationships Intra-organization communication The third party CA
Bank ATM network
Organization can be its own CA
The third party CA
CA is an independent entity
is like a notary public
is evaluating the truth of a person's representation
may be liable if due diligence is not performed
CS 450/650 Lecture 13: Digital Certificates

33. Validity Public key is not valid forever
limits risk associated with key compromise
1 year is typical
Certificates have a valid period
expired certificate may still be useful
non-repudiation
new certificate issued when old one expires
Possibly the same key re-certified
CS 450/650 Lecture 13: Digital Certificates

34. Certificate assumptions
During the valid period
public key is valid for use
association with identity assumed correct
revocation notifications will be published
CS 450/650 Lecture 13: Digital Certificates

35. Non-repudiation
Increasing legislation to allow digital signatures to serve as legally binding
Non-repudiation of digital signatures
Provides proof of the integrity and origin of data
both unforgeable, which can be verified by any third party at any time
An authentication that with high assurance
can be asserted to be genuine and
cannot subsequently be refuted
CS 450/650 Lecture 13: Digital Certificates

36. Revocation
What if Trudy hacks into Bob's computer and steals his private key?
Alice will still be sending encrypted messages, but now Trudy can read
Certificate must be revoked
can no longer be trusted
new certificate issued
how does Alice find this out?
CS 450/650 Lecture 13: Digital Certificates

37. Revoking a certificate
Reasons for revocation
Detected or suspected compromise
Change of data
e.g. subject name
Change of relationship between subject and CA
e.g. employee quitting a job from an organization which uses the current CA
CS 450/650 Lecture 13: Digital Certificates

38. Who can revoke? who revokes?
the subject
the CA
an authorized third party
e.g. the organization with an employee quitting
Authentication of the source of revocation request is needed
CS 450/650 Lecture 13: Digital Certificates

39. Certificate Revocation List
CRL is a time-stamped list of revoked certificates
digitally signed by the CA
available to all users
Each revoked cert is identified by a certificate serial number
CRL contains digital signatures, thus can be sent via unprotected channels
Users of public key certificates should check a suitably-recent CRL
CS 450/650 Lecture 13: Digital Certificates

40. Certificate Revocation List
The user of a public key
must check the CRL
every time the key is used
not enough to check when the certificate is originally accepted CA
must keep a revoked certificate in the CRL until it expires
list could get large
CS 450/650 Lecture 13: Digital Certificates

41. Example Trudy steals Bob's private key Bob discovers break-in
requests certificate revocation
Trudy sends a forged message to Alice
Alice verifies message
checks CRL
no problems with Bob's public key
CA publishes CRL with Bob's revocation
too late
CS 450/650 Lecture 13: Digital Certificates

42. CRL Distribution Pull method Push method
CA periodically updates CRL depository
users check when using a public key
Push method
broadcast new CRL when it changes
Both subject to denial of service attacks
CS 450/650 Lecture 13: Digital Certificates

43. CRLs Problems similar to blacklists with credit card companies
Database is periodically pruned, but still very large
Time delay between certificate being revoked and revocation being published in CRL
Widely-used CRLs have too many verifiers to be able to effectively use the “push” method
Susceptible to DOS attacks
Is the software default to accept or reject the certificate?
CS 450/650 Lecture 13: Digital Certificates

44. Online Certificate Status Protocol
Request / response protocol
Verifier receives up-to-the-minute status info
Alice checks Bob's public key directly with CA
most effective
most costly
Costs
handling traffic for every public key use
handling cryptographic operations at high spped
maintaining high security in Internet environment
Also subject to denial of service attack
CS 450/650 Lecture 13: Digital Certificates

45. Short-Lived Certificates
Certificate valid for 1 day at a time
re-requested each day
possibly the same public key
Revocation not necessary
Suitable for limited resource systems
e.g. mobile wireless systems
Assumes efficient certificate generation
CS 450/650 Lecture 13: Digital Certificates

46. Obtaining a certificate
Subscriber generates a public\private key pair Applies to CA for digital certificate with the public key.
CA verifies subscriber's identity and issues digital certificate containing the public key.  
CA publishes certificate to public, on-line repository.  
Subscriber signs message with private key and sends message to second party.  
Receiving party verifies digital signature with sender's public key and requests verification of sender's digital certificate from CA's public repository.  
Repository reports status of subscriber's certificate.
CS 450/650 Lecture 13: Digital Certificates

47. Obtaining a certificate
Digital signature (encrypt) K B +
Bob’s
public
key K B + CA
private
key - K CA
certificate for Bob’s public key, signed by CA
Bob’s
identifying information
CS 450/650 Lecture 13: Digital Certificates

48. CA's key management CA keys have many uses Short-use private keys But
signing (real-time validation)
historical validation
Short-use private keys
better security
But
a signed certificate can't have a valid period beyond the signer's certificate
CA will need multiple keys for different purposes
CS 450/650 Lecture 13: Digital Certificates

49. Certificate distribution
Alice sends Bob a two line signed
signature ≈ message size
certificate > message size
Alice's public key + CA's signature
certificate for each CA in certification path
Certification info could easily be 10x the message size
What if Bob already has Alice's public key?
CS 450/650 Lecture 13: Digital Certificates

50. Certificate + Signature
Inefficient
Not practical in network environment
Different users might need different certification paths
can't predict which certificates to include
CS 450/650 Lecture 13: Digital Certificates

51. Directory services General case for public key discovery
Online access to a directory
request a public key certificate for a given user
In this case
Alice sends only the signed message
Bob is responsible for getting Alice's certificate
CS 450/650 Lecture 13: Digital Certificates

52. Obtaining an Individual’s Public Key
When Alice wants Bob’s public key:
Alice gets Bob’s certificate (from Bob or elsewhere)
apply CA’s public key to Bob’s certificate, get Bob’s public key
digital
signature
(decrypt) K B +
Bob’s
public
key K B + CA
public
key K CA
CS 450/650 Lecture 13: Digital Certificates