Что такое пороговые подписи? |

Что такое пороговые подписи? | Электронная цифровая подпись
Содержание
  1. Требования и описание архитектуры
  2. 4 ключевых признака для выбора правильного типа
  3. Tss и мультиподписи
  4. Tss и смарт-контракты
  5. Tss и схема разделения секрета шамира
  6. Адаптация системы делопроизводства
  7. Алгоритм подписания информации (документа)
  8. Блокчейн
  9. В завершение
  10. В чём разница между цифровой и электронной подписью?
  11. Действительность подписи
  12. Зачем нужны сертификаты¶
  13. Как вручную проверить цепочку сертификатов¶
  14. Подробная информация о различных типах электронных подписей
  15. Пороговые кошельки
  16. Пространство доверия
  17. Секретный ключ¶
  18. Сила криптографии
  19. Система использования закрытого ключа для передачи открытого ключа
  20. Система оформления подписи
  21. Система формирования сообщения о персональных данных контрагента
  22. Система хранения ключей
  23. Служба штампов времени
  24. Сочетание tss с блокчейнами
  25. Структура блока
  26. Структура и возможности
  27. Типы электронных подписей
  28. Цепочки удостоверяющих сертификатов¶
  29. Электронная подпись: простая и усиленная

Требования и описание архитектуры

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

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

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

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

4 ключевых признака для выбора правильного типа

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

  1. Подлинность (англ.: Authenticity):

    Требуется ли в подписи однозначная ссылка на подписавшего?

  2. Авторство (англ.: Identity):

    Хотим ли мы быть абсолютно уверены в том, что можем идентифицировать подписавшего?

  3. Целостность (англ.: Integrity):

    Хотим ли мы обнаружить какие-либо изменения в документе после подписи?

  4. Аутентификация (англ.: Authentication):

    Хотим ли мы быть на 100% уверены в том, что подпись создается под исключительным контролем подписавшего?

Если на все четыре вопроса вы дали ответ «определенно, да», то вам потребуется высочайший уровень уверенности — QES. Если ответ «желательно» по всем четырем параметрам, то вы можете выбрать AdES. Если ставки не так высоки, или есть другие обстоятельства идентификации, или вам просто нужно, например, подтверждение прочтения лицензионного соглашения, то самым простым решением будет BES.

Tss и мультиподписи

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

Другими словами, мультиподписи и TSS, в сущности, имеют похожие цели, но TSS использует криптографию вне блокчейна (офчейн), а мультиподписи – в блокчейне (ончейн). Однако блокчейну нужен способ, чтобы зашифровать мультиподпись, что может навредить конфиденциальности, потому что структура доступа (число подписантов) доступна в блокчейне. Стоимость транзакции с мультиподписью выше, потому что информация о подписантах также должна передаваться в блокчейне.

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

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

Tss и смарт-контракты

Исследователи нашли цифровым подписям множество применений, и некоторые из них на удивление нетривиальны. Как уже упоминалось, TSS – это криптографический примитив, способный значительно повысить безопасность. В контексте блокчейнов можно сказать, что криптографией на основе TSS можно заменить многие функциональные возможности.

Над каркасом TSS можно надстраивать децентрализованные приложения, решения масштабирования второго уровня, атомарные свопы, перемешивание монет, механизмы наследования и многое другое. В конечном счёте это позволит заменить дорогие ончейн-операции со смарт-контрактами более дешёвыми и надёжными альтернативами.

Если привести конкретные примеры, то многоскачковая блокировка (Multi-Hop Locks) изобретательным образом использует двусторонние подписи и может служить альтернативой сети Lightning Биткойна с более безопасными и конфиденциальными платёжными каналами.

Tss и схема разделения секрета шамира

Схема разделения секрета Шамира (Shamir secret sharing scheme, SSSS) предоставляет способ распределённого хранения приватного ключа, так что когда он не используется, он хранится в нескольких местах. Между SSSS и TSS есть два различия:

  • Генерация ключей: В SSSS один участник, которого называют «дилером», отвечает за генерацию секретных долей приватного ключа. То есть приватный ключ генерируется в одном месте и затем распределяется дилером между участниками. В TSS дилера нет, так как его роль распределена и нигде никогда нет полного приватного ключа.
  • Подписание: В SSSS, чтобы подписать транзакцию, участники должны восстановить полный приватный ключ, что, опять же, создаёт единую точку отказа каждый раз, когда возникает потребность в подписи. В TSS подписание происходит распределённым способом, и полный приватный ключ из долей секрета не восстанавливается.

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

Адаптация системы делопроизводства

Адаптация системы делопроизводства должна обеспечить неизменяемость документа после подписания.

ПЭП

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

ПЭП

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

ПЭП

, важную роль играет время постановки подписи. Усиленная подпись агента должна быть по времени раньше, чем

ПЭП

контрагента, и этот факт должен быть зафиксирован независимыми источниками. Соответственно, усиленная подпись должна быть с возможностью постановки штампов времени (OID 1.2.643.2.2.34.25). Выполнение этих условий призвано обеспечить как доверие между контрагентом и агентом, так и доверие третьих сторон.

Алгоритм подписания информации (документа)


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

Поскольку асимметричные алгоритмы достаточно медленные по сравнению с симметричными, то объем подписываемых данных играет большую роль и если он велик, то обычно берут хэш от подписываемых данных, а не сами данные. Хэш получают с помощью хэш-функций, например, SHA512, которая принимает на вход некую информацию и возвращает хэш определенной длины.

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

Этапы:

  1. С помощью RSA, генерируем пару публичный и приватный ключи;
  2. Подписываемые данные подставляем в функцию SHA512 и получаем хэш;
  3. Полученный хэш и закрытый ключ подставляем в функцию асимметричного шифрования RSA, то есть RSAEncode(хэш от информации, закрытый ключ), на выходе получим строку – ЭЦП.


Алгоритм подписи данных продемонстрирован на рисунке 2.

Что такое пороговые подписи? |Рисунок 2 — алгоритм подписи данных

Блокчейн

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

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

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

Настоящая статья посвящена одному из таких прорывов – безопасным пороговым подписям (TSS).

Читать по теме: BLS-подписи: лучшая альтернатива подписям Шнорра

В завершение

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

Если вы хотите поэкспериментировать с реализациями TSS, то здесь можно найти код двустороннего кошелька для Binance Chain, или же можете попробовать кошелёк ZenGo, использующий гибридный метод, чтобы предоставить некастодиальное двустороннее решение.

Источник

Вы всегда можете поблагодарить переводчика за проделанную работу:
BTC: 1BHr4jrPPVwdWRpFTekaD34EZ2vo9p8FoC
ETH: 0xf45a9988c71363b717E48645A412D1eDa0342e7E

В чём разница между цифровой и электронной подписью?

Как вы можете видеть выше, существует разница между цифровой и электронной подписью, хотя многие используют эти два термина как синонимы. Разница в основном связана с технологиями.

Читайте также:  Приказ о наделении правом электронной подписи (ЭЦП) - образец по ФЗ-44

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

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

Действительность подписи

В соответствии с 63-ФЗ (Статья 11) документ с УКЭП обладает юридической силой, если:

●    квалифицированный сертификат был действителен на момент подписания либо в момент проверки подписи;

●    сертификат соответствует сформированной подписи;

●    в подписанный документ не вносили изменения.

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

Зачем нужны сертификаты¶

Итак, сертификат (certificate) — это файл, содержащий информацию о персоне или организации и подписанный цифровой подписью, нечто вроде паспорта персоны или организации. Главное содержимое сертификата — это публичный ключ шифрования.

У любого сертификата существует его автор-создатель и у этого автора есть секретный ключ шифрования. По сути сертификат — это всего лишь обёртка над публичным ключом, где помимо собственно ключа содержится разнообразная дополнительная информация: имя персоны или организации, страна, телефон, емейл и так далее.

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

Как вручную проверить цепочку сертификатов¶

Иногда возникает необходимость проверить, подписан ли один сертификат другим. Это можно сделать через openssl.

Возьмём три сертификата из Go Daddy, вот они: GD_root.pem (это корневой сертификат Go Daddy), GD_good.pem, GD_bad.pem. Нам нужно проверить, подписаны ли сертификаты GD_good.pem и GD_bad.pem корневым сертификатом Go Daddy.

Для верификации используем команду openssl verify, в ней мы должны указать файл с «доверенными» сертификатами, в нашем случае это один сертификат GD_root.pem, указывается через аргумент -CAfile GD_root.pem. Также мы указываем заведомо несуществующий путь к главному хранилищу сертификатов удостоверяющих центров, чтобы в процессе верификации участвовал только один сертификат, это делается через аргумент -CApath /nope. В новых версиях openssl (начиная с 1.1.0) введён специальный новый параметр -no-CApath.

И альтернативный вариант (предыдущий в новых версиях не работает):

Подробная информация о различных типах электронных подписей

В таблице ниже вы можете найти подробную информацию о типах подписи.

Тип подписи

BES

AdES

QES

Описание

Все электронные типы подписей, подтверждающие принятие или одобрение подписывающей стороны какого-либо соглашения.

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

Усовершенствованная электронная подпись с цифровым сертификатом, зашифрованным с помощью безопасного (квалифицированного) устройства подписи.

Имеет особый правовой статус в ЕС.

Личность подписавшего

Проверка личности подписавшего не обязательна.

Личность подписавшего проверяется, но не гарантируется.

100% возможность идентификации подписавшего. Необходима первоначальная личная проверка подписавшего или другой эквивалентный процесс.

Подлинность

Не обязательно, чтобы подпись была связана с подписавшим.

Подпись однозначно связана с подписавшим.

Подпись уникально связана с подписавшим.

Аутентификация

Не обязательно, чтобы подпись была создана под исключительным контролем подписывающего.

Подпись создана под исключительным контролем подписавшего. Многофакторная аутентификация по желанию.

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

ПО

Не требуется специального ПО.

Требуется устройство для создания защищённой подписи (SSCD).

Требуется квалифицированное устройство для создания подписи (QSCD), Квалифицированный поставщик доверительных услуг (QTSP).

Юридическая сила

Бремя доказывания лежит на стороне, которая инициировала подпись.

Бремя доказывания лежит на стороне, инициировавшей подпись.

Бремя доказывания лежит на стороне, оспаривающей подпись.

Примеры

Отправка одноразового пароля (OTP);

Вход в личный кабинет по имени и паролю;

Лицензионное соглашение;

Рукописная подпись.

Биометрия;

PAdES;

CAdES;

XAdES.

Смарт-карты;

USB-токены.

Пороговые кошельки

Кошелёк, основанный на технологии TSS, немного отличается от традиционных криптовалютных кошельков. Как правило, традиционный кошелёк генерирует seed-фразу и использует её для детерминистического получения кошельков. Пользователь может затем использовать эту иерархическую детерминистическую (ИД) структуру, чтобы: 1) получить приватные ключи, соответствующие адресам кошелька, и подписывать ими транзакции; и 2) восстановить все ключи кошелька с помощью seed-фразы.

В пороговом кошельке всё сложнее. Хотя можно сгенерировать ИД-структуру, это должно происходить распределённым способом, с помощью отдельного MPC-протокола. Участники совместно решают, какой ключ будет использоваться следующим. Другими словами, у каждого участника есть своя seed-фраза.

Кошельки на основе TSS также имеют полезную опцию безопасности: возможность ротации приватных ключей без изменения соответствующего публичного ключа и адреса в блокчейне. Ротация приватных ключей, также известная как проактивное разделение секрета, – это ещё один MPC-протокол, в котором в качестве входа используются доли секрета, а на выходе получается новый набор долей секрета. Старые доли секрета можно удалить и вместо них использовать новые.

Такая структура добавляет к безопасности временное измерение, то есть злоумышленник, чтобы атаковать пороговый кошелёк, должен одновременно находиться в нескольких местах. Объединение долей секрета до и после ротации не даст злоумышленнику дополнительного преимущества, если он хочет подделать подпись.

Недостаток такого кошелька в том, что отсутствие seed-фразы делает его несовместимым с кошельками с одним ключом. Поэтому важно учитывать, кто будет держать доли секрета.

Есть несколько возможных архитектур:

  • Аутсорсинг TSS: Пользователь позволяет n серверам выполнять вычисления для него. В сущности, генерация ключей, управление ими и подписание транзакций поручается поставщикам сервисов, которые не владеют активами, но предоставляют уровень безопасности в обмен на какое-нибудь вознаграждение.
  • Использование нескольких устройств: Пользователь использует TSS на нескольких устройствах, которые принадлежат ему. Например, одной стороной может выступать какое-нибудь устройство интернета вещей, другой – мобильный телефон пользователя, третьей – его ноутбук, и т. д.
  • Гибридный подход: Некоторые стороны в TSS контролируются внешними сервисами, а другими выступают устройства, принадлежащие пользователю.

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

Второй метод даёт пользователю полный контроль, но затрудняет проведение транзакций, так как нужно, чтобы сразу несколько устройств были онлайн и проводили вычисления.

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

Пространство доверия

Следующим этапом является решение вопроса о пространстве доверия

ПЭП

. Если источником

ПД

для хранения в системе обработки

ПД

является сайт агента, то это локальное пространство доверия и доверять может только агент. Для повышения статуса доверия необходимо сверить эти данные с оригиналом документа, выдаваемого при уполномоченной регистрации

ПД

– с оригиналом паспорта. Именно оригиналом, так как получение скан-копий паспортов через сайт – это просто усложненный ввод

ПД

, и он мало чем отличается от просто ввода

ПД

. Удаленно запрашивать скан-копии паспортов особого смысла не имеет и статуса доверия к данным не повышает, но при этом повышает уровень требований к защите

ПД

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

ЕСИА

. Планируется также создание

. Таким образом, запись

ПД

в системе обработки персональных данных может иметь два статуса – подтверждена/не подтверждена. Аналогичные статусы используются и на порталах государственных услуг.

Секретный ключ¶

Главный компонент всего — криптография, точнее криптографические алгоритмы.

Всё начинается с генерации пары ключей: секретного и публичного. Сначала при помощи математической и компьютерной магии генерируется секретный ключ, а затем из него вычисляется публичный. Чаще всего для сертификатов используется алгоритм RSA, вот как это делается в консоли через программу openssl:

В этом примере мы сгенерили секретный ключ для алгоритма RSA. Собственно сам ключ находится между специальными маркерами —–BEGIN RSA PRIVATE KEY—– и —–END RSA PRIVATE KEY—–. Чтобы при генерации ключа сохранить его сразу в файл, добавьте аргумент -out private.pem:

С подобным форматом представления криптографических данных вам предстоит сталкиваться постоянно, называется он PEM, что расшифровывается как Privacy-enhanced Electronic Mail. Его предназначение — кодировать бинарные криптографические данные в виде ASCII-текста.

Мы можем при помощи openssl сконвертировать секретный ключ из текстового формата PEM в изначальный бинарный, сохраним его в файл private.der:

Имя формата данных DER расшифровывается как Distinguished Encoding Rules и является частью стандарта ASN.1. В стандарте ASN.1 описываются правила и структуры для кодирования, раскодирования и передачи данных по телекоммуникационным и компьютерным сетям.

Также существует консольная программа dumpasn1 для просмотра бинарных данных, в дебиане/убунте она ставится через sudo apt-get install dumpasn1, для макоси можно поставить через macports, через homebrew (инструкция), либо скомпилировать самостоятельно из исходников.

Вот так, например, выглядит дамп нашего созданного секретного ключа:

Читайте также:  Блокхост ЭЦП 2.0 купить в Зеленограде — самая выгодная цена на официальном сайте

В нашем файле секретного ключа «упакованы» девять целых чисел, структура ключа для алгоритма RSA весьма простая и описана, например, в RFC 3447, в секции A.1.2 RSA private key syntax.

Ну и чтобы два раза не вставать, вытащим из секретного ключа публичный ключ в файл public.der, закодированный в бинарный формат DER, openssl умеет делать и это тоже:

И сразу же посмотрим на его структуру через dumpasn1:

Структура публичного ключа также описана в RFC3447, в секции A.1.1, если вы туда посмотрите, то увидите, что дамп файла public.der не соответствует этому описанию. Поздравляю с первыми граблями в openssl, с ними вам тоже придётся сталкиваться постоянно.

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

Сила криптографии

Для того чтобы понять TSS, необходимы некоторые базовые познания в криптографии. Начиная с 1970-х интернет-системы (такие как TLS и PGP) всё чаще использовали асимметричную криптографию, также известную как криптография с открытым ключом (public key cryptography, PKC).

Система использования закрытого ключа для передачи открытого ключа


Система достаточно подробно разобрана в

. Архитектура строится на основе статьи 12 ФЗ-63, т.е система обязательно должна обеспечивать:

  1. Уведомление контрагента о том, что он запускается процедура подписания. В уведомлении пользователю должны быть показаны реквизиты документа, который он подписывает, в идеале документ должен быть открыт для чтения. Контрагент должен ввести закрытый ключ подписи, конфиденциально известный только ему, для подтверждения и факта и момента подписи;
  2. Уведомление пользователя о том, что документ подписан. Технически процедура подписания состоит в том, что создается запись в реестре ПЭП и присваивается уникальный номер. Желательно продублировать регистрационный номер подписи, регистрационный номер документа и время подписания с помощью SMS. Тем самым пользователь виртуально получает «второй экземпляр документа» в свое владение;

Система оформления подписи

Цель системы оформления подписи – обеспечить ее непереносимость на другие документы. И агент, и контрагент должны быть уверены, что

ПЭП

, которой контрагент подписал некоторый документ, нельзя будет впоследствии отнести к другому документу, о котором он и понятия не имеет. В целом, законодательные акты не предусматривают для

ПЭП

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

ПЭП

с конкретным документом, в системе агента необходимо иметь электронный реестр

ПЭП

, где каждая

ПЭП

получит уникальный инкрементный идентификационный номер. Инкремент позволяет привязать подпись к времени ее постановки, меньший номер говорит о том, что подпись получена раньше. Фактически, такой номер

ПЭП

– это вторичный открытый ключ

ПЭП

. Реестр, кроме собственно материализации

ПЭП

, должен связывать связью «один-к-одному»

ПД

контрагента, идентификационный номер и дату документа, время подписания и

ПЭП

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

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

Подписано простой электронной подписью:
Иванов Иван Иванович, СНИЛС 000-000-000 00, Телефон (000) 000-00-00.
Регистрационный номер подписи: 0000000 от 31.01.2022 10:05:47

Можно также опереться на методические рекомендации межведомственного электронного документооборота (МЭДО) и визуализировать в стандарте PDF/А.

Система формирования сообщения о персональных данных контрагента


Следующим этапом является решение вопроса о том, как

ПД

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

ПД

в ФЗ-152 и ФЗ-63. Выписка статьи 9 из ФЗ-152 гласит:

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


Проблема в том, что, в случае с

ПЭП

, необходимо получить

ПД

, чтобы сформировать электронную подпись, а для того чтобы собрать

ПД

, необходимо получить согласие, уже подписанное электронной подписью. Плюс к этому, согласно выписке статьи 9 из ФЗ-63, необходимо соглашение о использовании простой электронной подписи. Получается замкнутый круг, который, с первого взгляда, можно разорвать лишь собственноручной подписью соглашения и согласия с личным визитом. Но, если использовать определенную форму соглашения об использовании

ПЭП

, а именно договор присоединения(публичную оферту), и совместить получение

ПД

с подписанием согласия, возможно сделать все удаленно. Таким образом, практически без вариантов, закон диктует следующий алгоритм регистрации

ПД

контрагента для использования в системах

ПЭП

, если ставится задача обойтись без личных визитов:

  1. Необходимо соглашение об использовании простой электронной подписи, разработанное квалифицированными юристами, которое должно приниматься анонимно, без использования подписи. Это дает правовую основу для электронной подписи согласия на предоставление ПД с помощью ПЭП. Закон предоставляет вариант организации анонимного соглашения: договор присоединения, к которому может присоединиться неограниченный круг пользователей (публичная оферта). Это первое, что должен увидеть пользователь при регистрации. Факт присоединения к оферте(акцепт) подтверждается формированием и вводом закрытого ключа. Процесс зависит от того, будет в дальнейшем использоваться многоразовый закрытый ключ (пароль) или одноразовые закрытые ключи.
  2. Форма ввода персональных данных, перечисленных выше, а именно ФИО, место жительства, серия и номер паспорта, СНИЛС и т.д., должна включать в себя согласие на предоставление персональных данных. Само согласие должно быть персональным, и, кроме типовых пунктов, перечисленных в статье 9 ФЗ-152, должно содержать пункт о том, что согласие подписывается ПЭП с перечислением открытых ключей: СНИЛС вторичные ключи (если есть). Подписывается вся форма (персональные данные и согласие) одним действием. Подробнее устройство системы подписи будет описано далее в разделе «Система передачи открытого ключа на основе закрытого ключа»
  3. После выполнения этих действий пользователь регистрируется в системе и получает возможность подавать заявления, заявки, обращения и жалобы, подписанные ПЭП. Согласие необходимо сохранить, так как оно может быть отозвано.


Определившись с перечнем сохраняемых

ПД

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

ПД

от несанкционированного доступа. Основные шаги, которые необходимо сделать:

  1. Выбрать платформу, сертифицированную ФСТЭК для работы с ПД. Платформа, согласно требованиям закона, в минимальном варианте должна обеспечивать разграничение доступа к ПД и логирование всех операций доступа к ПД. В моей практике обычно рассматривались следующие варианты: MS SharePoint 2022/2022, Битрикс, Alfresco, Liferay, и соответственно, в качестве БД – MS SQL Server, PostgreSQL (в составе сертифицированного AltLinux), MySQL. Естественно, возможны и другие варианты. Выбор в пользу того или иного варианта делается на основе сравнительного анализа стоимости владения и на основе ожиданий технического отдела агента – какую платформу им проще будет сопровождать.
  2. Разработать политику обработки персональных данных
  3. На основе разработанной политики обработки ПД нужно решить, необходимы ли дополнительные сертифицированные средства защиты ПД и регистрация в качестве оператора персональных данных. Есть определенные методики выполнения этого шага и лучше привлечь лицензированных специалистов, особенно если ПД закон обворачивает в слово «тайна», например – врачебная тайна.


В самом простом случае, если

ПД

невозможно использовать ни для каких других целей, кроме как идентификации субъекта

ПД

в целях оказания услуги и

ПД

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

Система хранения ключей


Основой подписи является информация, которую она передает. Как было показано при анализе целевой системы, подпись передает информацию о

ПД

, и необходимо решить, какие

ПД

контрагента будут локально зарегистрированы в системе делопроизводства агента. Ответ на этот вопрос дает выписка статей 20 и 21 ГК РФ – ФИО и место жительства. Для локального пространства доверия этих

ПД

достаточно, но если есть цель юридической значимости

ПЭП

, то необходимы идентификационные коды, присвоенные этим

ПД

в уполномоченной системе регистрации. Уполномоченная система в РФ – это МВД. МВД для ФИО и места жительства присваивает идентификационный код – серия и номер паспорта. Таким образом, чтобы локальная регистрация потенциально стала уполномочено-локальной, необходимо регистрировать ФИО, место жительства, серию и номер паспорта.

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

Выписка из ФЗ-63, а именно статья 4, не конкретизирует, что это за ключи. Но так как нужно добиться значимости подписи, здесь мы можем опереться на документы иного рода – судебную практику. Как показывает судебная практика, основной момент, который оспаривается в судах – это то, что выбранный метод подписи не имеет признаков аналога собственноручной подписи (АЛП).

Разные заинтересованные стороны по разному решают этот вопрос. Самый главный признак АЛП — неотчуждаемость от персональных данных В качестве открытого ключа нельзя выдумывать код, этот код должен однозначно указывать на ПД, аналогично монограмме личной подписи и должен быть зарегистрирован в уполномоченном органе, аналогично, как в паспорте зарегистрирована монограмма.

Читайте также:  ЭЦП заказчика для коммерческих торгов

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

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

Служба штампов времени

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

Штампом времени называют подписанный ответ TSA с фиксацией момента, в котором существовала штампуемая информация. Данные, а строго говоря их хэш, отправляются запросом по протоколу TSP (Time stamp protocol). Служба штампов формирует ответ, в котором в определенном формате фиксируется точное время существования полученного в запросе хэша.

После формирования подписи, чтобы зафиксировать момент ее создания, устанавливается штамп времени. Если в будущем сертификат подписанта истечет или закрытый ключ будет скомпрометирован, документ не потеряет юридическую значимость (при условии, что в указанное время сертификат подписанта был действителен).

Сочетание tss с блокчейнами

Самый очевидный способ применения пороговых подписей в блокчейне – это изменить блокчейн-клиент так, чтобы он генерировал ключи и подписи с помощью TSS. Здесь под блокчейн-клиентом понимается набор команд, выполняемых полным узлом. На практике технология TSS позволяет все команды, связанные с приватными ключами, заменить распределёнными вычислениями.

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

При использовании TSS у нас будет n участников, которые совместно вычисляют публичный ключ и у каждого из которых есть секретная доля приватного ключа (не раскрываемая другим участникам). Из публичного ключа можно получить адрес точно так же, как в традиционной системе, причём для блокчейна метод генерации ключа не имеет значения.

Так же можно подписывать транзакции. В этом случае вместо того, чтобы транзакцию своим приватным ключом подписывала одна сторона, используется распределённая генерация подписи несколькими участниками. Каждый участник может предоставить действительную подпись, если достаточное их число поступает честно. Опять же, мы перешли от локального вычисления (единой точки отказа) к интерактивному.

Важно упомянуть, что распределённая генерация ключей может допускать разные структуры доступа: общее условие типа «t из n» сможет выдержать до t произвольных отказов в операциях, связанных с приватными ключами, не скомпрометировав безопасность.

Структура блока

Каждый блок состоит из адреса, даты и времени создания, хэша и списка транзакций. Как на рисунке 1.

  • Адрес – публичный ключ, генерируемый ассиметричным алгоритмом шифрования (например, RSA), на основе придуманного пользователем приватного ключа;
  • Дата и время – тот момент, когда был создан блок (у транзакции тоже есть дата и время создания);
  • Хэш (связующий) – вычисляется с помощью SHA512 от адреса предыдущего блока и суммы хэшей всех транзакций текущего блока, почему связующий? Потому что при его вычислении требуется адрес предыдущего блока;
  • Информация — сообщение, сумма денег (криптовалюты), документы, история болезней, программный код (умные контракты) и т.д.

Что такое пороговые подписи? |
Рисунок 1 – блокчейн из 3-ех блоков

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

Структура и возможности

Блокчейн

— это один из видов распределенного хранения данных, использует 3 ранее известных технологии: одноранговые сети, шифрование и базы данных. База данных представляет из себя цепочку блоков, которая специальным образом шифруется и хранится на всех узлах сети в одном и том же виде (репликация — точная копия).

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

Наиболее интересные проекты, где используется блокчейн:

  1. Monegraph позволяет авторам закрепить права на свою работу и установить правила (и выплаты) за использования их работы;
  2. La Zooz это децентрализованный Uber. Предлагай свою машину, найди перевозчика без платы Uber’у;
  3. Augur – это онлайн букмекер. Делай ставки и получай выигрыш;
  4. Storj.io – это P2P хранилище данных. Сдавай свое неиспользуемое место на диске или найди самое дешевое онлайн хранилище;
  5. Muse – это распределенная, открытая и прозрачная база данных специально для музыкальной индустрии;
  6. Ripple позволяет проводить недорогие трансграничные платежи в банки;
  7. Golem – мировой децентрализованный суперкомпьютер с открытым кодом, доступ к которому может получить любой человек, для выполнения распределенных вычислений (от обработки изображений до проведения исследований и запуска веб-сайтов). Используя Golem, пользователи могут покупать или продавать вычислительные мощности между собой;
  8. Множество других криптовалют отличающихся высокой анонимностью работы, низкой стоимостью переводов, умными контрактами и т.д.

Типы электронных подписей

Во-первых, давайте взглянем на различные существующие типы подписей. Это различие основано на Положении об электронной идентификации, аутентификации и доверительных услугах (англ.: electronic Identification And trust Services, eIDAS), созданном ещё в 2022 году.

Этот регламент устанавливает правовую структуру для электронной идентификации, подписей, печатей и документов на всей территории ЕС. В России правовое регулирование осуществляется на основе Федерального закона №63-ФЗ «Об электронной подписи». Но мы будем рассматривать классификацию на основе eIDAS.

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

  1. Простая электронная подпись (англ.: Simple or Basic electronic signature, BES);

  2. Расширенная электронная или цифровая подпись (англ.: Advanced electronic or digital signature, AdES);

  3. Квалифицированная расширенная электронная или цифровая подпись (англ.: Qualified advanced electronic or digital signature, QES).

Цепочки удостоверяющих сертификатов¶

Удостоверяющий центр может выдать сертификат, в котором в поле X509v3 Basic Constraints разрешается его использование как удостоверяющего. Этим сертификатом тоже можно подписывать «доменные» сертификаты. Таким образом, все CA-сертификаты образуют цепочку, а в целом — дерево.

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

Естественно, центры авторизации не выписывают CA-сертификаты кому попало, но крупная организация может этого добиться, например, у Google есть свой CA-сертификат.

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

Корневой сертификат является самоподписанным, то есть он подписан тем же самым ключом, публичный ключ для которого находится в теле сертификата. У корневого сертификата совпадают поля issuer и subject.

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

Электронная подпись: простая и усиленная

Обратимся к Федеральному закону от 06.04.2022 № 63-ФЗ «Об электронной подписи» (далее – 63-ФЗ). Исходя из него, ЭП – это сущность, которая:

●    является информацией;

●    связана с подписываемой информацией;

●    позволяет определить подписанта.

Признаки усиленной квалифицированной электронной подписи (далее – УКЭП):

●    является информацией;

●    связана с подписываемой информацией;

●    предоставляет возможность определить подписанта;

●    получена с помощью ключа ЭП (закрытого) в результате криптографического преобразования информации;

●    позволяет установить факт внесения изменений в подписываемые данные;

●    ключ проверки ЭП (открытый) указан в квалифицированном сертификате;

●    для создания и проверки подписи используются сертифицированные средства ЭП.

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

Удостоверяющие центры (далее – УЦ), аккредитованные Минкомсвязью России, по запросам пользователей выпускают для них сертификаты. Требования к форме последних, средствам УЦ и средствам электронной подписи устанавливает ФСБ России (Приказ ФСБ РФ от 27 декабря 2022 г.

№ 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи»; Приказ ФСБ РФ от 27 декабря 2022 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра»). Примером сертифицированных ФСБ средств ЭП служит средство криптографической защиты «КриптоПро CSP».

Оцените статью
ЭЦП Эксперт
Добавить комментарий

Adblock
detector