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

<ProductName>Birdcage</ProductName>

</LineItem>

<LastName>Jones</LastName>

</CreditCard>

</Customer>

</Order>

An Order

Element: Data enclosed by named tags:

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>

<ProductName>Birdcage</ProductName>

</LineItem>

<LastName>Jones</LastName>

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

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

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)

</SignedInfo>

</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)

<SignedItem id="111">Stuff to be signed</SignedItem> </Object></Signature>

Example Sig2:Simplified Enveloped Signatures (2/4)

Example Sig2:Detached Signatures (3/4)

internal resource

</PurchaseOrderDocument>

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

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 ? > +

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!

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

</Reference>)+ </SignedInfo>

(<KeyInfo (id=)?> (<KeyName>)? (<KeyValue>)? (<RetrievalMethod>)? (<X509Data>)? (<PGPData>)? (<SPKIData>)? (<MgmtData>)?

<KeyInfo>)?

(<Object> (<Manifest (id=)?>

<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

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

<SSNo>34569812612</SSNo><Name>Fred Jones</Name><Salary>$42.644</Salary><Manager>David Mischief</Manager>

</Employee></MyDoc>

<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

<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

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

Summary

Web Services & Security ir. Paul Brandt, TNO-ICT Today, Friday January 13 Next week, Friday January 20.

Documents

Friday, January 18, 2013

January 23, 2015 (Friday)

Friday January 18, 2013

Friday, January 12, 2018

Friday, January 24, 2014

January 3 2014 (Friday)

Friday, January 27

Friday, January 8, 2011

FRIDAY 22nd JANUARY ‘10

Friday, January 18, 2019 Friday, January 11, 2019 1:00 ... -...

Friday, January 27, 2012

Friday, January 30, 2015

Friday 18 January 2019

Friday, January 23, 2015

Friday, January 19

Friday, January 16, 2015