1.1. Asymmetric key cryptography
(or public key) cryptography was devised in order to avoid exchanging
secret keys prior to every secure transaction. It is a means of encryption
that relies on two keys: the public key and the private key.
party has a pair of keys: one private key which must be kept secret, and
one public key which is transmitted to other parties. The two keys are
complementary: there is only one public key to match any given private
key, and vice versa. A document which is encrypted with the public key
can only be read using the private key, and vice versa. This principle
of uniqueness ensures that only the recipient will be able to decrypt
the message sent to him.
To exchange an encrypted document, the principle is as follows: The recipient's
public key (known by all parties) is used; only the recipient will be
able to decrypt the message using his private key (known only to him).
biggest advantage of asymmetric key cryptography is that the public keys
are universally available through a directory which can be consulted on
Bob sends an encrypted document to Alice.
Bob tries to send an encrypted document to Alice, he looks for Alice's
public key, and then encrypts the document with it. On receipt, only Alice
can decode the document using her private key.
symmetric key encryption, the time that a hacker will take to break the
code depends on the length of the key. Clearly, it is best to use the
longest possible keys. Asymmetric key algorithms are more complex and
therefore much slower than those used for symmetric keys. In practice,
therefore, they are used to exchange a symmetric key which is then used
for the rest of the transactions between parties.
to the complementary nature of the keys used in asymmetric cryptography,
they can also be used in the opposite direction to authenticate the other
party. So, to certify the origin of a document, the sender uses his private
key (which only he knows) to encrypt it, and the sender's authenticity
can be checked by the receiving party, using the public key (known to
make sure that the initial document has not been altered during transit
from sender to recipient, a one-way hashing algorithm is used to calculate
the digital footprint.
principle is as follows: a footprint is created from a document (the footprint
is a downgraded fixed-size version of the original document which cannot
be used to recreate the document), and then this footprint is encrypted
using the private key. The encrypted footprint forms the signature applied
to the document. It will be routed with the document to the recipient,
who uses the same hashing algorithm to recalculate a footprint which will
be compared to the one that was received. If the footprints mismatch,
it shows that the document has been modified during transit; the footprint
therefore guarantees the integrity of the document.
Creation of a document signature.
Lastly, asymmetric cryptography also incurs the sender's liability: the
sender cannot then deny having sent a document, as he alone possesses
the private key used to sign it. This is known as the principle of non-repudiation.
cryptography is used for secure communication between two parties, whether
they are individuals or server machines. However, it should be noted that
for any secure communication the other party should be known: exchanging
encrypted messages with an unknown party gives no guarantee of the other's
intentions. Likewise, paying for an item by secure transaction on a server
whose owner is unknown gives no guarantee that the item will be delivered.
to any secure exchange comes the issue of the identity of the other party.
In order to be sure of this, there should be a sort of electronic identity
card: this is the role of digital certificates.
Concept of certificates
certificate is a file signed with the private key of a trust service provider
or certificate authority (CA). It contains the holder's public key and
credentials (first and last names, email, possibly also the address).
When the certificate is presented to a third party, this party checks
the signature of the CA using their public key, available on their site.
The identity of the certificate-holder is then guaranteed by the trust
granted to the CA. So, just as we trust the holder of a credit card via
the body which delivered it, so we trust the holder of a certificate through
the certificate authority that delivered it.
Moreover, the holder can at any time invalidate his certificate by revoking
it (if the private key has been stolen, for instance). The certificate
authority can do the same (if for example the holder has used the certificate
for unlawful purposes). The certificate authority therefore keeps an up-to-date
directory of valid certificates, so that these can be checked at any moment.
Use of certificate
Classes of certificates
awarding a certificate, the CA must make the necessary checks on the identity
of applicants. CAs may produce the certificates themselves, or delegate
this to PKI operators. CAs have public directories from which the public
keys can be retrieved. There are three classes of certificates for three
degrees of guarantee of the identity of the user:
1: A class 1 certificate is obtained by filling out a form on the Internet,
and therefore does not give any guarantee of identity as there is nothing
to stop the applicant from providing false details.
Class 2: To award a class 2 certificate, the CA requests the candidate
to send a photocopy of their ID card and a signed agreement by post.
The certificate is then sent by email.
Class 3: Lastly, a Class 3 certificate is presented in person to the
applicant, who must go to the offices of the certificate authority.
Sometimes, to simply the process, the applicant is not required to travel
in person to the CA's premises, but instead receives the certificate
by registered post with acknowledgement of receipt. It is therefore
the postal service that checks the applicant's identity before delivering
the certificate. The Class 3 certificate offers the greatest degree
signatures have no legal value in France without a class 3 certificate
awarded by a state-recognized certificate authority.
Trust is a set of XML-based specifications which, in addition to traditional
PKI infrastructures, enable Internet-based exchanges to be protected in
a standard fashion.
The main technologies for ensuring trust during Internet transactions
are as follows:
XML Signature defines an XML syntax for electronic signatures.
XML Encryption encrypts XML documents using asymmetric encryption technology
to ensure confidentiality during transfers.
XKMS simplifies access to PKI infrastructures by defining a standard
interface and a simple XML-based protocol to manage certificates.
SAML provides a common language to describe and manage authorizations.
offers a SOAP extension to check the integrity and confidentiality of
messages, with a view to building secure Web services.
XML Signature specification defines an XML syntax for representing electronic
signatures, based on existing technologies (XML, XPath, XLink, namespaces
and so on). It also defines the procedures for creating and verifying
signatures. The signed data might be an XML document, independent elements
in an XML document, or external data referenced by XPointer. Three types
of signature exist:
Enveloping: The signature envelopes the content to be signed (via an
Enveloped: The signature is embedded in the document that it is signing
Detached: The signature references a document which is separate from
the XML document (reference to an external URI).
root element Signature contains a SignedInfo element which provides information
on the means of obtaining the footprint, and a SignatureValue element
containing the value of the footprint encrypted with the private key.
validate the signature, the recipient decodes the footprint contained
in SignatureValue using the signatory's public key. The recipient then
compares it with the footprint obtained by following the instructions
addition, the signature may contain an optional KeyInfo element which
gives information on the signatory. It can indicate:
KeyValue: the signatory's public key to be used to decode the
X509Data: The signatory's certificate written in standard X509
The name of the signatory (more specifically, the name of their key).
References a location outside the document, containing information on
signatory may indicate some or all of this information. XKMS services
enable the recipient to retrieve the missing information.
2.2. XML Key Management Specification (XKMS)
is a specification from the W3C intended to simplify integration of PKIs
and management of certificates in applications. As well as responding
to problems of authentication and verification of electronic signatures,
it also allows certificates to be managed, registered or revoked.
XKMS services reside on a server and are accessible via a simple XML protocol.
The developer can therefore delegate part of the processing to the XKMS
service, thereby making it less complex to interface with the PKI.
XML Key Management Specification comprises two sub-services:
XML Key Information Service Specification (X-KISS) defines the specification
used to retrieve the information (owner, status, validity date…) corresponding
to a public key.
XML Key Registration Service Specification (X-KRSS) defines the protocol
for managing the lifecycle of a key (registration, revocation…).
An XKMS service is middleware for accessing the PKI.
us imagine an application receiving a message signed in compliance with
the XML Signature specifications. The specification indicates that the
signatory may provide optional KeyInfo elements used to authenticate the
signature. The signatory may, for example, attach his public key to the
message. There are then two verification phases for the signature:
Local verification carried out directly by the receiving application,
which consists in decoding the signature with the signatory's public
key, and comparing it with the footprint obtained locally. This stage
checks that the document has been correctly signed and has not been
tampered with during transfer.
The second stage involves contacting the XKMS service and requesting
information on the public key transmitted. This will make known the
identity of the signatory, and also checks that the key has not been
revoked (if it has been stolen, for example) and is valid (period of
validity observed, for example).
The X-KISS protocol is used to carry out the checks described in step
2 via two services.
locate service is used to find out the other attached information
from the data contained in KeyInfo. This may, for example, make it possible
to retrieve a public key from the signatory's name, or to find an owner
from a public key, or to obtain the information contained in an X509 certificate
that has not been parsed locally.
validate service makes sure that a key is valid. This means that
it has not be revoked, or that it can be used for a particular purpose
(signature, encryption …).
XML messages used by the protocol within the context of X-KISS may themselves
be signed. This guarantees the integrity of messages during transfer over
the Internet, and makes sure that the desired XKMS service is being conversed
with. For the validate service, this is mandatory.
X-KISS to find a key from its name
order to use the services of X-KISS, it is necessary to register the keys
with the XKMS service. All the procedures that manage the lifecycle of
keys are carried out using X-KRISS services:
all these services, authentication is ensured by a password (PassPhrase).
When the keys are registered, the user must provide this password, and
must repeat it to retrieve their private key if it is lost, or to revoke
XKMS message transport
Access to all XKMS services is carried out in request/response mode in
XML format. SOAP will often be used as the communication protocol, and
WSDL as the service definition language. However, this is not compulsory,
and certain implementations may offer their services through a different
is a recent specification which offers an extension for creating secure
Web Services by applying other XML Trust technologies to SOAP messages.
The integrity and authenticity of messages are guaranteed by XML Signature,
and confidentiality by XML Encryption. Information concerning the security
of the SOAP message is attached in the message header, in a new <security>
The following example shows the skeleton of a SOAP message using WS-Security:
signed data is inside the Body tag. The different parties using the Web
service can therefore rest assured that the message has not been altered
during transit over the Internet.
well as managing integrity and confidentiality, WS-Security also defines
a mechanism for Web Service authentication using a userName coupled with
This article is taken from the latest TechMetrix Research White Paper,
XML Trust: Technology and Implementation. To get the full story, download
the white paper for free!
Adams, Steve Lloyd & Stephen Kent, Understanding the Public-Key
Infrastructure: Concepts, Standards, and Deployment Considerations
- 1999, New Riders Publishing
XML Trust Center (www.xmltrustcenter.org)
XML Key Management, XML Trust Services (www.verisign.com)
VeriSign Digital Trust Services: Enabling Trusted Web Services (www.verisign.com)
XML Signature Specifications (www.w3c.org)
XML Encryption Specifications (www.w3c.org)
XML Key Management System Specifications (www.w3c.org)
WS-Security Spécifications (www.versign.com)