Develop Reference

RND generator on SIM card: is it available outside (for Android for instance)?

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.

UID of a NFC/SWP-accessed SIM card

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.

Android: card emulation - read ndef message with PN532 nfc module

I have an LG D320n Android phone, elechouse's PN532 nfc module and Stollmann's NFCPlayer with which I can read NFC tags properly.
I tested a sample from here: https://github.com/grundid/host-card-emulation-sample
It works fine, when I read one Android device as tag with another Android device as reader. But I can not read the Android device as tag with PN532 reader through NFCPlayer. I want reader to read an NDEF message from the Android device acting as a tag, but NFCPlayer doesn't even recognise the Android device. I think I have to write some modifications on the Android side but I can't figure it out what to do. I think I don't have enough knowlege about how NFC communication and HCE work, even though I read this:
https://developer.android.com/guide/topics/connectivity/nfc/hce.html
I would really appreciate any guideline that could help me understand what am I missing here.

The grundid example app should be discovered by NFCPlayer as a "legacy tag" (tab "R/W: Legacy") as it does not implement the NDEF abstraction layer. On that tab, you can exchange PDUs (APDUs in the case of HCE) with the emulated smartcard. A valid APDU for the example app would be
00 A4 04 00 07 F0010203040506 00
You can send this APDU by typing it into the PDU field and clicking on the "Exch. PDU" button. Note that the grundid HCE app does not even implement ISO/IEC 7816-4 response APDUs. Hence, you may run into troubles with some contactless smartcard readers.
If you want your emulated smartcard to be discoverabe by NFCPlayer as NFC Forum Type 4 tag containing an NDEF message (tab "R/W: NDEF"), you would need to implement the NFC Forum Type 4 Tag Operation specification (as defined by the NFC Forum. This specification defines how data must be stored on an (emulated) ISO/IEC 14443-4 smartcard to be interpreted as NDEF tag. As a starting point you could use this NDEF on HCE example app (though, the quality and reliability of that code is questionable). This example implements the smartcard filesystem for storing NDEF data.

KitKat: How to route APDUs to the SIM

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.

Android NFC communication with Mifare DESFire EV1

Using a Nexus 4 and the latest Android API level 18 to communicate with a Mifare DESFire EV1 AES tag is giving me a headache. Following the NXP native protocol in order to write and read this type of tag, these steps must be followed:
Select application
Authenticate
Write or Read
To do it so, I use Android's IsoDep class which provides access to ISO 14443-4 properties and I/O operations. The very weird thing about it is that once I send the select application native command I get an unexpected response. Imagine I have the AID F4013D so I send:
-> 5AF4013D
<- 6E00
All possible responses must be one byte length (success 0x00 or error_code) and never two or more. Thus, the 0x6E before the success response is absolutely unexpected. It does not happen always, and when it does not and works fine, the select application and authentication processes work fine. However once authenticated the write command does not have a correct behavior, all write commands finishes with a 0xAF from the PICC instead of a success 0x00. It seems like the PICC expect some extra data when it should not (I send the correct length payload). If I send any other command I get a 0xCA (Command Aborted) error code.
-> 5AF4013D
<- 00 /*Success*/
-> AA01
<- AFA8394ED57A5E83106B4EE72FD2BB0CC4
-> AF148F525E1DDE0AD6AB60B4B615552475C91F2E8D89B8523E4465113DD5BD19C6
<- 0066D255C93F2F492AFE3715C88964F1BD /*Authentication success*/
-> 3D02000000030000222222 /*Write 3 bytes to file nº2*/
<- AF /*Unexpected, 0x00 was expected*/
As it is normal, if I send these type of commands with a personal reader (non Android NFC) it always works fine. It seems that something in the Android NFC API is going strange, when it should just be a raw data transporter which never interprets or modifies data.
I have also tried with ISO 7816-4 APDU structure with the same result. As a curiosity, with a Galaxy Nexus does not happen the select application strange response, but yes the write command one always.

(1) For the first part concerning the status code 6E00:
6E 00 is not a "strange byte 0x6E + success status code 0x00". Instead it is a response APDU status word 6E 00 ("Class not supported"). This indicates that there was previous communication with the card using APDU-based access (e.g. Android itself tried to read the card as Type 4 tag and did not reset the connection afterwards). Thus, the card will expect all further communication to be in ISO 7816-4 APDUs. In that case (i.e. if you receive an ISO 7816-4 status code like 6E 00), you could continue using DESFire APDU wrapped commands by simply wrapping your native commands.
EDIT: In fact, this is somewhat expected behavior on an NFC device. The idea is that an NFC device will automatically scan detected tags for NDEF messages. In the case of a DESFire card, the NFC device will detect the card as potential Type 4 tag. Thus the NFC device will send ISO 7816-4 APDUs as it would send to any other Type 4 tag. Hence, if the NFC device doesn't reset the communication with the tag before handing the detected tag to the app, the app can only communicate using ISO 7816-4 APDUs. Note, however, that I would consider it a bug that this happens only for some activations on the same device. In my opinion, the behavior on one specific device model should be consistent.
EDIT: While I would not consider this behavior a bug, it is actually caused by a known bug (#58773) in Android's NFC stack for devices with Broadcom NFC controller. On affected devices, the automatic presence check sends ISO 7816-4 APDUs at timed intervals that cause DESFire cards to switch into ISO 7816-4 APDU mode.
(2) For the second part concerning the (unexpected) response code 0xAF:
Could it be that your file's communication settings are setup for either "plain communication secured by MACing" or "fully enciphered communication"? In that case, simply sending the three data bytes would not be enough. Instead you would need to send either the plain data plus MAC or the padded, CRCed and encyrypted data. Hence the 0xAF indicating that the card expects further data.
EDIT: So to summarize the comments below. After sending further bytes (one byte at a time for each received 0xAF status code: AF FF) it turned out that exactly 8 more bytes were expected by the card. 8 bytes is exactly the size of the CMAC for AES authentication. Thus, the communication settings were set to "plain communication secured by MACing".