Reading Passport

[DavidParticipant]

Hi Richard,

Are you aware of any software available, on ios, that uses the Flojack for reading the chip on a passport?

[RichardKeymaster]

Hi David, indeed the FloJack/ACR35 can read ePassports that conform to the ISO14443 air interface. I recorded a video demonstrating this capacity some time ago:

Pardon the poor quality of the video but you get the idea. Basically the FloJack is able to send and receive APDUs to the smartcard inside the ePassport. This smartcard conforms to the NFC Forum Type 4 specification so the command set to interact with it may depend on the manufacturer/country. We do now provide support for ePassport protocols per se, only the management of the FloJack reader connect/disconnections, tag discovered alerts, and other reader management services. It will be up to you to send and process APDU command/response pairs to interact with the ePassport effectively.

I hope that helps,
Richard

[DavidParticipant]

Given the rumors that Apple is removing the headphone jack from future iPhones, is the FloBLE your future alternative or are you considering a lightning port FloJack?

[RichardKeymaster]

Hi David, yes the future alternative is indeed the FloBLE product line. The products have shown great success because of their flexible yet robust deployment options. We are field testing many dozen at a time and are pleased with their performance and manageability. Security, which may be your concern, is covered by a point-to-point encryption (P2PE) feature that’s included in the FloBLE hardware. It basically adds a required authentication step to the Bluetooth connection flow:

The authentication process involves symmetric encryption along with pseudo-random generated tokens to construct a 128bit session key for P2PE and goes something like this:

1. The Host device (iPhone) sends an auth request to the FloBLE
2. FloBLE generates a 128bit random token FT[0:15] and signs it with FloBLE shared secret FSS[0:15] to construct encrypted payload FEP[0:15].
3. The FloBLE encrypted payload FEP[0:15] is sent to Host device as an auth response.
4. Using FloBLE shared secret, the Host device will decrypt FEP[0:15] to recover the FloBLE token FT[0:15].
5. The Host device generates another 128bit random token HT[0:15] and appends it to the FEP[0:15] to create complete token CT[0:31]. The Host device then signs the complete token CT[0:31] with the FloBLE shared secret FSS[0:15] to construct Host encrypted payload HEP[0:31].
6. The Host device sends the auth message HEP[0:31] to the FloBLE.
7. The FloBLE decrypts the HEP[0:31] with the FloBLE shared secret FSS[0:15] to recover the complete token CT[0:31]. FloBLE checks if first half of the complete token CT[0:15] matches the original FloBLE token FT[0:15]. If not, the auth will fail.
8. The FloBLE signs the remaining Host token HT[0:15] with the FloBLE shared secret FSS[0:15] to construct FEP'[0:15]. Also the first 8 bytes of the FloBLE token FT[0:7] are appended with the first 8 bytes of the Host token HT[0:7] to create an 128bit session key SK[0:15].
9. The FloBLE sends the signed Host token FEP'[0:15] to the Host device.
10. The Host device decrypts the new FloBLE encrypted payload FEP'[0:15] to recover the Host token HT[0:15] and checks if it matches the original Host token. If not, the auth will fail. Otherwise, auth is complete and the Host device constructs the valid session key SK[0:15] from appending the first 8 bytes of the FloBLE token FT[0:7] with the first 8 bytes of the Host token HT[0:7].

I hope that settles your concerns regarding security over a Bluetooth link. We feel its less vulnerable to attacks than the audio jack or lightening port interface. Thus, we are not considering a lightening port FloJack at this time.

Either way let me know you thoughts on the matter. I’d like to best understand your requirements when it comes to security.

thanks,
Richard

[Author]

Posts