Формирование и отправка отчетности по FATCA через IDES

[TJJ25]

Коллеги, здравствуйте!

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

[Sergey77]

Добрый день!

Подскажите, сертификат делали на основной домен или поддомен? Как сохраняли закрытый ключ? Ведь, насколько я понял, им нужно будет подписывать отчеты....

Заранее благодарю...

[Bkmz]

Добрый день!

Подскажите, сертификат делали на основной домен или поддомен? Как сохраняли закрытый ключ? Ведь, насколько я понял, им нужно будет подписывать отчеты....

Заранее благодарю...

Сертификат получали на домен. Генерировали запрос на сертификат с помощью openssl. Ключ можно использовать как отдельно .key так и в составе pkcs12 контейнера

[Bkmz]

Коллеги, здравствуйте!

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

Сам сейчас пытаюсь разобраться со средствами шифрования и подписи. Основные шаги, которые необходимо реализовать:

1. Подписать XML файл в соответствии с рекомендациями w3c http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#
2. Сгенерировать AES ключ в отдельный файл
3. Зашифровать с помощью AES ключа архив с xml
4.Зашифровать AES ключ с помощью открытого ключа получателя

И в обратную сторону при получении зашифрованного ответа от ides, т.е. расшифровать, проверить подпись и т.д.

[ab70579]

Сам сейчас пытаюсь разобраться со средствами шифрования и подписи. Основные шаги, которые необходимо реализовать:

1. Подписать XML файл в соответствии с рекомендациями w3c http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#
2. Сгенерировать AES ключ в отдельный файл
3. Зашифровать с помощью AES ключа архив с xml
4.Зашифровать AES ключ с помощью открытого ключа получателя

И в обратную сторону при получении зашифрованного ответа от ides, т.е. расшифровать, проверить подпись и т.д.

получилось?

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

[ost]

содержимое AES (key) краказяброй выглядет

А в шеснадцетиричном виде не пробовали?

[ab70579]

А в шеснадцетиричном виде не пробовали?

пробовали. без толку.

сейчас с IRS контачим...

вообще, сами IRS говорят, что много выплыло проблем.

[ost]

ab70579, скажите, чем подписывали xml?

[ab70579]

ab70579, скажите, чем подписывали xml?

если не изменяет память, то ключем из сертификата sender's

[ost]

ab70579, софтом каким? с ключами-то всё понятно.

[ab70579]

ab70579, софтом каким? с ключами-то всё понятно.

openssl.
шифровал, конечно, не я, а безопасники. но софт точно openssl

[ost]

я не про шифрование, а про подписание xml envelope dsig.
openssl не умеет этого делать.

[OEUC]

Присоединяюсь к вопросу!

я не про шифрование, а про подписание xml envelope dsig.
openssl не умеет этого делать.

[ab70579]

я не про шифрование, а про подписание xml envelope dsig.
openssl не умеет этого делать.

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

[ab70579]

Присоединяюсь к вопросу!

последовательность команд была такая:

Сначала делаем хэш openssl dgst -sha256 "******.99999.SL.643_Payload.xml" > "******.99999.SL.643_Payload.xml_hash",

Потом его подписываем ключом sender openssl rsautl -sign -in "******.99999.SL.643_Payload.xml_hash" -inkey "sender.pem" –out "******.99999.SL.643_Payload.xml_sig"

[ost]

при создании xml dsig требуется приведение xml к канонической форме. просто так сделать хэш к файлу не прокатит.

[ab70579]

при создании xml dsig требуется приведение xml к канонической форме. просто так сделать хэш к файлу не прокатит.

собственно вопрос а) как это аффетит получаемый архив IRS? и вопрос б) а что в таком случае приводид xml файл к канонической форме и создает xml dsig?

[ost]

собственно вопрос а) как это аффетит получаемый архив IRS? и вопрос б) а что в таком случае приводид xml файл к канонической форме и создает xml dsig?

а) проверка подписи даст отрицательный результат.
б) вот это я хотел узнать у вас.

http://www.di-mgt.com.au/xmldsig2.html

вообще-то, есть xmlsec но я пока не понял, как его заставить сделать SHA-256. Есть апач хмл секьюрити проджект, в нем есть класс org.apache.xml.security.c14n.Canonicalizer
но это надо жабу разворачивать.
http://esus.com/canonicalizing-an-xml-file/

нашел ещё вот это http://xmlstar.sourceforge.net/docs.php

[Chaxliy]

Рассказываю, что сделали Мы, и попутно задам пару вопросов.
1) Подписание xml - используем xmlsec, в xml файл вставляется шаблон для подписи, запускается батник, просчитываются значения хэша и подписи, которые вставляются в xml. Если кому надо - напишу что за шаблон для подписи, и команду для батника(нет сейчас с собой, надо поискать)
2)Генерация ключа - openSSL, просто генерим случайную последовательность байт (32 байта), записываем в файл key
openssl.exe rand -out key 32
3)Шифруем с помощью этого ключа наш архив в openssl
openssl enc -nosalt -in НАШ_АРХИВ -out НАШ_ШИФРОВАННЫЙ_АРХИВ -aes-256-ecb -pass file:key

4) Шифруем сгенерированный ключ, используя открытый ключ из сертификата с сайта IDES
openssl.exe rsautl -encrypt -pkcs -pubin -inkey key_irs.pem -in key -out keyenc

Вроде все норм, но вот ответ IRS расшифровать не получается , а это значит что команда
openssl enc -nosalt -in НАШ_АРХИВ -out НАШ_ШИФРОВАННЫЙ_АРХИВ -aes-256-ecb -pass file:key
неверна.
Кто в каком ПО производил шифрование/расшифрование архива по алгоритму aes256, и если в OpenSSL то какой код?

[ab70579]

а) проверка подписи даст отрицательный результат

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

а у вас что-нить получилось с шифрованием-дешифрованием отчетности irs? может свои опытом поделитесь?

[ost]

Вроде все норм, но вот ответ IRS расшифровать не получается , а это значит что команда
openssl enc -nosalt -in НАШ_АРХИВ -out НАШ_ШИФРОВАННЫЙ_АРХИВ -aes-256-ecb -pass file:key
неверна.

Надо расшифровывать, а не шифровать. Как-то так:
openssl enc -d -in ПОЛУЧЕННЫЙ_АРХИВ -out РАСШИФРОВАННЫЙ_АРХИВ -aes-256-ecb -K key

key - the actual key to use: this must be represented as a string comprised only of hex digits. If only the key is specified, the IV must additionally specified using the -iv option.

Но сначала расшифровать присланный из IRS ключ вашим секретным ключом от сертификата. Будет выглядеть как-то так:
openssl rsautl -decrypt -in ФАЙЛ_С_ЗАШИФРОВАННЫМ_КЛЮЧОМ -out ФАЙЛ_С_РАСШИФРОВАННЫМ_КЛЮЧОМ -inkey ВАШ_RSA_private_key

1) Подписание xml - используем xmlsec, в xml файл вставляется шаблон для подписи, запускается батник, просчитываются значения хэша и подписи, которые вставляются в xml. Если кому надо - напишу что за шаблон для подписи, и команду для батника(нет сейчас с собой, надо поискать)

Да, очень надо.

[ost]

3)Шифруем с помощью этого ключа наш архив в openssl
openssl enc -nosalt -in НАШ_АРХИВ -out НАШ_ШИФРОВАННЫЙ_АРХИВ -aes-256-ecb -pass file:key

Вот по данной команде у меня вопрос.
openssl в общем случае, в таком виде ключ не принимает. если в файле есть непечатные символы, то openssl ругается.

Как вам удалось зашифровать файл?
В таком виде подается не ключ, а пароль, на основании которого openssl генерит ключ и IV.

[ost]

В общем, не всё так просто и кучеряво.

1. openssl использует свой формат для сохранения зашифрованных файлов. см. здесь: http://security.stackexchange.com/qu...-by-passphrase

The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code.

The header format is rather simple:

magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f
salt value (8 bytes)
Hence a fixed 16-byte header, beginning with the ASCII encoding of the string "Salted__", followed by the salt itself. That's all ! No indication of the encryption algorithm; you are supposed to keep track of that yourself.

The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!)

Я не нашел, как заставить openssl расшифровать файл указав ей только ключ без вектора инициализации (IV).

2. Нашел вот такой ресурс http://aes.online-domain-tools.com/ На нём мне удалось расшифровать файл из тестового примера FATCA. Т.е. предыдущий шаги (расшифровка ключа на секретном ключе получателя) был сделаны правильно. Алгоритм AES ECB
ищу тулзу для шифрования/расшифровывания aes

[ab70579]

В общем, не всё так просто и кучеряво.

1. openssl использует свой формат для сохранения зашифрованных файлов. см. здесь: http://security.stackexchange.com/qu...-by-passphrase


Я не нашел, как заставить openssl расшифровать файл указав ей только ключ без вектора инициализации (IV).

2. Нашел вот такой ресурс http://aes.online-domain-tools.com/ На нём мне удалось расшифровать файл из тестового примера FATCA. Т.е. предыдущий шаги (расшифровка ключа на секретном ключе получателя) был сделаны правильно. Алгоритм AES ECB
ищу тулзу для шифрования/расшифровывания aes

я так понимаю, у вас вопрос расштфровки решен?

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

[ost]

можете поделиться и показать полученный и расшифрованный xml?

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

[Ardnas]

Просьба к знатокам C# помочь проверить код для Step 1a - Sign the XML File.

Добрый день, коллеги.

Мы попытались сами наваять на C# код для Step 1a - Sign the XML File.
(Хотя американцы могли бы предоставить утилиту или пример кода. Но пока самим приходиться выкручиваться.)

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

Посмотреть, что американцы подписывают невозможно, хеширование – однонаправленная функция.

Код добывали гуглив просторы Интернета и по книжкам. Сами прежде глубоко в криптографию Microsoft .NET не вникали.

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

Код нужно вставить в приложение типа Windows Forms, на форме одна кнопка, и по клику на кнопке исполняется код.
Файл “000000.00000.TA.124.xml” и тестовый сертификат “sender.p12” надо подложить в директорию где компилируется на выходе и запускается EXE-файл. Программисты уверен быстро поймут что к чему.

Использовали:
Microsoft .NET версии 4.5 (если правильно поняли то именно в этой версии Microsoft любезно добавила нужные классы для "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256")

MS Visual Studio Express 2012

OS: Windows 2008 R2 SP1 ( или OS где встанет Microsoft .NET версии 4.5 например: Windows 7 Service Pack 1; Windows Server 2008 R2 SP1; Windows Server 2008 Service Pack 2; Windows Vista Service Pack 2)

[ost]

не можем добиться чтобы DigestValue и подпись в подписанном файле были как в тестовом примере

Аналогичная фигня. Я пользую xmlsec
Какой у вас дайджест получается?

У меня такой: HRwFr0D/5lb+jy7reKZL+1JVXJQMQqLOQqX9TCc5keo=

В примере: psVt7tiDgvrHKNFOBn8G99lnvQFVIo6QaYiQpyXpZvc=

уже голову сломал.

[ost]

Да, вдогонку, если прогнать американский файл через Online XML Digital Signature Verifer
https://www.aleksey.com/xmlsec/xmldsig-verifier.html

То он говорит, что подпись неверна.

[Ardnas]

Аналогичная фигня. Я пользую xmlsec
Какой у вас дайджест получается?

У меня такой: HRwFr0D/5lb+jy7reKZL+1JVXJQMQqLOQqX9TCc5keo=

В примере: psVt7tiDgvrHKNFOBn8G99lnvQFVIo6QaYiQpyXpZvc=

уже голову сломал.

У нас такой дайджест получается: erI6HyqVSpVke6oIx4ZkKH90uom5zYh0sTPjpOBuXuA=

[ost]

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

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