Pekka Jäppinen

- 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 a symmetric key ca be done in two ways
- 1. Generating key before key exchange
- Generate a random number that is between values - , where n is the size of required key
- 64 - bit key = 64 zeroes and ones in a row → integer number .

- The value has to be real random value.
- Bad implementation

- 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.

- Key exchange with symmetric cryptography
- Trusted third party T has a symmetric key for communication with both A and B (keys and )

- 1. A connects to T and requests session key () to communicate with B
- 2. T generates session key and makes two copies of it. T encrypts one copy with and other with and sends the copies to A
- 3. A decrypts the session key ( )
- 4. A sends to B the messages containing session key that was encrypted with key
- 5. B decrypts the key
- 6. A and B can now communicate securely with using the key

- 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

- 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 ,to be used for communication with B and encrypts it with another random key

- 2. A sends the encrypted key to B
- 3. B encrypts the message from A with his own random key and sends the message back to A

- 4. A decrypts the message with her own key and sends it back to B

- 5. B decrypts the message with his own key and has now the session key

- 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 as a result. XOR:ing with third messages gives key

- 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 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

- T signs the public keys of A and B
- The keys are signed along with information about the owner of the keys (certificate)

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.

- 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

- 2. A fetches the public key of B
- 3. A encrypts K with the public key of B

- 4. A sends both the encrypted message and encrypted session key to B (secured envelope)

- 5. B decrypts the session key sent by A

- 6. B decrypts the message using the session key

- For additional security A signs the whole message
- B can verify the signature

- 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.

- 2. A fetches the public keys of B, c and D.
- 3. A encrypts k with the public keys of B,C and D

- 4. A Broadcasts encrypted messages and all the encrypted keys

- 5. Only B,C and D can decrypt the key using their secret key and then decrypt the message M.

- 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
- 2. B generates random big number y and sends it to A
- 3. A calculates
- 4. B calculates
- Sessionkey:
- 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 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

- 1. A generates big random integer x and sends to B
- 2. B generates big random integer y and sends to C
- 3. C generates big random integer y and sends to A
- 4. A sends to B
- 5. B sends to C
- 6. C sends to A
- 7. A calculates:
- 8. B calculates
- 9. C calculates
- Session key is
- More participants can be taken into key exchange by adding rounds to the system.

- Allows pregenerated key
- 1. A generates random number x and calculates key
- k can be now used to encrypt messages

- 2. B generates big number y and sends to A
- 3. A sends to B
- 4. B calculates and
- 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)

- T signs the public keys of A and B
- The keys are signed along with information about the owner of the keys (certificate)

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 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

- Certification
- Binds key to the identity

- Validation
- Validates the authenticity of the certificate

- Individualising information about identity
- username, device address/ ip address, company name

- 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 expiration time passees
- Certificatee revocation list
- When secret key corresponding to certified public key is compromised
- Certificate authoritys secret key is compromised

- 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

- 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

- 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 - 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

- Email address
- public key
- Level of trust
- PGP defines level of trust value for each key.
- The higher the value on ID and key the more trusted is the link between identity and publickey
- The longer the certificate chain the smalled is the trust value

- No validity time for certificate
- User decides the validity

- No CRL lists