Я расскажу о тонкостях внедрения электронной цифровой подписи (ЭЦП) в информационные системы (ИС) на базе веб технологий в контексте Национального Удостоверяющего Центра Республики Казахстан (НУЦ РК).

В центре внимания будет формирование ЭЦП под электронными документами и, соответственно, NCALayer предоставляемое НУЦ РК криптографическое программное обеспечение. В частности уделю внимание вопросам связанным с UX и объемом поддерживаемого функционала NCALayer.

Процесс разделю на следующие этапы:

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

Формирование неизменного представления подписываемого документа

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

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

• извлечь все поля записи, привести их к строкам и соединить в одну строку;
• сформировать XML или JSON представление;
• сформировать PDF документ на базе шаблона с каким-то оформлением содержащий данные из записи;
• и т.п.

Далее возможны два сценария каждый из которых имеет свои подводные камни:

• ИС не хранит сформированного представления и каждый раз для проверки подписи под документом (в частности проверки неизменности данных) формирует его;
• ИС хранит сформированное представление и использует его для проверки подписи.

В том случае, если ИС не хранит сформированного представления, разработчикам необходимо гарантировать что в будущем формируемые представления будут бинарно идентичны тем, которые были сформированы в первый раз не смотря на:

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

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

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

Подписание документа в веб интерфейсе с помощью NCALayer

Для формирования цифровых подписей на стороне клиента НУЦ РК предоставляет единственный инструмент сертифицированное программное обеспечение NCALayer которое представляет из себя WebSocket сервер, запускаемый на 127.0.0.1, которому можно отправлять запросы на выполнение криптографических (а так же некоторых смежных) операций. При выполнении некоторых операций NCALayer отображает диалоговые окна то есть берет часть работы по получению пользовательского ввода на себя.

Описание API NCALayer доступно в составе комплекта разработчика. Для того, чтобы поэкспериментировать со взаимодействием с NCALayer по WebSocket можно воспользоваться страницей интерактивной документации KAZTOKEN mobile (KAZTOKEN mobile повторяет API NCALayer).

Взаимодействовать с NCALayer из браузера можно напрямую с помощью класса WebSocket, либо можно воспользоваться библиотекой ncalayer-js-client которая оборачивает отправку команд и получение ответов в современные async вызовы.

Замечу что весь основной функционал NCALayer доступен в модуле kz.gov.pki.knca.commonUtils, использовать модуль kz.gov.pki.knca.applet.Applet (наследие Java аплета) не рекомендую, так как, на мой взгляд, это не даст никаких преимуществ, но шансов выстрелить себе в ногу с ним больше к примеру можно случайно разработать интерфейс который не будет поддерживать аппаратных носителей (токенов или смарт-карт) с несколькими ключевыми парами.

Модуль kz.gov.pki.knca.commonUtils берет на себя взаимодействие с пользователем связанное с выбором конкретного хранилища, которое нужно использовать для выполнения операции (так же он берет на себя выбор конкретного сертификата и соответствующего ключа, а так же ввод пароля или ПИН кода), но ему необходимо указать какой тип хранилищ нужно использовать. Типы хранилищ стоит разделить на два класса:

• файловые, поддерживается единственный тип заданный константой 'PKCS12',
• аппаратные (токены и смарт-карты), для перечисления тех типов, экземпляры которых в данный момент подключены в ПК пользователя, следует использовать запрос getActiveTokens.

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

• гибкий отправить запрос getActiveTokens, в ответ получить массив имен доступных а данный момент типов хранилищ, добавить в него 'PKCS12' и спросить у пользователя каким он хотел бы в данный момент воспользоваться;
• простой отправить запрос getActiveTokens, в том случае, если он вернул массив несколькими именами, попросить пользователя отключить лишнее, если в массиве один элемент, использовать его, если массив пустой, использовать 'PKCS12'.

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

• createCAdESFromBase64 вычислить подпись под данными и сформировать CMS (CAdES);
• createCMSSignatureFromBase64 вычислить подпись под данными, получить на подпись метку времени (TSP) и сформировать CMS (CAdES) с внедренной меткой времени;
• signXml вычислить подпись под XML документом, сформированную подпись добавить в результирующий документ (XMLDSIG);
• signXmls аналогично signXml, но позволяет за один раз подписать несколько XML документов.

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

Модуль kz.gov.pki.knca.commonUtils поддерживает следующие типы сертификатов:

• 'AUTHENTICATION' сертификаты для выполнения аутентификации;
• 'SIGNATURE' сертификаты для подписания данных.

NCLayer предоставит пользователю выбирать только из тех сертификатов, которые соответствуют указанному типу.

Упрощенный пример подписания произвольного блока данных с использованием ncalayer-js-client:

async function connectAndSign(base64EncodedData) {  const ncalayerClient = new NCALayerClient();  try {    await ncalayerClient.connect();  } catch (error) {    alert(`Не удалось подключиться к NCALayer: ${error.toString()}`);    return;  }  let activeTokens;  try {    activeTokens = await ncalayerClient.getActiveTokens();  } catch (error) {    alert(error.toString());    return;  }  const storageType = activeTokens[0] || NCALayerClient.fileStorageType;  let base64EncodedSignature;  try {    base64EncodedSignature = await ncalayerClient.createCAdESFromBase64(storageType, base64EncodedData);  } catch (error) {    alert(error.toString());    return;  }  return base64EncodedSignature;}

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

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

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

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

Выполнять проверки необходимо с применением сертифицированных средств, к примеру с помощью библиотек входящих в состав комплекта разработчика НУЦ РК, либо можно воспользоваться готовым решением SIGEX.

Подготовка подписи к долгосрочному хранению

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

Для фиксации момента подписания принято использовать метки времени TSP. Метку времени на подпись можно получить либо на клиенте (запрос createCMSSignatureFromBase64 интегрирует метку времени в CMS), либо на сервере. Метка времени позволит удостовериться в том, что момент подписания попадает в срок действия сертификата.

Для того, чтобы удостовериться в том, что сертификат не был отозван в момент подписания, следует использовать CRL или OCSP ответ. Этот нюанс и рекомендации по реализации описаны в разделе APPENDIX B Placing a Signature At a Particular Point in Time документа RFC 3161.

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

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

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

Речь будет идти о сертификатах ЭЦП, выпущенных НУЦ РК.

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

Я буду использовать:

• Vue.js для удобства разработки (постараюсь не писать ничего специфического, так, чтобы можно было легко переключиться на любой другой);
• Bootstrap для базового оформления (его практически не будет заметно);
• axios для упрощения сетевого взаимодействия;
• pdfmake для создания PDF из JS;
• ncalayer-js-client для взаимодействия с NCALayer;
• SIGEX для проверки подписей и отправки документов по электронной почте.

Для реализации мне потребуются:

• шаблон электронного документа, состоящий из фиксированной части и полей, которые должен заполнять пользователь;
• действующий сертификат ЭЦП НУЦ РК;
• установленный NCALayer.

В самой статье я приведу только ключевые части кода, а с полной реализацией можно ознакомиться тут: https://github.com/sigex-kz/example-sign-web-form

Веб форма

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

<form v-on:submit.prevent="compilePDF">  <h2>{{ formHeader }}</h2>  <p>{{ formIntro }}</p>  <div v-for="formItem in formItems" class="form-group">    <label>{{ formItem.label }}</label>    <input v-model="formItem.value" type="text" class="form-control">  </div>  <button type="submit" class="btn btn-primary">Сформировать документ</button></form>

Фиксированные части формы буду заполнять в объекте данных Vue.js для того, чтобы их можно было использовать и в HTML и в PDF:

new Vue({...  data: {    formHeader: 'Документ 1',    formIntro: 'Этот документ сформирован в браузере из данных веб формы, является примером, он никого ни к чему не обязывает и ничего не гарантирует, несмотря на то, что он может быть подписан ЭЦП.',    formItems: [      { label: 'Первый вопрос', value: '', },      { label: 'Второй вопрос', value: '', },      { label: 'Третий вопрос', value: '', },    ],...  },...

Генерация PDF в JS

Для формирования PDF воспользуюсь библиотекой pdfmake, она создает PDF файл из определения объекта JS.

Сначала сформирую объект определения и наполню его данными, после этого передам его в pdfmake и получу байты PDF файла в base64 кодировке:

async compilePDF() {  const pdfDefinition = {    content: [      { text: this.formHeader, fontSize: 20, bold: true, alignment: 'center', margin: [ 0, 0, 0, 20 ] },      { text: this.formIntro, fontSize: 15, margin: [ 0, 0, 0, 20 ] },    ],  };  for (const formItem of this.formItems) {    pdfDefinition.content.push(`${formItem.label}: ${formItem.value}`);  }  this.dataB64 = await new Promise((resolve) => {    const pdfDocGenerator = pdfMake.createPdf(pdfDefinition);    pdfDocGenerator.getBase64(resolve);  });},

Подписание PDF цифровой подписью

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

<p>Вы подписываете документ <a v-bind:href="`data:application/octet-stream;base64,${dataB64}`" target="_blank" v-bind:download="title">{{ title }}</a>.</p>

НУЦ РК предоставляет сертифицированное средство ЭЦП приложение NCALayer, его и буду использовать для формирования подписи. NCALayer это WebSocket сервер, чтобы не писать обработку отправки и получения команд вручную, воспользуюсь библиотекой ncalayer-js-client.

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

const storageTypes = await this.ncaLayer.getActiveTokens();if (storageTypes.length == 0) {  this.storageType = 'PKCS12';} else {  this.storageType = storageTypes[0];}

Теперь можно подписать PDF. В зависимости от типа запрошенного хранилища, NCALayer отобразит соответствующий пользовательский интерфейс и завершит процедуру:

const signature = await this.ncaLayer.createCMSSignatureFromBase64(this.storageType, this.dataB64);

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

• электронный документ в виде PDF файла;
• цифровая подпись под электронным документом.

Проверка подписи и пересылка электронного документа по электронной почте

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

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

let response = await axios.post(  `${this.sigexURL}/api`,  {    title: this.title,    description: this.description,    signature,    emailNotifications: { to: ['some-manager@example.kz', this.email] },  },);this.sigexId = response.data.documentId;

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

Вторым этапом передам сервису на проверку подписанный документ:

const dataToSend = Uint8Array.from(atob(this.dataB64), c => c.charCodeAt(0)).buffer;response = await axios.post(  `${this.sigexURL}/api/${this.sigexId}/data`,  dataToSend,  {    headers: { 'Content-Type': 'application/octet-stream' },  },);

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

Итог

Проверим соответствие поставленной задаче:

• на основе заранее согласованного шаблона сформировать в веб интерфейсе электронный документ реализовано в виде статической веб страницы и небольшого количества JS кода;
• предоставить возможность подписать его ЭЦП реализовано с использованием рекомендуемого сертифицированного ПО;
• передать его для обработки группе менеджеров реализовано путем отправки подписанных документов на электронный адрес ответственных менеджеров;
• обеспечить юридическую значимость в соответствии с законодательством РК реализовано с помощью API сервиса SIGEX.