XML 暗号化と XML 署名の詳細な紹介

はじめに

XML は、インターネット上でデータを交換するための貴重なメカニズムとなっています。 XML メッセージを送信する方法である SOAP により、これまでにない方法でプロセス間の通信が可能になり、UDDI は Web サービスのプロバイダーとユーザーを統合するための標準になりつつあります。サービス自体は WSDL に基づいています。 (つまり、「Web サービス記述言語」の形式で記述されます)。 XML がなければ、この柔軟性と強力な機能は実現できず、多くの人が言っているように、メタ言語を発明する必要があるでしょう。

安全性 性的な分野も急速に成長している分野です。異なるグループ間で信頼を確立する従来の方法は、公共のインターネット、さらには大規模な LAN や WAN ではもはや適切ではありません。このような場合、非対称暗号に基づく信頼メカニズムは非常に役立ちますが、実際には、展開と鍵管理の容易さ、相互運用性の範囲、提供されるセキュリティの点で、さまざまな「公開鍵基盤」よりもはるかに劣ります。インフラストラクチャ (PKI) の熱心なベンダーのおかげで、私たちはそう確信しました。階層的なデータ構造や、機密性、アクセス権、整合性などのさまざまな要件を持つデータのサブセットを扱うのは特に困難です。さらに、今日の XML ドキュメントの標準とは異なるセキュリティ制御を備えたアプリケーションは決して単純ではありません。

現在、いくつかのグループがこれらの問題の調査と標準の開発に積極的に取り組んでいます。主な関連開発は、XML 暗号化と関連する XML 署名、「Extensible Access Control Language (XACL)」および関連する「Security Assertion Markup Language (SAML - 以前の競合製品である AuthML と S2ML の組み合わせ)」です。これらはすべて、OASIS と XML Key Management 仕様 (XKMS) によって推進されます。この記事では、XML 暗号化と XML 署名について説明します。

「XML Security Suite」
その理由の 1 つは、これらの標準がまだ開発段階にあるため、開発者が利用できるツールセットとライブラリの数がまだ限られているためですが、明らかなのは、これが変わり始めているということです。 IBM は、関連する 2 つの「Java 仕様要求 (JSR)」を「Java Community Process (JCP)」に提出しました。それらは、JSR-105「XML デジタル署名 API」と JSR-106「デジタル暗号化 API」です。
「IBM 東京研究所」は、1999 年に XML 署名のプロトタイプ実装として「XML Security Suite」を開発しました。これには、XML デジタル署名の自動生成、W3C の「標準」XML 作業草案の実装、および XML 暗号化の実験的実装による要素レベルの暗号化の提供のためのユーティリティが含まれています。また、XML ドキュメントに適用される場合に、セキュリティ固有の要件を処理する方法も提供します。 Extensible Access Control Language (XACL) の XML スキーマ定義も導入されています。

developerWorks には、スイートについて詳しく説明した Doug Tidwell による記事があり、スイートの最新バージョンは alphaWorks サイトで入手できます。 (「リソース」を参照してください。)
XML 暗号化と XML 署名
他の
ドキュメントと同様に、XML ドキュメント全体を暗号化し、1 人以上の受信者に安全に送信できます。これは、たとえば SSL や TLS の一般的な機能ですが、さらに興味深いのは、同じドキュメントの異なる部分がどのように異なる方法で扱われるかということです。 XML の貴重な利点は、XML 全体を 1 つの操作として送信してローカルに保存できるため、ネットワーク トラフィックが軽減されることです。ただし、これにより、さまざまな要素グループの許可された表示をどのように制御するかという問題が生じます。銀行が商品の購入の詳細を知る必要がないのと同様に、販売者は顧客の名前と住所を知る必要があるかもしれませんが、使用されているクレジット カードの詳細を知る必要はありません。研究者は個人の医療記録の詳細を閲覧できないようにする必要がある一方、管理者はその詳細が必要かもしれないが、病歴を閲覧できないようにする必要があるのに対し、医師や看護師は医療の詳細と一部 (すべてではない) の個人情報が必要な場合があります。材料。

暗号化 は、情報を隠すだけではありません。メッセージ ダイジェスト はテキストの整合性を決定し、デジタル署名は送信者の認証をサポートし、関連するメカニズムは、有効なトランザクションを後で拒否することができないようにするために使用されます。これらはすべてリモート トランザクションに不可欠な要素であり、ドキュメント全体を処理するメカニズムは現在非常によく開発されています。

通常の暗号化では、XML ドキュメント全体にデジタル署名することは問題ありません。ただし、文書のさまざまな部分に (おそらく別の人によって) 署名する必要がある場合、および署名を選択的なアプローチと組み合わせて行う必要がある場合には、問題が発生します。特定の人が特定の順序でさまざまな部分の暗号化を強制的に実行することは不可能であり、その価値はありませんが、ドキュメントのさまざまな部分を適切に処理できるかどうかは、これを知っているかどうかにかかっています。さらに、デジタル署名は特定の秘密キーを使用して認証されたことを主張するため、署名者がドキュメント アイテムをプレーン テキストで表示していることに注意してください。これは、他の理由で暗号化されたコンテンツの部分を復号化することを意味する可能性があります。別のケースでは、すでに暗号化されたデータが、より大きなセットの一部としてさらに暗号化される場合があります。単一の XML ドキュメント (いくつかの異なるアプリケーションや異なるユーザー、Web フォーム、またはワークフロー シーケンスで使用される一連のデータによって処理される可能性があります) に関係するトランザクション セットでさまざまな可能性を考慮するほど、次のようなことが起こる可能性が高くなります。巨大な潜在的な複雑さ。

他にも質問があります。 XML 言語の長所の 1 つは、検索が明確であることです。DTD またはスキーマが構文に関する情報を提供します。タグを含むドキュメントの一部が全体として暗号化されると、それらのタグに関連するデータを検索できなくなります。さらに、トークン自体が暗号化されている場合、漏洩すると、使用されている暗号化に対して平文攻撃を実行するために悪用される可能性があります。

これらは、ワーキンググループが検討している側面の一部です。

XML 暗号化の例
XML 暗号化構文の中心要素は EncryptedData 要素であり、これは開始者から既知の受信者に暗号化キーを送信するために EncryptedKey 要素と一緒に使用されます。 EncryptedData は EncryptedType 抽象型から派生します。暗号化されるデータは、任意のデータ、XML ドキュメント、XML 要素、または XML 要素コンテンツにすることができます。データを暗号化した結果は、暗号化データを含むか参照する XML 暗号化要素になります。要素または要素のコンテンツが暗号化されると、暗号化されたバージョンの XML ドキュメント内の要素またはコンテンツが EncryptedData 要素に置き換えられます。任意のデータを暗号化する場合、EncryptedData 要素が新しい XML ドキュメントのルートになることも、子孫要素になることもあります。 XML ドキュメント全体を暗号化する場合、EncryptedData 要素が新しいドキュメントのルートになる場合があります。さらに、EncryptedData は、別の EncryptedData 要素の親要素または子要素になることはできませんが、実際の暗号化データは、既存の EncryptedData 要素または EncryptedKey 要素を含むものであれば何でもかまいません。

暗号化作業草案では、暗号化の粒度が要件に応じてどのように変化するのか、またその結果がどうなるのかを示すために、いくつかの例が示されています。リスト 1 のコード スニペットは、クレジット カードやその他の個人情報を含む暗号化されていない XML ドキュメントを示しています。場合によっては (支払いメカニズム情報の非表示など)、顧客名を除くすべての情報を暗号化する必要がある場合があります。リスト 2 のコード スニペットは、その方法を示しています。

リスト 1. ジョン・スミスの銀行口座、5000 ドルの限度額、カード番号、有効期限を示す情報

  <PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <CreditCard Limit=&#39;5,000&#39; Currency=&#39;USD&#39;> 
           <Number>4019 2445 0277 5567</Number> 
           <Issuer>Bank of the Internet</Issuer> 
           <Expiration>04/02</Expiration> 
         </CreditCard> 
       </PaymentInfo>

リスト 2. 名前以外のすべてが暗号化された暗号化文書

<PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <EncryptedData Type=&#39;http://www.w3.org/2001/04/xmlenc#Element&#39; 
          xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39;> 
             <CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData> 
         </EncryptedData> 
       </PaymentInfo>

ただし、その他の場合非表示にする必要があるのは、おそらく販売者やその他のサードパーティからの一部の機密コンテンツのみである可能性があります。リスト 3 はこれを示しています。 (暗号化されたコンテンツに関連するタグ名が表示されることに注意してください。)

リスト 3. クレジット カード番号のみが非表示になっている暗号化された文書

  <PaymentInfo xmlns=&#39;http://example.org/paymentv2&#39;> 
         <Name>John Smith<Name/> 
         <CreditCard Limit=&#39;5,000&#39; Currency=&#39;USD&#39;> 
           <Number> 
             <EncryptedData xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39; 
              Type=&#39;http://www.w3.org/2001/04/xmlenc#Content&#39;> 
                 <CipherData><Ciphervalue>A23B45C56</Ciphervalue> 
                 </CipherData> 
             </EncryptedData> 
           </Number> 
           <Issuer>Bank of the Internet</Issuer> 
           <Expiration>04/02</Expiration> 
         </CreditCard> 
       </PaymentInfo>

文書内のすべての情報を暗号化する必要がある場合もあります。リスト 4 はこれを示しています。

リスト 4. すべての内容を隠す暗号化されたドキュメント

 <EncryptedData xmlns=&#39;http://www.w3.org/2001/04/xmlenc#&#39; 
        Type=&#39;http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml&#39;> 
                <CipherData><Ciphervalue>A23B45C56</Ciphervalue></CipherData> 
       </EncryptedData>

CipherData は、元の暗号化データをカプセル化または参照できます。最初のケースでは、Ciphervalue 要素のコンテンツに生データが表示されますが、2 番目のケースでは、暗号化されたデータの場所を指す 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 中国語 Web サイトの他の関連記事を参照してください。