Introduction
Introduction
Introduction/scope
The SignServer is an application framework performing cryptographic operations for other applications. It's intended to be used in environments where keys are supposed to be protected in hardware but there isn't possible to connect such hardware to existing enterprise applications or where the operations are considered extra sensitive so the hardware have to protected more carefully. Another usage is to provide a simplified method to provide signatures in different application managed from one location in the company.
The SignServer have been designed for high-availability and can be clustered for maximum reliability.
From version 3.0 there also exists a mail signer framework that can be used to perform cryptographic operation on emails.
Drawing 1: Overview of a possible set up of a highly available SignServer solution
Changes from previous versions
Changes between Version 3.0 and Version 3.1
- A new Cluster Class Loader, simplifying the management of customized workers in a cluster. All the resource data including the classes themselves are stored in database and accessible from all nodes simultaneously. It is also possible to run multiple versions of the same worker in the same SignServer cluster, this is useful when migrating a worker to new code since both the old and new worker can be run at the same time.
- PDF Signer, Time-Stamp Authority and MRTD and their specific libraries have the possibility to build into separate module archives (MAR files) that have to be uploaded to the SignServer installation before usage, if the cluster classloader is enabled (default).
- Installation packages for Linux/Windows of both SignServer and MailSigner using generation software from Bitrock.
- New extended module for signing ePassports: MRTD-SOD.
- New modules for signing and validating XML documents.
- A new ODF Signer module that adds signature to ODF documents, such as : odt,ods,odt (tested with OpenOffice.org 3.1.0). Simple web page is added where ODF document can be uploaded for signing, and resulted signed document downloaded.
- A new OOXML Signer Module that adds signature to Office Open XML documents, such as docx,xlsx,pptx (tested with Microsoft Office 2007).Simple web page is added where open office xml document can be uploaded for signing, and resulted signed document downloaded.
- Validators for several document types as well.
- Java 5 is no longer supported.
- For minor changes see the change log at http://jira.primekey.se
Changes between Version 2 and Version 3
- Complete refactorisation of J2EE from EJB2 to EJB3 to simplify further development.
- Renamed component "Service" to "TimedService" since 3.0 supports other services.
- A "TimedService" can now be configured with a 'cron-like' settings to have services executed in other than just periodical intervals.
- A Validation Service API used to validate certificate from different issuers. The Validation Service API have it's own easy to use Web Service used to integrate with other platforms. A Group Key Service API used to generate and manage group keys, symmetric or asymmetric.
- Possibility to have customized authorization of requests, not just the built in client certificate authorization list.
- The name SignToken is changed to CryptoToken and introduced a new concept of ExtendedCryptoToken that supports symmetric operations.
- The RMI-SSL interface have been removed and replaced with a JAX-WS interface with a simple client framework supporting different load-balance or high availability policies.
- All request data have changed from serialization to externalization to be easier to translate to other platforms.
- A completely new MailSigner API based upon the JAMES SMTP server to perform automated cryptographic operations on e-mails very similar to the plug-ins for the SignServer.
- Java 1.4 is no longer supported.
- A lot of new JUnit tests in the test suite.
- A PDF Signer that can add a signature to a PDF document through a simple HTML interface.
- PKCS11 Crypto Token to connect to different PKCS11 implementations.
Changes between Version 1 and Version 2
- signserver_server.property file have been removed and replaced with a global configuration store.
- It is now possible to dynamically add and remove available signers
- A new type of component, "Service" that is run on a timely basis, used to perform maintenance or report generation.
- Improved cluster deployment functionality.
- New CLI tools to batch configure the SignServer, and to backup a current configuration.
- This makes it possible to set-up a configuration in test environment, dump the configuration and configure the same it in production.
Terms Used in This Document
| Term | Explanation |
|---|---|
| Signer | A Processable service performing signatures upon requests. This could be a ready made signer or a custom developed one. |
| Crypto Token (former Sign Token) | A Crypto Token is a name for the entity containing the private key and is responsible for its cryptographic operations. Every Processable have a Crypto Token that can be a PKCS12, Smart Card or HSM connection. |
| Extended Crypto Token | An enhanced Crypto Token with support for symmetric key operations. |
| PKCS11CryptoToken | A Crypto Token able to communicate with Hardware Security Modules through the standard PKCS11 interface. |
| TimedService (former Service) | A TimedService is a task that is run on a timely basis, performing maintenance tasks like changing active key or generate a report. |
| Worker | A common name for Processable (Signer or other type of service), Mail Processor and TimedService |
| Processable | A type of worker that is used to process requests, i.e. not a TimedService. |
| Worker Configuration | Each Worker can be configured with properties specific for that worker. There are two sets of worker configuration one "Active" that is used by the signer and one "current" which is the one configured by the administrator. The current configuration isn't used in production until the administrator issued the reload command. This makes it possible for the administrator to configure multiple properties and double-check them before they are actually used. |
| Global Configuration Store | Is a dynamic store used to define available Workers and their Crypto Tokens. But other data that needs to be read globally could be set there as well. The global configuration properties are activated immediately. There are two different scopes for the store data, Global Scope and Node Scope. |
| Global Scope | Data stored in the global configuration that can be read by all nodes in the cluster. |
| Node Scope | Data that is node specific and can only be read within the same node. |
| Worker Id | Unique identifier of a worker, an integer larger than 0 |
| Worker Name | A name used as a human readable synonym for a Worker Id |
| Mail Processor | A plug-in used for the mail signer to perform automated cryptographic operations on e-mails sent through the mail server. This could for instance be the Simple Mail Signer for attaching a SMIME signature to all mails. |
| Validation Service |
A Processable that checks if a certificate is valid or not. Have a Default Validation Service implementation that should work in most cases. A Validation Service should have one or more Validators configured. |
| Group Key Service | A Processable that can be used to manage, generate and distribute group keys to a set of clients. The service support four types of calls, fetch group key (used by clients), pre-generate group keys, switch encryption key (key used to safely store the group keys in database) and remove group keys. There exists a Default Group Key Service that should satisfy most use cases. |
| Certificate Validator (former Validator) | A Certificate Validator is responsible for checking the status of one or more issuer's certificates. This could be as an OCSP client or a CRL checker or just looking up the status in a database. |
| Document Validator | A Document Validator is validating a signed document by checking its signature and corresponding certificate(s) and returns the validation result. |
| Authorizer | An interface that enables developers to integrate the authorization parts with existing authorization systems of who is authorized to perform requests to a Processable. |
| Time Stamp Signer | A Signer that can be used to set up a Timestamp Authority according to RFC 3161. |
| MRTD Signer | A Signer that performs signatures of MRTD (Machine Readable Travel Documents, i.e. Electronic Passports) blobs. |
| MRTD SOD Signer | A Signer that creates the complete security object (SOd) for a MRTD (Machine Readable Travel Document, i.e. Electronic Passports) by signing the data groups. |
| PDF Signer | A Signer that attaches an electronic signature signature to a PDF document. |
| XML Signer | A Signer that puts in an enveloped signature in XML documents (XMLDSig) |
| XML Validator | A Document Validator that validates signed XML documents (XMLDSig) |
| ODF Signer | A Signer that attaches an electronic signature to an ODF document. ODF Signer is tested with documents produced by OpenOffice.org v 3.1.0 |
| ODF (Open Document Format) Document | XML-based file format for representing electronic documents such as spreadsheets, charts, presentations and word processing documents. more... |
| OOXML (Office Open XML) Document | XML-based file format for representing spreadsheets, charts, presentations and word processing documents. more... |
| OOXML Signer | A Signer that attaches an electronic signature to an OOXML document. |
| Simple Mail Signer | A Mail Processor that envelopes authorized mails with a SMIME signature. |
| Cluster Class Loader | A Java Class Loader specific for the SignServer project. The class loader simplifies the distribution of new code to a cluster by uploading and fetching it from database. It also enables the use of multiple versions of the same worker code in the same cluster. |
| Module Archive or MAR file |
A 'Module Archive' is a specific packaging format used by the cluster class loader to upload code to a cluster. A MAR files is structured in a specific way with a descriptor containing module and version information. The MAR file also contains one or more parts depending on were in the system the code will be deployed. A Module Archive have the postfix .mar and can be generated with a specific ANT-task. |
Overall Architecture
Since the 3.0 version the SignServer project have two different builds, one is the classical SignServer and the other is a Mail Processing Server called the MailSigner.
SignServer
The SignServer is a framework designed to perform different kind of cryptographic operations for different applications.
Since the 3.0 version there are three kind of processable services. Signers (used to sign or in other way process requested data). Validation Services used to verify the validity of a certificate against a set of backed issuers. The validation service can be used to simply the integration of PKIs into existing applications. The the third processable service is a group key service framework used to manage and to distribute group keys for different applications, these keys can be both symmetric and asymmetric. In addition to processable services there also exists another concept called Timed Service (called just 'service' in 2.0 edition) which are plug-ins run at defined intervals performing maintenance or reporting routines.
Out-of-the-box are there three Signers ready to be used. They are a MRTD Signer used for signing Machine Readable Travel Documents (also known as Electronic Passports), a Timestamp Signer that can be used to set up a Timestamp Authority and a PDF signer that can be used to automatically sign documents.
The main way of communicating with the SignServer is through a WebService interface (previous versions had a RMI-SSL interface, but that have been replaced by the WS for better platform independence.) but the Timestamp Signer is also available through HTTP communication and the PDF signer have a simple HTML page that allows users to upload documents to be signed.
For an overview of the different concepts in the SignServer see illustration 1. The base component is called Worker which is assigned an id, optionally a name and a configuration. A sub component is a Processable which receives and processes requests. A Processable (optionally) have access to a cryptographic token (CryptoToken) in charge of managing the keys of a Processable. A CryptoToken can be either software or hardware based.
The applications i administrated through a command-line interface, where the properties and access control can be configured.
One SignServer can have multiple services for different purposes.
MailSigner
The MailSigner is a different build of the SignServer, targeted to perform automated cryptographic operations on e-mails. The MailSigner is an add-on to the James SMTP project and the James SMTP binaries is shipped along with the SignServer package for simplified set-up.
The MailSigner's main component is the MailProcessor which is the base for all MailSigner plug-ins. There exists one ready to use MailSigner called the SimpleMailSigner. It generates a signed SMIME message of all mails sent to through the server.
One instance can have more than one MailProcessor configured. Then will the plug-ins be called by worker id in ascending order.
The MailSigner have similar CLI interface and is administrated much in the same way as the SignServer. The SMTP server have support for SMTP Authentication. For more information about the James SMTP server see http://james.apache.org.
Illustration 1: Components in the SignServer project