View page as slide show

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

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

Key and message broadcasting

  • 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

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

PGP Certificate contents

  • 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
Last modified: 2014/02/12 09:38