How can keys be exchanged?

• Public Key: Broadcast the public key
1. How do we know the public key belongs to the claimed user?
2. Problem with distributing the binding between the user and the key
3. Trusted 3^rd party may be used to establish trust
• Shared Key
1. Similar mechanism to public key, still have to get the key out there once.
• Session keys
1. Include timestamps and nonces to prevent replay attacks
2. Easy to establish session keys if you already have a secure channel.
3. What if you don’t have a secure channel?
• Use trusted 3^rd party to provide session key
• Bootstrap problem: How do you create an agreement with the trusted third party?
• If you have a shared key with the 3^rd party, you must have already negotiated a key out of band.
• Or use a method like ssh. ssh server sends a key the first time you negotiate with it and you decide whether or not to accept it.
• How secure is the protocol? Usually very hard to formally prove correctness of protocol because you need to check all attack scenarios.
• Needham Schroeder Key Distribution
1. send source, destination, and nonce to mediator
2. mediator uses shared secret key with source to send session key, the nonce, and the destination. It also sends the session key encrypted using the shared secret key between the mediator and the destination
3. source sends destination the encrypted session key
4. destination sends source a nonce encrypted with session key
5. source sends back nonce-1 to the destination
• It can’t just send back nonce, because B sent it nonce which is already encrypted with the shared session key
• Here are a few attack scenarios from the lecture slides:
• Attack scenario 1
• C intercepts message from T
• C can’t decrypt the message
• Changing the message can be detected and forwarding/storing the message does no harm
• Attack scenario 2
• C pretends to be T. A sends message to with information that A wants to authenticate with B. C(T) then forwards the message to the real T while pretending to be A with information that A wants to authenticate with C.
• T returns A, but A can detect the change because it is expecting B in the message but sees C.
• Attack scenario 3
• C intercepts original request to T and C itself sends message to T indicating that C wants to authenticate with B. T returns message with key K{CT} and only C can decrypt. A cannot decrypt the message.
• Attack scenario 4
• C pretends to be A to B. But the user C is in KBT{KB,C} so B will detect C is not A.
• Valid Attack
• Attacker records all messages on the network.
• Consider an attack that manages to get an old session key.
• Attacker masquerades as Alice by replaying starting from step 3 of the protocol, but using the message corresponding to the old session key.
• This is outside the Dolev-Yao model since in the model, we assume the attacker can’t get the session key.
• C would need to use computation power to get the key. Possibly by looking at traffic encrypted by the session key.
• This can be prevented with timestamps or adding a lifetime to the key.
• Kerberos
• Used at Penn
1. Central server grants tickets to clients.
2. Tickets supposed to be unforgeable, non-replayable, authenticated, represent authority.
3. Use authenticates to Kerberos Server (password authentication)
4. Server returns the Ticket Granting Ticket
5. Gives the capability to ask for tickets from the ticket granting server
6. Server creates an authentication key and transmits it to the ticket granting server
7. User can then make a service request to the then send service request to the file server or any other server using the service ticket
8. The Kerberos server and ticket granting server could be on the same machine.
9. Passwords aren’t actualy transmitted. The server uses the password to generate a key to encrypt the TGT. The client uses the same password to generate the same key to decrypt the TGT. If the passwords don’t match, then the client won’t be able to decrypt the TGT.