Mifare 1K TAG Read and Write using KEYB

[selvaraj1]

Hi ,

Here using PN512 Reader for our Project.And Using Mifare 1K Tag.

For KeyA Based Authentication ,Read and Write Operation which getting success.

For KeyB only getting Authentication Success.Read and Write Operation getting Fail.

This will be on Default Access Bit- FF078069 and Both Keys are <FF FF FF FF FF FF>.

Same type of some NXP 1K Cards Getting Success on KEYB Read and Write.

 For Success and Fail Status Response Below from PN512.

Success:

Authentication of block 08 successful, continue operation.
Mifare Read: Block=08, Data:
30313100000000000000000000000000
Fail.
Authentication of block 08 successful, continue operation.
*** ERROR! MifareRead: Block=08, Status = 091b
Here 091b- refers to NACK detected.(negative acknowledgement)

Please give the Solution for this Issue.

Thanks

[selvaraj1]

Dear Jonathan,

we make the correction in the Library. and it's working on KEYB.

Thanks
Selva

[Jonathan_Iglesias]

Dear SELVARAJ KARUPPASAMY,

I see the internal case you posted once you determine it has been solved,  I will post here the answer.

BR

Jonathan

[selvaraj1]

Dear Jonathan,

   In PN512 Reader -Once change the KEY Block Access bit From -FF078069-   to 7F078869. then we can Read and write the Data Block Using KEY B. our issue will be solved By changing the Key Access Bit conditions.

Our New Product Development Using CLRC66303 reader chip.

For KeyA Login Authendication, Read and Write getting Success. 

Here Facing KEYB Authentication Fail.Does Not Login Using KeyB for this Access Bit Conditions (7F078869).

Here using OM26630FDK -Development Kit. Any Script File toTest the Authenticate, Read and Write using KeyB for Classic 1K/4Kcards.

Thanks

[Jonathan_Iglesias]

Hope you are doing great,

there was a mistake in the library, this will be fixed in the next release. The issue is following.

By using Key-B the pointer of ‘pKey’ is set to start at index ‘6’ of 'aKey’

Instead of all 0xFF the last 4 bytes are different. This causes the authentication to fail.

Conclusion: Initialization of the key is wrong/not done.

The keys are set by following function:

If we further look into this function we will see that the size of the key is retrieved by ‘phKeyStore_GetKeySize(wKeyType)’

So we will copy 12 bytes, of course!, for Key-A and Key-B. But if we look at the key we pass: it is only 6 byte long!!! The rest will be whatever is written after that. Actually we have here a perfect example of a boundary violation! By changing it to actual 12 bytes everything works as expected!!

BR

Jonathan