HSM (Hardware Security Module) setup

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
HSM (Hardware Security Module) setup
Complex
~3-5 business days
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1217
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1046
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

HSM (Hardware Security Module) Setup

Private keys stored in filesystem, encrypted with environment variables, even in AWS KMS — all software-based solutions with common vulnerability: with sufficient privileges in system, the key can be extracted from memory. HSM is a separate physical chip in which keys are generated and stored in a protected zone from which they cannot be exported. Operations with keys (signing, decryption) happen inside HSM — only result goes out.

In blockchain context HSM applies to: high-security multisig wallets, validator signing keys (especially relevant for Ethereum validators after Kraken slashing), custody solutions for institutional clients, transaction signing in automated systems without key compromise risk.

HSM vs Software Alternatives

Characteristic Software (file/env) AWS KMS Dedicated HSM
Key extractable? Yes No (theoretically) No (physically)
Memory attack Vulnerable Vulnerable on client No (operations inside)
Physical protection No Yes (Amazon) Yes (under your control)
Tamper evidence No No Yes (self-destruct on open)
FIPS 140-2 Level Level 2 Level 3 or Level 4
Cost ~$0 ~$1/10k operations $1000–$40000 per device
Latency per operation <1ms 10–50ms 5–100ms

FIPS 140-2 Level 3 — standard for financial sector. Requires physical protection against opening (tamper-evident), device-level authentication. Most enterprise HSMs (Thales Luna, AWS CloudHSM, YubiHSM 2) certified to this level.

HSM Selection: Options for Blockchain

Thales Luna Network HSM

Enterprise-grade hardware HSM. Supports secp256k1 (Bitcoin/Ethereum curve) starting with Luna 7. PKCS#11 compatible — standard interface for integration.

  • Cost: ~$20,000–$40,000 per device
  • Throughput: ~10,000 ECC operations/sec
  • Use: custody, exchanges, institutional solutions

AWS CloudHSM

HSM in the cloud. You get dedicated physical chip in AWS data center that AWS doesn't have access to (unlike KMS).

  • Cost: $1.45/hour ($1050/month)
  • FIPS 140-2 Level 3
  • Management via PKCS#11, JCE, OpenSSL

YubiHSM 2

Compact USB HSM for less critical tasks or testing. Supports Ed25519, P-256, but doesn't support secp256k1 natively.

  • Cost: ~$650
  • Use: transaction signing via pre-computation, validator keys for small operations

Azure Dedicated HSM

Microsoft's CloudHSM analog, uses Thales Luna underneath. FIPS 140-2 Level 3.

Ethereum Integration via PKCS#11

PKCS#11 is standard C API for HSM work. Most programming languages have bindings.

Key Generation Inside HSM

import pkcs11
from pkcs11 import Mechanism, KeyType, Attribute

# Connect to HSM via PKCS#11 library
lib = pkcs11.lib('/usr/lib/libCryptoki2.so')  # path to vendor library
token = lib.get_token(token_label='MyHSMToken')
session = token.open(user_pin='HSM_USER_PIN')

# Generate secp256k1 keypair (Ethereum/Bitcoin)
# Keys created and stored INSIDE HSM, don't leave it
public_key, private_key = session.generate_keypair(
    KeyType.EC,
    public_template={
        Attribute.TOKEN: True,         # store in HSM (not just in session)
        Attribute.LABEL: 'eth-signing-key-1',
        Attribute.EC_PARAMS: encode_named_curve_parameters('secp256k1'),
        Attribute.VERIFY: True,
    },
    private_template={
        Attribute.TOKEN: True,
        Attribute.LABEL: 'eth-signing-key-1',
        Attribute.SIGN: True,
        Attribute.EXTRACTABLE: False,  # CRITICAL: forbid private key export
        Attribute.SENSITIVE: True,
    }
)

# Get public key (it's exportable — that's fine)
ec_point = public_key[Attribute.EC_POINT]
# Convert to Ethereum address
eth_address = ec_point_to_eth_address(ec_point)
print(f"Ethereum address: {eth_address}")

Transaction Signing via HSM

from eth_account._utils.signing import sign_transaction_dict
import rlp

def sign_eth_transaction_hsm(session, private_key_label, tx_dict):
    """
    Sign Ethereum transaction with key inside HSM.
    Private key never leaves HSM.
    """
    # Encode transaction per EIP-155 (with chain_id for replay protection)
    chain_id = tx_dict['chainId']
    unsigned_tx = encode_unsigned_tx(tx_dict)
    
    # Compute hash for signature
    tx_hash = keccak256(unsigned_tx)
    
    # Get private key object from HSM (not the key itself!)
    private_key = session.get_key(
        label=private_key_label,
        key_type=KeyType.EC
    )
    
    # Sign INSIDE HSM — tx_hash goes to HSM, signature comes back
    # Mechanism ECDSA (raw) — for Ethereum need raw without hashing inside HSM
    der_signature = private_key.sign(tx_hash, mechanism=Mechanism.ECDSA)
    
    # DER -> (r, s) -> v, r, s for Ethereum
    r, s = decode_der_signature(der_signature)
    v = recover_v(tx_hash, r, s, chain_id, eth_address)
    
    signed_tx = encode_signed_tx(tx_dict, v, r, s)
    return signed_tx.hex()

Important detail: Ethereum uses secp256k1 with recoverable signature (component v needed to recover public key). PKCS#11 returns ECDSA signature without v. v (recovery id) computed empirically — try 0 and 1, check which recovers correct address.

Ethereum Validator Keys and HSM

For Ethereum PoS validators special situation: validator signing key (BLS12-381) used to sign attestations and blocks. Key compromise leads to slashing — loss of stake.

EIP-3030 (Ethereum Remote Signing) and Web3Signer project (from Consensys) solve this:

# web3signer configuration with HSM (Hashicorp Vault or PKCS11)
type: "pkcs11-signer"
pkcs11LibraryPath: "/usr/lib/softhsm/libsofthsm2.so"
slashingProtectionDbUrl: "jdbc:postgresql://localhost/web3signer"  # protection from double-signing
keystoreFile: "/etc/web3signer/keystore.yaml"

Web3Signer adds slashing protection database — even if sign request comes twice (e.g., from validator bug), second will be rejected.

Audit and Access Management

HSM logs every operation: who requested signature, with which key, when. These are forensically significant logs — must be exported to SIEM system and stored with integrity guarantees (append-only, signed).

Access control scheme:

  • Security Officer (SO) — manages HSM itself, creates/deletes keys, changes policies
  • Operator — can use keys for signing but can't delete or export them
  • Auditor — logs read-only

Role separation + m-of-n authentication for SO operations (e.g., 2 of 3 smart cards) — standard for custodial operations.

What's Included

  • HSM selection based on specific requirements (on-premise vs cloud, throughput, curves)
  • Physical installation and HSM initialization (for on-premise)
  • PKCS#11 integration with application: key generation, signing operations
  • Role and m-of-n authentication setup
  • Web3Signer integration for validator use case
  • Audit logging setup with SIEM export
  • Key material backup procedures (key wrapping under another HSM)
  • Disaster recovery scenario testing