[Cryptography] trojans in the firmware

[John Gilmore]

> I (and most everyone else, as well) no longer care about booting
> from "hard" disks.  Everyone boots from flash memories these days.

You have an odd definition of "everyone".  Disk drives still matter.

> So now the problem is gaining access to flash disk firmware.
> Normally, you can't.  However, there are now really decent file
> systems developed for Linux for _bare_ flash devices (i.e., not USB
> or uSD flash drives, which utilize internally managed flash memory
> "log-structured" file systems; see BadUSB for more info).

The One Laptop Per Child (OLPC) project was the first to design and
ship laptops with no hard drive, only flash.  They started with bare
flash, using Linux flash file system support.  It turned out that that
was a problem for several reasons.

The Linux flash file systems were initially built for very small
devices.  When run on larger raw flash chips, they added many seconds
to the boot time, merely to scan all the flash blocks and build an
in-memory index of them.  OLPC spent some programmer time and improved
the flash file systems, but they were still pretty clunky and had
almost zero mass market burnin time, compared with the disk-based file
systems like ext2, ext3, ext4, or even the oddball file systems like
ZFS or ReiserFS, that have millions of daily users.

But much more important to OLPC was the dynamics of the flash market.
With each new generation of flash parts, the interfaces to the parts
changed.  They needed more or fewer wires, more or less voltage, more
or less current, more or less time for each kind of access.  They have
increasingly bizarre programming and erasure algorithms.  Merely
reading a cell in some raw flash chips perturbs the data stored in
nearby cells!  It became clear that long-lived systems designed to use
a particular flash interface would be stuck at that year's capacity
forever, with commodity parts harder and harder to find cheaply,
despite or rather because of rapid capacity increases across the
industry over time.  For example, their early devices used
single-level flash cells; later ones used multilevel cells.  The
single level cells can be erased and reused hundreds of thousands of
times; in multilevel cells the limit was only a few thousand.  But
multilevel had higher capacity.

They ultimately solved their design problem, procurement problem, and
programming problem by designing to use *mediated* flash, that comes
bundled with a dedicated controller -- SD cards, microSD cards, and
eMMC modules, all of which have the same electrical interface and
programming interface.  See e.g.:

  http://lists.laptop.org/pipermail/devel/2010-August/029684.html

This lets their laptops upgrade what used to be a gigabyte of flash to
up to 32 gigs without changing the interface.  Of course this solution
adds other issues -- such as finding bugs or malice in the firmware in
the flash controllers.  Flash controller firmware is *complicated*
because it implements its own file system to pretend that flash chips
are just a series of working read/write sectors like disk drives.
They also do "wear leveling", moving the data around on the chips to
avoid doing too many writes to any given flash sector, and to try to
hide the erase latency.  Complex firmware means that bugs are
unavoidable, and obscure performance issues are very likely.  And there
are no free software implementations of flash controller firmware, so
you can't scrutinize the code yourself without using serious forensic
tools.

What distinguishes SD cards from ordinary MMC flash cards is that the
SD cards contain malicious firmware designed by Hollywood to let the
cards store information that the owner cannot access (we would call it
"DRM" but they call it "Secure Digital").  99% of devices with an SD
card slot don't use the DRM features (which were designed for MP3
players), but SD had much better marketing than MMC, so consumers
started demanding "SD" cards.  Of course this DRM leaves a nice back
door for NSA or other bad actors to cache information in SD cards
against the will of the card's owner or the owner of the system it
runs in.  I don't know of anyone who's surveyed the DRM
implementations on modern SD cards to even see how much of it works at
this point.  Since almost nobody uses the DRM code, vendors may be
leaving it out but using the SD logo anyway.  And if they keep it in,
that unexercised code is another highly probable source of exploitable
bugs.

There are proprietary commands for reflashing the firmware on many SD
cards (which usually boot their controllers from firmware stored on
the flash chips themselves).  I expect that NSA knows them, just like
it has stolen or compelled the info needed to reflash disk drive
firmware for ten companies' disk drives.

Oh, one more big issue about the flash market.  Nobody, not even the
big vendors, can tell whether a given product was made by their
factory and sold through legitimate channels, or was made by a
fly-by-night vendor and labeled with a mainstream company's logo.
(There's a 3rd level - ghost runs -- which are made in mainstream
factories during off hours by corrupt employees without the company
knowing it.)  The only way to really tell is to destroy the device by
peeling it apart and analyzing it with instruments.  See:

  http://www.bunniestudios.com/blog/?page_id=1022
  http://www.bunniestudios.com/blog/?p=3554
  
So even when buying a reputable brand from one of their main licensed
distributors, you have no idea who actually made or programmed
the chips you receive.  Have fun securing a system that boots from one
of these!

	John