Secure Networking - CQRE (Secure) '99: International Exhibition and Congress Düsseldorf, Germany, November 30 - December 2, 1999, Proceedings

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen

1740

3

Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Singapore Tokyo

Rainer Baumgart (Ed.)

Secure Networking – CQRE [Secure] ’99 International Exhibition and Congress D¨usseldorf, Germany, November 30 - December 2, 1999 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editor Rainer Baumgart Security Networks GmbH Weidenauer Str. 223-225, 57076 Siegen, Germany E-mail: [email protected]

Cataloging-in-Publication data applied for

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Secure networking - CQRE (Secure) ’99 : international exhibition and congress, D¨usseldorf, Germany, November 30 - December 2, 1999 / Rainer Baumgart (ed.). Berlin ; Heidelberg ; New York ; Barcelona ; Hong Kong ; London ; Milan ; Paris ; Singapore ; Tokyo : Springer, 1999 (Lecture notes in computer science ; Vol. 1740) ISBN 3-540-66800-4

CR Subject Classification (1998): C.2, E.3, D.4.6, K.6.5 ISSN 0302-9743 ISBN 3-540-66800-4 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. © Springer-Verlag Berlin Heidelberg 1999 Printed in Germany Typesetting: Camera-ready by author SPIN: 10749957 06/3142 – 5 4 3 2 1 0

Printed on acid-free paper

Preface The CQRE [Secure] conference provides a new international forum giving a close-up view on information security in the context of rapidly evolving economic processes. The unprecedented reliance on computer technology has transformed the previous technical side-issue "information security" to a management problem requiring decisions of strategic importance. Thus one of the main goals of the conference is to provide a platform for both technical specialists as well as decision makers from government, industry, commercial, and academic communities. The target of CQRE is to promote and stimulate dialogue between managers and experts, which seems to be necessary for providing secure information systems in the next millennium. Therefore CQRE consists of two parts: Part I mainly focuses on strategic issues of information security, while the focus of Part II is more technical in nature. This volume of the conference proceedings consists of the reviewed and invited contributions of the second part. The program committee considered 46 papers and selected only 15 for full presentation. For the participants’ convenience we have also included the notes of the invited lectures and short workshop talks in this volume. The selection of papers was a difficult and challenging task. I wish to thank the program committee members who indeed did an excellent job in reviewing and selecting the papers and providing useful feedback to authors. Each submission was blindly refereed by at least three reviewers to make the selection process as fair and objective as possible. The program committee was assisted by many colleagues who reviewed submissions in their field of expertise. My thanks to all of them. I would also like to thank the entire CQRE-team for their kind assistance in organizing this event. My special thanks to our hosts from Messe-Düsseldorf GmbH and especially to N. Mizera, M. Kotschedoff, S. Spamer, A. Viefers, and B. Wagner who greatly contributed to the success of this challenging project with their untiring engagement and timely decisions. Furthermore I would like to thank the team from Brodeur-Kohtes & Klewes around B. Boendel and my colleagues T. Gawlick, A. M. Schlesinger, and D. Hühnlein for kindly assisting me in administrative tasks. Last but not least, I wish to thank all the authors who submitted papers, making this conference possible, and the authors of accepted papers for updating their work in a timely manner , allowing the production of these proceedings. September 1999

Rainer Baumgart

Table of Contents

Risk Management Developing Electronic Trust Policies Using a Risk Management Model ..................... 1 Dean Povey

Security Design SECURE: A Simulation Tool for PKI Design............................................................ 17 Luigi Romano, Antonino Mazzeo, Nicola Mazzocca Lazy Infinite-State Analysis of Security Protocols..................................................... 30 David Basin

Electronic Payment Electronic Payments – Where Do We Go from Here? ............................................... 43 Moti Yung, Yiannis Tsiounis, Markus Jakobsson, David MRaihi

SmartCard Issues PCA: Jini-based Personal Card Assistant ................................................................... 64 Roger Kehr, Joachim Posegga, Harald Vogt An X.509-Compatible Syntax for Compact Certificates ............................................ 76 Magnus Nyström, John Brainard

Applications Secure and Cost Efficient Electronic Stamps ............................................................. 94 Detlef Hühnlein, Johannes Merkle Implementation of a Digital Lottery Server on WWW..............................................101 Kazue Sako

VIII

Table of Contents

PKI-experiences (Workshop Notes) Cert’eM: Certification System Based on Electronic Mail Service Structure .............109 Javier Lopez, Antonio Mana, Juan J. Ortega A Method for Developing Public Key Infrastructure Models....................................119 Klaus Schmeh The Realities of PKI Inter-operability .......................................................................127 John Hughes

Mobile Security Mobile Security – An Overview of GSM, SAT and WAP ........................................133 Malte Borcherding Secure Transport of Authentication Data in Third Generation Mobile Phone Networks ...................................................................................................................142 Stefan Pütz, Roland Schmitz, Benno Tietz

Cryptography Extending Wiener’s Attack in the Presence of Many Decrypting Exponents............153 Jean-Pierre Seifert, Nick Howgrave-Graham Improving the Exact Security of Fiat-Shamir Signature Schemes.............................167 Silvio Micali, Leonid Reyzin

Network Security (Workshop Notes) On Privacy Issues of Internet Access Services via Proxy Servers ............................183 Yuen-Yan Chan Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)........192 Bruce Schneier, Mudge, David Wagner

Key Recovery Auto-recoverable Auto-certifiable Cryptosystems (A Survey)..................................204 Moti Yung, Adam Young

Table of Contents

IX

Intrusion Detection A Distributed Intrusion Detection System Based on Bayesian Alarm Networks.......219 Dusan Bulatovic, Dusan Velasevic

Interoperability Interoperability Characteristics of S/MIME Products................................................229 Sarbari Gupta, Jerry Mulvenna, Srivinas Ganta, Larry Keys, Dale Walters The DEDICA Project: The Solution to the Interoperability Problems between the X.509 and EDIFACT Public Key Infrastructures ......................................................242 Montse Rubia, Juan Carlos Cruellas, Manel Medina

Biometrics Multiresolution Analysis and Geometric Measures for Biometric Identification Systems......................................................................................................................251 Raul Sanchez-Reillo, Carmen Sanchez-Avila, Ana Gonzales-Marco Author Index............................................................................................................259 Dates and Deadlines of CQRE [Secure] 2000.........................................................261

Developing Electronic Trust Policies Using a Risk Management Model Dean Povey Security Unit, Cooperative Research Centre for Enterprise Distributed Systems??, Level 12, S-Block, Queensland University of Technology, Brisbane Qld 4001, Australia, [email protected]

Trust management systems provide mechanisms which can enforce a trust policy for authorisation and web content. However, little work has been done on identifying a process by which such a policy can be developed. This paper describes a mechanism for developing trust policies using a risk management model, and relates this to a conceptual framework of trust. The process uses an extended risk management model that takes into consideration beliefs about the principals being trusted and the impersonal structures and systems involved. The paper also applies the extended risk management model to a hypothetical case study in which an individual is making investments using an electronic trading service. Abstract.

1

Introduction

Regardless of the strength or robustness of a given security mechanism, its effectiveness is limited without the existence of trust. Security protocols, cryptographic devices and digital signatures rely on the ability to trust either one or more parties, mechanisms or equipment to be sure that the assets they protect remain safe. In the physical world we derive much of our notions of trust from the tangible nature of things. For example, we perceive the information in a book to be worth reading because we know that it costs a lot of money to print a book, because the logo on the side shows that it has been reviewed by a publisher of repute, and often because a library has thought it worthwhile enough to stick it on their shelf. Similarly, we are convinced by the stability and trustworthiness of a bank, because the diÆculty of licensing a fraudulent organisation and the cost of setting up branches, ATM networks and marketing etc, would make it prohibitively expensive. However, the shift toward e-commerce means that we can no longer infer trust from physical, tangible things. We need to rethink our approach to trust ??

The work reported in this paper has been funded in part by the Co-operative Research Centre Program through the Department of Industry, Science & Tourism of the Commonwealth Government of Australia

R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 1-16, 1999  Springer-Verlag Berlin Heidelberg 1999

2

D. Povey

so that we can rely on the information and actions of people in a virtual world, with the same degree of con dence that we do in the real world. Trust management systems such as PolicyMaker[1], KeyNote[2], and REFEREE[3] provide mechanisms that can enforce a trust policy for authorisation and web content. However, little work has been done on identifying a process by which a trust policy for such systems can be developed. This paper describes a mechanism for developing trust policies using a risk management model, and outlines a hypothetical case study to illustrate the usefulness of such a scheme.

2

Risk Management

Risk management is the total process of identifying, controlling, and minimising the impact of uncertain events [4]. The Common Criteria [5] outlines a model for relating dierent elements of the risk management process, which is given in gure 1. In general, risk management for information security involves the following process: 1. Identify the assets to be protected, the threats to these assets, and the expected impact if those assets are compromised. 2. Identify the vulnerabilities or weaknesses which can lead to these threats arising. 3. Analyse the risk (i.e. the likelihood and consequences) of the vulnerabilities leading to these threats being exploited. 4. Determine whether to accept or treat the risk. Risk is treated using countermeasures which seek to reduce either the likelihood or consequence of a risk, or defer the risk to some third-party (e.g. insurance). Implementing a countermeasure has a cost associated with it, which must be balanced against the expected utility of implementing the measure. Countermeasures may also expose additional risks, or retain residual risk which must be considered in the risk management process. Risk management is well understood, and numerous standards and methodologies exist to describe the process (e.g. [6][7][8]). Integrating risk management into the trust management process is therefore useful, as it will enable us to leverage o this existing body of work.

3

Trust

To integrate trust with risk management, it is necessary to provide a framework by which dierent aspects of trust can be described and related. One of the more comprehensive frameworks for trust was developed by McKnight, Cummings and Chervany, and results from a survey of sixty papers across a wide range of disciplines[9][10]. McKnight et al's model provides a classi cation system for dierent aspects of trust, as well as a system for showing how trust can in uence behaviour and de nes the following constructs:

Developing Electronic Trust Policies Using a Risk Management Model

3

value Owners wish to minimise impose to reduce countermeasures that may possess

that may be reduced by

vulnerabilities may be aware of leading to that exploit

risk to

Threat Agents give rise to

that increase

assets

threats to wish to absue and/or may damage

Fig. 1.

Security concepts and relationships from the Common Criteria

Trusting behaviour

the extent to which one person voluntarily depends on another person in a speci c situation with a feeling of relative security, even though negative consequences are possible. This construct is in eect describing the \act" of trusting, and implies acceptance of risk (negative consequences) by the trusting party. Trusting intention the extent to which one party is willing to depend on the other party in a given situation with a feeling of relative security, even though negative consequences are possible. A trusting intention usually leads to trusting behaviour. Trusting intentions relate directly to the security policy which determines how entities in the system are trusted. A trusting intention essentially speci es a willingness to trust a given individual in a given context, and implies that the trusting entity has made decisions about the various risks and bene ts of allowing this trust. Trusting beliefs the extent to which one believes and feels con dent in believing that the other person is willing and able to act in the trusting party's best interests. A trusting intention will be largely based on the trusting par-

4

D. Povey

ties cognitive beliefs about the other person. McKnight et al describe four categories of trust belief: 1. Benevolence - the belief that a person cares about the welfare of the other person; 2. Honesty - the belief that a person makes agreements in good faith; 3. Competence - the belief that a person has the ability to perform a particular task; and 4. Predictability - the belief that a person's actions are consistent enough to forecast what they will do in a given situation. Trusting beliefs characterise the information by which we make our trusting decision about a given individual. They may be based on evidence, recommendations from third parties (which themselves must be trusted), and often by simple intuition. We can think of trusting beliefs as being the measures by which we will determine whether a given entity should be trusted given a speci c risk pro le. It should be noted that not all beliefs need to be strong in order to trust an individual in a given context. In business transactions, the issue of benevolence is rarely important (although the presence of malevolence may be) when compared to the issues of honesty, predictability, and most importantly competence. Also, some beliefs are easier to be con dent about than others. It is usually simpler to obtain a measure of an organisations competence (by accreditation and recommendations), and predictability (by past dealings); than it is to obtain a measure of their benevolence and honesty. Like trusting intentions beliefs may also be speci c to a context (e.g. belief in the competence of a lawyer to write contracts, does not extend to their competence to perform neurosurgery). As we shall see it is trusting beliefs which are the most important to ascertain, as they will determine the con dence by which we establish our trusting intentions. System trust the extent to which one believes that proper impersonal or institutional structures are in place to enable one to anticipate a successful future endeavour. An important dierence between system trust and trusting beliefs, is that while trusting beliefs relate to the attributes of another person whom is being trusted, system trust relates to the actual system/infrastructure under which the trusted action is taking place. System trust is important, as it provides stability to our interactions with people and organisations. Legal and regulatory systems provide punitive mechanisms to discourage malicious behaviour, and accreditation and certi cation schemes provide systems which allow us to evaluate an organisations competence. Like trusting beliefs, system trust is a critical component of determining a trusting intention. Dispositional trust the extent to which one has a consistent tendency to trust across a broad spectrum of situations and persons. A person may have dispositional trust because they either believe in the general good nature of people, or they believe that they will achieve better outcomes by tending to trust people.

Developing Electronic Trust Policies Using a Risk Management Model

5

Situational trust

the extent to which one intends to depend on a non-speci c party in a given situation. Situational trust is related to dispositional trust in that it is a general intention. However, it is dierentiated by the fact that where dispositional trust refers to a broad spectrum of situations and persons, situational trust is related only to a speci c situation. Belief formation processes The process by which new beliefs are developed and integrated into our schema about the world. These constructs do not exist in isolation, but have well-de ned relationships between them. We can clearly see that a trusting behaviour relies on the existence of a trusting intention, which in turn is created through the existence of one or more of trusting beliefs, system, dispositional or situational trust. Figure 2 shows the various constructs and their dependencies.

Trusting Behaviour that lead to Situational Decision To Trust

influence

Trusting Intentions

influences influences

Dispositional Trust

influences

System Trust

Trusting Beliefs form Belief Formation Processes

Fig. 2.

Related Trust Constructs

McKnight et al's conceptualisation of trust as multi-dimensional is both powerful and compelling. It also goes some way to explaining the diÆculty that researchers in many disciplines have encountered in the formulation of a single broad de nition of what trust is. In addition, their wide consultation of literature from many disciplines including management, communication, sociology, social psychology and economics, positions their model within a context that it is suÆciently broad to categorise most de nitions of trust.

6

D. Povey

4

An Extended Risk Model

To extend the risk model to encompass trust, it is important to see the goal we are trying to achieve in developing a trust policy. A risk management process seeks to identify risks, and to determine whether those risks should be treated or accepted. Trust management on the other hand, seeks to identify the circumstances under which we are prepared to accept risks that may be exposed by relying on certain entities. The key to merging these two concepts is to focus on risk as the common element. We can see that the de nition for trust management can be related to the decision about risk acceptance/treatment. In eect, trust becomes a risk treatment option, i.e. you are prepared to accept risks if you trust the entities that can expose them. This fact is intuitively obvious to most people. The more someone is trusted, the more we feel we can rely on them, and consequently the more risk we expose ourselves to. When we talk about levels of trust, we are really discussing the level of risk that we are prepared to accept for relying on a trusted entity. 4.1

Relating Trust Policies to McKnight et al's Model

The constructs described in section 3 provide a vocabulary for describing how trust is formed. By combining this process with the risk management process we can show how trust policies can be captured from the environment using a structured process. In McKnight et al's model, the trusting intentions form the trust policy, which is essentially a statement of the conditions under which we are prepared to trust a given entity. As noted in section 3, these intentions are formed from a number of sources: our dispositional trust, our beliefs about the entity we are trusting, how we trust the systems which we look to to support and protect us, and our tendency to trust in the given situation. As described, it is important to consider the risks of the behaviour of entities that we intend to trust. However, it is also important to consider the utility or value of trusting this entity, as this can considerably alter the decision to accept or treat a risk, or to not allow the behaviour to occur. On further analysis, we see that there is also important interactions between components of the trust framework that we must consider. One of the most important elements of forming the trusting intention is the existence of trusting beliefs about an entity. These are important, as they are the only input into the trusting intention decision which is speci c to a given entity. McKnight et al's model identi es a belief formation process, which is an iterative mechanism that uses information and experience gathered from the environment to form one or more trusting belief about an individual. In this extended risk management model, the information that is input into this process is called a trust metric. Trust metrics contribute to our understanding about the four trusting beliefs (competence, predictability, honesty and benevolence); and include: {

information based on previous experience;

Developing Electronic Trust Policies Using a Risk Management Model { { { { {

7

recommendations from third parties; certi cations or quali cations; memberships of professional organisations; certi ed histories (criminal records, credit reports etc.); and brand.

As we can see from this list, the trust metrics themselves can be subject to trust decisions about their accuracy. Thus, the belief formation process is recursive. Another important observation, is that metrics may have a cost associated with them (e.g. obtaining a credit report may cost money). In developing a trust policy, we must be careful to ensure that the costs of gathering metrics do not outweigh the utility gained from trusting, and that we maximise the value of our metrics, such that the cost re ects the contribution to our understanding of the trusting beliefs. Figure 3 shows how these constructs relate to form an extended risk model. 4.2

Using the Extended Risk Model for Trust Management

By combining the concepts from risk management with the extended risk model, we can establish the following process for establishing a trust policy: 1. Identify the entities and situations you want to determine a trust policy for. This allows the establishment of trust contexts, which encapsulate the security context within which trust decisions will be made. Note that such a context should include both all probable trusted entities and threat agents. 2. Identify the assets to be protected within this trust management context, the threats to these assets, and the expected impact if those assets are compromised. 3. Calculate the expected utility of trusting entities in the given situations. 4. Identify the vulnerabilities or weaknesses which can lead to these threats arising. 5. Analyse the risk (i.e. the likelihood and consequences) of the vulnerabilities leading to these threats being exploited. 6. Determine the adequacy of existing countermeasures which may mitigate these risks. 7. Determine the required beliefs and con dences in these beliefs required to trust (or distrust) entities which may expose the given risks. 8. Identify the various impersonal structures or systems which have an impact on the given trust context. Common systems will include legal or regulatory frameworks. Analyse our con dence in these systems to mitigate risks. 9. Identify metrics which will can help make decisions about the required trusting beliefs, and determine the con dence we have in the accuracy of these metrics (in itself a mini trust-management decision). 10. Evaluate the costs of gathering these metrics, and relate this to the expected utility, and their contribution to con dence in the trusting beliefs. Use this evaluation to select the subset of metrics which can be used to establish the trusting beliefs.

8

D. Povey

11. Using the metrics, establish the beliefs identi ed in step 7 and determine whether they meet the required con dence levels. 12. Based on this evidence and the levels of system trust, either unconditionally accept a trusting intention for the evaluated entity in the given situation; reject the trusting intention; or treat the risk and reevaluate.

value have

identify expect Owners use have have

are used by

Trust to form Formulation Processes

Trust Metrics that have

that must be less than

Costs Trusting Beliefs

Dispositional Trust

that influences

that influence

for permitting

about

Trusted Entites about

System Trust

Trusting Intentions

that influences

Situational Decision To Trust

Utility

that lead to

that influences

that influence Trusting Behaviour

Risks that may expose

that may influence Fig. 3.

to Assets

Extended Risk Model

Trusted entities and threat agents may be either known or unknown. In the case that they are known, then the policy should include the actual measurements for this entity obtained using the trust metrics. In the case that they are unknown, the policy should contain the list of metrics which are required to determine whether an entity should or should not be trusted. If a trusting intention is rejected, then risk may be treated by a number of mechanisms: 1. Add countermeasures which decrease the risk 2. Defer risk to a third party (e.g. insurance) 3. Increase the required belief trusting con dences by obtaining more or better metrics.

Developing Electronic Trust Policies Using a Risk Management Model

9

We can see that this process extends the risk management by integrating components of the trust model.

5

Writing Trust Policies

The outcome of the trust management process should be a policy which documents the decisions made. The policy should include:

Trust metrics A list of the metrics used in a trust policy, the trusting beliefs they measure, and their appropriateness for given trust contexts.

Con dence levels A description of the list of qualitative or quanti tative labels that indicate our level of con dence in a given trusting belief.

Trust context policies An articulation of the policy for making trusting decisions for each of the identi ed trust contexts.

These items are described below.

5.1 Trust Metrics One important component of the extended risk model is the use of trust metrics. These are mechanisms which can be used to enhance our con dence about certain beliefs. An important thing to note is that the trust metrics themselves need to be trusted, and we will have a con dence level associated with their precision. A trust policy should begin by evaluating the trust metrics which it will use, and providing con dence levels which we have in their measurements in a given context. When specifying the metrics used in the policy, the policy writer should state:

{ the contexts in which that metric is trusted; { the belief(s) that they measure; { the con dence in that metric for those contexts in which it is trusted, and how this is measured (NB: metrics can be evaluated using other metrics); and { the cost of evaluating that metric. In general, metrics should require close scrutiny as we are exposed to more systemic risk by trusting them.

5.2 Con dence Labels The policy writer should include con dence labels which may be attached to particular beliefs in the trusting decision. Con dence labels can be either qualitative or quantitative, and are similar to the likelihood measurements which are commonly used in risk management. The con dence label represents the likelihood that the belief it is attached to is correct, i.e high con dence means a high probability of correctness. Figure 4 gives an example of qualitative and

10

D. Povey

Label

Quantitative

Qualitative

Very Low A belief with this label has very low con dence, it p 0:5 relied on only if the risk is low. Medium A belief with this label has medium con dence, it may p > 0:95 be relied on for contexts at medium risk High A belief with this label has high con dence, it may be p > 0:995 relied on in high risk situations. Very High A belief with this label has very high con dence, it p > 0:999 may be relied on in all situations. Fig. 4.

Example con dence labels

quantitative labels which might be used in a trust policy. In the quantitative descriptions, p is the probability that a belief with that given label is correct. Con dence levels may be combined to obtain new con dence measures. This is useful when for example a number of metrics are being used to determine the level of a trusting belief. Quantitative metrics can be combined, simply by summing the probabilities (i.e. only one of the metrics has to be correct, for the belief to be correct). Qualitative metrics can be combined either on an ad hoc basis or by using rules to combine levels (e.g. HIGH = 3  MEDIUM). 5.3

Trust Contexts

These are all the situations and environments that are under consideration for the trust policy. For each trust context, the trust policy should detail: { { { { { {

a description of the context; the risks inherent in trusting entities for a given context; the expected utility of trusting entities for the given context; a list of the possible trusted and threat agents; a list of the beliefs and con dences required to trust/distrust entities in the trust context; and a list of the required/available metrics appropriate to establish these beliefs.

Contexts may be included within other contexts, for example a context which covers user access to a web site, may also include a sub-context for privileged access to les. This allows a simple hierarchical organisation of trust policies. If speci c entities are to be trusted for a given context, these entities should be listed along with the rationale for trusting them. Where the policy is specifying criteria for trusting unknown entities, it is sometimes useful to separate out the requirements in terms of the type of entity which is to be trusted. For example, entities could be divided into customers, employees and contractors. The policy writer may wish to express diering levels of required beliefs and con dences in each of these, as there are varying levels of utility for diering classes to exploit threats, and as such varying likelihood of threats occurring.

Developing Electronic Trust Policies Using a Risk Management Model

6

11

Hypothetical Case Study

In this section, the extended risk management model is applied to a hypothetical case study in which an individual is making investments using an electronic trading service. The case study serves to illustrate the complexity involved in evaluating a given trust decision, as it shows how making one trust decision relies on many other trust decisions. It should be noted that in the following example, some of the steps described in section 4.2 have been consolidated together. The aim is to give a general feel to how a trust policy can be developed using the mechanism, and not to explicitly show how the policy should be expressed. 6.1

Scenario

Bob is a nave investor, with a small amount of cash to spend. He is contemplating some direct share investments, and so asks his friend Alice who is wise in the ways of sharemarket for her advice. Alice suggests he makes a number of investments, but recommends in particular, a recently listed small Internet company { ComDot.com. She says that she has heard on the grapevine, that this company is likely to do spectacularly well, once it releases the next version of its new Website construction software. Alice also suggests that rather than fork out for brokerage fees, Bob purchase the shares directly from E-Shares, an online brokering rm which allows small purchases using a credit card. Bob contemplates whether to take Alice's advice. 6.2

Trust Management Process

Based on the information from Alice, Bob has to make a number of decisions about whether to invest in ComDot.com shares. Doing this requires a number of trusting decisions, which may also involve gathering information, and determining whether that should be trusted. Following the trust management process outlined in section 4.2, Bob sets about determining his trust policy. The scenario above constitutes Bob's trust management context, i.e. he is making decisions about trust within the context of making a speci c decision about buying a certain set of shares using an electronic trading service. There are a number of trusting intentions which Bob must have before he can make this decision: Establishing Trust Management Context

1. Bob must trust Alice to give good advice about the shares; 2. Bob must trust ComDot.com to conduct their business competently; and 3. Bob must trust E-Shares to respect his privacy, and keep his credit card details secure. In addition, Bob must also consider threats from the following sources: {

hackers, who wish to steal Bob's credit card details and make fraudulent purchases;

12

D. Povey

{ ComDot.com's competitors who may wish to spread misinformation in order to gain market advantage; and

{ marketeers, who may wish to use knowledge of Bob's share purchase as fuel for direct marketing campaigns.

Calculate Expected Utility By purchasing the shares, Bob aims to make at

least an 8% per annum return on his investment. By using the online trading scheme he hopes to save up to 20% in brokerage fees.

Identify Assets to be Protected In this scenario, Bob determines that he has three main assets under threat: 1. The cash he is investing (could be lost due to poor investment) 2. His credit card number (there is a threat of disclosure leading to fraudulent transactions on his credit card). 3. His privacy (Bob doesn't want people knowing how he spends his money).

Vulnerability Analysis By analysing his assets and the possible threats, Bob

determines the set of vulnerabilities which may lead to those threats being realised. 1. Information Bob uses to make decisions could be inaccurate. 2. Companies which Bob invests in might go out of business 3. E-shares might disclose private information 4. E-shares might disclose Bob's credit card details 5. Hackers might intercept Bob's credit card details over the Internet.

Risk Analysis For each of the above vulnerabilities, Bob identi es the likelihood and consequences of these vulnerabilities causing threats to be realised. Likelihood is measured qualitatively (RARE, UNLIKELY, MODERATE, LIKELY, CERTAIN), and the label UNKNOWN is used where making this judgement is not possible in this rst analysis (usually due to lack of knowledge about trust levels). Consequences are also indicated qualitatively with the labels: INSIGNIFICANT, LOW, MODERATE, SIGNIFICANT, CATASTROPHIC). This analysis is summarised in gure 5.

Identify Required Beliefs and Con dences Bob now needs to determine

the level of required beliefs in order to accept the risks he has identi ed. We shall brie y outline these decisions for two of the identi ed vulnerabilities:

Information Bob uses to make decisions could be inaccurate

Given the risk identi ed, Bob determines that he has to trust the information he receives about given shares with a HIGH degree of con dence (see gure 4). In order to trust the information he receives, Bob determines he has to know that the sources of the information are competent, honest and predictable; and that his con dence in these beliefs must either be HIGH, or the information must be con rmed from other sources, such that the total con dence for each of these beliefs is HIGH.

Developing Electronic Trust Policies Using a Risk Management Model Item

1. 2. 3. 4. 5.

#

Likelihood

13

Consequences Comments

UNKNOWN SIGNIFICANT Likelihood depends on how much we trust the source of information MODERATE SIGNIFICANT { MODERATE SIGNIFICANT { MODERATE LOW Low consequences, as vendor bares liability for all but $50 of fraudulent transactions UNLIKELY LOW As above, but SSL encrypted link which makes it less likely. Fig. 5.

Risk analysis Summary

Given the identi ed level of risk, Bob decides he needs to only have MODERATE con dence in E-shares competence to protect his credit card details. E-shares might disclose Bob's credit card details

Identify and Evaluate Metrics When relying on information or actions, Bob

determines the following metrics to be used to determine the con dence he has in certain beliefs about that entity.

{ previous experience with the entity (MEDIUM-HIGH con dence); { recommendations from other trusted sources (MEDIUM con dence); { established brands (MEDIUM con dence); { contractual obligations (HIGH con dence); and { regulatory controls (MEDIUM con dence). In addition, he determines the following additional metrics to be used where speci c software countermeasures (e.g. the SSL enabled browser he uses) are used to combat risk:

{ ITSEC or Common Criteria evaluation (HIGH); { open source software which has been heavily scrutinised (MEDIUM); { well known product or vendor (MEDIUM); and { recommendations from other trusted sources (LOW-MEDIUM). Lastly, Bob determines the following metrics which are used where he is relying on a third party security system.

{ disclosure of security practices and procedures (LOW); { third party audit by a trusted auditor (MEDIUM-HIGH); and { certi ed quality system (e.g. ISO9000) (MEDIUM-HIGH). Belief Analysis

14

D. Povey

Bob has already determined the following beliefs about two entities he will rely on for information: Information Bob uses to make decisions could be inaccurate

Alice: Competence (MEDIUM), Honesty (HIGH), and Predictability (HIGH). Alice can be trusted for information, providing the information is con rmed from at least one other mediumly trusted source. These beliefs were determined solely from a long history of past experience with Alice. Reuters News-Wire service: Competence (MEDIUM-HIGH), Honesty (HIGH), and Predictability (HIGH). Reuters can be trusted to report information, providing it can be con rmed by at least one other LOW-MEDIUM trusted source. These beliefs are determined by Reuter's good brand, recommendations from Alice and other friends, and previous experience.

{

{

Bob determines a HIGH level of con dence about E-shares' competence to keep his credit card details secure. This belief is determined from the existence of a certi ed ISO9000 quality system and a third party audit from KPMG which E-shares describe on their web sites. E-shares might disclose Bob's credit card details

Figure 6 summarises Bob's trusting decisions for each of the identi ed vulnerabilities. Trusting Decisions

Item # Trust decision Comments 1.

Accept Risk

2.

Accept Risk

3.

Accept Risk

4.

Accept Risk

5.

Accept Risk

Trust Alice's information (con rmed by a Reuter's article), and a policy is described for trusting subsequent information SuÆcient information is available to trust ComDot.com's competence to do well. A policy is described for obtaining the required trust in other companies whose shares Bob wants to purchase. Bob determines E-shares' privacy policy is suÆcient, and trusts them to enforce it. Bob is convinced by third party evidence that Eshares' is competent at keeping its site secure enough to mitigate this risk. Bob trusts the SSL mechanism used to secure communications with E-shares, and trusts his browser and E-shares web server to implement this mechanism correctly.

Fig.6. Trusting decisions summary 6.3

Summary

This hypothetical case study outlines the application of the trust management process based on the extended risk model. It should be noted that only a sub-

Developing Electronic Trust Policies Using a Risk Management Model

15

section of the full analysis is presented. Nevertheless it serves to illustrate the plausibility of such a technique in a real world situation.

7

Related Work

Khare and Rifkin [11] describe how trust management philosophies can be applied to the World Wide Web, and describe how trust policies can be designed. However, Khare and Rifkin's work is very much focused on the expression of trusting intentions, i.e. they describe how to express a trust policy, but do not provide a methodology for how to derive it. In [12] Jsang describes general criteria for modelling trust in information security and critiques some other existing formal schemes. Further work by Jsang [13] develops these ideas into a formal model based on a concept called subjective logic. Subjective logic allows us to reason about beliefs or opinion using an algebraic notation, and would be useful in the context of working with trusting beliefs in the extended risk model. As indicated, there have been several attempts to build trust management systems [1][2][3]. Of these REFEREE[3] is probably the most notable, as it provides way to integrate with third party recommender systems like the PICS [14] labelling scheme. The REFEREE architecture is also extensible, making it simple to integrate new components into the system. Future work on automating the trust management process could bene t highly by utilising REFEREE as a platform for gathering and evaluating information.

8

Future Work

Decision support systems is a catch all for a wide variety of systems which provide computer support for decision making [4]. There is a signi cant body of work on using decision support systems for risk management [15][8], which could be leveraged to develop similar systems for trust management based on the extended risk model. Another direction for this work might be the development of trust metrics which could be used to automatically establish beliefs about pages on the World Wide Web. Examples of such metrics might include:

{ { { {

number of pages linking to a given web page; trusted pages linking to given web pages; third party recommendations (e.g. PICS labels); and number of hits on a given web page.

Search engines might be useful sources for such information. In particular the Google search engine [16] already uses link counts in order to rate matched pages. Lastly, the importance of considering dynamically changing policies needs to be investigated. Beliefs and trust are not static, but change as new information is received. It would be useful to investigate how policies could be de ned which cope with dynamic changes.

16

9

D. Povey

Conclusions

This paper has presented a scheme for developing trust policies based on an extended risk management model. The scheme was applied to a hypothetical case study, which shows the utility of the process to real world applications. The paper has also discussed related work and given some rm directions for future research in this area.

References 1. M. Blaze, J. Feigenbaum, and J. Lacey. Decentralized trust managment. In Proceedings of the 1996 Symposium on Security and Privacy, pages 164{173, 1996. 2. Matt Blaze, Joan Feigenbaum, and Angelos D. Keromytis. Keynote: Trust managment for public-key infrastructures. In Cambridge 1998 Security Protocols International Workshop, England, 1998. 3. Yang-Hua Chu, Joan Feigenbaum, Brian LaMacchia, Paul Resnick, and Martin Strauss. Referee: Trust management for web applications. In Proceedings of the 6th International WWW Conference, 1997. 4. Dennis Longley, Michael Shain, and William Caelli. Information Security: Dictionary of Concepts, Standards and Terms. Macmillan, 1992. 5. Common Criteria for Information Technology Security Evaluation { Part 1: Introduction and general model, May 1998. 6. Standards Australia/Standards New Zealand. AS/NZS 4360:1999 Risk Management, 1999. 7. Communications Security Establishment (CSE) Government of Canada. A guide to Security Risk Managment for Information Technology Systems MG-2, 1992. URL: http://www.cse.dnd.ca/cse/english/Manuals/mg2int-e.htm. 8. Dennis Longley, Michael Shain, and William Caelli. Information Security: Dictionary of Concepts, Standards and Terms, pages 450{453. Macmillan, 1992. 9. D. Harrison McKnight, Larry L. Cummings, and Norman L. Chervany. Trust formation in new organizational relationships. In Information and Decision Sciences Workshop, October 1995. URL: http://www.misrc.umn.edu/wpaper/wp96-01.htm. 10. D. Harrison McKnight and Norman L. Chervany. The meanings of trust. Technical report, MISRC Working Papers Series, 1996. URL: http://www.misrc.umn.edu/wpaper/wp96-04.htm. 11. Rohit Khare and Adam Rifkin. Weaving a web of trust. World Wide Web Journal, 2(3), 1997. 12. Audun Jsang. Prospectives for modelling trust in information security. In Vijay Varadharajan, editor, Proceedings of the 1997 Australasian Conference on Information Security and Privacy. Springer-Verlag, 1997. 13. Audun Jsang. A model for trust in security systems. In Proceedings of the Second Nordic Workshop on Secure Computer Systems, 1997. 14. W3C. Platform for Internet Content Selection (PICS) technical speci cation. URL: http://www.w3.org/PICS/. 15. Giampiero E.G. Beroggi and William A. Wallace, editors. Computer supported risk management. Kluwer Academic Publishers, 1995. 16. Google Inc. Why use Google?, 1999. URL: http://www.google.com/why use.html.

SECURE: A Simulation Tool for PKI Design L. Romano1, A. Mazzeo2, N. Mazzocca2 1

Università degli Studi di Napoli “Federico II” Via Diocleziano, 328 I-80124 Napoli, Italy [[email protected]] 2 II Università degli Studi di Napoli Via Roma, 29 I-81031 Aversa (CE), Italy [mazzeo, [email protected]]

Abstract. This work presents a novel methodology for security analysis of computer systems. The suggested approach, called simulated hazard injection, is a variant of simulated fault injection, which has already been employed with success to the design and evaluation of fault-tolerant computer systems. The paper describes the key ideas underlying the proposed methodology, and defines a portfolio of security measures to be extracted from experimental data. These concepts are incorporated in a tool for dependability analysis of Public Key Infrastructure (PKI) based systems. The tool is called SECURE and is currently under development at the University of Naples. The paper describes the architecture of the tool and discusses its potentialities.

1 Introduction Security is of crucial importance in all automated, business-related transactions. Forms of electronic commerce, such as communication via electronic mail, Electronic Data Interchange (EDI), or the World Wide Web, are just a few examples of crucial fields of application, where a security breach may have significant economic impact and/or legal consequences. The deployment of paperless mechanisms can be highly beneficial in reducing business costs and in creating opportunities for new and/or improved customer services. However, the electronic systems and infrastructures that support electronic transactions are susceptible to abuse, misuse, and failure in many ways. All participants, i.e. commercial traders, financial institutions, service providers, and consumers are exposed to a variety of potential damages, which are often referred to as electronic risks [1]. These may include direct financial loss resulting from fraud, theft of valuable confidential information, loss of business opportunity through disruption of service, unauthorized use of resources, loss of customer confidence or respect, and costs resulting from uncertainty. In order to mitigate risks and promulgate the deployment of information security technology on a wide scale in the commercial environment, appropriate security countermeasures, and business and legal frameworks must be established. The following services must be provided [2]: R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 17-29, 1999  Springer-Verlag Berlin Heidelberg 1999

18

L. Romano, A. Mazzeo, and N. Mazzocca

• Confidentiality – Provides privacy for messages and stored data by hiding information using encryption techniques; • Message Integrity – Provides assurance to all parties that a message remains unchanged from the time it was created to the time it was opened by the recipient; • Non-repudiation – Can provide a way to prove that a document came from someone even if he/she tries to deny it; • Authentication – Provides two services. The first is to identify the origin of a message and provide some assurance that it is authentic. The second is to verify the identity of a person logging onto a system and after doing so, continuing to verify that person’s identity in case someone tries to break into the connection and masquerade as the user. For the most part, these services are enabled through public key (asymmetric) schemes rather than private (symmetric) schemes, for these are best able to cope with scalability problems. The distribution of keys, however, is difficult even in the public scheme if the Internet is the communication channel. On the Internet, obtaining a public key requires a certain level of trust. One must know that the public key belongs to the person one thinks it does. Someone might be masquerading as someone else. A solution is to work with a trusted third-party organization called Certificate Authority that distributes public keys for people and organizations and that verifies the credentials of the people associated with the public keys. In this way trust is transferred from a people-trusting-people to a people-trusting-an-organization scheme. This leads to a more complex organism (eventually to a world-wide global organism) incorporating independent certification authorities that can transfer trust among themselves. Such an organism is called a Public Key Infrastructure (PKI). As it is evident from the above description, a Public Key Infrastructure (PKI) is a complex organization, consisting of policies, services, and professionals. In this context, a party who acts or is in a position to act in reliance upon a certificate and its subject public key is referred to as a Certificate User or Relying Party. A certificate will become a sort of global passport and a personal database that holds a wealth of information about the certificate subject in a very secure way. In order to make public-key-based technologies usable on a wide scale, PKIs must support a variety of services, such as: • Registering users – This also entails authenticating certificate applicants. This task can be performed either by the Certification Authorities (CAs) or by separate entities, called Registration Authorities (RAs), that front-end Certification Authority service; • Issuing certificates – A CA has to issue certificates to Subscribers, i.e. parties who are the subject of a certificate and who are capable of using, and are authorized to use, the private key that correspond to the public key listed in the certificate; • Providing Information about Certificate Status – Certificates and other relevant information about certificates must be delivered or made accessible online to Certificate Users; • Issuing Certificate Revocation Lists - If a certificate is to be revoked, Certificate Authorities needs to make potential users of the certificate aware of the revocation.

SECURE: A Simulation Tool for PKI Design

19

Such services must be provided in accordance to a set of well defined policies and enforced rules. These must be clearly stated in a document (or a set of documents) called Certification Practice Statement (CPS).

2 Issues From the technological perspective, there are no major outstanding challenges. The field of information security has been studied for many years by governments, academia, and a small industry sector of specialists, and solutions to most of the technical problems are well-understood by the technology specialists. Until recently, however, these information security solutions have received little use, except for national security and certain internal banking purposes. Therefore, there is still a tremendous amount to be learned about deploying information security technology on a wide scale. In addition, diverse legal and business practices and controls must be addressed in conjunction with the deployment of technological security countermeasures. When trying to enforce security in this context, involving highly diverse organizations and communities which need to work together in complex ways, many interesting and subtle issues arise, of both a technical and a legal nature. A variety of products exist from many different vendors, which provide the mechanisms needed to build PKI based systems. None of them, however, incorporates the means to assist the system designer in identifying the optimal solution for a specific scenario. This may involve choosing between different potential architectures, and setting the most appropriate values for crucial configuration parameters, in order to maximize interoperability, while minimizing the risk and the impact of a security compromise. Increased security requirements have created an urging need for methodologies, models, and automated, cost-effective design and validation tools for trusted computer systems and infrastructures. The success of the engineering process will rely on the capability of the designers to measure or evaluate the security of each component, as well as of the overall architecture. Thus, security prediction, and evaluation must become an integral part of the system design activity. Predicting, at design time, the security level a system will achieve at operation time, is quite an hard task. Design methodologies, and tools must be provided, which allow the developer to address issues, such as: ways to structure relationships between multiple certification authorities, to associate different certification policies or practices with different certification paths, to find and validate certification paths, to develop and test certificate management protocols, and to enact legislation regarding PKIs to support digital signatures on commercial and governmental business transactions. To be efficient, the analysis must be conducted under realistic operational conditions, which take into account intentional and unintentional attacks, and other exceptional conditions.

20

L. Romano, A. Mazzeo, and N. Mazzocca

3 Approach The approach we suggest here is based on simulation. In the design phase of complex systems, simulation is an important experimental means for evaluating a system under a variety of aspects [3]. Simulation has many advantages over analytical modeling, some of which are reported here: • Compared to analytical modeling, simulation has the capability to model complex systems to a high degree of fidelity without being restricted to assumptions made to keep an analytical model mathematically tractable; • Analytical modeling tools only use probabilistic models to represent the behavior of a system. In essence, the effect of an event on the system is predefined by a set of probabilities and distributions. Functional simulation tools not only use stochastic modeling, they also permit behavioral modeling - which does not require that the effect of an event be predefined - and in some cases they allow the actual software to be integrated and executed within the simulated model. If this is the case, a number of system parameters are the results of (and not inputs to) the simulation experiment. In addition to this, unlike analytical modeling, in which only a few types of distribution are commonly used for the tractability of models, the simulation method can handle any form of distribution, empirical or analytical; • Too many factors affect the behavior of a system on the field, which cannot be easily modeled analytically. Even with simulation, however, a number of issues arises. A fundamental issue is simulation time explosion. This occurs in two cases: 1. When too much detail is simulated, such as modeling processes at an extreme level of detail; 2. When the target system is already characterized by a high security level, i.e. the probabilities of experiencing security breaches is extremely low, which means simulation sessions require a very long time, in order to collect a statistically significant amount of experimental results. Several techniques, including mixed-mode simulation [4], importance sampling [5], and hierarchical simulation [6] can be used to address the time explosion problem. Another fundamental issue involves workloads. The impact of hazards on system security is workload dependent. Hence, it is important to analyze a system while it is executing representative workloads. Workloads for simulation experiments can be trace files of real applications, selected benchmarks, or synthetic programs. If the goal of the study is to assess the security level attained by the system in a well-defined operational context, a model of the real applications to be run in the target configuration should be used in the simulation. If the goal is to study hazard impact with regard to general workloads, several representative benchmarks should be selected for the simulation. If the objective is to exercise every functional unit and location, neither real applications, nor benchmarks may be appropriate. In this case, synthetic workloads may have to be designed for achieving the goal. The workload issue complicates simulation models and increases simulation time. It is essential to develop techniques to represent realistic workloads while maintaining reasonable simulation times.

SECURE: A Simulation Tool for PKI Design

21

With these ideas in mind, we have developed a novel methodology, and a framework for system security analysis. The technique we suggest, herein after called simulated hazard injection, is a variation of simulated fault injection. Simulated fault injection has been successfully employed for dependability (reliability, availability, and performability) evaluation of fault-tolerant computer systems [7]. In simulated fault injection, faults, i.e. pathological events which may originate failures, are injected to a simulated model of the system, in order to evaluate the capability of the system to cope with errors. Simulated hazard injection consists in simulating the behavior of the target system while hazards, i.e. attacks to system security which may originate security compromises, are injected to its components, in order to evaluate the security level attained by the system. To the best of our knowledge, such an approach has never been proposed in the literature before. The following definitions are used: • Security hazard – An unintentional or intentional attack to system security, which makes the system exposed to potential security breaches; • Security compromise – A security breach which manifests in the system. It is the consequence of a security hazard. Simulated hazard injection can be used to pick out the key features, define the structure, and specify the configuration parameters of the target system.

4 Measures In order to evaluate the security level of the system, quantitative measures must be defined and support must be made available to extract such measures from experimental data. Based on the previously defined concepts of hazard and compromise, we have identified a portfolio of parameters, which are suited for use as security measures. Some basic measures are defined in the following: • Mean Number of Transactions Executed (MNTE) - The mean number of transactions executed in a secure way, before the occurrence of a security compromise; • Mean Time To Compromise (MTTC) - The mean time elapsed before the occurrence of a security compromise; • Mean Time Between Compromise (MTBC) - The mean time between the occurrence of security compromises; • Mean Time To Detection (MTTD) - The mean time elapsed before the detection of a hazard/compromise; • Mean Time To Removal (MTTR) - The mean time elapsed before the removal of a hazard/compromise. A fundamental measure is latency. Extra care must be devoted to the evaluation of security hazard/compromise latency. In this context, an event is said to be latent if the following conditions hold: 1. It has occurred;

22

L. Romano, A. Mazzeo, and N. Mazzocca

2. It has not been activated (i.e., it has not caused any other remarkable event); 3. It has not been detected (i.e., the system is unaware of it); 4. It has not been removed (i.e., it has not been eliminated from the system). According to the above definition, it is possible to distinguish between three different kinds of latency, namely: • Hazard activation latency - The amount of time an undetected hazard stays latent, before it is activated (i.e., originates a security compromise); • Hazard/compromise detection latency - The amount of time an hazard/ compromise, which is present in the system, stays undetected; • Hazard/compromise removal latency - The amount of time an undetected hazard/compromise persists in the system, before it is eliminated. The three contributions are shown in Figure 1. In a) an hazard hits a system entity at time to (time of occurrence) and an operation (which is sensitive to the presence of the hazard in the entity) is performed at time ta (time of activation). The time elapsed between to and ta is the hazard activation latency. In b) an hazard/compromise affects an entity at time to and is detected at time td (time of detection). The time elapsed between to and td is the hazard/compromise detection latency. In c) an hazard hits the entity at time to and is removed at time tr (time of removal). The time elapsed between to and tr is the hazard/compromise removal latency. activation latency occurrence t = to

a)

activation t = ta

time

detection latency occurrence t = to

b)

removal latency

detection t = td

time

occurrence t = to

c)

removal t = tr

time

Fig. 1. Contributions to security hazard/compromise latency: a) activation latency - an hazard hits a system entity at time to (time of occurrence) and an operation is performed at time ta (time of activation); b) detection latency - an hazard/compromise affects an entity at time to and is detected at time td (time of detection); c) removal latency - an hazard hits the entity at time to and is removed at time tr (time of removal)

It is worth noting the three contributions may combine in a variety of different ways, thus leading to more complicated scenarios. This makes latency evaluation quite a hard task. Nevertheless, careful investigation of latency data is of foremost importance in many cases, since it makes it is possible to: • Capture the underlying mechanisms which determine the security level attained by the system; • Get valuable feedback about the security bottlenecks of the current design;

SECURE: A Simulation Tool for PKI Design

23

• Evaluate the effectiveness of possible potential modifications and alternative strategies. In particular, latency evaluation is of foremost importance in all situations where resolution of disputes depends largely upon the accuracy with which times of events are known. A typical example of such a scenario, in PKI based systems, is the resolution of disputes upon revocation.

5 Hierarchical Simulation The approach we suggest favors hierarchical simulation. Hierarchical simulation is based on analyzing the system behavior at different levels of abstraction with a simulation sub-model associated to each level. For all levels, the workload might be a real trace file collected on the field, or in alternative it might be generated from a synthetic distribution. The effects of hazards injected at a given level are characterized by statistical distributions and hazard models (e.g., probability and number of hazards affecting a component, and their effects on the component behavior). These distributions are to be used as inputs for hazard injection at the higher level model. As a consequence, hierarchical simulation requires that: • Distinct levels of abstraction be identified; • Hazard dictionaries (i.e., a mechanism to propagate hazard effects from lower level models to higher level models) be defined; • Experimental results from lower levels be propagated to upper levels. If properly implemented, hierarchical simulation provides extremely detailed modeling of specific aspects at an acceptable computing cost. However, establishing the proper number of hierarchical levels and their boundaries is not trivial. Several factors must be considered to find an optimal hierarchical decomposition that provides a significant simulation speed up with a minimum loss of accuracy, and in particular: 1. 2. 3. 4.

The system complexity; The level of detail of the analysis; The kind of security measures to be evaluated; The strength of system component interactions (weak interactions favor hierarchical decomposition at the opposite of strong coupling).

Simulation for security analysis involves the injection and the propagation of hazards into the system under study at different levels of abstraction, such as the physical level, the system level, the network level, the application level, and the personnel administration level. We envision three fundamental hierarchical levels, which are illustrated in Figure 2. We believe these levels provide an efficient framework for accurate security analysis of a wide class of systems. The simulation, however, can be very time consuming and memory bound, since it has to track the propagation of hazards from lower levels to higher levels. There are several common issues that apply to hazard injection at all levels. The first issue is: what is the appropriate hazard model at the chosen level of abstraction?

24

L. Romano, A. Mazzeo, and N. Mazzocca

There is no easy answer to this question. Only field data and experience are valuable guides.

Unauthorized Transaction

Application Level Disclosure of confidential information

Network Level Tampering with Sensitive data

System Level

Fig. 2. Hierarchical simulation for security analysis. Hazards propagate from lower levels to higher levels. At the System Level an hazard may be represented by an attacker tampering with sensitive data. This security breach may lead at the Network Level to the disclosure of confidential information. By using such an information, a malicious user might be able at the Application Level to perform an unauthorized transaction

The second issue is: for a given hazard model (e.g. the disclosure of a private key) and hazard type (e.g. transient hazard), where should the hazard be injected? A straightforward approach is to randomly choose a location from the injection space (e.g. all private keys of certificate subjects in the community). This scheme is easy to implement, but it has two major drawbacks. The first is that many hazards may have similar impact (e.g. misuse of private keys of ordinary users may have comparable effects). The second is that many hazard locations may not be exercised at all. An alternative approach is to inject hazards to a few representative locations under selected workload. This technique can be used to evaluate the impact of locations or workloads in terms of system security. Alternative injection strategies should be used, so as to provide a broad evaluation of the system.

6 Tool Architecture The result of the above discussed considerations is a simulation tool, called SECURE, currently under development at the University of Naples. SECURE is a powerful tool for security analysis, which supports hierarchical and hybrid simulation. It represents a versatile means of evaluating system security as early as in the first design steps. It makes for effective testing, since it is possible to analyze the system under realistic operational conditions, including driving the simulation using real traces collected on the field. The hierarchical approach allows the behavior of components at a given level to be detailed in the lower level model. The granularity of the simulated

SECURE: A Simulation Tool for PKI Design

25

activities and the quantitative measures evaluated are refined from one level to another. The tool provides support to rapidly model fundamental components found in most PKI based environments, to represent functional relationships and timing dependencies between them, to inject hazards to system components, to investigate the effects of alternative policies, to mimic the execution of procedures for detection and handling of security compromises, and to evaluate the effectiveness of different protection mechanisms and strategies. This makes it possible to extract quantitative measures, characterizing the probability and the criticality of potential security breaches, and ultimately evaluate the security level attained by the system. System ability to cope with security attacks is evaluated with respect to a number of different factors, and under varying load conditions. In the following, we describe the structure of the SECURE integrated tool. This structure is illustrated in Figure 3.

Component

Hazard

libraries

Injectors Tracing facilities

C++ based

CSIM

Simulation Scheleton

objects

SECURE

CSIM Simulation Engine

Fig. 3. The SECURE simulation environment. The simulation scheleton defines interactions between simulated system components. C-SIM provides the simulation engine and the basic features to produce estimates of time and performance. SECURE facilities (the Component Libraries, the Hazard Injectors, and the Tracing Facilities) are specifically tailored to addressing security-related issues

As shown in the figure, SECURE incorporates C-SIM [8][9]. C-SIM is a processoriented discrete-event simulation package for use with C or C++ programs. It provides a convenient tool which programmers can use to create models of a system to produce estimates of time and performance. By incorporating C-SIM objects and features, SECURE is able to take into account performance related issues. The SECURE simulation environment augments CSIM with a number of facilities, specifically tailored to addressing security-related issues. To achieve this, SECURE provides a number of features to evaluate security related aspects. The main components of SECURE are:

• The component libraries • The hazard injectors

26

L. Romano, A. Mazzeo, and N. Mazzocca

• The tracing facilities 6.1 Component Libraries The component libraries provide a number of objects and features, which are a generalization of those typically found in most PKI based systems. Since SECURE is intended for use by designers of real PKI systems, the names for the base classes have been chosen as close as possible to the standard ones (we did not want to bother the designers with some new fancy names). The main object classes of the current implementation are: • The Certification Authority (CA) – Simulates an entity that issues Public Key Certificates (PKCs) and Certificate Revocation Lists (CRLs). Certificate applicants may enroll (either directly, or via a Registration Authority) and receive PKCs, which convey identity information about the certificate subject. This is done in accordance to well defined rules, as specified in the policy and in the Certification Practice Statement [10]; • The Authorization Authority (AA) – Simulates an entity that issues Attribute Certificates (ACs) and Attribute Certificate Revocation Lists (ACRLs). Certificate applicants may enroll (either directly, or via a Registration Authority) and receive ACs, which convey authorization information about the subject of the public key certificate pointed to by the attribute certificate [11]; • The Registration Authority - Simulates an entity that front-ends a Certification Authority service or an Authorization Authority service. It is in charge of authenticating certificate applicants, according to the enforced rules; • The Relying Party (or Certificate User) - Simulates a party who acts (or is in a position to act) in reliance upon a certificate and its subject public key; • The Subscriber - Represents a party who is the subject of a certificate and who is capable of using, and is authorized to use, the private key that corresponds to the public key listed in the certificate; • The Repository - Is a database of certificates and other relevant information accessible online; • The Link - Comes in two flavors: the Generic Link object and the Secure Link object. The former acts as a conduit, and is the basic means of communication. The latter is an embellished version of the same object, which provides a secure communication channel between two entities. 6.2 Hazard Injectors The hazard injectors enable the designer to mimic hazard occurrences in the system components according to realistic scenarios. This is achieved by means of a utility class that has the capability of injecting hazards into other objects, thus providing the user with an external mechanism to handle injecting hazards into a large number of components. Such a strategy increases the control one has over the actions of the individual pieces. Since several independent external injectors can be created and

SECURE: A Simulation Tool for PKI Design

27

used, this provides the means for simulating quite complex hazard scenarios. In alternative to using an external entity, injectors can be incorporated in the objects. This provides the components with a built-in injection system, which greatly simplifies the simulation. It is up to the user whether to use the simple route, or to employ the more customizable route. As far as hazard duration is concerned, we distinguish between transient hazards (i.e., hazards which disappear after some time), and permanent hazards (i.e., hazards which persist in the system if proper actions are not taken). A transient hazard occurs, for example, if a private key is disclosed. In this case, the hazard will automatically disappear upon expiration of the validity period of the corresponding public key certificate. The hazard may also be removed prior to the expiration date of the certificate, if this is successfully revoked. A typical example of a permanent hazard is a breach into a system which hosts sensitive data. In this case a security hazard is present until the breach is detected and proper remedy action is taken. SECURE provides many options to tailor how the injection process acts. For transient hazards, it is possible to set the hazard duration to a constant value, or, for randomduration ones, to set normalcy parameters for the duration and the standard deviation (for normal sampling). It is also possible to have the injector read hazard data from a file collected on the field. As far as hazard occurrence is concerned, different analytical models for both transient and permanent hazards, are available. We can set the injection model to one of a number of predefined types, such as constantly occurring, exponentially based, Weib-distribution based, or Erlang-distribution based. Again, it is also possible to have the injector read hazard data from a file collected on the field. 6.3 Tracing Facilities To help the designer to evaluate the security level attained by the system or system prototype under test, support has been incorporated into SECURE to extract quantitative measures from experimental data. The tracing facilities make it possible to monitor a number of events, and in particular: • Hazard occurrence – a security hazard manifests in a system component; • Hazard activation – an hazard, which was present in a system component, leads to a security compromise. An hazard activation thus corresponds to a compromise occurrence; • Hazard/compromise detection – an hazard/compromise, affecting the system or a system component, is detected; • Hazard/compromise removal – an hazard/compromise, affecting the system or a system component, is eliminated. The tracing facilities also provide a number of functions to extract from the collected data the security measures and the latency information described in section 4.

28

L. Romano, A. Mazzeo, and N. Mazzocca

7 Conclusions and Directions of Future Work This work has presented a novel methodology to system security analysis, called simulated hazard injection. The approach consists in simulating the behavior of the target system while hazards, i.e. attacks to system security which may originate security compromises, are injected to its components. To the best of our knowledge, such an approach has never been proposed in the literature before. The methodology is augmented by the definition of a set of parameters, which are suited for use as security measures. Among these, particularly relevant is latency. Extreme detail is needed in the evaluation of the latency of a security hazard/compromise, in order to evaluate the security level attained by the system. The suggested analysis technique and metrics have been integrated in a simulation tool for designing PKI based systems. The tool is called SECURE and it provides support to rapidly model fundamental components found in most PKI based environments, to represent functional relationships and timing dependencies between them, to inject hazards to system components, to investigate the effects of alternative policies, to mimic the execution of procedures for detection and handling of security compromises, to evaluate the effectiveness of different protection mechanisms and strategies, and to extract quantitative measures, characterizing the probability and the criticality of potential security breaches. This ultimately allows the system developer to evaluate the trade-offs of alternative design solutions, with respect to a number of different factors. Future work will aim at: • Demonstrating the potentialities of the suggested approach, by applying the methodology and the tool to the case study of a real system; • Combining the measures provided by the tool, in order to reflect standard criteria for product evaluation (such as, for example, the ITSEC common criteria).

Acknowledgements This work was supported in part by the MOSAICO project, in cooperation with the Universities of Naples.

References 1. 2. 3. 4.

Ford, W., Baum, M. S.: Secure Electronic Commerce. Prentice Hall Inc., Upper Saddle River (1997) nd Atkins, D. et al.: Internet Security Professional Reference. 2 edn. New Riders Publishing, Indianapolis (1997) Iyer, R. K. , Tang, D.: Experimental Analysis of Computer Systems Dependability. In: Pradhan, D. K.: Fault-Tolerant Computer System Design. Prentice Hall Inc., Upper Saddle River (1996) Saleh, R.A., Newton, A.R.: Mixed-Mode Simulation. Kluwer Academic Publishers (1990)

SECURE: A Simulation Tool for PKI Design

5.

29

Obal II, W. D., Sanders, W. H.: An Environment for Importance Sampling Based on th Stochastic Activity Networks. In: Proceedings of the 13 Symposium on Reliable Distributed Systems, Dana Point , CA (1994) 64-73 6. Kaancihe, M., Romano, L., Kalbarczyk, Z., Iyer, R. K., Karcich, R.: A Hierarchical Approach for Dependability Analysis of a Commercial Cached RAID Storage Architecture. In: Proccedings of The Twenty-Eighth Annual International Symposium on Fault-Tolerant Computing (FTCS28), IEEE-CS, Los Alamitos (1998) 6-15 7. Goswami, K. K., Iyer, R. K., Young L.: DEPEND: A Simulation-Based Environment for System Level Dependability Analysis”. In: IEEE Transactions on Computers, Vol. 46, No. 1 (1997) 60-74 8. Schwetman, H.: Using CSIM to model complex systems. In: Proceedings of the 1988 Winter Simulation Conference, ed. M. Abrams, P. Haigh, and J. Comfort, San Diego (1988) 246 - 253 9. CSIM18 User Guides (C++ version), http://www.mesquite.com/ 10. PKIX Working Group: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. INTERNET-DRAFT, April 1998 11. PKIX Working Group: An Internet Attribute Certificate Profile for Authorization. INTERNET-DRAFT, April 1999

































.



+

#

4

A

Y

f

}

~





‚

ƒ

„



…

H

ˆ

D

F

O

H

O

\

H

D

B

a

\

B

T

ˆ

R

F

T

S

R

Œ

T

Œ

O

H

b

T

\

O

‡

Ž

B

Ž

\

U

T

\

T

H

B

k

‡

B

D

[

\

m

H

F

F

O

j

›

H

D

k

K

F

T

o



5

F

H

n

H

S

Ž

6

M

F

K

O

g

r

\

j

5

A

O

H

M

s

t

8

R

K

S

b

k



#

%





(

*

+







@

O

O

v





=

B

a



#




ï

À

À

»

=

8

Ã

ô

»

Ã

@

Ð

º

8

Á

5

!

R

5

»

Ã

Â

:

Ã

È

»

@

5

É

»

Ã

8

»

¼

Á

Á

»

8

À

÷

º

º

º

½

»

Á

ù

Ï

Ã

5



À

À

Â

Ã

¼

ú

½

Ã

=

Î

5

Ã

À

/

@

½

»

Î

È

5

À

Ã

Ö

À

Â

Å

Ã

8

Ã

=

ß

½

º

5

5

»

@

=

Á

½

»

=

÷

»

Ç

@

Ó

»

º

»

½

8



Ã

»

½

@

¾

â

Â

¿

»

5

=

Ï

»

»

8

Ã

@

Ú

º

»

Ã

Ã

À

Â

»

=

ö

Ï

¼

º

=

É

8

¼

¼

¾

Â

=

»



Â

¼

@

@

º

»

»

Á

8

5

¼

=

Æ

@

Ï

½

º

8

½

Î

À

Ï

Ä

»

:

8



È

Á



5



Ä

Ê

Á



=

Â

=

º

¾



5

»

Â

Ï

@

õ

Â

Ç

À

Î

5

"

Á

»

¼

î

Â

@

À

½

À



¾

8

:

¾

¿



Æ

À

ì

À

º

Ã

Ã

Â

@

Ã

Ð

À

Â

½

=

Ç

Á

»

@

Â

»

½

8

»

À

Â

º

=

¿

8

»

º

Â

Ò

»

È

È

Ç

5

Ã

»

¿

=

Ç

¿

½

º

5

5

¼

Ã

»

Ó

@

8

»

È

=

=

Ï

Á

=

½

5

Ã

"

Á

5

½

Ã

5

8

:

=

8

¾

¾

º

"

»

Ï

À

À

Å

8

"

Á

»

À

Â

»

Ê

Ã

¿

:

@

½

½

Ä

»

8

¿

Ã

Ã

Ã

=

@

@

=

8

Å

Â

Ô

Ã

5

5

Â

8

8

Ç

»

À

5

@

¼

Ã

8

Á

@

Ð

»

¼

Ç

À

å

5

À

»

8

»

:

=

º

Ã

Ã

Ä

=

35

À

À

=

Á

»

@

½

@

»

Ã

=

36 h

D. Basin

ñ

r

ê

F

î

H

g

I

h

g

f

î

K

p

I

M

r

f

î

O

g

j

p

î

P

{

z

k

r

g

ò

î

q

s

Q

o

k

R

z

r

ò

ò

ò

ò

S

g

T

x

F

P

W

j

R

z

Y

Z

o

f

Y

H

M

I

]

Y

f

T

x

F

P

W

j

R

z

Y

Z

o

f

Y

H

M

I

]

Y

g

a

ê

f

]

S

h

b

r

ê

F

H

g

I

h

H

f

g

g

I

î

h

f

ê

d

ê

K

p

I

f

f

M

ñ

î

r

K

g

p

I

M

î

r

O

g

f

j

p

ñ

O

î

O

î

î

Q

o

g

j

p

g

j

p

k

R

î

P

î

P

z

k

{

z

{

z

g

ò

î

k

r

g

k

r

g

q

s

ò

î

Q

o

k

R

z

Q

o

k

R

z

r

ò

k

ò

g

ò

ò

ò

ò

T

x

r

Y

]

S

h

g

r

ê

F

H

g

I

h

H

g

g

I

g

g

î

g

ê

H

f

h

ê

g

h

d

ê

g

I

g

ê

K

p

I

f

M

î

ñ

Y

p

f

I

f

g

M

ê

i

i

r

K

î

Y

g

î

r

ê

K

f

p

I

i

o

k

z

k

f

ò

ò

ñ

ò

î

Q

o

k

R

z

k

g

ò

ò

ò

T

x

r

Y

Y

r

g

ê

R

ñ

ñ

M

ê

Q

f

g

ñ

ñ

i

i

î

Y

k

O

g

j

g

ê

p

î

ê

k

Q

o

g

i

k

R

z

k

g

i

ò

î

Q

o

k

R

z

k

f

ò

ò

ò

T

x

r

Y

]

S

g

r

r

g

R

s

z

p

r

ê

F

q

h

H

g

{

I

h

T

H

x

h

I

M

I

k

r

g

… H

8

@

8

Ã

½

Ã

À

=

»

»

:

5

»

Á

=

Î

Ã

À

5

½

»

Æ

Â

8

»

|

½

Ç

g

À

½

p

½

»

õ

:

Ç

¿

Ã

8

á

q

º

|

+

Ã

Â

T

M

x

F

I

Ï

Å

8

p

=

î

q

À

h

P

W

z

j

z

R

h

z

H

Y

M

Z

o

I

f

]

r

Y

ò

ò

]

+

g



5

Â

ð

@

\

B

:

º

½

\

Ã

»

¼

Ã

½

È

=

8

»

O

T

À

È

F

Ã

8

@

H

º

B

b

»

¾

F

@

Å

À

Ž

»

½

\

Ð

½

F

Ã

»

O

¿

T

¿

Â

»

Ã

‡

\

Ä

8

D

À

Ã

8

\

Å

À

F

Ã

@

º

Î

»

5

Ã

@

½

:

»

Î

»

5

Ê

¹

=

º

Ï

8

»

=

Ç

Ï

8

5

Â

Â

È

Â

»

5

Ã

=

»

½

8

À

½

5

À

=

Ã

Ï

½

À

º

»

8

Â

½

5

¼

Ä

Ã

5

Ç

Ç

À

@

5

À

½

Å

5

º

@

»

5

Ä

Ã

Ã

6

¼

½

»

»

Ã

º

»

½

»

8

=

»

Â

½

:

À

Â

»

»

½

Å

»

Ã

5

Æ

=

@

Ä

»

Â

Î

¿

Â

5

»

Æ

»

5

»

:

»

¼

ô

Ï

Â

»

8

:

º

Ã

º

Æ

@

»

À

Ä

Â

:

»

»

»

Â

¼

Ç

»

»

Ç

À

@

»

@

Ã

Ã

@

5

=

Ã

8

À

=

@

Å

À

=

Å

5

@

Ê

]

ú

5

À

Î

Æ

ð

À

b

Ê

»

½

O

¼

Ï

Â

Å

¿

=

Æ

R

Ã

¼

5

z

=

½

½

M

Á

8

5

À

z



=

Ã

D

»

À

Á

8

Ã

p

=

½

B

½

º

À

5

R

½

Ã

8

@

6

Â

ö

½

H

À

8

Á

8

À

F

8

H

F

¼

Ï

»

5

ù

m

‡

@

»

g

g

W

B

Î

»

¿

:



À

º

Â

{

g

K

Ã

¿

5

+

8

»

º

Ä

z



Ã

Ä

Ã



q

5

¼

Ã

@

h

k

…

=

½

5

o



5

5

À

ô

½

»

5

¹

Q

»

5

Ê

o

g

_

º

»

Ã

=

»

»

Ã

=

î

K

Ã

Ã

5

ô

ê

Â

»

»

=

8

»

:

¿

g

º

Ã

Â

»

Ä

¼

5

¼

5

Ú

Ã

z

À

½

¿

Å

½

Á

Ã

Ä

5

»

ô

À

5

N

À

Ã

z

»

@

@

Ä

p

Ð

Ê

½

»

Ã

Ã

»

»

¿

@

g

ó

Ä

5

»

r



Ã

Ã

¼

Ã

5

¾

@

»

»

:

À

8

º

Ç

»

Ã

À

¹

=

¼

Ä

I

q

l

ö

Ä

:

þ

ø

5

Ã

q

5



¼

+

À



@

ù

=

Ã

½

r

Á

s

¼

ù

Ã

À

t

½

ö

$

8

þ

Ã

þ

=

Æ

5

½

»

¾

Â

Á

À

@

Ç

¾

»

=

@

Ã

Ã

À

=

Ã

Ú

»

º

Ê

»

¾

Ê

Ã

Î

Ä

ù

¿

r

»

s

u

ù

t



á



5

½

»

w

»

6

5

Â

Á

5

Ã



é

¼

½

5

5

»

=

:

Æ

»

½

¼

½

À

Ä

»

Â

@

½

=

¼

5

g

r

g

|

g

r

g

P

{

z

k

r

ê

P

W

j

R

Á

»

¾

8

»

5

=

8

:

¾

Ã

5

À

Å

»

»

¿

½

»

5

ð

Î

Å

½

Â

Â

»

S

|

÷

:

Ç

@

=

»

À

À

À

»

½

Ç

Å

Î

Ç

@

À

»

=

5

»

Ã

Ï

»

Å

º

=

Î

Ç

À

Ï

¿

À

5

=

Â

Ä

¼

@

Ã

@

Ã

Ã

Ã

=

À

5

À

@

5

Î

Ã

½

»

:

»

5

¿

¾

5

Ã

:

½

5

À

5

»

»

»

Æ

Â

Á

À

Ä

½

:

»

º

Ç

»

8

@

Î

»

=

¾

|

g

r

N

g

À

¿

º

€

Ã

Á

Ã

Â

=

8

½

Ã

Ã

»

º

Å

¼

¿

»

À

Æ

=

»

@

»

Ã

@

Ã

Z

Ã

»

º

Ê

Ã

o

f

H

»

½

8

8

È

M

»

=

5

Î

¾

Ã

=

=

Ê

@



Î

:

/

À

5

@

5

z

À

À

Î

y

»

Ã

8

½

@

»



»

À

Ã

6

Î

@

»

@



¼

º

»

{

½

½

Ã

|

=

Î

Ä

Ê

5

¿



Ã

@

À

½

:

»

Ã

5

:

º

»

}

Ç

»

N



=



=

»

5

Ê

»

:

Ë

¾

º

»

»

=

=

Ê

5

=

}

Ç

5

6

É

¾

»

»

@

=

Ã

=

Ê

I

À

5

Â

Ç

Â

½

Ä

@

@

Â

:

½

5

ù

Á

½

»

Â

8

g

j

8

p

~

=

»

=

½

8

»

5

h

»

{

~

¼

Â

»

À

=

Ã

º

h

5

{

K

Ã

º

Ã

8

p

»

@

¿

=

À

I

M

8

À

¾

À

6

r

¿

º

Ã

@

P

{

z

»

k

8

À

5

r

~

»

h

{

»

Ã

@

½

»

º

Ã

À

5

=

á

Ã

»

:

»

Ä

@

Ã

À

¼

Å

À

½

Â

Ã

º

5

8

Å

Ä

Ã

Ã

5

º

¾

»

»

@

Ã

Ê

º

=

8

@

=

¿

¹

:

À

½

»

8

¾

»

Ê

ñ

@

Ã

¾

ô

¼

5

5

»

º

»

Ä

º

Ã

Ã

½

Ã

½

¿

Å

Á

@

»

5

»

Ä

=

8

½

Ç

=

ñ

@

@

¾

¾

Á

Æ

Å

À

À

=

:

À

¼

Ã

=

»

@

8

¿

5

»

=

À

»

¾

Ä

Â

Ç

@

½

@

½

Â

»

8

Á

¿

½

5

º

Ã

Å

¼

8

@

8

Ç

Å

Ï

»

@

¼

À

»

Å

ñ

5

=

½

À

»

Ã

Æ

Â

5

:

$

8

Ï

=

@

»

=

5

:

»

À

6

Ã

@

¼

Ã

8

Â

»

5

@

5

Ã

Á

5

:

Ú

À

ð

»

6

»

»

¼

½

=

º

@

Á

:

O

Ç

Î

:

»

5

Ã

5

À

@

Ç

3

|

Î

=

S

r

{

Ç

Ç

8

k

h

@

Â

»

5

»

À

=

å

À

º



~

½

8

Ê

Å

Ã

¿

5

Å

á

z

r

º

Ä

Á

R

k

Ä

º

@

k

z

5

Ã

»

À

o

{

Ï

8

»

¼

5

ô

P

5

=

Ð

r

Ï

:

Ã

Ú

k

Ã

Ã

»

@

Q

Ã

@

=

»

|

¼

@

=

Ã

S

r

z

5

5

:

À

:

5

6

5

k

{

»

8

Æ

8



@

½

¾

½

@

»

5

Ã

5

Î

z

P

=

¿

Â

{

h

Æ

À

»

:

ô

I

»

¼

:

P

@

=

P

À

:

=

g

5

½

À

r

5

Å

»

Ç

:

Ã

»

6

½

k

»

À

@

z

H

Ï

Ä

½

@

Ð

¾

Á

»

{

ê

Ã

»

8

¾

È

P

r

5

»

À

»

5

º

k

È

8

5

ê

z

¼

Ã



5

{



»

Æ

5

h

¾

Ã

@

5

S

z

S

~

=

Ã

5

@

»

Á

=

»

»

5

¿

=

¾

Ç

»

Ç

»

5

Å

@

À

Ç

»

À

À

¼

=

½

½

½

Ã

º

Ç

À

Á

Ï

Ã

À

@

Ã

6

:

Â

¼

5

»

5

À

@

½

»

5

Ã

À

5

5

Â

Ã

»

Ã

=

»

5

Ã

:

@

¼

½

=

@

8

¼

õ

Â

5

5

Ã

»

½

¼

¿

=

º

À

8

º

É

@

½

5

=

Ã

Lazy Infinite-State Analysis of Security Protocols g

k

g

W

W

m

z

g

l

r

j

h

k

37

ê

ƒ

„

h

ê

r

„

h

ê

„

F

„

h

|

„

h

ê

F

I

S

n

h

O

g

j

p

„

I

T

x

„

h

]

O

g

j

p

„

I

T

x

„

h

]

S

h

k

S

|

j

h

I

k

k

R

z

r

W

l

W

R

o

h

l

z

p

I

v

j

r

p

h

r

M

„

z

h

î

j

ê

k

F

ƒ

‰

„

o

K

p

‰

p

n

h

I

M

r

r

g

‰

o

{

p

„

‰

h

T

k

x

„

|

‰

o

h

Y

p

g

‰

|

{

ê

z

R

p

ê

I

g

M

]

r

ò

l

h

ê

k

ƒ

„

h

ê

„

h

S

g

{

z

k

r

M

r

d

ê

F

P

{

z

k

r

g

g

T

x

F

P

W

j

R

z

Y

Z

o

f

Y

H

M

I

]

]

S

R

p

I

„

h

ê

F

K

p

I

M

r

g

„

„

T

x

„

h

Y

g

T

x

F

P

W

j

R

z

Y

Z

o

f

]

]

S

M

j

h

z

k

î

g

z

h

j

j

k

p

„

ƒ

g

‰

h

r

o

ê

ê

p

F

‰

n

o

g

W

|

O

g

{

z

j

k

p

p

„

r

î

‰

I

‹

„

o

„

p

‰

p

x

R

p

Œ

T

I

î

h

M

x

„

r

z

‰

z

h

h

o

ñ

Y

p

I

‰

„

T

M

ò

‰

g

v

x

j

k

„

p

j

ò

o

z

p

z

h

z

z

h

ñ

î

H

g

I

h

d

f

„

ò

ê

j

n

g

ê

ê

]

l

k

S

l

h

h

‰

p

ò

z

q

M

r

I

h

z

r

r

p

S

f

g

ê

ê

H

M

I

r

l

z

k

F

„

]

z

W

h

z

F

]



o

p

n

{

ê

‹

„

h

x

Œ

î

n

„

h

ò

… H

Ã

º

Ã

À

Ú

»

@

Å

»

6

»

À

Á

»

Ã

Ã

@

=

Ã

8

Á

½

º

»

»

Â

8

¿

¾

º

Á

8

»

@

8

¿

¼

Ã

½

8

Â

À

5

@

‰

Â

À

î

Î

ô

8

á

û

›

{

5

/

H

„

h

ò

½

œ

Å

¼

T

Ï

Â

»

8

:

À

À

½

Ç

ó

ð

\

‘

õ

À

½

‡

ô

º

ð

Ã

º

T

º

»

5

@

Ã

Ã

Ã



=

½

H

\

ó

À

õ

»

½

¼

¼

»

Ã

½

@

»

=

:

º

º

8

@

=

=

Ã

=

»

»

º

À

Ã

Á

:

¼

¹

Ã

=

»

@

Ê

¾

½

=

À

Í

ñ

8

Á

@

Ì

»

¹

»

º

Ë

@

Ã

Ê

Æ

»

ˆ

À

=

Â

@

½

†

¿

@

»

5

Å

Ê

=

8

:

¼

5

{

5

À

š

=

½

Ã

Ç

š

»

É

À

À

½

š

5

$

@

»

È



@

|

¼

¼

D

/

»

8

5

5

F

€

»

»

H

¾

{

Ã

Š

q



=

Ð

H

œ

/

»

a



ó

»

@

Ã

8

@

»

ˆ

“



Â

5

T

š

q

5

Ã

=

D

œ

Ç

5

»

O



Ï

8

U

@

º

Ä

Â

‡

À

Å

Ã

Â

5

8

=

=

@

T



Ã

8

»

F

™

¼

º

ð

F

y

@

Ã

5

Å

\

Á

»

Ç



Ž

“

Ä

@

À

F



½

»

Â

b

ô

5

À

Â

B

—

8

º

Å

=

ô

Â

ö

á

8

õ

H

“

Ð

õ

Â

õ

Š

|

3

À

T

Á

»

Ä

¼

S

5

¼

½

Ã

k

õ

»

½

5

À

o

O



º

Ã

Ç

R



¹

»

j

…

•

Ê

º

=

Ã

Å

Ã

:

Å

»

k

_

“

¼

@

@

Ã

5



v

K

|

½

8

5

À

=

Ã

@

Ú

5

ô

Ä

ú

Ã

3

@

½

3

=



5

@

:

¹

ô

:

¼

À

@

}

@

¼

Ã

À

@

»

À

¼

¼

»

Ð

I

‰

»

º

Ã

»

»

=

¿

Ã

Ê

º

»

Ô

5

Á

8

@

Ð

Ã

Ç

8

Â

À

=

=

»

¿

5

Ã

»

=

Ã

5

Ã

»

j



=

Å

d

À

r

Â

Â

8

ð

5

Ç

z

½

z

Â

z

»

=

z

k

j

o

½

8

Á

@

@

ñ

k

¼

@

j

8

k

8

j

Ã

Â

À

º

Ã

½

º

»

ó

Ï

»

@

@

8

=

¼

5

¼

¿

¿

8

À

Ê

Ê

¾

Î

=

Ã

8

8

Ã

¼

Ã

¼

=

Ã

À

ð

=

=

¾

¼

»

À

=

»

:

Ä

Ã

á

Ã

Ê

º

»

Ê

@

=

»

Ã

º

5

á

¾

¿

¿

º

5

Å

5

Ä

5

Ã

á

=

½

½

=

í

=

¼

À

5

Ú

Ã

»

@

»

½

@

8

Ç

Ã

8

Ã

»

Â

¿

Â

»

6

=

»

Ä

5

º

8

»

@

½

Ç

Ã

¾

=

5

¼

½

@

À

À

Ã

À

º

»

¿

@

»

Å

=

8

5

Å

3

º

Ç

8

½



Ï

À

¾

»



»

Î

¼

@

¿

3

8

»

8

»

@

@

:

È

:

Ú

8

ž

À

Ç

@

»

Ã

z

À

Á

5

5

ô

é

=

=

@

ó

Ê

=

Ã

Â

Á

Ç

ô

½

5

½

¿

Å

Î

À

»

5

5

ó

8

5

¿

Ä



Ã

¿

À

È

À



¼

Å

@

5

Â

3

=

Ï

Ã

¿

@

À

Ú

À

=

Á

=

Ä

Ç



Å

Ã

@

5

»

õ

»

½

È

Ã



»

È

»

»

5

Ç

5

º

¿

¾

À

Ï

Î

¹

»

@

½

Î

Ê

º

8

Å

Å

@

»

Ã

:

Ã

»

R

Î

=

@

=

»

@

»

À

Ã

Ã

Ê

À

¾

8

8

½

¾

¿

5

Ã

Â

Á

Ê

=

=

5

¾

»

»

=

»

8

Î

½

¼

:

Å

8

=

»

@

5

@

h

À

À

á



Ã

Ç

Á

@

½

¼

Ç

5

8

5

:

Ç

ô

@

»

Â

»

Ú

r

º

Ç

»

¿

8

º

:

„

Ã

À

6

»

Á

Ã

ð

Â

Æ

¼

8

Æ

=

»

8

¾

5

À

@

5

=

»

Ã

Â

Î

@

ð

8

5

õ

½

p

Á

5

À

Ä

 

»



8

Â

÷

õ

Ç

ó

Î

|

»

½

Ã

5

»

ó

=

À

¼

@

½



@

Î

W

=

Å

@

5

3

5

Á

½

»

»

À

Ã

Å

8

¾

=

¼

=

Ä

»

5

Á

Ä

v

½

º

¹

f

5

Ã

»



=

8

8

Á

¼

@

8

¼

Ã

»

8

=

5

=

Â

À

½

Ê

r

C

A

B

T

Œ

Œ

H

F

H

R

B

W

F

R

§



\

Œ

ˆ

R

H

B

F

H

W

D

O

o

\

h

T

v

‡

p

Ž

T

U

\

D

T

M

K

B

‡

F

H

R

B

T

z

\

B

Œ

T

D

\

F

T

n

Œ

˜

¬

R

F

F

Ž

T

F

R

K

O

M

R

O

B

Œ

T

ˆ

ˆ

Š

H

\

D

F

h

S

T

Š

H

›

T

F

H

R

B

Œ

H

R

K

n

¡

\

O

D

Ž

\

O

\

D

Š

H

b

Ž

F

Š

B

F

H

Š

T

h

d

“

H

F

Ž

O

\

D

ˆ

\

‡

F

¿ F

R

T

K

Š

D

R

B

‘

D

˜

£

\

‡

R

S

ˆ

K

F

\

D

F

Ž

\

‡

Š

R

D

K

O

\

H

B

a

R

F

Ž

T

h

‡

R

S

ˆ

K

F

\

F

Ž

\

‡

Š

R

D

K

O

\

H

B

F

g

§

B

H

F

\

˜

_

R

O

S

T

Š

H

›

H

B

b

T

B

H

k

B

g

§

W

m

B

H

Ž

\

M

R

O

S

\

O

H

D

T

Š

“

I

T

k

d

r

B

Œ

W

l

D

H

g

B

§

B

H

F

k

\

g

T

B

W

“

Ž

\

O

\

T

D

“

\

R

B

Š

d

m

Œ

F

Ž

\

Š

T

F

F

\

O

H

D

T

Š

“

T

d

D

¤

F

\

D

\

F

H

D

B

R

F

T

ˆ

O

R

a

Š

\

S

H

B

T

Š

T

›

d

D

\

F

F

H

B

b

“

\

‡

R

K

Š

Œ

Œ

R

¤

F

Ž

H

a

O

D

“

T

H

B

‡

F

Ž

Ž

H

T

B

b

D

F

F

O

O

\

\

T

\

S

´

H

˜

B

D

£

F

R

\

T

“

Œ

\

R

[

M

\

O

W

T

“

§

B

\

H

F

Ž

T

\

[

a

O

\

T

T

B

[

‡

R

Ž

H

H

B

Œ

\

b

Œ

F

F

O

\

Ž

H

\

D

“

T

H

F

D

H

Ž

H

F

B

“

§

R

B

H

K

F

Š

\

Œ

Š

O

\

\

B

D

b

K

F

Š

Ž

F

H

a

O

B

T

T

B

B

‡

H

Ž

\

B

§

D

B

W

H

“

F

\

Ž

Š

H

d

‡

Ž

-

“

R

R

B

K

\

Š

Œ

D

‡

d

B

R

F

S

Ž

ˆ

\

D

Š

H

D

H

‡

D

T

F

F

\

\

ˆ

F

W

Ž

T

\

B

Œ

T

ˆ

D

ˆ

ˆ

O

Š

H

\

‡

T

T

Œ

F

H

F

R

Ž

B

\

R

‡

M

Š

O

R

D

\

K

R

O

O

\

Œ

\

‡

O

R

H

S

B

b

ˆ

Ž

K

F

\

T

K

F

O

H

H

R

D

B

F

H

‡

Œ

D

R

˜

“

A

B

B

D

´

F

H

\

B

T

D

Œ

F

W

\

T

“

Œ

\

R

ˆ

M

\

T

O

‡

M

O

R

O

R

S

D

¥

D

H

B

§

B

H

F

\

F

O

\

\

˜

K

F

-

D

Ž

F

\

38

D. Basin ê

¹

º

¾

»

»

8

Q

½

@

@

»

¿

Ã

º

º

Î

Å

Á

@

ñ

z

À

¼

¾

Ã

Á

„

Ï

º

8

½

À

»

Â

8

¼

P

º

8

Â

Ã

À

=

»

=

»

¿

8

Ê

¹

Á

Ã

»

º

»

»

=

Á

@

8

¼

Ã

¼

=

ñ

Ã

5

½

»

Ã

Æ

5

Ã

»

5

@

=

8

Æ

Î

=

º

»

À

¾

¼

z

k

º

8

h

¿

=

5

Â

½

Â

8

j

Ä

»

ð

k

Î

¼

»

o

j



Á

j

õ

½

=

k

=

8

5



Ã

6

ò

3

Â

»

ò

ó

»

½

r



Ä



5

»

À

ó

¿

Å

8

¿

ñ

Â

@

8

=

5

8

»

¿

:

Ã

¿

Ê

»

Â

4

À

8

»

½

»

:

¿

8

Ã

»

@

À

@

ñ

:

@

É

8

Ã

»

Ê

Ã

Ã

»

r

5

Ç

¾

Å

Ã

„



½

@

@

À

Ð

z



8

8

=

»

Ã

Å

Ä

Ã

Ä

5



Â

î

õ

¼

¿

=

ò

+

@

¿

k

:

z



5

À

o

@



½

Ä

¼

j

õ

Ä

»

h

¦

+

Æ

Ã

=

Â

k

5

|

z

@

z

õ

º



Ã

À

r



¼

¦

8

8

„

ó

8

|

Ã

=

À



º

@

5

z

Ä

Î

Â

=

z

Æ

@

¼

5

z

Ï

@

ñ

8

»

:

À

8

8

p

@

8

½

¼

r

»

À

Ã

À

»

8

=

¼

d

Â

¿

@

¿

|

»

Á

Ä

=

W

Æ

Î

Á

Â

½

j

5

=

Å

Ã

v

Â

½

@

Á

f

=

À

À

À

Å

=

@

»

Â

Ç

8

ñ

Ã

8

=

=

î

»

»

@

M

»

¼

»

g

½

¼

Ã

¿

q

Ã

Á

Ð

¼

î

»

=

Ç

@

»

r

8

r

º

»

»

À

:

j

Ã

º

»

¼

Ç

k

Å

Ã

º

»

»

À

»

Ã



j

Ã

Ã

@

Ã

z

À

5

À

»

|

À

½

¾

:

o

@

º

»

º

5

»

:

8

»

@

Æ

À

Ç

6

¿

¾

Ã

»

Ã

½

Å

Ä

5

Á

Ã

¼

»

@

½

¼

5

=

Ã

¼

Á

8

À

»

=

@

8

5

@

Ã

@

À

Å

:

¾

Ã

Ã

º

À

º

½

Ç

»

»

Å

5

»

Á

Ð

@

Â

Ã

¼

8

»

Ã

8

ð

»

@



=

À

8

@

Î

À

@

=

8

@

Ê

r

ê

q

g

M

î

l

z

‹

p

„

x

z

Œ

z

„

r

z

„

r

j

z

k

h

k

h

„

j

o

r

k

ò

h

z

„

ê

r

î

z

î

k

h

h

j

ñ

‰

o

o

k

h

p

‰

h

b

‰

o

p

‰

h

g

‰

o

p

‰

g

r

r

g

R

s

z

p

ò

r

ò



M

ê

f

¹

"

5

º

=

È

j

»

¿

Â

=

½

»

Å

5

¿

¼

À

¼

8

º

8

8

@

ñ

@

5

Â

5

8

:

=

º

5

»

Â

ö

»

Â

Â

Ï

Ã

º

»

Î

À

=

Ã

Ç

8

»

»

º

=

=

»

Ä

=

º

I

h

P

W

j

R

z

g

I

h

P

W

j

R

z

F

H

g

I

h

Z

o

f

F

H

g

I

h

Z

o

f

F

H

g

I

h

H

M

I

F

H

g

I

h

H

M

I

F

H

g

I

h

H

M

I

P

W

j

R

z

î

P

{

z

k

r

F

H

g

I

h

H

M

I

P

W

j

R

z

î

P

{

z

k

r

F

H

g

I

h

H

M

I

P

W

j

R

z

î

P

z

k

r

F

H

g

I

h

H

M

I

Z

o

f

î

P

{

z

k

r

F

H

g

I

h

H

M

I

Z

o

f

î

P

{

z

k

r

F

H

g

I

h

H

M

I

Z

o

f

î

P

{

z

k

r

N

À

8

Ã

=

»

÷

Ã

Á

º

8

H

È

j

M

P

Ã

Â

K

p

I

M

r

î

K

p

I

M

r

z

î

K

p

I

M

r

R

W

j

o

R

î

K

p

î

K

p

À

¼

½

º

I

z

Ã

5

M

î

f

Å

Ä

î

I

I

Z

5

¼

W

º

@

K

p

=

j

W

8

W

Z

o

H

¿

Ã

Ã

M

½

»

¼

Ã

5

@

:

¼

À

@

¼

8

=

»

Ê

¹

º

»

Ä

º

ò

]

ò

]

Ã

»

]

ò

]

ò

]

½

Ã

@

½

@

=

¼

Ã

»

¼

Ã

=

:

½

5

¼

@

À

»

5

Ã

Ê



@

½

Ã

=

Ã

¼

5

Ð

¾

½

Â

»

Ã

5

Ã

¼

¿

5

»

½

½

Á

Ã

À

½

½

»

=

@

¿

À

@

í

Å

Ã

Ã

»

:

8

@

¾

j

p

î

P

{

z

k

r

P

W

j

R

z

ò

î

Q

o

k

R

z

ë

ò

ò

ò

]

g

j

p

î

P

{

z

k

r

P

W

j

R

z

ò

î

Q

o

k

R

z

ë

ò

ò

ò

]

î

Q

o

k

R

z

ë

ò

ò

ò

]

ë

ò

ò

ò

]

p

g

j

p

î

ò

O

j

î

P

î

P

p

î

g

{

j

z

k

z

k

P

p

z

k

r

Z

î

{

{

r

P

{

r

½

¼

»

À

Â

=

Ã

À

5

@



»

À

À

½

Ç

¼

8

»

Ã

É

@

5

¿

5

»

Ä

í

=

=

@

Â

=

½

Â

8

À

º

»

À

:

À

Ä

½

À

Ê

=

@

@

¿

»

:

5

=

Ã

Ã

¼

Ê

Ç

=

Ï

»

@

=

»

8

5

5

»

À

Ï

»

ô

@

Ï

»

Ã

Â

Â

Ê

g

g

À

$

Ç

Ã

»

½

½

¿

O

O

ñ

ô

º

=

»

º

@

Ã

8

Ï

À

Á

@

½

»

8

»

Ã

Ã

Ã

º

»

À

5

Ã

8

ñ

»

À

Ã

:

Ã

»

:

º

º

5

@

=

½

=

½

À

@

5

Î

»

»

»

À

»

»

º

»

=

¹

Â

Ï

Ç

¼

Ã

Ê

»

Á

½

»

5

Ä

½

@

=

»

¼

=

Ç

º

8

½

À

5

»

Ã

º

Ã

»

»

À

»

»

É

»

Ã

»

"

»

º

Î

»

Ê

Ã

Ã

=

º

5

Æ

À

:

@

½

»

5

Å

»

Ã

Ã

»

Ã

À

»

@

5

½

=

=

½

»

À

Ã

Ã

Ã

º

@

Ä

Ä

½

»

@

Ä

ð

ð

5

Ã

Ï

8

5

5

¿

8

»

5

Â

Â

¾

@

Ã

5

5

@

½

@

5

@

O

j

o

Z

z

f

k

M

f

ò

r

H

o

H

I

î

Q

î

Q

ò

ò

M

o

I

k

R

k

R

ò

z

î

o

ë

Q

o

ò

k

z

R

ë

ò

ò

]

ò

ò

]

z

ò

]

¼

5

5

»

8

ñ

Ç

Å

Ã

Ã

Á

»

Î

=

À

@

:

¾

@

¼

8

=

5

:

î

g

5

½

@

¾

Á

»

½

Â

»

î

z

ò

8

5

½

»

»

»

=

»

¼

½

À

Ã

Ã

À

6

º

:

5

¼

½

¿

Ã

¼

z

R

z

¼

=

Á

»

»

î

R

I

R

I

O

f

f

M

î

j

o

j

O

Â

Ä

@

»

¼

À

Æ

:

Ï

@

z

j

P

Z

H

¿

R

î

Æ

@

À

¿

À

¾

8

I

P

W

Ã

f

M

f

P

=

:

¾

À

@

5

@

=

I

o

=

À

º

½

8

»

W

r

Ç

=

Ç

@

¼

½

Â

Æ

=

o

M

Z

5

º

P

M

»

»

Ã

Â

»

8

Î

8

Î

»

8

=

=

8

Ã

È

¿

8

»

:

È

¼

5

H

r

{

»

¾

I

8

Ê

5

¼

Ã

Ï

=

H

M

Â

»

Ã

»

¼

»

¾

Z

r

I

@

Ã

g

P

¾

=

5

:

½

É

5

Ã

À

5

H

M

»

5

º

º

À

5

Ï

H

H

f

Ã

Ã

8

»

¼

Ã

:

@

8

F

º

o

¾

@

5

Â

Ã

Ã

Î

5

Ã

=

=

F

Ú

Z

5

Ã

:

¿

Â

5

Â

È

8

8

»

½

5

@

À

5

@

:

=

¼

º

=

À

Ã

5

5

5

¼

5

Ã

Ç

½

ñ

»

8

Ã

º

À

:

Ã

¾

Ã

:

Å

ï

Ã

@

@

À

À

Ê

5

8

8

Ç

»

»

»

\

@

¼

º

6

±

»

Ç

@

:

¿

@

Ä

»

5

5

»

Ã

À

¸

Ã

5

Å

Ã

Z

½

½

=

:

¿

]

À

Á

5

»

Á

@

@

è

Ã

=

È

:

=

º

5

»

À

»

=

»

F

·

ð

É

¼

8

»

¼

Ã

8

8

»

5



:

5

5

8

=

?

Â

Ã

Ã

¼

Ê

Ä

»

Ã

Ã

»

ª

5

Ã

»



5

È

·

8

À

½

»

»

=

Ã

º

©

@

½

¼

5

Ç

5

¿

»

Ã

»

Â

@

½

@

À

À

ñ

A

½

ä

z

Ã

=

=

8

ñ

»

Â

Ã

Ã

À

@

º

À

Å

»

Å

z

»

?

8

¼

=

ï

Ã

»

p

¼

:

µ

Ã

À

r

»

À

Ç

º

Ã

»

6

½

½

½

:

5

À

d

¿

¼

´

º

»

|

=

Â

>



W

»

»

¨

Ã

v

»

¼

Î

»

Ã

=

º

¾

»

½

=

À

Ï

¿

Ä

Ê

á

8

¹

=

Á

º

»

5

=

@

»

Æ

¼

Â

À

»

@

Ã

:

À

=

¿

Â

Ä

5

Ä

º

Ç

5

Á

=

P

¼

í

º

R

À

@

Å

À

8

:

@

»

Ã

=

»

½

5

»

@

=

:

Ã

Û

Ã

º

»

Lazy Infinite-State Analysis of Security Protocols h

o

p

r

O

W

I

l

n

z

p

r

z

ê

q

g

q

M

Z

g

p

M

g

Z

p

k

R

g

l

k

R

z

l

h

z

h

n

n

î

Q

39

r

o

|

z

g

W

ò

ê

Q

o

|

z

g

î

q

g

M

î

q

g

M

Z

p

g

k

R

l

z

h

n

ò

î

n

W

ò

ò



M

i

ê

h

l

z

p

o

p

r

z

O

W

n

I

n

ê

h

o

î

p

r

M

Z

p

v

k

I

R

z

q

M

ò

M



R

q

M

î

Q

o

|

z

j

r

n

ñ

d

ñ

T

ò

î

z

W

Q

b



o

|

r

l

z

r

z

h

z

j

n

ñ

{

l

r

z

ò

ê

p

ê

ê

b

ê

î

M

r

l

z

z

p

z

ñ

ê

€

z



p

k

¬

z

W

h

z

­

p



l

j

d

«





z

b

k



o

r

H

r

z

j

{

l

r

î

l

z

g

|

r

ñ

ò

®

b



M

z

ò

ê

z



ð

î

n

p

o

q

H

M

I

z

j

{

l

r

î

l

z

g

|

r

b

ò



ò



M

p

M

o

p

r

M

o

H

p

r

o

p

o

H

j

n

j

n

H

g

I

h

„

H

g

ê

ê

ê

ê

î

ê

ê

H

g

M

d

î

g

d

r

l

r

l

K

p

z

M

p

z

I

p

I

M

p

v

k

z

n

g

r

ê

n

… H

Ã

º

8

5

Â

½

Ç

»

í

À

8

=

:

¾

½

¾

8

º

5

½

8

Ã

½

º

8

»

À

Ã

º

ñ

º

»

8

8

ñ

½

»

½

=

Ï

=

g

b

å

º

½

=

½

»

5

8

½

Ã

¼

º

=

8

Â

º

8

¼

ò

º

Î

À

»

Ã

5

»

=

5

Ð

¿

¿

Ä

Ã

Ä

Â

Ê

À

»

½

º

»

½

ñ

½

8

5

½

Â

g

j

ñ

î

î

P

{

z

k

r

d

ò

î

Q

o

k

R

z

k

ò

ò

ò

ò

ò

ò

ê

p

î

Q

o

k

R

z

k

g

ò

î

Q

o

k

R

z

k

f

ò

ò

ê

ë

Q

o

z

ê

î

Ã

Â

‹

k

ñ

ê

R

z

k

f

ò

ò

ò

ê

ë

H

„

x

=

Ã

M

I

Œ

ò

M

8

@

8

¿

¼

8

5

À

À

8

8

r

p

Ã

Ã

o

l

r

z

H

k

ë

r

=

z

z

M

î



Á

»

Ã

Â

=

Â

W

l

h

z

z

g

¯

|

„

»

»

Ã

Ã

@

½

º

Ã

ò

T

ê

g

ò

r

Ã

@

º

»

À

5

Á

Ã

½

Ã

8

º

¼

=

»

À

Ã

@

8

½

¼

»

8



5

8

8

²

Î

@

@

À

»

¿

»

8

5

:

5

5

½

Ã

Ã

Ã

:

=

5

À

¼

¿

»

È

½

Ã

Ä

5

=

Á

½

Ã

@

8

=

¼

Ï

Ã

5

8

5

@

Â

Ã

Ä

¼

º

º

»

5

Ã

Ä

8

@

Ã

8

Ã

º

»

»

À

=

¼

5

Ã

»

=

Ã

5

»

Ï

@

À

Â

Â

=

»

8

Ï

=

º

½

»

¼

8

Â

Î

Ã

Ê

½

5

½

Á

Ã

5

Á

É

»

»

À

Î

:

:

½

Ä

Â

Ä

Ã

º

¿

Â

5

Â

=

=

6

@

¿

Ä

¾

8

À

8

½

5

8

»

»

Á

5

½

=

5

½

Ã

@

½

»

¿

Â

»

@

º

»

8

:

½

Ã

½

Ä

=

Ç

À

Ã

=

@

»

8

À

É

Â

ñ

¿

½

Ë

½

»

Ê

@

@

Á

»

@

Å

À

À

¼

º

=

8

¼

¼

@

¾

5

Ã

=

»

8

»

½

Ã

¹

=

Ê

À

»

6

Á

»

:

5

5

5

Ê

=

:

8

¿

5

½

÷

=

8

½

º

º

=

8

¿

Î

»

Ã

»

¾

Ã

5

@

¼

:

½

:

À

»

:

Â

À

¼

5

½

@

$

@

8

¿

5

=

º

=

»

Ã

¼

º

Ç

@

8

Ã

8

º

5

Ã

»

½

=

5

Â

@

=

»

:

¿

8

»

Ã

@

Ï

Â

º

Ã

:

8

º

»

»

Î

Ä

½

º

¹

Î

Á

6

¿

Ç

È

@

À

8

8

5

»

»

¼

:

À

Ã

Ê

Ï

¼

8

=

Ã

6

À

Ã

@

@

À

=

À

@

À

Ï

»

½

¼

Ä

ð

:

Ã

@

»

º

Ã

º

5

¼

Ã

@

»

Ã

¿

½

Ï

À

5

Â

Ã

@

Î

8

¿

»

º

Á

5

À

»

Ä

5

6

5

=

Â

º

5

Â

º

Ã

Å

¾

Î

=

Ã

À

@

Ã

¿

@

¾

¿

Ã

é

Ã

8

=

Ç

Æ

À

5

@

À

»

½

\

Ã

8

=

:

=

Ê

:

¿

=

½

=

º

\

5

=

¼

$

À

¼

»

@

Ã

»

º

À

½

=

»

À

Á

»

À

À

O

º

Ä

8

Ã

»

:

Ã

Ã

=

5

¼

@

=

5

6

Ã

»

:

=

º

:

Â

¾

º

½

»

5

º

À

Â

=

F

Ê

=

5

½

Ã

@

@

¹

À

5

º

»

Ê

8

Â

¼

À

¹

\

Ã

»

8

Ç

»

Ž

=

6

½

Æ

½

Ê

¿

Á

»

¼

8

:

À

5

À

Ã

¼

6

=

½

À

À

@

:

:

Á

¼

8

»

¼

=

Ã

»

½

²

À

»

»

=

À

@

=

Ä

Ä

¼



5

8

=

»

À

½

F

@

Ã

»

Å

b

5

5

»

º

5

Ã

»

¼

½

¾

B

»

Â

º

½

H

Ç

»

»

5

O

½

º

5

Ã

@

Ã

¼

\

½

5

Ä

À

½

8

»

¼

=

¾

8

½

º

5

:

@

À

º

Ã

Î

»

8



8

º

Ã

8

@

»

¿

Å

Ä

½

½

¿

À

½

»

8

Ã

@

½

À

À

=

Â

=

@

Œ

@

»

Á

=

5

¿

º

½

Ä

»

»

º

Ã

¿

¼

O

Ã

»

8

8

Ç

¼

=

º

Ã

R

Á

=

Ï

Ç

»

5

»

8

½

\

6

Ï

Î

Ç

:

Æ

º

À

º

À

Å

»

Ã

Î

O

¾

5

Ã

Œ

¾

Î

»

Å

Â

@

»

=

B

@

8

À

Ã

:

Ï

º

Ã

=

»

½

¿

Ã

@

À

Á

½

8

8

Ä

Á

Å

=

º

5

Å

5

»

Ä

¿

5

Ã

Ï

À

»

=

º

Å

=

»

T

:

5

=

À

=

»

¾

Ã

¼

¿

@

¼

8

Â

½

Ç

@

½

Â

À

=

À

5

:

b

¼

»

Å

»

B

@

»

@

½

»

À

º

À

8

º

½

ñ

Ã

Å

½

Ã

½

À

8

@

ñ

Ï

=

5

H

Ï

=

Ã

5

»

¼

B

@

»

º

È

=

½

8

K

½

8

º

@

=

O

Æ

Ã

Ã

¿

»

Ï

Å

5

Ã

º

Â

:

@

»

ˆ

¹

»

5

=

5

»

Ê

=

8

»

»

¿

Î

8

@

Á

=

À

8

Î

O

½

6

5

½

=

½

º

Ã

8

»

½

Ç

Ã



¼

»

6

O

z

ñ

b

h

R

»

=

»

:

À

»

¼

Á

½

Ã

:

=

Ä

»

»

Á

5

º

z

»

»

z

M

¼

º

½

@

@

6

À

º

—

º

=

¿

ð

Ã

¾

õ

»

»

5

Â



º

Ã

Ç

Ä

3

Ã

8

À

8

h

î

p

S

l

@

¼

Ã

»

»

=

5

»

½

W

j

ë

ê

D

»

À

»

5

Ç

¾

º

R

‡

Á

¿

»

¼

H

@

»

ñ

:

»

@

¿

5

h

f

g

k

F

=

º

8

Ç

À

À

»

¼

@

È

:

»

Î

¾

Á

@

g

ñ

ñ

W

z

I

g

D

À

½

º

»

À

½

À

¿

À

Ã

»

H

:

Ã

:

Å

6

½

=

@

½

:

Ð

Ï

¿

=

»

r

g

d

M

p

O

Ã

À

=

=

»

À

5

º

Ã

@

5

=

Ã

Ã

Ã

8

¿

»

½

=

Ã

@

À

Ã

Ä

Ä

Z

K

Ä

=

Â

½

¿

Ã

Å

8

Ä

»

Ã

5

Ã

Â

=

8

»

¼

¿

À

Á

@

Ï

¿

Ã

»

ï

@

Â

À

@

»

Â

Å

¿

Ã

6

@

Á

5

H

p

\

Â

Â

5

À

ê

z

»

»

Â

Â

Â

¼

»

Ã

»

À

»

Á

=

=

6

¿

À

½

À

8

»

Å

=

¼

»

6

»

@

»

Ã

8

5

Á

8

Â

r

@

È

5

Â

¿

À

8

º

»

=

W

g

z

M

O

z

…

5

Â

=

Ã

À

½

Â

À

=

¾

À

Ã

Ã

Ã

»

Ã

8

=

À

Ç

Â

8

À

°

º

@

Ï

:

½

¼

»

8

=



À

6

Ï

Á

Ã

5

Ä

5

j

ê

£

¼

Ã

ñ

K

Á

5

¿

Ä

Á

»

»

»

Ã

Â

é

½

»

»

Æ

º

»

½

º

À

5

Ê

5

:

»

Á

½

½

Ž

8

½

Ã

¿

:

@

Ã

¾

Î

»

=

=

Ã

8

ô

=

»

º

Ã



Ç

½

¼

=

Î

º

Ã





ó

Ã

I

g

r

k

î

h

ë

h

î

ñ

W

b

K

z

„

z

M

k

S

j

r

ñ

K

î

ñ

I

k

î

f

f

ñ

l

ñ

h

I

r

g

g

I

î

d

ê

H

„

ñ

h

f

I

d

„

I

g

M

z

M

n

î

z

r

H

j

M

r

r

î

z

H

q

M

r

r

p

n

z

H

o

M

r

À

º

@

Ê

¾

¾

=

40

D. Basin 



»

»

8

Ã

Å

»

½

À

Ç

Á

5

Ã

À

@

»

:

:

=

»

Â

Ç

Æ

¼

À

À

Á

º

=

@

»

Ã

¼

Á

:

»

È

=

Ã

»

:

Å

º

Á

:

»

Â

»

8

5

¿

Ã

Ç

¿

@

8

º

½

Ç

ñ

À

6

¿

½

=

Â

Ã

»

»

:

=

Ç

=

»

»

5

»

5

@

½

Ã

¼

½

5

¼

º

Ã

º

8

Ï

=

À

8

¿

@

Ã

5

À

º

¼

Å

Æ

»

8

À

Á

Ã

»

Á

=

½

@

8

5

@

Ã

:

¾

8

=

=

6

Ã

»



5

:

Î

@

»

í

:

»

Î

5

¿

ô

½

»

Î

:

Ê

@

Ê

=

8

Ê

@

»

5

¾

½

=

¼

»

º

5

5

½

¼

Â

º

¾

À

Î

½



8

+

Ã

º

3

Ç

Î

Ã

=

º

Ê

5

Ã

Ê

S

j

|

j

|

h

M

h

j

p

k

z

|

r

k

M

n

p

z

k

z

W

h

ê

ê

z

j

l

|

î

ê

n

z

n

p

o

p

z

r

z

g

Q

ë

M

W

r

|

z

h

F

g

W

î

r

z

k

k

g

p

z

z

l

|

r

l

j

z

r

j

ò

M

p

î

n

W

h

k

k

M

p

z

|

r

k

T

x

F

ë

t

t

]

]

ê

n

k

ê

|

z

g

g

ì

r

|

g

p

r

z

z

h

r

r

l

z

ò

k

î

z

q

g

k

F

W

h

g

z

M

]

z

p

î

j

z

|

h

h

W

h

z

F

]

ò

r

k

î

k

x

ñ

ò

M

p

z

|

ò

W

ò



¹

º

»

½

»



À

Â

Ã

5

½

Ã

5

5

º

¼

Â

À

Ç



½

r

r

g

R

s

g

r

r

g

R

s

n

z

p

g

á

g

W

h

z

k

r

h

z

k

r

h

r

l

z

F

Ã

½

À

À

@

Å

Å

¿

5

À

Å

»

Ã

8

¼

Ð

{

5

ë

P

Î

=

Ã

½

Ã

»

=

5

8

Î

¾

º

8

»

@

½

º

Ã

¼

½

@

8

=

=

À

Ç

¼

À

»

Ã

@

º

É

Å

Ã

Ä

Â

»

6

Ú

»

@

=

@

ï

À

@

=

À

¾

»

Ã

Ã

@

@

5

»

ê

Ê

8

Á

É

=

@

Ä

Ê

8

5

:

Ã

½

5

=

=

Â

5

5

:

6

»

5

Â

Â

Ä

Á

À

½

º

Â

Ï

8

Ç

Ã

Ã

À

Î

6

À

8

»

º

»

Ã

À

5

»

Å

½

º

ð

5

½

=

=

»

º

Á

Ç

6

ð

+

¼

»

»

8

è

»

»

Â

Â

»

á

Â

º

º

5

¼

»

5

Ã

»

@



=

º

¾

ð



=

Ã

Ç

8

º

»

¼

8

½

¼

ð

=

8

º

Â

@

8

»

À

5

5

Å

Î

8

½

º

Å

Â

@

8

Â

Ç

¿

5

»

Ï

5

5

º

Ã

@

À

½

Ï

¼

Î

½

Ã

À

Ã

½

5

=

»

Å

¼

Ä

»

=

»

À

½

5

8

@

»

@

=

¿

Ã

»

¾

Å

5

Ç

8

¼

5

=

=

Ã

5

¼

»

º

È

@

|

»

Ã

¼

¾

Ã

Ã

Á

º

5

»

»

5

Ã

5

½

Ï

»

Ã

:

@

»

Ã

5

Ã

8

=

=

º

å

6

»

Å

Ã

@

»

Â

À

Ê

À

5

¼

Ã

¼

$

á

+

À

=

Ã

º

Ã

=

¿

À

Ï

=

Â

»

Ç

5

Ú

ô

Á

È

5

8



¼

5

¼

Â



ç

º

8

»

Ä

Å

Ã

:

½

ð

À

½

Á

»

¿

5

:

=

¿

»

Ä

»

Â

»

À

½

Ã

Ã

=

Â

À

5

¼

Î

»



¼

=

Å

ð

Ê

8

@

¾

=

¿

=

Ã

À

8

Ú

5

@

Ã

:

»

À

Ã

½

Ç

Ã

8

»

»

@

Ã

5

=

»

5

=

½

ð

8

»

5

Ç

Ã

»

@

8

¼

8

Ã

º

Ç

½

¼

½

Ã

½

»

Â

»

Á

½

À

5

5

½

8

¿

=

8

Ã

»

½

½

¼

=

Ã

=

5

»

5

5

Á

@

º

¿

¿

@

Å

Ã

@

Ã

À

5

Ê

z

f

î

k

î

]

¼

=

=

8

g

ñ

Â

8

¶

h

f

8

½

=

8

=

5

À

Ä

½

»

»

:

Ã

{

Ã

·

I

8

5

Ã

»

8

¿

Æ

Â

3

À

À

Â

½

Å

@

5

+

½

Ä

:

Á



¿

Ã

¿

8

À

¼

Ä

¿

Ã

6

¼

|

»

»

Á

=

8

»

Î

ê

H

½

Æ

5

»

@

=

Æ

¾

ê

z

Ã

:

@

À

º

»

Â

]

î

ê

É

À

5

F

:

½

À

Ã

Ã

f

l

¼

¾

@

5

»

5

Ã

»

Â

À

@

»

g

j

Ã

8

»

Á

»

@

@

¾

@

À

½

@

»

Ï

¼

Á

8

½

@

Ã

ð

½

»

Î

8

»

8

Á

=

»

Ã

½

½

Â

Ã

=

½

Ã

º

8

5

¿

8

8

Ã

5

5

:

=

Ï

8

»

Â

5

@

¼

¿

Á

Ç

=

½

Å

Ã

½

À

»

:

Á

À

8

¼

@

À

=

À

ê

K

p

I

h

·

z

M

r

k

g

f

r

W

ñ

h

r

î

p

¸

Q

o

k

¸

R

g

k

z

k

g

W

f

I

ò

m

z

ò

ì

ò

r

p

z

ò

W

h

ê

z

g

r

r

g

R

s

r

p

z



î

H

î

g

f

I

h

ñ

f

ê

b

ê

R

f

S

z

g

g

r

r

g

R

l

z

g

5

¿

»

î

¿

Â

8

Â

»

»

F

H

g

H

h

I

h

I

h

H

g

I

h

º

5

»

¼

o

P

Î

P

j

½

å

R

5

¼

Â

H

»

8

¼

j

R

H

o

Î

»

M

î

»

=

5

Ã

5

K

p

:

½

Ã

Ã

=

p

K

p

À

M

R

ñ

ê

î

k

f

O

g

ñ

j

¸

p

î

¸

Q

o

R

ê

k

R

z

ê

d

R

ñ

ò

¸

î

¸

Q

o

k

R

R

a

z

k

ê

g

f

¸

ñ

ò

¸

ò

ò

R

ì

a

z

h

ê

p

f

z

h

r

ò

ê

ò

z

z

h

k

r

R

r

z

z

k

h

p

f

z

ò

î

h

r

g

k

g

W

m

g

î

h

z

z

h

H

M

I

r

p

ò

ò

p

5

I

M

I

Ã

@

:

Î

Ï

P

À

¿

»

¼

5

j

@

@

À

Î

Ã

À

Â

¼

Q

o

8

k

=

À

Ã

Â

O

o

R

Ï

Ã

Ú

ñ

º

½

P

Ç

î

ò

ò

À

:

»

Â

É

¼

º

»

¼

È

Ê

¹

º

»

¼

À

Ç

Ç

5

@

:

P

j

R

W

R

ë

=

=

í

z

ò

î

o

Q

¼

Ã

Ê

Ã

î

º

Q

k

o

À

¹

Ç

¿

º

»

Á

»

½

Ç

8

»

:

Ã

=

5

Ã

Á

:

Â

Â

»

8

À

@

Ã

À

À

ë

Å

5

Ã

Å

Ã

Ã

Ã

º

5

8

¼

º

»

=

ñ

=

È

À

»

½

5

=

½

@

Ã

Ã

¼

º

º

»

Ê

î

Q

»

Â

@



ò

î

º

Á

8

ì

R

Ã

»

@

ò

z

»

½

Ä

j

z

¼

5

Æ

r

k

½

»

Ç

:

W

À

º

è

»

k

o

Å

Ã

»

ñ

P

ò

6

=

8

z

Q

+

=

o

R

k

k

R

z

R

z

ë

z

ë

ò

b

ò

ò

ò

ò

ò

ò

ò

Y

Y

ò

Y

Y

]

»

Ã

º

Ã

{

ò

ô

5

r

b

»

=

@

k

p

b



:

Ã

»

z

z

z

=

{

j

R

»

Å

:

î

P

g

k

 

@

À

8

p

î

î

Q

j

:

½

@

Ã

g

@

Á

À

=

p

z

î

î

@

À

R

5

Ã

8

½

O

j

Î

»

=

ñ

g

I

»

½

½

Î

î

O

»

=

»

Â

I

W

M

f

Ï

½

6

M

½

8

À

î

H

Ã

º

¼

f

o

:

¼

5

À

H

o

Z

»

=

r

r

r

ð

8

Ã

r

M

»

8

º

À

M

:

º

p

k

º

@

½

I

¿

Ã

h

o

@

Ï

Z

p

I

Q

Ç

»

r

K

î

=

¿

M

î

I

8

Î

»

K

I

z

M

f

½

p

r

ê

h

r

8

Ã

½

î

K

z

s

=

Ç

½

»

I

M

f

ê

î

R

¿

5

¿

:

I

ò

À

»

»

»

î

W

Z

½

p

k

r

q

»

i

½

K

¸

ò

g

¼

»

Ã

À

f

z

I

º

Ã

½

»

k

r

z

r

M

=

5

º

8

s

Ã

z

o

f

M

Ã

È

R

Z

W

H

j

R

W

r

z

h

z

¿

»

¼

z

g

»

À

º

é

I

Z

g

¹

W

M

Ã

Ã

É

P

H

H

»

Ç

º

º

p

ê

g

Ã

h

ê

Ã

3

z

z

r

Å

¼

5

h

+

À

5

º

I

I

g

½

:

g

H



ì

ò

Â

r

d

m

p

Â

g

Ã

I

r

5

=

Ã

»

ì

h

@

W

d

º

|

»

5

»

j

8

Ç

=

N

Ã

|

Ã

î

g

î

8

r

k

s



k

¸

S

h

h

î

b

Ã

»

»

@

¿

Ã

á

=

Ã

Ï

º

8

5

Ã

º

Ã

¼

Ã

º

À

@

»

=

é

Ã

¿

8

Ã

Ä

Á

Ê

Ã

¹

»

Ã

º

»

º

»

é

5

¿

Ã

Ä

Ã

Ã

5

5

¼

È

È

Ê

»

=

ï

@

5

Ã

:

6

º

5

8

@

=

5

Ã

5

Ã

¾

É

»

Lazy Infinite-State Analysis of Security Protocols À

Å

Ã

¿

5

º

=

8

=

=

8

Æ

@

Ä

¾

=

À

Ã

@

5

½

å

Ã

Â

8

8

@

¼

¾

»

ê

5

=

@

À

Ç

Ã

»

=

º

=

»

5

½

¾

½

»

Á

Ê

@

À



º

Å

»

Ã

º

@

»


0. However, unlike the situation with Wiener’s attack, the fraction k1 d2 /(k2 d1 ) does not break the RSA cryptosystem for two reasons: – Firstly knowing, say, the numerator k1 d2 , does not allow us to find d2 or k1 without factoring this number. – Secondly there may be a factor in common between d1 k2 and d2 k1 in which case the continued fraction method would not give a fraction with numerator k1 d2 and denominator k2 d1 , but rather the fraction with the common factor removed. Guo assumes that the second problem does not exist, i.e. that we have gcd(k1 d2 , k2 d1 ) = 1, and it is estimated that this happens with probability 6/π 2 ' 0.61. To get around the first problem, Guo suggests that one could either try to factor k1 d2 (a number of size about N 2/3 and not typically of a hard factorisation shape), or alternatively assume that one has another encrypting exponent e3 with d3 < N 1/3 . Then (repeating the above procedure with e3 and e2 ) one can also find k3 d2 , and calculating gcd(k1 d2 , k3 d2 ) will hopefully (if gcd(k1 , k3 ) = 1) give d2 and thus allow the factoring of N . The probability of this attack working under the given assumptions is (6/π 2 )3 ' 0.23.

Extending Wiener’s Attack in the Presence of Many Decrypting Exponents

2.3

157

Overview of our Extension Approach

As already said in the introduction, our approach also assumes that we have more than one ei for a given N , and that each of these ei has a relatively small di . In the remainder we will use, among others, ideas from both Wiener and Guo to solve the general problem of breaking RSA in the presence of n encrypting exponents ei , all with relatively small di < N αn , i = 1, . . . , n. The main technique used in deriving these results is the creation and subsequent reduction of certain lattices. The approach taken by us, however, can currently only be classed as a heuristic method because, although the vectors we search for can be shown to be relatively short, we cannot prove yet that they are indeed among the shortest vectors (and hence bound to be found by lattice basis reduction algorithms). Nevertheless, in section 4 it is shown that our approach performs well in practice, and that the following theoretically derived bounds are frequently achieved. In particular, in the presence of n encrypting exponents ei , our approach allows for the di to be as large as N αn where  n (2n+1)2n −(2n+1) (n/2 )   if n is even, n  n  (2n−2)2 +(4n+2) (n/2 ) αn =  n−1 n   (2n+1)2 −4n ((n−1)/2)  if n is odd. n−1 (2n−2)2n +8n ((n−1)/2 ) The first few (from n = 1) start 1/4, 5/14, 2/5, 15/34, 29/62. In section 3.5 it is shown that αn → 1 as n → ∞. If the LLL algorithm (see [LLL]) is used in order to reduce the lattices underlying our approach, and the (pessimistic) estimate for its complexity of O(m6 log3 B) is assumed (given a lattice of dimension m with largest norm B), then the complexity of our method is O(26n n3 log3 N ), and so clearly the attack is only practical for small n.

3 3.1

An Extension in the Presence of Many Small Decryption Exponents Preliminaries

In extending the analysis to n encrypting exponents ei (with small decrypting exponents di ), we use both Wiener’s and Guo’s ideas. We shall refer to relations of the form di gei − ki N = g + ki s as Wiener equations, and we shall denote them Wi (see equation 1 for an example). Similarly we shall refer to relations of the form ki dj ej − kj di ei = ki − kj

158

N. Howgrave-Graham and J.-P. Seifert

as Guo equations, and shall denote them Gi,j (see equation 3 for an example). We shall also assume, for a given n, that the di and ki are at most N αn , that g is small, and that s is around N 1/2 . Notice that the right-hand sides of Wi and Gi,j are therefore quite small; in fact at most N (1/2)+αn , and N αn respectively. Finally we often refer to composite relations, e.g. Wu Gv,w , in which case we mean the relation, whose left-hand (resp. right-hand) side is the product of the left-hand (resp. right-hand) sides of Wu and Gv,w . For example, Wu Gv,w which has a relatively small right-hand side, bounded in size by N (1/2)+2αn . In the following analysis we examine the cases of 2, 3 and 4 exponents before generalising the approach to n exponents. This is done both to give explicit examples of the approach when in the presence of a small number of exponents, and also because it is not until the presence of 4 exponents that the general phenomenon becomes clear. The relations that we choose for the cases of 2, 3 and 4 exponents may seem “plucked from the air”, but the pattern is made clear in section 3.5. 3.2

RSA in the Presence of 2 Small Decryption Exponents

Assuming that we have two small decryption exponents, then the following relations hold: W1 , G1,2 , W1 W2 ; or more explicitly: d1 ge1 − k1 N = g + k1 s, k1 d2 e2 − k2 d1 e1 = k1 − k2 , d1 d2 g e1 e2 − d1 gk2 e1 N − d2 gk1 e2 N + k1 k2 N 2 = (g + k1 s)(g + k2 s). 2

Multiplying the first of these by k2 means that the left-hand sides are all in terms of d1 d2 g 2 , d1 gk2 , d2 gk1 , and k1 k2 , and hence we may write these equations in the matrix form below.   1 −N 0 N 2 (k1 k2 , d1 gk2 , d2 gk1 , d1 d2 g 2 )  e1 −e1 −e1 N  =   e2 −e2 N  e1 e2 (k1 k2 , k2 (g + k1 s), g(k1 − k2 ), (g + k1 s)(g + k2 s). The size of the entries of the vector on the right-hand side are at most N 2α2 , N (1/2)+2α2 , N α2 , and N 1+2α2 respectively. These size estimates may be made roughly equivalent by multiplying the first three columns of the matrix by N , M1 = N 1/2 , and M2 = N 1+α2 respectively, which gives the following matrix:   0 N2 N −M1 N  M1 e1 −M2 e1 −e1 N   L2 =   M2 e2 −e2 N  e1 e2 In this case the vector b = (k1 k2 , d1 gk2 , d2 gk1 , d1 d2 g 2 ) will be such that kbL2 k < 2N 1+2α2 .

Extending Wiener’s Attack in the Presence of Many Decrypting Exponents

159

We must now make the assumption that, in the lattice generated by the rows of L2 , the shortest vector has length ∆1/4− , where ∆ := det(L2 ) ' N (13/2)+α2 , and moreover that the next shortest linearly independent vector has a significantly larger norm than the shortest vector in L2 . Indeed, if the lattice L2 is pretty “random”, there are almost surely no lattice points of L2 significantly shorter than the Minkowski bound 2∆1/4 . Under these assumptions, then bL2 is the shortest vector in the lattice if 1/4  N 1+2α2 < (1/c2 ) N (13/2)+α2 for some small c2 , which is true if α2 < 5/14 − 0 . This implies that the vector b = (b1 , b2 , b3 , b4 ) can be found via lattice basis reduction algorithms (e.g. LLL) if α2 < 5/14 − 0 , and then d1 g/k1 = b2 /b1 can be calculated, which leads to the factoring of N as shown in section 2.1. 3.3

RSA in the Presence of 3 Small Decryption Exponents

This method extends easily to 3 encrypting exponents. We now have the quantities 1, e1 , e2 , e1 e2 , e3 , e1 e3 and e1 e2 e3 from which to form linear relationships, and we already have relationships concerning the first four of these from the 2 exponent case, namely 1, W1 , G1,2 and W1 W2 . For the remaining relationships we choose G1,3 , W1 G2,3 , W2 G1,3 and W1 W2 W3 . These relations imply looking for the vector b = (k1 k2 k3 , d1 gk2 k3 , k1 d2 gk3 , d1 d2 g 2 k3 , k1 k2 d3 g, k1 d3 g, k2 d3 g, d1 d2 d3 g 3 ), by reducing the rows of the following lattice:  0 0 1 −N 0 N 2  e1 −e1 −e1 N −e1 0   e2 −e2 N 0 e2 N   e1 e2 0 −e1 e2 L3 =   e3 −e3 N   e1 e3  

0 e1 N 0 −e1 e2 −e3 N 0 e2 e3

 −N 3 e1 N 2   e2 N 2   −e1 e2 N   × D, e3 N 2   −e1 e3 N   −e2 e3 N  e1 e2 e3

where D is the diagonal matrix diag(N 3/2 , N, N (3/2)+α3 , N 1/2 , N (3/2)+α3 , N 1+α3 , N 1+α3 , 1) used to maximise the determinant of L3 and still keep √ kbL3 k < 8N (3/2)+3α3 .

160

N. Howgrave-Graham and J.-P. Seifert

Again, using the assumptions that the shortest vector in the lattice generated by the rows of L3 has length det(L3 )(1/8)− , and is also significantly shorter than the next shortest linearly independent vector in L3 , means that bL3 will be the shortest vector in the lattice L3 if N (3/2)+3α3 < (1/c3 ) N 20+4α3


1/8

for some small c3 which is true if α3 < 2/5 − 0 . By using again the first two components of b, as in the 2 exponent case, one may now factor the modulus N as shown in section 2.1. 3.4

RSA in the Presence of 4 Small Decryption Exponents

In the presence of 4 exponents we can now use linear relationships among the quantities 1, e1 , e2 , e1 e2 , e3 , e1 e3 , e2 e3 , e1 e2 e3 , e4 , e1 e4 , e2 e4 , e3 e4 , e1 e2 e4 , e1 e3 e4 , e2 e3 e4 and e1 e2 e3 e4 . As before we already have linear relationships for the first half of these quantities from the analysis in the presence of 3 equations. For the remaining quantities we use the relations G1,4 , W1 G2,4 , G1,2 G3,4 , G1,3 G2,4 , W1 W2 G3,4 , W1 W3 G2,4 , W2 W3 G1,4 and W1 W2 W3 W4 . Putting these relations in matrix form, and multiplying the columns by appropriate factors to make all the relations of size at most N 2+4α4 , results in a 16 × 16 matrix, L4 , which has determinant N (109/2)+13α4 . The vector b we are now looking for is b = (k1 k2 k3 k4 , d1 gk2 k3 k4 , k1 d2 gk3 k4 , d1 d2 g 2 k3 k4 , k1 k2 d3 gk4 , d1 k2 d3 g 2 k4 , k1 d2 d3 g 2 k4 , d1 d2 d3 g 3 k4 , k1 k2 k3 d4 g, d1 k2 k3 d4 g 2 , k1 d2 k3 d4 g 2 , k1 k2 d3 d4 g 2 , d1 d2 k3 d4 g 3 , d1 k2 d3 d4 g 3 , k1 d2 d3 d4 g 3 , d1 d2 d3 d4 g 4 ). Therefore, again making the same assumptions as before, implies that the vector bL4 is the shortest vector in the lattice generated by the rows of L4 if 1/16  N 2+4α4 < (1/c4 ) N (109/2)+13α4 for some small c4 , and this is true if α4 < 15/34 − 0 . Using again the first two components of b, as in the 2 and 3 exponent case, one may again factor the modulus N as shown in section 2.1.

Extending Wiener’s Attack in the Presence of Many Decrypting Exponents

3.5

161

The General Approach

Due to space limitations we defer the subtle computation of the general allowable bound on the di when we have n encrypting exponents ei , i = 1, . . . , n, to the appendix and show below simply the graph for  n (2n+1)2n −(2n+1) (n/2 )   if n is even, n  n  (2n−2)2 +(4n+2) (n/2 ) αn =  n−1 n   (2n+1)2 −4n ((n−1)/2)  if n is odd. n−1 (2n−2)2n +8n ((n−1)/2 ) 1 "bounds"

0.8

0.6

0.4

0.2

0 0

20

40

60

80

100

Fig. 1. Graph of bounds αn for n ≤ 100.

4

Practical Results

Although our method is at the current time only heuristic, it works well in practice as can be seen from our experimental results below. Our implementation uses the NTL library [Sh] of Victor Shoup. Timings are given for a 300 MHz AMD K6 running under Linux. RSA-500 with 2 public exponents α2 bit length of di avg. time in secs. success rate 0.356 178 0.441 40% 0.354 177 0.421 100%

162

N. Howgrave-Graham and J.-P. Seifert

Fig. 2. Average running time (in seconds) and success rate for 10 random experiments as a function of α2 .

α2 0.357143 0.355714 0.354286 0.352857

RSA-700 with 2 public exponents bit length of di avg. time in secs. success rate 250 1.075 0% 249 1.117 70% 248 0.93 80% 247 1.33 100%

Fig. 3. Average running time (in seconds) and number of success rate for 10 random experiments as a function of α2 . RSA-500 with 3 public exponents α3 bit length of di avg. time in secs. success rate 0.4 200 3.632 0% 0.398 199 3.567 40% 0.396 198 3.599 90% 0.394 197 3.726 90% 0.392 196 3.595 90% 0.39 195 3.529 100% Fig. 4. Average running time (in seconds) and success rate for 10 random experiments as a function of α3 . RSA-200 with 4 public exponents α4 bit length of di avg. time in secs. success rate 0.44 88 14.538 0% 0.435 87 14.496 50% 0.43 86 14.328 80% 0.425 85 14.159 100% Fig. 5. Average running time (in seconds) and success rate for 10 random experiments as a function of α4 . RSA-200 with 5 public exponents α5 bit length of di avg. time in secs. success rate 0.45 90 424.756 0% 0.445 89 427.275 60% 0.44 88 422.74 100% Fig. 6. Average running time (in seconds) and success rate for 10 random experiments as a function of α5 .

Extending Wiener’s Attack in the Presence of Many Decrypting Exponents

5

163

Open Problems

The major open problem raised by our work is the following. To work out the manageable bound on αn for the secret exponents we had to make two heuristic assumptions concerning “random” lattices. As the experimental results strongly support the derived bounds it is natural to ask whether our attack can be turned into a rigorous theorem?

References B. D. Boneh, “Twenty years of attacks on RSA”, Notices of the AMS Vol. 46, pp. 203213, 1999. BD. D. Boneh, G. Durfee, “New results on the cryptanalysis of low exponent RSA”, to appear in Proc. of EUROCRYPT ’99. D. J. M. DeLaurentis, “A further weakness in the common modulus protocol for the RSA cryptoalgorithm”, Cryptologia Vol. 8, pp. 253-259, 1984. G. C. R. Guo, “An application of diophantine approximation in computer security”, to appear in Mathematics of Computation. HW. G. H. Hardy, E. M. Wright, An introduction to the theory of numbers, 5th edn., Oxford University Press, 1979. LLL. A. K. Lenstra, H. W. Lenstra, L. Lovasz, “Factoring polynomials with integer coefficients”, Mathematische Annalen Vol. 261, pp. 513-534, 1982. M. J. H. Moore, “Protocol failures in cryptosystems”, in G. J. Simmons (ed.), Contemporary Cryptology, IEEE Press, 1992. RSA. R. L. Rivest, A. Shamir, L. Adleman, “A method for obtaining digital signatures and public-key cryptosystems”, Commun. ACM Vol. 21, pp. 120-126, 1978. Sh. V. Shoup, “Number Theory Library (NTL)”, http://www.cs.wisc.edu/˜ shoup.ntl. Si. G. J. Simmons, “A ‘weak’ privacy protocol using the RSA cryptalgorithm”, Cryptologia Vol. 7, pp. 180-182, 1983. VvT. E. R. Verheul, H. C. A. van Tilborg, “Cryptanalysis of ‘Less Short’ RSA secret exponents”, Applicable Algebra in Engeneering, Communication and Computing Vol. 8, pp. 425-435, 1997. W. M. Wiener, “Cryptanalysis of short RSA exponents”, IEEE Trans. on Information Theory Vol. 36, pp. 553-558, 1990.

Appendix We now work out the general bound on the di when we have n encrypting exponents. The reader is encouraged to refer back to the previous sections (when n = 2, 3 and 4) as examples. Given that there are n exponents ei , then there are 2n different quantities, hj , n−1 involving the ei ’s, and the product of all of these (assuming e ' N ) is N (n2 ) . n This means that one considers a diagonal matrix, Ln , of dimension 2 , and that the determinant of this matrix, before multiplying the rows to increase the n−1 allowable bound, is N (n2 ) .

164

N. Howgrave-Graham and J.-P. Seifert

The last relation W1 W2 . . . Wn has a right-hand side of at most N (n/2)+nαn , and thus we increase the right-hand side of all the other relations up to this bound, making the desired vector b such that kbLn k∞ is (still) approximately N (n/2)+nαn . The general form of the desired vector b is that its j th entry is the product of n unknown quantitities ai for i = 1 . . . n, where ai is either di g or ki depending on whether ei is present in the j th quantity hj or not. We now consider the interesting problem of which relations to consider for n equations. Observe that a general relation of the form Ru,v = Wi1 . . . Wiu Gj1 ,l1 . . . Gjv ,lv , (where the i1 , . . . , iu , j1 , . . . , jv , l1 , . . . , lv are unique), has a left-hand side composed of products of (u + 2v) of the ei ’s with coefficients that are products of (u + v) of the unknown quantities ai (where ai is again either di g or ki ). Also notice that the right-hand side of Ru,v has size at most N (u/2)+(u+v)αn . Our method requires all the coefficients to be roughly the same size (a product of n of the quantities ai ). This means that relations which have coefficients less than this must be multiplied (on both sides) by some missing ki . For example, in the the 2 exponent case we multiplied the first equation by k2 to make all the coefficients of size N 2α2 . This has the effect of increasing the right-hand side of relation Ru,v to a size bounded by N (u/2)+(n−v)αn . Given this new relation Ru,v we now need to make it’s right-hand side as large as the right-hand side of W1 W2 . . . Wn , which means multiplying (both sides) by N (n−u)/2+vαn . For example, these multiplication factors are the (diagonal) entries of the diagonal matrix D in the example when n = 3. Say that the product of these multiplication factors (i.e. the determinant of D in the n = 3 example) is N βn , where βn = x + yαn , and let Ln denoted the lattice of (modified) relations as before. This means that (under the usual assumptions) the vector bLn is the shortest vector of the lattice if 1/2n  n−1 N n/2+nαn < (1/cn ) N n2 +x+yαn for some small cn , i.e. when αn
2l−1 , but also that |Zn∗ | = n − p1 − p2 + 1 > 2l−1 , and that p1 + p2 − 1 < 2l/2+1 . Let Q denote the set of non-zero quadratic residues modulo n. Note that |Q| > 2l−3 . Note also that for x ∈ Q, exactly one of its four square roots is also in Q (this follows from the fact that −1 is a non-square modulo p1 and p2 and the Chinese remainder theorem). Thus, squaring is a permutation over Q. From now on, when we speak −k of “the square root of x,” we mean the single square root in Q; by x2 we will k 2 is a non-square denote the single y ∈ Q such that x = y 2 .Also  note that 2 (p2 −1)/8 ), so 1 ∈ Q and modulo p1 and a square modulo p2 (because p = (−1) −1, 2, −2 ∈ / Q. In general, for any x ∈ Zn∗ , exactly one of x, −x, 2x, −2x is in Q. Following [GMR88], define F0 (x) = x2 mod n, F1 (x) = 4x2 mod n, and, for an m-bit binary string σ = b1 . . . bm , define Fσ : Q → Q as Fσ (x) = m Fbm (. . . (Fb2 (Fb1 (x))) . . .) = x2 4σ mod n (note that 4σ is a slight abuse of notation, because σ is a binary string, rather than an integer; what is really meant here is 4 raised to the power of the integer represented in binary by σ). Because squaring is a permutation over Q and 4 ∈ Q, Fσ is a permutation over Q. Note that Fσ (x) can be efficiently computed by anybody who knows n. Also, if one knows p1 and p2 , one can efficiently compute x = Fσ−1 (y) (as shown −|σ| mod n and then letting by Goldreich in [Gol86]) by computing s = 1/42 −|σ| x = y2 sσ mod n (these calculations can be done modulo p1 and p2 separately, and the results combined using the Chinese remainder theorem). However, if one does not know p1 and p2 , then Fσ−1 is hard to compute, as shown in the Lemma below. Lemma 1. If one can compute, for a given y ∈ Q and two different strings σ and τ of equal length, x1 = Fσ−1 (y) and x2 = Fτ−1 (y), then one can factor n. Proof. The proof is by induction on the length of the strings σ and τ . If |σ| = |τ | = 1, then assume, without loss of generality, that σ = 0 and τ = 1. Then F0 (x1 ) ≡ F1 (x2 ) ≡ y mod n, i.e., x21 ≡ 4x22 mod n, i.e., n|(x1 − 2x2 )(x1 + 2x2 ). Note that x1 , x2 ∈ Q and ±2 ∈ / Q, so ±2x2 ∈ / Q, so x1 ≡ / ± 2x2 (mod n), so n does not divide either x1 − 2x2 or x1 + 2x2 . Thus, by computing the gcd of x1 + 2x2 and n, we can get either p1 or p2 . For the inductive case, let σ and τ be two strings of length m + 1. Let σ 0 and 0 τ be their m-bit prefixes, respectively. If Fσ0 (x1 ) ≡ Fτ 0 (x2 ) (mod n), we are done by the inductive hypothesis. Otherwise, the last bit of σ must be different

172

S. Micali and L. Reyzin

from the last bit of τ , so, without loss of generality, assume the last bit of σ is 0 and the last bit of τ is 1. Then F0 (Fσ0 (x1 ) ≡ F1 (Fτ 0 (x2 ) (mod n), and the same proof as for the base case works here. The ID Scheme. The above lemma naturally suggests the following ID scheme. A user has n as the public key and p1 , p2 as the secret key. To prove his identity (i.e., that he knows p1 and p2 ) to a verifier, he commits to random X ∈ Q and sends it to the verifier. The verifier produces a random k-bit challenge σ −1 and sends it to the prover (the user). The prover responds with z = F0σ (X) (note that σ here is prefixed with a single 0 bit, whose use will be explained / 0 (mod n). shortly). The verifier checks that X = F0σ (z) = Fσ (z 2 ) and that z ≡ Informally, the security of this protocol is based on the fact that if the prover is able to respond to two different challenges σ and τ , then, by Lemma 1, he knows p1 and p2 . The 0 bit in front of σ is to save the verifier from having to check that the prover’s response is in Q (which is a hard problem in itself)—instead, she just squares the prover’s response and thus puts it in Q. We will say no more about the security of this ID scheme because we are not concerned with it in this paper. We will, however, point out an efficiency improvement for the prover. First, as part of key generation, the prover com−k−1 mod n. Then, when putes, using the Chinese remainder theorem, s = 1/42 committing to a random X ∈ Q, the prover randomly selects an x ∈ Zn∗ and k+1 mod n (note that X gets selected with uniform distribution as sets X = x2 long as x is so selected). Now, to respond to a challenge σ, the prover simply computes z = xsσ mod n. The E Scheme. The standard way to change the above ID scheme into a signature scheme is to replace the verifier with a random function H : {0, 1}∗ → {0, 1}k . The exact steps of the algorithms Gen, Sign and V er follow. Key Generation 1. Generate two random primes p1 ≡ 3 (mod 8) and p2 ≡ 7 (mod 8) and n = p1 p2 so that n < 2l , n − p1 − p2 + 1 > 2l + 1 and p1 + p2 − 1 < 2l/2+1 2. Generate coefficient c = p2 −1 mod p1 for use in the Chinese remainder theorem
k+1 mod pi2−1 for i = 1, 2 (note that ui is such that 3. Compute ui = pi4+1 k+1 raising a square to the root)
power ui modulo pi will compute its 2 pi +1 ui mod pi for i = 1, 2 4. Compute si = 4 5. Compute v = (s1 − s2 )c mod p1 and s = s2 + vp2 to get −(k+1) mod n s = 1/42 6. Output n as the public key and (n, s) as the secret key Signing k+1 mod 1. Generate X by picking a random x ∈ Zn∗ and computing X = x2 n (note that this step can be done off-line, before the message is known) −1 2. Compute σ = H(X, M ), and z = F0σ (X) via t = sσ mod n (this can be σ done via ti = si mod pi for i = 1, 2, v = (t1 − t2 )c mod p1 , t = t2 + vp2 ) and z = xt mod n 3. Output (z, σ)

Improving the Exact Security of Fiat-Shamir Signature Schemes

173

Verifying k+1 mod 1. Verify that z ≡ / 0 (mod n) and compute X = Fσ (z 2 ) via t1 = z 2 σ n, t2 = 2 mod n, X = t1 t2 mod n 2. Verify if σ = H(X, M ) 3.2

Security of the E scheme

We state the following two theorems that give two different views of the exact security of the E scheme and demonstrate the tradeoff between running time and success probability. Their proofs use known methods (see Pointcheval and Stern [PS96] and Ohta and Okamoto [OO98]). Our probability analysis is new, however, and results in slightly tighter reductions. Theorem 1. If there exists a forger that (t, qsig , qhash , ε, δ)-breaks the E scheme with security parameters l and k, then there exists an algorithm that (t0 , ε0 , δ)factors integers generated by Gen for t0 = 2t + 2(qsig + 1)T1 + T2   ε ε0 = ε − 2−k (1 − 2γ) , qhash + 1 where T1 is the time required to perform an E signature verification, T2 is the time required to factor n given the conditions of Lemma 1 (essentially, a gcd computation) and γ = qsig (qhash + 1)2−l+3 (note that γ is close to 0 for a large enough l). Proof. Let F be a forger that (t, qsig , qhash , ε, δ)-breaks E signature scheme. We will construct a factoring algorithm A that uses F to produce y, z ∈ Zn∗ and σ 6= τ ∈ {0, 1}k such that Fσ (z 2 ) = Fτ (y 2 ). This will allow A to factor n by using the method given in the proof of Lemma 1. The main idea of this proof is given by the “forking lemma” of [PS96]. It is to allow F to run once to produce one forgery—a signature (z, σ) on a message M such that σ = H(X, M ) where X = Fσ (z 2 ). Note that F had to ask a hashing-oracle query on (X, M )—otherwise its probability of success is at most 2−k . Then, run F the second time, giving the same answers to all the oracle queries before the query (X, M ). For (X, M ) give a new answer τ . Then, if F again forges a signature (y, τ ) using X and M , we will have achieved our goal. Assuming n is such that F has probability at least ε of success, the probability that A will factor n using this approach is roughly ε2 /qhash , because F needs to succeed twice and we have no guarantee that F will choose to use (X, M ) for its second forgery and not any of its other qhash oracle queries. The complete details of the proof are available in the full version of this paper and are omitted here in the interests of space. Theorem 2. If there exists a forger that (t, qsig , qhash , ε, δ)-breaks the E scheme with security parameters l and k, such that ε > 2−k+1 (qhash +1)/(1−qsig (qhash +

174

S. Micali and L. Reyzin

1)2−l+3 ), then there exists an algorithm that (t0 , ε0 , δ)-factors integers generated by Gen for (2qhash + 3)(t + qsig T1 ) + T2 ε(1 − γ) − 2−k+1 (qhash + 1)  2 1 1 0 1− ε = > 0.199, 2 e t0 =

where T1 , T2 and γ are as in Theorem 1. Proof. The idea is to iterate the A from Theorem 1 sufficiently many times to get a constant probability of success. More specifically, run F about 1/ε times the first time, to achieve a constant probability of a successful forgery, and about 2qhash /ε times the second time, to achieve a constant probability of a successful forgery that uses the pair (X, M ). The complete details of the proof are available in the full version of this paper and are omitted here in the interests of space. The following two statements follow directly from the theorems just proved once we fix the parameters to be high enough to avoid dealing with small terms. Corollary 1. If factoring l-bit integers generated by Gen is (t0 , ε0 , δ)-secure, then the E signature scheme is (t, qsig , qhash , ε, δ)-secure for qsig ≤ 2l−5 /(qhash + 1) t = t0 /2 − (qsig + 1)T1 − T2 /2 p ε = 2−k (qhash + 1) + 2ε0 (qhash + 1) Proof. Note that the value for t follows directly by solving for t the equation for t0 in the statement of Theorem 1. The value for ε is computed as follows: solve for ε the quadratic equation that expresses ε0 in terms of ε to get   q −k −2k 2 0 (qhash + 1) + 4ε (qhash + 1)/(1 − 2γ) /2 ε = 2 (qhash + 1) + 2   q p −k −2k 2 0 ≤ 2 (qhash + 1) + 2 (qhash + 1) + 4ε (qhash + 1)/(1 − 2γ) /2 p = 2−k (qhash + 1) + ε0 (qhash + 1)/(1 − 2γ). Observe that we are allowed to increase ε, as this will only weaken the result. Note that the condition on qsig ensures that 1 − 2γ ≥ 1/2, so setting ε to p 2−k (qhash + 1) + 2ε0 (qhash + 1) will not decrease it. Corollary 2. If factoring l-bit integers generated by Gen is (t0 , 0.199, δ)-secure, then the E signature scheme is (t, qsig , qhash , ε, δ)-secure for t=

(t0 − T2 )ε − qsig T1 4qhash + 6

Improving the Exact Security of Fiat-Shamir Signature Schemes

175

as long as qsig ≤ 2l−5 /(qhash + 1) ε ≥ 2−k+3 (qhash + 1). Proof. The proof is similar to that of of Corollary 1, and is given in the full paper.

4 4.1

The Swap Method Motivation

As exemplified by the proof of Theorems 1 and 2 above, all known results for the security of Fiat-Shamir-like signature schemes involve losing a factor of qhash (in either time or success probability) in the reduction from a forger to an algorithm that breaks the underlying hard problem (see, for example, [FS86], [Sch96], [PS96], [Sho96], [OO98]). While no proof exists that the loss of this factor is necessary, the problem seems inherent in the way signature schemes are constructed from ID schemes, as explained below. The security of an ID scheme usually relies on the fact that a prover would be unable to answer two different challenges for the same commitment without knowing the private key. Therefore, in the proof of security of the corresponding signature scheme, we need to use the forger to get two signatures on the same commitment, as we did in the proof of Theorems 1 and 2. The forger, however, has any of its qhash queries to pick for the commitment for the second signature— hence, our loss of the factor of qhash . We want to point out that qhash is a significant factor, and its loss definitely makes a reduction quite loose. This is because a reasonable bound on the number of possible hash queries of committed adversaries is about qhash = 280 (see Section 4.4). We therefore devise a new method of constructing signature schemes from ID schemes so that any one signature from the forger is enough to break the underlying hard problem. 4.2

Method

Recall that in Fiat-Shamir-like signature schemes, the signer comes up with the commitment and then uses H applied to the commitment and the message to produce the challenge. We propose that instead the signer first come up with the challenge and then use H applied to the challenge and the message to produce the commitment. In a way, we swap the challenge and the commitment. This method applies whenever the signer can compute the response given only the challenge and the commitment. It does not apply when information used during the generation of the commitment is necessary to compute the response. For example, it does not apply to discrete-logarithm-based ID schemes (such as the Schnorr scheme [Sch89]) in which the prover needs to know the discrete logarithm of the commitment in order to provide the response.

176

S. Micali and L. Reyzin

Additionally, in order to use this method, one needs to get around the problem that the commitment is selected from some structured set (such as Q in the case of E), while H returns a random binary string. This problem can usually be easily solved. The only case known to us when it seems to present a real obstacle is in the scheme of Ohta and Okamoto ([OO88]) in the case when an exponent L is used such that gcd(L, (p1 − 1)(p2 − 1)) > 2. The key-generation algorithm and the private key may need to be modified slightly in order to provide the signer with the additional information needed to compute the response from a random commitment, rather than from a commitment that it generated. The verification algorithm remains vastly unchanged. In the next section, we exemplify our proposed method and explain why it results a tighter security reduction. 4.3

E-swap

Description. The scheme depends on two security parameters: k and l. Let H : {0, 1}∗ → {0, 1}l−1 be a random function. Key Generation The key generation is the same as in the E scheme, except for one additional step (step 6) and extra information in the private key: 1. Generate two random primes p1 ≡ 3 (mod 8) and p2 ≡ 7 (mod 8) and n = p1 p2 so that n < 2l , n − p1 − p2 + 1 > 2l + 1 and p1 + p2 − 1 < 2l/2+1 2. Generate coefficient c = p2 −1 mod p1 for use in the Chinese remainder theorem
k+1 mod pi2−1 for i = 1, 2 (note that ui is such that 3. Compute ui = pi4+1 k+1 raising a square to the root)
power ui modulo pi will compute its 2 pi +1 ui 4. Compute si = mod pi for i = 1, 2 4 5. Compute v = (s1 − s2 )c mod p1 and s = s2 + vp2 to get −(k+1) s = 1/42 mod n 6. If ui is odd, make it even by setting ui = ui + pi2−1 for i = 1, 2 (note that now ui is such that raising a square or its negative to the power ui modulo pi will compute its 2k+1 root) 7. Output n as the public key and (n, s, u1 , u2 , p1 , p2 ) as the secret key Signing 1. Generate a random σ and compute t = sσ mod n (note that this step can be done off-line, before the message is known). 2. Compute X = H(σ, M ). We will assume X ∈ Zn∗ (i.e., (X, n) = 1), because the
probability of X ∈ / Zn∗ is at most 2−l/2+2 . If the Jacobi X symbol n = −1, set X = 2X mod n. Now either X or n − X is in Q. Compute z = F0 σ −1 (±X) via xi = X ui mod pi for i = 1, 2, v = (x1 − x2 )c mod p1 , x = x2 + vp2 and z = xt mod n. 3. Output (z, σ). Verifying k+1 1. Verify that z ≡ / 0 (mod n) and compute X = Fσ (z 2 ) via t1 = z 2 mod n, t2 = 2σ mod n, X = t1 t2 mod n (this step is the same as for the E scheme). 2. Let X 0 = H(σ, M ). If X ≡ ±X 0 (mod n) or X ≡ ±2X 0 (mod n), accept the signature (this step differs slightly from the E scheme).

Improving the Exact Security of Fiat-Shamir Signature Schemes

177

Security of E-swap. Theorem 3. If there exists a forger that (t, qsig , qhash , ε, δ)-breaks the E-swap scheme with security parameters l and k, then there exists an algorithm that (t0 , ε0 , δ)-factors integers generated by Gen for t0 = t + 2(qsig + qhash + 1)T1 + T2 ε0 = ε (1 − γ) − (qhash + qsig + 1)2−l/2+2 , where T1 is the time required to perform an E-swap signature verification, T2 is the time required to factor n given the conditions of Lemma 1 (essentially, a gcd computation) and γ = qsig (qhash + 1)2−k (note that γ is close to 0 for a large enough k). Proof. Familiarity with the proof of Theorem 1 will be helpful for understanding this proof. Let F be a forger that (t, qsig , qhash , ε, δ)-breaks E-swap signature scheme. Similarly to the proof of Theorem 1, we will construct an algorithm that, after interacting with F , will produce y, z ∈ Zn∗ and σ 6= τ ∈ {0, 1}k such that Fσ (z 2 ) = Fτ (y 2 ). The main idea is to answer each hash query on (σ, M ) with an X computed via X = Fτ (y 2 ) for a random y ∈ Zn∗ and arbitrary τ that is different from σ. Then if F forges a signature (z, σ) on M , we will have Fσ (z 2 ) = Fτ (y 2 ) and will be able to factor n. The complete details of the proof are available in the full version of this paper and are omitted here in the interests of space. Theorem 4. If there exists a forger that (t, qsig , qhash , ε, δ)-breaks the E-swap scheme with security parameters l and k, such that
ε > (qhash + qsig + 1)2−l/2+2 / 1 − qsig (qhash + 1)2−k , then there exists an algorithm that (t0 , ε0 , δ)-factors integers generated by Gen for t + 2(qsig + qhash + 1)T1 + T2 ε (1 − γ) − (qhash + qsig + 1)2−l/2+2   1 ε0 = 1 − > 0.632, e t0 =

where T1 and T2 are as in Theorem 3. Proof. Let

α = ε (1 − γ) − (qhash + qsig + 1)2−l/2+2 .

By assumption, α > 0. So if we repeat the algorithm constructed in the proof of Theorem 3 up to 1/α times (except for the final gcd computation, which need only be done once), we will get the desired ε0 , similarly to the proof of Theorem 2.

178

S. Micali and L. Reyzin

Similarly to the E scheme, we have the following two corollaries. Corollary 3. If factoring l-bit integers generated by Gen is (t0 , ε0 , δ)-secure, then E-swap signature scheme is (t, qsig , qhash , ε, δ)-secure, where qsig ≤ min(2k−2 /(qhash + 1), ε2l/2−4 − qhash − 1) t = t − 2(qsig + qhash + 1)T1 − T2 ε = 2ε0 . Proof. The condition on qsig ensures that ε(1−γ)−(qhash +qsig +1)2−l+2 ) ≥ ε/2. The rest follows, similarly to the proof of Corollary 1, from solving the equations of Theorem 3 for t and ε. Corollary 4. If factoring l-bit integers generated by Gen is (t0 , 0.632, δ)-secure, then the E-swap signature scheme is (t, qsig , qhash , ε, δ)-secure for qsig ≤ min(2k−2 /(qhash + 1), ε2l/2−4 − qhash − 1) (t0 − T2 )ε − 2(qsig + qhash + 1)T1 . t= 2 Proof. The condition on qsig ensures that ε(1−γ)−(qhash +qsig +1)2−l+2 ) ≥ ε/2. The rest follows, similarly to the proof of Corollary 2, from solving the equations of Theorem 4 for t and ε. 4.4

Parameter Choice

The formulas in the Corollaries 1–4 are quite different. Nonetheless, it is immediately clear that E-swap loses no factor of qhash , neither in time nor in probability. This is a big advantage for E-swap because qhash can be quite big. A fuller comparison, provided in the next section, depends on the actual values of the parameters qsig , qhash , k and l. Let us deal here, however, with the preliminary problem of assigning reasonable values to these parameters. We believe it reasonable to set qsig = 230 and qhash = 280 − 1. This is so because signature queries have to be answered by the honest signer (who may not be willing or able to sign more than a billion messages), while hash queries can be computed by the adversary alone (who may be willing to invest extraordinary resources). Notice that we recommend a higher value for qhash than suggested in [BR96]. We recommend setting k = 100 for the E scheme and k = 112 for E-swap. For the E scheme, this is so because, from Corollaries 1 and 2, we see that 2−k (qhash + 1) has to be small (the value of 2−k (qhash + 1) is essentially the success probability of the simple attack that relies on correctly guessing one hash value among qhash + 1 hash queries). Therefore, we need 2−k+80 to be small, and by setting k = 100 we make it less than 10−6 . For E-swap, this is so because 2k−2 has to be at least qsig (qhash + 1) = 2110 from Corollaries 3 and 4.

Improving the Exact Security of Fiat-Shamir Signature Schemes

179

As for l, notice that both E and E-swap are immediately broken if the adversary succeeds in factoring the l-bit modulus. Therefore, l ought to be at least 1000. Given the above choices for the other parameters, such a minimum value for l is large enough to make all the constraints involving l in Corollaries 1–4 satisfied (for any reasonable ε in the case of Corollaries 3 and 4). Thus, the value of l depends on the presumed security of factoring, as discussed in the next section.

5 5.1

The Case for Exact Security-Cost Analysis The Costs of Security

The desired level of security is usually dictated by the specific application. It is after settling on the desired amount of security that choosing among the various secure schemes becomes crucial. Indeed, when choosing a signature scheme, the goal is to maintain the desired level of security at the lowest possible cost. In a sense, picking a signature scheme is similar to shopping for an insurance policy for the desired face value. The costs of a signature scheme, however, are quite varied. They may include the sizes of keys and signatures, the efficiencies of generating keys, signing and verifying, the amounts of code required, and even “external” considerations— such as the availability of inexpensive implementations or off-the-shelf hardware components. In this paper, we focus on the efficiencies of signing and verifying. These are particularly important when signing or verifying is performed by a low-power device, such as a smart card, or when signing or verifying needs to be performed in bulk quantities, as on a secure server. It is for these costs, then, that below we compare the E and E-swap schemes. We also provide a comparison of the E scheme with the PRab scheme from [BR96], arguably the most practical among those tightly related to factoring. (The reason for choosing PRab rather than its PSS variant is that the latter is tightly related to RSA, and thus potentially less secure than factoring.) 5.2

Comparison of E and E-swap

The efficiency of signature verification in E is about the same as in E-swap. The security of E-swap is generally higher than the security of E for the same security parameters. Therefore, if the efficiency of verifying is the only significant component in the cost, E-swap will be able to provide the same amount of security for less cost than E. A more difficult case to analyze is the case when the efficiency of signing is of main concern. We will limit our analysis to the case when we are only concerned with the on-line part of signing. In both cases, this involves mainly a modular exponentiation. Therefore, a variety of sophisticated algebraic methods can be used here, but these methods apply equally to E and E-swap. We thus find it simpler to compare the two under “standard” implementations using the Chinese

180

S. Micali and L. Reyzin

remainder theorem (CRT). Then the total amount of time required for on-line signing in the E scheme is about 3kl2 /4 and the total required for on-line signing in E-swap is about 3l3 /8, not counting the (relatively small) cost of computing the Jacobi symbol. (In sum, on-line signing is l/(2k) times faster for E than for E-swap if one used the same value of l for both.1 ) Let us now see how the security of the two schemes compares assuming the on-line signing costs are the same. Let lE and kE be the security parameters for E, and lES and kES be the security parameters for E-swap. The on-line signing costs for E and E-swap are the same if 2 1/3 ) . lES = (2kE lE

(1)

The best known factoring algorithms take time about !  1/3 64 1/3 2/3 T (l) = C exp l (ln l) 9 for some constant C [LL93]. Therefore, we will assume that factoring l-bit integers generated by Gen is (C 0 T (l), 0.199, δ)-secure for some δ and some constant C 0 . Using the formulas given by Corollaries 2 and 4 and the values for qsig , qhash , kE and kES as given by Section 4.4, we can now find out when the E scheme becomes more secure that E-swap if we keep the signing costs equal. The details of further algebraic manipulations are omitted here and given in the full paper. The result is that at lE = 6109, lES = 1954, kE = 100, kES = 112, E and E-swap provide about the security and the same performance for on-line signing. Beyond this point, the gap in security for the same performance increases exponentially in favor of E. Thus, the signing algorithm of the E scheme is so fast that provable security and signing efficiency are the same when E uses 6109-bit moduli and E-swap 1954-bit moduli. In both cases, the security is that of factoring a 1954-bit integer generated by Gen. (The E scheme may actually be even more secure, but we cannot prove it!) It just so happens that this computed level of security is currently considered adequate for many applications. (Therefore, for these applications E-swap is preferable: E-swap has faster verification for the same level of security, as well as shorter keys and, therefore, shorter signatures.) However, whenever the application calls for an higher level of security, and the dominant cost is that of signing, then the “loosely”-secure E becomes preferable because the security gap between E and E-swap, given the same performance, increases exponentially.

1

Moreover, an optimization available to E but not to E-swap is precomputing some powers of the fixed base; this requires additional memory, so we will assume it is not implemented for the purposes of this analysis.

Improving the Exact Security of Fiat-Shamir Signature Schemes

5.3

181

Comparison of the E Scheme with Bellare-Rogaway’s PRab

The security of PRab is tightly related to that of modular square roots, rather than factoring. A factor of 2 in probability is lost (as compared to E-swap) when one relates the security of PRab to that of factoring. PRab’s performance for on-line signing is about the same as E-swap’s (PRab requires a few more Jacobi symbol computations, but no separate modular multiplication).2 A vastly similar analysis leads to the following conclusion: provable security and signing efficiency are the same when E uses 5989-bit moduli, and PRab 1929-bit moduli. Also here this is a “cross-over” point: the gap in security for the same performance increases exponentially in favor of the E scheme. As we can see, this cross-over point is just slightly more in favor of E than the cross-over point of E and E-swap. This is because of the factor of 2 difference in the security of E-swap and PRab.

Acknowledgments We would like to thank Salil Vadhan for pointing out an error in an earlier version of this work and Mihir Bellare for suggesting an improvement in the security analysis of the E scheme using an idea from [BM99].

References BM99.

Mihir Bellare and Sara Miner. A forward-secure digital signature scheme. In Michael Wiener, editor, Advances in Cryptology—CRYPTO ’99, volume 1666 of Lecture Notes in Computer Science. Springer-Verlag, 15–19 August 1999. Revised version is available from http://www.cs.ucsd.edu/ mihir/. BR93. Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigm for designing efficient protocols. In Proceedings of the 1st ACM Conference on Computer and Communication Security, November 1993. Revised version appears in http://www-cse.ucsd.edu/users/mihir/papers/crypto-papers.html. BR96. Mihir Bellare and Phillip Rogaway. The exact security of digital signatures: How to sign with RSA and Rabin. In Maurer [Mau96], pages 399–416. Revised version appears in http://www-cse.ucsd.edu/users/mihir/papers/crypto-papers.html. Dam90. I. B. Damg˚ ard, editor. Advances in Cryptology—EUROCRYPT 90, volume 473 of Lecture Notes in Computer Science. Springer-Verlag, 1991, 21–24 May 1990. FFS88. Uriel Feige, Amos Fiat, and Adi Shamir. Zero-knowledge proofs of identity. Journal of Cryptology, 1(2):77–94, 1988. FS86. Amos Fiat and Adi Shamir. How to prove yourself: Practical solutions to identification and signature problems. In Odlyzko [Odl86], pages 186–194. GMR88. Shafi Goldwasser, Silvio Micali, and Ronald L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing, 17(2):281–308, April 1988. 2

PRab has no off-line component in signing and has more efficient verification.

182 Gol86. Gol88. GQ88. LL93. Mau96. Mic94. MS88. Odl86. Oka92.

OO88. OO98.

OS90. PS96. QV89. Sch89. Sch96.

Sho96. Wil80.

S. Micali and L. Reyzin Oded Goldreich. Two remarks concerning the Goldwasser-Micali-Rivest signature scheme. In Odlyzko [Odl86], pages 104–110. S. Goldwasser, editor. Advances in Cryptology—CRYPTO ’88, volume 403 of Lecture Notes in Computer Science. Springer-Verlag, 1990, 21–25 August 1988. Louis Claude Guillou and Jean-Jacques Quisquater. A “paradoxical” indentity-based signature scheme resulting from zero-knowledge. In Goldwasser [Gol88], pages 216–231. A. Lenstra and H. Lenstra, editors. The development of the number field sieve, volume 1554 of Lecture notes in Mathematics. Springer-Verlag, 1993. Ueli Maurer, editor. Advances in Cryptology—EUROCRYPT 96, volume 1070 of Lecture Notes in Computer Science. Springer-Verlag, 12–16 May 1996. Silvio Micali. A secure and efficient digital signature algorithm. Technical Report MIT/LCS/TM-501, Massachusetts Institute of Technology, Cambridge, MA, March 1994. Silvio Micali and Adi Shamir. An improvement of the Fiat-Shamir identification and signature scheme. In Goldwasser [Gol88], pages 244–247. A. M. Odlyzko, editor. Advances in Cryptology—CRYPTO ’86, volume 263 of Lecture Notes in Computer Science. Springer-Verlag, 1987, 11–15 August 1986. Tatsuaki Okamoto. Provably secure and practical identification schemes and corresponding signature schemes. In Ernest F. Brickell, editor, Advances in Cryptology—CRYPTO ’92, volume 740 of Lecture Notes in Computer Science, pages 31–53. Springer-Verlag, 1993, 16–20 August 1992. Kazuo Ohta and Tatsuaki Okamoto. A modification of the Fiat-Shamir scheme. In Goldwasser [Gol88], pages 232–243. Kazuo Ohta and Tatsuaki Okamoto. On concrete security treatment of signatures derived from identification. In Hugo Krawczyk, editor, Advances in Cryptology—CRYPTO ’98, volume 1462 of Lecture Notes in Computer Science, pages 354–369. Springer-Verlag, 23–27 August 1998. H. Ong and C. P. Schnorr. Fast signature generation with a Fiat Shamir-like scheme. In Damg˚ ard [Dam90], pages 432–440. David Pointcheval and Jacques Stern. Security proofs for signature schemes. In Maurer [Mau96], pages 387–398. J.-J. Quisquater and J. Vandewalle, editors. Advances in Cryptology— EUROCRYPT 89, volume 434 of Lecture Notes in Computer Science. Springer-Verlag, 1990, 10–13 April 1989. C. P. Schnorr. Efficient identification and signatures for smart cards. In Quisquater and Vandewalle [QV89], pages 688–689. C. P. Schnorr. Security of 2t -root identification and signatures. In Neal Koblitz, editor, Advances in Cryptology—CRYPTO ’96, volume 1109 of Lecture Notes in Computer Science, pages 143–156. Springer-Verlag, 18–22 August 1996. Victor Shoup. On the security of a practical identification scheme. In Maurer [Mau96], pages 344–353. Hugh C. Williams. A modification of the RSA public-key encryption procedure. IEEE Transactions on Information Theory, IT-26(6):726–729, November 1980.

On Privacy Issues of Internet Access Services via Proxy Servers Yuen-Yan Chan Department of Information Engineering Chinese University of Hong Kong Shatin, Hong Kong [email protected]

Abstract. When you access to the Internet via an Internet services provider (ISP), information like when and how long you access the modem pool and which objects you request is logged in the proxy servers. Such data enables one’s user habit to be traced and analyzed. This is referred as ’clicktrails’ data collections and is a threat to user privacy. In this paper, present legal and technical solutions of protecting user privacy in Internet service provisions are discussed. We also propose a cryptographic solution that allows anonymous Internet connection via an ISP proxy, while the user’s identity is revealed when he/she misbehaves. In this way, user can access the Internet anonymously while the anonymity cannot be abused.

1

Introduction

The rapid development of the Internet has made a revolution over our daily life. Information is abundantly and easily accessible to everyone who has a connection to the world wide information superhighway. Internet applications like electronic commerce, electronic messaging (e.g. E-mails) as well as the World Wide Web provide great convenience to the modern society and eventually transform commerce, education, provision of government services and almost every other aspect of modern life. However, the privacy issues accompanying these innovations cannot be neglected. The potential interception or misuse of personal data collected from the provision of Internet services is a threat to user privacy. Moreover, the rapid development of data mining technologies makes this threat even more severe. This results in the calling of anonymous Internet access. We believe that anonymity should be provided conditionally. In the later part of this paper, we will propose a cryptographic solution that can achieve conditional anonymous Internet connections, which is developed based on the Electronic Cash Protocol introduced in [1]. In our protocol, user anonymity is maintained so long as the user does not misbehave. In this way, user privacy is protected while anonymity is not abused. R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 183–191, 1999. c Springer-Verlag Berlin Heidelberg 1999

184

2

Y.-Y. Chan

Privacy Issues of Internet Access Services

Internet services providers can learn much about their customers, as all information that will pass to an Internet user must first pass through the proxies reside in their servers. Although encryption techniques such as SSL are used so that third parties cannot interpret the contents being transmitted, the ISP can still determine what web sites or even which article a particular user has visited. This is because every Internet object request originated from the users is logged in the ISP’s proxy cache. This is referred as the ’clicktrails’ data collection. Collecting and analyzing the ’clicktrails’ data can derive much information about a person. 2.1

Present Privacy Laws and Policies

The collection of personal data is unavoidable in many occasions (e.g. opening a bank account), Some existing privacy ordinances such as [2] allows services providers to collect user’s private information for the purpose intended, but prevents them from changing the usage of such data. For the case of Internet services provision, at present, an ISP has right to collect ’clicktrails’ data and hold log files of user Internet usage for the purposes of system maintenance and troubleshooting. Individual ISP also has own policy on privacy, however the standard diverges and user privacy is sometimes not properly protected. 2.2

Present Anonymous Internet Services Solutions

Several anonymous Internet services technologies have been developed. They aim at hiding the user identity from the remote sites. For example, the anonymous web servers such as [3] fetches the requested objects on behalf of the users, so that the remote host receives the request apparently originated from the server. There are also technologies such as the Onion Routing [4] providing anonymous connection in which routing information is hidden. 2.3

Conditional Anonymous Internet Access Services

In order to prevent the abuse of the data in log files, users should remain anonymous to the ISP during Internet object requests. This can be achieved by using cryptographic methods. In Section three of this paper, we will present a conditional anonymous Internet access protocol that have the following features: – User is anonymous to the ISP during Internet access. – The ISP has no way to relate a requested object to its requester even if it is fetched via the ISP’s proxy. – The anonymity is conditional, the user identity is revealed when any misbehavior is detected. – This protocol is transparent to other applications; and it is interoperable among different ISP’s. Here we assume the employment of caller-ID blocking so that the ISP cannot trace the user identity from the phone number.

On Privacy Issues of Internet Access Services via Proxy Servers

3

185

The Protocol

We developed our protocol motivated by the E-Cash protocol proposed in [2]. In our system, the user login with a pass (x, f (x)1/3

(mod n))

in which the first term is the pseudonym of the user and the second term is the ISP’s public key signature [5]. Here n is a published composite and only the ISP knows its factors, f (.) is a one-way function known by both the user and the ISP and x is the pseudonym chosen by the user. We firstly introduce a simpler version of the protocol, in which anonymous Internet connection without user identity recovery is achieved. In later section, we will discuss how the protocol is modified so that the user’s identity can be revealed in case of any misbehavior occurrence. 3.1

ISP Issues a new Pass to Alice Using Blind Signature [6] Scheme

To open a new account, Alice generates x and r, where x is a pseudonym which she will use to access the Internet services and r is a blinding factor. These numbers only known by Alice. She presents the following token: T = r3 · f (x)

(mod n)

to the ISP. Upon receiving T and having verified on Alice’s identity, the ISP signs on T by calculating the third root of T modulo n and returns T 1/3 (mod n), i.e. r · f (x)1/3 (mod n), to Alice. It is assumed that only the server has the knowledge to compute the third root modulo n [5]. Alice then extracts f (x)1/3 (mod n) from the returned token by dividing T 1/3 (mod n) with r and form her pass: pass = (x, f (x)1/3

(mod n)).

This pass is saved at Alice’s side. She logins with this anonymous pass instead of her login name from now on. The server has no way to relate Alice to her pseudonym x because it cannot see the value of x when it signs on the T. 3.2

Account Operations

An account for x is created, where x is the pseudonym of Alice. When Alice login, she presents the pass pass instead of using her own username and password. Authentication is done by verifying the value of f (x)1/3 (mod n). from pass. All other account operations are similar to the existing system. Since the server has no knowledge on the identity of x, anonymous Internet service provision is achieved.

186

4

Y.-Y. Chan

Modified Version with Key Escrow on User Identity

In Section 3 we have presented the simpler version of our protocol. In this section, we modify on it so that the following desirable additional properties can be achieved: – Alice is the only legitimate user of the pass. – Alice’s identity will be revealed when necessary. The modification is based on the double spending prevention solution presented in [2]. The later property enables identity revocation in critical situations. In the modified version of the protocol, a trust third party (TTP) is involved. And a valid pass has the following format: (pseudonym, {pseudonym}ISP sign , {pseudonym}T T P sign ). Here we make the same assumption that only the ISP has the knowledge to compute the third root modulo n. 4.1

Getting a new Pass

Let f and g be some two-argument collision-free functions as described in [2]. And let u be a unique identifying number of Alice (e.g. the account number). Instead of producing a single blinding factor r as in the previous section, four independent sets of random numbers each consists of k elements, a, c, d and r are generated. In order to obtain the blind signature from the ISP, Alice forms and sends k Ti ’s in the following manner: Ti = ri3 · f (xi , yi )

(mod n)

where i = 1 to k xi = g(ai , ci ) and yi = g (ai XOR u, di ). Notice that at this stage, The ISP knows Alice’s identity, u. In order to verify the Ti ’s presented by Alice, the ISP undergoes the following steps: 1. It chooses randomly a set of k/2 integers, R = {ij }, where 1 ≤ ij ≤ k and 1 ≤ j ≤ k/2. 2. It asks Alice to show the values of ri , ai , ci and di for every i in R. 3. It compares the k/2 presented Ti ’s and see if it is can be derived from these ri , ai , ci , ci and u.

On Privacy Issues of Internet Access Services via Proxy Servers

187

After that, the ISP gives Alice Y

1/3

Ti

(mod n)

i6∈R

And Alice can easily extract the following component: Y

f (xi , yi )1/3

(mod n)

i6∈R

which is correspond to the ISP’s blind signature on the pseudonym, p=

Y

f (xi , yi )

(mod n).

i6∈R

Notice that the ISP has no way to relate u to p because it cannot see xi and yi for i 6∈R. Alice also needs to get the signature from the TTP. Before signing on p, the TTP verifies the validity of p and writes part of the information about Alice’s identity into the database. Notice that Alice is anonymous to the TTP and the information obtained by the TTP is not enough for it to compute Alice’s identity. To perform this task, the same set of k Ti ’s are presented to the TTP. The TTP then performs the following procedures: 1. It asks Alice to give the values of xi , (ai XOR u), and di for every i. 2. It verifies if the corresponding Ti ’s can be derived from the presented values. 3. If the verification succeeds, the TTP stores the values (ai XOR u) along with p into the database. The TTP then verifies and signs on the pseudonym p: 1. For every i ∈ R0 where R0 = {i ∈ Z : i 6∈R, 1 ≤ ij ≤ k}, it checks if the values of xi , (ai XOR u), and di match the corresponding Ti ’s involves in p. 2. It signs on the pseudonym using normal public-key signature schemes. Upon receiving the TTP’s signature, Alice can then form the pass: (pseudonym, {pseudonym}ISP sign , {pseudonym}T T P sign ). In the process of pass verification just mentioned above, the cryptographic method, zero-knowledge proof is employed. It enables one to prove his/her identity to the other party without revealing the identity. More details can be found in [7].

188

4.2

Y.-Y. Chan

Account Operations

Account operations can be performed as usual. However, there are some differences in pass verification. The verification of a pass includes three procedures, namely the verifications of the ISP signatures and that of the TTP signatures, and also the process to ensure Alice (who is anonymous to the ISP) is indeed a valid holder of the pass. The first two processes can be performed directly using the public-key signature verification schemes. While the last part is done by the following: 1. The ISP generate a random binary vector Z = (z1 , z2 , ..., zk/2 ) where the element zi correspond to the ith number in the set R0 . 2. Alice responds according to the following rule: – when zi = 1, Alice send the ISP ai , ci , and yi . – when zi = 0, Alice send the ISP xi , and yi . 3. From the received values, the ISP can check if the corresponding Ti ’s can satisfy the pass. 4.3

Identity Revocation

In this protocol, a user remains anonymous so long as he/she does not misbehave. In this way, a limited anonymity is provided so that user privacy cannot be abused. This is done by the cryptographic method of secret splitting; in which a piece of secret is divided among two or more parties and each party alone does not have knowledge about the secret [8]. When misbehavior of the holder of p is detected or in case of any appeals, the court asks the ISP to presents the pass p along with ai for i ∈ R0 ; which it obtains during pass verification process. The court also gathers the corresponding (ai XOR u) for j ∈ S where S = R ∪ R0 from the TTP. Notice that S ∪ R0 6= {∅} and let e be an element in S ∪ R0 . The user identity u is revealed as: u = ae XOR (ae XOR u).

5

Security Analysis

This section analyzes on the strength of our protocol in resistance of different potential threats. 5.1

Anonymity

Alice remains anonymous to the ISP. This is because during the stage of pass issuing, Alice prepares k candidates of Ti ’s and the ISP only random challenge on k/2 of them. The other k/2 values which are used to form the pass are never seen by the ISP. During the authentication process, the ISP only random challenge on the k/2 unseen values. Therefore the ISP cannot relate the identity of Alice to the pass that she possesses.

On Privacy Issues of Internet Access Services via Proxy Servers

5.2

189

Masquerade

During the pass issuing stage, Alice is not anonymous and the ISP should make sure Alice’s identity before signing on the pass. This can be done by employing a digital certificate scheme; in which one’s identity is proved by a recognized digital certificate. In this way, the identity of the pass receiver can be ensured. 5.3

Alice Cheats

Since the ISP views only half of the k candidates of ri , ai , ci and di , where i ∈ R, therefore in the pass issuing process Alice may have chance to cheat. She does this by not using a valid u in the calculation of those k/2 Ti ’s which are not viewed by the ISP. However her chance of successful cheating decrease exponentially with the value of k. For example, when k equals 16, the chance for the ISP choosing none of the Alice’s cheated Ti ’s is 1/28 = 0.0039. When k increases to 32 the chance further decreases to 1/216 = 1.526 × 10−5 . 5.4

Stolen Pass

Suppose Alice’s pass is stolen by Carol during the pass issuing stage, this will not bring any lost to Alice because Carol does not know the secrets that Alice is holding. That is, Carol does not know ai , ci and yi for every i ∈ R0 which involve in the random challenge process during future logins. Therefore cannot use the pass. Suppose Carol steals the pass at later stages so that she also steals the numbers ai , ci and yi for some i ∈ R0 . In this case, however, she cannot use the pass until she obtains ai , ci and yi for every i ∈ R0 . This is because different elements in a, c and y are challenged randomly each time so Carol can only obtain some of them each time. When Carol has waited long enough to collect ai , ci and yi for every i ∈ R0 , Alice may has already changed her pass.

6

Efficiency

Compare with the non-anonymous Internet access scheme, our secure anonymous Internet access protocol may require more computational power. In this section we analyze on the computational effort involved. 6.1

Random Number Generation

During the initial stage where the pass is issued, a total number of 4k random integers need to be generated. Where k is suitable and large enough to prevent cheat from any potential parties, as explained in Section 5.3. For example, if k = 32, then 128 random numbers are generated. The number-of-bit of these random numbers are arbitrary. For example, when 32-bit binary numbers are used, the possible variation for the values of

190

Y.-Y. Chan

ri , ai , ci , di equals 232 = 4294967296. When 64-bit binary number is used instead, the number of possible variations of these values is increased to 264 = 18446744073709551616. The higher the number-of-bit, the more secure but slower of the system is. 6.2

Signing on the Pass.

Blind signature by the ISP. When the ISP makes a blind signature on Alice’s pass, it need to verify on the pass using cut-and-choose method. This involves the verification on the k/2 presented Ti ’s; and each of the verification involves 3 hashes. The ISP also need to verify Alice’s identity and this involves one publickey certificate verification. Therefore the ISP needs to undergo 3k/2 hashes, one certificate verification and 1 public-key signature when it signs on a pass. Signature by the TTP. For the TTP, two procedures are involved in the signing process. Firstly it verifies the xi , (ai XOR u), and di for every i. This involves 2k hashes. Secondly checks if the k/2 Ti ’s involves in the pass are valid. This requires another k hashes. Therefore the TTP needs to undergo 3k hashes and 1 public-key signature when it sign on a pass. 6.3

Pass Validation

When a user login, the ISP undergoes random challenge and checks if the user is a legitimate holder of the pass. This involves a generation of a k/2-bit random binary number and 2z hashes, where z is the number of 1’s in the binary number and z ∈ k/2. 6.4

Identity Recovery

When the user misbehaves and his/her identity is going to be revealed; this simply requires one searching and one XOR calculation. To conclude, most operations undergone in our protocol are hashes, and they are light in terms of computational power [9].

7

Conclusion

In this paper we have pointed out the privacy problems involved in Internet access. We also proposed a cryptographic solution to the problem; which is motivated by the electronic cash protocols. Our protocol supports anonymous user login to a proxy server so that the Internet usage habit of a user cannot be traced and analyzed. However the user cannot abuse his/her anonymity because our protocol enable a misbehaved user’s identity to be revealed. This is achieved by a key escrow method in which a trusted third party keeps half of the secret about the user’s identity. In addition, our protocol resides on the application layer and does not require changes in other layers during implementation. With suitable legislation, user privacy of Internet access can be properly protected.

On Privacy Issues of Internet Access Services via Proxy Servers

8

191

Acknowledgement

The author would like to thank Professor Victor K.W.Wei for his supervision on the research.

References 1. Hong Kong SAR of the People Republic of China: Personal Data (Privacy) Ordinance, Version date 20 Dec 1996 2. David Chaum, Amos Fiat, Moni Naor: Untraceable Electronic Cash. Advances in Cryptology - Proceedings of CRYPTO’88 (1988) 3. The Anonymizer. [web page] (1999). http://www.anonymizer.com/3.0/index.shtml. [Accessed 6 Sept 1999] 4. Reed M.G., Syverson P.F., Goldschlag D.M.: Proxies for anonymous routing. Proceedings, 12th Annual Computer Security Applications Conference (1996) 95-104 5. Rivest, R.L., A. Shamir, and L. Adleman: A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, v. 21, n. 2, (1978) 120-126 6. David Chaum: Blind Signature for Untraceable Payment. Advances in Cryptology - Proceedings of CRYPTO’82, Plenum Press, (1983) 199-203 7. Bruce Schneier: Applied Cryptography 2nd Edition, (1996) 102-104 8. H. Feistel: Cryptographic Coding for Data-Bank Privacy, RC 2827, Yorktown Heights, NY. IBM Research (1970) 9. D. O’Mahony, M. Peirce, H. Tewari: Electronic Payment Systems (1997) 213

Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2) Bruce Schneier1 , Mudge2 , and David Wagner3 1 Counterpane Systems [email protected] 2 L0pht Heavy Industries [email protected] 3 UC Berkeley [email protected]

Abstract. The Point-to-Point Tunneling Protocol (PPTP) is used to secure PPP connections over TCP/IP link. In response to [SM98], Microsoft released extensions to the PPTP authentication mechanism (MSCHAP), called MS-CHAPv2. We present an overview of the changes in the authentication and encryption-key generation portions of MSCHAPv2, and assess the improvements and remaining weaknesses in Microsoft’s PPTP implementation.

1

Introduction

The Point-to-Point Tunneling Protocol (PPTP) [HP+97] is a protocol that allows Point-to-Point Protocol (PPP) connections [Sim94] to be tunneled through an IP network, creating a Virtual Private Network (VPN). Microsoft has implemented its own algorithms and protocols to support PPTP. This implementation of PPTP, called Microsoft PPTP, is used extensively in commercial VPN products precisely because it is already a part of the Microsoft Windows 95, 98, and NT operating systems. The authentication protocol in Microsoft PPTP is the Microsoft Challenge / Reply Handshake Protocol (MS-CHAP) [ZC98]; the encryption protocol is Microsoft Point to Point Encryption (MPPE) [PZ98]. After Microsoft’s PPTP was cryptanalyzed [SM98] and significant weaknesses were publicized, Microsoft upgraded their protocols [Zor98a,Zor98b,Zor99]. The new version is called MS-CHAP version 2 (MS-CHAPv2); the older version has been renamed as MS-CHAP version 1 (MS-CHAPv1). MS-CHAPv2 is available as an upgrade for Microsoft Windows 95, Windows 98, and Windows NT 4.0 (DUN 1.3) [Mic98a,Mic98b]. Even though this upgrade is available, we believe that most implementation of PPTP use MS-CHAPv1. This paper examines MS-CHAPv2 and discusses how well it addresses the security weaknesses outlined in [SM98]. R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 192–203, 1999. c Springer-Verlag Berlin Heidelberg 1999

Cryptanalysis of Microsoft’s PPTP Authentication Extensions

193

The most significant changes from MS-CHAPv1 to MS-CHAPv2 are: – The weaker LAN Manager hash is no longer sent along with the stronger Windows NT hash. This is to prevent automatic password crackers like L0phtcrack [L99] from first breaking the weaker LAN Manager hash and then using that information to break the stronger NT hash [L97]. – An authentication scheme for the server has been introduced. This is to prevent malicious servers from masquerading as legitimate servers. – The change password packets from MS-CHAPv1 have been replaced by a single change password packet in MS-CHAPv2. This is to prevent the active attack of spoofing MS-CHAP failure packets. – MPPE uses unique keys in each direction. This is to prevent the trivial cryptanalytic attack of XORing the text stream in each direction to remove the effects of the encryption [SM98]. These changes do correct the major security weaknesses of the original protocol: the inclusion of the LAN Manager hash function and the use of the same OFB encryption key multiple times. However, many security problems are still unaddressed: e.g., how the client protects itself, the fact that the encryption key has the same entropy as the user’s password, and the fact that enough data is passed on the wire to allow attackers to mount crypt-and-compare attacks. This being said, Microsoft obviously took this opportunity to not only fix some of the major cryptographic weaknesses in their implementation of PPTP, but also to improve the quality of their code. The new version is much more robust against denial-of-service style attacks and no longer leaks information regarding the number of active VPN sessions.

2

MS-CHAP, Versions 1 and 2

The MS-CHAPv1 challenge/response mechanism was described in [SM98]. It consists of the following steps: 1. Client requests a login challenge from the Server. 2. The Server sends back an 8-byte random challenge. 3. The Client uses the LAN Manager hash of its password to derive three DES keys. Each of these keys is used to encrypt the challenge. All three encrypted blocks are concatenated into a 24-byte reply. The Client creates a second 24byte reply using the Windows NT hash and the same procedure. 4. The server uses the hashes of the Client’s password, stored in a database, to decrypt the replies. If the decrypted blocks match the challenge, the authentication completes and sends a “success” packet back to the client. This exchange has been modified in MS-CHAPv2. The following is the revised protocol: 1. Client requests a login challenge from the Server. 2. The Server sends back a 16-byte random challenge.

194

B. Schneier, Mudge, and D. Wagner

3a. The Client generates a random 16-byte number, called the “Peer Authenticator Challenge.” 3b. The Client generates an 8-byte challenge by hashing the 16-byte challenge received in step (2), the 16-byte Peer Authenticator Challenge generated in step (3a), and the Client’s username. (See Section 3 for details.) 3c. The Client creates a 24-byte reply, using the Windows NT hash function and the 8-byte challenge generated in step (3b). This process is identical to MS-CHAPv1. 3d. The Client sends the Server the results of steps (3a) and (3c). 4a. The Server uses the hashes of the Client’s password, stored in a database, to decrypt the replies. If the decrypted blocks match the challenge, the Client is authenticated. 4b. The Server uses the 16-byte Peer Authenticator Challenge from the client, as well as the Client’s hashed password, to create a 20-byte “Authenticator Response.” (See Section 5 for details.) 5. The Client also computes the Authenticator Response. If the computed response matches the received response, the Server is authenticated. A general description of the changes between MS-CHAPv1 and MS-CHAPv2 is given in Figure 1. This protocol works, and eliminates the most serious weaknMS-CHAP Version 1 MS-CHAP Version 2 Negotiates CHAP with an algorithm va- Negotiates CHAP with an algorithm value of 0x80. lue of 0x81. Server sends an 8-byte challenge value. Server sends a 16-byte value to be used by the client in creating an 8-byte challenge value. Client sends 24-byte LANMAN and 24- Client sends 16-byte peer challenge that byte NT response to 8-byte challenge. was used in creating the hidden 8-byte challenge, and the 24-byte NT response. Server sends a response stating SUC- Server sends a response stating SUCCESS or FAILURE. CESS or FAILURE and piggybacks an Authenticator Response to the 16-byte peer challenge. Client decides to continue or end based Client decides to continue or end baupon the SUCCESS or FAILURE res- sed upon the SUCCESS or FAILURE ponse above. response above. In addition, the Client checks the validity of the Authenticator Response and disconnects if it is not the expected value. Fig. 1. Some basic differences between MSCHAPv1 and MSCHAPv2 authentication

esses that plagued MS-CHAPv1. In MS-CHAPv1, two parallel hash values were sent from the Client to the Server: the LAN Manager hash and the Windows

Cryptanalysis of Microsoft’s PPTP Authentication Extensions

195

NT hash. These were two different hashes of the same User password. The LAN Manager hash is a much weaker hash function, and password-cracker programs such as L0phtcrack were able to break the LAN Manager hash and then use that information to break the Windows NT hash [L97]. By eliminating the LAN Manager hash in MS-CHAPv2, Microsoft has made this divide-and-conquer attack impossible. Still, the security of this protocol is based on the password used, and L0phtcrack can still break weak passwords using a dictionary attack [L99]. As we will discuss later, multiple layers of hashing are used in the different steps of MS-CHAPv2. While this hashing serves to obscure some of the values, it is unclear what the cryptographic significance of them are. All they seem to do is to slow down the execution of the protocol. We also have concerns over the amount of control the client has in the influence of the ultimate 8-byte challenge that is used, though we have not yet been able to come up with a viable attack to exploit this. Certainly it opens the possibility of subliminal channels, which can be exploited in other contexts.

3

MS-CHAPv2: Deriving the 8-byte Challenge for the 24-byte Response

In MS-CHAPv1, the Server sends the Client an 8-byte random challenge. This challenge is used, together with the Client’s password and a hash function, to create a pair of 24-byte responses. In MS-CHAPv2, the Server sends the Client a 16-byte challenge. This challenge is not used by the Client directly; the Client derives an 8-byte value from this 16-byte challenge. The derivation process is as follows: 1. The Client creates a 16-byte random number, called the Peer Authenticator Challenge. 2. The Client concatenates the Peer Authenticator Challenge with the 16-byte challenge received from the server and the Client’s username. 3. The client hashes the result with SHA-1 [NIST93]. 4. The first eight bytes of the hash become the 8-byte challenge. It is these 8 bytes that the Client will use to encrypt the 16-byte local password hash (using the Windows NT hash function) to obtain the 24-byte response, which the Client will send to the server. This method is identical to MS-CHAPv1, and has been described in [SM98]. 3.1

Analysis

It is unclear to us why this protocol is so complicated. At first glance, it seems reasonable that the Client not use the challenge from the Server directly, since it is known to an eavesdropper. But instead of deriving a new challenge from some secret information—the password hash, for example—the Client uses a unique random number that is sent to the Server later in the protocol. There is no reason why the Client cannot use the Server’s challenge directly and not use the Peer Authenticator Challenge at all.

196

4

B. Schneier, Mudge, and D. Wagner

MS-CHAPv2: Deriving the 24-byte Response

Both MS-CHAPv1 and MS-CHAPv2 use the same procedure to derive a 24-byte response from the 8-byte challenge and the 16-byte NT password hash: 1. The 16-byte NT hash is padded to 21 bytes by appending five zero bytes. 2. Let X, Y, Z be the three consecutive 7-byte blocks of this 21-byte value, and let C be the 8-byte challenge. The 24-byte response R is calculated as R = hDESX (C), DESY (C), DESZ (C)i. 4.1

Analysis

This complicated procedure creates a serious weakness in the MS-CHAP protocols: it allows the attacker to speed up dictionary keysearch by a factor of 216 , which is a pretty devastating effect given the relatively low entropy of most user passwords. Suppose that we eavesdrop on a MS-CHAP connection. The response R is exposed in the clear, and the challenge C may be derived easily from public information. We will attempt to recover the password, using the knowledge that many passwords are closely derived from dictionary words or otherwise readily guessable. Note first that the value of Z can be easily recovered: since there are only 216 possibilities for Z, and we have a known plaintext-ciphertext pair C, DESZ (C) for Z, we may try each of the possibilities for Z in turn with a simple trial encryption1 . This discloses the last two bytes of the NT hash of the password. We will use this observation to speed up dictionary search. In a one-time precomputation, we hash each of our guesses at the password (perhaps as minor variations on a list of words in a dictionary). We sort the results by the last two bytes of their hash and burn this on a CD-ROM (or a small hard drive). Then, when we see a MS-CHAP exchange, we may recover the last two bytes of the NT hash (using the method outlined above) and examine all the corresponding entries on the CD-ROM. This gives us a list of plausible passwords which have the right value for the last two bytes of their NT hash; then we can try each of those possibilities by brute force. Suppose a naive dictionary attack would search N passwords. In our attack, we try only the passwords which have the right value for the last two bytes of their NT hash, so we expect to try only about N/216 passwords. This implies that the optimized attack runs about 216 times faster than a standard dictionary attack, if we can afford the space to store a precomputed list of possible passwords. This attack is applicable to both MS-CHAPv1 and MS-CHAPv2. However, the weakness is much more important for MS-CHAPv2, because for MS-CHAPv1 it is easier to attack the LanManager hash than to attack the NT hash. This is a serious weakness which could have been easily avoided merely by using a standard cryptographic hashing primitive. For instance, merely generating the response as R = SHA-1(NT hash, C) would be enough to prevent this attack. 1

This has been independently observed by B. Rosenburg.

Cryptanalysis of Microsoft’s PPTP Authentication Extensions

197

Note also that the MS-CHAP response generation algorithm is also a weak link, even when passwords contain adequate entropy. It is clear that the NT hash can be recovered with just two DES exhaustive keysearches (about 256 trial DES decryptions on average), or in just 9 days using a single EFF DES Cracker machine [Gil98]. Once the NT hash is recovered, all encrypted sessions can be read and the authentication scheme can be cracked with no effort. This shows that, even when using 128-bit RC4 keys, the MS-CHAP protocol provides at most the equivalent of 57-bit security2 . This weakness could also have been avoided by the simple change suggested above, R = SHA-1(NT hash, C). It is not clear to us why the MS-CHAPv2 designers chose such a complicated and insecure algorithm for generating 24-byte responses, when a simpler and more secure alternative was available.

5

MS-CHAPv2: Deriving the 20-byte Authenticator Response

In MS-CHAPv2, the Server sends the Client a 20-byte Authenticator Response. The Client calculates the same value, and then compares it with the value received from the Server in order to complete the mutual authentication process. This value is created as follows: 1. The Server (or the Client) hashes the 16-byte NT password hash with [Riv91] to get password-hash-hash. (The Server stores the client’s password hashed with MD4; this is the NT password hash value.) 2. The Server then concatenates the password-hash-hash, the 24-byte NT response, and the literal string “Magic server to client constant”, and then hashes the result with SHA. 3. The Server concatenates the 20-byte SHA output from step (2), the initial 8byte generated challenge (see Section 3) and the literal string “Pad to make it do more than one iteration”, and then hashes the result with SHA. The resulting 20 bytes are the mutual authenticator response. 5.1

Analysis

Again, this process is much more complicated than required. There is no reason to use SHA twice; a single hashing has the same security properties.

6

Analysis of MS-CHAPv2

We do not know why Microsoft chose such a complicated protocol, since this is not stronger than the following: 1. The Server sends the Client an 8-byte challenge. 2

This has been independently observed by P. Holzer.

198

B. Schneier, Mudge, and D. Wagner

2. The Client encrypts the 16-byte local password hash with an 8-byte challenge and sends the Server the 24-byte response, an 8-byte challenge of its own, and the username. 3. The Server sends a pass/fail packet with a 24-byte response to the Client’s challenge, which is the user’s password-hash-hash encrypted with the Client’s 8-byte challenge. The downside to the MS-CHAPv2 protocol is that an eavesdropper can obtain two copies of the same plaintext, encrypted with two different keys. However, in the current model, watching the network for any length of time will still give you multiple copies of a user challenge/response as the user logs in and out, which will be encrypted with different keys. As it stands, a passive listener is still able to get the 8-byte challenge and the 24-byte response from the information sent. The popular hacker tool L0phtcrack [L97], which breaks Windows NT passwords, works with this data as input. This task was much easier with MS-CHAPv1, since the weaker LAN Manager hash was sent alongside the stronger Windows NT hash; L0phtcrack first broke the former and then used that information to break the latter [L99]. L0phtcrack can still break most common passwords from the Windows NT hash alone [L97]. And this still does not solve the problem of using the user’s hash for MPPE keying, PPTP authentication, etc. without negotiating, at least, machine public key/private key methods of exchanging such an important key. 6.1

Version Rollback Attacks

Since Microsoft has attempted to retain some backwards compatibility with MS-CHAPv1, it is possible for an attacker to mount a “version rollback attack” against MS-CHAP. In this attack, the attacker convinces both the Client and the Server not to negotiate the more secure MS-CHAPv2 protocol, but to use the less secure MS-CHAPv1 protocol. In its documentation, Microsoft claims that the operating systems will try to negotiate MS-CHAPv2 first, and only drop back to MS-CHAPv1 if the first negotiation fails [Mic99]. Additionally, it is possible to set the Server to require MS-CHAPv2. We find this scenario implausible for two reasons. One, the software switches to turn off backwards compatibility are registry settings, and can be difficult to find. And two, since older versions of Windows cannot support MS-CHAPv2, backwards compatibility must be turned on if there are any legacy users on the network. We conclude that version rollback attacks are a significant threat.

7

Changes to MPPE

The original encryption mechanism in Microsoft’s Point to Point Encryption protocol (MPPE) used the same encryption keys in each direction (Client to Server, and Server to Client). Since the bulk data encryption routine is the RC4

Cryptanalysis of Microsoft’s PPTP Authentication Extensions

199

stream cipher [Sch96], this created a cryptographic attack by XORing the two streams against each other and performing standard cryptanalysis against the result. In the more recent version, the MPPE keys are derived from MS-CHAPv2 credentials and a unique key is used in each direction. The keys for each direction are still derived from the same value (the Client’s NT password hash), but differently depending on the direction. 7.1

Deriving MPPE Keys from MS-CHAPv2 Credentials

MPPE keys can be either 40 bits or 128 bits, and they can be derived from either MS-CHAPv1 credentials or MS-CHAPv2 credentials. The original derivation protocol (from MS-CHAPv1) was described in [SM98]. Briefly, the password hash is hashed again using SHA, and then truncated. For a 40-bit key, the SHA hash is truncated to 64 bits, and then the high-order 24 bits are set to 0xD1269E. For a 128-bit key, the SHA hash is truncated to 128 bits. This key is used to encrypt traffic from the Client to the Server and traffic from the Server to the Client, opening a major security vulnerability. This has been corrected in MSCHAPv2. Deriving MPPE keys from MS-CHAPv2 credentials works as follows: 1. Hash the 16-byte NT password hash, the 24-byte response from the MSCHAPv2 exchange, and a 27-byte constant (the string “This is the MPPE Master Key”) with SHA. Truncate to get a 16-byte master-master key. 2. Using a deterministic process, convert the master-master key to a pair of session keys. For 40-bit session keys, this is done as follows: 1. Hash the master-master key, 40 bytes of 0x00, an 84-byte constant and 40 bytes of 0xF2 with SHA. Truncate to get an 8-byte output. 2. Set the high-order 24 bits of 0xD1269E, resulting in a 40-bit key. The magic constants are different, depending on whether the key is used to encrypt traffic from the Client to the Server, or from the Server to the Client. For 128-bit session keys, the process is as follows: 1. Hash the master-master key, 40 bytes of 0x00, an 84-byte constant (magic constant 2 or 3), and 40 bytes of 0xF2 with SHA. Truncate to get a 16-byte output. 7.2

Analysis

This modification means that unique keys are used in each direction, but does not solve the serious problem of weak keys. The keys are still a function of the password, and hence contain no more entropy than the password. Even though the RC4 algorithm may theoretically have 128-bits of entropy, the actual passwords used for key generation have much less. This having been said, using different keys in each direction is still a major improvement in the protocol.

200

7.3

B. Schneier, Mudge, and D. Wagner

Trapdoors in the Magic Constants?

We are very concerned with the magic constants embedded in the key derivation algorithm for export-weakened keys. The protocol weakens RC4 keys to 40 bits by fixing the high bits of the 64-bit RC4 key to 0xD1269E. But this seems dangerous. It is known that, if an adversary is allowed to choose the high bits of the RC4 key, the adversary can force you into a weak key class for RC4 [Roo95,Wag95]. Therefore, if the MS-CHAP designers—or the NSA export-reviewer folks—wanted to embed a trapdoor in the protocol, they could exploit the presence of magic constants to weaken RC4. We do not know whether keys prefixed with 0xD1269E are unusually weak, but in our preliminary statistical tests we have found some suspicious properties of such keys that leaves us with some cause for concern. To give two examples: – Empirical measurements show that the first few bytes of output are biased, for keys which start with 0xD1269E. The first and second keystream bytes take on the values 0x09 and 0x00 with probabilities 0.0054 and 0.0060, respectively. This is noticeably higher than the 1/256 = 0.0039 probability you’d expect from good cipher. – The key schedule mixes some entries in the state table poorly, for this class of keys. For instance, S[1] = 0xF8 holds with probability 0.38 ≈ 1/e, and S[2] = 0x98 holds with a similar probability. These statistical properties are worrisome. Because no information is given on how the value 0xD1269E was chosen, one has to worry that it could well be a “trapdoor choice” which forces all 40-bit keys into some weak key class for RC4. We invite the MS-CHAP designers to openly disclose how all magic constants were chosen and to provide concrete assurances that those magic values don’t create any hidden trapdoors. In the meantime, we leave it as an open question to ascertain whether RC4 is secure when used with the fixed key-prefix 0xD1269E.

8

Attack on Export-Weakened Key Derivation

In this section we present a very serious attack on the way that exportable 40-bit session keys are generated. This weakness is also present in MS-CHAPv1 as well as MS-CHAPv2, but it has not been discovered until now. The end result is that the so-called “40-bit keys” really only have an effective strength of about 26 bits. As a result, the export-weakened protocol can be cracked in near-realtime with only a single computer3 . 3

Today’s computers seem to be able to try 216 –217 keys/second, which suggests that each key can be cracked in something like a quarter of an hour. (In lieu of an implementation, these estimates will necessarily be very rough.) With a small cluster of computers, the cracking performance can be greatly increased.

Cryptanalysis of Microsoft’s PPTP Authentication Extensions

201

We recall that the key derivation process appends 40 secret bits (generated in some way which is irrelevant to our attack) to the fixed value 0xD1269E. The resulting 64-bit session key is to RC4-encrypt the transmitted data. The problem is that this process introduces no per-session salt (compare to, e.g., SSL), and thus can be broken with a time-space tradeoff attack. For the remainder of this section, we assume that we can obtain a short segment of known plaintext (40 bits should suffice) at some predictable location. The known plaintext need not even occur at consecutive bit locations; the only requirement is that the bit positions be predictable in advance. This seems to be a very plausible assumption, when one considers the quantity of known headers and other predictable data that is encrypted. Let us assume for simplicity of description that this known plaintext occurs at the start of the keystream. We will attack this protocol with a time-space tradeoff. The cost of a lengthy precomputation is amortized over many sessions so that the incremental cost of breaking each additional session key is reduced to a very low value. A naive attacker might consider building a lookup table with 240 entries, listing for each possible 40-bit key the value of the first 40 bits of keystream that results. This requires a 240 precomputation, but then each subsequent session key can be broken extremely quickly (with just a single table lookup). However, in practice this attack is probably not very practical because it requires 240 space. A time-space tradeoff allows us to reduce the space requirements of the naive attack by trading off memory for additional computation. Consider Hellman’s time-space tradeoff [Hel80]. For a n-bit key, Hellman’s tradeoff requires a 2n precomputation and 22n/3 space, and then every subsequent session key can be broken with just 22n/3 work. (Other tradeoffs are also possible.) For MS-CHAP’s 40-bit keys, n = 40, and 2n/3 ≈ 26, so you get an attack that breaks each session key with approximately 226 work. The attack requires a 240 precomputation and 226 space, but these requirements are easily met. This means that the export-weakened versions of MS-CHAP offer an effective keylength of only about 26 bits or so, which is much less than the claimed 40 bits of strength. This is a deadly weakness.

9

Conclusions

Microsoft has improved PPTP to correct the major security weaknesses described in [SM98]. However, the fundamental weakness of the authentication and encryption protocol is that it is only as secure as the password chosen by the user. As computers get faster and distributed attacks against password files become more feasible, the list of bad passwords—dictionary words, words with random capitalization, words with the addition of numbers, words with numbers replacing letters, reversed words, acronyms, words with the addition of punctuation—becomes larger. Since authentication and key-exchange protocols which do not allow passive dictionary attacks against the user’s password are possible—Encrypted Key Exchange [BM92,BM94] and its variants

202

B. Schneier, Mudge, and D. Wagner

[Jab96,Jab97,Wu98], IPSec—it seems imprudent for Microsoft to continue to rely on the security of passwords. Our hope is that PPTP continues to see a decline in use as IPSec becomes more prevalent.

References BM92. BM94. Gil98. HP+97. Hel80. Jab96. Jab97.

L97. L99. Mic96a. Mic96b. Mic98a. Mic98b. Mic99. NIST93. PZ98.

S.M. Bellovin and M. Merritt, “Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks,” Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992, pp. 72–84. S.M. Bellovin and M. Merritt, “Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise,” AT&T Bell Laboratories, 1994. J. Gilmore, Ed., Cracking DES. The Electronic Frontier Foundation, San Francisco, CA, O’Reilly and Associates, 1998. K. Hamzeh, G.S. Pall, W. Verthein, J. Taarud, and W.A. Little, “Point-to-Point Tunneling Protocol,” Internet Draft, IETF, Jul 1997. http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-10.txt. M.E. Hellman, “A cryptanalytic time-memory trade-off,” IEEE Transactions on Information Theory, vol.IT-26, no.4, July 1980, p.401–406. D. Jablon, “Strong Password-Only Authenticated Key Exchange,” ACM Computer Communications Review, Oct 96, pp. 5–26. D. Jablon, “Extended Password Key Exchange Protocols Immune to Dictionary Attacks,” Proceedings of the Sixth Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, IEEE Computer Society, 1997, pp. 248–255. L0pht Heavy Industries, Inc., “A L0phtCrack Technical Rant,” Jul 1997. http://www.l0pht.com/l0phtcrack/rant.html. L0pht Heavy Industries, Inc, L0phtcrack, 1999, http://www.l0pht.com/ l0phtcrack/. Microsoft Corporation, Advanced Windows NT Concepts, New Riders Publishing, 1996. Relevant chapter at http://www.microsoft.com/ communications/nrpptp.htm. Microsoft Corporation, “Point-to-Point Tunneling Protocol (PPTP) Frequently Asked Questions,” Jul 1996. Microsoft Corporation, “Frequently Asked Questions about Microsoft VPN Security,” Dec 1998, http://www.microsoft.com/NTServer/commserv/ deployment/moreinfo/VPNSec FAQ.asp Microsoft Corporation, “Microsoft Windows 95 Dial-Up Networking 1.3 Upgrade Release Notes,” 1998, http://support.microsoft.com/ support/kb/articles/q154/0/91.asp Microsoft, Corporation, “Windows 98 Dial-Up Networking Security Upgrade Release Notes,” Feb 1999, http://support.microsoft.com/ support/kb/articles/Q189/7/71.asp. National Institute of Standards and Technology, “Secure Hash Standard,” U.S. Department of Commerce, May 1993. G.S. Pall and G. Zorn, “Microsoft Point-to-Point Encryption (MPPE) Protocol,” Network Working Group, Internet Draft, IETF, Mar 1998. http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-03.txt.

Cryptanalysis of Microsoft’s PPTP Authentication Extensions Riv91.

203

R. Rivest, “The MD4 Message Digest Algorithm,” Advances in Cryptology— CRYPTO’90 Proceedings, Springer-Verlag, 1991, pp. 303311. Roo95. A. Roos, “Weak Keys in RC4,” sci.crypt post, 22 Sep 1995. Sim94. W. Simpson, “The Point-to-Point Protocol (PPP),” Network Working Group, STD 51, RFC 1661, Jul 1994. ftp://ftp.isi.edu/in-notes/rfc1661.txt. Sch96. B. Schneier, Applied Cryptography, 2nd Edition, John Wiley & Sons, 1996. SM98. B. Schneier and Mudge, “Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol (PPTP),” Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, pp. 132–141. http://www.counterpane.com/pptp.html. Wag95. D. Wagner, “Re: Weak Keys in RC4,” sci.crypt post, 25 Sep 1995. http://www.cs.berkeley.edu/ daw/my-posts/my-rc4-weak-keys. Wu98. T. Wu, “The Secure Remote Password Protocol,” Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, Mar 1998, pp. 97–111. ZC98. G. Zorn and S. Cobb, “Microsoft PPP CHAP Extensions,” Network Working Group Internet Draft, Mar 1998. http://www.ietf.org/internet-drafts/draftietf-pppext-mschap-00.txt. Zor98a. G. Zorn, “Deriving MPPE Keys from MS-CHAP V1 Credentials,” Network Working Group Internet Draft, Sep 1998. http://www.ietf.org/internetdrafts/draft-ietf-pppext-mschapv1-keys-00.txt. Zor98b. G. Zorn, “Deriving MPPE Keys from MS-CHAP V2 Credentials,” Network Working Group Internet Draft, Nov 1998. http://www.ietf.org/internetdrafts/draft-ietf-pppext-mschapv2-keys-02.txt. Zor99. G. Zorn, “Microsoft PPP CHAP Extensions, Version 2,” Network Working Group Internet Draft, Apr 1999. http://www.ietf.org/internet-drafts/draftietf-pppext-mschap-v2-03.txt.

Auto-recoverable Auto-certifiable Cryptosystems (A Survey) Adam Young1 and Moti Yung2 1

Currently: Columbia University 2 Currently: CertCo LLC

Abstract. In this paper we survey the recent work on Auto-Recoverable Auto-Certifiable Cryptosystems. This notion has been put forth to solve the “software key escrow” problem in an efficient manner within the context of a Pubic Key Infrastructure (PKI). This survey presents the exact specification of the problem which is based on what software key escrow can hope to achieve. The specification attempts to separate the truly difficult technical issues in the area from the ones that are only seemingly difficult. We then review the work in Eurocrypt ’98 and PKC ’99, which gives an efficient reduction to a software key escrow system from a certified public key system (PKI). Namely, we show how to construct an escrowed PKI for essentially the same cost and effort required for a regular PKI. More specifically, the schemes presented are as efficient for users to use as a PKI, do not require tamper-resistant hardware (i.e., they can be distributed in software to users), and the schemes are shadow public key resistant as defined in Crypto ’95 by Kilian and Leighton (namely, they do not allow the users to publish public keys other then the ones certified). The schemes enable the efficient verification of the fact that a given user’s private key is escrowed properly. They allow the safe and efficient recovery of keys (and plaintext messages) which is typical in emergency situations such as in the medical area, in secure file systems, and in criminal investigations. We comment that we do not advocate nor deal with the policy issues regarding the need of governments to control access to messages; our motivation is highly technical: in cases that escrow is required or needed we would like to minimize its effect on the overall PKI deployment. We then briefly mention forthcoming developments in the area which include further flexibility/compatibility requirements for auto-recoverable cryptosystems, as well as design of such systems which are based on traditional public key methods (RSA and discrete logs).

1

Introduction

We are currently at the point, due to the enormous surge of Internet use, where a large-scale Public Key Infrastructure (PKI) is about to be deployed. On the other hand, another set of requirements suggest that decryption keys should be R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 204–218, 1999. c Springer-Verlag Berlin Heidelberg 1999

Auto-recoverable Auto-certifiable Cryptosystems

205

escrowed. This is easily justifiable in world wide deployment of systems where medical records can be accessed, typically by the client, but only in an emergency using escrow mechanisms. Also, governments are interested in securing access to telephony systems for law enforcement (this last issue is politically controversial, but our treatment is only technical). Most if not all of the early proposed key escrow schemes suffer from at least one form of drawback or another (typically from inherent incompatibilities with software based regular PKIs). These include the need for “tamper-resistant” devices, e.g., Clipper and Capstone, added overhead of protocol interaction between users and the escrow authorities, the need for “trusted third parties” to generate cryptographic keys and be active in the user-to-user transactions, and requiring changes in protocols which are outside the cryptographic system. In fact, the problem of implementing an escrowed PKI efficiently is regarded as too difficult a problem to achieve by a number of researchers, cryptographers, and security experts [K-S]. In another paper [FY97], formal arguments are presented explaining why building key escrow on top of a public-key system is a non-trivial task (even when third parties are allowed to be present). The early attempts to present escrowed encryption, indeed, proposed systems much different than a regular PKI. Auto-Recoverable Auto-Certifiable cryptosystems attempt to solve the efficiency (and compatibility) problems that are posed to escrowed PKI’s, and do not claim to resolve the ongoing conflict between privacy advocates and those seeking access to escrowed keys. We remark that unlike recent escrow proposals which give the escrow authorities only access to some fraction of the escrowed information (e.g., as in [BGw97]), Auto-Recoverable Auto-Certifiable cryptosystems give the escrow authorities access to all encrypted information when authorized. However, the access does not have to be to a key, rather it can have very small granularity which enables access to an individual message. We believe that granular access [FY95] is more acceptable than partial access which implies further computational costs in recovering the message (the cost effectiveness is not justified from an engineering point of view and the delay of partial recovery may not be tolerable).

2

Initial Problem Specification

The following are specifications of software escrowed PKI as can be derived from existing documents, discussions in the cryptographic community, and approaches to systems development: 1. Software implementation: Each and every system component does not require tamper-proof hardware. 2. Software distribution: The software that users employ is public (and hence is easily distributed). 3. Key self-generation: Users generate their own private keys independently and efficiently. The private keys (or messages encrypted by these keys) are recoverable by the escrow authorities only.

206

A. Young and M. Yung

4. Escrow authorities minimal intervention: The escrow authorities act only at the system’s set-up, and when key recovery is needed. 5. PKI-compatible certification process: To certify a key, a user sends one message requesting certification to the Certification Authority (CA), as in a regular public key infrastructure. This message is created by an efficient procedure, performed independently by the user alone. 6. Certified keys are recoverable: A user’s public key is certified by a Certification Authority (CA) only if the corresponding private key is verified to be recoverable by the authorities. This verification is conducted solely from the message that forms the request for certification; the verification is successfull if and only if the key is recoverable with very high probability. 7. PKI-compatible certificates: A user’s key in the certificate should include the same information as in a regular public key. 8. Universal verifiability of recoverability: Upon request, a user can present the message that forms the request for certification to any party and this party can verify that the private key is recoverable by the authorities. 9. Efficient recovery: The key recovery procedure is efficient (it can preferably be done by distributed parties, e.g., using threshold cryptography [FD89] and verifiable secret sharing which have been developed in the 80’s). 10. PKI-compatible user system: The system is as easy for users as a public key cryptosystem, and can be implemented in software. Such a solution therefore constitutes a reduction of a PKI with a Certification Authority [Koh78] to an escrowed public key infrastructure with the same configuration. Since such a solution can be implemented securely in software, it can be implemented and distributed in source code form, thus making it as easy to distribute and use as a public key software package (e.g., PGP). 11. PKI-compatible software/architecture layers: From an infrastructure and systems integration perspective, these specifications differentiate between various independent layers. The first layer consists of the escrow authorities, who act only at the time the system is established and who act only when a private key needs to be recovered. The later action is performed without interfacing with users. The second layer is the public-key infrastructure, where users and CA’s generate certified keys whose corresponding private keys are private to the users. The third layer is the use of the certified public keys within communication and storage applications. In such a system the third layer is related to the second layer as in a regular public key infrastructure. 12. Communication Protocol Compatibility: The solution should not change headers and messages outside the PKI protocols; e.g., communicating parties use existing communication protocols. 13. Compliance assurance: In [FY95,FY97] Frankel and Yung note that an escrow encryption scheme can always be bypassed (hardware or software). This is due to under-encrypting, over-encrypting, etc. Thus, governments cannot hope to solve misbehaviors in general. What is important is the definition given in [FY95] which says that “as long as the parties employ the mechanisms provided for confidentiality by the system, the escrow capability

Auto-recoverable Auto-certifiable Cryptosystems

207

should be enabled”. In an Auto-Recoverable Auto-Certifiable system, the CA ties the certification of keys to assure that secret keys are escrowed. It seems that this is a proper choice of control since in order to bypass the system, users will have to use another system or use an unauthorized modification of the system. Also, not performing the ‘assurance of escrow’ by the CA at the infrastructure level may cause problems in system design, as pointed out in [FY97]. 14. Security: The public key is as secure as a key in a PKI against all parties ([YY98] and [YY99]require an additional assumption for each, but only for arguing security against the CA, whereas it is possible to reduce the security of the key to a known assumption, otherwise). 15. Shadow-public-key resistance: Another aspect of security is that the system should not contain a subliminal channel that enables “shadow publickey” distribution [KL95]. Such a property is hard to prove, but at the very least it should be required that what is published to the general public in the key escrow system is the same information as what is published in a regular public key system. There are three additional requirements which are often desired in many applications: 16. Low Cost: We need to have the system be of relative low resource cost. In particular, whereas the user should have no additional cost when compared to an unescrowed PKI user, the CA may have some additional cost (e.g., a moderate increase in memory and processing, though this memory may be maintained at the escrow authorities as well) and the only real additional cost is in managing and operating the escrow authorities (which is a required cost). A typical cost of the authorities and the needs for their security should be compatible with the corresponding cost and needs of a (perhaps distributed) CA. 17. Granularity of Escrow: Another property which may be required is that rather than opening keys of users, the authorities open session keys which are encrypted under the public keys of users. The session key is openable regardless of which of the two users in the session has been authorized as a target for key escrow. The notion of granularity in taking a key out of escrow was dealt with in [DDFY94,FY95] and by Lenstra, Winkler, and Yacobi [LWY95]. This property is typically a function of the key of the escrow authority (but can be always achieved if the authorities, rather than a large number of users, are implemented in tamper-proof hardware). 18. CA as the source of trust: In a PKI setting the system’s trust is with the CA; it may be desirable in an escrow PKI setting that trust remain with the CA. In Auto-Recoverable Auto-Certifiable cryptosystems it is possible for the CA to retain critical escrowed information for each user (though the CA cannot access it), and thus CA collaboration can be made necessary to take information out of escrow, thus making the trust remain with the CA.

208

3

A. Young and M. Yung

Auto-Recoverable Auto-Certifiable Cryptosystems: General Structure

The papers [YY98] and [YY99] describe two different Auto-Recoverable AutoCertifiable Cryptosystems such that when each is run an ElGamal [ElG85] public/private key pair, an escrowed encryption of the private key, and a proof that the escrow authorities can recover the private key is produced for the user. The proof, in addition to the ‘encryption’ of the private key, has been called a certificate of recoverability. This certificate is publicly verifiable and assures that the private key is escrowed properly. In short, each algorithm describes how to construct a string which constitutes an implicit encryption of the private key x under the escrow authorities key and a non-interactive zero-knowledge (NIZK) proof that allows a prover to prove to a verifier that her private key x in y = g x mod p is the same as in the implicit encryption. Hence, a Certification Authority (CA) can insist that a user who submits her own public key for publication also submits the certificate just described. Having done so, the CA can be certain that x is escrowed properly, without ever learning x itself. The primary difference between the two algorithms is that the public key of the escrow authorities in [YY98] is a discrete log based public key, whereas in [YY99] it is an RSA modulus. We emphasize that the proofs and encryptions employed are efficient and do not contain encryptions of circuits and general proofs which employ such constructions (which are typically plausibility results rather than actual systems). Once the keys are certified by the CA, their use within the system is as in a regular PKI based on ElGamal/Diffie-Hellman keys. Key recovery is an efficient procedure between the CA and the escrow authorities, who are otherwise not active. The cooperation with the CA is needed, yet the CA cannot recover the keys. For security the primary cryptographic assumption that is made is that the Diffie-Hellman (DH) problem is hard. This assumption is used for security against adversaries. For the user to be secure from the CA, each of the aforementioned Auto-Recoverable Auto-Certifiable Cryptosystems requires a new cryptographic assumption. Note that the DH assumption is already required because the ElGamal PKCS is secure if and only if the DH problem is hard. Due to the non-interactive nature of the certificates of recoverability, a random oracle cryptographic hash assumption (for SHA1) is also required for the validity of the proofs within the certificate. The certificate of recoverability to the CA is not made public to avoid shadow public abuse. Related Work Various tamper-resistant hardware solutions have been proposed, like the U.S. government’s Clipper chip and Capstone chip. These solutions are undesirable for users since they require special hardware, and since secret unscrutinized

Auto-recoverable Auto-certifiable Cryptosystems

209

algorithms have to be trusted. (See [YY96,YY97a,YY97b] for potential problems with such designs). Also, attacks has been found (e.g., [FY95]). Fair Public Key Cryptosystems (FPKC) is a public key escrow system that can be implemented in software [Mi92]. One of the problems with FPKC’s is that every user must split his or her private key and send the shares to the authorities. The authorities must then interact to insure that the key is escrowed. So, the system has more communication overhead than a typical public key system. Also, FPKC’s can be abused via the use of shadow public key cryptosystems, as shown by Kilian and Leighton [KL95]. Kilian and Leighton proposed a key escrow solution called Failsafe Key Escrow (FKE) to fix the shadow public key abuse problem. However, in so doing FKE’s require even more protocol interaction to escrow keys than FPKC’s. A “Fraud-Detectable Alternative to Key-Escrow Proposals” based on ElGamal was described in [VT97]. This system, called binding ElGamal, allows users to send encrypted information along with a poly-sized proof that the session key that was used in the encryption can be recovered by the escrow authorities. It was pointed out in two different rump session presentations at Eurocrypt ’97 that it is possible to use the means provided by the binding ElGamal system to defeat the escrow capability [PW97,T97].

4

Definitions

Informally, an Auto-Recoverable and Auto-Certifiable cryptosystem is a system that allows a user to generate auto-certifiable keys (keys with a proof of the method of generation) efficiently. The following is a formal definition. Definition 1. An Auto-Recoverable and Auto-Certifiable Cryptosystem is a triple (GEN,VER,REC) (where REC may be an m-tuple (REC1 ,REC2 ,...,RECm ) such that: 1. GEN is a publicly known poly-time probabilistic Turing Machine that takes no input and generates the triple (K1 ,K2 ,P ) which is left on the tape as output. Here K2 is a randomly generated private key and K1 is the corresponding public key. P is a poly-sized certificate that proves that K2 is recoverable by the escrow authorities using P . 2. VER is a publicly known poly-time deterministic Turing Machine that takes (K1 ,P ) on its input tape and returns a boolean value. With very high probability, VER returns true iff P can be used to recover the private key K2 . 3. REC is a deterministic Turing machine with a private input. For a distributed implementation: RECi , where 1 ≤ i ≤ m is a poly-time deterministic Turing Machine with a private input that takes P as input and returns share i of K2 on its tape as output, assuming that K2 was properly escrowed. (Subsets of ) the Turing Machines RECi for 1 ≤ i ≤ m can be used collaboratively to recover K2 . 4. It is intractable to recover K2 given K1 and P without REC (or REC1 ,..., RECm ).

210

A. Young and M. Yung

Next we will define informally the steps taken in a Public Key Infrastructure (PKI) and in an Auto-Recoverable Auto-Certifiable PKI. The following is the structure (protocol) of a Public Key Infrastructure: 1. CA’s addresses and parameters are published and distributed. a) Each user generates a public/private key pair, and submits the public key, along with an ID string, to a CA. b) The CA verifies the ID string, certifies the public key (by signing it), and enters the certification in the public key database. c) To send a message, a user queries the CA to obtain the public key of the recipient, and verifies the signature of the CA on the public key. d) The user then encrypts the message with the recipients public key and sends the corresponding ciphertext to the recipient. e) The recipient decrypts the ciphertext with his or her own private key. The following is an Auto-Recoverable Auto-Certifiable PKI: 1. A set of system parameters are agreed upon. The escrow authorities generate an escrowing public key with corresponding private shares. The public parameters and CA’s parameters are distributed (e.g., in software). a) Each user generates a public/private key pair, and submits the public key along with an ID string and a certificate of recoverability, to a CA. b) Using the escrowing public key, the CA verifies the certificate of recoverability. Provided that this verification holds, and that the ID string is valid, the CA certifies the public key (by signing it), and enters the certification in the public key database. c) To send a message, a user queries the CA to obtain the public key of the recipient, and verifies the signature of the CA on the public key. d) The user then encrypts the message with the recipients public key and sends the corresponding ciphertext to the recipient. e) The recipient decrypts the ciphertext with his or her own private key. 2. If a wire-tap is authorized for a given user, the escrow authorities obtain the certificate of recoverability of that user (from the CA), and recover the key or cleartext under the key. Note that (a) through (e) above are functionally equivalent in both systems. The only difference is that in the escrow system, the CA is able to verify that the private key is recoverable by the escrow authorities. The only added items in the auto recoverable PKI to what is required for a PKI are set-up extra work in step 1 and step 2. step 2 is necessary by definition and step 1 additional work seems necessary to bind the system to the escrow authorities. In an Auto-Recoverable Auto-Certifiable system, the i-th escrow authority EAi knows only RECi , in addition to what is publicly known. To publish a public key, user U runs GEN() and receives (K1 ,K2 ,P ). U keeps K2 private and sends the pair (K1 ,P ) to the CA. The CA then computes VER(K1 ,P ), and publishes a signed version of K1 in the database of public keys iff the result is true. Otherwise, U’s submission is ignored. In either case the certificate of recoverability is not published. Suppose that U’s public key is accepted and K1

Auto-recoverable Auto-certifiable Cryptosystems

211

appears in the database of the CA. Given P obtained from the CA, the escrow authorities can recover K2 as follows. EAi computes share i of K2 by running RECi (P ). The authorities then pool their shares and recover K2 .

5 5.1

The Auto-Recoverable Auto-Certifiable Cryptosystems The scheme from (YY98)

∗ denote the multiplicative group of caMathematical Preliminaries Let Z2q nonical elements relatively prime to 2q (we used it to call the group and its ∗ elements). Here q is a large odd prime. It is straightforward to show that Z2q is a cyclic group (it possesses a primitive root). In fact, if s is a primitive root modulo q and if s is odd, then s is also a primitive root modulo 2q. If s is a primitive root modulo q and s is even, then s + q is a primitive root modulo 2q. See [Ro93] for details. It can be shown that there exists a generator s for all ∗ . Thus, there is a probabilistic poly-time algorithm to find a generator groups Z2q ∗ of Z2q . The following first two simple claims are used to show that if discrete log ∗ problem is hard, then the discrete log problem in Z2q is hard.

Claim. (sk mod 2q) mod q = sk mod q. 0

Claim. If (sk mod 2q) = sk mod q, then k0 = k. Claim. If DH mod q is hard, then DH mod 2q is hard. Proof. We will prove this by proving the contrapositive. Suppose we are given a box X that takes A and B and returns sab mod 2q where A = sa mod 2q and B = sb mod 2q. We need to show that we can use X to perform DH given 0 0 ∗ such A0 = sa mod q and B 0 = sb mod q. To do this, we choose r1 , r2 ∈R Zq−1 0r1 0r2 that A and B are odd mod q, provided that s is odd (if s is even, we make sure these two values are even). We then compute t = X(A0r1 mod q, B 0r2 mod q). 0 0 −1 By Claim 2 it follows that t = sa b r1 r2 mod q. We then output t(r1 r2 ) mod q. ∗ Note that r1 r2 has a unique inverse mod q−1 since r1 , r2 ∈ Zq−1 . Our algorithm 0 0 thus outputs sa b mod q as needed. QED. From Claim 3 it follows that if the DH problem is hard, then the discrete log ∗ is hard. problem in Z2q Problem 1: Let p = 2q + 1 and let q = 2r + 1 where p, q, and r are prime. k Find tk mod 2q given sk mod 2q and g t mod p. Here g, s, t, and p are public. ∗ ∗ g generates Zp , s generates Z2q , and t generates a large subgroup of Z2q . The difficulty of Problem 1 is a cryptographic assumption in [YY98]. Clearly, Problem 1 is not hard if the discrete-log problem is not hard, or if DH is not hard. We note that Stadler [St96] has initiated the use of the double-decker exponentiation in his publicly-verifiable secret sharing (PVSS) work prior to our use of it. He also notes that his PVSS can be used in the model of Micali’s “Fair Cryptosystems”. However, this means that the application suffers from the similar problems of the original fair cryptosystems which our work has attempted to overcome.

212

A. Young and M. Yung

System Setup A large prime r is agreed upon s.t. q = 2r + 1 is prime and s.t. p = 2q + 1 is prime. We have produced such large values efficiently. A generator g is agreed upon s.t. g generates Zp , and an odd value g1 is agreed upon s.t. g1 ∗ generates Z2q . The values (p,q,r,g,g1 ) are made public. One example of organizing the escrow authorities is given; other settings of threshold schemes or even schemes where users decide on which authorities to bundle together are possible. There are m authorities. Each authority EAi chooses zi ∈R Z2r . They each compute Yi =Qg1 zi mod 2q. They then pool m their shares Yi and compute Pm the product Y = i=1 Yi mod 2q. Note that Y = z g1 mod 2q, where z = i=1 zi mod 2r. The authorities choose their zi over ∗ again if (g1 /Y ) mod 2q is not a generator of Z2q . Each authority EAi keeps zi private. The public key of the authorities is (Y ,g1 ,2q). The corresponding shared private key is z. Key Generation GEN uses “double decker” exponentiation and operates as follows. It chooses a value k ∈R Z2r and computes C = g1 k mod 2q. GEN then solves for the user’s private key x in Y k x = g1 k mod 2q. GEN computes the public key y = g x mod p. GEN computes a portion of the certificate v to −k be g Y mod p. GEN also computes three NIZK proof transcript P1 , P2 , P3 (which are generated by the NIZK proof systems ZKIP1 , ZKIP2 , and ZKIP2 , described below). The certificate P is the 5-tuple (C,v,P1 ,P2 ,P3 ). GEN leaves ((y,g,p),x,P ) on the output tape (note that y need not be output by the device since y = v C mod p). The user’s public key is (y, g, p). Public Escrow Verification VER takes ((y,g,p),P ) on its input tape and outputs a boolean value. VER verifies the following things: 1. 2. 3. 4.

P1 is valid, which shows that U knows k in C P2 is valid, which shows that U knows k in v P3 is valid, which shows that U knows k in v C mod p verifies that y = v C mod p

VER returns true iff all 4 criterion are satisfied. P1 is essentially the same as the proof described first in [GHY85] for isomorphic functions, but the operations ∗ . ZKIP2 , which is the basis for P2 and P3 , will be explained in here are in Z2q the following section. ZKIP In ZKIP2 , the prover wishes to interactively prove to a verifier that the k prover knows k in T = g s mod p. It is assumed that the verifier does not know sk mod 2q (and hence he doesn’t know k). The values T , g, s, and p are public. The quantity g generates Zp . The following three-pass protocol is repeated n times. 1. 2. 3. 4.

The The The The

e

prover chooses e ∈R Z2r and sends I = T s mod p to the verifier. verifier sends b ∈R Z2 to the prover. prover sends z = e + bk mod 2r toz the verifier. verifier verifies that I = (T 1−b g b )s mod p.

Auto-recoverable Auto-certifiable Cryptosystems

213

The verifier accepts the proof iff step 4 passes in all n rounds of the protocol. ZKIP1 is a three-pass protocol that uses values (I,b,z) which are very similar to the values (I,b,z) which are used in ZKIP2 . It remains to show how the NIZK proofs in P are constructed. Let ei,j denote the prover’s random choice for iteration j of proof Pi . Here 1 ≤ i ≤ 3 and 1 ≤ j ≤ n. 1. P = (C,v) 2. The prover chooses values e1,1 , e1,2 , ..., e1,n , e2,1 , e2,2 , ..., e2,n ,e3,1 , e3,2 , ...,e3,n ∈R Z2r . Note that the e’s must be in Z2r , otherwise information about k may be leaked in step (8). To see this, note that e is needed to blind kb perfectly. −e2,j mod p, and I3,j = 3. The prover computes I1,j = g1 e1,j mod 2q, I2,j = v Y e3,j (g1 /Y ) mod p for 1 ≤ j ≤ n y 4. The prover includes all the values Ii,j in P , where 1 ≤ i ≤ 3 and 1 ≤ j ≤ n. 5. The prover computes rnd = H(I1,1 , I1,2 , ..., I1,n , I2,1 , I2,2 , ..., I2,n , I3,1 , I3,2 , ..., I3,n ) where H is a cryptographic one-way function. 6. The prover gets the 3n values bi,j for 1 ≤ i ≤ 3 and 1 ≤ j ≤ n from the 3n least significant bits of rnd. These are the challenge bits. Note that the verifier can calculate these bits given the values for I. 7. The prover computes zi,j = ei,j + bi,j k for 1 ≤ i ≤ 3 and 1 ≤ j ≤ n. 8. The prover includes the values zi,j in P , where 1 ≤ i ≤ 3 and 1 ≤ j ≤ n. The verifier accepts the proof iff all 3n checks pass and if y = v C mod p. This method of making a ZKIP non-interactive is due to Fiat and Shamir [FS86]. Key Recovery RECi recovers share i of the user’s private key x as follows. RECi takes C from P . It then computes share si to be C zi mod 2q, and outputs sQi on its tape. The authorities then pool their shares and each computes Y k = m −k mod 2q, which is i=1 si mod 2q. From this they can each compute x = CY the user’s private key. The escrow authorities can recover the plaintext of users suspected of criminal activity without recovering the user’s private key itself. To decrypt the ciphertext (a, b) of user U the escrow authorities proceed as follows: 1. 2. 3. 4.

Each of the m escrow authorities i receives C corresponding to U . −z1 mod p. Escrow authority 1 computes s1 = aC −zi+1 Escrow authority i + 1 computes si+1 = si C mod p. Escrow authority m decrypts (a, b) by computing b/(sm C ) mod p.

This system allows for multiple CA’s to be associated with the escrow authorities. Escrowing across escrow authorities domains (e.g., different countries) can be solved by the users employing the long-lived Diffie-Hellman key as their

214

A. Young and M. Yung

common key (which is recoverable by either country) or by bilateral agreements. For proofs of security we refer the reader to [YY98]. Note that only the user’s public key is published as in a regular public key system. In fact, it is insisted that the certificate of recoverability not be published. This is to prevent the establishment of a shadow public-key for each user. 5.2

The scheme from (YY99)

Mathematical Preliminaries The system requires the following cryptographic assumption. ∗ , Problem 2: Without knowing the factorization of n, find x where x∈ Z2tn e x given x mod 2tn and g mod p. Here, p = 2tn + 1, n = qr, p, q, r, and large primes,t is a small prime, g generates a large subgroup of Zp , and gcd(e,φ(tn)) = 1. In this work e = 3.

It is also assumed that it is hard to compute the entire plaintext if reductions are performed modulo 2tn, as opposed to reducing modulo n as in RSA. Recall that t is a small prime number1 . Intuitively, it seems that problem 2 should be hard, since xe mod 2tn is a presumed one-way trapdoor function of x, and g x mod p is a presumed one-way function of x. Clearly, Problem 2 is not hard if cracking RSA is not hard, or if computing discrete logs is not hard. System Setup The escrow authority (authorities) generate a shared Blum integer n = qr, where q and r are prime. The escrow authorities then make sure that gcd(3,φ(n)) = 1. If this condition does not hold, then the escrow authorities generate a new n. The escrow authorities then compute p = 2tn + 1, where t is drawn from the first, say 256 strong primes starting from 11, inclusive. If p is found to be prime using one of these values for t, then the values for n and p have been found. If none of the values for t causes p to be prime, this entire process is repeated as many times as necessary. Note that t = 2t0 + 1 where t0 is prime. Since we insist that t > 7, we are guaranteed that gcd(3,φ(tn)) = 1. Once n and p are found, the escrow authorities generate the private shares ∗ is chosen such that g d1 , d2 , ..., dm corresponding to e = 3. A value g ∈R Z2tn has an order that is at least as large as the smallest of q and r, in the field Zp (recall that the factorization of n is not known). The values t, n, and g are made public. This system can be setup much faster than [YY98] since the escrow authority can generate a composite modulus very quickly, and in order to find a prime p, t can be varied as needed. The expected time to find such a p is inversely proportional to the density of primes. In contrast, in [YY98] the system setup relied on finding three primes with a rigid relationship between them. Heuristicly this means that sampling such primes may take an expected time which is inversely proportional to the density of the primes cubed. 1

the CA can be given the value mod n and the user can always choose values which are fixed and known mod 2t.

Auto-recoverable Auto-certifiable Cryptosystems

215

∗ Key Generation GEN operates as follows. It chooses a value x ∈R Z2tn and 3 computes C = x mod 2tn. x is the user’s ElGamal private key. GEN then computes y = g x mod p. The user’s ElGamal public key is (y, g, p). Note that g may not necessarily generate Zp , but, we can make sure that it generates a large subgroup of Zp . GEN also computes a non-interactive zero-knowledge proof based on C and y. The following is how this proof is constructed.

1. 2. 3. 4. 5. 6.

∗ choose r1 , r2 , ..., rN ∈R Z2tn . compute Ci = ri 3 mod 2tn for 1 ≤ i ≤ N compute vi = y ri mod p for 1 ≤ i ≤ N b = H((C1 , v1 ), (C2 , v2 ), ..., (CN , vN )) mod 2N bi = (2i AN D b) > 0 for 1 ≤ i ≤ N b zi = ri x0 i mod 2tn for 1 ≤ i ≤ N

Here N is the number of iterations in the NIZK proof (e.g., N = 40). Concerning step 1, technically the prover has a chance that one of the ri will have q or r in its factorization, this is highly unlikely. Note that bi in step 5 results from a boolean test. bi is 1 if when we take the logical AND of 2i and b we get a value greater than zero. It is 0 otherwise. The proof P is (C, (C1 , v1 ), (C2 , v2 ), ..., (CN , vN ), z1 , z2 , ..., zN ). GEN leaves ((y,g,p),x,P ) on the output tape. Public Escrow Verification VER takes ((y,g,p),P ) on its input tape and outputs a boolean value. VER verifies the following things: 1. C bi Ci = zi 3 mod 2tn for 1 ≤ i ≤ N 2. vi = (y 1−bi g bi )zi mod p for 1 ≤ i ≤ N VER returns true both criterion are satisfied. Note that skeptical verifiers may also wish to check the parameters supplied by the escrow authorities (e.g., that n is composite, p is prime, etc.). Key Recovery RECi recovers share i of the user’s private key x as follows. RECi takes C from P . It then recovers share si using the private share di . It outputs si on its tape. The authorities then pool their shares and x is computed. Recovering Plaintext Data The escrow authorities can recover the plaintext of users suspected of criminal activity without recovering the user’s private key itself. In this section, it is assumed that the method Pm being used is [BF97]. In this case the private decryption exponent is d = i=1 di mod φ(tn), and d is the inverse of 3 mod φ(tn). To decrypt the ElGamal ciphertext (a, b) of a user U the escrow authorities proceed as follows: 1. 2. 3. 4.

Each of the m escrow authorities receives C corresponding to U . d1 Escrow authority 1 computes s1 = aC mod p. di+1 mod p. Escrow authority i + 1 computes si+1 = si C dm Escrow authority m decrypts (a, b) by computing b/(sm−1 C ) mod p.

Since the escrow authorities do not reveal the values C di , no one can recover x. For proofs of security we refer the reader to [YY99].

216

6

A. Young and M. Yung

Depth-3 Escrow Hierarchy

The last solution can be combined with [YY98] to implement a depth-3 escrow hierarchy. The following is how to realize such a system. The escrow authorities generate a shared composite n such that q 0 = 2tn + 1 is prime, and such that p = 2q 0 + 1 is prime. Here t is a small prime of the form 2t0 + 1 where t0 is prime. Thus, from the root of the tree to the children of the root, the escrow system that is used is the one that is described in this section. It is somewhat more difficult to generate an appropriate prime 2tn + 1 in this case, since 4tn + 3 must also be prime (so we have the same inefficiency as in [YY98]). Each child of the root (intermediate node) then generates a (potentially shared) public key Y mod 2q 0 . Thus Y is an ElGamal public key in ElGamal mod 2q 0 . The leaves corresponding to (i.e. under) each of these intermediate children then generate escrowed keys based on the values for Y using the algorithm from [YY98]. Thus, the [YY98] algorithm is used between the intermediate nodes and the users at the leaves. Note that in this case the generator that is used in Y ∗ may only generate a large subgroup of Z2q 0.

7

Recent Developments

There are a number of things that could improve on these Auto-Recoverable Auto-Certifiable cryptosystems. For instance, it is desirable to eliminate the assumption that Problem 1 and Problem 2 are hard. Also, note that in both systems, the user’s public keys have special algebraic form, as dictated by their reliance on the shared public key of the escrow authorities. In a generic system one would like to be able to escrow generic keys (RSA and regular El-Gamal). This gives rise to the following additional requirements. 19. Employing Generic Keys: The systems use the traditional public keys: RSA/factoring-based or ElGamal variants. 20. Compatible User: The only change for the user is additional information sent during key registration (or reregistration). 21. No Cascading Changes: The users do not have to change their applications which employ cryptography, not even within the PKI applications (namely they use the same general cryptographic functions, and the same software, all we change is some added procedure in registration). 22. Seperation of Users and Escrow Agents: The escrow authorities are managed and constructed independently of the users (only their public key(s) need be known). 23. Independent User Keys: The user’s key is independent of any third party key and is produced in much the same way as in an unescrowed PKI. The users can keep their basic cryptographic algorithms (key generation, encryption, etc.). 24. Multiple Escrow Authorities Users can register for escrow with multiple escrow authorities.

Auto-recoverable Auto-certifiable Cryptosystems

217

25. Coexistence Escrow/ non-Escrow: Users can under the same CA have unescrowed keys and escrowed ones (and can transfer unescrowed keys to escrowed ones). 26. Escrow Hierarchy: A multi-level security system can be implemented where escrow authorities at each level can access all information below in the hierarchy, and none of the information above.

8

Forthcoming Work

In work that is yet to appear, we present an Auto-Recoverable Auto-Certifiable cryptosytem with ElGamal user keys that does not involve any new cryptographic assumptions (like Problem 1 or Problem 2 being hard). In fact, all that is assumed is the existence of a semantically secure PKCS (though the random oracle model is still used). Hence, the shared public key of the escrow authority can have any algebraic form, so long as it is part of a semantically secure PKCS. The solution decouples the algebraic connection between the user keys and the shared public key of the escrow authority, and thus gives rise to a completely new feature in Auto-Recoverable Auto-Certifiable cryptosystems. It enables “drop-in replacement” of certified public keys. This results from the fact that the public key of the user can be generated in exactly the same way as in an unescrowed PKI. Thus, should a user even decide to escrow his or her public key, he or she can do so at any time, even after the public key is made public. The user need only construct the certificate of recoverability at a later time and submit it for verification by the CA. In future work we will be presenting such a system where the user’s public key is an RSA public key [YY-ms]. This decoupling of the algebra behind the public keys also enables arbitrary depth key escrow hierarchies. The new systems have the properties specified above.

References BGw97. M. Bellare, S. Goldwasser. Verifiable Partial Key Escrow. In ACM CCCS ’97. BF97. D. Boneh, M. Franklin. Efficient Generation of Shared RSA Keys. In Advances in Cryptology—CRYPTO ’97, 1997. Springer-Verlag. DDFY94. A. De Santis, Y. Desmedt, Y. Frankel, M. Yung. How to Share a Function Securely. In ACM Symp. on Theory of Computing, pages 522–533, 1994. DH76. W. Diffie, M. Hellman. New Directions in Cryptography. In volume IT-22, n. 6 of IEEE Transactions on Information Theory, pages 644–654, Nov. 1976. ElG85. T. ElGamal. A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. In CRYPTO ’84, pages 10–18. FD89. Y. Frankel, Y. Desmedt. Threshold Cryptosystems. In CRYPTO ’89, pages 307-315. FS86. A. Fiat, A. Shamir. How to Prove Yourself: Practical Solutions to Identification and Signature Problems. In CRYPTO ’86, pages 186–194. FY95. Y. Frankel, M. Yung. Escrow Encryption Systems Visited: Attacks, Analysis and Designs. In CRYPTO ’95, pages 222–235,

218 FY97.

A. Young and M. Yung

Y. Frankel, M. Yung. On characterization of Escrow Encryption Schemes. In ICALP ’97. GHY85. Z. Galil, S. Haber, M. Yung. Symmetric public-key encryption. In CRYPTO ’85, pages 128–137. 1985. K-S. H. Abelson, R. Anderson, S. Bellovin, J. Benaloh, M. Blaze, W. Diffie, J. Gilmore, P. Neumann, R. Rivest, J. Schiller, B. Schneier. The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption. available at http://www.crypto.com/key study KL95. J. Kilian and F.T. Leighton. Fair Cryptosystems Revisited. In CRYPTO ’95, pages 208–221, 1995. Springer-Verlag. Koh78. L. Kohnfelder. A Method for Certification. MIT Lab. for Computer Science, Cambridge Mass., May 1978. LWY95. A. Lenstra, P. Winkler, Y. Yacobi. A Key Escrow System with Warrant Bounds. In CRYPTO ’95, pages 197–207, 1995. Mi92. S. Micali. Fair Public-Key Cryptosystems. In CRYPTO ’92, pages 113–138, 1992. Springer-Verlag. PW97. B. Pfitzmann, M. Waidner. How to Break “Fraud-Detectable Key Escrow”. Eurocrypt ’97 rump session. Ro93. K. R. Rosen. Elementary Number Theory and its Applications. 3rd edition, Theorem 8.14, page 295, 1993. Addison Wesley. St96. M. Stadler. Publicly Verifiable Secret Sharing. In Eurocrypt ’96, pages 190– 199, 1996. Springer-Verlag. T97. H. Tiersma. Unbinding ElGamal - An Alternative to Key-escrow? Eurocrypt ’97 rump session. VT97. E. Verheul, H. van Tilborg. Binding ElGamal: A Fraud-Detectable Alternative to Key-Escrow Proposals. In Eurocrypt ’97, pages 119–133, 1997. YY96. A. Young, M. Yung. The Dark Side of Black-Box Cryptography. In CRYPTO ’96, pages 89–103, YY97a. A. Young, M. Yung. Kleptography: Using Cryptography against Cryptography. In Eurocrypt ’97, pages 62–74. YY97b. A. Young, M. Yung. The Prevalence of Kleptographic Attacks on Discrete-Log Based Cryptosystems. In CRYPTO ’97, pages 264–276. Springer-Verlag. YY98. A. Young, M. Yung. Auto-Recoverable and Auto-Certifiable Cryptosystems. In Advances in Cryptology—Eurocrypt ’98. YY99. A. Young, M. Yung. Auto-Recoverable Cryptosystems with Faster Initialization and The Escrow Hierarchy. In PKC ’99. YY-ms. A. Young, M. Yung. manuscript (available from authors).

A Distributed Intrusion Detection System Based on Bayesian Alarm Networks Dusan Bulatovic1 and Dusan Velasevic2 1 Informatika, Jevrejska 32, 11000 Belgrade, Yugoslavia [email protected] 2 University of Belgrade, School of Electrical Engineering, 11000 Belgrade, Yugoslavia [email protected]

Abstract. Intrusion Detection in large network must rely on use of many distributed agents instead to one large monolithic module. Agents should have some kind of artificial intelligence in order to cope successfully with different intrusion problems. In this paper, we suggested Bayesian alarm network to work as independent Network Intrusion Detection Agent. We have shown that when narrowed in detecting one specific type of the attack in large network, for example denial of service, virus, worm or privacy attack, we can induce much more prior knowledge into system regarding the attack. Different nodes of the network can develop their own model of Bayesian alarm network and agents could communicate between themselves and with common security data base. Networks should be organized hierarchically so on the higher level of hierarchy, Bayesian alarm network, thanks to interconnections with lower level networks and data, acts as a distributed Intrusion Detection System.

1 Introduction Due to increased connectivity (especially on the Internet), and the vast of financial possibilities that are opening up in electronic trade, more and more computer networks and hosts are subject to attack. One way to prevent subversion is by building a completely secure system. However this is not possible in practice. The vast installed base of systems world-wide, guarantees that any transition to a secure system and network, if ever attempted, would take long time in coming. It seems obvious that we cannot prevent subversion. Tools are therefore necessary to monitor systems, to detect attacks, and to respond actively to them. This is essentially what is expected from one Intrusion Detection System (IDS) to be able to do. An intrusion is defined [1] as any set of actions that attempt to compromise the integrity, confidentiality, or availability of a resource. It is a violation of the security policy of the system. Any definition of an intrusion is, of necessity, imprecise, as security policy requirements do not always translate into a well defined set of actions. From the other side, Intrusion Detection is the methodology by which intrusions are detected. This methodology can be divided into two category of intrusion, misuse intrusion and anomaly intrusion that can be described as: R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 219–228, 1999. © Springer-Verlag Berlin Heidelberg 1999

220

• •

D. Bulatovic and D. Velasevic

Misuse intrusions are well defined attacks on known weak points of a system. They can be spotted by watching for certain actions being performed on certain objects. Anomaly intrusions are based on observations of deviations from normal system usage patterns. They are detected by building up a profile of the system being monitored, and detecting significant deviations from this profile.

As misuse intrusions follow well-defined patterns they can be detected by doing pattern matching on audit- trail information. However, anomaly intrusions are harder to detect. There are no fixed patterns that can be monitored for and so we need a system that combined human-like pattern matching capabilities with the vigilance of a computer program. Thus it would always be monitoring the system for potential intrusions, but would be able to ignore spurious false intrusions if they resulted from legitimate user actions; so another goal is to minimize the probability of incorrect classification. In large networks, Intrusion Detection Systems must relay on network wide information. Often, use of many distributed agents instead of one large monolithic IDS module will give better results. Agents should have some kind of artificial intelligence in order to cope successfully with different intrusion problems. As a future direction in developing IDS, it is believed that Bayesian network should be used. In a general case it is not clear how to do that, but we will show that when narrowed in detecting one specific type of the attack, for example denial of service, virus, worm or privacy attack, we can induce much more prior knowledge into the system regarding the attack. Before we present our solution, we will first describe three corresponding methods of network intrusion detection.

2 Use of Genetic Programming in Intrusion Detection Many seemingly different problems in artificial intelligence, can be viewed as requiring discovery of a computer program that produces some desired output for particular inputs. When viewed in this way, the process of solving these problems becomes equivalent to searching a space of possible computer programs for a most fit individual computer program. This approach is chosen in [2] to building IDS. Instead of one large monolithic IDS module, here is used a finer-grained approach with a group of free-running processes which can act independently of each other and the system. They are called Autonomous Agents. An agent is defined as [3] a system that tries to fulfill a set of goals in a complex, dynamic environment. In this context, every agent would try to detect anomalous intrusions in a computer system under continually changing conditions. In other words, the agent would be the IDS. If an IDS can be split up into multiple functional entities which can operate in their own right, each of them can be an agent. This gives multiple intrusion detection systems running simultaneously. The agents run in parallel in the system. Each agent is a lightweight program - it observes only one small aspect of the overall system. A single agent alone cannot form an effective intrusion detection system - its view of the overall system is too limited in scope. However, if

A Distributed Intrusion Detection System Based on Bayesian Alarm Networks

221

many agents all operate on a system, then a more complicated IDS can be built. Agents are independent of each other. They can be added to and removed from the system dynamically. The agent code is composed of a set of operators (arithmetic, logical and conditional) and a set of primitives that obtain the value of metrics. As is usual with Genetic Programming, these sets can be combined in any way during evaluation run to generate parse trees for solution programs. Packet data obtained from the lower layer of the system

Packet Data

Evaluate agent for each packet

IF

IP NEQ

IP-DEST

RAISE

MY-IP

Example code for a simple agent

A broadcast message to all other agents

Fig. 1: Sample internal parse tree for an agent

Figure 1 shows a sample parse tree for an agent. The Terminals in the parse tree (the primitives IP-DEST, MY-IP and RAISE) obtain their values from the system abstraction layer. In this simple example, the primitive IP-DEST would obtain the IP Destination address for the current packet from the abstraction layer. The advantages of using genetic programming looked trough the model of Autonomous agent are efficiency, fault tolerance, resilience to degradation, extensibility and scalability. Having many small agents has a number of advantages against a single monolithic IDS. Clear analogy can be drawn between the human immune system and this proposal. The immune system consists of many white blood cells dispersed throughout the body. They must attack anything which they consider to be alien before it poses a threat to the body. The foreseen drawbacks include the overhead both on hosts and network because of so many processes, long training times, and the fact that if the system is subverted, it becomes a security liability. An interesting possibility they open up is that of an active defense, that can respond to intrusions actively instead of passively reporting them (it could kill suspicious connections, for example). Developing good training scenarios is an important issue with this model and that should be area for future investigation.

222

D. Bulatovic and D. Velasevic

3 Graph Based Intrusion Detection This approach in Intrusion Detection will be described on the model developed by group of authors in University of California, Davis [4]. Their work was inspired by Internet Worm Attack (1988), which caused the Internet to be unavailable for about five days [5]. They designed GrIDS - Graph-based Intrusion Detection System in order to develop secure infrastructure capable to defend Internet and other large networks. Its primary function is to detect and analyze large-scale attacks, although it also has the capability of detecting intrusions on individual hosts. The nature of operation of the GrIDS system will be presented on a simple example of tracking warm and building such an activity graph. In Figure 2 the worm begins on host A, then initiates connections to hosts B and C which causes them to be infected. The two connections are reported to GrIDS, which creates a new graph representing this activity and records when it occurred. The two connections are placed in the same graph because they are assumed to be related. In this case, this is because they overlap in the network topology and occur closely together in time.

D B A

E C

Fig. 2: The beginning of a worm graph, and the graph after the worm has spread

If enough time passes without further activity from hosts A, B, or C, then the graph will be discarded. However, if the worm spreads quickly to hosts D and E, as in the figure, then this new activity is added to the graph and the graph’s time stamp is updated. Graph-based Intrusion Detection is a helpful step toward defending against widespread attack in the networks. It presents network activities to humans as highly comprehensible graphs. In addition, policy mechanisms allow organizations much greater control over the use of their networks than is possible, for example, with firewalls alone. GrIDS, implementation of the graph-based Intrusion Detection, is designed to detect large-scale attacks or violations of an explicit policy. However, a widespread attack that progresses slowly will not be diagnosed by its aggregation mechanism. Also additional safeguards must be taken to ensure the integrity of communications between GrIDS modules, and to prevent an attacker from replacing parts of GrIDS with malicious software of her own.

A Distributed Intrusion Detection System Based on Bayesian Alarm Networks

223

4 Cooperative Intrusion Detection for Detecting Denial of Network Service Denial of service for the routing infrastructures, (routers and routing protocols), may be caused by natural faults as well as by malicious attacks. To protect network infrastructures from routers that incorrectly drop packets and misroute packets, Cheung and Levitt [7] used a detection - response approach. They presented protocols that detect and respond to those misbehaving routers. Protocols are supposed to detect and respond to two types of denial of service, “black hole” routers and routers that misroute packets. One of the proposed protocols, distributed probing is applicable to detecting network sinks and misrouting routers that cause denial of service - that is, the misrouted packets cannot reach their destinations. With distributed probing, a router can diagnose its neighboring routers by sending them directly (i.e., without passing through intermediate routers) a test packet whose destination router is the tester itself. Based on whether a tester can get back the test packet within a certain time interval, the tester can deduce the goodness of the tested router. Network is modeled by a directed graph G = (V;E) where vertices denote routers and edges denote communication channels. An edge (i; j) ∈ E is called testable if cost(j; i) is strictly less than the cost of any other path from j to i in G, where the cost of a path is the sum of the costs of all edges on the path. In Figure 3 we have a network example that has three routers, namely a, b, and c. and three edges (b,c), (b,a), and (c,b). If (c,b) is testable and router c sends a packet p whose destination is c itself to b, then, in distributing probing protocol, p will return to c if and only if b does not misbehave on p. a c2

c3 p

c

b c1 Fig. 3: Testable edges

This model of cooperative work for detecting denial of service, unfortunately, does not solve the entire denial of service problem of routing infrastructures. There are router failures not covered by this failure models. For example, a compromised router may modify the body of a transit packet. Also, link failures are not modeled, so a link failure that results in packet loss may be viewed as a node failure. Finally, these models only consider transit traffic. In other words, packets sent by source hosts to source routers and those sent by destination routers to destination hosts are not addressed. However, this model represent a first step in protecting routing infrastructures from denial of service using an intrusion detection approach.

224

D. Bulatovic and D. Velasevic

5 Our Proposal: A Bayesian Alarm Network as Independent Intrusion Detection Agent Bayesian approach to probability and statistics differs from the classical probability. Whereas a classical probability is a physical property of the world (e.g., the probability that a coin will land heads), a Bayesian probability is a person’s degree of belief in that event. Important difference between physical probability and personal probability is that, to measure the latter, we do not need repeated trials. While classical statistician has a hard time measuring that the cube will lend with a particular face up, the Bayesian simply restrict his attention to the next toss, and assigns a probability. For some events it is not possible to measure the probability and that is why Bayesian classification represents interesting tool in intrusion detection. This technique of unsupervised classification of data, and its implementation, Autoclass [8] searches for classes in the given data using Bayesian statistical techniques. It attempts to determine the most likely process(es) that generated the data. It does not partition the given data into classes but defines a probabilistic membership function of each datum in the most likely determined classes. Bayes’ rule does not provide an algorithm for classification. The designers of a Bayesian classifier are faced with the computationally intractable problem of searching the hypothesis space for the optimal distribution that produced the observed data and the controversial problem of estimating the priors. In the case where we are faced with large number of variables and relationships among them Bayesian network is a representation suited to solve the problem. It is a graphical model (directed acyclic graph-DAG), that can efficiently encode the joint probability distribution (physical or Bayesian) for a larger set of variables. The idea to use Bayesian or other belief networks in Intrusion Detection Systems has come from the necessity to combine different anomaly measures in detecting intrusions. Bayesian networks [10] allow the representation of causal dependencies between random variables in graphical form and permit the calculation of the joint probability distribution of the random variables by specifying only a small set of probabilities, relating only to neighboring nodes. This set consists of the prior probabilities of all the root nodes (nodes without parents) and the conditional probabilities of all the non root nodes given all possible combinations of their direct predecessors. Bayesian networks, which are DAGs with arcs representing causal dependence between the parent and the child, permit absorption of evidence when the values of some random variables become known, and provide a computational framework for determining the conditional values of the remaining random variables, given the evidence. Figure 4 gives a trivial Bayesian network modeling intrusive activity. Each box represents a binary random variable with values representing either its normal or abnormal condition. If we can observe the values of some of these variables, we can use Bayesian network calculus to determine P(Intrusion|Evidence). However, to determine the a priori probability values of the root nodes and the link matrices for each directed arc for a general case, where many different intrusion are possible, we must incorporate a substantial amount of knowledge concerning the different types of attacks that can be used to compromise system security, as well as the conditional probabilities that various well-defined events will occur given that

A Distributed Intrusion Detection System Based on Bayesian Alarm Networks

225

INTRUSION

To Many Users To many CPU Intensive Jobs

To many Disk Intensive Jobs

Disk I/O

Fragmentation

CPU

Net I/O

Newly available Program on the Net

Trashing Fig. 4: Bayesian alarm network – general case

those attacks are in progress. Unfortunately, Intrusion-detection community is at the moment only at first stage of trying to assemble this type of knowledge. Our proposal is, because of complicity to find general solution, not to use Bayesian alarm network as universal, standalone Intrusion Detection System. Instead, it could be used as independent Intrusion Detection Agent for detecting one, specific type of network attack. This way we need to induce into the system prior knowledge only regarding that type of the attack. At the same time some other nodes of large network can develop its own model of alarm network for detecting same kind of the attack, entering freely local believes in data sensitivity, and expectation of the attack. These agents should be able to communicate between themselves on broadcast or search principle, as required. Beside being able to communicate between themselves, this approach require for agents to communicate with a common data base-Bayesian Management Information Base (BMIB), which contains information regarding the attacks in progress. However, different site will normally select different vendors and, since network incidents are often distributed over multiple sites, it is likely that a single incident will be visible in different way. Clearly, it would be necessary for these diverse intrusion detection systems to be able to share data. Solution to that problem could result from the work of a new Intrusion Detection working group established in the Security Area of the IETF to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and the management systems which have to interact with them. However, for our model, not only data format in BMIBs and exchange procedure must be standardized, but also notation of the network attacks, like P–for privacy, Vfor virus , W-for worm, D-for denial of service etc.

226

D. Bulatovic and D. Velasevic

For the definition of the architectural model that could be used in the implementation of the security management system, hierarchical organization of the networks and BMIBs is suggested [12]. The lower level of the hierarchy should include a small number of interconnected physical networks. Network of the upper level will interconnect the lower levels networks and BMIB will contain relevant information regarding attacks in wider area. Due to sophisticate nature of network attacks the security management cannot rely only on the real-time monitoring of security measures. The network manager needs also to store in a database and analyze historical security information in order to detect an attack as a symptom of past correlated events and to discover the attacker. As an illustration of solving the specific problem of detecting privacy attack to sensitive medical records, in Figure 5 is given a simplified structure of a corresponding Bayesian alarm network. One possible choice of variables for this problem was Intrusion (I), Aids (A), External (E), Medical (M), Nonmedical (N), Outsider (O), where I represent that current access to sensitive records is intrusion to privacy, A access to records with diagnose of aids and E access to external sensitive records (other ward or hospital). Variables M, N and O denote that access is performed by medical staff, nonmedical staff, or outsider.

I-Intrusion

M-Medical staf

N-Nonmedical

O-Outsider

A-Aids

E-External

Fig. 5: One specific attack (privacy intrusion) - simpler Bayesian alarm network

In this example, using ordering (I,M,N,O,E,A) we have the following conditional independencies:

p( m i ) = p( m ) , p ( n i, m ) = p ( n ) ,

p( o i, m, n ) = p( o ) , p( e i, m, n, o ) = p( e i ) , p( a i, m, n , o, e ) = p ( a i, m, n , o ) .

(1)

A Distributed Intrusion Detection System Based on Bayesian Alarm Networks

227

As seen, we consider that accesses to sensitive records at different places are conditionally independent. Also, accesses by medical staff, nonmedical or outsider are mutually conditionally independent. Our judgments about conditional independence between various variables, guide us to the network structure where it is possible easier to compute the probability of interest (probability of intrusion):

p( i m, n, o, e, a ) =

p( i, m, n, o, e, a ) = p( m, n, o, e, a )

p( i, m, n, o, e, a ) . p ( i , m , n , o , e , a ) ′ ∑i ′

(2)

Given the conditional independencies in Equation (1), we can make this computation more efficient:

p( i m, n, o, e, a ) =

p( i ) p( m ) p( n ) p( o ) p( e i ) p( a i, m, n, o ) ∑ i′ p( i ′ ) p( m) p( n ) p( o) p( e i ′ ) p( a i ′, m, n, o )

(3)

i.e.:

p ( i m, n , o, e, a ) =

p ( i ) p ( e i ) p ( a i, m , n , o ) . ∑ i′ p ( i ′ ) p ( e i ′ ) p ( a i ′, m , n , o )

(4)

From the presented example it is also possible to conclude that requirement for the prior knowledge regarding the attack is not drawback in the case of Bayesian network developed to detect one specific kind of intrusion. As we are here concentrated to one type or a small subset of intrusions, it is expected that we should have more knowledge regarding the matter. At the same time thanks to interconnections with other alarm networks at the same level of hierarchy and corresponding BMIB we should be able to collect more knowledge and data regarding the same type of the attack. (Connection to other alarm networks is here symbolically denoted with variable E – access to external sensitive records in other ward or hospital). At higher level of hierarchy, based to its interconnections with lower level networks and data from Bayesian Management Information Base, Bayesian alarm network will be able to monitor network attacks in wider area, and can act as Distributed Intrusion Detection System. Using recorded data from BMIBs such a distributed Intrusion Detection System, with assembled knowledge from different Bayesian alarm networks, could have integrated, human and computer program intrusion detection capability.

6 Discussion It is shown that our model will provide Bayesian alarm network to work as independent Intrusion Detection System, and, at the same time, to be part of a larger distributed IDS. In opposed to others agents based Intrusion Detection, our agent do not have limited capability but can work as standalone IDS. Different sites, with different vendors selected, can develop independently its own model of alarm network for detecting same kind of the attack, but agents will be able to communicate between themselves thanks to standard data format, exchange procedure and notation of the attacks.

228

D. Bulatovic and D. Velasevic

Beside standardization in messaging, in our approach is as well important introduction of Bayesian Management Information Base (BMIB) concept. BMIB will store information regarding the attack in progress and also historical security information. Based on hierarchical organization of networks, it is possible to develop distributed Intrusion Detection System that will use information from BMIBs and communicate with lower lever networks. With Bayesian alarm network in conjunction with Bayesian statistical techniques, we can easy overcome problem of missing data and facilitate the combination of prior knowledge and data especially in the case, (what is usual with Intrusion Detection), when no experiments are available. Finally with Bayesian alarm network we have no problem with different type of data as different type of attributes may be freely mixed. Bayesian alarm network in described framework can be used not only to detect intrusion but to play active role in protecting networks as well. Due to nature of Bayesian probability it could be able to prevent on going attack even if we have not evidenced that kind of attack before.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

R. Heady, G. Luger, A. Maccabe, and M. Servilla. The Architecture of a Network Level Intrusion Detection System. Technical report, University of NewMexico, Department of ComputerScience, August 1990. Crosbie M., October 1995. Defending a Computer System using Autonomous Agents. In Proceedings of the 18th NISSC Conference, October 1995. Maes P. 1993. Modeling adaptive autonomous agents.Artificial Life 1(1/2). S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, C. Wee, R. Yip, D. Zerkle, "GrIDS -- A Graph-Based Intrusion Detection System for Large Networks". The 19th National Information Systems Security Conference, 1996. M. Eichin and J. Rochis. With microscope and tweezers: An analysis of the Internet worm of November 1988. IEEE Symposium on Research in Security and Privacy, 1989. D. Seely. A tour of the worm. IEEE Trans. On Soft. Eng., November 1991. S. Cheung, K. N. Levit: Protecting Routing Infrastructure from Denial of Service Using Cooperative intrusion Detection. In Proceedings of New Security Paradigm Workshop, Cumbria, UK, September 1997. P. Cheeseman, J. Stutz, and R. Hanson: Bayesian classification with correlation and inheritance. Proceedings of 12th International Joint Conference On Artificial Intelligence pages 692-698, San Mateo, California, 1991. K. Fukunaga. Introduction to Statistical Pattern Recognition. Academic press, New York, 1990. D. Heckerman, Probabilistic Similarity Networks. MIT Press, 1991. G. Finn, “Reducing the Vulnerability of Dynamic Computer Networks," ISI Research Report RR-88-201, University of Southern California, June 1988. T. Apostolopoulos,V. Daskalou: “On the implementation of a Prototype for Performance Management Services”, Proceedings of IEEE Int Symp. on Computers and Communications, ISCC’95, 1995. D. Comer, “Internetworking with TCP/IP." Vol.1, Prentice Hall, 1991. R. Perlman, “Interconnections: Bridges and Routers." Addison-Wesley, 1992. Biswanath Mukherjee, L Todd Heberlein and Karl N Levitt. Network Intrusion Detection, IEEE Network, May/June 1994, pages 26-41.

Interoperability Characteristics of S/MIME Products 1

2

1

2

2

Sarbari Gupta , Jerry Mulvenna , Srinivas Ganta , Larry Keys , and Dale Walters 1

CygnaCom Solutions, Inc., 7927 Jones Branch Drive Suite 100W, McLean, VA {sgupta, sganta}@cygnacom.com 2 National Institute of Standards and Technology, Gaithersburg, MD {mulvenna, keys, walters }@csmes.ncsl.nist.gov

Abstract. S/MIME is based upon the popular MIME standard, and describes a protocol for adding cryptographic security services through MIME encapsulation of digitally signed and encrypted objects. The S/MIME version 2 specification was designed to promote interoperable secure electronic mail. However, because the specification allows multiple interpretations and implementations, and is sometimes silent about key aspects that affect interoperability, a number of “S/MIME Enabled” products are available on the market that are incapable of fully interacting with one another. In this paper, we present a set of characteristics that affect the interoperability profile for a given S/MIME application, and illustrate how they may be used to achieve a higher level of interoperability within the family of S/MIME compliant products. We also analyze the S/MIME version 3 specification to determine what subset of the identified interoperability characteristics still remain to be adequately addressed.

1

Introduction

S/MIME (Secure / Multipurpose Internet Mail Extensions) is a specification for securing electronic mail. S/MIME is based upon the popular MIME standard, and describes a protocol for adding cryptographic security services through MIME encapsulation of digitally signed and encrypted objects. The exact security services offered by S/MIME are authentication, non-repudiation, message integrity, and message privacy. The S/MIME Version 2 specifications were designed to promote interoperable secure electronic mail, such that two compliant implementations would be able to communicate securely with one another [6, 7]. However, because the specification allows multiple interpretations and implementations, and is sometimes silent about key aspects that affect interoperability, what has resulted is the availability of multiple S/MIME compliant commercial products that are not capable of fully interoperating with one another with respect to secure messaging. Recently, the S/MIME Version 3 specifications were passed by the IESG (Internet Engineering Steering Group) and are in the process of being published as RFC (Request For Comment) standards by the IETF (Internet Engineering Task Force) [8, 9]. However, this paper describes the findings of a set of interoperability experiments that were conducted using commercial-off-the-shelf (COTS) S/MIME version 2 products from different vendors. The experiments were R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 229–241, 1999. © Springer-Verlag Berlin Heidelberg 1999

230

S. Gupta et al.

designed to test the interoperability between peer S/MIME applications, between S/MIME applications and Certification Authority products, and between S/MIME applications and Directories. Other groups have also conducted tests on S/MIME applications and have published results [10]. All of the S/MIME implementations tested have been awarded the “S/MIME Enabled” seal based upon compliance tests conducted by RSA Labs. [Appendix A lists the actual products that were used in the tests.] Yet, there were a significant number of scenarios, where interoperability between the implementations was either limited or unachievable. From the test results, we concluded that there are a number of characteristics or properties that affect the interoperability of a given S/MIME application with other S/MIME applications, Certification Authority products and Directory products. These characteristics are neither part of the S/MIME version 2 specifications, nor do they appear in the S/MIME compliance testing methodology adopted by RSA. The recently approved S/MIME version 3 standard addresses some, but not all of the characteristics described in this paper. In this paper, we discuss these characteristics and illustrate how they affect the interoperability profile for a given S/MIME application. Interoperability is a prime concern of users of S/MIME implementations. Awareness of these characteristics may help to fine tune the S/MIME specifications to support a greater level of interoperability. They may also help the developers of S/MIME applications to make design decisions that would further the cause of interoperability. Additionally, these characteristics may help individuals who are procuring S/MIME applications to differentiate between the available implementations and select the one that most closely meets their interoperability needs. Finally, although these characteristics were derived from tests conducted upon S/MIME implementations, they may be applied to any end-user security application that requires a public key infrastructure. The rest of this paper is organized as follows. Section 2 describes the necessary background including the evolution and current status of the S/MIME specification. Section 3 describes a categorized set of characteristics that impact the ability of an S/MIME implementation to interoperate with other implementations. Section 4 discusses how the findings in this paper can be used to attain a higher level of awareness about the potential bottlenecks to interoperability. Section 5 analyzes the S/MIME version 3 specifications to identify the S/MIME interoperability characteristics that have been adequately addressed, and the ones that still need more attention at the specification level. Finally, our conclusions are presented in Section 6.

2 2.1

Background Evolution of the S/MIME Standard

The Multipurpose Internet Mail Extension (MIME) was also developed by the IETF, and was designed to support non-textual data (such as graphics data or video data) as the content of an Internet message [4,5]. Additional structure was imposed on the MIME message body to provide an encryption and digital signature service as part of the S/MIME specification.

Interoperability Characteristics of S/MIME Products

2.2

231

S/MIME Version 2

The S/MIME specification uses data structures that conform to Public Key Cryptographic Standard (PKCS) #7 [1]. PKCS #7 is a cryptographic message syntax that is designed to specify the content and form of the information that is required in order to provide an encryption and digital signature service. S/MIME implementations support several different symmetric content encryption algorithms. The RC2 algorithm with a key size of 40 bits is supported, even though it provides weak encryption, in order to comply with U.S. export regulations. In addition, in most S/MIME implementations, the user can choose DES, Triple DES or RC2 with a key size greater than 40 as the content encryption algorithm. The user can normally select either SHA-1 or MD5 as the message digest algorithm; the receiver’s application must be able to process both algorithms. The sender’s system must use the RSA public key algorithm with a key size ranging from 512 to 1024 bits to sign a message digest or to encrypt the content encrypting key A Certification Authority (CA) issues certificates that bind the identity of a public key to a user. This binding is only as strong as the out-of-band verification that the CA performs before issuing the certificate. Since many CAs can issue certificates, there must be a method of establishing trust among CAs so that each user can trust the information in a certificate issued by a CA other than his own. After the public certificate is issued, there must be a method by which the certificate is made available to other users. The certificate must be in a standard format so that the information in the certificate can be processed by applications built by different vendors. Deployment of S/MIME secure e-mail implementations requires a supporting Public Key Infrastructure (PKI) to provide solutions for the issues listed above. In some cases, standards have already been developed and implemented to provide this infrastructure. There is agreement that the certificate format will conform to Version 3 of the International Telecommunications Union (ITU) x.509 Recommendations. There is agreement that the Lightweight Directory Access Protocol (LDAP) is the protocol that will be used to access the directories that function as certificate repositories. PKCS#10 specifies the format for a request for a CA to issue a certificate [2]. 2.3

S/MIME Version 3

The S/MIME Version 3 specification [8, 9] is based on the usage of data structures from the Cryptographic Message Syntax (CMS) published as an RFC [11] by the IETF. CMS is derived from PKCS#7 version 1.5. The changes were designed to accommodate key agreement techniques for key management and the support of attribute certificates. Version 3 products are mandated to support the use of DSA (Digital Signature Algorithm) for signatures, and DH (Diffie-Hellman) for key establishment. The use of RSA for signature and key exchange is not mandated, but is specified as desirable. The symmetric encryption algorithm that must be supported by all Version 3 implementations is Triple DES (DES EDE3 CBC). 40 bit RC2 is supported as a nonmandatory algorithm to allow backward compatibility with Version 2 implementations.

232

S. Gupta et al.

Version 3 specifies a number of attributes that may be sent within the CMS message as either signed or unsigned attributes. Receiving agents must be able to process these attributes. The signed attributes that may be included in a Version 3 message are, signing time, S/MIME capabilities, S/MIME encryption key preference, and signing certificate. It may be noted that the Version 3 specification implicitly supports the usage of separate key pairs (and hence certificates) for signature and key exchange. The S/MIME capabilities signed attribute allows the sender to specify their algorithmic preferences in the order of preference. This allows a peer to select the algorithms that are appropriate. Both opaque as well as multipart formats are supported for signed messages in Version 3, but neither one is specified as being mandatory for sending or receiving agents. The support for messages that carry only certificates to the peer is supported in Version 3, thus allowing in-band certificate distribution. Certificates and certificate revocation lists used within Version 3 implementations must be compliant with [1]. Receiving agents must validate peer certificates (including revocation checking) for all messages. Version 3 also supports the use of X.509 attribute certificates. Receiving agents must be able to handle messages that contain no certificates using a database or directory lookup scheme. 2.4

S/MIME Compliance Tests from RSA

S/MIME products are being developed to interoperate with the products of different vendors. When they purchase an S/MIME product, users want to know that they can exchange signed and encrypted messages with any other S/MIME user. RSA Data Security has set up an S/MIME Interoperability Center that allows vendors to perform interoperability testing on their products and to have the results published. The RSA Interoperability Test Center was established in 1997. Participating vendors test against WorldTalk’s WorldSecure Client which is the designated reference implementation. All vendors participating in the testing use Verisign’s Class 1 public key certificates. The vendor first sends a signed message containing a public key certificate to the reference implementation and receives two signed and encrypted messages in return. One message uses RC2 as the content encryption algorithm; the second message uses Triple-DES for content encryption. Both messages contain a secret phrase. The vendor decrypts the messages, extracts the secret phrases and includes them in the messages sent back to the reference implementation, using the same content encryption algorithm. If the reference implementation can recover the secret phrases, the successful test results will be posted on the S/MIME Interoperability Test Center Web Page (www.rsa.com/smime). As of January 1999, more than 20 different S/MIME products have been successfully tested. [Appendix B lists the products that have been awarded the S/MIME compliance seal by RSA Labs.] The testing, while providing useful information is limited in scope. It doesn’t test the ability of an S/MIME implementation to interact with a certificate repository in order to publish or obtain a public key certificate. It doesn’t test the ability to process certificates issued by different Certification Authorities or the ability to process Certification Revocation Lists. It also doesn’t follow that, because the

Interoperability Characteristics of S/MIME Products

233

implementations test successfully with the reference implementation, they will successfully test with each other.

3

Interoperability Characteristics

This section describes characteristics and properties that are pertinent to the ability of an S/MIME implementation to interoperate with peer implementations, Certificate Authorities, and Repositories. The properties are categorized into sets that affect a particular area of operation of a specific implementation. 3.1

Certificate Handling

This section describes characteristics related to the management and use of certificates within an S/MIME implementation. Managing Certificates for Local User. The local user is the human entity that controls an S/MIME application to send and receive secure email with its peer entities. Distinct Signing and Encryption Certificates for Local User. The S/MIME Version 2 specification calls for the use of a single certificate for signing outgoing email as well as receiving incoming encrypted email. Most currently available S/MIME implementations support a single certificate for the local user running the S/MIME application. S/MIME Version 3, however, supports the use of separate certificates for signatures and encryption, and a small set of S/MIME implementations implement this two-certificate scheme [8, 9]. An S/MIME application that only supports a single certificate for encryption and signatures may be unable to communicate securely with a peer that supports a dual certificate scheme. For example, a typical S/MIME implementation will try to use the certificate used to validate a signed message from a peer to send encrypted message to that peer entity. However, if the peer happens to be a dual-certificate-based implementation, it will reject the incoming encrypted message since it will not be able to use its own encryption certificate to decrypt the message. Thus, single certificate implementations provide the greatest level of interoperability in the current S/MIME version 2 space of products. If dual-certificate implementations are used, it is recommended that users identify the same certificate as the signature as well as the encryption certificate. Self-Signed Certificate Support for Local User. The use of the security features of S/MIME within a group of peer entities is predicated upon the availability of a PKI that allows an entity within the group to establish trust in the public key certificates of every other entity within the group. However, the deployment of large-scale public key infrastructures has been neither easy nor widespread. In the absence of a PKI, certain trust models allow a small group of peers to trust one another implicitly. This is typically achieved by exchanging certificates via some secure means and trusting

234

S. Gupta et al.

peer certificates implicitly, as opposed to trusting them via certificate path validation to a trusted anchor or root certificate. A subset of the S/MIME implementations that are currently available support the use of an implicit trust model using self-signed certificates. Self-signed certificates accompanying incoming signed messages from peers can be implicitly trusted and used to send encrypted messages to the peer entity. Other S/MIME implementations do not allow the use of self-signed certificates either for the local user or their peers. To allow rapid deployment of S/MIME in an environment where PKI path-based trust cannot be established, it is preferable to use S/MIME implementations that support an implicit trust model. Single / Multiple Certificates for Local user. Some S/MIME applications have the capability to support multiple certificates for the local user. This allows the local user to belong to multiple PKI hierarchies simultaneously, selecting the certificate to use when interacting with a particular peer. For example, user A belong to infrastructures X and Y and has certificates Kx and Ky from infrastructures X and Y respectively. Entity B belongs to infrastructure X and can only validate certificates in X; entity C belongs to infrastructure Y and can only validate certificates within Y. When interacting with B, A selects certificate Kx. Likewise, A selects certificate Ky when interacting with C. Support for multiple certificates for the local user is thus a very desirable attribute in an S/MIME application. Ability to Import PKCS #12 Credentials for Local user. PKCS (Public Key Cryptography Standards) #12 is a de-facto standard from RSA Laboratories for securely packaging credentials (public and private key pairs) for transport or storage [3]. Many S/MIME applications have built-in or companion modules that generate key pairs, and are able to dispatch certificate requests to Certification Authorities using the newly generated public key. In such cases, the ability to import PKCS#12 objects is not necessary. However, there are two situations where it becomes important for an S/MIME application to import PKCS#12 objects. In the first situation, a Certification Authority may perform key pair generation for every certificate issued by it; a PKCS#12 object is then sent back to the S/MIME user for import into the S/MIME application. In the second case, a key pair and certificate may be held within an external module (such as a browser,) and the user may be interested in importing the same set of credentials for use within the S/MIME application. The ability of an S/MIME implementation to import and use PKCS#12 objects thus affects its interoperability with CAs and the ability to share digital credentials with other PKI-based applications. Managing Peer Certificates. Self-Signed Peer Certificate Support. The ability to support an implicit trust model using self-signed certificates from peers allows an S/MIME application to be fit for quick deployment in communities where a pervasive PKI is either lacking.

Interoperability Characteristics of S/MIME Products

235

Acquiring Certificates for Peers. Peer certificates are acquired by S/MIME applications in any of the following three ways: • • •

Extracting certificates from incoming signed messages from peers Loading certificates from *.p7c files Lookup of peer certificates from a LDAP Repository

The lack of support for one or more of the above may hinder an S/MIME application from obtaining certificates for peer users, and therefore, from being able to communicate securely with them. For example, if an S/MIME client application only has the capability to extract certificates from signed messages, then it cannot interact with a peer S/MIME application that does not send certificates along with a signed message. Support for Selective Trust of Peer Certificates. Occasionally, peer certificates that are acquired (through any of the mechanisms discussed in the last section) cannot be validated using any of the known trusted root keys embedded within the S/MIME application. In such cases, it is very useful if the S/MIME application provides the local user the ability to selectively trust peer certificates that have been acquired. Once the local user designates the peer certificate as trusted, secure, encrypted email can be sent to that peer. Managing Root Certificates. Most S/MIME implementation comes preloaded with a set of root certificates, all or a subset of which may be designated as trusted. These trusted root certificates are used to validate the certificates of peers. This section describes some attributes that affect the management of root certificates. Acquiring Certificates for Roots. Root certificates may be acquired via the same three ways (as mentioned in the last subsection) used to acquire peer certificates. Support for various means of acquiring root certificates for use within an S/MIME application allows it to use additional roots to establish trust in peer certificates. Conversely, lack of support for one or more of these ways, may disallow import of a particular root certificate, and prevent interoperability with a peer that is certified by that root authority. Selectively Trusting Root Certificates. Having acquired or imported additional root certificates into an S/MIME application, it is very useful to have the ability to selectively trust one or all of the newly imported root certificates. Thus, if the local user is given the opportunity to designate newly imported roots as trusted, it may allow the local user to establish trust in all certificates issued by these additional trusted roots. Conversely, if additional trusted roots cannot be established within an S/MIME application, it may be impossible to communicate with a large set of potential peers. 3.2

Interaction with Certificate Authorities

S/MIME users need to obtain certificates signed by Certification Authorities (CA) to communicate securely with peers. The only exception is when self-signed certificates

236

S. Gupta et al.

are used within a small well-known community to establish implicit trust in peers. Most S/MIME applications have associated modules or software tools that allow the generation of a key pair on behalf of the local user, and the construction and dispatch of a certification request to a CA. The certificate request message is based upon the PKCS#10 format as specified in the S/MIME Version 2 specification. Support for Multiple Mechanisms for Requesting Certificates from CAs. Certification Authorities or their delegates support one or more of the following transport mechanisms for incoming certification requests, and distribution of issued certificates: • • •

Web: The User’s Web Browser connects to the CA’s website to dispatch certification requests, or to collect an issued certificate. Email: The User sends an email to the CA’s email address with the certification request. The CA may send an email back to the User with a reference to the location where the issued certificate may be picked up. In-Person/Floppy/Smart Card: The User places the certification request on a floppy or similar physical medium and transports it to the CA or its delegate. The CA or its delegate may return the issued certificate on a floppy or other medium (such as a smart card) for import and use by the User’s application.

S/MIME applications that support all of the above mechanisms for interaction with a CA are able to request and receive certificates from the majority of CA products. 3.3

Interaction with Repositories

Certificate distribution in a small community may be achieved by users exchanging certificates with one another. However, the S/MIME Version 2 specification calls for the use of LDAP (Lightweight Directory Access Protocol) to interface with directories/repositories to obtain certificates and revocation information for users. Publishing local user certificate. Typically, the CA that issues a certificate is responsible for publishing it in a repository. However, some S/MIME implementations also have the ability to publish the local user’s certificate in a chosen directory. This feature is very useful in a domain where peers obtain each other’s certificate from an organizational directory. Publication in the directory makes the user’s certificate readily available to a large community of peers, and thus promotes interoperability. Peer Certificate Lookup. When an S/MIME application supports the lookup of LDAP-based Directories for peer certificates, it gives the local user access to a large set of potential peer certificates, and the ability to interact with these peers. 3.4 Signing Outgoing Messages This section describes various issues involved during signing of messages that may determine its level of interoperability.

Interoperability Characteristics of S/MIME Products

237

Support for Opaque/Clear Signed Message Formats. S/MIME Version 2 provides for two data signing formats. In the “clear” or multipart format, the signature is separated from the signed data and is sent as an attachment. There is both an advantage and a disadvantage in using this signing format. The advantage is that the recipient can always read the message even if the recipient’s e-mail application is not an S/MIME client and the signature cannot be verified. The disadvantage is that the message may undergo some format conversion as it transits a mail gateway that is not S/MIME- aware. This will cause the receiving S/MIME application to invalidate the signature. This can be corrected by binding the signature with the message in a single binary file. The resulting format is labeled the “opaque” format. No conversion will be performed by a mail gateway on the binary file and the message can be verified by an S/MIME application that serves the recipient. However, because the message text is wrapped in a binary file, the recipient cannot read it if the recipient’s e-mail application is not an S/MIME client. The existence of two possible signing formats has led to some difficulties in S/MIME interoperability. Some applications sign in “clear” format, some sign in “opaque” format; others give the user a choice. The applications that support both formats for outgoing signed messages are guaranteed to be able to successfully interoperate with every other S/MIME application. Support for Multiple Algorithms and Key Sizes. All currently available S/MIME implementations use RSA for signatures; the keys that are used vary between sizes 512/768/1024/2048. The hashing algorithm used within the signature could be SHA-1 or MD5. Some S/MIME applications support only a subset of the above algorithms for incoming signed messages. In order for two S/MIME implementations to exchange signed messages, they must support a common set of algorithms and key sizes. Thus the implementations that support both hash algorithms and various RSA moduli, and allow the local user to select the algorithms to use for specific outgoing signed messages enable the greatest level of interoperability with other S/MIME implementations. 3.5

Validating Incoming Signed Messages

Support for Opaque/Clear Signed Message Formats. Support for both signed message formats for validating incoming signed messages provides the highest level of interoperability with other S/MIME implementations that may support only one of the formats for outgoing signed messages. See similar subsection above for further details. Support for Multiple Algorithm Choices and Key Sizes. Support for multiple hash algorithms and various moduli for the RSA signature keys for validating incoming signed messages promotes interoperability with a large number of sending clients. See similar subsection above for further details. X.509v3 Certificate Path Validation. S/MIME Version 2 specifies the use of X.509v3 certificate path validation mechanisms for S/MIME implementations;

238

S. Gupta et al.

support for this type of path validation allows an S/MIME application to parse complex certificate chains to establish trust in peer certificates. All S/MIME applications that we have tested have the capacity to validate flat certification hierarchies, namely, the CA issues certificates to S/MIME users in a one level deep hierarchy. However, many implementations do not support the validation of certificates that are part of a multiple level hierarchy. In order to interoperate with the largest possible set of peers (some of which may send out signed messages with certificate chains that are part of a multiple level hierarchy), it is very useful if an S/MIME implementation supports fully compliant X.509v3 path validation. 3.6

Encrypting Outgoing Messages

In S/MIME, Version 2, an encrypted message is constructed as follows: a random symmetric key is used to encrypt the message, and the recipient’s public key is used to wrap the symmetric key for key transfer purposes. On the recipient’s side, the corresponding private key is used to unwrap the symmetric decryption key, and the latter is used to decrypt the message. Support for Multiple Algorithm Choices and Key Sizes. The S/MIME Version 2 specification allows the use of various symmetric algorithms and key sizes for message encryption, and various RSA moduli for key exchange. Currently, S/MIME applications support one or more of the symmetric encryption algorithms, DES, Triple DES and RC2, with various key sizes. In order for an encrypted message to be passed between two S/MIME applications, both sides must support the same encryption algorithm and key size, and the same modulus for RSA key exchange. Some implementations support only a single algorithm and key size for encryption, or a single modulus for RSA keys. The implementations that support all or a large subset of the available algorithms provide the greatest level of interoperability with peer implementations with a limited set of algorithms. 3.7

Decrypting Incoming Messages

Selection of Local User Certificate for decryption. When the local user possesses more than one certificate, and receives an encrypted S/MIME message, the correct certificate and private key needs to be selected to decrypt the message. Some implementations leave the selection of the appropriate private key (from the set of available private keys) to the user. Others allow a transparent selection of the appropriate private key for decryption; this is very useful feature in environments where users routinely possess certificates from multiple public key infrastructures, and use them for communicating with peers from disparate trust domains. Support for Multiple Algorithms and Key Sizes. See similar subsection above for details.

Interoperability Characteristics of S/MIME Products

4

239

Usefulness of the Interoperability Characteristics

The characteristics and properties outlined in this paper provide us with a greater insight into the issues that affect the interoperability of a S/MIME implementation in a real-world scenario. Ideally, the S/MIME specification should be capable of addressing each of these issues and setting minimum requirements to allow a base level of interoperability between all compliant implementations. Understanding the intricacies of the various choices that can be made within the scope of the S/MIME Version 2 specification may help to fine tune the future S/MIME specifications. Understanding the characteristics that affect interoperability also helps vendors of S/MIME products understand the implications of the implementation and design choices they make for their products. Knowledge of these characteristics is also important to the community of S/MIME product users and procurers. Users who are aware of their own environments with respect to the deployment of PKI products will be able to make an informed decision about which subset of the characteristics presented in this paper are relevant to their interoperability needs. Having defined their idealized profile for S/MIME products, they can then evaluate the available implementations from the various vendors and select the one that scores highest in the evaluation based upon their customized needs. The characteristics described in this paper were derived through a study of the S/MIME specification and experimentation with S/MIME implementations. However, we believe that a large subset of these characteristics are also applicable to most other public key infrastructure based secure communication protocols, and their implementations. The lessons learned through the study of S/MIME should be easily transferable to other similar domains.

5

Analysis of the S/MIME Version 3 Specifications with Respect to the Interoperability Characteristics

S/MIME Version 3 uses the CMS instead of the PKCS#7 standard to build the S/MIME objects. CMS supports a set of signed attributes that are encapsulated within the signerInfo data type that is a part of each S/MIME signed object. CMS allows object identifiers (OIDs) for preferred algorithms to be conveyed using these signed attributes. However, there does not appear to be a way to support the conveyance of other critical information for the sender, such as signature format preferences, or trust anchors known to the sender, etc. Additionally, these capabilities seem to be supported only when a signed message is sent. When the enveloped data content type is used, only a limited set of originator information (certificates and CRLs only) may be included in the message – there does not appear to be a way for the originator to include their algorithmic preferences to their peers. A deficiency that continues to exist in the Version 3 specification is that there is no mandate to support a particular signature format (opaque versus multipart). As we have noted in this paper, a number of the interoperability problems were related to the support of only one or the other signature formats in Version 2 products that we tested. It would be desirable to establish a baseline for the supported signature formats – this would allow a minimal level of interoperability between all S/MIME

240

S. Gupta et al.

implementations. Thus, we would recommend that the S/MIME specification be augmented to require that both sending as well as receiving agents MUST support the opaque signature format. In addition, sending and receiving agents SHOULD support the clear signing format to allow non-S/MIME capable mail agents to display the message contents. A desirable feature of Version 3 specification is that it supports the ability to dynamically import additional trust anchors into an S/MIME product. Receiving agents MUST support the import of additional trusted roots and certificate chains from incoming S/MIME messages. During the import of additional trust anchors, receiving agents SHOULD allow the user to select whether or not to trust new root certificates that were imported. Other methods to allow import of additional trust anchors would also be desirable (for example, the import of self-signed .p7c files from a floppy).

6

Conclusions

In this paper, we have described a number of important properties that affect the ability of an S/MIME implementation to interoperate with its peer implementations. However, there are other issues that also affect the suitability of an implementation within a particular environment. The usability characteristics of an implementation go a long way to promote the usage of the product. If secure email products provide daunting user interfaces, they will not be widely. One obvious recommendation to heightened user friendliness would be to transparently support the digital certificates of peers within the address book mechanisms provided by the basic email package. Thus, when a signed message comes in, the local user can add the sender to their local address book and thereby transparently add the sender’s certificate to the address book entry. Conversely, when sending out encrypted email, the local address book could be used to select the receiver and transparently select the receiver’s certificate (if present as part of the address book entry.) Most current implementations also have little or no support for revocation checking of certificates. As public key infrastructures become widely deployed, the very real management problems such as certificate revocation need to be handled within the applications using the infrastructure. In conclusion, we would like to point out that it is heartening to see the widespread adoption of the S/MIME secure electronic mail standard, and the availability of commercial products based upon the standard. Despite the fact that public key infrastructure technology is still in its infancy, and the standards are continuously evolving, the S/MIME vendors are making considerable progress in resolving the existing barriers to interoperability. In the near future, users will find that security services will be integrated into most e-mail applications.

Interoperability Characteristics of S/MIME Products

7

241

References

[1] Kaliski, B., “PKCS #7: Cryptographic Message Syntax Version 1.5”, RFC 2315, March 1998. [2] Kaliski, B., “PKCS #10: Certification Request Syntax Version 1.5”, RFC 2314, March 1998. [3] Kaliski, B., “PKCS #12: Personal Information Exchange Syntax Standard, Version 1.0 Draft”, 30 April 1997. [4] Postel, J., “Simple Mail Transfer Protocol”, RFC 821, Aug 1982. [5] Crocker, D., “Standard for the format of ARPA Internet text messages”, RFC 822, Aug1982. [6] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, “ S/MIME Version 2 Message Specification”, RFC 2311, March 1998. [7] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, “ S/MIME Version 2 Certificate Handling”, RFC 2312, March 1998. [8] Ramsdell, B., “S/MIME Version 3 Message Specification”, RFC 2633. [9] Ramsdell, B., “S/MIME Version 3 Certificate Handling”, RFC 2632. [10] Backman, D., “Secure E-Mail Clients: Not Quite Ready For S/MIME Prime Time. Stay Tuned”, Network Computing Online, http://www.networkcomputing.com/902/902r22.html. [11] Housley, R., “Cryptographic Message Syntax”, RFC 2630.

8

Appendix

These are the products that were tested in order to derive the characteristics described in this paper: • • • • • •

Baltimore Technologies MailSecure Exchange Plug-in Version 2.1 WorldTalk WorldSecure Eudora Plug-in Version 3.05 WorldTalk WorldSecure Exchange Plug-in Version 3.0 Netscape Messenger Version 4.05 Microsoft Outlook Express Version 5.0 Beta 2 Microsoft Outlook 98

The DEDICA Project: The Solution to the Interoperability Problems between the X.509 and EDIFACT Public Key Infrastructures Montse Rubia1,2, Juan Carlos Cruellas1, and Manel Medina1 1

Telematics Applications Group - Department of Computer Architecture Universitat Politècnica de Catalunya c / Jordi Girona 1-3, Mòdul D6 08034 - Barcelona (SPAIN) {montser, cruellas, medina}@ac.upc.es 2

Safelayer Secure Communications S.A. Edificio World Trade Center (s4) Moll de Barcelona s/n 08039 – Barcelona (SPAIN) [email protected]

Abstract. This paper introduces the barriers of interoperability that exist between the X.509 and EDIFACT Public Key Infrastructures (PKI), and proposes a solution to remove them. The solution goes through the DEDICA1 (Directory based EDI Certificate Access and management) Project. The main objective of this project is to define and to provide the means to make these two infrastructures inter-operable without increasing the amount of information to be managed by them. The proposed solution is a gateway tool interconnecting both PKIs. The main goal of this gateway is to act as a TTP that "translates" certificates issued by one PKI to the other’s format, and then signs the translation to make it a new certificate. The gateway will, in fact, act as a proxy Certification Authority (CA) of the CAs of the other PKI, and will take the responsibility of the certified data authenticity, on the behalf of the original CA.

1. Introduction The security services based on asymmetric cryptography require a Public Key Infrastructure (PKI) to make the public key values available. Several initiatives around the world have caused the emergence of PKIs based on X.509 certificates, such as SET (Secure Electronic Transaction) or PKIX (Internet Public Key Infrastructure). Another PKI type is the one based on the EDIFACT certificate. These infrastructures are not interoperable, mainly due to the fact that the certificates and messages are coded in different way (ASN.1 and DER are used for X.509 PKI, whilst EDIFACT syntax is used for EDIFACT PKI). 1

This project has been funded by the EU Telematics program and the Spanish CICYT, and has been selected as one of the pilot projects to promote the telematic applications by the SMEs by the G7.

R. Baumgart (Ed.): CQRE’99, LNCS 1740, pp. 242–250, 1999. © Springer-Verlag Berlin Heidelberg 1999

The DEDICA Project

243

DEDICA (Directory based EDI Certificate Access and management) is a research and development project. Its main objective is to define and to provide means to make the two above-mentioned infrastructures inter-operable without increasing the amount of information to be managed by them. The proposed solution involves the design and implementation of a gateway tool interconnecting both PKIs: the certification infrastructure, based on standards produced in the open systems world, and the existing EDI applications, which follow the UN/EDIFACT standards for certification and electronic signature mechanisms. The main goal of the gateway proposed by DEDICA is to act as a Trusted Third Party (TTP) that “translates” certificates issued in one PKI to the other’s format, and then signs the translation to make it a new certificate: a derived certificate. In this way, any user certified, for instance, within an X.509 PKI could get an EDIFACT certificate from this gateway without having to register in an EDIFACT authority, saving not only time and money, but also allowing the users to use the same private key for both environments. The gateway will act, in fact, as a proxy Certification Authority (CA) of the CAs of the other PKI. The figure 1 shows the DEDICA gateway context. Each user is registered in his PKI and accesses the certification objects repository related to its PKI. The DEDICA gateway must be able to interact with the users of both PKIs in order to serve requests from any of them. It must also be able to access the security object stores of both PKIs, and to be certified as EDIFACT and X.509 CAs.

CAE1

CAE2

Network

User E

Gateway certified by X.509 and EDIFACT CAs

CAX1

D EDI CA

CAX2

Network

User E

User X User X X.500 Directory

Certificates store

EDIFACT

X.509

Fig. 1. DEDICA gateway context.

244

M. Rubia, J.C. Cruellas, and M. Medina

2. Functionality of the gateway The interoperability problem between the X.509 and EDIFACT PKIs was focused by the DEDICA project in two levels: . 1. The different formats of the certificates: The DEDICA consortium, after an indepth study of the contents of both types of certificates, specified a set of mapping rules that makes possible the two-way translation of both types of certificates. 2. The different messages interchanged by the entities of the PKIs: whereas in the EDIFACT world the UN/EDIFACT KEYMAN message is used to provide certification services, in the X.509 world a set of messages specified for each PKI (PKIX on the Internet, for instance) are used. The DEDICA gateway assumes the role of a TTP for users of both infrastructures. The gateway accomplishes a process of certificate translation from EDIFACT to X.509 and conversely; however this translation process is not strictly a mapping at level of certificate formats, since the gateway adds a digital signature to the mapped data. In addition to that, in some cases, it is not possible just to move data from one certificate to the other, due to format restrictions (size, encoding). In these cases the gateway has to generate tagged data for the derived certificate, that will allow it to reproduce the original data, kept in internal records (e.g. names mapping table, see fig. 3). When the X.509 certificate has private extensions, the gateway will just ignore them, since they are assumed relevant only to other applications. Full details of the mapping mechanism between both infrastructures may be found at: http://www.ac.upc.es/DEDICA/ and at DEDICA CEC-Deliverable WP03.DST3: Final Specifications of CertMap Conversion Rules [5]. The DEDICA gateway is able to offer a basic set of certificate management services to users of different infrastructures: 1. Request of an EDIFACT certificate from an X.509 certificate generated by an X.509 CA. 2. Verification of an EDIFACT certificate generated by the DEDICA gateway (coming from the mapping of an X.509 certificate). 3. Request of an X.509 certificate from an EDIFACT certificate generated by an EDIFACT CA. 4. Verification of an X.509 certificate generated by the DEDICA gateway (coming from the mapping of an EDIFACT certificate). The above requests will be carried out making use of the appropriate messages from the infrastructure: KEYMAN PACKAGES for EDIFACT, and PKIX for X.509. 2.1. Request of a derived certificate In the scenario shown in Figure 2, an X.509 user (user X) that may want to send EDIFACT messages to an EDIFACT user (user E) using digital signatures or any security mechanism that involves the management of certificates. This user needs a certificate from the other Public Key Infrastructure (in this case, the EDIFACT PKI). He then sends an interchange to the gateway requesting the production of an EDIFACT certificate “equivalent” to its provided X.509 one. This interchange will

The DEDICA Project

245

contain a KEYMAN message (indicating a request for an EDIFACT certificate) and the X.509 certificate of this user in an EDIFACT package (EDIFACT structure capable of containing binary information). The gateway will validate the X.509 certificate. If the certificate is valid (the signature is correct, it has not been revoked, and it has not expired), it will perform the mapping process, and will generate the new EDIFACT certificate. After that the gateway will send it to user X within a KEYMAN message. Now user X can establish a communication with user E using security mechanisms that involve the use of electronic certificates through the new EDIFACT certificate, sending him an EDIFACT interchange with this certificate. 2.2. Validation of a derived certificate Following the process described in the previous section, user E, after receiving the interchange sent by user X, requests validation of the certificate generated by the DEDICA gateway by sending the corresponding KEYMAN message to the gateway. The gateway determines whether the EDIFACT certificate has been generated by itself, and proceeds with the validation of the original X.509 certificate, to find out whether it has been revoked or not, and of the derived EDIFACT certificate. The EDIFACT user could only check the derived certificate, since it has no access to the original environment. The general process of validation of derived certificates is as follows: 1. It verifies the validity of the derived certificate. This requires checking of: (a)The correctness of signature, using the public key of the gateway. (b) Whether the certificate can be used in view of the validity period. 2. The gateway accesses to the X.500 Distributed Directory, in order to get the original X.509 certificate and the necessary Certificate Revocation Lists (CRL). 3. It verifies the signature of the original certificate, and checks the validity period. 4. The gateway verifies the certification path related to the original X.509 certificate, and checks that its certificates have not been revoked. Now the DEDICA gateway will send the positive or negative validation response to the EDIFACT user within a KEYMAN message.

3. Gateway architecture The DEDICA gateway has two main architectural blocks: the CertMap and the MangMap modules. 3.1. CertMap module The CertMap module is responsible for performing the certificate translations following the mapping rules specified by the DEDICA consortium in Deliverables WP03.DST3 ([5]). The CertMap is composed of three main modules: the CM_Kernel module, the EDIFACT certificate coding/decoding module, and the set of APIs needed to allow

246

M. Rubia, J.C. Cruellas, and M. Medina

the CM_KE to interact with external software tools (the ASN.1 API and the Cryptographic API). The CM_Kernel module (CM_KE) coordinates the operations performed by all the other CertMap modules. Four groups of information presents in both certificates have been identified: Names, Algorithms, Time and Keys. For each one of these groups, inside the CM_Kernel, a software module implements the appropriate relevant translation process: the CM_Names, the CM_Algorithm, the CM_Time and the CM_Keys modules. Request of certificate KEYMAN UNO X.509 UNP

DEDICA

KEYMAN (EDIFACT Cert)

MangMap

CertMap

User X

User E

Secured Interchange & EDIFACT Certificate User X

User E

Validation of a derived certificate

DEDICA CertMap MangMap User X

KEYMAN (EDIFACT Cert) KEYMAN (Valid.result)

User E

Fig. 2. Functionality of the DEDICA gateway

Mapping between X.509 and EDIFACT certificates. The Certificate Mapping Rules developed in DEDICA were designed in such a way that the translated information was relayed as precisely as possible from the original certificate to the derived one. A number of issues had to be taken into account: • Specification syntax and transfer syntax for the transmission. The EDIFACT certificates are specified following the EDIFACT syntax, and they are transmitted coded in printable characters. However, in the X.509 environment the ASN.1 Abstract Syntax and the DER rules are used. • Naming System. In the X.509 world, the basic mechanism of identification is the DN (Distinguished Name) [6], which is associated with an entry in the DIT (Directory Information Tree) of the X.500 Distributed Directory. On the other hand, the EDIFACT certificate supports both codes (i.e., identifiers assigned by authorities) and EDI party names. The DEDICA gateway performs a name mapping between the DNs and the EDI Names, according to guidelines defined in EDIRA (EDIRA Memorandum of Understanding) [7]. EDIRA proposes an identification mechanism compatible with the DN strategy in X.500. The DEDICA Deliverable WP03.DST2([4]) contains the specifications of the conversion rules that are used by the CertMap module to execute the mapping between DNs and EDI Names.

The DEDICA Project

247

• Extension mechanism. Version 3 of the X.509 certificate has an extension mechanism that allows it to extend the semantics of the information that it carries out. However, at present the EDIFACT certificate does not have any extension mechanism, and its syntax specification does not allow to specify such a wide variety of information. In the mapping of X.509 certificates version 3, only the following extensions will be mapped: keyUsage and subjectAltName. Other extensions, mainly the private ones, even if they are tagged as critical for the intended applications of the original certificate, are ignored, since we assumed that user and issuer know and accept the EDIFACT certificate format, when they make the application for a derived certificate. • Digital signature. When the gateway finishes the mapping process, it automatically generates a new digital signature. In the certificate field identifying the issuer entity, the DEDICA gateway identifier will appear, instead of the original certificate issuer identification. The figure 3 shows the internal structure of the CertMap module. It also shows the sequence of operations that will take place inside the CertMap to generate an EDIFACT certificate from the initial X.509 one. ASN.1

Tool

(1) DER to internal representation CM_Names(CM_NM) CM_Algorithm(CM_AL) CM_Time(CM_TM) CM_Keys(CM_PK) (7) Return certificate to MangMap

To/ From

CM_Kernel (CM_KE)

(2) [ Mapping CM_EDICert(

process ] CM_Cert)

(3) Internal representation to EDIFACT coding

MangMap

CRYPTO

Tool

(4) Signature of EDIFACT coding CM_EDICert(

CM_Cert)

(5) Append signature: USC-USA(3)-USR (6) Add new entry Names

Mapping

Table

...

Fig. 3. Mapping process from X.509 to EDIFACT

3.2. MangMap module The MangMap module of the DEDICA gateway converts certain operations of the KEYMAN message into equivalent operations (messages) in the X.509 PKI (including X.500 access).

248

M. Rubia, J.C. Cruellas, and M. Medina

MangMap is also the general management module for DEDICA gateway. It receives all the requests sent to it and chooses which information has to be recovered from external repositories, what type of translation is needed, and what results must be generated and sent to the requesting entity. Internal structure of the MangMap module. The main blocks of the MangMap are shown in Figure 4, and its functionality may be summarised as follows: • MangMap Kernel (MK) module The Kernel module of the MangMap controls all the actions within the DEDICA gateway and co-ordinates the co-operation between the different DEDICA modules. • KEYMAN Handling (KH) module On reception of KEYMAN messages from an end user, it checks the protection applied to the KEYMAN, analyses it, interprets the message and converts it into an internal request to the MangMap Kernel block. On reception of requests from the MangMap Kernel block, it builds KEYMAN messages, applies the required protection and makes the KEYMAN available to the communication services. • X.509 Public Key Infrastructure Messages Handling (XH) module On reception of relevant X.509 public key infrastructure messages from an end user, XH module checks the protection applied to the message, analyses it and converts the message into an internal request to the MK.

EDIFACT Certificates Directory

X.500 Directory

MangMap Module EDIFACT applications (EA)

KEYMAN Handling (KM)

X.500 Access Handling (XH)

EA/SM KM/MK MK/KH Security Module (SM)

MangMap Kernel (MK)

EDI user

CertMap Module (CM)

DEDICA gateway

Fig. 4. Structure of the DEDICA gateway

X.500 User

The DEDICA Project

249

XH is also able to access the X.500 Directory in order to get X.509 certificates, revocation lists and certification paths. XH will be able to send requests to X.500 and to obtain and interpret answers from it. Due to the complexity of DAP, the XH module uses the LDAP (Lightweight Directory Access Protocol) [8] interface to access the X.500 Directory. LDAP offers all the functionality needed to interact with the X.500 Directory at much lower cost. On reception of requests from MK, it builds relevant X.509 public key infrastructure messages, applies the required protection and makes the messages available to the communication service.

4. Conclusions This work has proved the suitability to launch a TTP service to translate security objects between different protocol environments. The problems found in this project are of general nature, and the solutions adopted here may be extrapolated to any other pair of environments. Other arising PKI services, like SPKI or UMTS (Universal Mobile Telephone System), or XML-EDI are potential candidates to use the results of this work. But it will be possible to extend the results of this work to other TTP services, like Time Stamping, Attribute certification, etc. The data type conversion based on translation table may solve any format incompatibility, and the message mapping strategy used to handle the different certificate management strategies may also overcome with almost any mismatching services between the two protocols being linked. As far as both, environments and protocols, have the same goals, the details of data and service elements not having a corresponding element on the other environment may either: a) be just overridden because it is not useful in the destination application, or b) be replaced by an equivalent data or service element with similar meaning in the destination protocol. The interoperability between the X.509 and EDIFACT PKIs can be greatly enhanced by facilities such as the DEDICA gateway, which acts as a TTP capable of offering a basic set of certificate management services to users of both infrastructures. The DEDICA project has set up a gateway to translate the security objects between X.509 and EDIFACT. This solution also provides interoperability between EDIFACT and all the other tools used in electronic commerce, since all of them authenticate the entities using X.509 certificates. The DEDICA gateway is being integrated in several pilot schemes and projects in the context of electronic certification, such as the TEDIC system, the AECOC-UPC EDI over Internet project, or in the SAFELAYER2 X.509 Certification Authority. The DEDICA service is interesting to both the large enterprises and SMEs, although this gateway is mostly interesting to SMEs. This is because it allows them to use security in the interchange of messages, without the need to pay registration fees

2

Safelayer Secure Communications S.A. is a company provider of PKI and SET software solutions

250

M. Rubia, J.C. Cruellas, and M. Medina

in several infrastructures. This was the reason for which DEDICA was selected as one of the G7 pilots projects to promote the use of information technology by the SMEs. The main advantage for the user will be to share the authentication mechanism (digital signature, tools, etc.) between the various applications where they can be applied, avoiding the burden of having to register with various services in order to satisfy one single user requirement. Moreover, the service has been quickly deployed and made available, thanks to the fact that no additional registration infrastructure is needed, due to its compatibility with the EDIFACT and X.509 infrastructures. This service will promote the use of Internet by EDI applications (since it will allow them to secure the interchanges which has been identified) in spite of the major barriers to the deployment of EDI over Internet in the past. Within the project, several pilot schemes have been launched to demonstrate the system in the following fields: customs, electronic chambers of commerce, tourism, electronic products manufacturers, EDI software providers and electronic payment in banking and public administration.

References 1. Security Joint Working Group, Proposed Draft of a MIG Handbook UN/EDIFACT Message KEYMAN, 30. June 1995. 2. Security Joint Working Group: Committee Draft UN/EDIFACT CD 9735-5, Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) - Application Level Syntax Rules, Part 5: Security Rules for Batch EDI (Authenticity: Integrity and NonRepudiation of Origin, Release 1, 14. December 1995. 3. DEDICA Consortium, CEC Deliverable WP03.DST1: Technical description of X.509 and UN/EDIFACT certificates, July 1996. 4. DEDICA Consortium, CEC Deliverable WP03.DST2: Naming Conversion Rules Specifications Requirements, July 1996. 5. DEDICA Consortium, CEC Deliverable WP03.DST3: Final Specifications of CertMap Conversion Rules, July 1996. 6. Network Working Group, RFC 1779: A String Representation of Distinguished Names, ISODE Consortium, 1995. 7. EDIRA - Memorandum of Understanding for the Operation of EDI Registration Authorities, Final Draft. November, 1993. 8. Network Working Group, RFC 1959: An LDAP URL Format, 1996. 9. PKIX Working Group, INTERNET-DRAFT: Internet Public Key Infrastructure, X.509 Certificate and CRL Profile, 1997. 10. Fritz Bauspieß, Juan Carlos Cruellas, Montse Rubia, DEDICA Directory based EDI Certificate Access and Management, Digital Signature Conference, July 1996. 11. Juan Carlos Cruellas, Damián Rodriguez, Montse Rubia, Manel Medina, Isabel Gallego, WP07.DST2. Final Specification of MangMap Conversion Rules, DEDICA Project, 1996. 12. Juan Carlos Cruellas, Damián Rodriguez, Montse Rubia, Manel Medina, Isabel Gallego, WP07.DST1. Final Specifications of MangMap, DEDICA Project, 1996.

Multiresolution Analysis and Geometric Measures for Biometric Identification Systems Raul Sanchez-Reillo1 , Carmen Sanchez-Avila2 , and Ana Gonzalez-Marcos1 1

2

Universidad Politecnica de Madrid. E.T.S.I. Telecomunicacion. Dpt. Tecnologia Fotonica. Ciudad Universitaria s/n. E-28040 Madrid, Spain {reillo, agonmar}@tfo.upm.es Universidad Politecnica de Madrid. E.T.S.I. Telecomunicacion. Dpt. Matematica Aplicada. Ciudad Universitaria s/n. E-28040 Madrid, Spain [email protected]

Abstract. The authors describe here their work in two different biometric techniques: iris pattern and hand geometry. These two techniques require very different processing algorithms, achieving good results for two different security environments. While iris pattern is a high cost and very high reliability technique, hand geometry is low cost, highly accepted and provides medium/high security. Adaptive techniques have been studied for increasing hand geometry reliability while new processing algorithms, such as symmetric real Gabor filters, have been used to decrease the computational cost involved in iris pattern recognition. The target of adapting these biometric techniques for small embedded systems, comes with the design of new Biometric Systems, where the user’s template is stored in a portable storage media. This media can also be used to store some user’s sensible information, such as his health record, and new access conditions are designed to avoid the reading of this data unless the biometric verification has been performed. The media chosen has been a smart card, and a new requirement is established: biometric verification (hand or iris) should be performed inside the smart card, in order to not be able to extract the user’s template from the card.

1

Introduction

Nowadays, one of the main threats that IT systems and security environments can have, is the possibility of having intruders in the system. This is normally solved by user authentication schemes based on passwords, secret codes and/or identification cards or tokens. Schemes based only on passwords or secret codes can be cracked by intercepting the presentation of such a password, or even by counterfeiting it (via passwords dictionaries or, in some systems, via brutal force attacks). On the other hand, an intruder can attack systems based on identification card or tokens by robbing, copying or simulating that card or token. If the scheme used in the system is based both on a card and a password (usually called Personal Identification Number - PIN), the intruder should apply R. Baumgart (Ed.): CQRE ’99, LNCS 1740, pp. 251–258, 1999. c Springer-Verlag Berlin Heidelberg 1999

252

R. Sanchez-Reillo, C. Sanchez-Avila, and A. Gonzalez-Marcos

more effort to gain entry to the system, and with more advanced technologies, such as smart cards, some vulnerabilities of the system could be avoided (e.g. brutal force attacks are impossible under a well-defined smart card). But even with the most advanced techniques, authentication schemes based on passwords and identification cards have a legal limitation: a person cannot be legally identified by the knowledge or possession of something, but only by the measure of some biological behavioural features. This requisite is only solved by biometric techniques such as speaker verification, signature recognition or measurement of fingerprint, iris pattern or hand geometry. Each biometric technique has its own advantages and disadvantages. While some of them provide more security, i.e. lower False Acceptance Rate (FAR) and False Rejection Rate (FRR), other techniques are cheaper or better accepted by final users. The authors report here a biometric R&D project where two biometric techniques have been analysed and developed: iris pattern and hand geometry. Iris Pattern Recognition was chosen for providing an extremely high reliability biometric identification. Its reliability is only improved by Retinal Scanning which is highly rejected by final users for using laser scanning inside the eye. The main disadvantage of this technique is only its high cost, not only economical but also computational. On the other hand, Hand Geometry Measurement was chosen as a medium/high security technique with a medium equipment cost, low computational cost and very low template size. After this introduction, a brief explanation of both systems (first iris pattern, followed by hand geometry) will be given. Then main results achieved with both techniques will be shown, ending this work with the final conclusions obtained.

Fig. 1. Samples of iris (in the left) and hand (in the right), before preprocessing and feature extraction

2

Iris Pattern Recognition

From all biometric techniques known today, iris recognition is considered to be the most promising of all for high security environments. This technique presents

Multiresolution Analysis and Geometric Measures

253

several advantages compared to other techniques, with only one main disadvantage: the cost. But considering the overall costs that suppose the installation of a high security system, this disadvantage could be minimized. Iris recognition is based on the characterization of the pattern of the iris. Medical and forensic studies have proven that an iris has higher unicity than other techniques, i.e. the probability of finding two iris patterns identical is nearly null (identical twins do not have the same iris pattern and even the two eyes of the same person have different patterns). Another strong characteristic of this technique is the stability of the pattern. After the adolescence the pattern has completely evolved and the protection of the cornea makes any modification in the pattern impossible, unless a major injury destroys part of the eye and, of course, the vision of the user. Biological studies have affirmed that the iris pattern is not influenced by age, and even common vision illness as myopia or cataract do not affect irises in any sense. The excellent unicity of this technique leads to a False Acceptance Rate (FAR) nearly null, while its stability allows to reach really low False Rejection Rates (FRR). Iris recognition systems do not suffer from high user rejection due to the use of video or photograph cameras, instead of laser beams such as the ones used for retinal scanning which leads to consider the latter technique somehow invasive. Counterfeiting an iris is nearly impossible unless a whole surgery is made in the eye with the threat of losing the vision in that eye. The use of contact lenses with a copy of other user’s pattern printed on it is easily detected because of the continuous involuntary movement of the iris, which is not present in a printed one. 2.1

Preprocessing, Feature Extraction and Verification

As the first process, the iris location and isolation is performed. This is performed taking profit from the circular pattern of the iris within the eye studying the first derivate of the intensity of the image around a circle with fixed centre and variable radiuses ∂ ∂r

I x0 ,y0 ,r

I(x, y) ds . 2πr

(1)

The same process is performed to eliminate the pupil from the iris. Once isolated, the resulting image is stretched for better processing. Then wavelet multiresolution analysis is carried out. Several multiresolution algorithms have been studied (e.g. [2], [5] and [6]) achieving best results with real symmetric Gabor filtering    1 (x cos θ + y sin θ)2 (x sin θ − y cos θ)2 G(x, y) = exp − + 2 δx2 δy2 · cos(2πω(x cos θ + y sin θ)).

(2)

254

R. Sanchez-Reillo, C. Sanchez-Avila, and A. Gonzalez-Marcos

After obtaining the wavelet coefficients, a reduced set of them has been selected through principal component analysis. With the set of data chosen, a primary pattern is formed. This pattern is used in three statistical decision schemes for the verification process: Euclidean and Hamming distances and Gaussian Mixture Modelling (GMM) [7]. In this application, distances between authentic eyes and imposters are so different (around 0.1 for authentics and 0.5 for imposters), that a universal threshold could be applied, being sufficient the usage of Euclidean and Hamming distances instead of GMMs, with the advantage of lower computational cost of the former two compared with the latter.

3

Hand Geometry Measurements

The importance of hand geometry as a biometric technique relies on its medium/low cost and on its great acceptance by the user based on the following three main points: it has not any police implication (e.g. fingerprint verification is closely related to police for most of the users), the system is really easy to use (not like speaker verification without being through a telephone or iris recognition) and it does not imply physical invasions of user’s vital organs (such as eyes in retinal scanning). As it will be shown, there are other facts that make hand geometry an optimal solution for some security environments, such as the template size which is the lowest of all the biometric techniques existing today. But the main disadvantage of this technique is the ”lack” of security. Compared to commonly considered high security methods (like fingerprint, iris and retinal scanning), hand geometry FAR and FRR figures are much higher, due to the lower unicity and stability of the hand template compared with the abovementioned techniques. Unicity and stability are two characteristics of a biometric technique that can be studied separately. Because of the low unicity of the geometry of the hand (i.e. the possibility of finding two hands identical), this technique is not recommended for high security environments, but the level of security it gives, makes this technique valid for medium security access control systems or ATMs. The low stability of the hand geometry is a problem that can be solved in two ways: by performing relative measures and/or by adapting the template each time the user is authenticated by the system. 3.1

Capture, Preprocessing, Extraction and Verification

As in any biometric system the first step is the signal capture. In hand geometry a digital camera is used for this task. The image captured shows not only the reverse of the palm but also the lateral view of the hand which will serve as a weighting factor for the features extracted. The photo will be taken when the hand is correctly placed in the system, as it will be indicated by position and pressure sensors. Applying gradient ascent techniques, the edge of the hand is quickly obtained, and ready to perform the feature extraction. Several parameters were measured, from the width of the palm and fingers, to the length and height of the latter. The

Multiresolution Analysis and Geometric Measures

255

angles formed in the phalange joints were also taken into account. A principal component analysis has been done to select the parameters that will be used in the user’s template. Absolute measures, as well as relations between them have taken part in the analysis. Corrections have been made according to the pressure done by the user. The analysis showed that even with a low number of parameters, such as 10 of them, satisfactory figures for FAR and FRR have been obtained. Increasing the number of parameters, FAR and FRR data could be decreased. With proper parameter codification, the template size could be from 9 to 25 bytes, which makes this technique ideal for minimizing template storage and lowering computational cost of the verification process. After analysing different verification methods, from the ones based in metrics (e.g. Hamming and Euclidean distances), to the ones based on the statistical decision theory (e.g. Gaussian mixture modelling), and considering the neural network approach with MLP and radial basis functions, the results obtained show that the method with the best rate between computational cost and FAR+FRR is the Hamming distance, although for best reliability GMMs are recommended (as seen in the next section). 3.2

Stability Improvement

With the system developed as explained above, overall error rate is below 5%. The relation between FAR, FRR and this rate could be modified (as said) playing with the threshold value, depending on the specific needs of the system. But the stability limitations that this technique has, are shown when this system is used over a long period of time. Adult users gaining or losing weight can change absolute measures, and if the weight difference is large enough, even a change can appear in the relative measures. On the other hand, non-adult users (i.e. users in their growing years), change continuously their measures. Although the latter case is not important in most environments, the improvement reported by the authors also solves it. This improvement is validated based on two hypotheses: Hypothesis 1. The gaining or losing of weight or height, involve homogeneous changes in hand geometric measures, changing absolute measures but not the relative ones. Hypothesis 2. The speed of changing the hand features, is slow enough to consider that no important variation will occur in a period of one week. The first hypothesis solves most of the problems by taking relative measures instead of absolute ones. Thanks to the second hypothesis, stronger protection can be included in the biometric templates through adaptation. This adaptation should consider not the change in a single attempt, but the evolution of a set of them. For example, the last five successfully recognized attempts could be averaged with the template, after using a weighting factor for each of these

256

R. Sanchez-Reillo, C. Sanchez-Avila, and A. Gonzalez-Marcos

measurements, which depend on the period of time among them. With these improvements, the stability of the features is increased and therefore, FRR figures remain the same throughout time. With this average process, influence of a potential intruder wrongly recognized as the user authenticated, is reduced. If the system is based on the storage of the templates in a user’s smart card, instead of in a central database, the threat is decreased even more, and because this technique uses a very small template, no memory limitations exist and the average could be performed even with the last ten or twenty successful attempts. Furthermore, the mathematical operations involved in the whole process are simple enough to enable processing times much below the ones needed for other techniques and with less powerful microprocessors (e.g. using 8-bit processors).

4

Results Obtained and Conclusions

After designing and developing the biometric systems explained above, the main results obtained have been as expected, with null FAR for iris pattern recognition and FRR much lower than the one obtained for hand geometry (see Fig. 2). However, iris feature extraction should be improved to lower the FRR without increasing the computational cost.

Fig. 2. FAR and FRR for iris pattern recognition and hand geometry measurement

On the other hand, the results obtained with hand geometry measurements are very satisfactory, being able to achieve overall error rates below 5% with a GMM based verification algorithm. If computational cost is a high restriction, Hamming distances can mean an alternative with the sacrifice of increasing the overall error rate up to 12%, as it can be seen in the next illustration. Finally the performance of the hand biometric system has been analysed throughout 9 months, with and without the stabilization improvement, showing an increase of the FRR when no adaptation is present and absolute measurements are used, while with the stabilization the overall error rate has been kept in similar figures.

Multiresolution Analysis and Geometric Measures

257

Fig. 3. Overall error rates and time consumed in verification (of the whole process time) in hand geometry biometric system, with Hamming and GMM based verification algorithms

Fig. 4. Stability improvement in hand geometry biometric system

With the results obtained, both techniques can be implemented in small embedded systems, such as a smart card. The verification rates obtained are satisfactory for most of the applications since are less than 10%, although for high security environments iris recognition is recommended.

References 1. Berliner, M.L.: Biomicroscopy of the Eye. Paul B. Hoeber, Inc. (1949) 2. Daugman, J. G.: High Confidence Visual Recognition of Persons by a Test of Statistical Independence. IEEE Trans. PAMI, vol. 15, no. 11, Nov. (1993) 11481161 3. Duda, R. O., Hart, P. E.: Pattern Classification and Scene Analysis. John Wiley & Sons (1973) 4. Jain, A. K.: Fundamentals of Digital Image Processing. Prentice Hall (1989) 5. Jain, A. K., Bolle, R., Pankanti, S.: Biometrics Personal Identification in Networked Society. Kluwer Academic Publishers (1999) 6. Jain, L. C., Halici, U., Hayashi, I, Lee, S. B., Tsutsui S.: Intelligent Biometric Techniques in Fingerprint and Face Recoginition. CRC Press (1999)

258

R. Sanchez-Reillo, C. Sanchez-Avila, and A. Gonzalez-Marcos

7. Reynolds, D. A., Rose, R. C.: Robust Text-Independent Speaker Identification Using Gaussian Mixture Speaker Models. IEEE Trans. on Speech and Audio Processing, vol. 3, no. 1, (1995) 72-83 8. Sanchez-Reillo R., Gonzalez-Marcos A.: Access Control System with Hand Geometry Verification and Smart Cards. Proceedings of the IEEE ICCST Conference (to be published). October (1999) 9. Schalkoff, R. J.: Digital Image Processing and Computer Vision. John Wiley & Sons (1989) 10. Sch¨ urmann, J.: Pattern Classification. A unified view of statistical and neural approaches. John Wiley & Sons, Inc. (1996) 11. Zoreda, J.L., Oton, J.M.: Smart Cards. Artech House Inc. (1994)

Author Index

Basin, D. Borcherding, M. Brainard, J. Bulatovic, D.

30 133 76 219

Cruellas, J.C. Chan, Y.-Y.

Nyström, M.

76

Ortega, J. J.

109

242 183

Posegga, J. Povey, D. Pütz, S.

64 1 142

Ganta, S. Gonzales-Marcos, A. Gupta, S.

229 251 229

Reyzin, L. Romano, L. Rubia, M.

167 17 242

Howgrave-Graham, N. Hühnlein, D. Hughes, J.

153 94 127

Sako, K. Sanchez-Avila, C. Sanchez-Reillo, R. Schmeh, K. Schmitz, R. Schneier, B. Seifert, J.P.

101 251 251 119 142 192 153

Tietz, B. Tsiounis, Y.

142 43

Velasevic, D. Vogt, H.

219 64

Wagner, D. Walters, D.

192 229

Jakobsson, M.

43

Kehr, R. Keys, L.

64 229

Lopez, J.

109

MRaihi, D. Mana, A. Mazzeo, A. Mazzocca, N. Medina, M. Merkle, J. Micali, S. Mudge Mulvenna, J.

43 109 17 17 242 94 167 192 229

Young, A. Yung, M.

204 43, 204

CQRE [Secure] November 30 - December 2, 1999, Düsseldorf, Germany

Program Chair Rainer Baumgart, Secunet, Germany

Program Committee Johannes Buchmann .......................... University of Technology Darmstadt, Germany Dirk Fox ..........................................................................................Secorvo, Germany Walter Fumy................................................................................... Siemens, Germany Rüdiger Grimm................................................................................... GMD, Germany Helena Handschuh...................................................................Gemplus / ENS, France Pil Joong Lee .............................................................................. Postech, South Korea Alfred Menezes ........................................ University of Waterloo / Certicom, Canada David Naccache................................................................................. Gemplus, France Clifford Neumann.......................................... University of Southern California, USA Joachim Posegga ............................................................Deutsche Telekom, Germany Mike Reiter.......................................................................................... Bell Labs, USA Matt Robshaw..................................................................................... RSA Labs, USA Richard Schlechter.....................................................European Commission, Belgium Bruce Schneier ............................................................................... Counterpane, USA Tsuyoshi Takagi ...................................................................................NTT, Germany Yiannis Tsiounis .................................................................................Spendcash, USA Michael Waidner .............................................................................. IBM, Switzerland Moti Yung ............................................................................................... CertCo, USA Robert Zuccerato ........................................................... Entrust Technologies, Canada