Налаштування HSM (Hardware Security Module)

Настройка HSM (Hardware Security Module)

Приватні ключі, зберігаючись у файловій системі, зашифровані змінними оточення, навіть в AWS KMS — все це software-based рішення з загальною уразливістю: при достатніх привілеях у системі ключ можна витягти з памяті. HSM — це окремий фізичний чіп, у якому ключі генеруються і зберігаються в захищеній зоні, з якої їх не можна експортувати. Операції з ключами (підпис, дешифрування) відбуваються всередині HSM — наружу виходить тільки результат.

У блокчейн-контексті HSM застосовується для: мультисиг гаманців високого рівня безпеки, validator signing keys (особливо актуально для Ethereum validators після слешингу Kraken та інших), custody рішень для інститутціональних клієнтів, підписання транзакцій в автоматизованих системах без ризику компрометації ключа.

HSM vs програмні альтернативи

FIPS 140-2 Level 3 — стандарт для фінансового сектора. Вимагає фізичної захисту від вскриття (tamper-evident), аутентифікації на рівні пристрою. Більшість enterprise HSM (Thales Luna, AWS CloudHSM, YubiHSM 2) сертифіковані за цим рівнем.

Вибір HSM: варіанти для блокчейну

Thales Luna Network HSM

Аппаратний HSM рівня enterprise. Підтримує secp256k1 (Bitcoin/Ethereum крива) починаючи з Luna 7. PKCS#11 сумісний — стандартний інтерфейс для інтеграції.

• Вартість: ~$20,000–$40,000 за пристрій
• Throughput: ~10,000 операцій ECC/сек
• Застосування: custody, біржі, інститутціональні рішення

AWS CloudHSM

HSM у хмарі. Ви отримуєте виділений фізичний чіп в дата-центрі AWS, до якого AWS не має доступу (на відміну від KMS).

• Вартість: $1.45/годину ($1050/місяць)
• FIPS 140-2 Level 3
• Управління через PKCS#11, JCE, OpenSSL

YubiHSM 2

Компактний USB HSM для менш критичних завдань або тестування. Підтримує Ed25519, P-256, але не підтримує secp256k1 нативно.

• Вартість: ~$650
• Застосування: підписання транзакцій через передвичислення, validator keys для невеликих операцій

Azure Dedicated HSM

Аналог CloudHSM від Microsoft, використовує Thales Luna під капотом. FIPS 140-2 Level 3.

Інтеграція з Ethereum через PKCS#11

PKCS#11 — стандартний C API для роботи з HSM. Більшість мов програмування мають біндинги.

Генерація ключа всередині HSM

import pkcs11
from pkcs11 import Mechanism, KeyType, Attribute

# Підключаємось до HSM через PKCS#11 бібліотеку
lib = pkcs11.lib('/usr/lib/libCryptoki2.so')  # шлях до вендорної бібліотеки
token = lib.get_token(token_label='MyHSMToken')
session = token.open(user_pin='HSM_USER_PIN')

# Генеруємо secp256k1 ключову пару (Ethereum/Bitcoin)
# Ключі створюються і зберігаються ВСЕРЕДИНІ HSM, з нього не виходять
public_key, private_key = session.generate_keypair(
    KeyType.EC,
    public_template={
        Attribute.TOKEN: True,         # зберігаємо в HSM (не тільки у сесії)
        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,  # КРИТИЧНО: заборона експорту приватного ключа
        Attribute.SENSITIVE: True,
    }
)

# Отримуємо публічний ключ (він exportable — це нормально)
ec_point = public_key[Attribute.EC_POINT]
# Перетворюємо на Ethereum адресу
eth_address = ec_point_to_eth_address(ec_point)
print(f"Ethereum address: {eth_address}")

Підписання транзакції через HSM

from eth_account._utils.signing import sign_transaction_dict
import rlp

def sign_eth_transaction_hsm(session, private_key_label, tx_dict):
    """
    Підписуємо Ethereum транзакцію ключем всередину HSM.
    Приватний ключ ніколи не залишає HSM.
    """
    # Кодуємо транзакцію за EIP-155 (з chain_id для replay protection)
    chain_id = tx_dict['chainId']
    unsigned_tx = encode_unsigned_tx(tx_dict)
    
    # Вичислюємо хеш для підпису
    tx_hash = keccak256(unsigned_tx)
    
    # Отримуємо об'єкт приватного ключа з HSM (не сам ключ!)
    private_key = session.get_key(
        label=private_key_label,
        key_type=KeyType.EC
    )
    
    # Підписуємо ВСЕРЕДИНУ HSM — tx_hash йде в HSM, підпис повертається
    # Механізм ECDSA (raw) — для Ethereum потрібен саме raw без хешування всередину HSM
    der_signature = private_key.sign(tx_hash, mechanism=Mechanism.ECDSA)
    
    # DER -> (r, s) -> v, r, s для 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()

Важлива деталь: Ethereum використовує secp256k1 з recoverable signature (компонент v потрібен для відновлення публічного ключа). PKCS#11 повертає ECDSA підпис без v. v (recovery id) вичисляється емпірично — пробуємо 0 і 1, перевіряємо який відновлює правильну адресу.

Ethereum Validator Keys та HSM

Для Ethereum PoS validators особлива ситуація: validator signing key (BLS12-381) використовується для підписання аттестацій і блоків. Компрометація ключа ведає до slashing — втрати частини stake.

EIP-3030 (Ethereum Remote Signing) та проект Web3Signer (від Consensys) вирішують цю задачу:

# web3signer конфігурація з HSM (Hashicorp Vault або PKCS11)
type: "pkcs11-signer"
pkcs11LibraryPath: "/usr/lib/softhsm/libsofthsm2.so"
slashingProtectionDbUrl: "jdbc:postgresql://localhost/web3signer"  # захист від double-signing
keystoreFile: "/etc/web3signer/keystore.yaml"

Web3Signer додає базу даних захисту від slashing — навіть якщо запит на підпис прийде двічі (наприклад, з-за bug у validator client), другий буде відкинутий.

Аудит та управління доступом

HSM логує кожну операцію: хто запросив підпис, з яким ключем, в який час. Це криміналістично значимі логи — вони мусять експортуватись в SIEM систему і зберігатись з гарантіями цілісності (append-only, підписані).

Схема управління доступом:

• Security Officer (SO) — управляє самим HSM, створює/видаляє ключі, змінює політики
• Operator — може використовувати ключі для підписання, але не може їх видалити або експортувати
• Auditor — тільки читання логів

Розділення ролей + m-of-n аутентифікація для SO операцій (наприклад, 2 з 3 смарт-карт) — стандарт для custodial операцій.

Що входить в роботу

• Вибір HSM під конкретні вимоги (on-premise vs cloud, throughput, криві)
• Фізична установка і ініціалізація HSM (для on-premise)
• PKCS#11 інтеграція з додатком: генерація ключів, операції підписання
• Настройка ролей і m-of-n аутентифікації
• Інтеграція з Web3Signer для validator use case
• Настройка аудит-логування з експортом в SIEM
• Процедури backup ключового матеріалу (key wrapping під іншим HSM)
• Тестування disaster recovery сценаріїв