This MEG provides some educational and general guidance on encryption for the MISMO community. Encryption is the process of transforming information (e.g., text, graphics) into something that is unreadable or unrecognized. Encryption masks the information to protect its confidentiality. There are two basic components; algorithm and key. Both the algorithm and key are important concepts and implementers should be familiar with both components. Users can select the default, specify or negotiate an algorithm with their trading partner and the algorithm can be exchanged openly. The secret is the “key”. Users can negotiate, reference (e.g, John Smith, URL) or dynamically generate keys.
Encryption can be one-way or two-way (bi-directional). One-way encryption is used to create a hash (mangles bits data) that cannot be decrypted. One-way or hashes are used for digital signatures or message authentication codes (MAC). This material is concerned with bi-directional encryption and one-way encryption is not within the scope of the MEG.
Two-way or bi-directional encryption permits the decryption of any encrypted (cipher text) information. XML encryption provides standard mechanisms for the exchange of cipher text between parties. There are standard algorithms based on current best practices and various methods for the exchange of keys. Encryption can be at the application (code that generates the XML) or transport (SOAP Message Security) layers. The choice of which layer to encrypt data depends on business use case scenario and risk requirements. The use of standardized XML encryption features permits the use of commercial products.
For additional information on encryption see the W3C XML Encryption Syntax and Processing 
and the OASIS SOAP Message Security Web Services Security: SOAP Message Security 1.1 guides.
1.1 Audience
Analysts, Security Personnel, and Developers of MISMO XML standards are concerned with the confidentiality of sensitive information. With the migration to MISMO Version 3 element centric model, encryption of confidential information can be achieved using standard XML encryption and WS-Security SOAP Message Security mechanisms.
1.2 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. See «add reference to MISMO glossary for terminology used in this MEG».
1.3 Document Status
The information supplied in this document reflects the MISMO interoperability principles at the time of writing. It is a living document, which will be updated as required to reflect the evolving nature of XML technologies and service requirements identified by MISMO constituency. Comments on this document should be sent to the MISMO designated contact identified in the document preface. MISMO does not accept any liability for the accuracy, adequacy, or completeness of the information contained in these Guidelines.
2. Rationale for this MEG
The protection and access of sensitive information; Intellectual Property (IP), Personally Identifiable Information (PII) and business/contract data is a requirement for all organizations. Legislation; Gramm-Leach-Bliley (GLB), Fair and Accurate Credit Transactions Act (FACT) and regulatory; Federal Trade Commission (FTC) Safe Guards and Federal Finance Interagency Examination Counsel (FFIEC) IT Security requirements are mandated. MISMO must supply flexible and secure methods to ensure the safety and non-disclosure of information for the mortgage industry.
Confidentiality and privacy are often used synonymously. There are several methods to achieve privacy of information from strong access controls to encryption. Transactional data within an enterprise and between partners is exposed as it moves across a network, and encryption is the recommended method for confidentiality. MISMO Version 3 provides greater support of element encryption, and embedded XML and WS-Security mechanisms. This MEG outlines some of the basic methods to encrypt sensitive information.
There are two basic encryption approaches:
- XML Encryption
- WS-Security SOAP Message Security
Both XML Encryption and SOAP use similar structure and syntax. MISMO developers have the ability to encrypt native XML or wrap confidential information in a SOAP envelope depending on their requirements or implementation.
2.1 Namespaces
| namespace |
location |
| env |
http://www.w3.org/2003/05/soap-envelope |
| dsig |
http://www.w3.org/2000/09/xmldsig |
| xenc |
http://www.w3.org/2001/04/xmlenc# |
| wsse |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd |
| wssu |
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd |
| wsse11 |
http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd |
| mismo |
http://www.mismo.org/residential/2007/schemas |
3. XML Encryption
XML encryption is used at the application layer. The selection of XML encryption depends on the business use case scenario and risk requirements. An advantage of XML application encryption is that it protects both data-at-rest and data-in-motion. Data that resides on any media or less-restricted devices can be encrypted. XML applications can decrypt information as required at processing time. Developers packaging information for transmission, either within the enterprise or along external networks, can ensure confidentiality regardless of the transport.
The W3C XML Encryption Syntax and Processing recommendation Section 3 defines the EncryptedData element, and Section 2 provides examples how XML data may be encrypted. The following discussion is explanatory and drawn from the W3C recommendation.
EncryptedType is the abstract type from which EncryptedData and EncryptedKey are derived. Implementation MUST generate schema valid EncryptedData or EncryptedKey as specified by the subsequent schema declarations.
- The EncryptedData element is the core element in the syntax. Not only does its CipherData child contain the encrypted data, but it‘s also the element that replaces the encrypted element, or serves as the new document root.
- The CipherData is a mandatory element that provides the encrypted data. It must either contain the encrypted octet sequence as base64 encoded text of the CipherValue element, or provide a reference to an external location containing the encrypted octet sequence via the CipherReference element.
- EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm must be known by the recipient or the decryption will fail.
- There are three ways that the keying material needed to decrypt CipherData can be provided:
- The EncryptedData or EncryptedKey element specify the associated keying material via a child of ds:KeyInfo.
- A detached (not inside ds:KeyInfo) EncryptedKey element can specify the EncryptedData or EncryptedKey to which its decrypted key will apply via a DataReference or KeyReference.
- The keying material can be determined by the recipient by application context and thus need not be explicitly mentioned in the transmitted XML.
- Additional information items concerning the generation of the EncryptedData or EncryptedKey can be placed in an EncryptionProperty element (e.g., date/time stamp or the serial number of cryptographic hardware used during encryption).
3.1 Encryption Example
Consider the following fictitious borrower information, which includes address and identification information: <Borrower xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<Address Street='123 Main St' City='Springfield' State=”IL”>
<SSN>123 56 7890</SSN>
<DOB>01/01/1970</DOB>
</Address>
</Borrower>
Algorithm and Key information have previously been negotiated.
3.2 Encrypting an XML Element
Smith‘s Social Security Number (SSN) is sensitive information. If the parties wish to keep that information confidential, it can encrypt the Address element: <Borrower>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Borrower>
By encrypting the entire Address element from its start to end tags, the sensitive information in the element itself is hidden. The CipherData element contains the encrypted serialization of the Identity element.
3.3 Encrypting XML Element Content (Elements)
As an alternative scenario, it may be useful for intermediate agents to know the borrower’s address, but not the borrower‘s SSN and DOB. In this case, the content (character data or children elements) of the Address element is encrypted: <Borrower>
<Name>John Smith</Name>
<Address Street='123 Main St' City='Springfield' State=”IL”>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</Address>
</Borrower>
3.4 Encrypting XML Element Content (Character Data)
Or, consider the scenario in which all the information except the SSN can be in the clear, including the fact that the SSN element exists: <Borrower>
<Name>John Smith</Name>
<Address Street='123 Main St' City='Springfield' State=”IL”>
<SSN>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</SSN>
<DOB>01/01/1970</DOB>
</Address>
</Borrower>
Both Address and SSN are in the clear, but the character data content of SSN is encrypted.
3.5 Encrypting Arbitrary Data and XML Documents
If the application scenario requires all of the information to be encrypted, the whole document is encrypted as an octet sequence. This applies to arbitrary data including XML documents. <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
MimeType='text/xml'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
4. SOAP Message Security
SOAP Message Security is used at the transport layer. The selection of SOAP Message Security depends on the business use case scenario and risk requirements. The primary use for SOAP encryption is data-in-motion and can ensure confidentiality of sensitive information regardless of a transport method. SOAP Message Security can be used for both enterprise and external transmissions.
One recommended best practice is to encrypt the entire Body when encryption is used at all. Encrypting portions of the payload may be secure, but various vulnerabilities are possible. Therefore, the example is for entire Body encryption.
See the “Use of the MISMO Envelope (SOAP)” - MEG0030 for additional information on SOAP and security.
4.1 SOAP Full Payload Encryption
<soapenv:Envelope>
<soapenv:Header>
<wsse:Security xmlns:wsse="..." xmlns:ds="..." soapenv:mustUnderstand="1">
<xenc:EncryptedKey >
<xenc:EncryptionMethod Algorithm="...#rsa-oaep-mgf1p">
<ds:DigestMethod Algorithm="...#sha1"/>
</xenc:EncryptionMethod>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier EncodingType="...#Base64Binary"
ValueType="...#X509SubjectKeyIdentifier">CuJd...=
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>Hyx...=</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#encBody"/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
<wsu:Timestamp wsu:Id="Timestamp" >
<wsu:Created>2007-03-26T16:53:39Z</wsu:Created>
</wsu:Timestamp>
<wsse:BinarySecurityToken wsu:Id="bst" ValueType="...#X509v3"
EncodingType="...#Base64Binary">MIID...=</wsse:BinarySecurityToken>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm=".../xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="...#rsa-sha1"/>
<ds:Reference URI="#Timestamp">
<ds:Transforms>... </ds:Transforms>
<ds:DigestMethod Algorithm="...#sha1"/>
<ds:DigestValue>+g0I...=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#Body">...</ds:Reference>
<ds:Reference URI="#bst">..</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>RRT...=</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference >
<wsse:KeyIdentifier EncodingType="...#Base64Binary"
ValueType="...#X509SubjectKeyIdentifier">Xeg5...=
</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="Body" >
<xenc:EncryptedData Id="encBody" Type="...#Content"
MimeType="text/xml" Encoding="UTF-8" >
<xenc:EncryptionMethod Algorithm="...#aes256-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>W84fn...1</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
5. REST Message Security
REST Web Services involve data in motion, and while REST Web Services support encryption, they do not mandate when to use encryption. It is up to each REST-WS application to determine whether the representation data it transfers is sensitive and when encryption is needed. Many lending applications use only public MISMO Logical Data Dictionary items, which is not sensitive and can be exposed without compromising privacy or security.
Consider a hypothetical interest rate data service. Many newspapers today publish the current interest rates of local lenders to make it easy for readers to compare rates. Participating lenders do not demand any security measures to be applied to their interest rates, and publish them willingly and without restriction. These lenders could easily publish their rates using a REST Web Service. Such an interest rate data service would require no security measures at all, so there is no reason to encrypt the interest rate data. Exposing public data like interest rates to the Web in unencrypted form can encourage unexpected applications for that data to emerge. For instance, we would expect newspapers to create applications to format the interest rate data of local lenders for publication. But unexpectedly a real estate agency could also create an application to compare local lender interest rates in real time.
Many REST-WS applications do transfer sensitive data-in-motion and do require data encryption. These applications can combine transport layer encryption with representation data encryption as befits the application. If the REST-WS application requires authentication, or if the representation is not an XML document, it is often simplest just to encrypt the transport layer. When the transport layer is encrypted, that removes the requirement to encrypt the transferred representation.
When using an insecure network, and the data representation is an XML document that includes sensitive information which must be encrypted, the REST-WS application can choose to encrypt the data instead of encrypting the transport layer. The application may choose to encrypt the entire body of a representation, or just its sensitive elements at either the content or element level. Encryption methods found within XML Encryption Syntax and Processing and illustrated earlier show how to do this. Using granular encryption methods ensures that sensitive representation data can be encrypted while public data can remain unencrypted.
In sum, it is both secure and permitted to expose public data elements on the Web, so a representation that includes encrypted sensitive and unencrypted public data elements is considered to be secure. There are uses for MISMO data that do not require encryption at all, but when encryption is needed, an encrypted transport layer and encryption methods from XML Encryption Syntax and Processing are sufficient to provide the confidentiality of sensitive information within REST Web Services. Transparently exposing public data elements should encourage the emergence of unexpected and useful applications.
Content
Guidelines
| Ref |
Guideline |
| MEGNumber.1 |
Guideline Content for number 1 |
| MEGNumber.2 |
Guideline Content for number 2 |
Metadata
Version .01
05/22/2008
| Release History |
| Date |
Release |
Comments |
| 05/22/2008 |
.01 |
Initial Version |
| Changes Since Last Version |
| Note |
| Contacts |
| Name |
Organization |
Contact Details |
| MISMO Staff |
MISMO |
info@mismo.org |
| Metadata |
| Element |
Description |
| Title |
MEG0029 XML Encryption of MISMO XML |
| Identifier |
MEG0029 |
| Category |
Information Security |
| Publisher |
MISMO |
| Rights |
Copyright of MISMO. All rights reserved. |
| Date Created |
05/22/2008 12:00:00 PM |
| Date Modifiend |
MM/DD/YYYY HH:MM:00 PM |
References