Requirements
and Goals for the
Design of
an 'XML Encryption Standard'
Gerald Huck and Arne Priewe
{huck, priewe}@darmstadt.gmd.de
Definitions
The following tries to identify some major requirements and also non-requirements for the definition of an
XML Encryption Standard (XES), and XML Encryption Language (XEL) for representing encrypted data.
In order to be able to express a certain need and priority we use a classification of requirements by using the words MUST, SHOULD, MAY, and MUST NOT as follows:
-
MUST
Requirements essential and indispensable for the standard.
-
SHOULD
Requirements which are important for certain applications, but not really
show-stoppers if not fulfilled.
-
MAY
Requirements which are nice to have additional ‘sugar’.
-
MUST NOT
These are explicitly mentioned NON-requirements or non issues. Most of these
are better addressed by different activities.
3. XML Representation of Encrypted Data
5. Compliance of Encryption/Decryption Processors
6.4. Referencing
Encryption Information or Target Locations for Data
6.5. Backward
compatibility with existing parsers
R1.1 XES MUST define an XML representation/syntax for encrypted data.
R1.2 XES MUST describe the effect/semantic of encryption and decryption for its XML representations.
R1.3 XES MUST define all constraints which MUST be fulfilled for such a representation.
R1.4 XES MUST relate its work to the XML charter and it MUST define all dependencies and relationships to other XML activities and standards.
R1.5 XES MUST NOT rely on security features or functionality offered solely by certain protocols or applications.
Providing such an independence enforces and allows the usage of XES in a broad range of applications without binding XES already in its specification to limited usage scenarios.
R1.6 XES MUST offer the freedom to base encrypted data representations on different approaches for representing and retrieving keys, applicable transformations, and encryption algorithms.
R1.7 XES MUST define minimal and optional compliance requirements to be fulfilled by encryption and decryption processors.
R1.8 XES MUST discuss related security issues.
Design issues, limitations, possible security leaks and pitfalls, as well as relationship to other security related XML activities, or other security architectures need to be discussed. This part can address e.g. the role of signatures (XML-Signature), ACLs, PKIs, possible attacks caused by weak system design, etc.
R2.1 XES MUST provide for encrypted representations of well formed XML document constituents
These constituents can e.g. be derived from the XML Information-Set.
In addition it means, that XES MUST NOT rely on the existence of schema-information, i.e. can only cope with valid XML documents.
R2.1.1 XES MUST support encrypted representation of
- Elements (Each element with its attributes and content)
- Text Data (PC-DATA/CDATA at direct child level)
- Attributes (name and value of an attribute)
These represent the basic building blocks of an XML-Document. However, there exist additional levels of granularity and data within an XML-Document which could be target of encryption:
R2.1.2 XES SHOULD support encrypted representations of
- Attribute values
- Whole XML Documents (?)
- Processing-Instructions, comments, entities (???)
R2.2 XES MAY provide for encrypted representations of non XML data
These can e.g. comprise MIME-objects. However, XES should assume the existence of standardized XML representations for these, applying its standard XML-encryption to them. IT MUST-NOT be the scope of XES to define such XML representations.
R3.1 XES MUST represent encrypted data in XML (c.f. R1.1), and it MUST propose a normative XML Encryption Language (XEL) for representing encrypted data.
R3.2 XEL MUST be applicable to all items identified in R2.1, R2.2
R3.3 XEL MUST provide for appropriate and customizable representations for encryption information and encrypted data.
R3.4 XEL Encryption Information MUST identify
- applied serialization/transformation algorithms, extended by (optional) parameter data
- required keys, and chosen key-management methods for obtaining a key
- encryption algorithms, extended by (optional) parameter data
- the type of the encrypted data, e.g. element, pc-data, attribute,...
R3.4.1 XES MUST define a uniform naming scheme for serialization/transformation/encryption algorithms
R3.4.2 XES MUST define optional and required arguments of predefined, supported algorithms and their XML representation.
R3.4.3 Encryption Information MAY comprise additional integrity/authentication information if it relates to the encrypted data
Such information like Method Authentication Code (MAC) can be achieved via complementary approaches, e.g. XML-Signature. See also section 6.1 (Signatures)
R3.4.4 Encryption Information MUST NOT comprise authentication information
Authentication, i.e. rights in accessing and modifying data, are orthogonal to Encryption and needs to be addressed by complementary approaches – as these may also be applied to non-encrypted XML.
R3.5 XEL Encrypted Data MUST identify the chosen encoding for the encrypted data and the encrypted data itself.
R3.5.1 XES MUST support XML-Schema proposed representations for binary data, i.e. hex and base64.
R3.5.2 XES SHOULD support additional representations for binary data.
R3.6 XEL MUST provide for self-contained encrypted data representation which comprise encryption information together with the encrypted data.
R3.7 XEL SHOULD allow for separation of encryption information from encrypted data, and support stable reference mechanisms for addressing encryption information from encrypted data sections.
For various reasons (document modifications), XPath based references do not fulfil such stability criteria, whereas ID/IDREF attribute based approaches offer better stability.
R3.8 XEL MUST be able to provide only a minimum of plain-text information required for decryption.
This requirement ensures that attackers can not take advantage of too much plain-text meta-data.
R3.8.1 Encrypted XML Documents SHOULD not conform to original DTDs or schemas
Schemas provide for additional information, exploitable for attacks.
R3.8.2 Encryption MUST be applicable to encryption information.
E.g.: for additional transformations that have been applied before encryption.
R3.8.3 Plain-text encryption information MUST comprise:
- key-information and key-method which are needed to obtain a valid decryption key
- encryption algorithm and (optionally) its initialization parameters
- encoding of encrypted data
R3.8.4 Encryption Information for which encryption MUST be possible:
- the type of XML data encrypted
- chosen serialization and transformation algorithms
R4.1 XES MUST define an encryption mapping from plain-text XML-documents to encrypted ones.
R4.1.1 XES MUST
define the correspondence between XML encryption information and its
semantic with respect to the data exchanged and order in which serialization,
transformations, and encryption-algorithm have been applied.
R4.1.2 XES MUST define validity constraints for the separation of encrypted data and corresponding encryption-information
R4.1.3 The result of encrypting a well-formed XML-document partially MUST be a well-formed XML-Document.
R4.2 XES must define a decryption mapping from encrypted XML-documents to plain-text XML-documents.
R4.1.3 The result of decrypting an encrypted XML-document MUST be a well-formed XML-Document.
R4.3 XES MUST define the location/position of decrypted data.
We propose here also a scheme which eliminates the need for XPath expressions identifying the target location. Instead, encrypted representations of elements or PC-DATA should obey a simple replace semantic, i.e. they will exactly be placed at the location where the encrypted data was positioned before.
Changing the context (either by moving the XEL representation or defining a new parent) will then have the same effect as for the corresponding plain-text representation.
Attributes are different things as they only exist as long as the element for which they are defined exists. Therefore, XEL representations should utilize an ID/IDREF addressing scheme to identify the element for which an XEL attribute representation is defined. If the containing plain-text element has been removed, the decryption of the encrypted attribute will not have any effect.
R4.4 XES MUST support further modification of partially encrypted XML-documents
R4.4.2 Decryption MAY fail, if XEL constituents have been removed or modified.
R4.4.1 Decryption MUST NOT fail if the plain-text context has changed, but no modifications have been applied to XEL constituents.
Note that these requirements also apply to our interpretation of location/position for encrypted representations – as the XEL element identification attribute has been removed, whenever the corresponding plain-text element has been removed.
R4.5 XES MUST support multi-key encryption
R4.5.1 Different parts of a document MUST be en-/decryptable via different keys.
This requirements describes the case where different parts of a document are intended for several, different recipients
R4.5.2 The same part of a document MUST be en-/decryptable with several optional keys.
This requirements describes the case where one key out of several keys suffices to decrypt data.
R4.5.3 The same part of a document MUST be en-/decryptable with several mandatory keys.
This requirements describes the case where all keys are needed in order to be able to decrypt data.
R4.6 XES MUST support recursive encryption (encryption of already encrypted parts)
R4.6.1 Recursive encryption MUST guarantee that any encryption information of already encrypted data is preserved.
This is a very subtle requirement. It prevents from accidental removal of encryption information which has been separated from encrypted data referring to it. Encrypting such encrypted data representations again can lead to the situation that no unencrypted encrypted data representation refers any longer to such encryption information – and thus can be removed accidentally. Copying such information when re-encrypting encrypted data allows to safely remove such encryption information.
R5.1 XES MUST predefine a set of key-identification and key-management methods to be supported by a compliant processor.
This minimal set could e.g. comprise: Standardized key identification (e.g. from X509), Key agreement (e.g. X9.42), in band Key transport (e.g. RSA), out of band Key transport (e.g. 3DES)
R5.2 XES MUST facilitate integration and usage of additional key-identification and key-management methods.
R5.3 XES MUST predefine a set of content encryption algorithms to be supported by a compliant processor.
The algorithms need carefully to be chosen, regarding availability, legal issues, performance, and strength of encryption. These standard algorithms MUST at least comprise one algorithm which is resistant against known plain-text attacks and chosen plain-text attacks.
R5.4 XES MUST facilitate integration and usage of additional content encryption algorithms.
R5.5 XES MUST predefine a set of key encryption algorithms to be supported by a compliant processor.
R5.6 XES MUST facilitate integration and usage of additional key encryption algorithms.
R5.7 XES MUST predefine a set of serialization/transformation algorithms
These algorithms address environmental needs, e.g. arising from XML-Signature, by allowing the definition of additional transformations to be applied to XML-Data before encryption takes place, e.g. normalization or compression.
R5.8 XES MUST facilitate integration and usage of additional serialization/transformation algorithms.
R5.9 XES MAY define some constraints enabling the efficient processing of partially encrypted XML documents.
Especially when using stream based parsing approaches (SAX) for decryption, all required encryption information should be given prior to its usage. Such constraints need not, but could be part of XES.
When executing sign/crypt it MUST NOT be possible to remove signatures without being able to be noticed, and it SHOULD NOT be possible to observe the existence of the signature before decrypting the data. Therefore we suggest to encrypt the signature together with the signed and encrypted data.
When using crypt/sign it SHOULD be possible to notice if the signature was removed.
By embedding references to outer signatures inside the ciphertext, it would be possible to guarantee this.
Another issue about signatures is the point of a possibly weak security design, as discussed on this mailing list.
We think that signatures can have two different meanings that often are not exactly distinguished.
The first meaning is pure technical (authentification, integrity and non reputability), saying something like “I have signed this stuff and so I’m responsible for it, if it wasn’t changed”. We see no big problems with this point.
But the user must be aware that this meaning is only correct for the signed data itself. It may not be correct for any not signed data in the same document or data presented together with the signed data inside an application.
This second meaning is binding a semantic between the signed data and the application context. Here start the problems. The designer of an application or protocol can try to avoid them, so that users can’t make a mistake by making a wrong conclusion. For an email this would mean to sign the receiver, the sender and the subject together with the body. Depending on the design for an XML application this could even mean that the source URI must be signed together with the whole XML document, e.g. if an attacker could simply copy and paste a signed document to another location that changes the user’s interpretation of the content.
We believe that problems evolving from this second meaning of a signature can’t be solved for all applications by some simple standard rules like a <from /> tag. It depends on the application/protocol design.
So we suggest that these problems should be explained broadly with some examples for good and bad designs and the pitfalls that can occur (see section 1, R1.8).
The previous point (embedding references to outer signatures), but also the need for encrypting encryption information, gives rise to the design issue, if beside the visible plain-text XML representation of encrypted data, there should co-exist an encrypted XML envelope as well. This envelope could capture these kinds of information in a safe way and would naturally be part of the encrypted XML data.
Appropriate choices for serialization algorithms or transformations should address requirements of XML-Signature which requires particular normalizations to be applied before signing.
For encryption, we suggest incorporation of AES and IDEA (symmetric block cipher algorithms) which offer good security properties as well as the various ones already proposed in the mailing list.
To increase security, we suggest that for some algorithms the parameterization with initialization vectors should be mandatory whenever used by encrypted data. This is in contrast to some proposals in the mailing list which allows the definition of one initialization vector for multiple encrypted data items or give the responsibility for creating IVs to an external protocol. Instead of explicitly modeling such vectors in XML, they could be implicitly represented in the binary encoded data sections as headers (of fixed length) (similar to the IDEA standard).
We strongly suggest the incorporation of redundancy-removing or randomizing transformations, e.g. by compression prior to encryption, as it has been proven to increase the overall security of block cipher algorithms as DES or IDEA (Handbook of applied cryptography by A.Menezas et.al., CRC Press Inc, 1997, p227 ).
In order to be able to reuse and separate encryption information from encrypted data, several proposals use XPath expressions or implicit, relative addressing to refer to encryption information (but also to target locations for encrypted data). These approaches are very brittle with respect to further modification of the document as they can easily break the validity of XPath expressions.
Following the ‘keep it simple’ paradigm, one can easily see that XPath is an overkill. XPath locates node-sets, but when looking at the addressing problem above, one can observe that it suffices completely to address ONE SINGLE ELEMENT containing the encryption information, or serving as target element, e.g. for attributes. For these scenarios, XML itself already provides a solution: The use of ID/IDREF attributes.
For existing XML applications there SHOULD be a standardized way to guarantee backward compatibility. The hardest requirement for this purpose is, that the schema of the documents may not be altered (deleting, appending, inserting or altering any elements or even attributes). In this mailing list external encryption infos and XPath together are proposed as a solution.
We suggest a simple and straightforward solution:
- The source document is encrypted so that all tags are preserved (e.g. don’t encrypt elements, but only PCDATA). At this point tags are added to the document that replace the sensitive information. But no tags are deleted, altered or appended.
- The encrypted nodes contain the needed decryption information as inner elements.
- Until here everything was done the usual way. Now the encrypted nodes are completely base64 encoded, so that all added tags are substituted with PCDATA. As a result the source schema has not been touched.
We agree that this is more a kind of a hack as a clean XML design. But it should work well and has some advantages. No XPath or external documents are needed and it is easy to implement. The existing application must only be minimally changed. The only disadvantage is that the application must either know in advance which data in the documents are encrypted or must try if any PCDATA (decoded with base64) contains encrypted XML elements. But this is similar to the point that a solution with XPath needs to know in advance where it can get the external encrypted data.