Android HCE App Preview

[maxieds]

Thanks to @geo-rg for sending me two new free Chameleon Mini Rev. G boards for contributing to the project. This is a preview of what I will be using these extra boards for. For the time being the HCE app repo will be private, but the aim is to get the local doors at my apartment complex which are currently opened by Desfire cards to open with my phone. This is a screenshot:

What I can get out of the local readers for right now w.r.t. communication with my Droid device is NDEF messages with session info, and a single (not very useful) APDU AID select command that gets sent through my customized HostApduService. When I respond to this APDU with a RESPONSE OK return, the connection to the Tag is abruptly cut off.

Of course I can get more information about what the reader is expecting from the card with the Chameleon Mini. Any suggestions for what to try next to initiate more communication with the reader?

[maxieds]

I think it's going to be related to a transfer of this type based on what I can pick up with the Chameleon: auth-scheme.pdf. Does that seem about right?

[maxieds]

And another example of the difficult door reader behavior I'm trying to decode:

Notice that the link is lost immediately after returning anything via the HostApduService, but that some state information is still passed via URI in an NDEF message. There's actually already an app for this class of door readers. I really don't want to have to reverse engineer that APK (tried briefly, painful and slow-going) and there is no available documentation on using a third-party application to coerce the reader into letting a cell phone log itself in besides with their sanctioned app. Again any suggestions are welcome for getting this up and running further.

[doegox]

The doc you mention is just the TypeA anticollision that always takes place at the beginning of a conversation. What you can try is:

• read the UID of your desfire
• emulate the uid with the chameleonmini configured as mifare ultralight (so 7bytes UID) Sometimes it's enough to fool poor authentication systems.

Second option is that you would have to emulate some low level details of desfire cards (atqa, sak, reply to selectAID) in case the reader makes the diff between ultralight & desfire cards.

Third is that your access control is really using the crypto features of the desfire. In theory you could emulate it with the chameleon mini or the HCE of a phone but you don't have the keys so in this last case... forget about it, there is nothing you could do.

[doegox]

Ha if there is already an app foreseen for these locks, this mean they accept also other type of cards than desfire cards. From your log it looks like the door is sending an NDEF msg that the phone can read and the phone has to go online to that URL to probably do some auth, then...

[maxieds]

Yeah, I noticed that. Huh... But still, the readers work with just the standard Desfire cards.

I have the UID of my Desfire handy. Based on sniffing the conversations between the card and the door reader, the bits (some sequences get repeated erratically, but the sequences themselves do not change) essentially do not change. I am led to believe that there isn't any crypto auth going on with the door reader and this can be done all by knowing the card's UID. The problem is getting the reader to communicate with me. See this image in Issue #6 https://user-images.githubusercontent.com/22165688/34960426-bde38218-fa08-11e7-90de-ea66452287a5.png for an example of the weird behavior I'm getting from the reader.

Sending back 0x26 in response to the AID select gets it to reissue the select command. Sending back {0x20, 0x93} gets it to issue an NDEF. After that I'm lost on getting it to talk back to me more.

[doegox]

Some info https://www.aptiqmobile.com/AreYouReady/how-it-works.html

[maxieds]

Surely you jest. But in case not:

This is all marketing. There are no good tech specs for how to interact with the reader unless you have access to one of these Admin portals. Try downloading that app just for fun and see what it does. I think that the admin pin mentioned in your link is just a one-time registration type thing to get the user of the app initially authenticated with the big bad cloud system. Once you have that data stored in the app (maybe they're doing online lookups into the cloud db's everytime you use the app, maybe probably not), then (and of course only then) will the door reader get along with the Droid phone.

This is my annoyance with the topic. I think that if you know what to do with the codes in that NDEF message, then the ApduHostService will magically be able to talk to the door reader like it obviously can using their proprietary app. This is what they are using in their app to talk over Android (HCE, nothing else particularly new Android wise). There's obviously a way to do this. I just want to know how so I can use my credentials without their app -- say with the one I'm writing.

[maxieds]

I can sniff the communication between the card and the reader with the Chameleon. The problem is that unless you have an authenticated version of the officially sanctioned app, you're not going to be able to sniff what the Droid phone is actually sending back in response to the NDEF and APDU AID select command. Two completely different protocols -- one for the cards (Droid doesn't let you get that low-level) and another masked one for layering on top with the phone.

Edit: If you can dig up any more tech specs like that I'd be interested in seeing them. That link is more detailed than what you can get to from the site that the NDEF message URI redirects to after a timeout. Tinkering with this is what got me to finally try a hardware solution like the Chameleon.

[maxieds]

This is another interesting link: http://www.locksmithledger.com/article/12090691/deeper-access-control-on-more-doors. Google images also turns up some good images.

[maxieds]

And then there's this. So I believe @doegox was correct: they intend on using multiple cards and charging for the service to use your cell phone with their branded door readers. Interesting strategy, though not too pricey.

[maxieds]

As it turns out the link in the last post buys you (for approximately $6-7.99) one (non-refundable) "Mifare credential" for using with the AptiQ door readers. As far as I can tell this is not necessarily tied to the Desfire card you are using to open the door without an Android phone. The problem here (as I have expressed less reservedly above) is that you are not being given the sequence of decidedly mock APDU commands needed to figure out what to send to the reader without knowing this magic credential. So for a small service fee, Allegion gifts your phone with a Mifare key of their choosing so you can use their app to open the doors. Will keep this thread posted in case anyone gets anything searching google for this information months from now.

[jekkos]

@maxieds think easiest way to know is relaying nfc comms between reader and the card. That's how I figured out most of the communication patterns in my research. For that I used two openPCDs and nfc-relay from libnfc toolkit.

If the answer is static then I presume that indeed no crypto functionality is used..

[jekkos]

@maxieds what would be even cooler is to have an android app without custom hardware handle this. Might be sidetracking but I found that the standard android stack is well capable of sending custom the (atqa, sak, reply to selectAID) by some AOSP code manipulation. What it can't do is emulate uids.

At the time I only digged into specific libnxp to patch this (CM 12), so not sure on what the state of this software is by now.