SIM card is used as a secure element in my project. It is accessed through NFC-SWP contactless interface from a terminal device.
I need to identify the SIM card somehow with a unique and permanent identifier and I need to be able to read the identifier through NFC. ICCID seems to be the best choice, but I would have to expose the EF ICCID file through the contactless interface, which might be dangerous. Moreover, the EF ICCID file is out of my scope on SIM card - access to my dedicated security domain is all I have.
I also tried to use the 4-byte long UID specified in ISO/IEC 14443 Type A, but I get a different UID each time I read the SIM card through NFC. Why?
Another solution would be accessing the card serial number through Global Platform Get Data command (Card Production Life Cycle Data (CPLC)), but I would have to be able to select the card manager through contactless interface, which is forbidden by default and not recommended because of security.
Is there any typical way to solve this issue?
The 4 byte UID for type A (same for PUPI for type B) is allowed to be random (ISO 14443-3, chap. 6.4.4 "fixed unique number or random number"). Their purpose is only, to select one of several cards currently in the field of the reader. Therefore the description of UID is in the anticollision chapter.
Getting the serial number of the card is surely the solution, but since this allows card tracking (I do not know, who this is, but she was present 10 minutes ago already) in privacy-aware context it is frequently only allowed after some kind of authentication (and possibly establishing a secure channel, so eavesdroppers don't benefit). For ideas, how to handle this, take a look at the ICAO specifications under BAC or EAC. I would not expect to find a privacy-aware solution for a card without being able to place specific information onto it.
Related
Fuzzy question here.
I know that some smart-cards (including SIM cards) can contain random number generator. But I cannot get any information about that. Is it possible to get random numbers outside of SIM card? For instance, I want to create Android App, which asks SIM card somehow (using APDU commands for example) for random number, then app uses it as intended. Is it possible? I mean, is this generator accessible outside? And if so, what the command should be used?
I'll be very grateful for any hints and links.
If you can install a Java Card Applet on the SIM card then you can use the methods of RandomData to retrieve data from the SIM card. Note that normally you will have to use the deprecated methods / constants as a lot of the functions were created specifically for Java Card version 3.0.5. You can use this functionality to create an APDU interface. Usually you would implement the ISO/IEC 7816-4 GET CHALLENGE APDU for this.
You can also cheat a bit if the card supports Global Platform: the GP INITIALIZE UPDATE platform INITIALIZE UPDATE APDU in the end returns a "Card challenge" as part of the response data. That way you can access the RNG, but only for 6 bytes at a time. Worse, the SIM card may think it is under attack and perform counter measures, which in the worst case could destroy your SIM, depending on the implementation.
I want to exchange (or only read) the NFC tag ID from one Android device to another but I don't know if I should use peer-to-peer mode or emulate an NFC tag with HCE.
If I use HCE, is the emulated tag ID unique?
What is the better option or is there a simpler one?
Neither P2P nor HCE will provide you a unique ID, least not on any phone I'm aware of. With P2P it's required that the ID exchanged in ATR is random. With HCE the emulated tag ID is usually set to 08h plus a random number. There may be API call to set but I'm not aware of such. But it makes a lot of sense that a phone can not be uniquely identified by just anyone reading.
How can I read the NFC ID of another Android device?
I assume you are talking about the anti-collision identifier/UID here. On the reading Android device, you can use the reader-mode API to access devices in HCE mode:
nfcAdapter.enableReaderMode(this, new NfcAdapter.ReaderCallback() {
public void onTagDiscovered (Tag tag) {
byte[] uid = tag.getId();
// TODO: do something with the UID ...
}
}, NfcAdapter.FLAG_READER_NFC_A | NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, null);
Is the emulated tag ID unique?
See Stephen's answer. Typically, neither P2P mode nor HCE should provide a unique and stable ID. However, there are some exceptions to this and the point of time when a non-stable ID changes may vary (also see this answer). It could be that:
The device has a secure element and uses the static UID of that secure element.
The device generates a new random UID whenever it is turned on, but continues to use the same UID until it is powered off.
The device generates a new random UID on every activation by an external reader device. I.e. whenever an external HF field is applied to the NFC antenna of the Android device.
Also note that some NFC devices will use randomly generated UIDs that do not start with the random-prefix 0x08.
Can I force a device to use a fixed/stable UID?
Android does not provide an API to influence the UID/anti-collision identifier, so the short answer is no. However, if rooting or creating a custom ROM is an option, there are some possibilities to change the UID and other protocol parameters:
Editing Functionality of Host Card Emulation in Android
Host-based Card Emulation with Fixed Card ID
Should you use the UID to identify (or even authenticate) a device?
No, you should definitely not do this. While you sometimes do not have much choice when you try to integrate a HCE device into some legacy system, you should definitely think about a different design.
First of all, as Stephen already wrote, if an NFC device exposes a fixed/stable identifier, this could possibly introduce a privacy issue as anyone could read and track the ID.
Second, while many systems still use these IDs to authenticate(!) cards, UIDs are not necessarily unique (particularly there are less 4-byte UIDs than cards out there) and UIDs can easily be cloned. See this answer for further details.
I have a simple JavaCard applet installed on my SIM card. I try to communicate with my applet using Omnikey 5121 CL reader and NFC-enabled Sony Xperia L through NFC/SWP (single wire protocol).
The problem is I cannot select the applet - as a status word I get 6999. The LED light is turned on, so I suppose there is some communication between reader and the SIM card. Moreover, I cannot select my security domain either.
However, when I put the SIM card into a standard contact smartcard reader, everything works fine.
Is there any extra configuration of Android OS, SIM card, NFC modem etc. I have to setup before communicating with SIM card over NFC? Any ideas?
More information:
ATR of SIM accessed in the contact way:
3B9F96C00A3FC6A08031E073FE211F65D001900F3B810FE6
ATR (generated by PCSC from ATS) of SIM accessed over NFC in the contactless way:
3B8880010000000000817000F8
My INSTALL for INSTALL APDU: (worked, finally!)
80E6040C32 //CLA INS P1 P2 Lc
0CF0AAAAAAAAAAAAAAAABBBBBB // AIDs
09F0AAAAAAAAAAAAAAAA
09F0AAAAAAAAAAAAAAAA
01
00 //privileges
0B //length of parameters
EF07 //system parameters
A005A5038201FF
C900 //applet parameters
00
Receiving status code 6999 in response to the SELECT (by AID) command is a clear indication that the applet was not found/not selectable. If the applet has been installed and is selectable (using the same AID) over the contact interface of the UICC/SIM card, then it is likely not made selectable over the SWP (contactless) interface. Typically secure elements allow to selectively enable/disable applets for specific interfaces (in addition to this, applets can detect over which interface they are selected and can react accordingly).
Applets typically need to be explicitly made selectable over the contactless interface by setting the Contactless Protocol Parameters in the INSTALL (for MAKE SELECTABLE) command (or later on by doing a registry update). See Amendment C to the Global Platform Card specification for further details.
Btw. the security domain not being selectable over the contactless interface is not unusual for a SIM card. Card management is typically restricted to the contact interface for security reasons. (Card management over the contactless interface is typically not used in production environments anyways.)
I wonder if it's possible to access to the SIM card with an Android Application
You can get the IMEI like this (but is it what you want ?), just an exemple :
mTelephonyMgr = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);
String imei = mTelephonyMgr.getDeviceId();
Likewise, you have
String getSimCountryIso():
Returns the ISO country code equivalent for the SIM provider's country code.
String getSimOperator(): Returns the MCC+MNC (mobile country code + mobile network code) of the provider of the SIM.
String getSimOperatorName(): Returns the Service Provider Name (SPN).
String getSimSerialNumber(): Returns the serial number of the SIM, if applicable.
int getSimState(): Returns a constant indicating the state of the device SIM card.
String getSubscriberId(): Returns the unique subscriber ID, for example, the IMSI for a GSM phone.
For more, take a look at this page
and don't forget to add the correct permission in the manifest (getDeviceId() => Requires Permission: READ_PHONE_STATE)
Without SmartCardAPI from SEEK(Secure Element Evaluation Kit) its never possible. In majority Android phones available in market SmartCardAPI is not implemented. So either you build your own Android after integrating the SmartCardAPI code or wait for some decent phone with this feature to come out. You can find the patch file for implementation here.
SmartCard API for Android might be of interest for you:
http://code.google.com/p/seek-for-android/
SIM card access is only possible for system applications:
Low level access to the SIM card is not available to third-party apps.
The OS handles all communications with the SIM card including access
to personal information (contacts) on the SIM card memory.
Applications also cannot access AT commands, as these are managed
exclusively by the Radio Interface Layer (RIL). The RIL provides no
high level APIs for these commands.
source: https://source.android.com/security/overview/app-security.html#sim-card-access
SEEK is most useful one,but majority Android phones are not support that.So,maybe we can assess SIM card by some other method like read SMS(in SIM card).
You should use IccFileHandler in interal api of android using java reflection .
It is located at framework/base/telephony
I want to route APDUs I get from an NFC Reader to the SIM Card. According to the HCE documentation I thought it would be possible simply by creating an OffHostApduService with the according routing-entries (which I did).
Sadly, the SIM does not seem to get any APDUs. SELECT-Commands that work when the SIM is directly attached to my workstation by a SIM-Reader return with 6a82 (File not found).
In LogCat I found two interesting bits of information:
Every time I shoot a select command which should be routed to the SIM, I get these entries:
01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: event=0x17
01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: NFA_CE_DATA_EVT; h=0x302; data len=12
01-14 10:44:18.501: D/HostEmulationManager(1009): notifyHostEmulationData
I think that this is a clue that the routing is not set correctly, since I think the Android OS should not be aware when the routing to the SIM is active, and a select or another command is sent to the SIM.
Every time I remove the phone from the NFC field of the reader, I receive the following error:
01-14 10:46:48.791: E/BrcmNfcNfa(1009): UICC[0x0] is not activated
I tried to track the cause of this error down and found the file external/libnfc-nci/src/nfa/ce/nfa_ce_act.chere which seems to belong to the Broadcom NFC Driver.
I think that the mistake is that the application cannot set the correct routing for the APDUs since the driver thinks that the SIM is not activated. In the moment I send the commands, the SIM is unlocked (PIN-Entry), but I doubt that this has anything to do with it since I don't have to unlock the SIM before using it in the card reader.
I use a Nexus 5 for testing. Does anybody have experience and / or a working example where the APDUs can be routed to the SIM instead of the CPU?
A quick check (analyzing the signals on the SWP pin of a UICC inserted into the device) revealed that the Nexus 5 is not activating the SIM as an NFC secure element (neither at boot nor when putting the phone on a smartcard reader).
However, I found two interesting files on the device's system partition:
/system/etc/libnfc-brcm-20791b05.conf and
/system/etc/libnfc-brcm.conf.
These two files seem to provide the configuration for the NFC controller (the first one a chip-sepecific configuration and the second one a chip-family specific one?).
After unlocking the bootloader, I was able to modify those files through adb by booting a clockworkmod recovery image, so I did some experimenting with the configuration parameters.
The result is that I managed to let the device activate the UICC (UICC was activated and registered its CE gates through SWP?), the device sometimes even notified the UICC about field status changes. However, with none of my modified configurations, I was able to get the reader to smoothly discover card emulation (this was working before, when only HCE was available on the device) nor to communicate with the UICC.
The interesting parameters in /system/etc/libnfc-brcm.conf seem to be:
NFA_MAX_EE_SUPPORTED: This is currently set to 0. I tried a value of 3, which seems to be the default.
ACTIVE_SE: This is currently set to 0 (no active SE). I tried to uncomment that line to let the device use the first SE detected.
NFA_HCI_STATIC_PIPE_ID_??: Should not be necessary but on out GS4 this is set to 0x71 for ?? = F3 and F4.
UICC_LISTEN_TECH_MASK: This is set to 0x00 on our GS4.
REGISTER_VIRTUAL_SE: I left this as it was (== commented out).
SCREEN_OFF_POWER_STATE: I did not experiment with this, but on our GS4 this is set to 3 (screen-off CE).
The interesting parameters in /system/etc/libnfc-brcm-20791b05.conf seem to be:
NFA_DM_START_UP_CFG: I've tried the commented-out parameters for UICC and I tried to use the configuration from our GS4. The value starts with a length byte and is structured in TLV format (one tag byte, one length byte, parameter data). The relevant tag for UICC activation seems to be C2, where the upper two bits in the second parameter byte disable the SWP interfaces of the NFC controller if set.
NFA_DM_PRE_DISCOVERY_CFG: The comments suggest that this need to be uncommented for UICC support.
It's been a while since I last played with card emulation on Android but AFAIK (I could be wrong), secure element access (internal or inside SIM) has not yet been opened to all developers (without some hacking). There are many non-technical issues regarding SE control which seem not yet solved (who keeps the biggest slice of the cake the Telcos or service providers?).
The news is that Google has taken a different approach with KitKat and its HCE, which basically consists on implementing a NFC card emulation mode without hardware secure element. IMHO this basically breaks the security required for the interesting card emulation mode applications: e-payment, ticketing, authentication, etc. Nexus 5 lacks such secure element and I doubt Google will pander to carriers by easing the access to secure element inside SIM, so I guess it still will not be possible to send APDUs to the SIM with stock firmware.
If you add the following to /etc/libnfc-brcm.conf
DEFAULT_ISODEP_ROUTE=0xF3
the UICC will receive APDUs
You also need all modifications above in libnfc-brcm.conf and libnfc-brcm-20791b05.conf
Up to Jelly Bean 4.3, normal way is to use nfc_extras and its method CardEmulationRoute (<route>, <nfcEe>) to route the UICC to the RF.
But on KITKAT, this brutal modification through DEFAULT_ISODEP_ROUTE is enough to have UICC Card Emulation enabled.