Tukukkk

I've just been reading this article on proprietary RF protocols vs Bluetooth and it seems to be suggesting that the security through obscurity gained through a proprietary protocol is advantageous over the more well-known Bluetooth.

It states that

The case for proprietary PHY and protocol is strong if a design requires optimization in the direction of security...

and

...proprietary designs ensure “security-through-obscurity,” in that an RF interface that isn’t well known is harder to hack.

From a purely security standpoint, would I be better off developing my product targeting a proprietary RF protocol that I design, or sticking with Bluetooth?

This is a great question and very important as companies move to industrial IoT, which is where I see this come up the most. I can say, from first hand pentesting experience, that proprietary protocols using "Security through obscurity" are very dangerous.

The problem with proprietary protocols is that they are not typically fully developed or developed with a specific focus on security in mind, or at all, in my experience. Typically the RF engineer to build the protocol is an EE not a security professional.

Proprietary protocols not being safe is also true with more than RF and also applies to ethernet or serial protocols. I've had companies tell me their device is secure because [pick someone] couldn't figure out the protocol. Yes, that can happen if you have a classic IT red-team, but when you send it to us and we pull out a spectrum analyzer and reverse it and everything is in plain text I'd call that almost no security. Definitely not security you can count on. I can personally verify my lab reversing multiple proprietary Ethernet protocols and 2 wireless RF and one IR. All insecure.

You can also run into multiple other problems, like information leakage, developer backdoors (how about a command to factory reset a device with no authentication, for example), and just broken QA. You also have to pay for all of that now.

Standard bluetooth has a built ability to use AES encryption. I'd highly recommend that approach. 6lowpan and Zigbee are less "known" but both have undoubtedly been fully broken apart by nation state security professionals, as if we did it in our 10 man lab I don't believe the NSA has not although, I have no proof.

So to be clear, if you would like to pay engineers and security engineers to build you a secure protocol and go through full QA and Pen testing, that's not a bad thing. If you want to create a simple, unencrypted protocol, and hope "no one will look" I'd say that's a recipe for disaster. Or you could just use Zigbee/Bluetooth and make sure encryption is enabled.

That said, yes proprietary protocols will be out of reach of the "Script Kiddie," but I wouldn't call that ideal security.

That article's security advice is so wrong that presenting it borders on engineering negligence. "Security through obscurity" has been known to be a flawed approach for over 160 years. Pretending that nobody cares about your signals is a strategy best left to the ostriches that came up with it; it is not an actual, viable security strategy in the modern world.

Like everything else associated with security, this past decade has seen the world getting much tougher for the security of RF communications. The introduction of cheap Software Defined Radio hardware has led to a host of open source RF protocol disassembly and analysis tools, rendering the security properties of most proprietary applications all but transparent. If you'd like to see some examples, here's a video demo showing decoding various 433MHz signals using rtl_433; and here's a Universal Radio Hacker tool that can automatically detect, parse, and playback many forms of communications. The only investment needed to get started is an under-$20 USB receiver and a computer.

Standardized protocols have the advantage of years of real-world attackers trying to break into the communications. The few comparatively secure protocols in common use today (Bluetooth, WPA3, NFC) are those that have had earlier implementations cracked and broken over and over, and through the iterative process have been refined and improved. Even so, today's "secure" protocols can have exploitable vulnerabilities discovered tomorrow.

So where does all that bad news that leave you? Your first task is to figure out what an attacker stands to gain by breaking your protocol. Can he remotely operate equipment? Unlock cars? Disable alarms? Make a children's toy emit terrifying noises? The more "value" your protocol protects (including your customers' reputations), the more incentive attackers have to crack it.

Today's "RF script kiddies" are an extremely well-armed bunch, and they gain respect by hacking new signals; do not discount their abilities or tenacity.

A homegrown protocol may be cheap, but it will be completely insecure. If security researchers and professionals can't get a protocol secure after 20 years of trying, you know it's not an easy problem to solve. Homegrown might be fine if you're looking to change the color of a desk lamp; it will not be so good if you're looking to operate door locks. A standard protocol will have a much better security model, but might have higher unit costs or energy requirements; and even a standard protocol won't remain perfect over time. Your best defense in both cases is to provide a firmware patching mechanism that will allow your customers to securely upgrade and fix future security bugs.

In summary: everything that DigiKey article said about security is wrong. Please disregard it. Your customers deserve much better.