3

I'm searching for a way to find a unique number for every smart card I work with. I have heard there are IC Fabrication date, IC Serial Number and IC Batch Identifier that are unique for every card.

how can I get these information from my card?

MJay
  • 987
  • 1
  • 13
  • 36
  • 1
    This link can help solve this problem: http://stackoverflow.com/questions/37640130/get-data-apdu-command-different-tags-and-response-format – MJay Sep 21 '16 at 07:56
  • 2
    Check `GET Data` APDU command in GlobalPlatform Card Specification. And take a look at output of `gp.exe -l -v -d -i`. There you can see the related APDU comamnds and their output for retrieving IC Serial Number, IC Fabrication Data and So on. – Ebrahim Ghasemi Sep 21 '16 at 09:53
  • 3
    Why you don't write a simple pair of `setSerialNum` and `getSerialNum()` methods for your own applet to return a unique serial number? Are you worry about simulating your applet's methods? I assure you that the hacker can simulate the card's unique response too. The hacker can write an applet that has AID of your card's SD and make it as default selected and each time you request Security Domain for SN, his/her applet returns the arbitrary value (unless you use a secure channel. In cases of secure channel there is no difference between a secure session for your applet or for Security Domain.) – Ebrahim Ghasemi Sep 21 '16 at 09:54
  • 1
    [This one](http://stackoverflow.com/q/39238382/5128464) might help as well (as long as your cards are "sane" java cards). Good luck! – vlp Sep 21 '16 at 11:15
  • @Abraham thank you for the tips, I used the first one and that was it. Could you please leave an answer to let me thick it as true response? – MJay Sep 23 '16 at 08:20
  • @vlp thanks, thats it. – MJay Sep 23 '16 at 08:22
  • @MJay You're welcome. Kindly, I suggest you to mark dear guidot post as answer. Actually his post answers the question. My comments answer the question "How I can detect my cards uniquely?", not this question. :) – Ebrahim Ghasemi Sep 24 '16 at 12:11
  • @Abraham I suppose you can add an answer for GP cards, or maybe simply add the information to guidots more generic answer for this special case. Note that the question *is* marked [tag:javacard] so assuming GP is not a bad thing and therefore warrants a separate answer. – Maarten Bodewes Sep 27 '16 at 15:47

2 Answers2

3

Surely every hardware supplier integrates information like the mentioned into the chip. This unfortunately leaves the following problems:

  • The information may or may not be made available by the operating system
  • There is little in common between several hardware suppliers beneath the one byte manufacturer ID, which is maintained globally (see e.g. chip manufacturer byte); so x and y coordinates on the wafer may be on different offsets depending on manufacturer and the length of this block may even vary depending on the chip. In any case the hardware reference manual is required.

Summary: If you need an unique information, the specification must have stated this at the very beginning, most likely via a specified instruction to retrieve it. In a multi-supplier environment everything else is likely to fail. The only remaining choice is, to add a sort of ID as user data under your own management.

Appended by Abraham:

As the question is tagged with javacard, we conclude that your card is a GlobalPlatform compatible card.

1: For GP cards, the SD (Security Domain: A mandatory applet that is installed on the card by default) is responsible for returning card specific data including IC Fabrication date, IC Serial Number and IC Batch Identifier, etc. As long as you didn't use a secure channel between the card and the off-card entity, you can't trust the SD response. But why? Because any malicious user can write a simple applet with AID equal to your card SD's AID that returns his/her arbitrary data to your command and install it on a smart card and make it default selected. In this case when he/she put the card on your readers, his applet answers to your off-card application command and you can't detect fake cards.

2: As dear guidot mentioned above, different card may or may not support equal commands to return these card specific data.

So, I suggest you to add a pair of setSerialNumber() and getSerialNumber() methods to your applet and implement a secure channel between your offcard and your applet to be sure about uniqueness of your cards.

Ebrahim Ghasemi
  • 5,850
  • 10
  • 52
  • 113
guidot
  • 5,095
  • 2
  • 25
  • 37
1

For most usecases the PC/SC UID should be sufficient. This is a 4 to 7 byte identifier that is read anyway when building the contactless communication with the card. Although some cards may be configured to return random UIDs, however this is not a problem if you have the cards for your project under control

Paul Bastian
  • 2,597
  • 11
  • 26
  • 4
    This *UID* is intended to solve just the selection of the correct card, when several are in the field of the reader at the same time (so it addresses a low level protocol issue). Given, that the original question neither mentions contactless, nor is tagged accordingly and finally due the intrinsic weakness (probability instead of uniqueness) leads to my downvote. – guidot Sep 21 '16 at 19:20
  • I don't really get your point. Answers are suggestions and I explicitly bolted the **contactless** part and explained the entropy strength of the PC/SC UID. His questions even asdks for "unique smartcard ID" which is just pretty much the translation of the PC/SC UID. The answer is by no means wrong and a suggestion with the stated circumstances. Disagree with you.. – Paul Bastian Sep 22 '16 at 09:29
  • And by the way things can be intended to certain things and it is just very common they get used in other ways as well. I know lots of use cases like printers that simply rely on PC/SC UID to identify users... – Paul Bastian Sep 22 '16 at 09:31
  • 1
    I've upvoted since a non random UID can certainly be used for this kind of purpose, but I've also voted up guidot's comment... this is a severely limited option, but an option none-the-less. – Maarten Bodewes Sep 27 '16 at 15:45