We humans are funny creatures. When it comes to how we organize ourselves, we like for someone to be in charge. But we don’t want them to be too much in charge. Exactly how that balance is set is a point of constant friction around the world, and there’s no one right setpoint for everyone or every culture.

System design inherits this ambivalence. We don’t want chaos, but we want maximal individual freedom and flexibility. So we want standards, but not too many. And we like reference designs, but we want to be able to customize them and make them our own.

It’s all about adding value: we all want to build something that’s uniquely us. From a business standpoint, we’re hoping that “that special something” will excite customers and become a sales differentiator. But, while we want to put our custom touches on it, we don’t want to develop everything from scratch, and we tend to eschew redundancy as being inefficient (unless it’s a requirement for safety purposes, in which case we go along begrudgingly).

In one very specific area, HCC Embedded describes encryption – a critical component of security – as being in a state of too much chaos and overlap in current systems – particularly ones that target the Internet of Things (IoT). Security is a big topic in the IoT (one we’ll go into more broadly in the future), but, according to HCC Embedded, encryption has been a requirement that had to be met – not by the systems themselves, but by the applications that run on the systems.

So if an application needs encryption for communicating data, the developer has to build it into the app. That likely means researching the wide variety of algorithms to decide which one(s) are best suited to the task and then researching implementations to see if there’s one that can work off-the-shelf. If not, then someone might need to get busy writing code.

It’s unlikely that anyone would be able to change this system of matching the algorithm to the task, since encryption must fit the app in form and function. But what happens when another application on the same platform needs encryption?

In that case, according to HCC Embedded, the folks developing that second app will presumably go through the same process – selecting a set of encryption algorithms, looking for – or creating – implementations, and then building them into their app. If they happen to choose the same algorithms that the first team chose, well, then there will be two implementations of that algorithm in the system. (And if they happened to use the same implementations, then there will be two iterations of the same code – not shared as a DLL.)

So… what kinds of systems does this apply to? When we think “application” or “app,” it’s easy to think of phones and servers, but there are plenty of things in IoT Things that qualify as well. HCC Embedded’s Dave Hughes listed a few standard such “apps”:

• Bootloaders, for protecting application code
• TLS/SSL for secure sockets
• SSH – secure sockets shell
• IPsec for network security
• SNMP (v3) for network management
• System applications (that is, the app-level communication and data requirements)

That could reflect a lot of repetition if each one handles its own security independently. In addition, it’s not like each of these picks one algorithm. In many cases, the Thing will negotiate with something else to decide on the fly which algorithm to use for a session. Each of those apps needs to keep on hand a copy of each of the algorithms it might need. That’s even more repetitively redundant.

If one were to be unhappy about that redundancy, then the pendulum might be released in the opposite direction: to build the security into the underlying platform and then require all of the apps to use the built-in code. But this would be problematic in a few ways.

First, it may simply violate designers’ sense of who’s in charge. Being forced to use something you didn’t have a voice in choosing tends to rankle, even if the dictated algorithms end up being your first choice when all is said and done.

On a less subjective note, it’s hard for platform designers to think of every possibility, so there’s a good chance that the dictated choice(s) won’t suit everyone’s needs. And even if the algorithms are well chosen in the abstract, encryption and security-related functions are, almost by definition, mission-critical code, so designers and managers will be concerned about the quality of the code – reserving the right to use a different implementation if there is any concern about what’s been handed to them.

So both ends of the pendulum swing have issues: one is too inefficient; the other too draconian. It is into this scenario that HCC Embedded has proposed a different solution – one that tries to strike the right balance between flexibility and efficiency.

What they’ve launched is an encryption manager. This is code that operates at the platform level, not at the application level. It has been written using what they refer to as a “formal process,” meaning that they’ve gone through some of the pains that most folks don’t want to endure in order to ensure robust code. In particular, they’ve achieved MISRA compliance, along with full MC/DC compliance. The point is that they have designed this in a way that should allow its incorporation into a wide variety of systems without itself introducing any new vulnerabilities.

The manager then allows a wide variety of algorithms to be registered at the platform level. Each algorithm needs to be registered only once; it’s then available to any app that wants to use it. Apps writers who don’t find what they want can register their own algorithms (or their own implementations of algorithms). This is how the balance is struck between a platform-level set of resources and the freedom for applications to select their own encryption.

The manager supports a discovery process; it will provide a handle to any of the registered algorithms. The good news here is that, if an application wants to use a particular standard and the system already has it, then it simply gets the handle and uses it; no more building the encryption into the app. Encryption is now a system service.

And if there’s more than one implementation of a particular algorithm? No problem; you can register multiple implementations, and they’ll each have a separate handle.

Of course, one other benefit of something like this can be a huge savings in development time – if the system includes algorithms that you want, implemented in a manner that gives you the confidence you need. HCC Embedded is trying to accommodate both of these desires as well, including “verified” versions of AES, 3DES, DSS, EDH, MD5, RSA, SHA1, and SHA256 algorithms.

How do you know they’ve been verified? Because they say so. Yeah… that might not be good enough for you. And they figured that as well, so they’ve included a test suite that’s intended to let you verify for yourself that these algorithms work as promised. And if you don’t like them? Then you can add your own.

There’s one other concern that folks might have reasonable motivation for checking out. After all, “central management” often conjures up visions of bloat. Any goodness of such a manager falls apart if it takes a lot of space and kills performance. HCC Embedded claims that their code footprint is less than 1K bytes, so it shouldn’t blow out the system. And access to the algorithms is managed by the handles – it’s a simple extra level of indirection. Given the compute-intensity of many of these algorithms, there should be no detectable loss of latency.

One other consideration that’s been built in: if your platform has accelerated encryption through hardware, it can also be hooked into the manager. It becomes one of the “discoverable” options.

With this system, HCC Embedded is trying to thread that needle through what they’re hoping is an optimal level of efficiency coupled with enough flexibility to keep both platform and app developers happy. They’ve now got a manager that’s clearly in charge, but, if HCC Embedded has done it right, the manager won’t become a despot.

More info:

HCC Embedded’s Encryption Manager