СМЭВ 3. Электронная подпись сообщений на Java и КриптоПро / Хабр

Основные функции смэв

Основными функциями СМЭВ являются:

В целях исполнения своих функций СМЭВ обеспечивает:

• доступ к электронным сервисам³ информационных систем, подключенных к СМЭВ;

• возможность использования централизованных баз данных и классификаторов информационными системами, подключенными к СМЭВ;

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

• защиту передаваемой информации от несанкционированного доступа, искажения или блокирования с момента поступления указанной информации в СМЭВ до момента передачи ее в подключенную к СМЭВ информационную систему;

• ведение реестра электронных сервисов информационных систем, подключенных к СМЭВ.

Что такое смэв и для чего она нужна?

Единая система межведомственного электронного взаимодействия (СМЭВ)1  – федеральная государственная информационная система, предназначенная для организации информационного взаимодействия между информационными системами участников СМЭВ в целях предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме.

Участниками межведомственного электронного взаимодействия (участниками СМЭВ) являются федеральные органы исполнительной власти, государственные внебюджетных фонды, исполнительные органы государственной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры, иные органы и организации.

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

СМЭВ предназначена для решения следующих задач:

Анализ исходных данных

Загружаем с портала СМЭВ 3:

Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.

Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml

Как стать участником смэв?

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

Интеграция информационных систем в рамках СМЭВ осуществляется в соответствии с Техническими требованиями к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия (утв. приказом Минкомсвязь России от 27.12.2021 № 190).

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

АИС МФЦ ДЕЛО — решение для автоматизации деятельности многофункциональных центров предоставления государственных и муниципальных услуг (МФЦ). Основная цель внедрения АИС МФЦ – повышение качества работы МФЦ. Это достигается путем взаимодействия со СМЭВ, РСМЭВ, УЭК, ИАС МКГУ, ГИС ГМП, Центром Телефонного Обслуживания, а также с федеральной государственной информационной системой «ЕСИА»:

Справочная информация: Перечень наиболее важных документов по организации информационного взаимодействия органов государственной власти в рамках СМЭВ:

Подготовка к подписи по правилам смэв 3

Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.

В библиотеке xmlsec-1.5.0.jar в файле orgapachexmlsecurityresourceconfig.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.

Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.

По старинке это делалось так:

//APACHE-SANTUARIO INIT WITH CryptoPro JCP
        System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml");
        org.apache.xml.security.Init.init();
        String cfile1 = System.getProperty("org.apache.xml.security.resource.config");
        LOGGER.log(Level.INFO, "Init class URL: "   org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation());
        LOGGER.log(Level.INFO, cfile1);

В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:

ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();

Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:

  try {
                Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName());
                santuarioIgnoreLineBreaks(true);
                LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized");
            } catch (AlgorithmAlreadyRegisteredException e) {
                LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: "   e.getMessage());
            } 

Заодно сразу выполняем требование из Методических указаний:

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

santuarioIgnoreLineBreaks(true);

    private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";

/**
     * Apache Santuario privileged switch IgnoreLineBreaks property
     * 
     * @param mode
     */
    private void santuarioIgnoreLineBreaks(Boolean mode) {
        try {
            Boolean currMode = mode;
            AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
                
                public Boolean run() throws Exception {
                    Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD);
                    f.setAccessible(true);
                    f.set(null, currMode);
                    return false;
                }
            });
            
        } catch (Exception e) {
            LOGGER.warning("santuarioIgnoreLineBreaks "   ExceptionUtils.getFullStackTrace(e));
        }
    }

Делается это в привилегированном блоке AccessController.doPrivileged

и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.

Просто через настройку системного свойства:

System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");

не работает.

Через настройку опции JVM:

-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true

работает.

Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».

private static boolean ignoreLineBreaks =
        AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
            public Boolean run() {
                return Boolean.valueOf(Boolean.getBoolean
                    ("org.apache.xml.security.ignoreLineBreaks"));
            }
        }).booleanValue();
public static boolean ignoreLineBreaks() {
        return ignoreLineBreaks;
    }

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

Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.

С этим свойством, конечно, возникает вопрос к Apache Santuario:

Подпись сообщений смэв 3

Для подписи документов СМЭВ 3 все готово.

Код подписания выглядит следующим образом:

Получить ключ электронной подписи для смэв

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

• ЭП-ОВ — электронная подпись органа власти для подписания ответов;
• ЭП-СМЭВ — сертификат ЭЦП должностного лица для подписания запроса.

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

Преимущества смэв

Единая информационная система имеет ряд неоспоримых преимуществ:

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

Для получения информации, размещенной в СМЭВ, необходимо отправить запрос. Для подписания запроса используется квалифицированная электронная подпись.

Проблемы. хэш не совпадает

Внимание!

Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xmlИз него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.

Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как

ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП

Почему

не совпадал с оригинальным примером:

Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8); 

для параллельного анализа всех этапов трансформации.

Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:

Поиск решения показал, что, во-первых

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

Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.

Старая версия класса трансформации выдала следующий нормализованный документ:

С ним хэш стал совпадать, а подпись успешно проходить валидацию.

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

if (logger.isDebugEnabled()) {
                debugStream = new DebugOutputStream(argDst);
                dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8);
            } else {
                dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8);
            }

Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:

Отсутствует строка:

prefixMappingStack.pop();

, которая удаляет первый объект из стека с префиксами

  Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();

, что приводило к неверной работе SmevTransformSpi.

Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.

Проверка подписи сообщения смэв 3

Код проверки подписи выглядит следующим образом:

Результаты

Подписание конвертов СМЭВ 3 выполняется успешно.

Сообщения проходят проверку на портале Электронного правительства Госуслуги

И в собственном приложении:

Технологическое обеспечение смэв

Технологическое обеспечение информационного взаимодействия с применением СМЭВ достигается путем использования:

Электронная подпись (эцп) для смэв | сертификат электронной подписи смэв