Мы описываем облачную службу, которая использует безопасное оборудование для хранения криптографических ключей, так что доступ к ним защищен фактором знаний с низкой энтропией (например, PIN-кодом блокировки экрана). Безопасное оборудование предназначено для предотвращения атак методом перебора, делая сохраненные криптографические ключи навсегда невозвратными после слишком большого количества неудачных попыток предоставить правильный фактор знания.
Автор: Шабси Уолфиш
Дата версии: 06.03.2018
Примечание. Этот документ все еще находится в стадии разработки, и детали реализации все еще дорабатываются. По мере стабилизации системы и появления дополнительной документации мы будем обновлять этот технический документ более подробной информацией (особенно вместе с соответствующими выпусками с открытым исходным кодом).
Обзор
Традиционно шифрование (которое используется для обеспечения конфиденциальности данных) требует использования секретов, имеющих высокую энтропию с точки зрения злоумышленника. Требуется высокая энтропия, поскольку схема шифрования должна противостоять атакам грубой силы, которые исследуют пространство всех возможных секретов, пока не будет найден правильный. Учитывая сегодняшнюю доступность вычислительных мощностей, разумное минимальное требование энтропии для криптографических секретов может составлять от 70 до 80 бит. К сожалению, людям очень трудно запомнить и надежно вспомнить пароли или другие секреты с таким количеством энтропии 1 , особенно если они используются редко (но частое использование паролей с высокой энтропией сложно и утомительно). Это ставит перед нами сложную проблему: как мы можем защитить частные данные с помощью технологии шифрования, если мы хотим, чтобы секрет был «фактором знания», который с большой вероятностью запомнится пользователю? По ряду причин эту проблему настолько сложно решить, что службы облачного хранения обычно шифруют данные только с помощью секретов, которыми управляет сам поставщик облачного хранилища, а не полагаются на то, что пользователь запомнит свой собственный секрет.
Одним из подходов к преодолению разрыва между требованиями к криптографическим секретам и секретам, запоминаемым человеком, является использование службы Cloud Key Vault (CKV) для хранения «ключа восстановления» с высокой энтропией, защищенного секретом, запоминающимся человеком с низкой энтропией. Служба CKV выдаст ключ восстановления только тому лицу, которое докажет знание правильного запоминающегося секрета человека. Атаки грубой силы против памятного человеку секрета могут быть предотвращены службой CKV, которая устанавливает абсолютный лимит на количество неудачных попыток доказать знание секрета. Сам ключ восстановления представляет собой стандартный криптографический симметричный ключ, подходящий для использования со схемой (аутентифицированного) шифрования, которая позволяет легко зашифровать большой объем данных (например, резервную копию диска), которые можно безопасно хранить где угодно. Такие зашифрованные данные бесполезны для шифрования. любой, кто не может получить ключ восстановления.
В этом техническом документе описывается наш подход к созданию службы Cloud Key Vault с использованием доверенных аппаратных модулей (THM). Наша первая реализация службы CKV предназначена для защиты ключей восстановления с помощью пользовательского фактора знания экрана блокировки (LSKF) — секретного PIN-кода, пароля или шаблона смахивания, используемого для разблокировки смартфонов. Люди могут надежно помнить свой LSKF. В то же время такие секреты LSKF обычно обладают достаточной энтропией, чтобы противостоять злоумышленнику, у которого очень ограниченное количество попыток, что делает их хорошо подходящими для службы CKV.
Первым применением нашей службы Cloud Key Vault будет обеспечение резервного копирования Android с шифрованием на стороне клиента. Раньше файлы, зашифрованные локально на устройстве Android, использовали ключ, защищенный LSKF пользователя, но резервные копии этих файлов, хранящиеся (и зашифрованные) в облаке, не были защищены LSKF. Cloud Key Vault впервые обеспечивает защиту экрана блокировки для резервных копий Android, хранящихся в облаке. Это означает, что серверы Google не имеют возможности получить доступ к содержимому зашифрованных резервных копий или восстановить их — только устройство с пользовательским LSKF может расшифровать резервные копии.
Основные понятия
Первоначально единственной поддерживаемой клиентской платформой для службы Cloud Key Vault является операционная система Android 9 Pie, и когда мы говорим о клиенте в этом документе, мы имеем в виду устройство под управлением операционной системы Android 9 Pie со службами Google Play. Наша серверная реализация работает на специально выделенных серверах Google, на которых установлен дополнительный чип Titan 2 . Чип Titan, разработанный Google, служит аппаратным компонентом нашего доверенного аппаратного модуля, и мы специально снабжаем его специальным загрузчиком и прошивкой, которая реализует наши протоколы и механизмы обеспечения безопасности (как описано здесь). Мы используем методы аттестации оборудования, чтобы получить уверенность в том, что наш протокол действительно работает на оборудовании Titan.
Служба CKV должна масштабироваться для обработки трафика с миллиардов 3 устройств Android без потери какого-либо значительного объема пользовательских данных из-за сбоев оборудования (например, перегорания чипов) или длительных простоев из-за обслуживания центров обработки данных. По этой причине серверы с чипами Titan организованы в группы, каждая из которых состоит из нескольких независимых THM, каждый из которых содержит копию одного и того же ключевого материала. Определенная группа будет распределена по физически разным центрам обработки данных в разных зонах обслуживания, чтобы гарантировать, что система сможет достичь своих целей доступности и надежности. В целях масштабируемости клиенты будут разделены на несколько различных когорт, чтобы мы могли регулировать мощность службы, просто добавляя больше серверов и увеличивая количество доступных когорт.
Теперь мы готовы перечислить основные компоненты сервисной архитектуры Cloud Key Vault.
Архитектурные компоненты / Глоссарий
Фактор знания экрана блокировки (LSKF): секрет, запоминаемый человеком, например короткий PIN-код, рисунок смахивания по сетке 3 x 3 точки или пароль. Этот секрет используется для защиты возможности локальной разблокировки устройства и считается основным (или «сильным») фактором аутентификации для блокировки экрана локального устройства пользователя.
Клиент: устройство конечного пользователя, работающее под управлением операционной системы Android 9 Pie и служб Google Play или эквивалентно поддерживаемого программного обеспечения.
Android Framework: мы используем этот общий термин (или просто Framework ) для обозначения API в Android 9 Pie или более поздних версиях, и он не предназначен для обозначения каких-либо более ранних выпусков.
Сервисы Google Play: набор сервисов и приложений, которые запускаются на устройстве конечного пользователя и позволяют ему работать с системой учетных записей Google и пользовательскими API-интерфейсами сервера.
Агент восстановления: системное приложение, работающее как часть сервисов Google Play в пользовательском пространстве на устройстве Android 9 Pie (или аналогичном). Агент восстановления отвечает за выполнение клиентской части различных протоколов и при необходимости за взаимодействие с операционной системой Android для создания любых протокольных сообщений, в которых используется LSKF.
Заявление о восстановлении: когда пользователь хочет получить ключ восстановления, он должен создать заявление о восстановлении, содержащее зашифрованную копию LSKF, о которой, по утверждению пользователя, он знает. Как правило, пользователю будет предложено ввести LSKF своего старого устройства на новом устройстве, которое пытается получить доступ к ключу восстановления старого.
Ключ восстановления: криптографический секретный ключ, который защищен службой Cloud Key Vault и используется для шифрования (и аутентификации) данных на клиентском устройстве. После помещения ключа восстановления в хранилище (см. ниже) локальную копию можно удалить, как только клиент завершит ее использование для шифрования данных.
Служба Cloud Key Vault (CKV): Интернет-служба, которая позволяет клиентским устройствам хранить криптографические ключи, защищенные запоминаемым человеком LSKF.
Когорта: совокупность серверов Vault/THM, которые могут служить резервными копиями друг друга.
Открытый ключ когорты : открытый ключ из пары ключей, сгенерированной определенной группой THM. Соответствующий закрытый ключ доступен только внутри THM, которые были в когорте на момент генерации ключа.
Доверенный аппаратный модуль (THM): специальный модуль безопасности (микроконтроллер), предназначенный для обеспечения минимальной и надежной вычислительной среды. Как минимум, элемент безопасности должен иметь возможность генерировать и/или хранить секретные ключи и поддерживать некоторое энергонезависимое развивающееся состояние (чтобы он мог предотвращать атаки, связанные с возвратом в более раннее состояние).
Хранилище: определенная запись в базе данных службы CKV, содержащая ключ восстановления, защищенный LSKF, для одного устройства. У конечного пользователя может быть несколько хранилищ в файле, каждое из которых соответствует отдельному устройству или LSKF. Только THM на сервере хранилища может проверять или извлекать содержимое хранилища.
Сервер Vault: машина общего назначения, работающая в центре обработки данных Google, специально модернизированная для добавления доверенного аппаратного модуля (THM).
Проектирование протоколов
Протокол CKV состоит из нескольких этапов, а именно:
Инициализация
Для инициализации системы Google предоставит открытый ключ для «корня доверия», который платформа будет использовать для проверки аттестаций оборудования Google. Ключ подписи для этого корня доверия хранится в автономном режиме и тщательно охраняется, поэтому для подписи с его помощью требуется участие нескольких сотрудников. Открытый ключ для этого корня доверия встроен в ОС Android и может быть изменен только посредством обновления ОС.
Google также периодически публикует список открытых ключей для каждой группы THM вместе с подтверждением в списке. Аттестация в списке использует подпись, которая связывается с корнем доверия. Каждое обновление опубликованного списка также содержит порядковый номер, чтобы можно было предотвратить откаты. Агент восстановления получит самый последний опубликованный список открытых ключей когорты и предоставит его платформе. Затем платформа проверяет аттестацию и случайным образом выбирает из списка открытый ключ когорты, который будет использоваться на этапе создания хранилища.
Создание хранилища
Помогая платформе завершить инициализацию путем получения списка открытых ключей когорты , агент восстановления запросит платформу создать новое хранилище. Всякий раз, когда пользователь вводит LSKF в следующий раз, платформа генерирует новый ключ восстановления и шифрует его сначала с помощью ключа, полученного из хэша LSKF, а затем с помощью открытого ключа когорты , выбранного платформой во время инициализации. Полученный зашифрованный большой двоичный объект представляет собой хранилище, которое платформа передает обратно агенту восстановления, который затем загружает его в службу Google CKV.
Открытие хранилища
Когда агенту восстановления на новом устройстве необходимо получить доступ к ключу восстановления , хранящемуся в определенном хранилище , он сначала предложит пользователю ввести LSKF исходного устройства, создавшего хранилище . Затем агент восстановления попросит платформу создать заявку на восстановление с использованием этого LSKF. Платформа сгенерирует новый ключ заявителя и зашифрует этот ключ заявителя, а также хеш заявленного LSKF с помощью того же открытого ключа когорты , которым изначально было зашифровано хранилище . Полученный зашифрованный большой двоичный объект называется запросом на восстановление , и платформа передает его агенту восстановления, который затем передает его службе CKV.
CKV направляет заявку на восстановление (и соответствующее ей хранилище ) на серверы хранилища , входящие в правильную группу. Затем THM на серверах хранилища расшифровывает заявку на восстановление и пытается извлечь ключ восстановления из исходного хранилища , используя заявленный хэш LSKF (для получения внутреннего ключа шифрования). Если исходный хеш LSKF и заявленный хэш LSKF совпадают, THM извлечет ключ восстановления из хранилища и повторно зашифрует его с помощью ключа заявителя , который был в заявке на восстановление . В противном случае THM сработает счетчик неудачных попыток. Как только счетчик неудачных попыток достигнет своего предела, THM откажется обрабатывать любые последующие заявки на восстановление для этого Хранилища .
Наконец, если все прошло хорошо, повторно зашифрованный ключ восстановления (который теперь зашифрован под ключом заявителя ) отправляется обратно с сервера Vault на всю платформу. Платформа использует свою копию ключа заявителя для расшифровки ключа восстановления , и теперь протокол завершен.
Меры безопасности
Система Cloud Key Vault призвана обеспечить «глубокую защиту», включая средства защиты на нескольких уровнях нашего стека. Чтобы дать представление о том, как работают эти средства защиты, мы начнем с описания Клиента и продвинемся вверх по стеку к службе Cloud Key Vault.
Безопасность клиента
В зависимости от конкретного OEM-производителя и устройства фактор знания экрана блокировки (LSKF) обычно сохраняется и защищается на устройстве с использованием различных методов, которые различаются в зависимости от OEM-производителя. Например, устройства Google Pixel 2 используют защищенный от несанкционированного доступа аппаратный модуль безопасности для хранения неактивного LSKF и обеспечения соблюдения аппаратных ограничений скорости при проверке LSKF. Новые API-интерфейсы Framework, которые вводятся для обеспечения возможности использования Cloud Key Vault, предназначены для максимально возможного сохранения существующих гарантий безопасности, даже если устройство использует такой аппаратный модуль безопасности для защиты хранилища LSKF.
В этом разделе мы сосредоточим внимание конкретно на соответствующих проблемах безопасности и средствах защиты, влияющих на новую функцию Cloud Key Vault, а не на попытках предоставить полную картину всех механизмов безопасности, связанных с LSKF.
Защита API платформы
Новые API-интерфейсы Framework, добавленные для поддержки службы CKV, помечены как @SystemApi и требуют специальных разрешений, которые гарантируют, что они доступны только для системных приложений, одобренных OEM, таких как службы Google Play. Это в значительной степени устраняет любую поверхность прямой атаки, которой могут подвергнуться приложения, которые пользователь устанавливает на устройство.
API-интерфейсы Framework также гарантируют, что хранилища создаются только для открытых ключей когорты, подтвержденных корнем доверия. Корень доверия встроен в платформу OEM-производителем при ее поставке и не может быть изменен без обновления ОС. Это дает уверенность в том, что LSKF используется только для создания хранилищ, которые будут должным образом обеспечивать аппаратную защиту от перебора. Полагаясь на THM в службе Cloud Key Vault для защиты LSKF методом перебора, мы можем добиться безопасности, сравнимой с использованием защищенного оборудования на устройстве для той же цели (как это делают устройства Google Pixel 2).
Поскольку мы не предполагаем, что LSKF будет храниться где-либо на устройстве за пределами защищенного оборудования, новое хранилище можно создать только сразу после разблокировки устройства. Когда пользователь вводит LSKF для разблокировки устройства, LSKF на короткое время становится доступным платформе в оперативной памяти. Именно в этот момент его использует новый API для создания Хранилища. Невозможно создать новое хранилище, защищенное LSKF, пока устройство заблокировано, поскольку LSKF недоступен.
Защита агента восстановления
Основная защита безопасности, которую мы обеспечиваем в агенте восстановления, заключается в том, что протокол разработан таким образом, чтобы агент восстановления никогда не видел LSKF текущего устройства или какие-либо ключи восстановления. Только платформа должна видеть эти вещи на стороне клиента, что значительно затрудняет использование любых потенциальных ошибок или уязвимостей безопасности в агенте восстановления. Агент восстановления в основном используется для управления событиями жизненного цикла и передачи данных между облаком и платформой. Единственное исключение из этого правила происходит во время восстановления непосредственно перед протоколом открытия хранилища, когда пользователь должен ввести LSKF старого устройства — пользовательский интерфейс, который собирает заявленный LSKF для старого устройства, реализован в агенте восстановления 4 . Однако реализация агента восстановления «забывает» заявленный LSKF, как только платформа берет на себя создание запроса на восстановление.
Функции безопасности протокола
Хотя полный анализ протокола выходит за рамки этого документа, мы хотим выделить некоторые из встроенных в протокол средств защиты. В частности, протокол повсюду использует только хэш LSKF. Это означает, что если LSKF имеет высокую энтропию (например, если это хороший пароль с высокой энтропией), хранить Хранилище строго лучше, чем хранить хэш пароля, и в этом случае хэш пароля может обеспечить меру безопасности, независимую от безопасность THM. По этой причине мы поддерживаем жесткое хеширование LSKF с солью как часть протокола. Мы также криптографически привязываем Vault к идентификатору устройства, которое его создало, и привязываем заявку на восстановление к одноразовому номеру, который используется в качестве запроса во время протокола открытия хранилища, чтобы гарантировать актуальность заявки на восстановление.
Поскольку ключ восстановления генерируется заново при каждом создании Хранилища, мы реализуем ротацию ключей, перезаписывая существующую запись Хранилища вновь созданным Хранилищем. Адрес счетчика неудачных попыток, используемый Хранилищем, выбирается во время создания Хранилища, и платформа гарантирует, что адрес счетчика, используемый для любых последующих Хранилищ, не изменится, пока не будет изменен LSKF или не появится новый подтвержденный список общедоступных когорт. Ключи. Таким образом, ротацию ключа восстановления можно выполнить без ущерба для защиты от перебора LSKF.
Безопасность сервера для службы Cloud Key Vault
Сервер реализован с использованием комбинации программного обеспечения, работающего на обычном серверном оборудовании, и встроенного ПО, работающего на специализированном оборудовании (чип Titan). Мы опишем средства защиты, предлагаемые на каждом уровне.
Аппаратная защита
Основной защитой безопасности, реализованной на серверной стороне службы CKV, являются доверенные аппаратные модули (THM), созданные с использованием специально разработанных Google чипов Titan. На чипах установлена прошивка, которая предоставляет необходимые API для реализации протоколов CKV. В частности, они могут генерировать и безопасно делиться парой ключей с другими членами своей когорты, так что логика прошивки защищает закрытый ключ от утечки за пределы чипов Titan в когорте. Они также могут выполнять операцию открытия хранилища и поддерживать строго увеличивающийся счетчик неудачных попыток для каждого хранилища (где счетчик поддерживается состоянием, хранящимся внутри чипа Titan). Более подробное описание протокола, выполняемого прошивкой чипа CKV Titan, будет представлено в будущей версии этого документа.
Учитывая, что безопасность сервера зависит от логики прошивки в чипах Titan, мы должны гарантировать, что логика не изменится таким образом, чтобы чипы разглашали секреты или игнорировали ограничения счетчиков. Для достижения этой цели мы также изменили загрузчик Titan, чтобы гарантировать, что хранящиеся на чипе данные (например, закрытый ключ для когорты) полностью стираются перед применением какого-либо обновления. Обратной стороной этой защиты является то, что мы не можем исправлять ошибки в прошивке, не испытывая при этом некоторой потери данных: обновление прошивки функционально эквивалентно разрушению существующего оборудования и замене его новыми чипами. В случае необходимости критического обновления прошивки Google необходимо будет создать и опубликовать совершенно новый список подтвержденных открытых ключей когорты и постепенно перевести всех пользователей в новый список. Чтобы снизить этот риск, мы стараемся свести кодовую базу прошивки к минимуму и тщательно проверять ее на предмет любых потенциальных проблем безопасности.
Защита программного обеспечения
В дополнение к жестким ограничениям на количество сбоев для каждого хранилища, налагаемым THM, служба CKV также реализует программное ограничение скорости. Ограничение скорости предназначено для предотвращения проникновения угонщика в учетную запись пользователя и быстрого исчерпания лимита неудачных попыток восстановления, эффективно блокируя доступ реального пользователя к его ключам восстановления. Подобно временным задержкам, вводимым устройством пользователя после слишком большого количества неудачных попыток разблокировать экран, служба CKV будет принудительно увеличивать временную задержку после каждого последующего неудачного запроса на открытие хранилища.
Мы также реализуем стандартные меры безопасности для облачных сервисов, в которых размещаются пользовательские данные, включая строгий контроль доступа, мониторинг и аудит.
Подробная спецификация протокола
Подробная спецификация протокола все еще находится в разработке, и этот документ будет обновлен, чтобы включить эти детали вместе с публикацией клиентского кода в Android Open Source Project позднее в этом году.
Примечания
- «На пути к надежному хранению 56-битных секретов в памяти человека | USENIX». 1 августа 2014 г., https://www.usenix.org/node/184458 . ↩
- «Блог Google Cloud Platform: Подробности о Титане: безопасность в открытом тексте». 24 августа 2017 г., https://cloudplatform.googleblog.com/2017/08/Titan-in-eep-security-in-plaintext.html . ↩
- «Google сообщает о более чем 2 миллиардах активных устройств на Android в месяц…» 17 мая. 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users . ↩
- Это позволяет нам предоставлять гибкие пользовательские интерфейсы для ввода LSKF другого устройства — платформа текущего устройства может не иметь подходящего пользовательского интерфейса для ввода LSKF старого устройства. ↩