Б. Проверка подлинности взаимодействующих процессов при прямом обмене сеансовыми ключами

Необходимо рассмотреть процедуры проверки подлинности при прямом обмене с секретным и открытым ключом.

1. Процедура подтверждения подлинности при взаимном обмене с секретным ключом.

Абоненты А и В используют общий для них секретный ключ К_AB, полученный ранее (вне РКС). Процедура выполняется за три шага.

1. А→В: I_А, r₁.

На первом шаге инициатор обмена абонент А передает в открытом виде абоненту В свой идентификатор I_А и случайное число r₁. Это сообщение могло быть послано любым абонентом сети.

2. В→А: К_АВ(f(r₁), I_B, r₂, К_s).

На шаге 2 абонент В генерирует случайное число r₂ и сеансовый ключ K_s, посылает А сообщение, зашифрованное общим секретным ключом К_AB. Абонент может быть уверен, что сообщение пришло от В, т. к. только ему известен ключ К_АВ. Функция f(r₁) подтверждает, что сообщение получено в ответ на сообщение 1, а не является повтором старого сообщения.

3. А→В: К_s(f(r₂)).

На шаге 3 абонент А подтверждает, что сеансовый ключ находится именно у него. На этом процедура завершается.

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

1. А→В: КО_B(r₁, I_А).

На первом шаге абонент зашифровывает сообщение для В с помощью открытого ключа КО_В. Случайное число r₁ и идентификатор абонента А может прочесть только абонент В с помощью секретного личного ключа.

2. В→А: КО_A(f(r₁), r₂, I_B, К_s).

На втором шаге абонент вычисляет функцию f(r₁), генерирует случайное число r₂ и сеансовый ключ К_s и зашифровывает все сообщение с помощью открытого ключа абонента А. Абонент А делает вывод, что сообщение 1 получено абонентом В.

3. А→В: К_s(f(r₂)).

Взаимное опознание заканчивается на шаге 3 получением зашифрованной функции f(r₂). Абонент В убеждается, что сеансовый ключ передан именно абоненту А.

Если даже сеансовые ключи передаются, минуя РКС, то распределение мастер-ключей и индивидуальных ключей абонентов в защищенной корпоративной сети осуществляется ЦРК.

§6. Подтверждение подлинности информации, получаемой по коммуникационной подсети

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

1. получатель должен быть уверен в истинности источника данных;

2. получатель должен быть уверен в истинности представляемых данных;

3. отправитель должен быть уверен в доставке данных получателю;

4. отправитель должен быть уверен в истинности полученного подтверждения о приёме информации.

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

Цифровая подпись сообщения представляет собой контрольную двоичную последовательность. Она получается путем специальных преобразований хэш-функции от данных сообщения и секретного ключа отправителя сообщения. Таким образом, цифровая подпись, с одной стороны, несет в себе контрольную характеристику (хэш-функцию) содержимого сообщения, а с другой - однозначно указывает на связь содержимого сообщения и владельца секретного ключа. Использование хэш-функции позволяет зафиксировать подмену или модификацию данных сообщения. При удовлетворительных результатах проверки цифровой подписи получатель может быть уверен, что полученное сообщение пришло от субъекта, владеющего секретным ключом, и содержательная часть сообщения не подвергалась изменениям. Если цифровая подпись получается в соответствии с официальным государственным стандартом, то она имеет юридическую силу обычной подписи под документом.

Впервые идею цифровой подписи предложили в 1976 году американские специалисты У. Диффи и М. Хеллман. В настоящее время для получения цифровой подписи используются методы, применяемые в шифровании с несимметричными ключами.

Первым по времени изобретения алгоритмом цифровой подписи был разработанный в 1977 году алгоритм RSA. Предложенный в 1984 году алгоритм Т. Эль-Гамаля позволял повысить стойкость подписи при ключе в 64 байта примерно в 1000 раз, но длина самой цифровой подписи увеличивалась в два раза и составляла 128 байт.

Алгоритм Эль-Гамаля послужил основой для разработки национального стандарта США DSА, введенного в 1991 году, и государственного стандарта РФ ГОСТ Р 34.10-94, введенного в действие с 1995 года. В алгоритме DSA удалось сократить длину цифровой подписи до 40 байт при сохранении ее стойкости на прежнем уровне. Дальнейшим развитием стандарта DSA стал стандарт США DSS.

Российский стандарт ГОСТ Р 34.10-94 схож со стандартом DSS, но предполагает более сложный алгоритм вычисления хэш-функции. Стандартом ГОСТ Р 34.10-2001 (вместо ГОСТ Р 34.10-94) определён следующий алгоритм вычисления цифровой подписи и аутентификации сообщения. Отправитель и получатель сообщения имеют в своём распоряжении некоторые открытые атрибуты создания и проверки цифровой подписи: начальный вектор хеширования Н и параметры р, g и а. Параметры вычисляются в соответствии с процедурой ГОСТ.

Отправитель выбирает свой секретный ключ х и вычисляет открытый ключ y = а^х (mod р). Открытый ключ у отсылается получателю. Секретный ключ выбирается из интервала 0 < х < 2²⁵⁶. Число k генерируется в процессе получения подписи сообщения, является секретным и должно быть уничтожено после выработки подписи. Упрощённый алгоритм процедуры выработки подписи включат следующие шаги.

1. Вычисление хэш-функции h(М) от сообщения М.

2. Получение целого числа k, 0 < k < g.

3. Вычисление значений r = а^k(mod р) и r' = r (mod g). Если r' = 0, перейти к шагу 2.

4. Вычисление значения s = (хr'+kh (М)) (mod g). Если s = 0, то переход к шагу 2, иначе конец работы алгоритма.

Цифровой подписью сообщения М является вектор <r'>₂₅₆||<s>₂₅₆, который состоит из двух двоичных слов по 256 бит каждое, т. е. длина цифровой подписи составляет 512 бит.

Для проверки подписи (верификации сообщения) получатель сообщения выполняет следующие шаги.

1. Проверка условий: о < s < g и о < r' < g. Если хотя бы одно условие не выполнено, то подпись считается недействительной.

2. Определяется хэш-функция h(М1) от полученного сообщения М1.

3. Вычисляется значение v = (h(М₁))^g-2(mod g).

4. Вычисляются значения z₁= sv(mod g), z₂= (g-r')v(mod g).

5. Вычисление значения u = (а^z1у^z2(mod р))(mod g).

6. Проверка условия: r' = u.

Если условие выполнено, то получатель считает, что полученное сообщение подписано отправителем, от которого был получен ключ у. Кроме того, получатель считает, что в процессе передачи целостность сообщения не нарушена. В противном случае подпись считается недействительной и сообщение отвергается.

Имея открытые атрибуты цифровой подписи и тексты открытых сообщений, определить секретный ключ х можно только путём полного перебора. Причём при длине цифровой подписи 40 байт стандарт DSA гарантирует число комбинаций ключа 1021. Для получения ключа перебором потребуется 30 лет непрерывной работы 1000 компьютеров производительностью 1 млрд. операций в секунду.

Использование цифровой подписи для аутентификации коротких сообщений, подтверждающих прием информационных сообщений, существенно увеличивает длину служебного подтверждающего сообщения. Для подписи служебного сообщения может быть использована подпись полученного информационного сообщения, модифицированная по определенному алгоритму. Например, выбраны разряды по маске. Если в сети реализован режим передачи пакетов, то цифровая подпись передается в конце всего сообщения, а не с каждым пакетом. Иначе трафик в сети увеличится. Степень увеличения трафика будет зависеть от длины пакета. При длине информационной части пакета в 2048 бит использование цифровой подписи каждого пакета привело бы к возрастанию трафика примерно на 25%.

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