AMT3 - Remote Configuration и сертификаты

Статья "AMT3 - Remote Configuration и сертификаты" из серии "Учебник по Intel AMT", часть восьмая.

Есть у революции начало…

Революционное появление AMT1 как таковой, такое же революционное появление AMT2 с переездом ME-процессора в северный мост и переходом на защищённую схему инициализации (в первой версии это была неприятная дырка - она проходила по HTTP, а не HTTPS), добавлением WiFi в 2.5 - логично требовало продолжения буйства инженерной мысли. И оно продолжилось. Накопив впечатлений от геморроя развёртывания систем с помощью One Touch (представьте счастливого админа сотен компов, который их "вантачит"), стало очевидно, что хоть и простая-понятная, а потому "рабоче-крестьянская" версия с PID/PPS — не годится для реальной автоматизации. Была поставлена задача уменьшить количество "касаний" ещё на одно, т.е. до нуля. Так появились Zero Touch и Remote Configuration, которые и были представлены в 2007-м году с выходом чипсетов Intel Series 3 (Q35) и третьей версии AMT (впоследствии частично подобное появилось в виде обновлений AMT 2.2. и AMT 2.6 соответственно). Разберём всё подробней.

Remote Configuration

Чем был хорош PID/PPS? Тем, что в таком способе всё очевидно, просто и понятно. Однако при практическом применении очень быстро стала очевидна неудобность — ведь по-любому в MEBx должны как-то попасть пары ключей PID/PPS. Да, некоторые производители на свои компьютеры их предустанавливали, однако, всё равно, это было не так удобно (ведь списки предустановленных тоже как-то должны быть куда-то введены). Кроме того был вопрос последующей переинициализации в случае проблем.

В общем, нужно было придумывать что-то серьёзное, надёжное и "долговечное" — и это было сделано. Была добавлена "инициализация по сертификатам", она же Remote Configuration. Она же Zero Touch, т.к. в идеале админу не нужно было ничего нажимать (в идеале, правда, ничего, но - в идеале :) ).

Сертификаты

Не обладая хотя бы базовыми знаниями основ шифрования HTTPS/SSL/TLS - без шансов разобраться в теме AMT. Но разводить излишнее теоретизирование тоже смысла нет (а кому реально нужно в подробностях -  в интернете материалов предостаточно). Потому далее буду стараться излагать упрощённо, постепенно втягиваясь в "теорию".

Итак, сертификаты обычно используются для шифрования канала связи между клиентом и сервером. Например, самый привычный вариант - когда вы заходите на Google.com или Яндекс.Почта (где ваш браузер выступает в роли клиента, а сайт - сервера) — вы автоматически соединяетесь с ними по шифрованному каналу (видя характерный замок на соединении в вашем браузере).

https mail.yandex.ru

В реальности происходят следующие процессы. Вы отправляете запрос на сервер (google.com или mail.yandex.ru) по HTTP - это нешифрованный канал. Гуглояндексы из-за нежелания делиться ни с кем полученной от вас информацией, перекидывают запрос на их HTTPS-адрес (или вы сразу на него попадаете, если закладку сделали недавно). Итак, клиент-браузер отправляет запрос к HTTPS-серверу Яндекса на соединение. Тот в ответ вам, как клиенту (точней - браузеру), отправляет его (сервера) сертификат, предлагая с помощью оного осуществить шифрование канала. Получив данный сертификат, клиент (браузер или ОС - зависит от браузера) решает, "доверяет" он этому сертификату или нет. Для этого он проверяет кем выдан сертификат, когда, на сколько и т.п. (например,  не просрочен ли он). Если находит, что он валиден и выдан "доверенной организацией" (а некоторый список сертификатов этих доверенных организаций предустановлен в любой ОС - и Windows и Linux; либо в некоторых браузерах - например, старая Опера использует своё, независимое от ОС хранилище сертификатов) и что текущее соединение (т.е. по-простому - адресная строка) совпадает с "именем сертификата" (CN - Common Name), то "соглашается" и происходит соединение по HTTPS (шифрованное, "условно" - данным сертификатом).

certificate mail.yandex.ru

Однако кроме этого сертификаты могут использоваться и для авторизации - в таком случае в начале соединения вы (как клиент) представляете серверу свой сертификат и если он подписан тем, кому уже сервер "доверяет" - соединение устанавливается, иначе получаете "отлуп". Таким образом имеем вариант "клиентской авторизации" (когда сервер проверяет клиента). А предыдущий пример с Яндекс.Почта, соответственно, является "серверной авторизацией" (когда клиент проверяет сервер).

Вышеприведенная картинку про серверную авторизация (та привычная, что в интернете - HTTPS): можно ещё раз расписать следующей последовательностью:

1. Браузер отправляет запрос на сервер (mail.yandex.ru) и получает от него сертификат.
2. Браузер проверяет сертификат на валидность:

  • текущая дата попадает в диапазон 18.04.2014-25.12.2016? Если нет (в т.ч. "она ещё не наступила") - сертификат не валиден.
  • сертификат организации KEYNETICS - той, кто выдал (подписал) данный сертификат Яндексу - имеется ли у нас такой среди доверенных (в хранилище ОС или "локально" браузера - зависит от него, пользуется ли он своим "локальным", либо использует хранилище сертификатов операционной системы)? Если таковой среди доверенных есть - значит мы доверяем и тому, кого он подписал (кому выдал), т.е. данному сертфикату Яндекса
  • итак, сертификат точно валиден, однако тот ли он, за кого себя выдаёт, т.е. по правильному ли он адресу расположился? Для этого браузер сравнивает адрес, куда он отправлял запрос (п.1) с полем CN ("Общее имя"), что извлекает из полученного сертификата. Совпадают? Значит "сервер авторизован".
  • иначе - грозное предупреждение на экране, что "сертификат просрочен" либо "сервер выдаёт себя за другого" и т.п. сообщения об ошибке при работе HTTPS.

Аналогичная (только с точностью до наоборот) ситуация происходит при "клиентской авторизации" - тут уже сервер проверяет присланный клиентом сертификат и если всё нормально - соединяется с ним по шифрованному каналу.
Оба варианта используются в АМТ - и по отдельности и сразу (когда и клиент и сервер взаимно авторизуются).

Certificate Hash

Не увлекаясь многочисленными тонкостями реализации различных алгоритмов хэширования, лишь остановимся на хэше сертификата — как его условной "контрольной сумме", правда с поправкой на то, что она строго уникальна для каждого сертификата (даже выданного на один и тот же адрес - прямо вот в одно время). Эта контрольная сумма - хэш - "отпечаток" — удобна своей небольшой фиксированной длинной. С её помощью удобно сравнивать сертификаты, да и хранить можно не сами сертификаты (порядка двух килобайт каждый), а лишь их хэши (20 байт). Например, в приведённом выше примере сертификата Яндекса

Отпечаток SHA1 — 16:66:68:B7:6F:E3:E3:F5:C2:02:BA:80:11:B9:D6:41:39:71:BF:0B

Примечание: Алгоритм MD5 для сертификатов в АМТ не используется как уязвимый.

Теперь, просто зная хэш, в HEX это 166668B76FE3E3F5C202BA8011B9D6413971BF0B, и имея программную возможность его посчитать у любого полученного сертификата, нам для того, чтобы убедиться в "трастовости" ("доверенности"), достаточно лишь посчитать хэш и сравнить его с сохранённым.

Центры сертификации

Право выдавать сертификаты, признаваемое подавляющим большинством ОС/браузеров/пользователей/устройств, имеет ограниченное количество "центров сертификации" - Certificate Authority (CA). Например, в вышеприведенном случае Яндекса видно, что сертификат ему был выдан от "CLASS 2 KEYNETICS CA".

Keynectis CA mail.yandex.ru

Проверить такую связь ("выдан") можно просто посмотрев поля "Кем выдано" в сертификате Яндекс.Почты и после проверив "Кому выдано уже в сертификате KEYNETICS. Последний сертификат является "корневым" - он выдан "от себя самого" (или "самоподписанный").

Class 2 Primary CA

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

Итого: главным для нас является наличие в доверенных "корневых сертификатов" - основных центров сертификации, которые выдают сертификаты, признаваемые нами уже по цепочке, которую можно проследить при проверке.

Хэши корневых сертификатов и АМТ-инициализация

Именно так и поступили, когда разрабатывали схему "Remote Configuration" - "внутрь" МЕ зашили несколько хэшей корневых сертификатов, которые имеют право выдавать сертификаты для AMT-инициализации.

Certificate Hashes

Соответственно, в процессе инициализации удалённый сервер присылает АМТ-компьютеру свой сертификат, полученный от такого центра и сам корневой сертификат (данного СА - центра сертификации).

provisionserver.vpro.by certificate

МЕ-процессор получает проверяет валидность предоставленного сертификата, наличия в нём свойства, позволяющего инициализировать AMT (на картинке указано стрелочкой), его связь с корневым, далее считает хэш корневого сертификата и если он находится среди своего набора "трастовых хэшей" - разрешает "проинициализировать себя" (т.е. принимает от сервера дальнейшие команды и конфигурационные данные).

Check Certificate Hash

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

В результате такой схемы - Remote Configuration - нам уже не нужно ничего вводить в МЕВх, т.е. серьёзно улучшается автоматизация инициализации AMT. Правда при этом повышается и сложность, да и стоимость - всё же получение подобного vPro-сертификата таки не самое дешёвое и очевидное действо. В последующих частях будут раскрыты подробности данного процесса, в этой же части резюмируем появившуюся в AMT3/2.6/2.2 фичу под названием Remote Configuration, которая впоследствии стала основным способом инициализации AMT:

  • Ходить в MEBx (в идеале) не нужно вообще - большой плюс в копилку автоматизации.
  • Унификация на уровне производителя - хэши корневых сертификатов прошиваются изначально, а потому и могут быть обновлены с выходом новой прошивки (что обычно и происходит с применением апдейта)
  • Безопасность самого процесса инициализации АМТ (через сертификаты) повысилась практически до максимума
  • Возросла стоимость и сложность

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступные HTML теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.
Anti-bot.