Verification of Security Protocols

Chapter 3(b): Secrecy Types for Asymmetric Cryptography

+Chapter 4: Authentication

Note

• Mid-term exam will be on April 27, 10:30 till 12:00

Reminder: Syntax for Asymmetric Crypto

• Messages.• M,N,K ::= · · ·

| {|M|}K asymmetric ciphertext| Enc(K) encryption part of keypair K| Dec(K) decryption part of keypair K

• Processes.• P ::= · · ·

| decrypt M is {|x|}K−1;P asymmetric decryption

• We will define typing rules for these syntactic operators.

Types for Asymmetric Keys

• T ::= · · ·| PubKeyPair(T) public-enc/private-dec keypairs| SignKeyPair(T) private-enc/public-dec keypairs| Enc(T) enc-part of keypair of type T| Dec(T) dec-par of keypair of type T

• Subtyping.– Enc(PubKeyPair(T)) <: Public– Dec(PubKeyPair(T)) <: Secret– Enc(SignKeyPair(T)) <: Secret– Dec(SignKeyPair(T)) <: Public

What can we infer from public key crypto

• Consider– A ->B : {|s|}pB– A ->B : {|{|s|}sA|}pB– A ->B : {|{|{|s|} pB|} sA|}pB

• In which cases can B be sure that s is secret?– no– yes, provided he checks the signature of A and A doesn’t cheat

• relies on “what’s inside”

– yes, provided he checks the signature of A and A doesn’t cheat• relies on “what’s around”

Typing Rules for Key Extraction

E ⱶ K : TE ⱶ Enc(K) : Enc(T)

E ⱶ K : TE ⱶ Dec(K) : Dec(T)

Typing Rules for Public Key Crypto

E ⱶ K : Enc(PubKeyPair(T)) E ⱶ M : TE ⱶ {|M|}K : Un

E ⱶ M : UE ⱶ K : Dec(PubKeyPair(T)) E, x : T ⱶ P : okIF (Un <: U) THEN (E, x : Un ⱶ P : ok)

E ⱶ decrypt M is {|x|}K−1;P : ok

Remarks on the decryption rule.

• It is necessary to show P’s well-typedness twice, if Un <: U.

• The premise E, x : Un ⱶ P : ok accounts for the possibility that an attacker has formed the ciphertext. This is possible because the encryption key is public.

• Proofs of the premise E, x : Un ⱶ P : ok sometimes make use of the rule (If Fail) for conditionals (the second rule for conditionals on the previous set of slides).

Typing rules for signing.

E ⱶ K : Enc(SignKeyPair(T))E ⱶ M : T <: U {Secret, Public, Un}

E ⱶ {|M|}K : U

E ⱶ M : UE ⱶ K : Dec(SignKeyPair(T)) E, x : T ⱶ P : ok

E ⱶ decrypt M is {|x|}K−1;P : ok

Example: Sign-Then-Encrypt

• A generates secret sA ->B : {|{|s|}sA|}pB

• This protocol type-checks with the following key types:• Any guesses on the key types?• Type of A’s signing key pair: SignKeyPair(Secret).• Type of B’s public key pair: PubKeyPair(Secret).• Do parts of proof tree on blackboard.

Part 1

E ⱶ sA : Enc(SignKeyPair(Secret))E ⱶ s : Secret <: U = Secret {Secret, Public, Un}--------------------------------------------------------------------E ⱶ {|s|}sA : SecretE ⱶ pB : Enc(PubKeyPair(Secret)) ---------------------------------------------------------------------E ⱶ {| {|s|}sA |}pB : Un

Part 2

Authenticity and Authenticity Types

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.– 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 attackA 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 fixA 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 cab 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, often 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)}kasS -> B : {msg2(A,m)}kbsB 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)}kasS -> B : {msg2(A,m)}kbsB 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)}kas

S -> O : {msg2(A,m)}kbs

O -> B : {msg2(A,m)}kbs

B ends Send(A,m,B)O -> B : {msg2(A,m)}kbs

B 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)}kasS -> B : {msg2(A,m)}kbsB 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.

Timeliness

• We will not talk about timeliness for a while, but will come back to it IF we study BAN logic.

Types for Authenticity: Basic Idea

• Abadi/Needham’s Principle 1 [AN96].– “Every message should say what it means: the interpretation

of the message should depend only on its content. It should be possible to write down a straightforward English sentence describing the content—though if there is a suitable formalism available that is good, too.”

• Sometimes this principle is called the explicitness principle.

• Authenticity types enforce the explicitness principle.– Well-typed processes are robustly safe for authenticity.

Symbols

• structural congruence• • ⱶ• in