Download presentation

Presentation is loading. Please wait.

Published byKaitlyn Cardon Modified about 1 year ago

1
5 June 2002 - Lecture 1 1 TU Dresden - Ws on Proof Theory and Computation Formal Methods for Security Protocols Catuscia Palamidessi Penn State University, USA

2
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 2 Plan of the lectures A brief overview of Security Protocols A very brief overview of Cryptographic Methods A brief overview of Concurrency Theory Specification and Verification of SP The CSP/FDR approach Examples Modeling secrecy Modeling authentication The Needham-Schroeder PK protocol Modeling anonymity The spi calculus approach Examples Model checking unbounded systems

3
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 3 Security Protocols Aka Cryptographic Protocols Goals: Security services across a distributed system Establishing session keys between partners Authentication of agents and nodes Ensuring secrecy Ensuring integrity Ensuring anonymity...

4
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 4 Security Protocols How they work: Exchange of messages between nodes May involve a trusted third party Use of various cryptographic mechanisms Symmetric / asymmetric encryption Hash functions Digital signatures... Hostile environment Agents deliberately trying to undermine the protocol. In literature such hostile agents are also referred to as intruders, spies, enemies, attackers, evesdroppers, penetrators.

5
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 5 Security Protocols Example: The Needham-Schroeder Secret-Key (NSSK) protocol One of the earliest protocols Basis of the Kerberos authentication and authorization system It uses purely symmetric encryption algorithms Purpose: Enable two parties (Alice and Bob) to establish a secure channel of communication with the help of a trusted server (Jeeves) We assume that Alice and Bob share private, long-term keys with Jeeves so each of them is able to communicate securely with Jeeves Questions Why do we want a direct secure channel between Alice and Bob? Jeeves would become a bottleneck and a possible point of failure Communication along a very secure, long-term key is expensive Alice and Bob may not want to reveal their secrets to Jeeves Why don't we provide upfront a private long-term key for every pair of agents which may wish to communicate? N 2 keys required many keys may not be needed the number of agents may change dynamically long-term keys are more vulnerable or more expensive

6
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 6 Security Protocols Notation Message n x -> y : data in the n-th step agent x dispatches a message data to agent y n x a nonce generated by agent x. A nonce is a fresh, unique, unpredictable number {data} k the value data encrypted with key k m.n text m followed by (concatenated with) text n

7
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 7 Security Protocols Example: The NSSK protocol Alice (A) and Bob (B) establish a secure channel with the help of Jeeves (J) Message 1 A -> J : A.B.n A Message 2 J -> A :{n A.B.k AB.{k AB.A} ServerKey(B) } ServerKey(A) Message 3 A -> B : {k AB.A} ServerKey(B) Message 4 B -> A : {n B } k AB Message 5 A -> B : {n B - 1} k AB At the end A and B share a new key k AB generated by J

8
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 8 Security Properties To say that it a protocol is "secure" or "correct" does not mean anything. It is always necessary to specify exactly the properties that a security protocol is supposed to satisfy and the precise assumptions on the possible threats. Secrecy Secrecy properties can have various degrees of strength. E.g. (Strongest) Intruders cannot deduce anything about the activities of Bob and Alice (Weaker, but usually sufficient in practice) An intruder can see that Alice is sending a message to Bob, and maybe even have an idea of how long it is, but cannot decrypt the message. Weaker properties are usually easier to implement and to analyze Question does the NSSK protocol satisfy the strongest property? No, only the weaker one.

9
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 9 Security Properties Authentication of origin If Bob receives a message that claims to be originated by Alice, then Alice should have sent it. There may be various additional requirements: The message was intended The message was sent within a certain time Each message is received only once... Entity authentication Bob and Alice are sure of each other identities Integrity (Strongest) Intruders should not be able to corrupt messages (Weaker, but usually sufficient in practice) Corruption of messages can be always detected by the legitimate partners

10
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 10 Security Properties Authenticated key exchange If Alice receives a key K which she thinks is private between herself and Bob, then it must be the case that K is known only to Alice and Bob (plus, possibly, to a third trusted party) Non-repudiation If Bob receives a message sent by Alice, then it must be possible to prove that Alice has indeed sent the message (even if she tries to deny it). Question: Why Alice may want to deny it? Fairness Avoid that one of the parties ends the protocol part-way through in order to gain some unfair advantage over the other party. Question: What kind of advantage could the party gain? Anonymity We need to know that a certain action has been performed but no one should know which agent has performed it (except of course the agent itself) Question: What could be an example?

11
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 11 Cryptographic Methods Two kinds: Symmetric cryptography (aka Secret-key) Asymmetric cryptography (aka Public-key) Symmetric cryptography It requires that the two parties both know the same key. Each party can do both encryption and decryption. The first method to be discovered and used Until the advent of asymmetric cryptography, the governments and security agencies were rather protective about research done in this field. Public research and publications on this topic were not encouraged

12
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 12 Cryptographic Methods Symmetric methods Transposition: text reshuffling Substitution: text substituted with other text Stream: Each symbol of the text is encrypted individually Block: More than one symbol at the time are encrypted

13
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 13 Cryptographic Methods An example of block cipher: The Playfair cipher The letters of the alphabet are arranged in a table, and scrambled according to some rule. To encipher a pair of letters we first situate them in the table, then we take the pair of letters at the opposite corners. In the example represented in the table below, the rule for scrambling is the placement of the world DISLEXIA at the beginning of the table, and consequent shift of all other letters. For example, the pair PL is encrypted as QS. +---+ D Y|S L|E X I|A B|C F G|H K|M N O|P Q|R +---+ T U V W Z The Playfair cipher is simple, in the sense that the function AxA -> AxA is constant.

14
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 14 Cryptographic Methods Asymmetric cryptography Introduced in 1976 by Diffie and Hellman. Actually, it was invented slightly earlier by researchers at the GCHQ (Government Communications Headquarters), but the idea was not made public. It allows two parties to establish a shared secret by using only open communication channels. Basic idea: every agent A has two keys: PK : Public key, publicly known SK : Secret (or private) key, known only by the agent Whoever wants to send a message M to A, it will encrypt it by using PK, then send the result of the encryption, { M } PK, to A. A will then decrypt it by using SK. Let {{ M } PK } SK be the final result. The following property must hold: (a) {{ M } PK } SK = M In some scheme, like RSA (Rivest, Shamir and Adleman), also the reverse holds: (b){{ M } SK } PK = M Note: (a) implies that { } PK is injective and (b) implies that { } PK is injective. How to make sure that SK is really secret? Idea: Use one-way functions One-way function are easy to calculate in one direction, but intractable in the other direction. So, SK is not secret in an absolute sense, but it is secret in practice.

15
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 15 Cryptographic Methods Example Let p, q be prime. Calculating the product n = pq is easy, while calculating p and q given n is thought to be intractable Given an element of a finite field r, and a number m, calculating n = r m is easy, while calculuating m given r and n is thought to be intractable. So, we could use a one-way function f as the public key Encrypt: apply f to the message. Decrypt: apply the inverse of f to the encrypted message Question: This alone wouldn't work. Why? Idea: Use a trap-door Given a one-way function f, a trap-door is an information that makes it easy to calculate the inverse of f. Of course the trap-door relative to a secret key should be known only by the agent who owns the secret key. The trap-door should be hard to discover just from the knowledge of the encryption algorithm.

16
5 June 2002 - Lecture 1 TU Dresden - Ws on Proof Theory and Computation 16 Cryptographic Methods Example: The RSA algorithm (Rivlest, Shamir, Adleman) Choose two large primes p an q and calculate their product n = pq Choose an integer e with the feature of being relatively prime to (p-1)(q-1) Choose an integer d with the property that ed = 1 (mod (p-1)(q-1)) Using Fermat's Little theorem, we know that m ed = m (mod n) e and n are made public, while p, q and d are kept secret. Encryption: given a message (number) m < n, compute c = m e (mod n) Decryption: given an encrypted message c, compute c d. By the Fermat's Little theorem, we have c d = m ed = m (mod n) To derive p and q (and hence d) from n is believed to be intractable.

Similar presentations

© 2017 SlidePlayer.com Inc.

All rights reserved.

Ads by Google