Проблемы интероперабельности Национальной системы электронных цифровых подписей

Опубликовано: 
Кибернетика и системный анализ. – 2009. – № 3. – Р 55-63

 

Введение

Национальная система электронных цифровых подписей (ЭЦП) Украины, функционирующая с июля 2005 года, от имени государства гарантирует качество услуг ЭЦП, а Центральный удостоверяющий орган (укр. Центральний засвідчувальний орган – ЦЗО) регулирует их качество, являясь органом аккредитации и государственного надзора за деятельностью центров сертификации ключей (ЦСК), аккредитованных и зарегистрированных. На май 2009 года аккредитовано десять ЦСК, насчитывающих более полумиллиона клиентов.

В настоящее время Национальная система ЭЦП не интероперабельна по организационным причинам преимущественно из-за слабой координации действий ЦЗО и контролирующего органа как главных субъектов Закона Украины об ЭЦПот 22.05.2003 №852, гармонизированного с Директивой Евросоюза 1999/93/EC, а также ввиду существенных пробелов в законодательной базе [1-14] и технологических просчетовв реализации информационных технологий (ИТ), поддерживающих функционирование ЦЗО и всех ЦСК. Основное препятствие обусловлено хуторянской позицией Украины, т.е. ориентацией на негармонизированный национальный стандарт ДСТУ 4145 и СНГ-стандарты ГОСТ 34.310 и ГОСТ 34.311, а не на международные ЭЦП согласно действующим гармонизированным стандартам ДСТУ ISO/ІЕС 14888:2002, ДСТУ ISO/ІЕС 13888:2002, ISO/ІЕС 9798:2002, ДСТУ ISO/ІЕС 10118:2003, ДСТУ ISO 9735:2006, ДСТУ ISO/IEC 18014:2002. Даты утверждения этих ДСТУ в 2002 и 2006 гг. однозначно негативно характеризуют организационно-технологическое влияние контролирующего органа на развертывание всей Национальной системы ЭЦП в Украине. 

Проблемы интероперабельности Национальной системы ЭЦП привели к значительному сужению круга пользователей ЭЦП и способствовали отрицательному имиджу у инвесторов в отличие от ЕС, в котором от грамотного регулирования ЭЦП зависят не только сферы электронного бизнеса (eHealth, eTransport, eCommerce, eGovernment, eInvoicing, eProcurement), но и поддержка всех функций информационного общества. По этой причине представляется незначительным экономический эффект от внедрения в Украине электронного документооборота, основанного на ЭЦП. Определенной части этого эффекта можно достичь вследствие интеграции Украины в СОТ, что невозможно для электронного бизнеса без кроссертификации, т.е. трансграничного признания сертификатов открытых ключей ЭЦП, изданных в разных странах. Согласно Закону Украины об ЄЦПЭ право на кроссертификацию имеет ЦЗО, но он к этому не готов. В процедурах кроссертификации, в частности с ЕС, предусмотрены полномасштабная валидация и автоматическое Интернет-тестирование всей Национальной системы ЭЦП, а также анализ ее законодательной базы.

Цель статьи – обосновать способы минимаксного (минимум затрат, максимум результатов) решения проблем интероперабельности в инфраструктуреЭЦП как внутри Украины, так и с другими государствами.

Текущее состояние Национальной системы ЭЦП

Согласно европейской бизнес-модели ЭЦП [1] существуют три вида так называемых квалифицированных подписей, поэтому соответствующую инфраструктуру ЭЦП называют QPKIв отличие от принятой за пределами Евросоюза PKI(инфраструктура открытых ключейX.509) [14].

Помимо трех типов подписи, ЭЦПеще различают по требованию непосредственного участия человека в процессе подписания электронного документа. Например, для выставления счета на товары в виртуальном магазине не требуется вмешательство человека в процесс подписания (кроме этапа конфигурирования), но согласно Закону Украъни об ЭЦП [2] недопустимо автоматическое подписание электронных документов без участия человека. А юрисдикции большинства государств ЕС допускают такой сценарий манипулирования ЭЦП. К сожалению, в Украине нет четкого разграничения понятий печать и штемпель, поэтому сложно и даже невозможно однозначно интерпретировать их электронное значение.

Построить полноценные бизнес-модели ЭЦП невозможно без обязательного атрибута подписи – временного штемпеля и/или маркера времени. Маркер времени – информация в следе аудита провайдера надежных услуг, связывающая представление данных с конкретным временем и создавая доказательство, что данные существовали до этого времени. Токен временного штемпеля –аналогичный объект данных в контейнере ЭЦП и/или подписанного документа. В Украине отсутствует техническое регулирование этой составляющей  Национальной системы ЭЦП, несмотря на наличие с июля 2008 года в Институте метрологии (г. Харьков) доступного в Интернете сервера времени, функционирующего согласно требованиям эталонного времени Международного телекоммуникационного радиокомитета ITU-R и бюро контроля времени BIPM, 200 атомных часов которого размещены в лабораториях и обсерваториях 30 стран (ftp://62.161.69.5/pub/tai/publication). На харьковском сервере легко построить надежную инфраструктуру штемпелевания времени любого отдельного органа или составляющей ЦСК [3-4].

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

Форматы подписи как контейнеры с конкретными наборами атрибутов определены в [5, 6]. Используя эти атрибуты, можно создать произвольные форматы ЭЦП на основе стандартных или полностью независимых.

В настоящее время в Украине реализована только одна, простейшая и не интероперабельная модель подписи [1], а полноценная бизнес-модель ЭЦП поддерживается тремя составляющими.

 

 


Таблица 1 Действующие в ЕС профили ЭЦП

Номер и название  стандарта

Информация о регистрации на получение OID

CWA 14169:2004 Безопасные средства создания подписей «EAL 4+»

EAL4+BSI-PP-0004-2002 Профиль защиты. Безопасные средства создания подписей типа 1. Версия 1.05

EAL 4+BSI-PP-0005-2002 Профиль защиты. Безопасные средства создания подписей типа 2. Версия 1.04

EAL 4+BSI-PP-0006-2002Профиль зашиты. Безопасные средства создания подписей типа 3. Версия 1.05

CWA 14890:2004 Прикладной интерфейс для смарт-карточек, используемых как безопасные средства создания подписей. Часть 1. Основные требования

Важные AlgIDдля использования с ESIGN-приложением для функций цифровой подписи и аутентификации ESIGN-средства

CWA 14890:2004 Прикладной интерфейс для смарт-карточек, используемых как безопасные средства создания подписей. Часть 2. Дополнительные свойства

Правила кодирования OID криптоалгоритма на смарт-карточке

CWA 14167-2:2004Криптографический модуль для операций подписания CSP с резервированием. Часть 2. Профиль защиты CMCSOB

Профиль защитыCMCSOB криптомодуля для операций подписанияCSP с резервной копией(ProtectionProfileofCryptographicModuleforCSPSigning  Operationswithbackup), версия 0.28. Общий статус– оцененисертифицирован

CWA 14167-3:2004Криптографический модуль для услуг генерации ключей провайдером услуг сертификации. Профиль защитыCMCKG-PP

ПрофильзащитыCMCKG-PP криптомодуля дляоперацийподписанияCSP (ProtectionProfile  ofCryptographicModuleforCSPKeyGenerationServices), версия 0.12. Общий статус– проектWS/E-Sign дляоткрытыхкомментариев

CWA 14167-4:2004Криптографический модуль для операций подписания CSP. Часть 4. Профиль защиты  CMCSO

Профиль защитыCMCSOкриптомодуля для операций подписанияCSP(ProtectionProfileofCryptographicModuleforCSPSigning  Operations) , версия 0.28. Общий статус– профиль оцененисертифицирован

ETSI TS 101 862 V1.3.3 (2006-01)Профиль усиленного сертификата

Идентификатор утверждения, созданный CA, представлен как OIDиз рекомендованного набора

ETSI TS 101 861 V1.3.1 (2006-01)Профиль штемпелевания времени

Профилирует RFC 3161

ETSI TS 102 734 V1.1.1 (2007-02)Электронные подписи и инфраструктуры. Профили CMS расширенных электронных подписей, основанных на TS 101 733 (CAdES)

Вводит профили для ETSI TS 102 733:

 

 

 

ETSI TS 102 904 V1.1.1 (2007-02)Электронные подписи и инфраструктуры. Профили расширенных электронных XML подписей, основанных на TS 101 903 (XAdES)

Вводит профили для ETSI TS 102 903:

 

 

 

 

В Украине действуют стандарты на криптоалгоритмы как составляющие комплекта подписи (рис 1). В силу возможных взаимодействий, способных повлиять на защиту ИТ, алгоритмы и параметры для безопасных ЭЦП используются только в предопределенных комбинациях, именуемых комплектами подписей. Комплект подписи состоит из трех компонентов: хеш-функции, метода дополнения, алгоритма подписания с широким набором параметров.

Если изменен один из компонентов комплекта, то его соответственно изменяют. Пример рекомендованных ETSIкомплектов подписи приведен в табл. 1 [8].

 

 

 

 

 

 

 

 

 

 

Таблица 1

Имя комплекта подписи

Имя хеш-функции

Имя метода дополнения

Имя алгоритма подписания

sha1-with-rsa

sha1

Выбирается из [8]

rsa

sha1-with-dsa

sha1

Не требует дополнения

dsa

ripemd160-with-rsa

ripemd160

Выбирается из [8]

rsa

ripemd160-with-dsa

ripemd160

Не требует дополнения

dsa

sha224-with-rsa

sha224

Выбирается из [8]

rsa

sha256-with-rsa

sha256

Выбирается из [8]

rsa

rsa-pss сmgflSHA-1Identifier

mgf1SHA-1

rsa

rsa-pss сmgf1SHA-224Identifier

mgf1SHA-224

rsa

rsa-pss сmgf1SHA-256Identifier

mgf1SHA-256

rsa

sha1-with-ecdsa

sha1

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

sha1-with-ecgdsa

sha1

Не требует дополнения

ecgdsa-Fp илиecgdsa-F2m

sha224-with-ecdsa

sha224

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

sha256-with-ecdsa

sha256

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

sha384-with-ecdsa

sha384

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

sha512-with-ecdsa

sha512

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

ecdsa-with-RIPEMD160

ripemd160

Не требует дополнения

ecdsa-Fp илиecdsa-F2m

Рассмотрим использованные в табл. 1 идентификаторы компонентов комплектов:

С комплектом подписи ассоциированы рекомендованные сроки стойкости комплекта.

QPKI-инфраструктура квалифицированных подписей

Вступление Украины в СОТ и ее стремление к евроинтеграции требуют скорейшей и качественной модификации Национальной системы ЭЦП, что возможно при соблюдении трех принципов: 1) модульности, 2) развития инфраструктуры независимых оценщиков и 3) внедрения Технического регламента, наделяющего поддерживающие его стандарты статусом не добровольного использования (что имеет место в настоящее время), а обязательного.

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

В Украине не реализован принцип модульности, а ЦСК и их пользователи применяют разработанные «под ключ» системы, не преследующие идеологию комплектов подписей [8].

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

Анализ проблем Налоговой администрации Украины

Проблемы интероперабельности Национальной системы ЭЦП обусловило различие между криптоалгоритмом, описанным в некотором стандарте, и криптомодулем, реализующим криптоалгоритм. Если каждый ЦСК использует собственный криптомодуль, а не отработанное и признанное всеми «готовое решение», то расшифровка ЭЦП на документе, проведенная адресатом посредством другого модуля, закончится неудачей. Два разных криптомодуля необходимо верифицировать на полную идентичность процедур вычисления экземпляра ЭЦП, построенных на обработке случайных чисел. Не решает проблемы простое оценивание соответствия криптомодулей спецификации криптоалгоритмов относительно стандартов. Необходимо проверять криптомодули на специальном стенде, а этого не делает никто из независимых оценщиков Украины.

 

 

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

Отсутствие формата подписей

За основу взят протокол SMTP[10]. «Жесткая» нотация обменного формата привела к постоянным его пересмотрам и переработкам, что повлекло за собой ошибки как со стороны пользователей, так и систем обработки ЦСК и ДПА. Недостаток подхода – невозможность (иногда техническая) предоставления статуса обработки отчета, хотя бы в режиме полу-онлайн. Использование электронной почты – простое, но недостаточно практичное решение, поскольку несвоевременная сдача отчета приводит к финансовым последствиям, а ответ ДПА можно получить за два часа [11].

Оптимально решить эту задачу можно в два этапа:

Разделение функциональных нагрузок Согласно [12] формат отчетов ДПА имеет вид XML-документов, как современной формы обмена. Существуют разнообразные формы обмена XML-документами, например, e-mail, http, ftp, webdav, soap, rest. Ограничивать их использование нецелесообразно. Более практично организовать основанное на контракте взаимодействие (веб-службы) и обеспечить обмен безопасной информацией (в XML-документах в отношении вредоносного программного продукта) и вариацию реализаций, независящую от конечного формата обмена. К достоинствам этого подхода отнесем простое онлайн отображение статуса отчетов в разных формах. Последнее очень важно, поскольку публикация на сайте морально устарела, а конечным пользователям не всегда удобно просматривать реестры на сайте.

Отметим, что обменный формат не должен содержать дополнительных данных об XML-документах, поскольку сами документы предоставляют минимально достаточный объем данных для обработки системами ДПА. Эти данные размещены в заголовке сообщения, содержащем перечень вложенных файлов-отчетов.

Формат подписей.Реализация сдачи отчетности организована с использованием административных рычагов, что обусловило:

Пока ДПА вынужденно реализовала специфический вариант, в котором:

В этой схеме много «творческих» решений, негативно зарекомендовших себя на практике, скажем, договор, который обязана заключить фирма и ДПА. Согласно [13] «юридическая сила электронного документа не может быть отвергнута только на основании того, что он имеет электронную форму», т.е. согласно Закону [13] реализуется схема на рис 6, а фактически работает схема на рис. 7. Схема на рис. 7 стала реальной ввиду отсутствия интероперабельности Национальной системы ЭЦП. В дополнение к организационно-юридической составляющей реализация транспортного сообщения стала ответом на такие технологические требования, как доступ к ЭЦП, параметрам ЭЦП, данным, сертификатам.

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

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

В стандарте [5] определен набор свойств подписи, которые можно скомбинировать для получения форм ЭЦП, обеспечивающих выполнение разных требований. Указанные в нормативной части [5] поля содержат минимальный необходимый объем информации для обработки XML-документов. Результирующая XML-подпись отчета приведена на рис. 8.

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

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

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

Для решения поставленных задач необходимо создать органы штемпелевания времени, действующие согласно [3] и предоставляющие услуги согласно[4].

Заключение

Развитие Национальной системы ЭЦП имеет политический подтекст, вследствие последней редакции Закона [2], в которой контролирующий орган перебрал на себя больше полномочий, чем в предыдущий редакции этого Закона. С позиций системного анализа нарушена концепция распределения функций в инфраструктуре независимых оценщиков. Так, ЦЗО только аккредитует ЦСК, а техническим надзором за их деятельностью (качеством предоставляемых услуг) занимается контролирующий орган. Значит, он должен нести единоличную ответственность за все случаи компрометации ключей, хотя в новой редакции Закона эта функция осталась за ЦЗО. Вообще монополизация контролирующим органом сферы развития Национальной системы ЭЦП существенно тормозит ее развитие и всего информационного общества и, как следствие, не способствует конкурентоспособности Украины на мировом рынке.

Принятие Технического регламента, основанного на ДСТУ, гармонизированных с международными (в первую очередь, с европейскими) и де-факто стандартами (например, RFC), и поддержанного тестовым стендом валидации функций каждого ЦСК (при необходимости каждого владельца ЭЦП), является минимаксным способом достижения внутренней и внешней интероперабельности Национальной системы ЭЦП с возможностью кроссертификации с разными государствами. В настоящее время разработан достаточный набор национальных стандартов для инициализации процедуры создания Технического регламента.

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

Список литературы

 

1          ДСТУ ETSI TR 102 045 V1.1.1 (2003-03) Електронні підписи й інфраструктури (ESI). Політика підписів для розширеної бізнес-моделі

2          Закон України від 22.05.2003 № 852-15 ”Про електронний цифровий підпис”

3          ДСТУ ETSI TS 102 023 V1.2.1 (2003-01) Електронні підписи й інфраструктури (ESI). Вимоги політики для органів штемпелювання часу

4          ДСТУ ETSI TS 101 861 V1.3.1 (2006-01) Профіль штемпелювання часу

5          ДСТУ ETSI TS 101 903 V1.3.2 (2006-03) Розширені електронні XML-підписи (ХAdES)

6          ДСТУ ETSI TS 101 733 V1.7.3 (2007-01) Електронні підписи й інфраструктури (ESI). CMS розширені електронні підписи (CAdES)

7          ДСТУ-П CWA 14172:2008  Настанова Європейської Ініціативи стандартизації електронних цифрових підписів з оцінювання відповідності (у 8 частинах)

8          ДСТУ ETSI TS 102 176-1 V2.0.0 (2007-11) Електронні підписи й інфраструктури (ESI). Алгоритми та параметри безпечних електронних підписів. Частина 1. Геш-функції й асиметричні алгоритми

9          Наказ  ДПА України “Уніфікований формат транспортного повідомлення при інформаційній взаємодії платників податків і податкових органів в електронному вигляді телекомунікаційними каналами зв'язку з використанням електронного цифрового підпису” від 22.07.2008  № 485

10        RFC 821 Simple Mail Transfer Protocol

11        Наказ ДПА України “Про подання електронної податкової звітності” від 10.04.2008 №233

12        Наказ ДПА України “Про затвердження формату (стандарту) електронного документа звітності платників податків” від 03.05.2006  № 242

13        Закон України від 22.05.2003 № 851-15 “Про електронні документи та електронний документообіг”

14        IETF RFC 2459 Профіль сертифікатів й CRL Інтернет-інфраструктури відкритих ключів X.509

 

ВложениеРазмер
Interoperable.pdf386.95 КБ
Аннотация: 

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