The new Android Pixel 3 contains a secure element called Titan M.
First, I am wondering if it is possible to interact with this secure element by using the Open Mobile API (package android.se.omapi) now available on Android 9.
Secondly, I looked at this OMAPI and found that it allows to send APDU messages to applications using ISO 7816 protocol for smart cards. So I would like to know what kind of applications I can interact with.
If it is possible, my aim would be to insert a JavaCard applet into the Titan M secure element and to use OMAPI to send APDU to this applet. Has anybody tried to do that ? I would be happy to get any feedback on what it is possible to do with this API and Pixel 3.
Thanks.
Franck
First, I am wondering if it is possible to interact with this secure element by using the Open Mobile API (package android.se.omapi) now available on Android 9.
At first glance and doing some limited research (mainly because there is limited information available) it doesn't look like this would be the case. That API is mainly intended for SIM cards, and I sincerely doubt with a high level of confidence that a SIM API or functionality is present in the Titan M System-on-a-Chip (with ARM SC300 core, in all likelihood).
Secondly, I looked at this OMAPI and found that it allows to send APDU messages to applications using ISO 7816 protocol for smart cards. So I would like to know what kind of applications I can interact with.
SIM cards and embedded Secure Elements that support an APDU interface on devices that support OMAPI. However, although I would say that Titan M is an embedded Secure element, I would wage that it doesn't use OMAPI and because of that, it won't be available through the API. Actually, I would be surprised if it uses APDU's at all. ISO/IEC 7816-4 is a pain that you can do without if you're able to specify the transport layer yourself.
If it is possible, my aim would be to insert a JavaCard applet into the Titan M secure element and to use OMAPI to send APDU to this applet. Has anybody tried to do that ? I would be happy to get any feedback on what it is possible to do with this API and Pixel 3.
I would find it entirely unlikely that Google is willing to pay license costs to Oracle to be able to implement Java Card. I certainly don't see Google listed in the JCF, which you would expect if you would implement a native Java Card solution yourself.
Finally, there have been many posts that said that the Titan M "firmware" would be released as Open Source by Google. However, that promise never materialized. Note that it is extremely tricky to release such code for secure processors. If a security issue is found that requires a software fix then that fix might have to be applied all over the place, and details of the fix may help adversaries.
So, all said, you will have to do with the high level interfaces that Android offers - as far as I am able to find out.
Related
Are there javax.smartcardio analogues on Android?
but not using Open Mobile API.
Thanks!
I'm using javax.smartcardio.* as a facade to IsoDep on Android in a project called SCUBA. Note that this is for trancieving APDUs to ISO14443 cards in the field of the NFC chip (in NFC capable Android phones), and not for communicating with SIM or SE.
(Main motivation was to be able to use the same JMRTD ePassport reading API jar both on J2SE and Android without changes.)
EDIT: If you're interested in communicating with a card in an external reader, have a look at this SCDroid project. Also ACS appears to have Android support for their ACR122U reader.
You can check out the com.android.nfc_extras packages in the AOSP tree. This will allow you to send APDU's to a secure element. It will also allow you to enable card emulation. This will only work on a rooted phone or an AOSP build. You wont be able to install anything on the secure element as you won't have access to the keys (unless you have a engineering sample with a different secure element). NFC extras is a private API so you may not be able to use it on a non-rooted phone.
I'm looking to get access to get low level network information on an android device that isn't available through the api. Is there a way to talk to the RIL to get more information?
Yes. I'm actually messing around that same thing. My hardware uses GSM radio and everything turns around the android internal API. (do a stackoverflow search with "[android] internal API" and you will get tons of info on how to access it). In my case, I'm interested in the data link over the GSM. So, it's in android source code in frameworks/base/telephony/java/com/android/internal/telephony/DataConnectionTracker.java. If you are interested in other features like SMS, SIM cards, voice call or anything that is not available on the standard "public" API, look in the folders frameworks/base/telephony/java/com/android/internal/telephony and the names are pretty relevant to what it does. As for a clear documentation, I did not find it. I think it's not publish since it is not recommended to use the internal APIs because it could change without notice and there is no guaranty an internal API will not change in the next Android version.
I am developing an android application and I want to store my data securely.
There are two way for that
Storing Sim card
Mobile security card
I want to use second one but I don't want to buy this card before I make sure it is useful for me.
I am running Google's SmartcardSample(svn) application.
But I get an error like this.
See this answer for using the SIM as Secure Element https://stackoverflow.com/a/9364030/156477 (Its not scalable solution at present).
This isn't Google's code, and the SEEK API isn't part of Android (out of the box). Have a look at http://code.google.com/p/seek-for-android/wiki/SmartcardAPI. You'll see at the bottom you need to rebuild your own version of the Android OS, and flash it to your device.
I notice you haven't tagged the question with NFC. I wonder, do you really need SmartCard support or do you just need to store data securely? The typical SmartCard use case is to use the phone for payment, or building access - know as NFC Card Emulation mode.
The reason that this question was born is that I am totally lost, so please forgive the trivial and senseless parts.
I have an Android app, a web-service, a MicroSD smart card (mobile security card). I need to know how can I use the card with ssl to securely communicate with the web-service. Rebuilding and flashing the OS is not an option.
What I know:
The API used to communicate with the MSC
How to write/deploy applets to the MSC
How to call a web-service
What I don't know:
SSL
Too much about certificates and cryptography (only shady academic stuff from the university)
How things come together and what should I use to accomplish this
seek-for-android has an OpenSC tutorial and library, but the OS needs to be patched for that. Is there a way to avoid that and still use the solution?
I know I could be much further into this with a little research, but my deadline is quite close (a few days), so I need help, much help, and very soon.. Thank you in advance!
EDIT:
More specifically:
I have a Smart Card SD card from Giesecke & Devrient, with Java Card OS and fine applets and dev tools. I also recieved an android service to communicate with the card (the applets) with APDUs. This is quite low-level, it acceps byte codes as commands and data.
I need to call a web-service via SSL authentication. Now I know that SSL uses (can use) hardware tokens with PKCS#11 interfaces.
There is a project called seek-for-android with a guide to patch the OS and have a standard PKCS#11 interface over the smart card (I believe this would be OpenSC). I CAN'T patch the OS.
So the questions again:
Can the Android SSL implementation use (custom) PKCS#11 interfaces in some way, if yes, how? (e.g. possibly with some security providers)
Can I use OpenSC (and other stuff mentioned in the linked guide) without patching the OS (e.g. extract the libs and include it in my application)?
Overall, how should I link the gap between the low-level smart card and the high level SSL? I kindly ask you for any material regarding this.
As this is a special form of a Smart-Card encapsulated inside a microSD-card I assume that the API bases on special SD-Card read and write operations. Such operation may or may not be usable on Android without root access.
That depends on the certain implementation of the API. Usually such a microSD card already comes with Android libraries (as it is the most open relevant mobile platform) from the vendor. You should ask there for getting more information.
Use Bouncycastle (Spongycastle is the fork for Android) and implement your own Security Provider which uses the SmartCard instead of a file for stored certificates.
If you can access your card without patching the ROM, you can roll your own (requires knowledge of cryptography) SSL implementation on top of it.
If not, then AFAIK you need to patch Android to get access to the extra hardware. And the built-in SSL library has no support whatsoever for client-side "hardware tokens" AFAIK.
All smartcards have embedded crypto capabilities and computation power.
Is is possible to take advantage of this with developed android application? For example, would I be able to sign a file using the public/private key stored on the SIM.
I heard about some standards and norms and initiatives (ETSI-MSS, Mobile PKI) but I do not see any application of such architecture.
Do someone has some clue on this?
No, you cannot access the SIM card directly in Android. All access to telephony-related services takes place in the TelephonyManager API and there is no API exposed to doing and cryptographic operations in the SIM.
My understanding is that SIM cards do not use standard crypto. The handle certains kinds of authentication and crypto for the network. Given the quality of say A3/5, I'm not sure you would want to. I doubt you can get AES or reven basic RSA out of them
Actually the above statement is somewhat incorrect: apparently there is work either to get SIM cards to have this functionality or to write generic libraries for exposing it. I cannot,however, for the life of me remember the article I read this in.
This appears at least to be a starting point https://stackoverflow.com/a/9364030/980922