1. Security attacks

2. 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

3. Secret-key cryptography

4. Public-key cryptography

5. Encryption modes Electronic Code Book mode (ECB)
Output Feedback mode (OFB)

6. Hash function

7. Signature

8. 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

9. CSP - Basic Building Blocks
Visible Events and Internal Action (S - t)
Basic Operators
Parallelism
Advanced Constructs
Hiding
Renaming
Stop the process that does nothing
event prefix
event prefix choice
input prefix choice
choice between two processes
general choice
P П Q nondeterministic choice
∏ S general nondeterministic choice
lockstep parallel
synchronizing parallel
interface parallel
general interleaving
event hiding
process relational renaming
successful termination
sequential composition
recursive definition
Stop – is the simplest process of all. It doesn’t do anything: no internal action and no visible action either
aP – is the process that performs the communication a and then behaves like P.
?x:AP(x) - is the process that offers to the environment all of the actions in A≤ Sigma and when a is chosen the system behaves as P(a)
in?x – allows the environment sny communication of the form in.x, where x ranges over the type of in
c?x – is the correspoding output form

10. Process Behavior Deadlocks, Livelocks, Nondeterminism
Traces model of CSP
Recursion
Time: Timed CSP or tock Event

11. 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:

12. The three participants A, B and S respectively perform:

13. 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)

14. 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.

15. 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.

16. 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.

17. 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.

18. 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..)

19. Authentication Schemes
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.
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.
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.

20. Modeling: Trace Specification
We need to express the requirement
Event e precedes event d
We can use a trace specification

21. Modeling Yahalom (1) Authentication of initiator to responder
Case 3 ~ Stricter Authentication
Nonces (na, nb)
Cryptographic Key (kab)

22. Modeling Yahalom (2) CSP Specification
Initiatora
Responderb
CSP Specification
Provided that the initiator is honest, we guarantee authentication given that the ds information matches in the scheme signals.
The Running_initiator event correctly precedes the 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.
a.na
b.{a.na.nb}ServerKey(b)
{b.kab.na.nb}ServerKey(a).{a.kab}ServerKey(b)
Run_Init.a.b.na.nb.kab
{a.kab}ServerKey(b).{nb}kab
Com_Resp.b.a.na.nb.kab
Responder(b,nb) =
Initiator(a,na) = env?b:Agent  send.a.b.a.na 

23. Modeling Yahalom (3) Authentication of responder to initiator
Case 2 ~ Looser Authentication
Nonces (na, nb) ~ Required
Cryptographic Key (kab) ~ Non required

24. 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) =
env?b:Agent  send.a.b.a.na 
Responder(b,nb) =

25. 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.

26. 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.
Correctness will be concerned with the suitability of the evidence.
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.

27. 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)

28. 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:
the identity of the agents who sent a message
the content of the message itself.

29. 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