Настройка 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
• Применение: подписание транзакций Ethereum через предварительное вычисление, 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 protection database — даже если запрос на подпись придёт дважды (например, из-за bug в validator client), второй будет отклонён.

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

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

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

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

Разделение ролей + m-of-n authentication для 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 сценариев