If there is a provably advantage (and reasonable cost) of adding hardware support for a particular feature it will surely happen. Nvidia's TEGRA is such an example.
However, in this case it is not completely clear that there actually is a need since PCs (AFAIK) so far have managed fine without general-purpose crypto acceleration. Based on my G1, improving WiFi seems way more critical since WiFi empties the battery of most phones in just a day or so. However, regarding crypto acceleration in Android, the bouncycastle stuff is already calling selected native-mode OpenSSL methods, which in turn with ease could call hardware if such were available. It is completely transparent. Anders ----- Original Message ----- From: Hadi Nahari To: [email protected] Sent: Friday, June 05, 2009 06:11 Subject: [android-security-discuss] Re: Crypto accelerators. Was: Lack of response from the android team Aggreed with OK and Chris. Talking with chip vendors I know for fact that they're interested in the use cases mentioned in this thread, but they're pet-peeve is that stack vendors won't use it. Classical chicken-egg. We need to ask for these capabilities, and to expose them in easier ways to general developer community. My $0.02 -HRN3811 On Thu, Jun 4, 2009 at 9:00 PM, OK <[email protected]> wrote: 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
