SIGNING XML FILES
The current version of BlueRidge supports the signing of XML documents according to the XMLDSIG standard. The next version of BlueRidge will support XML Advanced Electronic Signatures (XAdES). XAdES extends the XMLDSIG specification, it is a standard that is designed and used to sign XML documents. Functionally, it has much in common with PKCS#7 but is more extensible and focused on signing XML documents.
The extensions are addressing non-repudiation in particular. This is achieved by adding several additions to the XMLDSIG node in a XML document. These additions can be thought of as being organized in ‘layers’ around the core electronic signature defined by XMLDSIG. The different methods of adding information to achieve a signature that cannot be repudiated, even over many years of time, are below:
LEVEL
0
1
2
3
4
5
TYPE
XAdES
XAdES-T
XAdES-C
XAdES-X
XAdES-X-L
XAdES-A
DESCRIPTION
Basic extensions that do not provide non-repudiation, but add useful information to the XMLDSIG nodes.
Adds a timestamp to the signature.
Adds the complete certificate information and revocation information at the time of signing.
The information that XAdES-T and –C adds is not signed or protected by a signature. Therefore the XAdES-X adds a timestamp that is calculated over (part of) the information that was added by the lower layers.
Extension for the long term. Adds additional certificate and revocation data.
Extension that protects the signature against cryptographic data becoming weak. This is achieved by an additional archiving timestamp.
The BlueRidge Sign & Validate Service to sign XML documents consists of the following main components:
BlueRidge server
Optionally HSM: for instance BankSys Dep PCI/64 (FIPS 140-2 Level 2)
Includes the electronic signature service
Includes the server component for signature generation (with time stamping and OCSP certificate revocation checking support)
Includes the server component for signature validation
Client component for signature generation and validation
There are several schemes that BlueRidge supports to sign a XML document. In particular we use detached, enveloped and enveloping signature schemes, each with their advantages and disadvantages. This section will discuss these schemes and how they are used in BlueRidge.
DETACHED SIGNATURE
A detached signature is created as a separate document and includes the electronic signature and all properties needed to achieve a XML-signature. The advantage of this method is that the original document is left untouched, this means a third party can view the document using the proper visualization program (e.g. MS Word) without any further requirement. A disadvantage is that the management to keep the signature linked to the original document is more complex as they are both different documents that do not necessarily reference each other. The detached signature is normally used to sign non-XML (or non text based) documents.
ENVELOPED AND ENVELOPING SIGNATURE
Enveloped and enveloping signatures both reside in the document that is being signed. This has the advantage that the signature and the signed contents are both contained into the same document, which makes archiving management less complex.
Although enveloped and enveloping signatures are most frequently used to sign XML data, they can both be used to sign non-XML document types. In the latter case the following procedure is used:
The original document is converted to a text based octet string by converting it to base64.
A new XML document is created which embeds the encoded content along with metadata that indicates the type of document.
Then the signature (enveloped or enveloping) is applied on the document.
A disadvantage of this method is that the original document is not viewable anymore without an extra step, which is decoding the base64 data to binary data and then opening it with the appropriate visualization program. This extra step requires an extra program that does the conversion. On Windows systems the decoding software can be integrated into the shell so that if users double click a signed XML file the decoding is done automatically and the resulting file is opened in the appropriate visualization program.
Signature Generation Service
BlueRidge server has a XML signature service that provides both delegated and semi-delegated signature generation. This is done using a X509 v3 based certificate. A HSM can optionally be embedded in the BlueRidge server to store the private keys used by the Advanced Electronic Signature Service. The signature solution of BlueRidge consists of a server and a client component. The BlueRidge signature service allows the generation of detached (XML signature used to sign is located outside the original document), enveloped (signature request type for adding the resulting signature inside the original document) and enveloping signatures (signature request type for adding the document inside the generated signature).
The signature process is as follows:
Delegated signatures
The canonical form of the input XML is created.
The hash is calculated over the appropriate parts of the canonical XML document. The parts are selected by the reference(s) in the XML document.
The hash is signed using a certificate that is at the disposal of the server (through HSM or the Microsoft certificate store).
The signed XML document is composed. The signature can be detached, enveloped or enveloping.
The XML containing the signature can be stored locally.
Semi-delegated signatures
The canonical form of the input XML is created.
The hash is calculated over the appropriate parts of the canonical XML document.
The hash is transported to the client.
The hash is signed by the client component and transported back to the server
The signed XML document is composed. The signature can be detached, enveloped or enveloping.
The XML containing the signature can be stored locally.
The BlueRidge server can optionally be equipped with a HSM that enables it to create an advanced electronic signature by using a digital certificate to sign with the hardware signature calculating device. Multiple signatures to a single document are supported by BlueRidge. BlueRidge can communicate with a Time Stamp Authority and external CSP services.
All methods can be pre-configured for automatic use. Strong authentication and authorisation of client applications in order to regulate all accesses to the Advanced Electronic Signature service operations and hence to the HSM stored keys are achieved by requiring all accesses to the signature service to occur through a secured channel (i.e. SOAP over HTTPS). The Advanced Electronic Signature Service logs all sensitive operations executed on behalf of a client application.
Signature Validation Service
The BlueRidge signature validation service allows the verification of detached, enveloped and enveloping signatures. The solution performs an integrity check, as well as a check on the certificates and their chain up to a trusted certificate and a revocation check to check their validity at the time of signing. The system verifies the signature ensuring its compliance with the signature policy. The solution delivers to the user the validation results as well as the extended signature if requested. The Signature Validation Service supports SOAP over HTTP(s).
Path building and validation
A certificate needs to be traceable back to a trusted source, often called a root or anchor. When organizations issue certificates, those certificates contain references that point back to the issuing organization. Individual user certificates are usually signed with organizational certificates to provide proof of their source and authenticity and that it is subject to the rules of requirements established by that organization.
Revocation checking
In revocation checking, the signing or verifying application may contact the issuer of a certificate and requests information about the current status of the signing certificate. The issuer sends a response indication whether the certificate is valid or has been revoked. Certificates may be revoked for many reasons, such as a lost smart card, or fraudulent activity. Revocation checking lends more credibility to a digital signature because it can provide a real-time status of a certificate at the time of signing. The BlueRidge solution uses an advanced revocation verification scheme.
For revocation checking we support:
Imported CRL’s on local file system or file share
CRL distribution points in the certificate (HTTP, LDAP and OCSP)
(If required, CRLs from specified distribution points can be downloaded and cached to the server at specified times.)
Interactive LDAP servers configuration
Interactive OSCP verification
Time stamp validation
This solution allows the verification of a AdES compliant signature. The verification process is done on the BlueRidge server and can be pre-configured for automatic use. The user can view the verification result and the extended signature is also delivered to him if requested.
Certificate Validation Service
Prior to signing, BlueRidge checks if the digital certificate can be used for signing. When a client application receives a digital certificate, BlueRidge has to decide whether this certificate can be trusted and whether it can be accepted in the current application context.
The validation of a certificate against a validation policy implies several steps. First, the complete certificate chain, from the end-user certificate up to a trusted CA certificate, has to be built. The parameters for validation of a certificate (such as the trusted anchors) can be pre-configured for automatic use. Once a valid certification chain has been established, a full revocation status check of the complete certification chain has to be performed. This check can be done against various CSP revocation services available like the CRL or OCSP servers.
Only valid certificates can be used for signing. The Certificate Validation Service is compliant with this RFC-3280 standard.
Signature Browser Plug-in
The Signature Browser Plug-in is used when the certificate to be used for signing is located in the keystore of the local computer and the user signs in semi delegated mode. So, the Signature Browser Plug-in acts as a bridge between the web application and the keystore on the computer of the user. By using a HTTP(s) based client-server communication protocol, problems with firewalls are greatly reduced.
This module is available as a Java applet and a .Net ActiveX version.
Time Stamping Service
Some transactions and records are time-sensitive, and often electronic records need to record the time of signing in a verifiable manner. The most accurate way to establish the time of signing is to add a secure time stamp to a digital signature. A secure time stamp is a standards-based method (based on RFC 3161) for recording the time of a transaction.
BlueRidge supports time stamping. A Time Stamping Authority providing trusted time stamp tokens is required by the Advanced Electronic Signature Service when promoting an existing AdES signature to one of the extended forms that requires a time stamp. In this case the program will fetch a time stamp upon creation of the signature from a Time Stamp Server. The program calculates a hash value of the document to sign. This hash is packed into a timestamp request and is sent to the Time Stamp Server. Only the data file’s unique hash value is transmitted, sensitive data is never transmitted outside the client. The Time Stamp Server adds the current time to the hash value, signs it, and generates a time stamp according to [RFC3161]. This time stamp is delivered back to the BlueRidge server as a DER coded ASN.1 stream. All client to server communication is HTTP(s). The TSA response is then incorporated in the signature itself. When the BlueRidge server validates the signature, not only the signature and its integrity are checked, but the time stamp can also be validated online with the Time Stamp Server. The software uses the public key to prove the time stamp is authentic.
Copyright 2014 © All Rights Reserved.
