Let the hardware do the heavy lifting

Iron Power

Inline TLS in Linux

Support for inline TLS was introduced in Linux kernel 4.13 [3]. The setsockopt utility is called from a user application to register the TLS as ULP on the TCP/IP stack and program the crypto keys. The handshake is executed in the TLS library, and record processing is offloaded using sendmsg/sendfile calls of sk->sk_prot. Currently, the Tx (encryption) path is proposed for inline processing, but hardware vendors can add support for inline Rx (decryption). The solution I refer to supports inline Tx/Rx (i.e., inline encryption and decryption of a record in hardware).

The steps to using inline TLS are:

1. Create the TCP socket:

fd = socket (AF_INET, SOCK_STREAM, 0);

2. Set the TLS ULP and initialize the sk->sk_prot required for inline TLS support. The hardware driver can have custom definitions for some of the struct proto routines associated with the socket.

setsockopt(fd, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

3. Exchange TLS library handshake messages. The new keys are ready at the CCS stage and made available to the driver with another sockopt option (the crypto_info format is shown in Listing 1).

setsockopt(fd, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info));

Once the keys are programmed and the inline TLS driver is ready to process send and receive messages, the TLS library should skip record encryption/decryption/authentication, to be done in hardware.

Listing 1

crypto_info Format

struct tls12_crypto_info_aes_gcm_128 {
struct tls_crypto_info info;
unsigned char iv[TLS_CIPHER_AES_GCM_128_IV_SIZE];
unsigned char key[TLS_CIPHER_AES_GCM_128_KEY_SIZE];
unsigned char salt[TLS_CIPHER_AES_GCM_128_SALT_SIZE];
unsigned char rec_seq[TLS_CIPHER_AES_GCM_128_REC_SEQ_SIZE];
};

Conclusion

Implementing hardware-assisted TLS in an inline fashion reduces latency and saves host CPU cycles. This solution finds good application for media servers streaming encrypted data to several thousand clients. Inline TLS offloading ensures a single pass over PCIe, thereby enabling more throughput.

Work still remaining for the future includes:

  • Leveraging TLS crypto offload capabilities to secure a wider range of applications.
  • Consideration for implementing hardware-assisted UDP-based Datagram Transport Layer Security (DTLS).
  • Assessing TLS 1.3, the newer version of TLS enhanced to reduce handshake time by half and make web pages load faster.

Infos

  1. Crypto Kernel TLS socket, Dave Watson. Accessed September 22, 2016: https://lwn.net/Articles/665602
  2. Inline TLS performance: https://www.chelsio.com/wp-content/uploads/resources/t6-100g-inline-linux.pdf
  3. Kernel documentation: https://www.kernel.org/doc/Documentation/networking/tls.txt

The Author

Atul Gupta leads Security and BIOS software development at Chelsio Communications and is actively working on crypto solutions for next generation security chips.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=