CODEWITHSUNDEEP
smartcardapducontactless-smartcardnxp-microcontrollerecdh
Laye
Laye

Reputation: 1

6D00 error when writing to a Data Group (DG) secured with PACE

I am encountering an issue when trying to write to a Data Group (DG) that I have secured with PACE. Here is the context:

The DG is protected for both reading and writing with PACE. I am able to read the DG without any issues after successfully authenticating via PACE, which shows that the security session is correctly established for reading. However, when I attempt to write to the DG, I receive an error with the status code 6D00, which seems to indicate an unsupported or incorrect command. Here are the commands I used during the personalization of the DG:

CREATE_ICAO_DG2 = "00E00000126210800200C88201018302010286031010FF";
8044000100
Send => 8044000100
Get <= 9000

And here is the write command that fails (the commande 00D6 (UPDATE BINARY) is encrypted in the secure messaging and i am using chipDoc from NXP !) :

0C0D60001D871101394F17A27353F12D46F4E6A7F2FCABD68E08A2B1779F4C0FA5CE00
Send => 0C0D60001D871101394F17A27353F12D46F4E6A7F2FCABD68E08A2B1779F4C0FA5CE00
Get <= 99026D008E085345F3604A59FB2E6D00

I expected the write command to work since the PACE session seems to be properly established, and reading works fine. However, I get the 6D00 error. I have checked the commands, and the APDU format seems correct, but I suspect that something in the write permissions wasn't properly set during personalization.

Is there an additional authentication step required to write to a DG protected with PACE? Or could the issue be related to the format of the APDU command?

Thanks for your suggestions!

Upvotes: 0

Views: 91

Answers (3)

Laye
Laye

Reputation: 1

I Found the solution. The issue was due to an error in the encoding of the command in secure messaging. Instead of 0C0D60001D871101394F17A27353F12D46F4E6A7F2FCABD68E08A2B1779F4C0FA5CE00, the correct command was 0CD60001D871101394F17A27353F12D46F4E6A7F2FCABD68E08A2B1779F4C0FA5CE000.

The problem was caused by the encryption function, which added an extra 0 at the start of the string (after the 0C) if it was odd, turning 0CD6 into 0C0D6. After making this adjustment, the 6D00 error was resolved, and writing to the Data Group now works as expected. Thank you

Upvotes: 0

Maarten Bodewes
Maarten Bodewes

Reputation: 94038

You are currently trying to create the datagroup using E0 instruction, but you are posting an APDU with INS=44 that means DEACTIVATE FILE. I'd use the UPDATE BINARY instructions (D6 or D7) directly after establishing the secure channel.

If that instruction indicates that the file doesn't exist then it is time to create it. You can select the file by file ID in the P1 and P2 parameters right after the instruction. Depending on the system, it might be possible to read out the size of the data group using SELECT FILE (A4 of course) and P2 = 00 first.

Upvotes: 0

guidot
guidot

Reputation: 5333

Note, that access rules may depend on more than a previous authentication or trusted channels establishment. The data groups are typically just written once (before issuance of the passport) and the card may have switched its life cycle, to something like operational active to reflect that irreversible transition. Card life cycle, communication interface and privileged terminals (having presented additional certificates) are the most common other influence factors for an access rule evaluation result. (Since you seem to suggest, that you wrote the access rule yourself, it is not very likely, that this is the reason here).

Another possibility is, that only the odd instruction variant of UPDATE BINARY is provided (which is a functional superset of the even INS code), so INS code of B7 may be your friend. This would much better fit the "INS invalid" error code you encounter.

Upvotes: 0

Related Questions