48.Эцп на базе эллиптической кривой.

ГОСТ Р 34.10-2001 основан на эллиптических кривых. Его стойкость основывается на сложности вычисления дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции по ГОСТ Р 34.11-94.

После подписывания сообщения М к нему дописывается цифровая подпись размером 512 бит и текстовое поле. В текстовом поле могут содержаться, например, дата и время отправки или различные данные об отправителе:

СООБЩЕНИЕ М

+

ЦП

Текст

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

Механизм генерации параметров определяется на месте в зависимости от разрабатываемой системы.

Цифровая подпись (ECDSA)

- Алиса хочет послать подписанное сообщение Бобу. У нее есть пара ключей (d_A, Q_A)

- Пусть m – отправленное сообщение, L_n – длина числа n в битах

- Генерация подписи:

1.Вычислить e=HASH(m) и получить z: L_n старших бит e.

2.Сгенерировать случай k из [1, n-1]

3.Получить r=x₁(mod n), где (x₁, y₁)=kG

4.Вычислить s=k­^-1(z+rd_A) (mod n)

5.Если r=0 или s=0, повторить с шага 2

6.Подпись: пара (r, s)

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

Если известно, что n различных сообщений были отправлены с одним и тем же k, то из пары уравнений, используемых на шаге 4, легко получить k, а затем и d_A.

Криптостойкость цифровой подписи опирается на две компоненты — на стойкость хэш-функции и на стойкость самого алгоритма шифрования.

49. Протоколы установления подлинности. Парольные системы разграничения доступа.Протокол рукопожатия.

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

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

Kerberos — защищенный протокол аутентификации, применяемый в локальных сетях. В настоящее время используется пятая версия этого протокола (Kerberos v5). Поддержка протокола Kerberos включена во многие операционные системы — Windows 2000/2003, SunSolaris, Linux, FreeBSD и другие. Kerberos является двусторонним протоколом аутентификации, его описание приведено в RFC 1510 и 1964.

Основными компонентами системы Kerberos являются:

• KeyDistributionCenter (KDC);

• Ticket-grantingticket (TGT);

• Serviceticket (ST).

KDC является посредником между клиентом и сервером. При первоначальной аутентификации после проверки имени и пароля клиент получает специальный билет (ticket), дающий возможность обращаться к службе KDC за сервисными билетами. Этот билет носит названиеticket-grantingticket (TGT). В дальнейшем, когда клиенту нужно получить билет на доступ к серверу, он обращается к KDC, предъявляя свой TGT. Протоколы аутентификации РАР и CHAP

Протоколы аутентификации РАР (PasswordAuthenticationProtocol) и CHAP (ChallengeHandshakeAuthenticationProtocol) применяются в сценариях удаленного доступа для аутентификации клиентов. Они поддерживаются практически всеми клиентами и серверами удаленного доступа. РАР и CHAP — односторонние протоколы.

Протокол РАР — незащищенный протокол, передающий имя и пароль пользователя в открытом виде.

Протокол CHAP описан в RFC 1994. Он использует механизм вызов-ответ (challenge-response) для передачи серверу MDS-хэшаидентификатора вызова, самого вызова (8 случайных байт) и пароля пользователя.

Расширяемый протокол аутентификации (ExtensibleAuthenticationProtocol, ЕАР) Достигается это за счет того, что ЕАР определяет лишь общие черты процесса аутентификации и форматы пактов, в то время как реальная аутентификация производится дополнительным модулем, «подключаемым» к ЕАР. Изначально ЕАР был разработан для аутентификации протокола РРР, но в дальнейшем был адаптирован и для сетей Ethernet (EAfOL). Пакет протокола ЕАР содержит поле Туре, определяющее реальный механизм аутентификации. Использование различных механизмов аутентификации совместно с ЕАР определено в различных документах RFC. Например, если поле Туре=4 (RFC 3748), то это значит, что применяется механизм аутентификации MD5-Challenge (аналогичен CHAP). Если же Туре=13 (RFC 2716), то используется аутентификация с помощью смарт-карт или сертификатов.

Протокол Рукопожатия.

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

Протокол Рукопожатия включает следующие шаги:

1. Обмен сообщениями Hello для согласования алгоритмов, обмен случайными значениями и проверка возобновляемости сессии.

2. Обмен необходимыми криптографическими параметрами, которые позволяют клиенту и серверу согласовать премастер-секрет (клиент посылает премастер-секрет серверу).

3. Обмен сертификатами и криптографической информацией, что позволяет клиенту и серверу аутентифицировать друг друга.

4. Предоставление параметров безопасности на уровень Записи.

5. Возможность клиенту и серверу проверить, что они вычислили одни и те же параметры безопасности и что Рукопожатие произошло без вмешательства злоумышленника.

Протокол разработан для минимизации риска атак типа встреча посередине, но защита от атак, при которых злоумышленник может блокировать доступ к порту, где функционирует сервис безопасности, и попытаться стать участником переговоров аутентифицированного соединения, не предусмотрена. Фундаментальное правило состоит в том, что протоколы более высокого уровня должны учитывать свои требования к безопасности и никогда не передавать информацию по менее безопасному каналу, чем требуется. Протокол TLS является безопасным, и выбранный набор алгоритмов обеспечивает соответствующий уровень безопасности. Например, если в результате переговоров были выбраны 3DES, 1024-битный ключ RSA и сертификат сервера проверен, соединение можно считать безопасным.

пример

Данные цели достигаются протоколом Рукопожатия, который можно просуммировать следующим образом. Клиент посылает сообщение ClientHello, на которое сервер должен ответить сообщением ServerHello или фатальной ошибкой и прерыванием соединения. После сообщений Hello сервер посылает сертификат для аутентификации. Если сервер аутентифицирован, он может запросить сертификат клиента, если того требует установленная политика безопасности. Теперь сервер посылает сообщение ServerHelloDone, указывающее на то, что фаза Hello-сообщений Рукопожатия завершена. Затем сервер ждет ответа клиента. Если сервер послал сообщение запроса сертификата, клиент должен послать сообщение Certificate. После этого посылается сообщение обмена ключа клиента, содержимое этого сообщения зависит от выбранного алгоритма открытого ключа в сообщениях ClientHello и ServerHello. Если клиент имеет сертификат для подписывания, то посылается сообщение цифровой подписи для явной проверки всех сообщений Рукопожатия.

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