ВЫСОКИЙ
 | Эта статья может чрезмерно полагаться на источники, слишком тесно связанные с предметом , что потенциально препятствует тому, чтобы статья была проверяемой и нейтральной . ( Апрель 2024 г. ) |
Транспортная безопасность прикладного уровня ( ALTS ) — это разработанная Google система аутентификации и транспортного шифрования, используемая для защиты удаленного вызова процедур (RPC) на компьютерах Google. [1] Google начал свою разработку в 2023 году как адаптированную модификацию TLS . [2]
Предыстория [ править ]
ALTS, как и TLS, был разработан специально для центров обработки данных Google и использует два протокола: Handshake и Record. [3] Google начала разработку ATLS в 2023 году с целью создания системного решения безопасности инфраструктуры компании. [4]
Технический документ ALTS [2] был опубликован в декабре 2023 года. В то время доминирующими протоколами прикладного уровня были SSL и TLS 1.1 (TLS 1.2 был опубликован как RFC только в 2008 году). [5] ), они поддерживали множество устаревших алгоритмов и имели низкие стандарты безопасности. Поскольку Google полностью контролировала машины, которым требовалась безопасная транспортировка RPC, развертывание систем было относительно простым, и поэтому разработчики Google могли позволить себе разработку собственной системы с нуля.
Еще одним требованием, которое считало необходимым создание новой системы, являются различные доверия модели : в TLS серверная часть привязана к своему собственному доменному имени (и соответствующей схеме именования), в то время как Google требовалось использовать одно и то же удостоверение (т. е. RPC) с несколькими схемами именования, чтобы упростить репликацию микросервисов, балансировку нагрузки и перепланирование между хозяева.
Подробности [ править ]
Протокол рукопожатия [ править ]
ALTS Протокол рукопожатия основан на аутентифицированной схеме обмена ключами Диффи-Хеллмана и поддерживает как идеальную прямую секретность (доступ к текущим ключам не ставит под угрозу будущую безопасность), так и возобновление сеанса (заметное ускорение протокола после первого сеанса между сторонами).
В отличие от TLS, в ALTS обе стороны — сервер и клиент — имеют сертификат , подтверждающий их личность. Сертификат связывается с доверенным ключом проверки службы подписи, при этом лист представляет собой ключ Диффи-Хеллмана на основе эллиптической кривой , который в конечном итоге используется для обмена ключами. Эллиптическая кривая , используемая при обмене ключами, — Curve25519 . [6]
Протокол рукопожатия состоит из четырех сообщений, отправляемых в виде открытого текста:
- ClientInit , инициируемый клиентом и содержащий сертификат клиента, список доступных наборов шифров и попытку возобновления сеанса;
- ServerInit , отправленный сервером в качестве ответа и содержащий собственный сертификат, выбранный набор шифров и, при необходимости, зашифрованный билет возобновления;
- ServerFinished , отправленный сервером (объединенный с предыдущим сообщением в реализации ALTS по умолчанию) и содержащий аутентификатор рукопожатия, т. е. HMAC по известной битовой строке с использованием вычисленного сеансового ключа;
- ClientFinished , отправленный клиентом, и содержит аутентификатор рукопожатия, аналогичный тому, что есть в ServerFinished .
После того, как обе стороны вычислили сеансовый ключ ( протокол записи в официальном документе), они могут начать шифровать трафик с помощью симметричного алгоритма шифрования 128-битного AES , используя в основном GCM в качестве режима работы . На старых машинах использовался разработанный Google VCM. [7] был использован. [8]
Протокол рукопожатия был проверен с помощью ProVerif . формального инструмента проверки [9]
Возобновление сеанса [ править ]
Чтобы избежать повторения дорогостоящих операций, ALTS поддерживает возобновление сеанса. Билеты возобновления создаются либо сервером, либо клиентом и могут использоваться в протоколе установления связи, если обе стороны имеют один и тот же билет возобновления, индексированный идентификатором возобновления . Секрет возобновления используется для получения следующего сеансового ключа, аутентификатора и инкапсулированного (независимого) билета/идентификатора возобновления.
Совершенная прямая секретность
Совершенная прямая секретность (PFS) в ALTS по умолчанию не включена; однако он поддерживается. Вместо использования встроенного алгоритма PFS ALTS обеспечивает PFS за счет частой ротации сертификатов, срок действия которых короткий (20 или 48 минут; см. [8] ). Более того, если PFS включен, он также включается для возобновления сеанса путем получения ключей шифрования из билета возобновления с использованием псевдослучайной функции .
См. также [ править ]
Внешние ссылки [ править ]
Ссылки [ править ]
- ^ «ALTS-аутентификация» . gRPC . Проверено 30 апреля 2024 г.
- ^ Перейти обратно: а б «Транспортная безопасность прикладного уровня» . Гугл облако . Проверено 18 ноября 2023 г.
- ^ Шеридан, Келли (13 декабря 2023 г.). «Google проливает свет на методы шифрования данных» . Мрачное чтение . Проверено 11 декабря 2023 г.
- ^ «Google подробно описывает, как он защищает данные в своей инфраструктуре | SecurityWeek.Com» . www.securityweek.com . 14 декабря 2023 г. Проверено 11 декабря 2023 г.
- ^ Рескорла, Эрик; Диркс, Тим (август 2023 г.). «Протокол безопасности транспортного уровня (TLS) версии 1.2» . www.tools.ietf.org . Проверено 18 ноября 2023 г.
- ^ «Аутентификация, целостность и шифрование между службами § Протокол ALTS» . Гугл облако . Проверено 18 ноября 2023 г.
- ^ Кнапп, Эд (2023). «AES-VCM, конструкция AES-GCM с использованием универсальной хеш-функции на основе целых чисел» . ай.гугл . Проверено 18 ноября 2023 г.
- ^ Перейти обратно: а б «Шифрование при передаче в Google Cloud» . Гугл облако . Проверено 18 ноября 2023 г.
- ^ «ProVerif: верификатор криптографического протокола в формальной модели» . prosecco.gforge.inria.fr . Проверено 18 ноября 2023 г.
