web services & security

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 ConnectivityEasy to access remote resourcesExpose business processes over the

WebInterface is standard, published,

discoverable, self-describing

What are the Security Challenges?Message orientedIdentities

Message orientedWeb services typically use multi-hop

communication pathsTransport 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

IdentitiesWeb services transport potentially

unkown identies into my platformWho 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 basics

XML ObjectiveStructured, self describing interface...... totally independent application,

protocol, vocabulary, operating system & programming language

Grammar & syntax to build interfaceNothing to do with semantics!!

XML CharacteristicsXML 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 OrderElement: 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 SchemaXML document can be validated

against schema, automaticallySchema defines hierarchical

structureSchema 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>

NamespacesProblemSolution: xmlns

ProblemAnyone 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 LandscapeXML standards belonging to

operation domainXML standards belonging to XML

Family (Security)XML standards belonging to XML

Family (general)

XML standards belonging to operation domainhrXML - 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

ObjectiveIntegrity of resourceIdentity of originatorNon-repudiation of eventFoundation from Digital Signature

Foundation from Digital SignatureGreatly 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

CoreA set of pointers (references) to

things to be signedThe 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-SignatureEnveloping 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 modelNo new security technologies were

invented (Digital Signature)But: Digital Signature == Integrity

AND IdentityHence: Public keys (asymmetrical:

RSA, DSA) => integrity & identityKeyed 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 XMLregardless 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 signedReference the resource(s)

(enveloped/-ing/detached) using URICalculate (& include) Digest of

referenced resource(not before Transforms have been

applied, such as c14n, XSLT, XPath)<Reference URI ? > +

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. Transformations1.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 model2.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

Objective

2. Message oriented2.1. Web services typically use multi-hop

communication paths2.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 views3.1. Encrypt different sections3.2. Possibly with distinct keys3.3. Hence: different sections

mutually exclusive available for different target audiences

4. Target resource4.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> elementEither wraps data within the XML

document that is being encryptedOr 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 structure1.1.2. Can be placed anywhere in

your XML resource1.1.3. Represents: one single

resource that has been encrypted1.1.4. Encrypted data either

encompassed or detached

1.2. Attributes for <EncryptedData>1.2.1. Id : one can refer to this

<EncryptedData> element1.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 imageMimeType='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>

elements1.3.2. Each is associated with one

single key1.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

asymmetrical5.1.2. Unlimited plain text size of

target5.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 StatementIff: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


<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


<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 conclusionOrder of processing SfESecurity Model: SfE or EfS

Order of processing SfEProblem: What to do 1st, Decrypt or

Validate SignatureSolution: additional 'Decrypt

Transform' for XML-Signature

Security Model: SfE or EfSDepends on context, the specific

situationSpecify a PolicyConsider multi-layered approach

SfEfS

Summary

web services & security

Documents