Computer Security- lec 5

Lecture 5 notes

Forward Secrecy- the secrecy of past key sessions must not depend on the secrecy of long-term shared keys

So if a server were to be compromised then the leak of the private key wouldn’t impact upon current communications using existing keys

Think heartbleed bug!

Perfect forward secrecy-

Each session has a secret key

Long term key used

Long term key not linked to session keys

Compromise will not impact

Example:

A sends a message to B which includes a K and then the public key of B

B sends back an encrypted message and the key

A sends B an encrypted message with same key

So lets say key is X and public key of b is Y

A sends X which is encrypted by Y

B sends back a message, encrypted with X- can see X as can unlock Y

A then sends a message with X

But the intruder could record A’s message, B’s message and A’s second message and then use the compromised private key to unlock K and therefore have access to everything

TO avoid this- use the Diffie-Hellman based key establishment

A has secret number a

B has secret number B

Both have pre-known numbers p and g

Use the following to agree on a shared secret key:

K = (pa mod g)b mod g = (pb mod g)a mod g

Notice that (P to the power of A mod G)times B

Ans                      (P to the power of B mod G) times A

So both secret numbers generate they key

But only A knows a and only B knows b

Example from lecture slide

So can see A encryptes with it to the power of Pa- signes it keyAB

B does same but to power of B

A then encrypts to power of b mod A

B does opposite

Compromising the keyab wont get the session key

A bit easier to understand is this:

So A sends a temp session key and encrypts with KeyAB

B then encrypts a message with KeyAB sending the new Kab generated by public temporary key

They then use new Kab for the session

So what did heartbleed do

Exploitation of a vulnerability

Queries the server, realizing it can ask for more than it should be able to

Could ask for example-

Info which has 4 content blocks

But exploitation meant you could request info with 25 blocks

As 4 are filled, the remaining come from other data to fill the blocks

So the remaining would sometimes contain keys

In essence- the server says, oh info takes up 4 but I’ve been asked for 25, so I’ll just use some information to fill the other 21

Plenty of other methods of forward secrecy that I need to look at !

CSEC Tutorial: Perfect Forward Secrecy

For the following protocol, where A and B share some prime number α, and where x is known only to A and y is known only to B, and where K = αxy = αyx:

A -> B: αx

B -> A: αy, encrypt(sign((αy, αx),KprB),K)

A -> B: encrypt(sign((αx, αy),KprA),K)

Demonstrate how this protocol exhibits the following two properties:

1. Perfect forward secrecy: if the private keys of either Alice or Bob are compromised, this will not affect the secrecy of short-term session keys K exchanged in sessions previous to the compromise time.
2. 2-way authentication.

1) The protocol exhibits perfect forward as A is B makes the encryption with Ay and Ax, which gives the K key

this is perfect as compromising won’t give previous key information

this is because x and y change with each protocol so therefore the calculation is different each time

e.g A may use the number 2 and B the number 3 and protocol is 6

but next time A uses 4 and B uses 3 so key is 12

but there is no link between number choices so therefore compromising one does not mean the other could be

kpra cannot work out the keys

On the other hand, consider the following two variants of the protocol:

Variant 1:

A -> B: αx

B -> A: αy, sign((αy, αx),KprB)

A -> B: sign((αx, αy),KprA)

original:

A -> B: αx

B -> A: αy, encrypt(sign((αy, αx),KprB),K)

A -> B: encrypt(sign((αx, αy),KprA),K)

Variant 2:

A -> B: αx

B -> A: αy, encrypt(sign(αy,KprB),K)

A -> B: encrypt(sign(αx,KprA),K)

Consider what a malicious attacker, Carol (C) could do to interfere with these two variants.  Discuss what the effects of such interference would be on the security of these protocols.

Variant 1- no encryption of the keys, so Carol just has to listen in and will then have the keys necessary to generate the session key

variant 2-what changes?

B does not send A Ax and as such A does not send the encryption with both ax and Ay

instead only sends ax which can only be worked out with knowing x, so only B knows?

SO has B send the key that is just using Ay, in which case all Carol needs to know is Ay

Carol could interfere with this by listening to ax

A never signed with Ay- can you prove A is actually A?

georgeryan@dfl-25:~/compseclab5$ openssl enc -d -kfile symkey.key -in kpbtempenc.txt -out kpbtemdec.txt

CSEC Practical Problem: Proving PFS in OpenSSL

Explore the files contained in the folder “T4Files.zip” on Moodle.  These represent three sessions of an authentication protocol, as well as a compromised long-term symmetric key.

Convince yourself, using OpenSSL operations, that the only symmetric key you can see is the compromised key included in the above folder, and that in particular, you cannot unlock any other (previously established) short-term symmetric session keys.

Can you guess what the Alice/Bob specification of the authentication protocol is?

Explored files-

there is finalenc.txt

final2enc.txt  finalenc.txt     kpbtemp3enc.txt  symkey.key

final3enc.txt  kpbtemp2enc.txt  kpbtempenc.txt   T4Files

encs are all encrypted docs

sym is a key that is just random text

same with the temps

so the sym key is the symmetric session key

was given this

unable to load Private Key

140482776901272:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: ANY PRIVATE KEY

Rsautl -decrypt -inkey file 1private.pem -in filename ME.txt

openssl rsautl -decrypt -in MMMMMME.txt -out T5.txt -inkey 3private.pem