[cryptography] side channel analysis on phones
Kevin W. Wall
kevin.w.wall at gmail.com
Sat Mar 9 14:21:07 EST 2013
Hopefully some more food for thought. However, given that neither
nor side-channels is where my expertise lies, I can't guarantee that such "food"
won't cause undue illness. ;-)
On Sat, Mar 9, 2013 at 5:06 AM, ianG <iang at iang.org> wrote:
>> 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.
For timing / CPU side-channels, why can you just deal with that by adding random
noise to the timing via sleeping a random # of microseconds, inserting
at various places (you can work on calculating the next Mersenne prime
for a short
duration :), etc. I suppose there a lot of ways to add random
consumption of power.
Of course none of those things are very user friendly, but like
everything in security
(and most of engineering), there are trade-offs.
Also, what types of Android permissions are you assuming for this malicious app?
And are you assuming that the Android phone as bee rooted or not? A
rooted device is
probably always go to be an issue because then you have to worry about another
rooted app collecting the side channel leakage and such apps are no longer
confined to just what can be done via the Dalvik sandbox. If that's
part of your
threat model, t's likely that the only countermeasures that you can
that would ironically requiring that your own app run with root privs
as well so that
you can go beyond the Android sandbox to protect things. (E.g., in theory, you
could send a SIGSTOP to all non-system processes to stop all non-essesntial
processes were process was running and then sending all a SIGCONT signal
so they couldn't gather any side channel leakage while your app was running.
Of course, that's apt to be very somewhat non-portable as well, although not
as bad as trying to rely on certain hardware accelerator support.
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents." -- Nathaniel Borenstein
More information about the cryptography