Secure Element access for Android
Daniel
we want to contribute a SmartCard API into the AOSP in order to
provide an interface for applications to Secure Elements which are
already available in current Android devices like an embedded SE in
the Nexus S, SIM or MicroSD cards in almost any Android device, ...
The API is already available under http://code.google.com/p/seek-for-android
with applications, documentation and discussions for review.
Since the SIMalliance association published an industry-agreed spec
for such an API for mobile devices (Open Mobile API) we see a great
benefit for the AOSP to integrate such.
Use cases:
- Wallet applications in combination with NFC making use of Secure
Elements as a 'secure wallet'
- Keystore(s) on Secure Elements for HTTPS/VPN/SMIME/...
- Authentication tokens like OTP, ...
- Enterprise security requirements
- enhancing the AOSP with access to a secure execution environment
We would like to contribute to the project:
1. ASSD kernel driver
to provide access to MicroSD cards with embedded smart card controller
first to Android kernel, second to the kernel.org according to a
public specification of the SDA (http://www.sdcard.org/developers/tech/
ASSD)
2. SmartCard API core
including framework API extensions together with an SmartcardService
for resource management to enable secure access to MicroSD card(s) and
embedded Secure Elements as seen in the Nexus S
3. Telephony extensions for UICC access
to provide the necessary modifications in the Telephony framework for
SIM or UICC access together with the UICC enhancement of the SmartCard
API
4. Emulator extensions
in order to be able to test and debug Secure Element applications in
the emulator in combination with a locally connected Secure Element
together with a reference implementation how the corresponding RIL/
baseband adoptions should integrated by OEMs
5. (near) future
- CTS test cases for SmartCard API
- STK extensions in order to provide BIP/SCWS support
- Sample applications (e.g. Google OTP Authenticator)
- Access Control Scheme to protect the access to SE applications as
soon as it's standardized
Any comments, hints or remarks to this proposal?
---
Daniel
Dave Sparks
Petr Moravek
it looks reasonable but there are parts like BIP and UICC access that
are not secure store related.
Would then help to have them separated to expedite the review and
acceptance then?
This part is really important and could be seen independent.
What would you suggest?
Petr
Robert H.
meanwhile we've uploaded some patches. You can find them under
following change ids:
1. ASSD kernel driver
I9858031802def78d25597414642f0ab4ac88e2c7
2. SmartCard API core
I30e78f50542fa8df87897806fc015f4447e02a62,
I05469de464a21f20efdc7da892f4ccfcedc4b2b8, and
Ib014d041950494cc1900a7206093f87d7b520d43
I4c15eaf4c80b20f1f1f457e831006f6581508c17
4. Emulator extensions
I1e6e6520ba646411a6451b85a6b94ee0f9ca2812, and
Ic446c4ee476c2bbafb6ac7ae262637ecd4df2dcf
Please keep in mind that most of those patches depend on some of the
others (although the "Dependencies" section is empty, but I couldn't
figure out how to do that). The goal of our work is to have access to
any secure element for any use, not only but also for secure storage.
Don't hesitate to contact us for further coordination.
Regards,
Robert
On May 12, 9:31 pm, Petr Moravek <petr1mora...@gmail.com> wrote:
> Hello Dave,
>
> it looks reasonable but there are parts like BIP and UICC access that
> are not secure store related.
> Would then help to have them separated to expedite the review and
> acceptance then?
>
> This part is really important and could be seen independent.
>
> What would you suggest?
>
> Petr
>
> > There is some internal work being done on crypto/secure store API's. I'll
> > mention the work you are doing to the team that is working on it.
> > There will likely need to be an effort required to reconcile the work you're
> > doing with the internal project before we could accept this contribution.
>
Dave Sparks
Jeff Hamilton
Thank you for the contribution! Splitting it up this way makes it
easier to review and get into the platform.
We're starting to review the code, but there are a few administrative
requests that cover all the patches. First, for code outside external/
we require the copyright to be assigned to "The Android Open Source
Project". For contributions coming from outside Google the convention
is to add a comment immediately following the copyright & license
comment in the form:
/* Contributed by: <company> */
to recognize the source of the contribution in the code. See
https://review.source.android.com/#change,18363 for an example of this
being applied in a previous code review.
Second, it looks like a good amount of the new code does not follow
the Android code style guidelines described at
http://s.android.com/source/code-style.html. The code doesn't have to
be 100% compliant, of course, but we'd like to see the major things
like variable naming conventions, parentheses placement, and 4 space
indention with no hard tabs fixed. Most people working on Android have
their editors setup to format this way and it can make a mess of
patches when editors change those things on you automatically.
Last, we'd like to see the public facing APIs in this contribution put
into a shared library instead of added directly to the framework. The
existing secure element APIs are done this way (see
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=nfc-extras;h=05023071dd91252d33a0d1ccea04a5dd0abf1926;hb=refs/heads/master)
as well. If you'd like more info on how to set this up please let me
know and I can help.
-Jeff