The prime interest of the team at G&D is to make it easier for
application developers to use solid security solutions. And of course,
these applications should also be easy to use for end-users.
Android could be a great platform for that, given its openness.
But even on Android there is a lot to do on this front.
Our first step is to create the simplest solution that connects an
application on Android to the applet on a Secure Element. And we
announced this week the release of a first (alpha?) version of that.
All open source, with minimal documentation.
Yesterday I submitted a post about that to this list with more detail.
Hopefully that post will show up soon.
In short, have a look at
http://code.google.com/p/seek-for-android/
and
http://groups.google.com/group/seek-for-android
You will find there a paper that describes a somewhat longer term
vision, but it covers only a fraction of the security space.
So we believe there is a lot to do for all.
The trick will be work together effectively, covering the issues
without too much overlap.
We haven't discussed keystores and key generation in our team in any
depth, but you might be able to build on our work.
We have no explicit enterprise or consumer focus. If we need to choose
we go for the biggest markets.
I hope that helps to position us a bit.
And lets continue the discussion.
--
Johan
On Nov 5, 1:15 pm, "Anders Rundgren" <[email protected]>
wrote:
> From: "Chevalier Dev"
>
> >This might change things a bit:
> >http://www.infosecurity-magazine.com/view/4997/giesecke-devrient-play...
> >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
