Разработка системы управления приватными ключами

Разработка системы управления приватными ключами

Приватный ключ — единственный источник истины в блокчейне. Нет пароля для восстановления, нет службы поддержки, нет отката транзакции. Компрометация ключа = потеря всех активов под его управлением навсегда. При этом большинство организаций хранят ключи в .env файлах на серверах или, хуже, в личных кошельках разработчиков.

Разработка корпоративной системы управления ключами — это инженерная задача на стыке криптографии, distributed systems и operational security. Правильная архитектура должна обеспечить: невозможность компрометации одной точкой атаки, аудируемость каждого использования ключа, восстановление при выходе из строя компонентов.

Threat model: от чего защищаемся

Прежде чем выбирать технологии — нужно чётко определить угрозы.

External attacker: взлом сервера, утечка credentials, SQL-инъекция в смежных системах. Атакующий получает доступ к среде исполнения.

Malicious insider: сотрудник с легитимным доступом пытается использовать ключ несанкционированно или украсть его.

Infrastructure failure: сервер с ключом падает в самый неподходящий момент. Нужна репликация без снижения безопасности.

Supply chain attack: скомпрометированная зависимость, модифицированный Docker образ, BGP hijack облачного провайдера.

Разные угрозы требуют разных защитных мер. Нет единственного правильного решения — есть набор инструментов с разными trade-off между безопасностью и удобством.

Уровни защиты ключей

Аппаратные модули безопасности (HSM)

HSM (Hardware Security Module) — физическое устройство, хранящее ключевой материал и выполняющее криптографические операции внутри защищённой среды. Ключ никогда не покидает устройство в открытом виде.

Облачные варианты: AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM. On-premise: Thales Luna, Entrust nShield. Для блокчейна часто используют YubiHSM 2 (доступный вариант, ~$600).

# Взаимодействие с HSM через PKCS#11 (стандартный интерфейс)
import pkcs11
from pkcs11 import Mechanism, KeyType, ObjectClass

def sign_ethereum_transaction_with_hsm(
    tx_hash: bytes,
    slot_id: int,
    pin: str,
    key_label: str
) -> tuple[int, int, int]:
    """
    Подписывает хеш транзакции приватным ключом внутри HSM
    Возвращает (v, r, s) компоненты подписи
    """
    lib = pkcs11.lib('/usr/lib/softhsm/libsofthsm2.so')  # или путь к реальному HSM
    token = lib.get_token(slot_id=slot_id)
    
    with token.open(user_pin=pin) as session:
        # Ищем ключ по label
        private_key = session.get_key(
            object_class=ObjectClass.PRIVATE_KEY,
            key_type=KeyType.EC,
            label=key_label
        )
        
        # Подпись происходит внутри HSM, ключ не экспортируется
        signature = private_key.sign(tx_hash, mechanism=Mechanism.ECDSA)
        
        # Конвертируем DER подпись в (r, s)
        r, s = decode_ecdsa_signature(signature)
        v = determine_recovery_id(tx_hash, r, s)
        
        return v, r, s

def generate_key_in_hsm(session, label: str) -> None:
    """Генерирует ключевую пару внутри HSM"""
    # Ключ генерируется внутри HSM и никогда не выходит в открытом виде
    pub, priv = session.generate_keypair(
        KeyType.EC,
        key_length=256,
        curve='secp256k1',
        public_template={
            pkcs11.Attribute.LABEL: label,
            pkcs11.Attribute.TOKEN: True,
            pkcs11.Attribute.VERIFY: True,
        },
        private_template={
            pkcs11.Attribute.LABEL: label,
            pkcs11.Attribute.TOKEN: True,     # Сохранить на токен
            pkcs11.Attribute.PRIVATE: True,
            pkcs11.Attribute.SENSITIVE: True,  # Не экспортировать в открытом виде
            pkcs11.Attribute.SIGN: True,
            pkcs11.Attribute.EXTRACTABLE: False,  # Критично: запрет экспорта
        }
    )

Multi-Party Computation (MPC)

MPC — технология, при которой ключ никогда не существует в полном виде на одном устройстве. Несколько участников хранят shards (доли ключа), подписание транзакции происходит через криптографический протокол без сборки полного ключа.

Используется в Fireblocks, Zengo, Qredo, Coinbase Prime. Preстандартные протоколы: GG18/GG20 (Lindell et al.), FROST (Flexible Round-Optimized Schnorr Threshold Signatures).

Схема MPC подписания (упрощённо):

Участник A имеет: key_share_A
Участник B имеет: key_share_B  
Участник C имеет: key_share_C

Для подписания нужны любые 2 из 3 (схема 2-of-3):

1. A и B начинают протокол
2. Обмениваются commitment'ами (не раскрывают shards)
3. Вычисляют partial signatures
4. Агрегируют: signature = combine(partial_A, partial_B)
5. Результат — валидная ECDSA подпись
6. key_share_A и key_share_B НИКОГДА не встречались на одном устройстве

Преимущества MPC перед multisig на блокчейне: подпись выглядит как обычная single-sig транзакция (меньше gas, не раскрывает структуру governance), policy enforcement off-chain (можно добавить любые правила без изменения смарт-контракта).

Threshold Signatures vs Multisig

Важно не путать MPC threshold signatures с on-chain multisig (Gnosis Safe). Это разные подходы с разными trade-offs:

Для большинства организаций: Gnosis Safe для крупных cold хранилищ (прозрачность важнее gas), MPC для операционных hot wallets (скорость и гибкость policy).

Политики авторизации транзакций

Ключи — это только часть системы. Не менее важно определить: кто, когда и при каких условиях может подписывать транзакции.

Policy Engine

interface TransactionPolicy {
    id: string;
    name: string;
    conditions: PolicyCondition[];
    requiredApprovals: number;
    approvers: string[];
    maxAmountUsd?: number;
    allowedContracts?: string[];
    allowedChains?: number[];
    timeRestrictions?: TimeRestriction;
}

interface PolicyCondition {
    type: 'amount' | 'contract' | 'method' | 'time' | 'chain';
    operator: 'eq' | 'lt' | 'gt' | 'in' | 'not_in';
    value: unknown;
}

class PolicyEngine {
    private policies: TransactionPolicy[];
    
    async evaluateTransaction(tx: PendingTransaction): Promise<PolicyResult> {
        const matchingPolicies = this.findMatchingPolicies(tx);
        
        if (matchingPolicies.length === 0) {
            return { 
                allowed: false, 
                reason: 'No matching policy',
                requiresManualReview: true 
            };
        }
        
        // Берём наиболее строгую применимую политику
        const strictestPolicy = this.getMostRestrictivePolicy(matchingPolicies);
        
        // Проверяем лимиты
        if (strictestPolicy.maxAmountUsd) {
            const txValueUsd = await this.getTransactionValueUsd(tx);
            if (txValueUsd > strictestPolicy.maxAmountUsd) {
                return {
                    allowed: false,
                    reason: `Exceeds limit: $${txValueUsd} > $${strictestPolicy.maxAmountUsd}`,
                    requiresApproval: true,
                    approvers: strictestPolicy.approvers
                };
            }
        }
        
        // Проверяем whitelist контрактов
        if (strictestPolicy.allowedContracts && 
            tx.to && 
            !strictestPolicy.allowedContracts.includes(tx.to.toLowerCase())) {
            return {
                allowed: false,
                reason: 'Contract not in whitelist',
                requiresManualReview: true
            };
        }
        
        return { allowed: true, policy: strictestPolicy };
    }
}

Уровни авторизации

Типичная корпоративная иерархия:

Автоматические транзакции (до $1,000 эквивалента): выполняются без подтверждения человека. Подходит для gas-топлива, мелких операций, batch-транзакций.

One-person approval ($1,000–$50,000): операция требует подтверждения одного авторизованного лица через мобильное приложение или аппаратный ключ.

Multi-person approval ($50,000–$500,000): требуется M из N подтверждений от разных сотрудников в разных геолокациях.

Board-level approval (свыше $500,000): созыв комитета, физическая встреча, возможно нотариально заверенные документы.

Key Lifecycle Management

Жизненный цикл ключа: генерация → регистрация → операционное использование → ротация → отзыв. Каждый этап требует отдельных процедур.

Генерация: должна происходить в trusted environment (HSM, air-gapped машина). Entropy источник верифицируется. Генерация документируется с подписями свидетелей.

Шардирование при бэкапе: ключи резервируются через Shamir's Secret Sharing. Схема 3-of-5: пять шардов распределяются по разным физическим локациям, трёх достаточно для восстановления.

from secretsharing import PlaintextToHexSecretSharer

def backup_private_key(private_key_hex: str, shares: int = 5, threshold: int = 3) -> list[str]:
    """
    Разбивает приватный ключ на N шардов, из которых threshold достаточны для восстановления
    Шарды хранятся раздельно: разные люди, разные физические локации
    """
    shards = PlaintextToHexSecretSharer.split_secret(
        private_key_hex,
        threshold,
        shares
    )
    return shards

def recover_private_key(shards: list[str]) -> str:
    """Восстанавливает ключ из любых threshold шардов"""
    return PlaintextToHexSecretSharer.recover_secret(shards)

# Процедура бэкапа:
# 1. Air-gapped машина, без сети
# 2. Генерация 5 шардов
# 3. Каждый шард на отдельную железную флешку + бумажный бэкап
# 4. Конверты запечатываются, подписываются свидетелями
# 5. Хранятся в разных сейфах (офис, банковская ячейка, home safe ключевых сотрудников)

Ротация ключей: плановая (раз в год) и внеплановая (при подозрении на компрометацию, увольнении сотрудника с доступом). Для on-chain контрактов требует смены owner через multisig.

Отзыв: при компрометации — немедленный перевод активов на новый ключ. Нельзя просто «заблокировать» ключ в блокчейне.

Аудит и мониторинг

Каждое использование ключа должно логироваться: кто запросил подписание, что было подписано, кто авторизовал, timestamp, IP, device fingerprint.

interface KeyUsageEvent {
    eventId: string;
    timestamp: Date;
    keyId: string;
    operation: 'sign' | 'derive' | 'export_public' | 'rotate';
    requestedBy: string;      // user ID или service account
    approvedBy: string[];     // если требовалось approval
    transactionHash?: string; // если транзакция
    transactionData?: {
        to: string;
        value: string;
        chainId: number;
        methodSignature?: string;
    };
    policyId: string;
    ipAddress: string;
    deviceId: string;
    approved: boolean;
    rejectionReason?: string;
}

// Все события подписываются HSM ключом аудита — нельзя подделать
// Хранятся в append-only storage (Kafka, CloudTrail, immutable S3 bucket)

Аномалии для алертинга: подписание ночью нерабочими часами, нетипичные destination адреса, объём транзакций выше исторической нормы, попытки подписания отклонённых транзакций.

Disaster Recovery

Recovery plan должен быть задокументирован и регулярно проверяться (tabletop exercises). Сценарии: потеря одного сервера с ключом, потеря дата-центра, компрометация одного шарда, увольнение key keeper.

RTO (Recovery Time Objective) для разных уровней: hot wallet — минуты (автоматический failover на резервный HSM), cold storage — часы (процедура с несколькими людьми), полная переключение на новые ключи — 24–48 часов.

Регулярные тесты: ежеквартальная симуляция восстановления в staging среде. Без теста recovery plan — это просто документ.

Стек и сроки разработки

Инфраструктура: AWS CloudHSM или YubiHSM 2, Hashicorp Vault (управление secrets и policy), Kubernetes для сервисов подписания.

MPC-библиотеки: tss-lib (Go, реализация GG20), ZenGo-X/multi-party-ecdsa (Rust), Fireblocks SDK для enterprise.

Backend: Go или Rust для performance-critical signing service, Node.js/Python для API gateway.

Аудит: security audit системы управления ключами обязателен, желательно с penetration testing.

Сроки разработки корпоративной KMS: 4–6 месяцев для production-grade системы с HSM, MPC и policy engine. Интеграция с Gnosis Safe или Fireblocks вместо custom MPC сокращает время вдвое.