Secure Cryptographic Communication Between Devices

Our modern world is a sea of complex and rapid communications networks. For most use cases, there is an expectation of secure communication.

When two servers (or cloud services) are talking, there are mature solutions to protect that communication. But what if one or both ends of the communication pipe are on devices outside the data center?

For example:

  • Medical Devices increasingly communicate with hospital or clinic networks (and each other) delivering information from which a diagnosis may be made and treatment administered.
  • Every modern car, whether traditional or electric, is a self-contained network of multiple systems managing drivetrain, interior climate, safety systems, and entertainment. These devices are all linked on the CAN bus of the vehicle and increasingly also communicate to the outside world via their own means, or via the mobile devices in use by the vehicle’s occupants.

In both these examples, there’s a requirement to keep communications between components secure. But with the equally large number of connections to the outside world (Bluetooth, WiFi, LORAWAN, 5G, etc.), the threat from malicious actors, or even simple oversights, can leave these systems open to compromise.

Cryptographic protection of the data streams in transit is often seen as the way to ensure secure communication. But simply using encryption protocols is not enough. What of the encrypt and decrypt processes at either end of a transmission? Are these processes secure? If not, they are the easiest points to attack and gain access to the information, or to corrupt or even replace the legitimate data stream.

How can the encryption process compromise secure communication?

Secure communication means protecting both the privacy and integrity of data. Encryption is used to achieve this while the data is in transit. When dealing with communications, the assumption is that encrypting data while it is in transit is enough. If the stream is encrypted, then we're good right? Um, not exactly…

So far we’ve considered the communication pipe and how to attack that pipe through the side wall. Encryption has stopped these attacks.

Let’s look at the problem from a different perspective. Let’s move from the side of the pipe and look at the ends. At the end of the pipe we have both the data and encryption key(s) sitting in the clear. This gives us everything we need to bypass the encryption, compromising both the privacy and integrity of the data.

If one end of the pipe is attached to a server or cloud API, while not impenetrable, the defenses are mature.

There is a good chance the other end is in a device out in the wild. For example, that device could be a desktop application using AI to process data in real-time, it could be a mobile application authorizing high-value banking transactions, or a medical IoT device collecting safety-critical patient data. The list of use-cases where one end of the communication is potentially exposed is endless.

When cryptographic operations are running within software on devices at the edge, threat actors can use reverse engineering techniques to extract those secrets. That compromises the security of our communication pipe.

Open platforms and secure communication

As you can see from the examples, our endpoint is often in a consumer-off-the-shelf (“COTS”) device such as a smartphone or tablet. COTS devices are designed as open platforms—they have to be in order to allow their many uses determined by software, thus they are inherently insecure and cannot be treated as security trusted platforms.

Given that apps are open for anyone to download from the operating systems’ app stores, the analysis of apps’ code by potential bad actors, including access to encrypt/decrypt functions, APIs, and IP is simple: just download a target app, open it using open source tools like Jadx, and search for the required data.

As developers integrating with Twitter’s APIs discovered to their cost recently, it’s not hard to find “private” data within mobile apps.

The classic solution is to perform any sensitive processing at the edge within a secure hardware enclave, such as a Trusted Execution Environment. As not all processors in a network will be equipped with these—and when they are, flexible access often isn’t provided—developers can only rely upon their own software to be the first, second, and third line of defense.

Some of these issues have been identified by individual market sectors (such as Mobile Payments and even Digital Rights Management), but the silos between industries mean that best practices are rarely shared.

Securing communication in the end point

The issues above can be addressed if the cryptographic algorithms are protected in the end-points. By doing so, designers of devices and their software engineering teams can drastically reduce the risk of attacks on the communications.

This means that the full use cycle of a crypto algorithm (at rest, in use and in transit) has to be protected within the software end-points.

This is only possible with white-box cryptography, which dissolves the sensitive keys that control the encrypt/decrypt processes into the running code of an application, thus protecting the process before the encrypted data can be passed to the next node.

PACE White-Box Works is a 3rd generation white-box tool kit that goes beyond the traditional model of simply providing a library and hoping to protect cryptographic processes on the end-points. Instead, White-Box Works allows developers to build their own unique, protected versions of the cryptographic algorithms critical to encrypt/decrypt processes, as well as securing other software secrets.

Developers are free to creatively build their architectures, uniquely tailored for their own use cases and platforms. Given that many edge devices have limited processing capabilities, tailoring architectures to the use case helps maximize functionality and security.

For more on how PACE Anti-Piracy can support your security needs or to see a demo of White-Box Works, contact us.

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram