Cryptomathic Signer v. 2.0 Technical White Paper 2001, Cryptomathic A/S. All rights reserved Kannikegade 14, 3. DK-8000 Aarhus C, Denmark This document is protected by copyright. No part of the document may be reproduced in any form by any means without prior written authorization of Cryptomathic. The information described in this document is protected by a pending patent application. This document is provided “as is” without warranty of any kind. Cryptomathic may make improvements and/or changes in the product described in this document at any time. The document is not part of the documentation for a specific version or release of the product, but will be updated periodically. Cryptomathic A/S Kannikegade 14, 3 DK- 8000 Aarhus C Denmark www.cryptomathic.com Tel: (+ 45) 8613 9020 Fax: (+45) 8620 2975 Date: 05.07.2002 Doc.: Cryptomathic Signer Technical White Paper Doc. Version: 1.0 Cryptomathic Signer Technical White Paper 2 Table of Contents 1 Introduction 4 1.1 Contact Information 4 2 Cryptomathic Signer’s Position in PKI 5 2.1 Integration into Existing PKI 6 2.2 Integration with End User Applications 6 2.3 Different Keys for Different Purposes 7 2.4 Prepared for the Future 7 3 Protecting the Secrets 7 3.1 Confidentiality 7 3.2 Integrity 8 4 Managing Trust: Who Must Trust Whom? 8 4.1 Authenticity 8 4.2 Non-repudiation 9 4.3 Conclusion 9 5 Overall Architecture 9 6 Technical Issues 11 6.1 Cryptographic Standards 11 6.1.1 Digital Signatures 11 6.1.2 Certificates 11 6.1.3 CA Protocols 11 6.2 Server Platform 11 6.3 Database Back End 12 6.4 Cluster Architecture 12 6.5 Administration of Cryptomathic Signer Servers 12 6.5.1 Server-side API 12 6.6 Administration Client 12 6.7 Administration API 12 6.8 Integration with End User Software 12 6.8.1 Browser-based Applications 12 6.8.2 Microsoft Crypto-API 13 6.8.3 PKCS#11 13 6.8.4 Proprietary API 13 Cryptomathic Signer Technical White Paper 3 1 Introduction This document provides an introduction to Cryptomathic Signer. It includes a description of Cryptomathic Signer’s position in a PKI and explains how issues of trust and security are handled and how Cryptomathic Signer is integrated with existing systems. Further- more, the overall architecture of Cryptomathic Signer is described and the technical is- sues regarding supported platforms, database back end integration issues etc. are dis- cussed. The intended audience is IT-security managers, solution architects and security experts considering the option of using Cryptomathic Signer as part of a Public Key Infrastruc- ture. The reader is assumed to be familiar with the basic concepts of PKI. 1.1 Contact Information If you need further information about Cryptomathic Signer or any of the other Crypto- mathic products, please do not hesitate to contact us. Contact information can be found on page 2. Cryptomathic Signer Technical White Paper 4 2 Cryptomathic Signer’s Position in PKI Cryptomathic Signer’s role in a public key infrastructure (PKI) is to manage the users’ private keys. Cryptomathic Signer’s two main concerns are: 1. Secure management of private keys on a central server 2. Secure usage of the private key: The key is under the full control of its owner and must never be in a position where anyone else can use it. Cryptomathic Signer generates CA certifies keys in keypair, registers user at CA, requests Cryptomathic Signer certificate and generates signatures. CA Alice logs on to Cryptomathic Signer Cryptomathic Signer and uses her signature to do her Homebanking homebanking and send a signed server mail to bob Bob trusts the mail from Alice because of the signature and Alice the certificate Bob Cryptomathic Signer interacts with the CA as both registration authority (RA) and key owner by: • Initiating registration at the CA • Generating key pairs • Requesting certification by the CA of the generated key pairs Apart from a certificate cache, Cryptomathic Signer itself does not manage certificates but leaves it to the CA to publish certificates and distribute certificate revocation lists (CRLs) etc. Cryptomathic Signer can thus be seen as an alternative to storing the private key on disk or on a smart card, but it does more than just that: Because the key is located on a central server, it can be accessed from any terminal, effectively enabling roaming. Cryptomathic Signer Technical White Paper 5 Cryptomathic Signer is very flexible with respect to the methods used to authenticate us- ers1 and because any secrets required in a PKI can be kept under the user’s private key, Cryptomathic Signer can be used for single logon to the PKI (session logon). The advan- tage of this is clear, since it allows the same strong user authentication to be employed everywhere within the PKI. Cryptomathic Signer’s primary and most secure mode of operation is as online service with complete control over the private keys, but it is also possible to use it as a remote key store from where keys can be downloaded for offline use. It is configurable on a per- key basis whether keys are downloadable or not. 2.1 Integration into Existing PKI Cryptomathic Signer can easily be integrated into any standards compliant PKI (follow- ing the PKCS#10 “issue” and PKIX-CMP “revocation” standard). The only issue is the protocol used to register a customer on a CA as this particular protocol has not yet been standardized amongst CA vendors. Most CA vendors do, however, supply software development kits (SDKs) allowing oth- ers to integrate with their particular product. Please contact Cryptomathic if you have fur- ther questions regarding integration with CAs. Cryptomathic Signer comes with a comprehensive API for the administration tasks that are necessary in order to integrate Cryptomathic Signer into existing systems. 2.2 Integration with End User Applications Cryptomathic Signer implements both PKCS#11 and the Microsoft Crypto-API inter- faces for authenticated access to the private key. These APIs can be registered as crypto service providers (CSPs) to allow the key to be used from within Netscape Communica- tor, Microsoft Outlook and Microsoft Outlook Express for signing and encrypting email. Cryptomathic Signer also comes with two additional interfaces: • An applet for use in web browsers, e.g. for form signing or for signing transac- tions against an application service. • A proprietary C-interface for integration into other applications. This interface supports the same functionality as the PKCS#11 and the Crypto-API interfaces and also enables self-administration of the user’s account on the Cryptomathic Signer server. In addition, Cryptomathic Signer is currently being integrated with other standard prod- ucts. Please contact Cryptomathic for further information. 1 Cryptomathic Signer handles a number of different authentication methods and can do any combination of these ranging from a single static password (1-factor authentication) to combinations of a static password and one-time password schemes (2-factor authenti- cation) such as one-time passwords sent via SMS, the use of password cards or the use of various authentication tokens. Cryptomathic Signer Technical White Paper 6 2.3 Different Keys for Different Purposes Each Cryptomathic Signer user may have a number of keys for different purposes. Each key is issued with respect to a policy and may optionally be certified by a CA. Crypto- mathic Signer handles multiple CAs and multiple policies for flexibility. Each policy is associated with a set of requirements for user authentication. This allows some keys to be used with fairly weak authentication (password-only) whilst other keys require strong authentication involving one-time passwords or authentication devices. The list of authentication methods and devices supported by Cryptomathic Signer is con- stantly increasing. Please contact Cryptomathic for the latest list. The policy of a key also specifies whether a key can be downloaded for offline use or not, but downloadable keys can never require stronger authentication than a single password. 2.4 Prepared for the Future By maintaining keys centrally, Cryptomathic Signer is prepared for future extensions in the PKI. In particular, Cryptomathic Signer can easily be integrated with time stamping to provide non-repudiable digital signatures. 3 Protecting the Secrets Because Cryptomathic Signer implements remote use of the private key, it is important to consider how the data to be signed or decrypted is handled. We must ensure that data sent to Cryptomathic Signer will not be exposed to prying eyes and that messages arrive ex- actly as sent. These are the traditional issues of confidentiality and integrity. 3.1 Confidentiality If Cryptomathic Signer is used to sign a confidential document, then how do we know that the document is not exposed to prying eyes at the server? Similarly, how do we know that the transport key for an encrypted email remains confidential if Cryptomathic Signer is used to decrypt the transport key? The entire architecture of Cryptomathic Signer has been designed to provide complete confidentiality so that no one, not even system administrators, programmers or hackers will be able to learn the message to be signed or decrypted by the private key: • Cryptomathic Signer consists of two servers that share secrets so an attack on a single server cannot reveal sufficient information for the attacker to read the user’s data. If the servers are run by independent organizations, this even protects against attacks from privileged insiders. • Cryptomathic Signer can use specially programmed hardware security modules so that information about the user’s data or the private key is not even available in the runtime memory of the servers. • Cryptomathic Signer uses TLS/SSL for strong encryption of data communicated over the network. • Cryptomathic Signer further encrypts all communicated data under a session key derived from all the information that was gathered during user authentication. Cryptomathic Signer Technical White Paper 7 This protects the communication from any gaps in the TLS/SSL connection all the way into the hardware security module. All in all, this means that once data has been delivered at the remote interface to Crypto- mathic Signer, data will be treated with complete confidentiality. 3.2 Integrity If Cryptomathic Signer is used to sign an important document or an electronic transaction then how can we be sure that the data is not modified either intentionally by an attacker or unintentionally by noise? Cryptomathic Signer enforces strong cryptographic integrity checking on all communica- tion to and from the server and on all data stored in the database. This means that once the message is on its way over the network the message is protected from modification. In order to protect the message before it reaches the network, the interface to the network must be protected. This can be achieved by signing the applet used for signatures via web browsers. 4 Managing Trust: Who Must Trust Whom? Any PKI involves secrets and the process of certification requires the community using the PKI to trust something. With Cryptomathic Signer this issue carries extra weight be- cause the server actually maintains a secret on the user’s behalf. So the big question is: Who must trust whom to achieve authenticity and non-repudiation within a PKI built around Cryptomathic Signer? 4.1 Authenticity In the case of Alice sending a signed message to Bob, authenticity is a matter of how Bob determines that the message is indeed from Alice and not from someone else. In the case of a signed piece of paper, the authenticity of the signature is usually established by com- paring the signature to an authorized copy of the signature, e.g. on a credit card or a driver’s license. The situation is no different in the PKI except that the authorized copy of the signature now comes in the form of a digital certificate that must be issued by a Certificate Author- ity (CA). The critical part of the certification process is the establishment by the CA of the individual’s identity (i.e. if Alice goes to the CA to have a certificate issued then how does the CA check that Alice is indeed Alice and not her opponent, Eve?). This situation is the same when Cryptomathic Signer is part of the PKI except that estab- lishment of the user’s identity must take place when the user is enrolled into Crypto- mathic Signer and not as a separate process at the CA. Thus, because enrollment into Cryptomathic Signer implies registration at a CA, the enrollment procedure must be sub- ject to a Certificate Practice Statement (CPS) according to which authenticity is guaran- teed. Cryptomathic Signer has one benefit over traditional use of CAs in a PKI, namely that enrollment is only done once even though an enrolled user may have many different cer- tified keys. This means that if Eve somehow slips through the enrollment procedure as “Alice”, then we will know that all signatures issued by “Alice” are invalid no matter which certificate they correspond to. This is different from the situation in a traditional Cryptomathic Signer Technical White Paper 8 PKI where we can end up in a situation where some of the “Alice signatures” are false while other “Alice signatures” are genuine.[lw1] 4.2 Non-repudiation Non-repudiation means that if Alice sends a message to Bob, then Bob can prove to eve- ryone that Alice has indeed sent that message. In the case of the signed piece of paper above, Bob verified the signature by comparing it to an authorized copy, but this carries the tacit assumption that no one can forge the signature. If the signature can be forged then Bob cannot prove that Alice sent the message and so the signature cannot be said to have the non-repudiation property. This carries back to the PKI where non-repudiation cannot be achieved unless we are ab- solutely sure that no one but the owner had access to the private key when the message was signed. Cryptomathic Signer deals with this by requiring strong user authentication, by using specially programmed hardware security modules (HSMs) and by sharing the user’s trust between two independent organizations that must both fail trust in order to compromise the use of the private key. As a result, no system administrator, malicious programmer or loose hacker will be able to abuse the private key for the simple reason that there is never enough information available unless both organizations behind Cryptomathic Signer are compromised. The only feasible way to abuse the private key is either to attack the user’s terminal or to get hold of the user’s credentials, making Cryptomathic Signer at least as strong as any other digital signature token but with the benefit of flexibility w.r.t. authentication meth- ods. Finally, Cryptomathic Signer contains a detailed and tamper proof audit log of all opera- tions done on the server. This allows any abuse to be traced and gives for example the ability to distinguish between signatures generated before and after a user’s credentials got lost. This allows much better damage control than any solution where the private key is not confined to stay on a server. 4.3 Conclusion Cryptomathic Signer manages users’ private keys, whilst imposing no technological limi- tations to the strength of authenticity or non-repudiation. Authenticity is established by the certificate practice statement followed when enrolling users into Cryptomathic Signer, while non-repudiation is achieved by means of the authentication method used for a particular signature. Finally, the audit log can be used to resolve disputes about signatures and for damage control in case of lost credentials. 5 Overall Architecture The Cryptomathic Signer server system consists of a signature server and an authentica- tion server that should preferably be run by separate organizations in order to maximize the credibility of the system. Cryptomathic Signer Technical White Paper 9 This is important if Cryptomathic Signer is deployed as a public service providing users with signatures for arbitrary purposes. If Cryptomathic Signer is deployed with a specific purpose in mind such as providing digital signatures for Internet banking and for com- munication with bank personnel, it might be adequate to run both servers at the same or- ganisation. The only benefit of separating the operation of the two servers is to protect the user from fraud committed by insiders. Cryptomathic Signer Certificate Authority Signature Server Authentication Server Computer with Authentication Internet access SMS Information password generating token 182A3 1H7T4 printed card 1718U The role of the signature server is to store user data and to generate signatures / decrypt session keys. The role of the authentication server is to generate and distribute authentica- tion information. This includes: • Part of initial password (distributed in sealed envelope) • Onetime passwords (distributed on cards or via SMS) • Personalization of various authentication devices • Verification and derivation of session keys based on data from password cards or authentication devices. The keys maintained by Cryptomathic Signer may or may not be certified. If certified keys are to be used, the signature server must be able to access a CA. As default, Cryp- tomathic Signer interfaces with the CA from Cryptomathic Certification Authority ver- sion 3.2 or higher, but other CAs can be used as well. Cryptomathic Signer can interact with more than one CA. This can be convenient if running Cryptomathic Signer as a gen- eral-purpose service. The necessary user authentication is configurable on a per policy basis, but if strong user authentication is required, the authentication server must be set up to handle the desired authentication methods. The flexible plugin architecture of the authentication server ca- ters for almost any type of authentication, but please contact Cryptomathic for details about your preferred method. Cryptomathic Signer Technical White Paper 10 6 Technical Issues This section discusses the technical issues about cryptographic standards, platforms and database backend, clustering options, APIs etc. 6.1 Cryptographic Standards Cryptomathic Signer supports the following standards: 6.1.1 Digital Signatures Cryptomathic Signer generates RSA signatures with key lengths from 512 to 2048 bits where default is 1024. Signed formats are ISO9796, PKCS#1 and PKCS#7. 6.1.2 Certificates Cryptomathic Signer uses X509v3 certificates as public-key certificates. Certificates can be appended to signed messages (PKCS#1 and ISO9796) or embedded into the message (PKCS#7). 6.1.3 CA Protocols Cryptomathic Signer employs the PKCS#10 “issue” and the PKIX-CMP “revoke” proto- cols for issuing and revoking certificates. Certificate renewal and update is not used. The registration protocol is the only protocol not standardized and Cryptomathic Signer must be tailored to handle new CAs. 6.2 Server Platform Both the signature server and the authentication server run on Windows NT/2000. The servers come in three configurations: Configuration Description HSM Software Crypto All cryptographic operations are performed in software. None This configuration is suitable for demonstrations and for development purposes but protection of the private key is weak. Hardware Crypto All critical cryptographic operations are performed in a nForce or higher (from tamper resistant HSM, but runtime memory of the server nCipher). process will contain enough information for insider to abuse private key. This configuration is suitable for use in a limited domain such as home banking, where the operational environment is secure. DSEE All critical operations are carried out within a distributed SEE enabled nShield secure execution environment where runtime memory can- (form nCipher) not be examined. This configuration is suitable for providing true non- repudiation signatures in e.g. a public service. Cryptomathic Signer Technical White Paper 11 6.3 Database Back End Both the signature server and the authentication server need a database back end. At the time of writing, Microsoft SQL Server 7.0 and Oracle 8 are supported as production da- tabases while Microsoft Access can be used for demonstration purposes. The exact set-up of the database back end depends on the requirements towards stability, backup, throughput and operating platform for the database. 6.4 Cluster Architecture Both the signature server and the authentication server can be set up to run in a load- balanced cluster architecture where each node consists of a HSM equipped Windows NT/2000 platform. The cluster set-up has the benefit of scaling with the needs for throughput and of providing redundancy to improve stability of the system. The cluster is able to redirect open connections to new servers in case a server fails or shuts down. 6.5 Administration of Cryptomathic Signer Servers Cryptomathic Signer comes with a system initialisation tool, a complete administration client that takes care of all administration issues and a performance / load monitoring tool for the servers. The administration client can also be used to enrol new users into the sys- tem and to manage their accounts. 6.5.1 Server-side API A complete administration API is also available for integration into legacy systems or for batch enrolment from existing customer databases etc. The protection of the administra- tion API is based on SSL/TLS client authentication. The client certificates/keys and their associated privileges can be generated and managed from the administration client. 6.6 Administration Client The administration client requires the Java 2 Runtime System, two smart card readers (to authenticate administrators) and the appropriate PCSC drivers to operate. The preferred platform is Windows NT/2000. 6.7 Administration API The administration API comes as default compiled as a DLL for Windows NT/2000. The administration API must maintain a client SSL/TLS certificate and the corresponding key. 6.8 Integration with End User Software The end user can use Cryptomathic Signer in two different ways, either when signing messages or transactions from a browser application or when using standard products such as mail clients, file and folder encryption utilities etc. 6.8.1 Browser-based Applications When using Cryptomathic Signer from a browser application, the user does not need to be concerned with Cryptomathic Signer at all since the application can communicate with Cryptomathic Signer Technical White Paper 12 Cryptomathic Signer through a small applet (~30KB), which is downloaded automati- cally by the application when needed the first time. The Cryptomathic Signer applet also provides self-administration capabilities to the browser application. 6.8.2 Microsoft Crypto-API A crypto service provider for the Microsoft Crypto-API must be installed in order to use Cryptomathic Signer from applications from Microsoft, these including Microsoft Out- look and Outlook Express. 6.8.3 PKCS#11 A crypto service provider for PKCS#11 must be installed in order to use Cryptomathic Signer from Netscape Communicator. 6.8.4 Proprietary API A proprietary API is available to third party vendors wishing to provide self- administration capabilities for the Cryptomathic Signer account though their own soft- ware. Vendors wishing to use the signing and decrypting functionality of Cryptomathic Signer should use the standard Crypto-API or the PKCS#11 API for this. Cryptomathic Signer Technical White Paper 13 Page: 9 [lw1]Doesn’t the fact that only the hash is transmitted add to this end.
Pages to are hidden for
"Cryptomathic Signer Public Key Infrastucture"Please download to view full document