[Cryptech Tech] goals / use cases

[Joachim Strömbergson]

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

Aloha!

Warren Kumari wrote:
>> ... and now I have confused myself. When I read Peter's mail I
>> agreed with it -- it would be really nice if we *could* use some of
>> the crypto hardware that comes for free in SoCs, thereby providing
>> speed (in throughput and development time), and saving chunks of
>> FPGA. Even if the implementation was provided directly by an
>> adversary it would need to coexist and interoperate with other
>> implementations written by everyone else. If I encrypt or hash
>> something with the built in core, it needs to decrypt / match the
>> hash from a reference implementation, and so shenanigans should be
>> impossible (or there is some weakness in AES / SHA-1 that we don't
>> know about, in which case we are screwed no matter who makes
>> this!)
> 
>> and then, wearing the maximum tinfoil.... wheeee, side-channels...

Exactly. I'm not worried cores in the SoC don't conform to FIPS 197 or
FIPS 180-4 for example. If they did somebody would find our very fast.
You can't be almost right functionality wise with AES or SHA-256. Either
it gives the expected result or it is waay of. Its one of the things
which makes it so fun to implement these functions. It is hard to find
the errors, but when you are right you can be pretty certain that it works.


>> An example, (very) naive timing side-channel would be for the 
>> (malicious) on-core engine to leak information by watching for a 
>> specific signal in the datastream, and then either operating at
>> normal speed to signal a '1' or delaying the crypto by a bit to
>> signal a '0'. Or, after receiving a signal in the datastream,
>> simply correctly or incorrectly encrypting the next <keysize>
>> blocks. This would be very hard to detect (if you don't know the
>> signal), and, more importantly, very hard to prove does *not*
>> exist.

Yes.

Add key dependent delay (just a one or a few cycles), which might only
leak part of the key, but reduce the strength. Or perform key dependent
operations that toggle lots of bits thus consuming power, operations
that can't be read by SW and thus not be detectable from SW. Or vary the
frequency of an ocillator between to defined values based on the bits in
the key register.

All these are fairly easy to implement as part of a HW-core. Finding
them would require active meaurements of these types of effects. Or
reverse engineer the design from the layout of the chip.

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

iQIcBAEBCAAGBQJUyRBMAAoJEF3cfFQkIuyNWnsP/RzTMpnJBgOVs3FIYCoTDatD
Hovjo86dFNa/iTeSBnsj6QMb1F+tfATi25R0CBZyHUMfV41Y4WfsAkAN8zbS+l/N
F4jjjEQHFNgp5kGgakx/Cuw2nPkQy3AmgboFI0nU4brZH13+nm28Gc05Iwtaypup
zIdEHuFJG6JD5896nnIP8TjR1AEN/fGRN+Wveb+cEbRyIwycXITBvidSWdbEucIa
BjyUvflSWijlCThVMd23zj2G9WwyqWzd8dePp5Jexl9dd7yyCTs9Yhif4JZDK/Tz
+BYVKfHg2TBDLmoh/3CK/FBLz14N/AbnbmbMnVStqMcYRviTsnPYREcvkav5KDWY
mB6g7amYz55V7zRRmISkc9eJu4z6Xsq9HBukcoKKwboYOhCSRLc/BV3B/UgDlxi0
nTreRW9F7z6HhoT9flgyjvnxoZv/JVyIPWHBqXyjqJQ0tg6w332ErgXiVlBpH3hn
4OiUaoRaTUV1Lk7/PICOb0pAAEtrgwjuVv7YPTPwrvhyQB/g2thdn60wFZ4061P1
60ZkCuZgjVgiEQDwxyfHAKR+5lXAf7PMQIp+r+j8jWn9EuJhMs/jj4VvqYWFDUm6
NTdMZK1kf6qcZvXyCuHurwgaggRmVXphB5t5+TE8vfIWF7M05HF9NIOcJMhmVsX7
f19C101OTKUuGZ1O4UsD
=Mqi4
-----END PGP SIGNATURE-----