(5 оценок, среднее: 4,80 из 5)
Загрузка...
Учебная работа. Реферат: Защита электронной почты в Internet
Введение
…………………………………………………………………………………………………………………………………… 2
1. методы защиты потока данных в Web
………………………………………………………………………………. 3
2. защита на уровне приложений
…………………………………………………………………………………………….. 4
2. 1. Система PGP
…………………………………………………………………………………………………………………….. 4
2. 2. Система S/MIME
……………………………………………………………………………………………………………….. 7
3. Протоколы SSL и TLS
………………………………………………………………………………………………………… 11
3. 1. Архитектура SSL
…………………………………………………………………………………………………………….. 11
3. 2. протокол записи SSL
………………………………………………………………………………………………………. 11
3. 3. Протокол конфигурации характеристик шифрования
……………………………………………………………… 12
3. 4. протокол уведомления
……………………………………………………………………………………………………….. 12
3. 5. Протокол квитирования
…………………………………………………………………………………………………. 12
3. 6. Создание головного секретного ключа
……………………………………………………………………………… 15
3. 7. Генерирование криптографических характеристик
……………………………………………………………. 15
3. 8. Что такое TLS и его отличие от SSL
……………………………………………………………………………….. 16
4. защита на уровне IP (сетевой уровень)
………………………………………………………………………………. 16
4. 1. Архитектура защиты на уровне IP
…………………………………………………………………………………. 16
4. 2. Заголовок аутентификации (AH).
……………………………………………………………………………………. 18
4. 2. 1. структура заголовка
…………………………………………………………………………………………………… 18
4. 2. 2. Внедрение AH в транспортном и туннельном режиме
………………………………………… 18
4. 3. протокол ESP
………………………………………………………………………………………………………………….. 19
4. 3. 1. Формат пакета ESP
……………………………………………………………………………………………………… 19
4. 3. 2. Шифрование и методы аутентификации
………………………………………………………………. 20
4. 3. 3. Транспортный режим ESP
………………………………………………………………………………………….. 20
4. 3. 4. Туннельный режим ESP
……………………………………………………………………………………………… 21
4. 4. Композиция защищённых связей
…………………………………………………………………………………… 22
Заключение
…………………………………………………………………………………………………………………………….. 24
Источники инфы
…………………………………………………………………………………………………………. 25
Введение.
Большая часть заморочек, с которыми сталкиваются юзеры электрической почты (мусор, вирусы, различные атаки на конфиденциальность писем и т. д.), соединено с недостаточной защитой современных почтовых систем.
С этими неуввязками приходится иметь дело и юзерам общедоступных общественных систем, и организациям. Практика указывает, что одномоментное решение трудности защиты электрической почты нереально. Спамеры, создатели и распространители вирусов, хакеры изобретательны, и уровень защиты электрической почты, полностью удовлетворительный вчера, сейчас может оказаться недостающим. Для того чтоб защита электрической почты была на очень вероятном уровне, а достижение этого уровня не добивалось лишних усилий и издержек, нужен периодический и полный, с учетом всех угроз, подход к решению данной трудности.
Предпосылки неких заморочек, связанных конкретно с конфиденциальностью почтовых сообщений, закладывались при появлении электрической почты три десятилетия вспять. Почти во всем они не разрешены до сего времени.
· Ни один из обычных почтовых протоколов (SMTP, POP3, IMAP4) не включает устройств защиты, которые гарантировали бы конфиденциальность переписки.
· Отсутствие надежной защиты протоколов дозволяет создавать письма с липовыми адресами. недозволено быть уверенным на 100% в том, кто является реальным создателем письма.
· электрические письма просто поменять. Обычное письмо не содержит средств проверки своей целостности и при передаче через огромное количество серверов, быть может прочитано и изменено; электрическое письмо похоже сейчас на открытку.
· Обычно в работе электрической почты нет гарантий доставки письма. Невзирая на наличие способности получить сообщение о доставке, нередко это значит только, что сообщение дошло до почтового сервера получателя (но не непременно до самого адресата).
При выбирании нужных средств защиты электрической почты, обеспечивающих её конфиденциальность, целостность, нужно для системного админа либо юзера ответить на вопросец: какие более обычные средства может употреблять злодей для атак систем электрической почты?
Приведём лаконичный пример данных средств и способов:
1–ый метод. Внедрение снифферов. Сниффер — представляют собой программки, перехватывающие все сетевые пакеты, передающиеся через определенный узел. Снифферы употребляются в сетях на полностью легитимном основании для диагностики дефектов и анализа потока передаваемых данных. Ввиду того, что некие сетевые приложения, а именно почтовые, передают данные в текстовом формате (SMTP, POP3 и др.), при помощи сниффера можно выяснить текст письма, имена юзеров и пароли.
2-ой метод. IP-спуфинг (spoofing) — вероятен, когда злодей, находящийся снутри организации либо вне ее выдает себя за санкционированного юзера. Атаки IP-спуфинга нередко являются отправной точкой для остальных атак, к примеру, DoS (Denial of Service – «отказ в обслуживании»). Обычно IP-спуфинг ограничивается вставкой неверной инфы либо вредных установок в обыденный поток передаваемых по сети данных. Это происходит в случае, если основная задачка состоит в получении принципиального файла. Но злодей, поменяв таблицы маршрутизации данных и направив трафик на неверный IP-адресок, может восприниматься системой как санкционированный юзер и, как следует, иметь доступ к файлам, приложениям, и в том числе к электрической почте.
3-й метод – получение пароля на почту. Атаки для получения паролей можно проводить при помощи целого ряда способов, и хотя входное имя и пароль можно получить с помощью IP-спуфинга и перехвата пакетов, их нередко пробуют подобрать методом обычного перебора при помощи специальной программки.
4-й метод нарушения конфиденциальности — Man-in-the-Middle («человек посреди») — состоит в перехвате всех пакетов, передаваемых по маршруту от провайдера в всякую другую часть Сети. Подобные атаки с внедрением снифферов пакетов, транспортных протоколов и протоколов маршрутизации проводятся с целью перехвата инфы, получения доступа к личным сетевым ресурсам, преломления передаваемых данных. Они полностью могут употребляться для перехвата сообщений электрической почты и их конфигураций, также для перехвата паролей и имен юзеров.
5-й метод. Атаки на уровне приложений употребляют отлично известные беспомощности серверного программного обеспечения (sendmail, HTTP, FTP). Можно, к примеру, получить доступ к компу от имени юзера, работающего с приложением той же электрической почты.
Для защиты сетевой инфраструктуры нужно употреблять:
1. До этого всего мощные средства аутентификации, к примеру, разработка двухфакторной аутентификации.
2. Действенное построение и администрирование сети. Речь идет о построении коммутируемой инфраструктуры, мерах контроля доступа и фильтрации исходящего трафика, закрытии «дыр» в программном обеспечении при помощи модулей «заплаток» и постоянном его обновлении, установке антивирусных программ и многом ином.
3. Тайнопись, которая не предутверждает перехвата инфы и не распознает работу программ для данной цели, но делает эту работу никчемной. Тайнопись также помогает от IP-спуфинга, если употребляется при аутентификации.
1.
методы защиты потока данных в Web.
Существует несколько подходов к обеспечению защиты данных в Web. Они все похожи исходя из убеждений предоставляемых способностей и в некой степени исходя из убеждений применяемых устройств защиты, но различаются по областям внедрения и размещению соответственных средств защиты в стеке протоколов TCP/IP.
один из способов защиты данных в Web состоит в использовании протокола защиты IP (IPSec) Преимущество использования IPSec состоит в том, что этот протокол прозрачен для конечного юзера и приложений и обеспечивает всепригодное решение. Не считая того, протокол IPSec включает средства фильтрации, дозволяющие употреблять его лишь для той части потока данных, для которой это вправду нужно.
Иным решением является размещение средств обеспечения сохранности сходу над протоколом TCP. Примером современной реализации такового подхода являются эталон SSL (Secure Socket Layer — протокол защищенных сокетов) и его наиболее новенькая версия — эталон TLS (Transport Layer Security — протокол защиты транспортного уровня) неопасной передачи данных в Internet. На этом уровне для практической реализации данного подхода имеется две способности. Самым общим решением является внедрение средств SSL (либо TLS) в набор соответственных протоколов, что обеспечивает прозрачность средств защиты для приложений. В то же время средства SSL можно встраивать и в прикладные программки. На пример, броузеры Netscape и Microsoft Internet Explorer, также большая часть Web-серверов имеют встроенную поддержку SSL.
Разные средства защиты могут встраиваться и в приложения. Преимущество данного подхода заключается в том, что надлежащие средства защиты могут быть настроены хорошим образом зависимо от требований определенного приложения. В контексте сохранности Web принципиальным примером реализации такового подхода является протокол SET (Secure Electronic Transaction — протокол защиты электрических транзакций).
HTTP
FTP
SMTP
HTTP
FTP
SMTP
S/MIME
PGP
SET
TCP
SSL либо
TLS
Kerberos
SMTP
HTTP
TCP
UDP
TCP
IP/IPSec
IP
IP
Сетевой уровень Транспортный уровень Уровень приложения
Размещение средств защиты в стеке протоколов
TCP
/
IP
.
2.
защита на уровне приложений.
2. 1.
Система PGP.
Сервис PGP, если не разглядывать управление ключами, складывается из 5 функций: аутентификация, конфиденциальности, сжатия, сопоставимости на уровне электрической почты и сегментации.
Разглядим короткую характеристику функций PGP.
Функция
Применяемые
методы
Описание
Цифровая
подпись
DSS/SHA либо
RSA/SHA
При помощи SHA–1 создаётся хэш-код сообщения. Приобретенный таковым образом профиль сообщения шифруется при помощи DSS либо RSAс внедрением личного ключа отправителя и врубается в сообщение.
Шифрование
сообщения
CASTлибо IDEA,
или «тройной» DEScтремя ключами и методом Диффи-Хеллмана либо RSA.
Сообщение шифруется при помощи CAST-128 либо IDEA, либо 3DESс разовым сеансовым ключом, генерируемым отправителем. Сеансовый ключ шифруется при помощи метода Диффи-Хеллмана либо RSAcиспользованием открытого ключа получателя и врубается в сообщение.
Сжатие
ZIP
Сообщение можно сжать для хранения либо передачи, использую zip.
Сопоставимость
на уровне
электрической
почты
Преобразование в формат radix-64
Чтоб обеспечить прозрачность для всех приложений электрической почты, шифрованное сообщение можно перевоплотить в строчку ASCII, используя преобразование в формат radix-64.
Сегментация
Чтоб удовлетворить ограничениям наибольшего размера сообщений, PGPвыполняет сегментацию и оборотную сборку сообщения.
Схема аутентификации.
Обозначения:
Ка – сеансовый ключ, применяемый в схеме обычного шифрования,
KRа – личный ключ А, применяемый в схеме шифрования с открытым ключом,
KUа – открытый ключ А, применяемый в схеме шифрования с открытым ключом,
EP – шифрование в схеме с открытым ключом,
DP – дешифрование в схеме с открытым ключом,
EC – шифрование в схеме обычного шифрования,
DC – дешифрование в схеме обычного шифрования,
H – функция хэширования,
|| – конкатенация,
Z – сжатие при помощи метода zip,
R64 – преобразование в формат radix-64 ASCII.
Шаги:
1. Отправитель делает сообщение.
2. Употребляется метод SHA-1, в итоге что выходит 160-битовый хэш-вектор сообщения
3. Приобретенный хэш-вектор шифруется при помощи метода RSAcиспользованием личного ключа отправителя, и итог добавляется в начало сообщения.
4. Получатель употребляет RSAс открытым ключом отправителя, чтоб дешифрировать и вернуть хэш-код.
5. Получатель генерирует новейший хэш-код приобретенного сообщения и ассоциирует его с дешифрованным хэш-кодом. Если хэш-коды совпадают, сообщение считается подлинным.
Схема шифрования сообщения.
Шаги:
1. Отправитель генерирует сообщение и случайное 128-битовое число, которое выступает в качестве сеансового ключа лишь для этого сообщения.
2. Сообщение шифруется при помощи метода CAST-128 (либо IDEA, либо 3DES) и данного сеансового ключа.
3. Сеансовый ключ шифруется при помощи метода RSA и открытого ключа получателя и присоединятся к началу сообщения.
4. Получатель употребляет RSA c личным ключом, чтоб дешифрировать и тем вернуть сеансовый ключ.
5. Сеансовый ключ применяется для дешифрования сообщения.
Схема использования обоих служб (подписи сообщения при помощи личного ключа и его шифровки при помощи сеансового ключа).
Отправитель сообщения:
1. Для сообщения генерируется подпись (хэш-вектор, зашифрованный личным ключом отправителя соединяется воединыжды с открытым текстом сообщения).
2. Подпись и открытый текст сообщения сжимаются zip-ом
3. Сжатый открытый текст сообщения и подпись шифруются при помощи метода CAST -128 (либо IDEA, либо 3DES), а сеансовый ключ шифруется при помощи RSA(либо метода Эль-Гамаля) при всем этом употребляется открытый ключ получателя.
Получатель сообщения
1. Cеансовый ключ дешифруется при помощи личного ключа получателя.
2. При помощи приобретенного сеансового ключа дешифрирует сообщение
3. Распаковка сообщения
4. Открытым ключом отправителя дешифрирует хэш-вектор и генерирует новейший хэш-вектор.
5. Ассоциирует их. Если совпадают — сообщение не было изменено.
Идентификаторы ключей.
Потому что получатель сообщения имеет возможность получать зашифрованные и подписанные сообщения от почти всех участников переписки, как следует он должен иметь несколько пар личный/открытый ключей. Для того, чтоб получателю найти какой личный ключ (метода RSA) нужно употреблять для расшифровки сеансового ключа (метода CAST-128) он получает идентификатор открытого ключа (заместо самого ключа пересылается его идентификатор, потому что сам открытый ключ для RSAможет иметь длину в сотки десятичных разрядов). Идентификатор, связываемый с каждым открытым ключом, располагается в младших 64 разрядах ключа.
Идентификатор ключа требуется и для цифровой подписи PGP. Из-за того что отправитель может пользоваться одним из нескольких личных ключей для шифрования профиля сообщения, получатель должен знать, какой открытый ключ ему следует употреблять. Потому раздел цифровой подписи сообщения включает 64-битовый идентификатор соответственного открытого ключа. При получении сообщения получатель инспектирует, что идентификатор соответствует известному ему открытому ключу отправителя, а потом продолжает проверку подписи.
формат передаваемого сообщения
.
Сообщение
Подпись
Компонент сеансового ключа
содержимое
Данные
Метка даты-времени
Название файла
Профиль сообщения
Ведущие два октета профиля сообщения
Идентификатор открытого ключа отправителя (KUa)
Метка даты-времени
Сеансовый ключ (Ks)
Идентификатор открытого ключа получателя (Rub)
EkRa
EkUa
Операция
ZIP
Eкs
R64
ERUb–шифрование с внедрением личного ключа юзера B
EKRa–шифрование с внедрением открытого ключа юзера А
EКs– шифрование с внедрением сеансового ключа
ZIP – функция сжатия ZIP
R64 – функция преобразования в формат radix-64.
Компонент подписи
включает последующие элементы:
1. Метка даты-времени. Время сотворения подписи
2. Профиль сообщения. 160-битоавый профиль сообщения, сделанный при помощи SHA-1 и шифрованный с внедрением личного ключа подписи отправителя (KRа). Профиль рассчитывается для метки даты-времени подписи, связанной конкатенацией с порцией данных компонента сообщения. Включение метки даты-времени подписи в профиль обеспечивает защиту от атак проигрывания сообщения. Исключение имени файла и метки даты-времени компонента сообщения гарантирует, что отделённая подпись будет в точности совпадать с подписью, добавляемой в префикс сообщения. Отделенные подписи рассчитываются для файла, в каком нет никаких полей заголовка сообщения.
3. Ведущие два октета профиля сообщения. Чтоб обеспечить получателю возможность найти, соответственный ли открытый ключ употреблялся для шифрования профиля сообщения с целью аутентификации, проводится сопоставление этих 2-ух октетов открытого текста начального профиля с первыми 2-мя октетами дешифрованного профиля. Эти октеты также служат 16-битовой последовательностью, применяемой для проверки сообщения.
4. Идентификатор открытого ключа отправителя. Идентифицирует открытый ключ, который должен служить для дешифрования профиля сообщения и, как следует, идентифицирует личный ключ, использовавшийся для шифрования профиля сообщения.
Компонент сообщения и необязательный компонент подписи могут быть сжаты при помощи ZIPи могут быть зашифрованы с внедрением сеансового ключа.
Компонент сеансового ключа включает сеансовый ключ и идентификатор открытого ключа получателя, который употреблялся отправителем для шифрования данного сеансового ключа.
Весь блок обычно переводиться в формат radix-64. Перевод в формат radix-64 употребляется для сопоставимости на уровне электрической почты. Сервис аутентификации подразумевает, что мы шифруем лишь профиль сообщения (цифровая подпись), сервис конфиденциальности подразумевает, что мы шифруем само сообщение (сеансовым ключом) и подпись (при наличии крайней), таковым образом часть либо весь выходной блок сообщения представляет собой поток случайных 8-битовых байтов. Но почти все системы электрической почты разрешают употреблять лишь блоки, состоящие из знаков текста ASCII. Чтоб удовлетворить такому ограничению, PGPобеспечивает сервис конвертирования сырого 8-битового двоичного потока в поток печатаемых знаков ASCII. Для этого употребляется схема конвертирования radix-64.
2. 2.
Система S/MIME.
Система S/MIME (Secure/MultipurposeInternetMailExtension – защищённые многоцелевые расширения электрической почты) является усовершенствованием исходя из убеждений защиты эталона формата MIMEэлектронной почты в Internet, базирующимся на использовании технологии RSADataSecurity.Есть основания считать, что S/MIMEстанет эталоном коммерческого и промышленного использования, в то время как PGPостанется кандидатурой для защиты личной электрической почты большинства личных юзеров.
Эталон MIMEявляется расширением базисного эталона RFC 822, призванным решить некие трудности и преодолеть ограничения протокола SMTP либо некого другого протокола передачи почты, и RFC 822.
Ограничениями протокола SMTP, которые решает MIMEявляются:
1. SMTPне дозволяет передавать исполняемые файлы и остальные объекты в двоичном формате. Существует ряд схем преобразования двоичных файлов в текстовые (к ним относятся Uuencode/Uudecodeдля unix), которые потом могут быть применены разными почтовыми системами SMTP/ Но ни одна из таковых схем не является эталоном.
2. SMTP не дозволяет предавать текстовые данные, включающие знаки государственных языков.
3. Шлюзы SMTP, выполняющие трансляцию кодов ASCII в коды EBCDICи назад, могут иметь различные таблицы перевода, что выливается в трудности трансляции.
Исходя из этих недочетов технические спецификации MIMEвключают последующие элементы:
1. Определяется 5 новейших полей заголовка сообщения, которые могут врубаться в заготовок RFC 822. Эти поля несут внутри себя информацию о теле сообщения.
2. Определяется несколько форматов содержимого, задающих эталоны представления документов мультимедиа в сообщениях электрической почты.
3. Определяются эталоны шифровок передаваемых данных, дозволяющие защитить содержимое сообщения от конфигурации при осуществлении почтовыми системами преобразования передаваемых данных из 1-го формата в иной.
Эталон MIMEопределяет 5 полей заголовка сообщения, любые либо все из которых могут врубаться в заголовок RFC 822:
MIME-
Version (версия
MIME).
Соответственный параметр обязан иметь
Content-
Type (тип содержимого).
Обрисовывает данные, помещённые в тело сообщения, довольно тщательно для того, чтоб агент получателя сумел избрать соответственный агент либо механизм, позволяющий представить приобретенные данные юзеру либо обработать их каким-то другим подходящим образом.
Content-
Transfer-
Encoding (шифровка передаваемого содержания).
Указывается тип преобразования, использовавшегося для того, чтоб представить тело сообщения в виде, применимом для пересылки почтой.
С
ontent-
ID (идентификатор содержимого).
Служит для того, чтоб неповторимым образом идентифицировать объекты MIMEсреди огромного количества контекстов.
Content-
description (описание содержимого).
Текстовые описания объекта в теле сообщения; полезно тогда, когда объект имеет форму, труднодоступную для чтения (к примеру, звуковые данные).
Неважно какая реализация, как минимум, обязана поддерживать обработку полей MIME-Version, Content-Typeи Сontent-Transfer-Encoding.
В S/MIMEзащита объекта MIMEобеспечивается подписью, шифрованием либо и тем, и иным сразу. Объектом MIMEможет быть как всё сообщение (кроме его заголовков RFC 822) либо, в случае многокомпонентного содержимого MIME, одно либо несколько частей сообщения. Объект MIMEготовится в согласовании с обыкновенными правилами подготовки сообщений MIME. Потом объект MIMEвместе с некими связанными с ним данными защиты (к примеру, идентификаторами метода и сертификатов) обрабатывается S/MIME, чтоб в итоге получить то, что обычно именуют объектом PKCS (Public-KeyCryptographySpecification– спецификация криптографии с открытым ключом). С объектом PKCS потом обращаются как с содержимым сообщения, которое упаковывают в MIME (добавляя надлежащие заглавия MIME).
Кроме типов содержимого эталона MIME, в эталоне S/MIMEиспользуются ряд новейших типов содержимого, перечисленные в таблице. Все эти типы содержимого употребляют обозначения PKCS, размещенные RSALaboratoriesи доступные для S/MIME.
Тип
Подтип
Параметр S/MIME
Описание
Multipart (многокомпонентный)
Signed
(подписанный)
Открытое подписанное сообщение из 2-ух частей: сообщения и его подписи
Application (приложение)
pkcs7-mime
signedData
Подписанные объект S/MIME
pkcs7-mime
envelopedData
Шифрованный объект S/MIME
pkcs7-mime
Degenerate signedData
объект, содержащий лишь сертификаты открытых ключей
pkcs7-signature
-
Тип подписи, являющейся частью сообщения типа multipart/signed
pkcs10-mime
-
Сообщение запроса регистрации сертификата.
Формирование объекта
envelopedData (упакованные данные).
При подготовке объекта envelopedDataMIMEдолжны быть выполнены последующие деяния:
1. Генерируется псевдослучайный сеансовый ключ для определенного метода симметричной схемы шифрования (RC2/40 либо 3DES).
2. Для всякого получателя сеансовый ключ шифруется при помощи открытого ключа получателя и RSA.
3. Для всякого получателя готовится блок данных, именуемый RecipientInfo (информация для получателя), содержащий сертификат открытого ключа отправителя, идентификатор метода, использовавшегося для шифрования сеансового ключа, и шифрованный сеансовый ключ.
4. содержимое сообщения шифруется при помощи сеансового ключа.
Блоки RecipientInfo, за которыми следует шифрованное содержимое сообщения, вкупе составляют блок envelopedData. Эта информация потом кодируется в формате base64 (radix-64).
Пример такового файла:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
Формирование объекта
signedData (подписанные данные).
1. Выбирается метод сотворения профиля сообщения (SHA либо MD5).
2. Рассчитывается профиль сообщения (
3. Профиль сообщения шифруется при помощи личного ключа стороны, подписавшей документ.
4. Подготавливается блок, именуемый SignedInfo (информация подписавшей стороны), содержащий сертификат открытого ключа подписавшей документ стороны, идентификатор метода, использовавшегося для шифрования профиля сообщения и шифрованного профиля сообщения.
объект signedDataформируется из ряда блоков, включающих идентификатор метода сотворения профиля сообщения, само подписываемое сообщение и блок SignerInfo. Вся эта информация кодируется в base64. Пример такового сообщения (с исключёнными заголовками RFC 822):
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
Открытое подписанное сообщение.
Открытое подписанное сообщение выходит тогда, когда для содержимого употребляется тип multipartи подтип signed. Сообщение типа multipart/signedвключает две части.
1-ая часть быть может хоть какого типа MIME, но обязана быть подготовлена так, чтоб она не была изменена в пути следования от источника к адресату. Это означает, что если 1-ая часть не представлена в 7-битовой шифровке, то данные нужно кодировать в формат base64. В первой части размещается открытый текст сообщения.
2-ая часть представляет собой отделённую подпись. Она формируется по методу объекта signedData. В итоге создаётся объект в формате signedData, поле содержимого которого оказывается пустым. Потом этот объект кодируется в формат base64, чтоб стать 2-ой частью многокомпонентного сообщения. Для типа MIMEэтой 2-ой части выбирается значение application, а для подтипа — pkcs7-signature. Пример такового сообщения:
Content-Type: multipart/signed;
Protocol=”application/pkcs7- signature”;
Micalg=shal; boundary=boundary42
— boundary42
Content-Type: text/plain
Это открытый текст подписанного сообщения.
— boundary42
Content-Type: application/pkcs7- signature; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Rfvbn765BghyHhUjfewqwnvdCDC7
— boundary42 —
объект является двухкомпонентным открытым подписанным сообщением. части и сравнив его с профилем сообщения, который восстанавливается из подписи во 2-ой части.
Криптографические методы.
В таблице представлены криптографические методы, применяемы в системе S/MIME.
В S/MIMEпринята терминология, предложенная в документе RFC 2119 и позволяющая указать уровень требований.
ОБЯЗАТЕЛЬНО (MUST). Определение является абсолютным требованием спецификации. Неважно какая реализация обязана включать это свойство либо функцию, чтоб соответствовать данной спецификации.
РЕКОМЕНДУЕТСЯ (SHOULD). В определенном окружении могут существовать предпосылки игнорировать это свойство либо функцию, но рекомендуется, чтоб реализация всё же имела соответственное свойство либо функцию.
Функция
Требование
Создание профиля сообщения, применяемого при формировании цифровой подписи.
ОБЯЗАТЕЛЬНА поддержка SHA-1 и MD5
РЕКОМЕНДУЕТСЯ внедрение SHA-1
Шифрование профиля сообщения для формирования цифровой подписи
Для агентов отсылки и приёма ОБЯЗАТЕЛЬНА поддержка DSS
Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования RSA
Для агента приёма РЕКОМЕНДУЕТСЯ поддержка верификации подписей RSAс длиной ключа от 512 до 1024 битов.
Шифрование сеансового ключа для передачи с сообщением
Для агентов отсылки и приёма ОБЯЗАТЕЛЬНО поддержка метода Диффи-Хеллмана.
Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования RSAс длиной ключа от 512 до 1024 битов.
Для агента приёма РЕКОМЕНДУЕТСЯ поддержка дешифрования RSA
Шифрование сообщения для передачи с внедрением сеансового ключа
Для агента отсылки РЕКОМЕНДУЕТСЯ поддержка шифрования tripleDESи RC2/40.
Для агента приёма ОБЯЗАТЕЛЬНА поддержка дешифрования tripleDESи РЕКОМЕНДУЕТСЯ поддержка дешифрования RC2/40.
S/MIMEобъединяет три метода, использующих открытые ключ. Эталон цифровой подписи (метод DSS) является желаемым методом сотворения цифровой подписи. Желаемым методом шифрования сеансовых ключей в S/MIMEназывается метод Диффи-Хеллмана, но практически в S/MIMEиспользуется вариант метода Диффи-Хеллмана, обеспечивающий шифрование/дешифрование и узнаваемый как метод Эль-Гамаля. В качестве кандидатуры как для подписей, так и для шифрования сеансовых ключей может употребляться метод RSA.
Для шифрования сообщений рекомендуется «тройной» DEScтремя ключами (tripleDES), но неважно какая эластичная реализация обязана поддерживать 40-битовую версию метода RC2. Крайний является очень слабеньким методом шифрования, но зато соответствует экспортным требованиям США (Соединённые Штаты Америки — протокол SSL призван обеспечить возможность надежной защиты сквозной передачи данных с внедрением протокола TCP. SSL представляет собой не один протокол, а два уровня протоколов. Протокол записи SSL (SSL Record Protocol) обеспечивает базисный набор средств защиты, используемых протоколами наиболее больших уровней. Эти средства, а именно, может употреблять протокол передачи гипертекстовых файлов (HTTP), призванный обеспечить обмен данными при содействии клиентов и серверов Web. Частью SSL числятся и три протокола наиболее высочайшего уровня: протокол квитирования установления связи (Handshake Protocol), протокол изменения характеристик шифрования (Change Cipher Spec Protocol) и протокол извещения (Alert Protocol). Эти протоколы служат для управления обменом данными SSL.
протокол квитирования
SSL
Протокол конфигурации характеристик шифрования
SSL
протокол уведомления
SSL
FTP,
SMTP, HTTP.
Протокол записи
SSL
TCP
IP
Стек протоколов
SSL.
Меж хоть какой парой обменивающихся информацией сторон (к примеру, приложений типа HTTP клиента и сервера) можно установить много защищенных соединений. На теоретическом уровне меж сторонами можно установить и несколько сразу имеющихся сеансов, но на практике таковая возможность не употребляется.
соединение (connection) — транспорт, обеспечивающий сервис некого пригодного типа (SMTP, HTTPи т.д.) Каждое соединение ассоциируется лишь с одним сеансом.
Сеанс (session). Сеанс SSL — это связь меж клиентом и сервером. Сеансы создаются протоколом квитирования SSL (SSL Handshake Protocol).
Сеанс описывает набор характеристик криптографической защиты, которые могут употребляться несколькими соединениями. Сеансы разрешают избенажимать необходимости ведения переговоров о установлении характеристик защиты для всякого новейшего соединения.
3.2.
протокол записи SSL
Протокол записи SSL (SSL Record Protocol) обеспечивает поддержку 2-ух следующих сервисов для соединений SSL.
• Конфиденциальность. протокол квитирования SSL (SSL Handshake Protocol) описывает общий для клиента и сервера скрытый ключ, используемый методом классической схемы для шифрования данных, передаваемых по протоколу SSL.
• Целостность сообщений. Кроме обеспечения конфиденциальности, протокол квитирования SSL описывает общий скрытый ключ для вычисления значений MAC (Message Authentication Code — код аутентичности сообщения).
порядок отправки данных:
1. Этот протокол, получив сообщение для пересылки иной стороне, поначалу фрагментирует данные, разбивая их на блоки пригодного размера;
2. По мере необходимости выполняет сжатие данных;
3. Применяет метод вычисления MAC;
4. Шифрует данные (MAC +сжатое сообщение);
5. Добавляет заголовок
6. Передает приобретенные пакеты сектору TCP.
При принятии данных: данные дешифруются, проверяются, восстанавливаются, собираются вновь и передаются приложениям наиболее высочайшего уровня.
При вычислении кода аутентичности сообщения употребляется особая схема вычисления MAC, в какой употребляется метод хэширования MD5 либо SHA-1.
Сжатое сообщение вкупе с добавленным к нему значением MACшифруется.
Применяемые методы шифрования:
Блочное шифрование
Поточное шифрование
метод
Размер ключа
Метод
Размер ключа
IDEA
128
RC4-40
40
RC2-40
40
RC4-128
128
DES-40
40
DES
56
3DES
168
Fortezza
80
В случае внедрения алгоритмов поточного шифрования шифруются лишь сжатое сообщение и добавленное к нему
При использовании алгоритмов блочного шифрования опосля значения MAC можно добавлять заполнитель. Заполнитель состоит из некого числа байтов заполнителя, за которыми следует 1-байтовое текст + MAC + заполнитель), будет кратна длине блока шифра.
Оканчивающим шагом в работе протокола записи SSL является создание заголовка, состоящего из последующих полей.
• Тип содержимого
(8 битов). Описывает протокол лежащего выше уровня, при помощи которого должен обрабатываться данный фрагмент.
• Основной номер версии (8 битов). Показывает основной номер версии используемого протокола SSL. Для SSLv3 это поле содержит
• Доп номер версии (8 битов). Показывает доп номер версии используемого протокола SSL. Для SSLv3 это поле содержит
• Длина сжатого фрагмента (16 битов). Длина в б данного фрагмента открытого текста (либо сжатого фрагмента при сжатии). Очень допустимое
Для типа содержимого определены значения change_cipher_spec, alert, handshake и application_data. 1-ые три значения обозначают протоколы стека SSL.
3. 3.
Протокол конфигурации характеристик шифрования
протокол конфигурации характеристик шифрования (Change Cipher Spec Protocol) генерирует однобайтовое сообщение, содержащее состояние, что приводит к обновлению набора шифров, используемых для данного соединения.
3. 4.
протокол уведомления
Протокол уведомления (Alert Protocol) предназначен для передачи иной участвующей в обмене данными стороне уведомлений, касающихся работы SSL. Как и данные хоть какого другого приложения, использующего SSL, сообщения протокола уведомления буквально так же сжимаются и шифруются в согласовании с параметрами текущего состояния.
Сообщение, генерируемое данным протоколом состоит из 2-х байтов: 1-ый б — б – код, обозначающий определенный смысл уведомления. Если в первом б указан уровень неискоренимой ошибки, то протокол SSLразрывает соединение, остальные соединения могут продолжать существовать, но новейшего соединения для данного сеанса сделать уже будет нереально.
В протоколе уведомления существует 5 уведомлений, указывающих на неискоренимую ошибку и 7 уведомлений не указывающих на неискоренимую ошибку.
3. 5.
протокол квитирования.
Этот протокол дозволяет серверу и клиенту выполнить обоюдную аутентификацию, также согласовать методы шифрования, вычисления MAC и криптографические ключи, которые будут служить для защиты данных, пересылаемых в записи SSL. протокол квитирования должен использоваться до начала пересылки данных прикладных программ.
В случае с протоколом квитирования генерируется несколько сообщений, которыми обмениваются клиент и сервер. Хоть какое такое сообщение содержит три последующих поля.
• Тип (1 б). Показывает один из 10 допустимых типов сообщения.
• Длина (3 б). Длина сообщения в б.
• содержимое (> 1 б). Характеристики, связываемые с сообщением данного типа.
В содержимом может находится несколько полей, в любом из которых находятся элементы.
Этапы установления сеанса (session) меж клиентом и сервером.
№ шага
Типы сообщений
Черта шага
1
Определяется черта защиты, включая номер версии протокола, идентификатор сеанса, набор шифров, способ сжатия и начальные случайные числа.
2
может передать сертификат, сообщение обмена ключами и запрос сертификата. Сервер говорит о окончании фазы приветственного сообщения.
3
клиент передаёт сертификат, если он был запрошен. клиент передает сообщение обмена ключами. Клиент может передать сообщение верификации сертификата.
4
Смена набора шифров и окончание работы протокола квитирования
1-ый шаг – определение черт защиты.
процесс инициируется клиентом, который передаёт сообщение серверу client_hello, отвечает сообщением server_helloс избранными параметрами, которые доступны клиенту.
Тип сообщения: client-hello.
Заглавие поля
Черта поля
версия
Наивысший номер версии SSL, поддерживаемый клиентом.
Случайное времени и 28 байтов, приобретенных с помощью защищенного генератора случайных чисел. Эти значения употребляются в качестве оказий во время обмена ключами с целью защиты от атак проигрывания.
Набор шифров
Перечень, содержащий наборы криптографических алгоритмов, поддерживаемых клиентом, перечисленные в порядке убывания их приоритета. Любой элемент перечня (любой набор шифров) определяет метод обмена ключами для схем обычного шифрования, вычислений значений MAC и остальные характеристики шифрования. в server_hello должен найти какой-нибудь набор шифров.
способ сжатия
Перечень способов сжатия, поддерживаемых клиентом. в server_hello должен найти способ сжатии из доступных по списку.
Идентификатор сеанса
Идентификатор переменной длины для данного сеанса. Ненулевое соединение в рамках такого же сеанса. Нулевое соединение в новеньком сеансе.
2-й шаг – Аутентификация сервера и обмен ключами сервера.
Данный шаг начинается с отправки сервером его сертификата, если требуется аутентификация сервера. Сообщение certificate (сертификат) требуется для хоть какого из предлагаемых способов обмена ключами, не считая анонимного метода Диффи-Хеллмана. При использовании способа Диффи-Хеллмана с фиксированными параметрами это сообщение сертификации (certificate) делает функции сообщения обмена ключами (server_key_exchange), так как в нем содержатся предлагаемые сервером открытые характеристики метода Диффи-Хеллмана.
Потом по мере необходимости быть может отправлено сообщение server_key_exchange (обмен ключами сервера). Отправка такового сообщения не требуется в 2-ух вариантах: (1) когда выслал сертификат для способа Диффи-Хеллмана с фиксированными параметрами либо (2) когда предлагается употреблять схему обмена ключами RSA. Сообщение server_key_exchange необходимо в вариантах, когда употребляются последующие схемы.
• Анонимный способ Диффи-Хеллмана.
• Способ Диффи-Хеллмана с разовыми параметрами. Сообщение содержит такие же три параметра, как и в случае анонимного способа Диффи-Хеллмана, и еще подпись для этих характеристик.
• Обмен ключами по схеме RSA, когда использующий RSA имеет ключ RSA лишь для подписи.
• Fortezza.
Опосля этого неанонимный (т.е. , не использующий анонимный способ Диффи-Хеллмана) может запросить сертификат клиента. Сообщение certificate_request (запрос сертификата) включает два параметра: certificate_type (тип сертификата, указывающий на используемый метод шифрования с открытым ключом) и certificate_authorities (центры сертификации). Центры сертификации — перечень имен допустимых центров сертификации.
Крайним (и единственным неотклонимым) сообщением второго шага является сообщение server_done, которым извещает о завершении фазы приветствия сервера ввиду отправки им всех соответственных сообщений. Это сообщение не имеет характеристик. Опосля отправки этого сообщения перебегает в режим ожидания ответа клиента.
3-й шаг — Аутентификация клиента и обмен ключами клиента.
Получив сообщение server_done, клиент должен убедиться в том, что сервер предоставил действительный сертификат (если это требуется) и что характеристики сообщения server_hello являются применимыми. Если проверка заканчивается успешно, клиент оправляет серверу последующие сообщения.
1. Если запросил сертификат, клиент начинает данный шаг с отправки серверу сообщения certificate. Если у клиента пригодного сертификата нет, клиент посылает заместо него извещение no_certificate (нет сертификата).
2. Последующим идет сообщение client_key_exchange (обмен ключами клиента), Содержимое этого сообщения зависит от избранного способа обмена ключами и быть может последующим.
• RSA. клиент генерирует 48-байтовый подготовительный основной ключ и шифрует его при помощи открытого ключа из сертификата сервера либо при помощи временного ключа RSA из сообщения server_key_exchange. Этот подготовительный ключ дозволяет вычислить основной ключ.
• способ Диффи-Хеллмана с разовыми параметрами, либо анонимный способ Диффи-Хеллмана. Отправляются открытые характеристики клиента для способа Диффи-Хеллмана.
• Способ Диффи-Хеллмана с фиксированными параметрами. В данном случае открытые характеристики клиента для способа Диффи-Хеллмана уже были высланы в сообщении certificate, потому содержимое данного сообщения оказывается пустым.
• Fortezza. Отправляются характеристики клиента для метода Fortezza.
В окончание данного шага клиент может выслать сообщение certificate_verify (проверка сертификата), чтоб обеспечить средства прямой верификации сертификата клиента. Это сообщение отчаливает вослед за сертификатом клиента, поддерживающим подпись (т.е. вослед за хоть каким сертификатом клиента, не считая тех, которые содержат характеристики Диффи-Хеллмана с фиксированными параметрами). Сообщение включает подпись хэш-кода предшествующего сообщения.
4-ый шаг – окончание сотворения защищённого соединения.
клиент посылает сообщение change_cipher_spec (изменение характеристик шифрования) и копирует характеристики шифрования из поля «набор шифров» состояния ожидания в поле текущего состояния. Обратите внимание на то, что это сообщение не считается частью протокола квитирования, а отсылается в рамках протокола конфигурации характеристик шифрования (Change Cipher Spec Protocol). В ответ клиент немедля посылает сообщение finished, шифрованное новеньким методом с новенькими ключами и секретными значениями. Сообщение finished подтверждает, что процессы обмена ключами и аутентификации завершились удачно. содержимое сообщения finished представляет собой итог конкатенации последующих 2-ух значений хэш-кода.
MD5 (master_secret || pad_2 || MD5 (handshake_messages || Sender || master_secret || pad_l)),
SHA (master_secret || pad_2 || SHA (handshake_messages || Sender || master_secret || pad_l)),
где Sender — код, указывающий на то, что отправителем является клиент,
handshake_messages — все данные сообщений квитирования, кроме данного сообщения.
master_secret – вместе используемый основной скрытый ключ, представляет собой однократно применяемое 48-байтовое занчение (384 бита), генерируемое для данного сеанса в процессе защищённого обмена данными.
В ответ на эти два сообщения отправляет свое сообщение change_cipher_spec, переводит характеристики шифрования состояния ожидания в текущее состояние и отправляет свое сообщение finished. На этом процесс квитирования заканчивается, и сейчас клиент и сервер могут начать обмен данными на уровне приложения.
3. 6.
Создание головного секретного ключа.
Создание головного ключа состоит из 2-ух шагов. На первом шаге согласуется стороны вычисляют значение главного ключа (master_secret). Для передачи друг другу значения pre_master_secret у сторон имеется два варианта.
• RSA. Генерируемый клиентом 48-байтовый ключ pre_master_secret шифруется при помощи открытого ключа RSA сервера и отчаливает клиентом серверу. дешифрирует приобретенный шифрованный текст при помощи собственного личного ключа и восстанавливает
• Способ Диффи-Хеллмана. И клиент, и сервер генерируют открытые ключи для метода Диффи-Хеллмана. Опосля обмена этими ключами любая сторона делает определенные вычисления по способу Диффи-Хеллмана, в итоге которых выходит вместе применяемое
Сейчас обе стороны могут вычислить
master_secret = MD5 (pre_master_secret ||
SHA (‘A’ || pre_master_secret || ClientHello.random || ServerHello.random)) ||
MD5 (pre_master_secret ||
SHA (‘BB’ || pre_master_secret || ClientHello.random || Server Hello.random)) ||
MD5 (pre_master_secret ||
SHA (‘CCC’ || pre_master_secret || ClientHello.random || ServerHello.random)),
где ClientHello.random и ServerHello.random являются значениями оказий, входящих в уникальные сообщения приветствия сторон (поле «случайное значение»).
3. 7.
Генерирование криптографических характеристик.
Для элемента “Характеристики шифрования” поля “набор шифров” требуются скрытый ключ MAC клиента для записи, скрытый ключ MAC сервера для записи, ключ клиента для записи, ключ сервера для записи, вектор инициализации клиента для записи и вектор инициализации сервера для записи. Все эти характеристики генерируются из головного ключа методом внедрения функции хэширования к основному ключу с целью получения защищенной последовательности байтов достаточной длины.
Процедура генерирования ключей из головного ключа подобна процедуре генерирования головного ключа из подготовительного и показана ниже.
key_block = MD5 (master_secret ||
SHA (‘A’ || master_secret || ServerHello.random || ClientHello.random)) ||
MD5 (master_secret ||
SHA (‘BB’ || master_secret || Server Hello, random || ClientHello.random)) ||
MD5 (master_secret ||SHA(‘CCC’ || master_secret || ServerHello.random || ClientHello.random)) || …
Процедура производится до того времени, пока не будет сгенерирована последовательность достаточной длины. Эта алгоритмическая структура представляет собой псевдослучайную функцию. Значение master_secret можно разглядывать как инициализирующее значения модификаторов (salt values), применяемых с целью усложнения криптоанализа.
3. 8.
Что такое TLS и его отличие от SSL.
протокол TLSпредставляет собой итог инициативы IETF (InternetEngineeringTaskForce– проблемная группа проектирования Internet), целью которой является разработка эталона SSLдля Internet. Текущая версия проекта эталона TLSочень похожа на SSLv3. Разглядим различия меж TLSи SSLv3.
1. Схемы вычислений значений MACэтих протоколов различаются по двум характеристикам: используемому методу и области данных, для которых рассчитывается значение кода аутентичности сообщения.
2. В TLSприменяется PRFфункция. PRFфункция служит для получения маленького по длине секретного значения, которое служит для генерирования наиболее длинноватых блоков данных (используя специальную схему расширения данных где применен метод HMAC), защищённых от атак на функции хэширования и вычисления значений кода аутентичности сообщения. Секретное
3. В TLSне уведомления no_certificate, но определён ряд доп кодов уведомления (их всего 12, 9 из которых означают неискоренимую ошибку).
4. В TLSвключены все методы симметричной схемы шифрования, кроме Fortezza.
5. Сообщение finishedв TLSпредставляет собой хэш-код, вычисленный c помощью master_secret, прошлых сообщений и метки, идентифицирующей клиент и сервер. Схема вычисления сообщения finishedотличается от схемы, применяемой в SSLv3. ВTLS схемывыглядиттак: PRF (master_secret, finished_label, MD5 (handshake_meassages) || SHA-1 (handshake_messages)), где
finished_label – строчка «client finished» дляклиентаи «server_finished» длясервера.
6. Схема вычисления master_secretдля TLSиная чем в SSLv3.
7. В SSLбайты заполнителя добавляются к данным юзера, подлежащим шифрованию, мало нужном количестве, достаточном для того, чтоб получить общую длину данных для шифрования, кратную длине блока шифра. В случае TLSразрешается добавлять хоть какое число наполнителей (до 255 байтов включительно), только бы в итоге длина блока данных вышла кратной длине блока шифра.
4.
защита на уровне IP (сетевой уровень).
4. 1.
Архитектура защиты на уровне
IP
IPSec обеспечивает сервис защиты на уровне IP, позволяя системе избрать нужные протоколы защиты, найти метод (методы) для соответствующего сервиса (сервисов) и задать значения всех криптографических ключей, требуемых для запрошенного сервиса. Для защиты употребляется два протокола: протокол аутентификации, обозначенный заголовком данного протокола (заголовком аутентификации АН), и комбинированный протокол шифрования/аутентификации, определенный форматом пакета для этого протокола (протокола ESP). В данном случае обеспечиваются последующие виды сервиса:
• контроль доступа;
• целостность без установления соединений;
• аутентификация источника данных;
• отторжение воспроизведенных пакетов (форма целостности последовательностей);
• конфиденциальность (шифрование);
• ограниченная конфиденциальность транспортного потока.
В случае ESP есть два варианта: с внедрением и без использования функции аутентификации. Как АН, так и ESP имеют способности контроля доступа, основанного на распределении криптографических ключей и управлении транспортными потоками, относящимися к сиим протоколам защиты.
Вид сервиса
AH
ESP (
лишь шифрование)
ESP (
шифрование и аутентификация)
Контроль доступа
-
-
-
Целостность без установления соединений
-
-
Аутентификация источника данных
-
-
Отторжение воспроизведенных пакетов
-
-
-
Конфиденциальность
-
-
Ограниченная конфиденциальность транспортного потока
-
-
Главным объектом в механизмах аутентификации и конфиденциальности для IP является защищенная связь (Security Association). Связь представляет собой однобокое отношение меж отправителем и получателем, применяющим сервис защиты к транспортному сгустку. Сервис защиты предоставляет возможность для защищенной связи использовать или АН, или ESP, но никак не обе эти способности сразу.
В любом пакете IP защищенная связь совершенно точно идентифицируется адресом пт предназначения в заголовке IPv4 либо IPv6 и индексом параметров защиты (даёт возможност ьвыбрать защищённую связь по которой должен обрабатываться приобретенный пакет) во вложенном заголовке расширения (АН либо ESP).
Заглавия АН и ESP поддерживают два режима использования: транспортный и туннельный. Дадим лаконичный обзором этих режимов.
Транспортный режим.
Транспортный режим обеспечивает защиту до этого всего для протоколов высшего уровня. Это означает, что защита транспортного режима распространяется на нужный груз пакета IP. Примеры включают сектор TCP либо UDP, либо пакет протокола ICMP , которые располагаются конкретно над IP в стеке головного протокола. Когда система употребляет заглавия АН либо ESP над IPv4, полезным грузом являются данные, обычно размещаемые сходу опосля заголовка IP. Для IPv6 полезным грузом являются данные, обычно последующие опосля заголовка IP и всех имеющихся заголовков расширений IPv6, за вероятным исключением заголовка характеристик адресата, который тоже может подлежать защите.
ESP в транспортном режиме шифрует и, если необходимо, идентифицирует полезный груз IP, но не заголовок IP. АН в транспортном режиме идентифицирует нужный груз IP и некие части заголовка IP.
Туннельный режим.
Туннельный режим обеспечивает защиту всего пакета IP. Опосля прибавления к пакету IP полей АН либо ESP весь пакет, вкупе с полями защиты, рассматривается как нужный груз некого новейшего «наружного» пакета IP с новеньким наружным заголовком IP. Весь уникальный, либо внутренний, пакет при всем этом пересылается через «туннель» от одной точки сети IP к иной, и ни один из маршрутизаторов на пути не может проверить внутренний заголовок IP. Ввиду того что уникальный пакет инкапсулирован в новый, больший пакет может иметь совсем остальные адреса источника и адресата, что увеличивает защиту. Туннельный режим употребляется тогда, когда один либо оба конца защищенной связи являются шлюзами защиты, к примеру брандмауэрами либо маршрутизаторами, которые основаны на IPSec. При использовании туннельного режима системы в сетях за брандмауэрами могут производить защищенный обмен данными без внедрения IPSec. Незащищенные пакеты, генерируемые таковыми системами, связываются по туннелям, проложенным через наружные сети при помощи туннельного режима защищенной связи, установленного программным обеспечением IPSec в брандмауэре либо защищенном маршрутизаторе на границе локальной сети.
Многофункциональные способности транспортного и туннельного режимов
Вид заголовка
Транспортный режим защищенной связи
Туннельный режим защищенной связи
АН
Идентифицирует нужный груз IP, также отдельные части заголовка IP и заголовков расширений IPv6
Идентифицирует весь внутренний пакет IP (заголовок и нужный груз внутреннего пакета IP), также отдельные части наружного заголовка IP и наружных заголовков расширений IPv6
ESP
Шифрует нужный груз IP и все заглавия расширений IPv6, последующие за заголовком ESP
Шифрует внутренний пакет IP
ESP
с аутентификацией
Шифрует нужный груз IP и все заглавия расширений IPv6, последующие за заголовком ESP.
Идентифицирует нужный груз IP, но не заголовок IP
Шифрует внутренний пакет IP. Идентифицирует внутренний пакет IP
4. 2.
Заголовок аутентификации (AH).
4. 2. 1.
структура заголовка.
Заголовок аутентификации (АН) обеспечивает поддержку целостности данных и аутентификации пакетов IP. Свойство целостности данных гарантирует невозможность неприметной модификации содержимого пакета в пути следования. Функция аутентификации дает возможность конечной системе либо сетевому устройству идентифицировать юзера либо приложение и соответственно отфильтровать трафик, также защититься от весьма всераспространенных сейчас в Internet атак с заменой сетевых адресов. Заголовок АН также защищает от атак проигрывания сообщений.
Заголовок аутентификации состоит из последующих полей
Последующий заголовок
Длина полезного груза
Зарезервировано
Индекс характеристик защиты
Порядковый номер
Данные аутентификации (переменой длины)
Заголовок аутентификации
IPSec.
— Последующий заголовок. Идентифицирует тип заголовка, следующего конкретно за данным заголовком
— Длина полезного груза (8 битов). Длина заголовка аутентификации в 32-битовых словах, уменьшенная на 2.
— Зарезервировано (16 битов). Для грядущего использования.
— Индекс характеристик защиты (32 бита). Идентифицирует защищенную связь.
— Порядковый номер (32 бита).
— Данные аутентификации (переменной длины). Поле переменной длины , содержащее MAC для данного пакета.
Атаки проигрывания сообщений состоят в том, что противник может получить экземпляр удостоверенного пакета и позднее предъявить его предполагаемому адресату. Повторное получение схожих удостоверенных пакетов IP может каким-то образом нарушить сервис либо иметь какие-то остальные нежелательные последствия.
4. 2. 2.
Внедрение AH в транспортном и туннельном режиме.
В этом подразделе мы разглядим область внедрения аутентификации, обеспечиваемой при помощи протокола АН, и размещение заголовка аутентификации в любом из 2-ух режимов. При всем этом случаи IPv4 и IPv6 несколько различаются.
Для транспортного режима
АН с применением IPv4 данные АН располагаются конкретно опосля необычного заголовка IP и перед полезным грузом IP (к примеру, сектором TCP). Аутентификации подлежит весь пакет, кроме изменяемых полей в заголовке IPv4, которые обнуляются для вычисления значения MAC.
Удостоверяется кроме изменяемых полей
Уникальный заголовок IP
AH
TCP
Данные
Удостоверяется кроме изменяемых полей
В контексте IPv6 данные АН рассматриваются как нужный груз сквозной передачи; т.е. проверка и обработка этих данных промежными маршрутизаторами не предполагается. Потому данные АН располагаются опосля базисного заголовка IPv6 и заголовков расширений транзита, маршрутизации и фрагментации. Заголовок расширения характеристик адресации может располагаться до либо опосля заголовка АН — зависимо от требований семантики. снова же, аутентификация предполагается для всего пакета, кроме изменяемых полей, которые обнуляются для вычисления значения MAC.
Уникальный заголовок IP
Транзит, адресация, маршрутизация, фрагментация
AH
Адресация
TCP
Данные
Для туннельного режима
АН удостоверяется весь уникальный пакет IP, a заголовок АН вставляется меж необычным заголовком IP и новеньким внешним заголовком IP. Внутренний заголовок IP несет адреса оригинальных источника и адресата, в то время как наружный заголовок IP может содержать совсем остальные адреса IP (к примеру, адреса брандмауэров либо других шлюзов защиты).
В туннельном режиме весь внутренний пакет IP, включая весь внутренний заголовок IP, защищается средствами АН. Наружный заголовок IP (а в случае IPv6 и наружные заглавия расширений IP) защищается с исключением изменяемых и непрогнозируемых по значению полей.
Удостоверяется кроме изменяемых полей в новеньком заголовке IP
Новейший заголовок
IP
AH
Уникальный заголовок
IP
TCP
Данные
Удостоверяется кроме изменяемых полей в новеньком заголовке IPи его заголовках расширений
IPv4
Новейший заголовок
IP
Заглавия расширений
AH
Уникальный заголовок
IP
Заглавия расширений
TCP
Данные
IPv
6
4. 3.
протокол
ESP
.
4. 3. 1.
Формат пакета ESP
Поля пакета ESP.
• Индекс характеристик защиты (32 бита). Идентифицирует защищенную связь.
• Порядковый номер (32 бита). случае для АН.
• Нужный груз (переменной длины). Это сектор транспортного уровня (в транспортном режиме) либо пакет IP (в туннельном режиме), который защищается шифрованием.
• Заполнитель (0-255 байтов).
• Длина заполнителя (8 битов). Показывает число байтов заполнителя, непосредственно предыдущего данному полю.
• Последующий заголовок (8 битов). Идентифицирует тип данных, содержащихся в поле данных полезного груза, при помощи идентификации первого заголовка этого полезного груза (к примеру, заголовка расширения IPv6 либо протокола верхнего уровня, такового как TCP).
• Данные аутентификации (переменной длины). Поле переменной длины , содержащее код ICV (IntegrityCheckValue — код контроля целостности), вычисляемый для всего пакета ESP без поля данных аутентификации.
Индекс характеристик защиты
Порядковый номер
Данные полезного груза
Заполнитель (0-255 б)
Длина заполнителя
Последующий заголовок
Данные аутентификации (переменной длины)
Поле заполнителя создано для последующих целей.
• Если метод шифрования просит, чтоб длина открытого текста была кратна некому целому числу байтов (к примеру, длине 1-го блока блочного шифра), поле заполнителя служит для того, чтоб дополнить открытый текст (складывающийся из полей полезного груза, заполнителя, длины заполнителя и последующего заголовка) до подходящей длины.
• формат ESP просит, чтоб поля длины заполнителя и последующего заголовка были выровнены по правому краю в 32-битовом слове. Это эквивалентно требованию, чтоб шифрованный текст имел длину, кратную 32 битам. Поле заполнителя создано для того, чтоб выполнить такое сглаживание.
• Доп наполнение можно употреблять тогда, когда требуется обеспечить частичную конфиденциальность для транспортного потока, чтоб скрыть настоящую длину полезного груза.
4. 3. 2.
Шифрование и методы аутентификации.
Сервис ESP подразумевает шифрование полей полезного груза, заполнителя, длины заполнителя и последующего заголовка.
Имеющиеся на сей день спецификации требуют, чтоб неважно какая реализация поддерживала внедрение метода DES в режиме СВС (режим сцепления шифрованных блоков. Остальные метод которые могут применяться для сервиса ESP:
• «тройной» DES с 3-мя ключами,
• RC5,
• IDEA,
• «тройной» IDEA с 3-мя ключами,
• CAST,
• Blowfish.
Как и АН, протокол ESP поддерживает внедрение значений MAC длиной по дефлоту 96 битов. Так же как и в случае с АН, имеющиеся сейчас спецификации требуют, чтоб неважно какая реализация поддерживала схемы HMAC-MD5-96 и HMAC-SHA-1-96.
4. 3. 3.
Транспортный режим
ESP
.
Транспортный режим ESP служит для шифрования и, если необходимо, аутентификации данных, пересылаемых по протоколу IP (к примеру, сектора TCP). Для этого режима в случае с IPv4 заголовок ESP размещается в пакете IP конкретно перед заголовком транспортного уровня (к примеру, TCP, UDP, ICMP), а концевик (trailer) пакета ESP (содержащий поля заполнителя, длины заполнителя и последующего заголовка) располагается опосля пакета IP; если же употребляется функция аутентификации, то поле данных аутентификации ESP добавляется опосля концевика ESP. Весь сектор транспортного уровня вкупе с концевиком ESP шифруются. Аутентификация обхватывает весь шифрованный текст и заголовок ESP.
Удостоверяется
Шифруется
Уникальный заголовок
IP
Заголовок
ESP
TCP
Данные
Концевик
ESP
Аутентификатор
ESP
В контексте IPv6 данные ESP рассматриваются как созданный для сквозной пересылки нужный груз, не предполагающий проверку либо обработку промежными маршрутизаторами. Потому заголовок ESP располагается опосля основного заголовка IPv6 и заголовков расширений транзита, маршрутизации и фрагментации. Заголовок расширения характеристик адресата быть может помещен до либо опосля заголовка ESP — зависимо от требований семантики. В случае IPv6 шифрование обхватывает весь сектор транспортного уровня вкупе с концевиком ESP, также заголовок расширения характеристик адресата, если этот заголовок располагается опосля заголовка ESP. Аутентификация предполагается для шифрованного текста и заголовка ESP.
Удостоверяется
Шифруется
Оригинальный заголовок
IP
Транзит, адресация, маршрутизация, фрагментация
Заголовок
ESP
адресация
TCP
Данные
Концевик
ESP
Аутентификатор
ESP
В транспортном режиме производятся последующие операции:
1. В узле источника блок данных, состоящий из концевика ESP и всего сегмента транспортного уровня, шифруется, а открытый текст этого блока заизменяется шифрованным текстом, что сформировывает пакет IP для пересылки. Если выбрана функция аутентификации, то добавляется поле аутентификации.
2. Потом пакет направляется адресату. Любой промежный маршрутизатор должен проверить и обработать заголовок IP, также все заглавия расширений IP, доступные в нешифрованном виде. Шифрованный текст при всем этом остается постоянным.
3. Узел адресата инспектирует и обрабатывает заголовок IP и все заглавия расширений IP, доступные в нешифрованном виде. Потом на базе информации индекса характеристик защиты в заголовке ESP дешифруются другие части пакета, в итоге что становится легкодоступным сектор транспортного уровня в виде открытого текста.
Внедрение транспортного режима обеспечивает конфиденциальность для хоть какого применяющего этот режим приложения, что дозволяет избежать необходимости реализации функций обеспечения конфиденциальности в любом отдельном приложении. Этот режим довольно эффективен, а размер добавляемых к
пакету IP данных при всем этом невелик. Недочетом этого режима будет то, что при его использовании не исключается возможность анализа трафика пересылаемых пакетов.
4. 3. 4.
Туннельный режим
ESP
.
Туннельный режим ESP предназначен для шифрования всего пакета IP. Для этого режима заголовок ESP добавляется к пакету как префикс, а потом таковой пакет вкупе с концевиком ESP шифруются. Данный способ можно употреблять, когда требуется исключить возможность атак, построенных на анализе трафика.
Ввиду того чтозаголовок IP содержит адресок пт предназначения и, может быть, директивы начальной маршрутизации вкупе с информацией о параметрах транзита, недозволено просто передать шифрованный пакет IP с добавленным к нему в виде префикса заголовком ESP. Промежные маршрутизаторы не сумеют оработать таковой пакет. Таковым образом, нужно включить весь блок (заголовок ESP, шифрованный текст и данные аутентификации, если они есть) во наружный пакет IP с новеньким заголовком, который будет содержать довольно инфы для маршрутизации, но не для анализа трафика.
Удостоверяется
Шифруется
Новейший заголовок
IP
Заголовок
ESP
Уникальный заголовок IP
TCP
Данные
Концевик
ESP
Аутентификатор
ESP
IPv4
Удостоверяется
Шифруется
Новейший заголовок
IP
Заглавия расширений
Заголовок
ESP
Оригинальный заголовок
IP
Заголовок расширений
TС
P
Данные
Концевик
ESP
Аутентификатор
ESP
IPv6
В то время как транспортный режим подступает для защиты соединений между узлами, поддерживающими сервис ESP, туннельный режим оказывается полезным в конфигурации, которая подразумевает наличие брандмауэра либо другого шлюза защиты, созданного для защиты надежной внутренней сети от наружных сетей. В случае с туннельным режимом шифрование употребляется для обмена лишь меж наружным узлом и шлюзом защиты либо меж 2-мя шлюзами защиты. Это разгружает узлы внутренней сети, избавляя их от необходимости шифрования данных, и упрощает функцию распределения ключей, понижая число требуемых ключей. Не считая того, таковой подход усложняет проблему анализа потока сообщений, направляемых определенному адресату.
Разглядим вариант, когда наружный узел соединяется с узлом внутренней сети, защищенной брандмауэром, и когда ESP употребляется наружным узлом и брандмауэром. Тогда при пересылке сектора транспортного уровня от наружного узла к узлу внутренней сети будут выполнены последующие деяния.
1. Источник готовит внутренний пакет IP с указанием адреса пт назначения, являющегося узлом внутренней сети. К этому пакету в виде префикса добавляется заголовок ESP. Потом пакет и концевик ESP шифруются и к результату могут быть добавлены данные аутентификации. Полученный блок заключается во наружный пакет IP с новеньким заголовком IP (базисный заголовок плюс необязательные расширения, к примеру параметров маршрутизации и транзита для IPv6), в каком адресом пт назначения является адресок брандмауэра.
2. Наружный пакет отчаливает брандмауэру. Любой промежный маршрутизатор необходимо проверить и обработать наружный заголовок IP и все наружные заглавия расширений IP, оставив шифрованный текст постоянным.
3. Брандмауэр-адресат инспектирует и обрабатывает наружный заголовок IP и все наружные заглавия расширений IP. Потом на базе инфы индекса характеристик защиты в заголовке ESP брандмауэр дешифрирует другие части пакета, в итоге что становится легкодоступным внутренний пакет IP в виде открытого текста. Этот пакет позже передается по внутренней сети.
4. Внутренний пакет направляется через маршрутизаторы внутренней сети либо конкретно к узлу-адресату.
4. 4.
Композиция защищённых связей.
Отдельная защищенная связь может употреблять или протокол АН, или ESP, но никак не оба эти протокола сразу. Тем не наименее, время от времени конкретный поток обмена данными может добиваться и сервиса АН, и сервиса ESP. Не считая того, определенному сгустку обмена данными может пригодиться сервис IPSec для связи меж главными узлами и иной сервис для связи меж шлюзами защиты, к примеру брандмауэрами. Во всех этих вариантах одному сгустку для получения всего комплекса услуг IPSec требуется несколько защищенных связей. Тут вводится понятие пучка защищенных связей (
security
association
bundle
),
обозначающее набор защищенных связей, средством которых сгустку обязано предоставляться нужное огромное количество услуг IPSec. При всем этом защищенные связи в пучке могут завершаться в разных конечных точках.
Защищенные связи могут быть объединены в пучки последующими 2-мя способами.
— Транспортная смежность.
Применение наиболее 1-го протокола защиты к одному пакету IP без туннелирования. Этот подход к созданию комбинации АН и ESP оказывается действенным лишь для 1-го уровня вложения: последующие вложения не дают доп выигрыша, поскольку обработка производится в одной инстанции — IPsec (конечного) получателя.
— Повторное туннелирование.
Применение нескольких уровней протоколов защиты при помощи туннелирования IP. Этот подход допускает огромное количество уровней вложения, так как туннели могут начинаться и завершаться в различных использующих IPsec узлах сети вдоль маршрута передачи данных.
Эти два подхода можно соединить (к примеру, организовав в части туннельной защищенной связи меж шлюзами защиты транспортную защищенную связь меж находящимися на пути узлами).
Заключение.
Исходя из рассмотренных уровней защиты потока данных в Webи архитектуры построения сети на базе стека TCP/IPбыл произведён обзор эталонов, имеющихся в истинное время и обеспечивающих надёжную передачу данных (по e-mail), если применяемое нами программное и аппаратное обеспечение поддерживает комплекс требований, изложенных в этих эталонах.
Итак, рекомендуемые меры и средства для защиты электрической переписки:
1. Мощные средства аутентификации, к примеру, разработка двухфакторной аутентификации.
2. Действенное построение и администрирование сети. Речь идет о построении коммутируемой инфраструктуры, мерах контроля доступа и фильтрации исходящего трафика, закрытии «дыр» в программном обеспечении при помощи модулей- «заплаток» и постоянном его обновлении, установке антивирусных программ и многом ином.
3. Тайнописью, основанную на мощных криптоалгоритмах (Симметричные — RC4, RC5, CAST, DES, AES, лучшая длина ключа которых = 128 разрядов, ассиметричные — RSA, Diffie-Hellman и El-Gamal, лучшая длина которых 2048 разряда.
4. Если криптографический метод, применяемый в системе довольно стоек, а генератор случайных чисел, применяемый для сотворения ключей, никуда не годится, хоть какой довольно опытнейший криптоаналитик сначала направит своё внимание конкретно на него.
5. Если удалось сделать лучше генератор, но ячейки компа не защищены, опосля того как в их побывал сгенерированный ключ, грош стоимость таковой сохранности.
6. Следует учесть, что большая часть сбоев в обеспечении информационной сохранности происходит не из-за отысканных слабостей в криптографических методах и протоколах, а из-за возмутительных оплошностей в их реализации.
7. Данная мера, которая в главном употребляется для усиления защиты электрических коммерческих операций, быть может реализована и для защиты обыкновенной e-mail. Это построение многоуровневой эшелонированной системы обороны, которая заключается в реализации защиты на нескольких уровнях модели OSI. к примеру, если какие-то приложения Web имеют интегрированные протоколы защиты данных (для e-mailэто могут быть PGPили S/MIME), внедрение IPSec дозволяет усилить эту защиту.
8. Нужно отметить, что SSL защищает письма лишь при передаче и если не употребляются остальные средства криптозащиты, то письма при хранении в почтовых ящиках и на промежных серверах находятся в открытом виде.
В этом случае нужно употреблять средства шифрования прикладного уровня (S/MIME) либо сеансового уровня (IPSec), на котором реализуется шифрование всего пакета IP (либо TCP зависимо от режима).
Источники инфы:
1. Вильям Столингс, Тайнопись и защита сетей: принципы и практика, 2-е издание: пер. с британского – М, : Издательский дом «Вильямс», 2001.
2. Материалы электрической библиотеки InfoCity. (www.infocity.ru)
3. Материалы сервера www.citforum.ru
]]>