Hacker News new | ask | show | jobs
by tptacek 1457 days ago
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. :)

2 comments

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.

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.