# CT30A9700 Network Security

Pekka Jäppinen

## Key exchange

• In order to create secure communication channel both sides have to know the key to encrypt and decrypt data
• In symmetric cryptography both side have one shared key.
• secure key exchange guarantees that both sides know the key and no-one else does.
• In asymmetric both sides have their own private keys and publicly known public keys
• Key exchange is used to verify the authenticity of the public key.

## Creating keys

• Creating a symmetric key ca be done in two ways
• 1. Generating key before key exchange
• Generate a random number that is between values $0$ - $(2^{n}-1)$ , where n is the size of required key
• 64 - bit key = 64 zeroes and ones in a row → integer number $0 - (2^{64}-1)$.
• The value has to be real random value.
• Which side generates the key
• Do we trust that the other side generates secure key?
• 2. Generating key along with the key exchange protocol
• Key depends on random values generated on both sides
• Creation of asymmetric key
• Depends on the used algorithm as the public and private key has a relation.

## Symmetric key exchange using symmetric cryptography

• Key exchange with symmetric cryptography
• Trusted third party T has a symmetric key for communication with both A and B (keys $K_{T-A}$ and $K_{T-B}$ )
• 1. A connects to T and requests session key ($K_{A-B}$) to communicate with B
• 2. T generates session key and makes two copies of it. T encrypts one copy with$K_{T-A}$ and other with $K_{T-B}$ and sends the copies to A
• 3. A decrypts the session key ($D_{K_{T-A}}(E(_{K_{T-A}}K_{A-B}))$ )
• 4. A sends to B the messages containing session key that was encrypted with key $K_{T-B}$
• 5. B decrypts the key
• 6. A and B can now communicate securely with using the key $K_{A-B}$

## Problems in using symmetric cryptography

• Have to trust T completely
• T knows the session key and can thus decrypt the secured communication between A and B
• T can be bottleneck
• If Malicious M corrupts T, M can decrypt the messages sent between A and B (old and new messages)
• Blocking communications to T breaks the system

## Shamir-three-pass protocol

• Requires commutative symmetric cipher
• In commutative ciphers encryption and decryption functions can change places or can even be the same function. For example XOR
• 1. A creates random session key $K_{A-B}$,to be used for communication with B and encrypts it with another random key $K_{A}$
$E_{K_{a}}(K_{A-B})$
• 2. A sends the encrypted key to B
• 3. B encrypts the message from A with his own random key $K_{B}$ and sends the message back to A
$E_{K_{B}}(E_{K_{A}}(K_{A-B})$
• 4. A decrypts the message with her own key and sends it back to B
$D_{K_{A}}(E_{K_{B}}(E_{K_{A}}(K_{A-B}))$
• 5. B decrypts the message with his own key and has now the session key
$D_{K_{B}}(D_{K_{A}}(E_{K_{B}}(E_{K_{A}}(K_{A-B})))=K_{A-B}$
• If XOR is used as encryption function, the key can be revealed if all the three transmitted messages are eavesdropped.
• XOR:ing first and second message gives $K_{B}$ as a result. XOR:ing $K_{B}$ with third messages gives key $K_{A-B}$

## Key exchange using asymmetric cryptography

• 1. A fetches the public key of B from T.
• T can be for example KDC (Key Distribution Center)
• 2. A generates random session key.
• 3. A encrypts session key with the public key of B and then sends it to B.
• 4. B decrypts the message from A with his private key.
• 5. A and B encrypt the communication channel with the symmetric cipher using the shared session key.

## Man-in-the-middle

• Man-in-the-middle attack can be used to eavesdrop communication when asymmetric algorithm is used.
• M pretends to be B to A and A to B and thus can eavesdrop the communication
• 1. A sends her public key to B. M catches the message and instead sends his own public key to B.
• 2. B sends his public key to A. M catches also this message and sends A his own public key.
• 3. When A sends messages to B they are encrypted using M:s public key. M catches the messages, decrypts them and encrypts them again using B:s public key and then sends them to B
• 4. Similar measures are taken when B sends messages to A.
• when using KDC
• M pretends to be KDC to both A and B
• M may pretend to be A and B towards KDC and give his own key to KDC as a key of A or B.
• M may break in to the KDC's key database and change the key information in there
• Man-in-the-middle attack works, because A and B has no way to verify they validity of each others public key nor with whom they are communication

## Using digital signatures to verify keys

• T signs the public keys of A and B
• The keys are signed along with information about the owner of the keys (certificate)
$I_{T},E_{Tprivate}(k_{Apublic},I_{A}),k_{Tpublic}$
where I is Identity information and k is the key
• A and B can verify the validity of keys by verifying the signature of T
• Requires the knowledge about the public key of T.
• The protocol reduces the risks of using T.
• M cannot pretend to be A or B, as he don't know their secret keys.
• M cannot change his own key as a key of A or B as his key is signed for M.
• IF KDC is broken into, M can get only the public key of KDC, which can then be used to sign new keys to other identities.
• Previously cerated and used session keys are not compromised like in symmetric model.
• Breaking in have to happen before public key exchange or the communicating partners have to be fooled to redo the key exchange.
• Different Ts can certificate each other to make the life of M harder.

## Key exchange along the message

• The key exchange is performed along with the first message of protocol
• 1. A generates random session key K and encrypts message M with it
$E_{k}(M)$
• 2. A fetches the public key of B
• 3. A encrypts K with the public key of B
$E_{Bpublic}(K)$
• 4. A sends both the encrypted message and encrypted session key to B (secured envelope)
$E_{K}(M),\: E_{Bpublic}(K)$
• 5. B decrypts the session key sent by A
$D_{Bprivate}(E_{Bpublic}(K))$
• 6. B decrypts the message using the session key
$D_{K}(E_{K}(M))$
• For additional security A signs the whole message $E_{APrivate}(E_{K}(M),\: E_{Bpublic}(K))$
• B can verify the signature $D_{APublic}(E_{APrivate}(E_{K}(M),\: E_{Bpublic}(K)))$
• Time stamps and other security protocols are described later.

• When communicating with multiple persons.
• 1. A generates random session key k and encrypts message M with it.
$E_{K}(M)$
• 2. A fetches the public keys of B, c and D.
• 3. A encrypts k with the public keys of B,C and D
$E_{Bpublic}(K),\: E_{Cpublic}(K),\: E_{Dpublic}(K)$
• 4. A Broadcasts encrypted messages and all the encrypted keys
$E_{Bpublic}(k),\: E_{Cpublic}(K),\: E_{Dpublic}(K),\: E_{K}(M)$
• 5. Only B,C and D can decrypt the key using their secret key and then decrypt the message M.

## Diffie-Hellman key exchange

• Asymmetric algorithm that can only be used for key exchange not in encrypting messages
• Choose numbers n and g so that n is prime and g is primitive root mod n (primitive mod n)
• Numbers n and g can be public
• 1. A generates random big number x and sends it to B $X=g^{x}mod\: n$
• 2. B generates random big number y and sends it to A $Y=g^{y}mod\: n$
• 3. A calculates $k=Y^{x}mod\: n$ $(g^{y}\, mod\: n)^{x}mod\: n=g^{yx}mod\: n$
• 4. B calculates $k'=X^{y}mod\: n$
• Sessionkey: $k=k'=g^{xy}mod\: n$
• Eavesdropper can only get values n, g, X and Y, which are not enough to calculate k.
• n has to be big number
• Security of the system is based on the discrete logarithm problem for numbers that are size of n.
• n defines the also the size of changed key.
• The size of g has no meaning to security of algorithm
• For better security $(n-1)/2$ should also be prime.
• Example with small numbers:
• Let n be: 5 and it's primitive root g: 2.
• A's random number x is 3 and B's random number y is 2
• $X=2^{3}\: mod\:5=3$
• $Y=2^{2}\: mod\:5=4$
• $k=4^{3}\: mod\:5=4$
• $k'=3^{2}\: mod\:5=4$

## Diffie-Hellman between 3 or more communicating partners

• 1. A generates big random integer x and sends to B $X=g^{x}mod\: n$
• 2. B generates big random integer y and sends to C $Y=g^{y}mod\: n$
• 3. C generates big random integer y and sends to A $Z=g^{z}mod\: n$
• 4. A sends to B $Z'=Z^{x}mod\: n$
• 5. B sends to C $X'=X^{y}mod\: n$
• 6. C sends to A $Y'=Y^{z}mod\: n$
• 7. A calculates: $k=Y'^{x}mod\: n$
• 8. B calculates $k=Z'^{y}mod\: n$
• 9. C calculates $k=X'^{z}mod\: n$
• Session key is $k=g^{xyz}mod\: n$
• More participants can be taken into key exchange by adding rounds to the system.

## Hughes variant of DH

• Allows pregenerated key
• 1. A generates random number x and calculates key $k=g^{x}mod\: n$
• k can be now used to encrypt messages
• 2. B generates big number y and sends to A $Y=g^{y}mod\: n$
• 3. A sends to B $X=Y^{x}mod\: n$
• 4. B calculates $z=y^{-1}$ and $k'=X^{z}mod\: n$
• k'=k so everything works
• The advantage of the Hughes variant is that A can use key k for encryption before making contact to B
• Data that has been encrypted with key k can be exchanged to different parties at different times. (Publish now in web page and exchange the key later)

## Using digital signatures to verify asymmetric keys

• T signs the public keys of A and B
• The keys are signed along with information about the owner of the keys (certificate)
$I_{T},E_{Tprivate}(k_{Apublic},I_{A}),k_{Tpublic}$
where I is Identity information and k is the key
• A and B can verify the validity of keys by verifying the signature of T
• Requires the knowledge about the public key of T.
• The protocol reduces the risks of using T compared to symmetric systems
• M cannot pretend to be A or B, as he don't know their secret keys.
• M cannot change his own key as a key of A or B as his key is signed for M.
• IF KDC is broken into, M can get only the public key of KDC, which can then be used to sign new keys to other identities.
• Previously cerated and used session keys are not compromised like in symmetric model.
• Breaking in have to happen before public key exchange or the communicating partners have to be fooled to redo the key exchange.
• Different Ts can certificate each other to make the life of M harder.

## PKI: Public Key Infrastructure

• PKI tries to answer to the question: How can we be sure that certain public key is the public key of certain entity.
• Connects the public key into unique identity
• person, device, organisation
• Transparency
• Does not require too much from the user

## Basic Operations

• Certification
• Binds key to the identity
• Validation
• Validates the authenticity of the certificate

## Certificate contents

• Public key
• Other information, depending on the certificate system (expiration time etc.)
• All the above mentioned information signed by trusted third party
• The signer is called Certification authority
• The signature states that the signer quarantees this public key belongs to this identity

## Certificate revocation

• Certificate expiration time passees
• Certificatee revocation list
• When secret key corresponding to certified public key is compromised
• Certificate authoritys secret key is compromised

## X.509 (ISO/IEC 9594-8)

• Part of ITU-T X.500 recommendations, that define directory services
• Is used in e.g. S/MIME, SSL/TLS, SET, IPSEC
• Several RFC's exists about the use of X.509
• First version released 1988, v2 1993 and v3 1999 (RFC 2459)
• The first draft of X.509 v3 was released 1995
• Does not depeend on any algorithm, although RSA is recommended for asymmetric cryptography
• Requires use of hash function
• Certificate Revocation List (CRL) for invalid certificates
• contains non expired invaalid certificates
• CA upkeeps the list

## X.509 structure

• Certificate
• Version
• Serial number
• Algorithm ID
• Issuer
• Validity
• Not before
• Not After
• Subject
• Subject public key information
• Public Key Algortihm
• Subject Public k key
• Issuer Unique Identifier (added in v2)
• Subject Unique Identifier (added in v2)
• Extensions (added in v3) can be divided in three different groups
• 1. Key and policy informaation fields (Who and where the key can be used)
• 2. Certificate subject and issuer attributes (aliases and more information about the identity issuer and subject)
• 3. Certification Path Constraints
• Certificate Signature Algorithm
• Certificate Signature

## X.509 certificate validation

• 1. Verification of CA
• going back in certificate tree until trusted CA is found
• 2. validity check
• Is the validation time of certificate started and not expired
• Is the certificate in CRL list
• 3. Verifying the Signature
• NOTE! Certificate validation does not authenticate the certificate sender.
• Certificate is public and anyone can copy it.
• Only the proper owneer of certificate knows the private key corresponding to the certified public key
• In order to authenticate the sender, the sender has to be able to proof he knows the secret key (e.g. challenge-response authentication)

## PGP certificate

• PGP - Pretty Good Privacy
• Used for email
• Is based on user gathered keychains that form webs of trust
• User acts as a CA
• Users share their certificate lists with each other