IBM punts cryptotastic cloudy ID verification services IBM is marketing cloud-based technology to help consumers better protect their personal data online. The technology – called Identity Mixer – uses a cryptographic algorithm to encrypt the certified identity attributes of a user, such as their date of birth, nationality, home address and credit card number in a way that allows …
Tom Chiverton 1, you don't send your personal details to anyone, they always stay with you. That's the point. If you need to prove you are 21, the credential, which sits on YOUR mobile device or YOUR desktop, tells the 3rd party service, YES, Tom is "21 or older" or just says "Yes". The code answers on your behalf. Get it?
Start by sending all my personal details to a US company, where the US government can do whatever they like with it ? Nah. I'll pass.
Or you could start by learning what Identity Mixer actually does and how it works. (Of course, it'd help if the Reg article weren't so misleading.) The IM wallet can be stored anywhere - the demo is just in the IBM cloud for, er, demonstration purposes. That's right in the FAQ. I know, research is hard. And your personal details aren't sent to IM token consumers; that's the whole point.
Reg readers: Condemning what they don't understand since 1998!
I don't know about the implementation, and specifically the owner, but the concept is something I have discussed for a decade now: Have a trusted place with all your personal details, and share the absolute minimum from it as needed.
Personally, I believe there is no real need for this to be a "cloud" system. It would be better as a personal wallet, with encrypted data signed by a trusted authority. You can choose what to reveal from it, and when, and the third party can verify that data through it's signature. It's a little more complex, but way more secure.
All in all, I believe we need a system of this kind. Think of all the wasted time you spend filling in your details on different sites, often giving out way more information than necessary.
The area I think which could benefit the most from this is insurance. Getting a quote would become a hell of a lot easier! I don't understand why they haven't done this already, unless they want you to make a mistake on your application so they can refuse to pay out in the even of a claim.
The trick will be the trusted authority.
I agree that's always going to be the difficult part.
For the types of assertions discussed in the IM materials, the trusted authority already has all of the information being protected. When the example "eGovernment" authority signs an assertion about your age falling into a given range, it has that authority because it issued your birth certificate in the first place.
So IM can't represent any additional exposure there. It can only improve the security of that information by preventing it from spreading further.
Hi, Dr. Mouse, yes, the concept of a zero knowledge proof has been around for 15 years. The cloud just makes it easier for developers to plug the Identity Mixer code into apps. You can download Identity Mixer from Git Hub today, but as you will see its complicated to deploy.
the concept of a zero knowledge proof has been around for 15 years
True, but it would be more accurate to say that ZKPs have been around for 30 years.
How are ZKPs used in the Identity Mixer protocol? I didn't see any indication of them in the FAQ (and no, I'm not going to watch a demonstration video). This looks more like SAML - tokens are just signed assertions that the requirement is satisfied, without providing additional information.
Don't get me wrong; it looks like a good idea. But I don't see how or why ZKPs would be involved.
Is there a proper article on the technology somewhere?
We get that part. But who's going to vouch for it? IOW, who's going to be Trent? This is currently one of the biggest problems with identity and security on the Net today: the matter of trust and it being subverted. So far as we know, no one's been able to figure out how Alice and Bob can prove their identities without some sort of Trent to vouch for them. Trouble is, who vouches for Trent?
The point of the tech in question here is that Alice can prove to Bob that The Man guarantees that she is above 18 yo, and that The Cashier received payment from her. So now Bob can send a p0rn flick to her but neither The Man nor The Cashier are wiser about her taste of movies.
Of course Bob has to trust The Man and The Cashier.
"Of course Bob has to trust The Man and The Cashier."
And therein lies a big problem. How can one be sure The Man (1) really is the Man and (2) won't use whatever knowledge it's gleaning now against you. We're trying to introduce a system of trust in an increasingly paranoid world: one where the answer for whom to trust is increasingly, "No one, and certainly not The Man."
How can one be sure The Man (1) really is the Man and (2) won't use whatever knowledge it's gleaning now against you.
I can't figure out if this isn't expressed well or is simply an error.
Under the IM protocol the authority is not "gleaning" any additional knowledge about you. It receives a request to confirm an assertion that some detail about you satisfies some constraint (eg that your age falls within a given range). It already has the records that guarantee that assertion.
"Under the IM protocol the authority is not "gleaning" any additional knowledge about you. It receives a request to confirm an assertion that some detail about you satisfies some constraint (eg that your age falls within a given range). It already has the records that guarantee that assertion."
It will know whose credential is being asked (Due to the need to look it up) AND who is doing the asking (Does the asker really need to know this?). That alone can be interesting evidence, especially piled up with other bits of information accumulated over time, and there's no way to be certain this information isn't kept in some way, shape, or form. It may be a breadcrumb, but gather enough of them and you end up with enough to fill a can.
Hi Charles, yes, it comes down to who do you trust. Your local Dept of Motor Vehicles could vouch for you and give you the credentials when you get your drivers license. Or perhaps the local post office can do it. Or it could be an international body like ICANN. You obviously trust your government with your data already, assuming you have a passport or license. Or you trust your credit card company or bank, assuming you have an account.
Problem is, bureaus like DMV have been shown to either (1) leave your supposed-to-be-private info laying around for others to steal or (2) go well beyond their remit and (a) share their data with other bureaus who really shouldn't have it or (b) data mine it themselves to create profiles that leap to conclusions. You can claim it as a necessary evil, but there are those who are starting to think, "Is it?"
In one scenario, the user can take his/her passport to the local Post Office. The post office will verify your identity and they will provide you with the credential on your smartphone. It could also be done by TSA at the airport, local police station, etc.
This will depend on the country.
A well-funded attacker can throw resources at ANY program, audited or not, simply because programs by necessity have a certain structure in order for the CPU to execute them. Plus the attacker will almost always have greater motivation than the original coder to find the exploits. That's why closed sources aren't a good defense and why defenses like ASLR and DEP can only go so far.
Presumably there's some rate limiting in there somewhere.
Identity Mixer can confirm that Alice is at least 12 without disclosing her date of birth and reveal that she lives in the correct region.
Q: Is Alice at least 12?
A: Yes
Q: Is Alice at least 13?
A: Yes
Q: Is Alice at least 14?
A: Yes
Q: Is Alice at least 15?
A: No
Oops....
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
