I want to implement Chip Authentication for ePassport documents, and wish to validate my understanding of it.

I've managed to get it up and running by using the JMRTD library, specifically the function doEACCA(). When inspecting the code of this and associated functions, I observed that it doesn't actually verify the outcome of the protocol. It runs the CA protocol according to the standard, and this leads to a new Secure Messaging key, then switches the internal wrapper to use that protocol going forward. But it seems there's no actual validation done after this and no actual communication after this. So if one stopped here, it would actually lead to a false impression of success on the inspection system, since it doesn't know it derived a different shared key than the chip. In fact it seems somewhat of a misnomer to call the protocol Chip Authentication. It would be more correct to call it a key exchange. Since all the shared key is used for is to setup a new SM tunnel, I suppose (and this is what I want to verify by this question) that the actual validation happens first when issuing some other command. This command must involve SM - critically, the response from chip must have a payload that includes a MAC. It is validation of this MAC, by the inspection system, that actually completes the Chip Authentication.

It seems the choice of command (apart from the stated aspects above) is not important? If true, can you suggest a command to run? Due to other aspects of the setup in which my solution operates, it would be preferable with a simple, "one-shot" command where both command and response can fit in a single APDU etc. This will complete my communication with the chip.

1 Answer 1


Yes, you are right, the next command - or rather the MAC over the response data & status word returned for the next command - is what is validating that the chip has the private key. This is an unfortunate way of doing things; the response should have included a MAC set with one of the keys or a separately derived key. Currently you have to make horrible design choices when implementing secure messaging, for one. And maybe you just want to authenticate the chip.

It is something that I've indicated at the time and which should be corrected when using PACE or PACE-CAM, if I remember correctly. That is the PACE password authentication with integrated Chip Authentication (I forgot what the M is for).

If you want to look for a command that should do nothing then GET CHALLENGE is a good command, it just gets some random bytes from the chip, and as such would not contain any user data or reset any security environment. I would request an 8 byte challenge as that is what is used during BAC authentication. Of course you'd need to send this (or any following) command including secure messaging. The only thing that is slightly worrying is that GET CHALLENGE could only be implemented without SM.

You could also use READ BINARY to read DG1, containing the MRZ. That data group contains required knowledge anyway, and you may want to compare it to the physical MRZ as an authentication check.

  • Maarten, thanks for your reply! I actually hoped you would reply since I saw some of your previous. And thanks for helping my sanity, it really seems strange this design so it's good if it's fixed in PACE-CAM (PACE only authenticates the inspection system). In my scenario this design of CA is particularly annoying and causes some layering violations between components. But at least now I know there isn't a better way (I kept looking for a call that would return something derived from the shared secret, HMAC or similar, as is typical in auth protocols).
    – Morty
    Jun 3, 2021 at 6:01
  • Yeah, I had the same issue. Seems that you know your layering, shame that the protocol doesn't :| Jun 5, 2021 at 0:02
  • 1
    BTW, justfor future readers, the passport I was working with wouldn't accept a GET CHALLENGE over SM. But I ended up using a simple GET FILE for the COM file and that works nicely over SM and produces an authenticated response.
    – Morty
    Jul 1, 2021 at 20:51
  • Heh, I guess that would make it officially non-ISO 7816-4 compliant, but show me one smart card that is fully compliant - I've seen worse atrocities :) Yeah, COM file or DG1 can both be used, but there was some talk about removing the COM file as the SOD already contains the contents as well, so beware. Jul 1, 2021 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .