소개
XML은 인터넷에서 데이터를 교환하는 중요한 메커니즘이 되었습니다. XML 메시지를 보내는 방법인 SOAP는 프로세스가 전례 없는 방식으로 서로 통신할 수 있도록 하며, UDDI는 서비스 자체가 XML인 웹 서비스 공급자와 사용자를 통합하는 표준으로 빠르게 자리잡고 있습니다. WSDL(예: "웹 서비스 설명 언어") 형식으로 설명됩니다. XML이 없었다면 이러한 유연성과 강력함은 불가능했을 것이며, 많은 사람들이 말했듯이 메타언어를 개발하는 것이 필요할 것입니다.
안전성적 분야도 빠르게 성장하는 분야입니다. 서로 다른 그룹 간에 신뢰를 구축하는 기존 방법은 공용 인터넷은 물론 대규모 LAN 및 WAN에서는 더 이상 적합하지 않습니다. 이러한 경우 비대칭 암호화를 기반으로 한 신뢰 메커니즘이 매우 유용할 수 있지만 실제로는 배포 및 키 관리의 용이성, 상호 운용성 범위 및 제공되는 보안이 다양한 "공개 키 기반"에 비해 훨씬 열등합니다. 인프라(PKI)는 열성적인 공급업체를 통해 우리를 믿게 만들었습니다. 계층적 데이터 구조와 기밀성, 액세스 권한 또는 무결성과 같은 다양한 요구 사항이 있는 데이터 하위 집합을 처리하는 것은 특히 어렵습니다. 또한 오늘날의 XML 문서 표준과 다른 보안 제어 기능을 갖춘 애플리케이션은 결코 단순하지 않습니다.
현재 여러 그룹에서 이러한 문제를 검토하고 표준을 개발하는 데 적극적으로 참여하고 있습니다. 주요 관련 개발로는 XML 암호화 및 관련 XML 서명, "XACL(Extensible Access Control Language)" 및 관련 "SAML - 이전 경쟁자인 AuthML 및 S2ML의 조합"이 있습니다. 이 모든 것은 OASIS 및 XKMS(XML 키 관리 사양)에 의해 주도됩니다. 이 기사에서는 XML 암호화 및 XML 서명을 소개합니다.
"XML 보안 제품군"
그 이유 중 하나는 이러한 표준이 아직 개발 단계에 있기 때문에 개발자가 사용할 수 있는 도구 세트와 라이브러리의 수가 여전히 제한되어 있기 때문입니다. 자신감 요점은 이것이 변화하기 시작했다는 것입니다. IBM은 "JCP(Java Community Process)"에 두 가지 관련 "JSR(Java 사양 요청)"을 제출했습니다. JSR-105, "XML 디지털 서명 API" 및 JSR-106, "디지털 암호화 API"입니다.
"IBM Tokyo Research Laboratory"는 1999년에 XML 서명의 프로토타입 구현으로 "XML Security Suite"를 개발했습니다. 여기에는 자동으로 XML 디지털 서명을 생성하고 W3C의 "표준" XML 작업 초안을 구현하며 XML 암호화의 실험적 구현을 통해 요소 수준 암호화를 제공하는 유틸리티가 포함되어 있습니다. 또한 XML 문서에 적용할 때 보안 관련 요구 사항을 처리하는 방법도 제공합니다. XACL(Extensible Access Control Language)에 대한 XML 스키마 정의도 도입되었습니다.
developerWorks에는 제품군에 대해 자세히 설명하는 Doug Tidwell의 기사가 있으며 최신 버전의 제품군은 alphaWorks 사이트에서 사용할 수 있습니다. (리소스 참조)
XML 암호화 및 XML 서명
다른 문서와 마찬가지로 XML 문서 전체를 암호화한 다음 하나 이상의 수신자에게 안전하게 전송할 수 있습니다. 예를 들어 이는 SSL이나 TLS의 일반적인 기능이지만 더 흥미로운 점은 동일한 문서의 서로 다른 부분이 어떻게 다르게 처리되는지입니다. XML의 중요한 이점은 전체 XML을 단일 작업으로 보낸 다음 로컬에 저장할 수 있어 네트워크 트래픽을 줄일 수 있다는 것입니다. 그러나 이는 다양한 요소 그룹에 대한 승인된 보기를 어떻게 제어할 수 있는지에 대한 질문을 제기합니다. 판매자는 고객의 이름과 주소를 알아야 할 수 있지만 은행이 구매하는 상품의 세부 사항을 알 필요가 없는 것처럼 사용되는 신용 카드의 세부 사항을 알 필요는 없습니다. 연구자는 개인의 의료 기록에 대한 세부 정보를 볼 수 없도록 해야 하고, 관리자는 해당 세부 정보를 정확히 볼 수 있어야 하지만 의사나 간호사는 의료 세부 정보와 일부(전부는 아님) 개인 정보를 볼 수 없도록 해야 합니다. 재료.
암호화는 이제 정보를 숨기는 것 이상의 역할을 합니다. 메시지 다이제스트 는 텍스트 무결성을 결정하고, 디지털 서명은 보낸 사람 인증을 지원하며, 관련 메커니즘은 나중에 어떤 당사자도 유효한 거래를 거부할 수 없도록 보장하는 데 사용됩니다. 이것들은 모두 원격 트랜잭션의 필수 요소이며 전체 문서를 처리하는 메커니즘은 이제 상당히 잘 개발되었습니다.
일반적인 암호화를 사용하면 전체 XML 문서에 디지털 서명하는 것은 문제가 되지 않습니다. 그러나 문서의 서로 다른 부분에 서명해야 하는 경우(아마도 다른 사람이 서명해야 하는 경우), 선택적 접근 방식과 함께 서명해야 하는 경우에는 어려움이 발생합니다. 특정 사람들이 특정 순서에 따라 여러 부분의 암호화를 수행하도록 강제하는 것은 불가능하거나 가치가 없을 수 있습니다. 그러나 문서의 다른 부분을 성공적으로 처리하는 것은 이를 아는 것에 달려 있습니다. 또한 디지털 서명은 특정 개인 키를 사용하여 인증되었음을 주장하므로 서명자가 문서 항목을 일반 텍스트로 보고 있다는 점에 주의하십시오. 이는 다른 이유로 암호화된 콘텐츠의 일부를 해독한다는 의미일 수 있습니다. 또 다른 경우에는 이미 암호화된 데이터가 더 큰 컬렉션의 일부로 추가로 암호화될 수도 있습니다. 단일 XML 문서(몇 가지 다른 응용 프로그램과 다른 사용자, 웹 양식 또는 워크플로 시퀀스에 사용되는 일련의 데이터에 의해 처리될 수 있음)와 관련된 트랜잭션 세트에서 더 많은 가능성을 고려할수록 더 많은 가능성을 볼 수 있습니다. 엄청난 잠재적 복잡성.
다른 질문도 있습니다. XML 언어의 장점 중 하나는 검색이 명확하다는 것입니다. DTD 또는 스키마는 구문에 대한 정보를 제공합니다. 태그를 포함한 문서의 일부가 전체적으로 암호화되면 해당 태그와 관련된 데이터를 검색할 수 없게 됩니다. 또한 토큰 자체가 암호화된 경우 유출되면 사용된 암호화에 대한 일반 텍스트 공격을 수행하는 데 악용될 수 있습니다.
워킹그룹이 고려하고 있는 부분은 다음과 같습니다.
XML 암호화 예
XML 암호화 구문의 핵심 요소는 EncryptedData 요소입니다. 이 요소는 EncryptedKey 요소와 함께 암호화 키를 개시자로부터 알려진 수신자에게 전송하는 데 사용됩니다. , EncryptedData는 EncryptedType 추상 유형에서 파생됩니다. 암호화할 데이터는 모든 데이터, XML 문서, XML 요소 또는 XML 요소 콘텐츠일 수 있습니다. 데이터 암호화의 결과는 암호화 데이터를 포함하거나 참조하는 XML 암호화 요소입니다. 요소나 요소 콘텐츠가 암호화되면 EncryptedData 요소는 XML 문서의 암호화된 버전에 있는 요소나 콘텐츠를 대체합니다. 임의의 데이터를 암호화할 때 EncryptedData 요소는 새 XML 문서의 루트가 될 수도 있고 하위 요소가 될 수도 있습니다. 전체 XML 문서를 암호화하는 경우 EncryptedData 요소가 새 문서의 루트가 될 수 있습니다. 또한 EncryptedData는 다른 EncryptedData 요소의 상위 또는 하위 요소가 될 수 없지만 실제 암호화된 데이터는 기존 EncryptedData 또는 EncryptedKey 요소를 포함하는 모든 것이 될 수 있습니다.
암호화 작업 초안에서는 요구 사항에 따라 암호화 세분성이 어떻게 달라지는지, 그리고 그 결과는 무엇인지 보여주는 몇 가지 예를 제공합니다. 목록 1의 코드 조각은 신용 카드 및 기타 개인 정보가 포함된 암호화되지 않은 XML 문서를 보여줍니다. 어떤 경우에는(예: 결제 메커니즘 정보 숨기기) 고객 이름을 제외한 모든 정보를 암호화해야 할 수 있으며 목록 2의 코드 조각은 이를 수행하는 방법을 보여줍니다.
목록 1. John Smith의 은행 계좌, $5000 한도, 카드 번호 및 만료 날짜에 대한 정보 표시
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
목록 2. 이름을 제외한 모든 항목이 암호화된 암호화된 문서
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>
</PaymentInfo>그러나 다른 경우에는 판매자나 기타 제3자로부터 숨겨야 하는 일부 민감한 콘텐츠만 있을 수 있습니다. party — 목록 3에서는 이를 보여줍니다. (암호화된 콘텐츠와 관련된 태그 이름이 표시됩니다.)
목록 3. 신용카드 번호만 숨겨진 암호화된 문서
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<CreditCard Limit='5,000' Currency='USD'>
<Number>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue>
</CipherData>
</EncryptedData>
</Number>
<Issuer>Bank of the Internet</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>목록 4에서 볼 수 있듯이 문서의 모든 정보를 암호화해야 할 수도 있습니다.
목록 4. 모든 내용이 숨겨진 암호화된 문서
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
<CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData>
</EncryptedData>CipherData는 캡슐화되거나 원본 암호화 데이터를 참조할 수 있습니다. . 첫 번째 경우 Ciphervalue 요소의 내용은 원시 데이터를 표시하는 반면, 두 번째 경우에는 암호화된 데이터의 위치를 가리키는 URI를 포함하는 CipherReference 요소가 사용됩니다.
规范的 XML
对应用了密码散列算法的消息进行最轻微的更改也会产生不同的值。这为消息完整性方面提供了信任，并适于通常用法，但是也引入了进一步的复杂性 — 两个 XML 文档虽然在逻辑上相等，但可能在确切文本比较中不同。象行定界符、空标记、在属性中使用十六进制而不是名称以及在特定情况下存在注释或注释变体这样的事情都可以成为文档的逻辑结构不受影响而实际彼此不同的实例。规范的 XML 规范描述了一种生成文档的物理表示（也成为范式）的方法，该范式解释允许的变体，以便如果两个文档具有同一范式，则认为两个文档在给定应用程序上下文中是逻辑相等的。
对于加密、特别是数字签名来说，这尤为重要，因为很明显，逻辑上相同的文本变体不应该表示文档的完整性及其发送方的认证是可疑的。用不同工具（譬如，解析器）生成不同文本（并因而生成不同消息摘要）进行处理时也可能发生这样的事。因此，在生成签名和验证计算期间，应该在范式上进行消息摘要。如果摘要匹配，这将确定：即使文本形式可能不同，它们在其上计算的范式也匹配。
XML 签名示例
可以将 XML 签名应用到任意数据内容。那些应用到相同 XML 文档中数据的签名称为封装或被封装的签名，而那些数据在签名元素外部的签名称为 分离签名。清单 5 取自签名候选推荐文档，它是一个简单分离签名的实例。
清单 5. 一个简单分离签名的示例
[s01] <Signature Id="MyFirstSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/
REC-xml-c14n-20010315"/>
[s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#dsa-sha1"/>
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"/>
[s08] </Transforms>
[s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/
xmldsig#sha1"/>
[s10] <Digestvalue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</Digestvalue>
[s11] </Reference>
[s12] </SignedInfo>
[s13] <Signaturevalue>MC0CFFrVLtRlk=</Signaturevalue>
[s14] <KeyInfo>
[s15a] <Keyvalue>
[s15b] <DSAKeyvalue>
[s15c] <p></p><Q></Q><G></G><Y></Y>
[s15d] </DSAKeyvalue>
[s15e] </Keyvalue>
[s16] </KeyInfo>
[s17] </Signature>实际签名的信息是位于 s02 行和 s12 行之间，即 SignedInfo 元素。在签名的部分中包含用于计算 Signaturevalue 元素的算法的引用，而那个元素本身位于签名部分之外（在 s13 行上）。s04 行上的 SignatureMethod 引用的是将规范的 SignedInfo 转换成 Signaturevalue 所用的算法。它是密钥相关的算法和摘要算法（在这里是 DSA 和 SHA-1）的组合，可能还具有象填充这样的操作。KeyInfo 元素（在这里位于 s14 行和 s16 行之间 — 该元素是可选的）指出用来验证签名的密钥。
转换
正如前面所提到的，加密、签名、修改和可能进行的更多签名所发生的顺序有很多种可能性。用户可能需要向已经部分加密或部分签名的表单字段中输入更多数据，并且需要能够在不妨碍以后的验证和解密的前提下这样做。为解决这种情况，W3C 最近发布了一个有关 XML 签名的解密转换工作草案。（请参阅参考资料。）
下面这个示例摘自那个文档，它演示了如何建议文档接收方采用正确的解密和签名验证顺序。第一个代码段显示了要签名的文档部分 — order 元素；其中，第 7 行到第 11 行的 cardinfo 元素是关于个人和财务方面的详细信息，它是纯文本，但也存在一些加密数据（第 12 行）。
清单 6. XML 文档中的 order 元素
[01] <order Id="order">
[02] <item>
[03] <title>XML and Java</title>
[04] <price>100.0</price>
[05] <quantity>1</quantity>
[06] </item>
[07] <cardinfo>
[08] <name>Your Name</name>
[09] <expiration>04/2002</expiration>
[10] <number>5283 8304 6232 0010</number>
[11] </cardinfo>
[12] <EncryptedData Id="enc1"xmlns="http://www.w3.org/
2001/04/xmlenc#"></EncryptedData>
[13] </order>清单 7. 经过签名和进一步加密、且现在显示转换信息的 order 文档
[01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
[02] <SignedInfo>
[03]
[04] <Reference URI="#order">
[05] <Transforms>
[06] <Transform Algorithm="http://www.w3.org/2001/04/
xmlenc#decryption">
[07] <DataReference URI="#enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#"/>
[08] </Transform>
[09] <Transform Algorithm="http://www.w3.org/TR/2000/
CR-xml-c14n-20001026"/>
[10] </Transforms>
[11]
[12] </Reference>
[13] </SignedInfo>
[14] <Signaturevalue></Signaturevalue>
[15] <Object>
[16] <order Id="order">
[17] <item>
[18] <title>XML and Java</title>
[19] <price>100.0</price>
[20] <quantity>1</quantity>
[21] </item>
[22] <EncryptedData Id="enc2"
xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData>
[23] <EncryptedData Id="enc1"
xmlns="http://www.w3.org/2001/04/xmlenc#"></EncryptedData>
[24] </order>
[25] </Object>
[26] </Signature>第 1 行到 第 26 行的 Signature 元素现在包含前面的 order 元素（位于第 16 行到第 24 行），和以前的加密纯文本 cardinfo（显示在第 22 行这一行中）。有两个转换引用：解密（第 6 行到第 8 行）和规范化（第 9 行）。解密转换指示签名验证器解密除 DataRef 元素中第 7 行指定的数据之外的所有加密数据。解密了第 22 行中的 EncryptedData 元素之后，规范化 order 元素并且恰当地验证签名。
其它相关语言和规范
隐藏 XML 文档中的敏感信息、建立完整性以及认证这些文档的不同部分的来源主要通过遵循加密和签名规范中列出的步骤来处理的，在引用的 W3C 草案中描述该规范（请参阅参考资料）。另外，还有其它紧密相关的领域，例如认证用户或系统、标识授权级别和管理密钥，所有这些都与 XML 安全性相关。
SAML 是一个由 OASIS 驱动的模型，它尝试融合相互竞争的 AuthML 和 S2ML 规范，使认证和授权信息的互换便于进行。“可扩展访问控制标记语言”是与 SAML 紧密相关的，但它更着重于特定 XML 文档的上下文中的面向主题特权对象的安全性模型，它也由 OASIS 指导，又是被称为 XACML 或 XACL（即使在同一些文档中）。通过用 XACL 编写规则，策略制订者可以定义，对于特定 XML 文档和前面所述的情况中的相关事情，由谁来实施哪些访问特权。
关于SAML的详细内容,我将在下一篇Blog内讲述.
위 내용은 XML 암호화 및 XML 서명 소개에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
