Poking the S in SD cards

Nicolas Oberli

Who am I ?

●

Research team @KudelskiSec

–

Focusing on hardware / embedded devices security

●

@BlackAlpsConf organization

–

Stickers !!

●

@Hydrabus developer

–

Again, Stickers !!

How did it start ?

●

SD stands for Secure Digital

–

What is the Secure for ?

●

Keep the attacks as low cost as possible

–

You can replicate this at home

–

No physical attacks on the cards

Introduction to SD cards

What is an SD card ?

●

Basically a microcontroller

interfacing the SD

interface with flash

memory

●

See bunnie and xobs talk

@ 30C3 for details

https://en.wikipedia.org/wiki/SD_card

Communication

●

SD cards support 3 communication protocols

–

SPI Bus protocol

●

Classic SPI

–

SD / UHS-I Bus protocol

●

CLK, CMD, Up to 4 data lines

–

UHS-II Bus protocol

●

RCLK, 2 differential data lines

https://en.wikipedia.org/wiki/SD_card

Time to dig into the specs

●

Specs are freely available in a simplified format

on the SD association website

–

262-pages document (general specs – part 1)

–

Presents the general description of the SD System

Initialization sequence

SD specs part 1, figure 7-2

Protocol

●

Query/reply-based

●

Each command has a number and is usually

referenced with it

–

eg. CMD0 - GO_IDLE_STATE

Protocol – cont.

●

7 different response formats

–

Depends on the sent command

●

Protocol implements a block transfer feature

–

Used to transfer more than 4 bytes

–

Block starts with 0xFE

–

Length is defined by CMD16 (512 bytes by default)

Interfacing with SD card

●

First need to communicate correctly with the

card

●

SPI is used here

–

Lots of existing tools available to use SPI

–

Already supported by Hydrabus

Hydrabus

●

Bus Pirate on steroids

–

More modern

alternative

–

Many supported

protocols

–

Open source

Setup

Tool

●

Python CLI interface using pyHydrabus

●

Drives SD card in SPI mode

–

Can send raw commands

–

Helper functions for specific commands

●

CRC is optional in SPI mode, easier to play with

–

Except when some cards require a valid CRC no

matter what

DEMO

SD security features

Security features

●

SDMI – Secure Digital Music Initiative

–

Detailed under specs part 3

●

Available only to SD members / NDA

●

Not covered here

Security features

●

Can be read- and/or write-protected

–

Available through several commands

●

CMD27 to set write protection bits

●

CMD42 to set read protection password

●

These commands are mandatory to get SD

label

CMD42 – LOCK_UNLOCK

●

Used to control the password protection

mechanism

–

Up to 16 bytes

–

Not limited to printable characters

–

Keyspace : 2

128

– Same as an AES key

●

Bruteforce is unachievable

Locking the SD card

●

The CMD42 command controls the password

locking functions

–

Takes no parameter, but card expects a following

data block

CMD42 data block

●

Contains the command options, length and the

actual password

Locking SD card

●

Send CMD42

●

Send a data block, setting the SET bit, the

password length and the password

–

Can optionally set the LOCK bit to lock the card in

the process

●

Lock status is available in the status bits

(CMD13)

Unlocking SD card

●

Send CMD42

●

Send a data block, unsetting the LOCK bit,

setting the password length and the password

●

Card will assert the MISO line, then send an

ACK once the command has been processed

●

Lock status is available in the status bits

(CMD13)

Attacking the password protection

Unlocking SD card

●

Send CMD42

●

Send a data block, unsetting the LOCK bit,

setting the password length and the password

●

Card will assert the MISO line, then send an

ACK once the command has been processed

●

Lock status is available in the status bits

(CMD13)

Guess what happens ?

CMD42 Password block Response

00000

000000

CLK

MISO

MOSI

CLK

MISO

MOSI

What’s happening ?

●

SD controller checks for the length of the

password, then compares each byte to the

correct password

●

Returns an error as soon as there is a

discrepancy

●

Possible to determine a correct byte by

measuring processing time

Measuring time using SPI

●

During processing time, read dummy bytes as

fast as possible

●

As long as we read zeroes, the password check

is still ongoing

●

Once we read a 1, count the number of zeroes

In practice :

DEMO

So ?

●

Bought a bunch of SD cards (~20)

–

Different vendors

–

Different sizes

●

Also asked colleagues / friends for SD cards

–

The only card I permanently locked was not mine

(‘-’*)

●

Locked them with “123456” as password

Special cases – Sony SD

●

Card refuses to check the password after three

failed attempts

●

Need to remove and insert the card again to get 3

more attempts

–

In fact, doing a reset sequence (CMD0) is enough to

get 3 more tries

–

Slightly makes the bruteforce slower

Special cases – Sony uSD

●

Card seems to have a really fast checking time

–

Can get no or maybe one zero bit

●

Sampling rate might be too slow

–

SPI interface is ~42MHz

–

Using logic analyzer (100MS/s) still does not show

any usable results

Faster !!

●

Used lab oscilloscope

–

Up to 40GS/s, more than enough

●

Had to setup a trigger for correct measurement

And...

Special cases - Kingston

●

It is possible to count the password length, but

not the password chars

●

Took a lot of measurements until I found this :

00000

000000

100000

120000

123000

123400

123450

Still vulnerable

●

Password checking works on groups of 4 bytes

●

If remaining bytes to check is >= 4, test each

byte individually

●

Attack takes more time, but works anyways

Results

Card Manufacturer Prod. date* Vulnerable ?

Transcend uSD 4GB Transcend (0x74) 09/2011 Yes

Transcend uSD 16GB Transcend (0x74) 10/2012 Yes

Hama 8GB Phison (0x27) 06/2010 Yes

Maxell 32GB Phison (0x27) 10/2011 Yes

Sony uSD 32GB Sony (0x9c) 07/2012 Yes

Sony 32GB Sony (0x9c) 12/2011 Yes

Kingston uSD 32GB Unknown (0x9f) 10/2012 Yes

Sandisk Extreme 128GB Sandisk (0x03) 03/2012 No

Sandisk mobile ultra 16GB Sandisk (0x03) 12/2009 No

Samsung Evo+ uSD 32GB Samsung (0x1b) 10/2012 Unsupported

* Production date format is not consistent

Ouch

●

Sandisk only controller I tested not vulnerable

to this attack

●

Remember : SD vendor != Controller

manufacturer

●

Samsung cards respond with invalid command

when sending CMD42

Write lock mechanism

Abusing Write lock mechanism

●

Setting the TMP_WRITE_PROTECT bit in CSD

●

Hypothesis: This will prevent the flash memory

content to be erased when a clear password is

sent

Testing for vulnerability

●

Write data on some pages

●

Set write protection

●

Set password

●

Power cycle card

●

Clear password

●

Test for password presence, and if data is still

present

Results

●

All tested cards do correctly erase the

TMP_WRITE_PROTECT flag and erase the

data

●

Did not test the permanent write protect yet

Abusing password clear feature

Password clearing

●

By setting the CLR bit in CMD42, it is possible

to remove the password protection on a card

●

Card content is erased in the process

●

Hypothesis : Does the card clear its password

BEFORE erasing the flash memory ?

Detecting flash writes

●

Flash memory uses charge-pump mechanism

to provide enough current to change memory

value

●

Detecting an increase in power consumption

would mean the flash will be written

Measuring current consumption

●

Ohm’s law : increasing the current through a

fixed resistance will increase voltage drop

●

Add a small (<10Ω) resistance after the SD

card and measure voltage using oscilloscope

–

Might need to slightly increase source voltage

●

Budget-tip: If you don’t have small resistances,

vape coils do work

Power consumption

By the way...

●

Checking a password consumes power

●

So the timing attack is also visible by looking at

the card power consumption

00000

000000

123450

Triggering on consumption

●

STM32 ADC offers a watchdog feature

–

Watchdog triggered when voltage goes above or

below thresholds

●

Added feature to Hydrabus

–

Programmable thresholds

–

Programmable delay (1μs minimum delay)

Cutting power

●

Used a MOSFET to drive the SD card current

–

Easy to use as a digital switch

–

Can be operated by a GPIO

●

Budget-tip: Motherboards have a lot of

MOSFETs that can be used.

–

Recycle your old stuff !

Final schema

In practice

Testing for vulnerability

●

Write data on some pages

●

Set password

●

Power cycle card

●

Clear password with trigger

●

Test for password presence, and if data is still

present

Example – Flash erase

Example – Flash erase glitched

Example – Different card

Vulnerable ?

●

Some cards were successfully unlocked using

this technique

●

No data page lost in the process \o/

SD card specification part 1

Demo

Results

Card Manufacturer Prod. date* Vulnerable ?

Transcend uSD 4GB Transcend (0x74) 09/2011 Died :(

Transcend uSD 16GB Transcend (0x74) 10/2012 Yes

Hama 8GB Phison (0x27) 06/2010 Yes

Maxell 32GB Phison (0x27) 10/2011 Yes

Sony uSD 32GB Sony (0x9c) 07/2012 Yes

Sony 32GB Sony (0x9c) 12/2011 No

Kingston uSD 32GB Unknown (0x9f) 10/2012 Yes

Sandisk Extreme 128GB Sandisk (0x03) 03/2012 No

Sandisk mobile ultra 16GB Sandisk (0x03) 12/2009 No

Samsung Evo+ uSD 32GB Samsung (0x1b) 10/2012 Unsupported

* Production date format is not consistent

Conclusions

●

Useless vulnerabilities ?

–

Feature not supported by any OS

●

Affects a lot of manufacturers

●

Reading specs is fun

–

Don’t take them as granted though

Conclusions – Cont

●

Simple side-channel analysis is not that hard

–

Does not require a lot of expensive tools to get

things done if you are creative

●

Tools are evolving, their price get lower, getting

more accessible

Conclusions – Cont

●

Automation is key

–

When you need hundreds of samples, better not

have to stay around while it’s working

Based on https://xkcd.com/303/

Future work

●

COP protection

–

Added in specs v5.00 (2016)

–

Adds a password to protect the clear password

feature

–

Couldn’t find a card that supports it

Thank you !

Nicolas Oberli

@baldanos