Error identifying Active Authentication Hash Algorithm - Chinese ePassport

[rbrouwer]

The solution of #194 broke AA for recent Chinese passports.

Those will return 0 bytes when giving them an Expected Response Length of 65536. When undoing the changes to secure messaging and setting the Expected Response Length to 256. Those work just fine again.

I guess behaviour such as in JMRTD' AAAPDUSender is wanted; Guessing the correct length and even retrying with 65536 when 256 did not make sense.

[rbrouwer]

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

[AndyQ]

Thats really annoying! will have a re-think

[AndyQ]

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!

[rbrouwer]

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.

[AndyQ]

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

[rbrouwer]

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.

[AndyQ]

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!

[rbrouwer]

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.

[furkanisik000]

?

[baskurtbey]

@rbrouwer Did you solve the problem

[baskurtbey]

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

[AndyQ]

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).

[AndyQ]

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)?

[baskurtbey]

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.