|
Public Key Infrastructures
1.1. Asymmetric key cryptography
Asymmetric (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.
Each 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).
The biggest advantage of asymmetric key cryptography is that the public keys are universally available through a directory which can be consulted on Internet.
Bob sends an encrypted document to Alice.
When 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.
Like 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.
1.2. Electronic signature
Owing 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 all).
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.
The 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.
1.3. Certificates
Asymmetric 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.
Prior 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.
1.3.1. Concept of certificates
A 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
1.3.2. Classes of certificates
Before 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:
- Class 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 of security.
Electronic signatures have no legal value in France without a class 3 certificate awarded by a state-recognized certificate authority.
2. XML TRUST
XML 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.
- WS-Security, offers a SOAP extension to check the integrity and confidentiality of messages, with a view to building secure Web services.
2.1. XML Signature
The 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 internal URI).
- Enveloped: The signature is embedded in the document that it is signing (internal URI).
- Detached: The signature references a document which is separate from the XML document (reference to an external URI).
The 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.
To 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 in SignedInfo.
In 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 signature.
- X509Data: The signatory's certificate written in standard X509 format.
- KeyName : The name of the signatory (more specifically, the name of their key).
- RetrievalMethod: References a location outside the document, containing information on the signatory.
The 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)
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.
2.2.1. X-KISS
Let 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.
The 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.
The 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 …).
The 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.
Using X-KISS to find a key from its name
2.2.2. X-KRSS
In 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:
- Key Registration
- Key Revocation
- Key Recovery
For 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 it.
2.2.3. 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 protocol.
2.3. WS-Security
WS-Security 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> element.
The following example shows the skeleton of a SOAP message using WS-Security:
The 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.
As well as managing integrity and confidentiality, WS-Security also defines a mechanism for Web Service authentication using a userName coupled with a password.
 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!
Bibliography and references
- Carlisle 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)
|
Understanding XML Trust
)