1

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?

vojta
  • 5,591
  • 2
  • 24
  • 64
  • 1
    _I get a different UID each time I read the SIM card through NFC. Why?_ I think the last three comments under Mr Bodewes's asnwer [here](http://stackoverflow.com/questions/13051167/apdu-command-to-get-smart-card-uid#comment47633707_13052719), have something for you. – Ebrahim Ghasemi Jun 01 '15 at 06:36
  • 1
    Again, as mentioned [here](http://stackoverflow.com/questions/4497671/contact-less-card-through-an-omnikey-how-to-get-uid), UID typically has 16 byte length. – Ebrahim Ghasemi Jun 01 '15 at 06:37
  • 1
    @Abraham: You are talking abot the card serial number, not about the 14443 UID for type A, which may be 4, 7 or 10 bytes long. – guidot Jun 01 '15 at 06:51
  • Ah, Sorry, you are right. I just checked the 14443-3 and I saw this lines under Table-9 : _The UID is a fixed unique number **or a random number** which is dynamically generated by the PICC. The first byte (uid0) of the UID assigns the content of the following bytes of the UID._ – Ebrahim Ghasemi Jun 01 '15 at 07:01
  • 1
    Is there anything that prevents you from issuing an application specific unique identifier that's personalized into your applet/application? – Michael Roland Jun 01 '15 at 15:26
  • @MichaelRoland I need to reinstall my applet "on the fly" in the phone. This reinstallation is not atomic (of course, because it consists of many GP APDUs), it can fail in the situation when the applet is gone (uninstalled but not installed again). In that case I still need to identify SIM somehow to be able to fix the situation and install the correct applet with correct data again. However, you might be right, I could create a special persistent applet just to store my identifier. Thanks! – vojta Jun 02 '15 at 21:13

1 Answers1

2

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.

guidot
  • 5,095
  • 2
  • 25
  • 37