I'm using ACR1222L NFC smartcard reader with Mifare Plus cards (Security Level 0 as of now; manufacturer default keys A and B). I tried a variety of commands to load authentication key into the reader:
FF 82 00 00 06 FF FF FF FF FF FF
FF 82 00 01 06 FF FF FF FF FF FF
FF 82 20 00 06 FF FF FF FF FF FF
FF 82 00 00 06 A0 A1 A2 A3 A4 A5
FF 82 00 00 06 D3 F7 D3 F7 D3 F7
... and others ...
All of them are returning the error status:
63 00 (Operation Failed)
What could be wrong? I have searched long and wide for a hint, but many other questions are about failed authentication or failed read after successfully loading authentication key with one of the above commands, and they are often based on a different device (ACR122U).
I noticed that the reader does not even respond to the command when a card is not present. Should a card be present on the reader for it to load authentication key?
To be able to use the commands such as "Load Authentication Key", "Authentication (of a block)", Read, Write, Update, etc, the card has to be in Security Level 1 or higher.
There are certain commands to move the card from Security Level 0 to Security Level 1 by loading several relevant keys into the card. Please contact ACS to obtain these commands as they are not publicly documented.
(Additional Info)
Please try command-
0xFF 0x82 0x00 0x60 [key length] [ key value]
or
0xFF 0x82 0x00 0x61 [key length] [ key value]
Where 0x60 to use key Type A and 0x61 for key Type B.
Related
When inserting an UICC in an iPhone SE2 and recording the APDU messages between the modem and the UICC I see a sequence opening a logical channel and trying to select an application. I could not find any reference to this application. What is it?
01 a4 04 0c 10 a0 00 00 00 09 02 03 ff ff ff ff 89 01 00 00 ff
The RID a0 00 00 00 09 is registered for the ETSI.
I have a clean Kona112 Javacard and I'm going to a put a Receipt key into it and then I want to delete it from the card or replace its value.
Step 1: I tried to create a new key on the card with Key Version == 0x71 (Quoted from GP UICC Configuration v1.0.1: "Key Version number '71' with Key Identifier '01' is reserved for the Receipt Key, which is a DES key"):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 B5 75 C3 8D 89 DC F9 B1 74 CC 1E 93 C4 45 C8 2C 03 CD 80 0F EC EA 8D 6F 8F BF 7D D0 // PUT KEY
<-- 6A 80
==> Quoted from GP UICC Configuration v1.0.1: "6A80 = ISO compliant standard status word for Algorithm not supported"
Step 2: As I received "Algorithm not supported" error, I enabled Delegated Management on my card and retried step #1:
[Select ISD]
[Successful Mutual Authentication]
[Proprietary APDU command to enable Delegated Management]
--> 84 D8 00 01 1F 71 80 10 1A F6 96 45 2A ED 66 86 75 DF FC 8B 59 55 6D 0B 03 CD 80 0F 87 03 E4 1A 8D AB 90 EC
<-- 71 CD 80 0F 90 00
Good! I successfully put the Receipt key in the card.
Step 3: Now, I want to delete it:
[Select ISD]
[Successful Mutual Authentication]
--> 80 E4 00 00 06 D0 01 01 D2 01 71 // Delete APDU Command to delete a key with Key ID = 01 and Key Version = 71
<-- 6A 80
As you see above, I received 6A 80 error status words. It is mentioned in the answer of my other question (and also in GP UICC Configuration v1.0.1) that the Key Deletion feature is optional.
So in step #4 I tried to replace the key with another value.
Step 4: I changed P1 in PUT Key APDU command from 0x00 (create key) to 0x71 (overwrite):
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 71 01 1F 71 80 10 E9 06 6B 8E D8 05 50 34 D5 A7 71 3B 81 CB BE 7A 03 CD 80 0F 91 0D BC E9 96 25 7E 89
<-- 6A 88
==> Quoted from GP UICC Configuration v1.0.1: "6A88 = Referenced data not found"
Well, that's weird, I received "Referenced data not found". So I tried the PUT Key command with P1 = 0X00 (Create Key) again:
[Select ISD]
[Successful Mutual Authentication]
--> 84 D8 00 01 1F 71 80 10 31 35 5C 0C E3 27 FD D5 8B 6B AE 37 56 CA 0D F2 03 CD 80 0F 0B EB 16 CF FF CE 4C 09
<-- 69 85 // Conditions of used not satisfied.
Well, I tried both cases of step #3 (P1 = 0x00 and P1 = 0x71) with disabled Delegated Management too, but nothing changed and I respectively received 0x6A80 and 0x6A88.
What's wrong? How can I fix the delete or modify this key?
Note that I tried all the steps in secure channel with SecurityLevel = 0x03 too. Nothing changed.
Update:
I tried to list the available keys in the card using GET DATA APDU command with Key Info Template tag, but I only can see ISD ENC, MAC and KEK keys in the APDU Response (For both DM enabled and DM Disabled.
--> 80 CA 00 E0 00
<-- E0 12 C0 04 01 01 80 10 C0 04 02 01 80 10 C0 04 03 01 80 10 90 00
One idea: The receipt key (and you also have to store a token key) might be linked to a application security domain. Select the Security Domain with Token Verification privilege and the Security Domain with Receipt Generation
privilege, maybe they are different from the ISD. I assume also that during [Proprietary APDU command to enable Delegated Management] a new application security domain (ASP) was created. Try the select these new security domains and list there all the keys using the key template flag and execute then your PUT KEY operations against one of these security domains. GET STATUSis the command to be used for listing the SDs. All the existing OS tools like GPShell and GlobalPlatformPro can do this.
I want to generate gp secure channel 01. my trace is:
Send: 80 50 00 00 08 00 00 00 00 00 00 00 00
Recv: 00 00 00 00 00 00 00 00 00 00 FF 02 00 02 0E 5A 8F F4 57 DD 35 5C 49 A6 8B 15 E9 A5 9000
so I have :
Card challenge= 00 02 0E 5A 8F F4 57 DD
Host challenge=00 00 00 00 00 00 00 00
according SPC01: image
Derivation data== 8F F4 57 DD 00 00 00 00 00 02 0E 5A 00 00 00 00
IV=0000000000000000
c_ENC: 404142434445464748494A4B4C4D4E4F
according this image and 3Des online
session s_ENC= C72F032C8BAD55D4D2579295CCF0A6CA
now :
hot-auth_data = card challenge + host challenge + pad
host-auth= 00020E5A8FF457DD00000000000000008000000000000000
s_ENC=C72F032C8BAD55D4D2579295CCF0A6CA
IV=0000000000000000
===========
result= 93CC77E144488A031BFFCCC62EB3B5C233A485F8255FE90E
Host cryptogram= 33A485F8255FE90E
but when I send :
848200000833A485F8255FE90E
I have error 0x6700 in method SDInstruction in line
short len = sc.processSecurity(apdu);
public void process(APDU apdu) throws ISOException {
if (selectingApplet()) {
return;
}
byte[] buffer = apdu.getBuffer();
switch (buffer[ISO7816.OFFSET_INS]) {
case ISO7816.INS_SELECT:
select();
return;
case INS_INIT_UPDATE:
case INS_EXT_AUTH:
SDInstruction(apdu);
break;
}
}
private void SDInstruction(APDU apdu)
{
byte[] buf = apdu.getBuffer();
byte cla = buf[ISO7816.OFFSET_CLA];
byte ins = buf[ISO7816.OFFSET_INS];
apdu.setIncomingAndReceive();
if(ins == INS_INIT_UPDATE)
sc = GPSystem.getSecureChannel();
short len = sc.processSecurity(apdu);
apdu.setOutgoing();
apdu.setOutgoingLength(len);
apdu.sendBytes(ISO7816.OFFSET_CDATA, (short) len);
}
Your card is using SCP02 and not SCP01.
Given the response to the INITIALIZE UPDATE command:
00 00 00 00 00 00 00 00 00 00 FF 02 00 02 0E 5A 8F F4 57 DD 35 5C 49 A6 8B 15 E9 A5 9000
The highlighted part is the "Key Information" which contains:
"Key Version Number" -- in your trace 0xFF
"Secure Channel Protocol Identifier" -- in your trace it is 0x02 indicating SCP02
See the Global Platform Card Specification for further reference (sections describing the INITIALIZE UPDATE command).
So you need to establish the secure channel with the card according to the SCP02.
Some additional (random) notes:
be sure to check the "i" secure channel parameter encoded inside the "Card Recognition Data" (tag '64') as well
you might want to look at the method GlobalPlatform.openSecureChannel() and the inner class GlobalPlatform.SCP0102Wrapper in the GlobalPlatformPro tool source code
Good luck!
According to the GlobalPlatform specification, the EXTERNAL AUTHENTICATE command has to include the host cryptogram as well as the MAC. Both are 8 bytes long, hence, your command should be 16 bytes in total.
If you want to implement the generation of this MAC value yourself, you can follow the description in the GlobalPlatform spec. But I suggest you to make use of available open source implementation. For example: GPJ is a Java implementation of the GlobalPlatform specification and has all commands that you need. You can take a look at the class GlobalPlatformService, where you will find the implementation of the secure channel protocol. GPDroid (github.com/mobilesec/secure-element-gpdroid) is a wrapper for this project on Android.
I've got a laptop (MSI GT72S) which features a manual GPU switch button. It can help me switch between the Nvidia GPU and the Intel one so that the disabled one will be hidden to the OS.
However, this function needs a driver called SCM which only supports Windows. When I press the button under Windows, there will be a pop-up window that asks me to reboot the machine so that it can switch to another GPU.
This is really a PIA to me as I use Linux far more often and every time I need to switch the GPU, I have to reboot into Windows and then reboot again. So I'd like to archive this function under Linux.
It seems that this is implemented by editing a block of the SMBIOS (not sure). When the Intel GPU is enabled, this block will be:
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 00
09 00 35 10 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
Strings:
Lan Phy Version
Sensor Firmware Version
Debug Mode Status
Enabled
Performance Mode Status
Disabled
Debug Use USB(Disabled:Serial)
Disabled
ICC Overclocking Version
UNDI Version
EC FW Version
GOP Version
BIOS Guard Version
Base EC FW Version
EC-EC Protocol Version
Royal Park Version
BP1.2.2.0_RP03
...and when the Nvidia GPU is enabled,
Handle 0x0052, DMI type 221, 96 bytes
OEM-specific Type
Header and Data:
DD 60 52 00 0D 01 00 00 00 00 00 00 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 00 00 00 00 00 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 FF
FF FF FF FF 0D 00 FF FF FF FF FF 0E 00 FF FF FF
FF FF 0F 00 FF FF FF FF FF 10 11 01 02 02 03 00
But I haven't touched such stuff before and I don't even know where to start. I have Googled it but few material was found. So I strongly need some suggestions now. Any help would be highly appreciated, thanks!
Looks like this is an OEM-defined structure (type 221) that reports status and version info. This information is built by the BIOS during POST, and posted to memory for reading by OS-based management agents (like dmidecode in Linux). Changing that information will not change the underlying configuration.
I have an ACR122U Contactless NFC reader. I bought a lot of blank RFID Mifare 4k tags. Their default Authentication KEY A and KEY B is FF FF FF FF FF FF.
Now I want to change them to something else. I'm using APDU structure. I'm sending commands like this and it works well:
byte[] baData = { 0x01, 0x00, (byte)i, 0x60, 0x00 };
APDUCommand apdux3 = new APDUCommand((byte)0xFF, (byte)0x86, (byte)0x00, (byte)0x00, baData, 0x05);
It works well. I don't know what this interface and model means, but using this type and structure, I want to change KEY A and KEY B.
Please help me. I can't find any document.
Regards
That's true, chips are delivered with default key FF FF FF FF FF FF for key A and B.
To change them you have to authenticate the card with the correct access bits.
Note: the Mifare key is composed as follow:
6 byte for key A
4 byte for Access Bits
6 byte for key B which is optional and can be set to 00 or any other value
To change your keys you have to authenticate the Sector Trailer and the write your new keys + new access conditions if you want to change them too.
Example
New key A = 00 11 22 33 44 55
Access bits not overwritten
Key B not used (so FF FF FF FF FF FF)
=> Write to Sector Trailer 00 11 22 33 44 55 FF 0F 00 FF FF FF FF FF FF FF
Further details are on the NXP website available or directly at the following link: https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf
A default Access Bits is usually FF 0F 00 that allow to write and read each block and to read and write key B.