NFCPassportReader
NFCPassportReader copied to clipboard
AndyQ
Incomplete inferOID
The current implementation of inferOID looks incomplete. The 9303_p11_cons_en.pdf seems to describe the complete listing.
How do we approach to correctly infer the OID when ChipAuthenticationInfo is missing? The JMRTD's inferChipAuthenticationOIDfromPublicKeyOID method is also incomplete.
Not sure what you mean by incomplete. The ChipAuthenticationInfo contains the details of what implementation should be used. Some passports for some reason don't include this so there is no way of knowing which is actually used, so we need to take a guess. There are two different types: DH and ECDSA, and within them you can use both 3DES and AES based encryption. If AES is used, then there are different key lengths.
However, however the Object ID for the Public Key only tells us that we are using either DH or ECDSA so we guess for the rest and based on the passports I've seen, in these cases they are all 3DES based so these are the ones I pick (as does JMRTD).
However, if there is a more complete way of guessing then I'd really like to know!
I have one remote (not mine) epassport that failed on Chip Authentication using JMRTD's infer method. What do you think of looping through each until it succeeds?
Would be interested to know what the type it actually was using was! If you are able to share the DG14 element and also the nationality of that passport that may be useful (not sure though).
The only issue with try each one if we are inferring, then it would probably break the secure session - passports tend to abort the session on an error with no warning which means that you would need to re-establish BAC each time adding a fair bit of complexity.
Would be interested to know what the type it actually was using was! If you are able to share the DG14 element and also the nationality of that passport that may be useful (not sure though).
The only issue with try each one if we are inferring, then it would probably break the secure session - passports tend to abort the session on an error with no warning which means that you would need to re-establish BAC each time adding a fair bit of complexity.
According to an ICAO protocol specification, it won't harm the state of the secure messaging on failed Chip Authentication attempt.
From this ICAO spec, isn't epassports with missing ChipAuthenticationInfo be considered deviants? However, he was able to do CA using ReadID so I wonder how ReadID did it.
I just tested using JMRTD that looping through each possible oid does not reset the secure messaging, until it finds the correct oid and is able to do a successful doEACCA(). In light of this result and what is stated here, I think I'll stick on my exhaustive looping technique rather than choosing one. For example, other possible actual value of OID is cited here.
If you want to submit a pull request I'm happy to see if I can get this tested on some of the passports I've found that also have the missing ChipAutheniticationInfo with a view to implementing it in a future version if all works ok.
