Презентация на тему РАЗДЕЛ 5

секретные данные будут доступны только тем пользователям, которым этот

доступ разрешен (авторизованные пользователи);

Доступности – гарантия того, что авторизованные пользователи всегда получат доступ к данным;

Целостности – гарантия сохранности данными правильных значений, которая обеспечивается запретом для неавторизованных пользователей каким-либо образом модифицировать, разрушать или создавать данные.

целостности и/или доступности информации, а также нелегальное использование других

ресурсов сети.

Атака – реализованная угроза.

Риск – вероятностная оценка величины возможного ущерба, нанесенного успешно проведенной атакой.

потере или раскрытии тех или иных данных?
Кто или что

является возможным источником угрозы, какие атаки возможны в системе?
Какие средства использовать для защиты каждого вида информации?

надежности защиты всех уровней
Использование средств, переходящих при отказе в

состояние максимальной защиты
Единый контрольно-пропускной пункт
Баланс возможного ущерба от реализации угрозы и затрат на ее предотвращение

нежелательных лиц и разрешает вход для легальных пользователей
Для доказательства

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

ресурсам системы, предоставляя каждому из них именно те права,

которые ему были определены администратором.

безопасностью

в публичных сетях.
Выполняет три основные функции:

на границе между частной и публичной сетью

шифрования предусматривают наличие параметра – секретного ключа.
Правило Керкхоффа:
«Стойкость шифра

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

были изложены Клодом Шенноном в 1949 году. Модель является

универсальной – если зашифрованные данные никуда не передаются, отправитель и получатель совмещаются в одном лице, а в роли злоумышленника выступает некто, имеющий доступ к компьютеру в отсутствии владельца.

IBM и в 1976 году рекомендован Национальным бюро стандартов

к использованию в открытых секторах экономики

блок данных размером 64 бита, он делится пополам на

левую (L) и правую (R) части.
На место левой части результирующего блока помещается правая часть исходного блока.
Правая часть результирующего блока вычисляется как сумма по модулю два левой и правой части исходного блока.
На основе случайной двоичной последовательности по определенной схеме в полученном результате выполняются побитные замены и перестановки.
Используемая двоичная последовательность имеет длину 64 бита, из которых 56 действительно случайны, а 8 предназначены для контроля. Эта последовательность и является ключом.

Для повышения криптостойкости иногда используют
тройной алгоритм DES – троекратное шифрование с использованием 2 ключей. Производительность снижается.

AES (advanced Encryption Standard): 128 разрядные ключи (есть возможность использования 192- и 256-разрядных), за один цикл кодируется 128-разрядный блок.

Криптостойкость симметричных алгоритмов во многом зависит от качества ключа. -

Надежность канала передачи ключа второму участнику секретных переговоров. При наличии n абонентов, желающих обмениваться секретными данными по принципу «каждый с каждым», потребуется nx(n-1)/2 ключей, которые должны быть сгенерированы и распределены надежным способом. Количество ключей пропорционально квадрату количества абонентов, что при большом количестве абонентов делает задачу чрезвычайно сложной.

середине 70-х описали принципы шифрования с открытыми ключами.
Одновременно генерируется

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

каналу связи передать некоторое сообщение в защищенном виде.
Получатель

на своей стороне генерирует два ключа: открытый Е и закрытый Д.
Закрытый ключ абонент должен хранить в защищенном месте, а открытый передает всем, с кем хочет поддерживать защищенные отношения.
Открытый ключ используется для шифрования текста, но расшифрован он может быть только с помощью закрытого ключа.
Открытый и закрытый ключи не могут быть независимы между собой, следовательно, существует теоретическая возможность вычисления закрытого ключа по открытому, но это связано с огромным объемом и временем вычислений.

сообщениями, то каждая из общающихся сторон генерирует свою пару

ключей и посылает открытый ключ своему абоненту.
В сети из n абонентов всего будет 2n ключей: n открытых ключей для шифрования и n секретных ключей для дешифрирования.
Таким образом решается проблема масштабируемости – квадратичная зависимость количества ключей от числа абонентов в симметричных алгоритмах заменяется линейной зависимостью в несимметричных алгоритмах. Исчезает задача секретной доставки ключа. Злоумышленнику нет смысла стремиться захватить секретный ключ, поскольку это не дает возможности расшифровать сообщение или вычислить закрытый ключ.

Хотя информация об открытом ключе не является секретной, ее нужно защищать от подлогов, чтобы злоумышленник под видом легального пользователя не навязал свой открытый ключ, после чего он сможет дешифрировать сообщения своим закрытым ключом и рассылать свои сообщения от имени легального пользователя.
Решение этой проблемы – технология цифровых сертификатов. Сертификат – это электронный документ, который связывает конкретного пользователя с конкретным ключом.

открытым ключом. Разработан в 1978 году.
RSA (аббревиатура от фамилий

Rivest, Shamir и Adleman).
RSA стал первым алгоритмом такого типа, пригодным и для шифрования, и для цифровой подписи. Алгоритм используется в большом числе криптографических приложений.
После работы над более чем 40 возможными вариантами, им удалось найти алгоритм, основанный на различии в том, насколько легко находить большие простые числа и насколько сложно раскладывать на множители произведение двух больших простых чисел, получивший впоследствии название RSA.

дайджест-функции).
Эта функция, примененная к шифруемым данным, дает в результате

значение (дайджест), состоящее из фиксированного небольшого числа байтов. Дайджест передается с исходным сообщением. Получатель сообщения, зная какая ОФШ, была применена для получения дайджеста, заново вычисляет его, использую незащищенную часть сообщения. Если полученный и вычисленный дайджесты совпадают, значит, полученное сообщение не подвергалось изменениям.

и целостности данных прикладного уровня, передаваемых между двумя взаимодействующими

приложениями, одно из которых является клиентом, а другое - сервером.

Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет TLS иметь обратную совместимость с SSL 3.0.

Для обеспечения криптозащиты используется связка из закрытых ключей, сертификатов и открытых ключей шифрования. 

Криптографический протокол SSL/TLS

четырех подпротоколов на двух уровнях.
Подпротоколы SSL в модели

TCP/IP

переносит на транспортный уровень сообщения от других подпротоколов SSL,

а также данные, поступающие от прикладного уровня. Сообщения из протокола Записи - это полезная нагрузка для транспортного уровня, обычно TCP.

Протокол Записей обеспечивает безопасность соединения, которая основана на следующих двух свойствах:
Конфиденциальность соединения
Для защиты данных используется один из алгоритмов симметричного шифрования. Ключ для этого алгоритма создается для каждой сессии и основан на секрете, о котором договариваются в протоколе Рукопожатия. Протокол Записи также может использоваться без шифрования.
Целостность соединения
Обеспечивается проверка целостности сообщения с помощью МАС с ключом. Для вычисления МАС используются хэш-функции SHA-1 и MD5. Протокол Записи может выполняться без вычисления МАС.

Протокол записи

– Handshake Protocol) используется для согласования данных сессии между

клиентом и сервером. Он устанавливает набор шифров и задает ключи и параметры безопасности.
Протокол Рукопожатия обеспечивает безопасность соединения, которая основана на следующих свойствах:
 
Участники аутентифицированы с использованием криптографии с открытым ключом. Эта аутентификация может быть необязательной, но обычно требуется по крайней мере для сервера.
Переговоры о разделяемом секрете безопасны, т.е. этот общий секрет невозможно подсмотреть.
Переговоры о разделяемом секрете надежны, если выполнена аутентификация хотя бы одной из сторон. В таком случае атакующий, расположенный в середине соединения, не может модифицировать передаваемый секрет незаметно для участников соединения.

используется для изменения данных ключа - информации, необходимой для

создания ключей шифрования.

Аварийный протокол
(Alert Protocol) нужен, чтобы известить о ситуациях, отклоняющихся от нормы. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
 

протокола рукопожатия достигаются следующие цели:
Устанавливается, какой вариант протокола из

поддерживаемых ( SSLv3, TLSv1, TLSv1.1, TLSv1.2)— будет использоваться. Всегда выбирается самый последний из возможных вариантов, то есть у TLSv1 всегда будет приоритет перед SSLv3 в случае, если и клиент и сервер поддерживают оба варианта. Клиент предлагает список вариантов, а сервер выбирает из предложенного списка.
Отправляются аутентификационные данные. Обычно сервер посылает аутентификационную информацию в форме сертификата X.509 (SSL), но протокол поддерживает и другие методы.
Устанавливается идентификатор (ID) сессии, таким образом, при необходимости сессия может быть перезапущена.
Происходят переговоры о наборе шифров, состоящем из алгоритма обмена ключами вместе с типом алгоритма шифрования объёмных данных и типом MAC, которые будут использоваться в последующей сессии обмена данными (протокол записи). Обычно в качестве алгоритма обмена ключами используется асимметричный алгоритм, такой как RSA, DSA или ECC (Elliptic Curve Cipher, шифр на основе эллиптических кривых, смотрите RFC 5289). Асимметричные алгоритмы потребляют очень много ресурсов процессора и потому для последующего шифрования объемных данных (протокол записи) используются симметричные шифры. Алгоритмы обмена ключами применяются для передачи информации, на основании которой могут быть независимо вычислены сеансовые ключи для симметричного шифра. MAC используется для защиты целостности передаваемых/получаемых данных во время протокола записи.

случайное число и список поддерживаемых алгоритмов – ClientHello
сервер сообщает

выбранную версию протокола, своё случайное число и выбранные алгоритмы – ServerHello

протоколов, поддерживаемые наборы шифров в порядке предпочтения и список

алгоритмов сжатия (обычно NULL). Клиент также посылает случайное значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричного ключа, и идентификатор сессии, который будет равен нулю, если не было предыдущих сессий, либо ненулевому значению, если клиент считает, что предыдущая сессия существует.
Каждый набор шифров состоит из алгоритма обмена ключами, алгоритма шифрования объёмных данных и алгоритма MAC (хэширования).
Набор шифров, используемый и клиентом и сервером, при первоначальном соединении таков:
TLS_NULL_WITH_NULL_NULL (0x00, 0x00)
# первый NULL — алгоритм обмена ключами
# следующий за ним WITH_NULL определяет алгоритм шифрования объёмных данных
# последний NULL определяет MAC

Это значение говорит о том, что шифрование выполняться не будет и потому все сообщения до Client Key Exchange (ClientKeyMessage) будут отправляться открытым текстом.

протокола, набор шифров и алгоритм сжатия. Сервер посылает случайное

значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричных ключей. Если идентификатор сессии в сообщении ClientHello был равен нулю, сервер создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
В RFC 7250 определено расширение server_certificate_format, которое может применяться для указания формата используемого сертификата. Это может быть нормальный формат X.509 или формат RawPublicKey, при котором в последующих сообщениях передачи сертификата протокола рукопожатия сертификат сокращается до одного атрибута subjectPublicKeyInfo.

(X.509 или OpenPGP)
сервер может запросить сертификат клиента, чтобы аутентифицировать

его
клиент проверяет сертификат сервера, используя PKI

открытый ключ сервера, алгоритм которого должен совпадать с алгоритмом

обмена ключами в выбранном наборе шифров. Протокол предлагает и другие методы доставки открытого ключа, — можно, например, просто указать на запись DNS KEY RR, — но сертификат X.509 является стандартным общепринятым методом. Цель данного сообщения — получение клиентом из доверенного источника открытого ключа сервера, который затем может использоваться этим клиентом для отправки зашифрованного сообщения.
RFC 7250 определяет упрощённый формат сертификата, в котором открытый ключ в чистом виде инкапсулируется в обёртку, состоящую из атрибута SubjectPublicKeyInfo (необходимого для описания свойств открытого ключа). Это скромный шаг в сторону более разумного способа обретения открытого ключа непосредственно от аутентифицированного источника, такого как защищённая DNS-запись DNSSEC.

предоставить свой сертификат, тогда сервер, используя PKI, проверяет аутентичность

клиента – так обеспечивается взаимная аутентификация
фаза аутентификации заканчивается сообщ. ServerHelloDone

части данной последовательности диалога и побуждает клиента продолжить последовательность

протокола. Примечание: В этом месте сервер может запросить клиентский сертификат для выполнения взаимной аутентификации.
Примечание: Если во время переговоров об установлении TLS/SSL сервер запросил сертификат клиента, то клиент должен отправить свой сертификат (в том же формате, который определен для сервера, с тем исключением, что RFC 6066 позволяет любому клиенту посылать URL сертификат вместо полного сертификата) непосредственно за сообщением ServerDone и до сообщения ClientKeyExchange.

и пересылает его серверу в сообщении ClientKeyExchange
клиент и сервер

на основе RNc, RNs и PMS генерируют ключ для симметричного криптоалгоритма

key, используя случайные числа (или отметки текущего времени) сервера

и клиента. Он шифрует этот ключ с помощью открытого ключа сервера, полученного из предоставленного сертификата X.509. Только сервер может расшифровать данное сообщение своим закрытым ключом. Обе стороны независимо друг от друга вычисляют общий секретный ключ master key из ключа pre-master, используя определённый в стандарте алгоритм. Любые сеансовые ключи, которые могут потребоваться, будут производными от этого ключа master key.

переходе в режим шифрования ChangeCipherSpec и посылает зашифрованное сообщение

о завершении квитирования с хэшем всех сообщений
сервер посылает ChangeCipherSpec и зашифрованное сообщение о завершении квитирования с хэшем всех сообщений

трафик, исходящий от данного клиента, будет зашифрован с помощью

выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отправляется в открытом виде. Оно часто объединяется с сообщением Client Key Exchange.
Finished — клиент (7): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке.

трафик, исходящий от данного сервера, будет зашифрован с помощью

выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отправляется в открытом виде. Получение данного сообщения неявно говорит клиенту о том, что сервер получил и смог обработать сообщение Finished этого клиента.
Finished — сервер (9): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и включает MAC, о которых договорились стороны. Если клиент может расшифровать это сообщение, используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, клиент прерывает соединение и выдаёт сообщение Alert и подходящий (хотя и не всегда конкретный) код ошибки.

Record Protocol (протокол записи): Последующие сообщения между сервером и клиентом шифруются с помощью алгоритма шифрования объемных данных и включают MAC, о которых договорились стороны.

соединение, а в фазе протокола записи происходит передача (инкапсуляция)

зашифрованного потока данных, таких как HTTP, SMTP или IMAP.
На рисунке чёрными стрелками показаны сообщения, отправляемые открытым текстом, синими — сообщения, отправляемые с использованием открытого ключа, предоставленного сервером (с помощью шифра обмена ключами), зелёными — сообщения, отправляемые с использованием того алгоритма шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.

выдача их и аннулирование, хранение информации, необходимой для последующей

проверки правильности сертификатов.

Центр сертификации (Certification Authority) является основной структурой, формирующей цифровые сертификаты подчиненных центров сертификации и конечных пользователей. Центр сертификации сам генерирует собственный секретный ключ и сертификат, содержащий открытый ключ данного центра.
Удостоверяет аутентичность открытого ключа пользователя своей электронно-цифровой подписью.
Формирует список отозванных сертификатов.
Ведет базы всех изготовленных сертификатов и списков отозванных сертификатов.

клиентом, на веб-сервере долженбыть установлен сертификат подписанный центром сертификатов

(CA). Браузер клиента должен знать этот центр сертификатов (доверять ему). Это значит, что сертификат этого центра сертификатов уже установлен в браузере и срок действия сертификата не истек. Если сертификат не установлен, то при доступе клиента к веб-серверу, у него высветитсясообщение предлагающее принять или отклонить сертификат веб-сервера, так как он подписан неизвестным центром сертификатов.

поиска
Имя издателя
Период действия (не ранее⁄не позднее)
Субъект сертификата
Информация об открытом ключе субъекта
Уникальный

идентификатор издателя
Уникальный идентификатор субъекта
Дополнения
Подпись

получение сертификата для отправки его CA:
o Сгенерировать пару открытый/закрытый

ключ (с помощью утилиты генерации ключей, которая обычно есть в веб-сервере).
o Сгенерировать запрос на получение сертификата, который включает в себя идентифицирующую информацию о компании Элис(Distinguished Name) и открытый ключ.
o Отправить запрос на получение сертификата выбранному CA(например, запрос может быть отправлен почтой).
2. В ответ на запрос CA отправляет Элис цифровой сертификат, в котором содержится открытый ключ Элис, подписанный CA.
3. После получения ответа от CA, Элис помещает цифровой сертификат в базу сертификатов веб-сервера. После того как Элис установила цифровой сертификат подписанный CA, она может начинать работу с клиентами.
Когда Боб обращается к веб-серверу Элис, выполняются
такие действия:

Пользователь Боб и веб-сервер Элис собираются взаимодействовать через защищенный канал. Пользователь использует браузер для доступа к серверу, который поддерживает SSL

броузер Боба автоматически скачает цифровой сертификат с веб-сервера Элис.
5.

Браузер Боба определит доверяет ли он CA, который подписал цифровой сертификат Элис:
o Сертификат CA дожен быть уже установлен в браузере Боба.
o Если сертификат установлен и срок его действия не истек, то дальнейший процесс будет прозрачным для Боба.
o Браузер дешифрует цифровой сертификат Элис с помощью открытого ключа CA, который получен из цифрового сертификата CA.
o Теперь у браузера Боба есть открытый ключ Элис.
6. Боб отправляет Элис сообщение в котором содержится сессионный ключ и шифрует его с помощью открытого ключа Элис:
o Сессионный ключ используется для шифрования трафика между Бобом и Элис.
o Этот ключ симметричный и будет использоваться для шифрования и дешифрования данных передаваемых между Бобом и Элис.
o Так как сообщение можно расшифровать только закрытым ключем Элис, то сессионный ключ безопасно доставляется на веб-сервер Элис.
7. Как только веб-сервер получает сообщение в котором хранится сессионный ключ, он его дешифрует с помощью закрытого ключа Элис.
o Все дальнейшие сообщения шифруются с помощью сессионного ключа (может передаваться информация об адресе, телефоне, кредитной карточке Боба).
o В зависимости от длительности соединения с веб-сервером,может использоваться несколько сессионных ключей, которые будут меняться после истечения их срока жизни.