Как расшифровывается кэш: что это простыми словами, что значит очистка памяти и как её сделать / Skillbox Media

Содержание

Логическая организация кэш-памяти процессора / Хабр

На днях решил систематизировать знания, касающиеся принципов отображения оперативной памяти на кэш память процессора. В результате чего и родилась данная статья.

Кэш память процессора используется для уменьшения времени простоя процессора при обращении к RAM.

Основная идея кэширования опирается на свойство локальности данных и инструкций: если происходит обращение по некоторому адресу, то велика вероятность, что в ближайшее время произойдет обращение к памяти по тому же адресу либо по соседним адресам.

Логически кэш-память представляет собой набор кэш-линий. Каждая кэш-линия хранит блок данных определенного размера и дополнительную информацию. Под размером кэш-линии понимают обычно размер блока данных, который в ней хранится. Для архитектуры x86 размер кэш линии составляет 64 байта.

Так вот суть кэширования состоит в разбиении RAM на кэш-линии и отображении их на кэш-линии кэш-памяти. Возможно несколько вариантов такого отображения.

DIRECT MAPPING

Основная идея прямого отображения (direct mapping) RAM на кэш-память состоит в следующем: RAM делится на сегменты, причем размер каждого сегмента равен размеру кэша, а каждый сегмент в свою очередь делится на блоки, размер каждого блока равен размеру кэш-линии.

Блоки RAM из разных сегментов, но с одинаковыми номерами в этих сегментах, всегда будут отображаться на одну и ту же кэш-линию кэша:

Адрес каждого байта представляет собой сумму порядкового номера сегмента, порядкового номера кэш-линии внутри сегмента и порядкового номера байта внутри кэш-линии. Отсюда следует, что адреса байт различаются только старшими частями, представляющими собой порядковые номера сегментов, а порядковые номера кэш-линий внутри сегментов и порядковые номера байт внутри кэш-линий — повторяются.

Таким образом нет необходимости хранить полный адрес кэш-линии, достаточно сохранить только старшую часть адреса. Тэг (tag) каждой кэш-линии как раз и хранит старшую часть адреса первого байта в данной кэш-линии.

b — размер кэш-линии.
m — количество кэш-линий в кэше.

Для адресации b байт внутри каждой кэш-линии потребуется: log2b бит.
Для адресации m кэш-линий внутри каждого сегмента потребуется: log2m бит.

m = Объем кэш-памяти/Размер кэш линии.

Для адресации N сегментов RAM: log2N бит.

N = Объем RAM/Размер сегмента.

Для адресации байта потребуется: log2N + log2m + log2b бит.

Этапы поиска в кэше:
1. Извлекается средняя часть адреса (log2m), определяющая номер кэш-линии в кэше.
2. Тэг кэш-линии с данным номером сравнивается со старшей частью адреса (log2N).

Если было совпадение по одному из тэгов, то произошло кэш-попадание.
Если не было совпадение ни по одному из тэгов, то произошел кэш-промах.

FULLY ASSOCIATIVE MAPPING

Основная идея полностью ассоциативного отображения (fully associative mapping) RAM на кэш-память состоит в следующем: RAM делится на блоки, размер которых равен размеру кэш-линий, а каждый блок RAM может сохраняться в любой кэш-линии кэша:

Адрес каждого байта представляет собой сумму порядкового номера кэш-линии и порядкового номера байта внутри кэш-линии.

Отсюда следует, что адреса байт различаются только старшими частями, представляющими собой порядковые номера кэш-линий. Порядковые номера байт внутри кэш-линий повторяются.

Тэг (tag) каждой кэш-линии хранит старшую часть адреса первого байта в данной кэш-линии.

b — размер кэш-линии.
m — количество кэш-линий, умещающихся в RAM.

Для адресации b байт внутри каждой кэш-линии потребуется: log2b бит.
Для адресации m кэш-линий: log2m бит.

m = Размер RAM/Размер кэш-линии.

Для адресации байта потребуется: log2m + log2b бит.

Этапы поиска в кэше:
1. Тэги всех кэш-линий сравниваются со старшей частью адреса одновременно.

SET ASSOCIATIVE MAPPING

Основная идея наборно ассоциативного отображения (set associative mapping) RAM на кэш-память состоит в следующем: RAM делится также как и в прямом отображении, а сам кэш состоит из k кэшей (k каналов), использующих прямое отображение.

Кэш-линии, имеющие одинаковые номера во всех каналах, образуют set (набор, сэт). Каждый set представляет собой кэш, в котором используется полностью ассоциативное отображение.

Блоки RAM из разных сегментов, но с одинаковыми номерами в этих сегментах, всегда будут отображаться на один и тот же set кэша. Если в данном сете есть свободные кэш-линии, то считываемый из RAM блок будет сохраняться в свободную кэш-линию, если же все кэш-линии сета заняты, то кэш-линия выбирается согласно используемому алгоритму замещения.

Структура адреса байта в точности такая же, как и в прямом отображении: log2N + log2m + log2b бит, но т.к. set представляет собой k различных кэш-линий, то поиск в кэше немного отличается.

Этапы поиска в кэше:
1. Извлекается средняя часть адреса (log2m), определяющая номер сэта в кэше.
2. Тэги всех кэш-линий данного сета сравниваются со старшей частью адреса (log2N) одновременно.

Т.о количество каналов кэша определяет количество одновременно сравниваемых тэгов.

Настройка кэширования контента на Mac

На Mac можно включить или выключить кэширование контента, выбрать объем и размер кэша, предоставить устройствам iOS и iPadOS доступ к кэшированному контенту или удалить весь кэшированный контент.

Подробнее о типах файлов, для которых можно использовать кэширование контента, см. в статье на сайте поддержки Apple Типы содержимого, поддерживаемые функцией кэширования контента в macOS.

Если Вы предоставляете кэширование контента для клиентов с произвольными общедоступными IP-адресами, Вам необходимо добавить или отредактировать запись TXT DNS для Вашего кэша контента. См. раздел Использование нескольких кэшей контента для устройств Apple в руководстве Развертывание платформы Apple (на английском языке).

Включение кэширования контента

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Включите «Кэширование контента», затем справа нажмите кнопку информации . и дождитесь, когда индикатор кэширования контента станет зеленым.
Нажмите всплывающее меню «Кэш», затем выберите содержимое, которое нужно кэшировать.
- Весь контент. Хранение обновлений ПО и приложений, загруженных от Apple, а также контента iCloud на этом компьютере Mac.
- Только общий контент. Хранение только обновлений ПО и приложений, загруженных от Apple, на этом компьютере Mac.
- Только контент iCloud. Хранение на этом компьютере Mac только контента iCloud, такого как фото и документы.
Нажмите «Готово».
Перезапустите клиентские устройства, которые используют кэш контента.
Перезапуск клиентских устройств обеспечивает незамедлительное обнаружение кэша контента этими устройствами. Если не перезапустить клиентские устройства, на обнаружение кэша контента может потребоваться определенное время.

Выключение кэширования контента

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Выключите параметр «Кэширование контента».

Выбор тома для кэширования

По умолчанию кэшированный контент хранится на загрузочном томе. Если на Вашем Mac доступны дополнительные тома, Вы можете выбрать том для сохранения кэшированного контента.

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Рядом с параметром «Кэширование контента» нажмите кнопку информации .
Нажмите «Параметры».
Нажмите кнопку «Изменить» рядом с местоположением кэша.
Выберите том хранилища, затем нажмите «Переместить».
При перемещении существующего кэша в новое местоположение кэширование контента временно приостанавливается.
Нажмите «OK», затем нажмите «Готово».

Настройка размера кэша

Вы можете выбрать объем хранилища, который компьютер Mac будет использовать для кэшированного содержимого.

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Рядом с параметром «Кэширование контента» нажмите кнопку информации .
Нажмите «Параметры».
Установите размер кэша с помощью бегунка или введите значение в текстовом поле и выберите единицы (МБ, ГБ, ТБ или ПБ) во всплывающем меню.
Нажмите «OK», затем нажмите «Готово».

См. раздел Изменение параметров хранилища, используемого для кэширования контента.

Включение или выключение кэширования контента iCloud

При кэшировании контента iCloud сохраняются файлы, которые пользователи хранят в iCloud, например документы Pages или Numbers.

Все кэшированное содержимое iCloud загружается, сохраняется и передается в зашифрованном виде, и кэш контента не имеет возможности его расшифровать.

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Рядом с параметром «Кэширование контента» нажмите кнопку информации .
Выполните одно из указанных действий.
- Включение кэширования контента iCloud. Нажмите всплывающее меню «Кэш», затем выберите «Весь контент» или «Только контент iCloud».
- Выключение кэширования контента iCloud. Нажмите всплывающее меню «Кэш», затем выберите «Только общий контент».
  Когда Вы выключаете кэширование контента iCloud, все кэшированные данные iCloud немедленно удаляются из кэша контента.
Нажмите «Готово».

Включив или выключив кэширование контента iCloud, можно перезапустить клиентские устройства. Клиентские устройства автоматически обнаруживают изменения, но на это может потребоваться время. Если перезапустить клиентские устройства, они незамедлительно обнаружат изменения.

Предоставление устройствам iOS доступа к кэшированному содержимому

Вы можете предоставить доступ к интернет-подключению и кэшированному контенту на Вашем Mac устройствам iOS, подключенным через USB. Эта функция также называется кэшированием по подключению.

При кэшировании по подключению:

Устройства iOS можно подключать и выключать в любой момент, если компьютер Mac не находится в режиме сна.
Устройства iOS, подключенные к Mac через USB, имеют доступ к интернету, даже когда они не подключены к сети Wi-Fi или сотовой сети.
Подключенные управляемые устройства iOS автоматически отмечаются в своей системе управления мобильными устройствами (MDM).

На устройстве iOS перейдите в меню «Настройки» > «Режим модема», затем выключите режим модема.
На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Рядом с параметром «Кэширование контента» нажмите кнопку информации .
Установите флажок «Подключение к интернету».
Нажмите «Готово».

При первом подключении устройства iOS к компьютеру Mac по USB необходимо выбрать «Доверять» на устройстве.

Удаление всего кэшированного содержимого

На Mac выберите меню Apple > «Системные настройки», нажмите «Основные» в боковом меню, затем нажмите «Общий доступ» справа. (Возможно, потребуется прокрутить вниз).
Открыть настройки общего доступа
Рядом с параметром «Кэширование контента» нажмите кнопку информации .
Нажмите «Параметры».
Нажмите «Сбросить», затем нажмите «Сбросить» еще раз, чтобы подтвердить запрос.

См. такжеИзменение настроек кэширования контента на MacНастройка клиентов, одноранговых узлов и родительских узлов кэшей контента на MacРазвертывание платформы Apple: Введение в кэширование контента (на английском языке)

Сведения о кэшировании ключа данных — AWS Encryption SDK

Как работает кэширование ключа данныхСоздание кэша криптографических материаловСоздание кэширующего менеджера криптографических материаловЧто находится в записи кэша ключа данных?Контекст шифрования: как выбрать кэш записиИспользует ли мое приложение кэшированные ключи данных?

Большинство приложений могут использовать реализацию кэширования ключей данных по умолчанию без записи пользовательский код. В этом разделе описывается реализация по умолчанию и некоторые подробности о параметры.

Темы

Как работает кэширование ключа данных
Создание кэша криптографических материалов
Создание кэширующего менеджера криптографических материалов
Что находится в записи кэша ключа данных?
Контекст шифрования: как выбрать кеш записи
Использует ли мое приложение кэшированные ключи данных?

Как работает кэширование ключей данных

При использовании кэширования ключей данных в запросе на шифрование или расшифровку данных AWS Encryption SDK сначала ищет в кэше ключ данных, соответствующий запросу. Если он находит действительный match, он использует кэшированный ключ данных для шифрования данных. В противном случае генерируется новый ключ данных, как это было бы без кеша.

Кэширование ключа данных не используется для данных неизвестного размера, таких как потоковые данные.

Этот позволяет кэширующему CMM должным образом применять максимальное порог байт. Чтобы избежать такого поведения, добавьте размер сообщения к шифрованию. запрос.

В дополнение к кэшу при кэшировании ключей данных используется менеджер кэширующих криптографических материалов (кэширующий CMM). Кэширующий CMM — это специализированный менеджер криптографических материалов (CMM), который взаимодействует с кэшем и базовым CMM. (Если вы укажете поставщика главного ключа или связку ключей, AWS Encryption SDK создает для вас CMM по умолчанию.) Кэширующий CMM кэширует ключи данных, которые его основные возвраты CMM. Кэширующий CMM также обеспечивает безопасность кэша. установленные вами пороги.

Чтобы предотвратить выбор неправильного ключа данных из кэша, все совместимые Кэширование CMM требует, чтобы следующие свойства кэшированных криптографических материалов соответствовать запросу материалов.

Набор алгоритмов
Контекст шифрования (даже когда пусто)
Имя раздела (строка, идентифицирующая кэширующий CMM)
(только расшифровка) Зашифрованные ключи данных

Примечание

AWS Encryption SDK кэширует ключи данных, только если набор алгоритмов использует производный ключ функция.

В следующих рабочих процессах показано, как обрабатывается запрос на шифрование данных с помощью и без кэширования ключей данных. Они показывают, как компоненты кэширования, которые вы создаете, включая кэш и кэширующий CMM, используются в процессе.

Зашифровать данные без кэширования

Для получения материалов шифрования без кэширования:

Приложение запрашивает у AWS Encryption SDK шифрование данных.

Запрос указывает поставщика главного ключа или связку ключей. SDK для шифрования AWS создает CMM по умолчанию, который взаимодействует с вашим поставщиком главного ключа или брелок.
AWS Encryption SDK запрашивает у CMM материалы для шифрования (получить криптографические материалы).
CMM запрашивает связку ключей (C и JavaScript) или провайдер главного ключа (Java и Python) для криптографических материалов. Это может включать вызов служба шифрования, например служба управления ключами AWS (AWS KMS). КИМ возвращается материалы шифрования в AWS Encryption SDK.
AWS Encryption SDK использует открытый текстовый ключ данных для шифрования данных. Он хранит зашифрованные данные и зашифрованные ключи данных в зашифрованном сообщении, которое он возвращает пользователю.

Шифрование данных с кэшированием

Чтобы получить материалы шифрования с кэшированием ключа данных:

Приложение запрашивает у AWS Encryption SDK шифрование данных.
В запросе указан менеджер кэширующих криптографических материалов (кэширующий CMM), который связан с базовым менеджером криптографических материалов. (СММ). Когда вы указываете поставщика главного ключа или связку ключей, AWS Encryption SDK создает для вас CMM по умолчанию.
SDK запрашивает у указанного кэширующего CMM материалы для шифрования.
Кэширующий CMM запрашивает материалы шифрования из кэша.
1. Если кэш находит совпадение, он обновляет возраст и значения использования совпадающую запись кэша и возвращает кэшированные материалы шифрования к кэширующему CMM.
  Если запись в кэше соответствует пороговым значениям безопасности, кэширующий CMM возвращает ее в SDK. В противном случае он сообщает кешу удалить запись и продолжает работу. как будто и не было совпадения.
2. Если кэш не может найти действительное совпадение, кэширующий CMM запрашивает свой базовой CMM для создания нового ключа данных.
  Базовый CMM получает криптографические материалы от его связку ключей (C и JavaScript) или поставщика главного ключа (Java и Python). Это может включать вызов службы, например службы управления ключами AWS. базовый CMM возвращает открытый текст и зашифрованные копии ключ данных для кэширующего CMM.
  Кэширующий CMM сохраняет новые материалы шифрования в кеш.
Кэширующий CMM возвращает материалы шифрования в SDK для шифрования AWS.
AWS Encryption SDK использует открытый текстовый ключ данных для шифрования данных. Он хранит зашифрованные данные и зашифрованные ключи данных в зашифрованном сообщении, которое он возвращает пользователю.

Создание кэша криптографических материалов

SDK AWS Encryption определяет требования к используемому кэшу криптографических материалов в кэшировании ключей данных. Он также обеспечивает локальный кеш, который является настраиваемым, кэш в памяти, наименее использовавшийся (LRU). Чтобы создать экземпляр локального кеша, используйте конструктор LocalCryptoMaterialsCache в Java и Python, функцию getLocalCryptographicMaterialsCache в JavaScript или функцию aws_cryptosdk_materials_cache_local_new конструктор на C.

Локальный кеш включает логику для базового управления кешем, включая добавление, удаление и сопоставление кэшированных записей, а также поддержание кэша. Вам не нужно написать любую пользовательскую логику управления кешем. Вы можете использовать локальный кеш как есть, настроить его или заменить любым совместимым кэшем.

Когда вы создаете локальный кеш, вы устанавливаете его емкость , то есть максимальное количество записей, которое может хранить кеш. Этот параметр помогает создать эффективный кэш с ограниченным повторным использованием ключа данных.

AWS Encryption SDK для Java и AWS Encryption SDK для Python также предоставляют нулевой кэш криптографических материалов (NullCryptoMaterialsCache). NullCryptoMaterialsCache возвращает пропустить все операции GET и не отвечает на PUT операции. Вы можете использовать NullCryptoMaterialsCache при тестировании или временно отключить кэширование в приложении, которое включает кэширующий код.

В AWS Encryption SDK каждый кэш криптографических материалов связан с менеджером кэширующих криптографических материалов (кэширующий CMM). Кэширующий CMM получает ключи данных из кэша, помещает ключи данных в кэш и применяет установленные вами пороговые значения безопасности. Когда вы создаете при кэшировании CMM вы указываете используемый им кэш и лежащий в его основе CMM или поставщик главного ключа, который создает ключи данных, которые он кэширует.

Создание менеджера кэширующих криптографических материалов

Чтобы включить кэширование ключа данных, вы создаете кэш и менеджер кэширующих криптографических материалов (кэширующий CMM). Тогда в вашем запросов на шифрование или расшифровку данных, вы указываете кэширующий CMM вместо стандартного менеджер криптографических материалов (CMM), поставщик мастер-ключей или связка ключей.

Существует два типа КИМ. Оба получают ключи данных (и соответствующие криптографические материала), но по-разному, следующим образом:

CMM связан со связкой ключей (C или JavaScript) или поставщиком главного ключа (Java и Python). Когда SDK запрашивает у CMM шифрование или материалы расшифровки, CMM получает материалы из своего набора ключей или поставщик мастер-ключей. В Java и Python CMM использует главные ключи для генерировать, шифровать или расшифровывать ключи данных. В C и JavaScript связка ключей генерирует, шифрует и возвращает криптографические материалы.
Кэширующий CMM связан с одним кэшем, например локальным кэшем, и базовым CMM. Когда SDK запрашивает у кэширующего CMM криптографические материалы, кэширующий CMM пытается получить их из кеша. Если он не может найти совпадение, кэширующий CMM запрашивает у своего базового CMM материалы. Затем он кэширует новый криптографические материалы, прежде чем вернуть их вызывающему абоненту.

Кэширующий CMM также применяет пороги безопасности которые вы устанавливаете для каждой записи кэша. Поскольку пороги безопасности установлены и обеспечивается кэширующим CMM, вы можете использовать любой совместимый кеш, даже если кеш не предназначен для чувствительного материала.

Что находится в записи кэша ключа данных?

При кэшировании ключей данных ключи данных и соответствующие криптографические материалы хранятся в кэше. Каждый запись включает элементы, перечисленные ниже. Эта информация может оказаться полезной, когда вы решаете, использовать ли функцию кэширования ключа данных, и когда вы настраиваете пороги безопасности на кэширующем диспетчере криптографических материалов (кэширующий CMM).

Кэшированные записи для запросов шифрования

Записи, добавляемые в кэш ключей данных в результате шифрования операция включает следующие элементы:

Ключ открытых данных
Зашифрованные ключи данных (один или несколько)
Контекст шифрования
Ключ подписи сообщения (если используется)
Набор алгоритмов
Метаданные, включая счетчики использования для обеспечения пороговых значений безопасности

Кэшированные записи для запросов расшифровки

Записи, добавляемые в кэш ключей данных в результате расшифровки операция включает следующие элементы:

Контекст шифрования: как выбрать кеш записи

Вы можете указать контекст шифрования в любом запросе на шифрование данных. Однако Контекст шифрования играет особую роль в кэшировании ключа данных. Это позволяет вам создавать подгруппы ключей данных в вашем кэше, даже если ключи данных происходят из одного кэширование КММ.

Контекст шифрования представляет собой набор ключей-значений пары, содержащие произвольные несекретные данные. Во время шифрования контекст шифрования криптографически привязан к зашифрованным данным, так что один и тот же контекст шифрования требуется для расшифровки данных. В AWS Encryption SDK хранится контекст шифрования. в зашифрованном сообщении с зашифрованными данными и данными ключи.

При использовании кэша ключей данных можно также использовать контекст шифрования для выбора определенные кэшированные ключи данных для ваших операций шифрования. Контекст шифрования сохраняется в записи кеша с ключом данных (это часть идентификатора записи кеша). Кэшировано ключи данных используются повторно только тогда, когда их контексты шифрования совпадают. Если вы хотите повторно использовать определенные ключи данных для запроса шифрования, укажите один и тот же контекст шифрования. Если вы хотите избежать этих ключей данных, укажите другой контекст шифрования.

Контекст шифрования всегда необязателен, но рекомендуется. Если вы не укажете контекст шифрования в вашем запросе, пустой контекст шифрования включен в кеш идентификатор записи и сопоставляется с каждым запросом.

Использует ли мое приложение кэшированные ключи данных?

Кэширование ключа данных — это стратегия оптимизации, которая очень эффективна для определенных приложений и рабочих нагрузок. Однако, поскольку это сопряжено с определенным риском, важно определите, насколько эффективным он будет в вашей ситуации, а затем решите, следует ли преимущества перевешивают риски.

Поскольку кэширование ключей данных повторно использует ключи данных, наиболее очевидным эффектом является уменьшение количества вызовов для генерации новых ключей данных. Когда реализовано кэширование ключей данных, AWS Encryption SDK вызывает операцию AWS KMS GenerateDataKey только для создания начальный ключ данных и когда кэш отсутствует. Но кэширование повышает производительность заметно только в приложениях, которые генерируют множество ключей данных с одинаковым характеристики, включая одинаковый контекст шифрования и набор алгоритмов.

Чтобы определить, действительно ли ваша реализация AWS Encryption SDK использует ключи данных из кэша, попробуйте следующие методы.

В журналах вашей мастер-ключевой инфраструктуры проверьте частоту обращений к создать новые ключи данных. Когда кэширование ключа данных эффективно, количество вызовов для создания новых ключей должно заметно упасть. Например, если вы используете Поставщик главного ключа AWS KMS или набор ключей. Найдите в журналах CloudTrail вызовы GenerateDataKey.
Сравните зашифрованные сообщения, которые AWS Encryption SDK возвращается в ответ на различные запросы на шифрование. Например, если вы используете AWS Encryption SDK для Java, сравните объект ParsedCiphertext из разных вызовов шифрования. в AWS Encryption SDK для JavaScript, сравните содержимое зашифрованных ключей данных свойство MessageHeader. При повторном использовании ключей данных зашифрованные ключи данных в зашифрованном сообщении идентичны.

Javascript отключен или недоступен в вашем браузере.

Чтобы использовать документацию Amazon Web Services, должен быть включен Javascript. Инструкции см. на страницах справки вашего браузера.

Условные обозначения документов

Установка пороговых значений безопасности кэша

Пример кэширования ключа данных

Защита кэшированных данных пользователя

Устройства Chromium OS должны быть портативными и безопасными общий. В результате защита конфиденциальности пользовательских данных, хранящихся на локальный диск является обязательным требованием для ОС на базе Chromium.
Защита конфиденциальности пользовательских данных, хранящихся на локальном диске, отключена. достигается за счет шифрования домашних каталогов пользователей на системном уровне.
Chromium OS использует eCryptfs многоуровневая файловая система с каталогами хранилищ и наборами ключей для каждого пользователя. отделить и защитить кешированные данные каждого пользователя.
Устройства Chromium OS могут использовать доверенный платформенный модуль (TPM) для защитить от попыток грубой силы восстановить набор ключей пользователя (и поэтому данные он защищает).

Chromium OS должна обеспечивать защиту конфиденциальности пользовательских данных, хранящихся на локальном диск. В частности, некоторое подмножество электронной почты пользователя, изображений и даже HTTP файлы cookie будут храниться на локальном диске, чтобы улучшить работу в Интернете и убедитесь, что ноутбуки Chrome полезны, даже если подключение к Интернету отсутствует доступный. Без этой защиты любой, кто имеет физический доступ к Устройство Chromium OS сможет получить доступ к любым кэшированным на нем данным.

Обычно данные, хранящиеся в облаке, защищены механизмами защиты конфиденциальности. предоставляется серверами, на которых он размещен. Когда данные извлекаются из облака, они выходит за пределы досягаемости этих средств защиты, предоставляемых сервером. Несмотря на то так обстоит дело сегодня с большинством компьютеров, есть две области, которые делают это еще важнее для Chromium OS:

С устройством Chromium OS пользователям не нужно беспокоиться о могут ли другие пользователи того же устройства видеть их кэшированные данные. Например, если мой друг хочет войти на мое устройство, чтобы проверить ее почте, это не страшно. Она не сможет получить доступ к моим данным, и даже если она использовала мое устройство, я не смогу получить доступ к ее данным.
Устройства Chromium OS являются портативными. Риск с очень портативным устройства заключается в том, что их легко потерять или оставить. мы не хотите, чтобы человек, нашедший устройство, мгновенно имел доступ ко всем веб-сайты пользователей, электронные письма, изображения и т. д.

Поскольку ОС Chromium построена на базе Linux, мы можем использовать существующие решения для шифрование данных пользователя данные на уровне базовой операционной системы и убедитесь, что это происходит автоматически и обязательный. Учитывая доступные варианты реализации, многие возможные подходы были рассмотрены (см. Приложение Б для подробностей). Из этих подходов мы выбрали решение, предоставляющее файл системное шифрование дома каталоги для каждого пользователя на устройство.

Шифрование домашнего каталога каждого пользователя означает, что все данные, хранящиеся и кешированные во время просмотра будут зашифрованы по умолчанию. Кроме того, данные, созданные и поддерживается плагинами, такими как Adobe Flash, будет прозрачно зашифрован без необходимости предпринимать какие-либо специальные действия разработчикам или пользователям. То же самое для любых данных, хранящихся веб-приложениями с поддержкой HTML5.

Существующие операционные системы полагаются на права собственности на файлы и права доступа к предотвратить доступ двух пользователей системы к файлам друг друга. Однако пользователь root или администратор обычно по-прежнему может получить доступ к любому из этих файлов, и файлы действительно защищены только до тех пор, пока этот экземпляр операционной системы загружен. Установка диска в качестве вторичного диска обеспечит полный доступ. Шифрование — лучшее решение этой проблемы, даже если устройство находится в руки злоумышленника, этому лицу все равно придется восстановить ключи шифрования для доступа к кэшированным данным.

Короче говоря, каждый пользователь получает уникальный каталог «хранилище» и набор ключей, созданный при ее первом входе в систему. Хранилище используется в качестве базового зашифрованного хранилище для ее данных. Набор ключей привязан к ее учетным данным для входа в систему и необходимо, чтобы система могла как извлекать, так и сохранять информацию в сейф. Хранилище открывается прозрачно для пользователя при входе в систему. При выходе или перезагрузка, данные пользователя снова заблокированы.

Каждому пользователю выделяется каталог хранилища, содержащий зашифрованную резервную копию хранилище для своего домашнего каталога. Хранилище находится в определенном каталоге пользователю, используя хэш имени пользователя со значением соли, и монтируется используя eCryptfs при входе в каталог пользователя. Шифрование файлов для конкретного пользователя ключ (FEK) и ключ шифрования имени файла (FNEK) позволяют eCryptfs прозрачно шифровать и расшифровывать, пока хранилище смонтировано. Успешный монтаж хранилища является обязательным шагом в процессе входа в систему Chromium OS. При первом входе в систему /etc/skel/ копируется в новый домашний каталог и готов к использованию.

FEK и FNEK (вместе с некоторыми дополнительными данными, называемыми набором ключей) для пользователя создаются с помощью генератора случайных чисел, предоставленного ядром, который, на устройствах Chromium OS при загрузке получает дополнительную энтропию от TPM. Эти 128-битные ключи AES используются для шифрования содержимого и имен файлов, соответственно. Как многоуровневая файловая система, eCryptfs имеет нижний файл (зашифрованный, постоянный файл, расположенный в хранилище и хранящийся на диске) для каждого верхнего файла (текстовый файл, представленный в точке монтирования, который никогда не сохраняется напрямую на диск). Ключи существуют в памяти ядра в течение всего времени монтирования.

Набор ключей пользователя никогда не меняется, если его учетная запись не удалена из Chromium. устройство ОС или если система стерта, например, при использовании устройства восстановления. Он должен быть защищен от раскрытия и доступен только при действительном входе в систему. реквизиты для входа. Для этого Chromium OS использует один из двух методов хранения keyset, в зависимости от того, доступен ли и инициализирован ли доверенный платформенный модуль. Предпочтительный метод включает в себя использование TPM, а резервный метод с использованием Библиотека шифрования Scrypt. Оба метода связывают набор ключей хранилища пользователя с паролем его учетных записей Google и описываются далее ниже.

Всем этим управляет один демон, cryptohomed, который прослушивает входящие запросы от менеджера входа. Если запрос заключается в установке зашифрованного хранилища, имя пользователя и слабый хэш пароля должны быть включены. Если запрос к размонтировать образ, cryptohomed очищает ключи, хранящиеся в ядре, и размонтирует убежище.

Добавление криптографии к файловой системе обходится дорого — шифрование потребляет как Циклы процессора и дополнительные страницы памяти. Последний в основном управляется Кэш страниц Linux, но первый может привести к тому, что операции чтения и записи будут привязаны к ЦП. а не с привязкой к вводу-выводу. На основе тестирования по сравнению с вводом-выводом напрямую в твердотельный носитель диск состояния, мы обнаружили, что текущие накладные расходы приемлемы, хотя есть всегда есть возможность стать лучше. Chromium OS использует шифрование для защиты кешированного пользователя данные, которые включают в себя некоторые часто используемые элементы, такие как кеш браузера и базы данных, но не включает общие файлы и программы операционной системы. Таким образом, несмотря на снижение производительности, оно не распространяется на все дисковые операции ввода-вывода.

Будучи многоуровневой файловой системой, eCryptfs имеет побочный эффект наличия одного нижнего файл для каждого верхнего файла. Это позволяет «сквозную передачу» — когда файл или каталог создается как обычный текст в базовой папке хранилища и отображается в верхней точке крепления. Как правило, это не очень хорошая идея для файлов (мы не хотел бы хранить текстовые данные на диске), но для каталогов у него есть приятное преимущество, позволяющее очищать файлы в автономном режиме.

В частности, сквозные каталоги позволяют отображать имя каталога в виде открытого текста. в хранилище, но содержимое каталога (файлы, подкаталоги и т. д.) еще зашифрован. Chromium OS может создавать сквозные каталоги для отбрасываемых информация, такая как кеш браузера. Поскольку название является стандартным местоположением, освобождение места на диске, когда оно мало, — это просто вопрос удаления известного имена каталогов кеша из каждого хранилища, существующего в системе. Без сквозные каталоги, каждое хранилище должно быть смонтировано (требуется каждый учетные данные пользователя), чтобы иметь возможность идентифицировать каталог кеша и удалить его.

Как упоминалось ранее, набор ключей хранилища пользователя в конечном счете защищен частичный криптографический хеш парольной фразы пользователя. Частичная криптография хэш используется, потому что пароль пользователя аккаунтов Google не должен быть раскрыт оффлайн атака. Вместо этого мы готовы потерять часть энтропии, поставляемой парольную фразу, выполнив дайджест SHA-256 пользовательской соли объединены с парольной фразой пользователя. Первые 128 бит дайджеста используется как «слабый хэш пароля» пользователя.

Часто пароли пользователей содержат только от 18 до 30 бит. энтропия начиная с 8 символов в длину. Распределяя эту энтропию по хешу и делить пополам не так уж и здорово. По крайней мере, добавление соли означает, что предварительно вычислить словарь хэшей будет довольно дорого, но все же не идеально, если у злоумышленника есть время и доступ к локальной соли, чтобы попытаться взломать локальный пароль. Есть еще две полезные опции которые можно использовать, чтобы предотвратить офлайн-атаки. Первый это ключ укрепление можно использовать для увеличить время, необходимое для вычисления хэша из словаря атака грубой силы, использующая повторные проходы через криптографический хэш. другой вариант — использовать устройство TPM, когда оно присутствует, например, в Устройства с ОС Chromium. Это позволяет TPM эффективно ограничивать грубую силу. атаки без накладных расходов на усиление ключа.

Как упоминалось выше, может использоваться как защита на основе Scrypt, так и на основе TPM. Сначала мы опишем метод Scrypt, который является более простым из двух. Преимущество использования Scrypt заключается в том, что он использует уникальный метод пароля усиление, чтобы получить ключ для шифрования, который является как CPU, так и привязывается к памяти, что делает параллельную атаку грубой силы более дорогостоящей, чем схема например, повторные хэш-раунды. Scrypt используется для прямой защиты хранилища набор ключей с использованием ключа на основе усиленного пароля пользователя (фактически слабый хэш пароля пользователя). Зашифрованный набор ключей хранится на диске и разблокирован для использования при входе в систему, когда действительные учетные данные позволяют расшифровать его.

Предпочтительный метод защиты набора ключей хранилища включает доверенный платформенный модуль для защиты против атак грубой силы. Метод использует защищенный ключ функции хранения TPM (и относительно низкая тактовая частота чип) для защиты набора ключей.

При использовании TPM Chromium OS создает общесистемный ключ RSA с использованием OpenSSL и затем оборачивает его корневым ключом хранилища TPM при первой загрузке. Оригинальный ключ уничтожены, и у нас остался ключ RSA, закрытый ключ которого известен только встроенный в TPM. Это означает, что, за исключением уязвимости в TPM, в чтобы использовать этот ключ RSA, операция с закрытым ключом должна выполняться на этом конкретный TPM, поэтому механизмы, которые его используют, лучше защищены от грубой силы атаки. Кроме того, поскольку текущие TPM могут занимать около полсекунды для работа с закрытым ключом, даже атаки, использующие TPM, эффективно оцениваются ограниченное.

Мы используем общесистемный ключ, а не ключ для каждого пользователя по двум важным причинам: во-первых, загрузка ключа в TPM обходится дорого (он должен расшифровывать закрытый ключ компонент). В то время как 0,5 с — это терпимый штраф за приватный ключ. операции, дольше (что было бы в случае, если бы нам пришлось загружать пользовательский ключ при каждой попытке входа) оказывает заметное влияние на вход пользователя. Использование общесистемного key позволяет загрузить один ключ и, как правило, оставить его в TPM, пока система загружается. Так как он защищен чипом, это нормально. Во-вторых, типичный метод объединения паролей пользователей с ключами на TPM требует аутентификация для их использования. Это было бы хорошим решением для Chromium OS, но есть минус. TPM имеют защиту от атак по словарю для конкретного поставщика. режим, в который легко войти при слишком большом количестве неудачных проверок подлинности TPM. На много чипов, этот режим является агрессивным, и после его входа чип становится бесполезным на какое-то время. Поскольку неудачные пароли случаются (как легитимные, так и злоумышленником), слишком много неудачных паролей приведет к отключению TPM на время, и хранилища, которые он защищал, непригодны для использования. Вместо этого мы используем беспарольный общесистемный ключ, но смешать пароль пользователя уникальным способом, который обеспечивает те же преимущества без возможности входа в этот режим.

В частности, когда набор ключей хранилища зашифрован, выполняется следующий процесс. место:

256-битный ключ набора ключей хранилища AES (VKK ниже) создается случайным образом и используется для шифрования набора ключей хранилища. Набор ключей зашифрованного хранилища сохраняется на диск. Этот промежуточный ключ используется для доступа к хранилищу. keyset должен быть больше, чем позволяет одна операция RSA.
VKK зашифрован ранее общесистемным ключом RSA упоминается (TPM_CHK ниже), что приводит к промежуточному зашифрованному ключ набора ключей хранилища (IEVKK).
Последние 128 бит зашифрованного большого двоичного объекта из шага 2 зашифрованы на месте с использованием слабого хэша пароля пользователя, который сначала был хэширует соль, специфичную для набора ключей. Это делается с помощью одного AES операция без заполнения, что позволяет не проверять при расшифровке. Результатом является зашифрованный ключ набора ключей хранилища (EVKK), который хранится на диск.

Шаг 3 имеет решающее значение для объединения слабого хэша пароля пользователя (и, следовательно, предотвращение дешифрования любым лицом, имеющим доступ к TPM и общесистемному ключу RSA набор ключей хранилища). Если злоумышленник не узнает пароль пользователя (или не угадает это), большой двоичный объект, переданный доверенному платформенному модулю для расшифровки с помощью общесистемного ключа, фактически мусор — доверенный платформенный модуль не сможет расшифровать, поскольку он эффективно повреждены до тех пор, пока эти последние 128 битов не будут исправлены. TPM рассматривает это как неудачная расшифровка (а не неудачная проверка подлинности) и ключ набора ключей хранилища (и набор ключей хранилища, который он защищает) невозможно восстановить. Эта операция показано ниже:

Хотя эти методы защиты обеспечивают защиту кэшированных пользовательских данных, что они эффективно решают проблему, не позволяющую злоумышленнику использовать брутфорс в автономном режиме. подбор пароля пользователя к аккаунту Google.

Основная причина хеширования имени пользователя — сделать его безопасным для использования на файловая система без написания пользовательского сопоставления небезопасных символов. веб-сайт имя пользователя может содержать символы, небезопасные для использования в файловой системе. Использование надежного хэша даст достаточно уникальное значение, безопасное для использования на файловая система. Кроме того, если все ссылки на имена пользователей за пределами зашифрованные изображения выполняются с использованием HASH(salt||user@domain. com), тогда это становится довольно сложно для любого пользователя или злоумышленника определить, какие имена пользователей находятся в использовать на данном устройстве, не пытаясь атаковать грубой силой. это приятно побочный эффект, но не явная цель.

Смена пароля и автономный вход в систему обрабатываются через cryptohomed.

Если пользователь изменит свой пароль из другого браузера, набор ключей хранилища по-прежнему привязан к предыдущему паролю. Chromium OS разрешает смену пароля только на успешный онлайн-вход. В этом случае веб-служба Google будет аутентифицировать пользователь с ее новыми учетными данными, возвращая успешное условие. Хром ОС попытается смонтировать ее хранилище, но это не удастся из-за плохой расшифровки состояние. Поскольку Chromium OS знает, что пароль на самом деле правильный, он предоставить пользователю возможность ввести свой старый пароль один раз (с которым он может восстановить набор ключей хранилища, а затем повторно защитить его с помощью нового пароля), или просто заново создайте хранилище с нуля.

Когда блокнот Chromium находится в автономном режиме, он не может аутентифицировать пользователя с помощью Google веб-сервис. Однако набор ключей зашифрованного хранилища можно использовать для работы в автономном режиме. проверка полномочий. Проще говоря, если заданный пароль приводит к успешному восстановление набора ключей хранилища, пароль был правильным. Итак, когда Chromium OS не обнаруживает сетевое соединение, он попытается аутентифицироваться путем монтирования хранилище пользователя напрямую (это работает только в том случае, если пользователь ранее вошел в систему в сети, и поэтому у нее есть хранилище на ноутбуке).

В настоящее время устройства с ОС Chromium не используют раздел подкачки, а временные данные записывается в файловую систему tmpfs, которая не поддерживается каким-либо постоянным хранилищем (например, диск). Если в будущем потребуется устройство подкачки, мы изучим проблемы, связанные с удовлетворительной защитой этих данных.

Хотя более новые выпуски Chrome OS начали включать zram для целей подкачки, он по-прежнему не хранится на диске. zram берет кусок памяти и использует его для менять. Когда страницы перемещаются между этим устройством подкачки, они сжатие/распаковка на лету. Так что до сих пор нет постоянного хранилища в играть.

Вам может быть интересно, что произойдет, если произойдет ошибка. Пользователь заблокирован? Если пользователь успешно аутентифицируется, но все попытки создать или получить доступ к зашифрованное хранилище не работает, тогда вход может или не может быть неудачным. Ответ зависит от сценарий. Chromium OS автоматически обнаруживает неисправимые сбои и воссоздает хранилище пользователя в условиях. Эти условия обычно связанные с доверенным платформенным модулем, например, если он очищается (фактически делая данные защищены им безвозвратно). Временные сбои не приводят к новым хранилище, но оба типа отказов редки и обычно предсказуемы (см. документ об использовании TPM для получения дополнительной информации).

Несмотря на это, пользователь всегда может войти на устройство как гость. В то время как это делает не предоставлять доступ к зашифрованным данным пользователя, а история сеансов не хранится, он всегда позволяет использовать систему.

Простые тесты показывают, что eCryptfs при распространенных шаблонах просмотра не работает. значительно изменить срок службы батареи. Это когда происходит устойчивое чтение и запись что все больше и больше процессора используется и, следовательно, больше потребляется батарея. Тест с тяжелая, устойчивая запись приводила к такой же скорости разряда батареи, как и тяжелая запись использовалась без шифрования, но зашифрованная большая запись заняла примерно вдвое больше времени. пока до завершения.

В большинстве случаев шифрование диска незаметно. Если ускорение AES достигает дополнительные процессоры, то влияние будет еще ниже.

Все метаданные для этой функции будут находиться в каталоге /home/. shadow. Каждый user будет иметь подкаталог с именем, основанным на хеше имени пользователя. Что каталог будет содержать все данные, связанные с изображением этого пользователя на машине. Для пример:

/home/.shadow/da39a3ee5e6b4b0d3255bfef95601890afd80709/хранилище

/home/.shadow/da39a3ee5e6b4b0d3255bfef95601890afd80709/master.0

Общесистемный ключ RSA TPM хранится в:

/home/.shadow/cryptohome.key

Основной целью является защита конфиденциальных данных конечного пользователя от раскрытия, если устройство или диск потеряны.

Пользовательские данные НЕ ДОЛЖНЫ быть доступны, когда устройство включено вниз.
Пользовательские данные ДОЛЖНЫ быть защищены, когда диск был извлечен из Устройство.
Данные пользователя МОЖЕТ быть защищены, когда устройство приостановлено.
Парольные фразы аккаунтов Google НЕ ДОЛЖНЫ раскрываться для прямого оффлайн атака.
Данные пользователя ДОЛЖНЫ быть доступны при автономном входе в систему.
Данные пользователя ДОЛЖНЫ быть восстанавливаемыми после внеполосного пароля изменять.
Пользовательские данные ДОЛЖНЫ НЕ открываться пользователям в многопользовательском устройство.
Пользовательские данные выгружены из памяти МОЖЕТ БЫТЬ защищенным (в зависимости от требование ниже).
Затраты на мощность и производительность ДОЛЖНЫ БЫТЬ сведены к минимуму. (Некоторый должны быть определены конкретные максимально допустимые накладные расходы. Это может Однако в конечном итоге они зависят от устройства. В частности, время загрузки, время входа в систему и проблемы с отзывчивостью браузера Chromium важно.)
Пользователи НЕ ДОЛЖНЫ иметь возможность отказаться от шифрования.

Нецели:

Хранение учетных данных в автономном режиме может быть побочным эффектом выбранная реализация.
Можно использовать устройство TPM, но создание Решение, зависящее от TPM.
Шифрование/защита корневого раздела не является целью.
Не ставится цель обеспечить механизм удаленной очистки с помощью этого особенность, но это может сделать такой дизайн проще.

Шифрование на основе блоков для каждого пользователя : Этот подход будет использовать случайный ключ для шифрования раздела для каждого пользователя, который защищен парольная фраза пользователя (и резервный ключ, хранящийся в Google). Этот подход будет гарантировать, что данные пользователя будут доступны только тогда, когда пользователь вошел в систему, и это позволяет легко удаленно стереть (удалить ключ для раздела). Это добавляет больше боли, когда дело доходит до управление устройством. Каждый раздел данных должен быть разделен в предварительно выделенные регионы для каждого одновременно кэшированного пользователя, хранящегося в системе (то есть пространство_данных / n = пространство_пользователей). Примечание: Это не должно быть видно пользователю, если он не попытается войти в систему. с новой кодовой фразой, пока он не в сети.
Шифрование файловой системы для каждого пользователя : Такой подход использование encfs, cryptofs или eCryptfs для добавления многоуровневого зашифрованного файла система поверх предварительно сконфигурированного блочного устройства. За исключением eCryptfs, производительность довольно болезненна с пользовательскими решениями, такими как encfs и криптофс. eCryptfs обеспечивает хорошую производительность и позволяет подход, аналогичный описанному выше (гарантия конфиденциальности для каждого пользователя и защиты) без необходимости предварительно выделять блочные устройства для каждого пользователя.
Шифрование всего диска с помощью TPM : для этого будет использоваться защищенный TPM ключ для разблокировки диска. Это означало бы, что со всем устройством, данные будут подвергаться атакам на уровне ОС после загрузки, если только использовалась некоторая форма предзагрузочной аутентификации. это не пользователь опыт, который мы ищем, и это тривиально выставит данные к физическому злоумышленнику. Диск будет защищен только при удалении с устройства.
Шифрование всего раздела данных : Это упростило бы пространство проблема использования, помещая всех пользователей в один зашифрованный раздел. Обычные средства контроля доступа могут удерживать пользователей от доступа к данным друг друга, но добавление нового пользователя на зашифрованный диск без необходимости другой пользователь для «авторизации» нового пользователя во время входа в систему является вызов по этой схеме. Причина, по которой это проблема, заключается в том, что ключ каждого пользователя, полученный из парольной фразы, используется для защиты диска ключ шифрования. Даже если пользователь разрешает другому пользователю доступ к диск, новый пользователь должен будет ввести исходный парольную фразу сразу (или при следующем входе в систему), или вторичный ключ будет должен быть в игре, чтобы можно было расшифровать ключ шифрования и повторно зашифрованы без присутствия первого пользователя. нет чистых способы обойти это. Другим недостатком этого подхода является то, что если какой-либо пользователь скомпрометирован и в системе существует уязвимость повышения привилегий, все пользовательские данные будут быть скомпрометирован. Кроме того, такой подход усложнил бы любую схему удаленной очистки, которую мы могли бы использовать. осуществлять. Шифрование всего раздела потребует фактического удаления файла реализовать очистку для каждого пользователя, а не просто повторно инициализировать криптографическая файловая система или полная очистка данных. Если мы поддерживаем только полные данные стереть, то это, вероятно, будет доступно только владельцам устройств, но стирание для каждого пользователя позволит пользователю очистить свои данные от друга машина, которой он пользовался один раз.
Нет шифрования : Это не только означает, что большинство предприятий не могут использовать устройство для работы, это также будет означать, что многие пользователи будут несчастный. Как бы то ни было, большинство людей не хотят терять свои данные, если кто-то крадет их устройство. И независимо от политики, люди будут использовать свои личные устройства на работе. Мы хотели бы думать, что предоставление простое и эффективное шифрование для платформы является долгосрочным преимуществом всем.
Шифрование только в браузере Chromium : Внедрение шифрования в Браузер Chromium рассматривался. Такой подход гарантирует, что все кэшированные данные и все загруженные/доступные данные зашифрованы. Этот решение можно искать в долгосрочной перспективе. В настоящее время предоставление шифрование на уровне ОС означает, что он поймает любые данные внешний по отношению к браузеру Chromium (локальное хранилище Adobe Flash) и данные разработчика.
Другие интересные побочные эффекты : Весь раздел данных шифрование и шифрование для каждого пользователя имеют преимущество бесплатное автономное хранилище учетных данных. Слабый хэш пароля может быть используется для защиты магазинов, которые затем проверяются при установке. В Кроме того, пользователь может быть сопоставлен с системной учетной записью с помощью этого информация. Если пользователь находится в ячейке пароля 1, то он будет сопоставлен с пользователь_1 и так далее.

Следующий список включает основные угрозы, которые устраняются этим дизайн:

Злоумышленник захватывает выключенное устройство с установленным в нем диском и пытается получить доступ ко всем домашним каталогам локальных пользователей.
Злоумышленник получает устройство в состоянии ожидания с находящимся в нем диском и пытается извлечь ключ шифрования с помощью атаки с холодной загрузкой.
Злоумышленник с правами входа пытается получить доступ к данные с использованием известной ошибки, уязвимости или обходного пути.

Этот дизайн не устраняет многие угрозы:

Злоумышленник с удаленной компрометацией сможет получить доступ к в настоящее время вошли в данные пользователя.
Злоумышленник сможет получить доступ ко всем данным пользователя, если автологин включено и устройство находится в любом состоянии.
Злоумышленник сможет получить доступ ко всем данным пользователя, если машина приостановлено или выполнен вход в систему, а блокировка экрана отключена.
Злоумышленник сможет сбросить всю оперативную память с приостановленной машины с помощью холодной загрузки атака, раскрывающая любую учетные данные в памяти и расписание ключа шифрования диска, пока что можно исправить.
Злоумышленник, укравший работающую машину с блокировкой экрана, будет возможность выполнять блокировку экрана, USB, сеть и любую другую среду выполнения атаки для получения доступа, если пользователь не может инициировать удаленную протрите, пока машина все еще подключена к Интернету.
Злоумышленник, который может изменить корневой раздел, сможет поставить под угрозу среду выполнения, что приведет к раскрытию данных, когда впоследствии пользователь входит в систему.
No related posts.