ePassport Chip Authentication - how to verify?

Question

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.

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.