Do you have any numbers supporting that for example IPSEC actually would gain by a specific crypto accelerator in contrast to just riding on the general performance improvements in CPUs? I.e. do we have a bottleneck here?
Anyway, for using crypto accelerators in applications like IPSEC, TLS, or DRM existing APIs should transparently make this selection if there is support in the platform for that. At least on the Java part this is simply a config of JCE providers. For OpenSSL this is probably a compile-time #define or a link-time shared library selection. There are presumably tons of similar platform-related settings for other stuff that is variant. Hardware-protected keys is though something different because then we are not necessarily talking about performance, but about security properties. The latter complicates matters quite a bit since there are no standards for signaling that keystores are of a certain strength or so. Since the quality of the key container is mainly an issuer concern (at least for banks, governments, and enterprises), this requires some kind of discovery protocol support as well. None of that is available from anybody; it is in fact not even identified as work-item by most security people. Anders ----- Original Message ----- From: "OK" <[email protected]> To: "Android Security Discussions" <[email protected]> Sent: Friday, June 05, 2009 06:00 Subject: [android-security-discuss] Re: Crypto accelerators. Was: Lack of response from the android team Crypto accelerators have been around for some time and were in several generation of phones. To me the uses are clear and OEMs are using and demanding more throughput. Briefly benefits are CPU offload, lower power, higher throughput. If you imagine higher-bandwidth demanding protected content being played on mobile platforms crypto accelerator usage need is clear (think drm, ipsec etc). Now for an open platform, where different SoC s maybe the underlying engine, I think the challange is to make this usage seemless to the application developers. Different OS crypto frameworks aim to do this but so far it is not clear to me how this can be done without asking the app developer specify the providers. Hoping to see an innovative framework from android but so far security and crypto has not been properly addressed in my opinion On Jun 3, 2:45 am, Chris Rutherford <[email protected]> wrote: > Actually, hardware cryptography devices consume much less power than > software therefore it will help preserve battery life when doing > intensive cryptography operations such as DRM playback. Also battery > life when using WiFi may also be improved. Both of these are obvious > benefits, as well as this the HW could be used for securely managing > keys. > > On Wed, Jun 3, 2009 at 9:34 AM, Anders Rundgren > > <[email protected]> wrote: > > > To begin with we may need to figure out *why* a phone vendor > > would add a crypto accelerator to their phones. Personally I do > > not see that happen because there's no obvious need for it. > > > What phone vendors actually do work with is rather hardware-based > > key storage. Nokia have had such facilities for years but have > > been unable to expose it to end-users due to lack of support > > infrastructure. Android "cupcake" does (AFAICT) still not support > > TLS-client-certificate authentication which makes HW-protected keys > > a no-issue. > > > /anders > > > Chris Palmer wrote: > > >> In the archives, OK asks about hardware crypto accelerators. I'm sure > >> that as soon as someone makes a phone that has one built-in, they'll > >> provide a driver, too. That's what device manufacturers have been > >> doing so far. OpenSSL, at least, has stubs for calling out to such > >> drivers, but I don't know about all the other crypto > >> libraries/implementations in Android. > > >> On Tue, Jun 2, 2009 at 4:50 AM, [email protected] > >> <[email protected]> wrote: > > >>> I think i just saw some tumbleweed. > > >>> On May 12, 8:02 pm, OK <[email protected]> wrote: > > >>>> As the subject implies, why the silence? > >>>> Could not get any response to the questions that I posed
