Комплексная настройка шифрования данных криптопроекта под ключ

Зачем настраивать шифрование данных криптопроекта?

Один незакоммиченный .env файл — и миллионы под угрозой. Потенциальный ущерб от утечки данных может достигать миллионов долларов. Большинство Web3 проектов хорошо защищают смарт-контракты, но забывают про off-chain инфраструктуру, которая является attack surface. Приватные ключи, API секреты, KYC-документы, seed-фразы — всё это требует системного подхода. Мы настраиваем шифрование данных криптопроекта под ключ: от управления секретами до мониторинга инцидентов. Опыт наших инженеров в блокчейн-разработке — гарантия отсутствия утечек. Свяжитесь с нами, чтобы оценить риски вашей инфраструктуры.

Как обеспечить шифрование на всех уровнях?

Управление секретами

80% инцидентов связаны с скомпрометированными учётными данными. Базовое правило: приватные ключи, RPC endpoint с API key, Telegram bot token — не в .env файле, не в репозитории. GitHub scanning (официальный, Gitleaks, Trufflehog) регулярно находит такие утечки в публичных репозиториях.

# Gitleaks: проверка репозитория на утечки секретов
gitleaks detect --source . --verbose

# Или как pre-commit hook
gitleaks protect --staged

HashiCorp Vault — для production-уровня. Секреты хранятся зашифровано, доступ — через dynamic secrets с TTL, аудит-лог каждого обращения.

# Получение секрета через Vault CLI
vault kv get -field=private_key secret/blockchain/signer

# В приложении: динамический токен с коротким TTL
vault token create -policy="blockchain-signer" -ttl=1h

Для приложений в Kubernetes — Vault Agent Injector или External Secrets Operator. Секрет монтируется как файл, не попадает в environment variables (которые часто логируются).

Шифрование приватных ключей

Почему HSM обязателен для signing ключей?

Для production подписывающих ключей (multisig, oracle, bridge) — HSM. Ключ никогда не покидает устройство, подпись выполняется внутри. AWS CloudHSM / Google Cloud HSM поддерживают secp256k1 (проверьте совместимость). HashiCorp Vault также может использовать HSM как backend.

Nitro Enclaves (AWS) — виртуальная изоляция: enclave не имеет постоянного storage и network доступа. Даже root на хост-машине не получит доступ к данным внутри.

Keystore шифрование

Для менее критичных ключей (hot wallets с лимитами) — EIP-55 keystore формат:

// ethers.js: создание зашифрованного keystore
const wallet = ethers.Wallet.createRandom();
const encrypted = await wallet.encrypt(
    process.env.KEYSTORE_PASSWORD!,
    { scrypt: { N: 131072, r: 8, p: 1 } } // высокий cost factor
);
// Сохранить encrypted JSON, не приватный ключ

// Расшифровка при старте приложения
const wallet = await ethers.Wallet.fromEncryptedJson(
    keystoreJson,
    process.env.KEYSTORE_PASSWORD!
);

Keystore пароль — тоже секрет. Храним в Vault или Secrets Manager.

Шифрование пользовательских данных (KYC и PII)

Если проект хранит KYC-документы — они подпадают под GDPR. Минимальные требования:

• Encryption at rest: AES-256-GCM для данных в БД. KMS для управления ключами.
• Encryption in transit: TLS 1.3 везде, cert pinning для мобильных приложений.
• Data minimization: хранить только хэш документа и статус, не сам документ.

-- Шифрование в PostgreSQL через pgcrypto
INSERT INTO kyc_data (user_id, encrypted_document_hash, verified_at)
VALUES ($1, pgp_sym_encrypt($2, current_setting('app.encryption_key')), NOW());

Шифрование данных в IPFS

IPFS — публичная сеть. Всё доступно всем. Для приватных данных — шифрование перед загрузкой:

import { create } from 'ipfs-http-client';
import { box, randomBytes } from 'tweetnacl';
import { encodeBase64 } from 'tweetnacl-util';

async function uploadEncrypted(data: Uint8Array, recipientPublicKey: Uint8Array) {
    const nonce = randomBytes(box.nonceLength);
    const { publicKey, secretKey } = box.keyPair();
    const encrypted = box(data, nonce, recipientPublicKey, secretKey);
    const payload = {
        nonce: encodeBase64(nonce),
        ephemeralPublicKey: encodeBase64(publicKey),
        ciphertext: encodeBase64(encrypted)
    };
    const ipfs = create({ url: 'https://ipfs.infura.io:5001' });
    const result = await ipfs.add(JSON.stringify(payload));
    return result.cid.toString();
}

Infrastructure Security

Сетевая изоляция

Signing ноды, bridge операторы, oracle ноды — не публичны. VPC с private subnets, security groups с минимальными разрешениями.

RPC endpoint безопасность

Публичный RPC — вектор атаки. Alchemy/Infura ключи ротируйте, используйте allowlists по origin. Собственная RPC нода (geth/erigon) в private subnet — лучше. Доступ только через внутренние сервисы.

Мониторинг и алертинг

OpenZeppelin Defender Sentinel мониторит on-chain события, шлёт алерты при аномальных транзакциях из privileged адресов. Forta — децентрализованный мониторинг с community detection agents. Настройка занимает 1-2 недели, но даёт критическую видимость для реагирования.

Что входит в работу при заказе настройки шифрования?

1. Аудит текущей инфраструктуры: оценка рисков, выявление утечек, рекомендации.
2. Проектирование архитектуры: выбор менеджера секретов, HSM, схемы шифрования.
3. Внедрение: развёртывание Vault/HSM, настройка ротации ключей, интеграция с приложениями.
4. Документация: схема инфраструктуры, инструкции по ротации, политики безопасности.
5. Обучение команды: воркшоп по работе с секретами и реагированию на инциденты.
6. Поддержка: мониторинг, алертинг, плановая ротация.

Полная настройка шифрования для production криптопроекта — 3-6 недель в зависимости от объёма инфраструктуры. Для оценки рисков свяжитесь с нами — получите консультацию за 2-3 дня.

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

Когда протокол теряет $197M через 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 имеет смысл для контрактов, которые: управляют > $50M, обновляются редко, имеют чётко формализуемые инварианты. Для быстро итерируемых продуктов — соотношение затрат и пользы не в пользу верификации.

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

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 (Wikipedia).

Oracle manipulation через TWAP. Spot price — стандартная цель для flash loan атаки (Wikipedia). 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 > $3B. Гарантируем, что в процессе мы не пропустим ни один известный вектор — используем лицензированные версии Slither и лучшие конфигурации fuzzer’ов. Предотвращённые убытки для клиентов оцениваются более чем в $50M.

Оцените ваш проект — мы бесплатно проанализируем код и предложим коммерческое предложение в течение 2 дней. Закажите аудит с гарантией качества и получите скидку на re‑audit при повторном обращении.