Security in Open Environments

1. Security in Open Environments

2. Overview • Types of attacks and countermeasures • Zero-knowledge protocols • Public-key Infrastructure

3. Security Models • Unconditional Security: an attacker can do no better than guessing. (one-time pad). • Complexity-theoretic security: Attacks are shown to be NP-complete. • Provable security: Attacks are as difficult as a problem that’s suspected to be hard (like factoring.) • Computational security: resources needed for an attack are beyond the capabilities of the attacker. • Ad hoc security/heuristic security: Practically, an attacker is unable to successfully break a system.

4. Man-in-the-Middle • Cryptographic Protocol attacks are often analyzed in terms of a man-in-the-middle • This is an agent who is able to listen to and potentially add, delete, or change messages being sent over an open channel.

5. Classes of Attacks • We can divide attacks roughly into two classes: • A passive attack is one in which the attacker is only able to monitor the communications channel. • Threatens confidentiality • An active attack is one in which the attacker attempts to add, delete, or modify messages. • Threatens both confidentiality and data integrity.

6. Attacks on encryption schemes • Passive attacks can be further subdivided • Ciphertext-only attacks attempt to deduce the plaintext from only the ciphertext. • Low chance of succeeding against strong encryption. • Known plaintext attacks: the attacker has access to a collection of plaintext messages and their corresponding ciphertext. • If same key is used to encrypt multiple blocks, frequency analysis is possible.

7. Attacks on encryption schemes • Chosen plaintext attack: the attacker gets to choose a message to be encrypted. • Goal: learn something about other ciphertexts. • This can be used to acquire a signed message. • “Please authenticate me.” • Adaptive chosen plaintext attack: attacker can iteratively choose plaintexts to be encrypted. • Chosen ciphertext attack: attacker chooses ciphertext and sees the corresponding plaintext. • Adaptive chosen ciphertext attack: attacker iteratively chooses ciphertexts and sees the corresponding plaintexts.

8. Active Attacks • Known-key attack: The attacker obtains previously-used keys and uses this to deduce information about new keys. • Tracks generation of pseudorandom numbers. • Replay: an attacker records a communication session and replays part of it at a later time. • Login, key exchange

9. Active Attacks • Impersonation: Attacker assumes the identity of one or more members of the network. • Reflection attack: A & B want to synchronize with secret keys – A sends a challenge to B • A -> m1 -> B • B -> E(m1, m2) -> A • A -> m2 -> B • Intruder intercepts, pretends to be B initiating the same protocol • Catches A’s response, pretends this is B’s response to the original challenge.

10. Active Attacks • Dictionary: Attacker uses a large list of words to deduce a password. • UNIX password attacks • Forward search: brute-force search of keyspace.

11. Active Attacks • Consider this authentication protocol: • A sends random number m1 to B. • B returns random numbers m1 and m2, signed, plus an identifier. • A returns signed random numbers m2 and m3, plus an identifier. A -> m1 -> B A <- m2, SB(m2, m1, A) <- B A -> m3, SA(m3, m2, B) -> B Intent: random numbers plus signatures will verify identity.

12. Active Attacks • An enemy E can initiate two separate protocols with A and B: • E -> m1 -> B • E <- m2, S_B(m2, m1, A) <- B • A <- m2 <- E • A -> m3, S_A(m3, m2, B) -> E E -> m3, S_A(m3, m2, B) -> B • Insecurity due to symmetry of messages • Could vary structure or require m1 to be included in final • message

13. Attacking Key Exchange • Key exchange is one of the most common places for a man-in-the-middle attack. • A sends B its public key. • Man-in-the-middle replaces A’s public key with a false one. • Man-in-the-middle is now able to intercept and decrypt secret messages from B to A.

14. Defeating Man-in-the-Middle • Interlock protocol: • A and B want to send messages to each other. • A sends first half to B. • B sends first half to A. • A sends second half to B. • B sends second half to A. • Since the man-in-the-middle cannot decrypt half of a message, it must pass something on. • Secure if the attacker cannot intelligibly mimic A or B.

15. Zero-knowledge Protocols • One application of public-key cryptography is zero-knowledge protocols. • Often, one party might want to prove or verify something to another without revealing any information • Nuclear treaties • Bank balances • Sensitive information • What are some real-world ways of solving this problem?

16. Zero-knowledge Protocols • Real-world solutions • Trusted third party • Random cups/phone numbers • Airline reservation • Passwords • Deck of cards

17. Zero-knowledge protocols • Alice wants to prove to Bob that she is Alice. • If she sends identification, Bob (or an eavesdropper) can use it. • Example: Authority chooses a number N=77, known by all. • Alice’s public ID: (58, 67) • Alice’s private ID: (9,10) • These are multiplicative inverses mod 77

18. Zero-knowledge protocols • Alice chooses some random numbers and computes their square mod N. • {19, 24, 51} -> 192(mod 77) = 53, 242(mod 77) = 37, 512(mod 77) = 60 • Alice sends {53,37,60} to Bob. • Bob sends back a random 2x3 matrix of 1s and 0s. • 0 1 • 1 0 • 1 1

19. Zero-knowledge protocols • Alice uses this grid, plus her original random numbers and her secret numbers, to compute: • 19 * 90 * 101 (mod 77) = 36 • 24 * 91 * 100 (mod 77) = 62 • 51 * 91 * 101 (mod 77) = 47 • She sends {36,62,47} to Bob.

20. Zero-knowledge protocols • Bob verifies Alice’s identity by computing: • {58,67} are Alice’s public numbers • 362 *580 *671 (mod 77)= 53 • 622 *581 * 670 (mod 77) = 37 • 472 * 581 * 671 (mod 77) = 60 • Alice’s original numbers reappear! • (Actually, an attacker would have a 1 in 64 chance of guessing correctly …)

21. Zero-knowledge protocols • In a real system, N would be very large • 160 digits. • Many more numbers would be generated. • This works because Alice’s secret numbers are multiplicative inverses of her public numbers mod N. • Also, Bob learns nothing that he didn’t know before.

22. Public-key Infrastructure • For real-world applications, a complex web of software systems is required to ensure security. • This is referred to as a Public Key Infrastructure (PKI). • Focus shifts from provable protocol properties to system design.

23. Some PKI Needs • We would like a PKI to ensure: • Data Integrity • Price Integrity • Scalable Identification and Authentication • Confidentiality • Non-repuduation • Interoperability

24. Trust Hierarchies • One of the primary functions of a PKI is the establishment of trust between users with no prior history. • A certificate authority can provide this, serving as a trusted third party.

25. Certificate Authority • A certificate authority has a number of functions within a PKI • Authentication • Key generation • Key revocation • Many commercial entities serve as CAs

26. Certificate Authorities • A Certificate Authority will wrap a user’s public key in a certificate. • X.509 is most common standard. • Contains the user’s identity and public key. • Signed with the CA’s private key. • Risk is shifted: • Previously: could unknown user A be compromised? • Now: could the CA be compromised?

27. Trust Models • Hierarchical • One root CA • Considered able to “vouch for” itself. • Scalable and fast • Tradeoff: More levels of hierarchy requires more work to design and maintain, but provides increased reliability/redundancy.

28. Example • Encrypting: • Alice generates a hash of her plaintext data. • Alice concatenates hash and plaintext. • Alice signs this with her private key. • Alice obtains Bob’s public key from a CA and uses this to encrypt the signed message.

29. Example • Decrypting: • Bob uses his private key to decrypt the message. • Bob then gets Alice’s public key from the CA. • Bob decrypts the message with Alice’s public key to get plaintext plus hash. • Bob computes the hash of the plaintext, verifying the integrity of the plaintext.

30. Trust Models • Distributed (Web of Trust) • No root CA • Users are able to authenticate each other • Same approach as P2P software • Highly redundant, but not very efficient. • Awkward fit for e-commerce.

31. Trust Models • Direct • Used with symmetric-key encryption • No CA is involved • Possession of secret key is sufficient for trust. • Also not appropriate for e-commerce.

32. Trust Models • Cross Certification • CA’s in different hierarchies sign each other’s public keys. • User A is trusted by Verisign, User B by Surety. • Surety signs Verisign’s public key with its own, allowing B to trust A. • Allows for scalable, dynamic trust networks.

33. Summary • Encryption provides a technique for hiding and sharing secrets. • To be effective, users must consider the system in which encryption is used. • Subtle flaws in a protocol can make it insecure. • A public key infrastructure is needed to provide secure communications