通过加密和完整性验证传输 XML 的好方法有哪些？
我们被要求开始开发一种标准化方法来在项目中传输 XML 数据，该方法最终将在整个特定行业中使用。一些要求包括：
- XML 必须允许对数据进行部分/完整加密
- 必须能够验证 XML 的来源（服务器和客户端彼此已知）
- 必须支持在线和离线处理（批量）
- 任何在线处理都必须通过安全通道
“服务器”和“客户端”将相互“注册”，并且都将发起消息的发送。
该联盟提出的一些想法：
- 大多数成员不喜欢 SOAP - 它通常会导致比解决的问题和开销更多的问题和开销
- XML 完整性和加密比传输更重要
- 大多数成员更喜欢加密/解密的概念应用程序级别，而不是仅在传输
- SSL 连接将是在线、实时的，并且无法在 Web 应用程序级别强制执行。
我们已经有了一个在概念验证阶段使用的基本 XML 模式，基本上包括：
- 命令/响应类型
- 变量/响应消息
我们目前处于高级阶段，并且我'我有兴趣了解目前存在哪些标准以及建议采取哪些方法。
We've been asked to start developing a standardised approach to transferring XML data in a project, which will eventually be used throughout this particular industry. Some of the requirements include:
- XML must allow partial/complete encryption of data
- Must be able to verify the source of the XML (server and client will be known to each other)
- Must support both online and offline processing (batches)
- Any online processing must be over a secure channel
The 'server' and 'client' will 'register' with each other, and will both initiate the sending of messages.
Some thoughts that have been raised by the consortium:
- SOAP isn't liked by most members - it often causes more problems and overhead than it solves
- The XML integrity and encryption is more important than the transport
- Most members prefer the concept of encryption/decryption at the application level, rather than solely at transport
- SSL connections would be online, realtime only and could not be enforced at the web-application level.
We already have a basic XML schema that has been used at the proof-of-concept stage, and basically consists of:
- A command / response type
- Variables / response messages
We're at a high-level stage at the moment, and I'd be interested to know what standards currently exist and what approaches would suggest.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您打算进行部分加密，那么 PKCS#7/CMS 很快就会成为一个障碍。 PGP 对此可能也不是很有用，因此这给您留下了 XML 签名和签名。 XML 加密标准。
对于签名生成/验证，使用 XML 数字签名是合乎逻辑的。但是，您需要非常清楚地指定您要签署的内容以及您将在验证方面做出哪些选择。一个好的验证清楚地验证了规范化方法、哈希方法等。除此之外，您必须真正确保您签署的内容就是您从 XML 中检索的内容。验证一个部分并发现您正在使用 XML 的完全不同的部分是非常容易的。有时软件很容易受到攻击，因为攻击者可以简单地从数据中删除签名！
如果您总是（总是）在解密之前验证 XML，则可以简单地使用 XML 加密和 AES-CBC。如果不这样做，您应该使用 GCM 模式。由于它目前是工作草案，因此可能需要您对当前软件进行一些更改。如果没有验证或具有完整性保护的密码，您将很容易受到填充预言机攻击。
当然，对于签名生成和验证以及加密/解密，您应该使用 x509 基础设施。您可以设置自己的 CA 软件，例如使用 EJBCA，但您应该获得这样做的专业知识（购买支持？）。证书和密钥管理应该是主要关注点之一。或者，您可以使用标准 SSL/TLS 证书。这也将允许您设置启用 SSL 的服务器。如果您选择 SSL/TLS（强烈推荐），请使用客户端身份验证和一小组安全密码套件。
最后，您应该真正限制可用选项的数量，同时为未来的更改保留选项。如果您保留太多选项，测试将变得非常困难，攻击者只会选择最不困难的选项进行攻击。如果对性能感兴趣，请为具有众所周知的命名曲线的 X509 证书选择 ECC，但要注意复杂性以及某些合作伙伴可能无法找到正确的库的可能性。
您可以从信誉良好的供应商处购买所有这些，但我对 XML 加密支持持怀疑态度。我已经离开了（甚至在测试它们之前）一些开源库，因为我根本无法足够信任它们。不幸的是，我见过“营利”组织的情况更糟。您需要一位具有良好声誉的加密专家来检查协议和实现 - 仅仅将一些东西组合在一起是不够的。
If you are going for partial encryption, then PKCS#7/CMS would quickly become a cludge. PGP is probably not very useful for this either, so this leaves you with XML signature & XML encryption standards.
For signature generation/verification it would be logical to use XML digital signature. However, you need to very clearly specify what you are going to sign and which choices you are going to make regarding verification. A good verification clearly verifies the canonicalization methods, hashing methods and so on. Beyond that you must make really really sure that what you sign is what you retrieve from the XML. It's very easy to verify one part and find out you are using an entirely different part of XML. Sometimes software is vulnerable because an attacker can simply strip the signature from the data!
If you always (always) verify your XML before decryption, you can simply use XML encryption and AES-CBC. If you don't, you should use GCM mode. As it is currently a working draft, it might require you to create some changes in current software. Without verification or a cipher with integrity protection, you will be vulnerable to padding oracle attacks.
Of course, for both signature generation and verification as well as encryption/decryption you should use an x509 infrastructure. You can setup you own CA software, e.g. using EJBCA, but you should get the expertise to do so (buying support?). Certificate and key management should be one of the main focusses. Alternatively, you could use standard SSL/TLS certificates. This will allow you to setup SSL enabled servers as well. If you go for SSL/TLS (highly recommended) use client authentication and a small set of safe cipher suites.
Finally, you should really limit the number of available options, while keeping options open for future changes. If you keep too many options open, it will get very tough to test and attackers will simply choose the least difficult one to attack. If performance is of interest, choose ECC for the X509 certificates with a well known named curve, but beware of the complexities and the likelyhood that some partners won't be able to find the right libraries.
You can buy all this from reputable vendors, but I would be pretty skeptic about XML encryption support. I've wandered away (even before testing them) from some open source libs because I simply was not able to trust them enough. Unfortunately, I've seen much worse from "for profit" organizations. You need a crypto expert with a proven reputation to check the protocols and implementations - just hacking something together is not going to be good enough.
我不知道我是否可以根据所提供的信息充分回答您的问题，但您要求的是公钥/信任基础设施网络。
具体如何实现以及使用哪种语言取决于您。大多数情况下，填充的对称密码就足够了，也许如果您将其作为 base64 嵌入到您的 xml 中，例如 <<编码>，应该可以。
HMAC。简单明了的 HMAC，通过 Diffie-Hellman 系统进行签名和身份验证的密钥交换。
但老实说，标准并不以您希望的方式存在。您可以将最佳实践和加密系统组合在一起。尽管永远不建议发明自己的系统。它会破裂。最好的办法是使用 SSL / TLS 和 x509 基础设施。
I don't know if I can answer your question sufficiently, with the information provided, but what you are asking for is a Public Key / Web of Trust Infrastructure.
How you implement this and in which language is your thing. Mostly a padded symmetric cipher would be sufficient, maybe if you embed it as base64 in your xml as something like < encoded >, that should work.
HMACs. Plain and simple HMACs, with signed and authenticated key exchange via Diffie-Hellman Systems.
But honestly, Standards don't exists in that way you would like them. There are best practices and crypto systems you can put together. Although it is NEVER advisable to invent you own system. It will break. Your best shot would be to use SSL / TLS and the x509 infrastructure.