US-12627502-B2 - Achieving high SSL/TLS throughput in embedded devices

US12627502B2US 12627502 B2US12627502 B2US 12627502B2US-12627502-B2

Abstract

An embedded system includes hash message authentication code (HMAC) hardware. The HMAC hardware receives data in separate data transfers to compute a hash. The HMAC hardware receives data of unaligned lengths in at least one of the separate data transfers. The data of unaligned lengths includes fewer valid bytes than the transfer size. The HMAC hardware responds to a residue indication indicating valid bytes associated with the data transfer to fill in the residue from a subsequent data transfer. For each data transfer the HMAC hardware receives an indication of whether the data is final data or if more data will be transferred for computation of the hash. The embedded system loads a linear buffer directly from scatter buffers, which contain encrypted data from a network. Decrypted data in the linear buffer is sent to a host using a direct memory access (DMA) operation responsive to a host request.

Inventors

Venkatesh VINJAMURI
Subba Reddy Kallam
Atul Suresh Joshi
Venkata Siva Prasad Pulagam
Satish Nallamalla
Rahul Kumar GURRAM

Assignees

SILICON LABORATORIES INC.

Dates

Publication Date: 20260512
Application Date: 20231127

Claims (14)

1 . A method comprising: receiving first data at a hash message authentication code (HMAC) hardware at a first time in a first data transfer, wherein the first data is received as data of unaligned lengths, the data of unaligned lengths being smaller than a number of bytes supplied to the HMAC hardware in the first data transfer; identifying to the HMAC hardware a number of unused bytes in the first data transfer, the unused bytes constituting a residue; receiving second data at the HMAC hardware at a second time in a second data transfer that is separate from the first data transfer; filling in, by the HMAC hardware, the residue from the second data transfer subsequent to the first data transfer; receiving third data at the HMAC hardware at a third time in a third data transfer that is separate from the first data transfer and the second data transfer; and performing a hash operation in the HMAC hardware using the first data, the second data, and the third data.
2 . The method as recited in claim 1 , further comprising: indicating that the first data is not a final data to be received prior to completing the hash operation; indicating that the second data is not the final data to be received prior to completing the hash operation; and indicating that the third data is the final data to be received prior to completing the hash operation.
3 . The method as recited in claim 1 , wherein the first data is prepended to decrypted secure sockets layer (SSL)/transport layer security (TLS) data, the second data is the decrypted SSL/TLS data, and the third data is padding data added to an end of the decrypted SSL/TLS data.
4 . The method as recited in claim 1 , further comprising: transferring secure sockets layer (SSL)/transport layer security (TLS) data into a linear buffer from scatter buffers; decrypting the SSL/TLS data; and storing decrypted SSL/TLS data in the linear buffer.
5 . The method as recited in claim 4 , further comprising: transferring the decrypted SSL/TLS data responsive to a read request using a direct memory access (DMA) operation that supports at least up to a 16 KB DMA operation.
6 . An apparatus comprising: a hash message authentication code (HMAC) hardware, wherein the HMAC hardware is configured to: receive data in separate data transfers to perform a hash operation; receive data of unaligned lengths in the data the HMAC hardware receives, the data of unaligned lengths being smaller than a length of a transfer to the HMAC hardware; receive a residue indication to indicate to the HMAC hardware a number of bytes in the data of unaligned lengths without data for use by the HMAC hardware, the number of bytes constituting a residue; and fill in the residue from a subsequent data transfer responsive to the residue indication.
7 . The apparatus as recited in claim 6 , wherein the data the HMAC hardware receives includes first data received at a first time; wherein the data the HMAC hardware receives includes second data received at a second time; and wherein the data the HMAC hardware receives includes third data received at a third time.
8 . The apparatus as recited in claim 7 , wherein the HMAC hardware receives a first type of indication to indicate that the first data is not a final data to be received prior to completing the hash operation; wherein the HMAC hardware receives the first type of indication to indicate that the second data is not the final data to be received prior to completing the hash operation; and wherein the HMAC hardware receives a second type of indication indicating that no more data after the third data is to be received prior to completing the hash operation.
9 . The apparatus as recited in claim 8 , wherein the first data is prepended to decrypted secure sockets layer (SSL)/transport layer security (TLS) data, the second data is the decrypted SSL/TLS data, and the third data is padding data added to an end of the decrypted SSL/TLS data.
10 . The apparatus as recited in claim 9 , further comprising: a plurality of scatter buffers; and a linear buffer communicatively coupled to the scatter buffers to receive data directly from the scatter buffers.
11 . The apparatus as recited in claim 10 , wherein the apparatus is responsive to a read request by a host to send decrypted data stored in the linear buffer to the host using a direct memory access (DMA) operation.
12 . A system comprising: a hash message authentication code (HMAC) hardware, wherein the HMAC hardware is configured to: receive data in separate data transfers to compute a hash for message authentication; receive data of unaligned lengths in at least one of the separate data transfers, the data of unaligned lengths including a first number of bytes of valid data in a transfer having a second number of bytes, the second number of bytes being greater than the first number of bytes; receive an indication of a residue indicating a number of bytes without data in the data of unaligned lengths and fill in the residue from a subsequent data transfer responsive to the indication of the residue associated with the data of unaligned lengths; and receive, for each of the separate data transfers, an indication of whether the data is a final data transfer for computation of the hash or if more data is to be transferred after current data for computation of the hash and compute the hash responsive to the data being the final data transfer.
13 . The system as recited in claim 12 , further comprising: a plurality of scatter buffers to store encrypted data that was transferred over a network; a linear buffer communicatively coupled to the scatter buffers; and wherein the system is configured to load the linear buffer directly from the scatter buffers.
14 . The system as recited in claim 13 , wherein the system is responsive to a read request by a host to send decrypted data stored in the linear buffer to the host using a direct memory access (DMA) operation.

Description

BACKGROUND Field of the Invention This disclosure relates to throughput on secure sockets layer/transport layer security (SSL/TLS) in embedded devices. Description of the Related Art There are increasing demands for secure communication in today's world. To address those demands, it is desirable to ensure high (SSL/TLS) throughput. SSL/TLS provides for secure network communications by encrypting the communications for transport over the network. The data is then decrypted for use by the receiving device. FIG. 1 illustrates a prior art approach for the receive flow in a portion of an embedded device receiving SSL/TLS data. The SSL/TLS layer requests data from the transmission control protocol/internet protocol (TCP/IP) layer and receives the data from the TCP/IP layer responsive to the request. The TCP/IP layer includes the TCP scatter buffers 102. A common TCP payload size is 1460 bytes. A larger SSL/TLS record, e.g., 16 kilobytes (KB), can be broken up into transfers of smaller portions of 1460 bytes each. The scatter buffers 102 are sized to contain 512 bytes of data. A 1460 byte payload along with the required packet and header information requires four scatter buffers. Assume that the SSL layer requests a record sized at 16 KB. The TCP scatter buffers 102 receive multiple 1460 byte payloads and transfer the 1460 bytes to an intermediate linear hold buffer 104 responsive to the request. Once the complete TCP payload of 1460 bytes is copied from the four scatter buffers 102 to the linear intermediate hold buffer 104, the four scatter buffers are freed at the same time. Once the intermediate linear hold buffer is filled, e.g., with 1460 bytes of the requested data, a memory copy operation transfers the contents of the intermediate linear hold buffer to the 16 KB linear buffer 106, which is sized to accommodate a 16 KB payload. The SSL/TLS layer read request length may not be equivalent to the length of the TCP packet received. For example, the read request may be for less data than contained in the TCP packet received. So, a portion of the data that is in the intermediate linear hold buffer that is not part of the SSL/TLS request is stored in the intermediate linear buffer 104 in the SSL layer to satisfy a future SSL/TLS layer request. Once the 16 KB linear buffer has received the encrypted data transmitted over the network, decryption logic 107 receives encrypted data stored in the 16 KB linear buffer 106, decrypts the data, and the decrypted data is then stored back into the 16 KB linear buffer 106. In addition, a message authentication process occurs as described further herein. Once the record is decrypted, the record is available for the host 110. FIG. 2 illustrates a prior art approach to transferring the data from the 16 KB linear buffer 106 to the host 110. In the approach illustrated in FIG. 2, transferring a 16 KB size SSL/TLS record requires 12 requests-responses (request from the host, response from the SSL/TLS layer in the Networking Processor (NWP) as the maximum packet size that can be transferred to the host is limited to 1460 bytes in the embodiment illustrated in FIGS. 1 and 2. Those 1460 bytes are stored in the host scatter buffers 108 shown in FIG. 1. In order to transfer one 16 KB record, 1460 bytes of data is copied into the scatter buffers 108 from the 16 KB linear buffer 106 responsive to each host request and then transferred to the host from the scatter buffers 108. That approach not only requires multiple (12) request-responses but also requires additional memory for creating the host scatter buffers 108. FIG. 2 shows the 16 KB linear buffer 106 starts with 16 KB of decrypted data and after 12 requests-responses the entire 16 KB record has been transferred through the scatter buffers 108 to the host 110. The hatched portion in FIG. 2 illustrates the cumulative amount of data that has been transferred. Referring back to FIG. 1, the HMAC (hash-based message authentication code) SHA (Secure Hash Algorithm) hardware 109 shown in FIG. 1 requires data be sent on aligned four byte boundaries and supports only a one-shot input meaning that data cannot be transferred in multiple transfers. Thus, all data sent for a particular HMAC SHA hardware operation must be aligned on four-byte boundaries and must be sent in one shot. Considering an SSL record size of 16 KB, before computing the hash on the given data, HMAC computations can require data be prepended and also require padding data to properly account for the required block size. Thus, 13 bytes of HMAC inner data is prepended to the record and the data must be padded if the given data is not a multiple of the HMAC block size. With HMAC hardware supporting only single shot mode, that requires a second linear buffer to be allocated sized at (13 bytes+record size+padding data) and the (13 bytes+record size+padding data) must be memory copied into the second linear buffer. SUMMARY OF EMBODIMENTS OF THE INVENTION In order to provide enhanced