SOAP响应MTOM附件无法解密(AES算法) [英] SOAP response MTOM attachment can't be decrypted (AES algorithm)

查看:142
本文介绍了SOAP响应MTOM附件无法解密(AES算法)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Soap客户端,在读取(和解密)响应附件时遇到问题。使用 MTOM 机制将附件包含在响应中,并通过 AES128-CBC 算法(密钥包含在响应xml标头中)。



以下是响应的基本结构:

 <?xml version = 1.0 encoding = UTF -8?> 
< soapenv:信封>

..包含附件
解密usign AES算法密钥的xml数据。

< / soapenv:Envelope>

--MIMEBoundaryurn_uuid_174A74CB7221A5AF451426570004765
Content-Type:应用程序/八位字节流
Content-Transfer-Encoding:二进制
Content-ID:< urn:uuid:174A74CB7221A5AF451426570004768 @ apache.org>

iQ。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 ')#^ & a p}Q ¨גZ< G。%_ |
Ps。< ''9 g](ǧ> ; l。 p>

MTOM机制意味着附件以二进制字符串形式发送(不编码为base64)。正如我建议的那样,必须通过AES解密此二进制字符串。但是不幸的是,应用AES解密的长度是错误的-AES使用16个字节的块,因此密码必须是16的倍数。但是,例如在附件长度为250的示例中,它不是。



也许我丢失了某些东西,并且在解密附件二进制字符串之前必须对它进行某种转换?



聚苯乙烯响应xml主体的一部分使用相同的算法(AES128-CBC)进行了加密,但以base64密码发送,必须对其进行解码以获得二进制字符串,然后再对其进行解密。哪个工作正常。解码后的主体密码具有正确的长度-16的倍数,可以解密而没有任何问题。



在此先感谢您的任何想法!

解决方案

旧的,但是从Oracle到页面的大约一半


注意:流MTOM不能与消息
加密一起使用。


http://docs.oracle.com/cd/E14571_01/web.1111/ e13734 / mtom.htm#WSADV141


I'm working on the soap client and have a problem with reading (and decryption) of the response attachment. The attachment is included into the the response using MTOM mechanism and encrypted via AES128-CBC algorithm (the secret key is included to the response xml header).

Here is the basic structure of the response:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope>

.. the xml data that includes the secret key for the attachment 
decryption usign AES algorithm.

</soapenv:Envelope>

--MIMEBoundaryurn_uuid_174A74CB7221A5AF451426570004765
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <urn:uuid:174A74CB7221A5AF451426570004768@apache.org>

iQ�<]�+)B�ل�$O:���'�zT�F�x�����������}�t��݄��')#^��&�a�p}Q��¨גZ<G�%_"��|
Ps�<���'9��g](ǧ">�l��� ��XPrJ��jM�f�<$�)Q�*��
--MIMEBoundaryurn_uuid_174A74CB7221A5AF451426570004765--

MTOM mechanism implies that the attachment is sent as a binary string (without encoding to base64). As I suggest, this binary string is what must be decrypted via AES. But unfortunately it has the wrong length to apply the AES decryption - AES uses the 16 bytes blocks, so the cipher must be a multiple of 16. But it does not, for example in the example above the attachment length is 250.

Maybe I'm missing something and some kind of transformation must be applied to the attachment binary string before decrypting it?

P.S. The part of the response xml body is encrypted using the same algorithm (AES128-CBC), but is sent as a base64 cipher, which must be decoded to get the binary string and then decrypted. Which works fine. The decoded body cipher has the proper length - a multiple of 16 and it can be decrypted without any problems.

Thank you in advance for any thought or ideas!

解决方案

Old, but from Oracle about half way down the page

Note: Streaming MTOM cannot be used in conjunction with message encryption.

http://docs.oracle.com/cd/E14571_01/web.1111/e13734/mtom.htm#WSADV141

这篇关于SOAP响应MTOM附件无法解密(AES算法)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆