Fall 2001, CSE 597E: Lecture 2

In this lecture we continue the overview of the issues related to Security Protocols.

Security Properties

Last time we introduced the notions of:

Secrecy
Autentication of origin
Integrity of messages

Other relevant properties are:

Authenticated key exchange

If Anne receives a key K which she thinks is private between herself and Bob, then it must be the case that K is known only to Anne and Bob (plus, possibly, to a third trusted party)

Non-repudiation

If Bob receives a message sent by Anne, then it must be possible to prove that Anne has indeed sent the message (even if she tries to deny it).
Question: Why Anne could be interested in denying it?

Fairness

Avoid that one of the parties ends the protocol part-way through in order to gain some unfair advantage over the other party.
Question: What kind of advantage could the party gain?

Anonimity

Sometime we may be interested in anonimity, for instance, we know that an action A has been performed but noone can know which agent has performed it (except of course the agent itself)

Question: What could be an example?

Availability

The protocol will eventually achieve some desired goal. For intance, in a key-exchange protocol, we would like to be confident that a secure session will eventually be extablished.

This is a fairness property:

Eventually something good will happen

All the other properties seen before were, in contrast, safety properties:

Nothing bad will ever happen

The distinction between the two is rather subtle and requires a formal model of computation. We mention this distinction here only to point out that the formal treatment of security properties can require very different techniques. Proving fairness properties is in general much more difficult than proving safety properties.

A brief overview of Cryptographic methods

Two kinds:

Symmetric cryptography (aka Secret-key)
Asymmetric cryptography (aka Public-key)

Symmetric cryptography

The first method to be discovered and used
It requires that the two parties both know the same key. Once the party has the key it can do both encryption and decription.
Until the advent of asymmetric cryptography, the governments and security agencies were rather protective about research done in this field. Public research and publications on this topic were not encouraged

A classification of symmetric methods

Transposition: text reshuffling
Substitution: text substituted with other text
- Stream: Each symbol of the text is encrypted individually
- Block: More than one symbol at the time are encripted

An example of block cipher: The Playfair cipher

The letters of the alphabet are arranged in a table, and scrambled according to some rule.

To encipher a pair of letters we first situate them in the table, then we take the pair of letters at the opposite corners.

In the example represented in the table below, the rule for scrambling is the placement of the world DISLEXIA at the beginning of the table, and consequent shift of all other letters.

For example, the pair PL is encrypted as QS.

        +---+
     D Y|S L|E
        |   |
     X I|A B|C 
        |   |
     F G|H K|M
        |   |
     N O|P Q|R
        +---+
     T U V W Z

The Playfair cipher is simple, in the sense that the function AxA -> AxA remains constant

Obviously the security can be made greater by working with larger blocks.

DES (Data Encryption Standards) works on 64-bit blocks
IDEA works on 128-bit blocks

Asymmetric cryptography

Introduced in 1976 by Diffie and Hellman. Actually, it was invented slightly earlier by researchers at the GCHQ (Government Communications Headquarters), but the idea was not made public.
It allows two parties to extablish a shared secret by using only open communication channels.

The basic idea: every agent A has two keys:

PK : Public key, publically known

SK : Secret (or private) key, known only by the agent

Whoever wants to send a message M to A, it will encrypt it by using PK, then send the result of the encryption, { M }_PK, to A. A will then decrypt it by using SK. Let {{ M }_PK}_SK be the final result.

The following property must hold:

(a) {{ M }_PK}_SK = M

In some scheme, like the RSA (Rivest, Shamir and Adleman), also the reverse holds:

(b) {{ M }_SK}_PK = M

Note: (a) implies that { }_PK is injective and (b) implies that { }_PK is injective. In theory this works fine, but how to make it work in practice? In other words: if one knows how to encrypt messages, in principle he should be able to infer also how to decrypt them. How to make sure that SK is really secret?

Idea:

Use one-way functions
One-way function are easy to calculate in one direction, but intractable in the other direction.

So, SK is not secret in an absolute sense, but it is secret in practice.

Examples

Let p, q be prime. Calculating the product n = pq is easy, while calculating p and q given n is thought to be intractable
Given an element of a finite field r, and a number m, calculating n = r^m is easy, while calculuating m given r and n is thought to be intractable.

So, we could use a one-way function f as the public key.

Encrypt: apply f to the message.
Decrypt: apply the inverse of f to the encrypted message

Question: This alone wouldn't work. Why?

Idea:

Use a trap-door

Given a one-way function f, a trap-door is an information that makes it easy to calculate the inverse of f.

Of course the trap-door relative to a secret key should be known only by the agent who owns the secret key.
The trap-door should be hard to discover just from the knowledge of the encryption algorithm.

Example: The RSA algorithm (Rivlest, Shamir, Adleman)

Choose two large primes p an q and calculate their product n = pq
Choose an integer e with the feature of being relatively prime to (p-1)(q-1).
Choose an integer d with the property that
ed = 1 (mod (p-1)(q-1))
Using Fermat's Little theorem, we know that
m^ed = m (mod n)
Note: x = y (mod n) means that the integer division of x and of y by n give the same remainder.
e and n are made public, while p, q and d are kept secret.
- Encryption: given a message (number) m < n, compute
  c = m^e(mod n)
- Decryption: given an encrypted message c, compute c^d. By the Fermat's Little theorem, we have
  c^d = m^ed = m (mod n)
To derive p and q (and hence d) from n is believed to be untractable.
Alternative ways of using one-way functions

Example: The Diffie-Hellman key extablishment scheme
This scheme is meant to extablish a private key between two parties.
It is more straightforward and does not require a trap-door.
1. Chose a prime p and a primitive root r modulo p. (primitive means that all numbers between 1 and p can be generated by taking exponents of r modulo p)
2. Anne chooses at random an integer x and sends Bob the message m₁ = r^x(mod p)
3. Bob chooses an integer y and sends Anne the message m₂ = r^y(mod p)
4. Anne calculates K₁ = m₂^x(mod p)
5. Bob calculates K₂ = m₁^y(mod p) It is easy to prove that K₁ = K₂. Hence Anne and Bob can use K₁ as a private key between themselves.
  Note that Anne and Bob play a symmetric role in the generation of the key.
  Deriving x from m₁ (and y from m₂) is considered to be intractable.
  Security protocols vulnerabilities
  Some of the strategies that an intruder may employ
  Man-in-the-middle
  The attacker interfers by intercepting the message and possibly modifying it and/or pretending to be one of the two parties.
  Example: Given the RSA encryption scheme, consider the following protocol which Anne could use to send a message to Bob:
  1. Anne sends to Bob the encrypted message { M }_{PK_Anne}
  2. Bob cannot decrypt the message (only Anne can), but he can encrypt it again. He sends to Anne the message
    {{ M }_{PK_Anne}}_{PK_Bob}
  3. Now, using the commutative property of the RSA scheme, namely
    {{ M }_{PK_Anne}}_{PK_Bob} = {{ M }_{PK_Bob}}_{PK_Anne}
    Anne strips off her own encryption and computes { M }_{PK_Bob}
  4. The above message is sent to Bob and he can finally decrypt it. Question: This protocol is not secure. Why?
    Answer: Various reasons: one is that for the commutative property the n's of the two public keys should be the same, and this mean that both Anne and Bob know the factorization and hence can guess the secret key of each other. Another reason is that the intruder could intercept the message sent from Anne, send it back to Anne as it is, and Anne will decript it. Finally, we have the following attack, which can be classified as an application of the man-in-the-middle strategy:
    1. Anne sends the message { M }_{PK_Anne} to Bob
    2. Yves intercepts this message and applies to it is own public key, so to obtain
      {{ M }_{PK_Anne}}_{PK_Yves}
    3. Yves sends the above message back to Anne, pretending he is Bob. Anne strips off her own encryption, and sends to Bob the message
      { M }_{PK_Yves}
    4. Yves intercepts again the message, and strips off his own encryption to reveal M
    - This attack is possible thanks to the lack of any form of authentication
    - The Diffie-Hellman key extablishment protocol is equally vulnerable
    Replay
    The intruder monitors a (possibly partial) run of the protocol and at some time reproduces (replays) one or more of the messages.
    Example: Consider a variant of the NNSK protocol (Needham-Schroeder-Secret-Key) with the nonce from A removed:
    Message 1 A -> J : A.B
    Message 2 J -> A :{B.k_AB.{k_AB.A}_ServerKey(B)}_ServerKey(A)
    Message 3 A -> B : {k_AB.A}_ServerKey(B)
    Message 4 B -> A : {n_B}_{k_AB}
    Message 5 A -> B : {n_B - 1}_{k_AB}
    Suppose that Yves eventually succeeds to break the key, so he now knows k_AB. Presumably this will have taken a long time, so k_AB is not used anymore by A and B.
    However, next time Anne sends a request to Jeeves, Yves can incercept Jeeve's reply, and send back to Anne the message
    {B.k_AB.{k_AB.A}_ServerKey(B)}_ServerKey(A)
    So Anne will think that k_AB is the key to be used in next conversation with Bob.
    Question: Why this attack is not possible in the original NNSK protocol?
    Oracle
    The intruder tricks an agent into inadvertendly reveal some information, possibly by inducing him into performing some steps of a protocol.
    Interleave
    The intruder contrives for two or more runs of the protocol to overlap
    Example of an attack which combines oracle and interleaving techniques: Consider the Needham-Schroeder-Public-Key protocol:
    
    Message 1 A -> B : { A.n_A }_{PK_B}
    Message 2 B -> A : { n_A.n_B }_{PK_A}
    Message 3 A -> B : { n_B }_{PK_B}
    
    At the end of the protocol, it seems reasonable to believe that:
    - A and B know with whom they have been interacting
    - A and B agree on the values of n_A and n_B
    - Noone else know the values of n_A and n_B
    In fact, for many years the protocol has been believed to satisfy those properties, but recently it has been shown that there is a rather subtle attack possible
    Attack to the NSPK protocol
    In the following, Y(A) represents Y generating (resp. receiving) the message, making it appear as generated (resp. received) by A.
    
    Message a.1    A -> Y : { A.n_A }_{PK_Y}
    Message b.1 Y(A) -> B : { A.n_A }_{PK_B}
    Message b.2    B -> Y(A) : { n_A.n_B }_{PK_A}
    Message a.2    Y -> A : { n_A.n_B }_{PK_A}
    Message a.3    A -> Y : { n_B }_{PK_Y}
    Message b.3 Y(A) -> B : { n_B }_{PK_B}
    
    Initially, Anne starts a protocol run with Yves thinking that he is an honest agent.
    At the end, Bob thinks that he and Anne share exclusively the knowledge of n_A and n_B, while this is not the case.

Fall 2001, CSE 597E: Lecture 2

Security Properties

Authenticated key exchange

Non-repudiation

Fairness

Anonimity

Availability

A brief overview of Cryptographic methods

Symmetric cryptography

A classification of symmetric methods

An example of block cipher: The Playfair cipher

Asymmetric cryptography

Examples

Example: The RSA algorithm (Rivlest, Shamir, Adleman)

Alternative ways of using one-way functions

Example: The Diffie-Hellman key extablishment scheme

Security protocols vulnerabilities

Man-in-the-middle

Replay

Oracle

Interleave

Attack to the NSPK protocol