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