I need to read serial number of MiFare card usin WinSCard. I am able to read 7B UID from the MiFare card.
The confusion is that i dont know if the UID and the serial number of
MiFare card are same?!!
I have googled the issue but only could get partial success. I found a question on stackoverflow also but it did not help.
I found a document of NXP online which says UID and serial number are different. (on page number 3, line number 5)
There is an application of OmniKey that reads the serial number of the card, and it also returns UID only.
NXP documentation says UID <> Serial Number and a other standard OmniKey application returns UID as Serial Number.
I have started pulling my hair off on the issue. I'd greatly appreciate if anyone could help.
Each smart card contains an integrated chip with a unique permanent identification (UID) number burned-in during the manufacturing process. This UID is often referred to as the Card Serial Number (CSN). The card serial number is not encrypted and any reader that is ISO compliant can read the card serial number.
Edit 1:
Mifare Card Serial Number is the unique identifier defined in ISO 14443-3A. There are 3 types of UID defined in the standard - single (4 bytes), double (7 bytes) and triple (10 bytes). Only in first versions of the Mifare card, the UID was 4 bytes but now have migrated to 7 bytes.
EDIT 2:
It might be helpful to you...
What is the difference between a 4 byte UID and a 4 byte ID?
A 4 byte UID is an identifier which has been assigned by the card
manufacturer using a controlled database. This database ensures that a
single identifier is not used twice. In contradiction, a 4 byte ID is an
identifier which may be assigned to more then one contactless chip over
the production time of a product so that more then one card with the same
identified may be deployed into one particular contactless system.
The differentiation in this case comes from the fact that a "Serial Number" implies that the numbers are a series, thus sequentially assigned.
MIFARE cards have Unique Identification Numbers (or in short UID), which are generated by an internal rule which is not necessarily sequential. This means that if you see a card with UID 01020304050607 it does not mean that there are at least that many cards produced so far.
If you ever see someone referring to the Card Serial Number, they are in fact referring to the UID.
The only last confusion can come from the fact that MIFARE cards can be configured to return Random IDs during activation. If that is the case, you would get different "UID" each time you activate the card. In that scenario you need to read the data contained in Block 0 (for which you will need to know the key to sector 0) to get the real UID of the card.
For DesFire cards:
UID is analogous to ethernet MAC address. It is assigned by the chip
manufacturer from a database. Everyone who creates applications for
the card has access to the UID.
The Card Serial Number is specific
to the application loaded on to the card. It can only be accessed by
that application via an encryption key. If the card had several applications loaded on to
it (unlikely but possible), then each could have a different CSN.
Related
Out of curiosity I was inspecting the official registrar of 16bit UUIDs:
https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf
Is it me or is the number-space reserved for companies running out. What I mean to say is that even though 16bits are enough for 65536 numbers, in the document we see that company-ids start from 0xFCDC (64732) and up.
The greatest company-id seems to be 0xFEFF (=65279 held by 'GN Netcom'. So there seem to be only around 244 IDs left to be bought.
If those 244 IDs are exhausted what will the Bluetooth SIG do? Expand to 32bit or try to recycle 16bit IDs that have already been used by companies which have vanished?
You are mistaken. This list grows downwards and the 16-bit UUID for Members 0xFEFF GN Netcom is the first one that was registered. The latest entry is 0xFCDC Amazon.com Services, LLC, so I assume that there is still plenty of room for the next years. And last but not least, a fee of $3,000 USD is charged for registering a 16-bit UUID.
I am interested in integrating the RFID1356MIFARE with the ESP32-EVB and using it as a card reader over UART. Basically reading UIDs, writing commands to UART serial and granting access or not based on what the reader output is. Initially I've tried using this library: https://github.com/elechouse/PN532 but I found out that the RFID1356MIFARE firmware is not compatible with it.
I would like to understand how does a RFID reader grant access to a card, to open a door for example. Thanks to this thread: Mifare 1K authentication keys I am starting to understand how the two Authentication keys work.
What I still don't get is:
who sets the authentication keys ?
are these keys unique to every card ?
are these keys stored in a reader ?
can I read the keys from a card ? If yes, how ?
are these keys the one that grant access to, say, a door that's linked to the reader ? If not, what makes a card to have access or not ?
are these keys the only form of authentication ?
is the UID used only for identification ?
why are there 16 sectors if all the information is available in the first sector ? What is the purpose of being able to set different keys to each sector ?
The most important question I have is: what makes a card reader give "Access Granted" to a card ?
I've found these docs on Mifare Authentication and they mention Load Authentication Keys and Authentication commands for that specific reader. The reader that I am using has no such commands. Looking at this thread Mifare card security also made me realise that my card reader lacks some commands or that they are just very poorly documented.
I have also read the MIFARE docs from NXP, but there is nothing in there that I actually need.
Ok here is answer for your corresponding queries:
KEY A and KEY B are set by card manufacturer at default value(0xFF...). This can be changed later by user.
By default they are same for every card.
Both keys are stored in Card. Reader also needs to know these keys to be able to read your cards.
No you can't read keys from card unless you at least one of keys. reading of keys can be disabled all together even if you have access to any key.
No these key don't grant access to doors. They are used to grant read/write access to reader on their corresponding sector.
These keys are one of the form of authentication, usually for reader.
UID is almost useless for most authentication cases as any one can read and alter them.
Each sector has 3 data block and a pair of keys on last sector. These keys are needed to read data on first three block of sector.
So on overall, First you create a authentication/ Identification string and store it in data block of any sector(let's say sector 4). Then you need to change KEY A/B of that sector so that no one can read data from that sector except your own access control device. Now only reader that know your specific key can read data on sector 4 thus preventing cloning of card. your reader will read data from sector 4 and use the string you stored to check if that card has access or not.
Hope I've cleared your query. The Mifare classic 1k datasheet has great deal of info about this, Check section 8.7 Memory Access.
I have a Mifare fob and a magic Mifare Classic card. When I fully clone the fob onto the card, the SAK found from the card is 0x88, despite a SAK of 0x08 on the fob.
If I change the sixth byte of block 0 on the card from 0x88 to 0x08, the SAK changes accordingly. However, the fob holds a value of 0x88 at that position whilst reporting a SAK of 0x08. So, what determines the SAK such that two cards with supposedly identical data can report different values for it?
I had the same problem. I had:
An original TAG (mifare 1k)
A chinese TAG (mifare 1k) gen1a with block 0 rewritable.
From the Rfid Research Group documentation we can found this information:
MIFARE Classic block0:
11223344440804006263646566676869
^^^^^^^^ UID
^^ BCC
^^ SAK(*)
^^^^ ATQA
^^^^^^^^^^^^^^^^ Manufacturer data
(*) some cards have a different SAK in their anticollision and in block0: +0x80 in the block0 (e.g. 08->88, 18->98)
so usually the SAK is determined by the bytes #6 of the block 0.
But as specified in the doc, some cards have a different SAK in their anticollision and in block0.
So unfortunately my chinese TAG gen1a was unable to reproduce the same behavior of my original TAG. Also a gen1a TAG accept magic command, which means that a backdoor exist with those tags and you can read or write a block without using the access key, this backdoor is now well known and some reader can detect that.
The solution was to use a gen2 TAG aka CUID card, with block 0 rewritable. This TAG add a 08 SAK, by default, that did not change, even if a rewrite the byte #6 of the block 0.
The SAK byte identifies the manufacturer code and product code.
x08 would be NPX mifare clasic 1k and
x88 would be Infineon mifare clasic 1k
You would need to clarify with your card supplier which one does he sale.
source: http://nfc-tools.org/index.php?title=ISO14443A
I'm sorting out how to achieve the following, I want to use smart or memory cards in a project. The cards should be read by standardized card readers (for example ACR38). When they are read by the computer ( command line or by a software (processing or p5js or similar), there should be a popup a window which shows the contents of the card being a picture and a text. Bit similar when I use my regular ID to be read by my E-idsoftware.
For the moment the card I have is this one SLE4428 (at the bottom instructions from the vendor)
These have no data on it yet and are bought blank
=> datasheet
The software I found but don't know if it's suited for my project and how to specifically use it is the following.
Opensource tools that I found when searching for SC cards software (no id how to use them.)
https://linux.die.net/man/1/opensc-tool
https://linux.die.net/man/1/opensc-explorer
I looked at my smartcard reader and found that http://www.acr38u.com/
is a platform but has to be payed for and I'm unable to found sofware for this on linux or apple.
Again here I found a datasheet with hex code to connect to the card, but still not how to physically connect to the cards.
This site shows many points of a working shell but I can't find the installer for it. opendsc
Then lastly this is the most promising and I already contacted the maker of it. But installation gets stuck in the make process (which I've already searched for and is not solution yet, being at it for a week now so therefore this post, maybe the community can help with an alternative look)
This is the explanation from the vendor side (Aliexpress) which is kind of specific. Though I don't know where to input these hex codes to write or read from the card. (there is a software but it's windows (If there is somebody that can say, that the way to solve the core question of my project then I'll try to get a windows pc to work on it via that way))
ISO7816 SLE 4442 Chip PVC Contact Smart Card (0.8* 85.5 * 54mm)
If you need write the 4442 cards,you should buy the contact smart reader writer!! 4442 cards not support 13.56mhz rfid writer!!!
NOTE:There is NO magnetic strip behind the card.
Graphics Quality Cards For All Photo ID Card Printers Including
DataCard, Zebra, Fargo, Evolis, Magicard, NBS & etc.
(These Cards Will Not Work In Inkjet Printers)
If you need 100pcs 4442 cards,pls check the links below:
[https://www.aliexpress.com/store/product/100-pcs-lot-ISO7816-RFID-Contact-SLE-4442-Chip-PVC-Smart-Card/516120_32425491077.html?spm=2114.12010608.0.0.R0bzFx][1]
Features:
Standard:ISO7816
Product Chip:SLE4442
Color:White
Dimension: L 85.5 x W 54 x H 0.80±0.04mm
256 × 8-bit EEPROM organization
32 × 1-bit organization of protection memory
erase cycles more than 100,000 times
Data retention for minimum of ten years
Default passwords: FFFFFF
3 bytes for error counter and card secret code area
1,Write protected area (first 32 bytes) of each byte can be individually write protected, After write,the data can't be changed.
2, Before checking the password, all the data can be read, if necessary,you could encryption data.
3, After confirm password is correct,the data could be write or modify.
4, The 3 bytes of user passwords, after confirm is correct,it could be change.
5, The password error counter, the initial value of 3, check the error code 1, then subtract 1, if the counter value is 0, the card is automatically locked, the data just read out, no longer change can no longer be password verification; if zero, the one time password verification is correct, restore to the initial value.
6, The byte address 0-5,6-7 factory prior written by the manufacturers can not be changed.
The specifics for this question lies in either
A: How can I achieve a working environment on linux or mac (first) to read and write data on an sc card (the one I have or !B: a working alternative)
C: Create a viewer program or webapp, etc.. to view or route the data to when the SC card is being read. (This would be a valid question, If i where to chose a Windows based existing program, I think)
Because this is not code specific, but I still want people that have the same questions to be able to see this page to show them pletora of scripts and ways to approach this or similar SC project.
This guy knows a lot about OpenSC!
For BLE advertising type LOCAL_NAME_COMPLETE, is there a minimum length requirement?
I could not find any length specification in the spec (other than it needs to fit in the advertising packet of 31 bytes minus anything else already in the advertisement packet), but am running into an issue where it may seem that there is. I wanted to confirm here.
According to the BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] section 12.1:
...The Device Name characteristic value shall be 0 to 248 octets in length. A
device shall have only one instance of the Device Name characteristic.
But since the AD packet is limited to 31 bytes then I guess that if it's too big then one should broadcast the shortened name instead of full name (different AD types)
So it seems like there is no limitations on a minimum size. Hope it helped.