В течение тысячелетий люди использовали различные методы для сокрытия передаваемой информации, а также проверки отправителя и сообщения. По мере развития цивилизации был создан и получает теперь широкое распространение единый метод для выполнения всех этих трех задач. Протокол
S/MIME – это система безопасной отправки электронной почты с использованием шифрования и цифровых подписей.
Текущие технологии шифрования (закрытия) делятся на два основных типа: алгоритмы с симметричными (секретными) ключами, такие как стандарт DES или AES, и алгоритмы с асимметричными (открытыми/закрытыми) ключами, такие как RSA или ECC. Современные средства проверки отправителя – это математические односторонние функции, именуемые хэш-кодами, которые создают уникальные подписи. Два часто используемых метода хэширования - это алгоритмы MD5 и SHA. Компьютеры могут использовать их для создания уникального хэш-кода или номера, соответствующего индивидуальному исходному тексту (идентичные исходные тексты имеют одно значение хэш-кода). Эти простые средства используются и сочетаются для создания инфраструктуры открытого ключа (PKI).
Проверяемое удостоверение
Удостоверения внутри системы PKI управляются с использованием цифровых сертификатов, которые не сильно отличаются от выданных государством удостоверений личности, которые большинство людей переносят через международные границы, – паспортов. Стандарт паспортов в мире цифровых сертификатов – это формат X.509, который широко используется для подписывания и шифрования в таких технологиях как S/MIME, IPsec, SSH, а также в безопасности беспроводных сетей, виртуальных частных сетях (VPN) и даже в безопасных сообщениях сервера (таких как веб-узлы SSL).
Сертификаты строятся на основе асимметричной криптографии и хэш-кодов. Для создания сертификата запрашивающий (тот, кому нужен ключ, подписанный более высоким центром сертификации), создает секретный ключ. Ключ держится запертым, чтобы его подлинность не подвергалась сомнению. Вместе с секретным ключом создается соответствующий открытый ключ. Как и предполагает его имя, открытая часть пары не секретна и свободно распространяется, хотя все же таким способом, который гарантирует ее подлинность.
Эта пара ключей делает возможной две основные операции. Во-первых, кто угодно может использовать открытый ключ для шифрования чего-либо, что может расшифровать только секретный ключ; во-вторых, открытый ключ можно использовать для расшифровки зашифрованного секретным ключом. Это имеет значение при проверке подписи, которую мог создать только секретный ключ.
Запрос к центру сертификации включает такие подробности, как то, какому лицу или компьютеру предназначается ключ, тип и надежность алгоритма, а также открытую часть пары ключей. Центр сертификации (CA) получает и проверяет информацию в запросе, после чего, используя алгоритм хэширования, создает уникальный идентификатор, соответствующий информации.
Используя свой закрытый ключ, центр сертификации шифрует хэш-код информации и собирает его в стандартный формат (такой как X.509), создавая сертификат, соответствующий первоначальному запросу. Сертификат X.509 будет содержать список заявок, включая удостоверение сертификата (субъект), период действительности, открытый ключ и операции, для которых может быть использован сертификат. После этого сертификат возвращается запрашивающему; это маркер, который по сути заявляет: «Я, центр сертификации (CA), ручаюсь за этот открытый ключ и секретную часть, соответствующую ему, для всех описанных здесь способов использования».
У корневых центров сертификации (находящихся на наивысшем уровне цепи доверия) сертификаты самоподписанные. Большинство приемлемых корневых центров сертификации поставляются встроенными в базовую операционную систему или приложение, но могут быть обновлены или изменены через пакеты либо корпоративную настройку. Между корневым центром сертификации и оконечным узлом дерева (который обычно описывает отдельную личность или систему) могут находиться один или несколько корневых центров сертификации.
Цепь состоит из всех узлов и всех предшествующих сертификатов, внедренных в них, подписанных центром сертификации на этом уровне. Стороннее лицо, пытающееся проверить сертификат, может сверить локально вычисляемый хэш-код с дешифрованным из самого сертификата, используя сопровождающий общий ключ для данного конкретного центра сертификации или личности. Таким образом и создается полностью проверенная цепь от корня к оконечному узлу дерева – предполагая, само собой, что корень пользуется доверием.
Обновление состояния сертификата
У каждого хорошего центра сертификации имеются способы распространения списка сертификатов, которым больше не следует доверять. Этот список отзыва сертификатов (CRL) описывает, какие выпущенные элементы центр сертификации прямо сделал недействительными. Что удобно, местоположение списка отзыва сертификатов обычно является свойством сертификата центра сертификации.
Центры сертификации регулярно выпускают списки отзыва сертификатов на двух основаниях: по расписанию (скажем, каждые две недели) или в случае событий (происшествий, указывающих, что выпущенный сертификат более не заслуживает доверия). Центр сертификации подписывает выпущенные списки отзыва сертификатов при их публикации. Когда получающая система оценивает действительность цепи, она обычно пытается получить список отзыва сертификатов для каждого выпускающего центра сертификации в цепи (через подробности, внедренные в сами сертификаты, или через некий заранее определенный доверенный механизм распределения). Если какой-то из список отзыва сертификатов недоступен, клиент может прибегнуть к недавней, успешно кэшированной копии, пока она не старше указанного периода обновления списка отзыва сертификатов. Но если и это уже невозможно, клиентские системы обычно демонстрируют какую-либо ошибку, указывая, что сертификат является допустимым, но состояние отмены невозможно определить.
Многие приложения тратят гораздо больше времени на загрузку сертификата, если они не могут проверить цепь или список отзыва сертификатов для каждого узла в цепи. В зависимости от того, что защищал сертификат, пользователь может пожелать или не пожелать доверять ему. Регулярно обновляемая, широко доступная точка распространения списков отзыва сертификатов совершенно необходима для каждого центра сертификации, а особенно для общедоступных корней.
Корни являются основанием цепи сертификатов, а на соединении в цепи основаны все иерархии сертификатов. Большинство клиентских систем и приложений предполагают, что сертификат оконечного узла дерева допустим, только если от него ведет цепь к доверенному корню. Это может быть корпоративный центра сертификации, находящийся во владении и под управлением данной конкретной компании, либо общедоступный корневой центр сертификации (такой как VeriSign).
Считается, что общедоступные корневые центры сертификации эксплуатируются строго надлежащим образом, позволяющим гарантировать целостность. Компании должны стремиться к такому же уровню в своих внутренних организациях, поскольку неприкосновенность корневых центров сертификации настолько же важна в этом контексте. Для оптимальной защиты корневые центры сертификации следует держать отключенными от сети, используя только для выдачи сертификатов и обновления списков отзывов о сертификатов. Дополнительную информацию по лучшим методам эксплуатации центра сертификации можно найти в статьях, перечисленных на врезке «Материалы по центрам сертификации».
Одним из важных аспектов, о которых следует подумать, является восстановление ключа. Чтобы поспособствовать расследованиям и гарантировать, что данные не будут невозвратимо заперты пользователем, компании следует создавать резервные копии всех выпущенных пользователями ключей. Вдобавок, эти резервные копии следует хранить в безопасном хранилище. Это позволяет при утрате ключа пользователя (скажем, если смарт-карта забыта в такси) сохранить доступ к любому содержимому, защищенному ключом.
Наконец, в каждую хорошую криптографическую систему входит концепция управления жизненным циклом. Чем компьютеры быстрее, тем менее стойки алгоритмы. Любой хорошей криптосистеме необходима способность обновлять себя и переходить на новые алгоритмы и размеры ключей с течением времени. Центры сертификации следует обновлять соответствующим образом, когда определяются криптографические нестойкости и определенные функции вводятся в эксплуатацию или выводятся из нее.
Реализация S/MIME
Начальная загрузка, составление, отправка и получение подписанных или зашифрованных сообщений электронной почты с использованием S/MIME состоит из нескольких стадий. Мы осветим подробности, проблемы и потенциальные решения по мере разбора типичного случая использования S/MIME: двух пользователей, отправляющих подписанные и/или зашифрованные сообщения друг другу из двух различных лесов Active Directory® и различных цепей центров сертификации (то есть из операционно различных объектов независимо от того, находятся они внутри одной компании или нет), используя Microsoft® Office Outlook® 2007.
Мы предположим, что уже существует необходимая инфраструктура, допускающая операции, которые мы опишем. В нашем случае мы используем интегрированный с Active Directory корпоративный сервер сертификации.
Получение сертификатов
Первая задача – это получить соответствующие сертификаты. Чтобы сделать это, откройте консоль управления MMC диспетчера сертификатов (certmgr.msc), щелкните правой кнопкой мыши папку Personal («Личные»), выберите All Tasks («Все задачи») во всплывающем списке и выберите Request New («Запросить новый») из списка.
В результате запустится мастер установки сертификатов, как показано на рис. 1. По умолчанию будут показаны несколько предназначенных для компаний вариантов, важен из них User certificate («Сертификат пользователя»). Позже он будет использован, чтобы сделать возможными процессы подписывания и шифрования. Сертификат должен быть пригоден для следующего.
Рис. 1 Запрос сертификата
- Цифровых подписей (создания сообщений с печатью подлинности от их создателя)
- Криптографической защиты ключа (защиты одного ключа другим для таких технологий, как шифрующая файловая система)
- Безопасного обмена электронной почтой (зашифрованных сообщений, которые могут быть прочтены только их предполагаемым получателем, владеющим соответствующим секретным ключом)
Для отправки подписанной S/MIME электронной почты свойства криптографической защиты ключа не требуется. Но для отправки или получения зашифрованной почты это свойство необходимо, тогда как свойство подписи – нет. По умолчанию, шаблоны в службе сертификатов Windows® включают эти три свойства. Если пользователю не разрешено запрашивать новые сертификаты, они не будут показываться при запуске мастера. Если корпоративный центр сертификации недоступен, пользователю будет представлена «ошибка установки», указывающая, что с доменом или с центром сертификации невозможно связаться. Для целей этого руководства мы предположим, что один сертификат допускает и подпись, и криптографическую защиту.
Обмен сертификатами
Простейшим способом начать обмен зашифрованными сообщениями электронной почты между двумя пользователями является отправка друг другу подписанных сообщений. После составления сообщения пользователь нажимает кнопку «Подписать». (Порой кнопка скрыта по умолчанию в Outlook, пока ее не использовали хоть раз. Ее можно найти, выбрав «Параметры для новых сообщений», затем нажав кнопку «Параметры безопасности» и установив флажок «Добавить цифровую подпись к этому сообщению» в диалоговом окне свойств безопасности.) Кнопка подписывания (маленький желтый конверт с красной лентой на нем с надписью «Подписать») добавляет цифровую подпись к сообщению, чтобы установить подлинность его источника.
При нажатии кнопки «Отправить» от пользователя могут быть запрошено предоставление дополнительных маркеров владения ключом, такое как вставление смарт-карты или ввод ПИН-кода. Это зависит от конкретных методов защиты ключа, используемых организацией.
Пользователю, получающему подписанное с помощью S/MIME сообщение электронной почты, потребуется просмотреть и щелкнуть правой кнопкой мыши имя отправителя (после «От:») и выбрать «Добавить к контактам Outlook» из контекстного меню, которое либо добавляет новую запись контакта, либо обновляет существующую. После этого сертификат связывается с данной конкретной записью контакта. Обратите внимание, что в обычной среде Active Directory (два пользователя в одном лесу или компании) распространение открытых сертификатов пользователя выполняется автоматически через атрибуты в объекте пользователя в Active Directory.
Другой способ обмена сертификатами – отправить друг другу свой(-и) сертификат(-ы) S/MIME в качестве вложений. Чтобы сделать это, сертификаты нужно экспортировать в файлы CER. Пользователям потребуется просмотреть сертификат и выполнить процедуру экспорта, о которой мы скоро расскажем, постаравшись при этом не экспортировать заодно секретный ключ, как показано на рис. 2.
Рис. 2 При обмене сертификатами не экспортируйте секретный ключ
Каждый получатель затем вручную создает запись контакта в Outlook и добавляет сертификат к записи отправителя. После того, как двое пользователей обменялись сертификатами, у них будет возможность обменяться друг с другом зашифрованными сообщениями электронной почты.
Устранение неполадок
Порой у получателя возникают сложности в открытии зашифрованного сообщения. Наиболее вероятными источниками проблем здесь являются недоверенные корневые центры сертификации, промежуточные центры сертификации, которые невозможно проверить, и недоступные списки отзыва сертификатов.
Недоверенный корневой центр сертификации обычно появляется в Outlook как сообщение об ошибке, связанное с подписью: «Имеются затруднения, относящиеся к подписи. Для получения дополнительных сведений нажмите кнопку подписи». Для решения проблемы откройте сертификат изнутри Outlook и нажмите кнопку «О центре сертификации...» из всплывающего диалога. Взгляните на сообщение на вкладке «Общие» или в диалоге свойств сертификата. Если оно указывает, что корневой сертификат центра сертификации не пользуется доверием, и его нужно установить, перейдите на вкладку сведений. Нажмите кнопку «Копировать в файл...» и выполните указания мастера, принимая все параметры по умолчанию и предоставляя имя и папку файла по запросу.
Затем откройте новую консоль управления Майкрософт (MMC) как администратор компьютера. Перейдите к оснастке Файл|Добавить/Удалить (Ctrl+M), выберите «Сертификаты» и добавьте ее к учетной записи компьютера, выбрав «Локальный компьютер», когда последует запрос. Далее разверните узел сертификатов в левом дереве, затем сделайте то же самое с узлом «Доверенные корневые центры сертификации». Щелкните правой кнопкой мыши панель и выберите Все задачи|Импорт из всплывающего меню. Импортируйте ранее упоминавшийся экспортированный файл сертификата в «Доверенные корневые центры сертификации» и нажмите кнопку «Готово». Затем попросите пользователя, для которого это выполнялось, перезапустить Outlook.
Эти указания следует использовать только для добавления корневого центра сертификации, который точно заслуживает доверия. Не все корни созданы равными. Хорошо подумайте о том, кто владеет корневым центром сертификации и управляет им, перед использованием этого метода, чтобы добавить корень к хранилищу для всей системы. Если компания контролирует список доверенных корней через групповую политику, настройка будет спущена клиентским системам. В этом случае указания могут не сработать. Если они не срабатывают, может возникнуть необходимость исследовать альтернативные варианты, такие как защищенные веб-узлы или серверы для обмена данными, поскольку электронная почта не предоставит безупречное и защищенное обслуживание.
Вторая проблема отмеченная выше, невозможность проверить промежуточные центры сертификации, обычно возникает в двух случаях: когда клиент, пытающийся проверить сертификат, не может получить доступ к местоположению информации о центре сертификации (AIA), определенному в сертификате, или у клиента имеется версия сертификата промежуточного центра сертификации, которая не совпадает с тем, что выпускает центр сертификации (клиент часто отстает на версию или две). Эти условия представляются очень похожими в интерфейсе пользователя Outlook. Мы видели это только в очень специальных обстоятельствах, когда срок действия сертификата промежуточного центра сертификации в цепи истекал, и сертификат выдавался заново, прежде чем истекал срок действия выпущенных центром сертификации подчиненных сертификатов.
По сути, эта проблема возникает, когда в цепи есть пробелы. Некоторые родительские сертификаты могут быть не слишком детализированными или не внедренными в оконечный узел дерева должным образом, что еще более усложняет ситуацию.
Чтобы решить эту проблему, отправителю нужно открыть новое сообщение и щелкнуть параметры нового сообщения, затем нажать кнопку параметров безопасности и кнопку изменения параметров. Далее нажмите кнопку «Выбрать» для сертификата подписи, затем кнопку просмотра сертификата во всплывающем диалоговом окне. Перейдите на вкладку пути сертификата, выберите поставщика оконечного узла дерева (то есть, на один уровень вверх в цепи) и нажмите кнопку просмотра сертификата. Выберите вкладку подробностей, затем нажмите кнопку «Копировать в файл...» и завершите работу мастера экспорта, выбрав PKCS #7 (.P7B). Убедитесь, что установлен флажок «Включить в путь все сертификаты», как показано на рис. 3. Наконец, отправьте экспортированный файл цепи желаемому получателю.
Рис. 3 Заполнение пробелов в цепи сертификатов
После получения экспортированной цепи сертификатов получателю понадобится открыть и импортировать цепь примерно так же, как мы ранее импортировали корень. Единственная разница состоит в том, что выбранной папкой хранения должны быть «Промежуточные центры сертификации». Если сообщение открывается, и сертификат показан как допустимый в Outlook, то все работает верно.
Что касается третьей проблемы, недоступности списка отзыва сертификатов, то исправление относительно просто. Первоначальный ответ от Outlook будет выглядеть весьма похожим на предыдущую проблему. Однако ошибка будет показана, даже если корневые или промежуточные подписывающие центры сертификации пользуются доверием. Для каждого уровня цепи сертификатов выше конечного откройте свойства сертификата, затем вкладку сведений и взгляните на поле, именуемое «Точки распространения списков отзыва (CRL)».
Для каждой перечисленной точки распространения списков отзыва сертификатов (особенно для доступных из Интернета) проверьте возможность открыть URL-адрес файла списка отзыва сертификатов. После проверки каждого уровня перемещайтесь на один уровень в цепи вверх. Если какой-либо из списков отзыва сертификатов не может быть получен, он, вероятно, является источником проблемы. Для разрешения проблемы следует убедиться, что локальная политика сети не блокирует доступ. В ином случае, попробуйте связаться с компанией, владеющей центром сертификации, или ждите, пока принадлежащая центру сертификации точка распространения списков отзыва сертификатов не вернется в рабочее состояние.
Распространение сертификатов
Распространение – это простая часть. По сути, подписанное сообщение передается серверу электронной почты, который затем отсылает его из одного места в другое проверенным способом – через SMTP. Единственная виденная нами проблема при передаче подписанной или зашифрованной почты состоит в том, что некоторые почтовые системы отвергают или разбивают подписанные или зашифрованные сообщения, проходящие через них. Способ исправления заключается в работе с руководителем ИТ-системы для получения допустимых типов сообщений. Само собой, возможно, придется смириться с фактом, что некоторые типы сообщений блокируются. У получателя могут быть веские причины не допускать зашифрованные сообщения в определенной рабочей среде.
Шифрование ответов.
Для создания зашифрованного ответа (предполагая, что вышеупомянутый процесс начальной загрузки уже завершен) отправителю необходимо лишь создать сообщение и затем нажать кнопку «Зашифровать» (маленький желтый конверт с синим замком на нем с надписью «Зашифровать») в окне составления сообщений. Если эта кнопка недоступна, выполните все действия по отправке подписанного сообщения, кроме последнего, вместо которого установите флажок «Шифровать содержимое сообщения и вложения».
Подпись S/MIME не требуется для отправки получателю зашифрованного сообщения, но то и другое отлично работают вместе, поскольку подпись позволяет читателю проверить сервер (функция шифрования не удостоверяет отправителя). Процесс шифрования попытается зашифровать сообщение с помощью известных открытых ключей всех получателей. Если система не может найти сертификаты для некоторых предполагаемых получателей, они будут помечены во всплывающем диалоге, предлагающем отправить сообщение незашифрованным, как показывает рис. 4.
Рис. 4 Можно решить отправить незашифрованное сообщение при наличии проблемы с сертификатом
По умолчанию подписывание и шифрование должны работать с другими сравнимо настроенными клиентскими системами, но порой обмен подписанными или зашифрованными сообщениями между несколькими версиями может привести к проблемам, если алгоритм хэширования или шифрования не поддерживается на предыдущем уровне. Мы столкнулись с такой проблемой при отправке подписанных сообщений электронной почты (используя SHA-512 как алгоритм хэширования) пользователю, использующему Windows XP с пакетом обновления 2. Поскольку получающая система не поддерживала хэширование, пользователю не удавалось проверить подпись или прочитать сообщение. Однако если параметры Outlook по умолчанию не изменялись, пользователи вряд ли встретят много проблем на этом этапе.
По получении сообщения предполагаемый получатель должен быть способен открыть его, если доступен открытый ключ, связанный с общедоступным сертификатом. Кроме того, от пользователя может потребоваться предоставление дополнительного маркера, подтверждающего владение секретным ключом, в зависимости от того, как он был развернут. Другие пользователи, выполнившие подобную процедуру инициализации, могут принять участие в подобной подписанной и зашифрованной переписке с получателем. Если пользователь изменил свой секретный ключ (скажем, из-за потери компьютера), ему нужно повторно запросить сертификаты и заново распространить подписанное сообщение или файл сертификата между теми, с кем он желает обмениваться зашифрованными сообщениями.
Заключение.
Заставить подписанную и зашифрованную S/MIME работать между двумя пользователями в двух различных каталогах или организациях обычно не сильно сложнее, чем выполнить описанное выше. Подпись очень удобна при правильном использовании, поскольку удостоверяет подлинность сообщения. Зашифрованные сообщения предоставляют дополнительный уровень секретности при передаче данных для конфиденциальных сообщений. Вместе они обеспечивают и подтверждение подлинности отправителя, и секретность данных. А описанный здесь процесс позволяет большинству пользователей без труда воспользоваться этими возможностями.
