Is it ever a good idea to 'roll your own' protocol for IoT device communication?

Question

I've heard many people mention that their embedded IoT devices aren't powerful enough to process known protocols, like HTTPS or even TLS security for sockets.

Instead, they turn to creating their own protocol to produce a custom communication system that suits their particular use case, although, typically, little time is actually spent developing the protocol, because it's not a particularly important factor. Usually, these homebrew protocols include authentication, security, encryption, etc.

This article suggests some of the many pitfalls which would seem to be waiting for anyone who did go down the route of writing their own protocol, and it's well known that you shouldn't try to write your own encryption.

Are there ever any cases where you would have to write your own protocol, rather than using an existing, tested protocol? How can you tell if rolling your own is a reasonable idea, rather than a big security risk?

Answer 1

The times when it makes sense to roll-your-own are quite limited. When it comes to device constraints, its important to look at the whole system performance. For sure, the state of the art does move on but the goal should be optimising endpoint energy performance rather than working out how to cope with a device that hasn't got a good entropy source, or enough memory to support a suitable standard.

These are the scenarios where it does make some sense.

1. Roll your own to learn. Particularly if you're interested in prototyping and making relative comparisons. Once you've learnt, pick the best standard guided by your research.

2. Improve on the current state-of-the-art. More secure, and more efficient sounds like a win. Might even make you rich.

3. Roll your own to cope with an environmental constraint (not product choice) which no existing protocol accommodates - but this is likely to be more at the physical/transfer layer. For example, a highly error prone channel or a demand for high resilience to blocking. Even then, the elements you need probably already exist, and just need to be assembled.

If it's a product design, you're unlikely to differentiate by saving $0.5 in hardware. You have either a good value-add for your customer, or an insecure product that no one wants even if it sounds cool.

Answer 2

How about maintainability? I prefer joining a project which says "meh, https and blowfish" than "hey we just tried a new crypting algorithm which implies turning 3 times around our chair and singing the base64 result in front of the screen".

I'd say if your device has a lack of power (memory, calculation,...) for your protocol/encryption programs, then you should adapt it to its maximum efficiency without waiting to long on not burning your device. You mention COAP a lot in IoT.SE, this is an example of "new" protocol written for specific devices!

This should be done for personal use (sandboxed, internal network,...).

How can you tell if rolling your own is a reasonable idea

Let's face it, everybody will find something to say about your algorithm if you submit it, and you will encounter obsolescence. But it could open a new perspective for future programs which could learn from your experience.

TL;DR

• Think maintainability! Is your new algorithm attractive? Easy to maintain?
• Do it if your device has particular features which don't match existing solutions
• Test it in a closed system first
• Submit it and get ready for criticism

P.S.: HTCPCP (Coffee Pot Control Protocol) was a joke, it is now widely implemented!