[Cryptography] The Crypto Bone's Threat Model

[Ralf Senderek]

The Crypto Pi has morphed into the Crypto Bone, as I succssfully
changed the OS to OpenBSD and use the Beagle bone as the hardware
platform now. These changes have made the original project more secure
and much more auditable.

But the question still remains, if the Crypto Bone's threat model
is sufficient or not. And I'd like to explain the threat model
for open criticism here.

To my knowledge, nobody has scrutinized the system as a whole, yet.
Obviously, decent peer-review is an investment of time and effort that
makes sense only when a certain level of maturity has been reached,
which is the case now, I think.

A technical explanation that defines what the Crypto Bone does can be
found here:

    http://crypto-bone.com/cbb-technicalview.html

The crucial assumption behind the Crypto Bone is, that for ordinary
users it is more secure to delegate the encryption of messages to an
isolated, personal device than to perform message encryption on their
endpoint devices. All design decisions follow this assumption to secure
processes on the Crypto Bone as much as possible and to let users
access the results with their (insecure) endpoint devices through
an encrypted tunnel only.

As a consequence, the threat model has to take several attack scenarios 
into account:

1) Attacks from outside the local network on the user's endpoint device
    (malware infection, browser misbehaviour, you name it)

2) Attacks from inside the local network on the Crypto Bone (by exploitation
    of the insecurity of the endpoint devices and the local network, i.e.
    compromise of the internet router via vendor induced back-doors, ...)

3) Modifications of core components like OS vulnerabilities or hidden firmware
    exploits (the recent discussion about SD card storage springs to mind)

4) Physical Attacks (manipulation of the SD card / storage medium, stealing the
    Crypto Bone, ...)

In short, the Crypto Bone responds to these threats by strict separation of
the keys that enable its use and the encrypted database of message keys.
Once set up, the Crypto Bone turns into a state of maximal isolation, prepares
for an incoming VPN connection over the network interface and waits for the
arrival of a masterkey through this VPN connection.

On the user's endpoint device a gui helps the user to locate his Crypto Bone,
helps to establish the encrypted link and helps to upload the masterkey via SSH.
The necessary secrets are stored on a memory stick, that the user provides to 
"unlock his Crypto Bone". These secrets will be stored away separately by removing
the memory stick from the endpoint device. This is the shortest description
I can think of.

Now, stealing the Crypto Bone won't let the attacker recover messages or message
keys, as the master key is not present, while the Crypto Bone is not working.
An uploaded master key will reside in a ramdisk not in the Crypto Bone's filesystem.
Stealing the master key alone (via malware) does not reveal message keys without
physical access to the Crypto Bone (i.e. the encrypted key database).

But stealing the vpn secret lets an attacker establish the encrypted link, if he can
use a local machine to set up the VPN with this secret. In my view, it is not
helpful to burden the user with the additional use of passwords to protect secrets
he needs to use the Crypto Bone. It might be more sensible to require the presence
of pico siblings, an idea developed at the University of Cambridge, to replace
passwords and to use these as additional conditions for the Crypto Bone to unlock.

      http://mypico.org/technical

But anyway, if separation of keys and encrypted database is the way to go, the user
has to get the key into the Crypto Bone in some way to unlock it. With OpenBSD it's
not possible to insert the keys directly as the usb hardware on the Beagle Bone is
not supported by OpenBSD at the moment. I hope that'll change soon.
The only way today would be flashing the Crypto Bone OS to the on-board EMMC memory
and to use the SD card as the temporary key medium that has to be provided manually
by the user. I can imagine that many user would not understand the necessity to 
remove the keys and would rather leave the SD in the Bone "for convenience".
And all protection against 4) is thrown out of the window again.
That's why I prefer the VPN link, instead.

Are there any major problems with this threat model from your point of view?


      --Ralf