[Cryptech Tech] goals / use cases

Warren Kumari warren at kumari.net
Wed Jan 28 22:57:34 UTC 2015


On Wed, Jan 28, 2015 at 2:26 PM, Bernd Paysan <bernd at net2o.de> wrote:
> Am Mittwoch, 28. Januar 2015, 19:43:06 schrieb Fredrik Thulin:
>> Hmm, no I think that sounds like the age old SSH passive monitoring attack
>> by Solar Designer
>>
>>   http://www.openwall.com/articles/SSH-Traffic-Analysis
>>
>> (see Interactive session weaknesses).
>>
>> I think the one I remembered and talked about was this USENIX paper
>>
>>
>> https://www.usenix.org/legacy/event/sec06/tech/shah/shah_html/jbug-Usenix06
>> .html
>>
>> Anyway, the point as Randy says is that there is no end to the possible side
>> channel attacks in black box chips.
>
> Yes, indeed.  The literature is full of side-channel attacks against AES, but
> one difficulty is that hardening against one side-channel attack might not
> give anything for other side-channels.  One of my concerns with AES is that
> the key for long encryptions is constant for a very long time, and so even
> very small differences between different keys can be extracted through side
> channels.  Modern stream ciphers like ChaCha or block ciphers like Threefish
> have the same problem: constant key + tweak.
>
> That's why I use Keccak for encryption, because the sponge function makes sure
> that nothing is constant; each round will mix the entire state.
>
> Side channel attacks are even more successful at slower operations like
> RSA/DH-style exponentiation, that includes elliptic curves.  Even when you
> have constant timing, constant current is difficult to achieve, and you don't
> control an FPGA well enough to get constant curent (with an ASIC and special
> care, this is easier).
>
> Possible example attack: Dan Bernstein's Ed25519 reference code first computes
> the 8 values pubkey*[1..8] to be multiplied with the accumulator.  Let's
> assume that each of these pre-computed numbers have their specific current
> consumption pattern when multiplied with other numbers.  So this optimization
> vs. a simple "always multiply with the pubkey, and then decide" instead
> "select one of 8 possible attacker-known inputs to multiply with the
> accumulator" opens up a possible side channel.  And we can't control it if we
> use the FPGA's multiplication units, because those aren't designed for
> constant current.
>
> This attack is probably not generally feasible, but as the attacker controls
> the pubkey, it might be possible to extract enough information from several
> DHEs with different prepared pubkeys to get at the secret.  You know, simply
> by having a special microphone seveal meters away, and recording the
> ultrasonic sound of the deblocking caps.

Have we documented the actual threat model anywhere?

What all access to the device are we designing for / what capabilities
does the attacker have?
Can the attacker get close to the device? How close? While it is
operating under normal conditions? Can he provide arbitrary data to
the device, or is his ability to provide input limited? Does he have
access to startup keys (a token you need to present when turning the
device on)? Can he physically monkey with it? While it is in
operation? Without being noticed?

I've been assuming (and I *think* we've all been assuming) that the
design is supposed to be secure against a powerful attacker with full
access to the device, while it is on and functional, and who can take
it away and poke at it under whatever conditions he wants, but I'm not
sure if we've ever actually discussed and documented this.

The sorts of protections that one need against a remote attacker are
(obviously) very different than those against someone with physical
access.

W

>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> http://bernd-paysan.de/
> net2o ID: kQusJzA;7*?t=uy at X}1GWr!+0qqp_Cn176t4(dQ*
>
> _______________________________________________
> 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


More information about the Tech mailing list