IP Library › Granted Patent US 12,212,600
Granted Patent B2
US 12,212,600 · App. 17/189,219 · Granted Jan 28, 2025

Offload of decryption operations

Inventors: Helia A. Naeimi (Santa Clara, CA); Sivakumar Munnangi (San Jose, CA); Namrata Limaye (Fremont, CA); Arvind Srinivasan (San Jose, CA); Gargi Saha (Santa Clara, CA); Hung Nguyen (San Jose, CA); Daniel Daly (Santa Barbara, CA)
Assignee: Intel Corporation
H04L63/166H04L63/0245H04L63/0435H04L63/20
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,212,600
App. No.
17/189,219
Granted
Jan 28, 2025
Kind
B2
Abstract

Examples described herein relate to a Transport Layer Security (TLS) offload engine to: based on detection of encrypted data unassociated with a previously detected data header: search for one or more data headers; identify at least two candidate data headers for validation; and based on receipt of an indication that the at least two candidate data headers are valid, perform decryption of received data in one or more packets. In some examples, the TLS offload engine is to: based on receipt of an indication that one or more of the at least two candidate data headers is not a valid header, search for two or more other candidate data headers.

Claims (48)

1. An apparatus comprising:

an interface and

a Transport Layer Security (TLS) offload engine circuitry coupled to the interface, the TLS offload engine circuitry to:

based on detection of packets received out-of-order:

search for at least two candidate data headers;

based on the at least two candidate data headers being valid, perform decryption of received data in two or more packets associated with the at least two candidate data headers; and

based on at least one of the at least two candidate data headers is not valid, do not perform decryption of the received data in the two or more packets, wherein to search for at least two candidate data headers, the TLS offload engine circuitry is to:

determine a data length associated with a first candidate data header and

identify a second candidate data header at a location based on the data length.

2. The apparatus of claim 1 , wherein the TLS offload engine circuitry is to:

based on the at least one of the at least two candidate data headers is not a valid, search for at least one other candidate data header.

3. The apparatus of claim 1 , wherein to search for at least two candidate data headers, the TLS offload engine circuitry is to:

provide the first and second candidate data headers to another agent or entity for validation.

4. The apparatus of claim 1 , wherein the TLS offload engine circuitry is to:

search for another candidate data header after the first candidate data header and before the second candidate data header.

5. The apparatus of claim 1 , wherein at least one candidate data header of the at least two candidate data headers comprises one or more of: a preamble, header, and length field.

6. The apparatus of claim 1 , wherein to search for the at least two candidate data headers, the TLS offload engine circuitry is to utilize resources otherwise used for decryption to search for one or more data headers.

7. The apparatus of claim 1 , comprising a network interface that includes the TLS offload engine circuitry, wherein the network interface comprises one or more of: an Infrastructure Processing Unit (IPU), data processing unit (DPU), network interface controller (NIC), or smartNIC.

8. The apparatus of claim 1 , comprising a server, wherein the server is to determine if the at least two candidate data headers are valid and indicate whether the at least two candidate data headers are valid or includes one or more invalid candidate data headers.

9. A method comprising:

a Transport Layer Security (TLS) offload engine performing:

based on detection of packets received out-of-order:

searching for at least two candidate headers;

based on the at least two candidate headers are valid headers, performing decryption of received data in two or more packets associated with the at least two candidate headers; and

based on at least one of the at least two candidate headers is not valid, do not perform decryption of the received data in the two or more packets, wherein searching for at least two candidate headers comprises:

determining a data length associated with a first candidate header and

identifying a second candidate header at a location based on the data length.

10. The method of claim 9 , comprising:

the TLS offload engine performing:

based on one or more of the at least two candidate headers is not a valid header, searching for at least one other candidate header.

11. The method of claim 9 , wherein searching for at least two candidate headers comprises:

providing the first and second candidate headers to a server for validation.

12. The method of claim 9 , comprising:

searching for another candidate header after the first candidate header and before the second candidate header.

13. The method of claim 9 , wherein at least one candidate header of the at least two candidate headers comprises one or more of: a preamble, header, and length field.

14. At least one non-transitory computer-readable medium, comprising instructions stored thereon, that if executed by at least one processor, cause the at least one processor to:

execute a device driver to configure a network interface controller to:

based on receipt of packets out-of-order:

search for two or more candidate headers, wherein the search for two or more candidate data headers, the network interface controller is to:

determine a data length associated with a first candidate data header and

identify a second candidate data header at a location based on the data length;

based on the two or more candidate headers being valid, perform decryption of received data in two or more packets associated with the at least two or more candidate headers; and

based on at least one of the two or more candidate headers is not valid, do not perform decryption of the received data in the two or more packets.

15. The at least one computer-readable medium of claim 14 , wherein the network interface controller is to:

provide the first and second candidate headers to a host system for validation.

16. The at least one computer-readable medium of claim 14 , wherein to search for one or more candidate headers, the network interface is to:

search for another candidate header after the first candidate header and before the second candidate header.

17. The at least one computer-readable medium of claim 15 , wherein at least one candidate header of the at least two candidate headers comprises one or more of: a preamble, header, and length field.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Apr 20, 2022
From: NAEIMI, HELIA A.; MUNNANGI, SIVAKUMAR; LIMAYE, NAMRATA; SRINIVASAN, ARVIND; SAHA, GARGI; NGUYEN, HUNG; DALY, DANIEL
To: INTEL CORPORATION
Reel/Frame 059648/0966 →
Continuity (4)
Continuation In Part 16838888 · Apr 2, 2020
Provisional Application 63130669 · Dec 26, 2020
Provisional Application 62834936 · Apr 16, 2019
Related Publication 20210211467A1 · Jul 8, 2021
References Cited (45)
US 7409558B2 · Beukema et al. · 2008 [cited by applicant]
US 9769149B1 · Brady · 2017 [cited by examiner]
US 10211985B1 · Brandwine et al. · 2019 [cited by applicant]
US 10778585B1 · Saalfeld et al. · 2020 [cited by applicant]
US 11062302B1 · Ho et al. · 2021 [cited by applicant]
US 20040230797A1 · Ofek · 2004 [cited by examiner]
US 20070130352A1 · Chhabra et al. · 2007 [cited by applicant]
US 20070162744A1 · Hoshino · 2007 [cited by examiner]
US 20080184331A1 · Cam-Winget · 2008 [cited by examiner]
US 20090006839A1 · Matsuoka · 2009 [cited by examiner]
US 20090249059A1 · Asano · 2009 [cited by applicant]
US 20100165897A1 · Sood · 2010 [cited by examiner]
US 20100223457A1 · Durham · 2010 [cited by examiner]
US 20130097615A1 · Falco · 2013 [cited by examiner]
US 20160094581A1 · Kasbekar · 2016 [cited by examiner]
US 20160234123A1 · Alisawi et al. · 2016 [cited by applicant]
US 20160330112A1 · Raindel et al. · 2016 [cited by applicant]
US 20180152467A1 · Anderson et al. · 2018 [cited by applicant]
US 20180167207A1 · Chaubey · 2018 [cited by examiner]
US 20180278583A1 · Cela · 2018 [cited by examiner]
US 20190116127A1 · Pismenny et al. · 2019 [cited by applicant]
US 20190132296A1 · Jiang et al. · 2019 [cited by applicant]
US 20190229903A1 · Balasubramanian et al. · 2019 [cited by applicant]
US 20200236140A1 · Srinivasan et al. · 2020 [cited by applicant]
US 20210160009A1 · Goyal et al. · 2021 [cited by applicant]
US 20210211467A1 · Naeimi et al. · 2021 [cited by applicant]
US 20210281608A1 · Green et al. · 2021 [cited by applicant]
US 20220329558A1 · Khan · 2022 [cited by examiner]
Chelsio Communications, “Crypto Offload”, https://web.archive.org/web/20180418210314/https://www.chelsio.com/crypto-offload/, Apr. 18, 2018, 2 pages. [cited by applicant]
Netdev, “TLS Offload to Network Devices”, Netdev 1.2, https://web.archive.org/web/20171202211713/https://netdevconf.org/1.2/session.html?boris-pismenny, Dec. 2, 2017, 4 pages. [cited by applicant]
Netdev, “TLS Receive Side Crypto Offload”, Netdev 2.2—Session, https://web.archive.org/web/20180131144710/https://www.netdevconf.org/2.2/session.html?pismenny-tlscrypto-talk, Jan. 31, 2018, 3 pages. [cited by applicant]
Netronome, “Agilio® CX 50GbE SmartNIC for OCP With Inline Crypto and Buffer Management”, Product Brief, Netronome Systems, Inc., Mar. 2019, 2 pages. [cited by applicant]
Pismenny, Boris, “TLS Crypto Offload to Network Devices”, Mellanox Technologies, Netdev conference, Tokyo, Oct. 2016, 22 pages. [cited by applicant]
Pismenny, Boris, et. al., “TLS Offload to Network Devices—Rx Offload”, Mellanox, Dec. 3, 2017, 5 pages. [cited by applicant]
Stewart, Randall, et. al., “Optimizing TLS for High-Bandwidth Applications in FreeBSD”, Netflix Inc., Feb. 13, 2015, 6 pages. [cited by applicant]
Watson, Dave, “Crypto kernel TLS socket”, https://lwn.net/Articles/665602/, Nov. 23, 2015, 2 pages. [cited by applicant]
Watson, Dave, “KTLS: Linux Kernel Transport Layer Security”, Facebook, San Francisco, USA, Sep. 26, 2016, 4 pages. [cited by applicant]
International Search Report and Written Opinion for PCT Patent Application No. PCT/US21/52078, Mailed Jan. 19, 2022, 11 pages. [cited by applicant]
Nowlan, Michael, “Unordered Delivery in TLS-Encrypted TCP Connections”, 690 Report, Department of Computer Science, Yale University, Published 2011, 7 pages. [cited by applicant]
Final Office Action for U.S. Appl. No. 16/838,888, Mailed Feb. 7, 2023, 31 pages. [cited by applicant]
“Kernel Transport Layer Security (kTLS) Offloads”, Nvidia, https://docs.nvidia.com/networking/m/view-rendered-page.action?abstractPageId=37849165, downloaded from the internet Nov. 2, 2022, 2 pages. [cited by applicant]
Baldwin, John, “TLS Offload in the Kernel”, FreeBSD Journal, May/Jun. 2020, 12 pages. [cited by applicant]
Mellanox, Chelsio and Netflix, “Kernel TLS and hardware TLS offload in FreeBSD 13”, Mellanox Technologies, Sep. 29, 2019, 30 pages. [cited by applicant]
Nowlan, Michael F., “Unordered Delivery in TLS-Encrypted TCP Connections”, Department of Computer Science, Yale University, Downloaded from the internet Nov. 2, 2022, 7 pages. [cited by applicant]
First Office Action for U.S. Appl. No. 16/838,888, Mailed Jun. 7, 2022, 23 pages. [cited by applicant]
Cited By (1)
US 12,457,243