Cryptomathic Signer Public Key Infrastucture by cps1992


									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

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-
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.


       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

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.

  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

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-
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
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-
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

   Authority                                Signature Server               Authentication Server

                              Computer with                                 Authentication
                              Internet access          SMS


                                                  1H7T4    printed card

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

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

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

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-
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.

To top