XML Security XML Signature

XML Signature and Canonical XML 2.0 drafts available

The W3C has published two first drafts XML Signature Syntax and Processing and Canonical XML of the upcoming version 2.0.

The new XML Signature version promises more simplicity and more performance. Chapter 10 lists the differences to the current version. In short: New namespace dsig2, Canonical XML 2.0 and a completely changed transformation model which isn't that general any more (which is good, since the completely open one we are using now may lead to a lot of security problems). The new one now separates between selection and canonicalization, which includes the new Selection element. In short this element chooses the data object that is to be signed.

Canonical XML 2.0 brings in more performance and more security. It is still designed for XML 1.0, not XML 1.1 (so still no canonicalization for XML 1.1 out there). And as written above it is required for XML Signature 2.0.

Since these are the first public drafts some things will change until the final recommendations will be available.

XML Encryption XML Security XML Signature

Apache Santuario 1.4.3 available

Version 1.4.3 of Apache XML Security (Santuario) is available. In case you do use this API you should update as soon as possible to the new release. This release doesn't provide any new features, but includes a lot of bug fixes, including a correction for the relatively serious security vulnerability that has been discovered lately.

XML Security XML Signature

HMAC truncation authentication bypass in XML Signature

There is a vulnerability with XML Signatures. The W3C recommendation includes support for HMAC truncation, as specified in RFC2104. The thing is, this support is not complete: The RFC does not allow truncation to less than half of the length of the hash output or less than 80 bits (whatever comes first). The XML Signature recommendation ignored this part of the RFC up to now. So when HMAC truncation is under the control of an attacker this can result in an effective authentication bypass.

On one side this is serious since it is possible to specify an HMACOutputLength of 1, so that only one bit of the signature is verified. This can allow an attacker to forge an XML Signature that will be accepted as valid. US-CERT lists the vulnerable products. Apache XML Security up to version 1.4.2 is vulnerable (among a lot of other products). Since version 1.4.3 should be available tomorrow (including a fix for this bug) at least Apache XML Security users will be on the safe side again. And on the other side the HMACOutputLength feature is not that widely used, so there is no need to panic.

The upcoming XML Signature 1.1 recommendation is already updated. See the Q&A page contains some additional information.

XML Signature

XML Signatures for widgets

The WebApps working group has published a first working draft of the Widgets 1.0: Digital Signatures recommendation. This is normally neither my working nor my research area. But this recommendation makes already use of XML Signature 1.1 and is a really cool and obvious usage scenario for XML Signatures. Since the widgets are based on XML there is no better possibility to sign this data than using XML Signatures. Maybe this is the killer (end user) application for XML Signatures that has been missing so far…

Java XML XML Encryption XML Security XML Signature

A whole bunch of new XML Security working drafts

The W3C XML Security Working Group has released eight first public working drafts last week, from updated XML Encryption 1.1 and XML Signature 1.1 specifications to even some new ones. Among others, these drafts include revisions to XML Signature and XML Encryption to support new algorithms and a new document proposing simplifications to the XML Signature Transform model to enhance performance and security.

XML Signature Best Practices experienced some updates to match the latest recommendations. XML Security Derived Keys, XML Signature Properties, XML Security Algorithm Cross-Reference and XML Security Use Cases and Requirements are completely new specifications.

XML Signature Syntax and Processing Version 1.1
This version mostly replaces more or less unsafe algorithms like SHA-1 with SHA-256 or higher (well, SHA-1 is not replaced, it is still a required algorithm, but SHA-256 is required too). Additionally elliptic curve cryptography has arrived in the recommendations in form of the ECPublicKey element and of course the matching algorithms. And we are confronted with a new digital signature namespace Check out the diff-marked version for all changes.

XML Encryption Syntax and Processing Version 1.1
Some updates on required and recommended algorithms too. Elliptic Curve Diffie-Hellman is now a required Key Agreement algorithm. Not too many changes here; and I couldn’t find a diff-marked version.

XML Security Derived Keys
This completely new specification defines a derived key XML type and associated elements, both used in XML Signature and XML Encryption.

XML Signature Properties
Signature properties are nothing new. Up to now it is possible to define any signature property one desires. This is still possible in the future, but this new recommendation will define some commonly used ones. Four properties are defined so far: Profile, Role, Expires and ReplayProtect. I guess we will see some more in the final recommendation…

XML Security Algorithm Cross-Reference
Another new document. And a really, really good idea! This reference contains all algorithms and their corresponding URI used in all XML Security recommendations. Bookmark this page, and never use an incorrect URI again!

XML Signature Best Practices
A collection of best practices, mostly security related, for implementers and users of the XML Signature recommendations. Not everything will be useful in every environment, but clearly this document points into the right direction of making a complex recommendation more practical in the daily usage.

XML Security Use Cases and Requirements
This document summarizes use cases and requirements driving revisions to XML Signature, XML Encryption and XML Canonicalization. Not that interesting for XML Security users.

XML Signature Transform Simplification: Requirements and Design
I like the idea behind this document. Basically it recommends replacing the current reference processing model with a simpler one. And simplicity is always good for security (and for performance). What may(!) happen is an extended Reference element with Selection, Transform and Canonicalization child elements. The Selection element chooses what is to be signed. The Transform element makes sure that you only sign what you see (it has a limited number of transformations that for). And finally the Canonicalization element is used to produce the input for the hash. So the reference processing may change a little bit in the future.

Java XML XML Security XML Signature

Best Practices für XML Signatures

Das W3C hat vor einigen Tagen unter eine Sammlung von 16 Best Practices für die digitalen Signaturen mit XML veröffentlicht. Noch ist es ein Working Draft (d.h. Kommentare sind bei der Working Group willkommen), aber ein erster Blick darauf kann keinem schaden, der mit XML Signatures zu tun hat.

Generell geht es mit den Best Practices darum, die Anzahl möglicher Attacken auf XML Signaturen zu reduzieren und somit natürlich die Sicherheit zu erhöhen. Grob vereinfacht, weniger Komplexität, mehr Sicherheit. Und da sticht Best Practice 3 besonders hervor:

Consider avoiding XSLT Transforms

Genau so wie Nummer 4:

Try to avoid or limit XPath transforms

Allein mit den beiden schon seit längerem bekannten Tipps hat man bereits viel gewonnen und eine große Menge Komplexität entfernt. Dass entspricht genau dem Wunsch vieler, die XML Sicherheit modular aufzubauen und in den Implementierungen nur die Features anzubieten, die man wirklich benötigt.

Best Practice 11 finde ich dagegen wenig hilfreich:

Unless impractical, sign all parts of the document.

OK, es gibt die Einschränkung Unless impractical, aber ein gigantischer Vorteil der XML Sicherheit (ob Signatur oder Verschlüsselung) ist es ja wohl, dass man gezielt einzelne Dokumentfragmente sichern kann. Wenn ich immer alles signiere bin ich, bis auf die XML Syntax, wieder zurück bei den herkömmlichen Signaturvarianten, und davon will ich mit der XML Sicherheit ja eigentlich weg. Für mich ein unbrauchbarer Tipp.

Nichtsdestoweniger lohnt es sich, das Dokument zu lesen und möglichst viele der Best Practices (sofern sie denn passen) in eigenen Implementierungen zu verwenden.