Security attacks

Security services
- confidentiality: only authorized parties have read access to
information
- integrity: only authorized parties have write access to
information
- availability: authorized access to information when needed
- authenticity: identity claims (user, message source) can be
verified
- non-repudiation: message exchange can be proved by
sender and receiver
- authorization: information / system / resource access
control
Secret-key cryptography
Public-key cryptography
 Encryption modes
Electronic
Code Book
mode (ECB)

Output
Feedback
mode (OFB)
Hash function
Signature
 What is CSP?

 CSP (Communicating Sequential Processes) is a

notation for describing systems of parallel agents that
communicate by passing messages.

 CSP is a notation for describing interaction

 CSP - Basic Building Blocks
 Visible Events and Stop
aP
the process that does nothing
event prefix
Internal Action (S - t) ? x : A  P event prefix choice
c ? x : A  P input prefix choice
PQ choice between two processes
general choice
Basic Operators
S
 PП Q nondeterministic choice
∏S general nondeterministic choice
P || Q lockstep parallel
 Parallelism P X ||Y Q
P || Q
synchronizing parallel
interface parallel
X
||| S general interleaving
P\ X event hiding
 Advanced Constructs PR process relational renaming
successful termination
 Hiding Skip
P; Q sequential composition
 Renaming P  F (Q) recursive definition
 Process Behavior

 Deadlocks, Livelocks, Nondeterminism

 Traces model of CSP

 Recursion

 Time: Timed CSP or tock Event

 Modeling security protocols in CSP
 Security protocols work through the interaction of a number of
processes in parallel that send each other messages.
 We describe how this is done, concentrating specifically on how
protocol models can be built that allow us to probe for security
flaws.
 We will study more precisely the Yahalom protocol:
 The three participants A, B and S respectively perform:
 An initiator process equipped with only one nonce and
using server S is:

 The responder role has a similar program (again,

assuming it has just one nonce to use)
 The server process definition can be expressed as follows:

 To model the risky world of communication, we add an

intruder process into the network:

 The only source of knowledge of the intruder is what he

observes being communicated, and that he can only decrypt
an encrypted message if he has the appropriate key.
An intruder process can, at any stage,
perform any action that is
cryptographically justifiable:

 Overhear and/or block messages that one agent sends

to another, including servers.
 Generate any message that can be built on the basis of
what the intruder has heard, knew initially, or might
legitimately have made up.
 Act as a regular agent: the intruder will have all
information that regular agents would have.

We want runs between our two agents to

be secure even if there are other agents
around who are corrupted.
 Expressing Protocol Goals
 Protocols are designed to achieve particular
security properties in the presence of particular
kinds and levels of threat.

 We will concentrate on secrecy and

authentication properties. Other properties, like
anonymity and non-repudiation, will also be
discussed.
 Secrecy
 If a particular data item m is intended to be secret at the end
of the protocol run, then a message Claim_secret will be
inserted at the end of the description of the protocol run.
 The secrecy property will state that the intruder cannot obtain
m during a run of the protocol.
 Authentication
 Verification of an entity’s claimed identity
 Commit.b.a ~ Agent b has completed a protocol run, apparently with a
 Running.a.b ~ Agent a is following a protocol run, apparently with b

 If Running.a.b must always have occurred by the time

the Commit.b.a event is performed, then authentication
of a to b is achieved

 In addition to simple signals, authentication events can

include additional information ds (nonces, keys, etc..)
 Authentication Schemes
1. Agent b requires that the other agent a is alive and has
not failed.
 This is ensured if Commit.b.a.ds provide evidence simply that a has
participated in some recent communication. Any data ds will suffice.
2. Agent b might require authentication in a run in which a
took b to be the other participant.
 In this case Commit.b.a.ds will guarantee it given that Running.a.b.ds’
occurred previously, although ds and ds’ need not to be the same
information.
3. Agent b might require that a be authenticated to have
participated with b in one particular run.
 This time a sequence of events is required, similar to that required by the
previous example, though both events must agree on some information.
 Modeling: Trace Specification

 We need to express the requirement

Event e precedes event d

 We can use a trace specification

tr' d  tr  e in tr'
 Modeling Yahalom (1)
 Authentication of initiator to responder
 Case 3 ~ Stricter Authentication
 Nonces (na, nb)
 Cryptographic Key (kab)

a  Honest  signal .Running _ Initiator.a.b.na .nb .kab precedes

signal .Commit _ Responder .b.a.na .nb .kab
 Modeling Yahalom (2)
Initiatora Responderb

a.na

 CSP Specification b.{a.na.nb}ServerKey(b)

Provided that the initiator is honest, we

guarantee authentication given that the ds {b.kab.na.nb}ServerKey(a).{a.kab}ServerKey(b)

information matches in the scheme signals. Run_Init.a.b.na.nb.kab

{a.kab}ServerKey(b).{nb}kab

The Running_initiator event correctly precedes the Com_Resp.b.a.na.nb.kab

Commit_Responder event and it is also correctly
performed after all the necessary information has
been sent back and forth and is thus available to
both parties.
Responder(b,nb) =
Initiator(a,na) =  receive.a.b.a.na  
 
env?b:Agent  send.a.b.a.na   send .b.J .b.{a.na .nb }ServerKey(b )  
[]
 receive.J .a.{b.k ab .na .nb }ServerKey( a ) .m    
kKey
a Agent 
receive.a.b.{a.k ab }ServerKey(b ) .{nb }kab  
[]   nNonce
kKey  signal .Running _ Initiator.a.b.na .nb .k ab    signal .Commit _ Responder .b.a.n .n .k  
nNonces
   a b ab

 send .a.b.m.{nb }kab  Session (a, b, k ab , na , nb ) 
mT
 Session ( b , a , k ab , n a , n b ) 
 Modeling Yahalom (3)
 Authentication of responder to initiator
 Case 2 ~ Looser Authentication
 Nonces (na, nb) ~ Required
 Cryptographic Key (kab) ~ Non required

b  Honest  signal .Running _ Responder .b.a.na .nb precedes

signal .Commit _ Initiator.a.b.na .nb .kab
 Modeling Yahalom (4)
 CSP Specification
Provided that the responder is honest, any commitment should establish that a corresponding Running event has
previously occurred. This assurance is independent of the key that the initiator has committed to, but it
does require agreement on the nonces.

Once again, the Commit signal must occur at the very end of the run of the protocol, although, this time the
Running event may occur right after the first signal, since the two events must only agree on the nonces, given
that na is available after the first message is sent, while nb is picked by the responder. As a consequence of such a
situation, a has a weaker authentication than b, in the sense that the protocol does not provide any guarantees
to a that b will ever obtains the key, and so authentication does not rely upon concordance of the cryptographic
key.

Initiator(a,na) = Responder(b,nb) =
env?b:Agent  send.a.b.a.na   receive.a.b.a.na  
 
 receive.J .a.{b.k ab .na .nb }ServerKey( a ) .m   []  signal .Running _ Responder .b.a.na .nb  
[]    
kKey
kKey
 send .a.b.m.{nb }kab   nNonces  send .b.J .b.{a.na .nb }ServerKey(b )  
nNonces   mT  receive.a.b.{a.k } 
 signal .Commit _ Initiator.a.b.na .nb .k ab   ab ServerKey ( b ) .{nb }k ab 
mT  
 Session (a, b, k , n , n )   Session (a, b, k , n , n ) 
 ab a b   ab a b 
 Non-repudiation
 It satisfies the need of sending and receiving messages providing
the parties involved with evidence so that neither of them can
successfully deny at a later time that the communication has
effectively taken place as agreed.

 Evidence is often in the form of signed messages, which provides

guarantees concerning their originator.

 Non repudiation might also provide mechanisms to guarantee

fairness.
 No party should ever – at anytime – have the evidence that they require without
the other party also having the required evidence.
 Non repudiation (2)
 Non-repudiation properties are expressed in a similar
way to authentication
 The occurrence of some event guarantees that some previous message was
sent. The provision of a certain piece of evidence should guarantee that a
particular message was previously sent by a particular party.

 The main objective of a non-repudiation protocol is thus

that of creating the evidence for the parties involved.
1. Correctness will be concerned with the suitability of the evidence.
2. Analysis will need to take into consideration the fact that each party might have
acted not in compliance with the protocol.

So each party is modeled almost as an intruder.

 Non repudiation (3)
 If each agent involved in the protocol is able to fire an event of the form
evidence.a.m for an agent a and a message m, the non-repudiation
property for the agent a is modeled as

evidence.a.m in tr => b sent m’

 Agent b is not required to be acting in compliance with the protocol so a

cannot be guaranteed that message m’ was actually sent by b as a well-
formed, complete message in accordance with the protocol specifications.
The non-repudiation property, though, guarantees a that m’ was somehow
issued by b.

 So, the sent predicate is actually defined as follows:

a sent m = (E) M : Fact ; b : Agent (send.a.b.M in tr & M contains m)

 Anonimity
 It is an unusual property for security protocols to
ensure, since it’s mostly required by malicious actions
rather than well-formed secured communication
protocols.

 Its main objective is that of protecting the identity of

agents with respect to particular events or messages.
 The messages need not to be protected.
 The model includes and separates between two different
entities:
1. the identity of the agents who sent a message
2. the content of the message itself.
 Anonimity (2)
 A data item that could have originated from one agent could equally
have been produced by any other.
 We define a set Anonuser
 Includes all users whose identities should be masked.

 Then, the set of messages we wish to confuse for a given piece of

information x is given by the set A

A = {a.x | a € Anonusers}

 In the CSP – model, one will provide anonymity on the set A if

 any arbitrary permutation of the events in A, applied to all the traces of
the system, for every occurrence of the set, does not change the
consistence and the identity of the traces of the Anonusers
agents