На threat-modeling сессии для распределённой платёжной системы на AWS стояла конкретная задача: три организации должны совместно подписывать транзакции, но ни одна не должна видеть полный закрытый ключ - включая оператора облака. HSM отпал первым: единственная точка доверия. TEE на базе Intel SGX - вторым: к тому моменту по SGX уже накопился десяток опубликованных атак - CacheZoom, SGX-Step, AsyncShock, Controlled-Channel Attacks (список есть в обзоре dcerezo на ethresear.ch). Остался MPC - threshold ECDSA с тремя участниками. Протокол заработал за неделю. Проблемы начались на третьей: red-team показал, что semi-honest модель безопасности, заложенная в реализацию, рассыпается при столкновении с реальной облачной инфраструктурой, где любой участник может вести себя произвольно.
В этой статье мы разберём, как MPC работает на уровне криптографии, где именно ломается при деплое в облако и какие конкретные векторы атак нужно закрывать. С примерами кода на MP-SPDZ и маппингом на MITRE ATT&CK.
Криптографические протоколы MPC: архитектура для вычислений на зашифрованных данных
MPC - семейство криптографических протоколов, где N участников совместно вычисляют функцию F(d₁, d₂, ..., dN) над своими приватными входами, не раскрывая эти входы друг другу. Концепция восходит к работе Эндрю Яо 1982 года (проблема миллионеров), генерализация для произвольного числа участников - к Голдрайху, Микали и Вигдерсону (GMW). Парадигма GMW стала базовым шаблоном для всех последующих многосторонних протоколов.
В облачных сценариях secure multi-party computation закрывает три задачи. Первая - распределённое управление ключами через threshold cryptography: закрытый ключ разбит на доли, ни один участник не владеет полным ключом. Fireblocks использует MPC именно так - ключи подписи никогда не собираются в одной точке. Вторая - конфиденциальная аналитика: несколько организаций вычисляют агрегированные метрики, не раскрывая исходные данные. Третья - secure aggregation в федеративном обучении: защита градиентов при совместной тренировке ML-моделей.
Secret sharing и garbled circuits: два подхода к data in use protection
Два доминирующих подхода к построению MPC-протоколов различаются тем, как представлена вычислимая функция.Арифметические схемы + secret sharing. Функция раскладывается на сложение и умножение над конечным полем. Входные данные разбиваются на доли (shares) по схеме Шамира или аддитивному разделению секрета. Сложение - локально, без взаимодействия. Умножение требует обмена сообщениями. Протоколы BGW, CCD и SPDZ работают в этой парадигме. SPDZ (произносится "спидз") вводит фазу предобработки (preprocessing), где генерируются корреляционные тройки Бивера - вычислительно тяжёлая криптография выносится в offline-фазу, а online-вычисление летит быстро. По оценкам с ethresear.ch, MPC с preprocessing даёт ускорение на порядок по сравнению с вариантами без него.
Логические схемы + garbled circuits. Функция - булева схема из вентилей AND, OR, NOT. Один участник "запутывает" (garbles) схему, шифруя таблицы истинности каждого вентиля; второй вычисляет через протокол забывчивой передачи (oblivious transfer), получая зашифрованные входы без знания соответствия значений. Garbled circuits Яо эффективны для бинарных операций и сравнений, работают за постоянное число раундов, но плохо масштабируются на большие входы. Для обхода - комбинации с ORAM и специальные схемы garbling RAM Programs.
Выбор определяется типом вычислений: арифметические схемы оптимальны для линейных операций (суммирование, статистика, линейные слои нейросетей), garbled circuits - для логики и сравнений. На практике гибридные протоколы комбинируют оба подхода для разных частей вычисления.
Модели безопасности MPC: semi-honest, malicious и почему это критично в облаке
Безопасность MPC-протокола определяется моделью угроз - допущениями о поведении скомпрометированных участников. И вот тут начинается самое интересное.Semi-honest (honest-but-curious, passive). Скомпрометированный участник следует протоколу, но пытается извлечь дополнительную информацию из промежуточных данных. Протоколы в этой модели проще и быстрее: базовый Shamir secret sharing, стандартные garbled circuits. Проблема: в облачной среде это допущение почти никогда не выполняется. Скомпрометированная VM может произвольно модифицировать сообщения - никакой внешний механизм не заставит её "честно следовать" протоколу.
Malicious (active). Скомпрометированный участник произвольно отклоняется от протокола: шлёт неверные данные, нарушает порядок сообщений, бросает сессию. Протоколы SPDZ, BDOZ, MASCOT используют MAC-аутентификацию долей и zero-knowledge proofs для верификации корректности. Overhead по сравнению с semi-honest: 10-100x по латентности, 2-10x по пропускной способности. Некоторые MPC-протоколы достигают сотен миллионов AND-гейтов в секунду (оценка относится преимущественно к semi-honest garbled circuits; malicious-secure варианты, например authenticated garbling, существенно медленнее).
Covert. Промежуточная модель: злоумышленник отклоняется от протокола, но рискует быть обнаруженным с вероятностью ε. В облаке с псевдонимными инстансами, где репутационные потери минимальны, модель работает плохо.
Adaptive corruption - отдельная головная боль, описанная на crypto.stackexchange. При статической коррупции набор скомпрометированных участников фиксирован до запуска. При адаптивной - атакующий компрометирует новых участников во время выполнения, получая их внутреннее состояние. Безопасность при адаптивной коррупции нетривиальна даже если все участники в конечном счёте скомпрометированы - симулятор должен корректно генерировать внутреннее состояние каждого нового скомпрометированного участника.
И вот ключевой момент, который я почти не встречаю в русскоязычных разборах: облачный провайдер не является участником протокола, но контролирует исполнительную среду. Он видит сетевой трафик между участниками, контролирует гипервизор, измеряет timing вычислений. Стандартные модели безопасности MPC этого adversary не учитывают - он вне threat model протокола, но внутри threat model инфраструктуры.
Конфиденциальные вычисления в облаке: MPC vs TEE vs HSM
При проектировании защиты данных в облаке MPC конкурирует с Trusted Execution Environments и Hardware Security Modules. Каждый подход ломается в своём месте.
| Подход | Преимущества | Ограничения | Когда использовать | Когда НЕ использовать |
|---|---|---|---|---|
| MPC | Не требует доверия к оператору; произвольные вычисления; криптографическая защита содержимого сообщений; не требует доверия к железу | Latency 10-100x; O(N²) коммуникация; не валидирует входы | Cross-org analytics; threshold key management; federated ML | Одна организация; latency < 10ms; простые крипто-операции |
| TEE (SGX/TDX/SEV) | Низкий overhead (~1x); произвольный код; изоляция от ОС | Доверие к вендору CPU; публичные атаки (CacheZoom, SGX-Step); rollback-атаки | Одна организация; доверие к Intel/AMD приемлемо; latency-critical | Multi-org без доверия к инфраструктуре; post-quantum требования |
| HSM (Cloud KMS) | Высокая физическая защита; сертификация FIPS 140-2/3; низкий overhead | Только крипто-операции; единая точка доверия; дорого ($3-5/час managed) | Управление ключами; подпись; шифрование at rest | Произвольные вычисления; multi-org сценарии |
Когда MPC необходим: когда ни один участник (включая оператора инфраструктуры) не должен видеть полные данные. Характерный пример - Датский сахарный аукцион 2008 года: фермеры определяли рыночную цену через электронный аукцион, скрывая ставки друг от друга. Это было первое крупномасштабное практическое применение MPC.
Когда MPC избыточен: данные принадлежат одной организации и задача - защитить их при обработке в облаке. TEE (при принятии рисков side-channel) или HSM (для крипто-операций) будут дешевле и проще. Не надо тащить threshold-протокол туда, где хватает KMS.
Векторы атак на MPC-деплойменты в облаке
Русскоязычные источники по MPC криптографии разбирают теоретическую корректность протоколов. Что происходит, когда криптографическая модель сталкивается с инженерной реальностью облачной инфраструктуры - не разбирает никто. Копнём.Selective abort: утечка через отказ от вычисления
В протоколах с допустимым abort (security-with-abort) скомпрометированный участник может получить результат вычисления до его доставки остальным. Если результат удовлетворяет некоторому предикату - завершает протокол штатно. Если нет - инициирует abort. Каждый abort утекает один бит информации.Конкретный сценарий: два банка совместно вычисляют, превышает ли совокупный объём подозрительных транзакций порог. Malicious участник при каждом запуске получает ответ "да/нет". Не устраивает - abort, пересогласование параметров, повторный запуск. За N итераций бинарный поиск сужает значение до N-битной точности.
Защита: guaranteed output delivery - протоколы, где результат доставляется всем участникам или никому. Требуется honest majority (> N/2 честных участников) с безопасными каналами. В двусторонних протоколах (2PC) guaranteed output delivery без доверенной третьей стороны невозможна в стандартной модели.
Side-channel через timing и сетевые паттерны
MPC-протоколы криптографически защищают содержимое сообщений, но не метаданные: размер, время отправки, порядок обмена. В облаке это критичная поверхность атаки.Timing side-channel. Если протокол содержит data-dependent branching (условные вычисления с разным временем выполнения в зависимости от значений), облачный оператор или co-tenant VM измеряет время через: задержки между раундами, нагрузку CPU через кросс-VM side-channel, паттерны обращения к кэшу. Маппится на Network Sniffing (T1040, credential-access, discovery) - пассивный сбор сетевого трафика.
Adversary-in-the-Middle (T1557, credential-access, collection). Если каналы между участниками не аутентифицированы или аутентификация скомпрометирована - атакующий подменяет сообщения протокола. В malicious-модели это приводит к обнаружению (MAC verification failure). В semi-honest реализациях - к молчаливому искажению результатов. Без детекции.
Transmitted Data Manipulation (T1565.002, impact). Модификация долей в транзите. В протоколах с аутентифицированными долями (SPDZ MAC) манипуляция детектируется. В базовом аддитивном secret sharing, как в примере из работы Баргсяна (CyberLeninka), MAC отсутствует - манипуляция проходит незамеченной.
Компрометация участников: от Cloud Accounts до supply chain
Самый практичный вектор атаки на MPC в облаке - компрометация compute nodes. Не протокол ломают, а инфраструктуру под ним.Cloud Accounts (T1078.004, initial-access, persistence, privilege-escalation, defense-evasion). Компрометация облачной учётной записи, управляющей MPC-нодой, даёт полный контроль над одним участником. В 2PC - это эквивалент malicious adversary. В многосторонних протоколах зависит от порога: если протокол обеспечивает perfect security при t < N/3 malicious участников (результат BGW; с broadcast каналами и statistical security достижимо t < N/2 (Rabin, Ben-Or); computational security при t < N/2 достижима с криптографическими допущениями (GMW, SPDZ)), компрометация одного из трёх и более участников может быть допустимой. Скомпрометировано t+1 участников - приватность нарушена.
Private Keys (T1552.004, credential-access). Извлечение долей закрытого ключа с compute node. В threshold-ECDSA при пороге t компрометация t+1 долей из N позволяет восстановить полный закрытый ключ. Хранение долей в памяти в открытом виде (in-memory plaintext) - стандартная ситуация для большинства MPC-фреймворков. Proactive secret sharing (ротация долей без реконструкции полного ключа) сужает окно уязвимости, но не устраняет его.
Supply Chain Compromise (T1195, initial-access). Компрометация MPC-библиотеки или её зависимостей. Вредоносный патч может: подменить генератор случайных чисел (фиксированный seed -> детерминированные доли -> утечка входов), ослабить параметры безопасности (Weaken Encryption, T1600, defense-impairment), или ввести скрытый канал утечки через timing вычислений.
Data from Cloud Storage (T1530, collection). Если доли или промежуточные состояния протокола персистируются (логирование, checkpointing), доступ к хранилищу одного участника раскрывает его долю. Критично для offline/online протоколов типа SPDZ, где preprocessed материал (тройки Бивера, authenticated bits) хранится между фазами и должен использоваться однократно - повторное использование тройки ломает безопасность.
MITRE ATT&CK: маппинг атак на MPC-инфраструктуру
| Вектор | ATT&CK ID | Тактика | MPC-специфика |
|---|---|---|---|
| Перехват трафика между нодами | T1040 (Network Sniffing) | credential-access, discovery | Утечка timing и размеров, не содержимого |
| MITM на каналах обмена | T1557 (Adversary-in-the-Middle) | credential-access, collection | Подмена долей; MAC детектирует в malicious-протоколах |
| Модификация долей в транзите | T1565.002 (Transmitted Data Manipulation) | impact | Искажение результата без детекции в semi-honest |
| Захват облачного аккаунта | T1078.004 (Cloud Accounts) | initial-access, persistence, privilege-escalation, defense-evasion, stealth | Полный контроль одного участника |
| Извлечение ключевых долей | T1552.004 (Private Keys) | credential-access | t+1 долей - полный ключ |
| Backdoor в MPC-библиотеке | T1195 (Supply Chain Compromise) | initial-access | RNG backdoor или отключение MAC |
| Ослабление параметров | T1600 (Weaken Encryption) | defense-impairment | Снижение размера поля или числа раундов |
| Доступ к stored shares | T1530 (Data from Cloud Storage) | collection | Preprocessed material, checkpoint'ы (применимо к IaaS: AWS, Azure) |
Практика: тестирование безопасности MPC с MP-SPDZ
Требования к окружению
- ОС: Ubuntu 22.04 LTS / Debian 12 (macOS - с ограничениями сборки)
- RAM: 8 ГБ минимум для semi-honest протоколов; 16 ГБ для malicious (MASCOT, SPDZ)
- CPU: 4+ ядра (параллельные потоки ускоряют preprocessing)
- Зависимости: Python 3.8+, GCC 11+, OpenSSL 3.x, Make, Git
- Сеть: для распределённого запуска - прямая TCP-связность; для локального тестирования - loopback
- Фреймворк: MP-SPDZ - наиболее зрелая открытая реализация, поддерживает более 30 протоколов
Разница между semi-honest и malicious на практике
Ключевой тест для аудита MPC-деплоймента: запустить одну функцию в обоих режимах, модифицировать одну долю - и посмотреть, детектирует ли протокол подмену.Сборка и подготовка:
Bash:
git clone [URL='https://github.com/data61/MP-SPDZ']https://github.com/data61/MP-SPDZ.git[/URL] && cd MP-SPDZ
sudo apt install -y automake build-essential git libboost-dev libboost-thread-dev libntl-dev libsodium-dev libssl-dev libtool python3 texinfo yasm
make -j8 tldr
make -j8 shamir-party.x mascot-party.x
./Scripts/setup-ssl.sh 3Programs/Source/sum3.mpc):
Python:
# sum3.mpc - три участника вводят числа, вычисляется сумма
a = sint.get_input_from(0)
b = sint.get_input_from(1)
c = sint.get_input_from(2)
print_ln("Sum: %s", (a + b + c).reveal())./compile.py sum3) и подготовки входов в Player-Data/Input-P{0,1,2}-0:
Bash:
# Semi-honest (Shamir) - НЕ детектирует модификацию долей
./shamir-party.x -N 3 -T 1 -p 0 sum3 &
./shamir-party.x -N 3 -T 1 -p 1 sum3 &
./shamir-party.x -N 3 -T 1 -p 2 sum3
# Malicious (MASCOT) - детектирует подмену через MAC
./mascot-party.x -N 3 -p 0 sum3 &
./mascot-party.x -N 3 -p 1 sum3 &
./mascot-party.x -N 3 -p 2 sum3mascot-party.x добавляет authenticated sharing - каждая доля идёт с MAC. Если участник модифицирует свою долю (имитация malicious behaviour), Shamir молча выдаст неверный результат. MASCOT детектирует подмену и прервёт вычисление с ошибкой MAC verification.Для воспроизведения детекции подмены нужно активно модифицировать трафик между нодами - через MITM-прокси с изменением байтов в сообщениях протокола или патч сетевого слоя MP-SPDZ одного из участников. Именно эту разницу надо проверять при аудите реального деплоймента. Протокол, который не детектирует модификацию долей, не обеспечивает безопасность в облачной среде - и точка.
Ограничения техники
Latency. Даже для простейших вычислений MPC добавляет overhead: 1-10ms для semi-honest локально, 50-500ms для malicious при WAN. Для ML inference overhead достигает 1000x по сравнению с plaintext. MPC быстрее homomorphic encryption (оценка ethresear.ch: ~1000x), но на порядки медленнее plaintext-вычислений.Коммуникационная сложность. Большинство протоколов - O(N^2) по числу сообщений. Для 3-5 участников приемлемо. Для 100+ - нужны специализированные протоколы (tree-based aggregation, server-aided MPC).
Input validation. MPC гарантирует приватность входов, но не их корректность. Участник может ввести ноль, максимальное значение поля, заведомо мусорные данные. Валидация требует range proofs или ZKP - дополнительный overhead.
Preprocessing dependency. В offline/online протоколах (SPDZ) preprocessing генерирует корреляционную рандомность. Компрометация preprocessing ломает все последующие online-вычисления. Повторное использование троек Бивера - критическая уязвимость. Это не теоретическая проблема: на одном аудите мы видели деплоймент, где тройки переиспользовались "для экономии" - потому что "preprocessing дорогой".
Output inference. MPC защищает входы, но результат доступен всем. Если функция проста (сумма двух входов), знание результата и своего входа тривиально раскрывает вход другого. Проектирование функций, устойчивых к output inference - задача, которую криптография протокола не решает.
Чеклист безопасности MPC-деплоймента в облаке
Десять лет назад MPC был конструкцией для публикаций - слишком медленной для production. Сейчас threshold-ECDSA подписывает транзакции у кастодиальных сервисов, secure aggregation защищает градиенты в федеративном обучении, конфиденциальная аналитика работает в регуляторных песочницах.
Но разрыв между криптографической моделью и инженерной реальностью никуда не делся. Большинство MPC-деплойментов, которые я видел на аудитах, используют semi-honest протоколы в средах, где любой участник может вести себя как malicious - потому что MASCOT "в десять раз медленнее Shamir". Это security theatre: semi-honest ECDSA, скомпрометированный через одну ноду на AWS, - не защита, а иллюзия.
Вторая системная проблема - восприятие MPC как серебряной пули. Он решает ровно одну задачу: приватность входов при совместном вычислении. Не решает input validation, output inference, side-channel через инфраструктуру, supply chain. Каждая из этих точек требует отдельного инженерного решения, не имеющего отношения к криптографии.
В ближайшие пару лет основной фронт будет не в ускорении протоколов (хотя и это тоже), а в интеграции MPC с остальным стеком безопасности - IAM, monitoring, incident response, SIEM. Пока MPC-нода живёт в отдельной вселенной от детекта аномалий и корреляции событий, она остаётся blind spot для всей цепочки защиты - и самым тихим local privilege escalation в вашей инфраструктуре. Проверьте свой деплоймент по чеклисту выше. Если пункт 1 не выполнен - у вас та же проблема, что была у нас на третьей неделе.
Последнее редактирование модератором:
