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.
Related
I want to build an app to transfer message history between iOS and Android.
Apple does not allow third party apps to access messages, but Samsung Smart Switch circumvents this by using either phone-to-phone USB connection or by accessing iCloud. Google phone transfer seems to do a similar thing.
How do these apps make this possible and is this something third party developers can do?
I don't think you can transfer things over like that from Android to Apple iPhone unless they give you the option when you are first setting up the iPhone to transfer contents over from android and it also transfers the messages.
Another option though it's been a long time since I have used an Android device. You could use something like https://messages.google.com/web to load up your android messages from your phone and possibly just export them and save them to your computer.
As for developing such a tool, working within the messages API for apple. I think you can only develop extensions or addons but can't directly access the content for security reasons. Without further research, the companies might be only allowing the company to do this via a contract between them, but would not let a 3rd party vendor such as you or I access this data.
https://developer.apple.com/app-store/review/guidelines/
Nowhere in the guidelines does it specify that you can't access the SMSes. But you can only access it if you use private methods which are not allowed and will get your app rejected.
You can only access data for which Apple supplies a documented API. You can not access files outside of the Sandbox of your App unless Apple provides an API for it.
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.
Softwares(such as Mozilla Firefox, Thunderbird) can load opensc module(opensc-pkcs11.so on linux and opensc-pkcs11.dll on windows)and use all smart cards supported by OpenSC for authentication, signing and decryption. My question is how can we do the same thing in android(where to store opensc module, how to access an external token etc.). For example how can an application use opensc module to access a smartcard token with nfc and/or bluetooth interface.
I dont like to flash my android like in seek for android.
I request for any suggestions or examples. Thanks in advance.
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.