Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

What is the basic idea?

Server A                            ------------ message ------------>          Server B

www.serverA.com                                                                       www.serverB.com

Public Key A                                                                                Public Key B

Private Key  A                                                                              Private Key B


During a communication, a message is send from Server A to Server B.

Server A sends along with the message its own public key.

Server B receives the message and extracts the public key of Server A.

Server B compares the key with the entries in a public database.

This database contains an entry that “Server A and the extracted public key belong together”.

Now Server B can be sure that the message is really send by server A. The sender is authenticated.

The public database could be a blockchain so we can use basically 2 features.

1.)  A blockchain is hard to manipulate

2.)  A blockchain has an inherent distribution mechanism

How to make sure the SenderA was really the editor of the message (key-to-message binding)?

The sender server A can encrypt the message with his private key.

SS: Then it becomes a problem of how to trust the public key associated with A's private key, and how do you trust that A's private key has not been compromised.  Blockchain could be useful (perhaps) in the trust model, and in the revocation model.

How to enable confidentiality in this scenario?

Server B can sign the answer message for server A with the A’s public key. Therefore, only the right receiver is able to decrypt and read the answer with its own private key.

SS: As above this becomes a problem of how to trust that you know the correct public key for A.  If you trust the wrong key, you encrypt to the wrong recipient.  Again, blockchain could help the model of how to trust public encryption keys.

Open issues / questions

What Consensus model could work in this context?

There could be used a "Proof of Authorization" model. For example when 2 of 3 nodes or even 3 of 4 nodes agree on "ServerA belongs to public key A" the entry is written to the block chain.

Should we use an public or private ledger?

Let's start with a private ledger.


 


Why not using x.509 certificates?

No reason not to include X.509 certificates for the underlying operations.  Where blockchain can make a difference is in the trust infrastructure that X.509 does not fully solve.

  • No labels