Error identifying Active Authentication Hash Algorithm - Chinese ePassport about nfcpassportreader HOT 20 OPEN

Well... Apparently that will give you: (Extended try) sw - 0x67, sw2 - 0x00, and no data

and then (Normal try) sw - 0x69, sw2 - 0x88, and no data

So apparently not.

Thats a shame! Not quite sure what to do here really. I could add a flag to enable extended mode BUT you'd have to know that the passport supports/doesn't support that. I'll did a little more into JMRTD code and see if I can see what they did to solve this. I had a quick look thorugh and they had some functions in bouncy castle that could get certain info about the keys that I haven't yet figured out how to do (I'm sure its possible though).

from nfcpassportreader.

The doInternalAuthentication function is actually not working. Active Authentication (AA) is not being created.

Could you try with version 2.1.1 and see if that works for you (that doesn't enable extended read) and has been working for most passports (except newer Australian and probably other newer ones)?

from nfcpassportreader.

So what I've done for the moment is instead of enabling extended mode for AA by default, we now have an additional flag set on PassportReader init - useExtendedMode. Not ideal but will think more.

Also, as per #224 - We're now using OpenSSL 1.1.2300 which is a signed release and includes a privacy policy.

Currently main branch only,

from nfcpassportreader.

The latest update solved my problem, thank you. You saved me from a big issue; I had been researching it for a week. 🙏❤️

from nfcpassportreader.

It's definitely getting closer. I'm still not 100% happy as I do t yet know what passport support extended reads and which don't! It looks like some Chinese ones don't but I'm sure there are others too. So I can't yet say when you should use extended read or not. JMRTD does some best guesses based on key lengths BITBi haven't yet figured out how to replicate that in OpenSSL (JMRTD uses bouncycastle which has different APIs).

from nfcpassportreader.

Setting Expected Response Length to 231 on this line works for those documents as well. Guessing the extended format is not being liked.

from nfcpassportreader.

Thats really annoying! will have a re-think

from nfcpassportreader.

I've created a test branch - aa_test which makes the following changes:

• passportReader.readPassport now takes in an optional PassportReaderOptions struct with various configuration options
• Added option usePACEPolling - Switches to PACE Polling for detecting passports rather that iso14443
• Active Authentication no longer always uses extended read
• Instead, we first try with standard 256 byte read, and if fails, tries extended read
  • Note this is currently untested as I don't have any passports that require extended read
• Sample app updated to show new options

If anyone can test this branch to see if it works fine that would be great!

from nfcpassportreader.

I do not believe that would work. Some documents (like that Australian passport in #194) will actually return OK with a partial signature (cutting off whatever did not fit). The implementation in aa_test would return that response and not go for an extended read.

This of course would work fine for this one document I now mentioned in this issue, but that other one would again break.

from nfcpassportreader.

Hmmm thats a good point. Wonder if it would work the other way round? try first with extended read and if that failed then try standard? I've pushed up a small change to try that

from nfcpassportreader.

That will not work for my document as you would need to handle the NFCPasswordReaderError.ResponseError thrown from TagReader.send(). This Chinese document returns sw - 0x69, sw2 - 0x88 (SM data objects incorrect) when doing the extended version first.

from nfcpassportreader.

Ah of course - small change! - currently doesn't check the error, just retries non-extended - any better?

I'm really interested if the passport will allow the normal read after the extended read fails!

from nfcpassportreader.

Well... Apparently that will give you:
(Extended try)
sw - 0x67, sw2 - 0x00, and no data

and then
(Normal try)
sw - 0x69, sw2 - 0x88, and no data

So apparently not.

from nfcpassportreader.

?

from nfcpassportreader.

@rbrouwer Did you solve the problem

from nfcpassportreader.

The doInternalAuthentication function is actually not working. Active Authentication (AA) is not being created.

from nfcpassportreader.

Hello, I tried but unfortunately there was an issue. It doesn't decode, most likely. The ID is a Turkish ID and it should normally be supported.

from nfcpassportreader.

It works seamlessly on Android using JMRTD.

from nfcpassportreader.

@AndyQ looks like it's working for @baskurtbey maybe it's time for a release? ;)

Also, when we should use the flag for extended? Which passports as far as you know require it to read them correctly?

from nfcpassportreader.

@AndyQ for what it's worth, ICAO specifies in https://www.icao.int/publications/documents/9303_p11_cons_en.pdf that

Note.— It should be noted that when using key lengths exceeding 1 848 bits (if Secure Messaging with 3DES is used) / 1 792 bits (if Secure Messaging with AES is used) in Active Authentication with Secure Messaging, Extended Length APDUs MUST be supported by the eMRTD chip and the Inspection System.

For Australian R-series EPassports, DG14 includes id-PACE-ECDH-GM-AES-CBC-CMAC-256 (0.4.0.127.0.7.2.2.4.2.4) as the only supported PACE algorithm.
This is a 256-byte key, so based on that we know the chip MUST support extended length APDUs.

Logs from here are:

doPace - inpit parameters
paceOID - 0.4.0.127.0.7.2.2.4.2.4
parameterSpec - 933
mappingType - Generic Mapping
agreementAlg - ECDH
cipherAlg - AES
digestAlg - SHA-256
keyLength - 256

from nfcpassportreader.