[Cryptech Tech] Fwd: Re: Cryptech HSM enquiry

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Thotheolh Tay wrote:
> Maybe I am confused but you mentioned you do not use closed source 
> stuff.

No, that is at least not what I meant. What I tried to say is that we
try to be as open as possible. And crucially, we try to avoid depending
on security functions and specific security components that are closed
source as basis for our security.

Given the choice of a very nice specific security memory from a specific
vendor that is a black box, or a standard memory available from several
vendors that we can add our own security on top of, we would probably
choose the latter.

Does that make it clearer?



> The  STM32 Cortex M4 based MCU from ST and Xilinx Artix-7 have their
> designs and circuitry opened ?

No they are not, and it is a problem.

We need a CPU/processor platform. If possible we would use an open
source based one. And there are some alternatives such as OpenRISC,
RISC-V. In the long run we might end up using one of those. But right
now we use separate CPUs. On the Novena Bunnie had selected the i.MX due
to no blobs and good documentation. But it is a very complicated CPU
with a lot of kitchen appliances built in.

The STM32 is simpler, does not require a blob to start running (like the
CPU on the Raspberry Pi). But the STM32 still has several peripherals
that we don't need. We try to tie them off. But if we could find an ARM
core with basically no peripherals or a chip based on open source it
would be very interesting. If you have any good suggestions we would
appreciate it.

For several different reasons we want to use our own custom security
hardware (cores for hashes, TRNG, modexp, ciphers etc.) In the long run
we could go to an ASIC. For ASICs there are open source tools that can
get you down to GDSII and then you have to trust the foundry to turn it
into chips based on you layout.

But FPGAs are black boxes and there are no real open tools. It is a
problem. We are looking at ways of making it possible to trust FPGAs,
and we need to address them when we are getting closer to meet the basic
use cases with our custom boards. But right now we basically have to
swallow the blue pill. But the FPGAs are still available from more than
one vendor and are generally available.


> I have not asked about the OS running the Alpha board. Is it a
> Linux, OpenBSD kernel or maybe an L4 kernel ?

On the Novena we are running fairly stock Debian ARM Linux. On the Alpha
board we will probably not be running a complete OS, but something more
lightweight. We have been looking at things like mbed, FreeRTOS etc. Rob
and Paul can probably give better info on this.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJV7yYaAAoJEF3cfFQkIuyN7LQQAMdx0Ra4GuELlQ9yWhsdrU93
VBZlsLw66rLEeD8F/W/kEnMq6ZFzJXl5UUCvqceNAA3nvMDGhWleV66mfV/HAyY5
Ku2f6R9isCaDcYXgCAnAnA2gM3M/hYz5tTmsXk5BhuttCxg/Tqf6vaiAHqlwZtuK
3ry7xZCIjuSz4Y6mKQ7afmqinsaneEAAzEvDoxX+U9U/10ZVOjZVEZt+WGMI+Jei
GwmnG9jBGdzVOeHoxUkp2+hnflnsXhAFK0jR0mMT2ev+oTrPZfpRxJsRdWbAzE/i
KBasp7Ws4Ogh/3r+AHC2VpOh7WMjihOVMiEMRSKuCE1Cmv1Mjz2FpIxVtKx7oIyZ
bR2VwcaRke2L8qU+LxMDeD/j6PgxYLXzXWBqJLg8IpZkHaIYCJCWIOG51msax7dt
nWnseqmCjEmMtDvMpcY74sXgJxiu9PQm90euhTzFvmEbMdNNVxwArOenuhSil95T
cY2zvYTfO5V2Uxer7AyLX5WoFCFhbYHl2k7wVWCmUPOIqiYk3iyEO4Zvv94+bna5
Ps2vizFwL2pYgSneFXBucnLpDpp24XzFsZ8wHx/JFk5Xr73flgTrysi/rneOlL6g
iJLSbzkxuJWG5y/MN/9fiQXsMUWkP3mZNwwmsXs9cCWhh+ep7eEbsauqIuuhRdrT
8xG4+1ZIznjtTgT7Zma+
=bENA
-----END PGP SIGNATURE-----