Механизм композиции идентификаторов устройств (DICE) улучшает состояние безопасности Android различными способами, при этом по мере расширения интеграции этой архитектуры в разработке находится больше вариантов использования.
Удаленное предоставление ключей
Первоначальный вариант использования DICE заключался в том, чтобы закрепить корень доверия для протокола удаленного предоставления ключей (RKP) в наименьшем TCB, доступном для чипа, ПЗУ, а не в TEE. Это значительно уменьшает поверхность атаки для постоянного компрометации RKP. Что еще более важно, он дает возможность восстановить доверие к устройствам после взлома TEE или загрузчика, который может повлиять на достоверность аттестаций ключей, генерируемых KeyMint.
Исторически сложилось так, что уязвимости в TEE или загрузчике приводили к полному отзыву ключей аттестации для всех затронутых устройств без возможности восстановления доверия, даже если уязвимости были исправлены. Это произошло потому, что невозможно было доказать удаленной стороне, что исправления были применены, поскольку удаленная проверка выполнялась TEE по образу Android, загружаемому через Android Verified Boot. DICE закрывает этот пробел, предоставляя возможность удаленно проверять текущее состояние прошивки, загруженной вне Android.
Взаимная аутентификация изолированных сред
Каждый домен приложения, в котором завершается DICE, получает идентификатор в форме ключа с цепочкой сертификатов, идущей обратно к общему корню доверия, полученному ПЗУ. Поскольку процесс создания DICE разветвляется по мере разделения путей загрузки, создается дерево сертификатов, имеющих один и тот же корень. Таким образом, в процессе DICE на устройстве создается PKI.
PKI, созданная в процессе создания DICE, создает механизм взаимной аутентификации компонентов в отдельных безопасных анклавах. Конкретным примером этого является SecretKeeper, Trusted HAL, который позволяет pVM связываться с TEE для получения стабильного секрета, который можно использовать для безопасного хранения постоянных данных.