Security experts have been talking about ‘crypto-agility’ for years now. It is a vague term that doesn’t do justice to the complex and varied use cases of cryptography. The reality is that cryptographic agility will be complex to build, as there are many interacting layers in the software and hardware security stack. SandboxAQ’s Sandwich library is one open-source tool that will help to bring crypto-agility to certain software applications, and in this post we’ll explain how it can streamline security engineering in Telecommunications.
Sandwich acts as an intermediary layer between software libraries which provide cryptographic functions (referred to as ‘backends’), and applications which rely on them for security. This communication link between general purpose software developers, and highly specialized cryptographers is a lossy one. The former have a wide remit and are primarily concerned with performance and functionality of their application, whereas the latter are often valuable due to their encyclopedic knowledge of algorithms, specifications, the pitfalls of using the wrong ciphersuite or why a certain insecure algorithm can’t be deprecated. At a Big Tech company I used to work at, one team of cryptographers acted as consultants to ensure that software developers didn’t make mistakes when selecting cryptography configurations for their applications. Neither the cryptographers (who would much rather be designing/implementing/breaking cryptosystems) nor the software engineers (who wanted to get on and ship code) were satisfied by the arrangement.
We know that Telcos recognise the importance of security, but really care about speed and reliability of communications. Less time spent navigating cryptography quagmires means more time engineering high performance solutions for end users. In search of a solution to the problem, we decided to write a cryptography library called Sandwich…
So how does another library help the situation? Well, instead of yet another backend, this library is intended to slide in between the cryptography providers on the bottom, and the applications on top, reducing friction between the two layers. Note we don’t implement cryptography. We just aim to provide a clean and usable interface to help engineers to access secure cryptography.
The next two sections describe how and why to offload the cryptographic complexities to Sandwich, culminating in the third: designing new innovative solutions without worrying about underlying crypto primitives.
When directly interfacing with cryptography backends, such as OpenSSL, it is devilishly easy to screw up. If you have a spare couple of hours, browse this thread for user gripes. In OpenSSL’s case, this is due to its long history as being the gold standard for secure communication over the internet. During this time it has needed to maintain backward compatibility and outdated programming approaches. Even the insecure primitives it supports are due to its age, dating back to 1998, presumably when these primitives were still regarded as secure.
There are some fascinating stories of cryptanalysis, vulnerabilities and exploits to uncover for security archaeologists, but this is not helpful for today’s engineers who work in fast paced environments and need to deploy complex cryptographic primitives and protocols correctly. Sandwich’s abstraction addresses this issue. First select your backend provider, then proceed to configure your TLS settings with a clean interface, all the while being restricted to modern and secure options. The ability for security non-experts to make sensible and secure selections will be a significant timesaver, enabling organizations to ship software faster and with greater confidence in their security posture.
We see a long future for Sandwich and tools like it. And with time it will fall prey to the same afflictions as OpenSSL’s graveyard of cracked crypto. Sometimes these developments occur without prior notice. The hash algorithm MD5 had been weakened several times in the years leading up to the MD5 exploit in Flame malware. Clearly, however, the existence of exploits in the wild came as a shock to cybersecurity vendors, among whose products it was still widespread. Other times we can see the wave rolling towards us from afar, as with the quantum threat to public key cryptography.
So what is to be done when the inevitable comes to pass, and an in-use ciphersuite is deemed insecure?
Let’s say a secure algorithm is available in a different backend. But updating to a new backend is scary. Let Sandwich handle the switch, and any API changes incurred. Google’s decision to fork OpenSSL and maintain its own version, BoringSSL, was made in the wake of Heartbleed, when a bug in OpenSSL leaked internal process memory, potentially including private key materials. The availability of alternative backend implementations may have provided the option of a secure replacement in the short term, possible only if the actual switch was also easy. Note here that BoringSSL does not have a one-to-one API mapping to OpenSSL, an issue Sandwich can worry about instead of you.
SandboxAQ developed TurboTLS with University of Waterloo, to achieve faster handshakes between long distance servers that are not able to benefit from QUIC or other UDP-based protocols. The idea was to switch the transport protocol between the handshake and record layer portions of TLS. We implemented TurboTLS in Sandwich and you can read more about that work here. This was possible because of Sandwich’s input/output interface, making TLS implementations versatile and highly configurable.
TurboTLS can then be implemented via a transparent proxy to turbo-boost long distance TLS connections of all versions. This is great for legacy servers which aren’t eligible for upgrade for some reason or other, as these proxies sit in front of the legacy servers and do not require modifications to them. It does this by intercepting TLS requests and adapting the transport layer, thus removing a costly round trip between Server and Client.
Furthermore, the intuitive interface which enables switching of algorithms means that teams can benchmark new cryptography which may not yet be production-ready, and switch efficiently back to production-ready algorithms. SandboxAQ previously helped Vodafone and SoftBank do just this for post-quantum cryptography, the next great cryptography transition.
With Sandwich, one could test a wide variety of experimental algorithms for benchmarking, and be ready to switch to production level algorithms from different libraries with a minimum of fuss.
The ideas above represent our vision for Sandwich. Some we have already brought to life, like TurboTLS, while others such as multi-backend support are at an earlier stage. We intend to build Sandwich according to the needs of the security and communications community. We want to solve the most acute security problems that you are living with so that you can focus on performance. Please write in and let us know what flavors you’d like your cryptography Sandwich to come in.
David Joseph is a product manager in the Quantum Security Group, where he was the first cybersecurity employee. Formerly a researcher, he has a background in theoretical cryptography and quantum computing for attacking information security, which he studied during his PhD at Imperial College London. He is an author on “Syndrome Decoding in the Head”, a digital signature scheme submitted by SandboxAQ and CryptoExperts to the NIST call for signatures, and a leading author on the 2022 Nature paper “Transitioning Organizations to Post-Quantum Cryptography.”
