[Cryptech Tech] goals / use cases

[Warren Kumari]

On Wed, Jan 28, 2015 at 11:37 AM, Joachim Strömbergson
<joachim at secworks.se> wrote:
> -----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.

Yup. Adding a delay has the advantage of being remotely observable
(well, more remotely!), but there are many ways to leak info through
side-channels.

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

Yup.
One of my favorite papers is "Designing and implementing malicious
hardware"  - http://www.acoz.net/pubs/malicious_processor.pdf (I'd
lost track of this over the years, and it was surprisingly hard to
find again).

This has a malicious CPU (as a demonstration, a SPARC implemented on
an FPGA) that watches for specific signal / payload before the
malicious behavior kicks in. In this paper they trigger it by sending
an unsolicited UDP packet to the machine that the CPU is in --  in
order to decide if it should accept the packet, the cpu has to look at
it, which triggers the malicious hardware. This could presumably also
be triggered the having a magic value in the data one asks a crypto
core to encrypt / decrypt / sign / hash / touch.
 It's a fun, and fascinating read.


Anyway, if the malicious behavior only kicks in after a specific set
of magic bytes comes across the data bus, I don't see how we could
detect this (other than reversing the chip, creating a reference
standard, and then pulling lots of samples, depotting, ensuring that
they match the reference, etc... obviously not very practical..

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf