[Cryptech Tech] goals / use cases

[Warren Kumari]

On Wed, Jan 28, 2015 at 9:30 AM, Joachim Strömbergson
<joachim at secworks.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Aloha!
>
> Peter Gutmann wrote:
>> No, but why would you need that?  Both SHA-1 and AES are totally
>> deterministic, even if the implementation came straight from the NSA,
>> what could they do with it?
>
> Side channel leakage - for example. How do you determine that their AES
> engine does not also do key dependent operations besides performing the
> algorithm specified FIPS-197?

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

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.

So, I think that this all comes down to just how much tinfoil you want
to wear, what the device that gets built does, etc. Perhaps, seeing as
we are building legos, the end user can decide to put together a
system where the keys live in the envelope, but they decide, with full
understanding of the consequence[0], to use a bulk crypto engine in
the MCU...

W
[0]: We'll just drop a note in the /doc folder, and *everyone* will
read it and understand... yeah, right...




> Yes, we are inside the tamper boundary so
> we can potentially reduce the problem. But the key thing is that we
> don't know what they do. We have no control and little trust.
>
> The whole point of Cryptech (at least my understanding of it) is to gain
> trust by as far as is possibly have control by moving away from
> dependencies of application specific functionality that we don't have
> the source to and can control. That is why we want to provide our own
> custom hardware that we can compartmentalize as much as we want.
>
> Using the cores in the cores in the CPU would thus be a step in the
> other direction from what we do with the Novena.
>
> If we suddenly decided that we trust black boxes in our CPU for random
> generation as well as crypto operations, blobs for firmware and sw, we
> could simply buy ourselves a security chip, add Cryptlib, write some
> custom SW to tie it all together put it in a box and be done. I don't
> think that is the plan we will follow.
>
> - --
> 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/
>
> iQIcBAEBCAAGBQJUyPKdAAoJEF3cfFQkIuyNBBIP/At9HiW75dCvD6f7MJXKYR3V
> L+6UiF/inIxEUGFcwnP1lZ1H8+3+YA0bo2UdsmMK00ajly/AkFaXTFc3w8b1RPSR
> JfEzSptF1fIbg0xTvv7lqQMqEuq03zOrbEIBxg6m3Fi4TM73xh1rtvf/spba1d7u
> NY7wSCdpQLnVB24M6kjbCZhqfxlPlNv5SKc4DPvYlffqvwcQ5GCZLFpb/Bam5DOJ
> J2rE2NIXafVgbCyKAadNZaI5MUE+rOooezyzkCxhymbwFjWzyjeTazinAwqJOw1O
> WfRBEwcP6PkN/qEC77ETn2hROYwyIQOPJaAY2X6oklYsuUnGAkFH6EsSz3INi1ph
> BX55xHv5jxYyP0wbFazfeKRP4MMsONRZSK8uy4hX2NNsO9PSr5Yh8lzAoumnM/rP
> 8YOBGSPncqJXnVVh2i9Dt/8aODpOwU6MG9wCM9obi6N81PpqdpPlvxBceqluTkhS
> LozbrkPjmWyxaYtICHxErdDVgh1dd1qFrDvOtRpgt+DalCRj3wz3cWKdqkRziMsX
> ITNZCojHIcWt1JxG9Racxi8LNYksrCbMsVf6KX1C5ybjugzhpIWXGZDrZZP5e3xa
> JgUviVzjDgIo4Q+RnL8GJsELkQaNViaIxx+g+t+zHgGehu61wLlnN/e3Ly+kFcTM
> n6TTg2selMEVqDo3uirK
> =wktH
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech



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