Lecture 14: RealTime Communication Security

1
Lecture 14 Real-Time Communication Security

• real-time communication two parties interact in
  real time (as opposed to delayed communication
  like e-mail)
• security features
• mutual authentication
• session key establishment for subsequent
  conversation
• security association conversation protected
  with a session key
• perfect forward secrecy
• escrow-foilage protection
• clogging protection
• endpoint ID hiding
• security systems IPsec, SSL/TLS, SSH

2
Networking Review
...

• the Internet (TCP/IP) isa packet-switched
  network
• data to be transmitted is divided into
  packets
• each packet is forwarded by routers towards
  the destination
• networking functions standardized into
  hierarchical layers of protocols, so that each
  layer uses the services of the lower layer and
  provides services to the upper
• the first three layers are implemented in the OS
  kernel
• the last layer is implemented in user space

...
Application Layer (HTTP, FTP, SMTP, etc.)
Transport Layer (TCP, UDP)
OS
Network Layer (IP)
Data Link Layer (PPP, Ethernet, etc.)
Physical Layer
3
Approaches to Securing Network Communication

• above the OS (at level 4) add a security
  wrapper around TCP interface (sockets)
• OS does not need to bemodified
• minimum modification at applications
• TCP is below crypto no cooperation between SSL
  and TCP DoS attack possible whole TCP session
  can be forced to reset by inserting a single
  bogus packet
• within the OS (at level 3) replace IP with
  secure implementation (IPsec)
• no modifications at applications
• security of IPsec is underutilized can only
  supply what IP does, even though can do
  authentication, etc.

application
insert SSL (TLS or SSH)
OS
TCP
replace IP with IPsec
lower layers
4
Session Key Establishment Issues

• message authentication with a session key
  establishment is needed against connection
  hijacking
• sequence numbers needed against packet replays
  (different from TCP seq.no.)
• session key reset before SN wrap around
• for freshness guarantee, both parties should
  contribute to the session key
• less likely to attacks when someone impersonate
  one party to the other
• good key even if only one party has access to
  random key generator

5
Perfect Forward Secrecy andEscrow-Foilage
Protection

• what is PFS again? whats an example of a system
  with PFS?
• non-PFS examples
• Kerberos (why?)
• session key transport with RSA encryption (why?)
• key escrow communicating parties have to store
  their long-term keys with a third-party
  (authorities, law-enforcement, etc.)
• escrow-foilage key stored at the third party is
  used maliciously
• escrow-foilage protection conversation between
  Alice and Bob is secret to passive eavesdropper
  Trudy in possession of Alices and Bobs
  long-term keys
• if a system is PFS it is also protected against
  escrow-foilage. why?

6
Denial-of-Service Protection

• denial-of-service authentication attack exhaust
  all servers resources by initiating numerous
  authentication sessions (possibly with faked IP
  packets)
• solutions
• cookies server responds to a session request
  with a random number (cookie), initiator has to
  reply back with that cookie to continue
• attacker have to either reveal its address or,
  abort the attack
• stateless cookies cookie is H(IP address,
  servers secret) server doesnt have to remember
  it
• puzzles to continue authentication server
  requires initiator to solve a puzzle e.g.
  MD5(x) , x ?
• solving is slow (depends on the size of x),
  verification fast
• can be made stateless, how?
• clients computation power varies, not useful
  against coordinated distributed DoS attack

7
Identity Hiding

• some apps require identity protection against
  eavesdropper
• parties can use Diffie-Hellman anonymously and
  then use shared key to encrypt the rest of the
  session (including authentication)
• passive attacker will not know the identities
• active attacker may still learn one or both
  identities, how?
• which identity is more valuable to protect? two
  opinions
• initiator (Alice) Bobs identity is probably
  already known
• responder (Bob) if Bobs id is harder to
  impersonate (Alice initiates the conversation)
• in the protocol below, whose id is protected
  against active attack?

I want to talk, gamod p
okay, gbmod p
Alice
Bob
gamod p Alice,gamod pAlice
gbmod p Bob,gbmod pBob
8
Live Partner Reassurance

• Bob is vulnerable to replays
• can use different D-H exponents for different
  sessions
• DH exponentiation is expensive problem for
  servers, low-end clients
• solution same DH exponents, different nonces
• Incorporate nonces into the session key. E.g., K
  H(gab mod p, nonces)
• how would these nonces be exchanged?

9
Parallel Key Computation

• Computing D-H exponents is expensive. May do it
  in advance
• in the protocol below, why is Bob sending two
  messages in sequence rather than combining them?

gamod pAlice
gbmod pBob
Alice
Bob
gabmod p Bobs message
gabmod p Alices message
10
Other Issues

• session resumption use previously established
  session keys to bypass public-key authentication
• one solution share a key medium term (derive the
  session key from it) and request knowledge on
  resumption
• deniability possibly need not to leave a proof
  that Alice talked to Bob
• ex Bobs name signed by Alices key, what does
  this message prove?
• solution dont use signatures for
  authentication. use encryption with public keys
• crypto negotiation key exchange protocols
  negotiate the algorithms to be used as well (ex
  key size, compression, prime (p) to use for D-H)
• problem Trudy may force Alice and Bob to use
  weak crypto (if it is available as an option for
  both parties by tampering with messages and
  removing stronger options
• solution?