Lecture 25 Secure Communications CPE 401 / 601 Computer Network Systems slides are modified from Jim Kurose & Keith Ross and Dave Hollinger

Secure Protocols  There are a growing number of applications for secure protocols   electronic commerce  electronic voting  Many application protocols include the use of cryptography as part of application level protocol  The Cryptographic scheme employed is part of the protocol  If stronger cryptographic tools become available we need to change the protocol Secure Communications 2

Message Integrity Bob receives msg from Alice, wants to ensure:  message originally came from Alice  message not changed since sent by Alice Cryptographic Hash:  takes input m, produces fixed length value, H(m)  e.g., as in Internet checksum  computationally infeasible to find two different messages, x, y such that H(x) = H(y)  equivalently: given m = H(x), (x unknown), can not determine x.  note: Internet checksum fails this requirement! Secure Communications 3

Internet checksum: poor crypto hash function Internet checksum has some properties of hash function: ü produces fixed length digest (16-bit sum) of message ü is many-to-one But given message with given hash value, it is easy to find another message with same hash value: I O U B O B 49 4F E F 42 message ASCII format B2 C1 D2 AC I O U B O B 49 4F E F 42 message ASCII format B2 C1 D2 AC different messages but identical checksums! Secure Communications 4

Message Authentication Code m s (shared secret) (message) H(. ) H(m+s) public Internet append m H(m+s) s compare m H(m+s) H(. ) H(m+s) (shared secret) Secure Communications 5

MACs in practice  MD5 hash function widely used (RFC 1321)  computes 128-bit MAC in 4-step process.  arbitrary 128-bit string x, appears difficult to construct msg m whose MD5 hash is equal to x recent (2005) attacks on MD5  SHA-1 is also used  US standard [ NIST, FIPS PUB 180-1]  160-bit MAC Secure Communications 6

Digital Signatures cryptographic technique analogous to hand- written signatures.  sender (Bob) digitally signs document, establishing he is document owner/creator.  verifiable, nonforgeable:  recipient (Alice) can prove to someone that Bob, and no one else (including Alice), must have signed document Secure Communications 7

Digital Signatures simple digital signature for message m:  Bob “signs” m by encrypting with his private key K B, creating “signed” message, K B (m) - - Dear Alice Oh, how I have missed you. I think of you all the time! …(blah blah blah) Bob Bob’s message, m public key encryption algorithm Bob’s private key K B - Bob’s message, m, signed (encrypted) with his private key K B - (m) Secure Communications 8

Digital Signatures (more)  suppose Alice receives msg m, digital signature K B (m)  Alice verifies m signed by Bob by applying Bob’s public key K B to K B (m) then checks K B (K B (m) ) = m.  if K B (K B (m) ) = m, whoever signed m must have used Bob’s private key. Alice thus verifies that: ü Bob signed m. ü No one else signed m. ü Bob signed m and not m’. non-repudiation: Alice can take m, and signature K B (m) to court and prove that Bob signed m Secure Communications 9

Digital signature = signed MAC Alice verifies signature and integrity of digitally signed message: large message m H: hash function H(m) digital signature (encrypt) Bob’s private key K B - + Bob sends digitally signed message: K B (H(m)) - encrypted msg digest K B (H(m)) - encrypted msg digest large message m H: hash function H(m) digital signature (decrypt) H(m) Bob’s public key K B + equal ? Secure Communications 10

Public Key Certification public key problem:  When Alice obtains Bob’s public key (from web site, , diskette), how does she know it is Bob’s public key, not Trudy’s? solution:  trusted certification authority (CA) Secure Communications 11

 Certification Authority (CA): binds public key to particular entity, E.  E registers its public key with CA.  E provides “proof of identity” to CA.  CA creates certificate binding E to its public key.  certificate containing E’s public key digitally signed by CA: CA says “This is E’s public key.” Certification Authorities Bob’s public key K B + Bob’s identifying information digital signature (encrypt) CA private key K CA - K B + certificate for Bob’s public key, signed by CA - K CA (K ) B + Secure Communications 12

 when Alice wants Bob’s public key:  gets Bob’s certificate (Bob or elsewhere).  apply CA’s public key to Bob’s certificate, get Bob’s public key Certification Authorities Bob’s public key K B + digital signature (decrypt) CA public key K CA + K B + - K (K ) B + Secure Communications 13

Secure Alice:  generates random symmetric private key, K S.  encrypts message with K S (for efficiency)  also encrypts K S with Bob’s public key.  sends both K S (m) and K B (K S ) to Bob.  Alice wants to send confidential , m, to Bob. K S ( ). K B ( ) K S (m ) K B (K S ) + m KSKS KSKS KBKB + Internet K S ( ). K B ( ). - KBKB - KSKS m K S (m ) K B (K S ) + Secure Communications 14

Secure Bob:  uses his private key to decrypt and recover K S  uses K S to decrypt K S (m) to recover m  Alice wants to send confidential , m, to Bob. K S ( ). K B ( ) K S (m ) K B (K S ) + m KSKS KSKS KBKB + Internet K S ( ). K B ( ). - KBKB - KSKS m K S (m ) K B (K S ) + Secure Communications 15

Secure (continued) Alice wants to provide sender authentication message integrity. Alice digitally signs message. sends both message (in the clear) and digital signature. H( ). K A ( ) H(m ) K A (H(m)) - m KAKA - Internet m K A ( ). + KAKA + K A (H(m)) - m H( ). H(m ) compare Secure Communications 16

Secure (continued) Alice wants to provide secrecy, sender authentication, message integrity. Alice uses three keys: her private key, Bob’s public key, newly created symmetric key H( ). K A ( ). - + K A (H(m)) - m KAKA - m K S ( ). K B ( ). + + K B (K S ) + KSKS KBKB + Internet KSKS Secure Communications 17

Pretty good privacy (PGP)  Internet encryption scheme,  de-facto standard.  uses  symmetric key cryptography,  public key cryptography,  hash function, and  digital signature as described .  provides  secrecy,  sender authentication,  integrity. ---BEGIN PGP SIGNED MESSAGE--- Hash: SHA1 Bob:My husband is out of town tonight.Passionately yours, Alice ---BEGIN PGP SIGNATURE--- Version: PGP 5.0 Charset: noconv yhHJRHhGJGhgg/12EpJ+lo8gE4vB3mqJ hFEvZP9t6n7G6m5Gw2 ---END PGP SIGNATURE--- A PGP signed message: Secure Communications 18

Secure sockets layer (SSL)  provides transport layer security to any TCP-based application using SSL services.  e.g., between Web browsers, servers for e-commerce  security services:  server authentication,  data encryption,  client authentication (optional) TCP IP TCP enhanced with SSL TCP socket Application TCP IP TCP API SSL sublayer Application SSL socket Secure Communications 19

SSL: three phases 1. Handshake:  Bob establishes TCP connection to Alice  authenticates Alice via CA signed certificate  sends master secret key to Alice  encrypted with Alice’s public key  nonce exchange not shown SSL hello certificate K A + (MS) TCP SYN TCP SYNACK TCP ACK decrypt using K A - to get MS create Master Secret (MS) Secure Communications 20

SSL: three phases 2. Key Derivation:  Alice, Bob use shared secret (MS) to generate 4 keys:  E B : Bob->Alice data encryption key  E A : Alice->Bob data encryption key  M B : Bob->Alice MAC key  M A : Alice->Bob MAC key  encryption and MAC algorithms negotiable between Bob, Alice Secure Communications 21

SSL: three phases 3. Data transfer H( ). MBMB b 1 b 2 b 3 … b n d dH(d) d H( ). EBEB TCP byte stream block n bytes together compute MAC encrypt d, MAC, SSL seq. # SSL seq. # dH(d) Type Ver Len SSL record format encrypted using E B unencrypted Secure Communications 22

HTTPS Usage  HTTPS is HTTP running over SSL.  used for most secure web transactions.  HTTPS server usually runs on port 443.  Include notion of verification of server via a certificate.  Central trusted source of certificates. Secure Communications 23

IPsec: Network Layer Security  network-layer secrecy:  sending host encrypts the data in IP datagram  TCP and UDP segments; ICMP and SNMP messages.  network-layer authentication  destination host can authenticate source IP address  two principal protocols:  authentication header (AH) protocol  encapsulation security payload (ESP) protocol  for both AH and ESP, source, destination handshake:  create network-layer logical channel called a security association (SA)  each SA unidirectional.  uniquely determined by:  security protocol (AH or ESP)  source IP address  32-bit connection ID Secure Communications 24

Authentication Header (AH) Protocol  provides source authentication, data integrity, no confidentiality  AH header inserted between IP header, data field.  protocol field: 51  intermediate routers process datagrams as usual AH header includes:  connection identifier  authentication data: source- signed message digest calculated over original IP datagram.  next header field: specifies type of data (e.g., TCP, UDP, ICMP) IP headerdata (e.g., TCP, UDP segment) AH header Secure Communications 25

ESP Protocol  provides secrecy, host authentication, data integrity.  data, ESP trailer encrypted.  next header field is in ESP trailer.  ESP authentication field is similar to AH authentication field.  Protocol = 50. IP header TCP/UDP segment ESP header ESP trailer ESP authent. encrypted authenticated Secure Communications 26

Kerberos  Trusted 3rd party authentication scheme  Assumes that hosts are not trustworthy  Requires that each client (each request for service) prove it’s identity  Does not require user to enter password every time a service is requested! Kerberos 28

Kerberos Design  User must identify itself once at the beginning of a workstation session  login session  Passwords are never sent across the network in cleartext  or stored in memory  Every user has a password.  Every service has a password.  The only entity that knows all the passwords is the Authentication Server. Kerberos 29

Kerberos 30 ServerServer ServerServer ServerServer ServerServer KerberosDatabase Ticket Granting Server Server Ticket Granting Server Server Authentication Authentication WorkstationWorkstation Kerberos Key Distribution Service

Secret Key Cryptography  The encryption used by current Kerberos implementations is DES,  Kerberos V5 has hooks so that other algorithms can be used. encryption plaintextciphertext key ciphertext plaintext decryption Kerberos 31

Tickets  Each request for a service requires a ticket.  A ticket provides a single client with access to a single server.  Tickets are dispensed by the “Ticket Granting Server” (TGS),  which has knowledge of all the encryption keys.  Tickets are meaningless to clients,  they simply use them to gain access to servers. Kerberos 32

Tickets (cont.)  The TGS seals (encrypts) each ticket with the secret encryption key of the server.  Sealed tickets can be sent safely over a network  only the server can make sense out of it  Each ticket has a limited lifetime  a few hours Kerberos 33

Ticket Contents  Client name (user login name)  Server name  Client Host network address  Session Key for Client/Server  Ticket lifetime  Creation timestamp Kerberos 34

Session Key  Random number that is specific to a session.  Session Key is used to seal client requests to server.  Session Key can be used to seal responses  application specific usage Kerberos 35

Authenticators  Authenticators prove a client’s identity.  Includes:  Client user name.  Client network address.  Timestamp.  Authenticators are sealed with a session key. Kerberos 36

Bootstrap  Each time a client wants to contact a server, it must first ask the 3rd party (TGS) for a ticket and session key.  In order to request a ticket from the TGS, the client must already have a TG ticket and a session key for communicating with the TGS ! Kerberos 37

Authentication Server  The client sends a plaintext request to the AS asking for a ticket it can use to talk to the TGS.  REQUEST:  login name  TGS name  Since this request contains only well-known names, it does not need to be sealed. Kerberos 38

Authentication Server  The AS finds the keys corresponding to the login name and the TGS name.  The AS creates a ticket:  login name  TGS name  client network address  TGS session key The AS seals the ticket with the TGS secret key. Kerberos 39

Authentication Server Response  The AS also creates a random session key for the client and the TGS to use.  The session key and the sealed ticket are sealed with the user (login name) secret key. Kerberos 40 TGS session key Ticket: login name TGS name net address TGS session key Sealed with user key Sealed with TGS key

Accessing the TGS  The client decrypts the message using the user’s password as the secret key.  The client now has a session key and ticket that can be used to contact the TGS.  The client cannot see inside the ticket, since the client does not know the TGS secret key. Kerberos 41

Accessing a Server  When a client wants to start using a server (service), the client must first obtain a ticket.  The client composes a request to send to the TGS: Kerberos 42 TGS Ticket Authenticator Server Name sealed with TGS key sealed with session key

TGS response  The TGS decrypts the ticket using it’s secret key. Inside is the TGS session key.  The TGS decrypts the Authenticator using the session key.  The TGS check to make sure login names, client addresses and TGS server name are all OK.  TGS makes sure the Authenticator is recent. Kerberos 43

TGS Response Once everything checks out - the TGS:  builds a ticket for the client and requested server. The ticket is sealed with the server key.  creates a session key  seals the entire message with the TGS session key and sends it to the client. Kerberos 44

Client accesses Server  The client now decrypts the TGS response using the TGS session key.  The client now has a session key for use with the new server, and a ticket to use with that server.  The client can contact the new server using the same format used to access the TGS. Kerberos 45

Kerberos Summary  Every service request needs a ticket.  Tickets come from the TGS  except the ticket for the TGS!  Workstations cannot understand tickets,  they are encrypted using the server key.  Every ticket has an associated session key.  Tickets are reusable.  Tickets have a finite lifetime.  Authenticators are only used once  new connection to a server  Authenticators expire fast !  Server maintains list of authenticators  prevent stolen authenticators Kerberos 46