Authentication in a peer-to-peer enterprise blockchain

Getting your Trinity Audio player ready...

The BSV blockchain manages authentication by its design, and enterprise blockchains which use BSV blockchain can be assured of the reliability, confidentiality and integrity of all data placed on chain.

Ensuring that the correct people can access the correct resources online is critical. Guaranteeing that a computer system, process, or user is genuine and verified means that authentication of that entity is required.

Authentication is critical to ensure the confidentiality of data. Authenticating users enables them to access the data that they are authorised to access. When they are authenticated, users can have access to a range of resources that have been specifically defined for the user to access.

In organisations, users log on to the server to gain access to corporate resources. The authenticating server checks the user’s credentials against its database, checks that the logon credentials match the entries in its database, and its ‘access control list’. If the logon is successful, the account is granted access to the corporate resources the user ID has access to.

Authentication proves the identity of the parties involved. It verifies that each party actually is who they say they are.

So how does authentication work when there is no central authority to grant access to resources and validate accounts?

Authentication can be achieved using Public Key Cryptography (PKC) which enables two parties to have secure communication over an insecure channel. In its simplest terms, the two end points agree on a one-way mathematical formula. The message is signed with the recipient’s public key and can only be decrypted using the private key of the recipient. A simple example of how PKC works between peer A and peer B follows:

• Each party creates a one-way mathematical equation which results in a public key. The two peers exchange their public keys and produce a secret shared by both parties
• If peer B wishes to be authenticated by peer A, peer B will ask and receive a challenge from peer A
• Peer B knows how to solve the equation to reach the public key value as the instructions on how to solve the equation are in the shared secret.
• If a rogue actor—peer C—challenges peer A the outcome will be different. Peer C needs to solve the mathematical puzzle to reach the public key value. Incorrect guesses will not be authenticated.
• The message which is encrypted (locked) with the recipient’s public key can only be decrypted (unlocked) with the recipient’s private key

PKC of course is far more complex than this—but it essentially invokes a mathematical puzzle, a challenge, and a response. Access will only be given if the correct response is received. There is no need for a central authority to validate keys as the peers have each agreed on and authenticated the shared secret. For in-depth information on PKC, read the Protocols for Public Key Cryptosystems paper by R.C. Merkle.

If one user wishes to send something such as data or money to another user, the originator will sign the message with their public key—and the public key of the intended recipient. The recipient knows that the message came from the originator as it contains the originator’s public key. The recipient can decrypt the message as they alone have the private key to solve the puzzle contained in their public key. The variable length data contained in the message is also hashed to provide a unique number for the content of the message.

So how can this be managed in an enterprise blockchain, where message exchanges happen regularly? The enterprise peer to peer network works exactly as originally described in the Bitcoin White paper. Data on the BSV blockchain is stored publicly and signed to demonstrate possession of the data.

Peer to peer transactions are signed and encrypted with a timestamp ensure that all data are secure. As the data are stored in blocks and hashed which form part of a continuous blockchain, which is copied to each node in the network, each block has a list of confirmed transactions which contains authenticated digital signatures.

As authentication and identity is managed by the BSV blockchain, inherent in its design Enterprise solutions on the BSV blockchain can rely on the confidentiality and availability of its data—no matter how many transactions the blockchain transacts. A centralised server is not required to hold the certificate authority for the entire network, so there is no risk of a central entity being compromised. Timestamps hash the items in each block and broadcast the data so that is can no longer be changed from its original form. The data is validated as correct which satisfies governance requirements and lifts any potential showstoppers for enterprise blockchain adoption.

Watch the BSV Global Blockchain Convention Dubai 2022 Day 1 here:

https://www.youtube.com/watch?v=ggbZ8YedpBE

Watch the BSV Global Blockchain Convention Dubai 2022 Day 2 here:

https://www.youtube.com/watch?v=RzJsCRb6zt8

Watch the BSV Global Blockchain Convention Dubai 2022 Day 3 here:

https://www.youtube.com/watch?v=RzSCrXf1Ywc