BCSE309L

Module 5
Key Management and Distributation
Winter Semester 2023-24

Dr. Sunil Kumar

Outline
Key Management and Distributation
• X.509 Authentication Service
• Public Key Infrastructure (PKI)
User Authentication
• Kerberos
 Key Distribution
➢ symmetric schemes require both parties to share
a common secret key
➢ issue is how to securely distribute this key
➢ whilst protecting it from others
➢ frequent key changes can be desirable
➢ often secure system failure due to a break in the
key distribution scheme
 Symmetric Key Distribution
➢ given parties A and B have various key
distribution alternatives:
1. A can select key and physically deliver to B
2. third party can select & deliver key to A & B
3. if A & B have communicated previously can
use previous key to encrypt a new key
4. if A & B have secure communications with a
third party C, C can relay key between A & B
 Key Hierarchy
➢ typically
have a hierarchy of keys
➢ session key
⚫ temporary key
⚫ used for encryption of data between users
⚫ for one logical session then discarded
➢ master key
⚫ used to encrypt session keys
⚫ shared by user & key distribution center
Key Hierarchy
Key Distribution Scenario
 Key Distribution Issues
➢ hierarchies of KDC’s required for large
networks, but must trust each other
➢ session key lifetimes should be limited for
greater security
➢ use of automatic key distribution on behalf
of users, but must trust system
➢ use of decentralized key distribution
➢ controlling key usage
Symmetric Key Distribution Using
Public Keys
 Simple Secret Key Distribution
➢ Merkle proposed this very simple scheme
⚫ allows secure communications
⚫ no keys before/after exist
 Man-in-the-Middle Attack
➢ thisvery simple scheme is vulnerable to
an active man-in-the-middle attack
 Secret Key Distribution with
Confidentiality and Authentication
 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
⚫ may be vulnerable to tampering
Public-Key Authority
 Public-Key Certificates
➢ The public-key authority could be somewhat of a
bottleneck in the system, for a user must appeal to the
authority for a public key for every other user that it
wishes to contact.
➢ 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
Public-Key Certificates
 X.509 Authentication Service
➢ ITU has designed X.509, a recommendation that
has been accepted by the Internet with some
changes.
➢ X.509 is a way to describe the certificate in a
structured way. It uses a well-known protocol
called ASN.
➢ X.509 certificates are widely used
⚫ have 3 versions
 X.509
Certificate
Use
X.509 Certificates
 Obtaining a Certificate
➢ any user with access to CA can get any
certificate from it
➢ only the CA can modify a certificate
➢ because cannot be forged, certificates can
be placed in a public directory
 Public Key Infrastructure
• Public-Key Infrastructure (PKI) is a model for creating,
distributing, and revoking certificates based on the
X.509.
• Public-Key Infrastructure X.509 (PKIX).
Public Key Infrastructure
 PKIX Management
➢ functions:
⚫ registration
⚫ initialization
⚫ certification
⚫ key pair recovery
⚫ key pair update
⚫ revocation request
⚫ cross certification
➢ protocols: certificate management protocols
(CMP), certificate management messages over
CMS (CMC)
Kerberos
Mutual Authentication
• Protocols which enable communicating parties to
satisfy themselves mutually about each other’s
identity and to exchange session keys
Central to the
problem of
authenticated
key exchange are
two issues:
Timeliness
• Important because of the threat
of message replays Confidentiality
• Such replays could allow an • Essential identification and
opponent to: session-key information
• compromise a session key must be communicated in
• successfully impersonate encrypted form
another party • This requires the prior
• disrupt operations by presenting existence of secret or public
parties with messages that keys that can be used for
appear genuine but are not this purpose
Remote User-Authentication Using
Symmetric Encryption
A two-level hierarchy of symmetric keys can be used
to provide confidentiality for communication in a
distributed environment
• Strategy involves the use of a trusted key distribution
center (KDC)
• Each party shares a secret key, known as a master key,
with the KDC
• KDC is responsible for generating keys to be used for a
short time over a connection between two parties and
for distributing those keys using the master keys to
protect the distribution
Kerberos
• Authentication service developed as part of Project
Athena at MIT
• A workstation cannot be trusted to identify its users
correctly to network services
• A user may gain access to a particular workstation and pretend
to be another user operating from that workstation
• A user may alter the network address of a workstation so that
the requests sent from the altered workstation appear to come
from the impersonated workstation
• A user may eavesdrop on exchanges and use a replay attack to
gain entrance to a server or to disrupt operations

• Kerberos provides a centralized authentication server

whose function is to authenticate users to servers and
servers to users
• Relies exclusively on symmetric encryption, making no use
of public-key encryption
Kerberos Requirements
• The first published report on Kerberos listed the
following requirements:
• A network eavesdropper • Should be highly
should not be able to reliable and should
obtain the necessary employ a distributed
information to server architecture
impersonate a user with one system able
to back up another
Secure Reliable

Scalable Transparent

• The system should be • Ideally, the user should not be

capable of supporting aware that authentication is taking
large numbers of clients place beyond the requirement to
and servers enter a password
Kerberos Version 4
• Makes use of DES to provide the authentication service
• Authentication server (AS)
• Knows the passwords of all users and stores these in a centralized
database
• Shares a unique secret key with each server
• Ticket
• Created once the AS accepts the user as authentic; contains the
user’s ID and network address and the server’s ID
• Encrypted using the secret key shared by the AS and the server

• Ticket-granting server (TGS)

• Issues tickets to users who have been authenticated to AS
• Each time the user requires access to a new service the client
applies to the TGS using the ticket to authenticate itself
• The TGS then grants a ticket for the particular service
• The client saves each service-granting ticket and uses it to
authenticate its user to a server each time a particular service is
requested
The Version 4 Authentication
Dialogue
The lifetime associated with the
ticket-granting ticket creates a
problem: A network service (the TGS or an
application service) must be able to
• If the lifetime is very short (e.g., minutes), the
user will be repeatedly asked for a password prove that the person using a ticket is
• If the lifetime is long (e.g., hours), then an the same person to whom that ticket
opponent has a greater opportunity for replay was issued

Servers need to authenticate

themselves to users
Summary of Kerberos Version 4 Message Exchanges
Elements of Kerberos Version 4 Protocol
Kerberos Realms and Multiple Kerberi

• A full-service Kerberos environment consisting of

a Kerberos server, a number of clients, and a
number of application servers requires that:
• The Kerberos server must have the user ID and
hashed passwords of all participating users in its
database; all users are registered with the Kerberos
server
• The Kerberos server must share a secret key with
each server; all servers are registered with the
Kerberos server
• The Kerberos server in each interoperating realm
shares a secret key with the server in the other realm;
the two Kerberos servers are registered with each
other
Kerberos Realm
• A set of managed nodes that share the same
Kerberos database
• The database resides on the Kerberos master
computer system, which should be kept in a
physically secure room
• A read-only copy of the Kerberos database might
also reside on other Kerberos computer systems
• All changes to the database must be made on the
master computer system
• Changing or accessing the contents of a Kerberos
database requires the Kerberos master password
Kerberos Principal

• A service or user that A service

is known to the An or user
name
Kerberos system instance
name
• Identified by its
A realm
principal name name

Three parts of a principal

name
Summary of Kerberos Version 5 Message Exchanges
Kerberos
Version 5
Flags
Mutual Authentication
• Public-key encryption for session key distribution
• Assumes each of the two parties is in possession of the
current public key of the other
• May not be practical to require this assumption
• Denning protocol using timestamps
• Uses an authentication server (AS) to provide public-key
certificates
• Requires the synchronization of clocks
• Woo and Lam makes use of nonces
• Care needed to ensure no protocol flaws
One-Way Authentication
• Have public-key approaches for e-mail
• Encryption of message for confidentiality,
authentication, or both
• The public-key algorithm must be applied once or
twice to what may be a long message
• For confidentiality encrypt message with one-
time secret key, public-key encrypted
• If authentication is the primary concern, a digital
signature may suffice
Kerberos Authentication Steps

Kerberos TGS

TGT Service TKT

Client Server
Service REQ

48
(1) AS_REQUEST

• The first step in accessing a service that requires

Kerberos authentication is to obtain a ticket-
granting ticket.

• To do this, the client sends a plain-text message to

the AS:
• <client id, KDC id, requested ticket expiration, nonce1>

49
(2) AS_REPLY
• <{Kc,TGS, none1}Kc, {ticketc,tgs}KTGS>

• Notice the reply contains the following:

• The nonce, to prevent replays
• The new session key
• A ticket that the client can’t read or alter

• A ticket:
• ticketx,y = {x, y, beginning valid time, expiration time, Kx,y}

50
(3) TGS_REQUEST
• The TGS request asks the TGS for a ticket to
communicate with a a particular service.

• <{authc} Kc, TGS, {ticketc, TGS}KTGS, service, nonce2>

•
• <{authc} is known as an authenticator it contains the name
of the client and a timestamp for freshness.

51
(4) TGS_REPLY
• <{Kc,service, nonce2}K c, TGS, {ticketc, service }Kservice >

• Notice again that the client can’t read or alter the

ticket
• Notice again the use of the session key and nonce
between the client and the TGS

52
(5) APP_REPLY
• <{authc}Kc,service, {ticketc,service}Kservice, request, nonce3>

• Notice again the use of the session key as well as

the protected ticket.

53
(6) APP_REPLY
• <{nonce3}Kc,service, response>

• Because of the use of the encrypted nonce, the

client is assured the reply came form the
application, not an imposter.

54
Pretty Good Privacy (PGP)
• History
• Written in early 1990s by Phil Zimmermann
• Primary motivation is email security
• Controversial for a while because it was too strong
• Distributed from Europe
• Now the OpenPGP protocol is an IETF standard (RFC 2440)
• Many implementations, including the GNU Privacy Guard (GPG)
• Uses
• Message integrity and source authentication
• Makes message digest, signs with public key cryptosystem
• Webs of trust
• Message body encryption
• Private key encryption for speed
• Public key to encrypt the message’s private key

55
Secure Shell (SSH)
• Negotiates use of many different algorithms
• Encryption
• Server-to-client authentication
• Protects against man-in-the-middle
• Uses public key cryptosystems
• Keys distributed informally
• kept in ~/.ssh/known_hosts
• Signatures not used for trust relations
• Client-to-server authentication
• Can use many different methods
• Password hash
• Public key
• Kerberos tickets

56
SSL/TLS
• History
• Standard libraries and protocols for encryption and
authentication
• SSL originally developed by Netscape
• SSL v3 draft released in 1996
• TLS formalized in RFC2246 (1999)
• Uses public key encryption
• Uses
• HTTPS, IMAP, SMTP, etc

57
 Transport Layer Security (TLS)
aka Secure Socket Layer (SSL)

• Used for protocols like HTTPS

• Special TLS socket layer between application and TCP (small

changes to application).

• Handles confidentiality, integrity, and authentication.

• Uses “hybrid” cryptography.

58
Setup Channel with TLS
“Handshake”
Handshake Steps:
1) Clients and servers negotiate
exact cryptographic protocols
2) Client’s validate public key
certificate with CA public key.
3) Client encrypt secret random
value with servers key, and send
it as a challenge.
4) Server decrypts, proving it has
the corresponding private key.
5) This value is used to derive
symmetric session keys for
encryption & MACs.

59
 How TLS Handles Data
1) Data arrives as a stream from the application via the TLS Socket

2) The data is segmented by TLS into chunks

3) A session key is used to encrypt and MAC each chunk to form a TLS “record”,
which includes a short header and data that is encrypted, as well as a MAC.

4) Records form a byte stream that is fed to a TCP socket for transmission.

60