JavaCard Questions

Support
1

Hey all,

I have a few questions related to the JC api - I understand this is more project-related than support, but figured I’d write anyways.

I have yet to receive a device or testing equipment, so I am in the process of conceptualizing a project, thanks for bearing with me!

  1. Is there a way to process “time” on the chip itself?

Since the NFC devices contain no batteries, the concept of current time seems impossible. However, my understanding of TOTP-based methods requires some type of synchronizing between the code provider and the requestor. I have reviewed some projects, and it appears the time is received to the NFC chip (line 50), but not sure if this is the only way in doing so.

  1. Are there examples of what is received from iOS / Android devices for background reading to initialize communication?

For iOS / Android devices, I’m not looking to utilize any external app and solely rely on native, background reading, and am curious as to what data is available to work with upon initial connection.

  1. Is there any known example of applets updating an NDEF record itself, without needing to re-write, similar to providing a ‘refreshed’ OTP?

Also, if there’s any reference outside of Oracle’s API documentation and example applets that would be useful to review ahead of a project, please let me know :slight_smile:

1 Like
2

The chips have no concept of time. The time that is sent for TOTP is considered by the chip as just data. The applet on the chip uses this data to calculate the OTP code response, but it’s not considered “time” by the chip or really the applet.

What is your goal? Data stored in NDEF format is just stored in memory… there is nothing else going on. To update it, you need to re-write the memory. Since this memory is segmented into pages of bytes, to change data you have to re-write any pages with changed bytes.

Again, what is your project / goal? The Apex Flex has an NFC Sharing application that outputs NDEF data that also includes a CMAC signature which can be validated for authenticity by the VivoKey API (Authenticity API - VivoKey Technologies)

3

Thanks for the quick response - with TOTP, that’s what I understood, but wasn’t sure if there was an alternative way time was able to be processed (rather than directly for a specific function, like a TOTP).

I was interested in seeing the initial data received over NFC from iOS / Android, mainly to see if timestamps were included in the request, to which, i could attempt to use them (though of course that could be forged, etc etc).

The overall goal of the project would involve creating an encrypted byte string that replaces the URI. The “time” part was to both log the interaction on the NFC side, use as part of the encryption / hash process, then create a URI with an encrypted parameter than can be decrypted and verified by the website server-side.

4

In a sense yes, the phone passes the current time to the chip via an instruction to the TOTP applet but the chip itself doesn’t know it’s a “time”… it’s just a data value that the applet uses. Sure you could think of it as time, but that’s a construct that exists outside the bounds of the chip and applet… it could be any agreed upon “salt” data that the applet and relying party (website) agree on. It can even be static and unchanging with each request, though this would be foolish as the generated code would not change.

You might be surprised but the Apex Manager app actually passes two “time” values to the TOTP applet on the Apex in order to calculate two codes for each key… this lets the app display one code and then the next code once the first one expires, without needing to interact with the chip again to do it… we basically tell the TOTP applet the current time, and then the current time + 30 seconds… because after all it’s just data… the chip and applet don’t actually work with this data as a “time”… it’s just a piece of salt data to base code calculations off of… so we do it twice during a single NFC session.

I think you might have some misunderstandings about how to properly leverage encryption and what it means to make something that is encrypted actually safe and secure. I will give an example - I consulted with a company once that was writing an encrypted wallet ID to a simple NFC transponder as an NDEF record. The purpose of this wallet ID was to allow the user to present their NFC token to a vending machine and it would charge their account for food taken from the vending machine. That’s it. There was nothing else happening… the reader on the vending machine would read the encrypted wallet ID and internally decrypt it, then identify the person and their account, then charge the account.

Do you see the problem with this approach?

In case you’re not sure, the problem is that anyone could simply copy the encrypted data from an NFC token to any other NFC transponder and impersonate the victim to the vending machine, stealing food using the victim’s account. The attacker does not need to decrypt anything if simply copying the encrypted data will successfully represent the victim to the target system. Just because something is encrypted does not mean it is in any way secure. There is literally no difference between encrypted and unencrypted data in this solution since the attacker simply does the same thing - copy data and present the copied data to the system - for both encrypted and unencrypted approaches.

I’m duplicate quoting you again here because you’ve explained what your intended solution is, but not your goal. What is your goal? To authenticate into a website using an NFC scan? The technical solution you describe is technically possible… passing a kind of one time code to the website as a querystring parameter vs typing it into some kind of interface. Yes this is technically possible, however your technical solution appears to require some additional things be set up like a shared key known to both the NFC applet and the relying parts for encrypting and decrypting the parameter value in the querystring.

These are really two different things when it comes down to it… encryption of data is meant to result in something that can be decrypted with a shared key or an asymmetric key, while a hash it meant to be one-way only data → hash and not reversible (without a rainbow attack anyway).

Why bother though if the parameter is meant to be a short lived TOTP code that already requires the server and NFC applet to share a key? Presumably the user already had to store the TOTP key during setup / registration, so there seems to be no point in further cryptographic requirements, just pass the TOTP code in the querystring as a parameter.

What is your goal?

I have made some assumptions about what your actual goal is based on the technical solution you provided above. Again, it is very difficult to help if I don’t know your actual goal. Care to share it?

2 Likes
5

First - I very, very much appreciate the time taken to reply.

Please don’t take this the wrong way, but I’m certainly passed the point of knowing the difference between hashing and encryption :slight_smile:

Also, I’m not interested in doing anything with TOTPs or OTPs in general. My example and reference was specifically to handle time, which would be used for the reasons I mentioned (logging, for one, as well as potentially a part of the encryption), and how it writes to memory / refreshes.

To that, I understand the flaws in the approach to the vending machine. This is planned for, with, in a perfect world, time being of assistance in doing this.

You asked for the goal, and it’s simply what I mentioned before. Server-side, should the validation pass, I plan to enable something when a URI is visited. If not, the included parameter is simply ignored. It has nothing to do with payments, or anything that could be mission critical production scenario for my super secret fortune 100 company. It’s simply privacy for myself and anyone else interested in the project (which will be open source, documented, etc).

To further your vending scenario, if the encrypted payload simply held the wallet ID, well, then obviously there would be a problem, as there’s no validation.

Because of this, the payload within the encryption was expected to include (for example) a timestamp, as well as a seed and salted hash of the current time, where, serverside, I could simply ignore payload that was from any day prior to the current server time, ignore any seed that has already been used for the same day, and validate the hash before enabling the piece on the site. I do not necessarily need to perform all of those checks, but, being able to handle them differently would be of interest.

As a general concept, this would mean a user could obtain a link, share it, and it would not work. The ‘goal’ would be to generate these URIs on-device.

Without time being involved, I would be limited in what types of validation could be done. Should the encryption be cracked, I would be limited to unique seeds and salted hashes, which would need to simply be against the seed. This is fine, but, having the timestamps would allow me to log when my device is being accessed, or at least attempted.

I hope the thought process here is enough. I wasn’t looking for anything other than what was in my initial post - if there’s been any creative ways to handle time in other projects, examples of background read NFC scans from iOS / Android devices, or an example on-device written URIs for NDEF sharing :slight_smile:

As a final bit - I already have a pathway for the project that I’m confident with if there’s nothing in the above available. Just was asking to consolidate my thoughts, but not necessary, just an enhacement :smiley:

6

Ok good to know you’re familiar with the concepts so now we don’t have to cover basics.

In short, who are you going to trust as a source of “time”? An app on the phone? The chip has no RTC on board and has no power when not in the field. You would have to pass time to the chip somehow, and this is not really supported in standard NDEF applet interactions anyway. To do it you would need a special app to pass in the current time, assuming you trust the external reader to provide this time data. Then this special app would need to extract the URL with encrypted data from the applet over NFC… at this point you’re better off just abandoning the NDEF concept all together and just going with an app on the phone which will pass time to the NFC applet, get back an encrypted parameter, and have the app construct the complete URI with encrypted parameter… or otherwise push the URI into the chip with macro placeholder for where the encrypted parameter would go and then use an instruction to push in time and get back the completed URI.

Bottom line, “time” is not a good way to do this… this is why our NFC Sharing applet uses counter based CMAC signatures which are validated by our API which produces an signed JWT which RPs can validate. VivoKey provides licensing options if you’re interested in exploring it. For an example of how CMACs work, check out;

https://vivokey.com/api/#elementor-toc__heading-anchor-15

2 Likes
7

Thank you! This project is to specifically utilize background reading, so native, rather than require an app.

I mentioned a few times - I know that I can create an app and send over data, I understand it can be made in a specific request, but this is not of interest due to general accessibility. Specifically, I am looking for what a connection intialization payload looks like when a chip (in this case, a FlexSecure) is tapped.

Per my second ask - if time is included within that initialization request, I can log it - regardless of trust. The validation against the seed will be the main source of protection, the time is simply an enhancement to the general project.

If it’s not included within the initial request received by flexsecure, then there would be no alternative that i can think of that would fit the project. And that’s okay, i was just asking. Not sure if Android includes this either.

8

If you are interested in how Android / iOS natively read an NDEF container on an NFC Type 4 chip like the flexSecure, they follow the NFC Type 4 standard (start there). Basically the first thing the phone does is detect that the chip is an NFC Type 4 chip which means it uses APDUs to communicate, then;

  • Attempt to select the standard NDEF AID (application ID) which is D2 76 00 00 85 01 01.
  • Read the Capability Container by opening file ID E1 03
  • Read 15 bytes from the CC to get info about the NDEF data payload
  • Read the NDEF file ID E1 04 to read the NDEF data

At no point will any native interaction write data or send any information to the chip other than file select and read commands.

It is not included and will not be possible if you are only interested in using native NFC capabilities built into iOS or Android phone operating systems.

As I mentioned, your only option for going native would be to use a counter based system that generates unique signatures for each native read, like the VivoKey NFC Sharing applet does.

9

Read this before I went to bed, and wanted to thank you first thing when i woke up! The type 4 direction and following information is exactly what I was looking for.

2 Likes