简体   繁体   中英

What's wrong with this Verify APDU command?

I've got the following Verify (PIN) APDU command, that we send to the Gemalto SafeNet Reader K1100:

00 20 00 81 08 26 12 34 56 ff ff ff ff

I always get the response 67 00 (wrong length). As far as I know this means that either LC or LE is incorrect.

The APDU looks correct assuming:

  • there exists a PIN with ID 1 within the current DF
  • the card uses a BCD format for PINs and pads them to 8 bytes or the PIN value contains strange non-printable characters

You could try 01 instead of 81, to ensure the PIN is searched in the MF, or 00 assuming the card knows the PIN id implicitly. If both attempts fail, you have to collect more information concerning initialization/personalization of your card.

Since the Verify command has no result, LE can't be wrong. Note however, that when using Java classes to construct the APDU, LC is added automatically and must not be specified.

My only other idea is, to omit the FF bytes adjusting the LC accordingly.

are you using Athena?

if this is the case try p2= A0

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM