If I get an xSIID, can I store a link or vCard that will automatically open, and also more arbitrary plaintext data? (I’m thinking of storing hand-encrypted backup/restore codes for my online accounts)
theoretically, yes. In reality, it depends on NDEF implementation / how hard it is to recover those codes. You can either add a NDEF record with a plain text type and hope the phone opens the first record automatically, or you can manually write data near the end of your tag (idk if that breaks NDEF storage, I could probably try it)
Assuming this is the xSIID, you could store the data in the 2nd kB of data, since that is not supported for NDEF records.
Do you have an example string (mainly length / number of them) that you want to store? I’m happy to try stuff out on my NTAG I2C test card for you.
Oh, and final question - are you an iPhone or android user?
Thanks for the reminder.
I really should get one of Amals NTAG I2C cards to add to my collection…
Thanks for the reply! I’ve seen you around on here sharing a lot of a brilliant info in understandable ways. Appreciate that
Yes, this would be the xSIID. I’ve read about that 2nd kB of data that’s inaccessible by NFC readers. But this still be read and written? What exactly is the capability of the 1st kB that the second one doesn’t have?
Let’s say my example string to store is something like:
Binance: CEHNTOEBJSAJSMVQ Facebook: 9083097845 34875983475 3847583745 93485345 GitHub: ed4ac-92ba3a 4b982-cd2a89 Google: 2857 8838 1002 3948 Instagram: 2857 8838 2857 8838 2857 8838 Patreon: sa8e-e83e-bceb-39ee Reddit: 847774 9294311
(note: these are all fake)
Maybe a bit longer. Under 1,000 UTF8 characters seems doable for what I want to do. (I still have to figure out how to encrypt though, hopefully that won’t add to the character count.)
And then let’s say I want to have an NDEF record on the chip as well, that I can put a link to my website on, or my WiFi info.
I’m an iPhone user.
Could you test a setup like this? That would be amazing!
It would awesome to be able to read and write data to the 2nd kB because the recovery data I need is just plain text that doesn’t have to be NFC-enabled, as long as I can access it in an emergency (e.g., using an app I could download on a friend’s cell phone).
Thanks for the help!
Or just use something like popl and you can change everything on the page and leave the static url on your chip
This is where shit gets kinda murky - NFC support for iPhones is a relatively recent thing, so idk how easy accessing that 2nd kB of data would be. Personally I’m an android user, but I do have access to iPhones (with thick cases… idk if I can actually use them very well )
This is quite complicated, and has kinda changed over time / as DT has changed how they program the implants in the factory. The short version is that the chip has been setup (for newer stock) so that only the first kB (actually 872 bytes) is usable for NDEF storage, due to no current phone app / system properly reading more NDEF data than that from a chip of this type.
Going back to the first part of this question, you can still read and write the 2nd kB of data, just not as / using NDEF. I had the same question, but I have experimented on the test card and yes, the 2nd sector is manually writable.
Now for the other part of this: the actual implementation of storing those strings. The first thing is that you may want a delimiter (specific character / data which signifies the end / start of a string) - this then requires more space as well.
You also need to decide whether you want to ‘remember’ the data format, or if you want to make it very obvious - e.g. storing Instagram, Reddit, etc. with the strings. Same with a delimiter - you could use the ASCII / unicode for space, or newline.
Then we get into encoding and encryption:
Encoding is the easier one, with the most obvious being the ascii / unicode numbers represented in hexadecimal. This is basically storing it in plain-text, which if you’re storing the corresponding sites with the strings, is a bad idea.
You mentioned encryption, and this is probably a very good idea. The challenging part is that most / many only focus on letters, not a combination of letters and numbers.
Something kinda between encryption and encoding is increasing all ascii codes by a set number, though this is relatively easy to decode / easy to pick up on.
For testing purposes, I’ll just try it plaintext, with \ as a main delimiter for different sites and / as a code delimiter.
Testing with plaintext is fine, I can encrypt any given string (including newlines to delineate individual codes) as ASCII using
$ openssl enc -aes256 -e -in example.txt -a -nosalt
(assuming a file
example.txt containing the example in my previous post).
Putting the output of this into a file,
$ openssl enc -aes256 -e -in example.txt -a -nosalt > example.enc.txt
and entering an example password, let’s say
dangerous when prompted results in a file
oZh+8+GOFTddsIGUx/EiuyQg23x9chPTZRDu1Je/Vdspx09xiIrqCV39KpcDh+fB dX1OycNMsOCBW1ByHRjDzbtBTnbOA5ckuLnEmE6XxxxJv8fxFTdG6y6S58lULy7v gvCMswVOdVq33DiK+fvcDm0L4FZi4PKTduymjJ+yqYZWQM0pDikJOcm81mhCVlZc py2//hj4wzLFW+n7dLzBPQFSn7KXC9mQOjmNdPXoW372tEGNte4sE494SwR6JcaM rpIMGoj8WTfymSSXFAEjR3hNXpkrFxVozj1e35IPa2LkmN0S1ocgzHvoj4gPrzaY
$ openssl enc -aes256 -d -in example.enc.txt -a -nosalt
should output the text of the original example!
I think this all means that if I can write plaintext to the chip, and retrieve it later, I can achieve my goal! To reiterate, my goal is to store recovery codes for internet accounts in xSIID memory, encrypted with a passphrase I store in my brain, so I will never lose them and be able to access my accounts in case of an emergency where I don’t have my phone, computer, or other 2FA items.
Requirements for this system to work:
Method of reading data off chip is ubiquitous enough
- I need to be able to do it within about a day if I lost my phone/laptop
- Downloading an app onto a friend’s phone, for example would be appropriate
Method of decrypting data on chip is ubiquitous enough
opensslseems common enough, access to a unix computer should be doable
Key is memorizable
openssl encsupports generation of keys from a password so I can choose whatever password I want and memorize that
As long as requirement 1 is met, I think I’m good to go!
So I’ve just tried reading the data back using raw commands with NFC shell, and apparently it doesn’t like reading more than 63 pages of information continuously using the FAST_READ command. Still, you can use multiple FAST_READ commands to read all of the data that you want.
The commands I used to read back the data from sector two, having stored the data starting at page 07:
C2FF 01000000 3A0745 3A4656
A brief explanation:
- The first two lines select sector 1 (the 2nd kB of data) - C2 being the sector select command, and 01 being the sector to select
- The third line uses the FAST_READ command 3A to read data from pages 07 - 45 inclusive
- The fourth line the reads the remaining data from page 46 - 56
This is so awesome! Thank you for testing this for me!!
Can you share how you loaded on the data using the NXP app? (Maybe this is super obvious I’ve just never used the app before.)
As for requirement 1, though:
Method of reading data off chip is ubiquitous enough
This is where it gets interesting… I don’t think the NXP app, even on Android can load the data. Personally, I used raw page write commands with NFC shell on my OG Pixel.
Since manually converting every character into those commands sucks I used a short java program, because that’s what I’m comfortable with. I’m probably gonna try to port it to JS on a website and I’ll host it on netlify / github.
Here’s the start of the commands so you can see what it looks like:
C2FF // Change sector 01000000 // Sector 1 A2076F5A682B // Write to page 07 6F 5A 68 2B (oZh+)
Full command list
C2FF 01000000 A2076F5A682B A208382B474F A20946546464 A20A73494755 A20B782F4569 A20C75795167 A20D32337839 A20E63685054 A20F5A524475 A210314A652F A21156647370 A21278303978 A21369497271 A21443563339 A2154B706344 A216682B6642 A2176458314F A21879634E4D A219734F4342 A21A57314279 A21B48526A44 A21C7A627442 A21D546E624F A21E4135636B A21F754C6E45 A2206D453658 A2217878784A A22276386678 A22346546447 A22436793653 A22535386C55 A2264C793776 A2276776434D A2287377564F A22964567133 A22A3344694B A22B2B667663 A22C446D304C A22D34465A69 A22E34504B54 A22F6475796D A2306A4A2B79 A23171595A57 A232514D3070 A23344696B4A A2344F636D38 A235316D6843 A236566C5A63 A2377079322F A2382F686A34 A239777A4C46 A23A572B6E37 A23B644C7A42 A23C50514653 A23D6E374B58 A23E43396D51 A23F4F6A6D4E A2406450586F A24157333732 A2427445474E A24374653473 A24445343934 A24553775236 A2464A63614D A2477270494D A248476F6A38 A24957546679 A24A6D535358 A24B4641456A A24C5233684E A24D58706B72 A24E4678566F A24F7A6A3165 A25033354950 A25161324C6B A2526D4E3053 A253316F6367 A2547A48766F A2556A346750 A256727A6159
Very exciting! Happy to help if you’d like.
So writing/rewriting the secret info to an implanted chip will be a kind of hard (location android phone, run script, send commands via NFC Shell), but reading it will be much easier. Better than the other way around!
Is there a reason you start writing at page
07 of sector 1?
If you’re looking for an easy way to encrypt/decrypt NDEF on android, I made an app a while ago that does that very thing with OpenPGP APIs. So you can store text in this form:
And then on scan of that encrypted tag:
It will decrypt with your PGP keys through the same app. You just need to also have the OpenKeychain application installed with a keyset made. Just in case you want a different way to store your secrets:)
I use it constantly, with it only taking about 3 seconds to encrypt or decrypt text.
Mainly safety… if the change sector command fails, then it won’t try to overwrite the TLVs in page 4-6, the CC in page 3? and page 0-2 with UID etc. You can start at 0 if you really want / are certain you have a good coupling
This will need to be confirmed with an iPhone, but certainly with an android phone, yes
That’s a very nice looking app! I’d certainly give it a shot
@identity is an iPhone user though (which means they might not even be able to do my way)
Ah, didn’t catch that. It really is a pain to get as much functionality out if these little buggers through iOS.
Is there any chance your app could be modified to support second sector data? Or does it support the NDEF record not being the first one?