Security attacks

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. Visible Events and Internal Action (S - t) Basic Operators Parallelism Advanced Constructs Hiding Renaming Stopthe 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 CSP - Basic Building Blocks

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 • Agentb 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) Responderb Initiatora a.na • 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. Initiator(a,na) = env?b:Agent  send.a.b.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) =

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 sentm’ • 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 sentm = (E) M : Fact ; b : Agent (send.a.b.M in tr & Mcontainsm)

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