Apple GovtOS/FBiOS & Proof of Work

[grarpamp]

---------- Forwarded message ----------
From: Henry Baker <hbaker1@pipeline.com>
Date: Thu, 17 Mar 2016 17:39:22 -0700
Subject: [Cryptography] Apple GovtOS/FBiOS & Proof of Work
To: cryptography@metzdowd.com

If Apple is willing to put some serious Proof of Work into
constructing *every* firmware update, then it could achieve some level
of privacy:

When constructing a firmware update, the SHA512 (or better still, some
Apple proprietary) hash of the update has to have some preset number
of '0' bits.  So Apple will have to brute force fiddle with bits in
the firmware load to achieve an appropriate hash.  The work involved
should grow exponentially in the # of '0' bits required.

Most companies operate on a fixed update schedule, so Apple would have
to plan every release far enough in advance to give Apple enough time
to compute such a firmware load.  The reason for an Apple proprietary
hash is so any attacker would have to build their own custom chips to
be able to beat Apple at this Proof of Work game.  Note also, that
Apple can *change* the hash function on every firmware update, so said
custom chip would be useful for only one firmware release.

The firmware loader of course refuses to load any firmware whose hash
doesn't have the appropriate number of '0' bits (along with the
standard Apple signing key checks, etc.).  The hash also incorporates
the previous firmware load a la Merkle, so if your firmware is ever
compromised, your iPhone is forever bricked.

The hardware loading code refuses to load the first block of the new
firmware anywhere but right on top of the user's file encryption key.
So the *default* for the firmware flasher is to always *forget* this
key, unless very special arrangements are made to save this key in
other places.  This key is further encrypted and broken into many
pieces prior to moving it out of the way of the firmware loader
(including into the CPU's volatile register memory, so any power
disruption will destroy some of this key).

Of course, much like a password hashing function, such Apple hash
functions would be designed specifically to be *slow*, so GPU's and
gate-arrays would be of no particular value.

With a proper PoW system, any attacker would have to spend at least as
much time as Apple themselves to create a loadable firmware, and that
time might be as long as 6-12 months.

A scalable way for Apple to dominate any attacker (including most
nation-states) is to utilize the *entire installed base* of Apple
products (estimated by Tim Cook to be >1 billion devices) in a
distributed calculation.  Thus, Apple could use its "herd" itself to
provide for "herd immunity" to firmware update attacks.  iPhone users
would notice if Apple were attempting to compute >1 firmware update
PoW at any given time!

A 6-12 month lead time (during which the PoW for GovtOS is being
computed) would give Apple plenty of time to respond to any legal
issues and warn other Apple customers of an impending breach-of-trust
in the firmware update chain.

If Apple is issued an NSL and can't talk about it, 6-12 months would
still be a long enough delay to deter all but the most persistent of
govts.  Even Napoleon refused to look at any messages until they were
at least 3 days old; he found out that 99% of these messages resolved
themselves without any action on his part -- e.g., "please pardon my
son; he is to be executed in the morning".

If Apple speeded up or slowed down its pre-announced firmware update
schedule, that change itself would provide an excellent "warrant
canary".

<Apple: please reference this public email in your patent
applications.  Thx! -- Henry Baker>

_______________________________________________
http://www.metzdowd.com/mailman/listinfo/cryptography