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

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

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

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

Threat model: від чого захищаємося

Перше, ніж вибирати технології — потрібно чітко визначити загрози.

Зовнішній атакуючий: взлом сервера, утечка credentials, SQL-інйекція в суміжних системах. Атакуючий отримує доступ до середовища виконання.

Шкідливий інсайдер: сотрудник з законним доступом намагається використовувати ключ без авторизації або украсти його.

Відмова інфраструктури: сервер з ключем падає в найнеподходящий момент. Потрібна реплікація без зниження безпеки.

Supply chain атака: скомпрометована залежність, модифікований Docker образ, BGP hijack cloud провайдера.

Різні загрози вимагають різних захисних заходів. Немає єдиного правильного рішення — є набір інструментів з різними trade-offs между безпекою та зручністю.

Рівні захисту ключів

Апаратні модулі безпеки (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. Стандартні протоколи: 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 перед on-chain multisig: підпись виглядає як звичайна single-sig транзакція (менше газу, не розкриває структуру governance), policy enforcement off-chain (можна додати будь-які правила без зміни смарт-контракту).

Threshold Signatures vs Multisig

Важливо не плутати MPC threshold signatures з on-chain multisig (Gnosis Safe). Різні підходи з різними trade-offs:

Для більшості організацій: Gnosis Safe для крупних cold хранилищ (прозорість важливіша за газ), 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): скликання комітету, фізична зустріч, можливо нотаріально засвідчені документи.

Управління життєвим циклом ключа

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

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

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

from secretsharing import PlaintextToHexSecretSharer

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

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

# Процедура бэкап:
# 1. Air-gapped машина, без мережі
# 2. Генерація 5 shards
# 3. Кожний shard на окремій железній флешці + паперовий бэкап
# 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[];     // якщо потрібна авторизація
    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). Сценарії: втрата одного сервера з ключем, втрата дата-центру, компрометація одного shards, звільнення 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 скорочує час удвічі.