Skip to main content

Features & Options

Features

Secure Access

CloudHSM implements security measures on the communication layer, subscriber authentication and authorization, roles, physical access, patching, monitoring, and so on. Here, the focus is on secure access to the communication interface.

Between the Primus API Provider (client-side software component) and the HSM in the CloudHSM service, a secure AES-256-GCM encrypted connection is established. The authentication takes place in two phases. First, the subscriber is authenticated on the gateway. In this step, access can optionally be limited to only whitelisted client IP addresses. It is only after this step when end-to-end encrypted communication to the HSM is granted by the gateway.

Alternatively, when using the REST API, communication is secured by TLS. Access is authenticated and authorized using a JSON Web Token (bearer token) issued to the subscriber in a multi-tenant TSBaaS setup, or alternatively through mutual TLS for a dedicated TSBaaS instance.

Secure Storage and Control of Key Usage

CloudHSM provides features to protect keys from export, import, or deletion at the level required by the use case of the subscriber. Typically, keys are generated within the HSM but of course, they can also be imported if required by the subscribers security policy. However, they are controlled by specific partition security policy settings on the HSM partition. Any interaction with the keys can only be performed by the subscriber through the cryptographic API.

Key exportability is controlled by two parameters: first, whether the individual key was marked as exportable during its creation, and second, if the partition security policy has been set to allow key export.

Depending on the requirements, deletion of keys can be prevented by setting the partition security policy to read-only or by using the Key Invalidation mode, which is a unique feature of the Primus HSMs. When using Key Invalidation, a key deleted via the API is only marked as invalidated but remains stored in the HSM until deleted by the Security Officers. Key Invalidation is a very effective measure to protect against accidental key deletion and to enforce the principle of multistage control.

Cryptographic Agility and Set of Algorithms

Among many cryptographic schemes, CloudHSM supports symmetric (AES, 3DES, Camellia, ChaCha, Poly1305), asymmetric (RSA, ECC, Diffie-Hellman), and hashing (SHA-2, SHA-3) cryptographic algorithms. Visit the Algorithms and Functions page for a comprehensive list of supported algorithms and functions.

The underlying Primus HSMs guarantee full crypto agility due to their dynamic architecture. Should quantum computers render any of the supported algorithms obsolete, then a quantum-computer-safe algorithm may be installed by means of a firmware/software upgrade. Different PQC algorithms are already supported.

Operation & Roles

Any activity on the CloudHSM service is permanently logged and monitored. Wherever possible, any subscriber metadata is anonymized. Alerts are triggered on certain system conditions or subscriber activity and can be followed up immediately.

The operation of the HSMs and the associated administrational roles (Security Officer) are handled by true experts of Securosys. Every Security Officer is deeply experienced in HSM operation and has passed a thorough background check. The Security-Officer role is strictly activated adhering to the four-eyes principle and an “air-gapped” second factor.

Compared to other solutions where administration is fully automated, CloudHSM is better protected against cyberattacks on the HSM administration pane. Special attention has been paid to the segregation of duties in the HSM operation, like customer onboarding, HSM partition configuration, backup/restore, firmware update, etc. They all involve different roles and require up to six eyes to be enabled.

However, for subscribers who want to take full control over their own partition, CloudHSM offers the role of Partition Security Officers. By using the Decanus Administration Terminal, subscribers can manage their HSM partition remotely and set the partition configuration, perform partition backups and restoration, access the partition-specific logs and set access credentials for their applications. A Partition Security Officer can even exclude the Device Security Officer from any configuration change to his partition. With or without the activation of Partition Security Officers the basic operational chores, like device firmware updates, remain with the Device Security Officer and are covered by the services provided by Securosys.

Backup and Business Continuity

In CloudHSM, the data is synchronized between all the HSMs within the cluster, thus offering a high degree of redundancy, which renders backups less important. In CloudHSM, we only take backups as a precautionary measure for certain maintenance tasks. Such backups follow the six-eyes principle and are taken manually. The backups are not held in online storage and as such are never exposed to internal networks; Instead, they are written to USB thumb drives and stored in a safe.

Despite the high redundancy level of the solution, certain subscribers still will have the mandatory requirement to keep an own regular backup of their data. For such subscribers, the Partition Security Officer feature allows them to connect to their partition with the Decanus Administration Terminal and to take a backup on their own USB thumb drive at the frequency their policy is stipulating, and hold the backup on premise. Moreover, CloudHSM has defined business continuity plans and offers different exit options, such as a migration of the key material to an on-premise HSM.

Application Integration, Flexibility, and Skills

The CloudHSM provides a wide selection of Application Program Interfaces (JCA/JCE, MS CNG, PKCS#11, OpenSSL, REST). It can be used with almost any business application ranging from Identity Access Management, Public Key Infrastructure, strong authentication, database encryption, electronic signature to raw data encryption, and blockchain validation.

Key Attestation

The Primus HSMs in CloudHSM feature a dedicated keystore, protecting a factory installed root certificate and root key. The device then creates its own intermediary (device) key and its certificate is signed by the root key. The intermediary key is then used to sign attestation and timestamp key created for each partition. Thus, providing proof to you or any trust service provider that your keys are hold securely inside a CloudHSM partition. The PrimusHSM Root Certificate for Key-Attestation for all CloudHSM service packages is published on the Securosys Support Portal, along with detailed instructions for the attestation verification process in the Audit and Attestation application note.

Key Invalidation

Key invalidation creates a shadow copy, trash bin, of the key when the key is deleted. This prevents accidental deletion of valuable keys from the API. The Security Officer role in charge of the partition can then in a manual step delete the invalidated keys, or in case of an erroneous deletion reactivate the individual key(s).

Options

In addition to the mentioned features, subscribers have the flexibility to choose from a range of functional options. These include Smart Key Attributes for enhanced security, enabling features such as multi-signature and multi-authorization functionality, support for Crypto Currencies such as Bitcoin, Ethereum, Cardano, Ripple, or IOTA, Transaction Security Broker capabilities, Post-Quantum Cryptographic (PQC) algorithms and Remote Partition Administration for convenient management.

Smart Key Attributes

The usage of keys is normally bound to the legitimate access to the HSM partition. E.g., the authenticated subscriber is allowed to execute operations (sign, decrypt, unwrap, ...). For many applications, this turns out to be sufficient. In cases where stricter and higher-granular control over the key operations is required, CloudHSM offers a concept called Smart Key Attributes (SKA). Smart Key Attributes (SKA) enable the assignment of a customizable policy to any individual key, ensuring that specific cryptographic operations associated with the key are strictly enforced by the key's policy on the HSM. The rules can contain any combination of quorums, time constraints, etc. To bring the concept of SKA closer to you, just think of a PKI where you wish to apply a specific condition when using the CA root key. With SKA, you would for example attribute a rule to the CA root key that this key may only be used if 3 out of 5 supervisors (e.g. representatives of different departments identified by their public keys) approve the operation within a given timeframe.

To learn more about Smart Key Attributes and their seamless integration with the Transaction Security Broker, which offers a REST API and SKA workflow engine, please refer to the SKA Tutorial.

Transaction Security Broker

The integration of the Smart Key Attributes workflow is alleviated with the Transaction Security Broker (TSB) service. The TSB orchestrates the approval collection from the supervisors (approval clients) for any transaction calls from the subscribers application based on the ruleset on the key object. The interaction between the subscriber application, the TSB and approval clients, respectively, is accomplished via an industry-standard REST API.

Crypto Currencies

The CloudHSM service presents a comprehensive solution for supporting Blockchain Algorithms, manifesting its versatility through features designed to cater specifically to the intricacies of various crypto currencies. This includes robust support for popular currencies such as Ethereum (ETH), Bitcoin (BTC), Cardano (ADA), Ripple, IOTA, and a myriad of others. Notably, the system facilitates key derivation on asymmetric keys with a built-in BIP 32 mechanism, ensuring secure and efficient key management. Moreover, the direct secure address generation, achieved through the hash of the public key, stands out as a distinctive feature that provides additional Post-Quantum Cryptography (PQC) protection within the HSM environment, enhancing the overall security posture for cryptographic operations. This nuanced approach to blockchain algorithm support underscores the commitment to delivering a robust and adaptable platform for diverse cryptographic needs.

Post-Quantum Cryptographic (PQC) Algorithms

CloudHSM offers robust support for cutting-edge Post-Quantum Cryptographic (PQC) algorithms, ensuring enhanced security in the face of evolving threats. Among the supported algorithms are CRYSTALS-Dilithium, CRYSTALS-Kyber, and SPHINCS+, providing advanced encryption capabilities that align with the latest security standards and protocols.

Partition Remote Administration

Subscribers who opt for CloudHSM do not need to trust Securosys to handle their security. Instead, they can control their partition access and security settings without any interference – even from Securosys administrator.

The Decanus Terminal's Partition Administration feature allows subscribers’ operators to take on the Partition Security Officers (PSO) role, allowing them to perform the same administrative tasks usually done at a device level with Security Officers privileges.

The Partition Security Officer role can be activated alternatively by one or two-out-of-m persons.

The PSO option allows the client to take full control over the partition security configuration and access credential generation. These include:

  • Resetting credentials
  • Changing the partition’s security configuration
  • Management of invalidated keys
  • Exporting logs
  • Partition backup/ restore

The PSO can additionally exclude the Security Officer role on device level (held by Securosys) from any intervention (e.g., password reset) on clients partition. Note that by doing so, the PSO (client) takes over full responsibility for the risk of losing PSO access credentials.

Partition Remote Administration

Timestamp Service (RFC3161 compliant)

The Timestamp Service enables the generation of timestamps in compliance with the RFC3161 as required by standard ETSI EN 319 422. It covers the necessary operations to support timestamping services, allowing users to create tamper-proof records of the time and date when a document or transaction was signed.