Домашняя страница Дениса Минича – Статьи – Введение в XML Digital Signatures

Домашняя страница Дениса Минича - Статьи - Введение в XML Digital Signatures Электронная цифровая подпись

Xml-криптография

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

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

Существуют Интернет-протоколы шифрования, такие как Secure Sockets Layer ( SSL ), Transport Layer Security ( TLS ) и IPSec, позволяющие шифровать данные, которыми обмениваются два приложения, и обеспечивать их целостность.

Тем не менее, между шифрованием XML и этими протоколами существуют фундаментальные различия [11.3]. Во-первых, XML -криптография позволяет шифровать не все данные, а только те элементы XML -документа, которые нуждаются в защите, оставляя остальное содержимое открытым.

Защита канала с помощью SSL обеспечивает шифрование всех передаваемых сообщений. Такой метод не всегда применим, поскольку отдельные части XML -сообщений нередко нужно оставлять открытыми.

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

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

Протоколы SSL, TLS и IPSec могут применяться только для шифрования соединения между двумя приложениями.

Таким образом, XML -криптография не заменяет существующие протоколы безопасности, но решает проблему другого рода, которая включает два основных аспекта [11.3]:

В консорциуме W3C создана рабочая группаW3CXML EncryptionWorking Group [11.

4], которая специально занимается вопросами шифрования XML -данных. В марте 2002 года группа выпустила рекомендации Candidate Recommendation Specification, и вместе с W3C в декабре того же года утвердила их.

В рекомендациях определены требования к XML -криптографии ( XML EncryptionRequirements ), синтаксис и правила обработки ( XML EncryptionSyntax and Processing ).

Спецификация “XML – EncryptionSyntax and Processing ” (“Синтаксис и обработка шифрования XML”) [11.

Читайте также:  Электронно-цифровая подпись для внутреннего документооборота

5] на момент написания данного курса лекций имеет статус рекомендации, т.е. потенциально подвержена изменениям. В отличие от спецификации XML -подписи, которая уже признана стандартом, .NET Framework не обеспечивает высокоуровневой поддержки спецификации XML -криптографии.

Спецификация XML Encryption, определяет методы, с помощью которых XML будет представлять зашифрованные XML -данные и другую информацию, но не предписывает применение конкретного метода шифрования.

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

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

Существует возможность совместного использования механизмов XML -подписи и XML – шифрования:

Преимущества и недостатки этих подходов показаны в табл. 11.1.

Xml-подпись

Реализация целостности и невозможность отказа обеспечиваются посредством цифровых XML -подписей ( XML-Signature ). XML -подпись служит для проверки целостности принятых сообщений и полной либо частичной аутентификацииXML -документов. Стандарт цифровой подписиXML-SignatureSyntax and Processing (сокращенно XMLDSIG от eXtensible Markup LanguageDigital SIGnature specification ) разработан консорциумом W3C в 2002 году [11.1].

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

Для реализации функциональности, связанной с XML -подписью, .NET Framework предоставляет набор готовых классов, расположенных в пространстве имен System.Security.Cryptography.Xml.

Применительно к XML -документам этот стандарт не является чем-то принципиально новым. Его специфика состоит в описании того, как цифровые подписи могут быть использованы внутри XML -документов.

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

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

Данные, заверенные подписью, могут содержаться внутри самого документа XML или размещаться в других документах. На рис. 11.1 схематически показаны три различных способа реализации XML -подписи [11.2]:

  1. “Изолированная” подпись ( Detachedsignature ) вычисляется по объекту данных, который является внешним по отношению к элементу XMLSignature. Элемент Signature и “подписанный” объект могут физически располагаться либо в разных XML -документах, либо внутри различных тэгов одного документа;
  2. “Охватывающая” подпись ( Enveloping signature, Wrappedsignature ) вычисляется по элементу Object, расположенному внутри элемента Signature ;
  3. “Встроенная” подпись ( Envelopedsignature, Embeddedsignature ) вычисляется по XML -контенту, содержащему элемент Signature.
Читайте также:  Как получить электронную подпись для егаис лес

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

С его помощью получатель может проверить полученную подпись. Перед подписанием XML -документ приводится к канонической форме, определенной правилами разработанной W3C рекомендации “CanonicalXML” [11.6].

Обеспечение
целостности данных и пользовательской аутентификации с помощью
подписей xml

Спецификация подписи XML – “Цифровая подпись XML” (XMLDS) –
которая была разработана совместными усилиями организации W3C и
IETF, имеет статус Рекомендации W3C. Этот документ определяет
правила обработки и синтаксис, предназначенные для упаковки в
XML-формат данных о целостности сообщения, его аутентификации и
пользовательской аутентификации.

Вернемся к примеру из предыдущей статьи – в нем речь шла о
взаимодействии между туроператором и его партнерами (отелями).
Предположим, что туроператор хочет вызвать метод
GetSpecialDiscountedBookingForPartners Web-сервиса своего
партнера.

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

  • сообщение не было изменено, пока оно передавалось в Web-сервис
    отеля (целостность сообщения); и

  • запрашивающая сторона является бизнес партнером
    (пользовательская аутентификация).

Если выполнены эти два условия, брандмауэр XML разрешает
запрашивающей стороне перейти к SOAP-серверу. На рисунке 1 показ
процесс пользовательской аутентификации:

  1. Туроператор направляет в Web-сервис отеля SOAP-запрос о вызове
    метода. Этот запрос включает всю информацию, относящуюся к
    обеспечению безопасности (пользовательская аутентификация и
    пользовательская аутентификация).

  2. Web-сервис отеля защищен брандмауэром XML, который принимает все
    запросы, направляемые в этот SOAP-сервер. брандмауэр XML проверяет,
    идентично ли полученное сообщение тому, которое запрашивающая
    сторона собиралась отправить.

  3. Если целостность сообщения не нарушена, брандмауэр XML считывает
    идентификационную информацию запрашивающей стороны из этого
    SOAP-запроса и проверяет, является ли этот пользователь бизнес
    партнером.

  4. Если запрашивающая сторона является бизнес партнером, брандмауэр
    XML разрешает запрашивающей стороне перейти к SOAP-серверу.

Рисунок 1. Процесс пользовательской
аутентификации с использованием брандмауэра XML

Процесс пользовательской аутентификации с использованием брандмауэра XML

Листинг 1 – это простой SOAP-запрос, который передает в
Web-сервис отеля вызов метода
GetSpecialDiscountedBookingForPartners. В этом SOAP-запросе
отсутствуют какие-либо данные о целостности сообщения или
пользовательской аутентификации. Листинг 1 – это начальная точка
демонстрации применения спецификации “Цифровая подпись XML”.

Читайте также:  Электронная подпись в Москве — на официальном сайте

Ошибки в системе безопасности в axis2

Что такое оракулы?

В современной криптографии есть направление Provable Security, которое подразумевает анализ исследуемой системы при активном воздействии на нее. Предполагается, что злоумышленник имеет возможность посылать запрос и анализировать полученный ответ, затем создавать новый запрос на основе полученной информации, опять получать ответ и т. д. Под оракулом понимают то, что отвечает на запросы злоумышленника (сервер, просто комп, смарт-карту, СКЗИ, шифровальщик и др.). В нашем сегодняшнем примере в качестве оракула выступает сервер с веб-сервисом, то есть мы посылаем сервису запрос на обработку данных, а он возвращает либо ошибку, либо результат обработки данных. Axis2, в свою очередь, — это фреймворк для создания веб-сервисов. Недавно была новость про Padding Oracle Attack, где в качестве оракула выступало приложение (веб-сервис, сайт на ASP.NET), созданное с использованием .net.

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

При возникновении ошибки безопасности сервис передает нам security fault. Причины генерации security fault можно разделить на две категории: 1. Ошибка дешифрования Такая ошибка возникает при некорректном дополнении последнего блока. Помнишь, я говорил, что последний байт каждого сообщения содержит число, равное количеству дополненных байтов?

Так вот, этот последний байт может принимать значения от 0x01 до 0x10, в противном случае мы получаем сообщение об ошибке. 2. Ошибка парсинга данных Эта ошибка может возникнуть по двум причинам. Первая — открытый текст содержит «запрещенные» символы, то есть символы с кодами ASCII от 0x00 до 0x1F (за исключением 0x09, 0x0A, 0x0D — пробела, конца строки и возврата каретки).

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

Как и в приведенном ранее простом примере, разобьем всю нашу таблицу ASCII на две группы символов (все внимание на четвертый рисунок). Группа A содержит запрещенные для формата XML символы плюс два «зарезервированных» символа «&» и «<», ну а группа B включает в себя все остальные символы.

Таблица ASCII с делением символов на группы
Таблица ASCII с делением символов на группы

Теперь все готово для построения оракула. Как и в примере, наш оракул, то есть сервер, получает на вход один блок текста, зашифрованного в режиме CBC, то есть 16-байтовый вектор инициализации и зашифрованный блок такого же размера, и возвращает true или false.

Конечно, этот блок должен быть правильно «обернут» в SOAP-сообщение, но здесь мы этим пренебрегаем. Итак, оракул возвращает true, если сервер в ответ на SOAP(AESENCCBC(k, (IV, C))) передает нам security fault, и возвращает false в противном случае.

Как я уже говорил, сервер не выдаст security fault, если на стороне сервера сообщение имеет правильное дополнение до полного блока, то есть открытый текст M имеет верную XML-структуру:

PAD(M) == (IV xor AES_DEC(k, C))

Здесь должны выполняться следующие условия: 1. M, содержащий XML-тег , обязательно должен содержать и закрывающий тег . 2. Если M содержит символ амперсанда «&», то он должен служить началом существующей escape-последовательности, например «&gt». 3. M не должен содержать символы из определенной нами группы B.

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

Получение требования и подтверждение о приеме

Полученные требования отображаются в форме “1С-Отчетность” в разделах “Входящие” и “Новое” (рис. 1).

Рис. 1

В процессе электронного документооборота при направлении требования и представлении истребуемых документов в ответ на требование участвуютследующие технологические электронные документы:

  1. Подтверждение даты отправки.
  2. Квитанция о приеме.
  3. Уведомление об отказе в приеме.
  4. Извещение о получении электронного документа.

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

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

Для подтверждения приема требования нажмите ссылку “Подтвердите прием” (см. на рис. 1) или откройте форму требования и нажмите кнопку“Подтвердить прием” (рис. 2).

При наличии оснований для отказа в приеме требования налогоплательщик формирует уведомление об отказе в приеме, подписывает ЭП и направляет вналоговый орган. Для этого нажмите кнопку “Отказать в приеме” (рис. 2).

Уведомление об отказе формируется в следующих случаях:

  • требование направлено налогоплательщику ошибочно (предназначалось другому адресату);
  • требование не соответствует установленному формату;
  • в требовании отсутствует (не соответствует) ЭП уполномоченного должностного лица налогового органа.

Рис. 2

К электронному требованию приложен pdf-файл требования, который открывается по ссылке под надписью “Приложенные файлы” (рис. 3). Вpdf-файле отражена суть требования и указаны сроки, в течение которых необходимо представить соответствующие документы (рис. 4).

Рис. 3

Рис. 4

Чтобы подготовить и отправить документы в ответ на требование необходимо нажать кнопку “Ответить” (рис. 5).

Рис. 5

При этом открывается форма “Ответ на требование о представлении документов” (рис. 6).

Для вставки документов в ответ на требование используются кнопки “Загрузить с диска” и “Выбрать из базы”, в зависимости от местахранения документов.

Максимальный размер всех файлов, добавляемых в ответ, составляет 72 Мб.

Если объем вложений превышает установленный размер, то в форме появится надпись, что допустимый размер превышен с гиперссылкой “Разбить ответ нанесколько”. Нажмите на гиперссылку, чтобы программа автоматически разбила ответ на части. Разбивка не выполняется только в том случае, если одинфайл вложения превышает размер 72 Мб, поэтому будьте внимательны.

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

Рис. 6

Практика утечек

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

Потеря сведений грозит ущербом:

  • финансовым, иногда составляющим миллионы долларов;
  • репутационным, в особенности для банков, интернет-магазинов и телеком-компаний;
  • социальным. Например, утечка сведений, из Пенсионного фонда РФ, произошедшая в 2022 году из-за ошибки при передаче информации, подорвала доверие к государственной организации.

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

Система защиты конечных узлов предполагает реализацию следующих мер:

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

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

И все же исследования российских производителей ИБ-решений говорят о том, что в 2022 году основной проблемой для владельцев данных и служб безопасности стали не утечки информации по каналам связи. Более 80 % утечек происходят именно на конечных узлах.

Статистика по российскому рынку выглядит так: 

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

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

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

Adblock
detector