Bishop, Chapter 11 Cipher Techniques

1
Bishop, Chapter 11 (Cipher Techniques)

• Strange name for a chapter the topic really is
• understanding the context in which a cryptosystem
  / protocol is implemented
• using protocols over a network.
• First topic (brief! and misplaced?)
• Regularities in the message may make the message
  content easy to infer.
• Easiest example is transmitting a single bit.
• Easy to pad the message to obscure its contents.
• Another regularity an alphabetic message is
  sent so that there is one transmission per letter
• lots of regularity in the message
• blocks can be rearranged
• The moral there will always be regularities in
  the content messages you send. Make sure they
  are not reflected in the transport of those
  messages

2
A Review of Some Network Concepts
Client side (Pine, etc) Send this email message
to postmaster_at_microsoft.com
Server side (SMTP) Handle all mail addressed to
users at microsoft.com
Network infrastructure
Network software resolve name to IP address
select port for SMTP server determine path to
destination split payload into packets send,
and verify delivery, resend if necessary
Network software select port for incoming
mail receive packets assemble message from
packets, request retransmission if
necessary
Encryption issues Does encryption happen at
the application or network level? What gets
encrypted, and when? How does a client and
server agree on a method / protocol?
3
The OSI / ISO Network Stack
CLIENT
SERVER
NETWORK (multiple)
Application
Application
Transport
Transport
Network
Network
Network
Data Link
Data Link
Data Link
Physical
Physical
Physical
4
Basic Protocol Layering Model

• Layers on the client and server sides (from top
  down)
• application layer ( presentation session)
  client talking to server ideally at the layer
  of symbolic names for services and for clients
  and servers
• transport layer (TCP or UDP) responsible for
  scheduling packets for delivery to a destination,
  sequencing, etc.
• network layer (IP) responsible for delivering a
  single packet end to end
• data link layer responsible for delivering a
  packet across a single network hop
• physical layer (wire/cable)
• Layers in the network (e.g. a router)
• network, data link, and physical layers
• the network does packet transmission apart from
  any particular application
• client/server and network roles are not mutually
  exclusive (a server could to packet routing too)

5
Network Stack and Message Headers
Application-level request / payload
(transport --TCP)
(network IP)
(physical transmission)
Application-level request / payload
6
IP and TCP Header Contents

• IP
• Source and destination address
• Protocol (e.g. TCP, UDP)
• Time to live / number of hops
• Fragmentation options
• Sizes and checksums
• Payload
• TCP
• Source and destination ports
• Sequence numbers (2)
• Control bits (used to manage handshake)
• Padding and data payload
• Checksum

7
TCP Control Bits and Protocol Handshake

• SYN (synchronize sequence numbers)
• ACK (acknowledge sequence number)
• FIN (tear down session)
• URG, PSH (expedite handling of the packet)
• RST (reset the protocol, unexpected packet
  received)
• Handshake
• Client SYN with ISN1
• Server ACK with ISN1 and SYN with ISN2
• Client ACK with ISN2
• Transmission proceeds

8
The SYN Flood DoS Attack

• Notice when server receives its first SYN, it
  must remember the client (its port and its ISN)
• this connection is in a strange half-open state
• how does the server decide that it wont get the
  second ACK, and should tear down the connection?
• A SYN flood simply sends an overwhelming number
  of SYN messages to a server, and never completes
  the connection
• often with different, forged source addresses
• aim is to fill connection tables, and/or flood
  the communication channel
• The SYN cookie defense
• server hashes all the information it needs to
  remember (address, port, sequence number) into an
  integer value
• it sends that integer value back to the client,
  and forgets about the transmission
• if it doesnt get an ACK back, no big deal
• if it does, it can re-create the saved state from
  its sequence number

9
The Next Big Question

• Supposing you need secure communication over a
  network
• handshake to agree on protocol/algorithms and key
  exchange
• encryption on client side
• decryption on server side
• What layer(s) of the network stack should be
  responsible for these steps?
• application layer (web browser, web server)
• transport layer (TCP)
• network layer (IP)
• link layer or below (router)
• What are the advantages / disadvantages of
  placing encryption high or low in the stack?

10
SSL

• What is it?
• developed by Netscape (c. 1995) to support secure
  communication between web browser and server
• a set of libraries that reside on the network
  stack between the application layer (browser,
  server) and the transport layer (TCP or UDP)
• network transport is unaware that SSL is in use
• but client and server application code must be
  programmed using SSL calls explicitly
• Protocols
• SSL record protocol defines message-passing
  parameters
• SSL handshake protocol is message exchange to
  authenticate client and server, exchange public
  keys, and establish an encrypted data connection

11
SSL Cipher Suites

• Each permits a certain combination of algorithms
• a public-key algorithm for key exchange
• a one-way hash algorithm for authentication
• a symmetric-key algorithm for message exchange
• SSL libraries must implement one or all of the
  suites
• Strongest (US only, banks etc.)
• RSA (key exchange), SHA (authentication), 3DES
• Strong (US only)
• RC2 or RC4 (128 bits) or DES, SHA or MD5
• Exportable
• Diffie-Hellman, MD5, RC2 or RC4 (40 bits)
• Weakest
• MD5 for MAC, no encryption
• used when client or server have no encryption
  libraries

12
The SSL Handshake Protocol

• The client sends the server the client's SSL
  version number, cipher settings, a nonce, and
  possibly a request for the server's certificate.
• The server sends the client the server's SSL
  version number, cipher settings, a nonce, its own
  certificate, and requests the clients
  certificate if it is needed.
• Client authenticates the server (warning box if
  it fails).
• Client creates the premaster secret for the
  session, encrypts it with the server's public key
  and sends it to the server. Client also sends
  its own certificate, if requested.
• Server authenticates the client (terminates
  session if authentication fails).
• Server uses its private key to decrypt the
  premaster secret, then performs a series of steps
  (which the client also performs, starting from
  the same premaster secret) to generate the shared
  master secret (shared session key). Client
  simultaneously computes session key.
• Client and server inform each other that they
  have computed a session key, and both signal
  termination of the handshake protocol.

13
SSL Authentication Steps

• Is today's date within the certificates validity
  period?
• Is the issuing CA a trusted CA?
• Each SSL-enabled client maintains a list of
  trusted CA certificates, and the client will only
  accept certificates from these.
• Does the issuing CA's public key validate the
  issuer's digital signature?
• Does the domain name in the server's certificate
  match the domain name of the server itself?
• This step confirms that the server is actually
  located at the same network address specified by
  the domain name in the server certificate.
  Although this step is not technically part of the
  SSL protocol, it provides the only protection
  against a man-in-the-middle attack.

14
SSL Record Protocol

• This protocol sits under the handshake (and
  other SSL protocols) in the stack
• that is, the handshake protocol steps will call
  it to transmit information
• Its duties
• break the message into fixed-length blocks
• compress
• add signature (MAC)
• encrypt
• add SSL header information
• pass the message to the transport layer
• and of course do the inverse for incoming messages

15
SSL Summary

• Interesting place in the network stack
• applications are aware, transport is not
• Developed by Netscape for secure HTTP still the
  standard (thats what the browser lock means)
• Commercial and open-source libraries available
• Leverages well-established cryptography
  algorithms
• RSA / Diffie-Hellman for key exchange
• X.509 certificates (but no certification chains)
• SHA or MD5 for MAC
• DES or RC4 or IDEA for data exchange

16
IPSec Security at the Network Level

• The idea is to push the security infrastructure
  down the stack to the IP level. Encryption
  libraries, protocols, etc. are all implemented in
  the network layer, and all upper layers are
  unaware
• Typical use of this technology establishing
  virtual private networks
• secure communication (of all kinds) between two
  hosts
• all communication between the hosts is routed
  through a particular system, which is using IPSec
• Examples
• external connection to UWT to access shared files
• communication between Amazon and Target

17
IPSec Key Concepts

• Kernel configuration since IP-level processing
  is typically a kernel-level operation, this
  functionality must be built into the OS (Free BSD
  for example. Windows 2000 Server. Some Linux)
• RedHat? Apparently not
• FIXME Waiting for our feature editor Stefan to
  finish his stuf
• Security policy database
• what messages are subject to IPSec control
• security policy can depend on ports and
  addresses, transport layer
• Security associations
• every packet is subject to a security association
  which will determine the IPSec protocol to use,
  the encryption algorithm, the key, etc.

18
IPSec Protocols

• (The SA entry for a packet will determine which
  of these will be used if either.)
• Authentication Header Protocol (AH)
• authenticates the origin of the packet
• protects against corruption, modification, replay
  (essentially through securing a sequence number
  for each packet)
• payload is not encrypted
• Encapsulating Security Payload Protocol (ESP)
• main feature is that the IP payload is encrypted
  according to an algorithm specified in the SA
  entry
• IP header is also encrypted

19
Counterpane on IPSec

• Interesting critique of IPSec by Counterpane Labs
• http//www.counterpane.com/ipsec.html
• Some highlights of the report
• "it is the best available network security
  system"
• "it should not be used, at all"
• the problem is that its impossibly complex, and
  thus invites errors in implementation,
  configuration, and use (this is a common
  complaint)
• certain design features seem superfluous, and
  even harmful
• transport mode
• authentication header protocol
• the problem is design by committee

20
Conclusion / Comments

• The basic premise is very appealing
• push security down to the network level, and its
  automatically available
• The implementation does not support that premise,
  and as such its a dangerous weapon
• Put to good use in carefully designed VPNs