"key.json: что это, почему опасно и как с ним обращаться"

Что такое key.json — определение и контексты использования

key.json — это не одно универсальное правило, а обычно просто имя файла в формате JSON, в котором приложения и сервисы хранят секретную информацию: приватные ключи, параметры шифрования, учетные данные сервис-аккаунтов и т.д. В криптовалютном мире наиболее распространённые значения ключа на filename key.json:

• Ethereum-keystore (Web3 Secret Storage) — часто файлы называются UTC--...--<address>.json, но разработчики и сервисы иногда переименовывают их в key.json.
• Solana CLI / keypair — JSON-массив из 64 чисел (байтов), часто сохраняют как keypair.json или key.json.
• Cloud/service keys — Google Cloud Service Account, AWS/other SDKs — JSON с полями private_key, client_email, project_id и т.д.; обычно называют service-account-key.json или key.json.

Важно: по содержанию и рискам эти файлы очень разные, но общий тезис прост — любой key.json, содержащий приватный ключ или credentials, представляет критическую точку атаки.

Примеры форматов (конкретика)

1) Ethereum keystore (Secret Storage v3)

• Стандарт: "version": 3
• Поля: address, id (UUID), crypto { cipher, ciphertext, cipherparams { iv }, kdf, kdfparams, mac }
• Частая комбинация: cipher = "aes-128-ctr", kdf = "scrypt", kdfparams: dklen = 32, n = 262144, r = 8, p = 1.
• Примерный размер файла: 800–1 800 байт (0.8–1.8 KB) в зависимости от представления hex/base64 и метаданных.
• Что это даёт: приватный ключ зашифрован с паролем пользователя; kdf (scrypt) замедляет перебор паролей.

2) Solana keypair

• Формат: JSON-массив из 64 целых значений 0–255 (закрытый ключ + публичная часть). Пример длины: ~250–350 байт.
• Без шифрования по умолчанию — если файл попал в чужие руки, кошелёк уязвим полностью.

3) Google Cloud service account key.json

• Поля: type, project_id, private_key_id, private_key (PEM в строке), client_email и прочее.
• Размер: ~1.5–2.5 KB.
• Угроза: полный доступ к облачным API, возможность создавать VM, базы данных, прочие ресурсы до финансовых потерь.

Почему key.json — это «единица смерти» инфраструктуры: числа и факты

• Утечки ключей в публичные репозитории остаются частой причиной компрометаций. По скромным оценкам индустрии, ежегодно тысячи (не десятки) сервис-аккаунтов и приватных ключей обнаруживаются в публичных репозиториях GitHub/GitLab; только малая доля из них быстро отзывается.
• Для Ethereum-аккаунтов: если злоумышленник получает доступ к файлу keystore (key.json) и подбирает пароль — он мгновенно контролирует адрес. Типично при слабом пароле (менее 60 бит энтропии) время взлома на современных GPU-кластерах — часы–дни.
• Параметры scrypt N=262144 (применяются в geth) делают проверку одного пароля на обычном CPU ≈ 0.1–0.5 секунды, т.е. 2–10 попыток в секунду на ядро. На GPU ускорение ограничено, но при специально настроенных установках можно достигать тысяч попыток в секунду для слабых kdf. Практический вывод: пароль 8 символов (≈40 бит) — статистически легко подбираем; 12–16 символов с высокой энтропией — существенно безопаснее.
• Solana keypair без пароля — компрометация мгновенная: файл + одно чтение = перехват средств.

(Числа приведены как иллюстрация: реальные времена зависят от железа, текущих настройок kdf и оптимизаций кода.)

Как злоумышленники находят и используют key.json

Типичные векторы обнаружения и последующей эксплуатации:

• Публикация в git-репозитории: разработчики вставляют ключи в код или конфиг, затем пушат в публичный репозиторий. Автоматические сканеры (например, для багбаунти/поиска секретов) находят их в течение минут–часов.
• Компрометация CI/CD: секреты в конвейере сборки (env vars) экспортируются и оказываются в артефактах.
• Фишинговые страницы и лукавые формы: пользователю предлагают импортировать key.json на «удобный» сервис, в результате файл утекает.
• Локальные бэкапы и облачные синки: автоматический бэкап в Dropbox/Google Drive/OneDrive без шифрования.

После получения файла злоумышленник: 1. Анализирует формат и определяет, зашифрован ли приватный ключ. 2. Если зашифрован — приступает к перебору пароля (с учётом kdf-параметров). 3. Если не зашифрован — немедленно выводит средства или использует права облака.

Оценка риска по типу файла (числа в сравнении)

• Не зашифрованный приватный ключ (например, Solana keypair без пароля): риск = 100% компрометации; время до потерь — минуты.
• Ethereum keystore с scrypt (N=262144, r=8, p=1) + слабый пароль (~40 бит энтропии): риск высокий — часы/дни.
• Ethereum keystore + пароль 80 бит энтропии (~12 случайных слов/символов): практически безопасно — перебор займёт десятилетия на доступной атакующей инфраструктуре.
• Service-account key.json (Google Cloud) в открытом доступе: риск критический — возможны прямые финансовые убытки от запуска ресурсов. Типичная стоимость аренды VM и майнинга в облаке позволяет злоумышленнику генерировать сотни долларов в час; одна утечка может стоить тысячи долларов за несколько часов.

Практические меры защиты (конкретика и "цифры")

1) Минимизировать surface:

• Не храните приватные ключи в исходниках и публичных бэкапах. Ноль — это лучшая политика.
• Проверка git-репозиториев перед пушем: pre-commit хуки, git-secrets. Внедрите эти проверки во все репозитории: это снижает вероятность утечки на 90%+ при регулярном использовании.

2) Усиление паролей и параметров KDF:

• Для keystore используйте пароли с энтропией ≥ 80–128 бит (примерно 12–20 случайных слов или 20–30 случайных символов).
• При возмож-ности выбирайте scrypt с N ≥ 2^18 (262144), r=8, p=1 или Argon2id с time=4, memory ≥ 64 MB. Эти параметры целенаправленно замедляют проверку пароля до сотых–десятых долей секунды на CPU.
• Проверка: если перебор одного пароля занимает 0.2 с на вашей машине, attacker может проверять ~5 паролей/сек на ядро; множьте на число ядер/узлов — становитесь реалистичными в оценке.

3) Хранение: аппаратные решения

• Для средств крупных сумм используйте hardware wallets (Ledger, Trezor): приватный ключ никогда не покидает устройство.
• Для сервисов и интеграций — HSM или облачные KMS (например, AWS KMS, Google Cloud KMS). KMS предоставляет возможности ограничить экспорт ключей и вести аудит. Для организаций с оборотами >100k–1M USD в месяц это стандарт.

4) Multisig и пороговые схемы

• Распределите контроль: multisig для кошельков (2/3, 3/5) снижает риск одиночной компрометации; пороговые подписи (threshold) дают ещё более гибкие варианты.
• Для DAO/фондов рекомендуется минимум 3 подписанта с квотированием и временными задержками транзакций.

5) Ротация и мониторинг

• Ротация ключей: периодическая замена ключей для сервисов (например, каждые 90 дней) снижает окно атаки.
• Мониторинг: настройте оповещения о неожиданных выводах средств, интеграции с блокчейн-аналитикой и SIEM для service-account.

Что делать при обнаружении утечки key.json — чеклист действий

1) Немедленное действие

• Для кошельков: как можно быстрее переместить средства в холодный кошелёк (hardware wallet или multisig) через безопасное устройство, если приватный ключ можно декодировать. При невозможности — отслеживать адресы и оповестить биржи.
• Для сервис-ключей облака: отозвать ключ (rotate/delete) и создать новый. Отключить счета/права, если нужно.

2) Анализ и инструменты

• Определите, какой тип key.json был скомпрометирован (формат).
• Для Ethereum-keystore проверьте kdfparams и оцените время перебора паролей; используйте оффлайн-аудит пароля при наличии заранее (ни в коем случае не отправляйте файл в онлайн-сервисы).
• Логи и источники утечки: git history, CI logs, бэкапы.

3) Уведомление и предотвращение повторного компромета

• Сообщите пользователям/партнёрам о риске и действиях.
• Обновите политики: запрет на хранение ключей в репозиториях, внедрение KMS/HSM.

Инструменты и утилиты для безопасной работы с key.json

• Для анализа Ethereum keystore: ethereumjs-wallet (Node.js), geth account import, pyethereum/eth-keyfile инструменты.
• Для Solana: solana-keygen, solana-cli.
• Для поиска утечек в коде: git-secrets, trufflehog, detect-secrets.
• Для облачных секретов: Google Secret Manager, AWS Secrets Manager, HashiCorp Vault — используют версионирование и аккуратные доступы.

Заключение: один файл — много рисков, но есть простые контрмеры

key.json сам по себе — лишь контейнер. Но контейнер, который может содержать ключ к деньгам, инфраструктуре и доверию. Основные идеи, которые стоит вынести:

• Всегда относитесь к key.json как к секрету первого уровня. Даже временное хранение в облаке или репозитории без шифрования — потенциальная катастрофа.
• Используйте аппаратные подписи, multisig и облачные KMS для production-сценариев. Для личных кошельков — hardware wallet.
• Усильте KDF и пароли: scrypt N=262144 и пароль высокой энтропии — базовый минимум для Ethereum-keystore.
• Внедрите автоматические сканеры и политику ротации: предотвращение утечки дешевле её ликвидации.