Администрирование защищенными устройствами

Изобретение относится к средствам разблокирования и обеспечения доступа к устройству. Технический результат заключается в повышении безопасности устройства. Принимают запрос на разблокирование зашифрованного устройства, соединенного с системой, причем запрос принимают с помощью защищенного раздела системы по защищенному каналу связи, установленному между доверяемой удаленной консолью и защищенным разделом, а защищенный раздел изолирован от основной операционной системы в системе. Принимают маркер от доверяемой удаленной консоли с помощью защищенного раздела. Используют с помощью защищенного раздела указанный маркер для разворачивания ключа шифрования устройства, хранящегося в защищенной области хранения, причем ключ шифрования устройства использован для шифрования блоков зашифрованного устройства, а защищенная область хранения скрыта от основной операционной системы. Разблокируют с помощью защищенного раздела зашифрованное устройство с использованием ключа шифрования устройства в ответ на запрос и без привлечения основной операционной системы. 7 з. и 14 з.п. ф-лы, 9 ил.

 

Область техники, к которой относится изобретение

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

Уровень техники

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

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

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

Другая проблема защиты данных, содержащихся в устройствах сохранения, состоит в том, чтобы устройства сохранения сами могли быть защищены, используя схему защиты паролем. Например, в соответствии со спецификацией соединения по усовершенствованию передовой технологии (АТА), замок диска представляет собой встроенное средство обеспечения безопасности привода жесткого диска. Спецификация АТА требует, чтобы диск имел два пароля: пароль пользователя и мастер-пароль. Диск может быть заблокирован в двух режимах: режим высокой степени защиты или режим максимальной защиты. В режиме высокой степени защиты диск может быть разблокирован, используя один из пароля пользователя или мастер-пароля, используя команду АТА "SECURITY UNLOCK DEVICE". При этом существует предельное количество попыток, обычно установленное равным 5, после чего диск должен быть подвергнут отключению питания или полному сбросу перед тем, как попытка разблокирования может быть предпринята снова. Также в режиме высокой степени защиты может использоваться команда SECURITY ERASE UNIT, с использованием одного из пароля пользователя или мастер-пароля.

В режиме максимальной защиты диск не может быть разблокирован без пароля пользователя. Единственный способ вернуть диск в пригодное состояние состоит в выработке команды SECURITY ERASE PREPARE, после которой немедленно следует команда SECURITY ERASE UNIT. В режиме максимальной защиты команда SECURITY ERASE UNIT требует пароля пользователя и полностью стирает все данные на диске. Таким образом, если диск защищен паролем, установленным в режим максимальной защиты, и пароль пользователя неизвестен, данные на диске не могут быть восстановлены.

Еще одна проблема, связанная с защитой данных, сохраненных на носителе записи, ассоциированных с вычислительной платформой, состоит в том, что платформа может потребовать аутентификации учетной записи пользователя перед тем, как доступ к данным на ассоциированных устройствах накопителей будет предоставлен. Например, некоторые вычислительные платформы защищены с использованием аутентификации пользователя Kerberos. В основании Kerberos используется симметричный протокол Нидхэма-Шредера. В нем используется доверительная третья сторона, называемая центром распределения ключей (KDC), который состоит из двух логически отдельных частей: Сервера аутентификации (AS) и Сервера предоставления билетов (TGS). Kerberos работает на основе "билетов", которые используются для подтверждения личности пользователей.

KDC поддерживает базу данных секретных ключей; каждый объект в сети (клиент или сервер) совместно используют секретный ключ, известный только им самим и KDC. Знание такого ключа используется для удостоверения идентичности объекта. Для обмена данными между двумя объектами KDC генерирует ключ сеанса, который они могут использовать для защиты их взаимодействия. Защита протокола в большой степени основана на участниках, поддерживающих свободно синхронизированное время, и на краткосрочных утверждениях аутентичности, называемых билетами Kerberos.

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

Краткое описание чертежей

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

На фиг.2 более подробно показана система по фиг.1 в устройствах, защищенных администрированием, в соответствии с одним вариантом осуществления изобретения.

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

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

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

На фиг.5 В показана блок-схема последовательности операций способа, выполняемого системой по фиг.5А после распознавания события замены устройства без перезагрузки.

На фиг.6 более подробно показана система по фиг.1 при администрировании защищенными устройствами в соответствии с одним вариантом осуществления изобретения.

На фиг.7 показана блок-схема последовательности операций способа, выполняемого при детектировании потенциально подвергаемого аудиту события, происходящего в пределах защищенного раздела системы, в соответствии с одним вариантом осуществления изобретения.

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

Подробное описание изобретения

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

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

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

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

Изолированная и защищенная среда менеджера защищенного диспетчера устройств может содержать различные разделы разных видов, включающие в себя совершенно отдельный аппаратный раздел (например, использующее Intel® Corporation's Manageability Engine ("ME"), Active Management Technologies ("AMT"), Platform Resource Layer ("PRL") и/или другие сравнимые или аналогичные технологии) и/или виртуализированное разделение (например, виртуальное устройство по схеме Intel® Corporation's Virtualization Technology ("VT")). Как будет очевидно для специалистов в данной области техники, виртуализированное хост-устройство также может использоваться для воплощения технологии ME, AMT и PRL (как описано более подробно ниже со ссылкой на фиг.8.)

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

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

На фиг.1 иллюстрируется система, выполненная с возможностью администрирования устройствами, защищенными с использованием схем шифрования, аутентификации идентичности пользователя и защиты паролем, в соответствии с одним вариантом осуществления изобретения. Платформа 100 включает в себя процессор 110, соединенный с набором микросхем/защищенным разделом 120, через интерфейс 111a администрирования настольными компьютерами (DMI). Набор микросхем/защищенный раздел 120 включает в себя механизм 130 управляемости (ME), который может быть воплощен, как микропроцессор, для администрирования конфигурацией и операцией платформы 100. В одном варианте осуществления механизм 130 управляемости (ME) собирает события аудита, аутентифицирует пользователей, управляет доступом к периферийным устройствам, администрирует ключами шифрования для защиты данных, сохраненных в устройствах накопителях платформы 100, и формирует интерфейсы с консолью 166 администрирования через сетевой контроллер 160. Используя консоль 166 администрирования, механизм 130. управляемости (ME) поддерживает согласованность с политиками всего предприятия для конфигурирования и администрирования платформами, такими как платформа 100. Механизм 130 управляемости (ME) соединен с процессором 110 через интерфейс 111b контроллера, внедренного в хост-устройство (HECI).

Интерфейс 111 с контроллера механизма виртуализации (VECI) соединяет процессор 110 с модулем 140 декодирования команды I/O набора микросхем/защищенного раздела 120. В одном варианте осуществления модуль 140 декодирования команды I/O представляет собой контроллер общего назначения, который выполнен с возможностью использования специализированного встроенного программного обеспечения, для выполнения декодирования команды сохранения и других ускоренных операций. Функциональность модуля 140 декодирования команды I/O также может быть полностью воплощена в специализированном аппаратном оборудовании. Модуль 140 декодирования команды I/O обеспечивает функцию администрирования для защиты данных, записанных на носителе записи, ассоциированном с платформой 100. Например, модуль 140 декодирования команды I/O может взаимодействовать с механизмом 150 шифрования для шифрования устройства сохранения, защиты метаданных, используемых для защиты устройства сохранения, перехвата и обработки аппаратных прерываний, относящихся к устройствам сохранения, и способствования операциям администрирования в отношении устройств сохранения.

Механизм 130 управляемости (ME) управляет поведением модуля 140 декодирования команды I/O и механизмом 150 шифрования, путем конфигурирования политики и ключей шифрования. Операция механизма 130 управляемости (ME) модуля 140 декодирования команды I/O и механизма 150 шифрования более подробно описана ниже.

Платформа 100 дополнительно включает в себя запоминающие устройства, такие как динамическое оперативное запоминающее устройство (DRAM) 114, статическое оперативное запоминающее устройство (SRAM) 122 в пределах набора микросхем/защищенного раздела 120, и запоминающее устройство 190 флэш. Когда платформа 100 полностью включена, участок DRAM 114, называемый верхней областью памяти (UMA), ME-UMA 116, является доступным для использования механизма 130 управляемости (ME). Основная операционная система 115 для платформы 100 не имеет возможности доступа к ME-UMA 116, в общем, благодаря механизму изоляции памяти, который сконфигурирован основной системой ввода-вывода (BIOS). Такой механизм изоляции памяти фиксирует доступ к запоминающему устройству 116 ME-UMA еще до работы основной операционной системы. Благодаря изоляции такого участка DRAM 114 для использования механизма 130 управляемости от основной операционной системы, защищается целостность механизма 130 управляемости от вирусов или другого вредоносного программного обеспечения, которое может инфицировать основную операционную систему 115.

Запоминающее устройство 190 флэш содержит встроенное программное обеспечение, используемое для инициализации платформы 100. Такое встроенное программное обеспечение инициализации включает в себя встроенное программное обеспечение 192 BIOS, встроенное программное обеспечение 194 сетевого контроллера для конфигурирования сетевого контроллера 160 и встроенное программное обеспечение 196 набора микросхем для конфигурирования набора микросхем/защищенного раздела 120. Целостность встроенного программного обеспечения 196 набора микросхем для механизма 130 управляемости (ME) и модуля 140 декодирования команды I/O обеспечивается с помощью цифровой сигнатуры перед ее сохранением в запоминающем устройстве 190 флэш. Данные для использования механизма 130 управляемости (МБ), такие как информация аутентификации пользователя, могут быть зашифрованы с помощью встроенного программного обеспечения шифрования в пределах механизма 130 управляемости (ME) и сохранены в области 198 данных запоминающего устройства 190 флэш.

Вариант осуществления платформы 100, показанный на фиг.1, дополнительно включает в себя контроллер 175 универсальной последовательной шины (USB), соединенной с устройством 177 USB. Устройства USB могут включать в себя устройства - указатели (такие как "мышь"), клавиатура, цифровые фотокамеры, принтеры, персональные мультимедийные проигрыватели, приводы флэш и внешние приводы жесткого диска. Спецификация USB обеспечивает возможность установки и отключения устройств без необходимости открывать корпус компьютера (замена без перезагрузки) или перезапуска компьютера, что является полезным для мобильных периферийных устройств, включая в себя приводы различного рода. Вместо первоначально предусматривавшихся и все еще используемых в настоящее время оптических устройств накопителей (приводов CD-RW, приводов DVD и т.д.) ряд производителей предлагают внешние портативные приводы жесткого диска USB или пустые корпуса для приводов диска, которые обеспечивают рабочие характеристики, сравнимые с внутренними приводами, ограниченные текущим количеством и типом присоединяемых устройств USB, и могут представлять верхний предел интерфейса USB (на практике приблизительно 40 Мбит/с для USB 2.0 и, возможно, потенциально 400 Мбит/с или больше для USB 3.0). Такие внешние устройства обычно включают в себя "устройство переноса", которое составляет мостик между интерфейсом привода (IDE, ATA, SATA, PATA, ATAPI или даже SCSI) с портом интерфейса USB. Функционально, такой привод выглядит для пользователя так же, как внутренний привод. Другие конкурирующие стандарты для возможности подсоединения внешнего привода включают в себя eSATA, ExpressCard (в настоящее время в версии 2.0), и FireWire (IEEE 1394).

Вариант осуществления платформы 100, показанный на фиг.1, дополнительно включает в себя разные типы устройств накопителей, доступных через контроллер 170 I/O, включающие в себя энергонезависимое запоминающее устройство 172, доступ к которому осуществляется через интерфейс 171 накопителя, и устройство 180 накопителя последовательного интерфейса с усовершенствованной технологией (SATA), доступ к которому осуществляется через интерфейс 181 накопителя. Интерфейс 171 накопителя может быть воплощен, как интерфейсы хост-контроллера (HCI) энергонезависимого запоминающего устройства (NVM) для энергонезависимого запоминающего устройства, и интерфейс 181 накопителя может быть воплощен как интерфейс усовершенствованной HCI (AHCI) для устройства 180 накопителя усовершенствованной технологией (SATA). Контроллер 170 I/O включает в себя обе функции контроллера NVM и SATA.

Данные, сохраненные в устройствах 172 и 180 накопителей, могут быть зашифрованы с помощью механизма 150 шифрования набора микросхем/защищенного раздела 120. Устройство 180 накопитель SATA используется, как пример устройства, зашифрованного в наборе микросхем, и дополнительно включает в себя зарезервированную область для сохранения метаданных 182, которые включают в себя, по меньшей мере, один ключ 184 шифрования устройства (DEK) для сохранения устройства 180 и другие метаданные, используемые механизмом 130 управляемости (ME). Метаданные 182 защищены от перезаписи с помощью приложений, работающих в процессоре 110, во время обработки команд I/O, с помощью модуля 140 декодирования команд I/O и контроллера 170 I/O.

В одном варианте осуществления, перед выполнением шифрования или дешифрования данных с помощью механизма 150 шифрования набора микросхем/защищенного раздела 120, механизм 130 управляемости (ME) вставляет ключ шифрования устройства (DEK), такой как DEK 184, ассоциированный с устройством сохранения, вовлеченным в операцию ввода-вывода, в регистр памяти, ассоциированный с механизмом 150 шифрования. Если одно физическое устройство сохранения логически разделено на ряд разных логических устройств или разделов, тогда каждое логическое устройство или раздел может иметь свой собственный соответствующий ключ шифрования устройства (DEK), и каждый из этих DEK может быть вставлен в соответствующий регистр памяти для механизма 150 шифрования.

В одном варианте осуществления механизм 130 управляемости (ME) администрирует шифрованием всех данных, ассоциированных с платформой 100, включая в себя шифрование, выполняемое механизмом 150 шифрования, в пределах набора микросхем/защищенного раздела 120, а также данных, шифрование которых не выполнялось набором микросхем, но вместо этого выполнялось программным обеспечением, работающим в процессоре 110 или с помощью самого программного обеспечения накопления. Одна из услуг, предоставляемых механизмом 130 управляемости (ME), представляет собой администрирование ключами шифрования в общих пределах и интерфейсом пользователя, независимо от компонента платформы 100, который выполняет шифрование данных. Дополнительные детали о структуре и операции набора микросхем/защищенного раздела 120 и механизма 130 управляемости (ME), при администрировании шифрованием данных, представлены в заявке 12/319,210 на патент, под названием "Enforcing Use of Chipset Key Management Services for Encrypted Storage Devices", с указанным автором изобретения Ned Smith, которая представлена здесь полностью по ссылке.

На фиг.2 показаны дополнительные детали компонентов механизма 130 управляемости (ME) и модуля 140 декодирования команды I/O в наборе микросхем/защищенном разделе 120 по фиг.1, в соответствии с одним вариантом осуществления настоящего изобретения. В пределах набора микросхем/защищенного раздела 120, механизм 130 управляемости (ME) включает в себя ядро 231 ME, общие услуги 233 ME, защищенный менеджер 235 устройств, встроенное программное обеспечение 237 безопасности/администрирования ключом, и встроенное программное обеспечение 239 администрирования идентичности. Каждый из этих компонентов будет более подробно описан ниже.

Ядро 231 ME обеспечивает основную функцию, включая в себя использование памяти SRAM 122 и участков DRAM 112 (таких как ME-UMA 114), постоянное сохранение данных в запоминающем устройстве 190 флэш и администрирование доступом. Ядро 231 ME управляет операцией модуля 140 декодирования команды I/O и механизмом 150 шифрования.

Общие услуги 233 ME включают в себя услуги, обычно требуемые для разных модулей встроенного программного обеспечения, и включают в себя услуги безопасности, сетевые услуги и услуги инициализации. Услуги безопасности, предоставляемые общими услугами 233 ME, обычно включают в себя аутентификацию пользователя, состоящую одновременно из Дайджеста HTTP и аутентификации Kerberos; авторизацию домена, с использованием Microsoft Active Directory и/или других услуг; услуг синхронизации тактовой частоты, для синхронизации тактовой частоты клиента и сервера; и услуг аудита безопасности.

Сетевые услуги, предоставляемые общими услугами 233 ME, содержат стек протокола транспортирования передачи/протокола Интернет (ТСРЛР), безопасности уровня транспортирования (TLS), протокола транспортирования гипертекста (HTTP), протокола доступа к одному объекту (SOAP), сетевых услуг для администрирования (WS-MAN) и интерфейса TLS на основе хост устройства, называемый услугой локальной управляемости (LMS).

Услуги инициализации, обеспечиваемые общими услугами 233 ME, используют совместно с консолью 166 администрирования по фиг.1 для инициализации программного обеспечения предприятия для платформы 100. Такие услуги инициализации поддерживают два режима развертывания: нулевое прикосновение и одно прикосновение. В режиме нулевого прикосновения ключи привязки сертификата развертывания сохраняются в области сохранения данных, такой как область 198 данных запоминающего устройства 190 флэш по фиг.1, обеспечивая возможность использования хорошо известных ключей авторизации сертификата для удостоверения учетных записей IT, которые могут затем использоваться для получения права собственности над платформой. Режим одного прикосновения конфигурирует организационные сертификаты, ключи симметрии и доверительных хост устройств, которые можно использовать для завершения установки и дистанционных задач развертывания.

Механизм 130 управляемости также включает в себя внеполосный модуль 230 передачи данных (OOВ). Модуль 230 передачи данных OOВ способствует передаче данных между компонентами платформы 100 с соответствующими компонентами консоли 166 администрирования через сетевой контроллер 160. Модуль 230 передачи данных OOВ устанавливает защищенный канал 168 передачи данных OOВ между набором микросхем/защищенным разделом 120 и консолью 166 администрирования.

Механизм 130 управляемости (ME) также включает в себя встроенное программное обеспечение 239 администрирования идентичности. Встроенное программное обеспечение 239 администрирования идентичности может сравнивать информацию аутентификации пользователя с метаданными учетной записи пользователя, сохраняемыми, например, в области 198 данных запоминающего устройства 190 флэш. Встроенное программное обеспечение 239 администрирования идентичности также может взаимодействовать со встроенным программным обеспечением 237 безопасности//администрирования ключом механизма 130 управляемости (ME), для подтверждения того, что информация пользователя также сохранена в контейнере в пределах устройства сохранения, такого как устройство 180 сохранения SATA. Такое подтверждение доступа пользователя к определенному устройству сохранения, такому как устройство сохранения 180 SATA, обеспечивает дополнительный уровень защиты данных, сохраненных в устройстве 180 сохранения SATA.

Встроенное программное обеспечение 237 безопасности//администрирования ключом администрирует ключами, такими как ключи шифрования, сформированные механизмом 150 шифрования. Встроенное программное обеспечение 237 безопасности//администрирования ключом может также аутентифицировать пользователей до того, как будет разрешен доступ к данным, сохраненным в устройствах сохранения, ассоциированных с платформой 100. Встроенное программное обеспечение 237 безопасности//администрирования ключом администрирует информацией /администрирования ключом и сохраняет эту информацию /администрирования ключом в запоминающем устройстве, или в устройстве накопителе, ассоциированном с платформой, таком как запоминающее устройство 190 флэш, или в устройстве 180 накопителе SATA. Местоположение, в котором информация /администрирования ключом сохранена, зависит от доступного пространства сохранения и количества данных, предназначенных для сохранения, и изобретение не ограничено определенной конфигурацией для сохранения информации администрирования ключом. В одном варианте осуществления встроенное программное обеспечение 237 безопасности//администрирования ключом шифрует информацию /администрирования ключом, используя ключ контейнера платформы (РСК), который связан с платформой 100.

Информация /администрирования ключом, администрируемая встроенным программным обеспечением 237 безопасности//администрирования ключом, включает в себя ключи шифрования, генерируемые набором микросхем (то есть, механизмом 150 шифрования в пределах набора микросхем/защищенного раздела 120) и сохраненных в метаданных 182, называемых ключом 184 шифрования устройства (DEK).

Механизм 130 управляемости (ME) дополнительно показан, как включающий в себя менеджер 235 защищенного устройства. В одном варианте осуществления менеджер 235 защищенного устройства связывается с модулем 140 декодирования команды I/O для подачи пароля устройства, используемого для разблокирования устройства, такого как устройство 180 сохранения SATA. Операция защищенного менеджера 235 устройства более подробно описана ниже со ссылкой на фиг.3 и 4.

Модуль 140 декодирования команды I/O показан, как включающий в себя ядро 241 модуля I/O и встроенное программное обеспечение 243 виртуализации SATA. Ядро 241 модуля I/O обеспечивает основную функцию модуля 140 декодирования команды I/O и принимает команды из ядра 231 ME. В то время как встроенное программное обеспечение 243 виртуализации SATA описано со ссылкой на этот вариант осуществления, как встроенное программное обеспечение, функция 243 встроенного программного обеспечения виртуализации SATA также может быть воплощена, как специализированное аппаратное обеспечение. Встроенное программное обеспечение 243 виртуализации SATA используется для доступа к устройствам сохранения SATA, таким как устройство 180 сохранения SATA, и обеспечивает выполнение механизмом 130 управляемости (ME) функции администрирования устройствами. Например, встроенное программное обеспечение 243 виртуализации SATA обеспечивает удаленный доступ защищенных устройств с помощью консоли 166 администрирования, путем ввода пакетов управления SATA в поток данных I/O без вовлечения основной операционной системы 115 или другого хост программного обеспечения, работающего в процессоре 110. Пакеты управления могут использоваться, например, для разблокирования устройства 180 сохранения SATA через команды из консоли 166 администрирования.

Встроенное программное обеспечение 243 виртуализации SATA также используется для скрытия диапазона адресов линейного блока в устройстве 180 сохранения SATA из основной операционной системы 115. Этот диапазон скрытых адресов линейного блока, скрытых от доступа основной операционной системы, называется здесь защищенной областью хранения, которая защищена таким образом, что метаданные 182 устройства могут быть сохранены в приводе. Метаданные устройства 182 могут включать в себя ключ 184 шифрования устройства, который обеспечивает шифрование и дешифрование блоков 180 устройства сохранения SATA.

Встроенное программное обеспечение 243 виртуализации SATA также может перехватывать события, детектируемые контроллером 170 I/O, такие как прерывания замены без перезагрузки, генерируемые, когда новое устройство соединяют с платформой 100. Встроенное программное обеспечение 243 виртуализации SATA также может отслеживать поток I/O в и из устройств сохранения, и детектировать события для аудита.

В одном варианте осуществления устройство 180 сохранения SATA защищено с использованием, как шифрования, так и пароля, такого, как пароль АТА, который должен быть введен пользователем перед тем, как может быть получен доступ к устройству. Пароль используется для разблокирования собственного механизма блокирования устройства 180 сохранения SATA. Механизм 150 шифрования используется для шифрования блоков устройства 180 сохранения SATA. Ключ шифрования устройства SATA (DEK), такой как DEK 184, сохранен в устройстве SATA в местоположении, которое скрыто для основной операционной системы. Устройство вначале разблокируют, используя пароль для собственного механизма блокирования перед тем, как может быть получен доступ к DEK для дешифрования зашифрованных блоков.

Во время сброса платформы 100 модуль 140 декодирования команды I/O и механизм 130 управляемости (ME) взаимодействуют для считывания метаданных устройства, таких как ключи шифрования и учетные записи аутентификации, пользователя, из устройства и сохранения метаданных устройства на защищенном накопителе, таком как область 198 данных запоминающего устройства 190 флэш, в качестве метаданных 298 устройства. В одном варианте осуществления для каждого пользователя, который может быть аутентифицирован в консоли 166 администрирования, имеется маркер, такой как Token-1 266A по фиг.2, который используется для вывода ключа обертывания для определенного устройства. Ключ обертывания устройства, в свою очередь, используется для обертывания ключа шифрования этого конкретного устройства.

Ключ обертывания пользователя и ключ обертывания устройства используются вместе, для определения, может ли пользователь получить доступ к конкретному устройству, и пары из ключа обертывания пользователя/ключа обертывания устройства сохранены в области 198 данных запоминающего устройства 190 флэш, как метаданные 298 устройства. В отличие от этого, ключ шифрования устройства, такой как DEK 184, сохранен в самом устройстве сохранения. Когда требуется получить доступ к устройству, копия Token-1 используется для определения соответствующей пары ключа обертывания пользователя/ключа обертывания устройства из метаданных 298 устройства. Ключ обертывания устройства пары используется для дешифрования метаданных 182 в устройстве, которое раскрывает ключ 184 шифрования устройства. Token-1 используют для выполнения операции администрирования для устройства сохранения, когда пользователь отсутствует или когда пользователь не может сформулировать необходимые учетные данные аутентификации.

В одном варианте осуществления метаданные 182 устройства зашифрованы механизмом 150 шифрования, используя другой ключ обертывания устройства, выведенный другим маркером, который упоминается здесь, как Token-2, который сохранен в устройстве USB, таком как устройство 177 USB. Устройство 177 USB предназначено для его надежного сохранения в физическом месте, не доступном для доступа ворам. Token-2 используют для выполнения операции администрирования в устройстве сохранения, когда никакое сетевое соединение не доступно для консоли 166 дистанционного администрирования, для соединения с устройством сохранения. Устройство 177 USB содержит Token-2 в незашифрованной форме открытого текста таким образом, что владелец Token-2 неявным образом авторизуется для выполнения операции администрирования в устройстве сохранения. Если предусмотрен Token-2, второй набор ключей обертывания пользователя выводят, используя Token-2, и второй набор из пар ключа обертывания пользователя/ключа обертывания устройства также может быть сохранен в запоминающем устройстве 190 флэш, как часть метаданных 298 устройства. Оба значения Token-1 и Token-2 защищены системой аутентификации пользователя, такой как встроенное программное обеспечение 239 администрирования идентичности таким образом, что только авторизованные пользователи имеют возможность раскрывать ключи шифрования устройства.

В одном варианте осуществления Token-1 266A надежно заархивирован в удаленном накопителе 266, ассоциированном с консолью 166 администрирования (или с услугой директории), вместе с паролем 266 В устройства 180. Пароль 266 В устройства 180 и Token-1 266A используется консолью 166 администрирования для дистанционного разблокирования устройства 180 SATA. Пароль 266 В устройства 180 предоставляется удаленной консолью 166 администрирования менеджеру 235 защищенного устройства, который использует пароль 266 В устройства 180 для разблокирования устройства. Менеджер 235 защищенного устройства предоставляет Token-1 266A во встроенное программное обеспечение 237 безопасности//администрирования ключом, который может использовать встроенное программное обеспечение 239 администрирования идентичности для развертывания ключа обертывания пользователя. Ключ обертывания пользователя используется для развертывания ключа обертывания устройства, который используется для дешифрования метаданных 182 и, таким образом, для предоставления доступа к ключу 184 шифрования устройства, который может использоваться механизмом 150 шифрования, для дешифрования блоков устройства 180 сохранения SATA. Token-1 266A защищен от сетевых атак, полагаясь на защищенный канал передачи данных, такой как канал 168 передачи данных 00 В, между консолью 166 администрирования и набором микросхем/защищенным разделом 120. Канал 168 передачи данных 00 В может быть защищен с использованием, например, ключей сеанса Kerberos.

Поскольку данные в устройстве 180 сохранения SATA могут быть зашифрованы, ключ 184 шифрования устройства (DEK) может быть сохранен в местоположении, доступном для менеджера 235 защищенного устройства для механизма 130 управляемости (ME). Благодаря тому, что DEK сделан доступным для менеджера 235 защищенного устройств, запросы считывания-записи SATA через интерфейсы 111b и 111c HECI/VECI могут обслуживаться даже в случае, когда данные в устройстве 180 сохранения SATA являются зашифрованными. После того, как менеджер 235 защищенного устройства получает доступ к паролю для разблокирования устройства 180 сохранения SATA, менеджер 235 защищенного устройства может сделать копию ключа обертывания устройства, который сохраняют в метаданных 298 устройства. Ключ обертывания устройства может использоваться для развертывания ключа шифрования устройства, содержащегося в метаданных устройства для каждого устройства SATA, прикрепленного к платформе.

На фиг.3 показана блок-схема последовательности операций способа, выполняемого после сброса системы, имеющей устройства, защищенные схемами защиты шифрованием, аутентификацией идентичности пользователя и паролем, в соответствии с одним вариантом осуществления изобретения. Способ по фиг.3 будет описан, как выполняемый компонентами системы по фиг.2, хотя способ не ограничен таким вариантом осуществления. После сброса системы, управление переходит на этап 310 "Менеджер защищенного устройства ME считывает метаданные устройства из устройства SATA опосредованно через модуль декодирования команда I/O через MECI". На этапе 310 менеджер 235 защищенного устройства механизма 130 управляемости получает информацию о присоединенных устройствах сохранения, путем считывания метаданных устройства из устройств SATA, таких как устройство 180 сохранения SATA. Поскольку механизм 130 управляемости не соединен непосредственно с устройствами сохранения, менеджер 235 защищенного устройства механизма 130 управляемости получает доступ к метаданным устройства опосредованно через модуль 140 декодирования команды I/O через MECI 131. Менеджер 235 защищенного устройства механизма 130 управляемости использует встроенное программное обеспечение 243 виртуализации SATA для получения доступа к метаданным устройства, сохраненным в устройствах SATA, таких как устройство 180 сохранения SATA. Встроенное программное обеспечение 243 виртуализации SATA раскрывает интерфейс сохранения для менеджера 235 защищенного устройства, таким образом, что устройство 180 сохранения SATA выглядит, как блочное устройство сохранения адресов линейного блока. Встроенное программное обеспечение 243 виртуализации SATA скрывает некоторые из адресов линейного блока от основной операционной системы и раскрывает их менеджеру 235 защищенного устройства. Встроенное программное обеспечение 243 виртуализации SATA взаимодействует с устройством 180 сохранения SATA, используя протокол I/O SATA.

Из этапа 310 "Менеджер защищенного устройства ME считывает метаданные устройства из устройств SATA опосредованно через модуль декодирования команды I/O через MECI", управление переходит на этап 320 "Модуль декодирования команды I/O считывает метаданные определения виртуального привода, содержащие информацию дескриптора метаданных". На этапе 320 встроенное программное обеспечение 243 виртуализации SATA модуля 140 декодирования команды I/O считывают метаданные определения виртуального привода, которые содержат информацию дескриптора метаданных, которая сохранена в метаданных 182, сохраненных в устройстве 180 сохранения SATA. В одном варианте осуществления встроенное программное обеспечение 243 виртуализации SATA выполняет виртуализацию устройства сохранения, таким образом, что множество разделов виртуального привода может быть распознано. Каждый из этих разделов виртуального привода описан в данных определения виртуального привода. Содержащееся в первом виртуальном приводе жесткого диска (HDD) определение может представлять собой традиционные элементы конфигурации привода. Например, начиная с нулевого адреса линейного блока (LBA), может быть сохранена главная загрузочная запись (MBR), после чего следуют данные привода, такие как файлы операционной системы и файлы пользователя. Некоторые системы имеют скрытые разделы, которые могут использоваться BIOS или другими системными утилитами. Защищенная хост область (НРА) может использоваться для сохранения OS аварийного восстановления (ROS), мультимедийных утилит, утилит диагностики или других программ. Системы, в которых воплощены избыточные массивы недорогих дисков (RAID), могут размещать метаданные RAID в конце виртуального привода. Путем размещения метаданных RAID в конце виртуального привода, необязательный ROM RAID может легко находить метаданные RAID при инициализации системы.

В одном варианте осуществления один ключ шифрования устройства, такой как DEK 184, охватывает каждый виртуальный HDD в устройстве, в результате чего все виртуальные HDD зашифрованы одним и тем же ключом. Данные определения виртуального привода (VDD) размещены в конце физического привода, например, в последнем адресе линейного блока LBA-n. Данные VDD содержат структуру привода, маркировку начала и конца каждого виртуального HDD. VDD также идентифицирует местоположения начала и конца области метаданных механизма управляемости, такие как местоположения начала и конца метаданных 182. Метаданные VDD и ME могут не быть зашифрованы механизмом 150 шифрования, но содержание метаданных 182 защищено модулем 140 декодирования команды I/O и механизмом 130 управляемости (ME).

В одном варианте осуществления метаданные 182 включают в себя блок системы файла AHCI, код аутентификации перед начальной загрузкой (РВА) и метаданные РВА. Система файла AHCI используется приводом сохранения встроенного программного обеспечения, который может быть выполнен процессором 110. Метаданные 182 также могут включать в себя обернутый DEK 184, данные конфигурации устройства, информацию статуса преобразования привода и пакет миграции привода, который можно использовать для миграции устройства, такого, как устройство 180 сохранения SATA, на другую платформу. Пакет миграции также содержит копию DEK 184, обернутую в ключ восстановления, который, в частности, не связан с платформой. Метаданные 182 также могут содержать исполняемые программы РВА и идентификатор для области сохранения, содержащий код РВА, выполняемый во время начальной загрузки в хост процессоре 110, перед тем, как основная операционная система будет загружена. Например, такая область сохранения, содержащая код РВА, может представлять собой часть запоминающего устройства 190 флэш. Доступ к области РВА разрешен кодом, выполняемым в хост процессоре 110, через модуль 140 декодирования команды I/O, использующий VECI 111с или через механизм 130 управляемости (ME), через хост интерфейс команды, который использует HECI 111b. Модуль 140 декодирования команды I/O обеспечивает то, что запросы на доступ к области сохранения РВА будут ограничены диапазоном сохранения, в котором сохранены исполняемые программы РВА, поскольку код РВА исполняется в хост процессоре 110.

Когда встроенное программное обеспечение 243 виртуализации SATA модуля 140 декодирования команды I/O считывает метаданные определения виртуального привода, которые содержат информацию дескриптора метаданных, которая сохранена в метаданных 182, сохраненных в устройстве 180 сохранения SATA "Модуль декодирования команды I/O считывает метаданные определения виртуального привода, содержащие информацию дескриптора метаданных" на этапе 320, при этом информация дескриптора метаданных может включать в себя множество экземпляров обернутого ключа шифрования устройства, такого как DEK 184, в метаданных 182 устройства. Например, DEK 184 может быть обернут как ключом обертывания устройства, который является специфичным для платформы, а также может быть обернут ключом восстановления, который не связан с платформой 100. Поскольку могут присутствовать множество экземпляров ключа шифрования устройства, существует потребность в определении местоположения конкретного ключа шифрования устройства, который может быть развернут, используя учетные данные аутентификации пользователя, вовлеченные в выполнение перезагрузки системы.

Как описано выше, пользователь, выполняющий перезагрузку системы, будет иметь ассоциированный ключ обертывания пользователя, который используют для обертывания ключа обертывания устройства. Ключ обертывания пользователя/ключи обертывания устройства сохранены в метаданных 289 устройства запоминающего устройства 190 флэш. Управление переходит на этап 330 "Модуль декодирования команды I/O определяет местоположение смещения метаданных аутентификации пользователя и считывает метаданные устройства". На этапе 330 модуль 140 декодирования команды I/O использует информацию дескриптора метаданных, для обнаружения места нахождения смещения метаданных аутентификации пользователя в пределах запоминающего устройства 190 флэш для учетных данных пользователя, используемых для выполнения сброса системы. Метаданные аутентификации пользователя и другие метаданные устройства считывают из местоположения запоминающего устройства 190 флэш, идентифицированного по смещению.

После считывания метаданных 298 устройства из запоминающего устройства 190 флэш на этапе 330 "Модуль декодирования команды I/O определяет местоположение смещения метаданных аутентификации пользователя и считывает метаданные устройства", управление переходит на этап 340 "Менеджеру защищенного устройства ME, сохраняет метаданные устройств на защищенном накопителе". Например, менеджер 235 защищенного устройства ME может сохранять метаданные устройства, включающие в себя учетные данные аутентификации пользователя для устройства 180 сохранения SATA, в метаданных 298 устройства из запоминающего устройства 190 флэш, для последующего доступа, с использованием механизма 130 управляемости (ME). Управление затем переходит к "Менеджеру защищенного устройства ME, ожидает выдачи команды операции управляемости" этап 350. Например, менеджер 235 защищенного устройства ME ожидает команды операции управляемости, такой как команда разблокирования, для доступа к устройству 180 сохранения SATA. После приема команды операции управляемости, менеджер 235 защищенного устройства ME может получить доступ к сохраненным метаданным для получения учетных данных аутентификации пользователя, и/или другой информации, требуемой для доступа к устройству 180 сохранения SATA.

На фиг.4 показана блок-схема последовательности операций способа, выполняемых после приема команды для разблокирования устройств, защищенных схемами защиты шифрованием, аутентификацией идентичности пользователя и паролем, в соответствии с одним вариантом осуществления изобретения. Способ по фиг.4 будет описан, как выполняемый компонентами системы по фиг.2, хотя этот способ не ограничен таким вариантом осуществления. Два примера потока операций способа представлены на фиг.4, в зависимости от происхождения запроса на разблокирование защищенного устройства. Этапы способа, включенные в блок 402 дистанционного разблокирования, вовлекают обработку команды дистанционного разблокирования, такую как команда разблокирования, принимаемой из консоли 166 администрирования через защищенный канал передачи данных, такой как канал 168 передачи данных 00 В. Этапы способа, включенные в блок 418 разблокирования USB, вовлекают обработку команды разблокирования в связи с устройством USB, содержащим маркер для разблокирования устройства сохранения.

Этапы способа блока 402 дистанционного разблокирования, для обработки дистанционной команды разблокирования, начинаются с этапа 404 "Консоль администрирования инициирует запрос на дистанционное разблокирование устройства SATA". Консоль 166 администрирования может инициировать запрос в ответ на политики администрирования предприятием, или консоль 166 администрирования может действовать в ответ на уведомление из механизма 130 управляемости (ME), что должно быть разблокировано устройство, такое как устройство 180 сохранения SATA. Консоль 166 администрирования инициирует запрос на разблокирование зашифрованного устройства SATA через механизм 130 управляемости (ME) и набор микросхем/защищенный раздел 120 в обстоятельствах, когда пользователь не присутствует за клавиатурой, когда пользователь присутствует, но не может успешно аутентифицироваться для платформы, когда платформа находится в состоянии ограниченного потребления питания (например, в соответствии с одним из усовершенствованных интерфейсов конфигурирования и энергопотреблением (ACPI) Sx, состояния питания от S1 до S5), когда система соединена через кабельную или беспроводную сеть или за пределами корпоративного брандмауэра, но устройства не доступны, и когда основная операционная система для системы неисправна.

Управление переходит с этапа 404 "Консоль администрирования инициирует запрос на дистанционное разблокирование устройства SATA" на этап 406 "Консоль администрирования соединяется с защищенным разделом; передает команду разблокирования диска, содержащую Token-1 и пароль устройства". Консоль 166 администрирования может использовать, независимо защищенный и зашифрованный каналы, такие как канал 168 передачи данных 00 В, для передачи защищенных команд, которые передают инструкции на операции разблокирования во встроенную подсистему защиты, предусмотренную набором микросхем/защищенным разделом 120. Когда канал защищенной передачи данных, такой как канал 168 передачи данных 00 В, устанавливается между консолью 166 администрирования и набором микросхем/ защищенным разделом 120, используется аутентификация Kerberos с помощью встроенного программного обеспечения 239 администрирования идентичности, для аутентификации консоли 166 администрирования и механизма 130 управляемости (ME). Если запрос на дистанционное разблокированные был инициирован механизмом 130 управляемости (ME), после установления защищенного канала передачи данных, консоль 166 администрирования может получать учетные данные пользователя, такие как имя пользователя и пароль, для пользователя, ассоциированного с платформой 100. Если запрос на дистанционное разблокирование был инициирован консолью 166 администрирования, учетные данные пользователя администратора могут использоваться для платформы 100. Такие учетные данные пользователя используются консолью 166 администрирования для получения ассоциированного пароля для устройства, такого как пароль 266 В устройства 180, и маркер, используемый для дешифрования устройства, такого как Token-1 266A, из накопителя 266 данных администрирования.

На этапе 406 "Консоль администрировании соединяется с защищенным разделом; передает команду разблокирования диска, содержащую Token-1 и пароль устройства" пароль устройства включают в команду разблокирования таким образом, что устройство может быть разблокировано, используя пароль устройства. Благодаря включению Token-1 в команду, ключ обертывания пользователя /ключ обертывания устройства могут быть идентифицированы, например, как в метаданные 298 устройства. Ключ обертывания пользователя/ключ обертывания устройства можно использовать для дешифрования блоков зашифрованного устройства сохранения, включающего в себя метаданные 182, которые включают в себя ключ 184 шифрования устройства.

С этапа 406 "Консоль администрирования соединяется с защищенным разделом; передает команду разблокирования диска, содержащую Token-1 и пароль устройства", управление переходит на этап 408 "Менеджер защищенного устройства ME удостоверяет команду, происходящую из доверительной консоли". Учетные данные аутентификации Kerberos, которые были необходимы для установления канала защищенной передачи данных между консолью 166 администрирования и набором микросхем/защищенным разделом 120, могут использоваться для удостоверения того, что команда происходит из доверительной консоли 166 администрирования. Управление затем переходит на этап 410 "Менеджер защищенного устройства ME использует Token-1 для разворачивания копии DEK в метаданных устройства". Как описано выше, после того, как менеджер 235 защищенного устройств получит доступ к паролю 266 В устройства 180 для разблокирования устройства 180 сохранения SATA, менеджер 235 защищенного устройства может сделать копию ключа обертывания устройства, который сохранен в метаданных 298 устройства запоминающего устройства 190 флэш. Ключ обертывания устройства может использоваться для разворачивания ключей шифрования устройства, содержащихся в метаданных устройства, для каждого устройства SATA, соединенного с платформой.

После того, как менеджер 235 защищенного устройства ME получит ключ шифрования устройства для зашифрованного устройства сохранения, управление переходит на этап 412 "Встроенное программное обеспечение безопасности МЕ/администрирования ключом записывает защиту DEK для механизма шифрования в регистр keyslot, соответствующий устройству SATA". Как описано в патентной заявке 12/319,210, под названием " Enforcing Use of Chipset Key Management Services for Encrypted Storage Devices" изобретателя Ned Смит, которая включена здесь полностью по ссылке, представленной выше, ключи шифрования устройства могут быть сохранены в регистрах keyslot внутри механизма 150 шифрования. Во время доступа к устройству, механизм 150 шифрования затем использует сохраненные ключи шифрования устройства из соответствующего регистра keyslot для дешифрования данных, сохраненных в соответствующем устройстве.

После того, как ключ шифрования устройства будет сделан доступным для механизма 150 шифрования на этапе 412 "Встроенное программное обеспечение безопасности МЕ/администрирования ключом записывает защиту DEK для механизма шифрования в регистр keyslot, соответствующий устройству SATA", управление переходит на этап 414 "Менеджер защищенного устройства ME выполняет операцию управляемости (которая может включать в себя перезагрузку OS)". Например, в ответ на команду дистанционного разблокирования, менеджер 235 защищенного устройства ME разблокирует устройство, которое может включать в себя предоставление пароля устройства для разблокирования устройства и использование механизма 150 шифрования для дешифрования блоков зашифрованного устройства. Если устройство дополнительно зашифровано программным обеспечением хост устройства, операция управляемости может потребовать, чтобы консоль 166 администрирования связалась с доверительным основным программным -обеспечением для дальнейшего дешифрования устройства. В ответ на команду разблокирования USB, менеджер 235 защищенного устройства ME аналогично разблокирует устройство, включая в себя использование пароля устройства для разблокирования устройства и механизм 150 шифрования для дешифрования блоков зашифрованного устройства. В зависимости от конкретной обрабатываемой команды операции управляемости, платформа может быть перезагружена, включая в себя перезагрузку основной операционной системы..

После выполнения операции управляемости на этапе 414 "Менеджер защищенного устройства ME выполняет операцию управляемости (которая может включать в себя перезагрузку OS)", управление переходит на этап 416 "Менеджер защищенного устройства ME выполняет перезагрузку платформы, в результате чего устройство SATA снова становится заблокированным". Менеджер 235 защищенного устройства ME выполняет этапы, описанные со ссылкой на фиг.3 для перезагрузки системы, в результате чего устройство сохранения будет снова заблокировано.

Как описано выше, фиг.4 также включает в себя этапы способа для разблокирования устройства вручную, используя команду разблокирования USB. Этапы способа в блоке 418 разблокирования USB для обработки команды разблокирования USB начинают на этапе 420 "Приложение BIOS подсказывает пользователю вставить устройство USB, содержащее Token-2". После запуска системы, приложение BIOS подсказывает пользователю вставить устройство USB, содержащее Token-2, для обеспечения доступа пользователя к устройству, такому, как устройство 180 сохранения SATA. Например, такая подсказка BIOS может быть предусмотрена, если пользователь не может ввести пароль для доступа к устройству. Управление переходит на этап 422 "BIOS считывает Token-2 и передает его в менеджер защищенного устройства ME через HECI/DHCI". Приложение BIOS считывает Token-2, предоставленный пользователем, и передает Token-2 в менеджер 235 защищенного устройства ME через HECI 111b. Управление затем переходит к этапу 424 "Менеджер защищенного устройства ME использует Token-2 для разворачивания копии DEK в метаданных устройства". Как описано выше, будучи защищенным, менеджер 235 устройства имеет доступ для разблокирования маркера для разблокирования устройства 180 сохранения SATA, при этом менеджер 235 защищенного устройства может сделать копию ключа обертывания устройства (DWK), которую сохраняют в метаданных устройства, таких как область 198 данных запоминающего устройства 190 флэш. DWK может использоваться для дешифрования DEK, содержащегося в метаданных устройства для каждого устройства SATA, присоединенного к платформе. После того, как ключ шифрования устройства будет сделан доступным для механизма 150 шифрования на этапе 412 "Встроенное программное обеспечение безопасности МЕ/администрирования ключом записывает защиту DEK для механизма шифрования в регистр keyslot, соответствующий устройству SATA", управление переходит, как описано выше.

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

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

Система на фиг.5А и 5В обеспечивает возможность доступа к устройству подключаемому без перезагрузки системы, при условии аутентификация учетных данных пользователя системы. Устройство, подключаемое без перезагрузки системы, может быть разблокировано и/или дешифровано, и учетные данные пользователя могут быть подтверждены, без перезагрузки системы, даже если устройство заблокировано или зашифровано с использованием команды АТА.

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

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

На фиг.5А показаны дополнительные детали системы по фиг.1 при обеспечении возможности для устройств динамического подключения, защищенных схемами защиты шифрованием, аутентификацией идентичности пользователя и паролем, и динамического подтверждения учетных данных аутентификации пользователя, без перезагрузки, в соответствии с одним вариантом осуществления изобретения. Ядро 531 механизма управляемости, общие услуги 533 механизма управляемости, встроенное программное обеспечение 537 безопасности/администрирования ключом, ядро 541 модуля I/O и встроенное программное обеспечение 543 виртуализации SATA работают, как описано со ссылкой на соответствующие компоненты системы по фиг.2.

В пределах механизма 130 управляемости (ME), клиент 539А Kerberos встроенного программного обеспечения администрирования идентичности взаимодействует с сервером 539 В Kerberos встроенного программного обеспечения администрирования идентичности для аутентификации пользователей. Клиент 539А Kerberos воплощает протокол Kerberos для Центра распределения ключа, такого как Центр 164 распределения ключа по фиг.1. Клиент 539А Kerberos может использовать доверительное встроенное программное обеспечение 536 I/O (если доступно), для использования соединений надежного канала с устройством дисплея и устройством ввода данных пользователем, для получения учетных данных от пользователя системы. Клиент 539А Kerberos может предоставлять учетные данные пользователя в центр 164 распределения ключа и получить билет Kerberos для доступа к услуге Kerberos, такой как предоставляет сервер 539 В Kerberos. Сервер 539 В Kerberos обеспечивает доступ к устройству 180 сохранения SATA после приема билета Kerberos, обозначающего, что учетные данные пользователя для доступа к устройству были аутентифицированы. Билет Kerberos может включать в себя поле расширения, которое содержит маркер пользователя, такой как Token-1 266A по фиг.2, который обеспечивает возможность генерирования ключа обертывания пользователя, который может использоваться для разворачивания ключа обертывания устройства и ключа шифрования устройства, как описано выше со ссылкой на фиг.2. Билет Kerberos также может включать в себя поле расширения, которое содержит пароль устройства, такой как пароль 266 В устройства 180 по фиг.2, который можно использовать для разблокирования устройства.

В пределах модуля 140 декодирования команды I/O встроенное программное обеспечение виртуализации подключения без перезагрузки декодирует события подключения без перезагрузки, принятые контроллером 170 I/O, и обрабатывает эти события перед дальнейшей передачей события подключения без перезагрузки в основную операционную систему 115. Операция встроенного программного обеспечения 545 виртуализации подключения без перезагрузки описана более подробно со ссылкой на фиг.5 В.

На фиг.5 В показана блок-схема последовательности операций способа, выполняемого системой по фиг.5А после распознавания события подключения устройства без перезагрузки. В действии 5.1, контроллер 170 I/O детектирует событие подключения без перезагрузки SATA, где устройство 180 сохранения SATA было динамически присоединено к платформе 100. Во время действия 5.2, встроенное программное обеспечение 545 виртуализации подключения без перезагрузки перехватывает событие подключения без перезагрузки и взаимодействует со встроенным программным обеспечением 543 виртуализации SATA, для раскрытия атрибутов устройства. Встроенное программное обеспечение 545 виртуализации подключения без перезагрузки запрашивает доступ к устройству, подключенному без перезагрузки из клиента 539А Kerberos встроенного программного обеспечения 539 администрирования идентичности. Если устройство заблокировано с использованием схемы пароля. АТА, шифрования АТА и/или шифрования на основе набора микросхем, встроенное программное обеспечение 545 виртуализации подключения без перезагрузки также может уведомлять клиента Kerberos 539A о том, что устройство 180 сохранения SATA заблокировано, как часть запроса, для доступа к устройству.

Во время действия 5.4, клиент 539A Kerberos получает информацию пользователя, такую как учетные данные аутентификации пользователя. Клиент 539A Kerberos может определять, помещены ли учетные данные пользователя в локальный кэш без механизма 130 управляемости (ME), такой как SRAM 122. Если учетные данные пользователя помещены в локальный кэш, действия 5.4 и 5.5 могут быть пропущены. Если учетные данные пользователя не помещены в локальный кэш, эти учетные данные аутентификации пользователя могут быть получены через доверительное встроенное программное обеспечение 536 I/O, если они доступны в платформе 100. Доверительное встроенное программное обеспечение 536 I/O использует соединение надежного канала, такое как соединение надежного канала с устройством дисплея для отображения запроса для ввода учетных данных и соединения надежного канала с устройством ввода данных пользователем, таким как клавиатура, для приема учетных данных. В варианте осуществления, в котором доверительное встроенное программное обеспечение 536 I/O ввода-вывода не доступно на платформе 100, уведомление может быть передано в хост агент (не показан), работающий в процессоре 110, о том, что было подключено новое устройство. Хост агент может собрать учетные данные пользователя и соединить набор микросхем/защищенный раздел 120 для разблокирования устройства и для того, чтобы сделать устройство видимым для основной операционной системы 115.

Во время действия 5.5, клиент 539A Kerberos получает билет Kerberos из центра 164 распределения ключа. В одном варианте осуществления билет Kerberos предоставляется вместе с маркером разблокирования для пользователя, таким как Token-1 266А по фиг.2, для устройства 180 сохранения SATA, и пароль АТА, принадлежащий пользователю, такой как пароль 266 В устройства 180 по фиг.2. Такой маркер разблокирования и пароль АТА для пользователя могут быть получены из услуги директории, такой как консоль 166 администрирования по фиг.1 и 2. Билет Kerberos подтверждает аутентичность учетных данных пользователя для приема услуги от сервера 539 В Kerberos. В одном варианте осуществления сервер 539 В Kerberos обеспечивает для клиента 539А Kerberos весь доступ к другим услугам в пределах механизма 130 управляемости (ME), таким, как услуги из встроенного программного обеспечения 537 безопасности/администрирования ключом и менеджера 539 защищенного устройства. В других вариантах осуществления раздельный билет Kerberos может быть получен для доступа к услугам, предоставляемым другим компонентам механизма 130 управляемости (ME), таким как встроенное программное обеспечение 537 безопасности/администрирования ключом. В одном варианте осуществления маркер разблокирования для пользователя для устройства 180 сохранения SATA и пароль АТА, принадлежащий пользователю, выводят, как поле расширения, которое представляет собой часть ключа сеанса Kerberos.

В действии 5.6 клиент 539А Kerberos подтверждает учетные данные пользователя с помощью сервера 539 В Kerberos. В альтернативном варианте осуществления клиент Kerberos 539А может подтвердить учетные данные пользователя непосредственно с помощью центра 164 с распределения ключа, без пропуска через локальный сервер Kerberos, такой как сервер 539 В Kerberos. Например, клиент 539А Kerberos может получить билет Kerberos для доступа к другой услуге аутентификации пользователя, такой как услуга активной директории, которая возвращает Token-1 266A и пароль 266 В устройства 180 при последующем обмене. В одном варианте осуществления консоль 166 администрирования по фиг.1 и 2 может формировать прокси-соединение с другой услугой аутентификации пользователя и/или сама может представлять собой хост-устройство для услуги аутентификации пользователя.

Действия 5.7-5.10 описывают действия, предпринимаемые, если устройство 180 сохранения SATA, подключенное без перезагрузки, защищено собственным механизмом блокирования, таким как пароль АТА или шифрование АТА. Если устройство не защищено собственным механизмом блокирования, таким как пароль АТА или шифрование АТА, этапы 5.7-5.10 могут быть пропущены.

Во время действия 5.7, в ситуации, когда устройство 180 сохранения SATA, подключенное без перезагрузки, было заблокировано с использованием пароля АТА, клиент 539А Kerberos предоставляет пароль АТА пользователя менеджеру 535 защищенного устройства. Во время действия 5.8, менеджер 535 защищенного устройства предоставляет пароль АТА пользователя во встроенное программное обеспечение 543 виртуализации SATA модуля 140 декодирования команды I/O. Во время действия 5.9, встроенное программное обеспечение 543 виртуализации SATA передает команду АТА в контроллер 170 I/O, для разблокирования устройства 180 сохранения SATA. Во время действия 5.10, контроллер 170 I/O использует команду АТА для разблокирования устройства 180 сохранения SATA. Как описано выше, если устройство 180 сохранения SATA было зашифровано с использованием механизма 150 шифрования, встроенное программное обеспечение безопасности/ключа администрирования/сервер 537 Kerberos могут работать совместно со встроенным программным обеспечением администрирования идентичности/клиентом 539 Kerberos для использования метки разблокирования пользователя, содержащейся в поле расширения билета Kerberos, для вывода ключа обертывания пользователя. Ключ обертывания пользователя может использоваться для доступа к ключу обертывания пользователя и ключу шифрования устройства из устройства 180 сохранения SATA.

Действия 5.11 и 5.12 описывают действия, предпринимаемые, если устройство 180 сохранения SATA, подключаемое без перезагрузки, зашифровано с использованием механизма 150 шифрования. Если устройство сохранения SATA, подключаемое без перезагрузки, не зашифровано механизмом 150 шифрования, этапы 5.11 и 5.12 могут быть пропущены. Если устройство 180 сохранения SATA, подключаемое без перезагрузки, зашифровано с использованием механизма 150 шифрования набора микросхем/защищенного раздела 120, в ходе действия 5.11, клиент 539А Kerberos может запросить встроенное программное обеспечение 537 запроса безопасности//администрирования ключом, обеспечить дешифрование устройства для устройства 180 сохранения SATA, подключаемого без перезагрузки. Учетные данные пользователя могут использоваться для получения ключа шифрования устройства, как описано выше со ссылкой на фиг.2. Во время действия 5.12, ключ 184 шифрования устройства предоставляют в механизм 150 шифрования. Как описано выше, ключ шифрования устройства может быть записан в регистр keyslot механизма 150 шифрования и может использоваться механизмом 150 шифрования для дешифрования блоков устройства 180 сохранения SATA, подключаемого без перезагрузки. Если устройство 180 сохранения SATA, подключаемое без перезагрузки, также защищено паролем АТА, этапы, описанные выше со ссылкой на действия 5.7-5.10, для разблокирования устройства 180 сохранения SATA, используют для разблокирования устройства перед тем, как будет предоставлен доступ к ключу шифрования устройства, сохраненному в устройстве.

Во время действия 5.13, клиент 539А Kerberos уведомляет встроенное программное обеспечение 545 виртуализации подключения без перезагрузки о том, что доступ к устройству 180 сохранения SATA был одобрен. Как описано со ссылкой на действия 5.7 -5.10, если устройство 180 сохранения SATA было заблокировано с использованием пароля АТА, устройство будет разблокировано. Как описано со ссылкой на действия 5.11 и 5.12, если устройство было зашифровано с помощью механизма 150 шифрования, дешифрование будет разрешено. Во время действия 5.14, встроенное программное обеспечение 545 виртуализации подключения без перезагрузки передает событие подключения без перезагрузки в основную операционную систему 115. Основная операционная система 115 затем получает доступ к разблокированным и дешифрованным данным из устройства 180 сохранения SATA. В ответ на прием события подключения без перезагрузки, основная операционная система 115 может вызвать файловую систему для монтажа устройства 180 сохранения SATA и/или внедрение устройства 180 сохранения SATA в массив RAID.

В системах, описанных выше со ссылкой на фиг.1-5В, шифрование устройств сохранения выполняют в пределах набора микросхем/защищенного раздела 120 с помощью механизма 150 шифрования. Кроме того, системы, описанные выше со ссылкой на фиг.1-5В, обеспечивают функцию шифрования и администрирования защищенного устройства в пределах защищенного раздела системы, который изолирован от основной операционной системы. Например, механизм 150 шифрования расположен в пределах набора микросхем/защищенного раздела 120, менеджер 235 защищенного устройства по фиг.2 расположен в механизме 130 управляемости (ME) в пределах набора микросхем/защищенного раздела 120, и встроенное программное обеспечение 543 виртуализации SATA и встроенное программное обеспечение 545 виртуализации подключения без перезагрузки по фиг.5 В расположены в пределах модуля 140 декодирования команды I/O набора микросхем/защищенного раздела 120.

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

На фиг.6 показаны дополнительные детали системы по фиг.1 в устройствах, защищенных администрированием, в соответствии с одним вариантом осуществления изобретения. Ядро 631 механизма управляемости, общие услуги 633 механизма управляемости, менеджер 635 защищенного устройства, встроенное программное обеспечение 637 безопасности//администрирования ключом, и встроенное программное обеспечение 639 администрирования идентичности работают, как описано со ссылкой на аналогичные компоненты, показанные на фиг.2 и 5А.

В варианте осуществления, показанном на фиг.6, механизм 130 управляемости (ME) включает в себя подсистему 638 аудита механизма управляемости, и модуль 140 декодирования команды I/O включает в себя подсистему 648 аудита модуля I/O. Подсистема 638 аудита механизма управляемости и подсистема 648 аудита модуля I/O идентифицируют и обрабатывают подвергаемые аудиту действия, которые возникают в их соответствующих компонентах набора микросхем/защищенного раздела 120. Поскольку модуль 140 декодирования команды I/O подготавливает данные для I/O в устройстве сохранения и работает непосредственно с механизмом 150 шифрования для шифрования данных, когда данные записывают в устройства сохранения, подсистема 648 аудита модуля I/O захватывает подвергаемые аудиту события, которые возникают во время I/O. В отличие от этого, механизм 130 управляемости (ME) не вовлечен непосредственно в I/O для устройств сохранения, и, таким образом, подсистема 638 аудита механизма управляемости захватывает подвергаемые аудиту события, относящиеся к администрированию защищенных устройств. Например, подсистема 638 аудита механизма управляемости захватывает события, вовлеченные в системы конфигурирования и установки, для администрирования шифрованием, аутентификации пользователя, инициализации и отказа устройства, ключей шифрования, детектирование кражи и выполнения других политик администрирования платформы предприятия.

Подсистема 638 аудита механизма управляемости и подсистема 648 аудита модуля I/O связываются через интерфейс 131 контроллера механизма управляемости (ME). Подсистема 638 аудита механизма управляемости также может связываться с удаленной услугой 640 администрирования аудитом в пределах консоли 166 администрирования через канал 168передачи данных OOВ, сетевой контроллер 160 и модуль 630 внеполосной передачи данных.

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

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

Инициируемые извне события могут включать в себя включение или выключение услуги защиты от воров; создание, удаление или модификацию учетной записи пользователя; успешную или неудачную регистрацию пользователя при входе/выходе из системы; генерирование или удаление ключа шифрования для различных типов ключей шифрования, таких как ключи шифрования устройства, ключи обертывания устройства и ключи восстановления; устройство, выполненное с возможностью шифрования или дешифрования; преобразование устройства или обратное преобразование устройства в качестве устройства, управляемого для безопасности; конфигурация устройства для PASS_THROUGH; миграция устройства или подготовка к миграции устройства; вставка или изъятие ключа шифрования устройства (DEK) из регистров механизма шифрования; регистрация или удаление регистрации политики события аудита; восстановление метаданных платформы или устройства; пользователь маркера локальной платформы; изменения политики шифрования, такие как изменения силы ключа, обновление ключа или дистанционное конфигурирование политики шифрования; переходы между аутентифицированным и не аутентифицированным шифрованием; операции разблокирования устройства; отказ устройства. Инициируемые изнутри события, подвергаемые аудиту, могут включать в себя неудачную собственную проверку механизма управляемости, модуль декодирования команды I/O, механизм шифрования и/или интерфейсы для защищенного раздела; успешная или не удачная самостоятельная проверка в соответствии с Федеральным стандартом по обработке информации; неудачная инициализация аудита; и/или отказ запоминающего устройства.

Когда детектируется событие подсистемой 638 аудита механизма управляемости или подсистемой 648 аудита модуля I/O, может быть определено, является ли детектируемое событие одним из событий, подвергаемых аудиту, определенных в политике аудита. Если детектируемое событие представляет собой одно из событий, подвергаемых аудиту в политике аудита, событие идентифицируют, как событие, подвергаемое аудиту.

Политика аудита может включать в себя инструкции для обслуживания записей события аудита каждого события, подвергаемого аудиту. Политика аудита может дополнительно устанавливать действия, предпринимаемые, если событие, подвергаемое аудиту, не может быть зарегистрировано. Например, подсистема 638 аудита механизма управляемости или подсистема 648 аудита модуля I/O могут быть выполнены с возможностью остановки, или аннулирования (обратное действие) операции, для которой запись события аудита не может быть записана в журнал регистрации аудита. Кроме того, политика аудита может устанавливать обработку исчерпанных ресурсов журнала регистрации для сохранения аудита, таким образом, что подсистема 638 аудита механизма управляемости или подсистема 648 аудита модуля I/O могут быть выполнены с возможностью перезаписи журнала регистрации аудита или прекращения записи для регистрации события аудита в журнале регистрации аудита.

В одном варианте осуществления каждая из подсистемы 638 аудита механизма управляемости и подсистемы 648 аудита модуля I/O генерирует запись события аудита для идентифицированного события, подвергаемого аудиту. Запись события аудита записывают в журнал регистрации аудита, который изолирован от основной операционной системы. В варианте осуществления, показанном на фиг.6, подсистема 638 аудита механизма управляемости записывает события, подвергаемые аудиту, в журнал 610 регистрации аудита, и подсистема аудита модуля I/O записывает события, подвергаемые аудиту, в журнал 620 регистрации аудита. В одном варианте осуществления журнал 610 регистрации аудита содержится в изолированной области запоминающего устройства памяти флэш, такой, как изолированная область, как область 198 данных запоминающего устройства 190 флэш по фиг.1, и журнал 620 аудита сохранен в изолированной области энергонезависимого запоминающего устройства, такой, как изолированная область устройства 172 сохранения на основе энергонезависимого запоминающего устройства по фиг.1. Поскольку энергонезависимое запоминающее устройство работает быстрее, чем запоминающее устройство флэш, в одном варианте осуществления, записи события аудита вначале записывают в журнал регистрации аудита, сохраняемый в энергонезависимом запоминающем устройстве (журнал 620 регистрации аудита в данном примере), если энергонезависимое запоминающее устройство доступно. Поскольку модуль 140 декодирования команды I/O подготавливает данные для I/O устройств сохранения и работает непосредственно с механизмом 150 шифрования для шифрования данных, по мере того, как данные, записывают в устройство сохранения, подсистема 648 аудита модуля I/O соединяется с более быстрым журналом 620 регистрации аудита, сохраняемым в энергонезависимом запоминающем устройстве, для уменьшения задержки при обработке событий I/O. Поскольку подсистема 638 аудита механизма управляемости не вовлечена непосредственно в I/O, подсистема аудита 638 механизма управляемости записывает регистрационные записи события аудита в более медленный журнал 610 регистрации аудита, сохраняемый в запоминающем устройстве флэш, таком как запоминающее устройство 190 флэш.

Когда журнал 610 регистрации аудита и/или журнал 620 регистрации аудита достигают порогового значения, подсистема 638 аудита механизма управляемости может уведомить удаленную услугу 640 администрирования аудита о необходимости обслуживания журнала регистрации аудита. В одном варианте осуществления, услуга 640 администрирования аудита копирует содержания журналов 610 и 620 регистрации аудита в удаленный накопитель и выполняет сброс порогового значения. Услуга 640 администрирования аудита не прерывает операцию подсистемы 638 аудита механизма управляемости или подсистемы 648 аудита модуля I/O, которые продолжают записывать регистрационные записи события аудита в свои соответствующие журналы 610 и 620 регистрации аудита одновременно с идентификацией событий, подвергаемых аудиту. Когда журнал 620 регистрации аудита достигает порогового значения, подсистема 648 аудита модуля I/O уведомляет подсистему 638 аудита механизма управляемости через MECI 131 таким образом, что подсистема 638 аудита механизма управляемости может передать запрос на обслуживание в услугу 640 администрирования аудита.

В одном варианте осуществления подсистема 638 аудита механизма управляемости работает совместно с услугой 640 администрирования аудита для администрирования всех подсистем аудита, активных в пределах защищенного раздела. Подсистема 638 аудита механизма управляемости может выполнять функции других подсистем аудита, такие как подсистема 648 аудита модуля I/O, когда другая подсистема аудита перегружена и не может обрабатывать события, подвергаемые аудиту. Подсистема 638 аудита механизма управляемости также может обслуживать события журнала регистрации аудита для других подсистем аудита. В одном варианте осуществления подсистема 638 аудита механизма управляемости требует, чтобы другие подсистемы аудита были зарегистрированы. Регистрация используется для уведомления подсистемы 638 аудита механизма управляемости о том, что существует локальный журнал регистрации аудита, такой как журнал 620 регистрации аудита, поддерживаемый другой подсистемой аудита. Регистрация также может использоваться для уведомления подсистемы 638 аудита управляемости о том, могут ли быть раздельные события, подвергаемые аудиту, перенаправлены для обработки, и/или запрашивается ли обслуживание журналов регистрации аудита.

В одном варианте осуществления операциями подсистемы 638 аудита механизма управляемости и подсистемы 648 аудита модуля I/O управляют по привилегиям домена предприятия, используя билеты Kerberos. В одном варианте осуществления событие, подвергаемое аудиту, выполняемое в защищенном разделе системы, идентифицируют, в котором защищенный раздел изолируют от основной операционной системы в системе. Запись события аудита генерируют для события, подвергаемого аудиту, и запись события аудита записывают в журнал регистрации аудита, который изолирован от основной операционной системы. В одном варианте осуществления множество событий, подвергаемых аудиту, определяют в политике аудита, политика аудита содержит инструкции для обслуживания каждого события, подвергаемого аудиту, и среди множества событий, подвергаемых аудиту, и идентификация события, подвергаемому аудиту, содержит определение, является ли детектируемое событие одним из множества событий, подвергаемых аудиту, определенных в политике аудита.

Журнал регистрация аудита может представлять собой первый журнал регистрации аудита среди множества журналов регистрации аудита, доступ к которым осуществляется только в пределах защищенного раздела. Каждый журнал регистрации аудита среди множества журналов регистрации аудита изолирован от основной операционной системы. В одном варианте осуществления определяют, доступен ли первый журнал регистрации аудита. Запись события аудита передают в первую подсистему аудита, ассоциированную с первым журналом регистрации аудита, если первый журнал регистрации аудита является доступным, и первая подсистема аудита выполняет запись регистрационной записи события аудита в первый журнал регистрации аудита. Если первый журнал регистрации аудита не доступен, запись события аудита передают во вторую подсистему аудита, ассоциированную со вторым журналом регистрации аудита, среди множества журналов регистрации аудита, и вторая подсистема аудита выполняет регистрационную запись события аудита во второй журнал регистрации аудита.

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

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

На фиг.7 показана блок-схема последовательности операций способа, выполняемого после детектирования потенциально-подвергаемого аудиту события, возникающего в защищенном разделе системы, в соответствии с одним вариантом осуществления изобретения. После детектирования события, возникающего в защищенном разделе, таком, как набор микросхем/защищенный раздел 120 на этапе 702 "Детектировать событие", управление переходит к точке 704 принятия решения "Подвержено ли событие аудиту?". В точке 704 принятия решения "Подвержено ли событие аудиту?", либо логика, кодированная в аппаратных средствах и/или соответствующая подсистема аудита (либо подсистема 638 аудита механизма управляемости или подсистема 648 аудита модуля I/O), может проверять политику аудита для определения, подвержено ли событие аудиту. В одном варианте осуществления битовая маска аудита используется для активации разных аппаратных компонентов и/или компонентов встроенного программного обеспечения, которые выполнены с возможностью детектировать события, подвергаемые аудиту. Оценка битовой маски аудита в точке 704 принятия решения "Подвержено ли событие аудиту?" определяет, является или нет событие подвергаемым аудиту.

В точке 704 принятия решения "Подвержено ли событие аудиту?", если событие подвержено аудиту, управление переходит на этап 706 "Сгенерировать регистрационную запись события аудита". Регистрационную запись события аудита генерируют с помощью какой-либо из логики, кодированной в аппаратных средствах и/или соответствующей подсистеме аудита (либо в подсистеме 638 аудита механизма управляемости или в подсистеме 648 аудита модуля I/O). После генерирования регистрационной записи события аудита, управление переходит в точку 708 принятия решения "Доступен ли журнал регистрации NVM?". Как отмечалось ранее, если журнал регистрации в энергонезависимом запоминающем устройстве является доступным, предпочтительно записывать запись события аудита в энергонезависимое запоминающее устройство для снижения задержки, связанной с обработкой события. В точке 708 принятия решения "Доступен ли журнал регистрации NVM?", если журнал регистрации NVM доступен, управление переходит к этапу 710 "Передать регистрационную запись события в подсистему аудита модуля I/O". На этапе 710 "Передать регистрационную запись события в подсистему аудита модуля I/O", регистрационную запись события передают в подсистему 648 аудита модуля I/O.

С этапа 710 "Передать регистрационную запись события в подсистему аудита модуля I/O" управление переходит к точке 712 принятия решения "Достигнуто ли пороговое значение?". Примеры достижения порога представляет собой случай, когда степень использования модуля I/O падает ниже нормальных уровней, и/или журнал регистрации аудита становится полным. Когда достигается пороговое значение, управление переходит к этапу 718 "Передать статус порогового значения в подсистему аудита механизма управляемости". Например, когда степень использования модуля I/O падает ниже порогового значения, активность аудита может потребоваться разгрузить для подсистемы 638 аудита механизма управляемости и/или журнал 620 регистрации аудита может потребовать обслуживания. Когда выполняют этап 718 "Передать статус порогового значения в подсистему аудита механизма управляемости", подсистема 638 аудита механизма управляемости выполняет соответствующие действия для администрирования достижения порога в соответствии с политикой аудита. Например, подсистема 638 аудита механизма управляемости может планировать услугу 640 администрирования аудита для обслуживания журнала регистрация и/или копирования журнала регистрации, который достиг порогового значения, в другом архивном накопителе. С этапа 718 "Передать статус порогового значения в подсистему аудита механизма управляемости", управление переходит к этапу 715 "Записать регистрационную запись события в журнал регистрации аудита", где регистрационную запись события аудита, которая привела к достижению порогового значения, записывают в журнал регистрации с помощью подсистемы 638 аудита механизма управляемости.

Из точки 712 принятия решения "Достигнуто ли пороговое значение?", если пороговое значение не было достигнуто, управление переходит на этап 715 "Записать регистрационную запись события в журнал регистрации аудита", где соответствующая подсистема аудита записывает регистрационную запись события аудита в ее соответствующий журнал регистрации. Управление затем переходит на этап 714 "Выполнить событие", где событие выполняют, и обработка события, подвергаемого аудиту, заканчивается.

В точке 708 принятия решения "Доступен ли журнал регистрации NVM?", если журнал регистрации NVM не доступен, управление переходит на этап 716 "Передать запись события в подсистему аудита механизма управляемости". Запись события аудита передают в подсистему 683 аудита механизма управляемости. Подсистема 638 аудита механизма управляемости затем записывает регистрационную запись события в журнал 610 регистрации аудита на этап 715 "Записать регистрационную запись события в журнал регистрации аудита". Управление переходит на этап 714 "Выполнить событие", где событие выполняют, и обработка события, подвергаемому аудиту, заканчивается.

В точке 704 принятия решения "Подвержено ли событие аудиту", если событие не подвержено аудиту, управление переходит к этапу 714 "Выполнить событие". Событие выполняют, и обработка события заканчивается.

Обработка событий, подвергаемых аудиту, может быть выполнена с помощью логических схем, кодированных в виде аппаратных средств и/или с использованием встроенного программного обеспечения. Инициализация компонентов. набора микросхем/защищенного раздела 120, такого, как механизм 130 управляемости (ME), модуль 140 декодирования команды I/O и механизм 150 шифрования представляют собой события, подвергаемые аудиту, которые могут быть кодированы в аппаратных средствах для этих соответствующих компонентов и/или включены во встроенное программное обеспечение для этих соответствующих компонентов. Аналогично, аппаратные средства и/или встроенное программное обеспечение для контроллеров и интерфейсов, таких как HECI 111b, VECI 111с, сетевой контроллер 160, контроллер 175 USB, контроллер 170 I/O, могут включать в себя логическую схему, для обработки событий, подвергаемых аудиту.

Обработка событий аудита может быть выполнена в пределах механизма 130 управляемости (ME) после исходных конфигураций, а также как во время операции компонентов механизма 130 управляемости (ME), например, во время операции встроенного программного обеспечения 237 безопасности/администрирования ключом по фиг.2. Например, события аудита могут быть инициированы, когда встроенное программное обеспечение 237 безопасности/администрирования ключом записывает ключ шифрования устройства (DEK) в соответствующий регистр механизма 150 шифрования, когда устройство сохранения должно быть зашифровано, или удаляет DEK из соответствующего регистра механизма 150 шифрования, когда шифрование отключено.

Обработка событий аудита также может быть выполнена, когда данные передают в форме открытого текста из контроллера 170 I/O в механизм 150 шифрования (для операции записи) и, когда данные возвращаются в механизм 150 шифрования в форме зашифрованного текста. События, повергаемые аудиту, возникающие через канал между контроллером 170 I/O и механизмом 150 шифрования, обеспечивает доказательство того, что данные шифруют, хотя политика аудита может ограничить аудит этих событий до периодического тестирования соответствия.

Обработка событий аудита может быть выполнена в интерфейсе 131 контроллера механизма управляемости (MECI), поскольку координация между подсистемами аудита может быть передана через MECI 131. Исходная конфигурация модуля 140 декодирования команды I/O также выполняется через MECI 131 и будет генерировать события, подвергаемые аудиту.

Обработка событий аудита может быть сгенерирована путем передачи данных из процессора 110 через интерфейсы HECI 111b и VECI 111 с.Например, команды безопасности АТА, которые относятся к состоянию блокирования устройства, производят события, подвергаемые аудиту, так же, как и команды, которые распространяются через эти интерфейсы в контроллер 170 I/O или в контроллер 175 USB. Кроме того, команды HECI, относящиеся к аутентификации пользователя, шифрованию, безопасности, администрированию ключом и статусу, представляют собой события, подвергаемые аудиту. Команды, используемые для инициализации контроллеров, таких как контроллер 170 I/O, контроллер 175 USB, и сетевой контроллер 160 также являются событиями, подвергаемыми аудиту. Команды сохранения журнала регистрации аудита и команды конфигурации также подвержены аудиту, и представляют собой обмен данных подсистем аудита с удаленной услугой 640 администрирования аудита по фиг.6. Подключение устройства к платформе 100 через контроллер 175 USB и/или контроллер 170 I/O, представляет собой событие, подвергаемое аудиту.

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

На фиг.8 показана среда виртуального устройства для воплощения защищенного раздела для действий администрирования, таких как схемы защиты устройств, используя шифрование, аутентификацию идентичности пользователя и защиту паролем, в соответствии с одним вариантом осуществления изобретения. Если платформа 800 является виртуализированной, она может включать в себя только один процессор, но монитор виртуального устройства ("VMM 830") в хост устройстве может представлять множество абстракций и/или видов хост устройства, таким образом, что лежащие в его основе аппаратные средства хост устройства выглядят, как одно или больше независимо работающих виртуальных устройств ("VM"). VMM 830 может быть воплощено в программных средствах (например, как раздельная программа и/или компонент основной операционной системы), аппаратные средства, встроенное программное обеспечение и/или любая их комбинация. VMM 830 администрирует выделением ресурсов хост устройства и выполняет переключение контекста, в соответствии с необходимостью, для циклической обработки между различными VM, в соответствии с карусельной или другой заданной схемой. Для специалистов в данной области техники будет понятно, что, хотя здесь представлен только один процессор ("Процессор 805"), варианты осуществления настоящего изобретения не ограничены этим, и множество процессоров также можно использовать в пределах виртуализированной среды.

Хотя только два VM раздела представлены ("VM 810" и "VM 820", здесь называемые совместно, как "VM"), эти VM представляют собой только иллюстрацию и дополнительные виртуальные устройства могут быть добавлены к хост устройству. VM 810 и VM 820 могут функционировать, как самостоятельные платформы, соответственно, работающие в своих собственных "гостевых операционных системах" (то есть, в операционных системах, работающих на основе хост устройства VMM 830, представленных как "гостевая OS 811" и "гостевая OS 821" и ниже называемые совместно, как "гостевая OS") и другое программное обеспечение (представлено, как "гостевое программное обеспечение 812" и "гостевое программное обеспечение 822", и ниже называемое совместно "гостевым программным обеспечением").

Каждая гостевая OS и/или гостевое программное обеспечение работают так, как если бы оно работало в специализированном компьютере, а не в виртуальном устройстве. Таким образом, каждая гостевая OS и/или гостевое программное обеспечение, можно ожидать, будет управлять различными событиями и будет иметь доступ к аппаратным ресурсам на платформе 800. В пределах каждого VM гостевая OS и/или гостевое программное обеспечение могут вести себя, как если бы они в действительности работали в физических аппаратных средствах платформы 800 ("Хост аппаратные средства 840", которые могут включать в себя сетевой контроллер 860).

Для специалистов в данной области техники будет понятно, что физическое разделение аппаратных средств со специализированным процессором, таким как механизм 130 управляемости (ME) на фиг.1, может обеспечить более высокий уровень безопасности, чем виртуализированный раздел (как показано на фиг.8), но варианты осуществления изобретения могут выполняться на практике в любой окружающей среде и/или в комбинации этих окружающих сред для обеспечения изменяющихся уровней безопасности. Как также будет понятно для специалиста в данной области техники, платформы ME, AMT или PRL могут быть воплощены без виртуализированной окружающей среды. Например, VM 820 может быть специализирована, как раздел ME в хост устройстве, в то время как VM 810 обеспечивает работу типичных приложений в хост устройстве. В таком сценарии хост устройство может включать в себя или может не включать в себя множество процессоров. Если хост устройство действительно включает в себя два процессора, например, VM 820 может быть назначено другому процессору, в то время как VM 810 (и другие VM в хост устройстве) могут совместно использовать ресурсы процессора 805. С другой стороны, если хост устройство включает в себя только один процессор, этот процессор может обслуживать оба VM, но VM 820 при этом все еще будет изолировано от других VM в хост устройстве при взаимодействии с VMM 830. С целью упрощения, варианты осуществления настоящего изобретения описаны в среде механизма управляемости (ME), но варианты осуществления настоящего изобретения не ограничены этим. Вместо этого, любые ссылки на механизм управляемости, ME, "раздел", "защищенный раздел", "раздел безопасности" и/или "раздел администрирования" должны включать в себя любой физический и/или виртуальный раздел (как описано выше).

После запуска или когда новое устройство подключают без перезагрузки к платформе, VMM 830 назначает устройство VM 810 или 820. Для выполнения аудита в пределах набора микросхем/защищенного раздела 120 в виртуализированной среде, такой, как описано со ссылкой на фиг.8, VMM 830 администрирует профиль маски аудита для каждого VM 810 и 820. Когда устройство назначают либо VM 810, или 820, соответствующий профиль аудита маски для VM ассоциируют с набором микросхем/защищенным разделом 120. Каждый раз, когда профиль маски аудита VM, ассоциированный с набором микросхем/защищенным разделом 120, изменяется, VMM 830 генерирует запись события аудита. Таким образом, VM 810 или 820, которое инициирует событие, подвергаемое аудиту, представляет регистрационные записи события аудита. Например, VM 810 или 820, которое вырабатывает команды I/O сохранения в устройство, идентифицируются в регистрационных записях события аудита.

Если устройство подключают без перезагрузки к платформе, VM 810 или 820, которое приняло назначение устройства, идентифицируют в регистрационной записи события аудита. Когда детектируют событие подключения без перезагрузки, модулю 140 декодирования команды I/O может потребоваться определить, является ли VM 810 или 820, в данное время ассоциированное с набором микросхем/защищенным разделом 120, авторизованным для приема назначения устройства. До тех пор, пока устройство не будет назначено и до тех пор, пока не будет определен правильный профиль маски аудита, который должен быть назначен для набора микросхем/защищенного раздела 120, внутренний профиль маски аудита может использоваться для событий аудита после события подключения без перезагрузки, до тех пор, пока не возникнет назначение устройства.

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

VMM 830 обеспечивает то, что переходные среды VM не приведут к неавторизованному назначению приводов. В одном варианте осуществления VMM 830 генерирует GUID (глобально уникальный ID) для каждого VM 810 и 820. GUID используется для разделения метаданных в запоминающем устройстве 190 флэш.

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

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

Такие машиночитаемые носители могут включать в себя, без ограничений, физические компоновки частиц, изготовляемых или формуемых устройством, включающие в себя носители сохранения информации, такие как жесткие диски, диск любого другого типа, включающие в себя гибкие диски, оптические диски, постоянное запоминающее устройство на компакт-дисках (CD-ROM), перезаписываемые компакт-диски (CD-RW) и магнитооптические диски, полупроводниковые устройства, такие как постоянные запоминающие устройства (ROM), оперативные запоминающие устройства (RAM), такие как динамические оперативные запоминающие устройства (DRAM), статические оперативные запоминающие устройства (SRAM), стираемые программируемые постоянные запоминающие устройства (EPROM), программируемые запоминающие устройства флэш (FLASH), электрически стираемые программируемые постоянные запоминающие устройства (EEPROM), магнитные или оптические карты, или любого другого типа носители информации, пригодные для сохранения электронных инструкций.

Выходная информация может применяться для одного или больше выходных устройств, известным образом. Для назначения данной заявки система обработки включает в себя любую систему, которая имеет процессор, такой как, например; цифровой сигнальный процессор (DSP), микроконтроллер, специализированная интегральная схема (ASIC), или микропроцессор.

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

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

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

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

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

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

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

6. Способ по п.1, в котором
выполняют разблокирование зашифрованного устройства при неисправной работе основной операционной системы в системе.

7. Способ по п.1, в котором
выполняют разблокирование зашифрованного устройства без привлечения пользователя системы.

8. Способ по п.1, в котором запрос содержит указанный маркер.

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

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

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

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

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

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

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

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

17. Способ по п.15, в котором
на этапе предоставления доступа к новому устройству используют собственную команду устройства для обеспечения дешифрования нового устройства.

18. Способ по п.15, в котором
вторые учетные данные содержат пароль для нового устройства; и
на этапе предоставления доступа к новому устройству используют пароль для разблокирования нового устройства.

19. Способ по п.15, в котором
вторые учетные данные содержат идентификатор пользователя; и
на этапе предоставления доступа к новому устройству предоставляют идентификатор пользователя доверяемой третьей стороне и предоставляют доступ к новому устройству в случае аутентификации доверяемой третьей стороной идентификатора пользователя.

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

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