CODEWITHSUNDEEP
smartcardapdu
Christoph Wimberger
Christoph Wimberger

Reputation: 136

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.

Upvotes: 0

Views: 1368

Answers (2)

user2880309
user2880309

Reputation: 1

are you using Athena?

if this is the case try p2= A0

Upvotes: 0

guidot
guidot

Reputation: 5333

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.

Upvotes: 0

Related Questions