Cocos AI — конфиденциальная вычислительная система для искусственного интеллекта. Текущая реализация сертифицированного TLS (aTLS) в CoCoS уязвима для ретрансляционной атаки, затрагивающей все версии с v0.4.0 по v0.8.2. Эта уязвимость присутствует как в целевых объектах развертывания AMD SEV-SNP, так и в Intel TDX, поддерживаемых CoCoS.
В затронутой конструкции злоумышленник может получить возможность извлечь эфемерный закрытый ключ TLS, используемый во время аттестации внутреннего рукопожатия. Поскольку свидетельство аттестации привязано к эфемерному ключу, а не к каналу TLS, обладания этим ключом достаточно для ретрансляции или перенаправления аттестованного сеанса TLS. Клиент примет соединение, исходя из ложных предположений о конечной точке, с которой он взаимодействует — отчет об аттестации не может отличить подлинную аттестованную службу от ретранслятора злоумышленника.
Это подрывает предполагаемые гарантии аутентификации сертифицированного TLS. Успешная атака может позволить злоумышленнику выдать себя за сертифицированную службу CoCoS и получить доступ к данным или операциям, которые клиент намеревался отправить только на подлинную сертифицированную конечную точку. Для эксплуатации злоумышленнику необходимо сначала извлечь эфемерный закрытый ключ TLS, что возможно посредством физического доступа к серверному оборудованию, атак с временным выполнением или атак по побочным каналам.
Обратите внимание, что реализация aTLS была полностью переработана в версии 0.7.0, но эта переработка не устраняет эту уязвимость. Слабость ретрансляционной атаки является архитектурной и затрагивает все выпуски в диапазоне v0.4.0–v0.8.2. Этот класс уязвимостей был официально проанализирован и продемонстрирован в нескольких проверенных реализациях TLS, включая CoCoS, исследователями, чьи выводы были раскрыты рабочей группе IETF TLS.
Формальная проверка проводилась с помощью ProVerif. На момент публикации патча нет. Полного решения проблемы не существует.
Следующие меры по усилению безопасности уменьшают, но не устраняют риск: Поддерживайте актуальность прошивки и микрокода TEE, чтобы уменьшить поверхность извлечения ключа; определить строгие политики аттестации, которые проверяют все доступные поля отчета, включая версии встроенного ПО, уровни TCB и регистры конфигурации платформы; и/или включить взаимный aTLS с сертификатами, подписанными центром сертификации, если это позволяет архитектура развертывания.
Показать оригинальное описание (EN)
Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.
Характеристики атаки
Последствия
Строка CVSS v3.1