[HN Gopher] Cryptographic failures in RF encryption allow steali...
___________________________________________________________________
Cryptographic failures in RF encryption allow stealing robotic
devices
Author : evilsocket
Score : 48 points
Date : 2022-06-29 15:42 UTC (7 hours ago)
(HTM) web link (www.cossacklabs.com)
(TXT) w3m dump (www.cossacklabs.com)
| a-dub wrote:
| > 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. : /
| bragr wrote:
| So 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.
| xbar wrote:
| I suppose they could be talking about any of a variety of
| drones.
|
| They suggest up to millions of affected devices.
| bragr wrote:
| ArduPilot then?
| tptacek wrote:
| The 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. :)
| motohagiography wrote:
| 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.
| a-dub wrote:
| on the flip side, do newer embedded hardware designs have
| better sources of entropy and monotony yet? (does that still
| matter?)
| adhesive_wombat wrote:
| 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.
| upofadown wrote:
| There 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.
| ziddoap wrote:
| > _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.
| vixentael wrote:
| A valid point. But responsible disclosure in the world of un-
| patchable devices that actually move and can cause physical
| harm once pwned feels a little bit different. While we've done
| things to mitigate a blast radius, publicising guilty names
| would still lead to lots of damage because you know, these are
| toy cars.
___________________________________________________________________
(page generated 2022-06-29 23:01 UTC)