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
Related
I made an app that discovers Bluetooth devices around me, and I'm looking into the datas I get about them. Now I'm trying to figure out the datas from BluetoothDevice.getBluetoothClass (CoD, Class of Device).
So far I've found these class codes around me:
43c
50c
704
1f00
c043c
c243c
8043c
60680
200408
240414
5a020c
About half of these I found some information for (http://domoticx.com/bluetooth-class-of-device-lijst-cod/). The rest of the codes I haven't been able to find anywhere (50c, c043c, c243c, 60680).
Does anyone know any overview with all of these codes (or at least the ones I haven't figured out)?
You can decode the Bluetooth Class of Device (CoD) yourself by first converting the above hex number to binary (for example using this link) and then checking the document below to try and find what the combination of the bits mean:-
https://www.ampedrftech.com/datasheets/cod_definition.pdf
As an example, 0x50c is 010100001100 in binary. Using the table in the document above, bits 8 to 12 indicate that the device is a peripheral:
And then bits 2 to 5 indicate that the device is a remote control
I am using IBM TPM v1332 + IBM TSS v1470 now and trying to store some essential keywords/passwords to non-volatile memory on TPM.
I found two ways to do so. One is to create a sealed object and use evictcontrol to store it, like:
${PREFIX}evictcontrol -ho $objHandle -hp 81800002 -hi p
Another way is using NV command directly to store something:
${PREFIX}nvdefinespace -hi o -ha 01000000 -pwdn nnn
${PREFIX}nvwrite -ha 01000000 -pwdn nnn
However, I couldn't find any information about the non-volatile spaces available in TPM. Is this described in the TPM spec? Where could I find the information? Thanks.
The TPM PC platform specification says:
"1.The TPM SHALL provide a minimum of 6962 (dec) bytes of NV Storage."
If you use evictcontrol you should note that the TPM allows only a small number of persitstent objects at the same time (at least 7, of which 4 are reserved).
You can get the number of available persistent slots using the TPM2_GetCapability command with TPM_CAP_TPM_PROPERTIES as capability. TPM_PT_HR_PERSISTENT_AVAIL will be at least 1 if you can store another object.
The amount of available NV memory is device dependant, you have to check the data sheets. I suggest to work with the numbers from the PC platform specification, they are valid for every device.
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.
I've started to work with the JavaCards and trying to grasp the sense of CLA byte.
If to read RFC 5.4.1 Class byte
5.4.1 Class byte
According to table 8 used in conjunction with table 9, the class byte
CLA of a command is used to indicate to what extent the command and the response comply with this part of ISO/IEC 7816 and when applicable (see table 9), the format of secure messaging and the logical channel number.
So... CLA flag is used for the indication, but what exact? Because, the table and description as for the beginner is rather difficult, I understand that usually are used the next CLA bytes: 0x00, 0x80, 0x84.
For e.g. if to read the content from table:
0X' Structure and coding of command and response according to this part of ISO/IEC 7816 (for coding of 'X' see table 9)
10 to 7F RFU
Reserved for PTS
I understand that for the fine developing - I should read GlobalPlatform specification, the specification about the exact card (mine is NXP one) and other related materials, but I want to admit, that it's difficult to understand the content.
I've expected the following (pseudo-table):
0x00 -> for reading streams from file system
0x01 -> for writing byte buffer to memory blocks
0x02 -> call AES/RSA methods
The CLASS byte is defined in ISO 7816-4. The first bit indicates the interindustry class. Java Card applets shall operate in this interindustry standard. Global Platform is another specification to manage and maintain the card and all commands will have class byte 0x80 - 0x8F. Class byte 0xFF is used for communication with the card reader in some cases and is otherwise invalid for a card.
The interindustry meaning for the CLA serves 3 major functions:
Function 1: Chaining
bit5 = 1 signalizes that the current command is not the last command of a chain, meaning that multiple APDUs all belong together and the card may therefore do additional things
Function 2: Secure Messaging
bit4+3 serve to signalize the secure messaging status of the current command. This means that the APDU is authenticated(e.g. MACed) and the data is encrypted(e.g. block cipher). The command header is never encrypted.
Function 3: Logical Channel
bit2+1 serve to identify the logical channel number. Logical channels are parallel communication interfaces through the card, therefore an applet A can be selected on Channel 0 and an applet B can be selected on Channel 1 while both applets remain in their internal state(no RAM is reset). Most cards do not support logical channels or you have to enable them explicitly.
CLA byte is a typical trap for Java Card beginners and its usually best that you leave at 0x00 for the start.
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.