I am currently working on an Android application that reads e-passports and other NFC enabled documents.
I have tested the code across multiple Android devices but have found 1 of them to be unsuccessful in reading documents.
Taking the e-passport as an example, it correctly communicates the Select Application call and returns a status code of 90 00. I also get a valid BAC challenge, but when I call the EXTERNAL AUTHENTICATE it returns a status code of 69 86 (Command not allowed (no current EF)). All my other test phones return status code 90 00.
My question is why a single model of phone is giving me a different APDU response. I have tried to read up on the NFC hardware within Android but haven't found an answer as to why this could be happening. I am left to presume that this maybe a protocol issue?
If anyone could shed some light on this, I would be most grateful.
Without analyzing the actual communication, one can only speculate what's going on there. There are, however, two potential causes:
What you experience, may be caused by the Android tag presence checking mechanism. By default, if you do not send commands fast enough, Android interleaves your communication with its presence checking mechanism. On some devices, this presence checking uses APDUs sent on the basic logical channel. Consequently, they are received and processed by the MRTD application on the passport and may causes state changes. See Android IsoDep command chaining failure.
Cryptographic operations on the MRTD need more power than other operations. If your passport requires more power than provided by that specific test device (remember that NFC phones are designed to read low-power NFC tags and not to interact with energy greedy contactless smart cards), communication with the passport may be lost, or in the worst case, may cause unexpected state changes in the smart card application (though smart card chips are usually designed to enforce a reset in these cases).