Presentation is loading. Please wait.

Presentation is loading. Please wait.

Network Authentication Protocol Studies (NAPS): The Theory of Secure Design Jim Alves-Foss Gurdeep Sing Hura University of Idaho Moscow, Idaho.

Similar presentations


Presentation on theme: "Network Authentication Protocol Studies (NAPS): The Theory of Secure Design Jim Alves-Foss Gurdeep Sing Hura University of Idaho Moscow, Idaho."— Presentation transcript:

1 Network Authentication Protocol Studies (NAPS): The Theory of Secure Design Jim Alves-Foss Gurdeep Sing Hura University of Idaho Moscow, Idaho

2 August 20, 2002 DARPA, OASIS PI Meeting2 Focus of This Research Enhance the design and analysis techniques used for modern security protocols Enhance the design and analysis techniques used for modern security protocols  Current protocols are often successfully attacked, Why? Present an implementation technique that will ensure protocols are secure against attacks. Present an implementation technique that will ensure protocols are secure against attacks.  Assuming certain security properties of underlying crypto, key management software, operating system and hardware

3 August 20, 2002 DARPA, OASIS PI Meeting3 Status Timetable Timetable  New project, started mid June 2002  Terminates December 2003 Research team Research team  2 Faculty, 2/3 students Commenced with initial tasks, exploring some relevant issues discussed here Commenced with initial tasks, exploring some relevant issues discussed here  Extension of a formal model of protocols, codifying in ACL2 theorem prover  Evaluating sample protocols and attack space mapping into formalism  Exploration into a “semantic gap” issues

4 August 20, 2002 DARPA, OASIS PI Meeting4 What is a Security Protocol? A set of messages designed to establish a desired security property between communicating agents, (players). A set of messages designed to establish a desired security property between communicating agents, (players).  Authentication, privacy, integrity, non-repudiation  May wish to provide key distribution, establishment of secure communication channel, proof of liveness, Used in banking, e-commerce, distributed systems, mobile communications, etc. Used in banking, e-commerce, distributed systems, mobile communications, etc.

5 August 20, 2002 DARPA, OASIS PI Meeting5 Cryptographic Protocol Notation Encryption Encryption  {…} K AB – Uses private key shared between A and B  {…} K A – Uses public part of A’s public key  {…} K A -1 – Uses private part of A’s public key Other Terms Other Terms  M.N – Concatenation of M followed by N  R A - random value generated by A for use as a nonce or part of a Diffie-Hellman style key- generation for use as a nonce or part of a Diffie-Hellman style key- generation

6 August 20, 2002 DARPA, OASIS PI Meeting6 Example “Secure” Protocol Adapted From: Needham Schroeder, “Using Encryption for Authentication in Large Networks of Computers”, Communications of the ACM, 21(12), December 1978, pg. 993-999. A.B.{R A } K B AnnBob B.A.{R A,R B } K A “A mutual authentication protocol” A.B.{R B } K B

7 August 20, 2002 DARPA, OASIS PI Meeting7 Sample Attack: Replay When the attacker takes a message generated by a communicating party and inserts it into the communication stream of an executing protocol in order to spoof a user of the protocol. When the attacker takes a message generated by a communicating party and inserts it into the communication stream of an executing protocol in order to spoof a user of the protocol.  earlier component from current protocol run  earlier component from previous protocol run  component from concurrent protocol run

8 August 20, 2002 DARPA, OASIS PI Meeting8 Attack on NS Protocol Adapted From: Lowe, “Breaking and Fixing the Needham-Schroeder Public-Key Protocol Using FDR,”, Proc. TACAS, 1996, pp. 147-166. “An attack on the mutual authentication protocol” A.E.{R A } K E Ann E.A.{R A,R B } K A A.E.{R B } K E E(A).B.{R A } K B Bob B.E(A).{R A,R B } K A E(A).B.{R B } K B EVE

9 August 20, 2002 DARPA, OASIS PI Meeting9 Other Problems Numerous Attacks have been published against protocols that don’t use correct labeling Numerous Attacks have been published against protocols that don’t use correct labeling Recent: Catherine Meadows, FCS June 2002 Recent: Catherine Meadows, FCS June 2002  Discovered an attack on a draft group multicast protocol, GDOI, where a dishonest participant could force a signature, generating a fake new group key. This occurred when a signature key was used to sign two different messages in the protocol, where the messages were not well labeled. This occurred when a signature key was used to sign two different messages in the protocol, where the messages were not well labeled.  Developed formalism for defining and detecting probabilities of “type confusion” between sets of generated messages.

10 August 20, 2002 DARPA, OASIS PI Meeting10 What Happened? We used cryptography, it should be secure!! We used cryptography, it should be secure!! Designers/analysts must correctly interpret the semantics of cryptographic services and how they are used. Designers/analysts must correctly interpret the semantics of cryptographic services and how they are used.

11 August 20, 2002 DARPA, OASIS PI Meeting11 What Really Happens in Protocol Message Exchange? Ann needs to determine what happened in the “Mysterious Beyond” between the transmission of message M1 and the receipt of Message M2 Mysterious Beyond Ann’s Protocol M1 M2

12 August 20, 2002 DARPA, OASIS PI Meeting12 Semantic Assumptions Proof carrying assumptions Proof carrying assumptions  Receiver can tell if a message is correctly decrypted (sender used correct protocol and key) easy when crypto algorithm includes encrypted checksums easy when crypto algorithm includes encrypted checksums  Receiver can determine partial ordering on messages Easy if initial message included a new/unique number (nonce) and response also includes that number where number must have been cryptographically “handled” Easy if initial message included a new/unique number (nonce) and response also includes that number where number must have been cryptographically “handled”  Receiver can tell if a message is well-formed and well-typed Not easy if there exists a collision in the type labels (if they even exist) of different messages. Not easy if there exists a collision in the type labels (if they even exist) of different messages. Why? Because the bad guys can cheat, and good guys make mistakes or do their own thing. Why? Because the bad guys can cheat, and good guys make mistakes or do their own thing.

13 August 20, 2002 DARPA, OASIS PI Meeting13 Semantics of Crypto Services Crypto Semantics (Axioms assumed of Crypto Services) Crypto Semantics (Axioms assumed of Crypto Services)  Handling – creation or reading of specific message contents (not relaying, but content handling) {…} K AB – A or B was last player to handle message and A or B will be next player to handle message {…} K AB – A or B was last player to handle message and A or B will be next player to handle message {…} K A – A is next subject to handle message {…} K A – A is next subject to handle message {…} K A -1 – A was last subject to handle message {…} K A -1 – A was last subject to handle message  The semantics are not Context-Sensitive Cryptography provides no requirement that the sender is operating within the same context as the receiver. We must add additional semantic constraints at a higher level Cryptography provides no requirement that the sender is operating within the same context as the receiver. We must add additional semantic constraints at a higher level

14 August 20, 2002 DARPA, OASIS PI Meeting14 Semantic Layering TCP/IP Stack Application Protocol Crypto Engine Reliable End-To-End Transport Handling Semantics; Can Determine Last/Next Handler Authentication? Key Distribution? Privacy? Non- Repudiation? Integrity? Liveness? Freshness? Want: Privacy, Integrity, Authentication, Non-repudiation Semantic Gap

15 August 20, 2002 DARPA, OASIS PI Meeting15 How Do We Prevent Replay Attacks? Uniquely identify each encrypted component of every message transmitted. This requires: Uniquely identify each encrypted component of every message transmitted. This requires:  Session ID, established prior to protocol run; unique for every run of the protocol  Component ID, established at protocol design time.  IDs are encrypted within each message.  These ideas are similar to those already in literature but have unique properties. Does this prevent the bad guys from cheating? Does this prevent the bad guys from cheating?

16 August 20, 2002 DARPA, OASIS PI Meeting16 Does labeling ever work? Yes, if we can guarantee disjoint encryption Yes, if we can guarantee disjoint encryption  Sufficient - to prevent cryptographic replays  Necessary – we believe so, needs proof Possible if: Possible if:  Every protocol uses the same rules and encoding we know vendors/designers will agree ;-) we know vendors/designers will agree ;-)  –or– Keys are enforceably bound to specific PROTOCOLS (we know users are willing to manage many keys) this means you need a key for each version/implementation of each crypto protocol on your system (expensive for certified public keys) this means you need a key for each version/implementation of each crypto protocol on your system (expensive for certified public keys)  –or– Crypto engines provide “context sensitive” encryption services

17 August 20, 2002 DARPA, OASIS PI Meeting17 PAPI Proposed solution: Protocol Services Layer Proposed solution: Protocol Services Layer  forces unique labeling. Implementation: Protocol Application Programmers Interface (PAPI) Implementation: Protocol Application Programmers Interface (PAPI) Protocol Services Layer Security Services Provider Network Services Layer Application Layer CDSA, MS CryptoAPI, JCE, Entrust TCP/IP, Sockets SSL, IPSE C, PAPI Prohibited in our approach, not in other approaches

18 August 20, 2002 DARPA, OASIS PI Meeting18 Tasks of this Project 1. Expand Existing Formal Analysis Model  Reason about wider classes of attacks  Validate with existing protocols/attacks 2. Develop Software Engineering Methodology for Secure Protocol Development 3. Demonstrate Feasibility on Simple Protocols 4. Demonstrate Feasibility on Fault Tolerant Survivable Network Management System

19 August 20, 2002 DARPA, OASIS PI Meeting19 Formal Model Use Strand Space Model Use Strand Space Model  Developed by Fábrega, Herzog & Guttman  Model Defines: Facts: messages, plain-text and encrypted (we add labels (tags) to our messages to uniquely identify cryptographic components) Facts: messages, plain-text and encrypted (we add labels (tags) to our messages to uniquely identify cryptographic components) Strands: consist of transmissions and receptions of facts Strands: consist of transmissions and receptions of facts Bundles: consist of interactions between strands Bundles: consist of interactions between strands Honest Strand: Define behavior of “good guys” Honest Strand: Define behavior of “good guys” Intruder Strand: fits a model of behavior that has control over network messages; we add replaying to allow for run- external attacks Intruder Strand: fits a model of behavior that has control over network messages; we add replaying to allow for run- external attacks

20 August 20, 2002 DARPA, OASIS PI Meeting20 Proofs We Prove We Prove  If there exists a successful attack against a protocol implemented using our tagging scheme, then there must exist an equivalent attack against the protocol that does not use replays.  Therefore, no replay attacks exist under our tagging scheme.  Following example is for an attack against authentication

21 August 20, 2002 DARPA, OASIS PI Meeting21 Proof Details Initially Initially  We assume honest players tag correctly and do not accept ill-tagged facts. May either ignore ill-tagged messages or abort protocol run May either ignore ill-tagged messages or abort protocol run  We define a retagging method  () that takes facts of one bundle and correctly tags them according to our scheme. This is fair to do, since ill-tagged facts will be discarded by honest players. This is fair to do, since ill-tagged facts will be discarded by honest players.

22 August 20, 2002 DARPA, OASIS PI Meeting22 More proof details Assume there exists an attack against the tagged bundle C; where no secret keys are compromised. Assume there exists an attack against the tagged bundle C; where no secret keys are compromised. Assume there exists a strand of minimal height that represent acceptance of authentication; but no corresponding honest sender Assume there exists a strand of minimal height that represent acceptance of authentication; but no corresponding honest sender We then take the bundle and retag it with  () to get C’; which is secure against replays since all messages are well-tagged, and honest players will not accept ill-tagged messages We then take the bundle and retag it with  () to get C’; which is secure against replays since all messages are well-tagged, and honest players will not accept ill-tagged messages We prove that the re-tagged attack still works., there fore the crucial portion of the attack was not dependent upon replays. We prove that the re-tagged attack still works., there fore the crucial portion of the attack was not dependent upon replays.

23 August 20, 2002 DARPA, OASIS PI Meeting23 Next Steps 1. Continue with extending strand space model to address new attacks and engineering approaches Replay attacks Replay attacks Guessing and probabilistic attacks Guessing and probabilistic attacks Fault Tolerant Design Issues Fault Tolerant Design Issues 2. Formalize Semantic Gap Is disjoint encryption necessary? Is disjoint encryption necessary? Under what assumptions is disjoint encryption possible. Under what assumptions is disjoint encryption possible.

24 August 20, 2002 DARPA, OASIS PI Meeting24 Further Steps 3. Once we resolve model and semantic issues, map these into software engineering methodology. 4. Start applying model and methodology to existing protocols

25 August 20, 2002 DARPA, OASIS PI Meeting25 Thank you.

26 August 20, 2002 DARPA, OASIS PI Meeting26 Security Service Requirements Always invoked Always invoked Non-bypassable Non-bypassable Tamperproof Tamperproof Evaluatable Evaluatable


Download ppt "Network Authentication Protocol Studies (NAPS): The Theory of Secure Design Jim Alves-Foss Gurdeep Sing Hura University of Idaho Moscow, Idaho."

Similar presentations


Ads by Google