Web Services & Security ir. Paul Brandt, TNO-ICT Today, Friday January 13 Next week, Friday January 20
Web Services & Security
ir. Paul Brandt, TNO-ICT
Today, Friday January 13Next week, Friday January 20
Web Services & Security
Web Services
What are Web Services?
Web pages for computersReality: heterogeneous systems,
platforms, dataReality: Processes change, be agile
to copeApplication: provides serviceRequest-responseLousely coupled
What's its Significance?
Application IntegrationEAI, B2B, Automating Business
ProcessesUniversal Application Connectivity
Universal Application Connectivity
Easy to access remote resourcesExpose business processes over the
WebInterface is standard, published,
discoverable, self-describing
What are the Security Challenges?
Message orientedIdentities
Message oriented
Web services typically use multi-hop communication paths
Transport level security (SSL, TLS, IPSEC, ...) only provides Point-2-Point (on-the-wire) confidentiality
Messages are decrypted in the servers (a.o. routing), violating confidentiality
Hence End-2-End, i.e. message based, confidentiality required
Combined approach is possible
Identities
Web services transport potentially unkown identies into my platform
Who are they?Are they authorized?Assett protection: What critical
information is leaving my platform?Can it be proved they did these
things?
XML-family
XML-family
XML basics
XML Objective
Structured, self describing interface...
... totally independent application, protocol, vocabulary, operating system & programming language
Grammar & syntax to build interfaceNothing to do with semantics!!
XML Characteristics
XML stores data within descriptive element tags: <PartNo>54-2345</PartNo>
Character-oriented, not binary, hence human-readable
Extensible Meta LanguageSeparates content from structure &
formAll family members are specified in
XML itself
Example 1: Simple XML (1/1)
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
<Model material="Iron" color="Blue" />
</LineItem>
<Amount Currency="USD">108.50</Amount>
<Customer id="customer" custNum="A2345">
<FirstName>Fred</FirstName>
<MiddleInit>L</MiddleInit>
<LastName>Jones</LastName>
<CreditCard>
<CreditCardType>VISA</CreditCardType>
<CreditCardNumber>43343456343566</CreditCardNumber>
<CreditCardExpiration>10/08</CreditCardExpiration>
</CreditCard>
</Customer>
</Order>
An Order
Element: Data enclosed by named tags:
<element>data</element>
Hierarchical: <Element> can contain other <Element>’s
Start-tag can contain attributes:attributeName=value
Reserved attributeNames:“id=” uniquely identifies
individual element
Empty element:no data, single <element/> tag
XML Schema
XML document can be validated against schema, automatically
Schema defines hierarchical structure
Schema defines data typesSchema defines particular order of
elementsSchema provides for accurate &
consistent dataXML document = instance of defined
XML schema
Example 2: XML Schema (1/1)
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:element name="Order" type="order"/>
<xsd:complexType name="order">
<xsd:element name="LineItem" type="lineItemType"/>
<xsd:element name="Amount" type="amountType"/>
<xsd:element name="Customer" type="customerType"/>
</xsd:complexType>
<xsd:complexType name="lineItemType">
<xsd:element name="ProductName" type="xsd:string"/>
<xsd:element name="Model" type="modelType"/>
</xsd:complexType>
. . . etc., until all types correspond to simpleTypes
(integer, string, double, float, date and time)
</xsd:schema>
An Order
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
<Model material="Iron" color="Blue" />
</LineItem>
<Amount Currency="USD">108.50</Amount>
<Customer id="customer" custNum="A2345">
<FirstName>Fred</FirstName>
<MiddleInit>L</MiddleInit>
<LastName>Jones</LastName>
<CreditCard>
<CCType>VISA</CCType>
<CCNumber> . . </CCNumber>
<CCExpiration>10/08</CCExpiration>
</CreditCard>
</Customer>
</Order>
Namespaces
ProblemSolution: xmlns
Problem
Anyone can define element namesHence, name collision and conflicts
all alongXML shall keep names separate and
distinct
Solution: xmlns XML namespace (1/1)
xmlns:myns=“http://www.myorg.com/foo”
<myns:order>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:element name="Order" type="order"/>
<xsd:complexType name="order">
<xsd:element name="LineItem" type="lineItemType"/>
<xsd:element name="Amount" type="amountType"/>
<xsd:element name="Customer" type="customerType"/>
</xsd:complexType>
<xsd:complexType name="lineItemType">
<xsd:element name="ProductName" type="xsd:string"/>
<xsd:element name="Model" type="modelType"/>
</xsd:complexType>
. . . etc., until all types correspond to simpleTypes
(integer,
string, double, float, date and time)
</xsd:schema>
My unique namespace
Namespaces are uniform resource identifiers:1. Define unique name2. Prepend that to each & every element name
Abbreviated namespace:prefix
Reserved namespace:“namespace def coming up”
Unique element name
XML Landscape
XML standards belonging to operation domain
XML standards belonging to XML Family (Security)
XML standards belonging to XML Family (general)
XML standards belonging to operation domain
hrXML - XML for Human Resource (employment agencies)
X4ML - XML for Merrill LynchHL-7v3: XML message format for
Health Care....really, really big landscape
XML standards belonging to XML Family (Security)
SOAP - Simple Object Access Protocol
XML-Signature XML-Encryption SAML - Security Assertion
Markup Language XACML - eXtensible Access
Control Markup Language XrML - eXtensible Rights
ML XKMS - XML Key
Management Specification WS-Security WS-Policy
XML standards belonging to XML Family (general)
WS-*: Web Service standardsWSDL - Web Services Description
LanguageXSL(T) - eXtensible Stylesheet
Language (Transformations)XPath
XML-Signature
XML-Signature
Objective
Integrity of resourceIdentity of originatorNon-repudiation of eventFoundation from Digital Signature
Foundation from Digital Signature
Greatly expands upon it:Uses power and flexibility of XML ...... as well as key Web technologies
(such as URLs) ...to sign almost any type of resource:
to sign almost any type of resource:
XML documentsParts thereofnon-XML object such as an imageas long as it has an URL
XML-Signature structure
Core
A set of pointers (references) to things to be signed
The actual signature(Optional) The key (or a way to look
up the key) for verifying the signature
(Optional) An Object tag for miscellaneous items not included in the first three items
Example Sig1:Highly Simplified XML Signature (1/1)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> <Reference URI="http://www.foo.com/secureDocument.html" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>... </KeyInfo>
</Signature>
actual signature bits
information about the key
Reference(s) to what is
being signed
3 Types of XML-Signature
Enveloping SignaturesEnveloped SignaturesDetached Signatures
Example Sig2:Simplified Enveloping Signatures (1/4)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <Reference URI="#111" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> <Object>
<SignedItem id="111">Stuff to be signed</SignedItem> </Object></Signature>
<PurchaseOrder id="po1"> <SKU>125356</SKU> <Quantity>17</Quantity> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <Reference URI="#po1" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature></PurchaseOrder>
Example Sig2:Simplified Enveloped Signatures (2/4)
Example Sig2:Detached Signatures (3/4)
internal resource
<PurchaseOrderDocument>
<PurchaseOrder id="po1"> <SKU>12366</SKU> <Quantity>17</SKU> </PurchaseOrder>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <Reference URI="#po1" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature>
</PurchaseOrderDocument>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <Reference URI="http://www.foo.com/Lion.jpg" /> <Reference URI="http://www.foo.com/Secure.txt" /> <Reference URI="http://www.foo.com/Secure.xml" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo></Signature>
Example Sig2:Detached Signatures (4/4)
external resource
The Bloody Details
Core element 1/4: <SignedInfo>
1. Security model2. Canonicalization (c14n)3. Identify resource(s) to be signed
1. Security model
No new security technologies were invented (Digital Signature)
But: Digital Signature == Integrity AND Identity
Hence: Public keys (asymmetrical: RSA, DSA) => integrity & identity
Keyed Hashed Authentication Code (symmetrical: HMAC) => ONLY integrity, NO identity
<SignatureMethod />
2. Canonicalization (c14n)
2.1. c14n normalizes the XML2.2. c14n: What does it actually do?
2.1. c14n normalizes the XML
regardless of inconsequential physical differences in the XML ...
... two logically equivalent XML documents ...
... will become physically, bit-to-bit equivalent.
This is a critical requirement for
digital signatures to work.
2.2. c14n: What does it actually do?
The document is encoded in UTF-8.
Line breaks are normalized to #xA on input, before parsing.
Attribute values are normalized, as if by a validating processor.
Character and parsed entity references are replaced.
CDATA sections are replaced with their character content.
The XML declaration and Document Type Definition (DTD) are removed.
Empty elements are converted to start-end tag pairs.
Whitespace outside the document element and within start and end tags is normalized.
All whitespace in character content is retained (excluding characters removed during linefeed normalization).
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.
3. Identify resource(s) to be signed
Reference the resource(s) (enveloped/-ing/detached) using URI
Calculate (& include) Digest of referenced resource
(not before Transforms have been applied, such as c14n, XSLT, XPath)
<Reference URI ? > +
<Reference URI ? > +
<Transforms> ?<DigestMethod><DigestValue>
Core element 2/4: <SignatureValue>
NOT signature of resource itself!Digital signature of the
<SignedInfo> blockSignature Method, Resource
Reference & Resource DigestIndirect, but water tight signature of
resource
Core element 3/4: <KeyInfo> ?
1. Can be omitted completely (assuming the receiver's got it already).
2. Provide a name to look up the key.
3. Provide the key in a raw form right in the XML.
4. Provide the key within a digital certificate.
Provides a variety of types of keys to support different cryptography standards.
Know your Keys! Verify!
Know your Keys! Verify!
Key is Valid (CA)Key is not revoked(asym:) Represents the individual
Core element 4/4: <Object> *
Type-attribute: 1 out of three:"Enveloping Signature: Here's your
data"A Manifest elementA SignatureProperties element
Resulting Schema shorthand
<Signature><SignedInfo>
<CanonicalizationMethod><SignatureMethod> (<Reference URI ? >
<Transforms> ?<DigestMethod><DigestValue>
</Reference>)+ </SignedInfo>
<SignatureValue>
(<KeyInfo (id=)?> (<KeyName>)? (<KeyValue>)? (<RetrievalMethod>)? (<X509Data>)? (<PGPData>)? (<SPKIData>)? (<MgmtData>)?
<KeyInfo>)?
(<Object> (<Manifest (id=)?>
<Reference> +</Manifest>) ?(<SignatureProperties>
<SignatureProperty (id=)?> +</SignatureProperties>) ?
</Object> ) *</Signature>
Best practices
1. Transformations
1.1. Only what is signed, is secure (... and NOT that what has been
removed by Transform, but still present in resource!)
1.2. WYSIWYS (... hence: include XSL(T)-
stylesheet)1.3. Work on what is signed (... not on resource, but on
transformed resource)
2. Security model
2.1. Know your Keys! Verify them!2.2. Public key signatures are primarily
associated with identity and integrity.2.3. Keyed hashed authentication codes
are shared key based, run much faster than public keys, however ONLY provides integrity, not identity
2.4. XML-Signature processing does not automatically sign <Object> elements within a <Signature> element: Only <SignedInfo> is signed!
Summary
XML-Encryption
XML-Encryption
Objective
2. Message oriented
2.1. Web services typically use multi-hop communication paths
2.2. Transport level security (SSL, TLS, IPSEC, ...) only provides Point-2-Point (on-the-wire) confidentiality
2.3. Messages are decrypted in the servers (a.o. routing), violating confidentiality
2.4. Hence End-2-End, i.e. message based, confidentiality required
2.5. Combined approach is possible
3. One document, Multiple views
3.1. Encrypt different sections3.2. Possibly with distinct keys3.3. Hence: different sections
mutually exclusive available for different target audiences
4. Target resource
4.1. Internal encryption: Within current document (similar to Enveloping)
4.2. External encryption: external resource (similar to Detached)
... XML document... any other MIME-type document... as long as it has got a URL
XML-Encryption structure
Example Enc1:Highly Simplified XML-Encryption (1/1)
encapsulated by original <SSNo>
encapsulating original <Salary>
Binary, encrypted content
<MyDoc><Employee>
<SSNo>34569812612</SSNo><Name>Fred Jones</Name><Salary>$42.644</Salary><Manager>David Mischief</Manager>
</Employee></MyDoc>
<MyDoc><Employee>
<SSNo><EncryptedData>kjhGEuf7639Fh*e#j&2V</EncryptedData>
</SSNo><Name>Fred Jones</Name><EncryptedData>jHFnkeiuHF3#9jeGi$@kjg*KJGm,jF</EncryptedData><Manager>David Mischief</Manager>
</Employee></MyDoc>
Core: <EncryptedData> element
Either wraps data within the XML document that is being encrypted
Or it points to something that has been encrypted
<EncryptedData> ..CipherData or ReferenceToCipherData.. </EncryptedData>
<EncryptedData>-element replaces original content
The Bloody Details
1. <EncryptedData>
1.1. Purpose:
1.1.1. Overall tag, container for XML-Encryption structure
1.1.2. Can be placed anywhere in your XML resource
1.1.3. Represents: one single resource that has been encrypted
1.1.4. Encrypted data either encompassed or detached
1.2. Attributes for <EncryptedData>
1.2.1. Id : one can refer to this <EncryptedData> element
1.2.2. Type="Content" or "Element":1.2.3. MIME Type :1.2.4. Encoding :1.2.5. All attributes are optional, in
practice Type always included
1.2.2. Type="Content" or "Element":
Don't encrypt <element> tag
... <SSNo> tag encapsulates <EncryptedData> tag
Do encrypt <element> tag
... <EncryptedData>-element encapsulates disappeared <Salary> tag
1.2.3. MIME Type :
To further describe the encrypted item, i.e. GIF image
MimeType='image/gif'
1.2.4. Encoding :
To further describe the encrypted item, i.e. Base-64 character encoding
Because encrypted data is binary data...
... encoding describes method to encode binary encrypted data to character data ...
... to be able to insert it in an XML document
Encoding="http://www.w3.org/2000/09/xmldsig#base64"
1.3. <EncryptedData> & Multiple views:
1.3.1. Define <EncryptedData> elements
1.3.2. Each is associated with one single key
1.3.3. Use N keys for N target audiences
2. <EncryptionMethod/> ?
3. <CipherData>
4. <EncryptionProperties> ?
5. <KeyInfo> ?
5.1. Encryption key = symmetrical key: (1/4)
5.1.1. Speed 1000x faster than asymmetrical
5.1.2. Unlimited plain text size of target
5.1.3. Shared key encryption utilizes public key encryption to manage distribution of the shared key securely to the recipient
5.2. <KeyInfo> element structure (2/4)
5.2.1. Identical to XML-Sig <KeyInfo>
5.2.2. Additional elements for key transport (<EncryptedKey>, <AgreementMethod>)
5.3. Key Transport (3/4)
5.3.1. Leave out the key (assuming both sides already know the secret key).
5.3.2. Provide name or pointer to it (he's got it, but needs to know which one to select: <keyName> or <RetrievalMethod>)
5.3.3. Include encrypted symmetrical key:
5.3.4. Include hint to generate key:
5.3.3. Include encrypted symmetrical key:
Uses asymmetrical key technology to transport symmetrical encryption key
<EncryptedKey> elementContains encrypted asymmetrical
keyIdentical to <EncryptedData>
structure & syntaxCan thus be recursive (!)Strategy is called "Digital
Enveloping"
5.3.4. Include hint to generate key:
Uses "Key Agreement Protocol" to transport information to generate symm. key
Provide key generation algorithm, nonce, originator & recipient key info etc.
<AgreementMethod> element
5.4. <ReferenceList> (4/4)
5.4.1. Lord of the Keys: "One Key to Rule Them All"
5.4.2. Efficiency: one <KeyInfo> block suffices
5.4.3. List of refs. to <EncryptedData> elements using this <KeyInfo>
Super encryption
<EncryptedData> element encrypts other <EncryptedData> elements:
Fully recursiveApplies to entire <EncryptedData>
element(s), not its parts
Resulting Schema shorthand
<EncryptedData Id? Type? MimeType? Encoding?><EncryptionMethod/>?<ds:KeyInfo>
<EncryptedKey>?<AgreementMethod>?<ds:KeyName>?<ds:RetrievalMethod>?<ds:*>?
</ds:KeyInfo>?<CipherData>
<CipherValue>? <CipherReference URI?>?
</CipherData><EncryptionProperties>?
</EncryptedData>
Combining XML-Encryption with XML-Signature
EncryptedData for SSNo.
Key (1) info belonging to Ciphered SSNo.
Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(1/2)
Ciphered SSNo.
EncryptedData for Key
Encrypted Key to decrypt Ciphered SSNo.
Key (2) info belonging to Encrypted Key
Signed info refers to Encrypted Data for SSNo.
Digest of EncryptedData for SSNo.
Signature of SignedInfo
Key (3) info to verify Signature
Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(2/2)
Reasonable Statement
Iff:Confident keys are associated with sender & recipientAND private keys are not compromised
Then:“This document was prepared by David Remy and can only be read by Jothy Rosenberg”
SfE: however...
<Signature> & <EncryptedData> are detached
<Signature> can be removed without being noticed
<Signature> can even be replaced: "Signed by David Copperfield"
Need Policy: If encrypted, then also signed
BTW: what's the order of processing ??
Example Enc & Sig 2: Encryption follows Signing (1/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> </Customer></Order>
The original Order
Example Enc & Sig 2: Encryption follows Signing (2/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <Name . . . /> <CreditCard . . . /> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#customer"> <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . . </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer></Order>
The Order, signed by David Remy
Example Enc & Sig 2: Encryption follows Signing (3/3)
<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encryptedData1" Type="Element"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=Jothy Rosenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData></Order>
The signed order, <Customer> is element Encrypted
EfS: however...
++ Signature, w/t sensitive data, invisible
++ Clear order of processing
-- Integrity of EncryptedData isn’t guaranteed
In conclusion
Order of processing SfESecurity Model: SfE or EfS
Order of processing SfE
Problem: What to do 1st, Decrypt or Validate Signature
Solution: additional 'Decrypt Transform' for XML-Signature
Security Model: SfE or EfS
Depends on context, the specific situation
Specify a PolicyConsider multi-layered approach
SfEfS
Summary