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

Содержание

Слайд 2

Криптографические Методы Защиты закрытие (шифрование) данных при хранении или передаче по

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

закрытие (шифрование) данных при хранении или передаче по каналам

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

Позволяют решать следующие задачи:

Слайд 3

Криптографические методы защиты Симметричное шифрование данных Асимметричное шифрование данных Комбинированные схемы

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

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

Основные

криптографические схемы:
Слайд 4

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

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

ЭД

Ь#*
!@$

ЭД

Открытый канал
связи

Шифрование

Расшифрование

Отправитель

Получатель

Секретный
ключ

Секретный
ключ

Слайд 5

Асимметричное шифрование ЭД Ь#* !@$ ЭД Открытый канал связи Шифрование Расшифрование

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

ЭД

Ь#*
!@$

ЭД

Открытый
канал
связи

Шифрование

Расшифрование

Отправитель

Получатель

Секретный
ключ

Открытый
ключ

Слайд 6

ЭД Канал связи Hash (ЭД) Ъ№ @ Шифрование Ъ№@ ЭД Ъ№@

ЭД

Канал связи

Hash
(ЭД)

Ъ№ @

Шифрование

Ъ№@

ЭД

Ъ№@

Hash
(ЭД)

Расшифрование

Hash
ЭД

=

?

Электронная цифровая подпись

Слайд 7

Криптографические алгоритмы Симметричное шифрование Data Encryption Standard (DES) DES: 56 бит

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

Симметричное шифрование
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 - облегчение использования криптографии с открытым ключом

Концепция PKI

Назначение PKI - облегчение использования криптографии с открытым ключом посредством

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

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

Слайд 11

Номер версии X.509 Открытый ключ пользователя Серийный номер сертификата Период действия

Номер версии 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

Орган сертификации Орган сертификации (Certification Authority, CA) – основной компонент PKI

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

Орган сертификации (Certification Authority, CA) – основной компонент PKI

СА -

доверенная третья сторона, чья подпись под сертификатом подтверждает подлинность связи открытого ключа с представляемым объектом (стороной).

Издает (создает и подписывает) сертификаты
Поддерживает информацию о статусе сертификатов и издает CRL
Публикует свои и изданные им сертификаты и CRL
Архивирует информацию об истекших или отозванных сертификатах

CA выполняет четыре основных функции PKI:

Слайд 15

Делегирование обязанностей СА Орган сертификации (Certification Authority, CA) Орган регистрации (Registration

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

Орган сертификации (Certification Authority, CA)
Орган регистрации (Registration Authority

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

Пять основных функциональных компонентов PKI:

Слайд 16

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

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

Слайд 17

Microsoft PKI

Microsoft PKI

Слайд 18

Microsoft Certificate Authority Два класса CA (Центров Сертификации) Enterprise CA (предприятия)

Microsoft Certificate Authority

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

типа СА (в иерархии)
Root CA (корневой)
Subordinate CA (подчиненный)
Слайд 19

Enterprise и Standalone CA Standalone CA Целесообразно использовать в качестве корневого

Enterprise и Standalone CA

Standalone CA
Целесообразно использовать в качестве корневого и промежуточных

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

Enterprise CA
Целесообразно использовать во внутренней сети организации, так как он автоматически (прозрачно для объектов домена) выполняет большую часть работы

Слайд 20

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

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

Практическая работа 19

Слайд 21

isec dom03.isec Сеть 506 200.1.1.0 dom08.isec dom10.isec dom06.isec dom04.isec dom12.isec Схема

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

Папки в оснастке для каждого Certification Authority: Revoked Certificates («отозванные сертификаты»)

Папки в оснастке для каждого Certification Authority:

Revoked Certificates («отозванные сертификаты»)

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

Управление СА

Слайд 23

Шаблоны сертификатов Определяют фиксированные наборы атрибутов и расширений, которые будет иметь

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

Определяют фиксированные наборы атрибутов и расширений, которые будет иметь выдаваемый

сертификат
Windows 2000 поддерживает 19 шаблонов, позволяющих легко изготовлять сертификаты для конкретных задач

Примеры шаблонов сертификатов:

Слайд 24

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

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

Слайд 25

Что такое защита сообщений? Основная защита сообщений Аутентификация источника данных Конфиденциальность

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

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

услуги
Подписывание квитанции о приеме: неотказуемость доставки
Метки безопасности
Защищенные перечни рассылки
Слайд 26

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

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

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

MIME
Слайд 27

История и разработка После разработки PEM и в параллель с разработкой

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

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

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

Цель 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 определен только один тип защиты контекста

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

В RFC 2630 определен только один тип защиты контекста
Цель этого

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

Формат Type + value Контексты произвольно вкладываются Content = encrypted Encryption

Формат Type + value
Контексты произвольно вкладываются

Content = encrypted

Encryption info

Content = signed

Signature(s)

Content

= data

DATA

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

Слайд 31

Формат Signed Data Однопроходная обработка

Формат Signed Data

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

Слайд 32

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

Формат Signature

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

Слайд 33

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

Формат Signature

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

Слайд 34

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

Формат Enveloped Data

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

ключей
Слайд 35

Поддерживаемые типы MIME Application/pkcs7-mime тип MIME с параметром smime-type установленным в

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

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

типов MIME: multipart/signed и application/pkcs7-signature
Слайд 36

Процесс обработки S/MIME Согласно RFC 2633, процесс отправления криптографически защищенного сообщения

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

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

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

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

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

Слайд 41

S/MIME против PGP

S/MIME против PGP

Слайд 42

S/MIME против PGP PGP: сетевая модель Сертификат может быть подписан несколько

S/MIME против PGP

PGP: сетевая модель
Сертификат может быть подписан несколько раз (различными

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

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

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

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

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

Слайд 44

Выберите пункт меню Сервис, Параметры и нажмите на закладку Безопасность. В

Выберите пункт меню Сервис, Параметры и нажмите на закладку Безопасность.
В

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

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

Слайд 45

В окне Сообщение нажмите кнопку Параметры. В появившемся окне диалога установите

В окне Сообщение нажмите кнопку Параметры.
В появившемся окне диалога установите

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

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

Слайд 46

Откройте полученное подписанное письмо. Установите курсор на адрес отправителя и, нажав

Откройте полученное подписанное письмо.
Установите курсор на адрес отправителя и, нажав

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

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

Слайд 47

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

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

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

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