1 / 35

tcpcrypt: real transport-level encryption

tcpcrypt: real transport-level encryption. UCL and Stanford. Andrea Bittau, Mike Hamburg, Mark Handley , David Mazieres, Dan Boneh. What would it take to encrypt the vast majority of TCP traffic?. Performance Fast enough to enable by default on almost all servers. Authentication

lucie
Télécharger la présentation

tcpcrypt: real transport-level encryption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. tcpcrypt:real transport-level encryption UCL and Stanford. Andrea Bittau, Mike Hamburg, Mark Handley, David Mazieres, Dan Boneh.

  2. What would it take to encrypt the vast majority of TCP traffic? Performance • Fast enough to enable by default on almost all servers. Authentication • Leverage certificates, cookies, passwords, etc., to give best possible security for any given setting. Compatibility • Works in existing networks • Works with unmodified legacy applications

  3. An observation on layering of crypto • Encryption is a generic function. • Independent of the semantics of the application. • Integrity Protection is a generic function. • What arrives should be what is sent. • Authentication is strongly application-specific. • Depends on the semantics of the application.

  4. An observation on layering of crypto Observation: Encryption and Integrity Protection are lower-layer functions than Authentication. • Encryption and Integrity Protection are natural transport-layer functions. • Cannot integrity-protect transport protocol from above it. • Different transport sessions have different security requirements so cannot share encryption keys. • Authentication is application-layer.

  5. Tcpcrypt

  6. Tcpcrypt uses TCP options to provide deployable transport-level encryption. • High server performance - push complexity to clients • Allow applications to authenticate endpoints. • Backwards compatibility: all TCP apps, all networks, all authentication settings.

  7. Tcpcrypt overview • Extend TCP in a compatible way using TCP options. • Existing applications use standard socket API, just like regular TCP. • Encryption automatically enabled if both end points support Tcpcrypt. • Extended applications can use a new getsockopt() for authentication.

  8. Perform decrypt on the client: Generate emphemeral key pair: public key Generate random master key encpub_k(master_key) client server Push expensive operations to the client Initial handshake: No authentication. Client decrypts. Lets servers accept connections 36x faster than SSL Public-key operations can be quite assymetric. RSA-exp3-2048 performance:

  9. After initial handshake, tcpcrypt’s Session ID provides the hook to link application authentication to the session. • New getsockopt() returns non-secret Session ID value. • Unique for every connection. • If same on both ends, guaranteed there’s no man-in-the-middle.

  10. How to check the Session ID? • Out-of-band: e.g., phone call, other secure protocol. • PKI: server signs Session ID. • Pre-shared secret: send CMAC of Session ID, keyed with Pre-shared secret.

  11. password-based auth of user and session ID Authenticating the session ID authenticates the endpoint session ID session ID tcpcrypt Authentication Example:Password-based Mutual Authentication • Whenever a user knows a password, mutual authentication should be used. • Does not rely on user to spot spurious URLs.

  12. Authentication Example:Password-based Mutual Authentication

  13. “B”, signed by amazon.com RSA op session ID: B Authentication Example:Signing a batch of session IDs to amortize RSA costs “A”, signed by amazon.com RSA op session ID: A

  14. Authentication Example:Signing a batch of session IDs to amortize RSA costs session ID: A session ID: C “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com RSA op session ID: B session ID: D

  15. session ID: A session ID: C “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com “A,B,C,D” signed by amazon.com RSA op session ID: B session ID: D SSL servers RSA decrypt each client’s secret: RSA op RSA op enc(Secret A) enc(Secret C) RSA op RSA op enc(Secret B) enc(Secret D)

  16. Tcpcryptin detail

  17. Outline of Tcpcrypt key exchange

  18. Key exchange is performed in the TCP connection setup handshake.

  19. Key Scheduling

  20. Tcpcrypt in TCP Packets

  21. Crypto state can be cached.Subsequent connections between the same endpoints get similar latency to regular TCP.

  22. Key Scheduling 2

  23. TcpcryptPerformance

  24. Tcpcrypt implementations • Linux kernel implementation: 4,500 lines of code • Portable divert-socket implementation: 7000 LoC • Tested on Windows, MacOS, Linux, FreeBSD • Binary compatible OpenSSL library that attempts tcpcrypt with batch-signing or falls back to SSL. tcpcryptd application Network kernel

  25. Apache using tcpcrypt performs well. Hardware: 8-core, 2.66GHz Xeon (2008-era). Software: Linux kernel implementation.

  26. Authentication over Tcpcrypt is fast.

  27. What would it take to encrypt all the traffic on the Internet, by default, all the time?

  28. Why tcpcrypt? • Want to protect TCP packet headers. • Defend against insertion attacks, etc. • But still traverse NATs, firewalls that rewrite sequence numbers. • Want on-by-default encryption for existing unmodified apps to protect against passive easesdropping. • Fast enough to enable on all servers by default. • Won’t break - downgrades to TCP if necessary. • Easy incremental deployment story due to negotiation in TCP handshake.

  29. Why tcpcrypt? • Want to enable and encourage appropriate authentication above tcpcrypt. • Cert-based, mutual auth, PAKE, etc, as appropriate. • Eg. can support connectbyname() in a shim library, and leverage DANE for auth. • Separation of layering provides flexibility. • Eg. allows corporate firewall to do encryption and app to still do authentication, so corporate IDS still works. • tcpcryptd on firewall • RPC to get session ID.

  30. Summary: tcpcrypt can enable ubiquitous transport level encryption • High server performance makes encryption a realistic default. • Applications can leverage Tcpcrypt to maximize communication security in every setting. • Incrementally deployable, compatible with legacy apps, TCP and NATs. http://tcpcrypt.org

  31. Spare slides

  32. Connection setup latency is slightly increased due to client-side RSA decrypt.

  33. Most authentication can be done very cheaply, once the Tcpcrypt session is established.

  34. Batch signing does not add additional latency

  35. Data encryption is very fast on today’s CPUs

More Related