---------- 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