Why do we need SKA?

A hardware security module (HSM) is a digital key vault. Keys are generated inside the HSM and cannot be taken out. Its tamper-proof housing, a multitude of sensors, and different hardware and software layers make sure nobody can get to the keys. Only applications that have the correct access credentials to the HSM can use these keys.

While the application and the HSM continuously perform a rollover and renew their access credentials an attack vector remains. The keys can be used by a corrupted, hacked client application that has access to the HSM. Cutting the line between application is only a short-term fix. But as soon as the application connects again to the HSM it can make use of the keys again.

In traditional applications like finance this is not that critical. The counter party is known, and the system allows to reverse false transactions. However, in systems such as blockchain, where transactions cannot be easily reversed, where the counter party may be unknown, access to the transaction (signature/private) keys have to be better protected. It is important to make sure that the keys are used by secure rules, reflecting the business and compliance needs. When it comes to digital assets, not having an additional security layer is death.

Storing of keys in an HSM is just the start. One has to make sure that they can only be used by adhering to certain rules attached to every key. This makes it impossible for corrupted or hacked applications (or admins) to use the keys, dramatically reducing the risk of having your assets stolen. 

Solution: Controlling use of each key by adding rules

Key access and security are governed by attributes restricting the use. With adding rules to an individual key, keys can only be used in a preset way determined by the client. In many industries or use cases this is a feature that dramatically increases security.

 

The Securosys Primus HSM supports adding such rules securely inside the HSM. The feature is named “smart key attributes” and can be used for a wide application spectrum, including - but not limited to - for signature services according to eIDAS (the European standard for electronic IDentification, Authentication and Trust Services), authorization of blockchain transactions, and much more.

Use Cases

Use Case individual qualified signatures:

Keys can only be used if you identify yourself beforehand. This is 1 of 1 quorum or 1 of many.

Qualified signatures can be used with prior identification. This means that software can access keys, but nothing can happen since there is no release, because a rule was bound to a key. Each key has its own rule. With its digital ID we can access our keys, so the software can be hacked, but nothing can happen with it.

Securosys_qualified_signature_1o1_quorum

(eIDAS framework was originally the idea that initiated Securosys SKA solution)

Use Case Multi-signature or i.e. 2 of 5:

Typical business processes require at least two authorized people to sign a contract. They are publicly identified and listed in the commercial registry. Similarly, the same must be achieved in the digital realm. While it requires a certain amount of effort to steal someone's identity and then use it, it is much harder if you need more than one and then apply it. Therefore, higher quorum authorizations, for example 2 out of many people have to sign off on a transaction, makes it much securer.

The SKA implemented in the Primus HSM provides other useful features. One of them are timing rules. Keys can be setup so that all approvals have to be provided within a certain timeframe, for example, within 5 minutes. They may also have hold requirements or usage can be blocked outside office hours.  

In any case, the Primus HSM logs everything, including who gave the authorization to use the key. Thereby an audit log is built as required by institutional customers.

Securosys_Multi_Signature

Advantages of Multi-Authorization

SKA allows companies to move their paper-based businesses processes into the digital realm. These processes can be mapped exactly the same way using the different key attributes offered, making it easy to implement all the compliance rules.

In banking, for example, transactions up to a certain amount can be signed automatically. Larger transactions might require the authorization of two traders. Even larger transactions might require the authorization not only by the traders, but also by a compliance officer. In certain cases, a hold might make sense so real-world processes can step in – comparable to calling the customer to confirm the transaction.

Possible applications

In some cases, more complex control of key usage is required, to enforce security of various business processes. Use cases are individual signature keys, such as in electronic digital signature services, electronic company seals, or any signature request that needs authorization by more than one person.

  • Digital Signature (signing service with authorization)
  • Digital seal
  • Timed approvals
  • Multiple access is convenient for different timeframes (e.g 3 of 5 within the hour, 1 of 5 with time limit of a week)
  • Multiple groups are convenient for different business units - multiple groups (e.g. 1 of Board of Directors and 2 of security officers)
  • Signing payload to prevent misuse of the signing operation

 

Applications

In Certificate Authorities (CA) and PKIs the initial key, the Root Key, is the most important key of the whole system. It is used to sign the keys and generate certificates of the Sub-CA. It is also used to sign the Certificate Revocation List (CRL). The Root Key is often locked away in an offline HSM in a physical vault to safeguard it.

Using the Root Key is therefore a very complex maneuver as the responsible signers have to get together, retrieve the offline HSM, take it online, and sign, for example, a CRL. The same can be achieved with the Securosys SKA without any loss in security. By adding multi-authorization rules (attributes) to the Root Key there is no more need to take it offline and store in a vault anymore. Rather, the listed authorizers on the Root Key, fulfilling the quorum and other rules attached to the key, enable any sign requests.

An important part in the digital transformation are digital signatures. To digitally sign a document the signer has to have a digital identity. This is achieved with a private key. As such a private key represents a person, a company, or another entity it has to be stored securely. But storing these private keys are not always done on an HSM. Some store them simply somewhere on the filesystem of a server, which is a main target for hackers. So, if a company, institution, or even a country wants to issue and maintain digital identities, they should use HSM.

A government will want to have a digital identity solution, that is dynamic, mobile, and online and can map different attributes to the private key representing the identity.

Traditional banking is using complex software solutions that are built according to the business processes of the bank. But transactions need to be signed and compliance rules need to be met. Adding this ruleset as attributes to the key delivers very good protection in case their software in use gets corrupted. And this may happen by external means or internal.

These banks are also tapping into the Digital Assets market. Such as the distributed ledger technology. A bank gets dramatically more confidence to invest into these markets when knowing the barriers to stealing digital assets that cannot be retrieved from a blockchain, are incredibly hard to hack. 

With digital assets, Banks have a huge risk to protect their reputation. So banks don’t actually invest in building their own crypto exchanges. The issue here is, that once tokens or crypto currencies have been removed from storage, they can no longer be retrieved.

Contact us

Looking for more information on this product? Or didn't find what you were looking for? Let us know. 

Looking for more information on this product? Or didn't find what you were looking for? Let us know.