Digital signing source code software for µFR Series NFC RFID contactless readers
Цифровая подпись — это будущее онлайн-бизнеса, говорим ли мы о простом документе, коде и подписи электронной почты или о более продвинутой криптографической реализации, как мы видим в настоящее время в криптовалютах и блокчейнах.
Digital Logic Ltd. является одной из первых компаний в мире, внедривших решения цифровой подписи с бесконтактными RFID-картами.
Мы ожидаем, что старые системы, которые все еще используют карточки контактов, скоро уйдут в прошлое.
Программное обеспечение μFR Signer поддерживает криптографические алгоритмы RSA и ECDSA для файлов цифровой подписи.
Программное обеспечение предназначено для использования с нашими nfc-устройствами серии μFR: Nano, Classic, Classic CS и Advance.
μFR Signer работает со всеми картами, поддерживающими RSA и ECDSA. В нашем демонстрационном видео мы использовали карту JCOP J3D081.
Карты DL Signer обеспечивают цифровую подпись данных и документов в самих картах с использованием асимметричных криптографических алгоритмов RSA или ECDSA. Поддерживается инфраструктура PKI, и в картах DL Signer можно хранить сертификаты X.509, которые связаны с парами криптографических ключей, сгенерированных в самих картах. Поддерживается хранение всех сертификатов X.509, составляющих цепочку доверия от корневого сертификата до сертификата конечной сущности.
Открытый ключ, который генерируется в карточках DL Signer, помещается в тело запроса при создании требования о подписании сертификата (далее CSR). Запрос подписывается в самой карточке соответствующим закрытым ключом, который никогда не покидает саму карту и никоим образом не может быть прочитан после генерации пар ключей. Далее КСО направляется в орган по сертификации для создания и подписания на его основе сертификата X.509. Этот сертификат конечной сущности помещается в карточку подписывающего лица DL вместе с другими сертификатами из цепочки доверия и готов к цифровой подписи данных и документов. Пользователь может отправить КСО в любой орган по сертификации, услугами которого он желает воспользоваться. Digital Logic предоставила механизм для выдачи сертификатов конечных сущностей для тестирования системы. Одной из основных характеристик сертификата конечной сущности является то, что закрытый ключ, который сопряжен с открытым ключом, содержащимся в таких сертификатах, не должен использоваться для подписи других сертификатов.
Программные средства Windows, которые инициируют генерацию пар криптографических ключей, генерируют CSR, управляют PIN-кодами и PUK-кодами карт DL Signer, манипулируют содержимым сертификатов X.509 и подписывают данные и файлы, распространяются как «ufr-signer».
"Signature-verifier" — это приложение Windows, проверяющее цифровые подписи RSA и ECDSA.
Цифровая подпись и проверка подписей также могут быть выполнены из приложения Adobe Acrobat Reader DC с помощью модуля ufr-pkcs11, который мы разработали для этой цели. Наш модуль PKCS#11 также можно использовать с популярным почтовым клиентом и веб-браузером Mozilla, а также с другими программными инструментами, совместимыми со спецификацией PKCS#11.
Мы также предоставили веб-сервисы для онлайн-проверки сертификатов X.509 и подписанных pdf-файлов.
Подписант uFR
«uFR Signer» — это программный инструмент, который инициирует генерацию пар криптографических ключей, генерирует запросы CSR, служит для управления PIN-кодами и PUK-кодами карт DL Signer, манипулирует содержимым сертификатов X.509 и подписывает данные и файлы.
Приложение разделено на несколько логических блоков с помощью визуального компонента элемента управления вкладкой. Вкладки помечены названиями следующих объектов:
«Ключи RSA» и «Ключи EC» используются для создания и управления парами ключей RSA или ECC.
RSA (Rivest, Shamir& Adleman) и ECC (Elliptic Curve Cryptography) представляют собой современные асимметричные криптографические алгоритмы. Карты DL Signer поддерживают хранение 3 ключей RSA и 3 ключей ECC отдельно. Каждый из криптографических ключей может иметь разную длину и характеристику и обозначается криптографическим алгоритмом и индексом ключа.
Вкладка «PIN-коды» относится к управлению и регистрации PIN-кода пользователя на карте DL Signer, расположенной в поле считывателя uFR. PIN-код является аббревиатурой от «Персональный идентификационный номер». В дополнение к PIN-кодам, на этой вкладке вы также можете разблокировать заблокированные карты с помощью PUK-кодов. PUK расшифровывается как «PIN-ключ разблокировки».
Вкладка "Объекты карты" используется для управления сертификатами ЦС и сертификатами конечных сущностей, связанными с соответствующими криптографическими ключами через их индексы. Сертификаты должны быть под X.509 версии 3. Учетные данные конечной сущности должны содержать открытый ключ, первоначально созданный в карточке подписывающего лица DL в паре с соответствующим закрытым ключом. Основное назначение сертификата — использование при подготовке к подписанию через модуль PKCS#11. Наличие сертификатов X.509 не является обязательным для использования DL Signer Card с проприетарными приложениями.
На вкладке «Подпись» есть опции для создания цифровых подписей. Можно подписать массив байтов, текстовый ввод или файл. Эти подписи могут быть проверены с помощью приложения "signature-verifier".
Для эффективного решения проблем с производительностью карточки подписывающих устройств DL предназначены для подписи блоков данных как можно более кратко. Поэтому существует практика цифровой подписи данных с помощью алгоритма RSA, определенного схемой PKCS # 1 v1.5. Для алгоритма ECDSA процедура создания цифровой подписи, заполнение и механизмы выравнивания определены в RFC 6979.
Последняя версия приложения uFRSigner — 1.5.3.0, и необходимо использовать библиотеку uFCoder версии 5.0.1 или выше и прошивку uFR версии 5.0.7 или выше.
PIN-коды
PIN-код является аббревиатурой от «Персональный идентификационный номер». Карта подписывающего лица DL содержит 2 различных PIN-кода. Это SO (сотрудник службы безопасности) PIN-код и PIN-код пользователя. Так называемый «сотрудник службы безопасности» — это пользователь, который имеет административные привилегии для доступа к объектам безопасности на карточке подписывающего лица DL. SO PIN-код должен отличаться от PIN-кода пользователя.
«Сотрудник службы безопасности» обязан авторизоваться для доступа к карте в случаях, когда необходимо изменить PIN- и PUK-коды и изменить содержимое хранилища для ключей и сертификатов. Вход с помощью PIN-кода пользователя необходим для получения цифровой подписи хэшированной строки данных.
PIN-коды на карточках подписанта DL могут содержать не менее 4 символов и максимум 8 символов. Здесь под символом находится любой буквенно-цифровой (с учетом регистра) или любой печатный символ. Печатные символы в основном относятся к знакам препинания на стандартных клавиатурах. При смене PIN-кодов не рекомендуется использовать специфические символы, которые можно найти только на отдельных локализованных клавиатурах, а только символы, которые находятся в стандарте ASCII и которые существуют на стандартных клавиатурах английского языка США.
Во всех карточках DL Signer изначально устанавливаются PIN-коды по умолчанию и PIN-коды пользователя, состоящие из восьми последовательных цифровых символов «0» (ноль) или «00000000».
Максимальное количество введенных неправильных последовательных PIN-кодов — 5. Если количество неправильных последовательных попыток ввести PIN-код превышено, этот PIN-код блокируется. Пока PIN-код не заблокирован, ввод правильного PIN-кода сбрасывает счетчик неправильно введенных PIN-кодов.
Единственный способ разблокировать PIN-код — ввести правильный PUK-код. PUK — это аббревиатура от «PIN-ключ разблокировки». Код SO PUK служит исключительно для разблокировки SO PIN-кода, а пользовательский PUK для разблокировки пользовательского PIN-кода. В случае 10 последовательно неправильно введенных PUK-кодов, PUK-код становится непригодным для использования, а функциональность карты, к которой относится заблокированный PIN-код, остается заблокированной навсегда.
Ключи RSA
На вкладке "Ключи RSA" есть опции для создания и управления ключами RSA. Перед работой с ключами RSA карта DL Signer Card должна находиться в поле считывателя uFR, подключенном к компьютеру, на котором запущено приложение ufr-signer. Кроме того, SO (Сотрудник по безопасности) должен войти в систему.
Клавиши EC
На вкладке "EC Keys" есть опции для создания и управления ключом EC. Перед работой с ключами EC карта DL Signer Card должна находиться в поле считывателя uFR, подключенном к компьютеру, на котором запущено приложение ufr-signer. Кроме того, SO (Сотрудник по безопасности) должен войти в систему.
Карты подписывающего лица DL поддерживают следующие стандартные кривые ECC:
Он определен стандартом PKCS#10 и представляет собой стандартизированную запись, которая, среди прочего, содержит основную информацию о пользователе сертификата в различающемся имени. Исходя из характеристического названия, в итоговом сертификате X.509 формируется так называемый Субъект (предметная область). Кроме того, записи CSR могут также содержать расширения, определенные стандартом X.509, которые центр сертификации (ЦС) может рассмотреть или отклонить, в зависимости от своей политики сертификации. Основной частью КСО, безусловно, является открытый ключ и его параметры. Все эти данные, упакованные в форму, определенную стандартом PKCS#10, окончательно пропускаются через соответствующий криптографический дайджест-алгоритм и результат подписывается в карточке соответствующим закрытым ключом. Полученная таким образом цифровая подпись становится неотъемлемой частью КСО.
CSR отправляется нужному издателю сертификата, который представляет собой так называемый центр сертификации (ЦС). Издатель сертификата сгенерирует сертификат конечной сущности X.509, который подписан соответствующим закрытым ключом, теперь связанным с открытым ключом, содержащимся в соответствующем промежуточном или корневом сертификате ЦС. Таким образом, сертификат конечной сущности становится частью цепочки доверия, гарантированной центром сертификации (ЦС).
Диалоговое окно «Запрос на подпись сертификата (CSR)» представляет собой отдельную группу для ввода «Различающееся имя (DN)», «Расширения» и в правом верхнем углу групп полей со списком, для управления алгоритмом хэширования и определения криптографического ключа. Внизу справа находится группа кнопок для выбора действий, связанных с генерацией КСО.
Различающееся имя, называемое DN, состоит из группы относительного различающегося имени (RDN), представляющей группу атрибутов. При определении DN очень важен порядок поля RDN. Важно отметить, что можно повторить одно поле RDN несколько раз в пределах DN. Необходимо помнить, что Центр сертификации (ЦС) не обязан выдавать сертификат с тем же DN, как определено в CSR, но DN может формироваться на основе собственных правил и данных, полученных в ходе ранее реализованной проверки личности пользователя.
Формирование DN выполняется путем выбора соответствующего RDN из поля со списком и ввода нужного значения в текстовое поле. При нажатии кнопки "Put" объявленное RDN будет помещено в список (List Box), определяющий DN. Если в списке выбрано одно из полей RDN, новое RDN будет вставлено между выбранным и предыдущим полем. Если в списке DN ничего не выбрано, в конце списка вставляется новое поле RDN. Чтобы отменить выделение в списке, нажмите кнопку «Отменить выбор». Неправильное RDN можно удалить из списка, нажав кнопку "Удалить". Порядок поля RDN можно изменить с помощью кнопок «Вверх» и «Переместить вниз», которые влияют на избыточность выбранного RDN в списке.
Расширения являются необязательной частью КСО, и центр сертификации (ЦС) может рассмотреть или отклонить их в зависимости от политики сертификации. Можно присвоить больше атрибутов, и желательно определить адрес электронной почты в пределах альтернативной темы субъекта (альтернативное имя субъекта, сокращенно subjectAltName), потому что это наиболее распространенный для этой цели эмитент сертификата в обычном для этой цели месте. Для расширений порядок отдельных атрибутов не важен. Предполагается, что желаемое назначение ключей, расширенное назначение ключей и операторы, связанные с квалифицированными сертификатами, все еще могут быть определены. Еще раз следует подчеркнуть, что эмитенты сертификата могут игнорировать расширения, и только некоторые из них могут выдавать так называемые квалифицированные электронные сертификаты. В любом случае, в рамках расширений пользователь может указать желаемые элементы будущего сертификата, но, опять же, окончательная ликвидация сертификата X.509 зависит исключительно от их эмитента и что все детали должны быть полностью ознакомлены с их политиками до заключения договора выдачи.
Выбор хэш-алгоритма осуществляется из поля со списком, помеченного «алгоритмом дайджеста подписывающей стороны». По умолчанию используется SHA-256, который относится к алгоритму SHA2, который имеет 256 бит на выходе или 32 байта, и это рекомендуется использовать для CSR. SHA1 больше не рекомендуется, а SHA2 с большим количеством байтов на выходе (384 и 512), а алгоритм SHA3 планируется к более частому использованию в будущем.
Ключи и их параметры («алгоритм шифрования подписывающей стороны» и «индекс ключа подписывающего лица (карточка)») здесь не могут быть изменены и уже определены на вкладке, с которой вы открыли этот диалог («Ключи RSA» или «Ключи EC»), и их назначение здесь только информативное. Если «Ключи RSA» или «Ключи EC», с помощью которых вы открывали диалог CSR, на этикетке, указывающей размер ключа RSA, не было соответствующего открытого ключа, ранее прочитанного с карты, то кривая ECDSA будет обозначена как «Открытый ключ не установлен». Когда открытый ключ не установлен, невозможно выполнить «Sign and Save CSR», но можно загрузить DN и расширения из существующего CSR или так называемого TBS CSR.
TBS CSR — это наш внутренний формат записи так называемого запроса «Быть подписанным», который может служить шаблоном для создания запросов CSR с несколькими общими функциями. TBS CSR не содержит криптографических ключей, а хранит только DN и расширения.
Нажатие кнопки «Очистить записи» удаляет все элементы в DN и расширении, так что диалоговое окно подготовлено для новой записи.
Нажав клавишу «Подписать и сохранить CSR», выполняется подписание CSR в карточке и сохранение ее в выбранном файле. Если карта не находится в поле подключенного считывателя uFR или введен неправильный PIN-код пользователя, вы получите сообщение об ошибке с соответствующим описанием.
Последнее, что нужно сделать после генерации CSR, это отправить его издателю сертификата для получения сертификата X.509. Вы можете выбрать любого из коммерческих или некоммерческих эмитентов сертификатов или, нажав кнопку «Получить сертификат онлайн», вы можете отправить CSR в наш веб-сервис для получения демонстрационного, тестового сертификата, выданного «Digital Logic Ltd.». Сертификаты испытаний. Демонстрация, сертификат теста предназначен только для тестового использования и срок его действия составляет 3 месяца. Сопутствующие корневые и промежуточные сертификаты ЦС можно загрузить с http://ca.d-logic.com.
Если вы нажмете на кнопку «Получить сертификат онлайн», вам будет предложено ввести ранее сохраненный CSR-файл с расширением «.pem», который будет отправлен на HTTP-сервер. В связи с сервером на https://certificates.d-logic.com успешно и сертификат X.509 выдан, вам будет предложено ввести имя файла для сохранения сертификата. В противном случае появится соответствующее сообщение об ошибке.
X.509 Объектов
Эта вкладка предназначена для управления объектами X.509, связанными с сертификатами на карточках подписывающих лиц DL. Чтобы считывать объекты X.509 с карты, не обязательно входить в систему с каким-либо из PIN-кодов. Чтобы изменить содержимое хранилища для объектов X.509 на карте, необходимо авторизоваться с PIN-кодом SO на странице «PIN-коды».
На вкладке "X.509 Objects" приложение сразу же пытается прочитать карту, которая присутствует в поле считывателя uFR. Если в поле нет DL Signer Card, появится сообщение об ошибке, как показано на рисунке ниже:
Если хранилище объектов X.509 успешно считано с карты, списки отображения сертификатов будут заполнены этим содержимым. Вы можете обновить эти списки в любое время, поместив нужную карту в поле считывателя и нажав кнопку «Обновить объекты с карты».
Выбор файла сертификата X.509 осуществляется нажатием клавиши «Открыть файл сертификата». Также возможно чтение сертификатов из файлов в формате PEM (в кодировке Base64), которые обычно имеют расширение ".pem" или из двоичных файлов, написанных в стандарте ASN.1 (DER-кодировке), которые могут иметь расширения ".crt", ".cer" или ".der". Если выбран допустимый файл, отобразится системное диалоговое окно с содержимым выбранного сертификата X.509. После проверки элементов сертификата достаточно подтвердить это нажатием кнопки «ОК».
Для хранения выбранного сертификата в карточке необходимо ввести требуемый идентификатор объекта (произвольную буквенно-цифровую символьную строку), который должен быть уникальным по отношению к другим сертификатам, хранящимся на карте. Идентификатор объекта вводится в текстовое поле "Идентификатор объектов:". Предложение состоит в том, чтобы сертификаты, содержащие открытые ключи RSA, были помечены идентификатором, например. От «0001» до «0003» и те, которые содержат открытые ключи ECDSA, будут помечены идентификатором, например. "1001" до "1003". Сертификаты ЦС также должны иметь уникальную идентификационную метку на карте, поэтому предлагается пометить их, например, от «5001» до «5012». По-прежнему необходимо выбрать тип ключа. Для типов RSA и ECDSA индекс закрытого ключа в карточке привязан к этому сертификату, и эти индексы должны быть согласованными. Для центра сертификации ЦС порядок индексов не актуален, но из-за прозрачности по рекомендации их следует вводить по порядку, один за другим парами, например, от root до intermediate. Приложения, поддерживающие модуль PKCS#11 и использующие сертификаты X.509, работают, считывая все общедоступные объекты с карты, а затем проверяя цепочку доверия на основе содержимого самих сертификатов. В конце нужно нажать кнопку с описательным названием «Поставить сертификат из файла в карточку с обозначенным ID, типом объекта и индексом».
Мы упомянули корневую и промежуточную пары сертификатов ЦС, и, возможно, потребуется дополнительно уточнить это. Здесь мы предположили, что сертификат конечной сущности в цепочке доверия устанавливается через промежуточный сертификат корневого ЦС. Это обычный способ формирования цепочки доверия официальными эмитентами сертификата. Однако это не строгое правило, и в других конфигурациях можно изменять сертификаты ЦС, которые образуют цепочку доверия. Важно подчеркнуть, что всегда есть два окончательных сертификата, в начале цепочки, так называемый корневой (корневой) сертификат ЦС и в конце цепочки сертификат конечной сущности (конечный сертификат)
Подпись
На вкладке «Подпись» есть команды для получения цифровых подписей с карты. Набор данных из строки ввода с меткой «M:» (сообщение) или файл, путь к которому можно задать, нажав на переключатель «Установить файл для подписи», может быть подписан. Данные могут быть введены в шестнадцатеричном (HEX) формате, в кодировке Base64 или в макете кода ASCII.
Шестнадцатеричный формат (HEX) включает пары шестнадцатеричных цифр, которые могут быть разделены пробелами. Формат Base64 часто используется в криптографии и PEM-записях сертификатов X.509. Здесь мы не будем подробно разбираться с форматом Base64. Макет кода ASCII является широко используемым стандартом для записи текстовых наборов данных, которые включают все буквенно-цифровые символы, а также все стандартные знаки препинания. В принципе, все, что можно ввести через стандартную английскую клавиатуру США, покрывается раскладкой кода ASCII. Если случайно будут введены символы, которые не являются частью макета кода ASCII, и выбран этот параметр, эти символы будут заменены внутренне символом '?'. Символы, которые не являются частью раскладки кода ASCII, можно ввести с помощью некоторых локализованных клавиатур или выбрав опцию «вставить» в контекстном меню текстового поля «M:».
Когда некоторые данные вводятся во входную строку, преобразование в другой тип записи выполняется простым выбором желаемого формата записи (параметры HEX / Base64 / ASCII), за исключением случаев, когда есть ошибка ввода.
При нажатии на переключатель "Установить файл для подписи" открывается стандартное для операционной системы Windows диалоговое окно выбора файла. Когда файл выбран, путь к нему устанавливается в текстовое поле "M:".
При нажатии кнопки «Сохранить сообщение в двоичный файл» можно сохранить массив байтов, введенных в текстовом поле «M:», в двоичный файл.
Выбрав «Получить подпись», подлежащие подписанию данные проходят через выбранный хэш-алгоритм (Message digest algorithm), результат которого отправляется на карту. Затем карта генерирует подпись на основе выбранного криптографического алгоритма из поля со списком «Алгоритм шифрования» (RSA или ECDSA) и индекса ключа в карточке (поле со списком «Индекс ключа в карточке»). Для подписания карты необходимо заранее войти в систему с ПОМОЩЬЮ PIN-кода пользователя.
После успешного подписания значение цифровой подписи отображается в текстовом поле «Подпись» в формате HEX или Base64 в зависимости от выбранного параметра. Изменив выбор HEX / Base64, можно преобразовать дисплей подписи. Подпись можно сохранить в двоичном файле, нажав кнопку «Сохранить подпись в двоичный файл».
Также реализовано дополнительное вычисление хэш-значения цифровой подписи. Выбор хэш-алгоритмов для этой цели также включает в себя устаревший алгоритм MD5 по историческим причинам, так как некоторые старые криптографические системы все еще зависят от этого механизма. Хэш-значение цифровой подписи можно сохранить в двоичном файле, нажав кнопку «Сохранить хэш в файл».
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
