Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Функция sign производит выработку подписи в формате CMS, что требует наличия сертификата. Для того, чтобы можно было произвести подпись без сертификата, только с использованием закрытого ключа, существует функция rawSign. Данная функция выдает "сырую" подпись ГОСТ Р 34.10-2001 в hex-формате. Функция, в зависимости от опций, либо считает переданные данные хэшом и производит только подпись этого хэша, либо производит вычисление хэша, а затем уже его подписывает его. В случае использования Рутокен PINPad и ключа с флагом визуализации в качестве опций должно быть передано хэширование данных, аппаратное вычисление хэш-функции и данные должны передаваться в форматированном виде (см. Приложение)

...

  • Для проверки подписи в плагине предусмотрена функция verify. Эта функция принимает "отсоединенную" или "присоединенную" подпись в формате CMS.
  • В случае "отсоединенной" подписи в параметре options.data должны быть переданы данные. Если параметр options.base64 установлен в true, то перед проверкой подписи данные будут декодированы из формата base64 в бинарный формат.
  • Проверка подписи производится в два этапа при установленной в true опции options.verifyCertificate: сначала проверяется подпись под данными с помощью открытого ключа из сертификата (который находится в CMS, либо передается через options.certificates), затем проверяется подпись под сертификатом с помощью открытого ключа из корневого сертификата. В случае установленной оцпии опции options.verifyCertificate в false проверяется только подпись под данными, подпись под сертификатом не проверяется. 
  • Для проверки подписи под сертификатом используются корневые сертификаты, хранящиеся на устройстве (импортированные на устройство как корневые). Кроме того, спикок список корневых можно расширить, передав в параметре options.CA массив дополнительных корневых сертификатов (в формате PEM). 
  •  Параметр options.certificates предназначен для того, чтобы передать массив сертификатов, на каждом из которых будет плагин, будет пытаться проверить подпись. При этом сертификат, содержащийся в CMS, будет проигнорирован. 
  • Для проверки того, не отозван ли сертификат, на котором производится проверка подписи предусмотрен параметр options.CRL, в который передается массив CRL (список отзыва), каждый в формате PEM.
  • При установке опции options.useHardwareHash в true при проверке подписи будет использоваться аппаратное вычисление хэш-функции ГОСТ Р 34.11-94.

Шифрование данных и

...

(или) файлов

Для того, чтобы обеспечить конфиденциальность обмена данными между клиентом и сервером в плагине предусмотрено шифрование /(расшифрование) данных. Данные шифруются  в формате CMS. Для того, чтобы зашифровать данные в формате CMS, требуется сертификат открытого ключа "адресата". При этом расшифровать такое сообщение сможет только владелец закрытого ключа. При шифровании данных для сервера рекомендуется хранить сертификат сервера на Рутокен PINPad. Этот сертификат может быть записан на устройство при регистрации пользователя на портале. Для этого следует использовать функцию importCertificate, при этом в качестве параметра category следует передать "other". Для использования в функции cmsEncrypt нужно получить тело сертификата по его дескриптору с помощью функции getCertificate. При этом дескриптор является уникальным и неизменным и может быть сохранен в учетной записи пользователя на сервере при импорте сертификата сервера. Для того, чтобы использовалось аппаратное шифрование по ГОСТ 28147-89, требуется установить опцию useHardwareEncryption в true. В противном случае будет использована быстрая программная реализация ГОСТ 28147-89. 

...

 Схема с 2 ключами и 2 сертификатами 

Image Modified

 

  • В этой схеме все платежки классифицируются как “белые” (доверенный респодент, незначительная сумма и т.д. , в зависимости от логики работы антифрод-системы) и “черные”. Такое разделение необходимо для того, чтобы не заставлять пользователя просматривать все платежки и подтверждать ЭП на экране Рутокен PINPad, что может быть физически трудно в случае большого количества платежек. “Белые” и “черные” платежки подписываются юридически значимой подписью, а “черные” дополнительно подписываются технологической подписью с визуализацией данных платежки на экране  Рутокен PINPad. И только при наличии и успешной проверке двух таких подписей, банк проводит платеж.
  • В этой схеме создаются 2 ключевые пары, при этом один ключ создается без флага визуализации, но с флагом дополнительной защиты. Второй создается с флагом визуализации, но без флага дополнительной защиты.
  • Для каждого ключа выдается по сертификату. Связка первый ключ + сертификат используется для формирования юридически значимой подписи CMS/PKCS#7 под всеми платежками с помощью вызова sign. Связка второй ключ + сертификат для подтверждения платежка путем формирования второй подписи CMS/PKCS#7 с визуализацией подписываемых данных с помощью вызова sign.  

  • Для того, чтобы банк показывал пользователю  только один сертификат можно маркировать второй специальным OID-ом в extKeyUsage. При поиске сертификатов на токене следует разбирать каждый и при наличии расширения не предоставлять его для выбора пользователю. Сопоставление второго сертификата первому можно проводить, например, также по уникальному OID, который прописывается в extKeyUsage обоим сертификатам. 
    Image Modified
  • Другим вариантом сопоставления основного и технологического сертификатов является запоминание дескрипторов обоих сертификатов в аккаунте пользователя на сервере. Функция поиска сертификатов enumerateCertificates каждый раз выдает уникальный и неизменный дескриптор для одного и того же сертификата. Следует отметить, что функция поиска закрытых ключей enumerateKeys также каждый раз возвращает уникальный и неизменный дескриптор для одного и того же ключа. 

...

  • В этой схеме все платежки классифицируются как “белые” (доверенный респодент, незначительная сумма и т.д. в зависимости от логики работы антифрод-системы) и “черные”. Такое разделение необходимо для того, чтобы не заставлять пользователя просматривать все платежки и подтверждать ЭП на экране Рутокен PINPad, что может быть физически трудно в случае большого количества платежек. “Белые” и “черные” платежки подписываются юридически значимой подписью, а “черные” дополнительно подписываются технологической подписью с визуализацией данных платежки на экране  Рутокен PINPad. И только при наличии и успешной проверке двух таких подписей банк проводит платеж.
      
  • В этой схеме создаются 2 две ключевые пары, при этом один ключ создается без флага визуализации, но с флагом дополнительной защиты. Второй создается с флагом визуализации, но без флага дополнительной защиты. При регистрации пользователя в системе должен быть зарегистрирован первый сертификат и отрытая часть для второго ключа. Открытая часть второго ключа, с помощью которой на сервере будет проверяться вторая подпись, может быт получена в hex-формате путем вызова функции getPublicKeyValue. При регистрации открытой части второго ключа требуется подписать некоторый текст в формате PINPad на клиенте на втором закрытом ключе, затем проверить подпись на сервере с помощью открытой части второго ключа. И только после этого сохранить открытую часть второго ключа в аккаунте пользователя.

  • Связка первый ключ + сертификат используется для формирования юридически значимой подписи CMS/PKCS#7 под всеми платежками с помощью вызова sign. Второй ключ служит для подтверждения платежки путем формирования "сырой" подписи ГОСТ Р 34.10-2001 с визуализацией подписываемых данных с помощью вызова rawSign.

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

...

<!PINPADFILE UTF8> обязательный признак строки, которая будет распознаваться Рутокен PINPad

<!>some text...... текст не распознаваемый Рутокен PINPad
<N>some text..... наименование поля
<V>some text..... значение поля
каждое
Каждое наименование поля и соответствующее значение поля располагаются на одной строке строке.
перед Перед каждым новым тегом <N> производится перевод строки.
количество Количество пар значений <N> , и <V> может быть произвольным.

Пример сообщения на PINPad

...

ФИО: Петров Петр Петрович Москва, Пионерская ул, д. 3, кв. 72

Перевод со счета : 42301810001000075212
Сумма : 150000
Валюта : RURRUB
Наименование получателя : Иванова Елена Ивановна

...

Тестовое платежное поручение в виде, распознаваемом Рутокен PINPad

<!PINPADFILE RU> <!>невидимый текст <N>ФИО:<V>Петров Петр Петрович Москва, Пионерская ул, д. 3, кв. 72 <N>Перевод со счета:<V>42301810001000075212 <N>Сумма:<V>150000 <N>Валюта:<V>RUR <N>Наименование получателя:<V>Иванова Елена Ивановна <N>Номер счета получателя:<V>40817810338295201618 <N>БИК банка получателя:<V>044525225 <N>Наименование банка получателя:<V>ОАО 'СБЕРБАНК РОССИИ' Г. МОСКВА <N>Номер счета банка получателя:<V>30101810400000000225 <N>Назначение платежа:<V>перевод личных средств

...