Page tree
Skip to end of metadata
Go to start of metadata

Оглавление

Введение

Рутокен PINPad представляет собой устройство класса trustscreen. Он используется в качестве:

  • Аппаратного модуля криптографии, реализующего функции электронной подписи, хэширования и шифрования
  • Хранилища цифровых сертификатов
  • Устройства визуализации подписываемой информации

В данном документе описано встраивание Рутокен PINPad через Рутокен Плагин.

Типовые сценарии

Рутокен Плагин с связке с Рутокен PINPad позволяет реализовывать следующие сценарии:

  1. Смена PIN-кода пользователем
  2. Регистрация на портале 
    1. Генерация ключевой пары и формирование запроса на сертификат
    2. Импорт сертификата на устройство
  3. Аутентификация на портале
  4. Электронная подпись данных и/или файлов в формате CMS
  5. Шифрование данных и/или файлов
  6. Обновление сертификата

Определение подключенных устройств

Любой сценарий начинается с определения всех подключенных к компьютеру устройств Рутокен PINPad. 

var devices = Array();
try 
{
    devices = plugin.enumerateDevices();
}
catch (error) 
{
    console.log(error);
}

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

Рутокен Плагин определяет все подключенные к компьютеру  USB-устройства Рутокен ЭЦП, Рутокен WEB и Рутокен PINPad. Поэтому следующим шагом следует определить тип устройства.

Определение типа устройства

Для определения типа устройства следует использовать функцию getDeviceInfo с параметром TOKEN_INFO_DEVICE_TYPE. Значение этой константы содержится в объекте плагина. Для Рутокен PINPad результатом вызова данной функции будет TOKEN_TYPE_RUTOKEN_PINPAD_2, числовая константа, которая так же находится в объекте плагин.

             Пример:

var type;
try 
{  
  type = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_DEVICE_TYPE);
}
catch (error) 
{
    console.log(error);
}

switch (type) 
{
        case plugin.TOKEN_TYPE_UNKNOWN:
             message = "Неизвестное устройство";
             break;
        case plugin.TOKEN_TYPE_RUTOKEN_ECP:
            message = "Рутокен ЭЦП";
            break;
        case plugin.TOKEN_TYPE_RUTOKEN_WEB:
             message = "Рутокен Web";
             break;
        case plugin.TOKEN_TYPE_RUTOKEN_PINPAD_2:
             message = "Рутокен PINPad";
             break;
  }

Типы объектов на Рутокен PINPad по уровню защиты от НСД

В Рутокен PINPad существуют 3 типа объектов, отличающиеся уровнем защиты от НСД:

  • Объекты, доступ в режиме чтения к которым не требует авторизации (например, цифровые сертификаты и открытые ключи).

                      Пример чтения сертификатов с устройства:

var certs = Array();
try 
{	
	certs = plugin.enumerateCertificates();
}
catch (error) 
{
    console.log(error);
}

           В данном примере функция enumerateCertificates не требует предварительно вызова функции login. Следует отметить, что функция записи сертификата на Рутокен PINPad (importCertificate) требует вызова login и ввода PIN1 (см. ниже), если PIN1 не находится в кэше.   

  • Объекты, доступ к которым требует ввода PIN-кода на клавиатуре компьютера, этот PIN-код (PIN1) передается в устройство через программный интерфейс. К таким объектам относятся закрытые ключи, не помеченные специальным флагом повышенной защиты. Флаг повышенной защиты нельзя установить ключу после его генерации.

                    Пример генерации ключа без флага повышенной защиты:

var options = {};
options.needPin = false;
 
try
{
	plugin.login(deviceId, "12345678");        
	plugin.generateKeyPair(deviceId, "A", null, options);      
}
catch (error) 
{
    console.log(error);
}

         В данном примере функция требуется вызов login для ввода PIN1.

  • Объекты, доступ к которым требует ввода PIN1 и дополнительного PIN-кода на экране Рутокен PINPad (PIN2). PIN2 обычно идентичен PIN1, что удобно для пользователя. К таким объектам относятся ключи, которые при генерации были помечены специальным флагом повышенной защиты.  Флаг повышенной защиты нельзя снять с ключа после его генерации. PIN2 является одинаковым для всех закрытых ключей, который были созданы с флагом повышенной защиты.

             Пример генерации ключа c флагом повышенной защиты:

var options = {};
options.needPin = true;
 
try
{
	plugin.login(deviceId, "12345678");
    plugin.generateKeyPair(deviceId, "A", null, options);
}
catch (error) 
{
    console.log(error);
}

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

 

Логин на устройство (PIN1)

Для логина на устройство используется фукция login, в которую следует передать PIN1.

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

 		var isLoggedIn = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_IS_LOGGED_IN);  

Кэширование PIN1

В Рутокен Плагин предусмотрено программное кэширование PIN1. При этом PIN1 вводится один раз, а затем вместе с серийным номером устройства сохраняется в кэш для текущего пользователя ОС и хранится в нем в защищенном виде. Если PIN1 закэширован, то для функций создания запроса (createPkcs10), подписи (sign), проверки подписи (verify) и иных, требующих авторизации на устройстве, не нужно будет предварительно вызывать функцию login. Если PIN1 находится в кэше, то вызов logout кэш для PIN1 не сбрасывает, но при этом сбрасывается кэш для PIN2 (см. ниже).

  • Через API Рутокен Плагин можно узнать, закэширован ли PIN1 для подключенного Рутокен PINPad:
		var isPinCached = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_IS_PIN_CACHED);          
  • Сохранение PIN1 в кэш:
		plugin.login(deviceId, "12345678");
	 	plugin.savePin(deviceId);
  • Удаление PIN1 из кэша:
		var isPinCached  = plugin.getDeviceInfo(deviceId, plugin.TOKEN_INFO_IS_PIN_CACHED);
        if(isPinCached == true)
        	plugin.removePin(deviceId);

Кэширование PIN2

PIN2 кэшируется при первом вводе на экране Рутокен PINPad непосредственно самим устройством. Кэш сбрасывается в 3-х случаях:

  • при отключении устройства от компьютера

  • в случае если пользователь не подтверждает процедуру подписи на экране устройства в течение 15 минут

  • при вызове функции logout из API Рутокен Плагин


Смена PIN1

Смена PIN1 производится вызовом функции changePin.

Визуализация подписываемых данных

Флаг визуализации присваивается закрытому ключ при генерации. Если ключ был создан с флагом визуализации, то данные, которые подписываются с помощью этого закрытого ключа, будут перед подписью показаны на экране устройства и для их подписи потребуется подтверждение пользователя в виде нажатия специальной кнопки на touchscreen. Данные в этом случае должны быть поданы на подпись в отформатированном виде. Формат данных для устройства Рутокен PINPad описан в Приложении. Флаг визуализации нельзя установить/снять с ключа после генерации ключа.

            Пример генерации ключа c флагом визуализации:

		var options = {};
		options.needConfirm = true;
        plugin.login("12345678");
        plugin.generateKeyPair(deviceId, "A", null, options);

Типы закрытых ключей

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

 

  • Ключ без визуализации и без повышенной защиты.

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

  • Ключ с визуализацией и без повышенной защиты.

          В этом случае для подписи с помощью ключа требуется ввести PIN1 и подтвердить подпись данных на устройстве при вызове функций sign или rawSign или authenticate. Возможна подпись только форматированных данных.

  • Ключ без визуализации и с повышенной защитой.

          В этом случае для подписи с помощью ключа требуется ввести PIN1 и при вызове функции sign ввести PIN2 на экране устройства. Возможна подпись любых данных.

  • Ключ с визуализацией и с повышенной защитой.

          В этом случае для подписи с помощью ключа требуется ввести PIN1, при вызове функций sign или rawSign или authenticate подтвердить подпись данных на устройстве, затем ввести PIN2 на экране устройства (если на момент вызова sign PIN2 не был закэширован, (см. Кэширование PIN2). Возможна подпись только форматированных данных.

Генерация запроса PKCS#10 на Рутокен PINPad

 Если самоподписанный запрос PKCS#10 на сертификат создается для ключа, который был сгенерирован с флагом визуализации, то при подписании на устройстве в процессе выполнения функции createPkcs10 пользовательская информация из запроса, а также алгоритм открытого ключа и сам открытый ключ будут представлены на экране устройства. При этом для подписи запроса требуется подтверждение пользователя.

                Пример:

		var subject = 
			[ {rdn: "commonName", value: "HabraHabr"}, 
			  {rdn: "pseudonym", value: "pseudonymus"}, 
              {rdn: "emailAddress", value: "example@example.com"} ];
 		var keyUsageVal = [ "digitalSignature","nonRepudiation","keyEncipherment","dataEncipherment" ];
 		var extKeyUsageVal = [ "emailProtection", "clientAuth" ];
 		var certificatePolicies = [ "1.2.643.100.113.2" ];
 		var extensions = { "keyUsage":  keyUsageVal, "extKeyUsage": extKeyUsageVal, "certificatePolicies": certificatePolicies };
 		
		plugin.createPkcs10(deviceID, keyID, subject, extensions, false);         

 

Типы сертификатов

Плагин поддерживает импорт сертификатов трех типов: пользовательский, корневой и "иной". При импорте сертификата (функция importCertificate) ему устанавливается тип посредством параметра category.

  • Пользовательские сертификаты  - это сертификаты, связанные с закрытым ключом пользователя. Применятся, например, для подписи/шифрования CMS/PKCS#7, аутентификации пользователя в протоколе TLS.
    Если сертификат импортируется как пользовательский, то при импорте будет произведен поиск  в устройстве соответствующего ему закрытого ключа. Если такой ключ будет найден, то сертификат будет "привязан" к этому ключу. Если ключ найден не будет, то вернется ошибка. 
  • Корневые сертификаты - это сертификаты издателей сертификатов, применяющиеся для проверки подписи под сертификатами для определения того. Подобная проверка подпис (построение цепочки доверия) позволяет определить, доверяет ли пользователь подписи другого пользователя. Например, в функции плагина verify есть режим проверки сертификата, на котором было подписано сообщение. При этом используется хранилище корневых сертификатов на токене, созданное импортом корневых сертификатов на токен.
  • "Иной" - это сертификат, который не связан с закрытым ключом и не является корневым.

 

Регистрация на портале

Возможны две ситуации – сертификат выдается самой системой, сертификат выдается внешним УЦ.

В первом случае последовательность вызовов такая:

  1. Получаем список подключенных к компьютеру устройств Рутокен PINPad вызовом enumerateDevices 
  2. Генерируем ключевую пару вызовом generateKeyPair
  3. Cоздаем запрос PKCS#10 на сертификат вызовом createPkcs10 
  4. Отправляем запрос на сервер
  5. На сервере создаем сертификат, привязываем к аккаунту (сам сертификат или его дескриптор). Следует отметить, что дескрипторы сертификатов, полученные при вызове функции enumerateCertificates, являются уникальными и неизменными.
  6. Отправляем сертификат на клиент
  7. На клиенте импортируем полученный сертификат на Рутокен PINPad вызовом importCertificate

Во втором такая:

  1. Получаем список подключенных к компьютеру устройств Рутокен PINPad вызовом enumerateDevices 
  2. Получаем список всех имеющихся сертификатов на Рутокен PINPad вызовом enumerateCertificates, с использованием константы CERT_CATEGORY_USER (константа из плагина). При этом будет выдан список сертификатов, связанных с закрытым ключом.
  3. Парсим каждый сертификат вызовом parseCertificate, показываем его пользователю (можно показывать, например, только Common Name)
  4. Пользователь выбирает нужный  сертификат
  5. Сервер формирует начальную последовательность случайных данных (строку salt) и отправляет ее на клиент
  6. Вызываем на клиенте authenticate. При передаче salt в функцию плагина authenticate данная последовательность дополняется дополнительными случайными данными размером в 32 символа, и происходит подпись итоговой последовательности на выбранном пользователем сертификате в формате CMS attached
  7. Подпись отправляется на сервер 
  8. На сервере происходит проверка CMS attached подписи с использованием корневого сертификата УЦ
  9. Из CMS attached сообщения извлекается итоговая случайная последовательность, “отсоединяется”  salt и происходит сравнение
  10. Если сравнение успешно, то регистрируем пользователя по сертификату, который содержится в CMS attached сообщении

Аутентификация на портале

Общая схема аутентификации, используемая в Рутокен Плагин, выглядит следующим образом: 

  1. сервер формирует начальную последовательность случайных данных (строку salt) и отправляет ее на клиент
  2. при передаче salt в функцию плагина authenticate данная последовательность дополняется дополнительными случайными данными размером в 32 символа, и происходит подпись итоговой последовательности на выбранном пользователем сертификате в формате CMS attached
  3. подпись отправляется на сервер
  4. на сервере происходит проверка подписи
  5. из CMS attached сообщения извлекается итоговая случайная последовательность, “отсоединяется”  salt и происходит сравнение
  6. в случае успешной проверки пользователь аутентифицируется на основе сертификата, извлеченного из сообщения CMS

При использование Рутокен PINPad и ключа с флагом визуализации при вызове функции authenticate на экране устройства будет отображено сообщение.  Мы рекомендуем делать сообщение примерно следующего содержания:

Имя пользователя можно взять из поля Common Name пользовательского сертификата. Как следует из приведенной выше схемы функции authenticate передаются случайные данные. Чтобы эти данные не отображались на экране устройства, следует их помещать после тэга <!>.

                Пример:                 

		authData = '<!PINPADFILE UTF8><N>Авторизация<V><N>Подтвердите авторизацию на сайте<V>'  + document.location.protocol + '//' + document.location.hostname + (document.location.port == 80 ? '' : ':' + document.location.port)   + '<N>Вход будет произведен для пользователя<V>' + commonName  + '<!>' + serverRnd;
		var Cms = Authentificate(deviceId, certId, authData);

 

На сервере при проверке подписи в формате CMS следует извлечь из CMS-конверта данные, затем найти в них тэг <!>  и выполнить пункты 6-7 представленной выше схемы для данных, которые идут после этого тэга.

Электронная подпись данных и/или файлов в формате CMS

  1. формируется текстовое сообщение (строка), формирование сообщения может происходить как на сервере, так и на клиенте. В случае использование PINPad сообщение должно быть специальным образом отформатировано (см. Приложение)
  2. если требуется подписать документ произвольного формата (например, PDF), то требуется перекодировать его в формат base64
  3. строка, содержащая данные для подписи, передается в функцию sign
  4. если строка представляет собой закодированные в base64 данные, то параметр функции isBase64 должен быть установлен в true, при этом перед подписью произойдет декодирование данных из base64. Для Рутокен PINPad и ключа с визуализацией данный флаг применим только в том случае, если начальные данные, закодированные в base64, были в формате PINPad (см. Приложение).
  5. если требуется использовать аппаратное вычисление хэш-функции ГОСТ Р 34.11-94 (сертифицированная реализация, скорость 60-70 Кб/c), то в options нужно установить опцию useHardwareHash в true. Если данная опция установлена в false, то будет использована быстрая программная реализация хэш-функции ГОСТ Р 34.11-94. В случае использования Рутокен PINPad и ключа с флагом визуализации опция useHardwareHash всегда должна быть установлена в true.
  6. если требуется сформировать  “отсоединенную” (detached) подпись CMS, то нужно установить опцию detached в true, иначе будет сформирована “присоединенная” (attached) подпись
  7. для того, чтобы включить/не включить пользовательский сертификат в подписанное CMS-сообщение существует опция addUserCertificate
  8. Установка опции addSignTime в true приведет к тому, что в подписанное CMS-сообщение будет добавлено системное время в качестве подписанного атрибута. Данная опция не должна применяться в случае использования для подписи ключа с визуализацией на Рутокен PINPad.
  9. В случае использования Рутокен PINPad и ключа с флагом визуализации при вызове функции sign потребуется подтверждение подписи пользователем на экране устройства:

“Сырая” подпись данных по ГОСТ Р 34.10-2001

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

Пример:

		var options = {};
		options.computeHash = true;
		options.useHardwareHash = true;
		var gost3410signature = rawSign(deviceId, keyId, data, options);

Для проверки "сырой" подписи ГОСТ Р 34.10-2001 на сервере требуется открытый ключ, значение которого может быть получено по дескриптору закрытого вызовом функции getPublicKeyValue из плагина.

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

  • Для проверки подписи в плагине предусмотрена функция 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. 

 

Пример:

// получение "тела" сертификата сервера
// параметр сertRecId привязан к учетной записи пользователя
var recipientCert = getCertificate(deviceId, certRecId);		
var options = {};
options.useHardwareEncryption = true;
 
// параметр certSenderId привязан к учетной записи пользователя
var cms = cmsEncrypt(deviceId, certSenderId, recipientCert, data, options);

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

Пример:

var data = cmsDecrypt(deviceId, keyId, cms, options);

Схемы встраивания Рутокен PINPad

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

 

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

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

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

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

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

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

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

Эта схема является вырожденным случаем "Схемы с 2 ключами и 2 сертификатами". В этом при случае все платежки требуют визуализации и подтверждения. Может применяться при незначительном количестве платежей в день. В этом случае юридическая значимость и визуализация обеспечиваются одной связкой ключ и сертификата.

Приложение 1. Формат входных данных для PINPad

Общая информация

На вход Рутокен PINPad должна подаваться специальным образом отформатированная строка UTF-8. 

где :

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

<!>some text...... текст не распознаваемый Рутокен PINPad
<N>some text..... наименование поля
<V>some text..... значение поля

каждое наименование поля и соответствующее значение поля располагаются на одной строке 
перед каждым новым тегом <N> производится перевод строки
количество пар значений <N>, <V> может быть произвольным

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

тестовое платежное поручение в текстовом виде

ФИО: Петров Петр Петрович Москва, Пионерская ул, д. 3, кв. 72
Перевод со счета : 42301810001000075212
Сумма : 150000
Валюта : RUR
Наименование получателя : Иванова Елена Ивановна

  • Номер счета получателя : 40817810338295201618

БИК банка получателя : 044525225
Наименование банка получателя : ОАО 'СБЕРБАНК РОССИИ' Г. МОСКВА
Номер счета банка получателя : 30101810400000000225
Назначение платежа : перевод личных средств

Тестовое платежное поручение в виде, распознаваемом Рутокен 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>перевод личных средств

 

  • No labels