Защита почтовых сообщений и коммуникаций

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

Криптографические методы защиты Симметричное шифрование данных Асимметричное шифрование данных Комбинированные схемы шифрования Электронная цифровая подпись Основные криптографические схемы:

Симметричное шифрование ЭД Ь#* ЭД Открытый канал связи Шифрование Расшифрование Отправитель Получатель Секретный ключ Секретный ключ

Асимметричное шифрование ЭД Ь#* ЭД Открытый канал связи Шифрование Расшифрование Отправитель Получатель Секретный ключ Открытый ключ

ЭД Канал связи Hash (ЭД) Шифрование ЭД Hash (ЭД) Расшифрование Hash ЭД = ? Электронная цифровая подпись

Криптографические алгоритмы Симметричное шифрование –Data Encryption Standard (DES) DES: 56 бит DESX: 128 бит Triple DES: 112 бит, 168 бит –Rivests Cipher (RC) RC2, RC4: 40 бит, 56 бит, 128 бит Хеширование –Message Digest (MD) MD2, MD4, MD5 –Secure Hash Algorithm (SHA-1) –Hashed Message Authentication Code (HMAC) Цифровая подпись –Digital Signature Algorithm (DSA) –RSA Digital Signature Обмен ключами –Diffie-Hellman Key Agreement –RSA Key Exchange –ГОСТ бит –ГОСТ Р (2001) 256 и 512 (1024) бит –ГОСТ Р

Три способа аутентификации (доказательства прав) 1. Знать что-либо, чего не знают другие (секретный пароль или ключ) 2. Иметь что-либо, чего нет у других (что сложно отнять или передать) 3. Иметь рекомендации от доверенного посредника (которому верит проверяющий)

Третий способ аутентификации

Концепция PKI Назначение PKI - облегчение использования криптографии с открытым ключом посредством создания и распространения сертификатов открытых ключей и списков отозванных сертификатов В 1978 году Кохфельдер (Kohnfelder, Loren M.) предложил использовать сертификаты для распространения открытых ключей с тем, чтобы их аутентичность можно было проверить. Фактически он предложил концепцию инфраструктуры открытых ключей.

Номер версии X.509 Открытый ключ пользователя Серийный номер сертификата Период действия сертификата Идентификатор издателя ЭЦП издателя Сертификат может выпущен только уполномоченным эмитентом (CA) и содержит единственную ЭЦП эмитента X509 - промышленный стандарт сертификатов X.509v3 Идентификатор пользователя Идентификатор алгоритма ЭЦП В настоящее время наиболее часто используются сертификаты на основе стандарта Международного союза телекоммуникаций ITU-T X.509 версии 3 и рекомендаций IETF (Internet Engineering Task Force) RFC 2459 Сертификат - решение проблемы доверия

Проблема отзыва сертификатов Сертификат – не воробей, - издашь не отзовешь ! (Пословица нового времени) Список отозванных сертификатов Certificate Revocation List (CRL) – подписанный набор записей, соответствующий отозванным открытым ключам, где каждая запись указывает серийный номер соответствующего сертификата, время отзыва, причину отзыва и др. Минимизировать возможный ущерб при компрометации индивидуального (секретного) ключа можно путем запрета его дальнейшего использования. Но кроме этого необходимо запретить использование всех копий соответствующего открытого ключа, то есть отозвать сертификат, сообщив всем его потенциальным пользователям, что верить ему больше нельзя.

Инфраструктура открытых ключей

Орган сертификации Орган сертификации (Certification Authority, CA) – основной компонент PKI СА - доверенная третья сторона, чья подпись под сертификатом подтверждает подлинность связи открытого ключа с представляемым объектом (стороной). Издает (создает и подписывает) сертификаты Поддерживает информацию о статусе сертификатов и издает CRL Публикует свои и изданные им сертификаты и CRL Архивирует информацию об истекших или отозванных сертификатах CA выполняет четыре основных функции PKI:

Делегирование обязанностей СА 1. Орган сертификации (Certification Authority, CA) 2. Орган регистрации (Registration Authority - RA) проверяет контекст сертификатов 3. Хранилище (repository) распространяет сертификаты и CRL 4. Архив (archive) хранит истекшие сертификаты 5. Клиентское ПО реализует криптографические услуги для владельцев и пользователей ключей и сертификатов Пять основных функциональных компонентов PKI:

Инфраструктура открытых ключей End Entity Face-to-face RAO CAO RA HSM D/B RA HSM D/B RA HSM D/B Gate - ways BrowserVPN CA HSM D/B CA HSM D/B CA Cross Certification CA HSM D/B Directory Services LDAP, DAP End User Domain PKI enabled applications LDAP

Microsoft PKI

Microsoft Certificate Authority Два класса CA (Центров Сертификации) –Enterprise CA (предприятия) –Stand-Alone CA (автономный) Два типа СА (в иерархии) –Root CA (корневой) –Subordinate CA (подчиненный)

Enterprise и Standalone CA Standalone CA Целесообразно использовать в качестве корневого и промежуточных СА, так как в целях более надежной защиты он может быть изолирован от сети Может быть использован в качестве издающего СА, размещенного в DMZ (откуда нет доступа к AD) Enterprise CA Целесообразно использовать во внутренней сети организации, так как он автоматически (прозрачно для объектов домена) выполняет большую часть работы

Установка служб сертификации Microsoft Certificate Services Практическая работа 19

isec dom03. isec Сеть dom08.isecdom10. isec dom06. isec dom04. isec dom12. isec Схема сети класса w2k03 w2k08w2k10 w2k12 w2k06 w2k04 root.isec

Папки в оснастке для каждого Certification Authority: Revoked Certificates («отозванные сертификаты») - список всех отозванных на данный момент сертификатов (CRL) Issued Certificates («изданные сертификаты») - список сертификатов, изданных данным CA Pending Requests («ожидающие запросы») - показывает «ожидающие» запросы, то есть запросы, оставленные CA в состоянии ожидания вашего решения Failed Requests («неудавшиеся запросы») - список неудавшихся или отвергнутых запросов Policy Settings («установки политики») - список шаблонов сертификатов, доступных на данном сервере Управление СА

Шаблоны сертификатов Определяют фиксированные наборы атрибутов и расширений, которые будет иметь выдаваемый сертификат Windows 2000 поддерживает 19 шаблонов, позволяющих легко изготовлять сертификаты для конкретных задач Шаблон Назначение шаблона Получатели сертификатов Компьютер Аутентифицирует клиентский компьютер по отношению к серверу и наоборот Компьютеры, входящие в состав доменов Пользователь Аутентифицирует сообщения от клиента к серверу Подписывает и шифрует электронную почту Шифрует данные EFS Одиночные пользователи, не имеющие других специальных полномочий Примеры шаблонов сертификатов:

Защита сообщений с использованием S/MIME

Что такое защита сообщений? Основная защита сообщений –Аутентификация источника данных –Конфиденциальность –Целостность –Неотказуемость с доказательством источника Дополнительные услуги –Подписывание квитанции о приеме: неотказуемость доставки –Метки безопасности –Защищенные перечни рассылки

Схемы защиты почтовых сообщений PEM: privacy enhanced mail PGP: pretty good privacy S/MIME: secure MIME

История и разработка После разработки PEM и в параллель с разработкой MOSS рабочая группа руководимая RSA Security, Inc. приступила к разработке другой спецификации для передачи цифровым образом подписанных и/или зашифрованных (в конверте) сoобщений в соответствии с форматом сообщений MIME и некоторыми ранее опубликованными стандартами (PKCS) Подход и спецификация протокола была названа Secure Multipurpose Internet Mail Extensions (S/MIME) Имеется три версии S/MIME: –S/MIME версии 1 была специфицирована и официально опубликована в 1995 году RSA Security, Inc. –S/MIME версии 2 был специфицирован парой RFC - RFC 2311 и RFC 2312 – в марте 1998 –Работы продолжавшиеся в IETF S/MIME Mail Security (SMIME) WG дали в результате S/MIME версии 3 специфицированной в RFC от 2630 до 2634 в июне 1999

Используемые стандарты Цель S/MIME защитить объекты MIME Объект MIME, в свою очередь, может быть частью сообщения, множеством частей, или полным сообщением Во всех случаях, S/MIME определяет как криптографически защитить объект MIME S/MIME основывается на синтаксисе криптографического сообщения (cryptographic message syntax, CMS) определенного в RFC 2630 CMS, в свою очередь, получен из PKCS #7 версии 1.5 определенного в RFC 2315 CMS величины генерируются с использованием ASN.1 и кодируются как байтовые строки согласно BER.

Синтаксис S/MIME В RFC 2630 определен только один тип защиты контекста Цель этого ContentInfo типа – инкапсулировать определенный тип контекста, и этот определенный тип контекста может обеспечить дальнейшую инкапсуляцию RFC 2630 определяет шесть типов контекста: –Data –SignedData –EnvelopedData –DigestedData –EncryptedData –AuthenticatedData

Формат Type + value Контексты произвольно вкладываются Content Type Content Content = encrypted Encryption info Content = signed Signature(s) Content = data DATA Синтаксис S/MIME

Формат Signed Data Digest (hash) algorithm(s) Encapsulated data Signer certificate chain(s) Signature(s) Однопроходная обработка

Формат Signature Используются неаутентифицированные атрибуты для предоставления дополнительной информации Поддержка множественных подписей Signing certificate identifier Authenticated attributes Signature Unauthenticated attributes

Формат Signature Используются неаутентифицированные атрибуты для предоставления дополнительной информации Поддержка множественных подписей Signing certificate identifier Authenticated attributes Signature Unauthenticated attributes

Формат Enveloped Data Поддержка заранее распределенных ключей Поддержка алгоритмов согласования ключей Поддержка алгоритмов транспортирования ключей Per-recipient information Key management certificate identifier Encrypted session key

Поддерживаемые типы MIME Application/pkcs7-mime тип MIME с параметром smime-type установленным в signed-data Поддержка типов MIME: multipart/signed и application/pkcs7-signature

Процесс обработки S/MIME Согласно RFC 2633, процесс отправления криптографически защищенного сообщения S/MIME состоит в следующем: Объект MIME подготавливается согласно обычных правил подготовки сообщения для MIME Получающийся MIME объект преобразуется в каноническую форму (детали процедуры канонизации зависят от фактического типа и подтипа MIME) MIME объект плюс некоторая относящаяся к защите сообщения информация, такая как идентификаторы алгоритмов или сертификаты, обрабатывается S/MIME и получается PKCS объект PKCS объект интерпретируется как контекст сообщения и заключается в оболочку MIME (в начале могут быть добавлены дополнительные MIME заголовки) Получившееся сообщение передается намечаемому получателю (лям)

Зашифрованный объект MIME From:... To:... Subject:... MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m …

Криптоалгоритмы Криптографические алгоритмы: –S/MIME v2 требует поддержки для SHA-1, MD5, 40-битного RC2, и RSA (U.S. Версии дополнительно реализуют DES и 3DES) –S/MIME v3 требует дополнительной поддержки для DES, 3DES, 128-битного RC2, DH и DSA С криптографической точки зрения, алгоритмы используемые S/MIME идентичны или совместимы с используемыми PGP (и OpenPGP)

Процесс защищенного почтового обмена

Процедура построения и проверки цепочки сертификации по RFC 2632

S/MIME против PGP Обязательные возможности S/MIME v3OpenPGP Формат сообщения Двоичный, основанный на CMS Двоичный, основанный на previous PGP Формат сертификата Двоичный, основанный на X.509v3 Двоичный, основанный на ранних версиях PGP Алгоритмы симметричного шифрования TripleDES (DES EDE3 CBC)TripleDES (DES EDE3 CFB) Алгоритмы подписиDH (X9.42) с DSAElGamal (DH) с DSA Алгоритм хэшированияSHA-1 MIME инкапсуляция подписанных данных Выбор формата multipart/signed или CMS multipart/signed с защитной оболочкой ASCII MIME инкапсуляция зашифрованных данных application/pkcs7-mimemultipart/encrypted

S/MIME против PGP PGP: сетевая модель –Сертификат может быть подписан несколько раз (различными объектами) –Личное доверие (установление степени доверия) S/MIME: Модель доверия не определена –Реализация почти любой модели доверия –Сертификаты X.509 –Сертификат подписывается один раз

1. Выберите пункт меню Сервис, Параметры и нажмите на закладку Безопасность. Нажмите кнопку Параметры. 2. Используя кнопки Выбрать, выберите личные сертификаты, соответствующие ключам подписи и шифрования. Конфигурация Outlook

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

1. В окне Сообщение нажмите кнопку Параметры. 2. В появившемся окне диалога установите флаг Добавить цифровую подпись к исходящему сообщению. 3. После того, как сообщение подготовлено к отправке, нажмите кнопку Отправить. Отправка подписанных сообщений в Outlook

1. Откройте полученное подписанное письмо. 2. Установите курсор на адрес отправителя и, нажав правую кнопку мыши, выберите пункт Добавить к контактам. 3. В отображаемом диалоге нажмите на закладку Сертификаты и убедитесь в наличие сертификата отправителя. Получение сертификата для шифрования сообщений в Outlook

1. Нажмите кнопку Параметры и в отображаемом диалоге установите флаг Зашифровать сообщение и вложение. 2. После того, как сообщение подготовлено к отправке, нажмите кнопку Отправить. Отправка шифрованных сообщений в Outlook

Запрос сертификатов и настройка защищенного почтового обмена Практическая работа 20