Service Mode

Running your own PKSA enables developers to perform tests in a safe and peaceful environment.

For the more paranoid users, this is an option that allows them to benefit from the advantages offered by HAS while maintaining full control over their private keys.

A "Service Mode" PKSA is software without a user interface running on a computer connected to the internet and waiting for authentication and transactions requests.

The applications and the PKSA must connect to the same HAS server to be able to communicate with each other.

Depending on how you configure it, it can register the account(s) you want it to manage without processing an offline authentication payload.

Your PKSA can then store and provide your App(s) with a valid authentication token. It can also (automatically) approve transactions requests coming from your App if you enable it to do so.

About security

If you want your PKSA to run as a service, you will have to take care of additional security measures.

The first problem to deal with is the fact that, as a PKSA service does not have a user interface, it cannot scan a QR code to obtain a communication encryption key.

The second issue is that it should NOT accept authentication requests from known or unknown applications unless being explicitly told to do so! This can be the case when its operator wishes to initialize an application authentication token, for example.

1. Securing communication

Remember that the authentication key (auth_key) that is used to encrypt the communication between an App and a PKSA is usually provided offline and changes with each authentication request.

The first way to solve this problem is to manually create an authentication token, an encryption key and add them manually in the configurations of your App and PKSA. This is my most secure method, but not the easiest to perform.

Another way to do it would be to provide the auth_key to the PKSA with the authentication payload, but this would allow the HAS server to decrypt all your communication. Unless you run your own HAS server, that's not a good idea. Even with your own HAS server, it could be that another PKSA where you registered your account could receive the authentication request (and the auth_key that would come with it).

To solve this issue, the App can use a secret pre-shared with the PKSA (auth_req_secret) to encrypt the auth_key. This means that only that specific PKSA service will be able to decrypt the auth_key provided by the App. Up to the App to have the auth_req_secret hard-coded or retrieve it from a config file or user input.

2. Securing authentication request

The next security measure to implement is to deny any authentication request that doesn't come with a valid token and only allow them for a short moment when you want to provide an app with a new valid token.

When you want to authorize a new session (an application running on a specific device for a specific user), you temporarily tell your PKSA to accept authentication requests without a valid token. Your PKSA will create a new token and send it to the app. Once authenticated in the app, your instruct your PKSA to block any new request coming without a token.

In order to avoid too often having to renew a token for an App, a PKSA service can also consider providing new tokens to the App with a longer expiration time.

An Open-Source PKSA example

Code for running a PKSA in service mode is available on GitHub.

The provided code has the following features implemented:

• reconnect the PKSA to the HAS server when the connection is unintentionally interrupted.

• generate a detailed log of interactions with HAS

• validate all commands against the HAS protocol definition.

• manage the many different possible exceptions

The code is documented with as many comments as possible and makes it easy to understand the proper functioning of a PKSA in service mode.

A HAS Server is available at wss://hive-auth.arcange.eu