Current-Based Side-Channel Attacks, Two Ways

January 4, 2024 by Dan Maloney 9 Comments

Funny things can happen when a security researcher and an electronics engineer specializing in high-speed circuits get together. At least they did when [Limpkin] met [Roman], which resulted in two interesting hardware solutions for side-channel attacks.

As [Limpkin] relates it, the tale began when he shared an office with [Roman Korkikian], a security researcher looking into current-based attacks on the crypto engine inside ESP32s. The idea goes that by monitoring the current consumption of the processor during cryptographic operations, you can derive enough data to figure out how it works. It’s difficult to tease a useful signal from the noise, though, and [Roman]’s setup with long wire runs and a noisy current probe wasn’t helping at all. So [Limpkin] decided to pitch in.

The first board he designed was based on a balun, which he used to isolate the device under test from the amplification stage. He found a 1:8 balun, normally used to match impedances in RF circuits, and used its primary as a shunt resistance between the power supply — a CR1220 coin cell — and the DUT. The amplifier stage is a pair of low-noise RF amps; a variable attenuator was added between the amp stages on a second version of the board.

Board number two took a different tack; rather than use a balun, [Limpkin] chose a simple shunt resistor with a few twists. To measure the low-current signal on top of the ESP32’s baseline draw would require such a large shunt resistor that the microcontroller wouldn’t even boot, so he instead used an OPA855 wideband low-noise op-amp as an amplified shunt. The output of that stage goes through the same variable attenuator as the first board, and then to another OPA855 gain stage. The board is entirely battery-powered, relying on nice, quiet 18650s to power both the DUT and the shunt.

How well does it work? We’ll let you watch the talk below and make up your own mind, but since they’ve used these simple circuits to break a range of different chips, we’d say this approach a winner.

Continue reading “Current-Based Side-Channel Attacks, Two Ways” →

SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software

February 21, 2023 by Dave Rowntree 5 Comments

[Kuba Tyszko] like many of us, has been hacking things from a young age. An early attempt at hacking around with grandpa’s tractor might have been swiftly quashed by his father, but likely this was not the last such incident. With a more recent interest in cracking encrypted applications, [Kuba] gives us some insights into some of the tools at your disposal for reading out the encrypted secrets of applications that have something worth hiding. (Slides here, PDF.)

There may be all sorts of reasons for such applications to have an encrypted portion, and that’s not really the focus. One such application that [Kuba] describes was a pre-trained machine-learning model written in the R scripting language. If you’re not familiar with R, it is commonly used for ‘data science’ type tasks and has a big fan base. It’s worth checking out. Anyway, the application binary took two command line arguments, one was the encrypted blob of the model, and the second was the path to the test data set for model verification.

The first thing [Kuba] suggests is to disable network access, just in case the application wants to ‘dial home.’ We don’t want that. The application was intended for Linux, so the first port of call was to see what libraries it was linked against using the ldd command. This indicated that it was linked against OpenSSL, so that was a likely candidate for encryption support. Next up, running objdump gave some clues as to the various components of the binary. It was determined that it was doing something with 256-bit AES encryption. Now after applying a little experience (or educated guesswork, if you prefer), the likely scenario is that the binary yanks the private key from somewhere within itself reads the encrypted blob file, and passes this over to libssl. Then the plaintext R script is passed off to the R runtime, the model executes against the test data, and results are collated.

[Kuba]’s first attack method was to grab the OpenSSL source code and drop in some strategic printf() function calls into the target functions. Next, using the LD_PRELOAD ‘trick’ the standard system OpenSSL library was substituted with the ‘fake’ version with the trojan printfs. The result of this was the decryption function gleefully sending the plaintext R script direct to the terminal. No need to even locate the private key!

Continue reading “SUPERCON 2022: Kuba Tyszko Cracks Encrypted Software” →

Why You Should Totally Roll Your Own AES Cryptography

July 11, 2022 by Maya Posch 27 Comments

Software developers are usually told to ‘never write your own cryptography’, and there definitely are sufficient examples to be found in the past decades of cases where DIY crypto routines caused real damage. This is also the introduction to [Francis Stokes]’s article on rolling your own crypto system. Even if you understand the mathematics behind a cryptographic system like AES (symmetric encryption), assumptions made by your code, along with side-channel and many other types of attacks, can nullify your efforts.

So then why write an article on doing exactly what you’re told not to do? This is contained in the often forgotten addendum to ‘don’t roll your own crypto’, which is ‘for anything important’. [Francis]’s tutorial on how to implement AES is incredibly informative as an introduction to symmetric key cryptography for software developers, and demonstrates a number of obvious weaknesses users of an AES library may not be aware of.

This then shows the reason why any developer who uses cryptography in some fashion for anything should absolutely roll their own crypto: to take a peek inside what is usually a library’s black box, and to better understand how the mathematical principles behind AES are translated into a real-world system. Additionally it may be very instructive if your goal is to become a security researcher whose day job is to find the flaws in these systems.

Essentially: definitely do try this at home, just keep your DIY crypto away from production servers :)

Side Channel Attacks Against Mixed Signal Microcontrollers

July 30, 2018 by Brian Benchoff 7 Comments

You shouldn’t transmit encryption keys over Bluetooth, but that’s exactly what some popular wireless-enabled microcontrollers are already doing. This is the idea behind Screaming Channels, an exploit published by researchers at EUERCOM, and will be a talk at Black Hat next week. So far, the researchers have investigated side-channel attacks on Bluetooth-enabled microcontrollers, allowing them to extract tinyAES keys from up to 10 meters away in controlled environments. A PDF of the paper is available and all the relevant code is available on GitHub.

The experimental setup for this exploit consisted of a BLE Nano, a breakout board for a Nordic nRF52832 Bluetooth microcontroller, a Hack RF, a USRB N210 software defined radio from Ettus, and a few high-gain antennas and LNAs. The example attack relies on installing firmware on the BLE Nano that runs through a few loops and encrypts something with tinyAES. Through very careful analysis of the RF spectrum, the AES keys can be extracted from the ether.

Side channel attacks have received a bit more popularity over recent years. What was once limited to Three Letter Agency-level Van Eck phreaking can now be done inexpensively and in a system with devices like the ChipWhisperer.

Of course, this is only a demonstration of what is possible with side-channel attacks in a highly controlled environment with a significant amount of work gone into the firmware running on the microcontroller. This isn’t evidence that balaclava-wearing hackers are sniffing your phone from across the parking lot to get the password to your Instagram account, but it does show what is possible with relatively cheap, off-the-shelf hardware.

NIST Helps You With Cryptography

May 25, 2017 by Elliot Williams 33 Comments

Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.

NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.

Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.

I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.

If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.

Your tax dollars at work. Thanks, NIST!

And thanks [acs] for the tip!

A protoboard layout for an ATtiny85 door chime

AES-CMAC On An ATtiny85

February 20, 2015 by Eric Evenchick 35 Comments

[Blancmange] built a custom door chime using an ATtiny85. Unlike most commercial products out there, this one actually tries to be secure, using AES-CMAC for message signing.

The hardware is pretty simple, and a protoboard layout is shown in the image above. It uses the ATtiny85 for control, with an LM380N audio amplifier, and a low cost 315 MHz receiver.

The more impressive part of the build is the firmware. Using AVR assembly, [Blancmange] managed to fit everything into the 8 Kbytes of flash on the ATtiny85. This includes an implementation of AES-CMAC, an AES cypher based message authentication code. The transmitting device signs the request with a key shared between both devices, and the receiver verifies that the message is from a trusted transmitter.

Fortunately, the assembly code is very well commented. If you’ve ever wanted to take a look into some complex ASM assembly, this is a great project to check out. The source code has been released into the public domain, so the rest of us can implement crypto on this cheap microcontroller with much less effort.

Stealing WiFi From LED Lightbulbs

July 6, 2014 by Eric Evenchick 13 Comments

Back in 2012, the LIFX light bulb launched on Kickstarter, and was quite successful. This wireless LED lightbulb uses a combination of WiFi and 6LoWPAN to create a network of lightbulbs within your house. Context Information Security took a look into these devices, and found some security issues.

The LIFX system has a master bulb. This is the only bulb which connects to WiFi, and it sends all commands out to the remaining bulbs over 6LoWPAN. To keep the network up, any bulb can become a master if required. This means the WiFi credentials need to be shared between all the bulbs.

Looking into the protocol, an encrypted binary blob containing WiFi credentials was found. This binary could easily be recovered using an AVR Raven evaluation kit, but was not readable since it was encrypted.

After cracking a bulb apart, they found JTAG headers on the main board. A BusBlaster and OpenOCD were used to communicate with the chip. This allowed the firmware to be dumped.

Using IDA Pro, they determined that AES was being used to encrypt the WiFi credentials. With a bit more work, the key and initialization vector was extracted. With this information, WiFi credentials sent over the air could be decrypted.

The good news is that LIFX fixed this issue. Now they generate an encryption key based on WiFi credentials, preventing a globally unique key from being used.

[via reddit]