Pages:
Author

Topic: Bitcoin's Decentralized PKI (Public Key Infrastructure) (Read 7796 times)

sr. member
Activity: 455
Merit: 250
You Don't Bitcoin 'till You Mint Coin
Update OP: 8/09/2012

Looking into the more technical aspect of how to store data on the block chain; so far, I've found these two methods:

1) Uses multiple outputs to send a message (store data). Each output address is data; therefore, the coins are destroyed.
https://en.bitcoin.it/wiki/Block_chain_message_service

2) Transaction with a message inside the script
https://en.bitcoin.it/wiki/Script#Transaction_with_a_message

Mike Hearn makes some good points about the first method that I believe also applies to second.
https://bitcointalksearch.org/topic/m.607667

Also, if I understand correctly, there are other ways to embed messages(data) into the transaction that are less likely to be (pruned) and deleted, but I'm still leaning towards #1.
Here's my reasoning:

* It requires more bitcoin to add data into the block chain when using the addresses in the outputs. Because of all the costs, it should satisfy any naysayer because the creator of the transaction "paid for it". Even if someone doesn't agree with the blockchain being utilized this way; well, who cares, those users burning their coins are making the rest of us more wealthy.

*When the question is asked "What uses does bitcoin have beyond just financial transactions?", you will now have an additional reason to give: pay miners to add data in the most distributed, secure, and accessible database in the world.

*Also, it would still be friendly to those that only want to manage a pruned/trimmed blockchain. As Michael Hearn pointed out, transaction outputs that will clearly never be spent can be deleted with no worry of anyone spending them.

I've also been thinking about adding in the technical document that all the coins used on undependable outputs for "Bitcoin's Distributed PKI" will be available for miner rewards once all the block rewards are finished. A new type of generation transaction could be created that would allow miners to collect those coins based on certain rules. This would give incentive to maintain all the unspendable outputs used in the PKI in the block chain database.
sr. member
Activity: 455
Merit: 250
You Don't Bitcoin 'till You Mint Coin
Update OP: 7/24/2012
 
Still Playing around with the title. Now, the name is just right IMO in describing where I hope this thread and project will go. I had debated about using the word "decentralized" since the name Bitcoin already implies this; however, the implementation of this PKI compared to the majority out there is decentralized in so many ways that I decided it had to be there.

Here's some good material of the technology already out there.
http://highsecu.free.fr/db/outils_de_securite/cryptographie/pki/publickey.pdf
http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Digital_signature


hero member
Activity: 602
Merit: 500
Wow guys....

just came accross that thread, a lot of intriguing ideas.

Just the moment before, I stumbled over this thread and commented:
https://bitcointalksearch.org/topic/m.1043586

Basically what I wrote there fully applies to this discussion here as well...


We should not try to develop "applications" or even "killer applications". This will just carry us away into diversification.

Rather, this topic should be approached similar to the layered network architecture, which was so successfull with the Internet.


Foundation layers.... pick as you see fit. Internet, cell phone, smoke signals, who cares... Wink
Network layer: Bitcoin network + namecoin network or a hybrid / linked approach
Transport layer: this is what we try to put together here

Application layer: basically any administrative / governmental protocol can be built on top.


What would be the service provided by this "transport layer"?  a timestamped, provable, irrevocable administrative act, linked to other prerequisite administrative acts. Note: the actual content and meaning of these administrative acts is application-dependant, just like the actual meaing and specific protocols in the internet are application-depentant.

Certifying trust would be an example for such an act. In most cases, such an act would not happen out of thin air. Rather, it would require some prerequistes, like some kind of "payment", or "title" or "approvement" or some other act provided in exchange.

To repeat my example of the "Anonymous insurance".
You pay and acquire insurance tokens in return.
Some incident happens, forcing you to draw on your insurance: now you contact a survey report service, which confirms the incident/damage and signs a sufficient amount of insurance tokens. These signed insurance+survey tokens now allow you to receive payment by a cooperating payout settlement service.

Note: none of the involved entities need to know and store the full disclosure of what happened.
  • the insurance company can do the bookkeeping, keep the balances sane and calculate the insurance rates, without needing to know anything about what happened to you. It just sees the signed insurance tokens sent back from the payout settlement serivce
  • the survey report service doesn't need to know anything about your finnancial situation. In fact, it doesn't even need to know which is the inssurance company, nor does it need to judge the finnancial consequences of its reports. Yet, the survey service gets its payment, based on the signed insurance tickets
  • similar situation for the payout service. It doesn't even need to know that you get an payout due to an insurance relevant incident. It just does payouts in exchange for signed administrative-act tickets

only you as the customer link together these parts and drive the process. You remain in control. Obviously, these cooperating parts need to trust each other. And this way we're entering recursion....


Hopefully you get my point: any administrative or governmental act could be done in such a peer-to-peer fashion. And the necessary techincal infrastructure is allready there....



sr. member
Activity: 455
Merit: 250
You Don't Bitcoin 'till You Mint Coin
updated the OP (7/19/2012)

Updated the Title
Old Title: Decentralized Identity Management using the Block Chain

Thanks to all for the responses and resources. When I originally had this idea, I had no experience or knowledge of what already existed on the net.
Wasn't even sure what to call it. The Web of Trust was by far the closest to what I had envisioned.
(see http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal_2)

My idea isn't new at all and there's are many similar applications and projects online.

I came across an article today that was a gold mine of information and the first part lay's the foundation to web of trust, decentralized ID system, and others.

Beyond “web of trust”: Enabling P2P E-commerce
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CFwQFjAE&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.15.82%26rep%3Drep1%26type%3Dpdf&ei=lU4IUMPQGsXI2wWqyL3SBA&usg=AFQjCNEPBsAnoUQrgcd1Uj76DUbbVLLriw

I'm considering starting a github repository where the technical aspects of this PKI using the blockchain can start to be formed.

If this is conflicting with anyone's efforts, please let me know. Also, PM me if you would like to be part of the project.
legendary
Activity: 3598
Merit: 2386
Viva Ut Vivas
Perhaps your DNA sequence could be used.

Add an extra digit to distinguish between twins/triplets/etc (1 for first born,2 for second...)
hero member
Activity: 686
Merit: 500
Wat
When there are numerous bitcoin-otc sites sharing trust metrics that will be a decentralized wot.

You simply need to define a sharing protocol between all the disparate sites.

Free market rating agencies ftw.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
btw - in regards to WoT I had previously posted some thoughts regarding using the blockchain here: https://bitcointalksearch.org/topic/idea-a-proposal-for-a-blockchain-based-meta-reputational-system-87339
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
I dont know about that. But i do know Ive never been ripped off using bitcoin-otc.

Sure - the idea of identifying a person uniquely is very different concept from creating a WoT (although it may actually be possible to use the blockchain technology to do both things).

For sure a WoT is the key thing for doing trading with other entities.

Identifying individuals is only critical if we want to be able to support a democratic style of voting in a de-centralised manner (something I think would be an amazing feat to achieve).
hero member
Activity: 686
Merit: 500
Wat
Politicians abuse this by getting dead people to vote. The diebold voting machines dont even use encryption. Heck i would be happy if the government sent me communications via gpg so all I had to do is gpg sign up at the voting booth.

Indeed that was my thinking behind having 2 private keys (one that only the actual person has) - also I guess a registry of dead identities would be required (yes rather impossible with fingerprints if they were burned beyond recognition - DNA?).



I dont know about that. But i do know Ive never been ripped off using bitcoin-otc.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Politicians abuse this by getting dead people to vote. The diebold voting machines dont even use encryption. Heck i would be happy if the government sent me communications via gpg so all I had to do is gpg sign up at the voting booth.

Indeed that was my thinking behind having 2 private keys (one that only the actual person has) - also I guess a registry of dead identities would be required (yes rather impossible with fingerprints if they were burned beyond recognition - DNA?).
hero member
Activity: 686
Merit: 500
Wat
Couldn't this be done with Namecoin? Namecoin is decentralized, cryptographically secure, and can be easily extended to have an ID or voting system.

http://dot-bit.org/Personal_Namespace
http://dot-bit.org/Namespace:Aliases

Interesting stuff (and makes Namecoin look more relevant), however, the problem when it comes to voting is one can create multiple identities and AFAICT this is the #1 problem that is so far lacking a de-centralised solution (hence why I threw out the bio-recognition idea).


Politicians abuse this by getting dead people to vote. The diebold voting machines dont even use encryption. Heck i would be happy if the government sent me communications via gpg so all I had to do is gpg sign up at the voting booth.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Couldn't this be done with Namecoin? Namecoin is decentralized, cryptographically secure, and can be easily extended to have an ID or voting system.

http://dot-bit.org/Personal_Namespace
http://dot-bit.org/Namespace:Aliases

Interesting stuff (and makes Namecoin look more relevant), however, the problem when it comes to voting is one can create multiple identities and AFAICT this is the #1 problem that is so far lacking a de-centralised solution (hence why I threw out the bio-recognition idea).
legendary
Activity: 1708
Merit: 1020
Couldn't this be done with Namecoin? Namecoin is decentralized, cryptographically secure, and can be easily extended to have an ID or voting system.

http://dot-bit.org/Personal_Namespace
http://dot-bit.org/Namespace:Aliases
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Exactly my point actually.... Finger printing is flawed to authenticate identity.. It only shows "significant evidence" you are authenticating your identity with only fingerprint. AFAIK a true fingerprint system would incorporate a Fingerprint, Eye scan as well as a unique password that is unique to the identity but then again that’s for entering secure buildings by that method of authentication becuase as its easy to kill someone and take their fingerprints, eyeballs(eww) and beat the password outta them before you kill them its shouldn't be possible to enter a secure building with a bloddy finger, an eye ball(forget the password) llol

Ouch - am now having nightmare visions of people turning up to voting booths with bags of eyeballs and fingers.  Shocked
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
Deffinatly want to bring your own fingerprint signing hardware Wink

That would just transfer the trust issue to the counter-party requesting your fingerprint to be checked.... s/he would need to trust your device not to be fraudulent.
Exactly my point actually.... Finger printing is flawed to authenticate identity.. It only shows "significant evidence" you are authenticating your identity with only fingerprint. AFAIK a true fingerprint system would incorporate a Fingerprint, Eye scan as well as a unique password that is unique to the identity but then again that’s for entering secure buildings by that method of authentication becuase as its easy to kill someone and take their fingerprints, eyeballs(eww) and beat the password outta them before you kill them its shouldn't be possible to enter a secure building with a bloddy finger, an eye ball(forget the password) llol
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Deffinatly want to bring your own fingerprint signing hardware Wink

That would just transfer the trust issue to the counter-party requesting your fingerprint to be checked.... s/he would need to trust your device not to be fraudulent.

One very interesting technology that comes to my mind with regards to this issue is open source 3D printing (although the possibility of using this tech to create such devices is probably a long way away). Smiley
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Wow... you're mixing 3 different things there. Don't you think it's too messy?

Without a doubt trying to uniquely identify someone and then allow that person (and only that person) to perform a tx in a way that cannot later be deconstructed to then identify them is one very difficult problem (so any solution I think is going to be somewhat messy).

Also, about your idea in particular, I'm not sure you can have the fingerprint in the private key. I'm not sure you can produce a unique hash out of all possible scans a finger can produce*. So, during the validation phase (2), the scanner would not be able to produce the same private key to derive the public key from.
Unless you also provide the original private key to the scanner, besides your thumb. Was that the idea?
If that's the case, and you're really going to trust the scanner like that not to output your private key, then what difference does it make if the fingerprint is a private key or just some hashed data in the public database?

* I'm not 100% sure of that. But I remember I friend who once used a fingerprint validation API, and he had to provide to the API both the scan output and what was saved in the database for the intended person. The API would tell if it matched or not. If it was possible to produce a common hash of all possible scans, then why wouldn't this hash be stored instead?

Also for sure I don't know anything about how actual fingerprint software operates. I was really just trying to put out an idea that perhaps someone else could work out (or perhaps just disprove if what I'm suggesting is not actually theoretically possible).
hero member
Activity: 630
Merit: 500
Deffinatly want to bring your own fingerprint signing hardware Wink

That would just transfer the trust issue to the counter-party requesting your fingerprint to be checked.... s/he would need to trust your device not to be fraudulent.
hero member
Activity: 630
Merit: 500
How do you limit a single ID to a single person?

One idea that came to my mind was the following:

SHA2( fingerprint information ) == private key 1
SHA2( some pass phrase or personal info ) == private key 2

1) Import the private keys into your wallet then send perhaps a specific BTC amount to both addresses (the sending could be done from anywhere to hide IP). The purpose of this is to be able to find the public key of all registered voters (and to be able to prove you have registered to vote). Also to ensure that no other public key #2 can be used with public key #1 (i.e. identity theft).

2) To prove identity a fingerprint scan would be performed and then public key #2 would be determine from the registration txs in the block chain (of course you need to trust that the device checking the fingerprint only actually outputs the public key and does not keep the raw data and that you were not photographed using the device, etc.).

3) A voting token (say BTC0.001) is sent in a tx that will require two sigs (for the 2 keys).

4) Some time later (and most likely at a different physical location) you can "spend" your vote.


Wow... you're mixing 3 different things there. Don't you think it's too messy?

A decentralized voting system != decentralized OpenID provider (this topic) != decentralized currency.
AFAICT there's no advantage on making them all be the same system, only disadvantages. I'd recommend sticking to the unix principle of doing just one thing and doing it right - and making things capable of cooperating. The decentralized voting system could eventually use OpenID for authentication, and both p2p systems could eventually use bitcoin to provide monetary incentives to their users.
But they are all different systems, with different applicabilities.

Also, about your idea in particular, I'm not sure you can have the fingerprint in the private key. I'm not sure you can produce a unique hash out of all possible scans a finger can produce*. So, during the validation phase (2), the scanner would not be able to produce the same private key to derive the public key from.
Unless you also provide the original private key to the scanner, besides your thumb. Was that the idea?
If that's the case, and you're really going to trust the scanner like that not to output your private key, then what difference does it make if the fingerprint is a private key or just some hashed data in the public database?

* I'm not 100% sure of that. But I remember I friend who once used a fingerprint validation API, and he had to provide to the API both the scan output and what was saved in the database for the intended person. The API would tell if it matched or not. If it was possible to produce a common hash of all possible scans, then why wouldn't this hash be stored instead?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Are you sure? AFAIK fingerprint scans do not always produce the same string of bytes. Each scan produce a particular "image", and there are algorithms that allow you to compare two different images and tell with a high certainty whether they were produced by the same finger. I guess all biometric scans (retina, DNA etc) work like that actually.

So, if all that's public is a hash of the fingerprint, unless you're really lucky to get the same string that was used to generate such hash, I don't think you'll be able to locate it.

Yup - for the key to be useful to identify a single individual the actual "fingerprint" would in fact already have to be some sort of hash that would be used for comparing fingerprints (rather than the raw scan data which of course would vary).

I was assuming this is how fingerprint DB's for forensics worked (but must admit I haven't researched it at all).
Pages:
Jump to: