Re: [cryptography] side channel analysis on phones

[ianG]

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" 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 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 
http://lists.randombit.net/__mailman/listinfo/cryptography




___
cryptography mailing list
cryptography@randombit.net 
http://lists.randombit.net/mailman/listinf

Re: [cryptography] side channel analysis on phones

[Thierry Moreau]

ianG wrote:


[...], I'm expecting 
there to be no special hardware access via Android/Java.


[...] 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.




Yet there is one such point: side-channel attack countermeasures.



Has anyone done any side channel analysis on phones?



Aren't side channel attacks hardware-specific, almost by definition?

If so, this original post postulates an impossible problem statement: 
hardware abstraction can not assist countermeasures for 
hardware-specific threats.



[...] how to limit the
possibilities of attacking the keys from another app.



OK, now you insert O/S abstraction and O/S-specific threats.

Regards,


--
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] side channel analysis on phones

[Wyss, Felix]

> -Original Message-
> From: cryptography [mailto:cryptography-boun...@randombit.net] On Behalf
> Of ianG
> Sent: Saturday, March 09, 2013 05:07
> To: cryptography@randombit.net
> Subject: Re: [cryptography] side channel analysis on phones
> 
> 
> 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.
> 

How frequently will your application perform the RSA signing operation in 
practical use?  I presume you'd want to minimize that at least for resource 
usage anyway.  So unless an adversary is able to force you to perform it much 
more frequently, it seems that a side-channel attack on the device is not very 
practical as it would require timing measurements for a very long time.  The 
longer this would take, the more other noise the adversary will have to deal 
with, such as the mix of installed and running applications changing, OS 
updates, etc.  It thus seems an attack on other aspects of your application 
would be higher on the list for an adversary.  For example, how do you manage 
the signing keys?  

--Felix
 


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] side channel analysis on phones

[Tanja Lange]

Dear Ian,
> Has anyone done any side channel analysis on phones?
> 
On the constructive side you might want to check out NaCl for ARM (best
with NEON), e.g.
 http://cryptojedi.org/crypto/#neoncrypto
which avoids all software side channel attacks. Not sure how you would
avoid cache attacks in Java.

Cryptographic Research has a demo attacking cell phones running slow
crypto (Java) by electromagnetic radiatiion, see
http://www.youtube.com/watch?v=4L8rnYhnLt8

Attacking fast (good) implementations is a lot harder but wee're looking 
into it. 

All the best
Tanja
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] side channel analysis on phones

[Kevin W. Wall]

Ian,

Hopefully some more food for thought.  However, given that neither
Android development
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  wrote:
>> On Mar 8, 2013 5:46 AM, "Ethan Heilman" > > 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
various spin-loops
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
apply against
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.

-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"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
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Jeffrey Walton]

Hi All,

For those interested, it appears Javascript is getting cryptography.
The Web Cryptography Working Group looks well organized, provides a
very good roadmap, and offers good documentation.
http://www.w3.org/2012/webcrypto/.

There is a list of use cases at
http://www.w3.org/TR/WebCryptoAPI/#use-cases. I believe there are some
missing use cases, and those missing use cases could identify gaps in
the API. If anyone has feedback from a security architecture point
view, I think it would be appreciated.

There are also a few open issues that could probably benefit from
comments by experienced crypto gurus.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Tony Arcieri]

On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  wrote:

> The Web Cryptography Working Group looks well organized, provides a
> very good roadmap, and offers good documentation.
> http://www.w3.org/2012/webcrypto/.


I have a blog post about it forthcoming, but I'd like to share the tl;dr
version here:

The normative parts of the specification seem mostly fine.

The specification provides no normative advice about what algorithms to
use, and worse, provides a non-normative listing of algorithms which are
not authenticated encryption modes (for symmetric ciphers, the only mode
listed in the spec is AES-GCM)

At the very least, I'd like to see the non-normative examples section
expanded to include a lot more authenticated encryption modes (EAX mode
comes to mind, and seeing support for NaCl algorithms like crypto_box and
crypto_secretbox would be super). Right now they give some rather poor
recommendations, for example they recommend CBC mode which is fraught with
problems.

Finally, it'd be great to see someone like NIST or ECRYPT provide browser
vendors with normative advice on algorithms to standardize on. The existing
WebCrypto spec leaves browser vendors to their own devices, and in that
eventuality, the browser venders will probably wind up implementing the W3C
spec's (poorly chosen) non-normative recommendations.

For an in-depth look at the problems, I'd recommend checking out Matt
Green's blog post:

http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)

[Ryan Sleevi]

On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote:
>  On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton  wrote:
>
> > The Web Cryptography Working Group looks well organized, provides a
> > very good roadmap, and offers good documentation.
> > http://www.w3.org/2012/webcrypto/.
>
>
>  I have a blog post about it forthcoming, but I'd like to share the tl;dr
>  version here:
>
>  The normative parts of the specification seem mostly fine.
>
>  The specification provides no normative advice about what algorithms to
>  use, and worse, provides a non-normative listing of algorithms which are
>  not authenticated encryption modes (for symmetric ciphers, the only mode
>  listed in the spec is AES-GCM)

That is correct. This is not a "How to use cryptography" spec. This is an
API.

This is not an evangelical API. I realize the crypto clergymen may not
like this, but APIs that proselytize do not somehow educate more.  They
merely get in the way of people who know what they're doing, and the
people who don't know what they're doing will find plenty of other ways to
screw up (eg: XSS, XSRF, insecure cookies, clickjacking, framing, etc).
Plus, it only takes one Stack Overflow question & answer, or one bad
W3CSchools post (redundant much?), to undermine whatever message was
intended for those crypto black sheep.


>
>  At the very least, I'd like to see the non-normative examples section
>  expanded to include a lot more authenticated encryption modes (EAX mode
>  comes to mind, and seeing support for NaCl algorithms like crypto_box and
>  crypto_secretbox would be super). Right now they give some rather poor
>  recommendations, for example they recommend CBC mode which is fraught with
>  problems.

What use case makes the "NaCl" algorithms (whose specification is merely
'use NaCl', which boils down to "Use Salsa+Curve25519") worthwhile? If you
don't trust developers to be able to use the API correctly, what makes you
think that they can sufficiently understand the security guarantees that
NaCl does - and *doesn't* - provide. And how can we be sure that the
problems that NaCl sets out to solve are the same problems developers want
or need to solve, especially when all the evidence suggests otherwise?

Arguably, the answer for whatever use case you imagine NaCl meeting can
almost certainly be met through JOSE, if and when it ever gets its act
together. If you want something high level, use something designed to be
interoperable (and hopefully, JOSE will actually use JSON by then). As
much respect as I have for DJB, Sodium's existence is proof positive of
what NaCl does and doesn't set out to do.

Finally, the recommendations are for what implementations should support.
There is not any mandatory to implement suite at this point. Instead, it's
looking at what are the algorithms in vast, sweeping use today in a number
of protocols and applications, and that developers will expect or need
supported to implement a variety of applications *that already exist
today*.

>
>  Finally, it'd be great to see someone like NIST or ECRYPT provide browser
>  vendors with normative advice on algorithms to standardize on. The
>  existing
>  WebCrypto spec leaves browser vendors to their own devices, and in that
>  eventuality, the browser venders will probably wind up implementing the
>  W3C
>  spec's (poorly chosen) non-normative recommendations.

NIST or ECRYPT? Why not KISA or GOST? After all, everyone loves SEED and
GOST 28147-89...

The answer is that the choice of algorithms were motivated by two factors:
1) As stated in the charter, exposing (some of) the cryptographic services
already inherent in browser applications today. [In order to provide
constant time, correct, validated implementations of the algorithms -
things impossible in JS today]

2) The choice of algorithms that are meaningful to web application
developers - which includes the W3C SysApps WG - which has an *entirely*
different security model than the drive by web. Support for "legacy"
algorithms in order to support those "esoteric" protocols like SSH, PGP,
or S/MIME (or would you rather your browser bake them in? *shudder*), as
well as the choice of algorithms that are suitable for future work (and,
notably, being explored in JOSE)

>
>  For an in-depth look at the problems, I'd recommend checking out Matt
>  Green's blog post:
>
>  http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html

Matt's post, besides being entertaining and certainly with some
meritorious points, basically sums up as "No backwards compatibility, and
only give people what the priesthood accept." Respectfully, that doesn't
lead to more secure code, nor does it lead to what smart people - people
who know what they're doing - *actually* want or need (as done through
repeated surveys from participants and non-participants of the WG).

While I can understand that, on a list such as this, people are well
trained to turn their noses upwards at "bad" cryptography, this is not
going