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 example.enc.txt
:
oZh+8+GOFTddsIGUx/EiuyQg23x9chPTZRDu1Je/Vdspx09xiIrqCV39KpcDh+fB
dX1OycNMsOCBW1ByHRjDzbtBTnbOA5ckuLnEmE6XxxxJv8fxFTdG6y6S58lULy7v
gvCMswVOdVq33DiK+fvcDm0L4FZi4PKTduymjJ+yqYZWQM0pDikJOcm81mhCVlZc
py2//hj4wzLFW+n7dLzBPQFSn7KXC9mQOjmNdPXoW372tEGNte4sE494SwR6JcaM
rpIMGoj8WTfymSSXFAEjR3hNXpkrFxVozj1e35IPa2LkmN0S1ocgzHvoj4gPrzaY
Now, running:
$ 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
- unix’s
openssl
seems common enough, access to a unix computer should be doable
- unix’s
-
Key is memorizable
-
openssl enc
supports 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?
That’s actually the next thing in the pipeline for it, along with some UI reworking. I’ve just been super busy with school lately (tomorrow’s my last final fortunately). That said, I’m actually gonna try and get the first “alpha” candidate if the Dangerous NFC application rework out before I do anything else to BioCom.
Which part? The multiple record support?
Makes perfect sense starting at 07
I’m not too familiar with PGP. Would I be able to decrypt with only a memorized password? The idea is if I lose my phone (which is my 2FA device) to be able to gain access to my 2FA backup codes. So if I need my PGP keys which are stored on my phone, that defeats the purpose.
Still, wicked app! Lots of cool potential with PGP stuff
I’m mid-finals myself. Good luck!