??ࡱ?>?? ???????m??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????t?(`?@?  2 ?X??Dhttp://www.w3.org/TR/xmldsig-core/?Z??Fhttp://www.ietf.org/rfc/rfc3275.txt?Z??Fhttp://www.w3.org/TR/xml-c14n#UTF-8?l??Xhttp://www.abccompany.com/xml/po.xml#sender1?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?b??Nhttp://www.w3.org/Encryption/2001/#Code? /? 0???DTimes New Romany't?\?d? 0t? & 0 ?DSymbolew Romany't?\?d? 0t? & 0  ?DMonotype Sortsy't?\?d? 0t? & 00?DVerdana Sortsy't?\?d? 0t? & 0 "@?DCourier Sortsy't?\?d? 0t? & 0P?DCourier Newtsy't?\?d? 0t? & 0 1`?DArial Unicode MS't?\?d? 0t? & 0??f???? ? .??@  @@``???  @?n???" dd@?????????  @@``?? ??X$??"*&3?2     .  !"S ?~??????????1???????????0? ??????n?@???8?????-?g??48d8dd? 0h?????????p?pp?0 ? <?4BdBd???@ 0$??u?ʚ;2N??ʚ;<?4!d!d???= 0??<?4dddd???= 0???????___PPT9??/? 0?z?\?Y??m??????r?-?:February 21, 2003. Amsterdam. ?Donkey ProjectO? ?=??a???XML Security in IODEF?$(??BINCH WG, IETF56 March 19, 2003 Yuri Demchenko ?"C$"?$ ??g??Outlines???XML Security Basics XML Signature XML Canonicalisation (reference) XML Encryption DonKey project at NLnet Labs: PK Management and XMLSig ?????^??#XML: Schema vs DTD and XML Protocol???DTD is document-oriented Like HTML Schema is data-oriented XML Signature SAML Basic XML Protocol(s) XML-RPC SOAP BEEP (by IETF)?t   ??W??.XML Security vs traditional (network) security???Traditional Security: Host-to-host or point-to-point security Client/server oriented Connection or connectionless oriented Generically single/common trust domain/association XML Security Document oriented approach Security tokens/assertions, policies can be associated with the document or its parts Intended to be cross-domain Potentially for virtual and dynamic trust domains (security associations)?t?Vf?Vf??V??XML Signature: Features??DFundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document. XML document may have a long history when different component are authored by different parties at different times Different parties may want to sign only those elements relevant to them Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed Allows carrying security tokens/assertions on document/data rather than on user/client Provides security features for XML based protocols ?6p?p???X??XML Signature structure???? ? ? (? ()?? ? ? )+? ? ()?? ()*? ??$?Z?%??? /   $??Y??How to Create an XML Signature ?  ??$W3C REC: http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://www.ietf.org/rfc/rfc3275.txt 1. Determine which resources are to be signed 2. Calculate the digest of each resource 3. Collect the Reference elements 4. Signing 5. Add key information 6. Enclose in a Signature element ?h%?" eD?yF? f?9F?B?^   ???m 0? +??m 0?Ad??Z??+Determine which resources are to be signed ?,* ???Resources are defined through a Uniform Resource Identifier (URI) http://www.abccompany.com/xml/po.xml#sender1 - references a specific element in an XML file on the Web reference document with attached signature ?>B?B$?h* ??m 0?Bn??[??%Calculate the digest of each resource?&& ??In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element. The element identifies the algorithm used to calculate the digest. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??C$? e3f?K$? e3f? $? e3f?$? e3f?? ?%3f????  ^  &  ??\??Collect the Reference elements ?  ??bCollect the elements (with their associated digests) within a element. The element indicates the algorithm was used to canonize the element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??cZ &? g3f?3&? g3f?&?g3f?:&? g3f??&?g3f?G&??'3f??:K < ?I 7&&  &   ??]??Signing ? ???Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element. Signature Algorithms DSA PKCS1 (RSA-SHA1) <SignatureValue>MC0E& LE=</SignatureValue> ???. e3f?< e3f?!  '3f?*'3f?" ?P >: ??_??Add key information ? ??If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, C=CA MIID5jCCA0+gA...lVN ??Z7 e3f?? r???'3f??'3f??8?       36"??`??Enclose in a Signature element ?  ??? Place the , , and elements into a element. The element comprises the XML signature. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be referenced by a URI within the XML signature; reside within the same resource as the XML signature (the signature is a sibling); be embedded within the XML signature (the signature is the parent); have its XML signature embedded within itself (the signature is the child). ??D&??&?K&?? &? g3f?&?g3f?&? g3f?&? g3f?&? g3f??&???   8??d??Verifying an XML Signature? ??Verify the signature of the element Recalculate the digest of the element (using the digest algorithm specified in the element) Use the public verification key to verify that the value of the element is correct for the digest of the element If this step passes Recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element. ?\1 ?$? e3f? $?$? e3f?6$?e3f?K$?e3f?*$? e3f? $? ?  e3f?A  e3f?  e3f?  ?? ) 8M, ` g  ??b??Canonicalisation (1) ? ???The canonical form of an XML document is physical representation of the document produced by the canonicalisation method that implies the following changes. Encoding and characters The document is encoded in UTF-8 Line breaks normalized to #xA on input, before parsing Whitespace outside of the document element and within start and end tags is normalized All whitespace in character content is retained (excluding characters removed during line feed normalization)?t?$?$??$?"??N? P `??m 0?????c??Canonicalisation (2)? ???Elements and references Character and parsed entity references are replaced CDATA sections are replaced with their character content The XML declaration and document type declaration (DTD) are removed Empty elements are converted to start-end tag pairs Attributes Attribute values are normalized, as if by a validating processor Attribute value delimiters are set to quotation marks (double quotes) Special characters in attribute values and character content are replaced by character references Superfluous namespace declarations are removed from each element Default attributes are added to each element Lexicographic order is imposed on the namespace declarations and attributes of each element??Z?Z Z?ZqG ,s??e??&XPath Data Model for Canonicalisation ???XML canonicalization is defined in terms of the XPath definition of a node-set. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order: normalize line feeds normalize attribute values replace CDATA sections with their character content resolve character and parsed entity references The input octet stream MUST contain a well-formed XML document, but the input need not be validated. The declarations in the document type declaration are used to help create the canonical form.?61??1????f??Transform Algorithms??XCanonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation?YY??h??%XML Signature: Security Consideration??>Transforms Only What is Signed is Secure Only What is  Seen is Secure  See What is Signed Check the Security Model Algorithms, Key Length, Certificates, etc.?< QD QD??i??XML Encryption??Encrypt an XML Element, XML Element s content (Elements), XML Element s content (Character Data), or arbitrary data ad documents Can be used for Key transport Can be used in combination with XML Signature More information http://www.w3c.org/TR/xmlenc-core/ http://?&?=?=??k??6XML Encryption  Data Model??? ? ? # extension to XMLSig KeyInfo ? ? ? ? # ? # envelopes or references the raw encrypted data ? ? # points to the location of the raw encrypted data ? # e.g., timestamp ?"?Z???      9 >  ??l??"XML Encryption: CipherData Element?$# ? ???Contains the encrypted octet sequence as base64 encoded text of the CipherValue element, or provides a reference to an external location containing the encrypted octet sequence via the CipherReference element. ?????C i   ( ??j??Encryption: Processing Rules??xFor each EncryptedData and EncryptedKey the encryptor must : 1. Select the algorithm (and parameters) 2. Obtain and (optionally) represent the key 3. Encrypt the data If the data is an  element or element  content , obtain the octets by serialising the data in UTF-8; any other data must be serialised as octets Encrypt the octets using the algorithm and key from steps 1 and 2 Provide type of presentation to indicate how to obtain and interpret the plaintext octets after decryption (e.g., MimeType= text/xml or MimeType= image/png ) 4. Build the EncryptedType (EncryptedData or EncryptedKey) 5. Process EncryptedData If the Type of the encrypted data is  element or element  content , then encryptor SHOULD be able to replace the unencrypted  element or  content with the EncryptedData element. If the Type of the encrypted data is  element or element  content , then encryptor MUST always be able to return the EncryptedData to the application. ?$=ZjZsZUZNZ    js ?    v  "    ??  ?   ? ??m??Decryption: Processing Rules???1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it. 2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. 3. Decrypt the data contained in the CipherData element  depending on existence of CipherValue or CipherReference child elements 4. Process decrypted data of Type 'element' or element 'content The cleartext octet sequence (from step 3) is interpreted as UTF-8 encoded character data The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. Validation on the serialized XML is NOT REQUIRED. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted 'element' or element 'content' represented by the UTF-8 encoded characters 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'.????[B 9 D ;% % -  P %a + g!?.A?_ $ 3 P ? *j?? m 0????? m 0?????m 0?+2??m 0?@G??m 0?????m 0?????n??Available tools???Not many OpenSource, especially for Windows Java based Refer to http://www.w3.org/Signature/#Code http://www.w3.org/Encryption/2001/#Code Commercial MS Visual Studio IBM AlphaWorks Coming soon - DonKey client by NLnet Labs??,J  *,J    *  ?< P'" *??m 0?c??G:??DonKey Project Goal(s)?? ??UOpen extendable system for public key and Identity management Initial stage Open global distributed system for publishing and retrieving named, signed public keys together with associated/bound information Intended development Identity management for federated cross-domain AuthN and AuthZ Donkey website: http://www.nlnetlabs.nl/donkey/?RV@""?"p?i;??DonKey functionality??^DonKey allows anyone to publish a named key, together with optional data (Donkey package) Key MUST be signed, and Package MAY be signed by Owner Donkey is NOT a permanent storage: key must be republished to remain available Donkey does NOT define a policy for key/payload usage This is an application specific function Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match Donkey allows anyone to query for a published key, based on the key's name (required) and signers (optional) Donkey allows anyone to sign a published key ??Z?)??Z?)??  ??U??'DonKey design issues: Package structure??(Proprietary) Internal format (currently: Python data object) but XML based exchange format Package ID Content Header Flags Names Owner Public Key # Name, Owner Key> must be unique Body Payload # Application dependent (e.g., AA, Identity, SSO) Signatures Signed??\ 9;\ 9  ;/?? P?????T? `? ????????f??????`? ???3?????????????`? ???___?????????????>???" dd=??????????????" dd?=?????????????uA?4? d?O?" ?i ?n???" dd??????????   @@``P?P   4 O i`? p?@??@    ? ?)? ?( ? ??p ? ? ?H??????d???? ?'W??? ? ? ?Z?Ȭ'?a????a?????????? ??x8???? ' ?T?? Click to edit Master title style?!? !?: ? ? ?T?`?'?a????a????????? ??Sg??? ' ???RClick to edit Master text styles Second Level Third Level Fourth Level Fifth Level?!    ? S?  ?  ?`?(?'?a????a??????????? ?? ????? ' ?b???*? ???=44OOii?  ?   ?`?@?'?a????a??????????? ?? `???  ' ?b??*? ???=44OOii?& ?!  ?`???'?a????a??????????? ??!????? ' ?~??Slide2_*?(  ???=44OOii?Z?F ?1?lY ?$ ??~???~ ?" ? ?N?????????2?????1?l$?~ ?# ? ?N?????????2?????1IlY??F ??? ?) ???c?8 ?% s ?B?C{DE?8F?@??????????????????@????????F??h??=?Zhz?zFz?\F3? @???????????????????0 ?& s ?B?C?DE?4F?<??????????????????@????? ????i??<?????<??#i?????@???????????????g?5?0 ?' s ?B-C?DE?4F?<??????????????????@????? ??o?????*l??,J??????Jz?o@???????????????Arn*? ?( ? ??BKCoDE?4F?<?????????? ??(%+(J27JQ+E%nEQ7@???????????????????H ? ? ?0??@??޽h??? ?? ??????????f?????? ?International?? ? ??@?% ?E?( ??4p? ~?p? ? ?^ ? ? ?6??????? ?@_??p ? ? ?H??????d???? ??_??? ? ? ?Z?H??a????a?????????? ???????? ? ?T?? Click to edit Master title style?!? !?? ? ? ?Z????a????a?????????? ??HZjG ?? ? ?W??#Click to edit Master subtitle style?$? $? ?  ?`??#??a????a??????????? ???????? ? ?\??*????=44OOii? ?  ?`?`?'?a????a??????????? ???S ???  ? ?^??*????=44OOii? ?  ?`??7??a????a??????????? ???????? ? ?n??Slide 2_*?  ???=44OOii?H ? ? ?0??@??޽h??? ?? ??????????f?????????? 0 ??`??*?( ? ?? ? ? ?T?웾?jJ??jJ??????? ???? t1??  ? ?h??*? ?? ? ??? ? ? ?T?p???jJ??jJ??????? ????? 41?? ? ?j??*? ?? ? ???p ? ? ?0?????1? ???r?L ?? ??: ? ? ?T?l????g?ֳ??g?ֳ?????? ??? c??? ? ???RClick to edit Master text styles Second level Third level Fourth level Fifth level?!    ? S?  ? ? ?Z?ܷ??jJ??jJ???????? ??? t???  ? ?h??*? ?? ? ???  ? ? ?Z?0???jJ??jJ???????? ???? 4??? ? ?j??*? ?? ? ???H ? ? ?0??.k?9???? ?? ??????̙33????????? ??p??0?( ? ??H ? ? ?0???.k?9??? ?? ??????̙33??????????? 0?(0????( ? ??? ? # ?l?????g????g????????????? ? ??x$?? ? ? ??? ? # ?l??@??g????g????????????? ? ?H????? ? ? ??H ? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????$?( ? ??r ? S ???????x8????  ? ? ??r ? S ???????Sg??? ? ? ??H ? ? ?0???@??޽h?? ?? ??????????f????????? ? ??? ???$?( ? ???r ?? S ???????x8????  ? ? ??r ?? S ???????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ???????$?( ? ???r ?? S ??H????x8????  ? ? ??r ?? S ???????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ???????$?( ? ???r ?? S ??(????x8????  ? ? ??r ?? S ???????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????0?( ? ???x ?? c ?$?|??????x8????  ? ? ??x ?? c ?$?$??????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????0?( ? ???x ?? c ?$??????x8????  ? ? ??x ?? c ?$?\?????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????0?( ? ???x ?? c ?$???????x8????  ? ? ??x ?? c ?$?T?????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????0?( ? ???x ?? c ?$?H?????x8????  ? ? ??x ?? c ?$?D?????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????0?( ? ???x ?? c ?$?X3'????x8????  ' ? ??x ?? c ?$?4'????Sg??? ' ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ?????0?( ? ???x ?? c ?$?87?????x8????  ? ? ??x ?? c ?$??7?????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??????$?( ? ???r ?? S ??<?"C$"?$ ??g??Outlines???XML Security Basics XML Signature XML Canonicalisation (reference) XML Encryption DonKey project at NLnet Labs: PK Management and XMLSig ?????^??#XML: Schema vs DTD and XML Protocol??rDTD is document-oriented Like HTML Schema is data-oriented XML Signature SAML Basic XML Protocol(s) XML-RPC SOAP?t    ??W??.XML Security vs traditional (network) security???Traditional Security: Host-to-host or point-to-point security Client/server oriented Connection or connectionless oriented Generically single/common trust domain/association XML Security Document oriented approach Security tokens/assertions and policies can be associated with the document or its parts Intended to be cross-domain Potentially for virtual and dynamic trust domains (security associations)?t?Yf?Yf??V??XML Signature: Features??DFundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document. XML document may have a long history when different component are authored by different parties at different times Different parties may want to sign only those elements relevant to them Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed Allows carrying security tokens/assertions on document/data rather than on user/client Provides security features for XML based protocols ?6p?p???X??XML Signature structure???? ? ? (? ()?? ? ? )+? ? ()?? ()*? ??$?Z?%??? /   $??Y??How to Create an XML Signature ?  ??$W3C REC: http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://www.ietf.org/rfc/rfc3275.txt 1. Determine which resources are to be signed 2. Calculate the digest of each resource 3. Collect the Reference elements 4. Signing 5. Add key information 6. Enclose in a Signature element ?h%?" eD?yF? f?9F?B?L  ???m 0? +??m 0?Ad??Z??+Determine which resources are to be signed ?,* ???Resources are defined through a Uniform Resource Identifier (URI) http://www.abccompany.com/xml/po.xml#sender1 - references a specific element in an XML file on the Web reference document with attached signature ?>B?B$?h* ??m 0?Bn??[??%Calculate the digest of each resource?&& ??In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element. The element identifies   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdef?hijkl????????opqrstuvwxyz{|}~????????????????????????????????????????????????????????????????????????????n????????g???????????????????????????????????????????????????????Root Entry??????????d?O?????)??rc????Current User????????????UJSummaryInformation(????????l PowerPoint Document(????SDocumentSummaryInformation8????????????&? ???????????????????????????????????? 2 ?X??Dhttp://www.w3.org/TR/xmldsig-core/?Z??Fhttp://www.ietf.org/rfc/rfc3275.txt?Z??Fhttp://www.w3.org/TR/xml-c14n#UTF-8?l??Xhttp://www.abccompany.com/xml/po.xml#sender1?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?b??Nhttp://www.w3.org/Encryption/2001/#Code? /? 0???DTimes New Romany'????d? 0?? & 0 ?DSymbolew Romany'????d? 0?? & 0  ?DMonotype Sortsy'????d? 0?? & 00?DVerdana Sortsy'????d? 0?? & 0 "@?DCourier Sortsy'????d? 0?? & 0P?DCourier Newtsy'????d? 0?? & 0 1`?DArial Unicode MS'????d? 0?? & 0??f???? ? .??@  @@``???  @?n???" dd@?????????  @@``?? ??X$??"*&3?2     .  !"S ?~??????????1???????????0? ??????n?@???8?????-?g??4;d;dd? 0?????????p?pp?0 ? <?4BdBd???@ 0`??u?ʚ;2N??ʚ;<?4!d!d???= 0??<?4dddd???= 0???????___PPT9??/? 0?z?\?Y??m??????r?-?:February 21, 2003. Amsterdam. ?Donkey ProjectO? ?=??a???XML Security in IODEF?$(??BINCH WG, IETF56 March 19, 2003 Yuri Demchenko ?"C$"?$ ??g??Outlines???XML Security Basics XML Signature XML Canonicalisation (reference) XML Encryption DonKey project at NLnet Labs: PK Management and XMLSig ?????^??#XML: Schema vs DTD and XML Protocol??rDTD is document-oriented Like HTML Schema is data-oriented XML Signature SAML Basic XML Protocol(s) XML-RPC SOAP?t    ??W??.XML Security vs traditional (network) security???Traditional Security: Host-to-host or point-to-point security Client/server oriented Connection or connectionless oriented Generically single/common trust domain/association XML Security Document oriented approach Security tokens/assertions and policies can be associated with the document or its parts Intended to be cross-domain Potentially for virtual and dynamic trust domains (security associations)?t?Yf?Yf??V??XML Signature: Features??DFundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document. XML document may have a long history when different component are authored by different parties at different times Different parties may want to sign only those elements relevant to them Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed Allows carrying security tokens/assertions on document/data rather than on user/client Provides security features for XML based protocols ?6p?p???X??XML Signature structure???? ? ? (? ()?? ? ? )+? ? ()?? ()*? ??$?Z?%??? /   $??Y??How to Create an XML Signature ?  ??$W3C REC: http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://www.ietf.org/rfc/rfc3275.txt 1. Determine which resources are to be signed 2. Calculate the digest of each resource 3. Collect the Reference elements 4. Signing 5. Add key information 6. Enclose in a Signature element ?h%?" eD?yF? f?9F?B?^   ???m 0? +??m 0?Ad??Z??+Determine which resources are to be signed ?,* ???Resources are defined through a Uniform Resource Identifier (URI) http://www.abccompany.com/xml/po.xml#sender1 - references a specific element in an XML file on the Web reference document with attached signature ?>B?B$?h* ??m 0?Bn??[??%Calculate the digest of each resource?&& ??In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element. The element identifies the algorithm used to calculate the digest. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??C$? e3f?K$? e3f? $? e3f?$? e3f?? ?%3f????  ^  &  ??\??Collect the Reference elements ?  ??bCollect the elements (with their associated digests) within a element. The element indicates the algorithm was used to canonize the element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??cZ &? g3f?3&? g3f?&?g3f?:&? g3f??&?g3f?G&??'3f??:K < ?I 7&&  &   ??]??Signing ? ???Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element. Signature Algorithms DSA PKCS1 (RSA-SHA1) <SignatureValue>MC0E& LE=</SignatureValue> ???. e3f?< e3f?!  '3f?*'3f?" ?P >: ??_??Add key information ? ??If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, C=CA MIID5jCCA0+gA...lVN ??Z7 e3f?? r???'3f??'3f??8?       36"??`??Enclose in a Signature element ?  ??? Place the , , and elements into a element. The element comprises the XML signature. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be referenced by a URI within the XML signature; reside within the same resource as the XML signature (the signature is a sibling); be embedded within the XML signature (the signature is the parent); have its XML signature embedded within itself (the signature is the child). ??D&??&?K&?? &? g3f?&?g3f?&? g3f?&? g3f?&? g3f??&???   8??d??Verifying an XML Signature? ??Verify the signature of the element Recalculate the digest of the element (using the digest algorithm specified in the element) Use the public verification key to verify that the value of the element is correct for the digest of the element If this step passes Recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element. ?\1 ?$? e3f? $?$? e3f?6$?e3f?K$?e3f?*$? e3f? $? ?  e3f?A  e3f?  e3f?  ?? ) 8M, ` g  ??b??Canonicalisation (1) ? ???The canonical form of an XML document is physical representation of the document produced by the canonicalisation method that implies the following changes. Encoding and characters The document is encoded in UTF-8 Line breaks normalized to #xA on input, before parsing Whitespace outside of the document element and within start and end tags is normalized All whitespace in character content is retained (excluding characters removed during line feed normalization)?t?$?$??$?"??N? P `??m 0?????c??Canonicalisation (2)? ???Elements and references Character and parsed entity references are replaced CDATA sections are replaced with their character content The XML declaration and document type declaration (DTD) are removed Empty elements are converted to start-end tag pairs Attributes Attribute values are normalized, as if by a validating processor Attribute value delimiters are set to quotation marks (double quotes) Special characters in attribute values and character content are replaced by character references Superfluous namespace declarations are removed from each element Default attributes are added to each element Lexicographic order is imposed on the namespace declarations and attributes of each element??Z?Z Z?ZqG ,s??e??&XPath Data Model for Canonicalisation ???XML canonicalization is defined in terms of the XPath definition of a node-set. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order: normalize line feeds normalize attribute values replace CDATA sections with their character content resolve character and parsed entity references The input octet stream MUST contain a well-formed XML document, but the input need not be validated. The declarations in the document type declaration are used to help create the canonical form.?62??2????f??Transform Algorithms??XCanonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation?YY??h??%XML Signature: Security Consideration??>Transforms Only What is Signed is Secure Only What is  Seen is Secure  See What is Signed Check the Security Model Algorithms, Key Length, Certificates, etc.?< QD QD??i??XML Encryption??Encrypt an XML Element, XML Element s content (Elements), XML Element s content (Character Data), or arbitrary data ad documents Can be used for Key transport Can be used in combination with XML Signature More information http://www.w3c.org/TR/xmlenc-core/ http://?&?=?=??k??6XML Encryption  Data Model??? ? ? # extension to XMLSig KeyInfo ? ? ? ? # ? # envelopes or references the raw encrypted data ? ? # points to the location of the raw encrypted data ? # e.g., timestamp ?"?Z???      9 >  ??l??"XML Encryption: CipherData Element?$# ? ???Contains the encrypted octet sequence as base64 encoded text of the CipherValue element, or provides a reference to an external location containing the encrypted octet sequence via the CipherReference element. ?????C i   ( ??j??Encryption: Processing Rules??xFor each EncryptedData and EncryptedKey the encryptor must : 1. Select the algorithm (and parameters) 2. Obtain and (optionally) represent the key 3. Encrypt the data If the data is an  element or element  content , obtain the octets by serialising the data in UTF-8; any other data must be serialised as octets Encrypt the octets using the algorithm and key from steps 1 and 2 Provide type of presentation to indicate how to obtain and interpret the plaintext octets after decryption (e.g., MimeType= text/xml or MimeType= image/png ) 4. Build the EncryptedType (EncryptedData or EncryptedKey) 5. Process EncryptedData If the Type of the encrypted data is  element or element  content , then encryptor SHOULD be able to replace the unencrypted  element or  content with the EncryptedData element. If the Type of the encrypted data is  element or element  content , then encryptor MUST always be able to return the EncryptedData to the application. ?$=ZjZsZUZNZ    js ?    v  "    ??  ?   ? ??m??Decryption: Processing Rules???1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it. 2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. 3. Decrypt the data contained in the CipherData element  depending on existence of CipherValue or CipherReference child elements 4. Process decrypted data of Type 'element' or element 'content The cleartext octet sequence (from step 3) is interpreted as UTF-8 encoded character data The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. Validation on the serialized XML is NOT REQUIRED. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted 'element' or element 'content' represented by the UTF-8 encoded characters 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'.????[B 9 D ;% % -  P %a + g!?.A?_ $ 3 P ? *j?? m 0????? m 0?????m 0?+2??m 0?@G??m 0?????m 0?????n??Available tools???Not many OpenSource, especially for Windows Java based Refer to http://www.w3.org/Signature/#Code http://www.w3.org/Encryption/2001/#Code Commercial MS Visual Studio IBM AlphaWorks Coming soon - DonKey client by NLnet Labs??,J  *,J    *  ?< P'" *??m 0?c??G:??DonKey Project Goal(s)?? ??UOpen extendable system for public key and Identity management Initial stage Open global distributed system for publishing and retrieving named, signed public keys together with associated/bound information Intended development Identity management for federated cross-domain AuthN and AuthZ Donkey website: http://www.nlnetlabs.nl/donkey/?RV@""?"p?i;??DonKey functionality??^DonKey allows anyone to publish a named key, together with optional data (Donkey package) Key MUST be signed, and Package MAY be signed by Owner Donkey is NOT a permanent storage: key must be republished to remain available Donkey does NOT define a policy for key/payload usage This is an application specific function Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match Donkey allows anyone to query for a published key, based on the key's name (required) and signers (optional) Donkey allows anyone to sign a published key ??Z?)??Z?)??  ??U??'DonKey design issues: Package structure??(Proprietary) Internal format (currently: Python data object) but XML based exchange format Package ID Content Header Flags Names Owner Public Key # Name, Owner Key> must be unique Body Payload # Application dependent (e.g., AA, Identity, SSO) Signatures Signed??\ 9;\ 9  ;/?? P??????? ? ??? ???$?( ? ???r ?? S ???????x8????  ? ? ??r ?? S ???????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ???????$?( ? ???r ?? S ??H????x8????  ? ? ??r ?? S ???????Sg??? ? ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ???@???$?( ? ???r ?? S ??'???x8????  ' ? ??r ?? S ???'???Sg??? ' ? ??H ?? ? ?0???@??޽h?? ?? ??????????f????????? ? ??`???:?( ? ???r ?? S ??????x8????  ? ? ??? ?? S ??x?????Sg??? ? ?"???5?H ?? ? ?0???@??޽h?? ?? ??????????f??????r(????D??B??F?~H?i????J??6u?(`?@?  ?  ?X??Dhttp://www.w3.org/TR/xmldsig-core/?Z??Fhttp://www.ietf.org/rfc/rfc3275.txt?Z??Fh  !"#$%????'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRST????V???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????Oh??+'??0< px??? ? ( 4 @ LX`?? HTTP и CGI TP=D:\msoffice\Templates\Presentation Designs\International.pot0Yuri Demchenkop359Microsoft PowerPoint 7.0sen@ h???@??G?}Y?@`??X7?@??rc??FG??????y  ?<&?????? &????&#????TNPP??2??OMi & TNPP? &????&TNPP   ?? ????-?-- !???-????-??-????--- !?T?F--?-&????u??&????-?-????- $u?u?~~????-? $~?~???????-? $???????>>?-? $????????-? $??????-?--&????&????--BPM:--???w???w@? ͷ??w???w ??w0- ????@Times New Roman???w???w ??w0-? .'2 ??XML Security in IODEF#/!   '#!.--O Gl-- ????@Times New Roman???w???w ??w0-? .2 ?(INCH WG, IETF56  # . .2 ?HMarch 19, 2003   .????@Times New Roman???w???w ??w0-? .<2 ?#Yuri Demchenko          .--??"System !?0????w-?&TNPP &????????՜.??+,??D??՜.??+,???`?????? the algorithm used to calculate the digest. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??C$? e3f?K$? e3f? $? e3f?$? e3f?? ?%3f????  ^  &  ??\??Collect the Reference elements ?  ??bCollect the elements (with their associated digests) within a element. The element indicates the algorithm was used to canonize the element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??cZ &? g3f?3&? g3f?&?g3f?:&? g3f??&?g3f?G&??'3f??:K < ?I 7&&  &   ??]??Signing ? ???Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element. Signature Algorithms DSA PKCS1 (RSA-SHA1) <SignatureValue>MC0E& LE=</SignatureValue> ???. e3f?< e3f?!  '3f?*'3f?" ?P >: ??_??Add key information ? ??If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, C=CA MIID5jCCA0+gA...lVN ??Z7 e3f?? r???'3f??'3f??8?       36"??`??Enclose in a Signature element ?  ??? Place the , , and elements into a element. The element comprises the XML signature. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be referenced by a URI within the XML signature; reside within the same resource as the XML signature (the signature is a sibling); be embedded within the XML signature (the signature is the parent); have its XML signature embedded within itself (the signature is the child). ??D&??&?K&?? &? g3f?&?g3f?&? g3f?&? g3f?&? g3f??&???   8??d??Verifying an XML Signature? ??Verify the signature of the element Recalculate the digest of the element (using the digest algorithm specified in the element) Use the public verification key to verify that the value of the element is correct for the digest of the element If this step passes Recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element. ?\1 ?$? e3f? $?$? e3f?6$?e3f?K$?e3f?*$? e3f? $? ?  e3f?A  e3f?  e3f?  ?? ) 8M, ` g  ??b??Canonicalisation (1) ? ???The canonical form of an XML document is physical representation of the document produced by the canonicalisation method that implies the following changes. Encoding and characters The document is encoded in UTF-8 Line breaks normalized to #xA on input, before parsing Whitespace outside of the document element and within start and end tags is normalized All whitespace in character content is retained (excluding characters removed during line feed normalization)?t?$?$??$?"??N? P `??m 0?????c??Canonicalisation (2)? ???Elements and references Character and parsed entity references are replaced CDATA sections are replaced with their character content The XML declaration and document type declaration (DTD) are removed Empty elements are converted to start-end tag pairs Attributes Attribute values are normalized, as if by a validating processor Attribute value delimiters are set to quotation marks (double quotes) Special characters in attribute values and character content are replaced by character references Superfluous namespace declarations are removed from each element Default attributes are added to each element Lexicographic order is imposed on the namespace declarations and attributes of each element??Z?Z Z?ZqG ,s??e??&XPath Data Model for Canonicalisation ???XML canonicalization is defined in terms of the XPath definition of a node-set. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order: normalize line feeds normalize attribute values replace CDATA sections with their character content resolve character and parsed entity references The input octet stream MUST contain a well-formed XML document, but the input need not be validated. The declarations in the document type declaration are used to help create the canonical form.?62??2????f??Transform Algorithms??XCanonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation?YY??h??%XML Signature: Security Consideration??>Transforms Only What is Signed is Secure Only What is  Seen is Secure  See What is Signed Check the Security Model Algorithms, Key Length, Certificates, etc.?< QD QD??i??XML Encryption???Encrypt an XML Element, XML Element s content (Elements), XML Element s content (Character Data), or arbitrary data ad documents Can be used for Key transport Can be used in combination with XML Signature More information http://www.w3c.org/TR/xmlenc-core/ http://www.w3.org/TR/xmlenc-decrypt/ http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-04.txt ?2?????>Q ??k??6XML Encryption  Data Model??? ? ? # extension to XMLSig KeyInfo ? ? ? ? # ? # envelopes or references the raw encrypted data ? ? # points to the location of the raw encrypted data ? # e.g., timestamp ?"?Z???     : >  ??l??"XML Encryption: CipherData Element?$# ? ???Contains the encrypted octet sequence as base64 encoded text of the CipherValue element, or provides a reference to an external location containing the encrypted octet sequence via the CipherReference element. ?????C i   ( ??j??Encryption: Processing Rules??xFor each EncryptedData and EncryptedKey the encryptor must : 1. Select the algorithm (and parameters) 2. Obtain and (optionally) represent the key 3. Encrypt the data If the data is an  element or element  content , obtain the octets by serialising the data in UTF-8; any other data must be serialised as octets Encrypt the octets using the algorithm and key from steps 1 and 2 Provide type of presentation to indicate how to obtain and interpret the plaintext octets after decryption (e.g., MimeType= text/xml or MimeType= image/png ) 4. Build the EncryptedType (EncryptedData or EncryptedKey) 5. Process EncryptedData If the Type of the encrypted data is  element or element  content , then encryptor SHOULD be able to replace the unencrypted  element or  content with the EncryptedData element. If the Type of the encrypted data is  element or element  content , then encryptor MUST always be able to return the EncryptedData to the application. ?=ZjZsZUZNZ    js ?   v "   ??  ?   ? ??m??Decryption: Processing Rules???1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it. 2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. 3. Decrypt the data contained in the CipherData element  depending on existence of CipherValue or CipherReference child elements 4. Process decrypted data of Type 'element' or element 'content The cleartext octet sequence (from step 3) is interpreted as UTF-8 encoded character data The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. Validation on the serialized XML is NOT REQUIRED. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted 'element' or element 'content' represented by the UTF-8 encoded characters 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'.?p??[B 9 D ` % -  P %a + g!?.A?_ $ 3 P ? *j?? m 0????? m 0?????m 0?+2??m 0?@G??m 0?????m 0?????n??Available tools??Not many OpenSource, especially for Windows Java based Refer to http://www.w3.org/Signature/#Code http://www.w3.org/Encryption/2001/#Code Commercial MS Visual Studio IBM AlphaWorks Coming soon - DonKey client by NLnet Labs http://www.nlnetlabs.nl/donkey/??,J  + ,J    + ?< P'" K??m 0?c??G:??DonKey Project Goal(s)?? ??UOpen extendable system for public key and Identity management Initial stage Open global distributed system for publishing and retrieving named, signed public keys together with associated/bound information Intended development Identity management for federated cross-domain AuthN and AuthZ Donkey website: http://www.nlnetlabs.nl/donkey/?RV@""?"p?i;??DonKey functionality??^DonKey allows anyone to publish a named key, together with optional data (Donkey package) Key MUST be signed, and Package MAY be signed by Owner Donkey is NOT a permanent storage: key must be republished to remain available Donkey does NOT define a policy for key/payload usage This is an application specific function Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match Donkey allows anyone to query for a published key, based on the key's name (required) and signers (optional) Donkey allows anyone to sign a published key ??Z?)??Z?)??  ??U??'DonKey design issues: Package structure??(Proprietary) Internal format (currently: Python data object) but XML based exchange format Package ID Content Header Flags Names Owner Public Key # Name, Owner Key> must be unique Body Payload # Application dependent (e.g., AA, Identity, SSO) Signatures Signed??\ 9;\ 9  ;/?? P?????R? `? ????????f??????`? ???3?????????????`? ???___?????????????>???" dd=??????????????" dd?=?????????????uA?4? d?O?" ?i ?n???" dd??????????   @@``P?P   4 O i`? p?@??@    ? ?)? ?( ? ??p ? ? ?H??????d???? ?'W??? ? ? ?Z??a????a?????????? ??x8???? ? ?T?? Click to edit Master title style?!? !?: ? ? ?T???a????a????????? ??Sg???  ???RClick to edit Master text styles Second Level Third Level Fourth Level Fifth Level?!    ? S? ?  ?`?? ?a????a??????????? ?? ?????  ?`??*? ???=44OOii?  ?   ?`???a????a??????????? ?? `???   ?b??*? ???=44OOii?& ?!  ?`?(!?a????a??????????? ??!?????  ?~??Slide2_*?(  ???=44OOii?Z?F ?1?lY ?$ ??~???~ ?" ? ?N?????????2?????1?l$?~ ?# ? ?N?????????2?????1IlY??F ??? ?) ???c?8 ?% s ?B?C{DE?8F?@??????????????????@????????F??h??=?Zhz?zFz?\F3? @???????????????????0 ?& s ?B?C?DE?4F?<??????????????????@????? ????i??<?????<??#i?????@???????????????g?5?0 ?' s ?B-C?DE?4F?<??????????????????@????? ??o?????*l??,J??????Jz?o@???????????????Arn*? ?( ? ??BKCoDE?4F?<?????????? ??(%+(J27JQ+E%nEQ7@???????????????????H ? ? ?0??@??޽h??? ?? ??????????f?????? ?International?? ? ??@?% ?E?( ??4p? ~?p? ? ?^ ? ? ?6??????? ?@_??p ? ? ?H??????d???? ??_??? ? ? ?Z?C?a????a?????????? ????????  ?T?? Click to edit Master title style?!? !?? ? ? ?Z????a????a?????????? ??HZjG ??  ?W??#Click to edit Master subtitle style?$? $? ?  ?`??U?a????a??????????? ????????  ?\??*????=44OOii? ?  ?`?< U?a????a??????????? ???S ???  U ?^??*????=44OOii? ?  ?`?XU?a????a??????????? ???????? U ?n??Slide 2_*?  ???=44OOii?H ? ? ?0??@??޽h??? ?? ??????????f????????? ? ??? ? ?$?( ? ? ?r ?  S ??T????x8????   ? ??r ?  S ??????Sg???  ? ??H ?  ? ?0???@??޽h?? ?? ??????????f????????? ? ?????0?( ? ??x ? c ?$??*????x8????   ? ??x ? c ?$??+????Sg???  ? ??H ? ? ?0???@??޽h?? ?? ??????????f????????? ? ???? ?0?( ? ? ?x ?  c ?$?(??????x8????  ? ? ??x ?  c ?$????????Sg??? ? ? ??H ?  ? ?0???@??޽h?? ?? ??????????f??????r(?J ?l?? y?e??]??i??JU???6u?(`?@?  ?  ?X??Dhttp://www.w3.org/TR/xmldsig-core/?Z??Fhttp://www.ietf.org/rfc/rfc3275.txt?Z??Fhttp://www.w3.org/TR/xml-c14n#UTF-8?l??Xhttp://www.abccompany.com/xml/po.xml#sender1?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~? ?jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-element?~??jhttp://www.w3.org/TR/2000/REC-xml-20001006#NT-content? /? 0???DTimes New Roman??t?\?d? 0t? & 0 ?DSymbolew Roman??t?\?d? 0t? & 0  ?DMonotype Sorts??t?\?d? 0t? & 00?DVerdana Sorts??t?\?d? 0t? & 0 "@?DCourier Sorts??t?\?d? 0t? & 0P?DCourier Newts??t?\?d? 0t? & 0 1`?DArial Unicode MS?t?\?d? 0t? & 0??f???? ? .??@  @@``???  @?n???" dd@?????????  @@``?? ??X,??!*&!3?2!      . S ?~??????????1???????????0? ??????n?@???8???????g??4MdMdd? 0h?????????p?pp?0 ? <?4BdBd???@ 0$??u?ʚ;2N??ʚ;<?4!d!d???= 0??<?4dddd???= 0???t?l?___PPT9?N/? 0?z?&?Y?????-?:March 19, 2003. San Francisco ?*XML Security in IODEFO? ?=??b???XML Security in IODEF?$(??BINCH WG, IETF56 March 19, 2003 Yuri Demchenko ?"C$"?$ ??g??Outlines???XML Security Basics XML Signature XML Canonicalisation (reference) XML Encryption DonKey project at NLnet Labs: PK Management and XMLSig ?????^??#XML: Schema vs DTD and XML Protocol??rDTD is document-oriented Like HTML Schema is data-oriented XML Signature SAML Basic XML Protocol(s) XML-RPC SOAP?t    ??W??.XML Security vs traditional (network) security???Traditional Security: Host-to-host or point-to-point security Client/server oriented Connection or connectionless oriented Generically single/common trust domain/association XML Security Document oriented approach Security tokens/assertions and policies can be associated with the document or its parts Intended to be cross-domain Potentially for virtual and dynamic trust domains (security associations)?t?Yf?Yf??V??XML Signature: Features??DFundamental feature: the ability to sign only specific portions of the XML tree rather than the whole document. XML document may have a long history when different component are authored by different parties at different times Different parties may want to sign only those elements relevant to them Important when keeping integrity of certain parts of an XML document is essential while leaving the possibility for other parts to be changed Allows carrying security tokens/assertions on document/data rather than on user/client Provides security features for XML based protocols ?6p?p???X??XML Signature structure???? ? ? (? ()?? ? ? )+? ? ()?? ()*? ??$?Z?%??? /   $??Y??How to Create an XML Signature ?  ??$W3C REC: http://www.w3.org/TR/xmldsig-core/ IETF Draft Standard: http://www.ietf.org/rfc/rfc3275.txt 1. Determine which resources are to be signed 2. Calculate the digest of each resource 3. Collect the Reference elements 4. Signing 5. Add key information 6. Enclose in a Signature element ?h%?" eD?yF? f?9F?B?L  ???m 0? +??m 0?Ad??Z??+Determine which resources are to be signed ?,* ???Resources are defined through a Uniform Resource Identifier (URI) http://www.abccompany.com/xml/po.xml#sender1 - references a specific element in an XML file on the Web reference document with attached signature ?>B?B$?h* ??m 0?Bn??[??%Calculate the digest of each resource?&& ??In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element. The element identifies the algorithm used to calculate the digest. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??C$? e3f?K$? e3f? $? e3f?$? e3f?? ?%3f????  ^  &  ??\??Collect the Reference elements ?  ??bCollect the elements (with their associated digests) within a element. The element indicates the algorithm was used to canonize the element. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. j6lwx3rvEPO0vKtMup4NbeVu8nk= ??cZ &? g3f?3&? g3f?&?g3f?:&? g3f??&?g3f?G&??'3f??:K < ?I 7&&  &   ??]??Signing ? ???Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element. Signature Algorithms DSA PKCS1 (RSA-SHA1) <SignatureValue>MC0E& LE=</SignatureValue> ???. e3f?< e3f?!  '3f?*'3f?" ?P >: ??_??Add key information ? ??If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification. CN=Ed Simon, O=XMLSec Inc., ST=OTTAWA, C=CA MIID5jCCA0+gA...lVN ??Z7 e3f?? r???'3f??'3f??8?       36"??`??Enclose in a Signature element ?  ??? Place the , , and elements into a element. The element comprises the XML signature. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be referenced by a URI within the XML signature; reside within the same resource as the XML signature (the signature is a sibling); be embedded within the XML signature (the signature is the parent); have its XML signature embedded within itself (the signature is the child). ??D&??&?K&?? &? g3f?&?g3f?&? g3f?&? g3f?&? g3f??&???   8??d??Verifying an XML Signature? ??Verify the signature of the element Recalculate the digest of the element (using the digest algorithm specified in the element) Use the public verification key to verify that the value of the element is correct for the digest of the element If this step passes Recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element. ?\1 ?$? e3f? $?$? e3f?6$?e3f?K$?e3f?*$? e3f? $? ?  e3f?A  e3f?  e3f?  ?? ) 8M, ` g  ??b??Canonicalisation (1) ? ???The canonical form of an XML document is physical representation of the document produced by the canonicalisation method that implies the following changes. Encoding and characters The document is encoded in UTF-8 Line breaks normalized to #xA on input, before parsing Whitespace outside of the document element and within start and end tags is normalized All whitespace in character content is retained (excluding characters removed during line feed normalization)?t?$?$??$?"??N? P `??m 0?????c??Canonicalisation (2)? ???Elements and references Character and parsed entity references are replaced CDATA sections are replaced with their character content The XML declaration and document type declaration (DTD) are removed Empty elements are converted to start-end tag pairs Attributes Attribute values are normalized, as if by a validating processor Attribute value delimiters are set to quotation marks (double quotes) Special characters in attribute values and character content are replaced by character references Superfluous namespace declarations are removed from each element Default attributes are added to each element Lexicographic order is imposed on the namespace declarations and attributes of each element??Z?Z Z?ZqG ,s??e??&XPath Data Model for Canonicalisation ???XML canonicalization is defined in terms of the XPath definition of a node-set. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order: normalize line feeds normalize attribute values replace CDATA sections with their character content resolve character and parsed entity references The input octet stream MUST contain a well-formed XML document, but the input need not be validated. The declarations in the document type declaration are used to help create the canonical form.?62??2????f??Transform Algorithms??XCanonicalisation Base64 XPath Filtering Envelope Signature Transform XSLT Transformation?YY??h??%XML Signature: Security Consideration??>Transforms Only What is Signed is Secure Only What is  Seen is Secure  See What is Signed Check the Security Model Algorithms, Key Length, Certificates, etc.?< QD QD??i??XML Encryption???Encrypt an XML Element, XML Element s content (Elements), XML Element s content (Character Data), or arbitrary data ad documents Can be used for Key transport Can be used in combination with XML Signature More information http://www.w3c.org/TR/xmlenc-core/ http://www.w3.org/TR/xmlenc-decrypt/ http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-04.txt ?2?????>Q ??k??6XML Encryption  Data Model??? ? ? # extension to XMLSig KeyInfo ? ? ? ? # ? # envelopes or references the raw encrypted data ? ? # points to the location of the raw encrypted data ? # e.g., timestamp ?"?Z???     : >  ??l??"XML Encryption: CipherData Element?$# ? ???Contains the encrypted octet sequence as base64 encoded text of the CipherValue element, or provides a reference to an external location containing the encrypted octet sequence via the CipherReference element. ?????C i   ( ??j??Encryption: Processing Rules??xFor each EncryptedData and EncryptedKey the encryptor must : 1. Select the algorithm (and parameters) 2. Obtain and (optionally) represent the key 3. Encrypt the data If the data is an  element or element  content , obtain the octets by serialising the data in UTF-8; any other data must be serialised as octets Encrypt the octets using the algorithm and key from steps 1 and 2 Provide type of presentation to indicate how to obtain and interpret the plaintext octets after decryption (e.g., MimeType= text/xml or MimeType= image/png ) 4. Build the EncryptedType (EncryptedData or EncryptedKey) 5. Process EncryptedData If the Type of the encrypted data is  element or element  content , then encryptor SHOULD be able to replace the unencrypted  element or  content with the EncryptedData element. If the Type of the encrypted data is  element or element  content , then encryptor MUST always be able to return the EncryptedData to the application. ?=ZjZsZUZNZ    js ?   v "   ??  ?   ? ??m??Decryption: Processing Rules???1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it. 2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. 3. Decrypt the data contained in the CipherData element  depending on existence of CipherValue or CipherReference child elements 4. Process decrypted data of Type 'element' or element 'content The cleartext octet sequence (from step 3) is interpreted as UTF-8 encoded character data The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data. Validation on the serialized XML is NOT REQUIRED. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted 'element' or element 'content' represented by the UTF-8 encoded characters 5. Process decrypted data if Type is unspecified or is not 'element' or element 'content'.?p??[B 9 D ` % -  P %a + g!?.A?_ $ 3 P ? *j?? m 0????? m 0?????m 0?+2??m 0?@G??m 0?????m 0?????n??Available tools??Not many OpenSource, especially for Windows Java based Refer to http://www.w3.org/Signature/#Code http://www.w3.org/Encryption/2001/#Code Commercial MS Visual Studio IBM AlphaWorks Coming soon - DonKey client by NLnet Labs http://www.nlnetlabs.nl/donkey/??,J  + ,J    + ?< P'" K??m 0?c??G:??DonKey Project Goal(s)?? ??UOpen extendable system for public key and Identity management Initial stage Open global distributed system for publishing and retrieving named, signed public keys together with associated/bound information Intended development Identity management for federated cross-domain AuthN and AuthZ Donkey website: http://www.nlnetlabs.nl/donkey/?RV@""?"p?i;??DonKey functionality??^DonKey allows anyone to publish a named key, together with optional data (Donkey package) Key MUST be signed, and Package MAY be signed by Owner Donkey is NOT a permanent storage: key must be republished to remain available Donkey does NOT define a policy for key/payload usage This is an application specific function Multiple parties are allowed to publish a key with the same name. Applications must select the correct key when multiple keys match Donkey allows anyone to query for a published key, based on the key's name (required) and signers (optional) Donkey allows anyone to sign a published key ??Z?)??Z?)??  ??U??'DonKey design issues: Package structure??(Proprietary) Internal format (currently: Python data object) but XML based exchange format Package ID Content Header Flags Names Owner Public Key # Name, Owner Key> must be unique Body Payload # Application dependent (e.g., AA, Identity, SSO) Signatures Signed??\ 9;\ 9  ;/?? P????r???j????R?