ECS726: Security and Authentication

Week 5: Cryptographic Protocols,

Key Management
Digital Certificates

Pasquale Malacaria

EECS, QMUL
Table of contents

1. Cryptographic Protocols
Analysing a simple protocol
Authentication and Key Establishment (AKE) protocols

2. Key Management

3. Public key certificates

1
Cryptographic Protocols
protocols?

I We follow protocols in real life: for example when we

are introduced to a new person, we smile, shake
hands (pre-covid protocol), we exchange few words
etc
I individuals follow protocols for weddings, funerals,
graduations etc etc, the state establish diplomatic
protocols, and several protocols are in place for all
sorts of eventuality (chemical/nuclear incidents,
pandemics, etc...)

2
What is a cryptographic protocol?

I A protocol is similar to an algorithm in that it is a

precise description of a procedure and regulations in
a given environment defined by a set of assumption
to achieve a specific goal. Differently than an
algorithm, a protocol involves multiple-parties. A
protocol typically involves exchange of specifically
formatted messages in a specific sequence order
between two or more parties to achieve a clear goal.
I A cryptographic protocol in particular is a
specification of how to apply cryptographic primitives
and in what precise sequence of message-passing
and actions between entities so that a specific set of
security goals are met. 3
Components of a cryptographic protocol

A cryptographic protocol needs to specify its:

B protocol assumptions – any cryptographic
prerequisites concerning the environment in which
the protocol will be run, e.g. possession of
cryptographic keys by the participating entities;
B protocol flow – the sequence of communications
(steps or passes) which need to take place between
the entities involved in the protocol;
B protocol messages – the content of each message
exchanged between entities;
B protocol actions – the details of any actions
(operations) an entity needs to perform after
receiving, or before sending, a protocol message. 4
Components of a cryptographic protocol

Components of a cryptographic protocol

B protocol assumptions – What needs to have

happened before the protocol is run?
B protocol flow – Who sends a message to whom,
and in what order?
B protocol messages – What information is
exchanged at each step?
B protocol actions – What needs to be done between
steps?

5
Cryptographic protocol standards

B Designing secure cryptographic protocol that meet

their specified goals can be surprisingly difficult (as
we will see through an example later).
B So as much as possible, we should use the
cryptographic protocols in standards. For instance:
- The PKCS standards for public-key cryptography.
- ISO/IEC 11770 for mutual entity authentication and
key establishment.
- SSL/TLS for setting up a secure communication
channel (as we see next week).

6
Analysing a simple protocol

In this scenario, we suppose Alice and Bob have access

to a common network. Periodically, at any time of his
choosing, Bob wants to check Alice is still alive and
connected to the network. This is our main security
objective, which we will refer to as a check of liveness
we assume Alice and Bob are two entities in a network
consisting of many such entities, all of whom regularly
check the liveness of one another, perhaps every few
seconds. We thus set a secondary security objective that
whenever Bob receives any confirmation of liveness from
Alice, he should be able to determine precisely which
liveness query she is responding to.
7
Analysing a simple protocol: Notations

typical notations in crypto

A session ID is a unique number that a Web site's server assigns a

specific user for the duration of that user's visit (session).
8
Example Protocol 1

identifier!

9
Example Protocol 1: Analysis

B Protocol 1 analysis
• Data origin authentication of Alice’s reply : MAC
• Freshness of Alice’s reply : nonce
• Assurance Alice’s reply corresponds to Bob’s request
:
1 rB , nonce Bob generated for this run.
2 reply contains the identifier Bob.
• Protocol Assumptions
1 Bob has access to a source of randomness.
2 Alice and Bob already share a symmetric key K.
3 Alice and Bob agree on the use of a strong MAC
algorithm.
Protocol 1 meets the security goals and hence is a
suitable protocol to use in our simple application. 10
Example Protocol 2

11
Example Protocol 2: Analysis

B The analysis of Protocol 2 is the same as for Protocol

1, except for: Data origin authentication of Alice’s
reply: Digital signature
Protocol Assumptions
• Bob has access to a source of randomness. As for
Protocol 1.
• Alice has been issued with a signature key, and Bob
has access to a verification key corresponding to
Alice’s signature key. This is the digital signature
scheme equivalent of the second assumption for
Protocol 1.
• Alice and Bob agree on the use of a strong digital
signature scheme.
Protocol 2 also meets the three security goals. 12
Protocols 1 and 2

which is better? Protocol 1 or Protocol 2?

13
Example Protocol 3

14
Example Protocol 3: reflection attack

B
(reflection attack): to prevent it include identifiers of
recipients in protocol messages

15
Example Protocol 4

Encryption can NOT provide data

origin authentication

16
Protocol 4 analysis

B Protocol Assumptions: identical to Protocol 1, except

that we assume Alice and Bob have agreed on the
use of a strong symmetric encryption algorithm E
(rather than a MAC). Issues:
• Encryption does not, in general, provide data origin
authentication.
• Encryption tends only to be used in this way if
confidentiality of the message data is also required.

17
Example Protocol 5

B a timestamp can serve the same

function as a nonce (as long as a time
stamp is not forgeable)

18
Protocol 5 analysis

B Assumptions: same as protocol 1, except for the

source of randomness being replace by Bob can
generate and verify integrity protected timestamps.
• Data origin authentication of Alice’s reply. As for
Protocol 1.
• Freshness of Alice’s reply. The reply text includes the
timestamp TB which Bob generated at the start of the
protocol.
• Assurance that Alice’s reply corresponds to Bob’s
request: timestamp, identifier Bob.
Hence Protocol 5 meets the three security goals.

19
Protocol 5 analysis

B timestamp TB needs to be integrity-protected, or:

• At 15.00, the attacker sends Alice a liveness check
with TB = 17 : 00
• Alice replies to Bob with TB = 17 : 00
• The attacker intercepts and blocks the reply from
reaching Bob, then stores it.
• The attacker kills Alice.
• At 17.00, Bob sends a genuine request to Alice.
• The attacker intercepts the request and sends back
the previously intercepted reply from Alice.
• Bob accepts the reply and assumes that Alice is OK

20
Example Protocol 6

21
Example Protocol 6

Is protocol 6 correct?

22
Example Protocol 7

B
a session identifier

what is Ta?

23
Example Protocol 7

Is protocol 7 correct?

24
Analysing a simple protocol: Summary

B • There is no one correct way to design a cryptographic

protocol .
• The choice of the most suitable protocol design thus
depends on what assumptions are most suitable for a
given application environment.
• The deficiencies of several of these protocol variants
are very subtle. Given that this application is
artificially simple, the complexity of designing
protocols for more intricate applications should be
clear.
• Designing cryptographic protocols is hard !!

25
AKE

B Authentication and Key Establishment (AKE) protocol

Objectives:
• Mutual entity authentication (Data origin authen. + freshness)
• Establishment of a common symmetric key
AKE protocol goals:
• Mutual entity authentication.
• Mutual data origin authentication.
• Mutual key establishment.
• Key confidentiality.
• Key freshness
• Mutual key confirmation.
• Unbiased key control.

26
Diffie-Hellman
the first protocol

B Diffie-Hellman key agreement protocol

• The basis for majority of modern AKE protocols
based on key agreement
• Designed for environments where secure channels
do not yet exist
• Based on the difficulty of discrete logarithm.

27
Diffie-Hellman

B Diffie-Hellman key agreement protocol

28
Diffie-Hellman

B Diffie-Hellman key agreement protocol (picture)

29
Diffie-Hellman key agreement protocol

B The idea of the protocol is simple:

• Alice and Bob agree on a large prime p and an
integer q < p 1
• Alice choose a secret random n, Bob chooses a
secret random m
• Alice send to Bob N = q n mod p, Bob send to Alice
M = q m mod p
• Alice computes A = M n = q m n mod p, Bob computes
B = N m = q n m mod p
• notice A = B (because x y z = x y∗z = x z y ) hence Alice
and Bob share key A
1
q generator of Z/pZ, cyclic group with p elements
30
Diffie-Hellman toy example

• Alice and Bob agree on the prime p = 23 and integer

q=5
• Alice choose the secret integer 4, Bob chooses the
secret integer 3
• Alice send to Bob 4 = 54 mod 23, Bob send to Alice
10 = 53 mod 23
4
• Alice computes A = 18 = 104 = 53 mod 23, Bob
3
computes B = 18 = 43 = 54 mod 23
3 4
• notice A = B (because 54 = 512 = 53 ) hence Alice
and Bob share key 18

31
Diffie-Hellman toy example: security

the attacker knows p = 23, q = 5, M = 4, N = 10 (but not n and m)

• he also knows that M = 5x mod 23 for some x and

N = 10 = 5y mod 23 for some y
• to get the shared key A(= B) he would need to derive
x (or y)
• if he derives x he can then he can compute
A = 10x mod 23
• if he derives y he can then he can compute
B = 4y mod 23
• to derive x or y is hard when p, q, M, N are large
integers!
32
Diffie-Hellman key agreement protocol

B Diffie-Hellman key agreement protocol. For an

attacker to recover the secret key he should solve
discrete logarithm, which is hard!
• the attacker knows p, q, M = q m mod p, N = q n mod p
but he needs B = N m = q n m mod p
• for this he would need to compute n from
N = q n mod p ( or compute m from M = q m mod p)
• to compute n (or m) is to solve the discrete logarithm
problem.

33
Diffie-Hellman: the man in the middle attack

B An attacker Fred could however impersonates Bob to

Alice and Alice to Bob,
Fred follows Diffie-Hellman and generates two keys:
one to talk to Alice, one to talk to Bob.
once this is done Alice thinks she is talking to Bob but
she is talking to Fred and the similarly for Bob.

34
Diffie-Hellman: man in the middle

35
Diffie-Hellman: man in the middle

B • Alice and Fred end up sharing the key g a∗f

• Alice thinks she is sharing the key g a∗f with Bob
• Bob an Fred end up sharing the key g b∗f
• Bob thinks he is sharing the key g b∗f with Alice
• Fred can now listen, delete and manipulate the
conversation between Alice and Bob

36
Diffie-Hellman: mitigating man in the middle

B How to make Diffie-Hellman works then? use public

key certificates, (also known as a digital certificate)
A public key certificate, includes
• the public key,
• information about the identity of its owner (called the
subject)
• the digital signature of an entity that has verified the
certificate’s contents (called the issuer).
((n,e), "Alice public key", Signed by
Amazon, ...)
the issuer is an authority trusted by all parties

37
Diffie-Hellman: station to station

B variation of Diffie-Hellman to avoid man in the middle:

public parameters q < p (as for D-H)
• Alice sends Bob q m mod p and her certificate CA
• Bob verifies CA and if ok sends Alice
n n m
(from Bob) q mod p||CB ||SigB (Alice||q mod p||q mod p)
• Alice sends Bob SigA (Bob||q m mod p||q n mod p)
• now they both can compute a shared key K = q mn
• they have mutual authentication: Bob knows he is
talking to Alice, Alice know she is talking to Bob.

38
using public key certificates

B now when Alice wants to communicate with Bob to do

Diffie-Hellman AKE (or for any other identification
protocol really) Alice can use public key certificates
• Question: do you still need Diffie-Hellman to create
symmetric keys if you use public key certificates
(which already include keys?)
• you could do without but then all communications
would rely on the public key, by doing a Diffie-Hellman
AKE, even if someone steal the private key of the
public key scheme, he still couldn’t decrypt the
messages encrypted with the Diffie-Hellman keys,
hence one has an additional layer of security.
most cases, it (AKE) is used for one side, like the client
needs to make sure he is connecting to Amazon, but
Amazon doesn’t need to 39
Key Management
Key Management

B • Crucial to the security of any cryptosystem.

• Key management: secure administration of
cryptographic keys.
• Key lifecycle:
• Key generation : the creation of keys.
• Key establishment : the process of making sure keys
reach the end points where they will be used. the
most difficult phase of the key lifecycle to implement.
• Key storage : the safekeeping of keys.
• Key usage : how keys are used.

40
Key length

B • Key length recommendations for symmetric

cryptography tend to be algorithm independent
• Key length recommendations for public key
cryptography tend to be algorithm specific
for symmetric keys for example: a 10 years
protections is estimated to require 112 bits, 20 years
128 bits. 256 bits is estimated to be good for long
term protection including quantum computers.

41
Key hierarchy

B Not all keys are created equal: e.g. some keys are
used to create other shorter terms keys, also a key
guarding a keychain is more valuable than any other
key in the chain... Typically:
• top of the hierarchy are the master keys
• then keys encrypting keys
• then data keys (e.g. generated each time you login at
the bank)

42
Key hierarchy

B Not all keys are created equal: e.g. some keys are
used to create other shorter terms keys, also a key
guarding a keychain is more valuable than any other
key in the chain... Typically:
• top of the hierarchy are the master keys
• then keys encrypting keys
• then data keys (e.g. generated each time you login at
the bank)

43
Keys: A key distribution scenario

B • Consider a simple two level hierarchy consisting of

only master and data keys.
• If we have a network of n users, then the number of
possible pairs of users is n(n − 1)/2, which is the
number of shared master keys. This is not practical
for a network with many users.
• Use a Key Centre (Key Distribution Centre) instead, a
trusted third party.
• Each user in the network shares a master key with
the KC.

Now, we only need n keys (if there are n users)

44
Keys: A key distribution scenario

B So whenever Alice wants to talk to Bob she uses the

Key Distribution Centre to establish a trusted
connection
• Alice ⇒ Key Distribution Centre ⇒ Bob.
• The Key Distribution Centre establishes a shared key
Alice and Bob can use to communicate
• the communication between Alice and Bob can then
either go at each step via the Key Distribution Centre
(translation) or is only between Alice and Bob once
key is established (generation). use D-H key establishment?

45
Key distribution using public key encryption

B we already touched this fundamental question:

How can we be sure of the identity of someone?
We said: Solution: public key certificate.
let’s see more details:

46
Public key certificates
Public key certificates

A public key certificate is data binding a public key to data

relating to the assurance of purpose of this public key. It
can be thought of as a trusted directory entry in a sort of
distributed database.
A public key certificate: ((m,e), subject, issuer, duration, __)

• provides a ‘strong association’ between a public key

and the owner of that key (the entity whose identity is
linked to the public key);
• provides a ‘strong association’ between a public key
and any other relevant data (such as expiry dates
and usage restrictions).

47
Public key certificate

Contents of a Public Key Certificate:

((m,e), subject, issuer, duration, __)
• Name of owner . The name of the owner of the public
key. This owner could be a person, a device, or even
a role within an organisation.
• Public key value . The public key itself.
• Validity time period . This identifies the date and time
from which the public key is valid and, more
importantly, the date and time of its expiry.
• Signature . The creator of the public key certificate
digitally signs all the data that forms the public key
certificate, including the name of owner, public key
value, and validity time period.
• And more? ( X.509: public key certificate standard) 48
Certificate authority

public key certificate are issued by a Certificate authority

(CA). The CA role: is

• Certificate creation : creating and signing the public

key certificate, and then issuing it to the owner.
• Certificate revocation . The CA is responsible for
revoking the certificate in the event that it becomes
invalid.
• Certificate trust anchor . The CA acts as the point of
trust for any party relying on the correctness of the
information contained in the public key certificate.

49
chain of trust

A certificate chain is a list of one or more CA certificates

(usually the last one being a self-signed certificate), with
the following properties:
• The Issuer of each certificate (except the last one)
matches the Subject of the next certificate in the list
• Each certificate (except the last one) is signed by the
secret key corresponding to the next certificate in the
chain (i.e. the signature of one certificate can be
verified using the public key contained in the following
certificate)
• The last certificate in the list is a trust anchor: a
certificate that you trust because it was delivered to
you by some trustworthy procedure 50
certificates: example

You can check certificates for a website by clicking on the

lock symbol next to https. For qmplus.qmul.ac.uk you will
see:

• CA list is: Amazon, Amazon Root CA 1

• qmplus is signed by Amazon with SHA-256 with RSA
Encryption (you can see the RSA public key in the
certificate)
• you can see information for the other elements in the
chain

51
self-signed certificates

“anyone” can in principle create a certificate not signed by

a CA, this is a self-signed certificate
A self-signed certificate

• doesn’t provide any trust value

• for example if a website uses a self-signed certificate
(e.g. to provide HTTPS services), visitors to that
website may not be connected to their intended
destination...

52
certificates

To get a “proper” certificate one should

• register with a registration authority RA who will do

due diligence, e.g. the company exists etc...
• then (pay to) get a certificate from a recognised CA
• RA and CA may be the same company (but they are
different roles)

53
 Questions?
Next week: Example Applications of
Cryptography.

53