CS-381 Network security
PU B LIC KE Y CR Y PT O GR APH Y
Dr. M M Waseem
Iqbal
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
Distribution of Public Keys
can be considered as using one of:
public announcement
publicly available directory
public-key authority
public-key certificates
Public Announcement
users distribute public keys to recipients or
broadcast to community at large
eg. append PGP keys to email messages or post to
news groups or email list
major weakness is forgery
anyone can create a key claiming to be someone else
and broadcast it
until forgery is discovered can masquerade as claimed
user
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
Public-Key Authority
improve security by tightening control over
distribution of keys from directory
has properties of directory and requires users to
know public key for the directory
then users interact with directory to obtain any
desired public key securely
does require real-time access to directory when keys
are needed
Public-Key Authority
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 etc
with all contents signed by a trusted Public-Key or
Certificate Authority (CA)
can be verified by anyone who knows the public-key
authorities public-key
Cryptographic Key
Infrastructure
Goal: bind identity to key
Classical: not possible as all keys are shared
U se 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
E rroneous binding means no secrecy between
principals
Assume principal identified by an acceptable name
1/18/2 0 2 2
Certificates
Create token (message) containing
Identity of principal (here,Alice)
Corresponding public key
T imestamp (when issued)
O ther information (perhaps identity of signer)
signed by trusted authority (here,Cathy)
CA = { eA || Alice || T } dC
1/18/2 0 2 2
U se
B ob gets Alice’s certificate
If he knows Cathy’s public key,he can decipher the
certificate
When was certificate issued?
Is the principal Alice?
Now B ob has Alice’s public key
Problem: B ob needs Cathy’s public key to
validate certificate
Problem pushed “up” a level
T wo approaches: Merkle’s tree,signature chains
1/18/2 0 2 2
Certificate Signature Chains
Create certificate
Generate hash of certificate
E ncipher hash with issuer’s private key
V alidate
O btain issuer’s public key
Decipher enciphered hash
R ecompute hash from certificate and compare
1/18/2 0 2 2
X .5 0 9 Chains
Some certificate components in X .5 0 9 v3:
V ersion
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
1/18/2 0 2 2
X .5 0 9 Certificate V alidation
O btain issuer’s public key
T he one for the particular signature algorithm
Decipher signature
Gives hash of certificate
R ecompute hash from certificate and compare
If they differ,there’s a problem
Check interval of validity
T his confirms that certificate is current
1/18/2 0 2 2
Issuers
Certification Authority (CA): entity that issues
certificates
Multiple issuers pose validation problem
Alice’s CA is Cathy;
B ob’s CA is Dan;
how can Alice validate B ob’s certificate?
H ave Cathy and Dan cross-certify
E ach issues certificate for the other
1/18/2 0 2 2
V alidation and Cross-Certifying
Certificates:
Cathy<<Alice>>
Dan<<B ob>
Cathy<<Dan>>
Dan<<Cathy>>
Alice validates B ob’s certificate
Alice obtains Cathy<<Dan>>
Alice uses (known) public key of Cathy to validate
Cathy<<Dan>>
Alice uses Cathy<<Dan>> to validate Dan<<B ob>>
1/18/2 0 2 2
Signing
Single certificate may have multiple signatures
Notion of “trust” embedded in each signature
R ange from “untrusted” to “ultimate trust”
Signer defines meaning of trust level (no standards!)
All version 4 keys signed by subject
Called “self-signing”
1/18/2 0 2 2
V alidating Certificates
Alice needs to validate
Arrows show signatures
B ob’s O penPGP cert Self signatures not shown
Does not know Fred,Giselle,
or E llen J ack
Alice gets Giselle’s cert
Knows H enry slightly,but H enry
his signature is at “casual” E llen
level of trust Irene
Alice gets E llen’s cert Giselle
Knows J ack,so uses his
cert to validate E llen’s,then Fred
hers to validate B ob’s
B ob
1/18/2 0 2 2
Key R evocation
Certificates invalidated before expiration
U sually due to compromised key
May be due to change in circumstance (e.g., someone
leaving company)
Problems
E ntity revoking certificate authorized to do so
R evocation information circulates to everyone fast
enough
Network delays,infrastructure problems may delay
information
1/18/2 0 2 2
CR Ls
Certificate revocation list lists certificates that are
revoked
X .5 0 9 : only certificate issuer can revoke certificate
Added to CR L
PGP: signers can revoke signatures;owners can
revoke certificates,or allow others to do so
R evocation message placed in PGP packet and signed
F lag marks it as revocation message
1/18/2 0 2 2
Public-Key Certificates
