From: "Chevalier Dev" >This might change things a bit: >http://www.infosecurity-magazine.com/view/4997/giesecke-devrient-play-secure-android-card/ >Executive summary: G&D is offering support for a secure element inside Android.
>This might be a good opportunity to gather everybody around a single >keystore, and from there expand key management to all applications in >need of it: encrypted e-mail and mass storage, VPN, WiFi, etc. Step by >step we would end up with an enterprise-level Android. It is nice to see that somebody is actually doing something in this space! Since I work with this both as a technologist (looking forward....) and as a developer shipping somewhat more down-to-earth solutions (...), I'm definitely interested. IMO, the goal (of any such endeavor) should be to make it a de-facto standard. To do that the entire scheme including the SE must be published. That a card is based on GlobalPlatform or 7816 etc. have in practice not returned any realizable interoperability and upgrading phones is much more difficult than PCs with Windows. Now to the applications. SEEK seems to be oriented towards enterprises. VPNs using IPSEC or SSL ought to be the killer apps because it applies to the entire spectrum of interconnected services. My personal take on this is that Google should (as the consumer-company they are), put more efforts in consumer solutions, which if properly designed, should be quite useful for enterprises as well. What's the problem here? Basically it is that consumers means browsers and the web. Unfortunately Google and the Android team appear unaware of the fact that Netscape's 13-year old relic known as <keygen> simply has nothing to offer smart card solutions like SEEK. OTOH, I'm not completely convinced that SEEK actually matches consumer needs either because the GlobalPlatform consortium haven't AFAICT spilt much energy on *open* on-line provisioning which is the most likely consumer method for authentication keys. The following is a scheme in early stages that tries to clone SEEK with consumer needs: http://webpki.org/papers/keygen2/secure-key-store.pdf Although the details of SEEK are sketchy I *assume* that the main differences between SKS and SEEK are that the former : - Supports air-tight key-provisioning and key-management - Is heavy tied to a protocol called KeyGen2 - Reserves some of the FLASH memory for storing certificates giving room for hundreds of keys including Microsoft InformationCards - Does not support Java, 7816, or PKCS #15, only a cryptographic API Regards Anders Rundgren
