- Unsupervised Learning
- Posts
- A Secure Physical Data Transfer Protocol
A Secure Physical Data Transfer Protocol
[ UPDATE October 27, 2016: This should be done via secure NFC like Apple/Samsung pay, not through anything visual. Gross. But like I said, it was a quick idea. ]
I mostly hate the doctor’s office because it physically infuriates me to fill out paperwork—especially since it’s mostly the same data over and over.
One for the doctor’s office itself. Another for the agreement. Another for the insurance update. Oh, and make sure you fill out your name, social, and address on each of them.
Right then—I’ll sleep well knowing you’re on the case.
Writing one’s name, over and over, on physical paper, using a pen, should be the new official pastime of the Society for Creative Anachronisms. Only, it’s not creative.
Concept
Keeping in mind I only had this idea a few minutes ago, and it’s not vetted at all, here’s what I want to be able to do:
I walk into a doctor’s office and they ask me for data.
I pull out my device, and open my Personal Data Application.
It shows me all the fields I have enabled, but not the data itself, e.g.: First Name, Last Name, Address, Phone Number, Social Security Number, Insurance Provider, Etc.
There’s a checkbox next to each of these fields, and I simply tap each that I want to share with them.
It creates a pattern on my screen that they then scan.
They scan it, and it prompts me for authentication.
I authenticate with a password, voice password, thumb print, etc. on my phone, which confirms I am allowing that data to be transferred.
In less than a second the data is tranferred and the transfer mechanism itself is rendered inoperative forever (see below), i.e., there’s not an artifact of this transfer (other than the data now being in their system as it would have eventually been anyway) that can be intercepted and stolen.
Security
Yes, it does. But getting in an automobile is the stupidest thing you could possibly do, yet we do it every day. Also, do remember that the existing alternative is to have physical copies of this data all over creation, which, by the way, has been entered into numerous electronic systems already. That pee is already largely in the pool.
Also, I hate filling out paperwork. Not sure if I mentioned that.
That being said, yes, everyone having this app on their phone in an insecure way would be a trove for attackers, and would increase the risk to the data. So let’s think for a moment how we could potentially secure it. I’m not saying we can, or that it’s a good idea, but let’s just explore it.
SPDT (Secure Physical Data Transfer)
Here are some initial thoughts on the protocol:
A visual scanner that reads something like a QR code that actually contains your data. Downside: anything catching your image permanently has your data. No thank you please. Unsupervised Learning — Security, Tech, and AI in 10 minutes… Get a weekly breakdown of what's happening in security and tech—and why it matters.
A visual scanner that reads something like a QR code, but it’s actually just a link to the location of the data you’ve prepared, and where additional authentication occurs.
Ok, how about that. How about the phone is the server, and it must authenticate the client. So we’re not using a cloud service (who’s going to upload all their data there and trust it without major marketing, inertia, etc.). But instead the phone is presenting an ephemeral glimpse into the approved fields, which an authorized client can pull from temporarily.
Ok, so, PKI. The doctor’s office has a wireless network that the reader is on and your phone gets on as well. It’s encrypted. You do the steps above, and when their reader scans it, your app has already authenticated their reader using PKI as an authorized reader of your data. They can present a public key, which is signed by the provider (CA), your app sends them an auth token encrypted with that public key, and the reader responds with that token, plus a new challenge, encrypted with your public key. You can now talk.
Then, you flash your barcode, which is just an obfuscated URL (highly randomized and highly ephemeral), that points to your phone. Once it hits your phone endpoint, it checks the identity of the requestor (the PKI token), and your app’s server then shows only those fields.
The last step of the auth (before the last bit above) is a second factor for (both sides?) (optional, defined by policy), which has you enter authentication (thumb, pass, pin, etc.) for the transfer to work.
Your app then immediately displays a green checkbox “Secure Transfer Complete”, and your server is shut down. This all happens in like a second. And the app isn’t even holding unencrypted personal data until the authenticated request hits the listener and you authorized the exchange. Total time of unencrypted data being available is less than a second, then it goes back into the vault within the app.
Oh, wait! How about a shared passphrase between the attendant and you. So you walk up and they show you the reader, and they say, “Short car sniffle.” where nobody can hear it, and that’s what each of you type into your respective sides (plus your thumb print or whatever). The key here is that it’s super quick, but that extra PHYSICALLY shared information is part of the auth protocol, and is required for your app to even decrypt the fields for presentation.
This keeps the data on your phone and not in the cloud, and it also means that anyone capturing the display code on your phone don’t have any data because it was only a link to a random window that required strong authentication and has long since died.
Ok, had another idea, there’s another component of the physical nature here. There’s a randomly generated local code that is gathered by the server, that can only be pulled in person. This is an additional seed for the authentication protocol. Could be a pattern displayed randomly. Could be a shared secret calculated like the verbal phrase, etc. The point is that it requires that the customer actually physically scan it with their device to kick it off, and that it cannot be captured by those around them.
Hmm. Will think more about it. Ideas welcome.
Notes
The data could be stored as discreet tokens as added security, i.e. an attacker with access would not have the relationships between the data elements. Basically, a list of valid socials is far less valuable if they’re not mapped to people. Same with addresses, etc.
It’s my belief that this type of thing is inevitable, as this type of data is not possible to keep private anyway in the future we’re now entering. Meaning, people will become more likely to go for this convenience since 1) the data is out there already, and 2) it’s not as catastrophic for people to have that data as it used to be.