[Cryptography] System level security in "low end" environments

John Gilmore gnu at toad.com
Sat Oct 5 14:00:45 EDT 2013


> b.  There are low-end environments where performance really does
> matter.  Those often have rather different properties than other
> environments--for example, RAM or ROM (for program code and S-boxes)
> may be at a premium.

Such environments are getting very rare these days.  For example, an
electrical engineer friend of mine was recently working on designing a
cheap aimable mirror, to be deployed by the thousands to aim sunlight
at a collector.  He discovered that connectors and wires are more
expensive than processor chips these days!  So he ended up deciding to
use a system-on-chip with a built-in radio that eliminated the need to
have a connector or a wire to each mirror.  (You can print the antenna
on the same printed circuit board that holds the chip and the
actuator.)

What dogs the security of our systems these days is *complexity*.  We
don't have great security primitives to just drop into place.  And the
ones we do have, have complicated tradeoffs that come to the fore
depending on how we compound them with other design elements (like
RNGs, protocols, radios, clocks, power supplies, threat models, etc).
This is invariant whether the system is "low end" or "high end".

That radio controlled mirror can be taken over by a drive-by attacker
in a way that would take a lot more physical labor to mess up a
wire-controlled one.  And if the attack aimed two hundred mirrors at
something flammable, the attacker could easily start a dangerous fire
instead of making cheap solar energy.  (Denial of service is even
easier - just aim the mirrors in random directions and the power goes
away.  Then what security systems elsewhere were depending on that
power?  This might just be one cog in a larger attack.)  Some of the
security elements are entirely external to the design.  For example,
is the radio protocol one that's built into laptops by default, like
wifi or bluetooth?  Or into smartphones?  Or does it require custom
hardware?  If not, a teenager can more easily attack the mirrors --
and a corrupt government can infect millions of laptops and phones
with malware that will attack mirror arrays that they come near to.

For products that never get made in the millions, the design cost
(salaries and time) is a significant fraction of the final cost per
unit.  Therefore everybody designs unencrypted and unauthenticated
stuff, just because it's easy and predictable.

For example it's pretty easy to make the system-on-chip above send or
receive raw frames on the radio.  Harder to get it to send or receive
UDP packets (now it needs an IP address, ARP, DHCP, more storage, ...).
Much harder to get it to send or receive *authenticated* frames or UDP
packets (now it needs credentials; is it two-way authenticated, if so
it needs a way to be introduced to its system, etc).  Much harder
again to get it to send or receive *encrypted* frames or UDP packets
(now it needs keys too, and probably more state to avoid replays,
etc).  And how many EE's who could debug the simple frame sending
firmware and hardware, can debug a crypto protocol they've just
implemented (even making the dubious assumpion that they compounded
the elements in a secure way and have just made a few stupid coding
mistakes)?

	John



More information about the cryptography mailing list