Как устроена приватная серверная память ИИ и где заканчиваются её гарантии
Разбираем архитектуру Google Private AI Compute: ключи на устройствах, шифрование, аппаратные анклавы, открытый код памяти и выводы независимого аудита.
Почему память переносят в облако
В исходной stateless-схеме Private AI Compute запрос живёт недолго: модель получает данные, формирует ответ, а временный контекст удаляется. Такая схема плохо подходит помощнику, который должен продолжить разговор на другом устройстве или вспомнить решение из прошлой сессии. Хранить всю историю только на телефоне тоже неудобно: её нужно синхронизировать и каждый раз передавать большой объём данных мощной модели в облаке.
23 сентября Google DeepMind описала расширение Private AI Compute с постоянной серверной памятью. Компания предлагает хранить персональный контекст в облаке, но оставлять ключевой секрет на устройствах пользователя. Публикация написана в будущем времени и не называет точную дату массового запуска, список поддерживаемых продуктов или пользовательские настройки удаления. Поэтому речь идёт об архитектуре и проверенной версии кода, а не о независимо испытанной готовой функции.
Два ключа вместо одного
По техническому документу и модели угроз Trail of Bits устройство получает пользовательский секрет и выводит из него ключ шифрования ключей — KEK. Сам сервис создаёт отдельный ключ данных — DEK. Память шифруется DEK, а DEK хранится в обёрнутом виде под KEK. На обычном серверном хранилище остаются шифротекст, wrapped DEK и служебные метаданные; открытого текста там быть не должно.
Это важнее формулы «ключ находится на устройстве». Для обработки запроса ключевой материал всё же попадает на серверную сторону, но только внутрь аттестованной доверенной среды. Иначе облачная модель не смогла бы прочитать память. Заявленная защита строится не на одном приёме, а на цепочке: устройство проверяет идентичность серверного ПО, создаёт шифрованный сеанс, а ключи раскрываются только одобренному коду внутри аппаратно изолированного окружения.
Как проходит запрос
Клиент устанавливает с сервером сеанс по протоколу Noise. Перед передачей данных он проверяет свидетельство удалённой аттестации: оно должно показать, что запущен ожидаемый бинарный файл в подходящей аппаратной среде. Запрос попадает в оркестратор внутри конфиденциальной виртуальной машины на AMD SEV-SNP.
Оркестратор связывается с Memory Oak Server через взаимно аттестованный канал ALTS. После проверки измерений анклава пользовательские ключи раскрываются движку базы. Нужные записи расшифровываются в оперативной памяти анклава, соединяются с текущим запросом и передаются модели на защищённой TPU-платформе. Новый контекст возвращается в Memory Oak Server, шифруется пользовательским DEK и сохраняется как шифротекст. Google утверждает, что временный открытый текст, токены и промежуточные активации очищаются после ответа.
Архитектура позволяет окружающей инфраструктуре реплицировать и резервировать зашифрованную базу без доступа к её содержимому. Но постоянная память меняет модель приватности. Для одноразового запроса система может скрывать связь трафика с конкретным пользователем. Для памяти сервис обязан определить, к чьему хранилищу обратиться. Технический brief прямо говорит, что stateful-вариант не заявляет сетевую «неприцеливаемость»: идентификатор пользователя нужен для маршрутизации, хотя содержимое должно оставаться непрозрачным без ключей.
Что дают анклавы и аттестация
Аппаратный анклав изолирует память гостевой виртуальной машины от хоста и шифрует её. Аттестация связывает разрешение на работу с измерением конкретного кода и конфигурации. Если компонент не предъявляет подходящее свидетельство, он не должен попасть в тракт данных или получить ключи. Внутренние каналы между оркестратором, памятью и inference-системой тоже аутентифицируются и шифруются.
Это уменьшает доверенную область, но не устраняет её. В открытом виде данные существуют внутри анклава во время обработки. Безопасность зависит от аппаратной реализации, механизма аттестации, кода внутри доверенной среды, сборки, выдачи ключей и правил вывода данных. Уязвимость в одном из этих слоёв может ослабить всю цепочку. Поэтому фраза Google «недоступно даже Google» — заявленная цель конструкции, а не математическое доказательство для любого будущего релиза.
Открытый код и публичная запись
Memory Oak Server и базовые компоненты Oak Containers опубликованы в репозитории Project Oak. Приложение памяти написано на Rust. Google связывает исходники с производственным бинарным файлом через воспроизводимую сборку, публикацию хеша в добавляемом журнале и аттестацию того же хеша перед выдачей ключей. Такая цепочка позволяет проверять не только код, но и то, какой бинарный файл заявлен как работающий.
Однако открыта не вся система. Trail of Bits получила доступ к закрытым репозиториям для аудита, но отметила, что важные внутренние модули остаются проприетарными. Ещё одно существенное уточнение: в блоге запись названа защищённой от подделки, а технический brief говорит о tamper-evident журнале и относит независимое наблюдение и совместную подпись непрерывного лога к будущим шагам. Уже опубликованный журнал повышает прозрачность, но не равен полностью независимой инфраструктуре контроля.
Что проверил независимый аудит
Google поручила Trail of Bits построить модель угроз и проверить код защищённой серверной памяти. Четыре консультанта работали с 4 июня по 17 июля 2026 года, суммарно пять инженерных недель; проверка исправлений прошла 5–7 августа. Аудиторы изучали управление ключами, аттестацию, обработку чувствительных данных, клиентскую проверку и протокол Noise. Полный PAIC, hardened TPU, внутренние Keystore и Borg Prime в этот этап не входили. TPU и часть базовой архитектуры ранее выборочно проверяла NCC Group.
Trail of Bits нашла десять проблем: две высокой, одну средней, две низкой и пять информационных. К моменту итоговой проверки Google исправила восемь. Аудиторы не обнаружили в проверенном коде механизма, который давал бы сотрудникам Google доступ к открытому пользовательскому содержимому. Они также указали, что найденные проблемы не давали внешнему атакующему прямого пути к компрометации, но ослабляли прозрачность и сопротивление внутренним угрозам.
Две проблемы остались нерешёнными. Первая имеет низкую серьёзность: хранилище может вернуть старый зашифрованный снимок, из-за чего удалённая память снова появится после следующего сеанса. Это не раскрывает текст без ключа, но означает отсутствие криптографически доказуемого удаления и свежести состояния. Вторая оценена как высокая: усечённые хеши фрагментов ответа отправляются за пределы доверенной вычислительной базы для поиска дословных совпадений. Эксплуатация требует привилегированного внутреннего доступа и сложна; Google сообщила о планах внедрить дополнительный фильтр внутри анклава, но аудит сохранил статус unresolved.
Что в итоге можно считать подтверждённым
Документы согласованно описывают конкретную конструкцию: секрет для KEK выводится на клиенте, пользовательский DEK хранится только в обёрнутом виде, открытый текст должен появляться лишь внутри аттестованных сред, а сервер памяти и среда Oak доступны для внешнего изучения. Публичный отчёт Trail of Bits подтверждает, что аудиторы видели исходники и конфигурации, нашли реальные дефекты и проверили исправления восьми из десяти проблем.
Не подтверждены абсолютная недоступность данных при любом сбое, надёжное удаление старых состояний и полная открытость всего производственного тракта. Аудит — срез определённой версии за ограниченное время. Google может изменить закрытые компоненты после проверки, а пользователь пока не получает полный набор доказательств непосредственно на своём устройстве. Именно поэтому клиентскую проверку аттестации, независимое наблюдение журнала и расширение воспроизводимых сборок компания сама относит к дальнейшей работе.
Практический вывод для оценки подобных систем простой: смотреть нужно не только на наличие шифрования. Важно выяснить, где появляется открытый текст, кто выдаёт ключи, что именно аттестуется, какая часть кода открыта, можно ли связать исходник с производственным бинарником, как устроено удаление и какие компоненты не вошли в аудит. Приватная серверная память делает длительный контекст совместимее с мощными облачными моделями, но переносит доверие с обычного сервера на более узкую и проверяемую — всё же не безошибочную — цепочку аппаратуры, кода и ключей.
