Лекции по "Информационной безопасности"

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

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

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

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

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

Закон определяет сведения, которые должен содержать сертификат ключа подписи:

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

Можно сформулировать следующие требования к цифровой подписи:

1. Подпись должна быть битовым образцом, который зависит от подписываемого сообщения.
2. Подпись должна использовать некоторую уникальную информацию отправителя для предотвращения подделки или отказа.
3. Создавать цифровую подпись должно быть относительно легко.
4. Должно быть вычислительно невозможно подделать цифровую подпись как созданием нового сообщения для существующей цифровой подписи, так и созданием ложной цифровой подписи для некоторого сообщения.
5. Цифровая подпись должна быть достаточно компактной и не занимать много памяти.

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

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

Прямая и  арбитражная цифровые подписи

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

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

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

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

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

Симметричное  шифрование, арбитр видит сообщение:

Х A: M || E_Kxa [ ID_X || H (M)]

Предполагается, что отправитель Х и арбитр А разделяют секретный ключ K_ХА и что А и Y разделяют секретный ключ K_АY. Х создает сообщение М и вычисляет его хэш-значение Н (М). Затем Х передает сообщение и подпись А. Подпись состоит из идентификатора Х и хэш-значения, все зашифровано с использованием ключа K_ХА. А дешифрует подпись и проверяет хэш-значение.

A Y: Е_Кay [ ID_X || M ||

       E_Kxa [ID_X || H (M)], T ]

Затем А передает сообщение к Y, шифруя его K_AY. Сообщение включает ID_X, первоначальное сообщение от Х, подпись и отметку времени. Y может дешифровать его для получения сообщения и подписи. Отметка времени информирует Y о том, что данное сообщение не устарело и не является повтором. Y может сохранить М и подпись к нему. В случае спора Y, который утверждает, что получил сообщение М от Х, посылает следующее сообщение к А:

Е_Кay [ ID_X || M || E_Kxa [ID_X || H (M)] ]

Арбитр использует K_AY для получения ID_Х, М и подписи, а затем, используя K_ХА, может дешифровать подпись и проверить хэш-код. По этой схеме Y не может прямо проверить подпись Х; подпись используется исключительно для разрешения споров. Y считает сообщение от Х аутентифицированным, потому что оно прошло через А. В данном сценарии обе стороны должны иметь высокую степень доверия к А:

1. Х должен доверять А в том, что тот не будет раскрывать K_ХА и создавать фальшивые подписи в форме Е_Kка [ID_X || H (M)].
2. Y должен доверять А в том, что он будет посылать Е_Kay [ ID_X || M || E_Kxa [ID_X || H (M)] ] только в том случае, если хэш-значение является корректным и подпись была создана Х.
3. Обе стороны должны доверять А в решении спорных вопросов.

Симметричное  шифрование, арбитр не видит сообщение:

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

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

X A: ID_X || E_Kхy [M] ||

       E_Kxa [ID_X || H (E_KXY [M]) ]

Х передает А свой идентификатор, сообщение, зашифрованное K_XY, и подпись. Подпись состоит из идентификатора и хэш-значения зашифрованного сообщения, которые зашифрованы с использованием ключа K_ХА. А дешифрует подпись и проверяет хэш-значение. В данном случае А работает только с зашифрованной версией сообщения, что предотвращает его чтение.

A Y: E_Kay [ ID_X || E_KXY[M] ||

       E_Kxa [ ID_X || H ( E_KXY [M])], T]

А передает Y все, что он получил от Х плюс отметку времени, все шифруя с использованием ключа K_AY.

Хотя арбитр и не может прочитать сообщение, он в состоянии предотвратить подделку любого из участников, Х или Y. Остается проблема, как и в первом сценарии, что арбитр может сговориться с отправителем, отрицающим подписанное сообщение, или с получателем, для подделки подписи отправителя.

Шифрование  открытым ключом, арбитр не видит сообщение:

Все обсуждаемые  проблемы могут быть решены с помощью  схемы открытого ключа.

X A: ID_X || E_KRх [ ID_X || E_KUy [E_KRx [M] ] ]

В этом случае Х осуществляет двойное шифрование сообщения М, сначала своим закрытым ключом KR_X, а затем открытым ключом Y   KU_Y. Получается подписанная секретная версия сообщения. Теперь это подписанное сообщение вместе с идентификатором Х шифруется KR_X и вместе с ID_X посылается А. Внутреннее, дважды зашифрованное, сообщение недоступно арбитру (и всем, исключая Y). Однако А может дешифровать внешнюю шифрацию, чтобы убедиться, что сообщение пришло от Х (так как только Х имеет KR_X). Проверка дает гарантию, что пара закрытый/открытый ключ законна, и тем самым верифицирует сообщение.

A Y: E_KRa [ ID_X || E_KUy [E_KRx [M] ] || T ]

Затем А передает сообщение Y, шифруя его KR_A. Сообщение включает ID_X, дважды зашифрованное сообщение и отметку времени.

Эта схема имеет  ряд преимуществ по сравнению  с предыдущими двумя схемами. Во-первых, никакая информация не разделяется  участниками до начала соединения, предотвращая договор об обмане. Во-вторых, некорректные данные не могут быть посланы, даже если KR_X скомпрометирован, при условии, что не скомпрометирован KR_А

Стандарт цифровой подписи DSS

Национальный институт стандартов и технологии США (NIST) разработал федеральный  стандарт цифровой подписи   DSS (Digital Signature Standard). Криптостойкость основана на вычислительной сложности задачи логарифмирования целых чисел в конечных полях.

Для создания цифровой подписи используется Асимметричный алгоритм ElGamal. В качестве хэш-алгоритма стандарт предусматривает использование алгоритма SHA-1 (Secure Hash Algorithm). DSS первоначально был предложен в 1991 году и пересмотрен в 1993 году в ответ на публикации, касающиеся безопасности его схемы.

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

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

 
Рис. 3.  Создание и проверка подписи с помощью стандарта DSS

DSS использует сильную хэш-функцию. Для начала вычисляется открытый ключ y из закрытого ключа x как у = g^x mod p. Для создания подписи отправитель вычисляет две величины, r и s, которые являются функцией от компонент открытого ключа (p, q, g), закрытого ключа пользователя (х), хэш-кода сообщения Н (М) и целого k, которое должно быть создано случайно или псевдослучайно и должно быть уникальным при каждом подписывании.

r = (g^k mod p) mod q

s = [ k^-1 (H (M) + xr) ] mod q

Подпись = (r, s)

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

w = s^-1 mod q

u₁ = [ H (M) w ] mod q

u₂ = r w mod q

v = [ (g^u1 y^u2) mod p ] mod q

подпись корректна, если v = r

Стандарт цифровой подписи ГОСТ 3410

В отечественном  стандарте ГОСТ 3410, принятом в 1994 году, используется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS. Оба алгоритма относятся к семейству алгоритмов ElGamal.

В стандарте ГОСТ 3410 используется хэш-функция ГОСТ 3411, которая создает хэш-код длиной 256 бит.