Authenticity

Specifying Authenticity

A begins! Send(A,m,B)A -> S : A, {B,m}kasS -> B : {A,m}kbsB ends Send(A,m,B)

• Insert begin- and end-markers into the protocol.• And require that they match up in protocol runs.

PA == new m : Secret; begin!(Send(A,m,B)); out net (A, {(B,m)}kas)PB == inp net {(a,m)}kbs; end(Send(a,m,B))

Specifying Authenticity (2)

A begins! Send(A,m,B)A -> S : A, {B,m}kasS -> B : {A,m}kbsB ends Send(A,m,B)

• P is safe for authenticity if in every run every end(M) is preceded by a matching begins!(M).

• P is robustly safe for authenticity if P | O is safe for authenticity for all opponents O.

• A more formal definition in terms of the spi-calculus will follow ...

Type flaw attack

A begins! Send(A,m,B)A -> S : A, {B,m}kasS -> B : {A,m}kbsB ends Send(A,m,B)

• If each agent acts both in the initiator and receiver role, then there is a type flaw attack: Can you see it?

A begins! Send(A,m,B)A as initiator -> O : A, {B,m}kasO -> A as receiver : {B,m}kasA ends Send(B,m,A)

• Note: begins!(Send(A,m,B)) and end(Send(B,m,A)) do not match.• A ends a Send(B,m,A)-session that B has never begun.• How can we fix it?

The fix

A begins! Send(A,m,B)A -> S : A, {B,m}kasS -> B : {A,m}kbsB ends Send(A,m,B)

• The protocol can be fixed by tagging the two encrypted• messages: {msg1(B,m)}kas and {msg2(A,m)}kbs.

Correspondence Assertions for Spi

P ::= · · ·| begin!(M); P an M-session begins

A ::= · · ·| end(M) an M-session ends| begun(M) an M-session has begun

• begun(M) is an auxiliary assertion that is used to record that an M-session has begun, when a process evolves.- It should not be inserted manually into protocols.- We will also allow begun(M) in type annotations. More on that later.

Propagating Correspondence Assertions

• Logical reduction rules for correspondence assertions.

- begin!(M); P -> !begun(M) | P- begun(M) | end(M) -> stop

• These are “logical” reduction rules. They do not affect theother rules of the operational semantics.

Robust Safety: Formal Definition

• A closed process P is safe for authenticity iff- IF P -> * new ~n; (end(M) | Q) - THEN Q == begun(M) | Q’ for some Q’.

• A closed process P is robustly safe for authenticity iff for all opponent processes O the parallel composition P | O is safe for authenticity.

Flavours of Authentication

• We can distinguish among various flavours of authentication. We use assertions to specify them.

• Examples. Assume a protocol, where B’s part contains an end-assertion of one of the following forms:- end(Send(A,M,B))− If execution reaches this end-assertion then M has previously been sent by A and was

intended for B.- end(Send(A,M))− If execution reaches this end-assertion then M has previously been sent by A (and may

or may not have been intended for B).- end(Contact(A,B))− If execution reaches this end-assertion then A has previously contacted B.

Non-injective Agreement

• The robust safety definition we have seen allows replays of messages that have previously been sent.- a single begin!-assertion could match several end-assertions.- (a many-to-one correspondence).

• Many-to-one correspondences specify so-called non-injective agreement, which allows replays.- Replays are not always harmful. − Consider, for instance, Alice sending Bob her digitally signed birth certificate. It is not

harmful, if this is a replay of a previously sent message that contains the same birth certificate.

- However, in other cases, replays are harmful. Consider, for instance,− a digitally signed money transfer order.

Specifying Injective Agreement

• We introduce begin-once assertions for one-one correspondences (which specify injective agreement).

• Begin-once statements.- P ::= · · · | begin(M); P- the only difference with begin-many is the missing “!”

• Semantically, begin(M) may match at most one end(M).• A logical reduction rule for begin-once statements.- begin(M); P -> begun(M) | P- Note that begun(M) cannot be replicated.

A Replay Attack

- A begins ! Send(A,m,B)- A -> S : A, {msg1(B,m)}kas- S -> B : {msg2(A,m)}kbs- B ends Send(A,m,B)

• we argued this is robustly safe for authenticity • how about this one? (discover the difference)- A begins Send(A,m,B)- A -> S : A, {msg1(B,m)}kas- S -> B : {msg2(A,m)}kbs- B ends Send(A,m,B)

A Replay Attack (2)

A begins Send(A,m,B)A -> S : A, {msg1(B,m)}kasS -> B : {msg2(A,m)}kbsB ends Send(A,m,B)

• a replay attackA begins Send(A,m,B)A -> S : A, {msg1(B,m)}kasS -> O : {msg2(A,m)}kbsO -> B : {msg2(A,m)}kbsB ends Send(A,m,B)O -> B : {msg2(A,m)}kbsB ends Send(A,m,B)

• But the matching begin-assertion has already been used!

Nonces to Avoid Replays

• A nonce is a random number. Used to avoid replays.• A challenger A- needs authenticated data that is not a replay.- So he generates a fresh nonce and sends it to the responder.

• The responder B replies the nonce back to the challenger together with the data he needs to send.

• A checks that the response contains the right nonce.- he now knows that the message cannot be a replay.

• Still TBD: A needs to check that the response really comes from B. More on that later.

How can we fix this?

- A begins Send(A,m,B)- A -> S : A, {msg1(B,m)}kas- S -> B : {msg2(A,m)}kbs- B ends Send(A,m,B)

Fixing the protocol

• Idea: Bob issues a nonce challenge to Alice to precede the two-message protocol from before.- A -> B : A- B generates a fresh nonce nb- B -> A : nb- A begins Send(A,m,B)- A -> S : A, {msg1(B,m, nb)}kas- S -> B : {msg2(A,m, nb)}kbs- B checks that the response nb equals the challenge nb- B ends Send(A,m,B)

• This protocol is robustly safe for authenticity.• This can, for instance, be shown with authenticity types.

Timeliness

• Nonces are sometimes used for ensuring injective agreement and sometimes for ensuring timeliness.

• These are subtly different protocol goals:- Injective agreement prevents accepting the same message more than once.- Timeliness prevents accepting messages that are older than acceptable.

Timeliness vs. Injective Agreement

• A scenario where timeliness is needed:- In protocols for establishing short-lived session keys it is ok to accept a replay of

a session key as long as this replay comes within the window of time where it is computationally impossible to crack the session key. It is not ok to accept a replay of a session key that is older than this window of time.

• A scenario where injective agreement is needed:- Consider a protocol that sends your money transfer order to your bank. You

don’t want the money to be transferred from your account twice, but it is ok if the transfer happens late.

Nonces for Ensuring Timeliness

• Challenge/Response protocols with random nonces.• In a challenge/response protocol, the challenger gets the following

timeliness guarantee: The message that is associated with the response has been sent after the challenge was issued.

• If the challenger issued the challenge recently, he knows that the response is recent, too.

Sequence Numbers for Ensuring Timeliness

• Run identifiers or sequence numbers.• A run identifier could for instance be a simple counter that identifies

the i-th run of the protocol. The run identifier is included in protocol messages. Upon receipt, agents check that the received message contains the current run identifier.

• Run identifiers give the following timeliness guarantee: Received messages with the current run identifier must have been sent after the current run has started.

• If the receiver knows that the current run has started recently, he knows that the received message is recent, too.

• Unlike random nonces, run identifiers are predictable. Appropriate use of cryptography is needed to ensure that attackers can not fake run identifiers.

Timestamps for Ensuring Timeliness

• Agents stamp messages with the current time. Upon receipt, agents check if the timestamp is close to the current time.

• Timestamps appear to be the most direct way of ensuring timeliness.

• Caveat: Timestamp-based protocols assume an idealized global clock. In reality, local clocks have to be synchronized. Synchronizing local clocks over an untrusted network is itself a security problem.

• Nevertheless, timestamps are common in practice.

Varia

• References- Our secrecy assertions are very similar to secrecy claims in the CSP model, see

Chapter 3.2 in [RS01].- The example protocol that is vulnerable to internal attack is a variant of Woo-

Lam’s authentication protocol . The attack is taken from the Clark/Jacob survey [CJ97], Section 6.3.10.

- The secrecy type system is very similar to the one by Abadi/Blanchet [AB01].- Gordon/Jeffrey’s article [GJ05] contains an extended secrecy type system that

deals with internal attackers.

Symbols

• structural congruence• • ⱶ