So… what if you woke up one day and found that some basic tenets of IoT security that you thought to be true might not, in fact, be true?

We did a huge tour through security a while back, including a look at artifacts like keys and certificates, authentication, and encryption. And the focus was on the ever-popular public-key infrastructure (PKI) setup, featuring asymmetric (public/private) key pairs.

As a quick review, so-called symmetric cryptography involves a single key that, typically, all participants share so that they can all engage in a jovial conversation. But if loose lips divulge the key, the entire network is exposed, and the laughs lapse. So conventional wisdom suggests that this isn’t the best arrangement.

Asymmetric keys involve a private key and a public key that mathematically fit together. Each node can have its own unique key pair because it publishes its public key when initiating a conversation. Encryption and hashing happen via the private key; decryption and hash verification happen via the public key. As long as the private key remains secret (only the owner can divulge it, since only the owner knows what it is – and, in the case of some key storage scenarios, not even the owner knows), security is maintained.

Rubicon Labs, however, in a conversation initiated at the recent IoT DevCon, points out some weaknesses to the whole asymmetric thing. First, symmetric keys can simply be random numbers, while asymmetric key pairs bear a mathematical relationship that Rubicon suggests is a weakness. The idea is to make that relationship so obscure (via so-called trap-door functions), that it’s practically impossible to derive the private key from the public key. In theory, it could be derived; whether we’re really at risk of this is unclear, at least with our current level of computational power.

But here’s perhaps the more important bit: in order to maintain this intractability, asymmetric keys have to be pretty long, and the computations involving them are significantly slower. Rubicon provided the following comparisons between AES (the leading symmetric cryptography standard), RSA (the oldest asymmetric approach), and ECC (a newer asymmetric approach that allows shorter keys):

(Source: Rubicon Labs)

This becomes a particular problem with IoT edge devices, since it requires more time and/or compute power than such devices typically have. You may recall that there’s yet another asymmetric approach, referred to as “algebraic eraser,” that’s intended to make for simpler computation, but, as of today, it’s still being vetted, so it’s not yet a thing.

So Rubicon’s assertion is that asymmetric cryptography can’t scale with its computational load. Rubicon’s solution is symmetric. But before we explore that, there’s some further nuance in today’s typical usage: it turns out that symmetric has more usage than you might think if you haven’t dived in yet.

The thing with AES is that it’s better at bulk encryption – as in, encrypting the content of large messages – than RSA is. And it’s got a shorter key, with less computation. So typical session setup involves everything we’ve discussed – key exchange, authentication, etc., but then, once everyone is cool with the conversation being set up, a random number is exchanged.

That exchange can partly be part of a “challenge”: “I’m going to encrypt my random number with your public key, and we’ll just see whether you can correctly decrypt it using your private key.” The other side decrypts the number and then re-encrypts it with your public key, and, if you decrypt it with your private key and it’s the same random number you started with, then all is well.

But you can then also use that random number as a session key for symmetric encryption. Yeah, we talked about how symmetric setups often have a single key for all nodes, but not in this case, since you have a different session key for each pair of conversing nodes and each session, so you no longer have the loose lips issue.

Put more concisely, you use asymmetric cryptography to authenticate and establish the session, and then you establish what Rubicon refers to as an AES tunnel, and the content of the conversation is then encrypted with the shared session key using AES. And, as it turns out, your browser is probably busy doing this right now as you read.

So that’s not really news (except to those of us getting slowly exposed to the ins and outs of this stuff). It certainly simplifies the computational load for an ongoing conversation, but it still requires asymmetric capability to start the conversation up. You may not have to use it as much as you might have feared, but you still need it.

Going Symmetric-Only

Or… not? Rubicon is promoting a symmetric-only approach that would allow an IoT device to be built with no provision for asymmetric security at all. It comes with its own cost, of course, and it moves back in a direction the industry was moving away from; Rubicon says that this is the pendulum swinging back.

Let’s review a symmetric-only scenario. Because there is no public/private key pair, there is no exchanging keys in real time. Each node needs to know the key of any node it’s going to communicate with. And the keys have to be loaded at manufacturing time. This is why the typical scenario is envisioned as a network where every node has the same key; it’s the obvious way to set things up so that everyone knows the key of everyone else they’re going to be talking to, long before they actually do that talking.

But there’s a different way, and it seems logistically messy, but it does work. Instead of giving each node the same key, each node gets its own key. The cloud with which the node will need to speak – and, in this case, Rubicon is specifically connected with DDS – will know that node’s key because, as the nodes are provisioned with keys, a database is built that says which key belongs to which node. That database gets shipped to the cloud.

Now, when the node connects and announces itself, DDS can find the key in the database. To confirm that the node really is who it says it is, the node creates a random number and hashes it with the key. It sends the number and the digest up to DDS; DDS hashes the random number with what should be the same key, and, if the digests agree, then identity is authenticated.

Notice one important simplification to this approach as described by Rubicon: it requires no certificates. You may recall that certificates provide trust to engender confidence that entities are who they say they are. It’s a system of someone vouching for someone else, but that works only if the voucher is also trustworthy. So the voucher needs to be vouched for by yet someone else, and this chain ultimately has to end somewhere with an entity that everyone trusts.

These so-called “certificate authorities” (or CAs) are in the business of selling trust. You obtain your “root certificate” from them – in exchange for some non-trivial amounts of money (can be six figures, with possible ongoing renewal costs). An authentication approach that eliminates this completely is a huge simplification and cost savings.

This notion got me wondering whether this proof of identity was weaker than that provided by certificates in the asymmetric model. The idea is that, in public/private key exchange, the node says, “Here’s who I am, and here’s a letter of introduction vouching for me.” That letter is the certificate. There is no such letter in the symmetric case. Is that a weakness?

A further discussion with Rubicon (they were quite patient with my, “Wait, but what about…” series of questions) helped clarify some important high-level notions here. It’s not the certificate that really seals the trust deal. It helps, but it’s a public artifact, so anyone can “steal” it. The thing that seals the deal is that the network gives the node a challenge that requires the node to use its private key: the random number encryption. It’s saying, “OK, you say you’re you, and you’ve submitted your public key; now we need you to prove that you have control of the private key by unencrypting this number.” If the node has the private key, then identity is taken as established.

In the symmetric case, DDS becomes the arbiter. If the node establishes, through the authentication above, that it has the right key, then DDS will decide that the node is legitimate. And DDS then acts as a voucher if two of its nodes want to communicate. DDS knows that both are legit, so it can establish a session key for a conversation directly between the two nodes.

In both cases, symmetric and asymmetric, it’s the fact that the node proves possession of the right secret key (private in the asymmetric case, simply secret in the symmetric case). If that key is compromised – stolen or calculated or guessed – then all bets are off. The authentication procedures don’t protect against that.

Another way of looking at the certificate is this: the certificate doesn’t establish that the node is who it says it is. It simply says that the public key being submitted hasn’t been monkeyed with because there’s a chain of signatures. (The certificate may have other useful permissions info and such, but that’s not important for this discussion.) Only when possession of the private key is proven is authenticity of the node itself established.

The Tradeoff

The cost of this simplicity lies in the database as a single, attractive point of attack, from which all the keys can be extracted. This has been the main knock against this kind of system in the past, but it’s what Rubicon says is coming back.

In one complicating factor, central to this approach is the fact that, at manufacturing, a key is created and loaded into both the IoT device and the database. But there are some key-protection approaches that would make this completely impossible. If you take a device like the Atmel (now Microchip) ECC508A, it supports asymmetric (ECC) cryptography by creating its own private key internally – and never divulging it to anyone anytime anyhow. In other words, if your IoT device had such a chip, there would be no way to interrogate the private key in order to put it in the database.

Such a device can create a random session key for an AES tunnel, but that happens on the fly, in conjunction with asymmetric authentication. It breaks down for the symmetric-only model.

Rubicon says that they can work with “non-Rubicon” devices by using a Rubicon-enabled device as a proxy. That proxy would need to support RSA so that it could authenticate the non-Rubicon node and then establish an AES conversation.

So, essentially, we’ve traded the higher overhead, larger circuitry, bigger software footprint, and longer compute time of an asymmetric system for a symmetric system where we’re trusting that the One Database to Rule them All cannot and will not be hacked.

You might wonder what Rubicon’s angle is with all of this. They’re selling “Identity as a service.” They have a board that they call TLS Armor that can plug into servers (the cloud end of things) to act as the firewall and security kiosk at the server. But they’re not looking to make so much money off of that; they’re making the circuits that support their approach available royalty-free.

The key infrastructure, which can be applied to other applications besides IoT (such as cloud server mirroring), lets them “rent” the keys, to use their term. So, consistent with the ongoing investor preference for annuities instead of one-time purchases, there are ongoing charges associated with Rubicon’s implementation of this system. This is where Rubicon looks to make their money.

Could you do it on your own, without them? Seems like it might be possible; I haven’t seen anything that looks like proprietary enabling technology. If you spent the money and time to develop something like that on your own, would it be cheaper than simply renting and still give you a result within your market window? Not having access to actual numbers, I can’t answer this; it’s a question you’d need to answer in conversation with Rubicon.

More info:

Rubicon Labs