Filling the Security Gaps

Recently I have gone through - what seemed at a glance - a "simple" exercise of adding security to a UDP-based transport system. The approach looked very straightforward. UDP is a standard protocol. It can go over variety of transports such as Ethernet, WiFi or Thread. And it is very easy for a Node A to communicate with a Node B over UDP. That was the starting point.

Then came two (equally benign looking) requirements:

• It must be secure
• The destination is a multicast address

And somehow implied was the latency requirement: it must be fast, such that the delays are not visible to humans (we are talking about a lighting application, so the assumption of latency / jitter is 100ms or less).

In other words: low latency secure multicast over UDP. Still does not sound like terribly hard to do. In the "IP world" we have the layered architecture and standards for everything, after all.

Security over UDP? Simple... just use DTLS. Yeah... but is it feasible to do a full DTLS handshake for every "push of a button"? Certainly not...  And BTW DTLS is a point-to-point protocol, so no multicast here unfortunately.

Then we will use symmetric keys and AEC-CCM to secure each message. Fine. But to do that, each message must additionally carry a proper nonce and a message integrity code. Hmmm... we probably need 64 bits of nonce and 64 bits of mic. Can we afford adding 16 bytes to a very simple payload like on-off over a low power (=slow) network links? 

And how do the receiving nodes know the key? How do we distribute these keys? Oh there are many ways to do that... we could use secure CoAP for example. Yes, we could. Adding the whole flow on top. And how about changing / refreshing this key? In a way that a compromised group member is not able to intercept the new key? Huh?

And once it is all done, do not forget about details like replay protection, which in itself, is a significant engineering problem to solve. Replay protection tracks received messages in a way that a copy of a message is never processed again. The requirement is simple, but the implementation of this mechanism faces challenges like limited endurance of flash memory, dealing with power cycles etc. In short, it is far from trivial.

It seems we are just scratching the the tip of an iceberg... There is abundance of methods and protocols for different purposes and to make things really interoperable, one must clearly and precisely specify what to use and how. And specify the tests and build a test system / harness.

It was all deja vu for me. To some extent. It took us 3 years to fill all these security-related gaps when working on Bluetooth Mesh (2014-2017). The basic concept was easy: have a low latency secure multicast system with highly compact messages, so they are very lightweight for over the air transmission. We ended up with a very successful and complete system specified on a couple hundred pages. And another couple of hundred for the test specification. It took some time for implementations to catch up, but as of now, there are multiple vendors offering complete software/hardware combinations qualified for Bluetooth mesh. And they offer exactly this: low latency secure multicast with integrated device discovery, onboarding and complete management of security material.

Easy and straightforward concepts require tons of engineering craftsmanship around. That same craftsmanship gap that Steve Jobs was so passionate about.