Responding to two at once:
On 8/03/13 16:58 PM, Derek Miller wrote:
Since he's writing an Android client side app, TrustZone is probably not
available to him.
Also, the latest ARM chips are still ARMv7. We wont see any ARMv8 chips
until at least next year. So the AES acceleration instructions are not
available to him.
Many SoC's have hardware crypto accelerators on them (separate from the
CPU) and they may be accessible through the android crypto libraries.
But this doesn't protect him on chips that don't have accelerators.
Those will just use software implementations.
Yes, the app is Java. Although I don't know for sure, I'm expecting
there to be no special hardware access via Android/Java.
Which makes sense to the developer - there are hundreds of phones out
there, and normally the developer has no control over which phone the
product will be used on. There isn't a lot of point in developing for
some special hardware features.
But this makes less sense to the phone manufacturer I suppose. Phone
manufacturers and chip manufacturers seek to get an edge in their
offering, and sometimes this sort of thing does it.
On Mar 8, 2013 5:46 AM, "Ethan Heilman" <eth...@gmail.com
<mailto:eth...@gmail.com>> wrote:
It depends what sort of side channel attacks you are worried about
and what sort of crypt algorithms you are using.
Sure. RSA signing is the algorithm. The side channel is another app
that is also running on the same phone, and has some ability to measure
what else is going on. Although there is sandboxing and so forth in the
Android, I'm expecting this to be weak, and I'm expecting there to be a
way to measure the rough CPU / energy consumption, etc, of other apps.
Enough to determine (for example) the beginning and end of an RSA sig.
My knowledge area is cache based side channel attacks.
1. ARM chips use trustzone which claims it prevents cache based side
channel attacks when running in secure mode but probably amplifies
them (I found this on a set of slides a crypto class a professor had
put up on the web a few years back but have not verified it myself).
2. ARM v8 has the AES instruction set which you should use, some
mobile libraries may not use so check your library.
There is little chance of any crypto libraries in Java accessing the
special instructions. Basically, Java crypto is a bureaucratic mess
that has to be experienced to be believed. I recently posted on this;
in order to resolve the library problems inherent in Android (BC v.
spongy BC v. Cryptix v. Sun...) I rewrote the lot and created an
entirely indigenous crypto suite. It cost me a month, which is very
annoying.
It is possible to link in Java to assembler or C, etc. But again, this
brings in platform dependencies, brittleness in the code, and install
costs. As we're talking hundreds of platforms, we can rule that out.
Also, another factor is that AES isn't so much the risk in this
application. The AES keys are more or less ephemeral, and also tasked
for privacy protection only. All important transactions are separately
signed by RSA. Key exchange is encrypted over RSA. Cracking an AES key
might reveal a day's worth of traffic, but cracking an RSA key will
allow theft. I'm assuming that if someone has an ability to do
side-channel analysis on the phone, they can probably also hack the
on-phone data, so traffic analysis is no longer interesting.
Thanks for all the responses, lots of food for thought.
iang
3. Timers on ARM chips don't have the same resolution as timers on
x86 so cache based attacks are very possible but harder.
Other than using the AES instruction set which should
completely mitigate the risk of cache based side channel attacks
against an AES key I am not sure there is much else you can do.
Noise can always be averaged away.
On Fri, Mar 8, 2013 at 2:57 AM, ianG <i...@iang.org
<mailto:i...@iang.org>> wrote:
Has anyone done any side channel analysis on phones?
I'm working on an android crypto app at the moment, and an
unanswered question from the threat model is how to limit the
possibilities of attacking the keys from another app. I can see
obvious techniques of adding additional camouflage crunching and
delays, but as there might be smart apps sitting right there in
another sandbox, it seems intuitively that just adding noise
isn't going to cut it.
iang
_________________________________________________
cryptography mailing list
cryptography@randombit.net <mailto:cryptography@randombit.net>
http://lists.randombit.net/__mailman/listinfo/cryptography
<http://lists.randombit.net/mailman/listinfo/cryptography>
_______________________________________________
cryptography mailing list
cryptography@randombit.net <mailto:cryptography@randombit.net>
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
