[Cryptech Tech] arm

[Joachim Strömbergson]

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

Aloha!

Hannes Tschofenig wrote:
> Note that there are also lots of M3/M4 CPUs offered by vendors with
> 100+ Mhz.

Yes there are. We probbaly need to go a wee bit further than that. But
GHz performance will quite probably not be needed.


> 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 problem is that there actually aren't that many chips that _lack_ a
lot of functionality. I've done some extensive parametric search among
M4-devices for another security wise project where we don't want things
like CAN-interfaces. I'm at least unable to find a very pure M4-based
device that only has say two USB2 interfaces, a couple of
SPI-interfaces. The target markets for these devices are things like set
top boxes/home entertainment, in-car media systems etc. High volume
markets where integrating a lot of functionality makes very good sense.

To us in Cryptech, with loads of professional tinfoil on our heads, the
mere fact that there are external interfaces that could be enabled via
SW is in itself troubling. We therefore want to avoid it as much as
possible.

> 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.

Probably.

> 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.

That is a very good suggestion. Getting a M4-based board and possible a
M0 board should allow us to better estimate what we need. And should be
cheap and fast to do. Rob, Randy, Fredrik - lets get some boards!

(And this does not imply that we will use mbed)


> 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...

As I tried to state, it is not as much about performance as security -
to move functionality out of SW space. And for some features we need
real HW.

In terms of the implementations of functionality in the FPGA actually
being SW I can assure you that the cores we use are NOT implemented that
way. (I'm the primary FPGA core developer.) We implement our own cores
for AES, SHA-256, RNG etc and don't instantiate any CPU inside the FPGA.
You can see our cores here:

https://wiki.cryptech.is/browser

- -- 
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/

iQIcBAEBCAAGBQJUskooAAoJEF3cfFQkIuyNLsIQALaD4JnPB6tboZbLb5RjOH0+
G/dHpJw8cgSwngihMXwAvXhWT0kR0ok7iVmpISyQBRc4tnngUggCqBnVigyyvdEv
WwOBuPZt4Ps4wBFj1u7WCpVz7fVSH+wMUbSg/vlQYTs3RLCD3nzPsD0AajYdtkDO
rHmOx9GQXTVjLskyMBri8FSeepsovkw2fYcGJ7dPlXjm8QkgM16vTFZ3kGX1mfcG
gBCFdh6M/TPEqjFoHG+GiIItjP/rknLfJnQDu782lC5aCp0UP560YCk7YlwB23Wi
lMZ3/xSEGNbiaMxSUxF0NfuLFUXK98QfzHQ9fCv6bTQkdUAsugZkKEYWKWJf2VdF
IX3xYY0UBqajyoQCGZnOO+VK6GJSAVChaGCAEn1QhygvoRfIv0tsAfL9OwFx4w8Z
qZHG+HsoMrG7D+wMWHKM8rhFUpdt4KcAHdqogkJPhB8CK3dwsE5rGhabyAIYGu86
Gnu/UTRpQYFRmM3ToH/go4EXgMgtcjLAcuHWNB+scIgAcH7RvXzgoJkw/kFc6ntI
H7bOSsu/uyy1ctA+vYjnsLfRxU49Yl40OY20BLhvxFHbjrkvsyrjujFtwTEEYpbb
xzKytn6IHLLBuxXO7vzpFc6XowUAFqhPAlt/5Th0i6Zh8TFllKPb3tEFxM0ytKaD
eqG48870fjwLUXUHUkKN
=KwIP
-----END PGP SIGNATURE-----