 |
|
Стандарт цифровой подписи ГОСТ Р34.10-94
В России принят стандарт ГОСТ Р34.10-94 "Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма". В этом стандарте используется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS. Рассмотрим вначале полностью алгоритм, описанный в ГОСТ Р34.10-94, а затем отметим его отличия от алгоритма DSA.
Вначале, так же как и по стандарту DSS, для группы абонентов выбираются три общих (несекретных) параметра р, q и a:
· параметр р должен быть простым числом длиной от 512 до 1024 бит. Старший бит в р должен быть равен единице.
· q – простое число длиной 254-256 бит; так же как и в DSA, q должно быть делителем числа (р-1). Старший бит в q должен быть равен единице.
· число а, удовлетворяющее неравенству 1 < a < p-1 и являющееся корнем уравнения aq mod p = 1.
· Затем каждый пользователь может сформировать закрытый и открытый ключи. В качестве закрытого ключа выбирается произвольное число х, 0 < x < q. Открытым ключом является число y, получаемое по формуле
y = аx mod pДля создания каждой новой подписи каждый раз выбирается новое случайное число k, 0 < k < q.
Подпись сообщения m состоит из двух чисел (r, s), вычисляемых по следующим формулам:
r = (аk mod p) mod q,s = (k * H(m) + x * r) mod q,где H(m) – результат вычисления хеш-функции для сообщения m.
На этом формирование подписи закончено, и сообщение m вместе с ЭЦП (r,s) может быть отправлено получателю. Теперь отметим отличия алгоритма формирования ЭЦП по ГОСТ Р34.10-94 от алгоритма DSS.
1. Перед вычислением подписи исходное сообщение обрабатывается разными функциями хеширования: в ГОСТ Р34.10-94 применяется отечественный стандарт на хеш-функцию ГОСТ Р34.11-94, в DSS используется SHA-1, которые имеют разную длину хеш-кода. Отсюда и разные требования на длину простого числа q: в ГОСТ Р34.10-94 длина q должна быть от 254 до 256 бит, а в DSS длина q должна быть от 159 до 160 бит.
2. По-разному вычисляется компонента s подписи. В ГОСТ Р34.10-94 компонента s вычисляется по формуле
s = (k * H(m) + x * r) mod q,а в DSS компонента s вычисляется по формуле
s = [k-1 (H(m) + x * r)] mod q.Последнее отличие приводит к соответствующим отличиям в формулах для проверки подписи.
В результате процедура проверки подписи по ГОСТ Р34.10-94 заключается в следующем. Получив [m, (r, s)], получатель вычисляет
w = H(m)-1mod q,u1 = w * s mod q,u2 = (q-r) * w mod q,v = [(аu1 * yu2) mod p] mod q.Затем проверяется равенство вычисленного значения v и полученного в составе ЭЦП параметра r. Подпись считается корректной, если v = r.
В алгоритме создания ЭЦП по ГОСТ Р34.10-94, так же как и в алгоритме DSS, производятся достаточно сложные вычисления, требующие затрат вычислительных ресурсов. Для ускорения процесса генерации подписей по этим алгоритмам можно заранее вычислять некоторое количество значений параметра r, не зависящего от подписываемого сообщения. Затем эти значения можно использовать по мере необходимости для подписи документов. Для алгоритма DSS заранее может вычисляться и значение k-1.
№ 21 ФЗ №63 «Об электронной подписи»:
¾ Использование простой электронной подписи.
¾ Признание квалифицированной электронной подписи.
¾ Сертификат ключа проверки электронной подписи
¾ Принципы использования электронной подписи.
¾ Виды электронной подписи.
¾ Условия признания документов, подписанных электронной подписью, равнозначными на бумажном носителе, подписанным собственноручной подписью.
¾ Функции удостоверяющего центра.
¾ ) электронная подпись - информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию;
¾
¾ 2) сертификат ключа проверки электронной подписи - электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу сертификата ключа проверки электронной подписи;
¾
¾ Принципами использования электронной подписи являются:
¾
¾ 1) право участников электронного взаимодействия использовать электронную подпись любого вида по своему усмотрению, если требование об использовании конкретного вида электронной подписи в соответствии с целями ее использования не предусмотрено федеральными законами или принимаемыми в соответствии с ними нормативными правовыми актами либо соглашением между участниками электронного взаимодействия;
¾
¾ 2) возможность использования участниками электронного взаимодействия по своему усмотрению любой информационной технологии и (или) технических средств, позволяющих выполнить требования настоящего Федерального закона применительно к использованию конкретных видов электронных подписей;
¾
¾ 3) недопустимость признания электронной подписи и (или) подписанного ею электронного документа не имеющими юридической силы только на основании того, что такая электронная подпись создана не собственноручно, а с использованием средств электронной подписи для автоматического создания и (или) автоматической проверки электронных подписей в информационной системе.
¾ Статья 9. Использование простой электронной подписи
¾
¾
¾ 1. Электронный документ считается подписанным простой электронной подписью при выполнении в том числе одного из следующих условий:
¾ 1) простая электронная подпись содержится в самом электронном документе;
¾
¾ 2) ключ простой электронной подписи применяется в соответствии с правилами, установленными оператором информационной системы, с использованием которой осуществляются создание и (или) отправка электронного документа, и в созданном и (или) отправленном электронном документе содержится информация, указывающая на лицо, от имени которого был создан и (или) отправлен электронный документ.
¾
¾ 2. Нормативные правовые акты и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
¾ 1) правила определения лица, подписывающего электронный документ, по его простой электронной подписи;
¾
¾ 2) обязанность лица, создающего и (или) использующего ключ простой электронной подписи, соблюдать его конфиденциальность.
¾
¾ 3. К отношениям, связанным с использованием простой электронной подписи, в том числе с созданием и использованием ключа простой электронной подписи, не применяются правила, установленные статьями 10 - 18 настоящего Федерального закона.
¾
¾ 4. Использование простой электронной подписи для подписания электронных документов, содержащих сведения, составляющие государственную тайну, или в информационной системе, содержащей сведения, составляющие государственную тайну, не допускается.
¾ Статья 5. Виды электронных подписей
¾
¾
¾ 1. Видами электронных подписей, отношения в области использования которых регулируются настоящим Федеральным законом, являются простая электронная подпись и усиленная электронная подпись. Различаются усиленная неквалифицированная электронная подпись (далее - неквалифицированная электронная подпись) и усиленная квалифицированная электронная подпись (далее - квалифицированная электронная подпись).
¾
¾ 2. Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
¾
¾ 3. Неквалифицированной электронной подписью является электронная подпись, которая:
¾
¾ 1) получена в результате криптографического преобразования информации с использованием ключа электронной подписи;
¾ 2) позволяет определить лицо, подписавшее электронный документ;
¾ 3) позволяет обнаружить факт внесения изменений в электронный документ после момента его подписания;
¾ 4) создается с использованием средств электронной подписи.
¾
¾ 4. Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
¾
¾ 1) ключ проверки электронной подписи указан в квалифицированном сертификате;
¾ 2) для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
¾
¾ 5. При использовании неквалифицированной электронной подписи сертификат ключа проверки электронной подписи может не создаваться, если соответствие электронной подписи признакам неквалифицированной электронной подписи, установленным настоящим Федеральным законом, может быть обеспечено без использования сертификата ключа проверки электронной подписи.
¾ Статья 11. Признание квалифицированной электронной подписи
¾
¾
¾ Квалифицированная электронная подпись признается действительной до тех пор, пока решением суда не установлено иное, при одновременном соблюдении следующих условий:
¾
¾ 1) квалифицированный сертификат создан и выдан аккредитованным удостоверяющим центром, аккредитация которого действительна на день выдачи указанного сертификата;
¾
¾ 2) квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен;
¾
¾ 3) имеется положительный результат проверки принадлежности владельцу квалифицированного сертификата квалифицированной электронной подписи, с помощью которой подписан электронный документ, и подтверждено отсутствие изменений, внесенных в этот документ после его подписания. При этом проверка осуществляется с использованием средств электронной подписи, получивших подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом, и с использованием квалифицированного сертификата лица, подписавшего электронный документ;
¾
¾ 4) квалифицированная электронная подпись используется с учетом ограничений, содержащихся в квалифицированном сертификате лица, подписывающего электронный документ (если такие ограничения установлены).
¾ 1. Удостоверяющий центр:
¾
¾ 1) создает сертификаты ключей проверки электронных подписей и выдает такие сертификаты лицам, обратившимся за их получением (заявителям);
¾ 2) устанавливает сроки действия сертификатов ключей проверки электронных подписей;
¾ 3) аннулирует выданные этим удостоверяющим центром сертификаты ключей проверки электронных подписей;
¾ 4) выдает по обращению заявителя средства электронной подписи, содержащие ключ электронной подписи и ключ проверки электронной подписи (в том числе созданные удостоверяющим центром) или обеспечивающие возможность создания ключа электронной подписи и ключа проверки электронной подписи заявителем;
¾ 5) ведет реестр выданных и аннулированных этим удостоверяющим центром сертификатов ключей проверки электронных подписей (далее - реестр сертификатов), в том числе включающий в себя информацию, содержащуюся в выданных этим удостоверяющим центром сертификатах ключей проверки электронных подписей, и информацию о датах прекращения действия или аннулирования сертификатов ключей проверки электронных подписей и об основаниях таких прекращения или аннулирования;
¾ 6) устанавливает порядок ведения реестра сертификатов, не являющихся квалифицированными, и порядок доступа к нему, а также обеспечивает доступ лиц к информации, содержащейся в реестре сертификатов, в том числе с использованием информационно-телекоммуникационной сети "Интернет";
¾ 7) создает по обращениям заявителей ключи электронных подписей и ключи проверки электронных подписей;
¾ 8) проверяет уникальность ключей проверки электронных подписей в реестре сертификатов;
¾ 9) осуществляет по обращениям участников электронного взаимодействия проверку электронных подписей;
¾ 10) осуществляет иную связанную с использованием электронной подписи деятельность.
¾
¾ Статья 14. Сертификат ключа проверки электронной подписи
¾
¾
¾ 1. Удостоверяющий центр осуществляет создание и выдачу сертификата ключа проверки электронной подписи на основании соглашения между удостоверяющим центром и заявителем.
¾
¾ 2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:
¾ 1) даты начала и окончания срока его действия;
¾ 2) фамилия, имя и отчество (если имеется) - для физических лиц, наименование и место нахождения - для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;
¾ 3) ключ проверки электронной подписи;
¾ 4) наименование используемого средства электронной подписи и (или) стандарты, требованиям которых соответствуют ключ электронной подписи и ключ проверки электронной подписи;
¾ 5) наименование удостоверяющего центра, который выдал сертификат ключа проверки электронной подписи;
¾
¾ 6) иная информация, предусмотренная частью 2 статьи 17 настоящего Федерального закона, - для квалифицированного сертификата.
¾ Удостоверяющий центр, указанный в части 4 настоящей статьи, по отношению к доверенным лицам является головным удостоверяющим центром и выполняет следующие функции:
¾ 1) осуществляет проверку электронных подписей, ключи проверки которых указаны в выданных доверенными лицами сертификатах ключей проверки электронных подписей;
¾ 2) обеспечивает электронное взаимодействие доверенных лиц между собой, а также доверенных лиц с удостоверяющим центром.
№ 22 Взаимосвязь между протоколами аутентификации и цифровой подписи.
Самый простой протокол аутентификации - доступ по паролю (Password Authentication Protocol, PAP). Его суть состоит в том, что вся информация о субъекте (идентификатор и пароль) передается по сети в открытом виде. Это и является главным недостатком PAP, так как злоумышленник может легко получить доступ к передающимся незашифрованным данным.
Более сложные протоколы аутентификации основаны на принципе "запрос-ответ", например, протокол CHAP (Challenge-Handshake Authentication Protocol). Работа протокола типа "запрос-ответ" может состоять минимум из четырех стадий:
1. Субъект отправляет системе запрос, содержащий его персональный идентификатор
2. Система генерирует случайное число и отправляет его субъекту
3. Субъект зашифровывает полученное число на основе своего уникального ключа и результат отправляет системе
4. Система расшифровывает полученное сообщение на основе того же уникального ключа. При совпадении результата с исходным случайным числом, аутентификация проходит успешно.
Kerberos /kɛərbərəs/ — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован , в первую очередь , на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов Нидхем-Шрёдер-протокола аутентификации на основе доверенной третьей стороны и его модификациях, предложенных Denning и Sacco[1]
Протокол Kerberos
Протокол Kerberos используется в системах клиент-сервер для аутентификации и обмена ключевой информацией, предназначенной для установления защищенного канала связи между абонентами, работающими как в локальной сети, так и глобальных сетях. Данный протокол встроен в качестве основного протокола аутентификации в Microsoft Windows 2000 и в UNIX BSD.
Kerberos обеспечивает аутентификацию в открытых сетях, т. е. при работе Kerberos подразумевается, что злоумышленники могут производить следующие действия:
• выдавать себя за одну из легитимных сторон сетевого соединения;
• иметь физический доступ к одному из участвующих в соединении компьютеров;
• перехватывать любые пакеты, модифицировать их и (или) передавать повторно.
Соответственно, обеспечение безопасности в Kerberos построено таким образом, чтобы нейтрализовать любые потенциальные проблемы, которые могут возникнуть из-за указанных действий злоумышленников.
Kerberos разработан для сетей TCP/IP и построен на основе доверия участников протокола к третьей (доверенной) стороне. Служба Kerberos, работающая в сети, действует как доверенный посредник, обеспечивая надежную аутентификацию в сети с последующей авторизацией доступа клиента (клиентского приложения) к ресурсам сети. Защищенность установленных в рамках сессии Kerberos соединений обуславливается применением симметричных алгоритмов шифрования. Служба Kerberos разделяет отдельный секретный ключ с каждым субъектом сети, и знание такого секретного ключа равносильно доказательству подлинности субъекта сети.
Основу Kerberos составляет протокол аутентификации и распределения ключей Нидхэма—Шредера с третьей доверенной стороной. Рассмотрим эту версию протокола. В протоколе Kerberos (версия 5) участвуют две взаимодействующие стороны и доверенный сервер, выполняющий роль Центра распределения ключей.
Этот протокол успешно работает при условии, что часы каждого участника синхронизированы с часами сервера. Следует отметить, что в этом протоколе необходим обмен с сервером для получения сеансового ключа каждый раз. Протокол обеспечивает надежное соединение объектов при условии, что ни один из ключей не скомпрометирован и сервер защищен.
Система Kerberos имеет структуру типа клиент—сервер и состоит из клиентских частей, установленных на всех рабочих станциях пользователей и серверах сети, и сервера Kerberos, располагающегося на каком-либо (не обязательно выделенном) компьютере. Клиентами могут быть пользователи, а также независимые программы, выполняющие такие действия, как загрузка удаленных файлов, отправка сообщений, доступ к БД, доступ к принтерам, получение привилегий у администратора и т. п.
Сервер Kerberos KS, можно разделить на две части: сервер аутентификации AS (Authentication Server) и сервер службы выдачи мандатов TGS (Ticket Granting Service). Физически эти серверы могут быть совмещены. Информационными ресурсами, необходимыми клиентам, управляет сервер информационных ресурсов RS. Предполагается, что серверы службы Kerberos надежно защищены от физического доступа злоумышленников.
Сетевые службы, требующие проверки подлинности, и клиенты, которые хотят использовать эти службы, регистрируют в Kerberos свои секретные ключи. Kerberos хранит БД о клиентах и их секретных ключах. Наличие в этой БД секретных ключей каждого пользователя и ресурсов сети, поддерживающих этот протокол, позволяет создавать зашифрованные сообщения, направляемые клиенту или серверу; успешное расшифрование этих сообщений и является гарантией прохождения аутентификации всеми участниками протокола.
Kerberos также создает сеансовые ключи (session key), которые выдаются клиенту и серверу (или двум клиентам) и никому больше. Сеансовый ключ используется для шифрования сообщений, которыми обмениваются две стороны, и уничтожается после окончания сеанса.
Область действия системы Kerberos распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в БД сервера Kerberos.
Укрупненно процесс идентификации и аутентификации пользователя в системе Kerberos версии 5 можно описать следующим образом.
Схема работы протокола Kerberos
Клиент С, желая получить доступ к ресурсу сети, направляет запрос серверу аутентификации AS. Сервер AS идентифицирует пользователя с помощью его имени и пароля и высылает клиенту мандат (ticket) на доступ к серверу службы выделения мандатов TGS (Ticket-Granting Service).
Для использования конкретного целевого сервера информационных ресурсов RS клиент С запрашивает у TGS мандат на обращение к целевому серверу RS. Если все в порядке, TGS разрешает использование необходимых ресурсов сети и посылает соответствующий мандат клиенту С.
Основные шаги работы системы Kerberos (см. рис. 13.10):
1. С —> AS — запрос клиента С к серверу AS разрешить обратиться к службе TGS.
2. AS —> С — разрешение (мандат) от сервера AS клиенту С обратиться к службе TGS.
3. С —> TGS — запрос клиента С к службе TGS на получение допуска (мандата) к серверу ресурсов RS.
4. TGS —> С — разрешение (мандат) от службы TGS клиенту С для обращения к серверу ресурсов RS.
5. С —> RS — запрос информационного ресурса (услуги) у сервера RS.
6. RS —> С — подтверждение подлинности сервера RS и предоставление информационного ресурса (услуги) клиенту С.
Данная модель взаимодействия клиента с серверами может функционировать только при условии обеспечения конфиденциальности и целостности передаваемой управляющей информации. Без строгого обеспечения информационной безопасности клиент С не может отправлять серверам AS, TGS и RS свои запросы и получать разрешения на доступ к обслуживанию в сети.
Чтобы избежать возможности перехвата и несанкционированного использования информации, Kerberos применяет при передаче любой управляющей информации в сети систему многократного шифрования с использованием комплекса секретных ключей (секретный ключ клиента, секретный ключ сервера, секретные сеансовые ключи пары клиент—сервер). Kerberos может использовать различные симметричные алгоритмы шифрования и хэш-функции.
На сегодняшний день протокол Kerberos является широко распространенным средством аутентификации. Kerberos может использоваться в сочетании с различными криптографическими схемами, включая шифрование с открытым ключом.
№ 25 Хэш-функция: классификация, требования предъявляемые к хэш-функциям. Гост 34.11- 94 «Информационная технология. Криптографическая защита информации. Функция хэширования».
Хеширование (иногда «хэширование», англ. hashing) — преобразование по детерминированному алгоритму входного массива данных произвольной длины в выходнуюбитовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хешем, хеш-кодом или сводкой сообщения (англ. message digest). Если у двух строк хеш-коды разные, строки гарантированно различаются, если одинаковые — строки, вероятно, совпадают.
Среди множества существующих хеш-функций принято выделять криптографически стойкие, применяемые в криптографии, так как на них накладываются дополнительные требования. Для того чтобы хеш-функция 
считалась криптографически стойкой, она должна удовлетворять трем основным требованиям, на которых основано большинство применений хеш-функций в криптографии:
· Необратимость: для заданного значения хеш-функции m должно быть вычислительно неосуществимо найти блок данных 
, для которого 
.
· Стойкость к коллизиям первого рода: для заданного сообщения M должно быть вычислительно неосуществимо подобрать другое сообщение N, для которого 
.
· Стойкость к коллизиям второго рода: должно быть вычислительно неосуществимо подобрать пару сообщений 
, имеющих одинаковый хеш.
Данные требования не являются независимыми:
· Обратимая функция нестойка к коллизиям первого и второго рода.
· Функция, нестойкая к коллизиям первого рода, нестойка к коллизиям второго рода; обратное неверно.
Следует отметить, что не доказано существование необратимых хеш-функций, для которых вычисление какого-либо прообраза заданного значения хеш-функции теоретически невозможно. Обычно нахождение обратного значения является лишь вычислительно сложной задачей.
Атака «дней рождения» позволяет находить коллизии для хеш-функции с длиной значений n битов в среднем за примерно 
вычислений хеш-функции. Поэтому n-битная хеш-функция считается криптостойкой, если вычислительная сложность нахождения коллизий для неё близка к .
Для криптографических хеш-функций также важно, чтобы при малейшем изменении аргумента значение функции сильно изменялось (лавинный эффект). В частности, значение хеша не должно давать утечки информации даже об отдельных битах аргумента. Это требование является залогом криптостойкости алгоритмов хеширования, хеширующих пользовательский пароль для получения ключа.[7]
Хеширование часто используется в алгоритмах электронно-цифровой подписи, где шифруется не само сообщение, а его хеш-код, что уменьшает время вычисления, а также повышает криптостойкость. Также в большинстве случаев, вместо паролей хранятся значения их хеш-кодов.