Protocols
A protocol is a set of rules for exchanging messagesbetween 2 (or more) principals over a network.
The word ‘protocol’ in the OSI model is reserved and refers to rules governing communication between a pair of peer entities.
Secure Protocol
When acting honestly, principals (participants) achieve the
stated aim of the protocol
- E.g.: Alice successfully authenticates to Bob, or Alice and Bob establish a key.
Neither passive eavesdropper (Eve) nor malicious, active adversary (Mallory) can defeat this aim (e.g. by successfully impersonating Alice in an authentication protocol with Bob).
This all pre-supposes that the stated aim is actually clearly stated!
Entity Authentication
- origin authentication (verifying the origin of received data) and
- entity authentication (verification of a claimed identity).
An origin authentication service can be built from a data integrity mechanism, e.g. a MAC
Typically achieved by exchange of messages called anauthentication protocol
Why Entity Authentication?
Entity authentication provides a fundamental service:
- It allows one host or user on the network to check with which other host or user it is communicating.
Successful entity authentication can be a precursor to (or part of) the use of more complex security services.
Entity authentication:
- the corroboration that an entity is the one claimed at a particular point in time (but not necessarily any guarantees after that time).
Unilateral authentication:
- entity authentication which provides one entity with assurance of the other’s identity but not vice versa.
Mutual authentication:
- entity authentication which provides both entities with assurance of each other’s identity.
- No – Mallory can easily impersonate A.
- Authentication protocols can be built from a number of different assumptions:
- A and B share a secret (e.g. a password, a PIN, biometric information, a symmetric key).
- A and B have authentic copies of each other’s public keys.
Challenge/Response Authentication
In challenge-response authentication, one entity ‘proves’ its identity to another by demonstrating knowledge of a secret known to be associated with that entity, without revealing that secret itself during the protocol.
Typically use cryptographic mechanisms to protect the messages in the protocol:
- Encryption.
- Integrity mechanism (e.g. MAC).
- Digital signature.
User Authentication
Here, the objective is to authenticate a user to a system (and possibly vice-versa).
User authentication usually based on (a combination of):
- Something you know (password, PIN).
- Something you have (a smartcard or token,…)
- Something you are (a biometric)
User authentication is limited by what a user can remember, carry, etc.
- The problem may be harder when user and system are remote, because credentials/data may need to be protected in transit.
- We can’t expect users to remember long cryptographic keys or carry unwieldy equipment.
Authentication not directly involving users (i.e. machine to machine) is not generally limited in this way.
Encryption based Authentication
Assume Alice and Bob share a secret key K. Design goal: Alice to be authenticated.
1. Alice sends an initiating message.
2. Bob sends Alice a challenge message R.
3. Alice responds with {R || B}K, message R concatenated with B, encrypted using shared key K.
4. Bob checks that the message he received decrypts to give message R || B.
5. If it does, then Alice is authenticated to Bob (or Bob authenticates Alice)
The Protocol
A →B: ‘Hi Bob, I’m Alice’
B →A: R (challenge)
A →B: {R || B}K(response)
Security of the Protocol -1
- Why can Bob be sure that message 3 in the protocol came from Alice?
Only Alice (and Bob) know secret key K.
- Why can Bob be sure that message 3 in the protocol is not a replay of a message from an earlier run of the protocol between himself and Alice?
Bob chose R at random just before sending message 2. This R should never have been used before. This means that message 3, which includes R in encrypted form, has never been produced before.
Assumption: Mallory cannot observe an old protocol run and then alter an old message {R’ || B}K to make it an acceptable response to Bob’s new challenge R (stream ciphers might be vulnerable to bit flipping attacks!)
- Why can Bob be sure that message 3 in the protocol is intended for him?
Alice includes Bob’s identity ‘B’ in the encrypted message. This prevents Mallory taking a message intended for someone else and sending it to Bob.
- Can an attacker learn the value of secret key K by observing multiple runs of the protocol?
No, not if the encryption algorithm is strong.
- Is Alice authenticated to Bob in this protocol?
Yes.
- Is Bob authenticated to Alice in this protocol?
No. (In fact Mallory could impersonate Bob in the protocol, but our design goal was a protocol in which Alice is authenticated, not Bob, so this is not a problem.)
- Does the protocol provide mutual or unilateral authentication?
Unilateral: authentication of Alice.
Assumption of the Security of this Protocol
We’re making an assumption that Mallory cannot observe an old protocol run and then alter an old message {R’ || B}K in such a way as to make it an acceptable response to Bob’s new challenge R.
This has implications for the kind of encryption primitive that Alice and Bob should use:
- For example, they should not use a stream cipher with this protocol, as Mallory can just flip bits in the message {R’||B}K to turn it into {R||B }K .
Replay Attack
Mallory begins by hijacking a session between Alice and Bob and firstly impersonates Bob to Alice in a protocol run initiated by Alice:
A → M(B): ‘Hi Bob, I’m Alice’
- *M(B) → A: R** (M predicts which R will be used later by B)
- *A → M(B):** {R || B}K
Mallory keeps hold of {R || B}K: it’s going to come in handy later:
- M(A) → B: ‘Hi Bob, I’m Alice’
- B → M(A): R (M predicted this R would be used by B)
- M(A) → B: {R || B}K
Liveness and Freshness
The replay attack shows that it is vital that the protocol contains a means of checking liveness of principals.
Liveness: assurance that message sent by a principal within an acceptably recent timeframe.
- Usually after an event known to be recent to the other principal.
- Liveness of principals usually ensured via freshness of messages.
Freshness: assurance that a message has not been used previously and originated within an acceptably recent timeframe.
- freshness of message together with authenticity of origin of message can assure liveness of principal.
Two main methods for providing freshness:
- Nonce (Number used once).
- Time-stamps (clock-based or `logical’ time-stamps).
Nonces
Most important: ‘one-time’ property - nonce should not have been used before.
- So one could in theory use a counter?
Many protocols need nonces to be unpredictable (to Mallory), rather than simply previously unused.
- For example, our protocol needs this property for R to prevent the replay attack.
- One could form R by generating a long string of bits at random.
- How long is long enough?
- How can we ensure R is sufficiently random?
Notice that in our protocol, R, the nonce is unpredictable but not secret.
logical time stamps
Alternative to clocks: Alice and Bob could use pair of sequence numbers NAB and NBA in their communications.
Every time A sends B a message she includes value NAB, and increments it. Likewise for B.
Needs pair of sequence numbers for every pair of communicating parties.
Sequence numbers may need to be kept secret in protocol runs.
- May otherwise be predictable to Mallory.
Using MACs for Entity Authentication
Replace encryption mechanism with a MAC:
A → B: ‘Hi Bob, I’m Alice’
B → A: R (challenge)
A → B: MACK(R || B) (response)
- Security as for encryption-based protocol: only Alice can prepare correct response for Bob;
- Freshness of R guarantees liveness of Alice.
Signature based Entity Authentication
Instead of challenge/response, now challenge/signature.
Use nonce or time-stamps for freshness.
Rather than a shared secret key, Bob needs to have authenticated version of Alice’s public key (and vice-versa for mutual authentication).
Signature-based Mutual Authentication
B→A: RB
A→B: RA,SA{RA ||RB||B}
B→ A: SB{RB||RA ||A}
SA{X} denotes A’s signature on string X.
Protocol achieves mutual authentication (via two signatures and two nonces).
A and B must check the signatures to ensure their correctness.
Signatures are on both nonces: messages are fresh and have been signed by the other party
Signature based Mutual authentication
B→A: RB
A→B: RA,SA{RA ||RB||B}
B→ A: SB{RB||RA ||A}
A’s signature is on a message containing B’s identity.
Otherwise, Mallory might be able to take messages signed by A intended for another party C and re-direct them to B. Likewise for B.
Why are the orders of the nonces swopped in messages 2 and 3?
This is to avoid a symmetry that can also be exploited by Mallory to mount an attack.
It’s important that Alice’s signature is on a message that contain randomness contributed by her.
Otherwise, Alice can be used as a signature oracle by Mallory: Alice can be forced to sign on messages of Mallory’s choosing.
Using Digital Signatures
Alice and Bob have to be sure that they are verifying each other’s signatures.
Trust in authenticity of public keys instead of shared secrets is needed
Reminder:
- Public keys can be certified by applying the digital signature of a Trusted Third Party (TTP) called a Certificate Authority (CA).
- Result (public key + entity name + expiry date + CA signature on three items) called a certificate.
Using Certificates
To check a certificate signed by a CA requires an authentic copy of the CA’s public key.
- If two entities have certificates signed by different TTPs, then a cross-certificate is needed (i.e. one a copy of one TTP’s public verification key signed by the other TTP).
- certification path, sequence of cross-certificates with the subject of one certificate being the signer of the next certificate in the sequence.
For the long-term memory: public-key cryptography for signatures does not solve the problem of distributing symmetric keys; it shifts it to the problem of verifying the authenticity of public keys.
