Todays Lecture

1
Todays Lecture

• intro to security in networking
• confidentiality
• integrity
• authentication
• authorization
• orientation for assignment 3

2
Security Goals

• confidentiality Who can read this data?
• integrity Who can modify this data?
• authentication Who am I talking to?
• authorization Is this person allowed to do this
  operation?

3
Network Security Challenges

• on the net, often communicate indirectly, through
  intermediaries
• intermediaries can eavesdrop or corrupt messages
• interact with unlimited number of parties
• frequent interactions with untrusted people

4
Private Communication
Practical issues - security of end systems -
how to establish a shared secret key
5
In Assignment 3...

• use AcmeNet.Util.AcmeCipher cipher
• constructor
• cipher new AcmeCipher(long key)
• to encrypt a byte
• ciphertext cipher.crypt(plaintext)
• same to decrypt
• 64-bit (Java long) key

6
Key Establishment

• use armed courier
• slow and expensive
• use face-to-face meeting
• doesnt scale
• use cryptographic tricks
• good no face-to-face meeting required
• bad hard to get right

7
Diffie-Hellman Algorithm

• the big picture
• two strangers have a public conversation
• result is a secret shared between them
• eavesdroppers cant learn the secret
• patented patent expired in September
• relies on difficulty of finding discrete log
• assume g and p are chosen cleverly
• given gx mod p, very hard to determine x

8
Diffie-Hellman in Action
9
But Wait...
Alice
Dr. Evil
Bob
10
Whats Going On?

• Diffie-Hellman gives you a private connection to
  somebody
• but you dont know who is at the other end
• need to take separate steps to prevent
  man-in-the-middle attack
• digitally sign Diffie-Hellman messages, or
• do separate authentication phase later

11
In Assignment 3...

• AcmeNet.Util.DiffieHellman class implements the
  math
• built-in choice of g, p
• to do an exchange
• make a new DiffieHellman object
• read its gx field and send it across
• get arriving message and pass it to the
  gotMessage method of your Diffie-Hellman object
• use the key field of the Diffie-Hellman object

12
In Assignment 3...

• PrivateConnection class extends Connection,
  adding privacy
• start with an ordinary Connection
• do a Diffie-Hellman exchange on the connection to
  generate a private key
• encrypt subsequent data on the connection with
  the DH-generated key
• no guarantees about who is on the other end

13
Authentication

• How can we protect against impersonation?
• two approaches
• digital signatures (and similar schemes)
• trusted third party
• usual approach claim identity, then prove it
• sometimes, authenticate and exchange keys in a
  single protocol

14
Digital Signatures

• everybody has two keys
• a private key for signing
• a public key for verifying signatures
• need a secure way to find the keys of others
• trusted certification authority signs key
  certificates, or
• letter of introduction approach

15
Using Signatures (First Try)

• challenge/response protocol
• how Alice proves her identity to Bob
• Bob sends a random challenge to Alice
• Alice signs the challenge and sends it back
• Bob verifies the signature
• prone to man-in-the-middle attack

16
Signatures and Diffie-Hellman

• after D-H exchange, each side concatenates the
  message it sent and the message it received, and
  signs the pair
• verify the other sides signature
• nice synergy
• message sent by D-H acts as a challenge
• signatures protect D-H from man-in-the-middle

17
Trusted Third Party Auth.

• Alice and Bob have a three-way conversation with
  a third party (Trent)
• result is a key that only Alice and Bob know
• no need for signatures or public-key crypto
• Trent must be completely trustworthy or all is
  lost
• each party must share a key with Trent

18
Needham-Schroeder Protocol

• steps
• Alice and Bob state their identities
• they could be lying!
• Alice sends to Trent (Alice, Bob, na)
• Trent generates a key K, creates a ticket
  (Alice, K) and encrypts it with Bobs key
• Trent sends to Alice (na, Bob, K,
  encrypted-ticket), all encrypted with Alices key
• Alice sends the encrypted ticket to Bob

19
Needham-Schroeder

• in the end, either
• Both parties are telling the truth about their
  identities, and both know the key K, or
• at least one party is lying, and the liar doesnt
  know K
• do a challenge-response handshake to verify
  knowledge of K in both directions
• if handshake works, use K to encrypt data

20
Key Verification Handshake

• steps
• set up encryption using the new key K
• actually, use K in one direction, K1 in the
  other
• send a random challenge to the other side
• receive the other sides challenge, and add one
  to it send the result back
• verify the other sides response

21
In Assignment 3...

• use a modified version of Needham-Schroeder
  protocol
• set up PrivateConnection
• do key-exchange/auth protocol
• switch to newly generated shared key
• trusted AuthenticationService lives at a
  well-known location
• talk to AuthService via PrivateConnection

22
In Assignment 3...

• each student has his/her own identity
• String identity equal to Unix userid
• each student shares a key with the AuthService
• 64-bit value
• think of it as a password
• stored in protected file accessible to AuthService

23
Generating Your Key

• can use AcmeNet.Util.Login to translate a String
  or byte-array into a Java long
• can use text passphrase rather than a number
• email exchange to set up keys
• please dont
• use a serious secret as your key
• use an easily guessable key
• use the Assn 3 algorithms for high security
  applications

24
More About Security

• public-key cryptography
• key management issues
• tamper-proof devices
• authorization
• logging, auditing and post-mortem repair
• intrusion detection
• policy creation and enforcement
• etc.