[cryptography] side channel analysis on phones

ianG iang at iang.org
Sat Mar 9 05:06:32 EST 2013

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" <eth3rs at gmail.com
> <mailto:eth3rs at 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 

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.


>     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 <iang at iang.org
>     <mailto:iang at 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 at randombit.net <mailto:cryptography at randombit.net>
>         http://lists.randombit.net/__mailman/listinfo/cryptography
>         <http://lists.randombit.net/mailman/listinfo/cryptography>
>     _______________________________________________
>     cryptography mailing list
>     cryptography at randombit.net <mailto:cryptography at randombit.net>
>     http://lists.randombit.net/mailman/listinfo/cryptography
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

More information about the cryptography mailing list