hey everyone,
last weekend, I was putting together a few strawman ideas for a MIFARE DF EV2 focused android app. At the most basic level, I am hoping to write this app to do the following things for me:
“Simple Read” and display card info - i.e., no PICC level or App level authN
Provide user an ability to supply PICC Master Key or passphrase, select the encryption type and optionally save it encrypted locally on the device (with fair warnings).
“Advanced Read” Give the user the ability to apply the PICC Master Key (from #2) and read card PICC settings, and App structure and files.
“Advanced Write” ability to change PICC level settings and reset to default Master Key - so long as the card is not locked out. Including ability to change settings such as “read w/o PICC” etc.
“Create App” - Open and Secured options. At this time creating files
I am not sure if and how fast I will be able to complete this app, but could be a good first foot in the door to build something w/ xDF2. There seems to be a gap in apps that allow users to do steps 2, 3 and 4. I could be wrong.
I want to socialize this with you all and seek your input; does this idea fall under a “fill gap” app, something you’d use or any suggestions. No wrong answer.
I have had a flexDF for a few years. I haven’t found a compelling use case for the advanced functions, but if you figure something out I would definitely give it a try. I just use it for the increased storage capacity and read range
I have been pondering over why I would ever need to change the default PICC / App level keys and settings. I self-trained to think that there are pieces of data that I dont care if people gain access to in “free-form” unsecure manner. While there are a couple of immediate use cases where I could put a authN layer to access. Examples include:
I use Microsoft Authenticator app for 2FA - quite a bit. I want to be able to share the authenticator’s setup application/key value pairs across devices. Yes, I can use the “live.com” backup feature for this. But, I also want to have those apps/key value pairs in a secured location. What better place to stow them away than in xDF2. Yes, it will be a challenge to squeeze all of them in w/i 8K.
I also want to be able to store my BitWarden’s Master Key and app setup backups inside of xDF2 in a similar manner.
as you all might agree, at some point, I will run out of space, so it becomes bit-minding game - perhaps store compressed ? and have the front-end android app, be knowledgeable enough to decrypt the bits - kinda dehydrate/hydrate operation.
Potentially you could use a second implant with the hash for the first one. 2²FA! Maybe use a spark + DF or even just the uid of another implant as the key.
(Disclaimer: I don’t know what I’m talking about, find a large grain of salt)
good question @Pilgrimsmaster. There are good number of mutually common denominators between the two types of chips. With that said, I don’t have a DF EV1 to test. Consequently, for this first iteration, shall try to focus on DF EV2. But, you do bring up good point to at least design the app in such a way that it could be configured to work with DF EV1. I will keep that in mind as I get started. Thanks for the nudge.
hey guys - wanted to share a very first “lame” wire-frame of the app exhibiting the “Step 1” idea when the app is first opened by the end-user. “Step 1 == securing access to app”.
Absolutely bare-bones idea at this time. Would love to hear any constructive feedback.
I am planning to use AES-128 encryption when generating and encrypting the access codec. AES key requires to be 16 bytes. The app will right-pad fill with (byte) “0x00” to ensure there are 16 bytes for the encryption to work. I will need to better wordsmith that screen.
“app 3.16” is the current project code name - something for me to ponder over.
A little bit about the workflow of using the UID component of the secure codec. At first, I was thinking about having the user manually enter a UID or scan a card/chip implant. However, I think it is a better and more secure experience to scan the card/chip while Step-1 and then also while login operation back into the app. I plan to storing the access codec in the supplied card/chip as an “application” with read/write/update rights. I will need to wordsmith the screen so the user is aware of this before I seek the consent (step 1 screen).
Suggestion… make it 32 characters and make it hex and put the padding in there to start so it’s all visible and totally clear what byte values are being written where. The idea of a keyboard being able to enter the entire range of possible byte values as ascii characters is bad (I learned this with the dangerous NFC app) and also making choices for the user (padding) leads to different apps making different choices for the user and becoming incompatible (like NFC tools and tagwriter are for ntag216 passwords).
thanks for the input. The purpose of the very last screen is a “review” screen that shows the fully formatted (padded) key. You could enter as few chars as you want and the app will do the formatting. To make things easier for user to remember the key is to allow them to use a free-form text (non-hex even) and then convert that free-form text to Hex and then pad it to fit 16 bytes. Might become clearer when you all will see a short video demo of the app. Soon to come.
hey everyone, just another quick update on the wire-frames for the Step-1 / “first-things-first” workflow. Thanks to everyone who provided their feedback during the iteration 1 of the wire-frames. I would appreciate any further feedback should you have. Thanks everyone.
No demo worthy app quite yet. but, hoping to work on it early tomorrow (sunday) morning.
