Slashdot Mirror
The Secure Public Data Repository?
jducoeur writes "So Hailstorm has died an unlamented death. But the demand for the idea of an information repository isn't going to go away -- users demand convenience, and this would be convenient. So here's a timely question looking for wild speculation: how would a truly secure, public data repository work? How would your data be stored? Would it be centralized or distributed? How would you grant access to specific elements within it? What would the business case for running such an archive be? Maybe if we can come up with a good design now, we can head off the next inevitable bad one..."
We already have systems such as SourceForge to handle programs and other CVS systems exist...
My data... public?
I don't think so... I'll buy another 100gig drive before sending it off over the net to a public storage facility..
If I wanted secure off-site storage, I would turn to Sea Land
20 Miles from anywhere and it doesn't respect any court of law in the world... So thats what I call secure (Even from the DMCA).
Okay so what features do we desire that this centralized repository is going to provide us? Presumably it will allow us to specify the amount of data released to third parties, charge fixed amounts without releasing our credit card numbers, and be portable. All of these problems are easily addressed with existing technology.
Specifying how much data is released could be done quite simply with something as easy as a browser plugin. A company would include some code in the webpage to cause a request of certain information that you could then accept or deny. Charging fixed amounts is easily done through schemes like paypal, or even better some sort of digital cash technology. For conveince this too could be implemented as a browser plugin (as it would have to in either case).
The only point where a centralized personal information database has any possible advantage is in portability. Even here though the advantage is fleeting, always on internet access for peoples home PCs is coming so fast that before long simply connecting to your home computer and requesting (possibly with various security levels) your profile will be a viable solution. This is essentially what all of us who ssh to our computers to check our mail are doing.
If you liked this thought maybe you would find my blog nice too:
Secure servers require some type of resources to manage. Microsoft has more resources than most of us can comprehend. However, I still don't want my information stored with them. People don't like Microsoft because they don't like being controlled - and that's what MS does, attempt to control as much as possible in their own interests. So I don't care who has a repository - Microsoft, the US Government, the EFF - the bottom line is that the information is controlled by someone. I'm sure someone will quip in with a statement about some techie solution, like PKI - but that's not the point. You still don't control the information. If anyone in the Slashdot/OSS community advocates a central repository, they are advocating control, which violates every principle that the community stands for. I will take a Microsoft with no reigns (directly, they're only screwing other companies, whose bottom lines I could give a damn about) over a central repository (where I have a *huge* potential for getting screwed, big-time) any day.
The best thing about a boolean is even if you are wrong, you are only off by a bit.
You have many seperate databases with powerful encryption and a hardware firewall. Have a very short list of places that can get direct access. Those places will only be allowed access to the parts they need. Everyone else in the world goes to one of those places to get their stuff.
So you have the central database. This database has different parts to it. One for financial info, one for government info, one for medical information, etc. In the center is a list of general information like name, address, age, phone #.
Now you have a very small #, less than 20, of people who have direct access to this. Each of these places has access to different sets of information. So if one of them provides credit card verification they have access to only the parts of the financial database they need. Then places like ebay and amazon, and paypal go to them to verify credit cards.
Another group would provide medical information. This group would give doctors offices acces to only medical records of their patients. etc.
Now to make it extra secure everything is encrypted with the strongest encryption available. If someone wants to use less encryption or no encryption, tough. Everything on the drives in the central database is encrypted. Public key encryption is used for transmission of data to providers. New keys are made as often as is practical. Data is re-encrypted on their drives. Then sent to the users who can de-crypt only the parts they need (if for some reason they are accidentally sent something htey shouldn't see) and use the information.
Of course all the standard security measures are taken such as putting the central database in a secure location. Firewalls. IT professionals working their 24/7. The works.
This may not be the most efficient design. It may not be a very specific or detailed design. It may be a design that provides a small group of people with a lot of power. However, it is I believe the most secure design. Make a special law about trying to hack it too, that'll make it even more secure. The only problem I forsee is the constant need to up the encryption because of faster processors and decryption methods, and the constant need for end users to update their keys/certificates.
I don't feel like deleting everything I just wrote, but I just improved my idea. End users create public and private key pairs. When they want to put their information in the central database they type their information into a very secure web form and off it goes, along with their attached public key. Now there is a central database of information that only the owner of that information can easily read. If I want amazon to get some of that information My computer will downloaded it, in encrypted form, decrypt the information I want to tell amazon, encrypt that with amazon's key and send it to them. Excuse my language, but ph33r that. Especially if you gave me the ability to change my key whenever I want.
Only problem, getting home users to make RSA 4096 bit key pairs, or whatever the newest one is. That's security for you. Keep your information on someone else's computer, that's already incredibly secure, but only you can read it. Not even the guy who built the system can see what's in it. Except of course for his own info.
The GeekNights podcast is going strong. Listen!
It's difficult to tell what will be the attributes of any method that will exist, but it's not hard to give requirements. I'll use the word "spyee" to mean the person whose data is being stored.
* First of all, it cannot be done without people's permission. Every single piece of info that is stored MUST be there with the spyee's knowledge and consent. If someone wants to store their sexual preference or medical records, etc. etc. let them, but don't reqiure me to tell you my SSN / Credit Card info.
* Second: It MUST be distributed. This is because it can work iff (if and only if) the spyee retains ownership and complete rights to his data. Nobody else can even think for a minute that they own it. Even if they store it. It's paramount that each spyee's info be broken up and different chunks stored on different computers. In this sence, it would work like The Eternity Service (here's even more info) or (my favorite), Freenet.
*Third, Every piece of info must be stored encrypted. Let the user's browser have a session keys. Let the user have a few keys. That way, the user can access his data (with the help of front-end programs) and he can have a stupid form filler, but the company or Skriptkidd1e can't use it.
*This MUST be a subscription service. I believe that it would be far too expensive for advertising to be the source of driving revenue. The storer MUST NOT be able to sell the data, thus depriving him of that form of revenue as well.
*The user can pay the same way as payment worked in ZKS FREEDOM - The user bought an activation number and used it to buy the service - but the end user name _cannot_ be traced to the person who bought it (Hence "zeroknowledge"). It was awesome!
This can be accomplished quite easily, and built in to any UI so that working it requires minimal gray matter. I think that the best way would be to store it on freenet. It takes care of all the above problems, but introduces one of its own: data expiration.
Reply and tell me what you think, this topic is fascinating.
Each time this topic comes back we need to be reminded that any uniform centralized information system is the first thing any "internal security" service puts in place. Why do we need to make it easy for them.
There is a very visible patern there we play with user fear of attack / security to convince them that it would be convenient for a "reliable authority" to store their identity information, etc... and before you know it you have lost your privacy and your freedom.
There are many way of doing this Hailstorm was one but the governement is also playing that game with social security numbers and identity cards.
Secondly, XML is the right way to do this for political not technical reasons. But still use XML.
Thirdly, and very importantly, all information held in the system is (C) the user, licensed under strict contract to the Information Repository to use. This is a protection against somebody buying the system if it becomes successful and changing the terms of service.
Fourthly, information has to be protected in three important ways:
Fifth, no unusual public key cryptography should be used in the system. SSH/SSL yes, PGP/GPG no - this is to protect from the government's ire. Symmetric key ciphers for protecting your own information (i.e. passwords) seem OK to me.
Sixth, two different sites/organizations, both accessing the same data about you, should not be able to tell from that request that they are accessing information about the same person: i.e. if A asks for your DOB, and B asks for it, they should not both be accessing UID234234.DOB. One scheme for this is that "permissions" are given to different organizations, of the form:
HASH (organization_pass_word + your_pass_word + your_unique_ID + index_of_data_you_wish_to_reveal + data_store_added_noise)
This protects your identity and prevents cross-correlation of different databases.
Seventh, the standard should work like email: standard infrastructure can provide a server, anybody can operate one, and you have control of your use of these systems. No single operator.
Eighth, and most importantly, none of this is worth shit without a constitutionally guaranteed right to privacy. Without that, any scheme can be forced over time into revealing more about users than they wish to reveal, either by legal, economic, social or political means.
Strong cryptography is nothing without strong laws, and strong laws are something without any cryptography at all. Support GeekPAC! (the Geek Political Action Committee
vkg.
Hexayurt - open source refugee shelter,
In terms of secure authentication biometrics are only usefull as an enhancement to other authentication means such as passwords and physical tokens (keys, smart cards etc). Retina and Iris scans are good, but not proven to be absolutely unique and equipment is not cheap. DNA could be absolute (hmm what about twins??) but is easily spoofed. Think of collecting a few hairs from someones head. Watch Gattaga. It might be a movie but it presents enough senerios to bypass most forms of biometrics.
Finger print scans on the other hand are a poor form of authentication. Finger print scans suffer from a very high false negative rate. Back when American Biometric existed and were making the BioMouse they were talking about a high secure mode of 1 in 10000 unique fingerprints, and a more resonable operating mode 1 in 5000 or lower. What that is saying is that given 5000 random finger prints (only 500 people!) one finger print will authenticate to the system as a false positive for a specific user. This is a result of a person's finger print scan changeing day to day due to the temperature, the humidity, the person's health, stress, heart beat, etc. If the system was absolutely secure the user would rarely be able to authenticate.
Biometrics are good for some forms of authentication. Biometrics are great for quick and easy authentication where other access control features will mitigate some of the risk, or where strong authentication is overkill. Think of a door lock to a house. A finger print scan would be a quick and easy way for the owner to unlock the door. A burglar isen't going to try to bypass the finger print scan, they will throw a rock though the back window. Similarly for a private office finger prints can be used as other access control features such as a guard at the front gate will mitigate the risk of a couple hundred people walking up to a finger print scanner and trying to get in. When combined with a unique token such as smart card an attack against the biometric authenticator is harder as the attacker needs to steal the token (which should be reported by the owner so that the token is disabled) or the attacker needs to spoof the token which should be more effort then the gain of bypassing the authenticator.
Banks would love to add iris and retina scans to their bank machines. However the cost of the machines is expensive. More importantly the general public is not cool with the idea of lights shinning in their eys to take pictures. This is over and above the privacy freaks who don't want to be tracked everywhere they go. Iris scans are the better of the two by far as they don't involve any bright lights and can authenticate people from a few metres (yards) away. However rris scanners are still a tough sell to the general public.
Regarless of the type of biometrics used it still needs to be combined with a password for truely secure authentication. By today's standards strong authentication combines both "something your have" and "something you know." Biometrics, secure tokens, swipe cards, and cryptographinc keys are all something you have. A password is something you know. If you want the most secure authentication it will involve a password.
The bottom line to all of thins is that biometrics aren't the most secure form of authentication. Biometrics are very convinient. A lot of people would prefer to use biometrics as passwords get written down and forgotten, and physical tokens get lost and stolen.
Most people here are talking about storing personal information on central business-run servers, central government servers, distributed server, servers, servers, servers...
What we really need is a personal storage device that is in charge of handling all your vital information and is carried around on your person. It would be universally accepted at hospitals, drug stores, government institutions, shopping malls, you name it.
Here's what it would look like:
The device would be paper thin and easily carried in a wallet or purse. It would have an adapter to allow you to update information on it from a PDA or personal computer.
The information on the device would be divided up into a couple of different areas, some that are editable by you and some that aren't
- Medical information: known allergies, diseases, physical attributes that would be updateable by the individual and accessible to hospitals. Some of this information would be editable by you, some would be only editable by the hospitals. Copies of this information would be stored at your hospital and would be synched up anytime you visited. If you went to another hospital, the information would be immediately available.
- Credit Card information: accessible to merchants. The card would have a touch pad screen to allow you to select method of payment, you'd swipe it at the POS and the sale would be complete. This information would be editable by the individual.
- Identification: Some of this information would be editable by the individual, like address, phone number, email, etc. Government stored information, like driver's license number and social security number would not be editable and would be used by the government to verify your identity. Swipe the card at the airport and you are who you say you are.
etc...
Now, here's the cool part. The card could only be activated by the individual who's information is on it. When you first receive your card, your biometric information would be stored on it (nowhere else!), which means that unless you yourself are in possession of the card, none of the information on it would be available.
This sytem requires no central repository for information. What is does require is a standard protocol for transferring data. No one agency would store all your information. Standard terminals everywhere would allow you to plug in and verify that you are the person you say you are. The division of information on the device would mean that only the information required by an institution would be available to them. Government bodies would not be able to access your hospital records unless you allowed them to. Merhants would not know your government information unless you specifically provided it to them. When shopping online, all you'd do is plug the card into your computer or PDA and make the transaction happen.
Forget central databases. Put the information in the hands of the individuals themselves.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
You can force any Freenet data to remain persistent as long as you periodically access it. Of course, the data may reside *only* on your node, but it will be as available (to the public) as your node is.
I think that expecting somebody else to make your data available *forever* is an unrealistic expectation, regardless of the technology or circumstances.
Even if I pay an ISP for secure webhosting with backups and everything, the most I can legally require is that they'll *TRY* to not lose my data.
The Web is like Usenet, but
the elephants are untrained.