простая электронная подпись php
Кейс: Подпись документов электронной подписью с помощью КриптоПро + PHP
Проблема
Именно с такой задачей к нам обратился регистратор ценных бумаг Сервис-реестр. Им этот функционал необходим как никому другому. Требовалось разработать механизм подписи электронных документов сразу двумя подписями, директора и бухгалтера. Мы не задумываясь взялись за эту задачу.
При общении с клиентом выяснилось, что предидущий подрядчик не справился с этой задачей. Мы очень удивились, ведь это был крупнейший разработчик и дистрибьютор программного обеспечения в России (по понятным причинам называть компанию мы не будем).
Реализация
Для реализации мы взяли за основу КриптоПро CSP. Далее дело техники и никакой магии. Установили на сервер КриптоПро и скомпилировали PHP расширение. При формировании документа создаются два файла подписей (директор и бухгалтер). Все три файла упаковываются в архив и отдаются на скачивание пользователю.
Результат и кому это будет полезно?
В результате заказчик получил именно тот функционал, которого и ожидал. Теперь эмитенты АО «Сервис-реестр» могут взаимодействовать с регистратором и получать юридически защищённые документы без необходимости физического присутствия или отправки/получения почтовой корреспонденции.
Такая функция будет востребована в любой организации работающей в b2b секторе. Сокращая бюрократические задержки, вы высвобождаете время своих сотрудников для решения более важных задач. Тем самым предоставляете более быстрый и современный сервис своим клиентам, что выгодно выделит вас на фоне конкурентов.
Реализация задачи Комзарев Алексей (программист IT-INFINITY).
openssl_sign
(PHP 4 >= 4.0.4, PHP 5, PHP 7, PHP 8)
openssl_sign — Генерация подписи
Описание
Список параметров
Строка данных, для которых вы хотите получить отпечаток
Строка, представляющая собой ключ в формате PEM
Целое число, определяющее алгоритм. Смотрите алгоритмы подписи.
Возвращаемые значения
Возвращает true в случае успешного выполнения или false в случае возникновения ошибки.
Список изменений
Примеры
Пример #1 Пример использования openssl_sign()
// Извлекаем секретный ключ из файла и подготавливаем
$pkeyid = openssl_pkey_get_private ( «file://src/openssl-0.9.6/demos/sign/key.pem» );
Пример #2 Пример использования openssl_sign()
//Данные для генерации сигнатуры
$data = ‘my data’ ;
Смотрите также
User Contributed Notes 3 notes
This may help if you just want a real-simple private/public key pair:
= «Beeeeer is really good.. hic. » ;
// IMPORTANT: The key pair below is provided for testing only.
// For security reasons you must get a new key pair
// for production use, obviously.
The list of Signature Algorithms (constants) is very limited! Fortunately the newer versions of php/openssl allow you to specify the signature algorithm as a string.
You can use the ‘openssl_get_md_methods’ method to get a list of digest methods. Only some of them may be used to sign with RSA private keys.
Those that can be used to sign with RSA private keys are: md4, md5, ripemd160, sha, sha1, sha224, sha256, sha384, sha512
Встраивание электронной подписи в системы с WEB-интерфейсом с помощью браузерного плагина и openssl
Несколько лет назад нашей компанией был выпущен продукт Рутокен Плагин, который предназначен для встраивания электронной подписи в системы с web-интерфейсом. Основываясь на полученном опыте интеграции продукта в реальные проекты мне хочется отметить, что нередко разработчики для реализации серверной части предпочитают использовать поддерживающий российские криптоалгоритмы openssl.
В данной статье будет расписана типичная схема подобной интеграции, основанная на следующих сценариях использования плагина:
Данные сценарии предполагают клиент-серверное взаимодействие, написание клиентских скриптов на JavaScript и соответствующих им серверных вызовов openssl.
Подробности под катом.
Общие операции
Операции с устройством
Поиск подключенных устройств
Любой клиентский сценарий начинается с поиска подключенных к компьютеру USB-устройств Рутокен. В контексте данной статьи акцент делается на устройство Рутокен ЭЦП.
При этом возвращается список идентификаторов подключенных устройств. Идентификатор представляет собой число, связанное с номером слота, к которому подключено устройство. При повторном перечислении это число может отличаться для одного и того же устройства.
Рутокен Плагин определяет все подключенные к компьютеру USВ-устройства Рутокен ЭЦП, Рутокен PINPad, Рутокен WEB. Поэтому следующим шагом следует определить тип устройства.
Получение информации об устройстве
Для определения типа устройства следует использовать функцию getDeviceInfo с параметром TOKEN_INFO_DEVICE_TYPE. Значение этой константы содержится в объекте плагина.
Смена PIN-кода
Пример смены PIN-кода на устройстве:
Здесь первым параметром выступает старый PIN-код, а вторым новый PIN-код.
Работа с сертификатами
1. На токене могут храниться 3 категории сертификатов:
2. Для чтения сертификатов, хранящихся на устройстве, не требуется авторизация на устройство.
Пример чтения пользовательских сертификатов с устройства:
3. Сертификат можно экспортировать в PEM-формате:
Получится примерно такая строка:
4. Сертификат можно распарсить вызовом функции parseCertificate и получить из него DN Subject, DN Issuer, расширения, значение открытого ключа, подпись, серийный номер, срок действия и т.п.
5. Сертификат можно записать на устройство.
Пример записи сертификата на устройство как пользовательского:
6. Вызовом функции deleteCertificate можно удалить сертификат с токена.
Работа с ключевыми парами ГОСТ Р 34.10-2001
1. Для получения декрипторов ключевых пар, хранящихся на устройстве, требуется ввод PIN-кода. Следует понимать, что само значение закрытого ключ получено быть не может, так как ключ является неизвлекаемым.
Пример генерации ключевой пары ГОСТ Р 34.10-2001:
3. С помощью функции deleteKeyPair ключевая пара может быть удалена с токена.
Конфигурирование openssl
Openssl поддерживает российские криптоалгоритмы, начиная с версии 1.0. Для того, чтобы их использовать, в openssl требуется подгружать engine gost. В большинстве дистрибутивов openssl эта библиотека присутствует. Чтобы engine подгружалась, можно прописать ее в конфигурационном файле openssl:
Если конфигурационный файл openssl не расположен в стандартном месте, то путь к нему можно задать через переменную окружения OPENSSL_CONF.
Другим вариантом подгрузки engine gost является ее передача в параметрах командной строки утилиты openssl.
Если engine gost не расположена в стандартном месте, то через переменную окружения OPENSSL_ENGINES можно задать путь к директории, в которой openssl будет ее искать.
Для получения информации о том, успешен ли был вызов утилиты openssl или нет, с возможностью уточнения ошибки, требуется парсить stdout и stderror. В конце статьи приведена ссылка на PHP-скрипт, который использует данную утилиту.
Теперь перейдем к реализации законченных пользовательских сценариев.
Регистрация на портале
Сертификат выдается при регистрации в системе
Последовательность вызовов в клиентском скрипте будет следующей:
Далее запрос отправляется на сервер, где на его основе выдается сертификат.
Для этого на сервере должен быть установлен и правильно сконфигурирован openssl версии от 1.0 и развернут функционал УЦ.
1. Генерация улюча УЦ:
После этого в файле ca.key будет создан закрытый ключ
2. Создание самоподписанного сертификата УЦ:
После ввода необходимой информации об издателе в файле ca.crt будет создан сертификат УЦ.
Полученный от клиента запрос сохраняем в файл user.csr и выдаем на его основе сертификат (без модификации данных из запроса):
После этого в файле user.crt создается сертификат пользователя в PEM формате. Его следует отправить на клиент.
Дальнейшая последовательность вызовов на клиенте:
Сертификат уже имеется на токене, выдан внешним УЦ
Ключевая пара при этом должна быть создана в формате, совместимом с библиотекой rtPKCS11ECP для Рутокен ЭЦП.
Последовательность вызовов на клиенте:
Подпись получается в base64-формате. При проверке ее на сервере с помощью openssl подпись следует обрамить заголовками, чтобы сделать из нее PEM. Выглядеть подобная подпись будет примерно так:
Проверка подписи на сервере:
Здесь sign.cms — файл, в котором находится подпись, ca.crt — файл с корневыми сертификатами, до одного из которых должна выстроиться цепочка, data.file — файл, в который будет сохранены подписанные данные, user.crt — файл, в который будет сохранен пользовательский сертификат. Именно из data.file нужно извлечь данные отсоединить последние 32 символа и сравнить salt.
Если на сервере нужно получить информацию из сертификата, то парсить его можно так:
Показать содержимое сертификата в текстовом представлении:
Показать серийный номер сертификата:
Показать DN субъекта (subject):
Показать DN издателя:
Показать почтовый адрес субъекта:
Показать время начала действия сертификата:
Показать время окончания действия сертификата:
Строгая аутентификация на портале
Электронная подпись данных и/или файлов в формате CMS
Проверка подписи на сервере описана выше.
Шифрование/расшифрование данных и/или файлов в формате CMS
Шифрование данных на клиенте для сервера
Для того, чтобы обеспечить конфиденциальность обмена данными между клиентом и сервером в плагине предусмотрено шифрование/расшифрование данных. Данные шифруются в формате CMS. Для того, чтобы зашифровать данные в формате CMS, требуется сертификат открытого ключа «адресата». При этом расшифровать такое сообщение сможет только владелец закрытого ключа. При шифровании данных для сервера рекомендуется хранить сертификат сервера на Рутокен ЭЦП. Этот сертификат может быть записан на устройство при регистрации пользователя на портале. Для этого следует использовать функцию importCertificate, при этом в качестве параметра category следует передать CERT_CATEGORY_OTHER. Для использования в функции cmsEncrypt нужно получить тело сертификата по его дескриптору с помощью функции getCertificate. При этом дескриптор является уникальным и неизменным и может быть сохранен в учетной записи пользователя на сервере при импорте сертификата сервера. Для того, чтобы использовалось аппаратное шифрование по ГОСТ 28147-89, требуется установить опцию useHardwareEncryption в true. В противном случае будет использована быстрая программная реализация ГОСТ 28147-89.
Последовательность вызовов приведена на картинке:
Шифрование данных на клиенте:
Расшифрование данных на сервере, перед расшифрованием сообщение нужно обрамить PEM-заголовками «——BEGIN PKCS7——» и «——END PKCS7——«:
recipient.crt — сертификат того, для кого зашифровано сообщение, recipient.key — ключ того, для кого зашифровано сообщение.
Расшифрование данных, полученных с сервера, на клиенте
Для расшифрования данных, полученных с сервера, предназначена функция cmsDecrypt. Так как сервер шифрует для клиента, используя его сертификат, то в качестве keyId должен быть передан дескриптор закрытого ключа клиента, соответствующий открытому ключу в сертификате. Этот дескриптор является уникальным и неизменным и потому может быть сохранен в учетной записи пользователя на сервере. Кроме того, дескриптор ключа пользователя может быть получен явным образом, путем вызова функции getKeyByCertificate.
Шифрование данных на сервере для клиента:
Расшифрование данных на клиенте:
Полезные ссылки
Данные ссылки могут быть полезны разработчикам инфосистем с поддержкой ЭЦП на базе Рутокен Плагин и openssl:
Подпись по ГОСТ в php?
Добавил в OpenSSL GOST Engine, проверил
Выпустил самоподписанный сертификат и закрытый ключ по ГОСТу 2012 256 бит, задал пароль
Пытаюсь пописать строку через openssl_sign
irishmann, Так же обратите внимание, установлена ли переменная OPENSSL_CONF
PHP will search for the openssl.cnf using the following logic:
the OPENSSL_CONF environmental variable, if set, will be used as the path (including filename) of the configuration file.
the SSLEAY_CONF environmental variable, if set, will be used as the path (including filename) of the configuration file.
The file openssl.cnf will be assumed to be found in the default certificate area, as configured at the time that the openssl DLL was compiled. This is usually means that the default filename is C:\Program Files\Common Files\SSL\openssl.cnf (x64) or C:\Program Files (x86)\Common Files\SSL\openssl.cnf (x86), or, prior to PHP 7.4.0, C:\usr\local\ssl\openssl.cnf.
Korya, конфиг залил в облако. При перезапуске сервера, скрипт выдает ошибки
При следующем старте скрипта они пропадают.
С OpenSSL ничего не вышло. Сделал с помощью КриптоПРО. Поставил CSP на сервер, установил сертификаты и собрал расширение phpcades. Ниже говнокод, ссылки на примеры и инструкции.
Использование Простой электронной подписи в документах
Цель написания статьи – популяризировать использование Простой электронной подписи (пЭП) в документах. Чем больше людей пользуется, тем более популярен механизм, тем меньше у всех страхов, подозрений и вопросов. Очень удобно, подписал счет и акты пЭП и передал по email в бухгалтерию контрагента.
Простая электронная подпись не требует получения ее в удостоверяющем центре, не требует специальных технических или программных средств, однако она при соблюдении определенных условий признается нашим законодательством равнозначной собственноручной подписи.
Более того, при наличии своего сервиса проверки, пЭП гарантирует достоверность подписи, в отличии от собственноручной подписи. Например третьему лицу, взявшему в руки документ, неизвестно, закорючка напротив ФИО это реальная подпись того человека или нет. А здесь зашел на указанный сервис, вбил номер подписи и ты точно знаешь, что именно данный документ подписал именно данный человек.
Как сделать такой сервис проверки, и как организовать свою пЭП и будет описано в данной статье.
PS: Данный способ не подходит для подписи счет-фактур. По счету-фактуре установлены жесткие требования — подпись либо живая, либо ЭП у оператора. А счет, акт и т.п. можно.
Комментарий юриста по данному поводу: «По счету-фактуре установлены жесткие требования — подпись либо живая, либо ЭП у оператора.
Была даже в свое время практика, можно ли подписывать сф факсимиле, вроде как примерно то же, что и живая подпись.
Суды сказали нельзя.
С ЭП будет то же самое. Слишком много бюджет теряет из-за сф.»
Сначала немного законодательной теории.
Наше законодательство однозначно определяет условия признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью. Это определяется ФЗ №63 от 06.04.2011 статья 9 “Использование простой электронной подписи”. Данный закон голосит:
1. Электронный документ считается подписанным простой электронной подписью при выполнении в том числе одного из следующих условий:
1) простая электронная подпись содержится в самом электронном документе;
…
2. Нормативные правовые акты и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
1) правила определения лица, подписывающего электронный документ, по его простой электронной подписи;
2) обязанность лица, создающего и (или) использующего ключ простой электронной подписи, соблюдать его конфиденциальность.
Т.е. для законного использования пЭП нам необходимо:
В разделе 1, Термины и определения вводится понятие пЭП.
1.6. «Простая электронная подпись» — подпись на электронной версии документов, передаваемых между Сторонами и определяемая правилами в Приложении 1 Данного договора, пунктами 4.2 и 4.3 данного Договора и статьей 9 Федерального закона от 06.04.2011 N 63-ФЗ «Об электронной подписи».
Далее раздел 4. Соглашение об использовании пЭП.
4. СОГЛАШЕНИЕ ОБ ИСПОЛЬЗОВАНИИ ПРОСТОЙ ЭЛЕКТРОННОЙ ПОДПИСИ.
4.1. Стороны, в соответствии с Федеральным законом от 06.04.2011 N 63-ФЗ «Об электронной подписи», дают согласие на использовании простой электронной подписи документах передаваемых между Сторонами, в том числе в закрывающих документах.
4.2. Правила и порядок формирования ключа простой электронной подписи и правила определения лица, подписывающего электронный документ, по его простой электронной подписью, определяются в Приложении 1 к данному Договору. Приложение 1 является неотъемлемой частью данного Договора.
4.3. Стороны обязуются соблюдать конфиденциальность ключа своей простой электронной подписи.
4.4. На основании п.4.2 и п.4.3. данного договора и положений п.2 статьи 9 Федерального закона от 06.04.2011 N 63-ФЗ «Об электронной подписи», электронные версии документов размещаемые в личном кабинете Лицензиата, либо предаваемые посредством электронной почты между Сторонами, признаются равнозначными документам на бумажных носителях, подписанным собственноручной подписью.
Далее раздел 6. Порядок взаиморасчетов. Тут сказано, что закрывающие документы могут удостоверяться пЭП.
6.7. Закрывающие документы между сторонами передаются в электронном виде посредством размещения в личном кабинете Лицензиата и (или) через электронную почту и удостоверяются Простой электронной подписью.
И наконец Приложение 1, где описываются правила и порядок формирования пЭП.
Правила и порядок формирования Простой электронной подписи.
1. Правила формирования подписи.
1.1. Ключ подписи – кодовое слово или любая последовательность символов от 6 до 64 знаков известная только владельцу.
Например: «Ключ Лицензиата»
1.2. Hash ключа подписи – ключ подписи обработанный hash функцией с длинной ключа от 64 до 256 бит.
1.4. В целях безопасности, 5-10 символы значения хеша ключа пользователя при выводе на экран заменяются звездочками (например: вместо 822f424c94ffbe1e9b0e53df6d851da4 на экран будет выведено 822f4*****ffbe1e9b0e53df6d851da4). Данная процедура исключает копирование ключа пользователя злоумышленником, даже в случае взлома логина-пароля аккаунта пользователя. Оригинал ключа должен храниться исключительно у пользователя.
1.5. Алгоритм получения простой электронной подписи документа:
«Простая электронная подпись» = hash_sha1(«Тип документа»+«Номер документа»+«Дата документа»+«Ключ Лицензиата»)
PS: ключ лицензиата в данной системе является “солью”.
1 – Счет
2 – Акт
3 – Договор
4 – Приложение к договору
1.6. Для улучшения читабельности Электронная подпись может представляться в виде по 5 символов разделенных дефисами. Данная процедура необязательна. Дефисы при вводе подписи программой автоматически удалятся.
2. Правила проверки подписи
2.1. Удостоверение подлинности Простой электронной подписи Лицензиара.
Лицензиар на своем официальном сайте erp-platforma.com предоставляет возможность проверки подписи любого документа по адресу erp-platforma.com/ecp. Для проверки необходимо ввести Простую электронную подпись из документа в поле «Простая электронная подпись», ввести код капчи и нажать на кнопку «Проверить подпись документа». В ответ программа выдаст реквизиты документа, либо напишет «Документ не найден, подпись не подтверждена».
Данную процедуру проверки подлинности Простой электронной подписи Лицензиата может проводить как Лицензиат, так и третьи лица, которым Лицензиат передал документы.
2.2. Удостоверение подлинности Простой электронной подписи Лицензиата.
Удостоверить подпись Лицензиата Лицензиар может 4 способами:
1) В личном кабинете Лицензиата должен быть внесен Hash ключа подписи пользователя, подписавшего документ. В этом случае при получении документов по электронной почте у Лицензиара появляется возможность автоматической проверки подлинности подписи зная тип документа, номер документа, дату подписи и hash ключа подписи пользователя.
2) В случае если Лицензиат производит подпись документ в личном кабинете, и внесен hash ключа подписи пользователя, то необходимо внести сформированную Простую электронную подпись для данного Акта в соответствующую графу документ и нажать на кнопку «ЭП». Программа автоматически произведет проверку подписи и поставит ее в документ.
3) В случае если Лицензиат не вносит hash ключа подписи пользователя в личном кабинете, но хочет передавать подписанные Простой электронной подписью документы через электронную почту, Лицензиат должен доставить Лицензиару hash ключа подписи пользователя, подписывающего документы на любом носителе, в том числе на бумажном
4) В случае если Лицензиат не желает сообщать лицензиару hash ключа подписи пользователя, он вправе сделать на своих технических средствах сервис проверки подписи аналогичный erp-platforma.com/ecp и вместе с документами присылать ссылку на данный сервис, чтобы у Лицензиара была возможность проверки подлинности Простой электронной подписи документа.
Код сервиса проверки
PS: не забываем про исключение SQL-иньекций при постановке в запрос ЭП!
Живой пример как можно организовать работу пользователей с ЭП и работу сервиса проверки, можно почитать здесь: