I can see many uses for that… 
2 Likes
There is one applet that would be useful: detect the command patterns to determine whether it’s an Android, iOS or some other device accessing the chip, and send a different NDEF depending on the kind of device. So for instance a vCard for an Android device, a URL for an iPhone, and a password for a PC. Better, using Tasker or a custom program for example, send a very unique pattern of reads and the applet replies with an SSH key or something. Kind of like port knocking.
5 Likes
Another question: is it possible for an applet to get run with a particular select? Like for example, the chip has UID 00:11:22:33:44:55:66 but the reader selects DD:EE:AA:DD:BB:EE:EE on purpose - despite that UID not being in the field - and the specific applet gets executed. Is that a thing? That’d be great: there could be hidden applets on the chip.
3 Likes
Each applet has an AID and it’s usually not visible to external readers or even the other applets on the chip. You can easily hide whatever secret applets you want on there. That’s literally the point of the thing, that’s why it can handle EMV and SECID applications 
3 Likes
That one coming from default would be nice.
Closes thing you can do on those chips (and not sure if Fidesmo ecossystem allows it) is to get a “default” app to run which can select what to return when the reader did not request any specific applet.
I think Fidesmo eats the interface for the “default” app though. (please correct me here whomever knows more about Fidesmo than me.)
1 Like
Although, by belonging to an ecosystem, and the having such particular “pagination system”, someone with enough access can still Identify the presence of hidden apps on a chip.
Less of a concern to an implant, unless you assume I could hold your hand under a reader for about 30 minutes without you noticing…
But with enough access time I could even dictionary out all the knows AIDs from the ecossystem, table them against known application sizes, and toss in a couple less brute-forcey tricks to identify the presence of extra applets…
But then there’s no method I’m aware to figure out the AID to gain access to such. (except brute force, but most chips add a small delay for each consecutive failed request, so brute force is basically out of the table)
1 Like
If the reader doesn’t know the aid, I’m assuming that you have to program the reader to ask for an aid, in which case, how would tesla key card app work? Because I’m pretty sure tesla doesn’t know, care about, or ask for the aid of our key card applet…
2 Likes
Good question.
Answer lies on RID.
When developing an applet you must assign it an unique ID.
For development purposes you can technically use anything. But for production purposes, the first 5 bytes of your ID must be an iso-registered/maintained vendor id.
You can check more about JavaCard conventions here:
https://openjavacard.org/devguide/naming.html
Although, since we’re talking about Apex here, most of that will be handled by the ecosystem maintainer, or Fidesmo. Despite having to go through theirs release process to get something properly added to your Apex, this way you won’t need to worry much about some “bureaucratic” tasks around developping within JavaCard environments… 
(Gosh, I hate the whole Java mindset) 
1 Like
No, we just use the aid they use.
There’s two they ask for, we use the “standard” one as opposed to their non-standard. It’s why it was up to fidesmo to let us use the tesla AID.
An applet can respond any way it likes to a select command. The convention is to respond with the full AID of the applet, but it’s by no means necessary. For example, the AID of an OpenPGP applet actually is extremely specific. It includes the reserved AID for the FSF Europe, an applet ID, some details like a manufacturer ID (issued by the maintainer of the standard), the applet version, and the serial of the applet.
But if you select just an AID containing the FSF prefix and an applet ID, you will get the first matching openpgp applet. You can narrow it down by version, then you can narrow it down by manufacturer etc. Even going right to trying to select a specific serial.
2 Likes
Default apps 99% of the time are the card manager app. Fidesmo is no different.
2 Likes
As expected then.
1 Like
I love this idea. But, I’m not sure if different phones interrogate NDEF differently.
There’s also room to use a NDEF app to hide data. The standard select and read gives you normal data, but if you use a select but a secret command (possibly requiring the correct pin in it) you get read/write access to a secret block of data.
2 Likes
The main issue with attempting to hide data within nfc chips is that the pagination system implemented makes it quite easy to identify data blocks and “secret” apps.
The chips are really good at making data secure/inaccessible, especially at hardware level and/or with cryptography, but attempts to “hide” something will most likely be foiled.
1 Like
Not really the best way to describe this issue. You mean hide data within ndef messages. Ndef is meant to be read. If you want to hide data in a chip you can write your own simple javacard application with custom AID and write your own reader / mobile software to interact with it.
1 Like
exactly my point.
2 Likes
Sorry I get picky about specifics as relates to security because I’ve heard so many people say things like “RFID is insecure” or “NFC is hackable” when really they are just transports. Security is the job of the application letter layer.
2 Likes
Well, I dunno what iOS does exactly, but I know Android does a lot of seemingly useless things several times in a row as a preample to doing anything at all, or letting whatever app happens to be running do its own things. It would have to be tested with several versions of Android and iOS, but I bet it wouldn’t be too hard to fingerprint the OS - provided the applet is able to “survive” a reset and immediate re-select, because I seem to remember that’s one of the things Android does.
1 Like
Oh, I completely agree with you. You should get picky! This is an open forum and it’s irresponsible of us to give the wrong impression away.
In hindsight, I also probably misread the sentence:
I interpreted as “secret block of data on the chip”, as in “hiding the application”.
Hence the tone in my reply, where I attempted to state:
- NDEFs are not meant to be secret. if you want secrecy you should use an applet
- Technically you cannot hide the fact that there is an application there, but…
- …those chips are so secure at a hardware level that you probably don’t want an app just to try and hide another app. It would be a moot exercise.
Also, just to make sure it’s clear…
Even on the scenarios where you could “hack” an nfc based card, all those “hacks” have wildly unrealistic scenarios.
For instance, one group who figured out that they could bypass the contactless transaction limit of 30U$D… but for pulling that trick out they “just needed” to install a device on the reader…
Come on, if I can “just install a device on the reader”, I can do so much more damage to a bank account even on a regular, insert + pin number, card!
Or the second classical case, which I tried to address by joking about keeping hold of @anon3825968 's hand for 30 minutes without him noticing, is when security researchers claim that “If I have access to a contactless card I can do this this and that and make a big transaction”.
What media usually fails to mention is that in those cases the techniques involved usually take about 30-45 minutes to be ran and/or require prior knowledge about someone’s shopping habits.
Come on, If I have prior knowledge about your shopping habits, all I need is 1 second’s access to your actual insert+pin card for a photo! then I can do a much bigger transaction online!
There just isn’t any actual realistic security threat to nfc technology.
Even Visa, which is constantly under the scrutiny of researchers, already declared multiple times: “we have a whole department of analysts and years of experience that shows us these attack scenarios are just unrealistic. Given the assumptions needed for a criminal to cause some damage utilising contactless transactions, a common crook under the same circunstances could pull a bigger stunt using non-contactless transactions as well. And we do have measures in place to avoid that”
Which boils down to, as @amal said, Security being responsibility of the application, not of the chip.
4 Likes
Apologies, guys, I mean a customised NDEF app with commands to swap the location you’re reading from. Almost a kind of paging, much like Rosco was describing, but where the swap only occurs if you send the chip a command with a valid password, otherwise there’s no way to be aware said command is enabled.
2 Likes
Another point - while an app might be there, knowing what data an app may hold is another thing.
1 Like