Chapter 4

Cryptographic Protocols

Information Security/System Security – p. 101/617

 Introduction
Just having a high-tech cryptosystem in place does not
guarantee security
Cryptography has to be used in a certain way to
achieve security

Information Security/System Security – p. 102/617

 Introduction (2)
That’s where cryptographic protocols come into play
A protocol is a
series of steps
involving two or more parties
designed to accomplish a task

Information Security/System Security – p. 103/617

 Protocols
Series of steps:
Each step must be well-defined
There must be specified action for every possible
situation
Everyone involved must know the steps and follow
them
Two or more parties:
Parties can be friends and trust each other or
adversaries and mistrust each other
Accomplish a task:
This can involve sharing (parts of) a secret,
confirming an identity, signing a contract, etc.

Information Security/System Security – p. 104/617

 Dramatis Personae
In order to simplify scenarios, over time the following
cast has evolved:
Alice: 1st participant
Bob: 2nd participant
Carol, Dave: more participants for multi-party
protocols
Eve: Eavesdropper
Mallory: malicious active attacker
Trent: trusted arbitrator

Information Security/System Security – p. 105/617

Dramatis Personae (2)

Information Security/System Security – p. 106/617

 Arbitrated Protocols
An arbitrator is a disinterested third party trusted to
complete the protocol
Has no allegiance to any party involved
All people participating trust that he is acting
honestly and correctly
Arbitrators can help complete protocols between parties
that don’t trust each other

Trent

Alice Bob

Information Security/System Security – p. 107/617

 Arbitrated Protocols (2)
In the real world, lawyers, public notaries, and banks
act as arbitrators
For example, Bob can buy a car from Alice using an
arbitrated protocol
1. Bob writes a check and gives it to the bank (Trent)
2. Bank puts enough money on hold to cover check
and certifies the check
3. Alice gives the title to Bob and Bob gives the
certified check to Alice
4. Alice deposits the check
This works, because Alice trusts the bank’s certification

Information Security/System Security – p. 108/617

 Arbitrated Protocols (3)
There are some problems with arbitrated protocols in
the virtual world:
It’s more difficult for people to trust a faceless entity
somewhere in the network
An arbitrator can become a bottleneck, as he has to
deal with every transaction
This may lead to even more delay (due to the
arbitrator there’s always some delay)
Lots of damage can be caused if arbitrator is
subverted
Someone has to pay for running an arbitration
service

Information Security/System Security – p. 109/617

 Adjudicated Protocols
Arbitrators have high costs, so arbitrated protocols can
be split into two sub-protocols:
A non-arbitrated part
An arbitrated part that is executed only if there is a
dispute
This special kind of arbitrator is called an adjudicator

Trent

evidence evidence
Alice Bob
Information Security/System Security – p. 110/617
 Adjudicated Protocols (2)
In the real world, judges are professional adjudicators
Alice and Bob can enter a contract without a judge; a
judge only sees the contract if it is brought before a
court
1. Alice and Bob negotiate the terms of the contract
2. Alice signs the contract
3. Bob signs the contract
The following is only executed in case of a dispute:
4. Alice and Bob appear before a judge
5. Alice presents her evidence
6. Bob presents his evidence
7. The judge rules on the evidence

Information Security/System Security – p. 111/617

 Adjudicated Protocols (3)
Issues with adjudicated protocols in the virtual world
Protocols rely in a first instance on the parties being
honest
However, if someone suspects cheating, the protocol
provides enough evidence to be able to detect this
In a good adjudicated protocol, this evidence also
identifies the cheating party
Instead of preventing cheating, adjudicated protocols
detect cheating
The (inevitability of) detection acts as a deterrent

Information Security/System Security – p. 112/617

 Self-Enforcing Protocols
A self-enforcing protocol does not need an arbitrator or
adjudicator
The protocol itself guarantees fairness
If one party tries to cheat, the other party is able to
detect this immediately
The protocol then stops and/or punishes the cheating
party

Alice Bob

Information Security/System Security – p. 113/617

 Self-Enforcing Protocols (2)
A well-known self-enforcing protocol is for dividing up
things, e.g. a cake
1. Alice divides up the piece of cake
2. Bob chooses which piece to take
Ideally, it would be nice to have self-enforcing protocols
for every possible situation
Unfortunately, that’s not possible

Information Security/System Security – p. 114/617

 Basic Cryptographic Protocols
In the following we’re going to have a look at some
basic protocols involving cryptography
These cover a range of different applications:
Communicating securely
Signing documents
Authenticating users
Exchanging keys
We will also have a look at potential weaknesses of
these protocols

Information Security/System Security – p. 115/617

Symmetric Crypto Communication
An obvious application is secure communication by
encrypting messages
Using symmetric cryptography, a protocol could look
like this:
1. Alice and Bob agree on a cryptosystem
2. Alice and Bob agree on a key
3. Alice encrypts her plaintext message using the
above cryptosystem and key
4. Alice sends ciphertext to Bob
5. Bob decrypts ciphertext using the above
cryptosystem and key

Information Security/System Security – p. 116/617

Symmetric Crypto Communication (2)
What are some of the problems of this protocol?
Step 2 has to take place in secret (Step 1 and 4 can
take place in public)
Assuming that Alice and Bob use a cryptosystem
in which all security relies on the key (not the
algorithm)
For world-spanning communication, this is
problematic

Information Security/System Security – p. 117/617

Symmetric Crypto Communication (3)
Problems involving compromised secrecy
If the key is compromised (stolen, guessed, extorted,
bribed, etc.), then
Eve can decrypt all messages encrypted with that
key
Mallory could intercept messages and send his
own, pretending to be Alice or Bob
This protocol assumes that Alice and Bob trust each
other:
Either one could claim that the key has been
compromised and publish the communication
anonymously

Information Security/System Security – p. 118/617

Symmetric Crypto Communication (4)
Yet another problem is key management:
If each pair of users in a network have their own key
then the total number of keys increases rapidly
with the number of users
For example, 10 users require 45 different keys;
100 users require 4950 keys
Sharing keys among users is not a solution:
If someone leaves the network or is not trusted
anymore, all users sharing keys with that person
have to change their keys

Information Security/System Security – p. 119/617

Asymmetric Crypto Communication
Let’s have a look at how this communication works with
a public-key cryptosystem
1. Alice and Bob agree on a public-key cryptosystem
2. Bob sends Alice his public key
3. Alice encrypts her plaintext message using Bob’s
public key
4. Alice sends ciphertext to Bob
5. Bob decrypts ciphertext using his private key

Information Security/System Security – p. 120/617

Asymmetric Crypto Communication (2)
What has changed?
The key exchange does not have to take place in
secret anymore
Even if Eve listens in on step 2 and 4, she only has
the public key and the ciphertext
This will not help her in recovering the private key
or the plaintext
Everyone who wants to communicate with Bob uses
Bob’s public key
There’s no need to have a separate key for each
pair of users

Information Security/System Security – p. 121/617

Asymmetric Crypto Communication (3)
So, everything is fine now?
Unfortunately, no. . . Enter Mallory (who is more
powerful than Eve)
In step 2, Mallory intercepts Bob’s public key and
sends his own to Alice
Alice encrypts her message using Mallory’s public
key (thinking it’s Bob’s) and sends it to Bob
On the way back Mallory intercepts Alice’s
ciphertext, decrypts it, encrypts it with Bob’s public
key, then sends it to Bob
Mallory could even change the message
Alice and Bob think they have a secure connection
This is called a man-in-the-middle attack (we’ll come
back to it later)
Information Security/System Security – p. 122/617
 Hybrid Cryptosystems
At first glance it seems a public-key algorithm is always
better than a symmetric algorithm
So why not use public-key all the time?
Public-key algorithms are much slower than most
symmetric algorithms
Public-key algorithms are vulnerable to
chosen-plaintext attacks:
If there are only a few possible messages, then it’s
possible to recover the plaintext (although not the
private key)
Encrypt all possible messages with the public key
If one of the generated ciphertexts matches the
message ciphertext, then you know what was sent

Information Security/System Security – p. 123/617

 Hybrid Cryptosystems (2)
It’s possible to combine a symmetric algorithm with a
public-key algorithm in a protocol
1. Alice and Bob agree on a public-key cryptosystem
and a symmetric cryptosystem
2. Bob sends Alice his public key
3. Alice generates a random session key for the
symmetric algorithm
4. She encrypts the session key using Bob’s public key
5. Alice sends ciphertext to Bob
6. Bob decrypts ciphertext using his private key to
recover the session key
7. Alice and Bob can now continue with the symmetric
algorithm

Information Security/System Security – p. 124/617

 Hybrid Cryptosystems (3)
Using public-key cryptography for distributing a key
improves key management
The key exchange can take place in public, even
though a symmetric algorithm is used for the bulk of
communication
The session key is only used for a limited time and
then destroyed
The longer a key sits around, the higher the
chances that it is vulnerable to compromise
The public-key cryptosystem is only used very
sporadically, generating a very small number of
ciphertexts
The less data, the harder it is to break a code

Information Security/System Security – p. 125/617

 Digital Signatures
Cryptography’s use is not limited to securing
communication
It’s possible to sign electronic documents using a digital
signature
Attaching/embedding a (graphical image of a) signature
to a document is not helping
It would be too easy to manipulate computer files and
cut and paste signatures

Information Security/System Security – p. 126/617

Symmetric Cryptosystem Signatures
Alice wants to sign a digital message and sent it to Bob
Possible with the help of Trent, who shares a secret key
KA with Alice and a secret key KB with Bob
1. Alice encrypts her message to Bob with KA
2. Alice sends the ciphertext to Trent
3. Trent decrypts the message with KA
4. Trent takes the message, adds a confirmation that it
is from Alice, encrypts it with KB
5. Trent sends this bundle to Bob
6. Bob decrypts it with KB (to read the message and
Trent’s confirmation)

Information Security/System Security – p. 127/617

Symmetric Cryptosystem Signatures (2)
Proving to a third person, e.g. Carol, that a message is
from Alice would involve Trent again:
1. Bob encrypts Alice’s message and Trent’s
confirmation with KB
2. Bob sends the ciphertext to Trent
3. Trent decrypts the message/confirmation with KB
4. Trent checks that the message is indeed Alice’s
5. If this is the case, Trent takes the message, adds a
confirmation that it is from Alice, encrypts it with KC
6. Trent sends this bundle to Carol
7. Carol decrypts it with KC (to read the message and
Trent’s confirmation)

Information Security/System Security – p. 128/617

Symmetric Cryptosystem Signatures (3)
In theory, this is a secure way of signing documents
If someone tried to “transfer” a signature to a different
document, Trent would notice it
However, there are some problems in practice:
Trent needs to store all messages that he confirmed
(to be able to check validity of a signature)
Every transaction has to go through Trent, he would
quickly become a bottleneck
Trent has to be a trusted entity and he has to be
infallible
If he makes a mistake, this would undermine other
people’s trust in him

Information Security/System Security – p. 129/617

Public-Key Cryptosystem Signatures
There are better ways for digitally signing a document
Many public-key algorithms (including RSA) can be
used for this
This is based on the fact that the private key can also
be used for encrypting messages
The public key is then used for decrypting it again
1. Alice encrypts the document with her private key
2. Alice sends ciphertext to Bob
3. Bob decrypts the ciphertext using Alice’s public key

Information Security/System Security – p. 130/617

Public-Key Cryptosystem Signatures (2)
Why does this work?
Bob can verify that the signature is authentic (by
decrypting message correctly with public key)
The signature cannot be forged, only Alice knows
her private key
The signature is not reusable (cannot be extracted
from document and attached to another)
The signed document cannot be changed (any
change of the ciphertext would lead to gibberish
when applying public key)
There is a variant of RSA, called DSA (Digital Signature
Algorithm), which can only be used for signatures (not
encryption)

Information Security/System Security – p. 131/617

Public-Key Cryptosystem Signatures (3)
Possible problems with this protocol:
Works fine if nothing is gained from having another
copy of the document
Things change if it is, e.g. a signed digital check
Bob could take the check to a bank, which verifies
Alice’s signature and transfers the money
However, Bob could keep a copy of the check and
take it to another bank later
Consequently, digital signatures often include
timestamps, i.e. current date and time is added to
document before signing
The bank can then compare the timestamp with a
list of stored timestamps of used checks

Information Security/System Security – p. 132/617

Public-Key Cryptosystem Signatures (4)
Non-repudiation is still a problem:
Alice can sign a document and later claim that she
did not
She can claim that her key was compromised (she
lost it, someone stole it) and someone else is
pretending to be her
There has been a discussion about tamper-resistant
modules
Prevents Alice from accessing her own private key
and accidentally “losing” it
If you need non-repudiation, then you have to fall
back on an arbitrated protocol

Information Security/System Security – p. 133/617

 Arbitrated Non-Repudiation
1. Alice signs her message
2. Alice generates a header (containing some identifying
information)
3. She concatenates header + signed message and signs
this again, then sends it to Trent
4. Trent verifies Alice’s signature and confirms the header
and adds a timestamp to the header + message
5. Trent signs this bundle of information with his own
signature and sends it to both, Alice and Bob
6. Bob verifies Trent’s signature, the header, and Alice’s
signature
7. Alice verifies Trent’s message and confirms, if it did not
originate from her she raises an alarm
Information Security/System Security – p. 134/617
Digital Signatures and Encryption
Digital signatures can be combined with encryption:
1. Alice signs a message with her private key
2. Alice encrypts the signed message with Bob’s public
key
3. Alice sends ciphertext to Bob
4. Bob decrypts ciphertext with his private key
5. Bob verifies with Alice’s public key and recovers
message

Information Security/System Security – p. 135/617

 Key Exchange
Diffie-Hellman was the first public key exchange
protocol (1976)
Alice and Bob can generate a secret key with this
They are not actually sharing a key (they are
creating one)
Necessary communication can take place in public
At the end, they both have the same secret key

Information Security/System Security – p. 136/617

 Key Exchange (2)
Step-by-step protocol:
1. Alice and Bob agree on two prime numbers n and g
(these numbers can be exchanged in public)
2. Alice chooses large random integer x, sends Bob
X = g x mod n
3. Bob chooses large random integer y , sends Alice
Y = g y mod n
4. Alice computes k = Y x mod n
5. Bob computes k ′ = X y mod n
Both, k and k ′ are equal to g xy mod n
Alice and Bob now have a secret key k

Information Security/System Security – p. 137/617

Visualization

Information Security/System Security – p. 138/617

 Key Exchange (3)
Someone listening in on the communication only knows
n, g , X , and Y
Solving discrete logarithms for large numbers is hard
Some caveats:
n should be really large, security is based on
difficulty of factoring numbers of the size of n
(n − 1)/2 should also be a prime
g can be any size, but should be primitive modulo n:
Every number coprime to n can be generated as a
power of g modulo n

Information Security/System Security – p. 139/617

 Key Exchange (4)
Protocol can be extended to work with three or more
parties
However, you have to generate a key with everyone you
want to communicate with
RSA public-key is more convenient in that respect
Nevertheless, there are still issues

Information Security/System Security – p. 140/617

 Key Exchange (5)
We still have an open problem:
How can we safely transmit a (public) key, so that we
can be sure it belongs to whom we think it belongs?
One solution is to have a secure database:
Anyone may read the content and access a public
key
Only Trent is allowed write-access to the database
To make sure that keys are not substituted during
transmission, Trent can sign the keys, users can
verify Trent’s signature
Users of the database just have to make sure
(once) that they have received the correct public
key of Trent

Information Security/System Security – p. 141/617

 Key Exchange (6)
In this scenario Trent is called a Key Certification
Authority (CA) or Key Distribution Center (KDC)
A large and well-known CA is VeriSign
Usually a CA signs a compound message called a
certificate containing information about the holder of a
public key
When you apply for a certificate with a CA, they check
your identity before issuing the certificate

Information Security/System Security – p. 142/617

 Certificates
A certificate contains the following fields:
Issuer: identity of the issuer (the CA)
Subject: identity of the owner of the public key
Public key: the public key of the subject
Dates valid: the time period for which the certificate
is valid
Type: there are different classes of certificates
Depends on the rigor with which identity check is
done
Serial number
Fingerprint: a one-way hash function of previous
data (more about these functions on next slide)
Signature: fingerprint signed by issuer
Information Security/System Security – p. 143/617
 One-Way Hash Functions
A one-way hash function is also known under different
names: message digest, fingerprint, (cryptographic)
checksum, message integrity check, manipulation
detection code
A hash function is a function that takes a variable-length
input string (called pre-image) and converts it to a
fixed-length (generally smaller) output string (called
hash value)
A simple example is a function that takes the
pre-image and returns a byte consisting of the XOR
(exclusive-or) of all input bytes
Can be used as a quick check if two pre-images are the
same: same pre-images have the same hash value

Information Security/System Security – p. 144/617

 One-Way Hash Functions (2)
A one-way hash functions is a hash function that works
in one direction
It’s easy to compute a hash value from a pre-image,
but it is hard to generate a pre-image that hashes to
a particular value
The aforementioned XOR function is not one-way
(given a hash-value, it’s easy to figure out a
pre-image that will generate it)
A good one-way hash function is also collision-free: it’s
hard to generate two pre-images with the same hash
value
The hash function is public, the security lies in its
one-wayness: it is computationally infeasible to find a
pre-image hashing to a particular hash value
Information Security/System Security – p. 145/617
 One-Way Hash Functions (3)
If you want to verify that someone has a particular file
(without sending the file itself), ask for its hash value
If they send you the correct hash value, then it is almost
certain that they have that file
Can also be used to verify data transmission via an
unreliable channel
Send message and its hash value, if they don’t
match, something has gone wrong
MD5 is a widely used one-way hash function (however,
MD5 seems to have a weakness concerning
collision-resistance)
SHA-2 is a safer bet in terms of security

Information Security/System Security – p. 146/617

 Signing Fingerprints
Instead of signing documents directly, often the
fingerprint is signed
This is done due to efficiency reasons, signing a
fingerprint is quicker
If someone manipulates the original document this can
be found out quickly:
The result of applying the one-way hash function to
the document and the signed fingerprint don’t match!

Information Security/System Security – p. 147/617

 Certificate Chains
If an organization wants its members to have a
certificate, it usually doesn’t get them individually
It obtains an organization-wide certificate from a CA
and then creates and signs a certificate for each
member
So we have a chain of certificates:
Member → Organization → CA

Information Security/System Security – p. 148/617

 Checking Certificates
If you want to check a certificate, you would
1. apply the issuer’s public key to the signed fingerprint,
decrypting it
2. and compare the decrypted fingerprint with the
provided fingerprint
3. optionally create the fingerprint of the certificate
using the one-way hash function and compare it, too
to verify that certificate hasn’t been tampered with
In case of a chain, you then need to verify the certificate
of the issuer
Now we have a problem. . .
Who signs the CA’s certificate?

Information Security/System Security – p. 149/617

 Checking the CA’s Certificate
A CA’s certificate is self-signed, i.e. the issuer and the
subject are identical
If Mallory approached you with his certificate signed by
VeriSign and he also provided VeriSign’s certificate,
would you trust him?
Probably not, anyone can create a self-signed
certificate
One solution for a CA is to widely publicize the
fingerprint of their own certificate
It’s not possible to cheat if everyone knows how a
CA’s certificate must look like
One more thing: there are Certificate Revocation Lists
(CRLs), as certificates can be invalidated
Information Security/System Security – p. 150/617
 Web Browsers and Certificates
Browsers are usually shipped with a number of
self-signed certificates already installed
These are certificates that the vendor (has verified) and
trusts
So if you trust the vendor, you can trust the installed
certificates
Nevertheless, a browser lets you
view installed certificates
install certificates yourself
specify whether you trust a certain certificate
Caveat: a browser does not necessarily check whether
a certificate has been revoked

Information Security/System Security – p. 151/617

 Security
There’s never 100% security, but in order to subvert a
key exchange involving a trusted third party Mallory
would have to
Replace Alice’s copy of the KDC public key
Corrupt the database: replace his own keys for the
valid keys and sign with his private key
Unfortunately, using a KDC (or CA) is an arbitrated
protocol
Can we cut out the man-in-the-middle attack with a
self-enforcing protocol?
This can be done using an interlock protocol

Information Security/System Security – p. 152/617

 Interlock Protocol
The interlock protocol has a good chance of foiling a
man-in-the-middle attack:
1. Alice sends Bob her public key
2. Bob sends Alice his public key
3. Alice encrypts message using Bob’s public key, she
sends half of the encrypted message to Bob
4. Bob encrypts message using Alice’s public key, he
sends half of the encrypted message to Alice
5. Alice sends the other half to Bob
6. Bob sends the other half to Alice
7. Alice puts the two halves together and decrypts them
8. Bob puts the two halves together and decrypts them

Information Security/System Security – p. 153/617

 Interlock Protocol (2)
The important point is that half of the message is
useless without the other half (that it cannot be
decrypted)
If the encryption is a block algorithm, half of each
block (e.g. every second bit) could be sent
Mallory can still substitute his key for Alice’s and Bob’s
in steps 1 and 2
However, when he intercepts Alice’s message in step 3,
he cannot decrypt it with his own private key and
re-encrypt it with Bob’s public key
He must invent a completely new message and send
half of it to Bob
Mallory has the same problem in step 4
Information Security/System Security – p. 154/617
 Interlock Protocol (3)
By the time he intercepts the second halves in steps 5
and 6, it’s too late to change the invented messages
Alice and Bob won’t send the second half of their
messages until they have received the first part from
the other person
The conversation between Alice and Bob will turn out to
be very different
Mallory has a chance of getting away with it, if he is
able to mimic Alice and Bob closely enough
However, that is much harder to do than intercepting
and reading messages

Information Security/System Security – p. 155/617

 Authentication
Another important area of cryptographic protocols is
authentication
When Alice logs into a computer (or ATM, or telephone
banking system, or any other system) how does the
host know who she is?

Information Security/System Security – p. 156/617

 Authentication (2)
Traditionally passwords are used for this
Alice enters her password and the host confirms that it
is correct
Both Alice and the host know a secret piece of
knowledge, which the hosts requests every time Alice
logs in

Information Security/System Security – p. 157/617

 Authentication (3)
The host does not actually have to know the password
(i.e. store it in cleartext)
That’s why sysadmins often cannot tell you your
password, they don’t have it (they can only reset it)
It just has to be able to differentiate valid passwords
from invalid ones
This can be done using one-way hash functions

Information Security/System Security – p. 158/617

Authentication Using Hash Values
Instead of storing passwords, a host stores one-way
hash values of the passwords
1. Alice sends the host her password
2. The host performs a one-way hash function on the
password
3. Host compares the result to the stored value
If someone breaks into the host, they cannot steal the
passwords
The one-way hash function cannot be reversed to
obtain the passwords

Information Security/System Security – p. 159/617

 Dictionary Attacks
A file of passwords encrypted with a one-way function is
still vulnerable
Mallory can take a list of the most popular passwords
and a dictionary and run it through the one-way hash
function
Usually each term is used in different variations (e.g.
concatenating numbers, using it backwards)
After stealing the password file, he can then compare
the password list with the generated hash values to find
matches
This is surprisingly successful, as many passwords are
chosen poorly

Information Security/System Security – p. 160/617

 Password Eavesdropping
So far, so good; however, we still have a serious
problem: what happens if Eve listens in on Alice’s
communication with the host?
Eve can intercept the password anywhere on the
network or on the host before it is hashed
For example, early electronic locks (e.g. remote
control garage door openers, car locks) sent their
serial number in the clear
This was very insecure, anyone able to listen in and
record the signal was able to open a door

Information Security/System Security – p. 161/617

Authentication with Public-Keys
Public-key cryptography can help solve this problem
The host keeps a file of every user’s public key, all users
keep their private key
This is how the (straightforward) protocol works:
1. The host sends Alice a random string
2. Alice encrypts the string with her private key and
sends it back (along with her name)
3. The host looks up Alice’s public key and decrypts the
message with it
4. If the decrypted string matches what the host
originally sent, then access is granted

Information Security/System Security – p. 162/617

Authentication with Public-Keys (2)
This protocol is also called challenge-response
The host sends out a challenge (a random number) to
which the Alice has to respond in the correct way
The response proves that Alice is in possession of her
private key
Important: the private key is never transmitted, only
encrypted messages
However, there are still weaknesses:
The plaintext and its ciphertext are transmitted
If random numbers issued by the host are not truly
random

Information Security/System Security – p. 163/617

Authentication with Public-Keys (3)
Plaintext/ciphertext:
Having access to (a large number of) plaintexts and
corresponding ciphertexts makes the job of a
cryptanalyst easier
Eve could listen in on Alice’s authentication attempts
to obtain information to deduce private key
Random numbers:
Mallory (knowing the sequence of future random
number) could intercept host’s challenge
Mallory forwards one of the future random numbers,
gets it encrypted by Alice; Alice’s login will fail
However, Mallory now has a correct response to a
future challenge

Information Security/System Security – p. 164/617

 Improved Protocol
Random number generator has to be implemented very
carefully
To avoid the other weakness, use the following protocol:
1. Alice performs a computation on her private key and
random number(s) and sends result to host
2. The host sends Alice a different random number
3. Alice performs a computation on her private key, her
and the host’s random numbers and sends result to
host
4. The host does some computation on the results
received by Alice and her public key to verify she
knows the private key
5. If the outcome is correct, access is granted

Information Security/System Security – p. 165/617

 Improved Protocol (2)
Step 1 might seem unnecessary, but is required to
prevent certain attacks against the protocol
Basically, Alice proves to the host, that she knows her
private key without
giving away any information on her private key
actually encrypting plaintext with her private key
The weaknesses of the original protocol are also a
good reason to
not sign just any random document with your private
key (it could have been sent by Mallory)
first sign a document, and then encrypt it

Information Security/System Security – p. 166/617

 Real-World Protocols
Let us now have a look at some protocols that are used
in real applications
Smartcard-based banking
We are going to have a look at a range of different
protocols used for banking
Kerberos
This is a trusted third-party authentication protocol
designed for TCP/IP networks
TLS (Transport Layer Security),
formerly SSL (Secure Sockets Layer)
TLS is a protocol for secure communication
between a client and a server

Information Security/System Security – p. 167/617

 Smart Cards and Banking
Everyone uses them, but what happens when you
insert your credit/debit/cash card into a terminal?
How does the terminal verify that your card is valid?
Newer cards employ the “Chip and PIN” method to do
this, what’s inside the chip?

Information Security/System Security – p. 168/617

 Magnetic Strip Cards
Before Chip and PIN, magnetic strip cards and
signatures (or PINs at ATMs) were used
Basically, the magnetic strip contains (some of) the
information printed on the card in machine-readable
form
It is relatively easy to copy the information on the
magnetic strip, then all that’s left to do is to
forge the signature
find out the PIN
However, not everything was bad for a customer
If a signature turned out to be forged later on, the
customer was not liable

Information Security/System Security – p. 169/617

 Weaknesses
Some (early) glitches included:
Only the account number on the strip was used:
Collecting the discarded ATM slip (which in the
beginning had the complete account number on it)
and shoulder-surfing the PIN was enough to
create a copy of a card
Putting one-way hash code of PIN on card insecurely
Make a copy of your own card replacing account
number
Take money from that account with your PIN
The relative ease with which card can be copied is still
a problem

Information Security/System Security – p. 170/617

 Chip and PIN
Chip and PIN was introduced to make it harder to
commit card-based fraud
Actually this is not just one protocol, but a whole suite of
protocols
The standard is officially called EMV, after the
participating institutions Europay, MasterCard, VISA
In the meantime, Japan Credit Bureau (JCB) and
American Express have joined as well
The complete standard consists of four books
containing hundreds and hundreds of pages
http://www.emvco.com/specifications.aspx

Information Security/System Security – p. 171/617

 EMV
EMV can be seen as a “construction kit” for building
payment systems
Word of warning: choosing building blocks at random
is probably going to result in a very insecure system
We are going to look at the three main protocols
Static Data Authentication (SDA)
Dynamic Data Authentication (DDA)
Combined Data Authentication (CDA)
Basic premise: a customer card contains a smartcard
chip with the capability to
verify a PIN
authenticate a transaction

Information Security/System Security – p. 172/617

 SDA
Certification Authority
private key public key
dCA eCA
Issuer
public key eI signed
eI with dCA

private key static app data

dI signed with dI

smart
terminal
card communication between
card and terminal

Acquirer
Information Security/System Security – p. 173/617
 SDA (2)
Usually the involved parties are the following:
Issuer: who gives you the card (e.g. bank)
Certification authority: scheme operator (e.g. VISA)
Acquirer: participant in the scheme (e.g. shops,
ATMs)
We’ll have a look at the protocol on the next slide
Basically, terminal verifies that the
static application data (put on the card when it was
created) has not been manipulated
PIN is correct
before going ahead with a transaction

Information Security/System Security – p. 174/617

 SDA Protocol
What follows is a step-by-step description of what
happens when a card gets inserted into a terminal
1. Terminal uses CA’s public key eCA (which it has to
obtain from CA) to verify that issuer’s public key eI
provided by card is valid
2. Terminal uses public key eI to verify that data on
card is valid (and has not been modified)
3. Card user is authenticated via PIN: entered PIN is
sent (in cleartext) to card, which verifies correctness
Purchase, cash withdrawal, etc. can now go ahead

Information Security/System Security – p. 175/617

 SDA Protocol (2)
4. Terminal sends transaction data (merchantID, amount,
serial number, etc.) to card
5. Card encrypts this using a symmetric key shared with
the issuer, creating an application cryptogram (or AC)
6. Next step is handled differently, depending on whether
(a) terminal is online: terminal sends AC to issuer for
verification (checks for sufficient funds, card reported
as stolen, etc.)
(b) terminal is offline: if amount is below a certain
threshold (“floor limit”)
i. transaction is processed (AC is kept as evidence
that card was used)
ii. otherwise, transaction is aborted

Information Security/System Security – p. 176/617

 Weaknesses of SDA
Backwards compatibility with magnetic strip cards
EMV has not been rolled out on a world-wide basis
(e.g. United States hasn’t joined)
Even if EMV is used as a standard (such as in the
UK), magnetic strip is sometimes used as fallback
(e.g. if chip doesn’t work)
This makes it as vulnerable as magnetic strip cards
Eavesdropping on communication between card and
terminal
Criminals have used sniffing devices put between
separate card readers and PIN pads
Tampered terminals have been found

Information Security/System Security – p. 177/617

 Weaknesses of SDA (2)
Picture below shows a terminal with an inserted wiretap

Information Security/System Security – p. 178/617

 Weaknesses of SDA (3)
“Yescards”: cards programmed to accept any PIN
Only works in offline mode and relies on the fact that
merchant cannot read the application cryptogram
Instead of generating a valid AC, card returns some
random data that looks like an AC
However, you need a valid certificate (ei signed with
dCA and card data signed with di )
Can be obtained by listening in on the
communication of a valid card with a terminal

Information Security/System Security – p. 179/617

 DDA
Compared to SDA there is one additional public/private
key pair in DDA
This key pair, labeled with SC (for smart card), is
used by the card
While the other private keys are only used for signing
messages, dSC is actually stored on the card
For this to work it has to be stored securely, under no
circumstances may it leave the card
In addition to this, the smart card needs to be able to
run public key crypto-algorithms
This needs more computing power than the
symmetric algorithm used in SDA

Information Security/System Security – p. 180/617

 DDA (2)
Certification Authority
private key public key
dCA eCA
Issuer
public key eI signed
eI with dCA

private key static app data

dI signed with dI

public key eSC signed smart

terminal
eSC with dI card communication between
card and terminal

private key Acquirer

dSC

Information Security/System Security – p. 181/617

 DDA Protocol
Let’s have a look at the protocol
1. Terminal sends challenge to card
2. Card signs this with its private key and sends it back
This assures the terminal that the card is present
(somewhere)
3. Terminal verifies issuer’s public key eI on card with
eCA
4. Terminal verifies card’s public key eSC with eI
Now terminal can actually verify that its challenge was
correctly answered
5. Card user is authenticated via PIN: PIN is not sent in
cleartext, but encrypted with eSC
Rest of steps as in SDA before
Information Security/System Security – p. 182/617
 CDA
Top-end protocol in terms of security
Similar to DDA
Main difference: the application cryptogram is also
signed by card using its private key (in addition to
encrypting it)
This makes sure that the card that was authenticated
earlier is also used for the transaction
Otherwise, if you’re able to switch cards,
transaction could be done with different card under
DDA

Information Security/System Security – p. 183/617

 Further Weakness
Even CDA is not 100% secure
Vulnerable to a relay attack (tested experimentally by
the Computer Lab in Cambridge)
Set up bogus terminal in a cafe hooked up via WiFi
and a laptop to a bogus card
When someone paid £5 for his cake, card was
connected to fake card
With this fake card, somewhere else someone
purchased a book for £50 (using the credentials of
the valid card)

Information Security/System Security – p. 184/617

 Kerberos
Kerberos is a network authentication protocol:
Allows nodes to authenticate each other securely
communicating over a non-secure network
Based on a ticketing system

Information Security/System Security – p. 185/617

 Kerberos (2)
The basic protocol isn’t too hard to understand:
1. A client requests a ticket for a Ticket Granting
Service (TGS) from a Kerberos server
2. The ticket is sent to the client (after authentication)
3. To use a particular server, client requests a ticket for
a particular server from TGS
4. If user is allowed to access server, TGS issues a
ticket
5. Client presents this ticket to the server

Kerberos 1
2 5
3 Client Server

TGS 4
Information Security/System Security – p. 186/617
 Kerberos (3)
We’ll look at some details in just a moment
You might ask yourself what the Ticket Granting Service
is for
Kerberos could check if a user is allowed to access a
service and issue ticket for Server directly
Functionality is split between Kerberos and TGS to
share workload:
Kerberos does authentication
TGS does access control for services
Kerberos is based on symmetric cryptography:
Kerberos shares a different secret key with every entity
on the network

Information Security/System Security – p. 187/617

 Steps 1 and 2
Client sends their name to Kerberos (+ TGS server to
use)
Kerberos looks up client in database, if found Kerberos
generates a session key K1 to be used between client
and TGS
Kerberos sends back two messages:
The session key K1 encrypted with the client’s secret
key
A Ticket-Granting Ticket (TGT) including the client
name, client network address, ticket validity period,
and K1
This is encrypted using the secret key of TGS
The client can decrypt the first message (and get K1 )
Information Security/System Security – p. 188/617
 Step 3
The client sends two messages to TGS
The TGT received from Kerberos (+ requested
service)
An authenticator including the client name and a
timestamp, encrypted using K1
The authenticator serves two purposes:
It shows TGS that the client knows K1
The current timestamp prevents an eavesdropper
replaying the TGT and authenticator later
TGS decrypts the TGT ticket and uses the extracted
session key K1 to decrypt the authenticator

Information Security/System Security – p. 189/617

 Step 4
TGS can now check validity of client (name, network
address) and validity of the timestamp (time period)
It also checks that client is allowed to access requested
service
If everything turns out to be correct, TGS generates
another session key K2 to be used between client and
server
TGS sends two messages to the client:
The session key K2 encrypted with K1
A Client-Server Ticket (CST) including the client
name, client network address, ticket validity period,
and K2
This is encrypted using the secret key of the server
Information Security/System Security – p. 190/617
 Step 4
Step 4 is very similar to Step 2, TGS is now playing the
role that Kerberos played before
After receiving the CST, the client
can now retrieve the key used in communication with
the server
and is ready to contact the requested service

Information Security/System Security – p. 191/617

 Step 5
The client sends two messages to the service
The CST received from TGS (+ requested service)
An authenticator including the client name and a
timestamp, encrypted using K2
The server decrypts the CST ticket and uses the
extracted session key K2 to decrypt the authenticator
After checking that everything is correct, it can provide
the service to the client
If client wants to have an authentication from the server:
Server encrypts (timestamp + 1) using K2 and sends
it back to client
This shows that server knew its own secret key
(used for decrypting CST)
Information Security/System Security – p. 192/617
Everything Clear?

Information Security/System Security – p. 193/617

 Weaknesses
There are a few weaknesses:
Single point of failure:
While the Kerberos server is down, no-one can
access anything
Kerberos server knows all the secret keys, if it is
compromised all of these keys are compromised
The clocks on the different machines need to be
synchronized (and accurate):
If the timestamp provided by the client does not lie
in the ticket validity period, access will be denied
If a host can be fooled about the correct time, old
authenticators could be replayed

Information Security/System Security – p. 194/617

 TLS
TLS (Transport Layer Security) is a cryptographic
protocol for secure client-server communication
Web browsers contain the client TLS (or SSL) software
If a server has been configured to run TLS, then a client
can use it by specifying https: in a URL (instead of
http:
Servers can request that clients use TLS (even if client
has not used https:, e.g. for logins, payment details)
A secure connection is shown
by a closed padlock:

Information Security/System Security – p. 195/617

 Initiating Communication
TLS can perform different activities: encryption, server
authentication, client authentication
When a client requests TLS, client and server go
through a handshake protocol to determine
which of the above activities will be performed
and which encryption algorithm will be used
A public/private key pair will be needed on the server
side to go ahead
A server’s public key can be found in its certificate (also
known as a server ID)

Information Security/System Security – p. 196/617

 Encryption Only
If client only wants a secure communication line using
encryption, the following protocol is used
1. Client sends request for server ID to server
2. Server sends back server ID
3. Client generates (random) session key and encrypts
it using public key found in certificate
4. Client sends session key to server
5. Server decrypts message to obtain session key
Client and server now have a secret session key for
encrypted communication

Information Security/System Security – p. 197/617

 Server/Client Authentication
There’s one additional step that the client does (before
sending a session key to the server):
3. (b) Client attempts to verify the server ID certificate
with installed certificates
If this cannot be done, then the browser will warn its
user
In the case of client authentication, client needs to send
its certificate and the server will perform an additional
step:
4. (b) Client sends its certificate
5. (b) Server attempts to verify the client’s certificate
with installed certificates

Information Security/System Security – p. 198/617

 Summary
Again, this is only scratching the surface of
cryptographic protocols
There are lots of other of cryptographic protocols for
doing a range of things:
Threshold schemes for sharing secrets:
reconstructing messages with any m out of n pieces
Subliminal channels: covert ways of communicating
secretly
Mental Poker: distributing keys anonymously
The important issue is: cryptosystems have to be
applied to be in a certain way to guarantee security

Information Security/System Security – p. 199/617