[Cryptography] High volume thermal entropy from an iPhone

[Alexandre Anzala-Yamajako]

>
>
> There's another thing to consider:  Even assuming NSA-level resources, it
> would be impossible to rig every potential source of randomness out there.
> And suppose you actually put this out there, and thousands of random
> hackers adopted it.  Would that be important enough for NSA to go to the
> trouble of forcing Apple to rig everyone's phones just to get to those?
> And - unless they could accomplish that with just a software update - it
> wouldn't work against any pre-existing phones *anyway**.*
>
1. you don't need Apple to target people you just need to impersonate the
appstore to them (so basically we re back to the PKI as your lifeline. That
does *not* make me feel safe). Probably there needs to be some nifty tricks
to pass the code signing check but that's their job and the payoff woulf be
huge.
2. there is already a ton of software running around your actual hardware
camera and i would guess a significant part of this software has a direct
impact on what you would get as the entropy of you raw image.
3. monitoring the output to try to detect suspicious variations of
"entropy" is extremely hard here because you have 3 non independent
distributions :
-the distribution of harware camera, each of them having their own specific
patterns
- the distribution of scenary (my office, my desk, la tour eiffel)
- and when the first 2 are fixed you have the pattern distribution of your
specific camera.
I could also add the distribution of effect of the software stack and/or
the process variations in the production of cameras which makes it that no
two of them are actually identical.
Basically from all of those complexed distributions I give you one (or 10
or 1000) data points and I ask you "Is it normal ?". I don't know how you
could ever answer yes in a foolproof way.

>
> Now, if it were known that someone like the North Korean military liked
> your design and started to use it ... everything would change.
>
> Things like that have to go into a reasonable risk analysis.
>
> We often remark here that you should rely on proven code from experts, not
> do your own crypto code.  That's true with respect to some kinds of attack
> scenarios, not so simple with respect to others.  If you're a small target,
> making sure that attacks against you are significantly distinct from
> attacks against the big targets is probably not a bad idea.
>
> For example:  Suppose you are suspicious that the NSA has an attack on AES
> - and you're a little guy who doesn't need to have high-speed hardware,
> just software; and you don't need to interoperate with anyone.  Take your
> AES software implementation, run the half the rounds, insert any keyed,
> reversible operation on the state (*using a key completely independent from
> the AES key*), then run the other half of the rounds.  In practical terms,
> no one will ever break that, even if they have some fancy attack on AES
> itself - unless you use it for something worth many billions of dollars.
>

Sorry but I very much dislike those kind of arguments because I think that
it encourages people to actually *use* the half baked crypto they wipped in
their garage.
Also even for the people you are talking about it is counter productive.
1. the cases where you know from the get go that you will never have to
interoperate with anyone are very seldom.
2. Even if you do, and you ve got your  AESbis, you re still a long way
away from a working application level secure communication protocol that
could replace say TLS for your secret organization. The issue is with every
layer you add, the probability of making a huge mistake grows exponetially.
OK you got AESbis but on top of it you need a mode. You use CBC ? Then I
bet you re vulnerable to those padding attacks (vaudenay, lucky13). Have
you thought about the authenticity ? On the protocol level have you
protected about replay, downgrade, cross-protocol attacks ? Do you get PFS
from you algorithms ? How do you do key distribution ?
That s a lot of things to get right for a group of guys.
I seriously believe that the reason we think those half baked algo are safe
is because nobody in the public sector has any incentive to break those...
3. Finally let s assume for a minute that you got 2. right (BIG
assumption). Then how do you communicate over the network ? If you use a
custom protocol you are pretty much sure that you are going to stick out
like crazy in any traffic analysis. If I worked at the NSA/CIA I wouldn t
make sure that I decrypted all the traffic, that s probably too hard. I
would make sure that I at least know how to classify traffic. If I see
something weird and unknown and clearly made not to interoperate I ll make
sure that I ll metadata the hell out lf it to know who is communicating
with whom when and so on. If they re not a group of students in Comp.Sec. I
ll just use one my many exploits to attack directly the endpoints before
the data is encrypted or after it s been decrypted and that whole thing
costed me a lot less than finding the outlier in a sea of TLS traffic.

The lesson for me is : If the starting point of your reasonning is "AES is
broken" then just go home and do something else anything that comes after
that has a 50% chance to be horribly broken and that s already way to high
if you want to protect valuable data.

>
>
>
> --
Alexandre Anzala-Yamajako
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171216/ac71135e/attachment.html>