- Email: [email protected]
Controlling digital signature services using a smartcard
Computers
& Security, 14 (1995) 681-690
Controlling Digital Signature Services Using A Smartcard Christopher J Holloway IBM UK Ltd, Security Solutions Group, IBM South Bank, London, UK.
Introduction Traditionally encryption has been used between institutions rather than between individuals. Perhaps the need to preserve the secrecy of each others keys made this a necessity The availability ofpublic key technology, combined with the widespread use of personal and mobile computers, and the ready access to open information networks, has brought cryptography to the end user. The digital signature paradigm matches that of the Internet in being a public utility for person-to-person communications. Along with this concept comes a package of assumptions about the control of public keys. The secret key is owned and controlled by the end user. It is probably stored on a PC hard-file enciphered under the users password as the end users are unlikely to pay for specialized cryptographic hardware. To provide assurance, Trusted Third Parties offer registration agent and certification authority facilities so that a correspondent can trust the signature. To guard against loss of the secret key, directory services record the current status of all certificates, so that a bad key can be spotted (if the recipient takes the trouble). The picture I am painting is one of ‘user power’ in a vaguely anarchic or self-regulated world. A picture I believe to be not too far from the truth. and a picture that is anathema to the corporate institution. It is anathema because the corporation needs to be in control of its own risks. Trusting the withdrawal of a
0167-4048/95/$9.50
0 1995, Elsevier Science Ltd
secret key to a third party, or the security of it to the whim of end-user password control is not an attractive paradigm when the misuse of a key can place the corporate at considerable and non-repudiable financial or operational risk. If the encrypted secret key can be copied, and the password pirated at another time, then control over its usage is completely lost, and the theft of the key may go un-noticed for a considerable period. However, while the end user may not be prepared to pay directly for the appropriate levels of security, corporations have a significant self-interest in doing so. Smartcard offers the potential to regain some level of control by burying the secret key on a non-copyable card, thereby making theft more obvious. However, until the costs of public key processing on the smartcard become more acceptable, and given the huge multipliers involved in providing this technology to end users, the use of public-key capable smartcards is unlikely to become widespread. Evidence for this view can be seen in the fact that almost all electronic purse systems use global DES keys or derived DES keys to overcome the cost implications and constraints of smartcard technology, whereas public key is perfectly suited to the application (ignoring costs and technology). However, even if smartcards do become available at reasonable cost for public key processing, there is a further dimension of control that could raise corporate concerns about their use. If the keys and the processes are both packaged on the same medium, and that medium is in the hands of individuals, then the corporate is subject to various internal threats such as
681
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
disruptive or destructive actions on the part of disgruntled employees. This possibility is further exacerbated when the card can be used directly across open networks, so bypassing all aspects of corporate control.
of the enterprise appear effectively as if they are local to the end user. This paper has been written with such an environment in mind.
This paper addresses these concerns in relation to the use of public key cryptography by corporate users, and at the same time shows the considerable advantages that even low cost smartcards can bring as one element in a chain of control processes to help the corporation to manage its own risks both economically and effectively.
Corporate Users
It does this by introducing a ‘signature server’ which is responsible for the control of signature keys and functions, leaving the end user with a lower cost smartcard. The end user has responsibility for user authentication, and authorizing the signature server to use their secret key to generate a signature on specific data. The security protocols between the smart card and the server ensure that keys cannot be misused, and are independent of the protocols governing the signature itself which will most likely be determined by external standards. This approach increases the level of control over secret keys by the corporation, and increases overall resilience and performance, while at the same time reducing implementation costs. As such the approach should be very attractive to any corporation needing to enter the world of digital signature processing.
Corporate rather than personal users have been assumed because the burden of risk is transferred from the individual to the corporation, and so their emerges independently of the end user, a motivation to control that risk. It should however be noted in passing that in a world of non-repudiation, the risks to the signatory of a transaction are substantially higher than they would be otherwise. If there is no effective means of appeal (my employee was no longer authorized when he made the transaction; or the key had been pirated) then the need for control is very substantial indeed. If there is a means of appeal, then the value to the correspondent of a non-repudiation scheme is lessened, and risk is transferred in some part to the recipient, along with an associated duty of care. The corporation may have sufficient solvency and muscle to ride out such a problem; for the individual however, or the small company it could be a quick route to bankruptcy.
Shared Servers
Assumptions Corporations have been moving increasingly towards distributed processing environments expressed in terms like ‘client server’, ‘down sizing’ and ‘object oriented’. Technologies such as the Distributed Computing Environment (DCE) from the Open Software Foundation, and KryptoKnight from IBM provide for users to sign into the corporate network through an ‘authentication server’ that authenticates the user to the rest of the environment. This process is available in principle to mobile and home users wherever they may be in the world. The underlying assumption is that of immediate and effective online real-time access to all of the computing resources and facilities that the company provides to enable the user to do their job. Technologies such as these break away from the geographic limitations of traditional LAN servers by making all of the resources
682
The distributed computing environment assumes that shared services are available domain-wide, and in particular that one such shared service could be a highly secured and well managed ‘digital signature server’ the function of which is to maintain control over secret keys and sign messages on behalf of users. Such a server of course raises other questions on behalf of the end user, who will need assurance that messages cannot be signed in their name without their explicit authority. The approach described in this paper provides just such explicit authority, and does so with cryptographic strength in a way that is specific to each individual message to be signed.
The Need This section explores the needs of the corporate organization and its employees that should be met if a digital signature system is to be effective in providing the levels
Computers & Security, Vol. 14, No. 8
of security and assurance that should be expected by and of corporations.
Usability The main features of usability fall into two categories: those as perceived by the administrators of the system, which are addressed later; and those perceived by the end user, which are addressed here. The end user has a small number of very important usability needs. Firstly, the system must support the natural flow of the business processes. In particular, this requires extreme flexibility of the technological implementations. Authorization to ‘sign’ information may in some circumstances be extremely tightly controlled (for example dual control over the processes for each signature on every transaction), or quite loosely controlled (for example, authorization to sign all batches for the next 12 hours). The security policy and standards should be those determined by the company in the light of the risks it deems acceptable and the business processes it undertakes. This suggests that the process of end user authorization and the process of presenting data for signature should be only loosely coupled in the sense that ‘signing’ should take place only when authority is present, but that explicit authorization should not be a pre-requisite for every signature. It also suggests that the authorization rules should be very flexible. Another requirement of the end user is easy self-administration. Changing the users authorization codes (e.g. PIN or password) should be a simple and locally performed function; and the system should support mobility of users both within the organization and geographically (e.g. a travelling salesman). Finally the user should enjoy some degree of protection from the risks of other employees attempting to defraud the company through misuse of the original users identity. This leads to a token based system, rather than a purely password based system, but also leads to the need for the user to be assured that his or her ‘account’ can be stopped immediately a token has been reported lost or stolen.
Control When entering the world of digital signature supported electronic trading, a company accepts new risks associ-
ated with the new threats and new means of fraud that are implicit within electronic trading. The digital signature guards against these risks, but also introduces new means to be duped. The company must therefore be assured that it remains in proper control over its risks. In particular this means that it must remain in control over the usage of secret keys which bear associated certificates. It is inherent within the concept of a ‘public key certificate’ that once issued, it is extremely cumbersome to withdraw, and so a company should not rely on the directory services of trusted third parties as the only means by which it controls the withdrawal of its own secret keys. Rather, it should insist upon its own means ofwithdrawing from usage or destroying the secret keys themselves in a fully auditable way. This will require that the secret keys are held in a highly controlled environment and in only a limited number of ‘recovery’ facilities if any. The requirement to control access to secret keys (or even to the use of secret keys) is a business imperative. Today’s business world is one where employees travel extensively and are highly empowered; but at the same time they are often on short term contracts, and will consequently have or show little loyalty to their ‘present employer’. This situation has been exacerbated by worldwide economic recession causing a sharp increase in lay-offs and redundancies demonstrating that the employer has little loyalty to the employee. The resulting drop in morale has been accompanied by an increase in social tension, a worsening of ones sense of personal worth and security, and an increase in social need. This is not the best environment in which to place full trust in the hands of the employees in such a way that it cannot easily be withdrawn. An employee signaturecard available for use across the Internet in the companies name would be just such a level of misplaced trust! The need then is to meet the employees requirements for flexible and easily usable signature systems while at the same time retaining a firm level of control over the signing process (and in particular the secret keys) independently of the employees themselves. This suggests that there should be at least two points of control during the signing process, and that these controls should be separately enforced and administered.
683
Controlling Digital Signature Services Using A Smatfcard/Christopher J Holloway
The first is the employees own control over authorizing a signature in the employees name (as an agent of the company), and the second should be the company’s control over the signing process and secret key, deciding whether this employee’s authority is still acceptable as a basis for signing on behalf of the company. The signing and authorization processes should therefore be split and not encapsulated.
secure hashing mechanism would suffice. However, in order to save space on the smartcard which already has DES function, one of the DES based hashing processes such as MDC2 would be most appropriate. The ability of the protocols described below to provide signature services securely without requiring signature algorithms to be implemented within a smartcard helps to keep the unit costs of the smartcard component to a minimum.
Performance Needless to say, performance should be adequate to purpose. This is very different at the individual workstation and at a central system or a switch. Fortunately, it has already been recognized that the processes of authorization and signing should be separated, and therefore, there is no a-priori need to embed the signature process within the authorization token. However, if the signature process is performed in a different system to the authorization process, then communications between these two processes needs to be protected from attack to level of confidence at least equivalent to the signature process itself. This paper presents just such an approach in which two separate processes are each locally encapsulated and cryptographically bound. One, the authorization process operates within a smartcard on a users workstation: the other operates a later time on a server system. Where timeliness is critical, or synchronous processes are required, then the ability for the end user to have access to multiple signature servers is of great benefit as they increase the resilience and throughput of the system.
Smartcard Costs Often, smartcards are the most populous components within an overall system, and will need regular replacement (depending upon usage). This means that there is significant pressure from corporations to keep down the unit costs of smartcards in any implementation. The approach described below assumes that the smartcard has a DES encryption process, and secure storage for a small number ofsecret keys and user authentication parameters. The protocols assume the use of a hashing function. The hash function chosen is independent of that used for the signature itself, and so any strong and
684
Accountability The fundamental purpose of digital signatures is to achieve accountability both within and between companies. It is therefore essential that the implementation of any signature system can demonstrate that the secret keys used for signing are properly controlled, and can be used only by an authorized signatory. This will require ‘encapsulation’ of certain processes so that they are not subject to modification or proofing. There are several forms of encapsulation. At its most basic is the physical isolation of a system so that it is invulnerable to attack. Such encapsulation of entire systems is appropriate only to the most sensitive of systems such as a certifications centre. Other systems cannot be fully isolated in this way - for example a security server needs by its very nature to be network connected. With these systems, some degree of physical protection is afforded by locking them away, but robust logical protection is also provided by building them on a TCB (trusted computing base), and implementing highly sensitive processes within the TCB itself. The TCB would normally be subject to high levels of scrutiny depending upon the level of assurance required. In some cases a software TCB is not considered suflcient. and sensitive cryptographic processes are often encapsulated within a physically secure boundary (a Tamper Resistant Module) and within this, a logically secured boundary (a Cryptographic Facility), both of which have strictly limited and well policed input and output channels. This paper assumes that critical processes are indeed encapsulated to the required level of security, although it does not discuss further what encapsulation means are required.
Computers & Security, Vol. 14, No. 8
External Standards The final need is for conformance to external standards. At heart, cryptography is needed because we communicate. External standards between companies are designed to reduce costs and facilitate business communication. Irrespective ofthe protocols and approaches used within the system, for example between the authorization process and the signing process, the signing process itself must be capable of supporting external certification and digital signature standards. One advantage of separating the authorization and signature processes is that a change in external signature standards would not need to lead to a change in the end user technology.
The Approach The approach to meeting these needs is described from three perspectives, that of a user of the system, that of the cryptographic protocols needed to support the system, and finally the initialization requirements of the system.The cryptographic protocols have been carefully designed and integrated with the user authentication mechanisms to provide for a chain of non-repudiation, and to meet the needs identified. Other approaches could be envisaged such as for example a ‘signature translation server’ to map internal and external signatures; or a ‘MAC-to-signature converter’. These
alternatives may be conceptually simpler, but would fail to meet all of the needs identified above. Only the preferred approach is described below.
Overview The approach has been to create clear divisions of control between the end user and the corporation, in which the corporation holds the secret key of the end user and may therefore destroy it, but in which only the end user is able to cause a signature to be generated using that key against specific data. The approach also creates clear divisions between the user authentication protocol (assumed in the example to be password based), the signature authorization protocol (assumed in the example to be DES based) and the external signature standards protocol. The boundaries between the protocol divisions are secured within the trusted environments of the smartcard and the signature server themselves, each of which falls entirely within a single domain of control. The protocols are however carefully designed so that the existence of signed data in the external world not only binds the corporation but implicates the end user with the degree of rigour required of a non-repudiation system. Key usage control is therefore effectively end to end, associating the end user with their public key certificate.
r
End User Control
Corporate Control
\/
b
Password User Keys
0 IN
HI-’ Smart card
User Authentication Protocol
Outside World
--?--(I Signature Servers Signature Authorisation Protocol
External standard Signature Protocol
Key Usage Control
Figure 1.
685
Con trolling Digital Signature Services Using A Smattcard/Christopher J Holloway
according to the security policy enforced on the card (e.g. after each transaction, when the card is removed or upon receipt of an explicit command). The authorized state would be volatile so that card removal automatically caused the card to revert to unauthorized.
The approach not only increases the level of security control for the corporation, but does so while at the same time potentially reducing implementation costs (since public key cryptography is no longer required in the smartcard) and increasing performance and resilience (through the introduction of one or more corporate security servers.)
In an authorized state, the smartcard would store in volatile memory an ‘authorization parameter’ or AP without which it would be unable to participate effectively in the signature scheme. The AP would need to be derived in a pre-determined way from the user authentication process and smartcard held data. The exact means of derivation could vary from system to system, however the value of AP would need to be reliably re-treatable by the smartcard. Indeed it is possible to consider an AP value which changes with each authentication action to thwart replay attacks, but the ‘next value’ would need to be predetermined by the smartcard, as it is a component part of data stored on the card between authentication processes in non-volatile memory as will be seen later.
The approach is described in technical detail below, firstly from the end user’s perspective, and secondly from the perspective of the security protocols themselves.
User View The user’s view is of two distinct processes, one is user authentication and the other is of transaction processing. How these two processes are inter-related is very much a matter of security policy and application design. In a rigorous design, user authentication would need to take place each time a transaction is signed; in a less rigorous design, user authentication would take place at the beginning of a ‘workstation session’ and terminate with the removal of the smartcard or after a pre-defined period of inactivity (or activity!).
In the simplest implementation, AP could be a hash value derived from the user’s identity and password. Indeed the user’s identity could be the user’s Public Key Certificate, although this is not necessary. By introducing a ‘sign-on count’ or smartcard stored (and presented) random number in the data to be hashed, then AP could vary from one transaction to the next.
To cater for the myriad of approaches, the smartcard would act as a state machine. It would allow transition from ‘unauthorized’ to ‘authorized’ when user authentication was successful, and in the opposite direction
\
/
User ID, Password,
* Authorisation Parameter (AP)
(Smart Card Processed Values)
J Signature Authorisation Value (SAV)
d SAV+SKH
I
ti
User Authentication Value (UAV) (Smart Card Stored Values)
SAV+KEY t
Card Unique Key (KEY)1
Secret Key Hash (SKH) c---+
b
.-+
reversible functions Figure 2.
one-way functions
Computers & Security, Vol. 14, No. 8
In order to overcome an attack in which a stolen smartcard is probed and the user authentication value obtained from memory, the value of the current or next AP is not stored in non-volatile memory on the card. Instead, two further values are derived from AI? These are UAV (User Authentication Value) and SAV (Signature Authorization Value). UAV should be derived Ii-om AP using a one way function such that UAV cannot be used to derive SAV. In its simplest form SAV could be AP itself, and UAV could be a hash value of SAV, or SAV enciphered using a smartcard held key, the result then being EXORed with SAV. UAV is stored directly in non-volatile memory of the smartcard, and is used to verify the correctness of the next value of AP that is presented. Verification of UAV unlocks the smartcard and places it in an authorized state. UAV acts like a PIN or Password, but avoids having to have these values stored on the smartcard. The verification of UAV also guarantees the correctness of the derived SAV which is essential to the successful operation of the signature process. SAV is itself not stored explicitly on the smartcard. The use of the AP based approach allows a user to change the underlying PIN or Password locally by presenting the old PIN or Password as well as the new. The old value and new value of AP may be calculated and so old and new UAV and SAV values may be derived. The new values may then replace the old only if the old UAV was correct. Although SAV is not stored explicitly on the card, it is stored implicitly, and its means of storage must permit this ready replacement of old with new. The means of storage presented in this paper is as one part of an encryption key The whole key has the value of SAV+KEY (where + denotes the EXOR function). From this value neither SAV nor KEY may be derived without a knowledge of the other value, this is why it should not be possible to derive SAV from the stored value of UAV. However, this form of storage of SAV+KEY means that the. value of SAV may be replaced as frequently as desired simply by further EXORing, as for example in the following equation: (SAVold + SAVnew) + (SAVold + KEY) + KEY)
= (SAVnew
If the smartcard always maintains the value of the next SAVnew+KEY, then to effectively use the value ofKEY, the correct next value of AP must be made available to the card. By tying the key value stored on the card to the user authentication process of unlocking the card, and by not storing the users password on the card, a strong linkage is achieved between user authentication and key usage. The key that will actually be used is a further derivative of KEY which itself cannot be derived by the card without SAVnew. As will be seen, KEY need never be held ‘native’ in the card even in volatile memory. These associations then directly tie the users authentication to the signature process (yet to be described), and protect the user against theft of the card. This then lays the foundation for extending the non-repudiation property of the digital signature (performed elsewhere) right back to the user.
Cryptographic
View
The discussion above has demonstrated the ability to derive a pre-determined KEY value on the smartcard only following successful user authentication, and without the smartcard storing either the value of the user authentication token (for example a password) or the value of the KEY in non-volatile storage. The value of KEY is therefore protected against probing even if the card has been stolen. The value of KEY is predetermined, and so may be known to the signature server through a process of key exchange with the smartcard initialization system. Indeed it could potentially be shared among several servers if necessary to meet the needs for performance, throughput, resilience or topology. A similar technique could be used to protect the smartcard stored value of any other secret data, and is assumed to be used for protecting the value of the Secret Key Hash (SKH) which is stored on the smartcard (e.g. the value SAV+SKH could be stored). SKH is a hash value of the user’s secret key as stored at the signature server. The hash could cover not only the value of the key itself, but also any control information that belongs to the key and is stored with it (such as the identity of the owning user, and the validity period of the corresponding public key certificate). The value of SKH itself is not stored at the signature server, but only on the smartcard. As will
687
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
be seen, it is the unique ability of the smartcard to present the signature server with the value of SKH that allows the smartcard to control the server’s signing function.
Uniqueness can be guaranteed by incorporating within the message and the calculation of MSH the identity of the smartcard and the value of the smartcard derived transaction counter.
The smartcard could simply transfer the value of SKH in the clear, or SKH enciphered using the value of KEY, but both of these approaches would be subject to replay attack. To prevent replay attack, and to bind the transfer to a single specific message, the following is transferred from the smartcard to signature server:
At the signature server then, the value of the user’s secret key is stored enciphered using SKH, along with its associated control information. Within the encapsulated process, the signature server has the original message, has derived a value assumed to be SKH, and has deciphered the user’s secret key hopefully into the clear. Before using the key to sign the message, the server now recalculates SKH from the control information and deciphered secret key value, and compares the results with the received value of SKH; only if this comparison is successful can it be guaranteed that the genuine value of the secret key has been obtained, and that all of the processes and protocols have been preserved with integrity. If the values are not the same, the signature request is rejected.
Here the value SKH is enciphered using the key KEY +MSH, where MSH is a hash of the message to be signed, and as a key management process triple-encipherment using a double-length DES key (KEY+MSH) is used. It should be noted that this value is independent of the users original authentication parameters, and ofthe users original password;but could not have been created without successful user authentication. This enables user authentication and password change to be purely a local matter while at the same time preserving the non-repudiation property. The key value KEY+MSH can be derived from the stored value KEY+SAV by EXORing the stored value with SAV+MSH, thereby avoiding the need for the true value of KEY ever to be held on the smartcard. The signature server can recover SKH from this token only if the original message from which MSH is derived is also presented with the token. At the signature server it is therefore essential that the steps of generating MSH from the message, and of deciphering SKH and of signing the message are all encapsulated in a single processes; in other words the implementation must not permit a different message to be signed than that which was used to derive MSH. This encapsulation would ideally be achieved through the use of tamper resistant hardware. Preventing misuse of the signature server itself may be assured by applying control-vector technology to the DES key-part ‘KEY’ thus ensuring that the received enciphered form ofSKH cannot be deciphered through any other processes supported by the signature server. The smartcard then binds a specific message to the delivery of the enciphered SKH, and thereby also prevents replay attacks so long as messages are unique.
Having successfully verified SKH, the server may now reformat the message, by for example removing the smartcard identity and transaction count, create a hash using the externally defined hashing standard, and build a signature for the message in conformance to any externally defined application standard. The signature may then be returned to the requester, and the values of SKH along with the users clear secret key destroyed from within the tamper resistant enclosure of the signature server thus preventing any possibility of reuse. If at any time the smartcard or user are thought to have been compromised, then the stored value of the enciphered secret key may be destroyed at the signature server, and so the corporation can guard against theft of signature keys and smartcards.
Initialization The essential elements of initialization are to deliver to the various components the information defined below. *To the user: 1. The smartcard and initial password To the smartcard:
??
1. KEY-tSAVinit
Computers & Security, Vol. 14, No. 8
2. UAVinit 3. SKH+SAVinit To the certification
??
authority:
1. User’s public key
It is beyond the scope of this paper to further define the management and initialization processes necessary to describe the functions defined. However, these are generally well understood.
To the signature server:
??
1. Es&Secret
If this centre also happens to be the security server itself, then the user’s secret keys do not need to be distributed. However, the ability to distribute the users secret key securely to a signature server also allows the implementation of multiple servers to support throughput or resilience needs.
Key)
2.KEY 3. User’s public key certificate The simple assumption of a ‘Security Initialization Centre’ which is cryptographically linked to each of the above parties, and which performs the following roles could readily fir&l the initialization requirements in a straight forward way. Key Generation
??
Centre:
1. Generates DES keys (e.g. KEY) and Public Key Pairs User Administration
??
Centre:
1. Creates and distributes User IDS and initial passwords Registration
??
1. Registers keys
Authority:
Benefits The benefits of this approach over either a wholly smartcard based signature system, or a system which does not involve smartcards (but relies for example on the user’s password to directly encipher the user’s stored secret key) have been made clear. In this section of the paper these benefits are therefore merely identified, and are not further elaborated.
End User Control User authentication
??
bound to the signature process.
Password change is a local function.
??
Password validation.
??
user identities and their associated public
Corporate Control
2. Sends public keys to the CA for certification
Withdrawal of certificates no longer the only control measure.
??
3. Maintains directory records Control Vector compatibility
??
Smartcard Initialization
??
Centre:
1. Initializes and personalizes smartcards 2. Installs initial security parameters on the smartcard (UAV, SKH+SAV KEY+SAV) Key Distribution
??
Centre:
Control over secret key (recovery and deletion).
??
Secure generation of secret key (no distribution).
??
@Sensitive values not stored explicitly (Password, KEY, SAV, SKH) .
on smartcard
1. Distributes enciphered secret keys to security servers (further enciphered under a bilateral DES key)
689
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
@User secret key not stored explicitly on the security servers. Secret key unusable without smartcard.
??
External Standards Supports external signature standards.
??
Internal protocols and technologies of external standards.
??
are independent
Performance Server level hardware performance
??
for signing.
Smartcard performance adequate for hashing and DES operations.
??
Multiple servers for throughput and resilience.
??
Smartcard Costs Smartcard functions not burdensome cost technologies.
??
to current low
No security functions required of smartcard reader.
??
Accountability Non-repudiation
??
preserved.
Use of secret key tied to smartcard.
??
Smartcard tied to possession and password knowledge.
??
Summary In this paper a number ofrequirements for the corporate user ofdigital signature technology have been identified. These appeared at first sight to be demanding security controls and usability requirements over and above those assumed of normal signature systems. However, once the requirements were fully analyzed, an approach was described which not only met the additional requirements, but did so while at the same time reducing the likely implementation cost, by reducing the burden placed on the smartcard, and increasing the effective performance be delegating signature processing to a shared server. This approach appears therefore to be unique in raising levels of security, usability and performance while at the same time reducing potential implementation costs and adhering to external standards. It should therefore be of extreme interest to all corporate users who wish to enter the world of electronic commerce backed by digital signature and non-repudiation.
Secret key can be destroyed rapidly if necessary.
??
*Only one point of usage for secret key (or a small number with multiple servers). Focal point for auditing (signature server)
??
Message cryptographically through to server.
??
690
bound
from smartcard
Chris Holloway is an IBM Corporate Technical StaE Member working for the Security Solutions Group of IBM UK. For the past 18 years he has specialized in the application of cryptography to transaction networks and has helped shape the IBM cryptographic products and solutions which are available today. This paper was first presented at Compsec International ‘95 in London in October.
& Security, 14 (1995) 681-690
Controlling Digital Signature Services Using A Smartcard Christopher J Holloway IBM UK Ltd, Security Solutions Group, IBM South Bank, London, UK.
Introduction Traditionally encryption has been used between institutions rather than between individuals. Perhaps the need to preserve the secrecy of each others keys made this a necessity The availability ofpublic key technology, combined with the widespread use of personal and mobile computers, and the ready access to open information networks, has brought cryptography to the end user. The digital signature paradigm matches that of the Internet in being a public utility for person-to-person communications. Along with this concept comes a package of assumptions about the control of public keys. The secret key is owned and controlled by the end user. It is probably stored on a PC hard-file enciphered under the users password as the end users are unlikely to pay for specialized cryptographic hardware. To provide assurance, Trusted Third Parties offer registration agent and certification authority facilities so that a correspondent can trust the signature. To guard against loss of the secret key, directory services record the current status of all certificates, so that a bad key can be spotted (if the recipient takes the trouble). The picture I am painting is one of ‘user power’ in a vaguely anarchic or self-regulated world. A picture I believe to be not too far from the truth. and a picture that is anathema to the corporate institution. It is anathema because the corporation needs to be in control of its own risks. Trusting the withdrawal of a
0167-4048/95/$9.50
0 1995, Elsevier Science Ltd
secret key to a third party, or the security of it to the whim of end-user password control is not an attractive paradigm when the misuse of a key can place the corporate at considerable and non-repudiable financial or operational risk. If the encrypted secret key can be copied, and the password pirated at another time, then control over its usage is completely lost, and the theft of the key may go un-noticed for a considerable period. However, while the end user may not be prepared to pay directly for the appropriate levels of security, corporations have a significant self-interest in doing so. Smartcard offers the potential to regain some level of control by burying the secret key on a non-copyable card, thereby making theft more obvious. However, until the costs of public key processing on the smartcard become more acceptable, and given the huge multipliers involved in providing this technology to end users, the use of public-key capable smartcards is unlikely to become widespread. Evidence for this view can be seen in the fact that almost all electronic purse systems use global DES keys or derived DES keys to overcome the cost implications and constraints of smartcard technology, whereas public key is perfectly suited to the application (ignoring costs and technology). However, even if smartcards do become available at reasonable cost for public key processing, there is a further dimension of control that could raise corporate concerns about their use. If the keys and the processes are both packaged on the same medium, and that medium is in the hands of individuals, then the corporate is subject to various internal threats such as
681
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
disruptive or destructive actions on the part of disgruntled employees. This possibility is further exacerbated when the card can be used directly across open networks, so bypassing all aspects of corporate control.
of the enterprise appear effectively as if they are local to the end user. This paper has been written with such an environment in mind.
This paper addresses these concerns in relation to the use of public key cryptography by corporate users, and at the same time shows the considerable advantages that even low cost smartcards can bring as one element in a chain of control processes to help the corporation to manage its own risks both economically and effectively.
Corporate Users
It does this by introducing a ‘signature server’ which is responsible for the control of signature keys and functions, leaving the end user with a lower cost smartcard. The end user has responsibility for user authentication, and authorizing the signature server to use their secret key to generate a signature on specific data. The security protocols between the smart card and the server ensure that keys cannot be misused, and are independent of the protocols governing the signature itself which will most likely be determined by external standards. This approach increases the level of control over secret keys by the corporation, and increases overall resilience and performance, while at the same time reducing implementation costs. As such the approach should be very attractive to any corporation needing to enter the world of digital signature processing.
Corporate rather than personal users have been assumed because the burden of risk is transferred from the individual to the corporation, and so their emerges independently of the end user, a motivation to control that risk. It should however be noted in passing that in a world of non-repudiation, the risks to the signatory of a transaction are substantially higher than they would be otherwise. If there is no effective means of appeal (my employee was no longer authorized when he made the transaction; or the key had been pirated) then the need for control is very substantial indeed. If there is a means of appeal, then the value to the correspondent of a non-repudiation scheme is lessened, and risk is transferred in some part to the recipient, along with an associated duty of care. The corporation may have sufficient solvency and muscle to ride out such a problem; for the individual however, or the small company it could be a quick route to bankruptcy.
Shared Servers
Assumptions Corporations have been moving increasingly towards distributed processing environments expressed in terms like ‘client server’, ‘down sizing’ and ‘object oriented’. Technologies such as the Distributed Computing Environment (DCE) from the Open Software Foundation, and KryptoKnight from IBM provide for users to sign into the corporate network through an ‘authentication server’ that authenticates the user to the rest of the environment. This process is available in principle to mobile and home users wherever they may be in the world. The underlying assumption is that of immediate and effective online real-time access to all of the computing resources and facilities that the company provides to enable the user to do their job. Technologies such as these break away from the geographic limitations of traditional LAN servers by making all of the resources
682
The distributed computing environment assumes that shared services are available domain-wide, and in particular that one such shared service could be a highly secured and well managed ‘digital signature server’ the function of which is to maintain control over secret keys and sign messages on behalf of users. Such a server of course raises other questions on behalf of the end user, who will need assurance that messages cannot be signed in their name without their explicit authority. The approach described in this paper provides just such explicit authority, and does so with cryptographic strength in a way that is specific to each individual message to be signed.
The Need This section explores the needs of the corporate organization and its employees that should be met if a digital signature system is to be effective in providing the levels
Computers & Security, Vol. 14, No. 8
of security and assurance that should be expected by and of corporations.
Usability The main features of usability fall into two categories: those as perceived by the administrators of the system, which are addressed later; and those perceived by the end user, which are addressed here. The end user has a small number of very important usability needs. Firstly, the system must support the natural flow of the business processes. In particular, this requires extreme flexibility of the technological implementations. Authorization to ‘sign’ information may in some circumstances be extremely tightly controlled (for example dual control over the processes for each signature on every transaction), or quite loosely controlled (for example, authorization to sign all batches for the next 12 hours). The security policy and standards should be those determined by the company in the light of the risks it deems acceptable and the business processes it undertakes. This suggests that the process of end user authorization and the process of presenting data for signature should be only loosely coupled in the sense that ‘signing’ should take place only when authority is present, but that explicit authorization should not be a pre-requisite for every signature. It also suggests that the authorization rules should be very flexible. Another requirement of the end user is easy self-administration. Changing the users authorization codes (e.g. PIN or password) should be a simple and locally performed function; and the system should support mobility of users both within the organization and geographically (e.g. a travelling salesman). Finally the user should enjoy some degree of protection from the risks of other employees attempting to defraud the company through misuse of the original users identity. This leads to a token based system, rather than a purely password based system, but also leads to the need for the user to be assured that his or her ‘account’ can be stopped immediately a token has been reported lost or stolen.
Control When entering the world of digital signature supported electronic trading, a company accepts new risks associ-
ated with the new threats and new means of fraud that are implicit within electronic trading. The digital signature guards against these risks, but also introduces new means to be duped. The company must therefore be assured that it remains in proper control over its risks. In particular this means that it must remain in control over the usage of secret keys which bear associated certificates. It is inherent within the concept of a ‘public key certificate’ that once issued, it is extremely cumbersome to withdraw, and so a company should not rely on the directory services of trusted third parties as the only means by which it controls the withdrawal of its own secret keys. Rather, it should insist upon its own means ofwithdrawing from usage or destroying the secret keys themselves in a fully auditable way. This will require that the secret keys are held in a highly controlled environment and in only a limited number of ‘recovery’ facilities if any. The requirement to control access to secret keys (or even to the use of secret keys) is a business imperative. Today’s business world is one where employees travel extensively and are highly empowered; but at the same time they are often on short term contracts, and will consequently have or show little loyalty to their ‘present employer’. This situation has been exacerbated by worldwide economic recession causing a sharp increase in lay-offs and redundancies demonstrating that the employer has little loyalty to the employee. The resulting drop in morale has been accompanied by an increase in social tension, a worsening of ones sense of personal worth and security, and an increase in social need. This is not the best environment in which to place full trust in the hands of the employees in such a way that it cannot easily be withdrawn. An employee signaturecard available for use across the Internet in the companies name would be just such a level of misplaced trust! The need then is to meet the employees requirements for flexible and easily usable signature systems while at the same time retaining a firm level of control over the signing process (and in particular the secret keys) independently of the employees themselves. This suggests that there should be at least two points of control during the signing process, and that these controls should be separately enforced and administered.
683
Controlling Digital Signature Services Using A Smatfcard/Christopher J Holloway
The first is the employees own control over authorizing a signature in the employees name (as an agent of the company), and the second should be the company’s control over the signing process and secret key, deciding whether this employee’s authority is still acceptable as a basis for signing on behalf of the company. The signing and authorization processes should therefore be split and not encapsulated.
secure hashing mechanism would suffice. However, in order to save space on the smartcard which already has DES function, one of the DES based hashing processes such as MDC2 would be most appropriate. The ability of the protocols described below to provide signature services securely without requiring signature algorithms to be implemented within a smartcard helps to keep the unit costs of the smartcard component to a minimum.
Performance Needless to say, performance should be adequate to purpose. This is very different at the individual workstation and at a central system or a switch. Fortunately, it has already been recognized that the processes of authorization and signing should be separated, and therefore, there is no a-priori need to embed the signature process within the authorization token. However, if the signature process is performed in a different system to the authorization process, then communications between these two processes needs to be protected from attack to level of confidence at least equivalent to the signature process itself. This paper presents just such an approach in which two separate processes are each locally encapsulated and cryptographically bound. One, the authorization process operates within a smartcard on a users workstation: the other operates a later time on a server system. Where timeliness is critical, or synchronous processes are required, then the ability for the end user to have access to multiple signature servers is of great benefit as they increase the resilience and throughput of the system.
Smartcard Costs Often, smartcards are the most populous components within an overall system, and will need regular replacement (depending upon usage). This means that there is significant pressure from corporations to keep down the unit costs of smartcards in any implementation. The approach described below assumes that the smartcard has a DES encryption process, and secure storage for a small number ofsecret keys and user authentication parameters. The protocols assume the use of a hashing function. The hash function chosen is independent of that used for the signature itself, and so any strong and
684
Accountability The fundamental purpose of digital signatures is to achieve accountability both within and between companies. It is therefore essential that the implementation of any signature system can demonstrate that the secret keys used for signing are properly controlled, and can be used only by an authorized signatory. This will require ‘encapsulation’ of certain processes so that they are not subject to modification or proofing. There are several forms of encapsulation. At its most basic is the physical isolation of a system so that it is invulnerable to attack. Such encapsulation of entire systems is appropriate only to the most sensitive of systems such as a certifications centre. Other systems cannot be fully isolated in this way - for example a security server needs by its very nature to be network connected. With these systems, some degree of physical protection is afforded by locking them away, but robust logical protection is also provided by building them on a TCB (trusted computing base), and implementing highly sensitive processes within the TCB itself. The TCB would normally be subject to high levels of scrutiny depending upon the level of assurance required. In some cases a software TCB is not considered suflcient. and sensitive cryptographic processes are often encapsulated within a physically secure boundary (a Tamper Resistant Module) and within this, a logically secured boundary (a Cryptographic Facility), both of which have strictly limited and well policed input and output channels. This paper assumes that critical processes are indeed encapsulated to the required level of security, although it does not discuss further what encapsulation means are required.
Computers & Security, Vol. 14, No. 8
External Standards The final need is for conformance to external standards. At heart, cryptography is needed because we communicate. External standards between companies are designed to reduce costs and facilitate business communication. Irrespective ofthe protocols and approaches used within the system, for example between the authorization process and the signing process, the signing process itself must be capable of supporting external certification and digital signature standards. One advantage of separating the authorization and signature processes is that a change in external signature standards would not need to lead to a change in the end user technology.
The Approach The approach to meeting these needs is described from three perspectives, that of a user of the system, that of the cryptographic protocols needed to support the system, and finally the initialization requirements of the system.The cryptographic protocols have been carefully designed and integrated with the user authentication mechanisms to provide for a chain of non-repudiation, and to meet the needs identified. Other approaches could be envisaged such as for example a ‘signature translation server’ to map internal and external signatures; or a ‘MAC-to-signature converter’. These
alternatives may be conceptually simpler, but would fail to meet all of the needs identified above. Only the preferred approach is described below.
Overview The approach has been to create clear divisions of control between the end user and the corporation, in which the corporation holds the secret key of the end user and may therefore destroy it, but in which only the end user is able to cause a signature to be generated using that key against specific data. The approach also creates clear divisions between the user authentication protocol (assumed in the example to be password based), the signature authorization protocol (assumed in the example to be DES based) and the external signature standards protocol. The boundaries between the protocol divisions are secured within the trusted environments of the smartcard and the signature server themselves, each of which falls entirely within a single domain of control. The protocols are however carefully designed so that the existence of signed data in the external world not only binds the corporation but implicates the end user with the degree of rigour required of a non-repudiation system. Key usage control is therefore effectively end to end, associating the end user with their public key certificate.
r
End User Control
Corporate Control
\/
b
Password User Keys
0 IN
HI-’ Smart card
User Authentication Protocol
Outside World
--?--(I Signature Servers Signature Authorisation Protocol
External standard Signature Protocol
Key Usage Control
Figure 1.
685
Con trolling Digital Signature Services Using A Smattcard/Christopher J Holloway
according to the security policy enforced on the card (e.g. after each transaction, when the card is removed or upon receipt of an explicit command). The authorized state would be volatile so that card removal automatically caused the card to revert to unauthorized.
The approach not only increases the level of security control for the corporation, but does so while at the same time potentially reducing implementation costs (since public key cryptography is no longer required in the smartcard) and increasing performance and resilience (through the introduction of one or more corporate security servers.)
In an authorized state, the smartcard would store in volatile memory an ‘authorization parameter’ or AP without which it would be unable to participate effectively in the signature scheme. The AP would need to be derived in a pre-determined way from the user authentication process and smartcard held data. The exact means of derivation could vary from system to system, however the value of AP would need to be reliably re-treatable by the smartcard. Indeed it is possible to consider an AP value which changes with each authentication action to thwart replay attacks, but the ‘next value’ would need to be predetermined by the smartcard, as it is a component part of data stored on the card between authentication processes in non-volatile memory as will be seen later.
The approach is described in technical detail below, firstly from the end user’s perspective, and secondly from the perspective of the security protocols themselves.
User View The user’s view is of two distinct processes, one is user authentication and the other is of transaction processing. How these two processes are inter-related is very much a matter of security policy and application design. In a rigorous design, user authentication would need to take place each time a transaction is signed; in a less rigorous design, user authentication would take place at the beginning of a ‘workstation session’ and terminate with the removal of the smartcard or after a pre-defined period of inactivity (or activity!).
In the simplest implementation, AP could be a hash value derived from the user’s identity and password. Indeed the user’s identity could be the user’s Public Key Certificate, although this is not necessary. By introducing a ‘sign-on count’ or smartcard stored (and presented) random number in the data to be hashed, then AP could vary from one transaction to the next.
To cater for the myriad of approaches, the smartcard would act as a state machine. It would allow transition from ‘unauthorized’ to ‘authorized’ when user authentication was successful, and in the opposite direction
\
/
User ID, Password,
* Authorisation Parameter (AP)
(Smart Card Processed Values)
J Signature Authorisation Value (SAV)
d SAV+SKH
I
ti
User Authentication Value (UAV) (Smart Card Stored Values)
SAV+KEY t
Card Unique Key (KEY)1
Secret Key Hash (SKH) c---+
b
.-+
reversible functions Figure 2.
one-way functions
Computers & Security, Vol. 14, No. 8
In order to overcome an attack in which a stolen smartcard is probed and the user authentication value obtained from memory, the value of the current or next AP is not stored in non-volatile memory on the card. Instead, two further values are derived from AI? These are UAV (User Authentication Value) and SAV (Signature Authorization Value). UAV should be derived Ii-om AP using a one way function such that UAV cannot be used to derive SAV. In its simplest form SAV could be AP itself, and UAV could be a hash value of SAV, or SAV enciphered using a smartcard held key, the result then being EXORed with SAV. UAV is stored directly in non-volatile memory of the smartcard, and is used to verify the correctness of the next value of AP that is presented. Verification of UAV unlocks the smartcard and places it in an authorized state. UAV acts like a PIN or Password, but avoids having to have these values stored on the smartcard. The verification of UAV also guarantees the correctness of the derived SAV which is essential to the successful operation of the signature process. SAV is itself not stored explicitly on the smartcard. The use of the AP based approach allows a user to change the underlying PIN or Password locally by presenting the old PIN or Password as well as the new. The old value and new value of AP may be calculated and so old and new UAV and SAV values may be derived. The new values may then replace the old only if the old UAV was correct. Although SAV is not stored explicitly on the card, it is stored implicitly, and its means of storage must permit this ready replacement of old with new. The means of storage presented in this paper is as one part of an encryption key The whole key has the value of SAV+KEY (where + denotes the EXOR function). From this value neither SAV nor KEY may be derived without a knowledge of the other value, this is why it should not be possible to derive SAV from the stored value of UAV. However, this form of storage of SAV+KEY means that the. value of SAV may be replaced as frequently as desired simply by further EXORing, as for example in the following equation: (SAVold + SAVnew) + (SAVold + KEY) + KEY)
= (SAVnew
If the smartcard always maintains the value of the next SAVnew+KEY, then to effectively use the value ofKEY, the correct next value of AP must be made available to the card. By tying the key value stored on the card to the user authentication process of unlocking the card, and by not storing the users password on the card, a strong linkage is achieved between user authentication and key usage. The key that will actually be used is a further derivative of KEY which itself cannot be derived by the card without SAVnew. As will be seen, KEY need never be held ‘native’ in the card even in volatile memory. These associations then directly tie the users authentication to the signature process (yet to be described), and protect the user against theft of the card. This then lays the foundation for extending the non-repudiation property of the digital signature (performed elsewhere) right back to the user.
Cryptographic
View
The discussion above has demonstrated the ability to derive a pre-determined KEY value on the smartcard only following successful user authentication, and without the smartcard storing either the value of the user authentication token (for example a password) or the value of the KEY in non-volatile storage. The value of KEY is therefore protected against probing even if the card has been stolen. The value of KEY is predetermined, and so may be known to the signature server through a process of key exchange with the smartcard initialization system. Indeed it could potentially be shared among several servers if necessary to meet the needs for performance, throughput, resilience or topology. A similar technique could be used to protect the smartcard stored value of any other secret data, and is assumed to be used for protecting the value of the Secret Key Hash (SKH) which is stored on the smartcard (e.g. the value SAV+SKH could be stored). SKH is a hash value of the user’s secret key as stored at the signature server. The hash could cover not only the value of the key itself, but also any control information that belongs to the key and is stored with it (such as the identity of the owning user, and the validity period of the corresponding public key certificate). The value of SKH itself is not stored at the signature server, but only on the smartcard. As will
687
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
be seen, it is the unique ability of the smartcard to present the signature server with the value of SKH that allows the smartcard to control the server’s signing function.
Uniqueness can be guaranteed by incorporating within the message and the calculation of MSH the identity of the smartcard and the value of the smartcard derived transaction counter.
The smartcard could simply transfer the value of SKH in the clear, or SKH enciphered using the value of KEY, but both of these approaches would be subject to replay attack. To prevent replay attack, and to bind the transfer to a single specific message, the following is transferred from the smartcard to signature server:
At the signature server then, the value of the user’s secret key is stored enciphered using SKH, along with its associated control information. Within the encapsulated process, the signature server has the original message, has derived a value assumed to be SKH, and has deciphered the user’s secret key hopefully into the clear. Before using the key to sign the message, the server now recalculates SKH from the control information and deciphered secret key value, and compares the results with the received value of SKH; only if this comparison is successful can it be guaranteed that the genuine value of the secret key has been obtained, and that all of the processes and protocols have been preserved with integrity. If the values are not the same, the signature request is rejected.
Here the value SKH is enciphered using the key KEY +MSH, where MSH is a hash of the message to be signed, and as a key management process triple-encipherment using a double-length DES key (KEY+MSH) is used. It should be noted that this value is independent of the users original authentication parameters, and ofthe users original password;but could not have been created without successful user authentication. This enables user authentication and password change to be purely a local matter while at the same time preserving the non-repudiation property. The key value KEY+MSH can be derived from the stored value KEY+SAV by EXORing the stored value with SAV+MSH, thereby avoiding the need for the true value of KEY ever to be held on the smartcard. The signature server can recover SKH from this token only if the original message from which MSH is derived is also presented with the token. At the signature server it is therefore essential that the steps of generating MSH from the message, and of deciphering SKH and of signing the message are all encapsulated in a single processes; in other words the implementation must not permit a different message to be signed than that which was used to derive MSH. This encapsulation would ideally be achieved through the use of tamper resistant hardware. Preventing misuse of the signature server itself may be assured by applying control-vector technology to the DES key-part ‘KEY’ thus ensuring that the received enciphered form ofSKH cannot be deciphered through any other processes supported by the signature server. The smartcard then binds a specific message to the delivery of the enciphered SKH, and thereby also prevents replay attacks so long as messages are unique.
Having successfully verified SKH, the server may now reformat the message, by for example removing the smartcard identity and transaction count, create a hash using the externally defined hashing standard, and build a signature for the message in conformance to any externally defined application standard. The signature may then be returned to the requester, and the values of SKH along with the users clear secret key destroyed from within the tamper resistant enclosure of the signature server thus preventing any possibility of reuse. If at any time the smartcard or user are thought to have been compromised, then the stored value of the enciphered secret key may be destroyed at the signature server, and so the corporation can guard against theft of signature keys and smartcards.
Initialization The essential elements of initialization are to deliver to the various components the information defined below. *To the user: 1. The smartcard and initial password To the smartcard:
??
1. KEY-tSAVinit
Computers & Security, Vol. 14, No. 8
2. UAVinit 3. SKH+SAVinit To the certification
??
authority:
1. User’s public key
It is beyond the scope of this paper to further define the management and initialization processes necessary to describe the functions defined. However, these are generally well understood.
To the signature server:
??
1. Es&Secret
If this centre also happens to be the security server itself, then the user’s secret keys do not need to be distributed. However, the ability to distribute the users secret key securely to a signature server also allows the implementation of multiple servers to support throughput or resilience needs.
Key)
2.KEY 3. User’s public key certificate The simple assumption of a ‘Security Initialization Centre’ which is cryptographically linked to each of the above parties, and which performs the following roles could readily fir&l the initialization requirements in a straight forward way. Key Generation
??
Centre:
1. Generates DES keys (e.g. KEY) and Public Key Pairs User Administration
??
Centre:
1. Creates and distributes User IDS and initial passwords Registration
??
1. Registers keys
Authority:
Benefits The benefits of this approach over either a wholly smartcard based signature system, or a system which does not involve smartcards (but relies for example on the user’s password to directly encipher the user’s stored secret key) have been made clear. In this section of the paper these benefits are therefore merely identified, and are not further elaborated.
End User Control User authentication
??
bound to the signature process.
Password change is a local function.
??
Password validation.
??
user identities and their associated public
Corporate Control
2. Sends public keys to the CA for certification
Withdrawal of certificates no longer the only control measure.
??
3. Maintains directory records Control Vector compatibility
??
Smartcard Initialization
??
Centre:
1. Initializes and personalizes smartcards 2. Installs initial security parameters on the smartcard (UAV, SKH+SAV KEY+SAV) Key Distribution
??
Centre:
Control over secret key (recovery and deletion).
??
Secure generation of secret key (no distribution).
??
@Sensitive values not stored explicitly (Password, KEY, SAV, SKH) .
on smartcard
1. Distributes enciphered secret keys to security servers (further enciphered under a bilateral DES key)
689
Controlling Digital Signature Services Using A Smartcard/Christopher J Holloway
@User secret key not stored explicitly on the security servers. Secret key unusable without smartcard.
??
External Standards Supports external signature standards.
??
Internal protocols and technologies of external standards.
??
are independent
Performance Server level hardware performance
??
for signing.
Smartcard performance adequate for hashing and DES operations.
??
Multiple servers for throughput and resilience.
??
Smartcard Costs Smartcard functions not burdensome cost technologies.
??
to current low
No security functions required of smartcard reader.
??
Accountability Non-repudiation
??
preserved.
Use of secret key tied to smartcard.
??
Smartcard tied to possession and password knowledge.
??
Summary In this paper a number ofrequirements for the corporate user ofdigital signature technology have been identified. These appeared at first sight to be demanding security controls and usability requirements over and above those assumed of normal signature systems. However, once the requirements were fully analyzed, an approach was described which not only met the additional requirements, but did so while at the same time reducing the likely implementation cost, by reducing the burden placed on the smartcard, and increasing the effective performance be delegating signature processing to a shared server. This approach appears therefore to be unique in raising levels of security, usability and performance while at the same time reducing potential implementation costs and adhering to external standards. It should therefore be of extreme interest to all corporate users who wish to enter the world of electronic commerce backed by digital signature and non-repudiation.
Secret key can be destroyed rapidly if necessary.
??
*Only one point of usage for secret key (or a small number with multiple servers). Focal point for auditing (signature server)
??
Message cryptographically through to server.
??
690
bound
from smartcard
Chris Holloway is an IBM Corporate Technical StaE Member working for the Security Solutions Group of IBM UK. For the past 18 years he has specialized in the application of cryptography to transaction networks and has helped shape the IBM cryptographic products and solutions which are available today. This paper was first presented at Compsec International ‘95 in London in October.