Я сегодня победил отечественные хеши в цифровой подписи XML документов (пока не саму цифровую подпись, а ее целостность-хеш)
Разработка программ часто напоминает лабиринт или квест, из которого не так-то просто найти выход. Иногда только шаманство и интуиция помогают найти выход из какзалось бы безвыходной ситуации. Прикол такой...
Есть алгоритм нормализации XML, который описан в документации без тестовых векторов. Поверх него лежит описанный стандартом RFC алгоритм канонизации XML, поверх него лежит алгоритм ГОСТ Р 34.11 хеша, поверх него лежит ГОСТ Р 34.10-2001 цифровая подпись от структуры Signature, которая заполняется хешами и параметрами цифровой подписли. Цифровая подпись делается поверх хешей от объекта - фрагмента дерева XML.
Нет такой открытой софтины, которая это умеет делать, я не нашел.
Обычно это делают с помощью микрософта MSXML50 и CryptoAPI/CAPICOM - CryptoPro. Подпись в MS выглядит так: создать объект XML с указанием алгоритмов в качестве атрибутов тегов, шаблон, потом попросить сформировать XML-Signature с заполненными элементами, в которые вставляются сертификаты хеши и цифровые подписи упакованные в base64. Все это делается неявно. Микросовт сам форматирует испльзуя атрибуты алгоритмов, и соответственно когда встречает упоминание алгоритмов gost вызывает соответствующий криптопровайдер.
Вот и как такого монстра отреверсить? У меня неотлажеваемый алгоритм нормализации по пути, на который есть дока но нет примеров, можно запутаться, единственная проверка может быть в совпадении хешей.
Про микросовт не известно, как он форматирует и нормализует, может добавлять причуды типа BOM или <?xml ....?> и мало ли что еще там всплывет, типа "\r".
Я сначала отладил алгоритм ГОСТ хеш, а потом больше суток подбирал, что должно быть на входе, чтобы получился нужный хеш.
Одна из идей была купить SDK от криптопро и таким образом наделать тестовых векторов. Однако, на простарах дырнета нашел примеры из криптопро и обнаружил, что там нет нужного алгоритма нормализации. Так что не помогло бы.
Потом расширил задачу поиска и нашел подробное описание алгоритма нормализации от центрабанка (банка россии), хотя названия алгоритмов разные и возможно расхождение в функциональности, помогло понять, что имела ввиду таможня, и кто с кого списывал документацию.
Из выборки в 20-30 подписанных документов выбрал пример с самым минимальным количеством вариаций относительно описания алгоритма нормализации; раза с дцатого подобрал правильный вход используя утилиты base64 и gostsum из девелопер пакета OpenSSL 1.0+. Потом отладил направление вывода для своего алгоритма гост-хеш и теперь вырисовываю свою функцию нормализации XML.
Прикол тут в том что проверять XML надо после парсера, выделив часть дерева для подписи, а это значит, что мне не кусок текста нужно отрезать от существующего текста, а сформировать/распечатать из структуры узлов фрагмент дерева уже в нормализованном виде. Короче, нужно в моей собственной реализации XML парсера научится работать с пространствами имен и сортировками атрибутов, ато никакой нормализации не получится.
В какой-то момент времени я решил, что наша страна попала на микрософт и КриптоПро, потому что отреверсить такое может не получится никогда. Хорошо, что не сдался. То что я делаю позволяет взаимодейстововать с гос структурами, например с таможней или банком россии. Может опубликовать результаты, чтобы другие не мучались?
Разработка программ часто напоминает лабиринт или квест, из которого не так-то просто найти выход. Иногда только шаманство и интуиция помогают найти выход из какзалось бы безвыходной ситуации. Прикол такой...
Есть алгоритм нормализации XML, который описан в документации без тестовых векторов. Поверх него лежит описанный стандартом RFC алгоритм канонизации XML, поверх него лежит алгоритм ГОСТ Р 34.11 хеша, поверх него лежит ГОСТ Р 34.10-2001 цифровая подпись от структуры Signature, которая заполняется хешами и параметрами цифровой подписли. Цифровая подпись делается поверх хешей от объекта - фрагмента дерева XML.
Нет такой открытой софтины, которая это умеет делать, я не нашел.
Обычно это делают с помощью микрософта MSXML50 и CryptoAPI/CAPICOM - CryptoPro. Подпись в MS выглядит так: создать объект XML с указанием алгоритмов в качестве атрибутов тегов, шаблон, потом попросить сформировать XML-Signature с заполненными элементами, в которые вставляются сертификаты хеши и цифровые подписи упакованные в base64. Все это делается неявно. Микросовт сам форматирует испльзуя атрибуты алгоритмов, и соответственно когда встречает упоминание алгоритмов gost вызывает соответствующий криптопровайдер.
Вот и как такого монстра отреверсить? У меня неотлажеваемый алгоритм нормализации по пути, на который есть дока но нет примеров, можно запутаться, единственная проверка может быть в совпадении хешей.
Про микросовт не известно, как он форматирует и нормализует, может добавлять причуды типа BOM или <?xml ....?> и мало ли что еще там всплывет, типа "\r".
Я сначала отладил алгоритм ГОСТ хеш, а потом больше суток подбирал, что должно быть на входе, чтобы получился нужный хеш.
Одна из идей была купить SDK от криптопро и таким образом наделать тестовых векторов. Однако, на простарах дырнета нашел примеры из криптопро и обнаружил, что там нет нужного алгоритма нормализации. Так что не помогло бы.
Потом расширил задачу поиска и нашел подробное описание алгоритма нормализации от центрабанка (банка россии), хотя названия алгоритмов разные и возможно расхождение в функциональности, помогло понять, что имела ввиду таможня, и кто с кого списывал документацию.
Из выборки в 20-30 подписанных документов выбрал пример с самым минимальным количеством вариаций относительно описания алгоритма нормализации; раза с дцатого подобрал правильный вход используя утилиты base64 и gostsum из девелопер пакета OpenSSL 1.0+. Потом отладил направление вывода для своего алгоритма гост-хеш и теперь вырисовываю свою функцию нормализации XML.
Прикол тут в том что проверять XML надо после парсера, выделив часть дерева для подписи, а это значит, что мне не кусок текста нужно отрезать от существующего текста, а сформировать/распечатать из структуры узлов фрагмент дерева уже в нормализованном виде. Короче, нужно в моей собственной реализации XML парсера научится работать с пространствами имен и сортировками атрибутов, ато никакой нормализации не получится.
В какой-то момент времени я решил, что наша страна попала на микрософт и КриптоПро, потому что отреверсить такое может не получится никогда. Хорошо, что не сдался. То что я делаю позволяет взаимодейстововать с гос структурами, например с таможней или банком россии. Может опубликовать результаты, чтобы другие не мучались?
Опубликовать. Причем в нескольких местах. А ссылки кинуть в msdn в статьи про msxml :)
ОтветитьУдалитьесть отдельная компонента ГОСТ-хеш ее опбликовать нет проблем. А вот XML-signature сильно завязана на множество других компонент: XML-парсер, XML-canonization,.. , которые не столь наглядны. Хотя можно попробовать сделать утилиту командной строки, которая проверяет или подписывает SOAP. В моей реализации нет четкой границы между парсером и канонизацией. Канонизация это не функуия обработки XML, это способ сериализации уже разобранной структуры дерева XML.
ОтветитьУдалитьДа, утилита — это хороший reference. В идеале еще бы в какой-нибудь журнал статью. Потому как иначе знание не будет широкодоступно.
ОтветитьУдалитьИ где же публикация???
ОтветитьУдалитьМы делаем коммерческий продукт, за деньги продается результат работы. К тому же это делается не вполне легально, поскольку не планируется сертификация ФСБ или ФСТЭК. Программный продукт содержащий в себе нашу криптографию уже отработал более двух лет в составе серверной корпоративной информационой системы. Мне публикация не нужна, пока не придумаю как на этом больше денег заработать.
ОтветитьУдалить