Hive Authentication Services - Protocol description

avatar
(Edited)

Yesterday, I introduced you to Hive Authentication Services. On purpose, I deliberately did not tackle the technical details of the project so as not to drown the less tech-savvy reader in too much information.



If you haven't already done so, support the project and vote for its proposal on Peakd, Ecency, hive.blog or using HiveSigner

I also invite you to read:


Today we're going to dive a little deeper into how HAS provides its services and interconnect third-party applications and your favourite wallet app which stores your precious private keys.

What are Hive Authentication Services (a quick reminder)?

The Hive Authentication Services (HAS) provide user authentication for any applications, either web, desktop, or mobile. It also allows applications to sign and broadcast transactions to the Hive blockchain without asking their users to provide them with any private key.

How does it work?

Hive Authentication Services (HAS) architecture consists of a WebSocket server acting as a middleware between any Application (App) supporting the HAS protocol and any Private Key Storage Application (PKSA) supporting the HAS protocol.

Beware, the content of the post will now become far more technical. Fasten your seatbelts!

1. Authentication

The initiator is the first peer who requests a connection, usually the App reacting to a login request made by the User.

The application login form will only require the account name (@username). No password will be required.

When the User hit the sign-in button, the App will then try to authenticate them with their Hive account. Here is the diagram describing the HAS authentication process.

  1. the App sends an auth_req command to the HAS.
  2. the HAS provides the App with a request identifier (uuid) and a request expiration time (auth_req_expire)
  3. the App builds an authentication payload (auth_payload) which contains the received uuid, the account name, a session encryption key (key_app) and the URL of the HAS host it is connected to. The auth_payload will be shared with the PKSA off-band using a QR code or deep linking.The App asks the User to start its PKSA and scan the auth_payload QR Code or trigger the PKSA using a deep link when on mobile.
  4. the User starts the PKSA.
  5. the user reads the QR code using the PKSA. This step is optional when on mobile because the PKSA can retrieve the auth_req_payload from the deep link that triggered it.
  6. to securely register the account (name) found in the auth_req_payload, the PKSA asks the HAS for a public encryption key.
  7. the HAS provides its public key key_server
  8. the PKSA can ask the HAS to register the account in order to receive subsequent transactions requests
  9. the HAS validate that the account exists and that the PKSA store valid private keys from the account against the blockchain.
  10. Upon successful validation, the HAS will forward the auth_req to the PKSA. The PKSA should wait for it and match both uuid to ensure the User has scanned the right QR code.
  11. the PKSA asks the User to approve or reject the authentication request.
  12. the User approves or rejects the authentication request.
  13. when the User approves the authentication request, the PKSA:
    • creates an auth_token and anauth_token_expire
    • stores them locally
    • encrypt the uuid with the key (key_app) found in the auth_payload and add it to the auth_ack_payload
    • create an auth_ack_payload with the above data and send it with an authentication request approval to the HAS.
  14. the HAS forward the authentication approval and its payload to the App.

The encryption performed at step 13 is to ensure that a malicious actor operating a HAS cannot bypass the PKSA to approve an authentication request. Remember that the HAS doesn't have access to key_app. Therefore, by matching the decrypted auth_ack_payload.uuid using its encryption key (key_app) with the pending request uuid, the App has 100% certainty that the encryption process was made by the PKSA.

Once the account is authenticated against the App, the application login process can go on et the App will be allowed to sign or broadcast transactions (with the user's consent, of course).

2. Broadcasting Transactions

This part only concerns applications that interact with the Hive blockchain. Following an action by the User within the App, the last one now wants to record a transaction in the blockchain.

Here is the diagram describing the process:

  1. the App sends a sign_req command to the HAS with a valid auth_token.
  2. the HAS check the auth_token and provides the App with a request identifier (uuid) and its expiration time (sign_req_expire) in a sign_wait message.
  3. [Optional] the App shows information about the pending request to the user. It may also ask them to (re)start their PKSA to approve the transaction within the allowed delay.
    Note: the PKSA can be started before or after the transaction request is issued. It doesn't matter.
  4. the HAS then forwards the sign_req command to the PKSA
  5. the PKSA prompts the user to approve or reject the transaction
  6. If the user approves the transaction. (For clarity, transaction refusal is not depicted in the above diagram. See below.)
  7. the PKSA signs the transaction and broadcasts it to the blockchain.
  8. If the transaction broadcast is successful, the PKSA sends a sign_ack to the HAS with the blockchain transaction ID (txID)
  9. the HAS forward the sign_ack message with the blockchain transaction ID (txID) to the App.

3. Signing Transactions

The application may wish to manage the sending of the transaction to the blockchain itself. In this case, it will ask PKSA to only sign the transaction.

Here is the diagram describing the process:

  1. the App sends a sign_req command to the HAS with a valid auth_token.
  2. the HAS check the auth_token and provides the App with a request identifier (uuid) and its expiration time (sign_req_expire) in a sign_wait message.
  3. [Optional] the App shows information about the pending request to the user. It may also ask them to (re)start their PKSA to approve the transaction within the allowed delay.
    Note: the PKSA can be started before or after the transaction request is issued. It doesn't matter.
  4. the HAS then forwards the sign_req command to the PKSA
  5. the PKSA prompts the User to approve or reject the transaction
  6. the User approves the transaction.
  7. the PKSA signs the transaction the PKSA sends a sign_ack to the HAS with the signed_transaction
  8. the HAS sends a sign_ack command to the App with the signed_transaction.
  9. It's now up to the App to broadcast the signed transaction to the blockchain.

About request timeout or refusal

Timeout
The maximum delay to approve an authentication or transaction request is 2 minutes.

This should give the user enough time to grab their mobile and launch their Wallet App (PKSA), if they have not already done so, and approve or reject the incoming request.

Note: the PKSA can be started before or after an App sends a request to process. It doesn't matter.

Request refusal
For clarity, the transaction refusal step was not included in the above diagrams, but the process is fairly simple:

When the user rejects a request:

  • the PKSA sends an auth_nack or sign_nack message to the HAS with the uuid of the request.
  • the HAS forwards the above message to the App

Wrap up

Hope you now have a better view and understanding of what has been put in place with Hive Authentication Services.

The HAS protocol may look complex for the authentication phase, but that's what enables its transactions counterpart to be way more simple but still secure.

In the next article, we'll dive even deeper into the mechanics of the HAS protocol. You will discover how HAS relies heavily on encryption to protect the use of your private keys, to identify various parties involved and to secure the data they exchange.

UPDATE: The HAS Developer Guide - Part 1 is now available for reading.

Thanks for reading.


Do not forget to support the HAS project:


Check out my apps and services


Vote for me as a witness



0
0
0.000
31 comments
avatar

pixresteemer_incognito_angel_mini.png
Bang, I did it again... I just rehived your post!
!PIZZA
8

0
0
0.000
avatar

That is a great insight into the technical aspects of how authentication works on Hive blockchain. Usually, we treat it lightly but is the most important component that puts our mind at ease at night...

Posted Using LeoFinance Beta

0
0
0.000
avatar

Keep up the good work @arcange am really enjoying to see this happening in this platform. It's really awesome

0
0
0.000
avatar

!PIZZA
!BEER

0
0
0.000
avatar

Following this closely for two reasons, it's an awesome feature for hive, but also for the education. These posts are really well explained and accessible. A lot is way over my head but i am getting some good stuff.

0
0
0.000
avatar

Thank you for your feedback @eroche
Education is the key to getting people to buy into a project.
PS: Do not forget to vote for the proposal to support the project. 😉

0
0
0.000
avatar

Pretty and Smart, we should marry this idea.

0
0
0.000
avatar

Congratulations @arcange! Your post has been a top performer on the Hive blockchain and you have been rewarded with the following badge:

Post with the highest payout of the day.

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

0
0
0.000
avatar

Thank you for this post. He sheds light on the structure of the project.

0
0
0.000
avatar

"Where the darkness is, he will bring the light" 💡
arcange, 2021.10.22

0
0
0.000
avatar

Nice job! It looks like the security of the protocol depends on how good communication channels are protected ( I suppose You assumes protection by HTTPS or any other server authentication and channel encryption), otherwise, malicious actors may listen and/or spoof the protocol messages. My question is do You plan to use the Hive chain to hold information about the valid HAS servers and their public keys/certificates, or the system will depend on external certification entities ? I mean the App may ask the Hive Blockchain for a list of valid HAS servers and all the information required to establish a secure connection with them.

0
0
0.000
avatar

Thank you for your feedback @mickiewicz

I suppose You assumes protection by HTTPS

I go much further. HTTPS only secures its communication but not its content. HAS protocol will use encryption extensively to validate the data exchanged between the parties.
It is important that the HAS server itself cannot access the content of the communications. If that was the case, it could easily modify the exchanged data and lure either the application or the Wallet app (PKSA).

do you plan to use the Hive chain to hold information about the valid HAS servers

This is a possible solution, but it is not planned at first.

the system will depend on external certification entities ?

No. The protocol was designed not to depend on any external entity and to allow full decentralization. It will work as we are used to with Hive API nodes. We can even imagine integrating HAS as a microservice deployed on each Hive API node.

0
0
0.000
avatar

Hats off, great idea. Hive has to seemlessly fit in the web.

Voting for the proposal.

0
0
0.000
avatar

Hello @arcange… I have chosen your post about “-Hive Authentication Services - Protocol description-” for my daily initiative to re-blog - vote and comment…
26.jpg
Let's keep working and supporting each other to grow at Hive!...

0
0
0.000
avatar
(Edited)

Super nice diagrams (they help a lot understanding this). I can see already the Hard work behind the scenes... so well done for this.

Some questions from me for each of the steps:

1. Looks all good here. 😎

One request though, even if the QR code is a great way to simplify the validation of who is requesting, it would be nice to have a way to see the IP of who is requesting, to allow users to have a second way to troubleshoot things when they are not making sense.

I am thinking about phishing situations when eventually users get emailed with QR codes in the name of the apps asking for authentications (of course no one should do this).

This IP (or session) validation could be done either at the PKSA side (and visually validated by the user) or using a phishing code as 3rd-step of an MFA (in case you activate it) provided by the library the "apps" would need to use. Effectively stamping that "confirmed" session in the blockchain. Comments...

2. and 3.

How is the user able to understand if the transaction request is from the browser/app/host he/she is requesting/interacting with?

For example, if I use the phone to accept and broadcast a transaction that is initiated on my PC. Is there a mechanism that only allows this after the authentication happens (which I would say, that can either have protection towards the active session, or something like, identify the session with a name or IP)?

I am looking at the same perspective of what I described on the authentication, and I understand that at the same time we want to make this simple for the user. So, maybe either provide a way to identify sessions (if multiple are allowed) or only allow one to persist, forcing the user to first authenticate before going through sign/broadcast transactions.

The scenarios above are probably important for public places where wireless devices can be trying to listen and be also man's in the middle. But I agree for most situations it will not be a problem.

Thanks

Cheers for all this work and the courage to deep dive into resolving this "complexity" problem for the community. Feel free to always tag me on these. My pleasure to support/review/discuss stuff like this. Hopefully, the proposal will go ahead.

0
0
0.000
avatar

Thank you for your comment @forykw

it would be nice to have a way to see the IP of who is requesting

Not sure it will help. When you're on mobile, people often don't even know which IP they use or how to display it, as the "requester" is the device itself, not an app running a remote server.
Moreover, the incoming IP seen by the PKSA will always be the one of the HAS it is connected to.
That being said, the App and the PKSA can display the uuid of the request for the users to match it.

How is the user able to understand if the transaction request is from the browser/app/host he/she is requesting/interacting with?

This will be explained in details in the coming posts. TLDR; communication between App and PKSA is a one-to-one once the user authenticated with an App

0
0
0.000
avatar
(Edited)

Ok, I can wait for it. Maybe in the HiveFest we can chat... easier.

PS: I was not covering people that know how to deal with IPs... but instead the other way around, the ones that don't know and will get "tricked" by people that wish to take the glorious stupid creative path.

Moreover, the incoming IP seen by the PKSA will always be the one of the HAS it is connected to.
That being said, the App and the PKSA can display the uuid of the request for the users to match it.

In normal circumstances yes... but behind firewalls anything can happen. And big commercial buildings have huge problems with these. Most household ISPs will be ok... but when we move to IPv6, this will be uncontrollable. Not something to worry for the immediate future, but something to think about ahead of time and make some "preventive" countermeasures.

0
0
0.000
avatar

Thank you for providing such a level of technical detail on HAS! I am convinced of its security, but what do you think about voting for or against it? Is there any reason not to support this proposal?

0
0
0.000
avatar

Thank you for your comment @catotune

Is there any reason not to support this proposal?

Honestly, I don't think I'm the best person to answer this question as I'm really convinced of the added value for Hive of this project. 😅

0
0
0.000
avatar

Just WOW - great job and a !BEER from me

Will get my vote

0
0
0.000
avatar

Would love to see your idea work. All the technical data above are confusing to me but it looks like it's for seamless and easier transactions. You have my vote :)

0
0
0.000