Конструируем локальный криптографический TLS-прокси c HTTP API электронной подписи / Хабр

Техника: что такое эцп и ее виды

Различают три вида электронной подписи:

1. Простая электронная цифровая подпись (ПЭП)
2. Усиленная неквалифицированная цифровая подпись (НЭП)
3. Усиленная квалифицированная цифровая подпись (КЭП)

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

Чтобы сформировать любую цифровую подпись документа, нужно три вещи:

1. Сам документ
2. Публичный ключ
3. Секретный ключ

Что такое эцп и кто может ее использовать

С развитием новых технологий электронно-цифровая подпись (ЭЦП) находит все более широкое применение. ЭЦП — электронный аналог личной подписи ответственного лица (а в некоторых случаях и печати организации).

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

ЭЦП бывает двух видов: простая и усиленная. Усиленная, в свою очередь, подразделяется на квалифицированную и неквалифицированную.

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

Усиленная неквалифицированная ЭЦП (НЭП) — подпись, полученная в результате криптографического преобразования информации, которая позволяет выявить:

• ответственное лицо, подписавшее документ;
• факт изменения документа после его подписания.

Усиленная квалифицированная ЭЦП (КЭП) — подпись, которая обладает всеми свойствами неквалифицированной ЭЦП, но при этом имеет сертификат проверки ключа ЭЦП.

Простая и усиленная НЭП соответствуют автографу подписывающего лица на бумажном носителе, а усиленная КЭП — подписи ответственного лица и печати фирмы-заверителя электронного документа (пп. 2, 3 ст. 6 закона 63-ФЗ «Об электронной цифровой подписи»).

Подробнее о простой и усиленной ЭЦП узнайте в материалах:

ЭЦП можно получить в удостоверяющем центре (УЦ), аккредитованном Минкомсвязью РФ. Выдаваемый центром комплект включает:

1. Сертификат ключа проверки ЭЦП — как правило, выдается на USB-носителе.
2. Дистрибутив софта «КриптоПро» с активированной лицензией для использования в течение срока действия ключа проверки ЭЦП.

Ключ проверки ЭЦП действует в течение 12 месяцев, после чего подлежит замене.

Stunnel

При заходе на URL local/login в случае успешной авторизации пользователя на Рутокен ЭЦП Flash локальное web-приложение, используя php-cgi, запускает процесс sTunnel, передавая ему PIN-код токена в качестве одного из параметров командной строки.Кроме того, локальное WEB-приложение может сконфигурировать sTunnel на использование определенного сертификата для проведения клиентской аутентификации в рамках TLS.

STunnel, слушая на localhost, ожидает реверcированного NGINX-ом запроса от браузера. При получении первого запроса устанавливает TLS-соединение с удаленным сервером в соответствии со своим конфигурационным файлом и затем передает по установленному соединению запросы и ответы.

Пример конфигурационного файла:

; проверка сертификата сервера обязательна
verify=1

; режим работы: клиент TLS-прокси
client=yes

; корневой сертификат
CAFile=ca2001_A-root.crt

; версия протокола TLS
sslVersion=TLSv1

; не создаем иконку в трее
taskbar=no

; уровень ведения логирования
DEBUG=7
output = log

; использовать engine PKCS11_GOST для работы с Рутокен ЭЦП
engine=pkcs11_gost

; использовать библиотеку PKCS#11 из директории запуска процесс
engineCtrl=MODULE_PATH:rtpkcs11ecp.dll

;за ГОСТ-ы отвечает engine
engineDefault=ALL

  
[remote system]

; используем для загрузки ключа engine PKCS11_GOST
engineNum = 1

; загружаем клиентский сертификат из файла
cert=client.crt

; ID ключевой пары на Рутокен ЭЦП                                                                  
key = a0:59:d9:62:0d:09:69:2f:b6:ba:2d:9b:da:5b:2b:4d:fe:75:05:19

; прокси принимает подключения на данном порту
accept = localhost:1443

; удаленный сервер
connect = x.x.x.x:443
sni = localhost


; используем российский шифрсьют для TLS
ciphers = GOST2001-GOST89-GOST89

; for IE
TIMEOUTclose = 0

Подобное конфигурирование дает вот что:

Web-сервер nginx

Этот web-сервер вполне успешно запускается на localhost без установки, с FLASH-памяти Рутокен ЭЦП Flash.

Конфигурационный файл выглядит так:

Архитектура решения

Есть несколько способов решения для работы с ЭЦП. Давайте рассмотрим их.

Безопасность при использовании кэп

Статьей 10 Федерального закона от 06.04.2021 №63-ФЗ «Об электронной подписи (далее – Федеральный закон №63-ФЗ) установлена обязанность участников электронного взаимодействия обеспечивать конфиденциальность ключей электронных подписей.

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

Чтобы не стать участником аферы, не передавайте свой ключ электронной подписи третьим лицам. Примером такой ситуации является случай, когда генеральный директор приобретает УКЭП и передает его бухгалтеру для сдачи отчетности, а бухгалтер выводит средства с расчетного счета компании.

В любом случае, чтобы обезопасить себя и свой бизнес, вам необходимо придерживаться трех простых правил:

Спасибо, за внимание! Если у вас остались вопросы, от отвечу в комментариях.

#Электронная_Подпись#ЭЦП#крипто

Внешний документооборот

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

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

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

Простой пример использования подписи в CRM — подписать в сделке договор. После подписи можно отправить клиенту. Нет необходимости отправлять документы почтой, ждать несколько дней, а то и недель (если клиент в другом городе), а потом столько же ждать возврата. Документ утвержден электронной подписью и считается юридически значимым.

Остался главный технический вопрос – а как включить ЭЦП в логику работы CRM или внутреннего портала?

Генерирование открытого и секретного ключей

Итак, вы решили самостоятельно изготовить усиленную неквалифицированную электронную подпись и научиться подписывать ею свои документы. Начать необходимо, конечно, с генерирования пары ключей, открытого (public key) и секретного (private key).

Существует множество стандартов и алгоритмов асимметричного шифрования. Одной из библиотек, реализующих эти алгоритмы, является PGP (Pretty Good Privacy). Она была выпущена в 1991 году под проприетарной лицензией, поэтому имеются полностью совместимые с ней свободные библиотеки (например, OpenPGP).

Одной из таких свободных библиотек является выпущенная в 1999 году GNU Privacy Guard (GnuPG, или GPG). Утилита GPG традиционно входит в состав почти всех дистрибутивов Линукса; для работы из-под Windows необходимо установить, например, gpg4win. Ниже будет описана работа из-под Линукса.

Сначала сгенерируем собственно ключи, подав (из-под обычного юзера, не из-под root’а) команду

gpg --full-generate-key

В процессе генерирования вам будет предложено ответить на ряд вопросов:

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

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

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

gpg --export -a "Иван Иванович Иванов" > public.key
gpg --export-secret-key -a "Иван Иванович Иванов" > private.key

Понятно, что private.key вы должны хранить в секрете, а вот public.key вы можете открыто публиковать и рассылать всем желающим.

Зачем электронная подпись в crm-системах и интранет-порталах?

В CRM есть 2 сценария использования цифровой подписи:

1. Для внутренней переписки и доверия “нажатию кнопки”. Часто в интерфейсе CRM-систем и интранет-порталах согласуются внутренние документы, а также скидки, договоры и дилерские соглашения.
2. Для отправки официальных ответов клиентам и государственным органам.

Разные сценарии – разные требования. В первом случае подписываются:

Второй случай серьезнее – не обойтись без квалифицированной электронной подписи.

Зачем?

Иногда документы нужно подписать и отправить, а руководителя нет на месте. Вполне можно потом забыть или нарушить сроки. Документы скапливаются целыми горами. Руководитель сидит и тратит много времени на подписание бумаг.

Да и вообще “бумаги” в 21 веке – неэкологичный анахронизм. Лучше вообще без них. А подписывать надо.

В чем суть электронной подписи? Как и в “мире оффлайна”, когда человек согласен, он ставит подпись. Только бумага и подпись физически не существуют.

Зачем нужна подпись? Коротко — для аутентификации (подтверждения) документа. То есть, чтобы убедиться, что подписант выразил согласие с положениями именно этой версии документа.

Как выглядит усиленная подпись

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

Например, PDF и почти все форматы Microsoft Office это поддерживают. А сами программные пакеты имеют функцию создания и проверки таких подписей. Таким образом, для технически неподготовленных пользователей процесс подписания выглядит как нажатие нескольких кнопок в Word, Excel или Adobe Reader.

Как подписать xml файл средствами php

<?
//Секретный ключ в нашей системе
$S_KEYS = '12345';

$ss='';
//Перебор всех полей полученных при передачи мотодом "POST"
foreach ($_POST as $k => $v)
{
$array[$k]=$v;
$ss = "$ss>>$k=$vn";
}
//Функция для кодирования данных($data) ключем($key) методом hmac 
function hmac($key, $data)
{
   $b = 64; // byte length for md5
   if (strlen($key) > $b) {
       $key = pack("H*",md5($key));
   }
   $key  = str_pad($key, $b, chr(0x00));
   $ipad = str_pad('', $b, chr(0x36));
   $opad = str_pad('', $b, chr(0x5c));
   $k_ipad = $key ^ $ipad ;
   $k_opad = $key ^ $opad;

   //Возвращает результат - кодированное слово 
   return md5($k_opad  . pack("H*",md5($k_ipad . $data)));
}
//Список фиксированных полей отправленных системой
//Остальные параметры - это поля поставщика услуг
$s1 = $array['date'];
$s2 = $array['id_pay'];
$s3 = $array['trans_pay'];
$s4 = $array['trans_corr'];
$s5 = $array['keyt'];
$s6 = $array['summ'];
$s7 = $array['curr'];
$s8 = $array['commiss'];
$s9 = $array['itogo'];

//Кодируемая строка (состоит из порядка данных фиксированных полей системы)
$strings = "$s1$s2$s3$s4$s5$s6$s7$s8$s9";

//Результат кодирования
$sign = hmac($S_KEYS, $strings);

$ss = "n$ss=STRING-$stringsnn";
$ss = "n$ss=SIGN-$signnn";

//Запись результатов обработки в файл 'file.txt'
$file=fopen('file.txt',"w ");
$text= "$ss";
fwrite($file,$text);
fclose($file);
?>

<?
//Секретный ключ в нашей системе
$S_KEYS = '12345';

$ss='';
//Перебор всех полей полученных при передачи мотодом "POST"
foreach ($_POST as $k => $v)
{
$array[$k]=$v;
$ss = "$ss>>$k=$vn";
}
//Функция для кодирования данных($data) ключем($key) методом hmac 
function hmac($key, $data)
{
   $b = 64; // byte length for md5
   if (strlen($key) > $b) {
       $key = pack("H*",md5($key));
   }
   $key  = str_pad($key, $b, chr(0x00));
   $ipad = str_pad('', $b, chr(0x36));
   $opad = str_pad('', $b, chr(0x5c));
   $k_ipad = $key ^ $ipad ;
   $k_opad = $key ^ $opad;

   //Возвращает результат - кодированное слово 
   return md5($k_opad  . pack("H*",md5($k_ipad . $data)));
}
//Список фиксированных полей отправленных системой
//Остальные параметры - это поля поставщика услуг
$s1 = $array['date'];
$s2 = $array['id_pay'];
$s3 = $array['trans_pay'];
$s4 = $array['trans_corr'];
$s5 = $array['keyt'];
$s6 = $array['summ'];
$s7 = $array['curr'];
$s8 = $array['commiss'];
$s9 = $array['itogo'];

//Кодируемая строка (состоит из порядка данных фиксированных полей системы)
$strings = "$s1$s2$s3$s4$s5$s6$s7$s8$s9";

//Результат кодирования
$sign = hmac($S_KEYS, $strings);

$ss = "n$ss=STRING-$stringsnn";
$ss = "n$ss=SIGN-$signnn";

//Запись результатов обработки в файл 'file.txt'
$file=fopen('file.txt',"w ");
$text= "$ss";
fwrite($file,$text);
fclose($file);
?>

Как работает усиленная подпись

Вспомните пример алгоритма простой подписи. Результат этого алгоритма не зависит от текста документа. Если подать этот текст на вход хеш-функции, получится нечто похожее на усиленную подпись. То есть, в результате изменения текста документа старая подпись «не подойдет» к новой версии документа.

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

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

Квалифицированная цифровая подпись (кэп)

Такая подпись имеет юридическую силу и признается государством. Например, можно отправлять документы в налоговую. Никаких дополнительных соглашений с участниками документооборота заключать не нужно — таким подписям все доверяют «по-умолчанию».

Секретный ключ для такой подписи передается пользователю на сертифицированном ФСБ защищенном носителе — USB-токене («флешка»), смарт-карте и др.

Для работы с носителем используется специальное программное обеспечение. Чаще всего, это ПО интегрируется с ОС таким образом, чтобы Microsoft Office, Adobe Reader и другие программные пакеты могли использовать носитель при создании подписей.

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

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

Ключевые термины

DSS (Digital Signature Standard) – стандарт США на цифровую подпись. В основе стандарта лежит алгоритм, называемый DSA (Digital Signature Algorithm) и являющийся вариацией подписи Эль-Гамаля.

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

ГОСТ Р34.10-94 – российский стандарт на алгоритм формирования и проверки ЭЦП, действующий с 1995 года. В стандарте используется модификация схемы шифрования с открытым ключом Эль-Гамаля и алгоритм выработки хэш-функции по ГОСТ Р34.11-94.

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

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

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

Количество ключей = количество станций

Предположим у нас у каждого сотрудника, который имеет права подписывать документы, есть ключ для ЭЦП.

Как это работает:

1. Разрабатываем приложение для рабочих станций, которое будет работать с криптопровайдером (самое популярное — криптоПРО)
2. Сотрудник формирует и подписывает запрос на своей рабочей станции
3. Запрос отправляется на сервер.
4. Полученный ответ конвертируется в PDF-файл или любой другой
5. PDF-файл загружается в CRM

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

Неквалифицированная цифровая подпись (нэп)

Такая подпись имеет юридическую силу (с точки зрения суда), если стороны заключили соответствующее соглашение. Такое соглашение нельзя заключить с гос. структурами.

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

Для создания подписи может использоваться любое программное обеспечение, которому стороны доверяют. Хоть утилиты OpenSSL, хоть КриптоАРМ, хоть встроенные средства подписи Microsoft Office или Adobe Reader.

Новый отечественный стандарт эцп

В 2001 г. был принят новый отечественный стандарт на алгоритм формирования и проверки ЭЦП. Его полное название следующее: “ГОСТ Р34.10-2001. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи”.

Данный алгоритм был разработан главным управлением безопасности связи Федерального агентства правительственной связи и информации при Президенте Российской Федерации при участии Всероссийского научно-исследовательского института стандартизации.

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

В целом алгоритм вычислений по алгоритму ГОСТ Р34.10-2001 аналогичен применяемому в предыдущем стандарте ГОСТ Р34.10-94. Сначала генерируется случайное число k, с его помощью вычисляется компонента r подписи.

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

Старый ГОСТ Р34.10-94 не отменен, и в настоящее время параллельно действуют два отечественных стандарта на ЭЦП. Однако необходимо отметить, что для прежнего ГОСТа принято ограничение: при реализации ЭЦП по стандарту ГОСТ Р34.10-94 разрешено использовать только 1024-битные значения параметра p.

Использование математического аппарата группы точек эллиптической кривой в новом ГОСТ Р34.10-2001 позволяет существенно сократить порядок модуля p без потери криптостойкости. Так, в стандарте указано, что длина числа р может быть 256 или больше бит.

Один ключ — много станций

Предположим Вам нужно подписывать документ и отправлять его на сервер. Сервер должен проверить документ и прислать ответ, в виде такого же подписанного документа.

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

Как это работает:

1. Делаем отдельный сервер для ЭЦП с подключенным ключом для ЭЦП, на который будут приходить XML-запросы
2. Сотрудник должен будет установить себе приложение для двухфакторной аутентификации, которое будет генерировать одноразовый пароль каждые N сек. (TOTP). В свою очередь наш сервер ЭЦП генерирует QR-код, который нужно отсканировать этим приложением, чтобы появился пароль. Этот пароль нужно вводить при каждой подписи, чтобы подтвердить допуск к USB-ключу.
3. После подписи, запрос отправляется на сервер.
4. После того, как ответ получен на сервере для ЭЦП, происходит конвертация XML-ответа в PDF-файл или любой другой.
5. PDF-файл загружается в CRM.

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

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

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

Пример вычисления и проверки цифровой подписи

Пусть абоненты, обменивающиеся через Интернет зашифрованными сообщениями, имеют следующие общие параметры: Р = 11, А = 7.

Один из пользователей этой системы связи хочет подписать свое сообщение m=5 цифровой подписью, сформированной по алгоритму Эль-Гамаля. Вначале он должен выбрать себе закрытый ключ, например, Х1=3 и сформировать открытый ключ Y1 = 73 mod 11 = 2. Открытый ключ может быть передан всем заинтересованным абонентам или помещен в базу данных открытых ключей системы связи.

Затем пользователь выбирает случайное секретное число k, взаимно простое с Р-1. Пусть k=9 ( 9 не имеет общих делителей с 10 ). Далее необходимо вычислить число

После этого с помощью расширенного алгоритма Евклида находится значение b в уравнении:

Решением последнего уравнения будет значение b=9.

Таким образом, пара чисел (8, 9) будет цифровой подписью сообщения m=5.

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

Так как с1 = с2, то цифровая подпись первого пользователя в сообщения m=5 верная.

Пример применения в реальном проекте для cedis (энергосистема черногории)

Бизнес задача: сотрудники должны подписывать документы и отправлять их клиентам.

Какие ресурсы? Один сервер, один ключ ЭЦП, CRM.

Пример создания и проверки подписи по стандарту гост р34.10-94

Пусть p = 23, q = 11, a =6 (проверяем: 611 mod 23 = 1 )

Создание подписи.

Предположим, пользователь А выбрал в качестве закрытого ключа число х=8. После этого он вычисляет открытый ключ по формуле y = аx mod p. То есть y = 68 mod 23 = 18.

Для создания подписи пользователь А выбирает случайное число k = 5.

Пусть результат вычисления хеш-функции для сообщения H(m) = 9.

Подпись сообщения состоит из двух чисел (r, s):

Таким образом, подпись сообщения состоит из пары чисел (2, 6).

Проверка подписи.

Получив сообщение вместе с подписью (2, 6), получатель вычисляет

Так как v = r, то подпись считается верной.

Подписи, созданные с использованием стандартов ГОСТ Р34.10 или DSS, так же, как и подписи, полученные по алгоритму Эль-Гамаля, являются рандомизированными, так как для одинаковых сообщений с использованием одного и того же закрытого ключа х каждый раз будут создаваться разные подписи (r,s) благодаря использованию разных случайных значений k.

Принцип создания и проверки подписи

Алгоритм Эль-Гамаля также можно использовать для формирования цифровой подписи. Группа пользователей выбирает общие параметры Р и А. Затем каждый абонент группы выбирает свое секретное число Х_i, 1 < Х_i< Р-1, и вычисляет соответствующее ему открытое число пару (закрытый ключ; открытый ключ) = (Х_i, Y_i). Открытые ключи пользователей могут храниться в общей базе системы распределения ключей и при необходимости предоставляться всем абонентам системы.

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

Пусть пользователь 1 хочет подписать свое сообщение цифровой подписью и передать его пользователю 2. В этом случае алгоритм действий следующий.

1. Первый пользователь выбирает случайное секретное число k, взаимно простое с Р-1, и вычисляет число
2. Затем с помощью расширенного алгоритма Евклида необходимо найти значение b в следующем уравнении:
   Пара чисел (a, b) будет цифровой подписью сообщения m.
3. Сообщение m вместе с подписью (a, b) отправляется пользователю 2.
4. Пользователь 2 получает сообщение m и с использованием открытого ключа первого абонента Y₁ вычисляет два числа по следующим формулам: Если с₁ = с₂, то цифровая подпись первого пользователя верная. Для подписывания каждого нового сообщения должно каждый раз выбираться новое значение k.

Подписи, созданные с использованием алгоритма Эль-Гамаля, называются рандомизированными, так как для одного и того же сообщения с использованием одного и того же закрытого ключа каждый раз будут создаваться разные подписи (a,b), поскольку каждый раз будет использоваться новое значение k.

Простая цифровая подпись

Коротко о работе ПЭП:

Симметричная или асимметричная криптография?

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

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

1. Алгоритмы с открытым ключом работают намного (в сотни раз) медленнее классических алгоритмов с закрытым ключом. Это их самый главный недостаток. Связан он с тем, что основной операцией в системах с открытым ключом является возведение в степень по большому модулю 500-1000 битовых чисел, что при программной реализации производится намного медленнее, чем шифрование того же объема данных классическими способами.
2. Алгоритмы с открытым ключом требуют обеспечения достоверности открытых ключей, что порой превращается в довольно сложную задачу. То же самое относится и к протоколам цифровой подписи. Для управления открытыми ключами используют специальную инфраструктуру открытых ключей, обеспечивающую функции управления открытыми ключами.
3. Алгоритмы с открытым ключом чувствительны к атакам по выбранному открытому тексту.

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

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

1. Пользователь А генерирует случайный сеансовый ключК и зашифровывает им с помощью симметричного алгоритмаF_сим свое сообщение M:
2. Пользователь А получает из базы данных открытый ключ U пользователя Б и зашифровывает им сеансовый ключК:
3. Пользователь А посылает своему абоненту зашифрованное сообщение Cт и зашифрованный сеансовый ключCk. Для защиты от вскрытия “человек-в-середине” передаваемые данные могут быть дополнены цифровой подписью.
4. Пользователь Б расшифровывает полученный сеансовый ключCk с помощью своего закрытого ключа R:
5. Пользователь Б расшифровывает сообщение с помощью сеансового ключа К:

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

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

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

Во многих странах сегодня существуют стандарты на электронную (цифровую) подпись. Стандарт цифровой подписи DSS (Digital Signature Standard – DSS) был принят в США в 1991 году и пересмотрен в 1994 году.

В основе стандарта лежит алгоритм, называемый DSA (Digital Signature Algorithm) и являющийся вариацией подписи Эль-Гамаля. В алгоритме используется однонаправленная хеш-функция H(m). В качестве хэш-алгоритма стандарт DSS предусматривает использование алгоритма SHA-1.

Рассмотрим сам алгоритм генерации ЭЦП. Вначале для группы абонентов выбираются три общих (несекретных) параметра р, q и a:

Зная эти числа, каждый абонент системы случайно выбирает число х, удовлетворяющее неравенству 0 < х < q, и вычисляет

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

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

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

1. Вычислить значение хеш-функции h = H(m) для сообщения m. Значение хеш-функции должно лежать в пределах 0 < h < q.
2. Затем сгенерировать случайное число k, 0 < k < q.
3. Вычислить r = (a^k mod p) mod q.
4. Определить s = [k^-1}(H(m) x * r)] mod q

В результате пользователь получит для сообщения m подпись, состоящую из пары чисел (r,s). Сообщение вместе с подписью может быть послано любому другому абоненту системы. Проверить подпись можно следующим образом:

1. Вычислить значение хеш-функции h = H(m) для сообщения m.
2. Проверить выполнение неравенств 0 < r < q, 0 < s < q.
3. Вычислить w = s^-1 mod q ;
4. Проверить выполнение равенства v = r. Если v = r, то подпись считается подлинной, иначе подпись считается недействительной.

В силу сложности вычисления дискретных логарифмов злоумышленник не может восстановить k из r или х из s, а следовательно, не может подделать подпись.

Стандарт цифровой подписи гост р34.10-94

В России принят стандарт ГОСТ Р34.10-94 “Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма”. В этом стандарте используется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS.

Вначале, так же как и по стандарту DSS, для группы абонентов выбираются три общих (несекретных) параметра р, q и a:

Подпись сообщения m состоит из двух чисел (r, s), вычисляемых по следующим формулам:

где H(m) – результат вычисления хеш-функции для сообщения m.

На этом формирование подписи закончено, и сообщение m вместе с ЭЦП (r,s) может быть отправлено получателю. Теперь отметим отличия алгоритма формирования ЭЦП по ГОСТ Р34.10-94 от алгоритма DSS.

1. Перед вычислением подписи исходное сообщение обрабатывается разными функциями хеширования: в ГОСТ Р34.10-94 применяется отечественный стандарт на хеш-функцию ГОСТ Р34.11-94, в DSS используется SHA-1, которые имеют разную длину хеш-кода. Отсюда и разные требования на длину простого числа q: в ГОСТ Р34.

2. По-разному вычисляется компонента s подписи. В ГОСТ Р34.10-94 компонента sвычисляется по формуле

а в DSS компонента s вычисляется по формуле

Последнее отличие приводит к соответствующим отличиям в формулах для проверки подписи.

В результате процедура проверки подписи по ГОСТ Р34.10-94 заключается в следующем. Получив [m, (r, s)], получатель вычисляет

Затем проверяется равенство вычисленного значения v и полученного в составе ЭЦП параметра r. Подпись считается корректной, если v = r.

В алгоритме создания ЭЦП по ГОСТ Р34.10-94, так же как и в алгоритме DSS, производятся достаточно сложные вычисления, требующие затрат вычислительных ресурсов. Для ускорения процесса генерации подписей по этим алгоритмам можно заранее вычислять некоторое количество значений параметра r, не зависящего от подписываемого сообщения.

Управление открытыми ключами

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

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

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

Эти организационные структуры играют роль доверенной третьей стороны и заверяют открытые ключи абонентов своими цифровыми подписями. Таким образом, в распределенных системах связи, использующих криптосистемы с открытыми ключами, вводится понятие инфраструктуры открытых ключей (Public Key Infrastructure – PKI), включающей комплекс программно-аппаратных средств, а также организационно-технических и административных мероприятий, обеспечивающих абонентам системы связи необходимый сервис для управления их открытыми ключами.

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

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

Сертификат обладает следующими свойствами:

Так как сертификаты не могут быть подделаны, их можно опубликовать, поместив в общедоступный справочник.

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

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

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

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

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

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

1. Администратор удостоверяющего центра генерирует пару (закрытый ключ, открытый ключ) и сообщает свой открытый ключ всем своим абонентам.
2. Пользователь А выбирает закрытые ключи для выполнения операций шифрования и формирования ЭЦП, а также вычисляет соответствующие открытые ключи.
3. Открытые ключи шифрования и подписи зашифровываются открытым ключом администратора и предъявляются в удостоверяющий центр для регистрации.
4. Администратор удостоверяющего центра проверяет (расшифровывает своим закрытым ключом) открытые ключи пользователя А; изготавливает и подписывает сертификаты открытых ключей пользователя А и помещает их в справочники открытых ключей шифрования и открытых ключей подписей. Каждый из справочников предоставляется в распоряжение абонентов удостоверяющего центра.
5. Любой пользователь системы может извлечь из справочника сертификат необходимого абонента, проверить подпись администратора под сертификатом (расшифровать его открытым ключом администратора) и извлечь открытый ключ.

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

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

Утверждение внутренних документов

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

Если вы все в одном офисе, то это дело получаса. А если производство в одном месте, а отдел кадров в другом? Всё затягивается на несколько дней. Выходом становится внедрение систем документооборота. У нас даже есть отдельный модуль документооборота.

Один минус — сотрудники иногда недостаточно серьезно воспринимают «электронные документы». Исправить это может внедрение электронной подписи. Тут как раз хорошо подойдёт неквалифицированная электронная подпись.

По сценарию использования можно выделить две возможности:

1. Подписать документ, загрузив его в специальной форме на отдельной странице CRM
2. Автоматическое утверждение документа при прохождении через бизнес-процесс

Цифровая подпись в bitcoin

Помимо прочего, электронная подпись используется в криптовалютах, в частности — в Bitcoin. У каждого пользователя Bitcoin есть пара из секретного и откpытого ключа. Хеш-значение открытого ключа служит основным адресом для передачи монет. Это значение не секретно, и сообщать его можно кому угодно. Но по значению хеша вычислить значение открытого ключа невозможно.

Сама пара ключей будет использована лишь однажды — при передаче прав собственности. На этом жизнь пары ключей заканчивается.

• PUB1 — публичный ключ;
• PRIV1 — секретный ключ;
• HASH1 или HASH(PUB1) — хеш-значение открытого ключа (биткойн-адрес);
• HASH2 или HASH(PUB2) — хеш открытого ключа следующего владельца.

Вот как устроен сам процесс передачи прав собственности на биткойны.

1. Владелец монеты открыто сообщает хеш своего публичного ключа HASH(PUB1), это и будет идентифицировать биткойн.
2. До момента продажи оба ключа PUB1, PRIV1 продавца остаются в секрете. Известен только HASH(PUB1) и соответствующий ему биткойн.
3. Как только появляется пoкупатель, владелец формирует открытое письмо, в котором указывает адрес биткойна HASH(PUB1) и хеш-значение публичного ключа нового владельца HASH(PUB2). И конечно же, подписывает письмо своим секретным ключом PRIV1, прилагая публичный ключ PUB1.
4. После этого пара ключей владельца PUB1 и PRIV1 теряют свою актуальность. Публичным ключом можно проверить само письмо, узнать новый адрес монеты.

О втором собственнике ничего не извeстно, кроме HASH(PUB2), до тех пор пока он не передаст права третьему владельцу. И эта цепочка может быть бесконечной.

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

Благодаря HASH(PUB) получается двойная защита. Первая загадка — узнать публичный ключ по его хешу. Вторая загадка — подписаться чужим секретным ключом.

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

Краткие итоги

Для формирования электронной цифровой подписи могут быть применены алгоритмы RSA, Эль-Гамаля и другие. Во многих странах сегодня существуют стандарты на электронную цифровую подпись. Так, в Российской Федерации действуют стандарты на алгоритмы формирования и проверки ЭЦП ГОСТ Р34.10-94 и ГОСТ Р34.10-2001.

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

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

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

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

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

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

Заключение

Конструкция, при всей ее кажущейся громоздкости, представляет собой 4 запущенных приложения — nginx, sTunnel, php, php-cgi.

Эти приложения, как я уже отмечал, не требуют установки, хранятся на FLASH-памяти и с нее же запускаются.

Не составляет большого труда написать управляющее приложение, которое аккуратно их стартует и «гасит» процессы при окончании работы или в случае отсоединения токена.

Выводы

Внедрение подписи документов в CRM-системы (да и вообще куда угодно) – интересная техническая задача на стыке разработки, информационной безопасности и оптимизации процессов.

Эта задача может быть решена описанным нами способом. Интересно мнение о других решениях такой задачи.