Module 3: Key Management &
Distribution
Symmetric Key Distribution (Overview)
• Two parties must share same secret key; key must be
protected.
• Four ways to distribute symmetric keys:
– 1) A selects key and physically delivers to B.
– 2) Third-party selects and physically delivers to A and B.
– 3) Use of previously shared key to encrypt new key.
– 4) Use a trusted third party C to deliver keys over
encrypted links.
Key Distribution Centre (KDC)
• Uses hierarchy of keys (master keys + session keys).
• Session key: temporary key for a logical connection; typically
discarded after use.
• Master key: shared between KDC and each end-system; used
to encrypt session keys.
KDC - Key Distribution Scenario
KDC - Key Distribution Scenario (Steps
1–3)
• Step 1: A requests session key from KDC, includes IDs and
nonce N1.
• Nonce (N1): timestamp/counter/random number to prevent
replays.
• Step 2: KDC replies encrypted with Ka and includes:
– • Session key Ks for A.
– • Original request (including N1) so A can match response.
– • For B (encrypted under Kb): Ks and IDA.
• Step 3: A stores Ks and forwards E(Kb,[Ks || IDA]) to B.
KDC - Authentication Steps (4 & 5)
• Step 4: B uses Ks to send a nonce N2 to A (encrypted with
Ks).
• Step 5: A replies with f(N2) (e.g., N2+1) encrypted with Ks —
proves freshness.
Major Issues with KDC
• KDC must be trusted and protected — single point of failure /
target for attack.
• Scalability: a single KDC not practical for very large
networks.
• Solutions: hierarchy of KDCs (local KDCs + global KDC).
Session Key Lifetime
• Trade-off: distribution delays & network load
• Connection-oriented: use same Ks for connection length, If a
logical connection has a very long lifetime, then it would be
prudent to change the session key periodically,
• Connectionless: options include per-exchange keys or
fixed-time / fixed-count key lifetimes.
Transparent Key Control Scheme (SSM)
Transparent Key Control Scheme (SSM)
• Session Security Module (SSM) handles key requests and
end-to-end encryption.
• Steps:
– 1) Host sends connection request; SSM saves packet.
– 2) SSM asks KDC for permission / session key (via master
key shared with KDC).
– 3) KDC generates Ks and delivers to SSMs encrypted under
each SSM's permanent key.
– 4) SSM releases cached packet; connection established.
– 5) SSMs encrypt all user data using Ks (transparent to
applications).
Decentralized Key Control
Decentralized Key Control
• Avoids trusting a single KDC, but requires each end-system to
share keys with many peers.
• Decentralized session key establishment (example):
– 1) A -> B: request with nonce N1.
– 2) B -> A: message encrypted with shared master key
containing Ks, IDB, f(N1), N2.
– 3) A -> B: returns f(N2) using Ks (authentication).
Controlling Key Usage — Key Types
• Separate key types to control usage:
– • Data-encrypting key — general communications.
– • PIN-encrypting key — electronic funds transfer
– • File-encrypting key — encrypt stored files.
• Avoid importing master keys as session keys — risk of
unauthorized access.
Key Tag (DES example) & Drawbacks
• DES has 8 non-key parity bits that can act as an 8-bit key tag.
Tag bits can indicate:
• One bit indicates whether the key is a session key or a master
key.
• One bit indicates whether the key can be used for encryption.
• One bit indicates whether the key can be used for decryption.
• The remaining bits are spares for future use.
• Drawbacks:
– • Only 8 bits — limited flexibility.
Control Vector Scheme
Control Vector Scheme
• Each session key has a control vector (CV) specifying allowed
uses/restrictions.
• CV is hashed: H = h(CV). Key-input = Km ⊕ H. Ciphertext =
E([Km ⊕ H], Ks).
• Decryption: D([Km ⊕ H], E([Km ⊕ H], Ks)) gives Ks; CV is
sent in clear with Ks.
• Advantages: arbitrary CV length; CV available in clear so
controls can be enforced widely.
Symmetric Key Distribution using
Asymmetric Encryption
• Simple Secret Key Distribution
• Secret Key Distribution with Confidentiality
and Authentication
• A Hybrid Scheme
Simple Secret Key Distribution
(public-key)
Simple Secret Key Distribution
(public-key)
• A generates key pair {PUa, PRa} and sends PUa and IDA to
B.
• B generates Ks and sends E(PUa, Ks) to A.
• A decrypts with PRa to obtain Ks; both discard ephemeral
keys as needed.
• Vulnerability: man-in-the-middle if public keys are
forged/intercepted.
Secret Key Distribution with
Authentication
Secret Key Distribution w/
Authentication (nonces)
• 1) A -> B: E(PUb, [IDA, N1]).
• 2) B -> A: E(PUa, [N1, N2]) — proves B decrypted A's
message.
• 3) A -> B: E(PUb, E(PRa, Ks)) — ensures confidentiality and
authenticity.
• 4) B recovers Ks by appropriate decryption steps.
Hybrid Scheme (KDC + Public-Key)
• KDC retains master-keys with users and distributes Ks
encrypted under master-keys.
Distribution of Public Keys (Methods)
• Common methods:
– • Public announcement (e.g., PGP key servers).
– • Publicly available directory (trusted directory authority).
– • Public-key authority (interactive retrieval with authority).
– • Public-key certificates (CA-signed, e.g., X.509).
Public Announcement & Public
Directory
• Public announcement: simple but vulnerable to forgery.
• Public directory: register keys with authority; authority must
be trusted and secure.
• If directory's private key compromised, attacker can distribute
counterfeit keys.
Public Announcement
Public Directory
Public-Key Authority
Public-Key Authority (interactive
retrieval)
• Requires clients to know the authority's public key.
• A requests B's public key (timestamped); authority replies
signed with PRauth.
• Message includes B's PUb, original request, and timestamp to
prevent replay.
Public-Key Certificates
Public-Key Certificates (Overview)
• Certificate binds identity to public key and is signed by a CA.
• Anyone knowing CA's public key can validate the certificate.
• Common standard: X.509 .
X.509 Certificates — Fields
• Key fields in X.509 certificates:
– • Version, Serial Number, Signature Algorithm.
– • Issuer Name, Validity Period (notBefore, notAfter).
– • Subject Name, Subject's Public-Key Info.
– • Optional unique IDs, Extensions, Signature (signed by
CA).
Certificate Revocation
• Reasons to revoke: private key compromise, no longer certified, CA compromised.
• CA publishes CRL: includes issuer, creation date, next update date, and revoked
serials.
• Each CRL entry: certificate serial number + revocation date. Clients should check
CRL.
X.509 Version 3 — Extensions
• Version 3 adds flexible extensions: identifier, criticality flag, value.
• Major extension categories:
– • Key & policy information (certificate policy, key usage).
– • Subject & issuer attributes (alt names, contact info, images).
– • Certification path constraints (limits on CA capabilities down the chain).
Hash functioin
APPLICATIONS OF CRYPTOGRAPHIC
HASH FUNCTIONS
• Message Authentication :Message
authentication is a mechanism or service used
to verify the integrity of a message.
Different ways to use hash code
Hash code in digital Signatures