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

Содержание

• 
  Слайд 1
  

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

• 
  Слайд 2

  Криптографические Методы Защиты

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

• 
  Слайд 3

  Криптографические методы защиты

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

• 
  Слайд 4

  Симметричное шифрование

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

• 
  Слайд 5

  Асимметричное шифрование

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

• 
  Слайд 6
  

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

• 
  Слайд 7

  Криптографические алгоритмы

  Симметричное шифрование Data Encryption Standard (DES) DES: 56 бит DESX: 128 бит Triple DES: 112 бит, 168 бит Rivest’s 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 ГОСТ 28147-89 256 бит ГОСТ Р 34.10-94 (2001) 256 и 512 (1024) бит ГОСТ Р 34.11-94

• 
  Слайд 8

  Три способа аутентификации(доказательства прав)

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

• 
  Слайд 9

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

  Иметь рекомендации от доверенного посредника (которому верит проверяющий)

• 
  Слайд 10

  Концепция PKI

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

• 
  Слайд 11

  Сертификат - решение проблемы доверия

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

• 
  Слайд 12
  

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

• 
  Слайд 13

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

• 
  Слайд 14

  Орган сертификации

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

• 
  Слайд 15

  Делегирование обязанностейСА

  Орган сертификации (CertificationAuthority, CA) Орган регистрации (RegistrationAuthority - RA) проверяет контекст сертификатов Хранилище (repository)распространяет сертификаты и CRL Архив (archive)хранит истекшие сертификаты Клиентское ПО реализует криптографические услуги для владельцев и пользователей ключей и сертификатов Пять основных функциональных компонентов PKI:

• 
  Слайд 16

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

  End Entity Face-to-face RAO RAO CAO RA HSM D/B RA HSM D/B RA HSM D/B Gate- ways E-mail Browser VPN 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

• 
  Слайд 17

  Microsoft PKI

• 
  Слайд 18

  Microsoft Certificate Authority

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

• 
  Слайд 19

  Enterprise и Standalone CA

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

• 
  Слайд 20
  

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

• 
  Слайд 21

  Схема сети класса

  isec dom03.isec Сеть 506 200.1.1.0 dom08.isec dom10.isec dom06.isec dom04.isec dom12.isec 4 5 3 2 8 7 10 9 12 11 13 6 100 w2k03 w2k08 w2k10 w2k12 w2k06 w2k04 root.isec

• 
  Слайд 22
  

  Папки в оснастке для каждого CertificationAuthority: RevokedCertificates («отозванные сертификаты») - список всех отозванных на данный момент сертификатов (CRL) IssuedCertificates(«изданные сертификаты») - список сертификатов, изданных данным CA PendingRequests(«ожидающие запросы») - показывает «ожидающие» запросы, то есть запросы, оставленные CA в состоянии ожидания вашего решения FailedRequests(«неудавшиеся запросы») - список неудавшихся или отвергнутых запросов PolicySettings(«установки политики») - список шаблонов сертификатов, доступных на данном сервере Управление СА

• 
  Слайд 23

  Шаблоны сертификатов

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

• 
  Слайд 24
  

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

• 
  Слайд 25

  Что такое защита сообщений?

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

• 
  Слайд 26

  Схемы защиты почтовых сообщений

  PEM: privacy enhanced mail PGP: pretty good privacy S/MIME: secure MIME

• 
  Слайд 27

  История и разработка

  После разработки 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

• 
  Слайд 28

  Используемые стандарты

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

• 
  Слайд 29

  Синтаксис S/MIME

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

• 
  Слайд 30
  

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

• 
  Слайд 31

  Формат Signed Data

  Однопроходная обработка

• 
  Слайд 32

  Формат Signature

  Используются неаутентифицированные атрибуты для предоставления дополнительной информации Поддержка множественных подписей

• 
  Слайд 33
  

  Используются неаутентифицированные атрибуты для предоставления дополнительной информации Поддержка множественных подписей

• 
  Слайд 34

  Формат Enveloped Data

  Поддержка заранее распределенных ключей Поддержка алгоритмов согласования ключей Поддержка алгоритмов транспортирования ключей

• 
  Слайд 35

  Поддерживаемые типы MIME

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

• 
  Слайд 36

  Процесс обработки S/MIME

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

• 
  Слайд 37

  Зашифрованный объект 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 …

• 
  Слайд 38

  Криптоалгоритмы

  Криптографические алгоритмы: 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)

• 
  Слайд 39

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

• 
  Слайд 40

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

• 
  Слайд 41

  S/MIME против PGP

• 
  Слайд 42
  

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

• 
  Слайд 43

  Конфигурация Outlook

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

• 
  Слайд 44
  

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

• 
  Слайд 45

  Отправка подписанных сообщений в Outlook

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

• 
  Слайд 46

  Получение сертификата для шифрования сообщений в Outlook

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

• 
  Слайд 47

  Отправка шифрованных сообщений в Outlook

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

• 
  Слайд 48
  

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