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, (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 Scalable and fast
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