[Cryptography] The Crypto Bone's Threat Model

[Ralf Senderek]

Ray Dillinger and Jerry Leichter have made suggestions on
how to reset an electronic device by the legitimate user.
Excuse my tendency towards applying these suggestions to the
Crypto Bone and its available features within its threat model.

A user wants to "reset" his working Crypto Bone, he does not wish to 
get a new, empty one, but for some reason he insists that the
vpn connection should use a new key and the message key database 
should be encrypted with a new masterkey and only he should have
these two new keys on a removable usb medium in his own hands.

Bear's suggestion (with more general demands on hardware design):

> Essentially this amounts to separating all firmware updating
> from all normal operation at as low a level as possible, while
> providing a "hardware reset" capability to restore a known
> firmware configuration.
> 
> 1) The Device has in ROM (ie, not rewritable AT ALL) the
>     required code to disable the device's external connections,
>     then "flash" all the rewritable firmware in the device
>     back to a known configuration.  Any updates to firmware
>     beyond the default configuration, must happen again
>     after any time this code is run.  Absolutely no on-
>     device memory image anywhere, save only the non-rewritable
>     ROM itself, survives the autoflash.
> 
> 2)  The "autoflash" action described above happens when and only
>     when a physical switch on/in the device is triggered by a
>     human.  It cannot be triggered nor prevented in any way
>     from software, including firmware.
>
>     I'd suggest a switch with a good mollyguard; maybe a
>     tiny button located behind a 12mm-deep 1mm-wide hole, such
>     that someone would have to stick a wire into the socket
>     to reset it or something. Or maybe a DIP switch mounted
>     behind a snap-out panel.  Up to you, just don't leave it
>     hanging out where someone could hit it accidentally.
> 
> 3)  When in its "autoflashed" mode it can copy new firmware
>     images from the mSD card into its own RAM, but does not
>     actually install any of it, on any device, at all,
>     until....
> 
> 4)  When the operator flips the switch back to "normal operation"
>     mode, a different chunk of the  ROM code runs.  It flashes
>     the new images to all on-device firmware, disables all
>     firmware updating, and THEN re-enables network communications.
>     At no time until it's finished running does it call any of
>     the firmware it is installing or has installed.

1) is equivalent to inserting a new mSD card, the database is lost, new 
keys are generated, this is not what the user wants. A reset should 
preserve the message keys. If need be, he could reset a single message
key in the usual way.

2) can be done by requesting the user (legitimate or not) to perform some
identifiable action on the beagle bone's gpio pins, like morsing SOS on a
pin by short-circuit pin x with pin y. Ther's no need for a switch, if you
don't insist that the action "cannot be triggered" by software. Software
surely will be necessary for that.

3) is no problem, as the new keys can be written to the ramdisk, internally
without replacing the working keys.

4) This is the crucial part that activates the new keys. And here the switch
alone does not suffice. I continue after Jerry's suggestion on that part.


Jerry Leichter's suggestion:

> I'd suggest the following:
> 
> 1.  The modifiable portion of the device contains a signature key based on a published algorithm.
> 2.  To change the key, not only do you have to enable the mechanical interlock, but you must
>      provide both the old key and the new key.  (Or perhaps sign the update with the old key.
>      It would seem these are equivalent, though I'd want to think about it some more.)
> 3.  All devices are shipped with the same published, initial key.
> 4.  If you lose the key, there's no way to ever update the device again - though it will continue
>     to operate in its current configuration indefinitely.
>     (Allowing a "reset to factory state" would allow an attacker to load arbitrary code, which
>     we obviously want to prevent.  Note that you can deliberately turn the device into a ROM by
>     changing the key to a new randomly-chosen one and promptly discarding the new key.)


1) At the moment, there is no signing key in the Crypto Bone at all. It generates the
vpnkey and the masterkey on its own by reading from /dev/random. And it destroys the masterkey
as it must be provided by the user from outside the Crypto Bone through 
the secure link.

2) Once the mechanical interlock is triggered, the user must provide the old masterkey to
prove he is a legitimate user. Note, the threat model assumes physical access to the CB, 
so an attacker can morse SOS on the gpio pins but without the masterkey a reset would not be
initiated. (Separation of masterkey from message key database).
But we're talking about Johnny, who can't encrypt, so the new key must be generated inside the
CB as a result of running the reset-code.

3) N/A

4) If Johnny loses the masterkey, no reset will be possible, the CB will be stuck after boot
in the loop waiting on the masterkey nobody can provide, access to the message key database
is lost. Time to insert a new mSD card image and be more careful next time.

So, what can go wrong?

If the reset-code on the Crypto Bone is unmodified (as other crucial parts of OpenBSD)
the legitimate user can trigger a reset by performing the action on the board.
An attacker without knowing the masterkey cannot. And the masterkey is 
nowhere to be found on a powered-off Crypto Bone.

When keys get replaced and the database re-enrcypted the transfer of these secrets to 
the legitimate user's removable medium must take place in the same manner as if it were
a fresh mSD card running for the first time. If Johnny forgets to remove the mSD card
and does not transfer the secrets to his usb stick, then leaving the SD in the Crypto
Bone will destroy the masterkey rendering the system unusable. And that is exactly what 
it should do.

      --Ralf