NFCPassportReader: Error identifying Active Authentication Hash Algorithm - Australian ePassport

Hi @AndyQ @harry-anderson,

We’re recently run into the same issue and together with @donbobka we’ve made some discoveries that we hope will help in solving this issue 🙂

Australian R series passport:

• uses a 256 byte RSA key for AA, so the expected AA signature length is also exactly 256 bytes
• we’re only getting 231 bytes back in AA response after unwrapping from the Secure Messaging envelope
• the chip doesn’t seem to support response chaining - we’re getting 0x90 0x00 status, which indicates success and no remaining data available - the fix for Finnish passports doesn’t apply here - apparently the Australian chip just silently truncates the response here
• OpenSSLUtils.decryptRSASignature called on truncated data is effectively random bytes, so we fail to identify the digest algorithm based on decrypted signature trailer
• we’ve managed to get AA working by forcing extended length APDU for AA request (both nested and Secure Messaging envelope) and response:

diff --git a/Sources/NFCPassportReader/SecureMessaging.swift b/Sources/NFCPassportReader/SecureMessaging.swift
index 575185a..765745b 100644
--- a/Sources/NFCPassportReader/SecureMessaging.swift
+++ b/Sources/NFCPassportReader/SecureMessaging.swift
@@ -88,7 +88,7 @@ public class SecureMessaging {
         // otherwise its a single byte of size
         let size = do87.count + do97.count + do8e.count
         var dataSize: [UInt8]
-        if size > 255 {
+        if size > 255 || apdu.expectedResponseLength > 256 { // possibly should be apdu.expectedResponseLength > 231 to account for SM envelope
             dataSize = [0x00] + intToBin(size, pad: 4)
         } else {
             dataSize = intToBin(size)
@@ -98,7 +98,7 @@ public class SecureMessaging {
 
         // If the data is more that 255, specify the we are using extended length (0x00, 0x00)
         // Thanks to @filom for the fix!
-        if size > 255 {
+        if size > 255 || apdu.expectedResponseLength > 256 { // possibly should be apdu.expectedResponseLength > 231 to account for SM envelope
             protectedAPDU += [0x00,0x00]
         } else {
             protectedAPDU += [0x00]
diff --git a/Sources/NFCPassportReader/TagReader.swift b/Sources/NFCPassportReader/TagReader.swift
index 8791622..ac8366b 100644
--- a/Sources/NFCPassportReader/TagReader.swift
+++ b/Sources/NFCPassportReader/TagReader.swift
@@ -52,7 +52,7 @@ public class TagReader {
     func doInternalAuthentication( challenge: [UInt8] ) async throws -> ResponseAPDU {
         let randNonce = Data(challenge)
 
-        let cmd = NFCISO7816APDU(instructionClass: 00, instructionCode: 0x88, p1Parameter: 0, p2Parameter: 0, data: randNonce, expectedResponseLength: 256)
+        let cmd = NFCISO7816APDU(instructionClass: 00, instructionCode: 0x88, p1Parameter: 0, p2Parameter: 0, data: randNonce, expectedResponseLength: 65536)
 
         return try await send( cmd: cmd )
     }

• notice that we had to make the change in both places inside protect, despite the fact that we’re not sending more than 256 bytes, but only expecting to receive more than 256 bytes back (our guess is that we must use extended APDU format for both request and response together)
• our fix might break AA for some older passport that don’t support extended length APDU at all, so we’re not going to submit that PoC as a PR 🙂 (also we don’t know what will happen for Finnish passports - with that fix we would use extended length APDU instead of response chaining, so the previous fix might be unnecessary anymore)

We used to have the same issue on android using jmrtd library and it was just recently fixed in https://sourceforge.net/p/jmrtd/code/1878/ - seems like they try to predict the AA signature size based on the AA public key from DG15.

We might submit a PR with a proper fix based on jmrtd’s approach in the following days/weeks, but we would also be very happy for you to do it, since we don’t have access to too many passport to test against and our understanding of the ICAO standards and NFC tech is also quite limited 😅

I did this for the reading of the data groups and it works fine (Swedish National ID) and much faster. It could be a good idea to have this as the default and then reintroduce the fallback mechanism to drop to 0xA0 (160) on failure.

Thats great news, I’ll test out across my dev passports hopefully today (work has got in the way this week!) and see if thats a compatible change.

OK, so thats out then, looks like it didn’t even get the signature back this time (which is odd esp as no error).

Am a little stumped at the moment.