Cryptographic failures in RF encryption allow stealing robotic devices
1–10 of 18 posts
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#2So are they talking about the Donkey car project? That's the only one that I'm aware of that aligns with what is said in the article.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#3So are they talking about the Donkey car project? That's the only one that I'm aware of that aligns with what is said in the article.
I suppose they could be talking about any of a variety of drones.
They suggest up to millions of affected devices.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#4>Hundreds of thousands, if not millions. The nature of the device has been heavily redacted to protect the guilty.
This is rather annoying, and sort of the whole point of responsible disclosure.
Disclose the vulnerability to the company, and at some predetermined amount of time later spill the beans, including the vendor.
If the company does not want to fix it, the people using the products deserve to know that and make their decision (dump the product, live with the risk, etc.). Or the company fixes it, and people are happy.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#5> Many developers see security people as annoying creatures, always pointing out mistakes and criticizing incorrect decisions. A cryptographer is considered more malignant: they know math and can tell you actual probabilities of some of your failures. They also yell crypto is not a cryptocurrency and don’t roll your own crypto often. That would be us.
> The precise definition of the second proverbial phrase depends on the context and has changed over the last couple of decades, but most of the time it means Do not design your cryptosystems, especially if you don’t know anything about them.
this post looks interesting but i can't get past this writing style. sorry. : /
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#6There doesn't seem to be any actual demonstration of an attack. Just a bunch of discussion of various types of attacks with the implication that there might be something or somethings out there that are susceptible.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#7The worst cryptography vulnerabilities I've discovered have been in RF and small embedded systems, because both settings (and they're often combined!) create constraints that make high-level crypto libraries untenable. This is part of why there's so much interest in lightweight cryptography schemes like Xoodyak (Daemen), Gimli (from the Nacl folks), and STROBE (Hamburg).
Everyone --- at least, everyone in the mid-2000s --- got CTR nonces wrong. But you haven't seen what a custom RF environment does to cryptography until you've seen the counters wrap. :)
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#8The worst cryptography vulnerabilities I've discovered have been in RF and small embedded systems, because both settings (and they're often combined!) create constraints that make high-level crypto libraries untenable. This is part of why there's so much interest in lightweight cryptography schemes like Xoodyak (Daemen), Gimli (from the Nacl folks), and STROBE (Hamburg). Everyone --- at least, everyone in the mid-200…
There may or may not have been an RF embedded vendor who just added an xor of any password key you gave it to itself, so that you could turn encryption "on" and add a password and it would "just work" with every other device because they all ostensibly encrypted traffic with a key that was a string of zeroes.
Another hypothetical vendor may have claimed to use 128-bit AES, where it would take a config password, encrypt it with AES, and then xor each packet payload of RF traffic with the bytes from that ciphertext. This was when SDRs and anything that could intercept FHSS traffic cost over $10k so nobody really noticed.
My skills were lame by most standards, and if this is getting attention now, we can expect some really funny conference talks in the next few years and there are some careers to be made on breaking implementations in this relative backwater. The hardest part at the time was extracting the bootloader firmware dump via an open jtag, but most of the firmware images were available via ftp, and the tools for that today are just amazing compared to the 00's.
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#9The worst cryptography vulnerabilities I've discovered have been in RF and small embedded systems, because both settings (and they're often combined!) create constraints that make high-level crypto libraries untenable. This is part of why there's so much interest in lightweight cryptography schemes like Xoodyak (Daemen), Gimli (from the Nacl folks), and STROBE (Hamburg). Everyone --- at least, everyone in the mid-200…
on the flip side, do newer embedded hardware designs have better sources of entropy and monotony yet? (does that still matter?)
Re: Cryptographic failures in RF encryption allow stealing robotic devices
#10The worst cryptography vulnerabilities I've discovered have been in RF and small embedded systems, because both settings (and they're often combined!) create constraints that make high-level crypto libraries untenable. This is part of why there's so much interest in lightweight cryptography schemes like Xoodyak (Daemen), Gimli (from the Nacl folks), and STROBE (Hamburg). Everyone --- at least, everyone in the mid-200…
on the flip side, do newer embedded hardware designs have better sources of entropy and monotony yet? (does that still matter?)
Yes, many more powerful chips include hardware RNGs now. ESP32 and STM32 and Atmel SAM have them at least. Some 16 bit ones like some MSP430s have them (and AES) too.
I don't think they're generally in 8-bitters unless some of the newer "big-little" ones throw one in, but probably most IoT devices that need cryptographic security would use a 32-bitter these days anyway if nothing else for the networking.
There are also devices like the ATECC608 which have an internal HRNG, and also provide offloaded security cryptographic signing based on that, which both saves a very small device burning cycles on crypto and also prevents a private key ever residing in the CPU.