Apologies for the delay; I’m holidaying in the remote wilds of Exmoor at the moment!
Thank you for adding NTAG216 support - I’m now using it successfully with a xNT / NTAG216 implant.
So before I left home; I quickly soldered some dupont cables to my M0 so I could do some testing with this from my laptop whilst away. Just sat down to test and it is working great, I followed the various documentation dotted around and so far I have tested two modes:
No password stored in array or on chip (so it prints out the UID).
Password stored in the array
And I’m happy to report both of those modes are working beautifully for me with this setup on a xNT / NTAG216 implant.
I’m looking forward to trying out the third-mode soon by writing and storing a bespoke password on my implant and then reading that.
I have an idea I will run by you soon @Zwack regarding the password-array mode, I can’t code like you can (I’m a beginner!) so I’m hoping you might be able to tell me if it would even be possible or not. I’ll post the idea soon.
So my idea to expand upon the password-array mode you have built in - whilst I love that capability, the paranoid in me knows that the password is stored in plain-text within the code on the Trinket M0.
In the unlikely event it was stolen; most thieves would be oblivious to it, so the password would be very unlikely to be extracted and stolen from the M0’s memory I would guess. However, would it be possible to obfuscate or encrypt the password within the code so it is actually hidden from view entirely from a more informed attacker. My idea is that your code would use the input (password or UID from the RFID chip) as the decryption key to unlock the encrypted password that is stored in the array.
I fully appreciate that you have taken to steps to try and make this easy to use and adjust for people which is great, it is already very versatile and I think the design is great so thank you. I also appreciate that if a user wanted this higher level of security I’m talking about they would have to be savvy to the process and jump through extra steps, like passing their password through some algorithm or process which would do the obfuscation/encryption for them of their password and then they would take that output and drop it into their KeyboardWedge.ino code. This could potentially be considered a new “mode” perhaps.
It sounds like you’ve got plenty of coding experience, so hopefully you’ve had some prior experience working with encryption. I have zero experience with encryption from a coding point of view, but I feel I have a good fundamental knowledge of how it works and have used various different forms of it. This is just a rough idea I had and I was thinking of it a little like a public / private key-pair, the public-key being the one held within the array in the code on the M0 and the private key being the one held on the user’s RFID chip or implant.
Does that make sense? And do you think it is plausible?
Thank you for your time and efforts on this project, I will be following closely and doing what I can to help with testing and adding to it if I can. I can also help with 3D printed case designs when I return home.
Just store a random key value on the reader, and the XORed sequence required to regenerate the ASCII password on the tag. It’s basic secret key encryption.
Of if you don’t want to store anything on the reader, use the tag’s UID as a key. But then it becomes plain obfuscation rather than encryption.
Got around to testing the third mode (retrieving the password from stored data on the chip) but I’m struggling. I can reliably write and read the data but I fear I may be storing it in the wrong format perhaps?
I’m using the paid version of “NFC Tools” on iOS and it lets you write dozens of record types, I realise most will be proprietary but I was hoping the simple text options may have sufficed, I’ve tried:
Thanks for sharing the other thread, I will take a look.
I just thought with this particular project if it wasn’t too technically challenging then it might be good to mitigate a potential risk - at the moment if one mode is used numerous passwords can be stored in plain-text on the reader, so if the reader was stolen they could be extracted by someone competent and in-the-know about the setup - if that risk can be mitigated easily then why not?
Unfortunately I am using a Proxmark3 to set the password /0 is a null byte and I am not sure if NFC Tools can write that I’ve never tried.
I need to add a password setting option using the same hardware, I am just not sure how to make it easy for users. I would have liked to use the MSC mode but that seems to be complicated on the Trinket M0.
I’m all about mitigating risks! I like this very much, I see the value.
I just think we’re too late with these ideas, as a really secure alternative is just around the corner.
You could do something similar with Sparks and the KVP API already and you can just manage passwords on the Apex later.
If you have access to iOS I don’t mind gifting the Pro Edition of NFC Tools to you.
The Pro Edition of NFC Tools can “Edit Memory” it reads all the memory in a very raw form by the looks of things and allows you to adjust it, but I can’t say I know what I’m looking at in there. It is a bit like this (this is someone else’s screenshot however):
And only £2.49 to upgrade from the Standard to Pro Edition, not too badly priced either. I feel like it gives me the access I need - I just don’t know enough to know what areas I should be editing for this particular project there looks to be hundreds of memory entries in my list.
If you wrote that data block as ascii to the chip then you should be able to fix it with the edit record. The other thing to make sure is that you have removed the UID from the internal password table. It actually checks the UID first as that is faster than scanning though the chip for ZPKW.
Thinking about it, being able to obfuscate the password table will only give a false sense of security as the code itself for de-obfuscation will be right there in the publicly available code.
Perhaps a better option would be to have a single entry table containing just the password, but each entry is encrypted with the relevant UID. Thus the scan provides a UID which is used to attempt to decrypt each password until it finds one that decrypts.
Yeah I’ve made sure to remove my UID from the password array. Unfortunately I’m still not having much luck. I don’t know how to convert the text/record type to ascii, I have tried.
One also thing I’ve noted after writing the ZPKWxxxxxxxxx\0 record with three different pieces of software in text-mode none of them are being recognised. I think one or more are potentially writing it in UTF-8. Would it be possible to make the code parse both ascii and UTF-8 in order to improve compatibility? As I say I’ve tried writing the record with three different softwares, I’ll post a couple of screenshots of the record types:
Just wanted to say, that I appreciate the design for this keyboard wedge
I am going to get an xSIID implanted next week and I am looking forward to using this.
Spent today looking at a couple of options for mass storage class USB devices (not going to be happening at the moment) and cryptography for the encrypted password table.
I decided not to use cryptography for that password table for two main reasons.
Any decryption key would be on the device anyway so it’s not going to be worth the extra computation.
Rather than including an extra library I might as well just obfuscate the password by XORing the password with the UID as suggested by @anon3825968. (Repetitively if necessary).
As for the option for writing the password to the chip, I think I will use the USB serial port rather than a mass storage device class. Connect to the USB device, it will prompt you for a password, ask you to repeat it and then assuming they match will write it either over the old password or find a blank space and add it to the chip.
there looks to be hundreds of memory entries in my list.
