Post-Quantum Computing Threatens Fundamental Transport Protocols

The Transport Level Security (TLS) protocol is one of the few rock-steady spots in the rapidly changing computing industry, but that’s about to change as quantum computers threaten traditional encryption schemes.

Because TLS is fundamental to network communications, including allowing Internet of Things (IoT) devices to function properly, researchers already are exploring both hardware and software defenses. Security vendors are preparing to have counter-measures in place before quantum computing becomes more available at some point in the next decade. For chip designers, this means understanding the risks and how best to implement solutions well in advance of actual threats.

If a systems architect or device physicist from 1994 stepped into a time machine and set it for 2024, they would be flummoxed by the new terms and concepts in hardware. But if a network security engineer made the same time trip, most of the basic ideas would be familiar. The security protocols that undergirded the early internet in the 1990s have evolved enough to secure the IoT ecosystem. In 1999, the first official transport layer security (TLS) protocol was published. The previous protocol was the secure sockets layer (SSL), which Netscape introduced in 1994. Starting with SSL 1.0., there have been only six major updates in 30 years. The latest, TLS 1.3 (IETF RFC 8446), was published in 2018.

“These protocols evolve slowly, especially if they’re good strong protocols,” said Mike Borza, principal security technologist at Synopsys. “Most of the protocol evolution in SSL, and then TLS, has been to fix security problems as they’ve been found. TLS 1.3 is a huge new version of TLS that changed a lot of the details. It’s more efficient for the session negotiation, which is the ‘Hello’ protocol or session-setup protocol. The actual bulk data part of the protocol is very consistent with other older versions of TLS in terms of the record processing. What has changed is many of the ciphers and modes that were available, against which people found exploits or common misconfigurations that led to blights. These have been eliminated in TLS 1.3.”

Fig. 1: Transport layer security protocols and security schemes. Source: Flex Logix

The fundamental structure of SSL/TLS protocols is a secure end-to-end connection between dedicated endpoints, with security parameters established during the “handshake” when both sides connect. The encrypted packets then appear as gibberish to the rest of the network. “It’s a shocking amount of computation that’s actually happening,” said Scott Best, director of anti-tamper security technology at Rambus.

The security architecture has allowed the protocols to extend beyond their roots from the 1990s, when they were employed only to establish secure sessions on the client side for web browsers. “These days, TLS is being used in a lot of other protocols,” said Borza. “For example, Open VPN is built on top of the TLS protocol. It’s being used a lot for machine-to-machine communications, which was never what it was envisaged for, but that’s now well within the realms of applications for TLS. There’s a related protocol called DTLS, which is essentially a packetized version of TLS. TLS operates over continuous streams of data. By contrast, DTLS is designed to operate using packets of data, which is a fundamental distinction.”

TLS lives on top of TCP, the transmission control protocol, which operates over a packet layer. At the most fundamental level, networks deliver packets, which are agnostic to each other. On top of that packet protocol, there’s TLS, which is designed to be a continuous, reliable stream of data that is independent of, and agnostic to, whatever the underlying network technology is and how it has packetized data. At this level, it’s not about including cryptographic schemes. It’s about ensuring the packets are assembled correctly.

Applications that are especially latency-sensitive generally employ DTLS (datagram transport layer security), a similar protocol that rides on the UDP (user datagram protocol) layer. “If you’re trying to transmit video, TCP/IP can get in the way because it’s always looking for a response,” said Best. “You don’t send your video until it gets all the responses. But all the acknowledgments of the data take up the bandwidth that you could have used to send more video. To avoid that, you use UDP instead of TCP.”

DTLS is also generally the chosen protocol for IoT because of how it handles latency. “TCP takes a fair bit of resources to get that illusion of a continuous stream of data,” said Borza. “To get an open channel that’s reliable — so that when you push bits in at one end and they pop out the other end and they’re always in order — takes a fair bit of software and a fair bit of memory to buffer data, to reorder data, etc. As a result, TCP for a lot of IoT devices is more than they can bear to handle. That’s why DTLS was created. It operates over an unreliable network that is just capable of delivering, on a best effort basis, a datagram from one place to another.”

A relatively recent addition to the functionality is REST (representational state transfer), which works as an API with TLS to create stateless web-based applications.

“When you make a request to a server, the server is supposed to respond to that request. If the client is completely satisfied with the response, they tear down the connection and it starts up later,” said Best. “With RESTful APIs, the IoT client can establish a connection to a server and just leave it alone, leave it quiet. It connects, it registers, and says, ‘I’m listening, and if you ever need to talk to me, you should respond to the channel.’ But otherwise, there’s no data actually occurring on the channel, so it’s a lightweight thing for the client and the server to maintain these RESTful connections. The nice thing about it is the IoT device always connects to the server. The server never has to connect to the device. Directionality matters on the internet, so in this type of connectivity the initiator is always the IoT device.”

Current TLS vulnerabilities
Authentication is key to TLS security. “The hardest part of TLS is, ‘Who am I talking to?’” said Best. Answering that question securely is at the heart of the protocol—and future post-quantum security challenges.

“If I use a URL with an HTTPS, I’m saying I want a secure communication,” said Jim Montgomery, principal solution architect of TXOne. “But in order to first establish the communication channel using TLS, there’s a certificate exchange, and then the encryption of the data based on that certificate, so that only the originating and the specific points will have the ability to decrypt that traffic based upon the certificate. By encrypting the communication between the nodes, you eliminate vulnerabilities like man-in-the-middle attacks or the ability to view the data in plain text.”

The validity of certificates is based on public key encryption. Unfortunately, real certificates can be spoofed, and counterfeit certificates can be issued by attackers who seek either to capture data or completely disrupt a system. Fortunately, successful incidents are now rare, and the IETF has an elaborate system to ensure authenticity.

“There’s no reason now for a browser to consume a malicious certificate and get confused about it,” said Best. “Once a theft actually happens, there are low-latency ways that that information can be percolated, within minutes, rather than within days. That’s a distinct improvement over how people were doing it 20 years ago.”

Far less reassuring is the potential ability of quantum computers to break traditional encryption algorithms.

“Quantum cryptographically relevant computers would be able to look at an authentic certificate, which contains a public key and a signature, and from that information — or some combination of other information, like the issuer’s public key — they could figure out what the secret signing key is,” said Best. “Using that information, a malicious operator that has access to a cryptographically relevant computer would be able to create bogus certificates that look completely authentic.”

Cures for contemporary security
In addition to employing quantum-safe algorithms, security can be increased by both software and hardware solutions.

Segmentation and access permissions are primary ways to control access, so that only authenticated devices can communicate with their authorized partners. Currently, most of that work is performed by VLANs. “The positive is that most of the switching equipment at the enterprise level is going to support VLANs,” said Montgomery. “The downside is the administrative overhead for VLANs.”

The process can be simplified through the creation of automated whitelists, noted Montgomery. “We’re introducing specific hardware into the environment that can automate that function, by listening to the traffic, and then creating whitelists based upon the traffic that you approve.”

Any of these approaches should be based on zero trust. “Who should be talking to who is foundational to ensuring security, because you’re limiting that ability for other devices to either spread lateral movement or to attack the system just because they’ve been allowed to communicate with devices,” he explained.

Jayson Bethurem, vice president of marketing and business development at Flex Logix, is an advocate of “crypto-agility,” which in practice means employing devices like FPGAs that can constantly reprogram themselves to keep up with evolving threats. “Post-quantum computing will render all of the older encryption algorithms useless, whether they’re integer factorization, discrete logarithmic, or elliptical curve. All of these types of foundational cryptographic algorithms will become insecure. Crypto-agility is going to be needed to fight this problem.”

Bethurem explained that one solution for cryptography is to intercept packets before they even get into the memory subsystem, so security analysis can be done at the transport layer. “As the packets are being dissected, there’s an audit where your own algorithms are looking for malicious types of activities. You can use an embedded FPGA to continuously adapt these algorithms because the threats constantly evolve, but you can stop malicious traffic like distributed denial-of-service types of attacks.”

Conclusion
To properly address the security issues with transport layer security, experts say the best strategy is to be pragmatic. For example, it’s not important for a security engineer to know that the transport layer is Layer 4 of the OSI protocol stack.

“Anybody who knows what TLS is, already knows where it is in the stack,” said Best. “And anybody who doesn’t know what TLS is won’t learn anything from knowing that it’s Layer 4. Our customers want to know important, precise details, like the key size that’s protecting the TLS, as well as other details. When we’re doing the key exchange, what algorithm is being used to establish that session key? What exactly was the algorithm used to sign the certificates? Is it quantum safe, or is it something really weak? Is it a very old version of RSA or the newer version? Engineers get into it pretty quickly about speed, authenticity, and privacy, but nobody says the letters OSI during that conversation.”

Synopsys’s Borza offered practical advice to avoid unfortunate choices, especially around IoT. “For starters, stick with standards and don’t try to invent something that you think seems good enough,” said Borza. “A lot of people have made that mistake and left themselves and their products vulnerable to all kinds of things. There are a lot of good, small implementations around these protocols that work. For example, for IoT, where space and cost are always issues, there are well-done small implementations of either TLS or DTLS that are suitable for those devices. Just stick to using those implementations and don’t try to do it yourself.”

Related Stories

Quantum Computing Challenged By Security, Error Correction
Cryptographers scramble for better security schemes, while physicists try to fix qubit errors.

Secure Your SoC From Side Channel Attacks With Adaptable Security
SoC designers ignore can’t ignore that side channel attacks are becoming highly capable of reverse engineering secret IP as well as cryptography keys and algorithms.