[Cryptech Tech] Fwd: Re: Cryptech HSM enquiry

[Thotheolh Tay]

Hi,

I would like to congratulate the CrypTech team on having an Alpha board
released after around 2 years of development (since 2014).

I find the CrypTech webpage terse on information so I have to ask questions
via email.

In the previous email, I was told the KMK key would be stored in a tamper
detecting and battery backed RAM.

Here are my questions:

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) ?

2.) Are there software protection against timing and power analysis or
other side-channel protection mechanism (i.e. dynamic whitebox crypto) ?

3.) Are there software protection against attempts to listen to CPU
processes via EM emissions (i.e. dynamic generation of false instructions
and routines) ?

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)  ?

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 ?

6.) How do I know I have booted the correct software and firmware without
any tampering ?

Regards,
Thoth.

On Wed, Sep 9, 2015 at 8:50 AM, Thotheolh Tay <twzgerald at gmail.com> wrote:

> Hi,
>
> Thanks for clearing up the confusion regarding the chips.
>
> You said: "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."
>
> 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.
>
> 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.
>
> 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.
>
> On Wed, Sep 9, 2015 at 2:16 AM, Joachim Strömbergson <joachim at secworks.se>
> wrote:
>
>> -----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-----
>>
>
>
>
> --
> ,----------------------------------------------------------,
>   PGP Secure Email Key ID:6FBFC19D
>       7721 3E54 FA6D B79D AFE6
>       AC45 8885 F995 6FBF C19D
> '----------------------------------------------------------'
>



-- 
,----------------------------------------------------------,
  PGP Secure Email Key ID:6FBFC19D
      7721 3E54 FA6D B79D AFE6
      AC45 8885 F995 6FBF C19D
'----------------------------------------------------------'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20160719/d4870b94/attachment-0001.html>