[Cryptech Tech] arm

[Hannes Tschofenig]

Hallo Joachim,


On 01/11/2015 09:21 AM, Joachim Strömbergson wrote:
> Aloha!
> 
> Hannes Tschofenig wrote:
>> I work for ARM and could help you with your questions.
> 
> Hi Hannes, and thanks for the offer, much appreciated.
> 
>> Mbed is designed to work with the Cortex M process family. There are
>> different types of processors available in that family, namely M0,
>> M0+, M3, M4, and now also M7. The M7 was announced around ARM TechCon
>> as well and aims to bridge the gap (in performance) between the
>> Cortex M family in the Cortex A family.
> 
> The M7 is an interesting development. Good to know that mbed will also
> support the device. I'm using Mbed with M0+ as well as M4 devices, but
> can see a clear need for even higher performance processors.

Note that there are also lots of M3/M4 CPUs offered by vendors with 100+
Mhz.

> 
> 
>> You will be astonished to see what features our silicon partners add
>> to the chips...
> 
> And that is actually one of our problems. If you look at M4-based
> devices they often comes with a bevildering array of peripheral
> functions. Dual CAN-interfaces, GPUs, touch screen controllers and
> integrated MAC/PHYs for example. Very nice if one is to design an in car
> media system. Not as good when one just wants to run general purpose
> code on a MCU that is as aeasilu audited and trusted as possible.

The second astonishing thing is that you have lots of choices. If you
don't want to have, for example, hdmi support on your chip then just
select a different chip.

For the ST chips I am using an app that allows me to do a parametric
search to find my way through the huge number of different chips variants.

Even if you have a feature on the chip you might not enable it (or
disable it later, such as debugging functionality).

> 
> The amount of compute power we actually need is yet to be determined, we
> are working on the requirement specification at the moment and will use
> that to drive the device selection. The Novena uses the quad ARM-A9
> cores running at 1.2 GHz. Our code does (afaik) use more than one core
> at a time. But anywhere close to the same clock speed puts us in
> M4-device area. But at the moment we really don't know what speed we
> need to support. We will connect to host systems using USB 2.0 Full
> Speed and parse PKCS#11 commands using Cryptlib to implement them.

To me this sounds like a pretty minimal performance requirement if you
consider that most chips have USB support already included. Parsing
PKCS#11 commands is something that even an M0 will do.

But you can give it a quick try if you take one of the mbed developer
boards and run the code there. I have run ECC performance tests on
various Cortex M processors and the performance was pretty good on most
of them. The only issue I ran into was lack of RAM to turn on the
optimization and then the performance suffered significantly. Since you
are not even doing the crypto operation on the Cortex M chip this
shouldn't be a problem at all.

>> PS: Why you want to use an FPGA is still a mystery to me.
> 
> There are a number of reasons for it. But basically:
> 
> (1) We really want to move the lower layer functionality (cryptographic
> functions, random number generation etc) out of the SW context to make
> them harder to modify. It also divides the system into more parts that
> are easier to audit.
> 
> (2) For some of the cryptographic functions we absolutely need
> concurrent execution. The entropy sources (we have multiple) driving the
> random generator for example are autonoumous and runs concurrently. Task
> switching in a CPU cannot replicate that.
> 
> (3) For some of the algorithms, parallel hardware provides a much better
> performance and allows us to run the CPU at lower clock speeds. This
> makes it easier for us to find a suitable device with less complex SoC.
> 
> It is important to realise that we are building a very high security
> system, not just an embedded system. Yes, quite a few ARM based devices
> (for example STM32) provides random number generators in them. But we
> can't test their internal function, don't know how they really work
> (just what the documentation states). We need to build our own RNG, hash
> functions, modular exponentiation, key storage. And then have as little
> else as possible.
> 
> That at least to me means FPGAs coupled with an MCU.

It is of course your project. I am not convinced but maybe you really
need the performance that justifies the FPGA use. Note that many things
that appear to be in "hardware" are actually software running on the
chip. I guess that would be a discussion in a pub after some beer...

Ciao
Hannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 513 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cryptech.is/archives/tech/attachments/20150111/6176d176/attachment.sig>