[Cryptography] The Crypto Pi

[Ralf Senderek]

On  Fri, 2 Jan 2015 Jonathan Thornburg wrote

> For a crypto appliance where security is paramount, would it
> be appropriate to choose as your foundation an OS with a more
> "secure by default" philosophy than modern Linux has adopted?
> 
> For example, should ASLR be turned on by default for all processes?
> Should malloc() aggressively randomize the addresses it returns?
> Should free() "poison" freeded blocks of memory in its data structures
> so that a later duplicate-free, or a later reuse without re-malloc-ing,
> causes a process-abort?  Should malloc() try to proactively check for
> buffer overruns?  Should the system gcc emit code which tries to
> catch buffer overruns?  If the Crypto Pi will be configured with
> swap space, should swap-space encryption be turned on by default
> to ensure that sensitive keying material never hits the disk?
> Should trying to dereference a NULL pointer be be a process-abort
> (to expose the failure) rather than a soft failure?
> Should system daemons be priviliged-separated, so that bugs which
> do occur, are less likely to be exploitable?
> 
> To me, these criteria suggest something like OpenBSD as your OS,
> rather than Linux:
>   http://www.openbsd.org/papers/ru13-deraadt/
>   http://homepages.laas.fr/matthieu/talks/openbsd-h2k9.pdf
>   http://www.openbsd.org/papers/eurobsdcon2009/otto-malloc.pdf

Thank you, for the links, If there was a mini or better micro version of 
OpenBSD running on the Raspberry, I'd love to use this as the foundation for 
the Crypto Pi. The criteria you mentioned would be very useful for a 
single binary that would run on the user's endpoint device where the attack
surface is very large. The Crypto Pi in itself is designed as an isolated
entity that is accessible only through a single encrypted tunnel, like a
VPN, so the attack surface is reduced. That doesn't mean that your suggestions 
should not be followed as much as possible inside the Crypto Pi.


     --Ralf