<div dir="ltr">Hi,<div><br></div><div>I would like to congratulate the CrypTech team on having an Alpha board released after around 2 years of development (since 2014).</div><div><br></div><div>I find the CrypTech webpage terse on information so I have to ask questions via email.</div><div><br></div><div>In the previous email, I was told the KMK key would be stored in a tamper detecting and battery backed RAM.</div><div><br></div><div>Here are my questions:</div><div><br></div><div>1.) Is the tamper detection provided by software inputs or what sort of inputs are needed to trigger the tamper reaction ? Would attempts to tap or tamper the chips directly cause the KMK to be wiped like other secure chips ? Does it use some sort of tamper detecting sensor (i.e. metal shields and meshes, power glitch sensing algorithms) and where is this particular battery backed RAM stored in (inside the ARM chip or FPGA chip) ?</div><div><br></div><div>2.) Are there software protection against timing and power analysis or other side-channel protection mechanism (i.e. dynamic whitebox crypto) ?</div><div><br></div><div>3.) Are there software protection against attempts to listen to CPU processes via EM emissions (i.e. dynamic generation of false instructions and routines) ?</div><div><br></div><div>4.) Are there considerations to tamper protect (physically and logically protect) the ARM and FPGA chips against attempts to tamper the HSM in order to extract processing details (i.e. loaded and unwrapped keys inside the FPGA)  ?</div><div><br></div><div>5.) Traditional HSMs (i.e. Thales nCipher HSM) uses M/N quorums to create an administrator key to unwrap the master key with the M/N quorum shares stored inside smart cards. Are there going to be similar approaches to use a M/N quorum share to create an administrative shared key to protect the KMK key for additional security ?</div><div><br></div><div>6.) How do I know I have booted the correct software and firmware without any tampering ?</div><div><br></div><div>Regards,</div><div>Thoth.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 8:50 AM, Thotheolh Tay <span dir="ltr"><<a href="mailto:twzgerald@gmail.com" target="_blank">twzgerald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Thanks for clearing up the confusion regarding the chips.</div><div><br></div><div><span style="font-size:12.8000001907349px">You said: </span><span style="font-size:12.8000001907349px">"For several different reasons we want to use our own custom security </span><span style="font-size:12.8000001907349px">hardware (cores for hashes, TRNG, modexp, ciphers etc.) In the long run </span><span style="font-size:12.8000001907349px">we could go to an ASIC. For ASICs there are open source tools that can</span></div><span class=""><div><span style="font-size:12.8000001907349px">get you down to GDSII and then you have to trust the foundry to turn it </span><span style="font-size:12.8000001907349px">into chips based on you layout."</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">This is a very interesting idea that have been bounced around a lot in many security forums and especially in Bruce Schneier's blogs comments section (which you can find me as a commentator by name of Thoth). It is good if a foundry can help do chips and a few of us on the blog comments have touched on and posted ideas albeit a good amount of caution. The one huge lurking danger would be state actors subversion of chips during the masking phase and we posted ideas to mitigate that in the blog.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Regarding the OSes, it's nice to focus on the FreeRTOS and make it as lean as possible and try to use them across all other boards if it's possible.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">It's nice talking about the current HSM development. I have seen this project started quite a while ago for a couple years and now it has a working board is a good leap. Most commercial crypto/security tools and devices are too much blackboxes and one of the criteria I noticed in the Common Criteria is secrecy of designs as part of the evaluation (forgot where I saw it from one of the documents). This only encourages more blackboxes and insecurity to be hidden. If an open source HSM can be created rivaling and far surpassing the strengths of most common market HSMs, it could force the shift in market to become more open and standards and criterias to be more transparent.</span></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 2:16 AM, Joachim Strömbergson <span dir="ltr"><<a href="mailto:joachim@secworks.se" target="_blank">joachim@secworks.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Aloha!<br>
<br>
</span><span>Thotheolh Tay wrote:<br>
> Maybe I am confused but you mentioned you do not use closed source<br>
> stuff.<br>
<br>
</span>No, that is at least not what I meant. What I tried to say is that we<br>
try to be as open as possible. And crucially, we try to avoid depending<br>
on security functions and specific security components that are closed<br>
source as basis for our security.<br>
<br>
Given the choice of a very nice specific security memory from a specific<br>
vendor that is a black box, or a standard memory available from several<br>
vendors that we can add our own security on top of, we would probably<br>
choose the latter.<br>
<br>
Does that make it clearer?<br>
<span><br>
<br>
<br>
> The  STM32 Cortex M4 based MCU from ST and Xilinx Artix-7 have their<br>
> designs and circuitry opened ?<br>
<br>
</span>No they are not, and it is a problem.<br>
<br>
We need a CPU/processor platform. If possible we would use an open<br>
source based one. And there are some alternatives such as OpenRISC,<br>
RISC-V. In the long run we might end up using one of those. But right<br>
now we use separate CPUs. On the Novena Bunnie had selected the i.MX due<br>
to no blobs and good documentation. But it is a very complicated CPU<br>
with a lot of kitchen appliances built in.<br>
<br>
The STM32 is simpler, does not require a blob to start running (like the<br>
CPU on the Raspberry Pi). But the STM32 still has several peripherals<br>
that we don't need. We try to tie them off. But if we could find an ARM<br>
core with basically no peripherals or a chip based on open source it<br>
would be very interesting. If you have any good suggestions we would<br>
appreciate it.<br>
<br>
For several different reasons we want to use our own custom security<br>
hardware (cores for hashes, TRNG, modexp, ciphers etc.) In the long run<br>
we could go to an ASIC. For ASICs there are open source tools that can<br>
get you down to GDSII and then you have to trust the foundry to turn it<br>
into chips based on you layout.<br>
<br>
But FPGAs are black boxes and there are no real open tools. It is a<br>
problem. We are looking at ways of making it possible to trust FPGAs,<br>
and we need to address them when we are getting closer to meet the basic<br>
use cases with our custom boards. But right now we basically have to<br>
swallow the blue pill. But the FPGAs are still available from more than<br>
one vendor and are generally available.<br>
<span><br>
<br>
> I have not asked about the OS running the Alpha board. Is it a<br>
> Linux, OpenBSD kernel or maybe an L4 kernel ?<br>
<br>
</span>On the Novena we are running fairly stock Debian ARM Linux. On the Alpha<br>
board we will probably not be running a complete OS, but something more<br>
lightweight. We have been looking at things like mbed, FreeRTOS etc. Rob<br>
and Paul can probably give better info on this.<br>
<span><br>
- --<br>
Med vänlig hälsning, Yours<br>
<br>
Joachim Strömbergson - Alltid i harmonisk svängning.<br>
========================================================================<br>
 Joachim Strömbergson          Secworks AB          <a href="mailto:joachim@secworks.se" target="_blank">joachim@secworks.se</a><br>
========================================================================<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2<br>
Comment: GPGTools - <a href="http://gpgtools.org" rel="noreferrer" target="_blank">http://gpgtools.org</a><br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" rel="noreferrer" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
</span>iQIcBAEBCAAGBQJV7yYaAAoJEF3cfFQkIuyN7LQQAMdx0Ra4GuELlQ9yWhsdrU93<br>
VBZlsLw66rLEeD8F/W/kEnMq6ZFzJXl5UUCvqceNAA3nvMDGhWleV66mfV/HAyY5<br>
Ku2f6R9isCaDcYXgCAnAnA2gM3M/hYz5tTmsXk5BhuttCxg/Tqf6vaiAHqlwZtuK<br>
3ry7xZCIjuSz4Y6mKQ7afmqinsaneEAAzEvDoxX+U9U/10ZVOjZVEZt+WGMI+Jei<br>
GwmnG9jBGdzVOeHoxUkp2+hnflnsXhAFK0jR0mMT2ev+oTrPZfpRxJsRdWbAzE/i<br>
KBasp7Ws4Ogh/3r+AHC2VpOh7WMjihOVMiEMRSKuCE1Cmv1Mjz2FpIxVtKx7oIyZ<br>
bR2VwcaRke2L8qU+LxMDeD/j6PgxYLXzXWBqJLg8IpZkHaIYCJCWIOG51msax7dt<br>
nWnseqmCjEmMtDvMpcY74sXgJxiu9PQm90euhTzFvmEbMdNNVxwArOenuhSil95T<br>
cY2zvYTfO5V2Uxer7AyLX5WoFCFhbYHl2k7wVWCmUPOIqiYk3iyEO4Zvv94+bna5<br>
Ps2vizFwL2pYgSneFXBucnLpDpp24XzFsZ8wHx/JFk5Xr73flgTrysi/rneOlL6g<br>
iJLSbzkxuJWG5y/MN/9fiQXsMUWkP3mZNwwmsXs9cCWhh+ep7eEbsauqIuuhRdrT<br>
8xG4+1ZIznjtTgT7Zma+<br>
=bENA<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">,----------------------------------------------------------,</div><div dir="ltr">  PGP Secure Email Key ID:6FBFC19D</div><div dir="ltr">      7721 3E54 FA6D B79D AFE6</div><div dir="ltr">      AC45 8885 F995 6FBF C19D</div><div dir="ltr">'<span style="font-size:12.8000001907349px">----------------------------------------------------------'</span></div></div></div></div></div>
</span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">,----------------------------------------------------------,</div><div dir="ltr">  PGP Secure Email Key ID:6FBFC19D</div><div dir="ltr">      7721 3E54 FA6D B79D AFE6</div><div dir="ltr">      AC45 8885 F995 6FBF C19D</div><div dir="ltr">'<span style="font-size:12.8000001907349px">----------------------------------------------------------'</span></div></div></div></div></div>
</div>