EE 418 Network Security and Cryptography
Lecture #17
December 1, 2016
Key Distribution and Management. Public Key Infrastructure
Lecture notes prepared by Professor Radha Poovendran.
Tamara Bonaci
Department of Electrical Engineering
University of Washington, Seattle
Outline:
1.
2.
3.
4.
5.
6.
1
Review: Introduction to digital signatures
Review: The digital signature algorithm
Review: Introduction to key distribution and management
Needham-Schroeder protocol
Kerberos
Public key infrastructure (PKI)
Review: Digital Signatures
Last week, we started our conversation about digital signatures, which we defined as a public-key mechanism
for providing message integrity and authentication. We saw that, like public-key cryptosystems, a digital
signature scheme requires two keys, a private (signing) key and a public (verifying) key. We also showed that
every digital signature scheme includes some basic steps, as depicted in Figure 1:
1. A user Alice generates a public key P KA and a private key SKA . Alice publishes the public key, while
keeping the private key a secret.
2. A user Bob downloads P KA (later we will discuss methods for Bob to verify that the public key was
generated by Alice, instead of a different user impersonating Alice).
3. Alice signs a message m using the private key SKA and a signing function sigSKA (m). Alice appends
the σ = sigSKA (m) to message m and transmits it to Bob.
4. Bob receives the message and signature (m, σ). Bob computes a verification function verP KA (m, σ) using
Alice’s public key. If verP KA (m, σ) returns true, Bob accepts the message; otherwise, Bob concludes that
the message has been modified and discards it.
Alice
m
sigK(.)
Bob
𝜎𝜎 =sigK(m)
[m, 𝜎𝜎 ]
verK(.)
True, accept
False, reject
K
Fig. 1. Providing message integrity using digital signatures.
2
Review: The Digital Signature Algorithm
The Digital Signature Algorithm (DSA) is a variant of the ElGamal and Schnorr signature schemes. It was
developed by NIST and adopted as a standard in FIPS 186. DSA is covered by U.S. Patent 5,231,668, but
has been made available royalty-free around the world. DSA is illustrated in Figure 2. The DSA consists of
Key Generation, Signature Generation, and Signature Verification algorithms.
1
2.1
DSA Key Generation
Alice generates the public and private keys for DSA through the following procedure:
1. Generate a prime number p. The current standard is for p to consist of at least 1024 bits (2048 and 3072
bit primes are required for some applications).
2. Pick a prime q with q|(p − 1). Prime q should be of length at least 160 bits (256 and 320 bit primes are
required for some applications). Let α be an integer with 1 ≤ α ≤ (p − 1) satisfying αq = 1 mod p.
3. Generate an integer a with 0 ≤ a ≤ (q − 1), and set β = αa mod p.
4. The public key is given by P KA = (p, q, α, β), while the private key is given by SKA = a. Alice publishes
the public key P KA and keeps the private key SKA a secret.
2.2
DSA Signature Generation
In what follows, h is a publicly known hash function; NIST has specified that SHA-2 or SHA-3 should be
used for h Alice signs a message m using DSA through the following procedure.
1. Generate a random number K with 1 ≤ k ≤ (q − 1).
2. Compute γ and δ as
γ = (αk mod p) mod q
δ = (h(m) + aγ)k −1 mod q
3. If γ = 0 or δ = 0, return to Step 1. Else the signature is given by (γ, δ).
2.3
DSA Signature Verification
A user Bob verifies that a signature (γ, δ) for message m was generated by Alice through the following
procedure:
1. Compute e1 and e2 as
e1 = h(m)δ −1 mod q
e2 = γδ −1 mod q
?
2. Bob checks (αe1 β e2 mod p) mod q = γ. If so, Bob accepts the message. Otherwise, Bob rejects the
message.
A proof of correctness for the DSA verification is given below.
2.4
Proof of DSA Verification
Assume that the computation of δ in the ElGamal scheme is changed from a “-” to a “+.”
δ = (m + aγ)k −1
(mod p − 1).
The verification condition in this case changes to:
αm β γ ≡ γ δ
(mod p).
(1)
Note in this equation that α has an order q (since αq ≡ 1 (mod p)) and β, γ are also of order q since they
are powers of α. Hence we can reduce all exponents in (1) by modulo q and the congruence will still hold.
So first δ is brought down to Zq
δ = (m + aγ)k −1 (mod q).
Similarly for γ
γ 0 = γ mod q = (αk mod p) mod q.
2
By replacing γ with γ 0 in the expression of δ the congruence remains unchanged (since δ is now considered
mod q). Hence one can write:
δ = (m + aγ 0 )k −1 mod q
The verification equation now becomes
0
αm β γ ≡ γ δ mod p
We raise both sides to the power of δ −1 mod q and obtain:
αmδ
−1
βγ
0 −1
δ
≡ γ mod p
Now we reduce both sides modulo q
(αmδ
−1
βγ
0 −1
δ
mod p) mod q ≡ γ mod q = γ 0
This yields the final verification in the DSA scheme.
Alice
Bob
Knows 𝑝𝑝, 𝑞𝑞, 𝛼𝛼, 𝛽𝛽
Chooses k in {1…q-1}
where 𝛽𝛽 = 𝛼𝛼 𝑎𝑎 mod 𝑝𝑝 and 𝑞𝑞|(𝑝𝑝 − 1)
Computes
𝛾𝛾 = (𝛼𝛼 𝑘𝑘 mod 𝑝𝑝) mod 𝑞𝑞
𝛿𝛿 = (𝑆𝑆𝑆𝑆𝑆𝑆 − 1(𝑚𝑚) + 𝑎𝑎𝑎𝑎)𝑘𝑘 −1 mod 𝑞𝑞
if 𝛾𝛾 = 0, or 𝛿𝛿 = 0
𝑚𝑚, (𝛾𝛾, 𝛿𝛿)
Computes
𝑒𝑒1 = 𝑆𝑆𝑆𝑆𝑆𝑆 − 1(𝑚𝑚)𝛿𝛿 −1 mod 𝑞𝑞
𝑒𝑒2 = 𝛾𝛾𝛿𝛿 −1 mod 𝑞𝑞
Checks if (𝛼𝛼 𝑒𝑒1 𝛽𝛽 𝑒𝑒2 mod 𝑝𝑝) mod 𝑞𝑞 = 𝛾𝛾
If yes, accept, else, reject.
Fig. 2. The Digital Signature Algorithm (DSA).
3
Review: Introduction to Key Distribution and Management
Last lecture, we started our conversation about key distribution and management. We considered two main
problems that we need to address in order to ensure CIA security goals:
1. If Alice and Bob rely on symmetric-key cryptography, they have to share the same secret encryptiondecryption key. How to they established that shared secret key over an insecure communication channel?
2. On the other hand, if Alice and Bob rely on public key cryptography, then how do they know that the
public key that they obtain somewhere online indeed belongs to the person they are wanting to talk to?
Last time, we focused on the first problem, related to symmetric-key cryptography, and we showed that there
are two possible approaches that Alice and Bob can take:
(a) Alice and Bob can use public key cryptography to establish a shared secret key that they can then use to
communicate securely using symmetric-key cryptography. (Diffie-Hellman protocol)
(b) Alice and Bob can rely a trusted third party, known as a key distribution center (KDC), to help them
establish a shared secret key. (Needham-Schroeder protocol)
3
4
Needham-Schroeder Protocol
The Needham-Schroeder (N-S) protocol was developed by Roger Needham and Michael Schroeder in 1978,
as a mechanism for Alice and Bob to agree on a shared key using a KDC. The steps in N-S are illustrated
in Figure 3 and described as follows:
KDC
Generates 𝐾𝐾𝐴𝐴𝐴𝐴
Computes
𝑡𝑡𝐵𝐵𝑜𝑜𝑜𝑜 = 𝑒𝑒𝐾𝐾𝐵𝐵 (𝐾𝐾𝐴𝐴𝐴𝐴 ||𝐼𝐼𝐷𝐷𝐴𝐴 �
Alice
𝐼𝐼𝐷𝐷𝐴𝐴 ||𝐼𝐼𝐷𝐷𝐵𝐵 ||𝑟𝑟𝐴𝐴
𝑒𝑒𝐾𝐾𝐴𝐴 (𝑟𝑟𝐴𝐴 𝐼𝐼𝐷𝐷𝐵𝐵 𝐾𝐾𝐴𝐴𝐴𝐴||𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 �
Bob
Chooses rA
Extracts KAB ,
tBob using KA
𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵
𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 (𝑟𝑟𝐵𝐵 �
Extracts KAB using KA
Chooses rB
𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 (𝑟𝑟𝐵𝐵 − 1�
Fig. 3. Establishing a shared key using a KDC with the Needham-Schroeder protocol.
1. Before initiating the protocol, Alice is assumed to share a key with the KDC, denoted KA . Similarly,
Bob is assumed to share a key KB with the KDC. Alice and Bob both have unique identifiers IDA and
IDB that are known to each other and the KDC.
2. Alice contacts the KDC and requests a shared key to communicate with Bob by generating a random
nonce rA and sending a message IDA ||IDB ||rA .
3. The KDC generates a shared key KAB and a ticket tB = EKB (KAB ||IDB ). The KDC sends EKA (rA ||IDB ||KAB ||tB )
to Alice.
4. Alice decrypts the message sent by the KDC and extracts tB and KAB . Alice checks to make sure that
the decrypted rA sent by the KDC matches the rA sent by Alice. Alice then transmits IDA ||tB to Bob.
5. Bob decrypts tB using KB and extracts KAB . Bob generates a random number rB and transmits
EKAB (rB ) to Alice.
6. Alice decrypts Bob’s transmitted message using KAB . Alice computes EKAB (rB − 1) and transmits this
message to Bob. By decrypting the message using KAB , Bob verifies that Alice knows the key KAB .
4.1
Replay Attack on Needham-Schroeder
The N-S protocol was found to be vulnerable to a replay attack by Denning and Sacco in 1987. The steps of
the attack are depicted in Figure 4:
1. An attacker Eve eavesdrops on the N-S protocol and obtains the messages exchanged by Alice, Bob, and
the KDC, including the ticket tB .
2. The attacker obtains a key KAB generated during a previous execution of the N-S protocol.
3. The attacker contacts Bob, pretending to be Alice, and transmits IDA ||tB to Bob.
4
Eve records
Eve
Bob
Obtains old
key KAB
recorded 𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵
𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 (𝑟𝑟𝐵𝐵 ′�
𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 (𝑟𝑟𝐵𝐵′ − 1�
Fig. 4. The replay attack on Needham-Schroeder.
4. Bob decrypts tB using KB and extracts the key KAB , which is known to the adversary. Bob generates
a random number rB and transmits EKAB (rB ) to Alice.
5. Since the attacker knows KAB , (s)he decrypts Bob’s transmitted message using KAB . The attacker
transmits EKAB (rB − 1) to Bob.
4.2
Kerberos
Kerberos was developed at MIT in the 1980s to enable the use of a KDC without vulnerability to replay
attack. Kerberos is described by IETF RFC 4120. The steps in Kerberos are depicted in Figure 5, and given
as follows:
1. Alice generates a random number rA and sends IDA ||IDB ||rA to the KDC.
2. The KDC computes tB = EKB (KAB ||IDA ||L), where L is the lifetime of the secret key KAB . The KDC
transmits y1 = EKA (rA ||IDB ||KAB ||L) and tB to Alice.
3. Alice decrypts y1 and obtains KAB . Alice computes y2 = EKAB (IDA ||time), where time is Alice’s current
system time. Alice transmits y2 ||tB to Bob.
4. Bob decrypts tB and obtains KAB . If time > L, then the key has expired and Bob discards the key. Bob
replies to Alice with EKAB (time + 1).
4.3
Security of Kerberos
The Kerberos protocol provides the following security properties:
– Authentication of the KDC: At step 3, Alice can decrypt the message EKA (rA ||IDB ||KAB ||L) sent
by the KDC and verified that the nonce rA was encrypted correctly by the KDC. Since only the KDC
has knowledge of KA , Alice has authenticated the KDC.
5
KDC
Generates 𝐾𝐾𝐴𝐴𝐴𝐴 ,
chooses lifetime L
Computes
𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 = 𝑒𝑒𝐾𝐾𝐵𝐵 (𝐾𝐾𝐴𝐴𝐴𝐴 ||𝐼𝐼𝐷𝐷𝐴𝐴 ||𝐿𝐿�
𝑦𝑦1 = 𝑒𝑒𝐾𝐾𝐴𝐴 (𝑟𝑟𝐴𝐴 ||𝐼𝐼𝐷𝐷𝐵𝐵 ||𝐾𝐾𝐴𝐴𝐴𝐴 ||𝐿𝐿�
Alice
𝐼𝐼𝐷𝐷𝐴𝐴 ||𝐼𝐼𝐷𝐷𝐵𝐵 ||𝑟𝑟𝐴𝐴
Bob
Chooses rA
𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 ||𝑦𝑦1
Computes
𝑦𝑦2 = 𝐾𝐾𝐴𝐴𝐴𝐴 (𝐼𝐼𝐷𝐷𝐴𝐴 ||𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡)
𝑡𝑡𝐵𝐵𝐵𝐵𝐵𝐵 ||𝑦𝑦2
𝑒𝑒𝐾𝐾𝐴𝐴𝐴𝐴 (𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 + 1�
Extracts time
Fig. 5. The Kerberos protocol.
– Preventing an adversary from impersonating Alice: Only a user with knowledge of KA could
decrypt the message y1 sent by the KDC and obtain KAB .
– Authentication of Bob to Alice: The last message sent by Bob, EKAB (time + 1), authenticates Bob
because only a user with KB could decrypt tB and obtain KAB .
– Security against replay attack: The lifetime L prevents an adversary Eve from recovering a stale key
KAB and replaying messages from a previous execution of the protocol.
To achieve these properties, Kerberos has the additional requirement of synchronized clocks between the
parties Alice, Bob, and KDC.
5
Public Key Infrastructure
When Alice and Bob communicate using public key cryptography, both users’ public keys should be managed
to ensure that Alice has Bob’s correct public key and vice versa. Otherwise, an adversary Eve could claim
to be Alice and publish its own public key. Any messages for Alice encrypted by Bob could then be read by
the adversary.
A standard approach to public key management is the use of Public Key Infrastructure (PKI). A key
component of PKI are Certificate Authorities (CAs), which are trusted third-parties used to verify public
keys. Alice can verify Bob’s public key with the help of a CA through the following procedure, depicted in
Figure 6:
1. Alice sends a request to Bob for Bob’s public key.
2. Bob sends a certificate C, which contains Bob’s public key P KB , Bob’s identity, and possibly other
information including the expiration time of the key (see Section 5.1). Attached to C is a signature
σ = SigP KCA (C), which is signed using the private key of the certificate authority.
3. Alice verifies the signature σ on certificate C. If the verification is successful, then Alice accepts P KB
as Bob’s public key.
Thus, we can think of PKI as a secure system that generates, manages, and updates certificates in order
to realize public key cryptography. Such a system consist of several important components:
6
Certificate
Authority
Bob
Alice
Bob, PKBob
Alice
Stores
SigCA(PKBob)
SigCA(PKBob)
Verifies PKBob
belong to Bob
Bob
Verifies
PKBob
PKBob, SigCA(PKBob)
𝐸𝐸𝑃𝑃𝐾𝐾𝐵𝐵𝐵𝐵𝐵𝐵 (𝑚𝑚�
Fig. 6. Verifying Bob’s public key using a certificate authority (CA).
1. Certificate Issuance: Certificates to users are issued by a Certification Authority (CA) (most of the
times there are more than one). Certificates are issued after the user has proven its identity by some
conventional means (as we have discussed in the past).
2. Certificate Revocation: Refers to the revocation of a certificate before the normal expiration time.
Similar to canceling and reissuing a stolen credit card.
3. Key backup: The private keys of all certified users are stored for the purpose of recovery in case of loss.
Recovery can occur in a similar fashion that one recovers a forgotten password (by proving its identity
to the CA).
4. Timestamping: The times that certificates and keys are issued are recorded. These times can be used
by different services for checking the validity of keys, certificates etc.
PKI are used to enable several services involving security, and privacy, and some examples of those services
are:
– Secure email protocols such as Secure Multipurpose Internet Mail Extensions (S-MIME) and Pretty
Good Privacy (PGP). Secure web services such as Secure Socket Layer (SSL) and Transport Layer
Security (TLS). Secure VPNs employing the IPSec protocol.
– Access Control: Implementation of privilege management for access to services such as database information, printing, etc.
– Privacy: Issuance of anonymous or pseudonymous certificates for purpose of access control and preservation of anonymity. For example, when one has access to a service if it belongs ot a group, but the
unique member is not identified.
5.1
X.509 Certificates
Typically a certificate binds the identity of a user to a public key. X.509 is a standard for public key
certificates, and has been adopted by the International Telecommunication Standardization Sector (ITU-T).
An illustration of an X.509 certificate is given as Figure 7. An X.509 certificate consists of the following
components:
– Version - The version of X.509 that is used.
– Serial number - An integer that, together with the CA’s name, uniquely identifies the certificate.
– Signature - The algorithm used to compute the signature on the certificate.
7
– Issuer - The name of the issuing CA.
– Validity - Contains two fields: the time that the certificate becomes valid, and the last time for which it
is valid.
– Subject - The name of the entity whose key is certified.
– SubjectPublicKeyInfo - The subject’s public key, along with the algorithm for which the subject’s public
key is generated (e.g., RSA or DSA).
– AlgorithmIdentifier - The algorithm used to compute the signature on the certificate. Contains the same
information as the Signature field described above.
– Encrypted - Contains the signature on all of the above fields except AlgorithmIdentifier.
Certificate: Data:
Version: 1 (0x0)
Serial Number: 7829 (0x1e95)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services
Division, CN=Thawte Server CA/[email protected]
Validity
Not Before: Jul 9 16:04:02 1998 GMT
Not After : Jul 9 16:04:02 1999 GMT
Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/[email protected]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77: 8
f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
e8:35:1c:9e:27:52:7e:41:8f
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72: 0
d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22: 68:9f
Fig. 7. An example of an X.509 certificate.
5.2
Certificate Authorities
There are many CAs operating in different countries and under different ownership. Examples include Symantec and GoDaddy, along with smaller CAs run by enterprises and individuals. The PKI must have a mechanism for relating the certificate authorities and determining whether a certificate can be trusted based on
the CA that has signed it.
A simple PKI organization is shown in Figure 8. In this PKI, a root CA issues certificates for Regional
Authorities, which in turn sign the certificates of smaller CAs. The trustworthiness of each signature is
derived from the common trust in the root CA.
6
Pretty Good Privacy (PGP)
PGP is a freeware electronic mail security program that employs IDEA for encryption, RSA signatures with
keys up to 2047 bits and MD5 for hashing. The only information that can be obtained by sniffing a PGP
8
RA 2 is approved.
Its public key is
47383AE349…
Root
Root’s signature
RA 1
CA 4 is approved.
Its public key is
542EA34149…
RA 2
RA 2’s signature
CA 1
CA 2
CA 3
CA 4
Fig. 8. A hierarchial PKI.
encrypted message is the recipient if the Key ID of the recipient is mapped to its identity. The interesting
fact about PGP is that it does not use a trusted CA, but management of keys is done in a distributed manner
by the users themselves using an architecture known as web of trust.
Instead of having a CA issuing certificates, the users issue the certificates themselves. The steps are as
follows:
– Alice generates a public key and binds her ID on the public key.
– Alice then generates her own certificate and signs it (with the private key corresponding to the public
key it generated).
– Other users can sign Alice’s public information and provide Alice with the certificate.
– Alice keeps a collection of all the certificates she has obtained from other users. The set of certificates
held by Alice are called the key ring.
– Alice assigns an Owner’s Trust Field (OFT) (a reputation indicator) to each certificate it obtains.
OFT values can be implicitly trusted, completely trusted, partially trusted or untrusted, with her own
certificate being always implicitly trusted.
– Once OFT values are set, Alice computes a Key Legitimacy Field (KLF) for each certificate with values
valid, marginally valid, and invalid.
6.1
Disadvantages of PGP
– It requires users to be technically savvy since users need to set the OFT values themselves (KLF values
are calculated automatically).
– No way to revoke bogus certificate (by default there is no notion of bogus certificate since there is no
CA issuing the certificates).
– It does not scale to large networks of users where users do not know each other and hence cannot build
a web of trust.
Sources for Today’s Lecture:
1. Wade Trappe and Lawrence C. Washington Introduction to Cryptography with Coding Theory. Prentice Hall, 2002,
p. 177–194 and 236–248.
2. Douglas R. Stinson, Cryptography, Theory and Practice, 3rd edition. CRC Press, 2005, p. 140–155 and 281–318
and 393–397 and 414–424 and 429–433 and 457–464.
3. Charlie Kaufman, Radia Perlman, and Mike Speciner Network Security: Private Communication in Public World,
2nd Edition. Prentice Hall, 2002, p. 117–143 and 307–365 and 371–401.
9