Key Distribution

SMU

CSE 5349/7349

Where to Put Encryption?

Link level
Vulnerable links equipped with encryption devices on both sides Needs large number of devices Needs decryption to perform routing

End-to-end
Carried out at the end systems Can encrypt only the data portion and not the header
SMU CSE 5349/7349

Link vs. End-to-End Key Distribution

Link keys must be distributed to each pair of link endpoints in advance
Relatively easy to distribute securely

For e-t-e, must generate and distribute many keys, often in real time

SMU

CSE 5349/7349

Logical Placement
Application layer Transport layer Network layer Link layer

SMU

CSE 5349/7349

Traffic Analysis
Both techniques hide user data (payload) Link encryption
Hides address information Buffers clear data in each node

E-T-E encryption
Leaves addresses in the clear No need to buffer decrypted payload

Use both techniques?

SMU CSE 5349/7349

Traffic Analysis
Identities of communicating partners Frequency of communication Message patterns, e.g., length, quantity, (encrypted) content Correlation between messages and real world events Can (sometimes) be defeated through traffic padding
SMU CSE 5349/7349

Covert Channels
Essentially, the dual of traffic analysis Usually intended to violate or defeat a security policy Examples Message length Message content Message presence

SMU

CSE 5349/7349

Key Distribution
Most important component in secure transmission. Options: (between A and B).

A selects a key and physically delivers it to B. A trusted third party key distribution center (KDC) selects a key and physically delivers it to A and B. If A and B already have have a viable key, it can be used to distribute a new key. If A and B have a secure link to KDC, can receive the key through that channel.
CSE 5349/7349

SMU

Key Distribution (contd)

Manual delivery is straightforward for link encryption, challenging for E-T-E The number of keys grows quadratically with the number of endpoints (n*(n-1)/2)
Further complexity for application/user level encryption

KDC a good alternative

Only n master keys required

CSE 5349/7349

SMU

Decentralized Distribution
No need for KDC to be trusted and protected Any two nodes can establish a session key Needs n(n-1)/2 master keys Can generate any number of session keys Key distribution protocol

SMU

CSE 5349/7349

Public Key Management

Distribution of public keys Public announcement Public directories Public-key authority Public-key certificates Use of public-key encryption to distribute secret keys

SMU

CSE 5349/7349

Public-Key Authority and Certificates

Very similar to session key obtaining process Both the parties are assumed to have authoritys public key Authority sends the key encrypted in private key (for authentication) Instead use certificates authenticated by authority
SMU CSE 5349/7349

Authority could be a bottle-neck

Public-key distribution of secret keys

A sends {public key, ID) to B B sends secret key encrypted in Kua A decrypts for private key

SMU

CSE 5349/7349

Public-Key Authority
Public-key authority (1) Request|T1 (4) Request|T2

(5) EKd_auth[Ke_a|Request|T2] (2) EKd_auth[Ke_b|Request|T1] (3) EKe_b[IDA| N1]

A (7) EKe_b[N2]
SMU

(6) EKe_a[N1|N2]

CSE 5349/7349

Public-Key Certificates
A certificate contains a public key and other information
Created by a certificate authority Given to the participant with the matching private key

A participant transmits its certificate to convey its key information

Other participants can verify that the certificate was created by the authority
All nodes are pre-configured with the public key of the certificate authority (CA)
SMU CSE 5349/7349

Exchange of Public-key Certificates

Certificate Authority Ke_b

CB= EKd_auth[T2, IDB, Ke_b] Ke_a CA= EKd_auth[T1, IDA, Ke_a] (1) CA A (2) CB B

B does: DKe_auth(CA)= DKe_auth(EKd_auth[T1, IDA, Ke_a]) = (T1, IDA, Ke_a), hence gets the public key of A
SMU CSE 5349/7349

Public-key distribution of secret keys

A sends {public key, ID) to B B sends secret key encrypted in Kua A decrypts for private key
Vulnerable to active attack?
(1) Ku_a|IDA
A
SMU

(2) EKu_a[Ks]
CSE 5349/7349

Distribution With Confidentiality and Authentication

(1) EKu_b[N1|IDA] (2) EKu_a[N1| N2] (3) EKu_b[N2] (4) EKu_b[EKr_a[Ks]]

SMU

CSE 5349/7349

Diffie-Hellman KE
Public information: p is a prime number g is a generating element of Zp Alices
Bobs
Private Key : a Public Key : ga mod p Private Key : b Public Key : gb mod p
CSE 5349/7349

SMU

DH Key Exchange
Key Exchange: Alice obtains gb and computes (gb)a = gab mod p = ks Bob obtains ga and computes (ga)b = gab mod p = ks Alice and Bob have agreed upon key ks The well-known man-in-the-middle attack exploits the lack of authentication
SMU CSE 5349/7349

Diffie-Hellman Scheme
Security factors
Discrete logarithm very difficult. Shared key (the secret) itself never transmitted.

Disadvantages:
Expensive exponential operation The scheme itself cannot be used to encrypt anything it is for secret key establishment. No authentication, so you can not sign anything

SMU

CSE 5349/7349

Man-In-The-Middle Attack
Alice ga=123 123 --> Eve Bob ge =654 gb =255 654 --> <--654 <--255 gae geb Eve plays Bob to Alice and Alice to Bob
SMU CSE 5349/7349

DH in Phone Book Mode

In the attack public key-component was intercepted and substituted Phone book mode allows everyone to generate the public key-component in advance and publish them through other reliable means All communicating parties agree on their common <g, p>
SMU CSE 5349/7349

Authenticated DH
Alice sends ga mod p to Bob and Bob computes kB = (ga )b mod p. Bob sends gb mod p and SB(gb, ga) and his certificate to Alice Alice computes kA = (gb )a mod p. Finally, Alice sends ga mod p and SA(ga, gb) and his certificate to Bob

SMU

CSE 5349/7349

Key Generation
Manual selection not good Using pass-phrase Random generation
PRNG Standards

SMU

CSE 5349/7349

Random Number Generation

Need
Stream Key Encryption keys
Secret symmetric keys Private asymmetric keys Session keys

Digital Signature Schemes

RSA

Against replay attacks

Nonce
SMU CSE 5349/7349

How do we know?

SMU

CSE 5349/7349

True Random Sources

Elapsed time between emissions of particles from a radioactive source Quantum effects in a semiconductor, such as a noisy diode or a noisy resistor Frequency fluctuations of free-running oscillators Fluctuations in the amount a metal insulator semiconductor capacitor is charged during a fixed period of time Fluctuations in read times caused by air turbulence within a sealed disk drive
SMU CSE 5349/7349

Typical Implementation

SMU

CSE 5349/7349

Cryptographic PRNGs
RNG from a counter ANSI X9.17 PRNG
2 pr inputs 3 Triple DES encryption

Blum Blum Shub generator

Considered to be cryptographically secure
SMU CSE 5349/7349