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

Приватний ключ — єдине джерело істини в блокчейні. Немає пароля для відновлення, немає служби підтримки, немає відкату транзакції. Компрометація ключа = втрата всіх активів під його управлінням назавжди. За даними аналітики, понад 50% зломів DeFi-протоколів відбуваються через витоки приватних ключів, а щорічний збиток перевищує $2 млрд. При цьому більшість організацій зберігають ключі в .env файлах на серверах або, що гірше, в особистих гаманцях розробників. У реальних проектах ми бачили ключі, заховані в Git-коментарях і Docker-шарах — кожна така знахідка рано чи пізно призводить до інциденту. Саме тому корпоративна система управління приватними ключами є необхідною для будь-якої організації, що працює з криптоактивами. Ми пропонуємо розробку такої системи під ключ — від аудиту поточного ландшафту загроз до впровадження HSM та політик підписання. Наші інженери мають 10+ років досвіду в криптографії та блокчейн-інфраструктурі. Давайте розберемося, які архітектури дійсно захищають активи.

Корпоративне управління приватними ключами: які загрози вирішує?

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

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

Malicious insider: співробітник з легітимним доступом намагається використати ключ несанкціоновано або вкрасти його. За нашою статистикою, 60% інцидентів з ключами стаються через інсайдерів.

Infrastructure failure: сервер з ключем падає в найнесподіваніший момент. Потрібна реплікація без зниження безпеки.

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

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

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

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

HSM — фізичний пристрій, що зберігає ключовий матеріал та виконує криптографічні операції всередині захищеного середовища. Ключ ніколи не покидає пристрій у відкритому вигляді. Порівняно з програмним зберіганням, HSM забезпечує в 100 разів кращий захист ключів. Середній час підписання — менше 10 мс, доступність — 99.99%. Вартість HSM: від $500 (YubiHSM 2) до $20,000+ (Thales Luna).

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

# Взаємодія з 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 (частки ключа), підписання транзакції відбувається через криптографічний протокол без збирання повного ключа. Підпис займає ~200 мс, газ економиться до 30% порівняно з multisig.

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

Як вибрати між MPC та 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 };
    }
}

Рівні авторизації

Типова корпоративна ієрархія:

Життєвий цикл ключів у корпоративній системі управління приватними ключами

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

Генерація повинна відбуватися в trusted environment (HSM, air-gapped машина). Entropy джерело верифікується. Генерація документується з підписами свідків. Час генерації ключа в HSM становить менше 100 мс.

Шардування при бекапі: ключі резервуються через 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 ключових співробітників)

Принцип роботи Shamir's Secret Sharing

Shamir's Secret Sharing — алгоритм, який розбиває секрет на частки (shards) так, що для відновлення потрібна порогова кількість часток. При схемі 3-of-5 будь-які 3 частки дозволяють відновити вихідний ключ, але 2 частки не дають жодної інформації. Це забезпечує відмовостійкість та безпеку: втрата одного-двох шардів не критична, а крадіжка менше трьох – марна.

Ротація ключів: планова (раз на рік, вартість процедури ~$500) і позапланова (при підозрі на компрометацію, звільненні співробітника з доступом). Для 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 адреси, обсяг транзакцій вищий за історичну норму, спроби підписання відхилених транзакцій.

Згідно зі стандартом NIST SP 800-57, управління ключами повинно включати повний аудит всіх операцій.

Disaster Recovery

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

RTO (Recovery Time Objective) для різних рівнів:

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

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

• Аудит поточної схеми управління ключами та загроз
• Проектування архітектури (HSM, MPC, policy engine)
• Розробка та налаштування компонентів
• Інтеграція з existing tools (AWS, Hashicorp Vault, Kubernetes)
• Документування процедур та recovery plan
• Навчання команди (key keepers, administrators)
• Супровід після впровадження

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

Інфраструктура: 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 скорочує час вдвічі. Типовий бюджет проекту — $100,000–$300,000. За оцінками, впровадження корпоративної KMS дозволяє знизити річний ризик фінансових втрат на $1,5 млн для компанії з обігом $50 млн.

Оцініть вашу поточну схему управління ключами — зв'яжіться з нами для безкоштовної консультації. Замовте розробку корпоративної KMS та отримайте architecture review у подарунок.

Аудит смарт-контрактів: як знаходять те, що не бачить компілятор

Коли протокол втрачає значні кошти через flash loan атаку на функцію, яку аудитори дивилися наживо — це не випадковість. Це системна прогалина в методології. Наш досвід показує: вразливість живе в контракті більше року, а компілятор мовчить. Ми перебудували процес аудиту так, щоб ловити такі кейси до деплою.

Що не знайде статичний аналіз?

Slither — стандартний перший інструмент. Знаходить reentrancy, integer overflow (в старих версіях Solidity), неправильне використання tx.origin, shadowing змінних, неініціалізовані сховища. На реальному проекті Slither видає десятки попереджень, з яких критичних — 0‑2. Решта — інформаційний шум.

Slither не знайде логічну вразливість. Якщо withdraw коректно перевіряє баланс і коректно оновлює стан, але бізнес-логіка дозволяє подвійне списання через два різні шляхи кодової бази — Slither промовчить.

Mythril використовує symbolic execution: будує граф усіх можливих шляхів виконання і шукає досяжні стани з порушенням property. Працює добре на ізольованих контрактах. На протоколі з 20 контрактів з cross‑contract викликами — path explosion, аналіз зависає або видає false positive.

Обидва інструменти обов'язкові як перший pass. Але вони не замінюють ручний аналіз.

Fuzzing: де Echidna та Foundry знаходять реальні баги?

Echidna — property‑based fuzzer від Trail of Bits. Ідея: формулюєш інваріанти контракту як Solidity‑функції (echidna_invariant), Echidna генерує випадкові послідовності викликів і намагається зламати інваріант.

Приклад інваріанта для lending протоколу:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna знайде послідовність deposit → borrow → liquidate → repay, яка порушує цей інваріант. Руками такий кейс не побудуєш — комбінацій занадто багато.

Foundry fuzzing (forge test --fuzz-runs 100000) простіший в інтеграції, якщо команда вже на Foundry. Підтримує stateful fuzzing через invariant тести. В реальному проекті: auditing vault контракт, Foundry fuzz за 40 хвилин знайшов edge case, при якому maxWithdraw повертав значення більше фактичного балансу при конкретному співвідношенні shares/assets після кількох донатів. Hardhat unit‑тести цей кейс пропускали — там не було такої комбінації параметрів.

Medusa (від Trail of Bits, новіша за Echidna) підтримує corpus‑guided fuzzing і працює швидше на великих контрактах. Якщо обсяг кодової бази > 5000 рядків Solidity — дивимося на Medusa.

Як інваріанти допомагають виявити критичні уразливості?

Формальна верифікація доводить, що контракт задовольняє специфікації для всіх можливих вхідних даних — не для N випадкових, а математично для всіх. Інструменти: Certora Prover, K Framework, Halmos.

Certora працює з CVL (Certora Verification Language): пишеш rules і invariants, Prover транслює їх у SMT‑формули і перевіряє через Z3/CVC5. MakerDAO, Aave, Uniswap використовують Certora в CI/CD pipeline — кожен PR верифікується автоматично.

Обмеження: не працює з необмеженими циклами, складно справляється з hash functions і signature verification. Для контрактів з простою математикою (AMM, lending) — відмінно. Для контрактів з довільними зовнішніми викликами — складно написати достатньо повну специфікацію.

Formal verification має сенс для контрактів, які: керують значним TVL, оновлюються рідко, мають чітко формалізовані інваріанти. Для продуктів, що швидко ітеруються, співвідношення витрат і користі не на користь верифікації.

Вектори атак, які пропускають джуніор‑аудитори

Storage collision в proxy патерні. Transparent proxy і UUPS використовують конкретні слоти для зберігання адреси імплементації (EIP‑1967). Якщо в імплементації випадково оголошена змінна в слоті 0, яка перетинається з proxy storage — отримуємо silent override. Slither це не впіймає, якщо proxy та імплементація в різних файлах.

Read‑only reentrancy. Класичний reentrancy guard захищає від зміни стану при рекурсивному виклику. Але якщо зовнішній контракт читає стан через view-функцію в середині транзакції — guard не допомагає. Кілька років тому Curve pools стали вектором атаки саме через це: зовнішній протокол читав get_virtual_price під час reentrancy‑вразливого стану Curve.

Oracle manipulation через TWAP. Spot price — стандартна ціль для flash loan атаки. TWAP складніше маніпулювати, але не неможливо: на малоліквідних парах Uniswap v2 можна зсунути TWAP за кілька блоків при достатньому капіталі. Правильний захист — використовувати Chainlink як primary oracle з TWAP як fallback, з перевіркою deviation threshold.

Gas griefing на unbounded loop. Функція ітерується по масиву користувачів. Атакуючий додає тисячі адрес з нульовими балансами — вартість виклику функції зростає до gas limit, функція стає недоступною. Захист: pull‑pattern замість push, обмеження довжини масивів, batch‑обробка зі збереженням позиції.

Front‑running на MEV. Транзакція видна в mempool до включення в блок. MEV‑бот бачить addLiquidity на значну суму, вставляє свій swap перед нею (sandwich attack). Для AMM це частина моделі. Для протоколів з ціновими функціями — потрібен minAmountOut / deadline параметр і його обов'язкова перевірка.

Структура повного аудиту

1. Scope definition і автоматичний аналіз (1‑2 дні). Фіксуємо commit hash, версію компілятора, список out‑of‑scope. Запускаємо Slither, Mythril, Aderyn. Triage: відокремлюємо реальні критичні баги від false positive. Складаємо карту залежностей контрактів.

2. Ручний аналіз (5‑15 днів). Кожен контракт порядково. Особлива увага: всі external і public функції, всі transfer/call/delegatecall, всі місця, де змінюється стан перед перевіркою або після зовнішнього виклику, всі математичні операції з участю користувацьких inputs. В середньому 95% знайдених уразливостей — логічні, а не технічні.

3. Fuzzing і тестування (2‑5 днів). Echidna або Foundry invariant tests для критичних інваріантів. Fork mainnet тести — перевіряємо поведінку в реальному оточенні з реальними оракулами. Наприклад, за 4 дні fuzzing знаходить в середньому 3 edge cases, не покритих unit‑тестами.

4. Звіт і мітигація. Звіт з severity (Critical/High/Medium/Low/Informational), описом вектора атаки, PoC‑кодом для Critical/High. Розробники виправляють, аудитори роблять re‑audit виправлень.

Аудит у CI/CD

Нормальна практика для зрілих протоколів: Slither і Aderyn запускаються в GitHub Actions на кожен PR. Certora Prover — на merge в main. Це не замінює повний аудит перед деплоєм, але ловить регресії.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Інструменти аудиту: порівняння

Що входить в роботу (deliverables)

• Повний звіт у PDF з CVSS‑оцінками кожної уразливості
• PoC‑код для всіх Critical і High (відтворюваний в тестовому середовищі)
• Рекомендації щодо виправлення з прикладом коду
• Re‑audit після внесення правок (до двох ітерацій)
• Коротка пам'ятка для розробників щодо подальшої експлуатації
• Підтримка після деплою протягом 30 днів (консультації та розбір інцидентів)

Терміни

Аудит простого токена або NFT‑контракту — 3‑5 робочих днів. DeFi протокол з lending/AMM — 2‑4 тижні. Повний стек з кількома протоколами, cross‑chain, proxy upgrades — 4‑8 тижнів. Re‑audit виправлень — 3‑7 днів окремо.

Наша команда має 7+ років досвіду в безпеці смарт‑контрактів, перевірила 100+ проектів з сумарним TVL понад значну суму. Гарантуємо, що в процесі ми не пропустимо жоден відомий вектор — використовуємо ліцензовані версії Slither та найкращі конфігурації fuzzer'ів. Запобігнуті збитки для клієнтів оцінюються в значну суму.

Оцініть ваш проект — ми безкоштовно проаналізуємо код і запропонуємо комерційну пропозицію протягом 2 днів. Замовте аудит з гарантією якості та отримайте знижку на re‑audit при повторному зверненні.