вторник, 27 октября 2020 г.

Требования к формату нотариально оформляемого документа в электронной форме

Приказом Минюста России от 30 сентября 2020 года №227 утверждены «Требования к формату нотариально оформляемого документа в электронной форме». Они также утверждены решением Правления ФНП от 16 сентября 2020 года №16/20. Приказ вступает в силу с 29 декабря 2020 года.

Ранее действующие требования к формату изготовленного нотариусом электронного документа, утвержденные приказом Минюста России от 29 июня 2015 года №155, признаны утратившими силу.

Документ в электронной форме изготавливается нотариусом в формате PDF (п.2), за исключением случаев:

  • Если на официальном сайте оператора ЕИС (единой информационной системы нотариата – Н.Х.) в сети Интернет размещена схема, подлежащая использованию для изготовления нотариусом документа в электронной форме в формате XML (XML-схема), документ в электронной форме изготавливается нотариусом в виде связанных между собой файлов в форматах XML и PDF. В случае изменения новая XML-схема размещается на официальном сайте оператора ЕИС за один месяц до ее введения (п.3);

  • Свидетельство о регистрации уведомления о залоге движимого имущества и выписка из реестра уведомлений о залоге движимого имущества изготавливаются нотариусом в виде XML-файла в соответствии с XML-схемой, размещенной на официальном сайте оператора ЕИС (п.4);

  • Если документ в электронной форме требуется для представления в орган государственной власти или во внебюджетные фонды, нотариус изготавливает его с учетом требований Основ законодательства Российской Федерации о нотариате от 11.02.1993 N 4462-1 и других законодательных актов РФ, устанавливающих требования к формату такого документа (п.7).

Для визуализации выданного нотариусом свидетельства о регистрации уведомления о залоге движимого имущества и выписки из реестра уведомлений о залоге движимого имущества в печатном виде и проверки электронной подписи может быть использован общедоступный сервис, размещенный по адресу: www.notariat.ru , указанному на официальном сайте оператора ЕИС (п.5).

Электронный образ документа на бумажном носителе формируется в виде одного файла изображения в формате PDF. Сканирование должно производиться с разрешением 300 dpi (точек на дюйм) в оттенках серого, глубина цвета 8 бит на пиксель (п.6).

Документ в электронной форме подписывается усиленной квалифицированной электронной подписью нотариуса в формате PKCS#7 (отделенная электронная подпись в кодировке DER). В случае, если электронный документ изготавливается нотариусом в виде связанных между собой файлов в форматах PDF и XML, УКЭП нотариуса подписывается пакет, состоящий из этих файлов, при этом каждый из файлов, входящих в этот пакет, считается подписанным УКЭП нотариуса (п.8).

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

Мой комментарий: Интересно, все ли версии PDF нотариус может использовать в своей работе? Разные версии поддерживают разные функциональные возможности, некоторые из которых (особенно в случае «полного» PDF) чреваты рисками…

Очень любопытно, как будет обеспечиваться корректная визуализация XML-файлов в случае изменений в схемах (кто-то должен будет позаботиться об архивном хранении схем и корректной «привязке» версий схем к XML-документам).

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

Источник: Консультант Плюс
http://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=364055

понедельник, 26 октября 2020 г.

Дэвид Розенталь: Замечания по поводу блокчейна


Данный пост д-ра Дэвида Розенталя (David Rosenthal – на фото) была опубликован на его блоге (DSHR's Blog) 6 октября 2020 года.

Блокчейн-решения состоят из трех компонентов: структуры данных, набора реплик и механизма консенсуса:
  • Часто говорят, что структура данных обеспечивает неизменность (immutability), защищённость от несанкционированного доступа (tamper-proof), - но это неверно. Структура данных состоит из битов, а биты могут быть изменены или уничтожены. На самом деле эта структура обеспечивает невозможность незаметного внесения несанкционированных изменений (tamper-evident), позволяя увидеть, что структура данных изменилась.

    Мой комментарий: В формулировке профильного комитета ИСО по блокчейну, неизменность данных (а также порядка блоков) является целевой характеристикой при проектировании блокчейн-систем. Хотя 100% гарантию неизменности на практике дать невозможно, разработчики блокчейн-решений тем не менее принимают все разумные меры для обеспечения этого свойства, поскольку решения, всего лишь поддерживающие детектирование изменений, куда менее интересны пользователям.

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

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

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

Используемая в блокчейн-решениях структура данных представляет собой форму дерева Меркля (хеш-дерева), концепция которого была опубликована Ральфом Мерклем (Ralph Merkle) в 1980 году (см. http://www.merkle.com/papers/Protocols.pdf ). В контексте блокчейна это линейная цепочка, к которой регулярно добавляются блоки фиксированного размера. Каждый блок содержит хеш своего предшественника; таким образом формируется цепочка блоков. Срок службы алгоритмов хеширования ограничен, - однако пока такой алгоритм остается невзломанным, чрезвычайно сложно изменять блоки в цепочке, сохраняя при этом те же хещ-значения. Изменение, которое не сохраняет то же значение хеша, легко обнаружить.

Реплики

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

Механизм консенсуса

Важный результат в области теоретической информатики был опубликован группой учёных во главе с Лампортом (Lamport) в 1982 году в книге «Проблема византийских генералов» (The Byzantine Generals Problem, https://doi.org/10.1145/357172.357176 ). Они показали, что минимальный размер набора реплик, выдерживающего f одновременных отказов, равен 3f + 1 (см. таблицу справа). Таким образом, протокол «Византийской отказоустойчивости» (Byzantine Fault Tolerance, BFT) является наиболее эффективным из возможных механизмов консенсуса с точки зрения количества реплик. Протокол BFT требует закрытого набора реплик и их синхронизированной работы, поэтому он может использоваться только в блокчейнах с ограниченным доступом.

Если возможно свободное присоединение к набору реплик блокчейна без ограничения доступа, такое решение будет уязвимо для атаки Сивиллы (Sybil attacks, см. https://ru.wikipedia.org/wiki/Атака_Сивиллы ), при которой злоумышленник создает множество независимых на первый взгляд реплик, которые на дел находятся под его единоличным контролем. Если создание и поддержка реплики бесплатны, то любой может авторизовать какое угодно изменение по своему выбору, просто создав достаточное количество реплик Сивиллы.

Защита от атаки Сивиллы требует, чтобы членство в наборе реплик было дорогостоящим. Стоимость атаки равна как минимум стоимости размещения половины набора реплик, чтобы злоумышленник получил контроль над большинством реплик. В блокчейнах без ограничения доступа реализованы несколько способов, позволяющих сделать участие затратным, включая следующие:
  • «Доказательство работы» (Proof of Work, PoW) – это концепция, разработанная в 1992 году Синтией Дворк (Cynthia Dwork) и Мони Наором (Moni Naor, https://dl.acm.org/citation.cfm?id=705669 ), в которой дорогостоящим ресурсом являются циклы центрального процессора. Этот тот метод «майнинга», что используется Биткойном, и единственный метод, который продемонстрировал свою хорошую работоспособность в больших масштабах. Но при больших масштабам затраты и экологический ущерб оказываются неподъёмными; по существующим оценкам, 5 ведущих криптовалют потребляет столько же энергии, сколько вся Голландия ( https://www.ofnumbers.com/2018/08/26/how-much-electricity-is-consumed-by-bitcoin-bitcoin-cash-ethereum-litecoin-and-monero/ ). При меньших масштабах этот подход не работает, поскольку в этом случае аренда 51% мощностей для майнинга оказывается достаточно дешёвой, чтобы мотивировать атаки. «Атаки 51%» стали обычным явлением среди более мелких альтернативных криптовалют. Например за один месяц, было три успешных атаки на Ethereum Classic (см. https://www.coindesk.com/ethereum-classic-blockchain-subject-to-yet-another-51-attack ).

  • «Доказательство доли» (Proof of Stake, PoS), где дорогостоящим ресурсом является вложенный/поставленный как ставка капитал. Участники могут потерять свою долю/ставку в случае, если будут замечены в некорректном поведении. Блокчейн Ethereum в течение 5 лет пытался реализовать PoS, но пока что без успеха. Этот метод имеет экономические ограничения ( https://dx.doi.org/10.2139/ssrn.3494434 ) и уязвимости ( https://blog.dshr.org/2020/03/proof-of-stake-in-practice.html ), аналогичные методу PoW.

  • «Доказательство времени и пространства» (Proofs of Time and Space, PoTS) - пропагандируется Брэмом Коэном (Bram Cohen, https://blog.dshr.org/2018/03/proofs-of-space.html ). Здесь дорогостоящим ресурсом является дисковое хранилище данных.
Выводы

Эрик Будиш (Eric Budish) указывает на фундаментальную проблему дорогостоящей защиты в своей книге «Экономические ограничения Биткойна и блокчейна» (The Economic Limits of Bitcoin and the Blockchain, http://www.nber.org/papers/w24717 ):

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

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

В статье Адема Эфе Генцера (Adem Efe Gencer) и др. «Децентрализация в сетях Биткойн и Эфириум» (Decentralization in Bitcoin and Ethereum Networks, https://arxiv.org/pdf/1801.03998.pdf ) сравниваются затраты системы с ограниченным доступом, использующей протокол BFT, с фактическим блокчейном Bitcoin, использующим PoW:

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

Как англичанин, я ценю преуменьшения. Под «намного более низкими» они подразумевают разницу примерно в 5 порядков величины.

Дэвид Розенталь (David Rosenthal)

Источник: DSHR's Blog
https://blog.dshr.org/2020/10/a-note-on-blockchains.html

Ответ на вопрос коллеги: Как сохранить юридическую значимость электронных документов, подписанных квалифицированными электронными подписями?

Вопрос: Как сохранить юридическую значимость таких документов при долгосрочном хранении в соответствии с требованиями законодательства?

Ответ: У данного вопроса могут быть два аспекта:

  • В предположении, что подписанный электронный объект сохраняется в неизменном виде, как доказать верность подписи уже после того, как истек срок действия сертификата ключа подписания (а в более длительной перспективе – и сертификат ключа подписи УЦ, которым был подписан пользовательский сертификат)?

  • Что делать, когда вследствие устаревания технологий документ в его первоначальном виде становится непригодным для использования, и его приходится преобразовывать в новый формат (Росархив, например, рекомендует преобразовывать электронные документы в формат PDF/A при передаче на архивное хранение) – и вследствие этого усиленная электронная подпись, жёстко «привязанная» к первоначальному объекту, уже не будет проверяться?

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

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

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

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

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

  • Сохранение документов владельцем вместе с необходимой вспомогательной документацией (сертификатами, списками отозванных сертификатов, квитанциями об онлайн-проверке подписей, отметками времени, иными электронными и бумажными документами, подтверждающими верность подписей в определенны момент времени). В этом случае владелец может привлечь для экспертизы не только тот УЦ, что выдавал сертификат ключа подписания, но и другие УЦ/экспертов, - но презумпции доверия к вспомогательной документации, естественно, уже не будет, и она будет тщательно проверяться.

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

  • Использование реестров документов, которые ведёт государственный орган или доверенная третья сторона.

  • Передача документов на хранение доверенному хранителю (государственному архиву), который проверяет верность подписей при приёме документов, а в дальнейшем обеспечивает их долговременную сохранность своими силами и средствами, уже не прибегая к перепроверке первоначальных подписей. Это наиболее перспективный путь, но для него опять же нужна соответствующая нормативно-правовая база. На данный момент он также может использоваться ограниченно – в рамках договорных взаимоотношений между организациями.

Иными словами, универсального решения на все случаи жизни пока что нет :(

воскресенье, 25 октября 2020 г.

Франция: Опубликован очередной стандарт XP Z42-105 по технологии «видимой электронной печати» (Cachet Electronique Visible, CEV)

Как сообщил сайт французского национального органа по стандартизации AFNOR, в сентябре 2020 года вышел в свет экспериментальный стандарт XP Z42-105 «Управление электронными документами – Требования к использованию видимой электронной печати для аутентификации, проверки и автоматического ввода данных, передаваемых документом или объектом» (Archivage électronique - Spécifications relatives à la mise en oeuvre du Cachet Électronique Visible (CEV) aux fins authentification, de vérification et de saisie automatique des données véhiculées par un document ou un objet), см. https://norminfo.afnor.org/norme/xp-z42-105/archivage-electronique-specifications-relatives-a-la-mise-en-oeuvre-du-cachet-electronique-visible-cev-aux-fins/191926 .

Стандарт разработан национальным техническим комитетом CN 171 «Вопросы архивации и управления жизненным циклом документа» (Applications pour l'archivage et la gestion du cycle de vie du document). Это уже пятый по счёту стандарт, относящийся к технологии «видимой электронной печати» (Cachet Electronique Visible, CEV), предусматривающей использование технологий электронной подписи / электронной печати для обеспечения доверия к бумажным документам. На рис. справа показан пример инвойса с электронной печатью CEV.

О работе над данным стандартом я уже писала здесь: http://rusrim.blogspot.com/2020/03/blog-post_1.html

Страница стандарта на сайте AFNOR

В аннотации на документ, в частности, отмечается:

Стандарт содержит спецификации, относящиеся к реализации видимой электронной печати (Cachet Electronique Visible, CEV) формата Otentik для аутентификации, проверки и автоматического ввода данных, передаваемых документом или объектом.

Мой комментарий: Во Франции существует Сеть обеспечения доверия Otentik (réseau de confiance Otentik, https://otentik.codes/ ), до 2019 года известная под названием «международная ассоциация по стратегическому управлению технологией видимой электронной печатью» (Association Internationale de Gouvernance du Cachet Électronique Visible, AIGCEV, https://aigcev.org/ ). Эта ассоциация и является разработчиком требований, зафиксированных теперь в национальном стандарте.

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

Настоящие технические спецификации не устанавливают требований, которым должны соответствовать при внедрении и использовании CEV-печатей пользователи, которые выпускают или проверяют документы. Они также не охватывает функции форматирования ответа (Response Formatting functions, RFF).

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

Содержание документа следующее:

Введение
1.  Область применения
2.  Нормативные ссылки
3.  Термины и определения
4.  Основные концепции
5.  Структуры и ресурсы
6.  Процесс создания
7.  Процесс проверки
Приложения

Источник: сайт AFNOR
https://www.boutique.afnor.org/standard/xp-z42-105/electronic-storage-specifications-for-use-of-an-otentik-visible-digital-seal-vds-for-the-authentication-verification-and-acquisi/article/948538/fa199910
https://norminfo.afnor.org/norme/xp-z42-105/archivage-electronique-specifications-relatives-a-la-mise-en-oeuvre-du-cachet-electronique-visible-cev-aux-fins/191926