What if the "volunteers" have an ulterior motive? E.g., to "accidentally"
corrupt the contents of the phone! Are they then criminally liable
(co-conspirators, after-the-fact) for these acts? Does the FBI have to vet
each applicant?
The discussions/speculations regarding what lies within the device seem
to be incredibly naive. It's not being thought of from the standpoint of
a device DELIBERATELY designed to be secure but, rather, as some sort
of general purpose computer running a "security program".
What if the device was INTENTIONALLY DESIGNED to make these sorts of
changes impractical? Not just by confounding with software but by
actually designing failure modes into the HARDWARE? (comparable to
a glass relocker in a wall safe!)
E.g., imagine the encryption processor has a "key/passphrase REGISTER"
(not some general memory address but a specific REGISTER). The
HARDWARE that implements and interfaces to this register:
- inherently requires a long time for the WRITE to update its contents
- "wears out" after some number of write cycles
There's no need for the interface to be FAST -- it takes considerable
real time for the user to enter the passphrase. If it takes 100ms to
store it in that register, the user will never be the wiser!
There's no need for the register to be *durable* -- how many times
is a user likely to enter the CORRECT passphrase (plus some number
of typographical errors) in the LIFETIME OF THE PHONE? 20 times per day?
365 days per year? 3-5 years before you EXPECT the user to grow tired of
the phone, drop it, lose it, etc.?? What if a nonresettable hardware
counter locks out writes when the number of writes exceeds this value?
What if the inherent fabrication technology ensures this as a side
effect of normal use??
If the key space is sufficiently large wrt to these factors, you could
remove any and all "artificial" (software imposed) constraints on the
process and still end up with a physically uncrackable device -- it
takes too long for an exhaustive search of the keyspace AND the hardware
"wears out" before that sort of attack can succeed, independent of time!
[Keep in mind Apple has made deliberate design choices to make these
sorts of cracking requests harder with which to comply; why wouldn't
they take advantage of their design and market leverage to create
a HARDWARE device that imposes such constraints?? Then, throw up their
arms when asked to expedite the passphrase write time or alter the
maximum number of writes before the device locks? "We'll have to lay
out a new *mask* -- which, of course, won't help you with THIS particular
phone..."]