Transcript Real-time security

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
1
Networking Review
...
the Internet (TCP/IP) is
a 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
Application Layer (HTTP, FTP, SMTP, etc.)
the first three layers are
implemented in the OS
Transport Layer (TCP, UDP)
OS
kernel
Network Layer (IP)
the last layer is
Data Link Layer (PPP, Ethernet, etc.)
implemented in
2
Physical Layer
user space
...
Approaches to Securing Network
Communication
application
above the OS (at level 4) – add
a security wrapper around
insert SSL (TLS or SSH)
TCP interface (sockets)
OS
TCP
• OS does not need to be
replace IP with IPsec
modified
lower layers
• 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.
3
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
4
Perfect Forward Secrecy and
Escrow-Foilage Protection
• what is PFS again? what’s 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 longterm 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
Alice’s and Bob’s long-term keys
– if a system is PFS it is also protected against escrow-foilage.
why?
5
Denial-of-Service Protection
denial-of-service authentication attack – exhaust all server’s 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, server’s secret); server
doesn’t 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?
– client’s computation power varies, not useful against coordinated
distributed DoS attack
6
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) – Bob’s identity is probably already known
– responder (Bob) – if Bob’s 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
gamod p {“Alice”,[gamod p]Alice}
Bob
Alice
okay, gbmod p
gbmod p {“Bob”,[gbmod p]Bob}
7
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?
8
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 p]Alice
gabmod p {Bob’s message}
Bob
Alice
[gbmod p]Bob
gabmod p {Alice’s message}
9
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: Bob’s name signed by Alice’s key, what does this message
prove?
– solution: don’t 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?
10