TLS Receive Side Crypto Offload to NIC

Slides:



Advertisements
Similar presentations
Umut Girit  One of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer.
Advertisements

CS 483 – SD SECTION BY DR. DANIYAL ALGHAZZAWI (3) Information Security.
Secure Socket Layer.
Transport Layer – TCP (Part1) Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF.
16-1 Last time Internet Application Security and Privacy Authentication Security controls using cryptography Link-layer security: WEP.
WEP Weaknesses Or “What on Earth does this Protect” Roy Werber.
Intercepting Mobiles Communications: The Insecurity of Danny Bickson ACNS Course, IDC Spring 2007.
Wired Equivalent Privacy (WEP)
Security in Wireless LAN Layla Pezeshkmehr CS 265 Fall 2003-SJSU Dr.Mark Stamp.
Chapter 15 – Part 2 Networks The Internal Operating System The Architecture of Computer Hardware and Systems Software: An Information Technology Approach.
CSCE 515: Computer Network Programming TCP Details Wenyuan Xu Department of Computer Science and Engineering.
IP-UDP-RTP Computer Networking (In Chap 3, 4, 7) 건국대학교 인터넷미디어공학부 임 창 훈.
Gursharan Singh Tatla Transport Layer 16-May
Wireless security & privacy Authors: M. Borsc and H. Shinde Source: IEEE International Conference on Personal Wireless Communications 2005 (ICPWC 2005),
COEN 350 Mobile Security. Wireless Security Wireless offers additional challenges: Physical media can easily be sniffed. War Driving Legal? U.S. federal.
High Performance Computing & Communication Research Laboratory 12/11/1997 [1] Hyok Kim Performance Analysis of TCP/IP Data.
Internet Addresses. Universal Identifiers Universal Communication Service - Communication system which allows any host to communicate with any other host.
Cosc 4765 SSL/TLS and VPN. SSL and TLS We can apply this generally, but also from a prospective of web services. Multi-layered: –S-http (secure http),
TCP Lecture 13 November 13, TCP Background Transmission Control Protocol (TCP) TCP provides much of the functionality that IP lacks: reliable service.
University of the Western Cape Chapter 12: The Transport Layer.
Transport Layer: TCP and UDP. Overview of TCP/IP protocols Comparing TCP and UDP TCP connection: establishment, data transfer, and termination Allocation.
NSRI1 Security of Wireless LAN ’ Seongtaek Chee (NSRI)
WEP Protocol Weaknesses and Vulnerabilities
1 Security Protocols in the Internet Source: Chapter 31 Data Communications & Networking Forouzan Third Edition.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Chapter 15 – Part 2 Networks The Internal Operating System The Architecture of Computer Hardware and Systems Software: An Information Technology Approach.
Chapter 9: Algorithms Types and Modes Dulal C. Kar Based on Schneier.
Shambhu Upadhyaya Security – AES-CCMP Shambhu Upadhyaya Wireless Network Security CSE 566 (Lecture 13)
SSL/TLS How to send your credit card number securely over the internet.
An initial study on Multi Path Routing Over Multiple Devices in Linux 2.4.x kernel Towards CS522 term project By Syama Sundar Kosuri.
Network Security7-1 Today r Reminder Ch7 HW due Wed r Finish Chapter 7 (Security) r Start Chapter 8 (Network Management)
CSC 600 Internetworking with TCP/IP Unit 5: IP, IP Routing, and ICMP (ch. 7, ch. 8, ch. 9, ch. 10) Dr. Cheer-Sun Yang Spring 2001.
1 CS 4396 Computer Networks Lab TCP – Part II. 2 Flow Control Congestion Control Retransmission Timeout TCP:
WLAN Security1 Security of WLAN Máté Szalay
COEN 350 Mobile Security. Wireless Security Wireless offers additional challenges: Physical media can easily be sniffed. War Driving Legal? U.S. federal.
1 Kyung Hee University Chapter 11 User Datagram Protocol.
MiniSec: A Secure Sensor Network Communication Architecture Carnegie Mellon UniversityUniversity of Maryland at College Park Mark Luk, Ghita Mezzour, Adrian.
Dan Boneh Authenticated Encryption CBC paddings attacks Online Cryptography Course Dan Boneh.
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
3. END-TO-END PROTOCOLS (PART 1) Rocky K. C. Chang Department of Computing The Hong Kong Polytechnic University 22 March
Block Cipher Modes Last Updated: Aug 25, ECB Mode Electronic Code Book Divide the plaintext into fixed-size blocks Encrypt/Decrypt each block independently.
Advanced Computer Networks
Executive Director and Endowed Chair
Fast Retransmit For sliding windows flow control we waited for a timer to expire before beginning retransmission of a packet TCP uses an additional mechanism.
Encryption and Network Security
Bruno Saba DCT/TV/IN 26/04/2010
Chapter 18 IP Security  IP Security (IPSec)
WEP & WPA Mandy Kershishnik.
Secure Sockets Layer (SSL)
5. End-to-end protocols (part 1)
Process-to-Process Delivery, TCP and UDP protocols
Visit for more Learning Resources
Understanding the OSI Reference Model
Originally by Yu Yang and Lilly Wang Modified by T. A. Yang
Wireless Security Ian Bodley.
Transport Layer Unit 5.
Block Cipher Modes CS 465 Make a chart for the mode comparisons
Packet Pacing Essentials
CCNA 2 v3.1 Module 10 Intermediate TCP/IP
TLS, Crypto, & ULP’s Dave Watson
CSE 4905 WiFi Security I WEP (Wired Equivalent Privacy)
PUSH Flag A notification from the sender to the receiver to pass all the data the receiver has to the receiving application. Some implementations of TCP.
Chapter 15 – Part 2 Networks The Internal Operating System
Rekeying Protocol Fix Date: Authors: Month Year
Computer Networks Protocols
Counter With Cipher Block Chaining-MAC
Counter Mode, Output Feedback Mode
Transport Layer 9/22/2019.
SPINE: Surveillance protection in the network Elements
Presentation transcript:

TLS Receive Side Crypto Offload to NIC Boris Pismenny Novmember 2017

Overview Background Motivation Control Path Model Data Path Summary Discussion

TLS Record Protocol: Application Data User Space: Application Data Data KTLS: Fragment (2^14) Data1 Data2 Data3 Data -> TLS Data Fragments H – header T – authentication tag KTLS: Encrypt & Authenticate Enc(Data1) T Enc(Data2) T Enc(Data3) T KTLS: TLS Records H Enc(Data1) T H Enc(Data2) T H Enc(Data3) T TCP: Segment (MSS) P1 P2 P3 P4 P5 P6 P7 H – TLS Record Header T – TLS Record Authentication Tag

TLS Crypto Offload vs. Other Protocols Ideally, packets would be processed independently: IPsec DTLS QUIC However, in TLS each record is processed independently Each record has an Out-Of-Band sequence number that is used for decryption Intermediate record state must be tracked by hardware Used by subsequent packets that are part of a previous record TLS Records: TLS Record 1 TLS Record 2 TCP Packets: P1 P2 P3 TLS Record 1 | TLS Record 2  P2

Motivation Setup: Two Xeon E5-2620 v3 machines connected back-to-back with Innova- TLS-Tx NICs (ConnectX4-Lx + Xilinx FPGA) Run IPerf2 with a patch to use OpenSSL for the handshake Compare the data path of the following: OpenSSL 1.1.0e SSL_write/SSL_read Kernel TLS send/recv with offload TCP send/recv (upper bound) Everything is normalized to SSL_write/SSL_read

Control Path kTLS is Now Upstream! User interface Currently, only send-side User interface Starts with a TCP connection Enable kTLS with setsockopt() Redirects user Send() call to kTLS functions, which calls do_tcp_sendpages() Straightforward uAPI extension for Rx TLS_RX socket option TLS recvmsg replaces TCP recvmsg

Model Offload initialization requires: KTLS Crypto material (keys, cipher) 5-tuple TCP sequence number of next TLS record TLS record sequence number of next TLS record Hardware decrypts in-order incoming packets Headers are unmodified - only the payload is processed OOO packets are unmodified Software stack is unchanged kTLS (without crypto) TCP/IP Congestion control Memory management KTLS TLS record plaintext byte stream* TCP Mark socket as offloaded Data path is unchanged* tcpdump - plaintext TCP segments of plaintext TLS records* NIC TCP segments of ciphertext TLS records Network *While receiving, there might be both plaintext and ciphertext packets

Data Path – Fast Path TLS Record 1 TLS Record 2 TLS Record 3 P1 P2 P3 1) Check all packets in record are decrypted – OK 2) Copy plaintext data to userspace TLS Records: TLS Records: TLS Records: TLS Record 1 TLS Record 2 TLS Record 3 Legend: Decrypted TCP Packets: TCP Packets: TCP Packets: P1 P2 P3 P4 P5 P6 P7

Data Path – Slow Path (Partial Decryption) 1) Check all packets in record are decrypted – Wrong! 1.1) Is some part of the record decrypted? – OK 1.1.1) Partial decryption: Decrypt the remaining packets in software. 2) Copy plaintext data to userspace TLS Records: TLS Records: TLS Records: TLS Record 1 TLS Record 2 TLS Record 3 Legend: Decrypted Partially Decrypted TCP Packets: TCP Packets: TCP Packets: P1 P2 P3 P4 P5 P6 P7

Data Path – Slow Path (Resync) 1) Check all packets in record are decrypted – Wrong! 1.1) Is some part of the record decrypted? – Wrong! 1.1.1) Partial decryption: Decrypt the remaining packets in software 1.2) Otherwise, the record is ciphertext – use the software crypto implementation 1.2.1) Call the driver for HW Resynchronization 2) Copy plaintext data to userspace TLS Records: TLS Records: TLS Records: TLS Record 1 TLS Record 2 TLS Record 3 Legend: Decrypted Partially Decrypted Encrypted TCP Packets: TCP Packets: TCP Packets: P1 P2 P3 P4 P5 P6 P7

Partial Decryption TLS Record 1 TLS Record 2 TLS Record 3 P1 P2 P3 P4 Observations: In AES counter mode, given the counter (IV) and the key – it is possible to generate the keystream Ciphertext = Plaintext XOR Keystream Partial Decryption Algorithm*: Calculate keystream by encrypting zeros For each plaintext packet XOR with keystream to obtain ciphertext Decrypt and authenticate the ciphertext record Return plaintext and authentication result TLS Records: TLS Record 1 TLS Record 2 TLS Record 3 Legend: Decrypted Partially Decrypted TCP Packets: P1 P2 P3 P4 P5 P6 P7 *This algorithm could be optimized to use one pass over the data instead of two passes as described here.

Resynchronization After packet drop/out-of-order hardware looses the following state required to offload the next TLS record: Location of TLS record frames in the TCP stream TLS record sequence number for each frame SW assistance is needed! Resynchronization process kTLS requests driver to resynchronize for every received record that was not decrypted kTLS provides driver with TCP SN corresponding to first byte of record Driver attempts to resynchronize HW based on this information Note: Hardware will not decrypt any packet until resync is accepted by software.

Optimizing Initial Synchronization Consider the following scenario: The user requests TLS offload after reading X bytes of data from TCP At this time, the kernel has Y > X bytes of data in the receive queue At the same time, hardware processed Z > Y > X bytes of data Problem: Offload requires the state at the last record within Z bytes. We suggest two techniques to mitigate this: The kernel walks the receive queue and provides hardware with the TCP sequence of the most recent TLS record Resync flow in HW TLS records: R1 R2 R3 TCP packets processed by userspace: P1 P2 P3 TCP packets processed by the kernel: P1 P2 P3 P4 P5 TCP packets processed by hardware: P1 P2 P3 P4 P5 P6 P7

TLS Renegotiation Before the ChangeCipherSpec (CCS) message the all data is encrypted using the old keys, after the CCS message all data is encrypted using new keys old keys old keys new keys new keys

TLS Renegotiation R1 R2 (CCS) R3 R4 P1 P2 P3 P4 P5 P6 P7 P8 P9 Assume packets are received in order during TLS key renegotiation TLS Change Cipher Spec record is not identified by hardware, as a result old keys are used to decrypt data that was encrypted using new keys When kTLS first observes the CCS message: Request hardware to stop offload Walk all received packets and re-encrypt bad decrypted packets encrypted using old key encrypted using new key TLS records: R1 R2 (CCS) R3 R4 decrypted using old key Authentication error Stop decryption TCP packets: P1 P2 P3 P4 P5 P6 P7 P8 P9

Summary Problem 1: During initialization hardware already processed the next TLS record Resync Kernel provides the TCP sequence of the last record received to HW Problem 2: Hardware lost track of TLS records in the TCP stream due to packet drop/reorder Problem 3: Old keys are used to decrypt data that was encrypted using new keys after a TLS Change Cipher Spec record is not identified by hardware kTLS will re-encrypt packets that were decrypted using the old key after processing CCS Problem 4: Some TLS records contain both ciphertext and plaintext packets Partial decryption

Discussion Need to pass 2 bits of metadata in the SKB crypto_done – was packet processed by hardware? crypto_success – was any error encountered during this packet’s processing? Prevent coalescing of plaintext and ciphertext SKBs tcp_collapse/gro must not coalesce ciphertext and plaintext TCP OOO queue might get bloated with plaintext-ciphertext-plaintext-… Could re-encrypt packets in OOO queue when pruning crypto_done && !crypto_success HW might continue processing a packet after encountering an error in the middle of it Call netdevice from kTLS to fix packet – revert the HW operation in software TLS offload uses CHECKSUM_UNNECESSARY CHECKSUM_COMPLETE is meaningful only for the ciphertext that was replaced. Could we combine TLS skb metadata with IPsec’s sec_path?

Thank You

Partial Decryption Observations: Given the counter (IV) and the key - GCM allows for decryption of any cipher block in the record. XOR ciphertext block with E_k(Counter + BlockNumber) Authentication tag is computed over the ciphertext Algorithm: Calculate keystream by encrypting the counters For each ciphertext block If plaintext: XOR with keystream to obtain ciphertext and multiply ciphertext with H If ciphertext: XOR with keystream to obtain plaintext and and multiply ciphertext with H Check authentication tag Return plaintext and authentication result.