XML Encryption and Signature

1. XML Cryptography Modules
2. Common characteristics
3. XML Signatures
4. Sign and Check Signature
5. Signature in XML
6. Adding Key Information
7. Transformations Possibilities
8. Example using XPath
9. Adding Information to Signature
10. Encryption
11. Encryption and Decryption
12. Encryption in XML
13. Encrypting the (Sub)tree
14. Encrypting Character Content
15. Encryption Data Stored Elsewhere
16. Transforms in Encryptions
17. Key management
18. Key management (cont)
19. X-KISS + X-KRSS = XKMS
20. Some X-KISS Usage Scenarios

XML Cryptography Modules

• Necessary to build a “web of trust”
  • needed for the deployment of Web Services, Semantic Web, etc
• Main documents from W3C:
  • XML Signature (Recommendation since February 2002)
  • XML Encryption (Recommendation since December 2002)
  • Key Management (Recommendation since June 2005)
  • some extra, technical documents
    • XML Canonicalization, XPath transforms
    • necessary to get Signature and Encryption working
  • but the “essence” is in the three above

Common characteristics

• W3C is not in the business of cryptographic algorithms
• It defines how to use them with XML
• Non-XML data can also be managed (entities, URI-s)
• Joint activities with IETF

XML Signatures

• An XML Syntax for the creation of digital signatures
• An XML Signature can sign:
  • (part of the) same XML document which contains the signature (“enveloped”)
  • another (XML) document, referenced through an URI (“detached”)

Sign and Check Signature

Signature in XML

Adding Key Information

<Signature Id="..."> 

  <SignedInfo>

    ... 

  </SignedInfo> 

  <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>

  <KeyInfo>

    <KeyValue>

      <PGPData>

        <PGPKeyID>FGHJ</PGPKeyID>

        <PGPKeyPacket>BKJHasdfJKN</PGPKeyPacket>

      </PGPData> 

    </KeyValue> 

  </KeyInfo>

</Signature>

The example is for PGP; there are variants for DSA, RSA, …

Transformations Possibilities

• Canonicalization
  • making the XML textual representation unambigous (a necessary step!)
  • subject of separate recommendations
• Base64
  • used to include binary data in textual format
• XSLT
  • a full XSLT transform on the XML source
• XPath
  • filter out parts of the documents for signature
• Others may be added

Example using XPath

For example, an enveloped signature on the rest of the document:

  <Document id="Full">

    <Signature xmlns:dsig="...">

      <SignedInfo>

        <Reference Id="#Full">

          <Transform Algorithm="..">

            <XPath>not(ancestor-or-self::dsig:Signature)</XPath>

          </Transform>

        </Reference>

        ...

      </SignedInfo>

    </Signature>

    ...

  </Document>

Adding Information to Signature

• For example: timestamp (using Reference means that the timestamp is also signed!)

<Signature Id="MySignature" ...>

  <SignedInfo> 

    <Reference URI="something">...</Reference>

    <Reference URI="#MyTimeStamp" 

       Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">

    ...

    </Reference> 

  </SignedInfo>

  ...  

  <Object> 

    <SignatureProperties>

     <SignatureProperty Id="MyTimeStamp" Target="#MySignature">

       <t:timestamp xmlns:t="http://www.ietf.org/rfcXXXX.txt">

         <t:date>19990908</t:date> 

         <t:time>14:34:34:34</t:time>

       </t:timestamp>

     </SignatureProperty>

   </SignatureProperties>

  </Object>

</Signature>

Encryption

• Goal is to encrypt:
  • a full XML tree rooted at an element;
  • the content of an element; or
  • only character data of an element
• The encrypted data replaces the original content

Encryption and Decryption

Encryption in XML

Encrypting the (Sub)tree

 <PaymentInfo>

    <Name>Ivan Herman</Name>

    <CreditCard>

       <Name>VISA</Name>

       <Number>4567 8901 2345 5678</Number>

       <Expiration>01 01</Expiration>

    </CreditCard>

 </PaymentInfo>

Can be encrypted as follows:

 <PaymentInfo>

    <Name>Ivan Herman</Name>

    <EncryptedData Type="http://www.w3.org/…/xmlenc#Element"

        xmnls="http://www.w3.org/2001/04/xmlenc#">

       <CipherData><CipherValue>QEK^SD27</CipherValue></CipherData>

    </EncryptedData>

 </PaymentInfo>

An eavesdropper doesn’t knows about any Credit Card!

Encrypting Character Content

 <PaymentInfo>

    <Name>Ivan Herman</Name>

    <CreditCard>

       <Name>VISA</Name>

       <Number>4567 8901 2345 5678</Number>

       <Expiration>01 01</Expiration>

    </CreditCard>

 </PaymentInfo>

Can be encrypted as:

 <PaymentInfo>

    <Name>Ivan Herman</Name>

    <CreditCard>

       <Name>VISA</Name>

       <Number>

          <EncryptedData Type="http://www.w3.org/…/xmlenc#Content"

              xmnls="http://www.w3.org/2001/04/xmlenc#">

             <CipherData>

                <CipherValue>QEK^SD27</CipherValue>

             </CipherData>

          </EncryptedData>

       </Number>

       <Expiration>01 01</Expiration>

    </CreditCard>

 </PaymentInfo>

Encryption Data Stored Elsewhere

<CipherData>

    <CipherValue>QEK^SD27</CipherValue>

 </CipherData>

can be replaced by:

 <CipherData>

    <CipherReference URI="....">

       <Transforms>

          ...

       </Transforms>

   </CipherReference>

 </CipherData>

Transforms in Encryptions

• “Transforms” refer to similar possibilities as in Signature
• But the semantics are different!
  • in signature, they are applied on the data to be signed
  • in encryption, they are applied to the referenced data
    • used to locate the encryption data
    • eg, Cyphers.xml contains several encryptions, take the third:

   <CipherData>

      <CipherReference URI="http://.../Cyphers.xml">

         <Transforms>

            <ds:Transform xmlns:r="…">

               <ds:XPath>self::text()[//r:CypherValue[3]]</ds:XPath>

            </ds:Transform>

            ...

         </Transforms>

     </CipherReference>

   </CipherData>

Key management

• Key information is very complex:
  • keys should be “managed” (registered, revoked, etc)
  • often done by public or private service providers
  • complex “trust policy” must be established
• XML Sig/Enc includes information about a key, but…
  • it is not obligatory
  • it is not clear whether the key can be trusted
• The client may use X-KISS (XML Key Information Service Specification)
  • client is relieved from the complexity of key checking

Key management (cont)

• To use X-KISS, keys must be properly managed
• This means, one should be able to:
  • register a key (store information bound to a key pair)
  • revoke a key
  • reissue a key (eg, if previously revoked)
  • recover a private key
• X-KRSS (XML Key Registration Service Specification) defines a protocol to do that

X-KISS + X-KRSS = XKMS

• X-KISS and X-KRSS are both defined in XKMS
  • XML Key Management Specification
  • W3C Recommendation since June 2005
• A separate document (XML Key Management Specification Bindings) provides a mapping to SOAP1.2 and 1.1
  • XKMS is in XML, so this is easy…
  • …but the correct fault codes must be defined
• A separate document (XKMS Part 2) provides a mapping

  to SOAP1.2 and 1.1

  • XKMS is in XML, so this is easy…
  • …but the correct fault codes must be defined

Some X-KISS Usage Scenarios

• Extracting key info
  • Alice does not know Bob’s key, but via X-KISS she can retrieve the key
    • in X-KISS she can specify which format she can handle
  • encrypts and sends the encrypted messsage to Bob
• Extending KeyInfo
  • Alice signs a document and sends it to Bob, but she sends only minimal data on the key
  • Bob retrieves the additional info for validation and sends to Carol who can check everything
• Document signature
  • Bob receives Alice’s signed message
  • Bob’s client can chek the signature, but does not know if the key info corresponds to Alice’s id
  • Bob can check this through X-KISS