[Cryptography] The Crypto Bone's Threat Model

[Ralf Senderek]

On 27.02.2015 02:23, Tom Mitchell wrote:
> On Wed, Feb 25, 2015 at 8:57 AM, Ralf Senderek <crypto at senderek.ie
> <mailto:crypto at senderek.ie>> wrote:
>
>     Are there any major problems with this threat model from your
>     point of view?
>
>
> One possible omission... verification.
>
> The BBB does have a possible  verification path.   Verification of the
> flash memory image and files
> is possible by booting from a mSD card.   
> Double check that connecting and disconnecting a mSD card or other
> device does not reset the
> system....
The system cannot be reset by accident for a number of reasons. First,
when in the initial step the
secrets are being generated, a symbolic link (as root) is created to
indicate that this Crypto Bone is
initialized. If an attacker is able to remove this link inside the
Crypto Bone from outside, then the system
is reset. Obviously, using a root shell inside the Crypto Bone must be 
made as impossible as possible.

The most likely event for this to happen is the exploitation of OpenBSD
code via smtpd or fetchmail or
cron, or ..., but it will never happen by inserting a SD media. The user
can get confused, if he uses
several different Crypto Bone SD cards for different identities or
purposes, but the web interface will
always tell him who he is at the moment.

I don't have a solution for a complete system reset at the moment at
all, because I don't want to
place a button in the web interface that removes the symbolic link. I'm
open for suggestions how
to do this securely, other than to insert a virgin, verified new SD
image and start from scratch.

In addition, OpenBSD does not support the use of "other devices", the
only path inside the Crypto
Bone leads through the network interface. To prevent that an attacker
gets a root shell via the NIC
is the main concern here.


I'm really interested to find out how verification can be implemented
apart from signing the mSD card
image file. When the system is in use a tripwire-like IDS may help, but
the user won't be able to make
sense of the scan results. What are your suggestions?


       --Ralf


> This is a good step iteration may be needed in the future but good start.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150227/5774e294/attachment.html>