Post
Topic
Board Bitcoin Discussion
Re: Why I worked on CoinValidation
by
AlexWaters
on 08/09/2014, 19:07:19 UTC
The hashing privacy thing is cool. I hope that a company like Blockscore can implement it.

Going forward, the Namecoin protocol - or something like it - can define systems for identity that mesh well with the needs of US business' KYC/AML procedures. Services like onename.io are compelling, but from a security and privacy standpoint; are far worse than the doomsday scenario people clamored over when the rumor spread that CoinApex was trying to build govcoin.

Here are some criteria I think will serve as a starting point for taking back consumer privacy control:

-Define a protocol for hashing identity information (CIP info like name, dob, social, etc.) so that it can be indexed and referenced
-Have a method for salting it such that the owner of the identity can grant and revoke access to the hash for their information with a builtin TTL for data requests
-Apply this methodology to the extant identity databases (government, public record, private)
-Form a responsible group to advocate for adoption whom are motivated by the interests of individual privacy

Ultimately I believe privacy can be enhanced by orders of magnitude while not stepping on the toes of law enforcement's abilities. Applying some of the basic principles of hashing and salting can help us avoid the current scenario. Here is what some current KYC/AML systems look like for massive corporations (not just bitcoin startups):

-Company A is required to do XYZ crime preventative measure which compels them to collect ABC data from their users.
-The data is neither encrypted nor hashed in the web browsing session, on the wire, or in the database of company A. Sometimes it may be hashed in the database of company A using hashing algorithms which are deprecated due to operator ignorance. Sometimes it cannot be hashed via modern tools because laws REQUIRE that it be hashed via deprecated algorithms (this also happens for government organizations, not just private industry.)
-The data is often tied to financial data such as credit card number, bank account details, or access to balances for online banking, paypal, etc. Giving an ideal target for an attacker.
-Typically the data is cross-referenced with company B. It is often sent without encryption, and in the rare chance that it is encrypted - dated algorithms are used. In the ultra rare chance that modern technology is used, in my experience, the decrypted data is NEVER a hash of the user's private information - it is always plaintext. Company B is cross referencing for company A the plain text private information and not a hashed version.
-Company B responds to company A that the identity pairs with an identity in their system (the matching is far from robust, more of a "it's probably him")
-Company A can proceed with whatever it was they wanted to facilitate for the end user

Need I mention that various company As and various company Bs have different protocols, data sets, etc. requiring that each user needs to upload this private information EVERY time they want to interact with a new company. There are some unified approaches, but almost always come from a centralized company and/or are not used by any substantive percentage of the market.

I hope it is as glaring obvious to others as to why this is a problem, especially as we move more of our finances and identity online.