Information Security: 6th International Conference, ISC 2003, Bristol, UK, October 1-3, 2003, Proceedings

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 2851 3 Berlin Heidelberg New Y...

Author: Colin Boyd | Wenbo Mao

8 downloads 732 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

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

2851

3

Berlin Heidelberg New York Hong Kong London Milan Paris Tokyo

Colin Boyd Wenbo Mao (Eds.)

Information Security 6th International Conference, ISC 2003 Bristol, UK, October 1-3, 2003 Proceedings

13

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Colin Boyd Information Security Research Centre Queensland University of Technology 2 George Street, Brisbane Q4001, Australia E-mail: [email protected] Wenbo Mao Hewlett-Packard Laboratories Filton Road, Stoke Gifford, Bristol, BS34 8QZ, UK E-mail: [email protected] Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress. Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at .

CR Subject Classification (1998): E.3, D.4.6, F.2.1, C.2, J.1, C.3, K.6.5 ISSN 0302-9743 ISBN 3-540-20176-9 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 New York a member of BertelsmannSpringer Science+Business Media GmbH http://www.springer.de © Springer-Verlag Berlin Heidelberg 2003 Printed in Germany Typesetting: Camera-ready by author, data conversion by Boller Mediendesign Printed on acid-free paper SPIN: 10958513 06/3142 543210

Preface

The 2003 Information Security Conference was the sixth in a series that started with the Information Security Workshop in 1997. A distinct feature of this series is the wide coverage of topics with the aim of encouraging interaction between researchers in diﬀerent aspects of information security. This trend continued in the program of this year’s conference. There were 133 paper submissions to ISC 2003. From these submissions the 31 papers in these proceedings were selected by the program committee, covering a wide range of technical areas. These papers are supplemented by two invited papers; a third invited talk was presented at the conference but is not represented by a written paper. We would like to extend our sincere thanks to all the authors that submitted papers to ISC 2003, and we hope that those whose papers were declined will be able to ﬁnd an alternative forum for their work. We are also very grateful to the three eminent invited speakers at the conference: Paul van Oorschot (Carleton University, Canada), Ueli Maurer (ETH Z¨ urich, Switzerland), and Andy Clark (Inforenz Limited, UK). We were fortunate to have an energetic team of experts who took on the task of the program committee. Their names may be found overleaf, and we thank them warmly for their considerable eﬀorts. This team was helped by an even larger number of individuals who reviewed papers in their particular areas of expertise. A list of these names is also provided, which we hope is complete. We are delighted to acknowledge the generous ﬁnancial sponsorship of ISC 2003 by HP Labs, Bristol and Microsoft Research, Cambridge. The British Computer Society are also thanked for their support. The excellent local organizing committee consisted of Vivienne Paulete, Michelle Davies, and Jan Ward. We would like to thank Eiji Okamoto and Javier Lopez who invited us to chair the conference and provided advice and support through all the preparations. We made use of the electronic submission and reviewing software supplied by COSIC at the Katholieke Universiteit Leuven. The software was run on the ISRC’s server at QUT and perfectly maintained by Andrew Clark.

July 2003

Colin Boyd Wenbo Mao

Information Security Conference 2003

October 1-3, 2003, Bristol, UK General Chair and Program Co-chair Wenbo Mao, Hewlett-Packard Laboratories, Bristol, United Kingdom Program Co-chair Colin Boyd, Queensland University of Technology, Australia Program Committee Masayuki Abe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NTT Laboratories, Japan Tuomas Aura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microsoft Research, UK Feng Bao . . . . . . . . . . . . . . . . . . . . . . . . Institute for Infocomm Research, Singapore Jan Camenisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Research, Switzerland Josep Domingo-Ferrer . . . . . . . . . . . . . . . . . . . . . .Universitat Rovira i Virgili, Spain Yair Frankel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TechTegrity, USA Steven Galbraith . . . . . . . . . . . . . . . . . . Royal Holloway, University of London, UK Virgil Gligor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of Maryland, USA Li Gong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sun Microsystems, China Stuart Haber . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hewlett-Packard Laboratories, USA Marc Joye . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gemplus, France Charlie Kaufman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IBM, USA Kwangjo Kim . . . . . . . . . . . . Information and Communications University, Korea Chi Sung Laih . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chengkung University, Taiwan Helger Lipmaa . . . . . . . . . . . . . . . . . . . . Helsinki University of Technology, Finland Javier Lopez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of Malaga, Spain Catherine Meadows . . . . . . . . . . . . . . . . . . . . . . . . . Naval Research Laboratory, USA Phong Nguyen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CNRS/ENS, France Eiji Okamoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of Tsukuba, Japan Michael Reiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carnegie-Mellon University, USA Phillip Rogaway . . . . . . . . . . . . . . . . . . . . . . . . . University of California, Davis, USA Akashi Satoh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Research, Japan Steve Schneider . . . . . . . . . . . . . . . . . . . Royal Holloway, University of London, UK Nigel Smart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of Bristol, UK Paul van Oorschot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Carleton University, Canada Vijay Varadharajan . . . . . . . . . . . . . . . . . . . . . . . . . . Macquarie University, Australia Serge Vaudenay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EPFL, Switzerland Moti Yung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Columbia University, USA Yuliang Zheng . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of North Carolina, USA

VIII

Organization

External Reviewers Isaac Agudo Gildas Avoine Joonsang Baek Endre Bangerter Simon Blackburn Rakesh Bobba Alexandra Boldyreva Emmanuel Bresson Ahto Buldas Mike Burmester Benoit Chevallier-Mames Olivier Chevassut Jung-Hui Chiu Andrew Clark Christophe Clavier Chris I. Dalton Ed Dawson Roberto Delicata Neil Evans Babak Falsaﬁ Cedric Fournet Mike Freedman Eiichiro Fujisaki Debin Gao Craig Gentry

Louis Granboulan Gael Hachez Helena Handschuh Chris Heneghan Florian Hess Herbie Hopkins Bill Horne Himanshu Khurana R. Koleva Susanna Leisten Vo Duc Liem Yi Lu John Malone-Lee Antonio Ma˜ na Keith Martin Lauren May James McKee George Mohay Jose A. Montenegro Scott Moskowitz Sean Murphy Chanathip Namprempre Gregory Neven Philippe Oechslin Katsuyuki Okeya

Francis Olivier Juan J. Ortega Dan Page Kenny Paterson Benny Pinkas David Pointcheval Jonathan Poritz Jason Reid Matt Robshaw Rei Safavi-Naini Tomas Sander Mike Scott Francesc Seb´e Jamshid Shokrollahi Igor Shparlinski Jessica Staddon Ron Steinfeld Koutaro Suzuki Mike Szydlo Gelareh Taban Frederik Vercauteren Mariemma Yague Sung-Ming Yen Alf Zugenmaier

Table of Contents

Invited Talk Revisiting Software Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paul C. van Oorschot

1

Network Security Enabling Shared Audit Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adrian Baldwin, Simon Shiu

14

Cryptographically Generated Addresses (CGA) . . . . . . . . . . . . . . . . . . . . . . . Tuomas Aura

29

Validating and Securing Spontaneous Associations between Wireless Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tim Kindberg, Kan Zhang Single Sign-On Using Trusted Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andreas Pashalidis, Chris J. Mitchell

44

54

Public-Key Algorithms Easy Veriﬁable Primitives and Practical Public Key Cryptosystems . . . . . David Galindo, Sebasti` a Mart´ın, Paz Morillo, Jorge L. Villar

69

Reactively Secure Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michael Backes, Birgit Pﬁtzmann, Michael Waidner

84

Validating Digital Signatures without TTP’s Time-Stamping and Certiﬁcate Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jianying Zhou, Feng Bao, Robert Deng

96

A Fast Signature Scheme Based on New On-line Computation . . . . . . . . . . 111 Takeshi Okamoto, Hirofumi Katsuno, Eiji Okamoto

Cryptographic Protocols Distributed RSA Signature Schemes for General Access Structures . . . . . . 122 Javier Herranz, Carles Padr´ o, Germ´ an S´ aez Divisible Voting Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Natsuki Ishida, Shin’ichiro Matsuo, Wakaha Ogata

X

Table of Contents

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment and Secure Two-Party Computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Anderson C.A. Nascimento, Joern Mueller-Quade, Akira Otsuka, Goichiro Hanaoka, Hideki Imai The Design and Implementation of Protocol-Based Hidden Key Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Eu-Jin Goh, Dan Boneh, Benny Pinkas, Philippe Golle

Invited Talk Intrinsic Limitations of Digital Signatures and How to Cope with Them . 180 Ueli Maurer

Protocol Attacks On the Security of Fair Non-repudiation Protocols . . . . . . . . . . . . . . . . . . . . 193 Sigrid G¨ urgens, Carsten Rudolph, Holger Vogt Security Analysis of a Password Authenticated Key Exchange Protocol . . 208 Feng Bao

Attacks on Public Key Algorithms Zero-Value Point Attacks on Elliptic Curve Cryptosystem . . . . . . . . . . . . . . 218 Toru Akishita, Tsuyoshi Takagi Cryptanalysis of an Algebraic Privacy Homomorphism . . . . . . . . . . . . . . . . . 234 David Wagner Analysis of the Insecurity of ECMQV with Partially Known Nonces . . . . . 240 Peter J. Leadbitter, Nigel P. Smart

Block Ciphers Hardware-Focused Performance Comparison for the Standard Block Ciphers AES, Camellia, and Triple-DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Akashi Satoh, Sumio Morioka A Note on Weak Keys of PES, IDEA, and Some Extended Variants . . . . . 267 Jorge Nakahara Jr., Bart Preneel, Joos Vandewalle Foundations of Diﬀerential Cryptanalysis in Abelian Groups . . . . . . . . . . . . 280 Tomasz Tyksi´ nski

Authorization Trust and Authorization in Pervasive B2E Scenarios . . . . . . . . . . . . . . . . . . . 295 Laurent Bussard, Yves Roudier, Roger Kilian-Kehr, Stefano Crosta

Table of Contents

XI

A Logic Model for Temporal Authorization Delegation with Negation . . . . 310 Chun Ruan, Vijay Varadharajan, Yan Zhang

Watermarking Zero-Distortion Authentication Watermarking . . . . . . . . . . . . . . . . . . . . . . . . 325 Yongdong Wu Designated Veriﬁcation of Non-invertible Watermark . . . . . . . . . . . . . . . . . . 338 Hyejoung Yoo, Hyungwoo Lee, Sangjin Lee, Jongin Lim

Software Security Proactive Software Tampering Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Hongxia Jin, Jeﬀery Lotspiech Run-Time Support for Detection of Memory Access Violations to Prevent Buﬀer Overﬂow Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Pramod Ramarao, Akhilesh Tyagi, Gyungho Lee Towards a Business Process-Driven Framework for Security Engineering with the UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Jos´e L. Vivas, Jos´e A. Montenegro, Javier L´ opez

Codes and Related Issues Error Correcting and Complexity Aspects of Linear Secret Sharing Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Yvo Desmedt, Kaoru Kurosawa, Tri Van Le Systematic Treatment of Collusion Secure Codes: Security Deﬁnitions and Their Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Katsunari Yoshioka, Junji Shikata, Tsutomu Matsumoto Short c-Secure Fingerprinting Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Tri Van Le, Mike Burmester, Jiangyi Hu The Role of Arbiters in Asymmetric Authentication Schemes . . . . . . . . . . . 428 Goichiro Hanaoka, Junji Shikata, Yumiko Hanaoka, Hideki Imai

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Revisiting Software Protection Paul C. van Oorschot Digital Security Group, School of Computer Science Carleton University, Canada [email protected]

Abstract. We provide a selective survey on software protection, including approaches to software tamper resistance, obfuscation, software diversity, and white-box cryptography. We review the early literature in the area plus recent activities related to trusted platforms, and discuss challenges and future directions.

1

Introduction and Overview

Software protection has recently attracted tremendous commercial interest, from major software vendors to content providers including the movie and music recording industries. Their digital content is either at tremendous risk of arriving free on the desktops of millions of former paying customers, or on the verge of driving even greater proﬁts through new markets. The outcome may depend in large part on technical innovations in software protection, and related mechanisms for digital rights management (DRM) - controlling digital information once it resides on a platform beyond the control of the originator. Privacy advocates are interested in similar mechanisms for protecting personal information given to others in digital format. Related activities include Microsoft’s heavy investment in a next generation trusted hardware platform (Palladium) [41], and the recent award by the U.S. Air Force Research Laboratory of a US$1.8m (£1.13m) research contract involving software obfuscation [25]. Software protection falls between the gaps of security, cryptography and engineering, among other disciplines. Despite its name, software protection involves many assumptions related to hardware and other environmental aspects. A signiﬁcant gulf currently exists between theory and practice. Inconsistencies have arisen in the relatively sparse (but growing) open literature as a result of differences in objectives, deﬁnitions and viewpoints. All of these issues provide research opportunities. We provide a selective survey on software protection and related areas, and encourage further research. We oﬀer a number of viewpoints, discuss challenges, and suggest future directions.

Version: 15 July 2003.

C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 1–13, 2003. c Springer-Verlag Berlin Heidelberg 2003

2

1.1

Paul C. van Oorschot

Focus

Under the heading of software protection, our main focus is on techniques useful for protecting software from reverse engineering (by obfuscation), modiﬁcation (by software tamper resistance), program-based attacks (by software diversity), and BORE – break-once run everywhere – attacks (by architectural design). Protecting content typically requires protecting the software which processes the content – motivating our focus on software protection. We are interested in copy protection – a term many use interchangeably with software protection – to the extent that it requires many of the same protections against reverse engineering and software tampering. We do not pursue digital watermarks, a form of steganography (see Petitcolas et al. [44] for a taxonomy); they typically do not by themselves prevent attacks a priori, but may be used for tracking and ﬁnding violators after-the-fact, often in conjunction with legal remedies. 1.2

Organization

The remainder of this paper is organized as follows. §2 reviews some early literature on software protection. §3 discusses a selection of software protection approaches including software tamper resistance, software obfuscation, software diversity, and white-box cryptography. §4 provides observations related to positive and negative results on software obfuscation, the challenges of using complexity-theory as a basis for security analysis, deﬁnitions of eﬃciency, and security through obscurity. §5 reviews recent directions in the related area of enhancing platform security with low-cost “trusted” hardware and secure software boot-strapping. §6 provides concluding remarks.

2

Early Research on Software Protection

As usual, we ﬁnd it instructive to review the earliest published works in any research area, to learn what was known to the original experts in the area, and has since been forgotten or re-invented. One of the earliest published works in software protection is the 1980 thesis of Kent [37], which addresses the security requirements of software vendors: protection from software copying and modiﬁcation (e.g. the latter by physical attacks by users, or program-based attacks). Tools proposed to address these requirements include physical tamper-resistant modules (TRMs) and cryptographic techniques; one approach involves using encrypted programs, with instructions decrypted immediately prior to execution. Kent also noted the dual problem of user requirements that externally-supplied software be conﬁned in its access to local resources (cf. hostile host vs. hostile code, §3.2 below). Gosler’s software protection survey [31] examines circa-1985 protection technologies including: hardware security devices (e.g. dongles), ﬂoppy disc signatures (magnetic and physical), analysis denial methods (e.g. anti-debug techniques, checksums, encrypted code) and slowing down interactive dynamic analysis. The focus is on software copy prevention, but Gosler notes that the strength

Revisiting Software Protection

3

of resisting copying should be balanced by that of analyzing the software (e.g. reverse engineering to learn where to modify software, and for protecting proprietary algorithms) and that of software modiﬁcation (to bypass security checks). Useful tampering is usually preceded by reverse engineering. Gosler also notes that one should expect that an adversary can carry out dynamic analysis on the target software without detection (e.g. using in-circuit emulators and simulators), and that in such a case, as a result of repeated experiments, one should expect the adversary to win. The practical defense objective is thus to make such experiments “extremely arduous”. Another suggestion [31, p.154] is cycling software (e.g. via some forced obsolescence) at a rate faster than an adversary can break it; this anticipates the paradigm of forced software renewal (cf. Jakobsson and Reiter [36], who propose discouraging pirates through forced updates and software aging). This approach is appropriate where protection from attacks for a limited time period suﬃces. Herzberg and Pinter [33] consider the problem of software copy protection, and propose a solution requiring CPU encryption support (which was far less feasible when proposed almost 20 years ago, circa 1984-85). Cohen’s 1993 paper [19] (see also §3.4 below) on software diversity and obfuscation is directly related to software protection, and provides a wealth of techniques and insights. Goldreich and Ostrovsky’s 1996 journal paper [30] (and earlier related individual 1987 and 1990 papers) provides one of the earliest theoretical foundation pieces. They reduce the problem of software protection – which they take to mean unauthorized software duplication – to that of eﬃcient (in the theoretical sense) simulation on oblivious RAMs. A new issue they address is the extraction of useful information gained by an adversary examining the memory access patterns of executing programs. To address this, oblivous RAMs replace instruction fetches in the original program by sequences of fetches, eﬀectively randomizing memory access patterns to eliminate information leakage. Interestingly, the subsequent practical tamper resistance system of Aucsmith [6,7] (see §3.3 below) addresses similar issues by a combination of just-in-time instruction decryption, and re-arranging instruction blocks at run-time to dynamically change the addresses of executing statements during program execution.

3

Software Protection Approaches

In this section we outline a selection of software protection approaches: obfuscation through code transformations (for protection against reverse engineering); white-box cryptography (for protecting secret keys in untrusted host environments); software tamper resistance (for protection against program integrity threats); and software diversity (for protection against automated attack scripts and widespread malicious software). We do not consider copy protection per se, but note that many of these techniques may serve useful roles in a copy protection solution. Approaches not discussed include the use of anti-debugging techniques.

4

3.1

Paul C. van Oorschot

Software Obfuscation via Automated Code Transformations

Several researchers have published papers on software obfuscation using automated tools and code transformations (e.g. Collberg et al. [21,22]). One idea is to use language-based tools to transform a program (most easily from source code) to a functionally equivalent program which presents greater reverse engineering barriers. If implemented in the form of a pre-compiler, the usual portability issues can be addressed by the back-end of standard compilers. For design descriptions of such language-based tools, see Collberg et al. [20], Nickerson et al. [16], and C. Wang [52]. Cohen [19] suggested a similar approach already in the early 1990’s, employing obfuscation among other mechanisms as a defense against computer viruses. Cohen’s early paper, which is strongly recommended for anyone working in the area of software obfuscation and code transformations, contains an extensive discussion of suggested code transformations (see also Collberg et al. [20], and the substantial bibliography in the circa-2000 survey of Collberg et al. [23]). C. Wang [52] provides an important security result substantiating this general approach. The idea involves incorporating program transformations to exploit the hardness of precise inter-procedural static analysis in the presence of aliased variables (cf. Collberg et al. [20, §8.1]), combined with transformations degenerating program ﬂow control. Wang shows that static analysis of suitably transformed programs is NP-hard. Collberg et al. [20] contains a wealth of additional information on software obfuscation, including notes on: a proposed classiﬁcation of code transformations (e.g. control ﬂow obfuscation, data obfuscation, layout obfuscation, preventive transformations); the use of opaque predicates for control ﬂow transformations (expressions diﬃcult for an attacker to deduce, but whose value is known at compilation or obfuscation time); initial ideas on metrics for code transformations; program slicing tools (for isolating program statements on which the value of a variable at a particular program point is potentially dependent); and the use of (de)aggregation of ﬂow control or data (constructing bogus relationships by grouping unrelated program aspects, or disrupting legitimate relationships in the original program). 3.2

Untrusted Host Environment and White-Box Cryptography

The fairly well-studied, but still challenging, malicious code problem is as follows: how should a host machine be protected from potentially untrusted external code (e.g. downloaded from a web site, or arriving as an email attachment). Standard solutions include containment through sand-boxing, veriﬁcation of source by code-signing, and anti-virus programs. More closely related to software protection is the less-studied dual, the malicious host problem: how should a trusted program (e.g. containing a proprietary algorithm, private or critical data, or special access privileges) be protected from a potentially malicious host. This problem has received the most attention in the context of mobile code security (e.g. see Chess [14]; Sander and Tschudin

Revisiting Software Protection

5

[46,45]; see also Algesheimer et al. [1]). Both problems were noted already more than 20 years ago by Kent [37] (see §2). It is clear that the standard cryptographic paradigm – involving known algorithms, secret keys, and trusted communications end-points – fails entirely in the malicious host environment, as secret keys are directly visible. Moreover, as demonstrated by van Someren and Shamir [49], ﬁnding cryptographic keys in memory is quite easy – their randomness and size distinguishes them from other items in memory, which generally contain redundancy. Thus storing critical keys in memory is a vulnerability, given the ubiquity of malicious software. The same malicious host issues arise in digital rights management applications where software attempts to constrain what end-users may do with content (e.g. music, movies and books), or with respect to modifying the software itself. Indeed, the host is eﬀectively considered a hostile environment. Once a software vendor or content provider makes their digital product available on a system not under their control, virtually all such control over the digital item is indeed lost. The threats include manual attacks (humans including legitimate end-users, typically aided by software tools) beneﬁting from hands-on access to the executing software; and program-based attacks by malicious software, programs which exploit software vulnerabilities, or simple local or remote exploits of access control failures. This leads to an extremely severe threat model: the white-box attack context of Chow et al. [17] (see also [18,35]) and white-box cryptography – cryptographic implementations designed to withstand attack in the white-box context. The white-box model contrasts traditional black-box models where only input-output or external behavior of software may be observed. An intermediate ground is gray-box attacks (also called side-channel attacks or partial-access attacks), such as fault analysis attacks (e.g. [10,11]) and the timing and power analysis attacks of Kocher and others, which involve the use of additional information. The white-box attack context assumes fully-privileged attack software has full access to the implementation of cryptographic algorithms (e.g. shares the host), can view and alter internal algorithm details, and can observe dynamic execution involving instantiated cryptographic keys. The attacker’s objective is to extract the cryptographic key, for use on a diﬀerent platform. As suggested above, in this context standard cryptographic algorithms fail to provide protection. Here the choice (diversity) of implementation appears to be a remaining line of defense. 3.3

Software Tamper Resistance

Software obfuscation provides protection against reverse engineering, the goal of which is to understand a program. Reverse engineering is a typical ﬁrst step prior to an attacker making software modiﬁcations which they ﬁnd to their advantage. Detecting such integrity violations of original software is the purpose of software tamper resistance techniques. Software tamper resistance has been less studied in the open literature than software obfuscation, although the past few years has seen the emergence of a number of interesting proposals.

6

Paul C. van Oorschot

Fundamental contributions in this area were made by Aucsmith [6], in conjunction with Graunke [7] at Intel. Aucsmith deﬁnes tamper resistant software as software which is resistant to observation and modiﬁcation, and can be relied upon to function properly in hostile environments. An architecture is provided based on an Integrity Verification Kernel (IVK) which veriﬁes the integrity of critical code segments. The IVK architecture is self-decrypting and involves selfmodifying code. Working under similar design criteria (e.g. to detect single bit changes in software), Horne et al. [34] also discuss self-checking code for software tamper resistance. At run time, a large number of embedded code fragments called testers each test assigned small segments of code for integrity (using a linear hash function and an expected hash value); if integrity fails, an appropriate response is pursued. The use of a number of testers increases the attacker’s diﬃculty of disabling testers. In related work, Chang and Atallah [12] propose a scheme with somewhat broader capabilities involving a set of guards which can be programmed to carry out arbitrary tasks – one example is check-summing code segments for integrity veriﬁcation providing software tamper resistance. Another suggested guard function is actually repairing code (e.g. if a damaged code segment is detected, downloading and installing a fresh copy of the code segment). They also outline a system for automatically placing guards within code. Chen et al. [13] propose oblivious hashing, which involves compile-time code modiﬁcations resulting in the computation of a running trace of the execution history of a program. Here a trace is a cumulative hash of the values of a subset of expressions which occur within the normal program execution. 3.4

Software Diversity

Diversity is an idea which is part of the software folklore, but it appears to only recently have received signiﬁcant attention in the security community. The fundamental idea is simple: in nature, genetic diversity provides protection against an entire species being wiped out by a single virus or disease. The same idea applies for software, with respect to resistance to the exploitation of software vulnerabilities and program-based attacks. In this regard, however, the trend towards homogeneity in software is worrisome: consider the very small number of diﬀerent Internet browsers now in use; and the number of major operating systems in use, which is considerably smaller than 10 years ago. The value of software diversity as a protection mechanism against computer viruses and other software attacks was well documented by Cohen [19] already in 1992-93. The architecture of automated code transformation tools to provide software obfuscation (see §3.1) can be modiﬁed slightly to provide software diversity: rather than creating one new instance of a program which is functionally equivalent to the original (and hard to reverse engineer), create several or many. Here the diﬃculty of reverse engineering or tampering with a single program instance is one security factor, but a more important factor is that an exploit crafted to succeed on one instance will not necessarily work against a

Revisiting Software Protection

7

second. Forrest et al. [28] pursue this idea in several directions, including simple randomizations of stack memory to de-rail high-proﬁle buﬀer-overﬂow attacks. The idea of relying on diversity for improving the reliability and survivability of networks has gained recent popularity, subsequent to incidents of global terrorism (e.g. see C. Wang [52] for contributions and references). The value of diversity for security and survivability was also recognized in the 1999 Trust in Cyberspace report [47], among others.

4

Other Observations on Software Protection

The relative scarcity in the open literature of theoretical papers on software protection and obfuscation suggests that the ﬁeld remains in its early stages. Not surprisingly, there exist inconsistencies in deﬁnitions, models, and conclusions in the existing literature, and often practical papers are entirely lacking in the former two. Often, the objectives of attackers are not clearly (if at all) deﬁned, making security analysis of proposed solutions a vague pursuit. A further challenge is that for techniques whose security supposedly is based on the diﬃculty of solving hard problems, it is often unclear if attackers must necessarily solve the underlying diﬃcult problems to achieve their objectives. 4.1

Positive and Negative Theoretical Results

On the side showing promise for software obfuscation are np-hardness results of C. Wang [52] (see also the earlier report [51]), the related results of Ogiso [43], and pspace-hardness results of Chow et al. [15]. These results suggest that one may expect code transformations to signiﬁcantly (e.g. exponentially) increase the diﬃculty of reverse-engineering, and provide the beginnings of a foundation justifying the approach and security possible through code transformations. In constrast are the impossibility results of Barak et al. [9], who prove that the following device does not exist: a software virtual black box generator which can protect every program’s code from revealing more than the program’s inputoutput behavior. While on the surface this result is quite negative for practitioners interested in software obfuscation, upon deeper inspection this is not so (despite the rather suggestive title of the paper); the results simply arise from the choice of deﬁnitions, model, and question posed. In practice, the non-existence of such a virtual black box generator would appear to be of little concern. Of greater interest are several diﬀerent questions, such as: to what proportion of programs of practical interest does this result apply; do obfuscators exist which are capable of obfuscating programs of practical interest; and can a more practical model be deﬁned, allowing some level of non-critical information to leak from the execution of a program, provided it is not useful information to the attacker.

8

4.2

Paul C. van Oorschot

Security Justiﬁed by Complexity Class Results

The usual caveats also exist regarding the use of complexity-theoretic arguments as the basis for security. While NP-complete problems [29] are generally considered intractable, this intractability is based on the diﬃculty of the hardest problem instances. However, some NP-complete problems are easy in the average case, while random instances of others are still diﬃcult. Thus for use in security, of greater interest than worst-case is average-case complexity analysis (e.g. see the overview by J. Wang [50]). In fact, we require not only average-case diﬃculty, but the probability of easy instances arising being very low. Moreover, there are many cryptographic examples where diﬃcult problems have been used to justify the security of proposals, which were later proven to be easily broken due to the fact that the particular problem instances built into actual instantiations turned out, for various reasons, to be far weaker than the hardest, or average, problem instances. By way of comparison, it is interesting to recall the deﬁnition of the preimage resistance property for cryptographic one-way hash functions (e.g. [40, p.323]): for essentially all pre-speciﬁed outputs, it is computationally infeasible to ﬁnd any input which hashes to that output. Thus a one-way hash function is considered good if it is diﬃcult to invert for almost all outputs. Note that the deﬁnition does not simply require that there exist some hard instances. 4.3

Deﬁnition of Eﬃciency

A separate challenge, that is not unique to the literature on software protection, is the diﬀerence between what theoreticians and practitioners refer to as eﬃcient. In standard complexity theory, slowing down running time by “only” a polynomial factor leaves a polynomial-time algorithm in polynomial time; and logarithmic slowdowns are considered quite good. In constrast in practice, a slowdown by a constant factor of as little as two (2), let alone two orders of magnitude (constant 100), is often far more than can be tolerated. Indeed in some cases, an overall slowdown of 10-20% is intolerable. Similar comments apply for space (although in practice, except in constrained environments, memory is now typically far less of a barrier - especially for personal computers). A related comment oﬀers a more graphical illustration for running time: for any ﬁxed key length t, a t-bit key space can be exhaustively searched in constant time 2t ; therefore, the time to break a strong cipher with a 128-bit key, e.g. AES [24], is uninteresting from a complexity-theoretic viewpoint – namely, O(1). 4.4

Security through Obscurity Vs. Software Obfuscation

A frequently cited set of cryptographic principles devised by Auguste Kerckhoﬀs in 1883 [38] stipulates that security should not suﬀer if an adversary knows all the details of an encryption function aside from the secret key (and therefore, all security rests on the secrecy of this key). Amateur cryptographers often

Revisiting Software Protection

9

violate this rule, designing systems whose security relies on secrecy of design details, which invariably become known. Such “security through obscurity” is thus severely frowned upon. Due to the language similarity with the phrase “software obfuscation”, many people are pre-conditioned to also frown upon software obfuscation, without thinking further. (Of course, depending on the type of software obfuscation, this may be entirely justiﬁed.) In our view, software obfuscation can and should be fundamentally distinct from security through obscurity. To this end, software obfuscation techniques should be pursued in which there are a very large space of possible transformations of an original software program to a transformed program, and indeed the security should not be compromised by an adversary knowing the set of possible mappings (or having the software transformation tool itself available). The choice among possible mappings should be suﬃciently large that the security rests on the wide range of possibilities (analogous to a large key space).

5

Low-Cost Trusted Hardware Approaches

Concerns have continued to mount regarding trust in the Internet as a reliable platform for secure e-commerce, and as a foundation for content protection in digital rights management applications. Behind these concerns are inherent limitations of software-only security solutions. Such issues have resulted in efforts to develop a low-cost, commercial generic trusted hardware platform. The Trusted Computing Platform Alliance (TCPA), recently renamed the Trusted Computing Group [48], began in January 1999 under the eﬀorts of Compaq, HP, IBM, Intel and Microsoft. Version 1.0 of the TCPA speciﬁcations were released early in 2001, deﬁning the core security funcationality of a trusted subsystem for computing platforms, intended to “create a foundation of trust for software processes, based on a small amount of hardware within such platforms” [8, p.5]. Microsoft has also launched a separate (related) initiative originally known as Palladium, and recently renamed the Next-Generation Secure Computing Base ([41,42]; see also patents by England et al. [26,27]). Lively debate is ongoing (e.g. see Anderson’s FAQ [2]) about the good and evil which will arise as a result of either or both TCPA and Palladium, and whether or not erosion of end-user control of their own devices, due to corporate-controlled DRM, is a likely result. Earlier, Arbaugh et al. proposed a general architecture of how to develop such a trust foundation ([4]; and related patent [5]), intializing a computer system by successively validating the integrity of each layer throughout the bootstrap process, thereby providing a chain of integrity guarantees based on initial trust in the hardware layer. Lie et al. [39] explore an alternate solution to the failures to date of softwareonly tamper-resistance, examining the hardware implementation of execute-only memory. Such memory allows the execution of stored-memory instructions, but no other manipulations. Gutmann [32] provides a clear discussion of the security issues facing cryptographic implementations in software under general-purpose operating systems, and examines the design challenges in overcoming these issues

10

Paul C. van Oorschot

by employing secure cryptographic co-processors. Anderson and Kuhn [3] provide a number of attacks against tamper resistant (especially low-cost) devices, and make the case that building and using such devices properly is deceptively diﬃcult.

6

Concluding Remarks

The theoretical results to date on software obfuscation leave room for software protection of considerable practical value. This should be of no surprise – indeed, the impossibility of building a program to determine whether other software is malicious does not preclude highly valuable computer virus detection technologies, and a viable (even lucrative) anti-virus industry. We believe that it is still early in the history of research in the areas of software protection and obfuscation, and that many discoveries and innovations lie ahead – perhaps especially in the areas of software diversity (which seems to be very little utilized presently), and software tamper resistance. We expect to see more open discussion of speciﬁc techniques, and believe that, similar to the history in the ﬁeld of cryptography, the surest way to obtain an increased number of secure techniques is to involve public scrutiny, peer evaluation, and open discussion in the literature. We see the past trends of proprietary, undislosed methods of software obfuscation techniques analogous to the early days in cryptography, where invention and use of (weak) unpublished encryption algorithms by novices was commonplace. A factor in favour of those promoting software obfuscation, software tamper resistance, and related software protection methods is Moore’s law. As computing cycles become yet faster and faster, and the availability and speed of memory continue to increase, the computational penalties typically experienced in relation to many software protection approaches, will be unimportant. (Again, this seems analogous to the execution of 512-bit RSA being intolerably slow on a PC 20 years ago.) As has been the case for some time, one of the greatest challenges in this area remains the lack of analysis techniques, and metrics for evaluating and comparing the strength of various software protection techniques. As a ﬁrst step before obtaining such metrics, we believe more work is necessary in clarifying the exact goals of software obfuscation, and the precise objectives of attackers. We also believe there is a substantial research opportunity to ﬁll in the large gap between the practical and theoretical progress in this area. For techniques of practical interest, we see opportunities to deﬁne models and approaches better reﬂecting applications for which software protection of short durations suﬃces (cf. forced software updates, §2). Acknowledgements: The author acknowledges the generous support of the National Sciences and Engineering Research Council of Canada for support under both a Canada Research Chair and an NSERC Discovery Grant.

Revisiting Software Protection

11

References 1. J. Algesheimer, C. Cachin, J. Camenisch, G. Karjoth, “Cryptographic Security for Mobile Code”, pp. 2–11 in Proc. 2001 IEEE Symposium on Security and Privacy (May 2001). 2. R. Anderson, Trusted Computing FAQ – TCPA/Palladium/NGSCB/TCG, http://www.cl.cam.ac.uk/∼rja14/tcpa-faq.html. 3. R.J. Anderson, M.G. Kuhn, “Low Cost Attacks on Tamper-Resistant Devices”, pp. 125–136, 5th International Workshop on Security Protocols, Springer LNCS 1361 (1997). 4. W.A. Arbaugh, D.J. Farber, J.M. Smith, “A Secure and Reliable Bootstrap Architecture”, Proc. 1997 IEEE Symp. Security and Privacy, pp.65–71, May 1997. 5. W.A. Arbaugh, D.J. Farber, A.D. Keromytis, J.M. Smith, Secure and Reliable Bootstrap Architecture, U.S. Patent 6,185,678 (ﬁled Oct.2 1998; issued Feb.6 2001). 6. D. Aucsmith, “Tamper Resistant Software: An Implementation”, Proc. 1st International Information Hiding Workshop (IHW), Cambridge, U.K. 1996, Springer LNCS 1174, pp. 317-333 (1997). 7. D. Aucsmith, G. Graunke, Tamper Resistant Methods and Apparatus, U.S. Patent 5,892,899 (ﬁled June 13 1996; issued Apr.6 1999). 8. B. Balacheﬀ, L. Chen, S. Pearson (ed.), D. Plaquin, G. Proudler, Trusted Computing Platforms: TCPA Technology in Context, Prentice Hall, 2002. 9. B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. Vadhan, K. Yang, “On the (Im)possibility of Obfuscating Programs”, pp. 1–18, Advances in Cryptology – Crypto 2001, Springer LNCS 2139 (2001). 10. E. Biham, A. Shamir, “Diﬀerential Fault Analysis of Secret Key Cryptosystems”, pp. 513–525, Advances in Cryptology – Crypto ’97, Springer LNCS 1294 (1997). Revised : Technion - C.S. Dept. - Technical Report CS0910-revised, 1997. 11. D. Boneh, R.A. DeMillo, R.J. Lipton, “On the Importance of Eliminating Errors in Cryptographic Computations”, J. Cryptology 14(2), pp. 101–119 (2001). 12. H. Chang, M. Atallah, “Protecting Software Code by Guards”, Proc. 1st ACM Workshop on Digital Rights Management (DRM 2001), Springer LNCS 2320, pp.160–175 (2002). 13. Y. Chen, R. Venkatesan, M. Cary, R. Pang, S. Sinha, M. Jakubowski, “Oblivious Hashing: A Stealthy Software Integrity Veriﬁcation Primitive”, Proc. 5th Information Hiding Workshop (IHW), Netherlands (October 2002), Springer LNCS 2578, pp.400–414. 14. D.M. Chess, “Security Issues in Mobile Code Systems”, pp.1–14 in Mobile Agents and Security, G. Vigna (ed.), Springer LNCS 1419 (1998). 15. S. Chow, Y. Gu, H. Johnson, V.A. Zakharov, “An Approach to the Obfuscation of Control-Flow of Sequential Computer Programs”, pp. 144–155, Proc. ISC 2001 – 4th International Information Security Conference, Malaga, Spain 1–3 October 2001, Springer LNCS 2200 (2001). 16. J.R. Nickerson, S.T. Chow, H.J. Johnson, Y. Gu, “The Encoder Solution to Implementing Tamper Resistant Software”, presented at the CERT/IEEE Information Survivability Workshop, Vancouver, Oct. 2001. 17. S. Chow, P. Eisen, H. Johnson, P.C. van Oorschot, “White-Box Cryptography and an AES Implementation”, Proc. 9th International Workshop on Selected Areas in Cryptography (SAC 2002), Springer LNCS 2595 (2003). 18. S. Chow, P. Eisen, H. Johnson, P.C. van Oorschot, “A White-Box DES Implementation for DRM Applications”, Proc. 2nd ACM Workshop on Digital Rights Management (DRM 2002), Springer LNCS (to appear).

12

Paul C. van Oorschot

19. F. Cohen, “Operating System Protection Through Program Evolution”, Computers and Security 12(6), 1 Oct. 1993, pp. 565–584. 20. C. Collberg, C. Thomborson, D. Low, “A Taxonomy of Obfuscating Transformations”, Technical Report 148, Dept. Computer Science, University of Auckland (July 1997). 21. C. Collberg, C. Thomborson, D. Low, “Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs”, Proc. Symp. Principles of Programming Languages (POPL’98), Jan. 1998. 22. C. Collberg, C. Thomborson, D. Low, “Breaking Abstractions and Unstructuring Data Structures”, IEEE International Conf. Computer Languages (ICCL’98), May 1998. 23. C.S. Collberg, C. Thomborson, “Watermarking, Tamper-Prooﬁng, and Obfuscation - Tools for Software Protection”, IEEE Trans. Software Engineering, Vol. 28 No. 6 (June 2002). 24. J. Daemen, V. Rijmen, The Design of Rijndael: aes – The Advanced Encryption Standard, Springer, 2001. 25. ComputerWeekly.com, “U.S. Software Security Takes Oﬀ”, 8 November 2002, http://www.computerweekly.com/Article117316.htm 26. P. England, J.D. DeTreville, B.W. Lampson, Digital Rights Management Operating System, U.S. Patent 6,330,670 (ﬁled Jan.8 1999; issued Dec.11 2001). 27. P. England, J.D. DeTreville, B.W. Lampson, Loading and Identifying a Digital Rights Management Operating System, U.S. Patent 6,327,652 (ﬁled Jan.8 1999; issued Dec.4 2001). 28. S. Forrest, A. Somayaji, D. H. Ackley, “Building Diverse Computer Systems”, pp. 67–72, Proc. 6th Workshop on Hot Topics in Operating Systems, IEEE Computer Society Press, 1997. 29. M.R. Garey, D.S. Johnson, Computers and Intractability - A Guide to the Theory of NP-Completeness, W.H. Freeman and Company, 1979. 30. O. Goldreich, R. Ostrovsky, “Software Protection and Simulation on Oblivious RAMs”, Journal of the ACM, vol.43 no.3 (May 1996), pp.431–473. Based on earlier ideas of Goldreich (STOC’87) and Ostrovsky (STOC’90). 31. J. Gosler, “Software Protection: Myth or Reality?”, Advances in Cryptology – CRYPTO’85, Springer-Verlag LNCS 218, pp.140–157 (1985). 32. P. Gutmann, “An Open-source Cryptographic Co-processor”, Proc. 2000 USENIX Security Symposium. 33. A. Herzberg, S.S. Pinter, “Public protection of software”, pp.371–393, ACM Trans. Computer Systems, vol.5 no.4 (Nov. 1987). Earlier version in Crypto’85. 34. B. Horne, L. Matheson, C. Sheehan, R. Tarjan, “Dynamic Self-Checking Techniques for Improved Tamper Resistance”, Proc. 1st ACM Workshop on Digital Rights Management (DRM 2001), Springer LNCS 2320, pp.141–159 (2002). 35. M. Jacob, D. Boneh, E. Felton, “Attacking an Obfuscated Cipher by Injecting Faults”, Proc. 2nd ACM Workshop on Digital Rights Management (DRM 2002), Springer LNCS (to appear). 36. M. Jakobsson, M.K. Reiter, “Discouraging Software Piracy Using Software Aging”, Proc. 1st ACM Workshop on Digital Rights Management (DRM 2001), Springer LNCS 2320, pp.1–12 (2002). 37. S. Kent, Protecting Externally Supplied Software in Small Computers, Ph.D. thesis, M.I.T., September 1980. 38. A. Kerckhoﬀs, “La Cryptographie Militaire”, Journal des Sciences Militaires, vol.9 (February 1883).

Revisiting Software Protection

13

39. D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell, M. Horowitz, “Architectural Support for Copy and Tamper Resistant Software”, Proc. 9th International Conf. Architectural Support for Programming Languages and Operating Systems (Nov. 2000). 40. A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1996. 41. Next-Generation Secure Computing Base (formerly Palladium), Microsoft web site, http://www.microsoft.com/resources/ngscb/default.mspx. 42. Next-Generation Secure Computing Base - Technical FAQ, Microsoft web site, http://www.microsoft.com/technet/security/news/NGSCB.asp. 43. T. Ogiso, U. Sakabe, M. Soshi, A. Miyaji, “Software Tamper Resistance Based on the Diﬃculty of Interprocedural Analysis”, 3rd Workshop on Information Security Applications (WISA 2002), Korea, August 2002. 44. F. Petitcolas, R.J. Anderson, M.G. Kuhn, “Information Hiding – A Survey”, Proc. of the IEEE (Special Issue on Protection of Multimedia Content), vol.87 no.7 (July 1999), pp.1062–1078. 45. T. Sander, C.F. Tschudin, “Towards Mobile Cryptography”, pp. 215–224, Proc. 1998 IEEE Symposium on Security and Privacy. 46. T. Sander, C.F. Tschudin, “Protecting Mobile Agents Against Malicious Hosts”, pp. 44–60 in Mobile Agents and Security, G. Vigna (ed.), Springer LNCS 1419 (1998). 47. F. Schneider (ed.), Trust in Cyberspace, report of the Committee on Information Systems Trustworthiness, Computer Science and Telecommunications Board, (U.S.) National Research Council (National Academy Press, 1999). 48. Trusted Computing Group, http://www.trustedcomputinggroup.org/home. 49. N. van Someren, A. Shamir, “Playing Hide and Seek with Keys”, pp. 118–124, Financial Cryptography’99, Springer LNCS 1648 (1999). 50. J. Wang, “Average-Case Computational Complexity Theory”, pp.295–328 in: Complexity Theory Retrospective II, L. Hemaspaandra and A. Selman (eds.), Springer, 1997. 51. C. Wang, J. Hill, J. Knight, J. Davidson, “Software Tamper Resistance: Obstructing Static Analysis of Programs”, Dept. of Computer Science, Univ. of Virginia, Tech. Report CS-2000-12 (May 2000). Updated in [52]. 52. C. Wang, A Security Architecture for Survivability Mechanisms, Ph.D. thesis, University of Virginia (Oct. 2000).

Enabling Shared Audit Data Adrian Baldwin and Simon Shiu Hewlett Packard Labs, Bristol, UK, [email protected], [email protected]

Abstract. Audit is recognised as an important aspect of good security and business practice however, current solutions are not supportive of electronic data and processes. This paper describes an audit service that both acts as a central place for logging from heterogeneous IT systems and a place to search and check the audit data. Notarisation structures are proposed that demonstrate the integrity of the audit records and allow users to check the validity and integrity of subsets of the overall audit chain. The audit system is based upon secure hardware allowing audit systems to be tightly integrated into the overall IT infrastructure whilst remaining in an alternative virtual trust domain.

1

Introduction

Audit is one of the fundamental security mechanisms; however, in many IT solutions it is often ignored or weakly implemented. Traditionally, audit involves various OS functions and applications logging events to a variety of log ﬁles. These will usually only be examined when things have gone wrong. Audit is an essential feature in controlling the actions of those responsible for systems and business processes but it is only eﬀective if the audit data is revisited. To achieve this successfully trust must be placed both on the integrity of the audit data and it must be checkable by all interested parties - this way mistakes or wrongdoing are likely be detected and those in charge will be held to account. This paper describes an audit service that encourages the sharing of segments of audit data with those involved in the transaction. To achieve this eﬀectively, any user querying the system and getting back a set of events must be able to gain conﬁdence that they have events that are from the audit log, that the events have not changed and that they have all related events. Various notarisation structures [1] [2] [3] [4] have been described to protect the integrity of audit events; the structures proposed in this paper solve the additional problems associated with the sharing of audit data. The next section of this paper provides background to the audit problem describing current approaches to IT audit, the audit requirements and the gulf between them that necessitates paper audit trails to support most business processes (including e-commerce). This is followed by a description of a third party audit service that supports and encourages the sharing of data. This service has a number of security issues; section 4 of the paper concentrates on the creation of audit information that interested parties can use to verify the integrity of the C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 14–28, 2003. c Springer-Verlag Berlin Heidelberg 2003

Enabling Shared Audit Data

15

data. These structures rely heavily on a third party audit service and a security hardware service delivery model is described that allows the audit service to be co-located with the IT infrastructure whilst reducing the possibility of collusion between parties.

2

Traditional Audit

Security is largely concerned with enforcing good behaviour and stopping inappropriate behaviour. It can be reinforced with strong audit processes. For example, an audit system would not prevent a system administrator using the many ’backdoors’ available to them, but it would record their actions, and so leave open the possibility that they could be held to account. Audit forms an important basis for encouraging good behaviour and resolving disputes over a range of examples including insurance, health [5], and supply chain management. 2.1

Typical Electronic Audit

Most large IT installations consist of a large and heterogeneous set of IT applications and operating systems, each with options to create ’audit’ log ﬁles. Each of these log ﬁles is created with independent application, or physical contexts. Thus, at all levels of abstraction, it is very diﬃcult to produce meaningful and interpretable views of what has actually happened. Some management tools exist for creating uniﬁed views, of your network or infrastructure (for example HP’s OpenView network management system), but these are more targeted to snapshot views for dynamic management purposes, rather than for interpreting the past. From a security perspective, a challenging and signiﬁcant problem is how to demonstrate the integrity of the audit data. The integrity question is important for an individual event record, a collection of events within a context, or even the whole (growing) set of records. Current best practice for the integrity of log ﬁles involves writing records to a WORM (write once read many) device, or maybe using Time stamping. However, because it is so easy to hide, manipulate, or create ﬁctitious electronic data it is questionable whether these approaches do enough to guarantee integrity. Moreover, the problems do not simply relate to preventing collusion between entities and their timestamp provider. More generally, any structures used to demonstrate integrity have to be done in the context of the whole audit process. Speciﬁcally, audit data should not be dead data that may be trawled through at some future date. Accountability is only achieved when the data is examined - it therefore needs to be searchable and viewable. Moreover its integrity will need to be independently veriﬁable, that is, it is not enough to prove integrity only to privileged users that have arbitrary access to all audit data (as such roles are likely to be limited, if they exist at all).

16

Adrian Baldwin and Simon Shiu

In summary, audit is fundamental to security and trusted business processes. Any service purporting to address audit needs to do so in a holistic sense, encompassing all the aspects and layers of electronic process and data. Finally, the service needs to provide strong record integrity and the ability for other parties to verify this integrity trustably.

3

An Audit Service

IT audit systems need to retain a high degree of separation from the usual infrastructure and therefore can be viewed as third party trust services [6]. This section describes such a third party service that receives, notarises and stores audit information as well as providing an interface for retrieving relevant audit events. This section describes the basic components and functionality of such a service and illustrates the service and associated trust issues using an example of the audit of medical records [5]. Trust in the service is largely provided by a set of notarisation structures that are described in the next section and in turn, trust in these structures is rooted in trust in a timestamp authority. Section 5 describes how a secure hardware service delivery model can be used to engender trust in the timestamp authority whilst allowing the service to be integrated into the overall IT infrastructure. As with traditional audit service, events are

Index Info

Users

Audit Record

Event Description

Notarisation

e1 e2 . . . ej

Query Engine

Index Data

Auditors

Fig. 1. The basic audit service received and added to the end of a log ﬁle. Again as with traditional audit service, these events will receive some form of timestamp allowing the integrity of the event data and the overall audit log to be veriﬁed and checked. Typical audit services do little to worry about how audit data is viewed and checked but this service oﬀers an interface to interested users so that they can query the system and recover events of interest and relevance to themselves. Searching a large log ﬁle is obviously time consuming and undesirable, as such, the audit service holds a database that indexes the audit events. The

Enabling Shared Audit Data

17

query mechanism uses this indexing database so that it can eﬃciently search over a range of queries and recover the appropriate audit records. Whilst events could just be placed into a database on being received, it is important to retain and manage the sequential nature of the audit log. Keeping this sequence is necessary to preserve a strong ordering of records, ensuring that records cannot be removed or alternative histories held. Fig. 1, shows the architecture of such an audit service with a notarisation module that receives and timestamps events. Events are then stored in the audit log and indexing information is added into the indexing database. This database includes a query engine that allows a user with the appropriate authentications and authorisations to request a segment of the audit trail. An auditor may use this query database but they may also have programmatic access to the full dataset. A traditional audit record will not be easily formatted to support indexing thus will often be low-level records that have little meaning for the end users such as an underwriter. However, the high-level audit data bridges the audit gap between the paper records and the underlying IT. As such, this type of audit service may not replace system log ﬁles but instead encourage applications and workﬂow systems to generate meaningful audit information. This information is expected to take the form of an event record containing a set of indexes, values for those indexes and a description. Thus, an event record e will have the form: < Event type ... < indnp , valnq >> description > where there are n indexing tuples that deﬁne each index of interest and a value within this index. The set of possible indexes will be deﬁned by the audit service and the application creating each audit event chooses how many and which indexes are used. A users query will be in the form ’give me all events where < indi = valk >..< indj = valm >’ and the audit system will return the whole event set matching those indexes. Such searches rely on the audit events having correctly indexed data. Events can be checked against templates before acceptance to check they include a minimal set of indexes. For any query, the user will get back a set of audit records and they are ﬁrstly concerned with the structure of the record: – When was the record created? – Has it been changed? They will also be concerned to check the validity of the overall audit segment: – Is each record part of the audit log? – Do I have all records? The notarisation structures described in the next section address these issues so that for a simple query the user can check the integrity of the record, that they are a part of the log ﬁle and that they have all appropriately indexed records. These structures ensure that they get the full picture of what has happened and make it very hard to change records, add alternative histories or hide records.

18

Adrian Baldwin and Simon Shiu

This is done at the level of a requested segment of the audit record as well as the record as a whole. 3.1

Example

Before delving into the details of the notarisation structures, it is useful to illustrate the importance of the audit service with a simple example. Consider an electronic patient record (EPR) system that records how patients are treated. Audit is a critical function in keeping doctors and other medical staﬀ accountable and it provides an aid in reviewing and dealing with the many disputes. An EPR would typically gather all information and may include timestamps showing the data has not changed. The EPR itself may be built on top of a standard database. Typically, these systems would be under the control of a hospital or health authority. In cases of a dispute, the time stamp may make it hard to insert a new record; however, once treatment is disputed relevant records could be suppressed. Alternatively, on early realisation of a mistake a doctor could record an alternative history and use this instead in the dispute. This shows the importance of being able to show the integrity of the whole audit system. Currently this would be done by allowing a discovery process where lawyers could wade through the millions of treatment events created over the relevant period. Audit services designed to not only share the audit data but also to demonstrate the integrity of this data very much simpliﬁes this task (the next section describes such structures). Sharing such event and audit data between the many interested and authorised parties can help smooth the underlying processes in that the audit service now provides a clear view on all that is happening in these processes. Trust in the notarisation structures does heavily rely on trust within the notarisation process as events are sent for audit. Audit services naturally have a close relationship with the entity that is being audited - they receive much conﬁdential data - this relationship could lead to collusion. A further attack to the integrity of the audit data would be if the hospitals audit service could be persuaded to rewind their clock and create a new history. The notarisation structures partially address this problem by publishing elements of the audit log. The proposed service delivery model also addresses this issue in that it allows the audit service to be an intimate part of the IT infrastructure but because it a service running within a secure hardware component it is hard to subvert. The service is software it does not have friends or a bribery interface - anyway what would it do with money?

4

Demonstrable Integrity

The basic ingredient of an integrity check is the timestamp. When a veriﬁer ’trusts’ a timestamp they essentially trust the timestamp authority, and their processes for securely using their private signing key. As hinted at in the introduction, and discussed more fully in section 5, the timestamp service is being

Enabling Shared Audit Data

19

delivered using secure hardware. This changes the trust relationship from trusting workﬂow processes relating to invoking a timestamp, to one of trusting the manufacture and coding of secure hardware. This makes it easier for a timestamp authority to demonstrate that they have not colluded (say to create ﬁctitious records) with any of their customer entities. However, the example above showed that it is still possible to create alternative ﬁctitious accounts, and to choose what to present. For this reason, this work makes use of a publishing service, which allows entities to record events, and clusters of events as ’part of the oﬃcial record’. 4.1

Notarisation Structures

The designs of the structures in this section serve 2 purposes: 1. The various interleavings make it more diﬃcult for entities to create alternative ﬁctitious records, and to make it more diﬃcult to hide records. 2. To allow eﬃcient and sharable ways to verify integrity based on trust in the timestamp authority and the publishing service. The chaining structures introduced in section 4.2 are what constitute the published ’oﬃcial record’. Collecting hashes without any structure is not enough, as this would allow entities to burrow ﬁctitious versions of events within the record. Auditors or sceptics will want ways to check the bijective mapping between oﬃcially recorded events, and (segments of) the raw log ﬁles presented. Moreover, they want to be able to do this without having access to all the hashes, and of course, without all the recorded events. Relating this to the example above, the auditor needs some evidence that each record they receive back was consciously placed in the oﬃcial record. The converse check that everything related to the query was returned is harder to achieve. The bijective mapping would allow such a check in some contexts, e.g. we could check that we have ’all records from a given application between given dates’. The index chaining described in section 4.3 enables richer completeness checks. User queries involve searching for particular values in one (or more) index. Assuring a requestor that they are seeing all records relevant to a query is in fact assuring them that they are receiving all the relevant records to which indexes have ever pointed. More speciﬁcally, it is still possible to edit the indexes to only point at a subset of the records. Index chaining resolves this problem by chaining events according to each index value they contain. Before being time stamped the hash of each of the previous records from each of the relevant index ﬁles is added to the message allowing users to validate that they have a continuous set of records for the search key. 4.2

Notarisation Chaining

A traditional audit log contains a sequence of all (auditable) events occurring within a system. This should be contrasted with a receipting model where individual events are created but are not sequenced. The receipt is a useful structure

20

Adrian Baldwin and Simon Shiu

because it can be looked at in its own right - however the audit log gives the larger picture of the full sequence of events. The notarisation chaining described here achieves a compromise between the two. Before describing the proposed chaining solution, it is useful to consider the security and integrity of the two diﬀerent solutions. Audit data can be secured by having the data signed by an audit service or a timestamp authority at the point of creation. Equally, receipts should be signed and time-stamped on creation. In each case, the time stamp authority (tsa) [7] creates a structure [1] including the hash of the event, coupled with the time it was seen by the timestamp authority, along with possible sequence numbers and usage restrictions. This creates individual records whose integrity can be validated based on trust in the audit or timestamp service. The audit log contains a sequence and this should be reﬂected in the notarisation or time stamping of the individual records. Chaining time stamped audit records allows an auditor to look at a whole log ﬁle and check that an individual event is validly contained within the ﬁle. It also allows them to check the order in which they were inserted. This ability to validate a sequence is an essential feature of the audit ﬁle; it stops alternative histories being created and individual records being removed from the system. However, to validate the audit ﬁle the auditor must have access to all the audit records and the volume of records make this process time consuming. To see this, consider the following naive chaining approach. The audit system receives a number of events e1 ...ei ...en each of which is given a timestamp and chained in the normal manner creating a composite audit structure ai =< ei , tsi > where tsi is the timestamp containing the information tpi =< hash(ei ), hash(tsi − 1), time, TSA> such that tsi =< tpi , Sig(T SA, tpi) >. This is the simple form of chaining described above that enforces a sequence between the various events but does not allow for an easy validation that an audit record aj is a member of the overall audit record. A user seeing a small set of audit records relating to their transactions has no validation path to check that each event is part of this sequence and in eﬀect, they just see each signed structure as a receipt. The sequential nature of the log is thereby lost. The audit model described in section 3 involved many people having access to a small subset of the audit records. The aim of this ﬁrst element of the notarisation chaining is to allow the user to check that each record they receive is a member of the overall audit sequence whilst reducing the amount of other data that they must examine (and have rights to see). At the same time, the auditor should still be able to check the consistency of the overall log ﬁle, or pieces of it - particularly in cases where users have suspicions. Figure 2 shows the tree like notarisation structure proposed here. At the bottom is the sequence of audit events a1 ...an ... whilst at the top a smaller summary sequence is published. A number of intermediate nodes sit between the full event sequence and the published summary sequence. An audit record now has the form < ai ,i1j ,i2k ,tl > where ai is the original audit record, i1j is the jth node of the ﬁrst intermediate layer, i2k is the kth node of the second intermediate layer and so on until the top

Enabling Shared Audit Data

21

Chain returned to user Published Layer ht0hi1, hi2 hi3 hi4

ht3hi14 hi15 hi16 hi17 hi18

ht6hi55 hi56 hi57 hi58

Intermediate Layers hi15 = Hash(I15) I15 hi14 he109 he110 he111 he112

I56 hi15 he312 he313 he314he315 he316

he109 = Hash(event110) event110

event314

Fig. 2. Deﬁning the audit sequence with a single intermediate layer

published chain is reached (where tl ) is the lth node. The number of intermediate layers will be a design decision of the audit system depending on the volume and frequency of event data. The ﬁrst layer of intermediate nodes can be thought of as breaking the audit trail into a series of blocks, which are themselves, chained together. The intermediate node thus contains a number of hashes and has a body ibj =< hash(an )...hash(an + s), hash(i1 j − 1) > and this structure could be signed but it is not necessary. The body thus contains the s hashes of consecutive events the value of s will be randomly selected between ﬁxed bounds or deﬁned times. This intermediate layer now forms a sequence itself with |a|/mean(s) elements. Subsequent intermediate layers can then be created on top of this sequence each time reducing the size of the sequence. Instead of being formed from the hash of the audit events, the next layer is constructed from the hashes of nodes in the previous layer. Each intermediate layer reduces the volume of events and since the number of events within each node is random it is harder to ascertain exact event numbers although where a simple probability density function is used to generate s the longer-term traﬃc trends will become determinable. However, additional padding events could be added to disguise traﬃc volume where this is sensitive. Now the top-level audit trail deﬁnes the sequence of the overall log ﬁle so that a user with an audit record can check that a particular event is within the audit trail and they can examine the relative order of events (by comparing positions within the intermediate nodes). Since the published summary audit trail now deﬁnes the sequence on the overall data structure, the audit authority should sign each of these top nodes. This allows the published audit trail to be veriﬁed and makes it harder to subvert at some later point without collusion. The published trail could be interleaved with the public trails from other audit systems [2] again reducing the likelihood of collusion. A search of the audit system, for example relating to all treatment for a particular patient, will result in a set of audit events being returned. Each audit

22

Adrian Baldwin and Simon Shiu

event will have the form of < ai ,i1j ,i2k ,tl >. The patient making the query can programmatically validate the audit event itself and check that the record has integrity. They can also check that the hash of the audit record hash(ai ) is within the intermediate node, and so on until the top node is reached. The top level chain will be published allowing a patient can also check that the top level node they have been given matches that in the chain as well as validating the integrity of the overall audit sequence - now represented by much fewer records. A simple validation algorithm can compute these results and this could be executed by the user or by a third party - equally, as the structures are opaque the validation algorithm can be written by a third party. The user need not see the full audit trail. Auditors can still validate the overall trail ﬁrstly, by looking at the audit event sequence that is chained together and secondly, by validating the intermediate structures and the published summary trail. 4.3

Index Chaining

The notarisation chaining structures described above are largely concerned with deﬁning the sequence on audit events when the user only sees a sparse collection of events from the overall sequence. It does not help the user in knowing that they have all relevant records - that the audit system or those who may have some legitimate or illegitimate control over it have suppressed data - or that those critical records are lost through accident. An auditor can, by having access to the full set of audit data, check the completeness of the audit log but in an audit system that can be queried a more accessible method is required. The original description of the audit service at the beginning of this section describes the structure of the audit event which is expected to have a number of deﬁned index ﬁelds value pairs as well as the basic event description. Thus the raw event has the form ei =< Event type ...< indnp , V alnq >> description > that is there is a set of index speciﬁcations that list indexes and the value in those indexes for a particular event. A query takes the form of ’ﬁnd all events with the value valv in index inda ’ and the user needs the ability to check that they have corresponding values. The audit service has structures associated with all indexes that allow all the events to be found. Each index within the audit system would typically be formed from some form of tree structure such as a b-tree which will include a reference to each index value seen (for example each patient). For each entry in this index tree there will be a table of relevant audit records such that on querying for all records for a particular patient these records can easily be recovered. These indexing structures, shown in Figure 3, must sit along side the basic audit log ﬁle and will have a set of pointers into that ﬁle. An incoming query will ﬁrstly lead to a search of the tree structure for that index; this will lead to an entry table for that value. The system must then collect all these entries from the audit log ﬁle, package them up with the notarisation chaining and send them back to the user. These additional index structures could be created, stored and managed using a traditional database.

Enabling Shared Audit Data Index 1 (eg patient name) name= Adrian

23

Record Store Raw Audit Messages

Key= Simon

Obj1

Obji Objj {I1=Adrian, I3=asprin}

Index 3 (eg Drug) Name= asprin

Objn

Name= Prozac

Fig. 3. Structures for indexing the audit log

The indexing structures described allow the audit system to respond to a users query without trawling through all the audit data but it does not directly help answer the ’have I got all relevant data’ problem. Each table created for an index entry consists of a series of pointers to audit events. This table forms a sequence for a particular query; and if the user can see that the sequence is unbroken, has deﬁned start and end points they can have conﬁdence they are seeing all relevant events. To achieve this the sequence of pointers within each

Indexi Keyj Entry Table H0=Start Flag H1=Hash(mesgl|| H0 )

Notarised Events Contain Index Chain Mesgl Index=IndexI Key=Keyj Hash=H1

H2=Hash(mesgm|| H1) H3=Hash(mesgn||H2)

User could add Extra ‘chain complete’ record

Mesg2 Index=IndexI Key=Keyj Hash=H2

Index Chain = H0,H1,H2,H3 User can Check Chains Continuity

Mesg3 Index=IndexI Key=Keyj Hash=H3

Fig. 4. The index chaining structures index are chained together. An incoming event will have additional index chain information added that corresponds to each of the index values. On adding an event, the system will look at each of the index, value pairs and recover the previous audit record for that value within that index - or rather; it recovers the hash of the previous audit record. It then creates an index chaining record that

24

Adrian Baldwin and Simon Shiu

includes the hashes of previous records for each previous value of an index. This happens before the audit record is signed by the timestamp authority and placed within the audit log. It is worth noting here that the arrival time and sequence should be recorded for notarisation such that delays in calculating these indexes (particularly in multi-threaded and multi-processor systems) do not change the event order. The audit record now is sealed (i.e. time stamped) with the original event message, the time it arrived, its sequence within the overall structure and the sequence within each index. The audit record ai now consists of a tuple < iei , tsi > where tsi is the timestamp of iei and iei = > description >< hash(prev(< indx1 , valy1 >)), ... hash(prev(< indxk , valyk >)). >>. Where the prev() function gives the hash of the previous audit record for any particular index, value tuple. A user’s query will take the form of ﬁnd all records for a particular index value tuple. Now when a set of records is returned, the service can also return index chains that allow the user (or more likely trusted software) to check that the chain continues from the beginning to the latest record (see Figure 4). There are issues relating to trusting the start point, and end point of each index. When a new index value is entered the prev() function returns no value the index entry is ﬂagged as the ﬁrst entry and a new index structure is created. The hash values for each index or the sequence start ﬂag are recorded and sealed by the timestamp at the time of creation. A user worried that the latest record might be missing can force a new record to be added that relates to their query - this should be the last record they see and binds together the record set. The system now heavily relies on the protection and proper use of the keys associated with the timestamp service but as long as they are well protected, the index chaining becomes very hard to break. The publication of the summary audit trail would make it very hard to replace one of these records. An auditor could of course check the integrity of the overall system, that there are no discontinuities within the records. Users may of course ask complex queries involving a number of indexes and values or for values within certain ranges. In cases where there is an intersection between results sets the user cannot perform the index chaining validation. However, they can split the query into parts and validate the parts.

5

Realisation

A prototype of the audit service described in sections 3 and 4 has been built and applied to a medical workﬂow process. Audit is a necessary important feature within many signiﬁcant electronic services hence it is important that the service can be delivered in an eﬃcient and trustworthy manner. There is a clear tension using a strong third party trust service for audit and the need for a local eﬃciet service. Using a remote service could result in the processes being audited bcoming blocked due to network delays.

Enabling Shared Audit Data

25

The obvious way to deliver the described audit service would be to give it an online presence at some address on the internet. Events would be securely sent to the service where they are notarised and stored. Much of the trust is rooted in the notarisation process and therefore the interaction could just be changed to run the notarisation services remotely. In this case, the hash of the audit record (event and index hashes) are sent remotely and a central service will generate the timestamp along with the notarisation chain. The event database will be run within the IT infrastructure whilst the notarisation is run in a diﬀerent trust domain at the third parties site. The other extreme would be to run the entire audit system locally. Here the notarisation service would be run on a heavily protected server. A well run IT infrastructure may enforce these separations but there are clear trust issues for outside parties who may claim collusion. An alternative solution is to use a secure hardware based service to lock down the keys and processes associated with the time stamping. This is the HSA approach described below. 5.1

Hardware Security Appliances

IT Infrastructure HSA Based Service Service API Service (Key use, Authentication, Authorisation, Audit.... Management Policies Service Identity

Signed Chain of Management events

System Administrators Domain

Management Interface (Constrained by Policy) Network

Service Controller

Fig. 5. An HSA approach to service delivery The hardware security appliance (HSA) approach [8] [9] oﬀers a way to run a service within its own trust domain whilst it is physically located with the conventional IT systems. The HSA itself is a tamper resistant hardware device; for example, based on a hardware security module (HSM), which provides a safe environment for services to run. Such a device will have active hardware protection [10] which will detect tampering and destroy cryptographic material. An HSM traditionally oﬀers a cryptographic API such as PKCS#11; an HSA is a very similar - if not identical-physical device but with very diﬀerent ﬁrmware allowing a service to be loaded, certiﬁed and conﬁgured. In doing so, the service binds together various critical security functions such as authentication,

26

Adrian Baldwin and Simon Shiu

authorisation and audit along with cryptographic key usage into a simple service API. For example, an HSA based service has a trusted clock and can ensure that keys used in time stamping only use this clock - thereby avoiding time rollback. On a service being loaded into the HSA (Figure 5), it is conﬁgured with its own management policies and given its own (PKI based) identity, certiﬁed by the service provider. As well as the service, oﬀering its normal functional API it also deﬁnes how it can be managed and the initialisation binds it very strongly to a service controller. The service now operates within its own trust domain physically enforced by the tamper resistance of the secure hardware and logically enforced through the limited service API and these initial management policies. The management policies deﬁne not only who controls the service but the extent of their control (even specifying no management control). These management functions can be carried out remotely using the PKI identities of the HSA based service and the service controller. This has changed the secure hardware device from oﬀering a simple cryptographic interface to a being a service delivery model. A crypto API help protect keys from disclosure but a subverted server process can still misuse key. Research has shown [11] [12] [13] how further security can be achieved by putting more of the application within the secure hardware. The HSA approach tries to take this further by using the secure hardware as a service delivery model creating a strongly controlled domain for limited but security critical process to run. 5.2

Integrated Audit

Instead of sitting on an internet port the notarisation service provider can create the notarisation service within an HSA and deliver the service by shipping the hardware. The simplest form would simply be to have an HSA based service with a trusted clock and a sequence counter. The service would receive an event hash, combine it with the time and sequence number forming a timestamp that is then signed with the service identity; which in turn is certiﬁed by the service provider. The API does not allow any other functions making it hard to subvert. The audit service is slightly more complex in that as the notarisation service timestamps a record it is also building the notarisation chain. Given the limited resources of the secure hardware, the chain is stored on the host systems disk with the secure hardware recording a hmac of the current state. As a new event is time-stamped, its hash is added into the chain data and the hmac updated within the HSA. Once the chain block is ﬁlled, it can be signed and sent to the database with a new open chain block being created including the hash that has just been signed. The same process happened for each level of the chain right up to the top published chain. The audit service is slightly more complex in that as the notarisation service timestamps a record it is also building the notarisation chain. Given the limited resources of the secure hardware, the chain is stored on the host systems disk with the secure hardware recording a hmac of the current state. As a new event is time-stamped, its hash is added into the chain data and the hmac updated within the HSA. Once the chain block is ﬁlled, it can be signed and sent to the

Enabling Shared Audit Data

27

database with a new open chain block being created including the hash that has just been signed. The same process happened for each level of the chain right up to the top published chain. Events must be time stamped as soon as they arrive at the audit service to ensure the correct event sequence is retained. However, the timestamp needs to be generated after the index chain information has been computed which will delay events and in a multi-processor system could cause events to be reordered at busy times. To prevent this, the event is initially sent to the timestamp service that registers the event, keeping an association between the time, sequence number and hash of the event. Once the complete audit record has been created, it is passed back to the timestamp service the hash is compared with the appropriate part of the audit record and the timestamp with the original time is produced. Where scalability becomes an issue several HSA devices can work in co-operation using one as a central clock. In this discussion, it is important to note that the service is provided by an external authority and this service is protected by the secure hardware. Further trust can be gained by publishing the service code so others can verify the lack of backdoors.

6

Related Work

There is a considerable body of work concerning time stamping and chaining structures created to avoid collusion between the timestamp authorities [1] [2] [3] [4] [14] [15]. These structures are aimed at ensuring that the integrity of the document can be proved and making sure that the document cannot be revisited. Techniques range from Merkle’s hash trees involving the periodic publishing of the root of a hash tree in a well-known publication through Haber’s digital signature schemes to mixed schemes creating chains of hashes as well as having a TSA sign the basic timestamp structure. There is even a time stamping standard deﬁning the format of a digitally signed timestamp along with the interactions with the timestamp service. Clearly, the structures proposed in this paper build on the previous timestamp work from the basic timestamp structure through the publication of summary nodes to root trust in the system. Little work has been carried out into expanding the role of an audit service to share event data trustably. The proposed structures have been created and tailored for this wider audit problem aimed at allowing others to see not only the integrity of individual events as in a time stamped receipt but also to check that the events are from the audit log and that all events of interest have been retrieved. Issues surrounding collusion are partially dealt with by publishing the summary audit trail. It would be hard to backdate an event such that it ﬁts into this published trail. Even if the published trail for a particular audit service could be subverted, it would be hard to gain access to signing keys that are generated within secure hardware and subsequently protected by active physical protection. The system is still rooted in social or brand trust in the device man-

28

Adrian Baldwin and Simon Shiu

ufacturer but they are so remote from the solution being audited that collusion is very unlikely.

7

Conclusion

This paper presented a study of the audit problem proposing that audit data should be available to all interested parties to ensure it will be checked. Extended timestamp structures based on chaining over time and index data are described that enable this trustworthy sharing of audit data. They allow users to ask for particular segments of audit data, validate the integrity of both the data and the set of the data. Secure hardware creates a virtual trust domain allowing an trust in an eﬃcent local service to be rooted. This type of audit service provides a strong root of trust in ensuring those in control of IT infrastructures and solutions are held to account for their actions.

References [1] Haber, S., Stornetta, W.S.: How to time-stamp a digital document. Journal of Cryptology 3 (1991) 99–111 [2] Bayer, D., Haber, S., Stornetta, W.S.: Improving the eﬃciency and reliability of digital time-stamping. In: Sequences’91: Methods in Communication Security and Computer Science, Springer-Verlag (1992) 329–334 [3] Merkle, R.: Protocols for public key cryptography. In: IEEE Symposium on Security and Privacy. (1980) 122–134 [4] Merkle, R.: A certiﬁed digital signature. In: Advances in Cryptology. (1989) [5] Ferreira, A., Shiu, S., Baldwin, A.: Towards accountability for electronic patient records. In: The 16th IEEE Symposium on Computer-Based Medical Systems. (2003) [6] Baldwin, A., Shiu, S., Casassa-Mont, M.: Trust services: A framework for service based solutions. In: 26th IEEE COMPSAC. (2002) [7] Adams, C., Cain, P., Pinkas, D., Zuccherato, R.: Rfc 3161 internet x.509 public key infrastructure time stamp protocol (tsp) (2001) [8] Baldwin, A., Shiu, S.: Encryption and key management in a san. In: IEEE Security In Storage Workshop, SISW02. (2002) [9] Baldwin, A., Shiu, S.: Hardware security appliances for trust. In: First International Conference on Trust Management, Springer Verlag (2003) [10] FIPS: Security requirements for cryptographic modules. FIPS 140-2 (2001) [11] Smith, S., Palmer, E., Weingart, S.: Using a high performance programmable secure coprocessor. In: The second international conference on ﬁnancial cryptography, Springer-Verlag (1998) [12] Itoi, N.: Secure coprocessor integration with kerberos V5. In: Usenix Security Symposium. (2000) 113–128 [13] Smith, S., Saﬀord, D.: Practical private information retrieval with secure coprocessors. Technical report, IBM Research T.J. Watson Research Centre (2000) [14] Buldas, A., Laud, P., Lipmaa, H., Villemson, J.: Time-stamping with Binary Linking Schemes. In: Advances on Cryptology — CRYPTO ’98, Springer-Verlag (1998) 486–501 [15] Schneier, B.: Applied Cryptography Second Edition: protocols, algorithms and source code in C. Wiley & Sons, Inc (1996)

Cryptographically Generated Addresses (CGA) Tuomas Aura Microsoft Research Roger Needham Building, 7 JJ Thomson Avenue, Cambridge CB3 0FB, UK [email protected]

Abstract. Cryptographically generated addresses (CGA) are IPv6 addresses some address bits are generated by hashing the address owner's public key. The address owner uses the corresponding private key to assert address ownership and to sign messages sent from the address without a PKI or other security infrastructure. This paper describes a generic CGA format that can be used in multiple applications. Our focus is on removing weaknesses of earlier proposals and on the ease of implementation. A major contribution of this paper is a hash extension technique that increases the effective hash length beyond the 64-bit limit of earlier proposals.

1. Introduction Cryptographically generated addresses (CGA) are IPv6 addresses where some of the address bits, usually the 64-bit interface identifier, are created from a cryptographic hash of the address owner's public key. The address owner uses the corresponding private key to sign messages sent from the address or to assert its ownership of the address. Anyone can verify which public key matches the address. The only way to circumvent this authentication is to find another public key that produces the same hash, i.e. to break the second pre-image resistance of the cryptographic hash function. The main advantage is that no third parties or additional infrastructure, such as a public-key infrastructure (PKI), are needed. Any IPv6 node capable of basic cryptographic operations can generate a CGA address locally, and only the address and the public key are needed for verifying the signatures. CGA-based authentication is particularly useful in securing IP-layer signaling protocols, such as neighbor discovery, where IPv6 addresses are the primary identifiers for the protocol participants. This paper describes a generic format for cryptographically generated addresses (CGA) that can be used in many such protocols. We have solved the main security weakness of earlier CGA proposals by effectively removing the 64-bit limit on the hash length. The hash extension is important because otherwise exponential growth of computing power could enable an attacker to break CGA-based authentication and, thus, protocols that depend on it in the foreseeable future. We achieve the improvement by artificially increasing both the cost of generating a new CGA address and the cost of a brute-force attack while keeping the cost of CGA-based authentication constant. C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 29-43, 2003.  Springer-Verlag Berlin Heidelberg 2003

30

Tuomas Aura

Potential applications for CGA-based authentication include Mobile IPv6 binding update authentication, proof of address ownership in secure neighbor discovery and duplicate address detection, and key exchange for opportunistic IPSec encryption and authentication. Sections 2 and 3 survey related work and give some preliminary information. The CGA address and parameter formats are defined in Section 4. Detailed algorithms for generating addresses and for verifying them are given in Section 5. Section 6 explains our design decisions and Section 7 overviews promising applications on which there is ongoing work.

2. Related Work Cryptographically generated addresses first appeared in the CAM protocol for Mobile IPv6 binding update authentication by O'Shea and Roe [OR01]. Nikander [Nik01] suggested using the same technique for proofs of address ownership. Montenegro and Castelluccia [MC02] worked on similar proposal for Mobile IPv6, called statistically unique and cryptographically verifiable addresses (SUCV). All these addresses are self-certifying in the same sense as the self-certifying file names by Mazières et al. [MKKW99]. Our specification differs from the earlier CGA proposals by defining a general-purpose address format rather than focusing on specific applications. We also remove the main security weakness of the earlier techniques, the 64-bit limit on hash length. An alternative to CGA are different types of public-key infrastructures (PKI). In X.509, certificates issued by a hierarchy of certification authorities (CA) bind names to public keys. An X.509 certificate can be used to bind an IP addresses to the address owner's public key because the address can be seen as a name for its owner. KeyNote [BFIK99a] and SPKI [EFL+99] support qualified trust relations and authorization in addition to naming. These systems could be used to authorize a public key to send messages from an IP address. Unlike CGA, which depends on the 128-bit IPv6 addresses, the PKI-based security solutions work equally well for IPv4. Identity-based cryptography [Sha84] is an alternative to certificates. In identitybased signature schemes any identifier can be used as a public key. A trusted authority generates and distributes the corresponding private key to the owner of the identifier. Address-based keys (ABK) [ODG+02] are an application of this technique to IP address authentication. Any IP address can be used as the public key. ABK has the same infrastructure requirements and security properties as a certificate-based PKI: a trusted party is needed for distributing the private keys. The performance of ABK is better, however, because the verifier of ABK-based authentication does not need to obtain or verify a certificate. The biggest advantage of CGA-based authentication compared to a PKI or ABK is that it does not require a trusted authority, pre-established trust relationships or other security infrastructure. The HIP architecture (see Moskowitz [Mos01] and Nikander et al. [NYW03]) goes one step further than CGA and suggests using a hash of the public key as the primary identifier for IP nodes. In the host identity payload (HIP) protocol, a new protocol layer between the transport and network layers maps the hash-based identifiers to

Cryptographically Generated Addresses (CGA)

31

Sec = (interface identifier & 0xe000000000000000) >> 61 Mask1 (112 bits) = -1 1 with size polynomial in , consider the subset Ωn,r ⊂ Znr deﬁned as Ωn,r = Zn + nZr . Then, the function fn,r,e : Zn × Zr −→ Ωn,r (x, y) −→ xe + ny mod nr is a trapdoor bijection family, for pk = (n, r, e) and sk = (p, q, r, d), where d is the inverse of e modulo (p − 1)(q − 1).

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

73

Notice that this function is well deﬁned since z ∈ Ωn,r iﬀ z mod n ∈ Zn . Let us see that fn,r,e is a bijection. Suppose that fn,r,e (x0 , y0 ) = fn,r,e (x1 , y1 ) for some x0 , y0 , x1 and y1 . Reducing the equality modulo n we get xe0 = xe1 mod n, and then x0 = x1 mod n. This implies ny0 = ny1 mod nr, so y0 = y1 mod r and the function fn,r,e is injective. Finally, given (p, q, r, d), to invert fn,r,e on input z = fn,r,e (x, y), it suﬃces to compute x = z d mod n. Then, y is easily obtained from the equation ny = z − xe mod nr. This shows fn,r,e is exhaustive, and therefore it is a bijection. The above implies there exist two PT algorithms that compute both fn,r,e and its partial inverse. Proposition 5 The partial one-wayness of the bijection family fn,r,e is tightly equivalent to the one-wayness of RSA[n, e]. Proof : ⇒) Assume that for some there exists a PPT algorithm, A, breaking the partial one-wayness of fn,r,e in time T and probability , i.e. Pr [A(n, r, e, xe + ny mod nr) = x | x ← Zn ; y ← Zr ] = . The following PPT algorithm, B, can be used to invert the RSA[n, e] function (i.e. RSA[n, e](x) = xe mod n) in time T + O(2 ) with probability at least : B(n, e, z) 1 y ← r, z = z + ny mod nr 2 x ← A(n, r, e, z ) 3 return x

⇐) Trivial.

Proposition 6 The bijection family fn,r,e is easy veriﬁable. Proof : Given (n, r, e), it is straightforward to design a plaintext checking algorithm. Firstly, verify if x ∈ Zn and z ∈ Ωn,r , that is, if z < nr and z mod n ∈ Zn . Then, check if the equation xe ≡ z (mod n) holds.

3

Encryption Security

Let us brieﬂy recall the security deﬁnitions we will consider for symmetric and asymmetric encryption schemes. 3.1

Symmetric Encryption

Let K and M be two recognizable sets denoting the keys and messages spaces respectively. Let us consider a symmetric encryption scheme E sym = (KeyGensym , Encsym , Decsym ), over these sets, with the following properties. KeyGensym is a PPT algorithm that on input 1 outputs a uniformly distributed element in K . Encsym and Decsym are PT algorithms with inputs in (m) = Encsym (k, m) and Decsym (c) = K ×M and outputs in M . Denote Encsym k k

74

David Galindo et al.

Decsym (k, c). For each k ∈ K , Encsym is a bijection on M and Decsym is its k k inverse. Suppose that for each pair (m, c) ∈ M × M there are at most γ values of k ∈ K such that c = Encsym (m). k Such a cryptosystem has indistinguishability of encryptions (IND-SYM), also called Find-Guess security in [8], if any couple of PPT algorithms AIND−SYM = (A1 , A2 ) (called “ﬁnding” and “guessing” stages of the adversary) have negligible advantage in the following game: Game IND-SYM() 1 b ← {0, 1} 2 (m0 , m1 , s) ← A1 (1 ) 3 k ← K ; c = Encsym (mb ) k 4 b ← A2 (s, c )

That is, E sym is IND-SYM if and only if Adv AIND−SYM = |2Pr [b = b] − 1| = |Pr [b = b] − Pr [b = b]| ∈ negl(), for all (A1 , A2 ). The messages m0 and m1 generated by A1 must be in M . Note that this is a very weak security notion, but it suﬃces to obtain a secure hybrid cryptosystem. 3.2

Asymmetric Encryption

Let (P K, SK, I) be a keypair generator, as deﬁned in section 1. Consider an asymmetric encryption scheme E asym = (KeyGen, Enc, Dec), over appropriate sets M , R and C, with the following properties: – The keys (pk, sk) = KeyGenf (1 ) are generated by using the sampling algorithm for I. – Enc is a probabilistic encryption algorithm which, on inputs a public key pk ∈ P K and m ∈ Mpk , runs on a randomness r ∈ Rpk and returns a ciphertext c ∈ Cpk . – Dec is a deterministic decryption algorithm that, on inputs a secret key sk ∈ SK, and c, returns a string m. We require that if (sk, pk) ← KeyGen(1 ), then Dec(sk, Enc(pk, m, r)) = m for all (m, r) ∈ Mpk × Rpk . We say E asym is IND-CCA, if any pair of PPT algorithms AIND−CCA = (A1 , A2 ) have negligible advantage in trying to distinguish the encryptions of two selected messages, with access to a couple of decryption oracles Dsk and Dsk,c . When queried with a ciphertext c, the ﬁrst decryption oracle answers Dec(sk, c). The only diﬀerence between Dsk and Dsk,c is that the second oracle rejects c . Game IND-CCA() 1 (pk, sk) ← KeyGen(1 ) 2 b ← {0, 1} D 3 (m0 , m1 , s) ← A1 sk (pk) 4 c ← Enc(pk, mb ) G,H,Dsk,c 5 b ← A2 (s, c )

That is, E asym is IND-CCA if and only if Adv AIND−CCA = |2Pr [b = b] − 1| = |Pr [b = b] − Pr [b = b]| ∈ negl(), for all adversaries AIND−CCA . The messages m0 and m1 must be in Mpk .

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

75

Notice that the decryption oracle formalizes the access to a decryption machine. Thus, the adversary is free to submit any polynomially bounded string (except for the target ciphertext, c , in the guessing stage) to this oracle. This implies that IND-CCA security depends not only on the encryption algorithm, but also on the concrete implementation of the decryption algorithm, including its behaviour for inputs outside the set of valid ciphertexts. This information might be very useful for an adversary.

4

Revisiting Fujisaki-Okamoto Hybrid Scheme

In this section, the transformation introduced in [8] from weak symmetric and asymmetric schemes into an IND-CCA hybrid encryption scheme is revisited. Let E f = (KeyGenf , Encf , Decf ) be a probabilistic asymmetric encryption scheme deﬁned from a TPOW function family f, and E sym = (KeyGensym , Encsym , Decsym ) be a symmetric encryption scheme. Let H : X × M → Y and G : X → K be random functions. The hybrid scheme E F O = (KeyGenF O , EncF O , DecF O ) works as follows. Key generation. The keys (pk, sk) are generated as in KeyGenf . Encryption. The ciphertext for a message m ∈ M is c = (fpk (x, y), Encsym (m)), G(x) where y = H(x, m) and x is uniformly chosen in Xpk . Decryption. To decrypt a ciphertext c = (c1 , c2 ), ﬁrstly compute x = gsk (c1 ). (c2 ) and return m if c1 = fpk (x, H(x, m)). OthThen, compute m = Decsym G(x) erwise, return the reject symbol ⊥. If it is not possible to compute gsk (c1 ) or Decsym (c2 ), return ⊥. G(x) Let AIND−CCA [T, , qG , qH , qD ] denote an adversary against the IND-CCA security of the above cryptosystem that runs in time T with advantage , doing no more than qG , qH and qD queries respectively to the random oracles H, G and to the decryption oracle Dsk . Then, the result claimed in [8] can be reformulated in the following way: Theorem 7 If there exists for some values of an adversary AIND−CCA [T, , qG , qH , qD ], then there exists an adversary APOW that in time T1 breaks the partial one-wayness of f with success probability 1 and an adversary AIND−SYM that in time T2 breaks the IND-SYM security of E sym with advantage 2 such that −qD 1 1 ≤ (2(qG + qH )1 + 2 + 1) 1 − 21 − 22 − − −1 |Y | |M | and

T = min(T1 , T2 ) − O((qG + qH ) log(|X||M |))

The main drawback of this scheme is that the security reduction obtained in the proof is not tight, due to the quantity qG + qH multiplying 1 . However, the same authors improved in [9] this result for the particular case of the OkamotoUchiyama scheme [13] (known as EPOC-2) and claimed, without proof, that a tight reduction is obtained for trivial easy veriﬁable primitives, using our terminology.

76

4.1

David Galindo et al.

Identifying Dangerous Ambiguities

However, as pointed out in the introduction, several attacks against EPOC-2 have been found [10,6,16]. Despite the reﬁnements introduced in FO conversion after [10], there are still some ambiguities both in the scheme and in the security proof that compromise the validity of the theorem above. For instance, let us consider a TPOW function f , and Xpk ⊂ X pk such that fpk (x, y) is computable in polynomial time for any x ∈ X pk and y ∈ Ypk . Then, some badly generated (m)) for x ∈ X pk \Xpk may be accepted. ciphertexts c = (fpk (x, H(x, m)), Encsym G(x) This was the case for the Okamoto-Uchiyama function in the original EPOC-2, where X pk = Z2 +1 and Xpk = Z2 , for 2 < p < 2+1 . This information was used in [10] to obtain the secret value p. As Fujisaki and Okamoto proposed later in [9], this attack is avoided if all ∈ Xpk are rejected. However, when this ciphertexts (c1 , c2 ) such that gsk (c1 ) change is included in the general conversion a problem of diﬀerent kind arises. If X is not a recognizable set, the checking cannot be performed in polynomial time. In this case the simulation of the Dsk in the proof is not correct. Nevertheless, it is possible to use an additional oracle to solve this problem. In this situation, an adversary can use the decryption oracle to solve a diﬃcult decisional problem. As a result, we could only guarantee that breaking security of the cryptosystem is equivalent to solving a gap problem; that is, a stronger assumption than claimed. This is the case for the Blum-Williams one-way trapdoor bijection family (i.e. squaring quadratic residues modulo n = pq), where Xpk = Qn and X pk = Zn . Rejection of all ciphertexts (c1 , c2 ) such that gsk (c1 ) ∈ Xpk means that the adversary will know if an arbitary x ∈ Zn is a quadratic residue. Thus, the INDCCA security of the hybrid cryptosystem will be based on the gap between the quadratic residuosity modulo n and factoring n assumptions. 4.2

The New Proposal

From the above discussion, we know that although it is necessary to check if gsk (c1 ) ∈ Xpk to avoid leaking vital information, this cannot be done in all cases. In this section, we restrict the asymmetric primitives to those which admit a correct and unambiguous proof of security for the general transformation. We also take into account the results in [6,16] that use the ability to distinguish among rejection rules in the hybrid scheme to launch a total break. Thus, we slightly modify the speciﬁcation of the decryption algorithm in the conversion. Finally, the recent developments in [12,3,4] can be applied to this transformation, and together with the concept of easy veriﬁable primitives, they are used to give a new proof of security, thereby improving the concrete security result presented in the original work. Let E sym = (KeyGensym , Encsym , Decsym ) be a symmetric encryption scheme and E f = (KeyGenf , Encf , Decf ) be an asymmetric encryption scheme, obtained from a TPOW familiy f . The ﬁrst change we introduce is that the random functions H, G are deﬁned with inputs in {0, 1}∗ and outputs in their respective

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

77

domains, that is, H : {0, 1}∗ → Y and G : {0, 1}∗ → K. It is unrealistic to restrict the inputs of the random functions, as the authors suggested, since in a practical implementation random functions are replaced by cryptographic hash functions. Now, X and M must be recognizable sets. Note that this is a restriction only for X, since almost always M = {0, 1}p(), for some polynomial p. In contrast, Z is not required to be a recognizable set. Instead of this, it is assumed that there exists a recognizable set Z¯ such that Zpk ⊆ Z¯pk , and that the partial inverse of fpk can also be computed (in polynomial time) on elements of the extended set Z¯pk . The proposed hybrid cryptosystem, E = (KeyGen, Enc, Dec), is almost the same as the original. The only change is that now two diﬀerent rejection symbols are produced in the decryption algorithm Dec. Thus, when a ciphertext is rejected, the adversary will know the reason, obtaining diﬀerent rejection symbols without mounting a timing attack. Then, if the computing time of each step in the algorithm is independent of the data, the scheme seems to be robust against reject timing attacks. Dec(sk, c) 1 if c ∈ Z¯pk × M ; return ⊥1 ; endif 2 (c1 , c2 ) = c 3 x ← gsk (c1 ) 4 m ← Decsym G(x) (c2 ) 5 y ← H(x, m) 6 if x ∈ Xpk or fpk (x, y) = c1 ; return ⊥2 ; endif 7 return m

It is necessary to point out that in the OR operation in step 6 of the algorithm, both predicates have always to be evaluated in order to prevent the adversary from detecting an extra rejection reason. Next the security results are stated. The ﬁrst theorem is for the special case where f is an easy veriﬁable function, while the corollary works for general TPOW functions. Theorem 8 If there exists for some values of an adversary AIND−CCA [T, , qG , qH , qD ] against the IND-CCA security of the proposed cryptosystem for an easy veriﬁable function family f , then there exists an adversary APOW that in time T1 breaks the partial one-wayness of f with success probability 1 , and an adversary AIND−SYM that in time T breaks the IND-SYM security of E sym with advantage 2 such that 2qD 2qD qH γ + , ≤ 1 + 32 + |K| − qD qH γ |Y | − qD T1 ≤ (qG + qH + qD + qG qD )T [V] + qD T [f ] + T [Decsym ] + T where T [V] is the time complexity of the plaintext checking algorithm and T [f ] is the time complexity of f . Proof : The proof is delayed for the appendix.

78

David Galindo et al.

Notice that now the probabilities are tightly related. In the general case, a plaintext checking algorithm might not exist. Using the access to a plaintext checking oracle instead, the following result is straightforward. Corollary 9 If there exists for some values of an adversary AIND−CCA [T, , qG , qH , qD ] against the IND-CCA security of the proposed cryptosystem, then there exists an adversary APOW−PCA that in time T1 breaks the POW-PCA of f with success probability 1 , and an adversary AIND−SYM that in time T breaks the IND-SYM security of E sym with advantage 2 such that 2qD 2qD qH γ + , |K| − qD qH γ |Y | − qD T1 ≤ qG + qH + qD + qG qD + qD T [f ] + T [Decsym ] + T ≤ 1 + 32 +

where T [f ] is the time complexity of f . Proof : It suﬃces to invoke the PCA oracle into the plaintext checking algorithm V. Thus, by deﬁnition of oracle access, T [V] = 1. 4.3

Particular Cases

Both in the case of the trivial construction of partial one-way bijection families and in the non-trivial family deﬁned in subsection 2.1, the simulation in the security proof can be improved by introducing few technical modiﬁcations. In both cases, there exist two very eﬃciently computable functions f˜pk : Xpk → Z˜pk and π ˜pk : Zpk → Z˜pk such that V(pk, x, z) = 1 if and only if ˜ fpk (x) = π ˜pk (z). Then, it is shown in the appendix that T [APOW ] ≤ (qG +qH + qD )T [V] + qG T [f˜] +

π] + T [Decsym ] + T [AIND−CCA ], + qD T [f ] + T [˜

providing a very tight security reduction. If the trivial constructions are considered, fpk (x, y) = (f˜pk (x), y) and ˜ ≈ T [V] so π ˜pk (˜ z , y) = z˜ so T [˜ π ] can be neglected. Moreover, T [f ] ≈ T [f] T [APOW ] ≤ (2qG + qH + 2qD )T [f˜] + qD T [Decsym ] + T [AIND−CCA ] On the other hand, using the generalised RSA-Paillier function, f˜n,r,e (x) = xe mod n and π ˜n,r,e (z) = z mod n. Then, T [APOW ] ≤ (2qG + qH + 2qD )O(2 log e) + qD T [Decsym ] + T [AIND−CCA ] Acknowledgements The authors thank the anonymous referees for their valuable comments on this paper.

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

79

References 1. M. Bellare and P. Rogaway. Random Oracles are Practical: a Paradigm for Designing Eﬃcient Protocols. ACM CCS 93, ACM Press (1993) 2. D. Catalano, R. Gennaro, N. Howgrave-Graham and P. Q. Nguyen. Paillier’s Cryptosystem Revisited. ACM CCS ’2001 ACM Press (2001). 3. J. Coron, H. Handschuh, M. Joye, P. Paillier, D. and C. Tymen. GEM: a Generic Chosen-Ciphertext Secure Encryption Method. CT-RSA’ 02, LNCS 2271 263–276 (2002). 4. J. Coron, H. Handschuh, M. Joye, P. Paillier, D. Pointcheval and C. Tymen. Optimal Chosen-Ciphertext Secure Encryption of Arbitrary-Length Messages. PKC 2002, LNCS 2274 17–33 (2002). 5. R. Cramer and V. Shoup. Universal Hash Proofs and a Paradigm for Adaptive Chosen Ciphertext Secure Public-Key Encryption. EUROCRYPT ’2002, LNCS 2332 45–64 (2002). 6. A. W. Dent. An implementation attack against the EPOC-2 public-key cryptosystem. Electronics Letters VOL. 38 NO. 9 412–413 (2002). 7. EPOC, Eﬃcient Probabilistic Public-Key Encryption. http://info.isl.ntt.co.jp/epoc/ 8. E. Fujisaki and T. Okamoto. Secure Integration of Asymmetric and Symmetric Encryption Schemes. CRYPTO ’99, LNCS 1666 537–554 (1999) 9. E. Fujisaki and T. Okamoto. A Chosen-Cipher Secure Encryption Scheme Tightly as Secure as Factoring. IEICE Trans. Fundamentals E84-A(1) 179–187 (2001). 10. M. Joye, J. J. Quisquater and M. Yung. On the Power of Misbehaving Adversaries and Security Analysis of the Original EPOC. CT-RSA’ 01, LNCS 2020 208–222 (2001). 11. T. Okamoto and D. Pointcheval. The Gap-Problems: a New Class of Problems for the Security of Cryptographic Schemes. PKC’ 01, LNCS 1992 104–118 (2001). 12. T. Okamoto and D. Pointcheval. REACT: Rapid Enhanced-security Asymmetric Cryptosystem Transform. CT-RSA’ 01, LNCS 2020 159–175 (2001). 13. T. Okamoto and S. Uchiyama. A New Public-Key Cryptosystem as Secure as Factoring. EUROCRYPT-98, LNCS 1403 308–318 (1998) 14. PSEC, Provably Secure Encryption Scheme. http://info.isl.ntt.co.jp/psec/ 15. D. Pointcheval. Chosen-Ciphertext Security for any One-Way Cryptosystem. Proc. PKC ’2000 LNCS 1751 129–146 (2000). 16. K. Sakurai and T. Takagi. A Reject Timing Attack on an IND-CCA2 Public-Key Cryptosystem. ICISC ’02, LNCS 2587 359–373 (2002).

A

Proof of Theorem 8

Let AIND−CCA = (A1 , A2 ) be the adversary aiming to attack the IND-CCA security of the hybrid encryption scheme, E = (KeyGen, Enc, Dec) described in subsection 4.2. In order to prove the theorem, some diﬀerent games will be considered. In all games, the adversary AIND−CCA uses the same coins, but the events deﬁned as functions of the view of AIND−CCA could occur with diﬀerent probabilities in each game. Starting from the IND-CCA game, we will decribe several intermediate games before designing the game for an adversary who tries to break the partial

80

David Galindo et al.

one-wayness (POW) of f . Each game will be obtained by introducing slight modiﬁcations to the previous game, in such a way that the adversary success probabilities are easily related. We denote by Pri [F ] the probability of event F in game i. The following trivial lemma will be very useful in this proof. Lemma 10 Let E1 , F1 be two events deﬁned in a probability space X1 , and E2 , F2 another two events deﬁned in a probability space X2 , such that p = PrX2 [F2 ] = PrX1 [F1 ] and PrX2 [E2 ∧ ¬F2 ] = PrX1 [E1 ∧ ¬F1 ]. Then |PrX2 [E2 ] − PrX1 [E1 ]| ≤ p Game0. The IND-CCA attack. There are some minor diﬀerences between Game0 and the standard IND-CCA game, described in subsection 3.2, but they do not modify any probability. Game0() 1 (pk, sk) ← KeyGen(1 ); G, H ← R 2 b ← {0, 1}; x ← Xpk sk 3 (m0 , m1 , s) ← AG,H,D (pk) 1 4

y ← H(x , mb ); c ← fpk (x , y ), Encsym (mb ) G(x )

5

b ← A2

G,H,Dsk,c

(s, c )

where the oracle answer Dsk (c) is exactly the same as the value returned by Dec(sk, c), described in subsection 4.2. Let S1 be the event where, during the game, either x is queried (by IND−CCA A ) to G or (x , m) is queried to H, for some m. Let us also deﬁne S01 = ¬S1 ∧ (b = b) and S00 = ¬S1 ∧ (b = b). After some easy computations, we obtain Adv AIND−CCA ≤ Pr0 [S1 ] + |Pr0 [S01 ] − Pr0 [S00 ]| Let TG be a table in which all queries made by AIND−CCA to the oracle G are stored along with the corresponding answers. Deﬁne TH and TD in a similar way for the oracle calls to H and Dsk respectively. Notice that the contents of these tables change during the game. Game1. In this game, the queries made by AIND−CCA to the two random oracles are intercepted in order to abort the execution of the game immediately if S1 occurs. Since the games are identical when ¬S1 , the events S1 , S01 and S00 remain unchanged in Game1. Then, Adv AIND−CCA ≤ Pr1 [S1 ] + |Pr1 [S01 ] − Pr1 [S00 ]| Game2. In this game, the decryption oracle is modiﬁed in such a way that new queries to the random oracle G are disallowed. To do this, all ciphertexts (c1 , c2 ) submitted to the decryption oracle such that gsk (c1 ) ∈ TG ∩ Xpk are rejected by returning ⊥2 , even when some of them may be valid ciphertexts.

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

81

Let F2 be the event where, in some query to the decryption oracle, the ciphertext is accepted in Game1 but rejected by the decryption oracle in Game2. Before F2 occurs, both games are indentical. Then, by lemma 10, |Pr2 [S1 ] − Pr1 [S1 ]| ≤ Pr [F2 ] |Pr2 [S01 ] − Pr1 [S01 ]| ≤ Pr [F2 ] |Pr2 [S00 ] − Pr1 [S00 ]| ≤ Pr [F2 ] From these inequalities, it can be easily shown that Adv AIND−CCA ≤ Pr2 [S1 ] + |Pr2 [S01 ] − Pr2 [S00 ]| + 2Pr [F2 ] The following lemma gives an upper bound for Pr [F2 ]. Lemma 11 Pr [F2 ] ≤

qD qD qH γ + |K| − qD qH γ |Y | − qD

(The proof of this lemma can be found in the full version of the paper.) Game2 . In this game, oracles G and H are simulated by using tables. The answers to new queries to G or H are perfectly simulated by uniformly distributed independent random variables. The generation of the ciphertext, which is also diﬀerent, is done as follows: (mb ) g ← K ; y ← Y ; c ← fpk (x , y ), Encsym g which is equivalent to redeﬁning some values of the random functions, namely, G(x ) = g and H(x , mb ) = y . But these changes in the oracles do not aﬀect the probability distribution of the view of AIND−CCA , since in Game2 neither x is queried to G nor (x , m) is queried to H, for any m. Game3. In this game, we introduce some modiﬁcations to avoid the use of mb in the generation of the target ciphertext. In fact, the diﬀerences between using mb and using a random message can be tapped by a new adversary AIND−SYM = (Asym , Asym ) who tries to break the IND security of E sym (see 3.1). 1 2 Game3() 1 β ← {0, 1} 2 (µ0 , µ1 , σ) ← Asym (1 ) 1 3 g ← K ; κ = Encsym (µβ ) g 4 β ← Asym (σ, κ ) 2

Asym (1 ) 1 1 TG3 ← empty ; TH3 ← empty 2 (pk, sk) ← KeyGen(1 ) 3 b ← {0, 1}; x ← Xpk sk (m0 , m1 , s) ← AG3,H3,D3 (pk) 4 1 5 m ← M

82

David Galindo et al. σ = (TG3 , TH3 , pk, sk, b, x , s) 7 return (mb , m, σ) (σ, κ ) Asym 2 1 (TG3 , TH3 , pk, sk, b, x , s) = σ 2 y ← Ypk ; c ← (fpk (x , y ), κ ) G3,H3,D3sk,c 3 b ← A2 (s, c ) 4 β ← 0 5 if b = b 6 β ← 0 7 else 8 β ← 1 9 endif 6

In addition, if S1 occurs, then β ← {0, 1} and β ← 1 before exiting the game in the simulators of G and H. Now, two diﬀerent advantages can be taken into account: Adv AIND−SYM = |2Pr3 [β = β] − 1| and Adv AIND−SYM = |2Pr3 [β = β] − 1|. It can be proved that Adv AIND−CCA ≤ Pr3 [S1 | β = 1] + 2Adv AIND−SYM + IND−SYM + Adv A + 2Pr [F2 ] Game4. Game3 (with β = 1) can be modiﬁed to obtain an implementation of an adversary, APOW , which tries to break the partial one-wayness of f . This adversary will know neither sk nor x . The use of sk in the decryption oracle simulator is avoided by using the deterministic plaintext checking algorithm V. Game4() 1 (pk, sk) ← KeyGen(1 ) 2 x ← Xpk ; y ← Ypk ; z ← fpk (x , y ) 3 APOW (pk, z ) POW (pk, z) A 1 b ← {0, 1} 2 m ← M ; g ← K ; c ← (z, Encsym (m)) g 3 TG ← empty ; TH ← empty G,H,D4pk 4 (m0 , m1 , s) ← A1 (pk) G,H,D4 pk,c 5 b ← A2 (s, c ) 6 x ← Xpk D4pk (c) 1 if c ∈ Z¯pk × M ; return ⊥1 ; endif 2 (c1 , c2 ) = c 3 foreach x ∈ TG4 4 if x ∈ Xpk and V(pk, x, c1 ) = 1 5 m ← Decsym TG4 (x) (c2 ) 6 y ← H4(x, m) 7 if fpk (x, y) = c1 ; return ⊥2 ; endif 8 return m 9 endif 10 endforeach 11 return ⊥2

Easy Veriﬁable Primitives and Practical Public Key Cryptosystems

83

The use of x in the random oracle simulators is also avoided. To do this, S1 is detected by checking if x ∈ Xpk ∧ V(pk, x, z) = 1 for each query x or (x, m). If S1 occurs then x ← x. These changes do not modify any probability. Moreover, the views of AIND−CCA in games 3 (with β = 1) and 4 are identically distributed. Then, Succ APOW = Pr4 [x = x ] ≥ Pr4 [S1 ] = Pr3 [S1 | β = 1] and, from the above results, Adv AIND−CCA ≤ Succ APOW + 2Adv AIND−SYM + 2qD 2qD qH γ + Adv AIND−SYM + + |K| − qD qH γ |Y | − qD In terms of time complexity of the algorithms, it is supposed that the time needed to check if c ∈ Z¯pk × M and x ∈ Xpk is negligible. Neglecting lower order terms, the running time of APOW in Game4 is bounded by T [APOW ] ≤ (qG + qH + qD + qG qD )T [V] + qD (T [f ] + T [Decsym ]) + T [AIND−CCA ], where T [V] is the time complexity of the plaintext checking algoritm and T [f ] is the time complexity of f . Also, T [AIND−SYM ] = T [AIND−CCA ]. A.1

Particular Cases

Both in the case of the trivial construction of easy veriﬁable functions and in the non-trivial family in subsection 2.1, the algorithm D4pk can be improved, without modifying the behavior of the game, to avoid exhaustive search in TG4 . If (f˜(x), x, G(x)) is stored in another table T˜G4 for each query x ∈ Xpk to G, the decryption oracle can be simulated as follows: D4pk (c) 1 if c ∈ Z¯pk × M ; return ⊥1 ; endif 2 (c1 , c2 ) = c 3 z˜ ← π ˜pk (c1 ) 4 if z˜ ∈ T˜G4 (x, g) ← T˜G4 (˜ z) 5 6 m ← Decsym (c2 ) g 7 y ← H4(x, m) 8 if fpk (x, y) = c1 ; return ⊥2 ; endif 9 return m 10 endif 11 return ⊥2

Now, T [APOW ] ≤ (qG +qH + qD )T [V] + qG T [f˜] + π ] + T [Decsym ] + T [AIND−CCA ] + qD T [f ] + T [˜

Reactively Secure Signature Schemes Michael Backes, Birgit Pﬁtzmann, and Michael Waidner IBM Research, Zurich Research Laboratory CH-8803 R¨ uschlikon, Switzerland {mbc,bpf,wmi}@zurich.ibm.com

Abstract. Protocols for problems like Byzantine agreement, clock synchronization or contract signing often use digital signatures as the only cryptographic operation. Proofs of such protocols are frequently based on an idealizing “black-box” model of signatures. We show that the standard cryptographic security deﬁnition for digital signatures is not suﬃcient to ensure that such proofs are still valid if the idealized signatures are implemented with real, provably secure signatures. We propose a deﬁnition of signature security in general reactive, asynchronous environments and prove that for signature schemes where signing just depends on a counter as state the standard security deﬁnition implies our deﬁnition.

1

Introduction

Protocols for problems like Byzantine agreement, clock synchronization or contract signing often use digital signatures as the only cryptographic operation. Proofs of such protocols typically use a “black-box” model of signatures: they just assume that signatures are unforgeable, i.e., they abstract from all cryptographic details like asymptotic security and error probabilities. Still one should expect that protocols proven secure in this abstract model are also secure if implemented with a real, cryptographically secure signature scheme. Unfortunately this is not true: Consider an arbitrary, secure signature scheme. We transform such a scheme into a new one which, when signing a message m, attaches to the signature on m all previously signed messages and their signatures. This is certainly a strange scheme, but it is easy to see that it satisﬁes the standard deﬁnition of a signature scheme (from [8]), and that it is secure provided the original scheme is secure: A signature scheme is secure if there is no polynomial-time (in k, a security parameter) adversary that can produce a forged signature with non-negligible probability. The adversary has exclusive access to a signature oracle, and any signature under a message for which the oracle was not queried counts as a forgery. When asking for the i-th signature the adversary has seen all signatures up to the (i − 1)-st anyway, thus our new scheme is not easier to break than the original one. Now consider a trivial protocol for fair contract signing: We have two potentially malicious parties A, B and a trusted third party T . Both have inputs c, the contract, and binary values dX , for X = A, B, which tell them whether they should sign (dX = 1) or reject (dX = 0) the contract. The contract should be C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 84–95, 2003. c Springer-Verlag Berlin Heidelberg 2003

Reactively Secure Signature Schemes

85

signed only if all honest parties X start with dX = 1. Now the protocol roughly works like this: Both A and B sign c, yielding signatures sA , sB . If dA = 1 then A stops, and otherwise it sends sA to T , and similarly B. If T receives both signatures it sends (sA , sB ) back to A and B, and the contract is considered signed. If T does not receive both signatures (which in an asynchronous network might just mean that T non-deterministically decides to terminate) then T stops and the contract is not signed, which means that nobody should get hold of the pair (sA , sB ). Intuitively this protocol is secure, and one can even prove this in the black-box model. But clearly if the protocol is executed multiple times then from each successful run one can construct valid contracts for all previous runs, even for those that did not produce a valid contract. In Section 2 we introduce the ﬁrst security deﬁnition of digital signature schemes that resolves these problems, and can be used as a basis for “blackbox” reasoning about protocols in general asynchronous, reactive environments (see [1] for more details). In Section 3 and 4 we show that for certain signature schemes security in the sense of [8] implies security against this deﬁnition. As our example has shown, this cannot be true in general, thus we limit ourselves to schemes where signing needs just a counter as state. This is suﬃcient for many provably secure signature schemes. For instance, in [8] the signer computes a tree and associates each signature with one of the leaves in this tree. Thus it is suﬃcient for the signing machine to keep track of which leaves are already used, and this can be easily encoded in a counter. Similar arguments apply, e.g., to the schemes in [10, 5, 6, 7]. Similar problems have been already identiﬁed for other cryptographic primitives, e.g., oblivious transfer [2] and public-key encryption [3]. For signatures, already the standard deﬁnition from [8] is in a reactive setting, but signatures are delivered to the adversary in the same order they were generated. In a general asynchronous setting these orders might be diﬀerent, which greatly complicates security proofs. In [4], Canetti deﬁnes security in a more general reactive setting, but his deﬁnition applies to stateless signature algorithms only. This avoids essentially all problems but excludes many provably secure signatures schemes, e.g., [8, 10, 5]. In [9] signatures are implicitly covered within secure channels, but there signatures are use-once, which again avoids all problems but does not lead to a general solution.

2 2.1

Definitions and Notation Notation

R We write “:=” for deterministic and “←” for probabilistic assignment, and “←” for uniform random choice from a set. ↓ is an distinguished error element available as an addition to the domains and ranges of all functions and algorithms. The fundamental datastructures in our upcoming deﬁnitions and proofs are arrays that store tuples of strings. For each array D, the tuples have a predeﬁned structure, e.g., each tuple stores a message along with a signature for it. In order

86

Michael Backes, Birgit Pﬁtzmann, and Michael Waidner

to elegantly capture selection of tuple entries, we adopt some database notation: Entries of a tuple are called attributes, e.g., we could have two attributes msg and sig denoting the message and the signature entry of each tuple. For an element x ∈ D, the value of its attribute att is written x.att . If the values of one distinguished attribute att are unique among all entries in D, i.e., the attribute gives a one-to-one correspondence to the entries of the array, we call att a primary key attribute. We use this to select entries of a tuple, i.e., if a primary key attribute att exists in D and att2 is another arbitrary attribute in D, we simply write att2 [a] instead of x.att2 , where x denotes the unique entry with x.att = a. If no such entry exists, we deﬁne att2 [a] := ↓. 2.2

Non-reactive Definitions

Signature schemes often have memory. As already explained in the introduction, signature schemes that divulge the history of message signed before are not suited for use in an asynchronous reactive environment. In our upcoming deﬁnition, we therefore do not allow a signature scheme to use arbitrary parts of its state for signing a message, but we model its memory by a counter. Definition 1. (Signature Schemes) A signature scheme is a triple (gen, sign, test) of polynomial-time algorithms, where gen and sign are probabilistic. gen takes an input (1k , 1s ) with k, s ∈ N, where s denotes the desired maximum number of signatures, and outputs a pair (sk , pk ) of a secret signing key and a public test key in Σ + . sign takes such a secret key, a counter c ∈ {1, . . . , s}, and a message m ∈ Σ + as inputs and produces a signature in Σ + . We write this sig ← signsk ,c (m). Similarly, we write verification as b := testpk (m, sig) with b ∈ {true, false}. If the result is true, we say that the signature is valid for m. For a correctly generated key pair, a correctly generated signature for a message m must always be valid for m. 3 When we speak about an arbitrary signature scheme in the following, we always mean a counter-based signature scheme in the sense of Deﬁnition 1. Signature schemes with truly arbitrary state will not matter in the sequel, and we hence also omit a precise deﬁnition. Security of a signature scheme is deﬁned against existential forgery under adaptive chosen-message attacks: Definition 2. (Signature Security) Given a signature scheme (gen, sign, test) and a polynomial s ∈ N[x], the signature oracle Sigs is defined as follows: It has variables sk , pk and a counter c initialized with 0, and the following transition rules: – First generate a key pair (sk , pk ) ← gen(1k , 1s(k) ), and output pk . – On input (sign, m) with m ∈ Σ + , and if c < s(k), set c := c + 1 and return sig ← signsk ,c (m).

Reactively Secure Signature Schemes

87

The signature scheme is called existentially unforgeable under adaptive chosenmessage attack if for every polynomial s and every probabilistic polynomial-time machine Asig that interacts with Sigs and finally outputs two values m and sig (meant as a forged signature for the message m), the probability that testpk (m, sig) = true is negligible (in k) if m is not among the messages previously signed by the signature oracle. 3 Lemma 1 (Skipping signatures). Without loss of generality, we can assume that a signature scheme which is secure according to Definition 2 is skipping secure: This means that the current value of the counter c is not computed within the signature oracle but externally input by the adversary along with the message to be signed. However, Sigs verifies that the incoming counter values are strictly increasing and do not exceed s(k). 2 Proof. Encode the messages from Σ + into Σ + such that there is an unused message m∗ (e.g., prepend a bit), and let Sigs sign m∗ for a value c if Asig skips it. 2.3

A New Reactive Definition

In order to obtain a security deﬁnition that is meaningful in a reactive environment, we have to extend the capabilities of the adversary when interacting with the signature oracle. More precisely, we still have to allow for signing arbitrary messages, but the obtained signatures are stored within the signature oracle and only output upon request of the adversary. Now a signature is considered a forgery for a message m if the signature is valid for m, and if no signature for this particular message has been requested. This is captured in the following deﬁnition. Definition 3. (Reactive Signature Security) Given a signature scheme and a polynomial s ∈ N[x], the reactive signature oracle RSigs is defined as follows: It contains variables sk , pk , a counter c initialized with 0, an initially empty set C of counter values, and an initially empty array SIGS with attributes c, m, and sig for storing counter values, messages, and already made signatures. The counter c can be used as a primary key attribute, which is clear by inspection of the below transitions. The transition rules of RSigs are: – First generate a key pair (sk , pk ) ← gen(1k , 1s(k) ), and output pk . – On input (sign, m) with m ∈ Σ + , and if c < s(k), set c := c + 1 and sig ← signsk ,c (m), and store (c, m, sig) in SIGS . – On input (choose, i), and if i ≤ c, set C := C ∪ {i} and return sig[i]. The signature scheme is called reactively secure if for every polynomial s and every probabilistic polynomial-time machine Asig that interacts with RSigs and finally outputs two values m and sig (meant as a forged signature for m), the probability that testpk (m, sig) = true for m = m[c] for all c ∈ C is negligible (in k). 3

88

Michael Backes, Birgit Pﬁtzmann, and Michael Waidner

Lemma 2 (Memory-less Schemes). Let Sig denote a memory-less signature scheme, i.e., signing of messages does not depend on prior inputs. If Sig is existentially unforgeable under adaptive chosen message attacks, then it is also reactively secure. 2 Proof. If an adversary breaks Sig in the reactive scenario of Deﬁnition 3, we can easily construct an adversary that has the same success probability against the same signature scheme in the non-reactive scenario of Deﬁnition 2: This new adversary simply defers signature requests of the original adversary, i.e., inputs of the form (sign, mj ), until the original adversary chooses those signatures. As the signature oracle is memory-less, making the signatures in the wrong order makes no diﬀerence. Moreover, every forged signature by the original adversary is also a suitable forgery for the new adversary.

3

Reduction Proof for Unchanged Signature Schemes

In this section, we show that an arbitrary signature scheme which is secure according to Deﬁnition 2 is already reactively secure. This means that signature schemes that only maintain a counter as their local state can safely be used in an asynchronous reactive environment, i.e., without having to bother about problems as sketched in the introduction. As a drawback however, we will see that the concrete complexity gets worse. Theorem 1. A signature scheme Sig is reactively secure if and only if it is existentially unforgeable under adaptive chosen-message attack. 2 Proof. The proof of the left-to-right direction is straightforward, since a reactively secure system is in particular secure for an adversary requesting all signed messages in the correct order, which corresponds to security against existential forgery under adaptive chosen-message attacks. In order to prove the opposite direction, we show that if there exists a successful adversary Adv∗ against the signature scheme in a reactive scenario, there as well exists another adversary Adv for attacking the scheme in a non-reactive scenario. This is shown in Figure 1. The adversary Adv consists of two machines: the adversary Adv∗ , which is used “black-box”, and a simulator Sim which interacts with Adv∗ and also has access to the (non-reactive) signature oracle Sigs . Intuitively, Sim tries to act like a valid reactive signature oracle for Adv∗ . If Adv∗ ﬁnally outputs a valid forgery for a so-far unsigned message, Sim uses this forgery to successfully attack the non-reactive signature oracle Sigs . The proof idea is that Sim does not sign exactly the messages that the adversary Adv∗ requests. Instead, it swaps some for random messages. Now there is a chance that the adversary catches the simulator cheating. However, if it does not, we can again use the argument that a successful adversary either forges signatures on messages that were never signed at all, or it is able to guess unknown random values.

Reactively Secure Signature Schemes

pk

sigi

signsk,i(m*)

sigi

signsk,i(mi)

(sign,m*) (sign,mi) sigi

c Sigs (Signature Oracle)

c*

R

{0,…,s(k)}

If c*-th distinct message then

m*

R

89

pk (sign,mi)

{0,1}k

else

Store (i, mi, sigi) (i, mi, sigi) stored? If mi is c*-th distinct message, give up. Otherwise

(choose,i)

sigi or ---

(m’,sig’) (m’,sig’)

Sim

Adv* Adv

Fig. 1. Overview of the reduction proof for unchanged signature schemes.

Description of the simulator. The simulator Sim maintains a counter c initialized with 0 and an initially empty array SIGS for storing counter values, messages, and signatures obtained from the signature oracle. Again, we use attributes c, m, and sig for these entries, and c is used as a primary key attribute. Sim further maintains an initially empty set C of counter values corresponding to signatures that have already been requested by the adversary. In order to allow for a successful cheating, Sim maintains two values c∗ , cnt ∈ {0, 1, . . . , s(k)}. Below, we let the simulator Sim choose a value R c∗ ← {0, . . . , s(k)} denoting the number of the message where it will cheat. Note that the choice c∗ = 0 is possible, i.e., Sim does not cheat at all in this case. This is important, since an adversary that requests all signatures would otherwise always catch our simulator cheating, and the proof would fail. Moreover, if the adversary lets a message m be signed twice, but chooses none of these indices and later outputs a signature on m, our simulator would lose. Hence our simulator does not change the c∗ -th incoming message, but the c∗ -th really different message, and then stick to the change whenever this message re-occurs. The value of cnt is initialized with 0 and represents the number of distinct messages that have already been input for signing so far, and it is used to determine when the simulator will cheat for the ﬁrst time. After this ﬁrst cheating, the value of cnt will be set to ↓ and will not matter henceforth. Furthermore, Sim maintains a variable mch ∈ Σ + determining the message that has been discarded for cheating, and a set cch ⊆ {0, . . . , s(k)} containing the counter values c corresponding to the message mch . (Since the discarded message could be repeatedly input for signing, we have to store several values of c, which illustrate the need for cch being a set here instead of a single value.)

90

Michael Backes, Birgit Pﬁtzmann, and Michael Waidner

The variables are initialized with ↓ and {} respectively. The behavior of Sim is sketched in Figure 1 and deﬁned as follows: R – First, it chooses c∗ ← {0, 1, . . . , s(k)}. – On input (sign, m) with m ∈ Σ + : If c < s(k), set c := c + 1, otherwise abort, i.e., stop the current transition without any further action. If m = m[i] for all i ≤ c and cnt = ↓, set cnt := cnt + 1. We now distinguish between three cases: = mch , sign in the normal way: Output • (No Cheating): If cnt = c∗ and m (sign, m) to the signature oracle yielding a signature sig. Store (c, m, sig) in SIGS . R • (First Cheating): If cnt = c∗ , let m∗ ← {0, 1}k and output (sign, m∗ ) to the signature oracle yielding a signature sig. Store (c, m∗ , sig) in SIGS , and set mch := m, cch := cch ∪ {c}, and cnt := ↓. • (Repeated Cheating): If m = mch , let c ∈ cch arbitrary, set m∗ := m[c ] and output (sign, m∗ ) to the signature oracle yielding a signature sig. Store (c, m∗ , sig) in SIGS , and set cch := cch ∪ {c}. – On input (choose, i): If SIGS [i] = ↓ abort. Otherwise let (i, m, sig) := SIGS [i] and set C := C ∪ {i}. If i ∈ cch then give up the simulation, else output sig to Adv∗ .

Proof of Correct Simulation. Assume that Adv∗ (reactively) breaks Sig. Thus, in interaction with a correct reactive signature machine RSigs , it outputs a tuple (m, sig) with m = m[c] for all c ∈ C and testpk (m, sig ∗ ) = true with nonnegligible probability . The idea is that if the adversary does not choose all of the signed messages, then there is a non-negligible probability that at least one of the remaining messages is the modiﬁed one. Provided that the simulator does not explicitly give up the simulation (which happens if the adversary requests a signature for the c∗ -th distinct message), we can then show that if Adv∗ outputs a valid signature with non-negligible probability, then the probability that this signed message is new, i.e., has not been signed before by the signature oracle, is also non-negligible. In the following, we calculate an upper bound of the probability that our simulation fails to determine a new valid signature. Mainly, there are three possibilities for our simulation to fail: 1. (Simulator gives up): The adversary Adv∗ has requested a signature for the cheated message, i.e., an input (choose, i) occurred with i ∈ cch . 2. (Unsuited signature): The adversary Adv∗ outputs a signature for a message m that has been signed before, but not requested by Adv∗ . 3. (Guessing the cheated message): The adversary produces a signature for the randomly chosen message m∗ . Moreover, there is a probability of failure, which does not depend on the simulation, but on the fact that the adversary may output either a wrong signature, or a signature for a message that it has already requested. The complemented

Reactively Secure Signature Schemes

91

probability stands for the success probability of the adversary Adv∗ if the simulation is done without changing the value of the cheated message. We denote this probability by PAdv∗ which is not negligible by assumption. In the following, let ϕ(SIGS ) := {m | ∃c, sig : (c, m, sig) ∈ SIGS } denote the set of all messages that have been signed, and ϕ(C) := {m | ∃c ∈ C, sig : (c, m, sig) ∈ SIGS } denote the set of messages that have been chosen by the adversary. Note that the cardinality of these sets denotes the number of distinct messages that have been signed or requested, respectively. As the upcoming calculation of the probability of failure will make extensive use of these cardinalities, we write ϕsig := |ϕ(SIGS )| and ϕc := |ϕ(C)| for the sake of readability. For calculating an upper bound for the remaining failure probability, we distinguish between two cases depending on whether Adv∗ request all signatures (i.e., ϕc = ϕsig ) or not. In the following, we only consider failures because of a giving-up simulator or an unsuited signature. A failure because of guessing the cheated message will be treated separately later on. – 0 ≤ ϕc ≤ ϕsig − 1: We distinguish two cases: • cch = ∅: In this case, we obtain a probability of zero that the simulator gives up, and a probability of one for an unsuited signature in the worst 1 (representing the case case. The probability of cch = ∅ is given by s(k)+1 s(k)−ϕ

c∗ = 0) plus s(k)+1sig (representing the remaining choices for c∗ ). In total, the probability of failure for this case is 1 + s(k) − ϕsig . s(k) + 1 • cch = ∅: In this case, the simulator gives up with probability obtain an unsuited signature with probability = ∅ is given by 1 − of cch failure probability of (

1+s(k)−ϕsig s(k)+1

=

ϕsig −ϕc −1 ϕsig −ϕc .

ϕsig s(k)+1 .

ϕc ϕsig ,

and we

The probability

In total, we obtain a

ϕ2sig − ϕsig − ϕ2c ϕc ϕsig − ϕc − 1 ϕsig = . + ) ϕsig ϕsig − ϕc s(k) + 1 (ϕsig − ϕc )(s(k) + 1)

Joining the probability of both subcases, we obtain a failure probability of ϕ2sig − ϕsig − ϕ2c 1 + s(k) − ϕsig + s(k) + 1 (ϕsig − ϕc )(s(k) + 1) =

s(k)ϕsig − ϕc − s(k)ϕc + ϕsig ϕc − ϕ2c . (ϕsig − ϕc )(s(k) + 1)

– ϕc = ϕsig : In case cch = ∅, we have a probability of zero that the simulator gives up, and also a probability of zero for receiving an unsuited signature since every message has been requested, hence no such message can still

92

Michael Backes, Birgit Pﬁtzmann, and Michael Waidner

be chosen. For the case cch = ∅, the simulator gives up with probability one, and we obtain an unsuited signature with probability of zero again. ϕsig The probability of cch = ∅ is given by s(k)+1 , which is hence also the total probability for this case. Since the probability in the ﬁrst case depends on the number ϕc of requested messages, we look for the maximum of all these probabilities when varying ϕc . Diﬀerentiation of the formula shows that it reaches its maximum at the border √ s(k) . (The minimum is at ϕsig − ϕsig ). We of the interval [0, . . . , ϕsig −1] as s(k)+1 ﬁnally have to maximize the probabilities for the second case when varying ϕsig . The formula is strictly increasing, hence it reaches its maximum at ϕsig = s(k). s(k) This yields a probability of s(k)+1 , which matches the probability of the ﬁrst case. So far, we omitted the failures that stem from receiving a forgery for the randomly chosen message m∗ . This probability is trivially upper bounded by ϕsig . Putting it all together, the probability that our simulation is correct is 2k lower bounded by (1 −

s(k) ϕsig ϕsig 1 − k ) · PAdv∗ = ( − k ) · PAdv∗ , s(k) + 1 2 s(k) + 1 2

which is not negligible, since ϕsig is upper-bounded by s(k). We need the same number of oracle queries in the proof, but we have a signiﬁcantly lower probability of success, i.e., the concrete complexity gets worse. A possibility to obtain almost the same probability of success is presented in the next section.

4

Obtaining Reactively Secure Signature Schemes by Additional Randomization

In the following, we show how additional randomization can be used to transform a signature scheme which is secure according to the non-reactive deﬁnition 2 into a scheme that is reactively secure with almost the same concrete complexity. Let Sig 1 = (gen, sign, test) be an arbitrary signature scheme. Then we can transform Sig 1 into another signature scheme Sig 2 = (gen, sign∗ , test∗ ) as follows: R For signing of a message, we deﬁne sign∗sk,c (m) := (r, signsk,c ((m, r))) for r ← {0, 1}k , where we assume that the tuple (m, r) is eﬃciently encoded into Σ + , similar in the following. For testing of a signature and a corresponding message, we deﬁne test∗pk (m, sig ∗ ) := testpk ((m, r), sig ) if sig ∗ is of the form (r, sig), and false otherwise. We want to show that if Sig 1 is secure against existential forgery under adaptive chosen message attack, then Sig 2 is reactively secure. This is captured in the following theorem. Theorem 2. Let Sig 1 = (gen, sign, test) be a signature scheme, and let Sig 2 = (gen, sign∗ , test∗ ) be the transformed signature scheme of Sig 1 as defined above.

Reactively Secure Signature Schemes

pk (sign,(mi,ri)) sigi

signsk,i(mi,ri)

sigi

93

pk ri

R

{0,1}k

(sign,mi)

Store (i,mi, ri, sigi)

(choose,i)

(i,mi, ri, sigi) stored? (ri, sigi) or ---

(m,sig*) with

c Sigs (Signature Oracle)

sig* = (r,sig) ((m,r),sig) Sim

Adv* Adv

Fig. 2. Overview of the reduction proof for the randomized scheme. Then Sig 2 is reactively secure if Sig 1 is secure against existential forgery under adaptive chosen message attack. 2 Proof. We again show that if there exists a successful adversary Adv∗ against the signature scheme Sig 2 in a reactive scenario, there as well exists another adversary Adv for attacking the scheme Sig 1 in a non-reactive scenario. The adversary Adv again consists of the adversary Adv∗ used “black-box”, and a simulator Sim which interacts with Adv∗ and also has access to the (nonreactive) signature oracle Sigs . Description of the Simulator. The simulator Sim maintains a counter c initialized with 0 and an initially empty set C of counter values corresponding to signatures that have been requested by the adversary. Finally, Sim maintains an initially empty array SIGS for storing tuples of signatures obtained from the signature oracle Sigs , along with the corresponding counter, the message, and the random value r. We have attributes sig, c, m, and r for these entries, and c is used as the primary key attribute. The behavior of Sim is sketched in Figure 2 and formally expressed as follows: R {0, 1}k – On input (sign, m) with m ∈ Σ + : If c < s(k), set c := c + 1 and r ← and output (sign, (m, r)) to the signature oracle, yielding a signature sig for the tuple (m, r). Store (c, m, r, sig) in SIGS . – On input (choose, i): If SIGS [i] = ↓ abort. Otherwise let (i, m, r, sig) := SIGS [i], set C := C ∪ {i} and output (r, sig) to Adv∗ .

Proof of Correct Simulation. Now assume that Adv∗ breaks Sig 2 . Thus, with non-negligible probability, it outputs a tuple (m, sig ∗ ) with m = m[c] for all c ∈ C and test∗pk (m, sig ∗ ) = true. The validity of the signature implies that sig ∗ is of the form sig ∗ = (r, sig). We distinguish two cases:

94

Michael Backes, Birgit Pﬁtzmann, and Michael Waidner

1. The pair (m, r) does not occur in SIGS (as second and third elements of a quadruple). In this case, we can use sig as a valid forgery of (m, r) with respect to Sig 1 , since test∗pk (m, sig ∗ ) = true implies testpk ((m, r), sig ) = true, and the message (m, r) has never been signed by Sigs . 2. A tuple (c, m, r, sig) occurs in SIGS . Then c ∈ C because of the precondition m = m[c] for all c ∈ C. We show that this means that Adv∗ has guessed an unknown random value correctly. The inputs (r[c ], sig[c ]) that Adv∗ obtained do not depend at all on the value of r[c]. More precisely, the probability distribution of these inputs is independent of the value r[c], since only the counter of the signature oracle is considered for message signing, and the random value r[c] does not inﬂuence this counter. Hence, the prob. This is negligible since the ability of guessing r[c] is upper bounded by s(k) 2k upper bound s(k) on the number of messages signed is polynomial.

In contrast to the results of the previous section, the concrete complexity is almost optimal: We need the same number of oracle queries and obtain almost the ∗ same success probability PAdv = (1 − s(k) 2k )PAdv . The computational complexity of Sim is essentially bounded by generating s(k) random values and s(k) lookups in a sorted array of length s(k).

Acknowledgments We thank an anonymous reviewer for pointing out an improvement to the proof of Theorem 1. We will incorporated this improvement in the long version of this paper.

References [1] M. Backes, B. Pﬁtzmann, and M. Waidner. A universally composable cryptographic library. IACR Cryptology ePrint Archive 2003/015, Jan. 2003. http://eprint.iacr.org/. [2] D. Beaver. How to break a ”secure” oblivious transfer protocol. In Advances in Cryptology: EUROCRYPT ’92, volume 658 of Lecture Notes in Computer Science, pages 285–296. Springer, 1992. [3] M. Bellare, A. Boldyreva, and S. Micali. Public-key encryption in a multi-user setting: Security proofs and improvements. In Advances in Cryptology: EUROCRYPT 2000, volume 1807 of Lecture Notes in Computer Science, pages 259–274. Springer, 2000. [4] R. Canetti. Universally composable security: A new paradigm for cryptographic protocols. In Proc. 42nd IEEE Symposium on Foundations of Computer Science (FOCS), pages 136–145, 2001. [5] R. Cramer and I. Damg˚ ard. Secure signature schemes based on interactive protocols. In Advances in Cryptology: CRYPTO ’95, volume 963 of Lecture Notes in Computer Science, pages 297–310. Springer, 1995.

Reactively Secure Signature Schemes

95

[6] R. Cramer and I. Damg˚ ard. New generation of secure and practical RSA-based signatures. In Advances in Cryptology: CRYPTO ’96, volume 1109 of Lecture Notes in Computer Science, pages 173–185. Springer, 1996. [7] C. Dwork and M. Naor. An eﬃcient existentially unforgeable signature scheme and its applications. Journal of Cryptology, 11(3):187–208, 1998. [8] S. Goldwasser, S. Micali, and R. L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM Journal on Computing, 17(2):281–308, 1988. [9] B. Pﬁtzmann and M. Waidner. A model for asynchronous reactive systems and its application to secure message transmission. In Proc. 22nd IEEE Symposium on Security & Privacy, pages 184–200, 2001. [10] J. Rompel. One-way functions are necessary and suﬃcient for secure signatures. In Proc. 22nd Annual ACM Symposium on Theory of Computing (STOC), pages 387–394, 1990.

Validating Digital Signatures without TTP’s Time-Stamping and Certificate Revocation Jianying Zhou, Feng Bao, and Robert Deng Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 {jyzhou,baofeng,deng}@i2r.a-star.edu.sg Abstract. In non-repudiation services where digital signatures usually serve as irrefutable cryptographic evidence for dispute resolution, trusted time-stamping and certiﬁcate revocation services, although very costly in practice, must be available, to prevent big loss due to compromising of the signing key. In [12], a new concept called intrusion-resilient signature was proposed to get rid of trusted time-stamping and certiﬁcate revocation services and a concrete scheme was presented. In this paper, we put forward a new scheme that can achieve the same eﬀect in a much more eﬃcient way. In our scheme, forward-secure signature serves as a building block that enables signature validation without trusted time-stamping, and a one-way hash chain is employed to control the validity of public-key certiﬁcates without the CA’s involvement for certiﬁcate revocation. We adopt a model similar to the intrusion-resilient signature in [12], where time is divided into predeﬁned short periods and a user has two modules, signer and home base. The signer generates forward-secure signatures on his own while the home base manages the validity of the signer’s publickey certiﬁcate with a one-way hash chain. The signature veriﬁer can check the validity of signatures without retrieving the certiﬁcate revocation information from the CA. Our scheme is more robust in the sense that loss of synchronization between the signer and the home base could be recovered in the next time period while it is unrecoverable in [12]. Our scheme is also more ﬂexible in the real implementation as it allows an individual user to control the validity of his own certiﬁcate without using the home base.

1

Introduction

Digital signature is a fundamental mechanism in security services such as authentication and non-repudiation. A pair of private key and public key are used in signature generation and veriﬁcation, respectively. A digital signature of a message can be used to verify the origin and integrity of that message. Moreover, it can be used to protect against the signer’s false denial of creating the signature if the private key is only known to the signer. The relationship between a public key and an identity of the owner of the corresponding private key is usually established in the form of a public-key certiﬁcate that is issued by a trusted third party (TTP) called the certification C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 96–110, 2003. c Springer-Verlag Berlin Heidelberg 2003

Validating Digital Signatures

97

authority (CA). An expiry date speciﬁed in the certiﬁcate indicates its maximum lifetime that could be used to verify the digital signatures. In practice, as the private key might be compromised before the corresponding public-key certiﬁcate’s scheduled expiry date, additional security mechanisms are required to prevent signature forgery with the compromised key. 1.1

Validity of Digital Signatures

Security requirements on digital signatures are diﬀerent when they are used in authentication and non-repudiation services, respectively. While authentication services protect against masquerade, non-repudiation services provide evidence to enable the settlement of disputes [21]. In authentication services, the signature veriﬁer only needs to make sure that both the signature and the public-key certiﬁcate are valid at the time of veriﬁcation, and does not care about their validity afterwards. In non-repudiation services, however, the validity of a signature accepted earlier must be veriﬁable at the time of dispute resolution even if the corresponding public-key certiﬁcate has expired or been revoked. The scenarios illustrated in Figure 1 gives a clearer view on this problem.

Tg

Tv

Tr

Td

signature

signature

certificate

dispute

generation

verification

revocation/expiry

resolution

Fig. 1. Validity of Digital Signatures Suppose a signature is generated at time Tg . The authentication service ends by time Tv , at which the validity of signature is checked. Success of authentication relies on whether the signature and the corresponding public-key certiﬁcate are valid at Tv . Revocation or expiry of the certiﬁcate at time Tr , where Tr > Tv , has no eﬀect on the authentication service. Suppose a dispute resolution takes place at time Td , where Td > Tr . Obviously, the certiﬁcate is invalid at Td . On the other hand, the signature has been accepted as non-repudiation evidence at Tv , where Tv < Tr . If the signature is treated as invalid at Td because of certiﬁcate revocation (or expiry), any party can generate a signature and later deny it by revoking the certiﬁcate. Therefore, it is critical to ensure that once a signature is accepted as valid evidence, it

98

Jianying Zhou, Feng Bao, and Robert Deng

remains valid even if the corresponding certiﬁcate is revoked or expires at a later time. A number of mechanisms exist for maintaining validity of digital signatures as non-repudiation evidence. However, most of the existing mechanisms (e.g., [3,6,7,23]) rely on supporting services from trusted third parties, e.g., timestamping [2] and certiﬁcate revocation [10,17]. That means a transacting party in an on-going session needs to establish extra connections with TTPs. – It may need to connect with a time-stamping authority (TSA) for trusted time-stamping on a signature. – It may need to connect with a CA for certiﬁcation revocation information. Obviously, this is less eﬃcient for on-line transactions, and sometimes infeasible for a mobile device to support simultaneous connections. There exist two mechanisms that validate digital signatures without trusted time-stamping and certiﬁcate revocation, one-way sequential link signatures [22] and intrusion-resilient signatures [12]. However, the ﬁrst mechanism is only limited to B2B applications, where the transacting parties usually have a regular business relationship, and both sides maintain a long-term transaction log. The second mechanism is fragile in real applications as loss of synchronization between the signer and the home base can cause the signer unable to generate valid signatures any more. A brief review of these mechanisms will be given in Section 2. 1.2

Our Results

In this paper, we propose a new scheme for validating digital signatures as nonrepudiation evidence. We adopt a model similar to the intrusion-resilient signature in [12] and achieve the same eﬀect (i.e., validating signatures without relying on trusted third parties for time-stamping and certiﬁcate revocation) in a much more eﬃcient way. In our scheme, forward-secure signature serves as a building block that enables signature validation without trusted time-stamping. A one-way hash chain is employed to control the validity of public-key certiﬁcates without the CA’s involvement for certiﬁcate revocation. A user has two modules, signer and home base as in [12], but they function diﬀerently. The signer generates forward-secure signatures on his own while the home base manages the validity of the signer’s public-key certiﬁcate with a one-way hash chain. When the signer requests a new public-key certiﬁcate, the home base generates a one-way hash chain and keeps the root hash value conﬁdential, then sends the last chained hash value to the CA to be embedded into the certiﬁcate. The maximum lifetime of the certiﬁcate is divided into predeﬁned short periods, each of which is related to a chained hash value. At the beginning of a time period, the signer obtains the corresponding hash value from the home base to refresh the validity of his certiﬁcate. The signer also updates his forward-secure signing key at the beginning of a time period and generates forward-secure signatures. A valid forward-secure

Validating Digital Signatures

99

signature can only be generated with the signing key related to the time period in which the signature is generated. In other words, forward-secure signatures are time-related, and their validity can be preserved without relying on a trusted time-stamping service. Signing key update is a one-way function, and the compromise of the current signing key will not lead to the compromise of past signing keys. However, it will result in the compromise of future signing keys, thus the forgery of signatures in future time periods. In our scheme, a one-way hash chain is used to control the validity of the signer’s public-key certiﬁcate. The certiﬁcate may expire at the end of the current time period thus invalidating all future signing keys if the home base destroys the hash chain root and stops releasing hash values. The signature veriﬁer can check the status of such a certiﬁcate without retrieving the revocation information from the CA or a designated directory. Our scheme is more robust in the sense that loss of synchronization between the signer and the home base could be recovered in the next time period while it is unrecoverable in [12]. Our scheme is also more ﬂexible in the real implementation as it allows an individual user to control the validity of his own certiﬁcate without using the home base.

2

Previous Work

Here we give a brief review of two existing mechanisms that validate digital signatures without trusted time-stamping and certiﬁcate revocation, and point out their limitations and weaknesses. 2.1

One-Way Sequential Link Signature

One-way sequential link mechanism provides a solution for maintaining validity of digital signatures generated in transactions between two parties without the TTP’s intervention for time-stamping and certiﬁcate revocation [22]. The main idea is to link all digital signatures generated by a transacting party in a way that any change to the link will be detected. The transacting party can revoke his signing key by sending the ﬁrst and the latest digital signatures in the link to the trading partner for counter-signing. With the trading partner’s approval, the transacting party can deny digital signatures that are generated with his revoked key but are not in the counter-signed link. Suppose two parties A and B are going to do a series of transactions, and A needs to generate signatures on messages X1 , X2 , · · · , Xi . A can establish a one-way sequential link of his digital signatures sA1 , sA2 , · · · , sAi as follows. sA1 = SA (X1 , n1 ) sA2 = SA (X2 , H(sA1 ), n2 ) ··· sAi = SA (Xi , H(sAi−1 ), ni )

100

Jianying Zhou, Feng Bao, and Robert Deng

Here, H is a collision-resistant one-way hash function. n1 , · · · , ni are incremental sequential numbers or local time stamps serving as an index of the one-way sequential link, which could be used to facilitate dispute resolution. Suppose A’s public-key certiﬁcate is CA . When B receives sAk , B needs to make the following checks before accepting and saving it. 1. B veriﬁes A’s signature sAk . 2. B checks that CA has not expired and is not marked as revoked in B’s transaction log. 3. B checks that sAk is linked properly in the one-way sequential link associated with CA . Similarly, B can also establish a one-way sequential link of his digital signatures sB1 , sB2 , · · · , sBj for transactions conducted with A. Suppose A wants to revoke his CA while the latest signatures in the one-way sequential links of A and B are sAi−1 and sBj−1 , respectively. A can send B a request sAi = SA (revoke, sA1 , sAi−1 , H(sAi−1 ), nAi ) and B can reply with an approval sBj = SB (approve, sA1 , sAi , H(sBj−1 ), nBj ) and mark CA as revoked. Then, A is only liable to the signatures appeared in the link starting from sA1 and ending at sAi , and can deny any other signatures intended for B and associated with CA . If needed, B can also terminate his one-way sequential link in the same way. Limitation 1: One-way sequential link mechanism is only limited to B2B applications, where the transacting parties usually have a regular business relationship. Each party should maintain a long-term transaction log, and cooperation is needed in approving the other party’s revocation request. Limitation 2: One-way sequential link mechanism only supports certiﬁcate revocation by the transacting parties themselves. In some applications, however, a transacting party’s certiﬁcate may need to be revoked by its manager to terminate the power of signing. 2.2

Intrusion-Resilient Signature

Intrusion-resilient signature was proposed in [12] for the purpose of getting rid of trusted time-stamping and certiﬁcate revocation in validating digital signatures. The provably-secure scheme presented in [12] is reﬁned in mathematics. However, a weakness exists in the scheme from the implementation viewpoint. We reason that the theoretical merit of the scheme does not lead to the practical implementation. The scheme in [12] takes the model where each user (signer), besides securely storing his signing key SKU , has a secret key SKB stored in his home base,

Validating Digital Signatures

101

which is used for updating the private signing key. There are two operations in updating the signing key, key update and key refresh. Time is divided into T short periods. Key update is conducted once at the end of each period while key refresh may be done multiple times within each period. The operation of key refresh brings fragility to the scheme in practical application of the scheme. In this operation, the secret SKB stored at the home base is refreshed with a randomly chosen number r, i.e., SKB := ref reshbase (SKB, r). The r and old SKB are then destroyed by the home base. The new SKB is sent to the user, which is used to refresh the signing key SKU , i.e., SKU := ref reshuser (SKU, SKB). This is equivalent to requiring a sort of synchronous status between SKU and SKB. The “synchronization” might be broken due to various possibilities, such as the user misses the SKB sent to him or an attacker succeeds somehow to conduct refresh operation with the home base. In that case, the SKU held by the user and the SKB stored at the home base are not consistent, and the synchronization can never be recovered as the home base has erased r and old SKB. As a result, the signing key cannot be updated correctly any more, and the corresponding public key has to be given up for ever. Our scheme does not suﬀer from this fragility in the sense that even if the update message from the home base to the user is lost or intercepted, it only aﬀects the current period but not the periods after the current period. Key-insulated signature [8] employs a model similar to the above intrusionresilient signature scheme. However, its security is weaker in some sense. If the signer’s current signing key is compromised, and the current key update information is also intercepted by an attacker, signatures of both the current and the subsequent periods could be forged. Moreover, eﬃciency is another concern because the length of public key grows linearly with the number of key-insulated periods. This is also true to master key stored in the home base for signing key update. There is a common weakness in both the intrusion-resilient and key-insulated signature schemes which did not deal with signature forgery once the signing key is compromised in the current time period. Although it might be a short time period that an adversary can forge signatures, the insecure window could leave the validity of all signatures generated in such a period in question. We will further discuss this problem in our scheme.

3

A New Signature Validation Scheme

Here we propose a new scheme that validates digital signatures without the TTP’s intervention for time-stamping and certiﬁcate revocation. The objective of our new scheme is to remove the limitations and weaknesses existing in the previous mechanisms. 3.1

Forward-Secure Signature

Forward-secure signature serves as a building block that enables signature validation without trusted time-stamping. In a forward-secure signature scheme,

102

Jianying Zhou, Feng Bao, and Robert Deng

time is divided into predeﬁned short periods, and the public key is ﬁxed while the corresponding signing key is updated at the beginning of each period with a public one-way function. Several schemes have been proposed in the past few years [1,4,11,14,15,16,19]. Definition A forward-secure digital signature scheme is a quadruple of algorithms, (FSkeygen, FSsign, FSupdate, FSverify), where: FSkeygen, the key generation algorithm, is a probabilistic algorithm which takes as input a security parameter k and returns a pair (SK1 , P K), the initial signing key and the public key; (P K may be registered with the CA.) FSsign, the signing algorithm, takes as input the signing key SKj for the current time period j and the message M to be signed and returns a pair , the signature of M for time period j; FSupdate, the signing key update algorithm, takes as input the signing key for the current period SKj , returns the new signing key SKj+1 for the next period and erases the past signing key SKj ; (The signing key update in each time period is illustrated in Figure 2.) FSverify, the veriﬁcation algorithm, takes as input the public key P K, a message M , and a candidate signature , and returns 1 if is a valid signature of M or 0, otherwise. Suppose a signer A’s signing key SKj is compromised at the time period j. Others cannot derive the past signing key SKp from SKj (pj), thus can forge valid signatures of the future time period f . Therefore, once SKj is compromised, A needs to inform the CA to revoke the corresponding certiﬁcate. Meanwhile, the signature veriﬁer needs to get the revocation information from the CA to check the validity of the certiﬁcate. A new mechanism is required for validating forward-secure signatures without the CA’s intervention for certiﬁcate revocation. 3.2

Refreshable Certificate

The refreshable certificate is an extension of the standard public-key certiﬁcate. The maximum lifetime of such a certiﬁcate is divided into short periods. The

Validating Digital Signatures

103

signer A is allowed to refresh the validity of his own certiﬁcate under the control of his home base, and the signature veriﬁer can check the validity of A’s certiﬁcate without retrieving the revocation information from the CA. Role of Home Base A home base serves as a manager who has authority over a group of signers. It plays a role diﬀerent from the CA. – A home base is only recognized by the signers under his management, and manages the validity of their certiﬁcates. – The CA is a more widely recognized trusted third party, and issues publickey certiﬁcates for a larger population. A home base is not required to be trusted by or connected with any entity other than the signers under his management. Therefore, the cost for establishment of a home base is much lower than that of the CA, and the bottleneck problem related to a home base is much less serious than to the CA. Co-operation with a home base in signature generation is not a weakness, but an advantage, in our scheme. As the home base acts as a manager of those signers, it can terminate a signer’s power of signing at the end of current time period if needed (e.g. because of change of job). Generation of Certificate Generation of a refreshable certiﬁcate involves three parties: the signer A, A’s home base, and the CA. Step 1. Actions by the signer A: 1. Generate a pair of keys: private key SKA and public key P KA . 2. Send P KA to his home base over an authenticated channel 1 . Step 2. Actions by A’s home base: 1. Deﬁne the maximum lifetime of A’s certiﬁcate as T time periods and the starting valid date as D, and select the length of each time period as L. (The refreshing points are denoted as D1 = D + L, D2 = D + 2 ∗ L, · · · , DT = D + T ∗ L and illustrated in Figure 2.) 2. Select a random number r, and generate a one-way hash chain H i (r) = H(H i−1 (r)) (i = 1, 2, · · · , T ), where H 0 (r) = r. 3. Send (A, P KA , D, H T (r), T, L) to the CA. Step 3. Actions by the CA: 1. Authenticate the certiﬁcate request with A’s home base in an out-of-band method to ensure the request is authorized by the home base 2 . 1 2

Suppose the signer A has registered with his home base. The authenticated channel can be established with a password-based protocol (e.g., [5,20]). On-line authentication could be performed if a secure channel exists between A’s home base and the CA.

104

Jianying Zhou, Feng Bao, and Robert Deng

2. Challenge A for a signature to ensure A holds the corresponding private key. 3. Generate a certiﬁcate CertA = SCA (A, P KA , D, H T (r), T, L) 3 . 4. Issue CertA to A (via A’s home base). Compared with a standard public-key certiﬁcate, CertA contains the extra data (H T (r), T, L) 4 . They will be used to control the validity of CertA .

Refreshing Point:

D 1 ...

D

T-1

Hash Value Release:

H

Signing Key Update:

SK1

(r)

T-2

H SK2

(r)

D j ... D T-1

D j-1

i

H (r) SKj

i-1

H

DT

0

(r)

H (r)

SKj+1

SKT

Fig. 2. Hash Value Release and Signing Key Update Use of Certificate At the starting valid date D, A retrieves H T −1 (r) from his home base to initialize the validity of CertA 5 , which then has an expiry date D1 = D + L. Suppose the next refreshing point of CertA is Dj . A retrieves H i (r), where i = T − (Dj − D)/L = T − j, from his home base, and attaches (H i (r), i) to each signature generated in the period between Dj−1 and Dj 6 . (The hash value release at each refreshing point is illustrated in Figure 2.) Note that it is entirely up to A for retrieving the hash value from his home base at a refreshing point. For example, if A does not generate any signature in the period between Dj−1 and Dj , A does not need to retrieve H i (r). But later if A wants to generate signatures in the period between Dj and Dj+1 , A can directly retrieve H i−1 (r). On the other hand, the home base has the full control on the validity of A’s certiﬁcate. If A’s authorization on signing with SKA must be revoked for some reasons such as change of job or key compromise, the home base can stop releasing the next hash value. Suppose A released (H i (r), i); the current time is Dv ; a signature veriﬁer B holds the CA’s public veriﬁcation key. B can take the following steps to check the status of CertA . 3 4 5 6

For simplicity, other less related information is omitted in CertA . CertA should also include an identiﬁer of the hash function used to generate and verify the hash chain. The home base could select an optimal technique in the computation-storage tradeoﬀ of hash chain traversal [18]. (H i (r), i) need not be a part of message to be signed. Instead, it is only the data that will be stored or transmitted together with the signature.

Validating Digital Signatures

105

1. B veriﬁes the CA’s signature on (A, P KA , D, H T (r), T, L). If valid, B is sure that A’s public key is P KA . The starting valid date is D, the maximum lifetime is T ∗ L, the refreshing time period is L, and the last hash value in the one-way hash chain is H T (r). 2. B checks that 0 ≤ i < T and H T −i (H i (r)) = H T (r). If true, B believes that H i (r) is a valid hash value in the one-way hash chain ended with H T (r). 3. B checks that Dv ≤ D + (T − i) ∗ L. If true, B concludes that CertA is valid now, and remains valid until Dj = D + (T − i) ∗ L. In such a way, the validity of CertA can be controlled by releasing the corresponding hash value when A generates digital signatures. B can check the status of CertA without retrieving the revocation information from the CA. Thus, the CA is exempted from certiﬁcate revocation. 3.3

Signature Validation

With the forward-secure signature and refreshable certiﬁcate, we can validate digital signatures without relying on the trusted third parties for time-stamping and certiﬁcate revocation. Suppose a signer A wants to generate a signature in the period j − 1, i.e., between refreshing points Dj−1 and Dj . A’s corresponding signing key is SKj . A forward-secure signature on message M is denoted as FSsign(M, SKj ) = . If A is sure that SKj is not compromised at the end of this period, A performs FSupdate and retrieves H i (r) and H i−1 (r), where i = T − j for j ≤ T − 1, from his home base 7 . Then A attaches to the signature. By releasing H i (r) and H i−1 (r), the signer A is liable for all signatures generated with forward-secure signing keys SKp for p ≤ j (i.e., signatures generated before the refreshing point Dj ). But A can deny all signatures generated with SKf for f > j (i.e., signatures generated after the refreshing point Dj ) if H i−2 (r) and its pre-images in the hash chain are not released. Suppose a signature veriﬁer B receives from A. B makes the following checks to conclude whether the signature and the related information could serve as valid non-repudiation evidence. 1. B veriﬁes A’s signature by checking the output of FSverify(M, j, s, P K). If true, B believes that is A’s signature on M generated during the time period j − 1, i.e., between refreshing points Dj−1 and Dj . 2. B further veriﬁes the status of CertA with as described before. If true, B believes that CertA is valid until the refreshing point Dj . 3. With H i−1 (r), B concludes that A is committed being responsible for all signatures generated between refreshing points Dj−1 and Dj . Thus B can accept as valid non-repudiation evidence. 7

To reduce the delay between signature generation in the period j − 1 and release of H i−1 (r) at the beginning of the period j, the refreshing period L may need to be deﬁned short. Alternatively, A may release H i−1 (r) in the period j − 1 if A is willing to undertake the risk of compromise of SKj .

106

Jianying Zhou, Feng Bao, and Robert Deng

Suppose SKj is compromised, and A has released H i−1 (r) in the period j − 1. Although an adversary can derive SKj+1 from SKj and CertA is valid in the corresponding period j (i.e., between refreshing points Dj and Dj+1 ), the adversary cannot forge valid signatures in the period j as long as A has not released H i−2 (r) which is a part of non-repudiation evidence in the above signature validation process. The above signature validation process shows that signature generation and veriﬁcation are not necessary to be taken in the same period. Instead, given a forward-secure signature being generated in an arbitrary period, the veriﬁer simply makes sure that the certiﬁcate is not only valid in the period that the signature was generated but also valid in the next period. The clocks of the signer and the veriﬁer may not be strictly synchronized to the real time, and a relative time could be used in our scheme. The signer A can generate a signature with SKj in a relative time period j − 1 while the actual time may not be the one between Dj and Dj+1 . The veriﬁer can check the validity of the signature without referring to the actual time of signature generation and veriﬁcation 8 . Therefore, the time information related to such a forward-secure signature cannot be used to prove the actual time of signature generation. Even if the clocks of the signer and the veriﬁer are synchronized to the real time, the time information still cannot be used to prove that a forwardsecure signature was actually generated within that time period. The signer can always use the signing key corresponding to a speciﬁc time period to generate a back-dated forward-secure signature (if the signer keeps the signing keys of the previous periods) or a post-dated forward-secure signature. Therefore, if the evidence on the time of signature generation is required in non-repudiation services, trusted time-stamping is necessary. 3.4

Optimization for Individual Users

In the above signature validation scheme, the home base acts as a manager of a group of signers for controlling the validity of their public-key certiﬁcates. This is especially useful in an enterprise environment, where each staﬀ’s power of signing is authorized by his manager. If a signer is an individual user who takes the full responsibility on the validity of his own certiﬁcate, our scheme could be optimized to enable signature validation without using the home base. In such a case, the hash chain root r will be generated by the signer instead of his home base. Then it is up to the signer whether to release a hash value to refresh the validity of his certiﬁcate. There is an advantage on the use of a separate secret r to protect the signing key SKi for an individual signer A. The system remains secure as long as either r or SKi is not compromised. If SKi is compromised, A could destroy r then CertA 8

In practice, however, it is safer for the veriﬁer to synchronize his clock to the real time, and only accept signatures while the corresponding certiﬁcate has not reached its maximum lifetime.

Validating Digital Signatures

107

will expire shortly at the next refreshing point. Similarly, if r is compromised, A could destroy SKi and stop using it for signing. The hash chain root r and the signing key SKi are diﬀerent in two aspects. – The signing key might be used at any time while the hash chain root is needed only at the refreshing points. That means SKi should be highly available in a system while r could be kept “oﬀ-line”. – The signing key usually has a length of 1024 bit or above while the hash chain root can be as short as 128 bits. That implies SKi is usually beyond the human’s capability to memorize while r might be memorized. Consequently, the signer A could protect r in a way diﬀerent from SKi . A might remember r and manually input r at the time of refreshing CertA . After the hash value needed for refreshing is generated, r will be erased from the local computer system thus minimizing the possibility of compromise caused by system break-in. There might be other ways to protect r “oﬀ-line” in a temper-proof hardware while keeping SKi “on-line” in a local system. 3.5

Comparison

Our signature validation scheme removes the limitations of the one-way sequential link mechanism in [22]. It is not restricted to B2B applications. It is especially useful in B2C applications where the number of customers are much more than the number of merchants. Suppose a merchant does 1000 transactions with 1000 customers, and generates one signature in each transaction within a time period (e.g., one day). With our new signature validation scheme, the merchant only needs to retrieve one hash value from his home base for generating 1000 signatures, and the customers do not need to make any connection to the CA when verifying the merchant’s signatures and certiﬁcate. In comparison, if a certificate revocation list (CRL) is used, each customer needs to retrieve the CRL from the CA in order to verify the merchant’s signatures and certiﬁcate. The operation cost is at least 1000 times higher than our scheme. Many of customers in B2C applications are likely individual users, then our scheme even supports validation of signatures generated by such customers without using the home base. This allows for a more ﬂexible implementation of our signature validation scheme compared with the intrusion-resilient signature in [12]. The requirement on the synchronization between the signer and the home base in our signature validation scheme is much weaker than in [12]. Loss of synchronization in [12] is fatal and unrecoverable. In our scheme, however, unavailability of a hash value from the home base only causes the signer unable to generate signatures in one time period. The signer’s power of signing can be recovered when receiving the next hash value in the next time period.

108

Jianying Zhou, Feng Bao, and Robert Deng

Actually, temporary unavailability of a hash value from the home base is a feature of our signature validation scheme. It allows the home base (manager) to temporarily disable the signer’s power of signing for some reason (e.g., on leave), and restore the signer’s power later if necessary 9 . Therefore, our scheme is more robust with enriched functions in the real implementation. There is a risk of signature forgery in [12] if the current signing key is compromised but has not expired yet. It may leave the validity of all signatures generated in the current period in question. Such a risk is handled in our scheme by requiring the singer to postpone releasing the hash value of the next period (which serves as a part of non-repudiation evidence) until the current signing key expires. That means a delay might be introduced in signature validation, though the delay could be reduced by deﬁning a short refreshing period L. Therefore, our scheme will not completely replace instant and trusted time-stamping and certiﬁcate revocation services which are still useful for high value transactions that cannot tolerate any risk of signature forgery and delay of signature validation.

4

Conclusion

Maintaining validity of digital signatures is of signiﬁcant importance in nonrepudiation services. The conventional approach is to rely on trusted third parties to provide time-stamping and certiﬁcate revocation services, both of which are very costly in practice. Intrusion-resilient signature is a new concept proposed in [12] to get rid of time-stamping and certiﬁcate revocation in signature validation. The scheme is secure but has some weaknesses which may aﬀect its robustness, eﬃciency, and ﬂexibility in practical implementation. In this paper, we proposed a new approach for signature validation. It achieves the same eﬀect (i.e., validating signatures without trusted time-stamping and certiﬁcate revocation) in a much more eﬃcient way, and overcomes the weaknesses in the existing schemes. In our scheme, forward-secure signature serves as a building block that enables signature validation without trusted time-stamping. A one-way hash chain is employed to control the validity of public-key certiﬁcates without the CA’s involvement for certiﬁcate revocation. Some attractive features of our signature validation scheme include – The signer’s power of signing can be temporarily disabled by the home base and recovered later if necessary. – Signatures generated by an individual user can be validated without using the home base.

References 1. M. Abdalla and L. Reyzin. A new forward-secure digital signature scheme. Lecture Notes in Computer Science 1976, Advances in Cryptology: Asiacrypt’00, pages 116–129, Kyoto, Japan, December 2000. 9

The manager should be careful when deciding to restore a signer’s power of signing as this will also result in a recovery of the signer’s power in the past disabled periods.

Validating Digital Signatures

109

2. C. Admas, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 public key infrastructure time-stamp protocol (TSP). RFC 3161, August, 2001. 3. S. G. Akl. Digital signatures: a tutorial survey. Computer, 16(2):15–24, February 1983. 4. M. Bellare and S. Miner. A forward-secure digital signature scheme. Lecture Notes in Computer Science 1666, Advances in Cryptology: Proceedings of Crypto’99, pages 431–438, Santa Barbara, California, August 1999. 5. S. Bellovin and M. Merritt. Encrypted key exchange: Password-based protocols secure against dictionary attacks. Proceedings of 1992 IEEE Symposium on Security and Privacy, pages 72–84, Oakland, California, May 1992. 6. K. S. Booth. Authentication of signatures using public key encryption. Communications of the ACM, 24(11):772–774, November 1981. 7. R. DeMillo and M. Merritt. Protocols for data security. Computer, 16(2):39–50, February 1983. 8. Y. Dodis, J. Katz, S. Xu, and M. Yung. Strong key-insulated signature schemes. Lecture Notes in Computer Science 2567, Proceedings of 2003 International Workshop on Practice and Theory in Public Key Cryptography, pages 130–144, Miami, January 2003. 9. L. C. Guillou and J. J. Quisquater. A paradoxical identity-based signature scheme resulting from zero-knowledge. Lecture Notes in Computer Science 403, Advances in Cryptology: Proceedings of Crypto’88, pages 216–231, Santa Barbara, California, August 1988. 10. R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 public key infrastructure certiﬁcate and CRL proﬁle. RFC 2459, January 1999. 11. G. Itkis and L. Reyzin. Forward-secure signatures with optimal signing and verifying. Lecture Notes in Computer Science 2139, Advances in Cryptology: Proceedings of Crypto’01, pages 332–354, Santa Barbara, California, August 2001. 12. G. Itkis and L. Reyzin. SiBIR: Signer-base intrusion-resilient signatures. Lecture Notes in Computer Science 2442, Advances in Cryptology: Proceedings of Crypto’02, pages 499–514, Santa Barbara, California, August 2002. 13. ITU-T. Information technology – Open systems interconnection – The directory: Public-key and attribute certiﬁcate frameworks. ITU-T Recommendation X.509(V4), 2000. 14. A. Kozlov and L. Reyzin. Forward-secure signatures with fast key update. Proceedings of 3rd Conference on Security in Communication Networks, Amalﬁ, Italy, September 2002. 15. H. Krawczyk. Simple forward-secure signatures from any signature scheme. Proceedings of 7th ACM Conference on Computer and Communications Security, pages 108–115, Athens, Greece, November 2000. 16. T. Malkin, D. Micciancio, and S. Miner. Eﬃcient generic forward-secure signature with an unbounded number of time period. Lecture Notes in Computer Science 2332, Advances in Cryptology: Proceedings of Eurocrypt’02, pages 400–417, Amsterdam, The Netherlands, April 2002. 17. M. Myers, R. Ankney, A. Malpani, S. Galperin and C. Adams. X.509 Internet public key infrastructure on-line certiﬁcate status protocol (OCSP). RFC 2560, June 1999. 18. Y. Sella. On the computation-storage trade-oﬀs of hash chain traversal. Lecture Notes in Computer Science, Proceedings of 2003 Financial Cryptography, Gosier, Guadeloupe, January 2003.

110

Jianying Zhou, Feng Bao, and Robert Deng

19. D. Song. Practical forward secure group signature schemes. Proceedings of 8th ACM Conference on Computer and Communication Security, pages 225–234, Philadelphia, November 2001. 20. T. Wu. The secure remote password protocol. Proceedings of 1998 Internet Society Network and Distributed System Security Symposium, pages 97–111, San Diego, California, March 1998. 21. J. Zhou. Non-repudiation in electronic commerce. Computer Security Series, Artech House, 2001. 22. J. Zhou. Maintaining the validity of digital signatures in B2B applications. Lecture Notes in Computer Science, Proceedings of 2002 Australasian Conference on Information Security and Privacy, pages 303–315, Melbourne, Australia, July 2002. 23. J. Zhou and K. Y. Lam. Securing digital signatures for non-repudiation. Computer Communications, 22(8):710–716, Elsevier, May 1999.

A Fast Signature Scheme Based on New On-line Computation Takeshi Okamoto1 , Hirofumi Katsuno2 , and Eiji Okamoto1 1

Institute of Information Sciences and Electronics, University of Tsukuba, 1-1-1 Tennodai, Tsukuba, Ibaraki, 305-8573, Japan, {ken, okamoto}@is.tsukuba.ac.jp 2 Department of Information Science, Tokyo Denki University, Hatoyama-machi, Hiki-gun, Saitama, 350-0394, Japan, [email protected]

Abstract. In this paper, we propose a fast signature scheme which realizes short transmissions and minimal on-line computation. Our scheme would require a modular exponentiation as preprocessing (i.e., oﬀ-line computation). However, there exist the following remarkable properties: neither multiplication and modular reduction is used in the actual signature generation (i.e., on-line computation). This means that in the on-line phase, our scheme requires only two operations: hashing and addition. So far, some fast signature schemes with small on-line computation are proposed. However, those schemes require multiplication or modular reduction in the on-line phase. This leads to a large amount of work compared to that of addition. As far as we know, this is the ﬁrst approach to obtain the fast signature without those two calculus methods.

1 1.1

Introduction Motivation

Nowadays, a signature scheme is an important tool for secure communication over open network. Consequently, we are strongly longing for more compact signature schemes to spread public-key infrastructure (PKI) system. In this case, the compactness means the eﬃciency of both computational work and transmitted data size. Such a compactness gives user’s convenience, and is acceptable for various application. We now consider the computational eﬃciency in signature schemes. Let us focus on the signer’s computational work in the signature schemes which can be derived from a three-pass identiﬁcation scheme like [21]. In such a signature scheme, there exist two kinds of computation for the signer: pre-computation and (actual) signature generation. The pre-computation can compute values without a message to be signed, and be executed during idle time and completely independent of the message. This means that such a computational cost does not inﬂuence the real-time computing. In this paper, we say that such a computation is the oﬀ-line processing. C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 111–121, 2003. c Springer-Verlag Berlin Heidelberg 2003

112

Takeshi Okamoto, Hirofumi Katsuno, and Eiji Okamoto

On the other hand, the (actual) signature generation does directly inﬂuence the processing time because a message is indispensable for computing. We say that such a computation is on-line processing in this paper. To estimate the eﬃciency of a signature scheme, we must separately consider the two types of computation. Needless to say, the fast signature scheme with the on-line computational eﬃciency, can make digital signatures much more practical in a variety of scenarios. We now focus on the various operations which appear in the on-line signature generation. In the case of usual signature, there exist four kinds of operations: (1) multiplication, (2) modular reduction, (3) addition and (4) hashing. Here (1) and (2) require much more large amount of work compared to (3) or (4). Therefore, one technique for reducing the computational work is to eliminate the operation of (1) or (2). Of course, to eliminate both (1) and (2) is the most desirable way for fast on-line computing. As far as authors know, such a scheme has never been proposed in the past. 1.2

Related Work

To realize the fast on-line signature generation, Girault [6] modiﬁed Schnorr’s scheme [21] which uses an RSA-modulus (i.e., the modulus is a product of two distinct primes) instead of a prime modulus. This modiﬁcation leads to no modulo reduction in the on-line signature generation. Therefore, Girault’s scheme makes faster processing for signature generation compared to Schnorr’s one. In 1998, Poupard and Stern [18] investigated and gave provable security for Girault’s scheme, and named that scheme GPS for short. Due to the description of [18] we say that a signature scheme, in which modulo reduction is not used in the on-line signature generation, is on the ﬂy scheme. In 1999, Poupard and Stern [19] proposed another on the ﬂy scheme (PS for short), whose security relies on the diﬃculty of integer factoring. In 2001, Okamoto, Tada and Miyaji [13] proposed on the ﬂy scheme (OTM1 for short) by improving PS in the computational work and transmitted data size. In 2002, Okamoto, Tada and Miyaji [14] proposed another signature (OTM2 for short) in which no multiplication is used in the on-line phase. This means that the phase involves only hashing, addition and modular reduction. The calculus method in OTM2 is more advantageous than that in the on the ﬂy schemes mentioned above, because a single modulus (in this case, a prime s) can be used in OTM2 and many reductions are executed by using such a modulus operation. 1.3

Our Contribution

In this paper, we propose a fast signature scheme. Our scheme has small keystorage ineﬃciencies such as the size of public-key or that of secret-key, but realizes quite fast on-line signature generation. Our idea to reduce the on-line computation, is completely diﬀerent from that of previous work. That is, both modular reduction and multiplication are

A Fast Signature Scheme Based on New On-line Computation

113

eliminated in our scheme. Our scheme consists of only hashing and addition in the on-line phase. Up to the present, some fast signature schemes which have the property of small on-line computation, have been proposed. To sum up, in the on-line computation, multiplication is used in on the ﬂy schemes and the modular reduction is used in the OTM2 scheme. We emphasize that those two operations are not used in our scheme. Now let us compare the computational eﬃciency among the multiplication, the modular reduction and the addition. In the multiplication, a recursive algorithm due to [8] reduces the complexity of the multiplying. In the modular reduction, we can use the eﬃcient technique such as [1, 11]. Nevertheless, those methods must suﬀer from a large amount of work to compute compared to the addition. On the other hand, addition is computed using a more straightforward way, and reduces the considerable complexity in on-line phase. Consequently, the addition in our scheme is faster than the other operations from implementation point of view. For more detailed treatment of the operations, see [9]. We now give a concrete evaluation with respect to the performance. Compared with Feige-Fiat-Shamir [4] (FFS for short), GPS, PS, OTM1 and OTM2, the size of a signature in our scheme can be reduced by at least 67%, 72%, 51%, 6%, 24%, respectively. As for the security, our scheme is as secure as integer factoring problem based on an RSA modulus n (in the random oracle model). To satisfy the security, our schemes use a public key g with speciﬁc structure, called asymmetric basis, and which is a variant of [15]. This property leads to good eﬃciency in terms of both transmitted data size (i.e., the size of signature) and amount of work (in the on-line phase).

1.4

Outline of Our Paper

This paper is organized as follows. In Section 2, we introduce our signature scheme. In Section 3, we show that our scheme is provably secure under the assumption that factoring problem is computationally hard to solve. In Section 4, we suggest practical values of our signature scheme and will describe the implementation notes. In Section 5, we evaluate the performance of our signature scheme by comparing with existing fast on-line signature signatures: FFS, GPS, PS, OTM1, OTM2. The conclusion is given in Section 6.

2

Signature Scheme

In this section, we introduce our signature scheme. Note that our signature scheme is derived from three-pass interactive zero-knowledge identiﬁcation scheme. That scheme can be translated into a signature scheme by using the technique of [5, 21]

114

2.1

Takeshi Okamoto, Hirofumi Katsuno, and Eiji Okamoto

Preliminaries

We ﬁrst brieﬂy show public parameters. Let k, a, s and O be four integers satisfying 2k 2s 2a and 2k O. The more detailed relations between those parameters are analyzed in Section 4. Notation is given as follows. The order of an element g ∈ Z∗n is represented ∗ k as Ordn (g). Let H : {0, 1} → {0, 1} be a hash function. The right side of ∗ H(x) = (e1 , e2 , · · · , ek ) means the bit strings of bit length k, where x ∈ {0, 1} ∗ and ei ∈ {0, 1} (1 ≤ i ≤ k). Let m ∈ {0, 1} be a message to be signed. In our scheme, we use slightly generalized asymmetric basis [15], which is deﬁned as follows. Definition 21 (Asymmetric basis) Let n be an RSA modulus such that n = pq. Then we say that g is an asymmetric basis in Z∗n if the multiplicity of 2 in Ordp (g) is not equal to that of 2 in Ordq (g). 2.2

Key Generation

A signer who wants to generate key parameters, executes the following steps. Step1 Pick up two large primes p and q. Step2 Compute n = pq. Step3 Pick up an asymmetric basis g ∈ Z∗n , where Ordn (g) = O. Step4 Pick up k random integers s1 , s2 , · · · , sk ∈ Z2s Step5 Compute vi = g −si mod n; each i (1 ≤ i ≤ k). Public-key/Secret-key: Signer’s public-key is (v1 , v2 , · · · , vk ; n; g) and secretkey is (s1 , s2 , · · · , sk ). 2.3

Signature Generation

Suppose a signer who has a public-key and the corresponding secret-key, generates the signature of her message m. Then she executes the following steps: Step1 Pick up a random number r ∈ Z2a . Step2 Compute x = g r mod n. Step3 Compute e = H(x, m) = (e1 , e2 , · · · , ek ); each ei ∈ {0, 1}. k Si , where Step4 Compute y = r + Σi=1 0 if ei = 0; Si = si if ei = 1. As you see, our scheme requires only a hashing (Step2) and an addition (Step3) in the on-line phase for the signer. This means that our scheme satisﬁes the conditions which are described in Section 1. Signature: The signature for a message m is (x, e, y).

A Fast Signature Scheme Based on New On-line Computation

115

Key generation Parameters: • RSA modulus n = pq • asymmetric basis g ∈ Zn∗ with Ordn (g) = O • for each i (1 ≤ i ≤ k) [ si ∈R 2s , vi = g −si mod n ] • 2k 2s 2a , 2k O

Signature generation and verification Signer

Veriﬁer

Public-key: vi , n, g Secret-key: si r ∈R Z2a x = g r mod n

pre-compute for (r, x)

e = H(x, m) := (e1 , e2 , · · · , ek ) for each ei ∈ {0, 1} k y = r + Σi=1 Si , where 0 if ei = 0; Si = si if ei = 1.

m, (x, e, y) −−−−−−−−−−−−−−−−−−−−−→

k x = g y Πi=1 viei mod n ?

e = H(x , m)

Fig. 1. Our signature scheme.

2.4

Verification

Suppose a veriﬁer who has the signer’s public key and the corresponding message, checks the validity of the signature for m. Then she executes the following steps: Step1 Check y < 2a holds or not. If the equation does not hold, then reject the signature and stop this protocol. k viei modn Step2 Compute e = H(x, m) and x = g y Πi=1 Step3 Check whether both e = e and x = x hold or not. If both equations hold, accept the signature. Otherwise reject it.

116

3

Takeshi Okamoto, Hirofumi Katsuno, and Eiji Okamoto

Security Analysis

We say that a signature scheme is secure, if no polynomial time adversary can existentially forge a signature under the adaptive chosen message attack. In this section, we show that our signatures scheme is secure, by using the forking lemma in [16], and showing that a signing oracle can be simulated by a polynomial-time machine in the random oracle model [2], which is under the one key attack scenario. Lemma 31 Let n be an RSA modulus and g be an asymmetric basis in Z∗n . Assume that we ﬁnd L > 0 such that g L = 1 mod n. Then we can construct a Turing machine M which on input n, g and L outputs a factor of n in time O(|L||n|2 ) Proof. (Sketch) This lemma is basically due to [15]. Hereafter, we describe how to construct M . At ﬁrst, M extracts the odd part b of L, such that L = 2a b. Since g is an asymmetric basis in Z∗n , it holds g 2b = 1 mod p and g 2b = 1 mod q, and also holds g b = 1 mod p and g b = −1 mod q. Then we have the following results: p | g b − 1 and n g b − 1. Consequently, M can ﬁnd a factor of n by computing gcd(g b − 1 mod n, n). Note that modular exponentiation algorithm (resp. extended Euclidean algorithm) has a running time of O(|L||n|2 ) (resp. O(|n|2 )). Hence M can execute the above steps in time O(|L||n|2 ). We say that a positive function f (k) : N → R is said to be negligible, if for any c, there exists a kc such that f (k) ≤ k −c for any k ≥ kc . Otherwise f is said to be non negligible. Let Q be the number of queries which a polynomial-time adversary A (adaptive chosen-message attacker) can ask to the random oracle. Let R be the number of queries which A can ask to the the actual signer. |x| denotes the binary length for a positive integer x. Theorem 32 Assume that, in our scheme, 2s /2a is negligible. Also assume that A can forge a signature with non-negligible probability ε ≥ 10(R+1)(R+Q)/2a , and with the average running time T . Then we can construct a polynomial time machine M which can solve the factorization of n with non negligible probability in expected time O(QT /ε + |L||n|2 ). Proof. (Sketch) We ﬁrst show that our signature can be statistically simulated by a polynomial time machine. This machine is simulated according to the protocol like in [16]. We denote, by p(α, β, γ) and p (α, β, γ), the probabilities that (α, β, γ) is output by the signature algorithm and the simulator, respectively. We set φ = ∗ k 2k+1 −1. Let R : {0, 1} → {0, 1} be an ideal hash function (i.e., random oracle) ∗ for a given message m ∈ {0, 1} . Here R(x1 , x2 ) = (β1 , β2 , · · · , βk ) = β for two integers x1 and x2 . For an integer A and a positive constant ∆, N (R, A, ∆) is

A Fast Signature Scheme Based on New On-line Computation

117

deﬁned to be the number of pairs (e, y) such that 0 ≤ e < 2k+1 , A ≤ y < A + ∆ k and R(g y Πi=1 viei mod n, m) = e. Then we have the following:  y k βi  g Πi=1 vi mod n = α,  χ  R(α, m) = β, a 0 ≤ γ − sβ < 2 p(α, β, γ) = 2a and

 k viβi mod n = α, g y Πi=1  χ  R(α, m) = β, a − φ φ ≤ γ < 2 , p (α, β, γ) = N (R, φ, 2a − φ) 

where for a predicate ℘, χ(℘) is the characteristic function of ℘, that is, χ(℘) = 1, if ℘ is true, and χ(℘) = 0, otherwise. Therefore, the summation Σ= |p(α, β, γ) − p (α, β, γ)| α,β,γ

has a upper bound of 2s k/2a , because Σ = 2(1 − N (R, φ, 2a − φ)/2a ) holds similarly with [18]. Consequently, the output by real signer and that by the simulator are statistically indistinguishable. Next, by using the technique in [16], we can get a multiple of Ordn (g), L, such that g L = 1 mod n. This means that we can obtain factorization of n. Hence this proves the theorem.

4

Parameter Generation

In this section, we describe the conditions of the parameters to keep the security with respect to our signature scheme. We also show how to implement the parameters. 4.1

Several Conditions

Parameters a and s: For the security reason, the values of a and s shall satisfy: a = |k/2|s + κ1 and s = k + κ2 , where k is a security parameter and both κ1 and κ2 are information leak parameters. We must set such that 1/2κ1 (resp. 1/2κ2 ) is interactive for the security parameter k. For implementation, we should take κ1 (resp. κ2 ) greater than 80 bits. Consequently, a = 240 and s = 160 are reliable values. Parameter O: Let us consider the attack which an adversary computes O only from the information of the public-key (n, g). We can see the algorithms to extract O, such as Pollard lambda method in [17] and the baby-step giant-step

118

Takeshi Okamoto, Hirofumi Katsuno, and Eiji Okamoto

method in [10]. One may say that the former is better than √ the latter since it has same computational complexity (exponential-time: O( O)) but does not need large memory. The size of O shall be set up such that the above algorithms cannot apply for the security parameter k. For implementation, we should take O greater than 160 bits for the security reason.

4.2

Implementation Notes

Choice of p, q and g: We describe how to ﬁnd p, q and an asymmetric basis g in Z∗n . Step1 Pick up two primes p = 2p p + 1 and q = 2q q + 1 such that p and q are also primes, and p and q are odd numbers. (p−1)/p Step2 Choose αp ∈ Z∗p satisfying gp = αp = 1 mod p. In the same way, choose αq ∈ Z∗q satisfying αq = q − 1 mod q, αq

(q−1)/2

(q−1)/2q αq

= 1 mod q and

gq = = 1 mod q. Step3 Compute n = pq and g = q(q −1 mod p)gp +p(p−1 mod q)gq mod n. In Step3, g is computed by using the technique of Chinese Reminder Theorem (CRT). Note that Ordp (g) = p and Ordq (g) = 2q . Therefore, Ordn (g) = lcm(p , 2q ) = 2p q . Choice of H: If H is an ideal hash function (i.e., random oracle), then the proposed signature scheme would be secure under the meaning of the description in [16]. Since such a random function does not exist in the real world, in implementation, we are recommended to adopt MD5 by [20] or SHA-1 by [12], each of which is designed so that the algorithm can be a collision intractable hash function [3].

5

Further Discussions

In this section, we ﬁrst introduce the optimized signature scheme. We next evaluate the performance.

5.1

Optimized Scheme

As for the signature scheme in Section 2, we can diminish the size of the signature. Consequently, communication load is more eﬃcient than before. When we have two parameters e and y, the parameter x can be generated by computing k viei mod n. Therefore, the signature x is eliminated like conventional x = g y Πi=1 generic signature schemes such as Schnorr [21] or Guillou-Quisquater [7]. In this case, the signature for m consists of (e, y).

A Fast Signature Scheme Based on New On-line Computation

5.2

119

Performance Evaluation

We evaluate the eﬃciency of our signature scheme by comparing existing on the ﬂy signatures. Table 1 gives the performance of various schemes, such as FFS, GPS, PS, OTM1 and OTM2, including ours. Table 1 show that our signature scheme is quite eﬃcient from both the computational cost and the data size point of view. For all schemes, we set |n| = 1024 and optimize the size of signature using the technique of Section 5.1. For each schemes, the parameters are set up as follows. • Our scheme has a = 240 and s = 160 by taking k = 80 and |O| = 160. • FFS has k = 80. • GPS has |A| = 1184 and |B| = 80 by taking k = 1024. • PS has |A| = 656 and |B| = 80 by taking k = 513. • OTM1 has a = 104, b = 80 and c = 288 by taking k = 160. To set up the same condition as our scheme, in this scheme, n is a RSA modulus and g is an asymmetric basis in Z∗n . Furthermore, the size of public-key is optimized as follows. We regard actual public-key as (n, g), and z is computed by z = H (n, g), where H is a hash function H : {0, 1}∗ → {0, 1}c . • OTM2 has a = 224 and b = 248 by taking k = 160, κ1 = 64 and κ2 = 24.

6

Conclusion

In this paper, we have proposed an eﬃcient and fast signature scheme, which is derived from a three-pass identiﬁcation scheme. As a result, the following remarkable advantages are given in our scheme. • The structure in the on-line phase is very simple: our scheme requires only hashing and addition. • In the following, minimal on-line computation is achieved. • Transmitted data size is small. We believe that our scheme would contribute to the cryptographic community. We have also shown that our signature scheme are existentially unforgeable against any polynomial-time adversaries that can execute adaptive chosen message attack in the random oracle model. In this case, the underlying number theoretic problem is the integer factoring problem with an asymmetric basis g for an RSA modulus n.

References [1] Paul Barrett. Implementing the rivest shamir and adleman public key encryption algorithm on a standard digital signal processor. In A.M. Odlyzko, editor, Proc. CRYPTO 86, pages 311–323. Springer-Verlag, 1987. Lecture Notes in Computer Science No. 263. [2] M. Bellare and P. Rogaway. Random oracles are practical: A paradigm for designing eﬃcient protocols. In Proc. of 1st ACM Conference on Computer and Communications Security, pages 62–73. Springer-Verlag, 1993.

120

Takeshi Okamoto, Hirofumi Katsuno, and Eiji Okamoto

Table 1. Performance of signature schemes.

Scheme

Oﬀ-line Underlying comput.∗2 problem (×M )

On-line comput.

Veri. (×M )

Public Secret Sig. key key (bits) (bits) (bits)

factoring∗1

61

40 times addition (160 bits)

378

83968 12800 360

factoring

1

41M

42

92944 81920 1104

Discrete log. (modulo n)

381

80 × 1024

1796

3072

1024

1264

factoring

381

80 × 512

1656

1024

513

736

OTM1 [13]

factoring∗1

61

80 × 160

552

2048

160

384

OTM2 [14]

factoring∗1

61

248 mod 160 372

2048

160

472

Our scheme

FFS [4]

GPS [18]

PS [19]

Abbreviation: • M represents the computational cost for one multiplication under a 1024bit modulus. • γ × δ represents the computational cost for multiplication of an γ-bit number and a δ-bit number on . • α mod β represents the computational cost for modular reduction of an α-bit number and a β-bit number modulus. Some Notes: • For all schemes in the above table, we set up the parameter under the line of the one-key attack scenario in [19]. • For respective computational cost, a primitive arithmetic of binary methods [9] are used, e.g. amount of work for g α mod n is 32 |α|M if |n| = 1024. Of course there exist more sophisticated techniques which reduce the amount of computational work. However we think they estimate the actual performance without loss of generosity. • The factoring problem of “∗1” is diﬀerent from usual integer factoring problem. This is a problem on input RSA modulus n and the asymmetric basis g, outputs the factor of n. • In the column of “∗2”, the signer uses the technique of CRT. In this case, the signer must secretly have the factors of n, p and q.

A Fast Signature Scheme Based on New On-line Computation

121

[3] I. B. Damg˚ ard. Collision free hash functions and public key signature schemes. In David Chaum and Wyn L. Price, editors, Advances in Cryptology - EuroCrypt ’87, pages 203–216, Berlin, 1987. Springer-Verlag. Lecture Notes in Computer Science Volume 304. [4] U. Feige, A. Fiat, and A. Shamir. Zero-knowledge proofs of identity. Journal of Cryptology, 1:77–95, 1988. [5] A. Fiat and A. Shamir. How to prove yourself: practical solutions of identiﬁcation and signature problems. In Crypto ’86, LNCS No. 263, pages 186–194. SpringerVerlag, 1987. [6] M. Giraut. Self-certiﬁed public keys. In Eurocrypt ’91, LNCS No. 547, pages 490–497. Springer-Verlag, 1992. [7] L. C. Guillou and J. J. Quisquater. A “paradoxal” identity-based signature scheme resulting from zero-knowledge. In Crypto ’88, LNCS No. 403, pages 216–231. Springer-Verlag, 1989. [8] A. Karatsuba and Yu Ofman. Multiplication of multidigit numbers on automata. Doklady Akademii Nauk SSSR, 145(2):293–294, 1962. [9] D. E. Knuth. Seminumerical Algorithms, volume 2 of The Art of Computer Programming. Addison-Wesley, 1998. Third edition. [10] D. E. Knuth. Sorting and Searching, volume 3 of The Art of Computer Programming. Addison-Wesley, 1998. Second edition. [11] P. Montgomery. Modular multiplication without trial division. Mathematics of Computation, 44:519–521, 1985. [12] National Institute of Standards and Technology (NIST). Secure hash standard(SHS). In Federal Information Processing Standards, April 1995. [13] T. Okamoto, M. Tada, and A. Miyaji. Proposal of eﬃcient signature schemes based on factoring. In Trans. IPSJ, Vol.42 No. 8, pages 2123–2133, 2001 (in Japanese). [14] T. Okamoto, M. Tada, and A. Miyaji. An improved fast signature scheme without on-line multiplication. In Financial Cryptography ’02. Springer-Verlag, 2002 (To appear). [15] D. Poincheval. The composite discrete logarithm and secure authentication. In PKC ’00, LNCS No. 1751, pages 113–128. Springer-Verlag, 2000. [16] D. Poincheval and J. Stern. Security arguments for digital signatures and blind signatures. Journal of Cryptology, 2000. [17] J. Pollard. Monte carlo methods for index computation ( mod p). volume 32, pages 918–924. Mathematics of Computation, 1978. [18] G. Poupard and J. Stern. Security analysis of a practical “on the ﬂy” authentication and signature generation. In Eurocrypt ’98, LNCS No. 1403, pages 422–436. Springer-Verlag, 1998. [19] G. Poupard and J. Stern. On the ﬂy signatures based on factoring. In Proc. of the 6th CCS, pages 48–57. ACM Press, 1999. [20] Ronald L. Rivest. The MD5 message-digest algorithm. Internet Request for Comments, April 1992. RFC 1321. [21] C. P. Schnorr. Eﬃcient identiﬁcation and signatures for smart cards. pages 239– 252. Springer, 1990. Lecture Notes in Computer Science No. 435.

Distributed RSA Signature Schemes for General Access Structures Javier Herranz, Carles Padr´o, and Germ´ an S´ aez Dept. Matem` atica Aplicada IV, Universitat Polit`ecnica de Catalunya C. Jordi Girona, 1-3, M` odul C3, Campus Nord, 08034-Barcelona, Spain {jherranz,matcpl,german}@mat.upc.es

Abstract. In a distributed digital signature scheme, a set of participants shares a secret information that allows them to jointly compute a valid signature for any given message. These systems are said to be robust if they can tolerate the presence of some dishonest players. Up to now, most of the proposed schemes consider only threshold structures: the system tolerates the presence of less than t corrupted players, and the subsets of players who can sign a message are those with k or more players, where k ≥ t. We propose a framework which is more general than the threshold one, considering a general access structure of players allowed to sign and a general family of dishonest players that the scheme can tolerate. If these structures satisfy some conditions, we can design a distributed and secure RSA signature scheme for this setting. Our construction generalizes the threshold scheme of Shoup [23]. We also present some examples of nonthreshold structures for which our scheme can be eﬃciently applied.

1

Introduction

The area of distributed cryptography, which is generally known as threshold cryptography, has been very active in the last years. The reason of this liveliness is the increasing number of situations in which an operation has to be made or supervised by more than a single party: transactions between companies, distributed certiﬁcation authorities, distributed key generation, etc. In particular, many distributed digital signature schemes have been proposed. In these schemes, some participants share a secret information that enables some subsets of them (those in the access structure) to compute a valid signature. There are several advantages of collective digital signatures with respect to individual ones. First, security increases because an adversary must corrupt a group of players to obtain some useful secret information instead of only an individual one. A second advantage is a reliability increase because if some participants have technical problems, for example, the rest of players can still compute a valid signature.

This work was partially supported by Spanish Ministerio de Ciencia y Tecnolog´ıa under project TIC 2000-1044.

C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 122–136, 2003. c Springer-Verlag Berlin Heidelberg 2003

Distributed RSA Signature Schemes for General Access Structures

123

In order to formalize these aspects, the situation is modeled by an external adversary who can corrupt some subsets of dishonest players (those in the adversary structure). Participants can be dishonest in two diﬀerent ways: they can try to obtain the secret information necessary to compute signatures without the consent of the honest players but executing the protocol correctly; or they can also try to boycott the process forging their shares of secret information. To tolerate these situations, the scheme must have the properties of unforgeability and robustness. A scheme is said to be unforgeable if any subset of dishonest players cannot obtain any information that allows them to compute a signature without the collaboration of any honest party. A scheme is said to be robust if it can detect lying participants, and they cannot avoid the honest players to generate a valid signature. It is also desirable that the resulting signature is a standard one; that is, the receiver of the signature cannot distinguish if it has been generated in a distributed way or not. Previous work. Early proposals of distributed digital signature schemes based on discrete logarithm signatures were made in [9], but they were not robust and required the presence of a trusted party. The proposals in [19] and [17] avoid the need of a trusted party, but neither do they consider the question of robustness. Finally, in [15] an optimal and robust scheme is proposed which does not require a trusted party. Recently, the threshold version of Schnorr’s signature scheme has been proposed in [26]. With respect to distributed schemes based on RSA signatures [21], ﬁrst attempts were made in [11,8]; they worked in a speciﬁc extension of a polynomial ring, and this fact leads to scheme that require either interaction or very large shares. In [14] a complete and robust (but still ineﬃcient) version of the proposal in [8] was presented. The proposals in [12,20,5] presented robust schemes that are besides proactive (they tolerate attacks performed by a non-static adversary), but with a high computational complexity. Shoup [23] proposes a robust, non-interactive, eﬃcient and conceptually simple scheme. It requires a dealer to generate the keys and distribute the shares among the players. Finally, in [7,10] we can ﬁnd robust schemes in which the presence of a dealer is not necessary (based on works [2,4,13]). A diﬀerent approach to design distributed RSA signatures consists of using a black-box secret sharing scheme (see [6], for example). Almost all the proposals we have mentioned have a characteristic in common: the adversary structure is a threshold one, that is, the scheme tolerates the presence of up to t corrupted players. The most logical solution then, in order to get unforgeability, is to deﬁne the access structure (those subsets of players who will be able to generate a signature) as a threshold structure, too. In this case, it must contain subsets of at least t + 1 players. We must remark here that the threshold Schnorr’s signature scheme in [26] is the only one designed to work with general access structures. Our contribution. We propose a framework that is more general than the threshold one, in the sense that we consider situations in which not all partici-

124

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

pants have the same power or the same susceptibility to be corrupted. Therefore, we consider a general access structure of players that are allowed to sign a message, and a general family of subsets of dishonest players that the system can tolerate (that is, a general adversary structure). We ﬁnd necessary conditions for these structures to reach robustness and unforgeability in a distributed signature scheme. We consider access structures that can be realized with a linear secret sharing scheme over the rationals which veriﬁes a certain algebraic property. For these access structures, we construct a distributed RSA signature scheme, inspired by the threshold scheme of Shoup [23]. The eﬃciency of the resulting scheme will depend on the complexity of the linear secret sharing scheme that realizes the access structure over the rationals. There is also another value which depends on the secret sharing scheme and which has an eﬀect on the eﬃciency of the distributed RSA signature scheme. We give some examples of access structures that are not threshold and for which our method provides an eﬃcient distributed signature scheme. Organization of the paper. In Section 2, we explain some basics about secret sharing schemes that we will use in the rest of the paper. In Section 3, we set a more general framework for the access and adversary structures. In Section 4, we explain our proposal of distributed signature scheme and prove its security. In Section 5 we give some examples of non-threshold access structures for which our scheme is quite eﬃciently applicable. Finally, in Section 6 we sum up the contribution of our work and some problems which remain open in the area of distributed signature schemes.

2

Secret Sharing Schemes

Secret sharing schemes are used as an important component in distributed cryptography. In these schemes, a secret value is shared among the participants in a set P in such a way that only qualiﬁed subsets of P can reconstruct the secret from their shares. A secret sharing scheme is said to be perfect if the subsets that are not qualiﬁed to reconstruct the secret have absolutely no information on it. An access structure Γ on a ﬁnite set P = {1, . . . , } of participants is the family of subsets of P that are authorized to reconstruct the secret. The access structure has to be monotone, that is, if A1 ∈ Γ and A1 ⊂ A2 ⊂ P, then A2 ∈ Γ . Therefore, an access structure can be determined by the family of minimal authorized subsets, Γ0 ⊂ Γ , which is called the basis of Γ . A secret sharing scheme is said to be ideal if the length of the secret is equal to the length of the share of every participant. There are access structures that cannot be realized by an ideal secret sharing scheme; however, there are interesting families of structures which can be realized by an ideal scheme. Linear secret sharing schemes are very useful in distributed protocols, because the secret can be recovered as a linear combination of the shares of a qual-

Distributed RSA Signature Schemes for General Access Structures

125

iﬁed subset. Simmons, Jackson and Martin [25] proved that any access structure Γ can be realized by a linear secret sharing scheme. Vector space secret sharing schemes are a particular ideal case of linear ones. For simplicity, we consider in this paper vector space secret sharing schemes, but the results can be easily extended to the more general case of linear schemes. The vector space construction was introduced by Brickell in [3]. Let Γ be an access structure on a set of participants P and D ∈ / P a special participant called the dealer. Γ is said to be a vector space access structure if, for some vector space E = K r over a ﬁnite ﬁeld K, there exists a function ψ : P ∪ {D} −→ E such that A ∈ Γ if and only if the vector ψ(D) can be expressed as a linear combination of the vectors in the set ψ(A) = {ψ(i)|i ∈ A}. If Γ is a vector space access structure, we can construct an ideal secret sharing scheme for Γ with set of secrets K: given a secret value k ∈ K, the dealer takes a random element w ∈ E, such that w · ψ(D) = k and sends to the participant i ∈ P his share si = w·ψ(i) ∈ K. A scheme constructed in this way is called a vector space secret sharing scheme. Let A ∈ Γ be an authorized subset; then, ψ(D) = i∈A cA i ψ(i), ∈ K. In order to recover the secret, the players of A compute for some cA i i∈A

cA i si =

i∈A

cA i w · ψ(i) = w ·

cA i ψ(i) = w · ψ(D) = k

i∈A

Shamir’s secret sharing scheme was introduced in [22] and it realizes threshold access structures, that is Γ = {A ⊂ P : |A| ≥ t}, for some threshold t. It is based on polynomial interpolation and can be seen as a particular case of vector space secret sharing schemes, taking E = K t and ψ deﬁned by ψ(D) = (1, 0, . . . , 0) and ψ(i) = (1, i, i2 , . . . , it−1 ). Most of the distributed signature schemes proposed until now consider only threshold structures and are based on Shamir’s secret sharing scheme. It is worth noting that linear secret sharing schemes can be thought as vector space ones where each participant can be associated with more than one vector.

3

Our Approach for General Structures

In this Section, we explain the general scenario where our distributed signature scheme will run, and some aspects related to general access structure that will be important to design our scheme. Remember that in the standard RSA signature scheme, the signer generates n = pq, where p and q are two large prime numbers (note that then φ(n) = (p − 1)(q − 1)), a value d ∈ Z∗φ(n) and its inverse e = d−1 mod φ(n). The signer makes public the pair (n, e). In order to sign a message M , the signer hashes the message into a value x = h(M ) ∈ Z∗n , and then computes y = xd mod n. The recipient of the message veriﬁes the correctness of the signature y by checking that y e = h(M ) mod n.

126

3.1

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

A General Scenario

Let P = {1, . . . , } be a set of participants. For any family B ⊂ 2P of subsets of P, we denote B = 2P \B and B c = {P\B : B ∈ B}. Now the tolerated subsets of dishonest players are not necessarily deﬁned according to their cardinality. We have a general adversary structure, A ⊂ 2P , which must be monotone decreasing: if B1 ∈ A is a tolerated subset of dishonest players, then B2 ∈ A for all B2 ⊂ B1 . Analogously to the case of monotone increasing structures, we can deﬁne the basis A0 of the adversary structure as / A, for all B ⊃ B}. the maximal subsets of A, that is, A0 = {B ∈ A | B ∈ On the other hand, we have the monotone increasing access structure Γ , that is, the collection of subsets of participants that will be able to generate a valid signature. If we want to achieve unforgeability, any subset in A cannot be in Γ , that is A ∩ Γ = ∅. This condition is the same as Γ ⊂ A, or equivalently, A ⊂ Γ , where Γ is the set of non-authorized subsets. Since Γ is monotone decreasing, we can consider the family (Γ )0 ⊂ Γ of maximal non-authorized subsets. To achieve robustness, for any B ∈ A, the subset P\B formed by the rest of players of P must be in Γ . In other words Ac ⊂ Γ . From these two conditions, it must be Ac ∩ A = ∅. We recall (see [18]) that a monotone decreasing structure A ⊂ 2P is said to be Q2 in P if Ac ⊂ A or equivalently, if there are not two subsets in A that cover all the set P. In the threshold case, Q2 condition is ≥ 2t + 1. In conclusion, both structures A and Γ must satisfy Ac ⊂ Γ ⊂ A. We will construct an unforgeable and robust distributed signature scheme for this scenario. 3.2

Previous Computations

Let A ⊂ 2P and Γ ⊂ 2P be adversary and access structures verifying Ac ⊂ Γ ⊂ A. In RSA distributed signature schemes, if n = pq is the public modulus, the secret d to be shared will belong to a group Zφ(n) (or Zm in our scheme, where φ(n) = 4m) that must remain secret to the participants. One possible approach to solve this problem is to use a black-box secret sharing scheme, which allows to share secrets belonging to any (possibly unknown for the participants) Abelian group. However, eﬃcient constructions of such schemes are only known for the threshold case (see [6]). Our approach, following the idea introduced by Shoup in [23], consists of modifying the framework of standard linear secret sharing schemes (in particular, we will consider the vector space case, for simplicity) in order to adapt them to our needs. We say that a function ψ : P ∪ {D} −→ Zr realizes Γ over the rationals A when A ∈ Γ if and only if there exists {cA i }i∈A , with ci ∈ Q, such that ψ(D) = A i∈A ci ψ(i). Furthermore, we say that such a function ψ is A-independent if for all subset of players B in the adversary structure A, the diﬀerent vectors in {ψ(j)}j∈B are linearly independent.

Distributed RSA Signature Schemes for General Access Structures

127

If a dealer would use this function, working in the corresponding group Zm , to distribute shares of the secret key d, then the following problem would appear: if an authorized subset would like to compute a valid RSA signature h(M )d mod n of a message M (where h is a hash function), its members would have to recover the secret key d in the exponent of an expression in Zn . If the coeﬃcients of the combination that allows to compute d from their shares were rational, this step could not be eﬃciently done, because the participants would not be able to compute roots modulo n. The solution is to ﬁnd a factor ∆ that cancels all these denominators in the coeﬃcients, for all the authorized subsets of players. Each player will multiply his share by this public factor ∆. Note that, then, an authorized subset will obtain in the exponent a multiple of the secret key d. But this fact does not aﬀect the computation of a valid RSA signature, as we will see later. For the security proofs of the resulting scheme, we also need that the factor ∆ cancels the denominators in the coeﬃcients of the following linear combinations: the vector of a player i written as a combination of the vector of the dealer and the vectors corresponding to a subset of players B ∈ (Γ )0 which does not contain player i. Here we explain a method to obtain such a public value ∆. This method is in general ineﬃcient. However, there can be access structures for which an appropriate ∆ can be found in a more eﬃcient way. The general method is the following. For each minimal authorized subset A ∈ Γ0 , we will associate to it a factor A MA such that c˜A i = MA ci is an integer, for all i ∈ A. This factor MA is the determinant of some non-zero minor, with maximal order, of the matrix GA whose columns are the vectors {ψ(i)}i∈A . We deﬁne M inA = {non-zero minors of matrix GA with maximal order}. Then we deﬁne the value MA in the following way: MA =

lcm

gA ∈MinA

{| det gA |}

It is clear that this factor MA cancels all the denominators in all the possible solutions {cA i }i∈A . But we are looking for a factor that cancels all the denominators, for all the minimal authorized subsets A ∈ Γ0 . Hence we deﬁne ∆1 = lcm {MA } A∈Γ0

With respect to the second condition that the value ∆ must satisfy, we have to consider systems of equations with the following form: the columns of the matrix of this system are the vectors ψ(D) and {ψ(j)}j∈B , where B ∈ (Γ )0 is a maximal non-authorized subset. We note this matrix GD,B . As before, we deﬁne M inD,B = {non-zero minors of matrix GD,B with maximal order}, and then the values MD,B =

lcm

gD,B ∈MinB

{| det gD,B |} and ∆2 = lcm {MD,B }. B∈(Γ )0

128

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

Finally, the factor ∆ is ∆ = lcm{∆1 , ∆2 }. In Section 5 there is some example which clariﬁes this way of computing the value ∆.

4

The Scheme

Let A and Γ be adversary and access structures deﬁned in a set of participants P = {1, . . . , }, as explained in Section 3.1; that is, Ac ⊂ Γ ⊂ A. Suppose we have an appropriate function ψ : P ∪ {D} −→ Zr that realizes the access structure Γ over the rationals, and that is A-independent. Note that using the technique presented by Simmons, Jackson and Martin in [25], we can ﬁnd for any access structure Γ an A-independent assignment of integer vectors to the dealer and to the players, where A = Γ . So the scheme that we propose can be used with any access structure. However, in some cases the construction of [25] can result in a very ineﬃcient scheme, in terms of the number of vectors (and so the number of shares) assigned to each participant. 4.1

The Proposal

If these conditions hold, we can construct a distributed RSA signature scheme secure against the action of an adversary who corrupts players in any subset of A, and in which participation of players of some subset of Γ is required in order to compute a valid RSA signature. Key generation. The access structure Γ , the function ψ and the value ∆ (that depends only on ψ) are public. The dealer chooses p = 2p + 1 and q = 2q + 1 in such a way that p, q, p and q are primes large enough (in particular, p and q must be larger than ∆ and larger than the absolute values of all the components of ψ(D)); we deﬁne m = p q . The value n = pq is public (note that m and so φ(n) = 4m remain secret to the participants). The dealer chooses the public exponent e as a positive odd integer such that gcd(e, m∆) = 1. He also computes d = e−1 mod m. Generation of the shares. 1. The dealer chooses a random vector w ∈ (Zm )r , such that w · ψ(D) = d mod m. 2. He sends to each player his secret share si = w · ψ(i) mod m, for 1 ≤ i ≤ . 3. The dealer also chooses a random v ∈ Qn , where Qn is the subgroup of squares in Z∗n , and computes vi = v si mod n, for 1 ≤ i ≤ . He makes public the veriﬁcation keys v and {vi }1≤i≤ . Distributed generation of an RSA signature. If the players want to sign x = h(M ) ∈ Z∗n , where M is a message and h is a hash function, the process is the following:

Distributed RSA Signature Schemes for General Access Structures

129

1. Each player i, for 1 ≤ i ≤ , computes and broadcasts his signature share xi = x2∆si mod n. He also makes public a “proof of correctness” of this share, which is a non-interactive proof of knowledge of a value si such that the discrete logarithm of x2i to the base x4∆ is the same as the discrete logarithm of vi to the base v and is equal to si . This proof must not give any information about the value si (see [23] for the details). 2. Each player j, for 1 ≤ j ≤ , veriﬁes the proof of correctness of player i, using the veriﬁcation keys v and {vi }1≤i≤ , and publicly complains if the proof is not correct. 3. Players who get complaints from an authorized subset are rejected. 4. Once the dishonest players have been rejected, and because of the restriction Ac ⊂ Γ , there is at least one authorized subset A ∈ Γ in which all the signature shares are valid. We can consider, for simplicity, that A is a minimal authorized subset, that is, A ∈ Γ0 . 5. Each player in A can obtain rational numbers {cA i }i∈A such that ψ(D) = A c ψ(i); because of the deﬁnition of ∆, we have that the values c˜A i = i∈A i 2˜ cA A 4∆2 d i ∆ci are integers, and so the users can compute ω = i∈A xi = x mod n. 6. Since gcd(e, m∆) = 1, we have that gcd(e, 4∆2 ) = 1 because e is odd. Then each player in A can obtain integers a and b such that 4∆2 a + eb = 1, using the Euclidian algorithm. 7. The signature for the message x is y = ω a xb . In eﬀect, y e = ω ea xbe = 2 x4∆ a+eb = x mod n. 4.2

Security Analysis

First we explain why we require the function ψ to be A-independent. Suppose that there exists some subset B ∈ A of corruptible players such that the vectors in the set {ψ(j)}j∈B are linearly dependent over the rationals. If we use the scheme explained in Section 4.1, then each player of B will receive the share sj = w · ψ(j) mod m. If there exists a non-trivial linear combination of the vectors in {ψ(j)}j∈B that is equal to zero, over the rationals, then the same combination applied to the shares {sj }j∈B will be equal to zero, in Zm . That is, players in B could obtain a multiple of m, and so break the system. Now we prove that the way in which the dealer distributes the shares si among the players is perfectly secure, if we require the primes p and q to be larger than the value ∆. In eﬀect, let B = {j1 , . . . , js } ∈ A be a corruptible subset of players, and let {si }1≤i≤ be a sharing of some secret d ∈ Zm , obtained with a random vector w ∈ (Zm )r . Because of the properties satisﬁed by the value ∆ (in particular, by ∆2 ), we have that the system of equations    k  1 ∆ · · · ψ(D) · · · ..  0  · · · ψ(j1 ) · · ·     .       .. .  .. ..    .  =   ..   .  . .  ..  0 · · · ψ(js ) · · · kr

130

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

has at least an integer solution k ∈ Zr . Since p and q are larger than ∆, we have gcd(∆, m) = 1, and so there exist integers α and β such that α∆ + βm = 1. For every possible value of the secret d ∈ Zm and for every solution k ∈ Zr of the system above, consider the vector w = w + (d − d)αk reduced modulo m. We have then that the vector w ∈ (Zm )r satisﬁes w · ψ(D) = (w + (d − d)αk) · ψ(D) = d + (d − d)α∆ = d mod m and w · ψ(j) = (w + (d − d)αk) · ψ(j) = sj mod m, for all j ∈ B. So each possible secret d ∈ Zm is equally likely, even if the shares {sj }j∈B are known. Therefore, players in B do not obtain any information about the shared secret from their shares. To prove the security of the distributed signature scheme, we follow the ideas that Shoup uses in his threshold scheme [23]. The idea is to prove that the scheme is simulatable, and then to use this fact to reduce the security of the distributed scheme to the security of standard RSA signature scheme [21]. Definition 1 A distributed signature scheme is said to be simulatable if, for any eﬃcient (polynomial time) adversary, there exists an eﬃcient algorithm Sim = (Sim1 , Sim2 ) such that: 1. Sim1 takes as input the public key of the scheme and simulates the view of the adversary on the execution of this key generation phase. 2. Sim2 takes as input the public key of the scheme, the transcript of Sim1 , a message and its signature, and simulates the view of the adversary on the execution of the distributed generation of this signature. This deﬁnition has been taken from [14], although it is quite standard. The algorithms Sim1 and Sim2 can use the public information related to the access structure; for example, the threshold t in a threshold scheme, or the function ψ and the value ∆ in a more general case. We can see this information as a part of the public key. Proposition 1 Our distributed signature scheme is simulatable, in the random oracle model [1]. Proof. We show how to construct an algorithm that simulates the view of an adversary during a real execution of the protocol. We ﬁrst construct Sim1 . The input of this algorithm is a public key (n, e), along with the publicly known access structure Γ , the function ψ : P ∪ {D} −→ Zr realizing Γ over the rationals, and the value ∆. Let B ∈ A be the set of players corrupted by the adversary. Because of the necessary combinatorial condition A ⊂ Γ , there exists a maximal non-authorized subset B ∈ (Γ )0 such that B ⊂ B . The real share of a player j in B is sj = w · ψ(j) mod m, where w is a random vector in (Zm )r . To simulate these r ˜ in (Zm ˜ = n/4 − 1. Then, shares, Sim1 chooses a random vector w ˜ ) , where m it computes s˜j = w ˜ · ψ(j) mod m, ˜ for all j ∈ B . The values {˜ sj }j∈B are the output of Sim1 ; since the statistical distance between the uniform distribution on {0, . . . , m} and the uniform distribution on

Distributed RSA Signature Schemes for General Access Structures

131

{0, . . . , m} ˜ is O(n−1/2 ), we can deduce that the distribution of the real values {sj }j∈B and the distribution of the simulated values {˜ sj }j∈B are computationally indistinguishable, as desired. Since the real distribution of the shares {sj }j∈B is perfectly secure, so it is the distribution of the simulated shares. Now we describe Sim2 . The input of this algorithm will be the public key (n, e) of the scheme, the transcript of Sim1 (in particular, {˜ sj }j∈B ), a message x = h(M ) and its signature y. Sim2 computes x˜j = x2∆˜sj , for all j ∈ B . Given that B ∈ (Γ )0 , we know that B ∪ {i} ∈ Γ , for all i ∈ P\B ; this condition is equivalent, in Q, to ψ(i) ∈ ψ(D), {ψ(j)}j∈B . That is, there exist rational numbers f0B ,i , {fjB ,i }j∈B such that B ,i fj ψ(j) ψ(i) = f0B ,i ψ(D) + j∈B

Due to the second condition that we have imposed to the value ∆, the values ∆f0B ,i and {∆fjB ,i }j∈B are all integers. Therefore, the algorithm Sim2 can compute, for all i ∈ P\B , the simulated signature shares x ˜i = y

2(∆f0B

,i

+ e

j∈B

∆fjB

,i

s ˜j )

mod n .

Using the same technique, Sim2 can also generate the values v˜, v˜1 , . . . , v˜ , computationally indistinguishable from the veriﬁcation keys that the adversary would see on a real execution of the protocol. Zero-knowledge simulatability of the “proofs of correctness” can be achieved exactly in the same way as in Shoup’s scheme (see [23] for the details), in the random oracle model. Theorem 1 Let A ⊂ 2P and Γ ⊂ 2P be adversary and access structures verifying Ac ⊂ Γ ⊂ A. Let ψ : P ∪ {D} −→ Zr be an A-independent function realizing Γ over the rationals. Then our distributed signature scheme is secure (robust and unforgeable under a chosen message attack) in the random oracle model [1], assuming that the standard RSA signature scheme is secure. Proof. The scheme is obviously robust, due to the requirements on the structures Γ and A. The proof of soundness for the “proofs of correctness”, in the random oracle model, is the same as in the threshold case (see [23]), because this part of the protocol is identical. Suppose now the distributed scheme to be forgeable under chosen message attacks. That is, there exists an eﬃcient adversary ADist that chooses some messages, executes the distributed signature protocol for them (obtaining their signatures, all the broadcast information and all the secret information of players corrupted by the adversary), and then is able to compute a valid signature for a message that has not been signed before. In this case, we could use this algorithm to construct a successful chosen message attack ARSA against standard RSA signature scheme in the following way:

132

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

1. ARSA runs Sim1 with input the same public key used by ADist , to obtain the view of ADist on an execution of the key generation phase. 2. For each message chosen by ADist to be signed during its attack, ARSA executes the standard RSA signature scheme and obtains its signature (ARSA is allowed to do this, by deﬁnition of chosen message attack [16]); then ARSA executes Sim2 with input the public key, the chosen message and its signature, and the transcript of Sim1 , and thus obtains the view of ADist on the executions of the distributed signature protocol. 3. ARSA can use this view to run ADist and get a valid signature for a message non signed before. But such an attack against standard RSA signatures is assumed to be computationally infeasible, in the random oracle model, so we conclude that our ﬁrst assumption was wrong; that is, the distributed signature scheme is unforgeable under chosen message attacks.

5

Examples

Shoup’s scheme [23] can be recovered as a particular case of our proposal (Section 4), by considering the structures Γ = {A ⊂ P : |A| ≥ t} and A = Γ = {B ⊂ P : |B| < t}. Following the idea of Shamir’s threshold secret sharing scheme, the function that realizes Γ over the integers is deﬁned by ψ(D) = (1, 0, . . . , 0) ∈ Zt and ψ(i) = (1, i, i2 , ..., it−1 ), for all participant i ∈ P = {1, 2, . . . , }. It is easy to see that this function is A-independent. Furthermore, the factor ∆ = ! satisﬁes the required conditions for it. It is worth noting that our general method for computing ∆, applied to threshold structures, results in a value (satisfying the required conditions) which is larger than !. So it is an example that there can be more eﬃcient ways to compute an appropriate value ∆ than the one explained in Section 3.2. However, this method always runs. We show in this section some examples of non-threshold access structures Γ that can be realized over the rationals by vector space secret sharing schemes whose assignments of vectors are A-independent, where A is the adversary structure the scheme is secure against, satisfying Ac ⊂ Γ ⊂ A. Example 1. Consider a set of ﬁve participants, P = {1, 2, 3, 4, 5}. Any subset formed by three participants will be able to sign a message. Furthermore, the participants 1 and 2 have more power than the rest, and they can compute valid signatures if they agree. The corresponding access structure Γ is deﬁned by its basis Γ0 = { {1, 2}, {1, 3, 4}, {1, 3, 5}, {1, 4, 5}, {2, 3, 4}, {2, 3, 5}, {2, 4, 5}, {3, 4, 5} } The adversary structure can be deﬁned, for example, as the family of nonauthorized subsets. Therefore, it is determined by the basis A0 = (Γ )0 = { {1, 3}, {1, 4}, {1, 5}, {2, 3}, {2, 4}, {2, 5}, {3, 4}, {3, 5}, {4, 5} }

Distributed RSA Signature Schemes for General Access Structures

133

These structures satisfy the necessary conditions Ac ⊂ Γ ⊂ A. The access structure Γ can be realized over the rationals by a vector space secret sharing scheme deﬁned by the following vectors: ψ(D) = (1, 1, 0), ψ(1) = (1, 0, 0), ψ(2) = (0, 1, 0), ψ(3) = (0, 0, 1), ψ(4) = (1, 2, 1), ψ(5) = (2, 1, 1). The vectors of the ﬁve participants are pairwise linearly independent, so the function ψ is A-independent, and we can apply our construction. For the computation of the value ∆, we must ﬁrst consider authorized subsets in Γ0 . For example, if we consider the subset {1, 2}, with related vectors (1, 0, 0) and (0, 1, 0), then there is only one non-zero minor with maximal order, which is

1 0

0 1 = 1 . If we consider the authorized subset {3, 4, 5}, then there is only one non-zero minor with maximal order, which is the whole matrix formed by the three corresponding vectors:

0 0 1

1 2 1 = −3 .

2 1 1

Once all the subsets in Γ0 have been considered, one ﬁnds the value ∆1 = 6. Then we must consider maximal non-authorized subsets (those in A0 ) and study the matrix formed by the related vectors along with the vector of the dealer. For example, for the subset {4, 5}, the resulting matrix is   110 1 2 1 211 and the only non-zero minor with maximal order is the whole matrix, which has determinant equal to 2. Repeating this process with all the subsets in A0 , one ﬁnds the value ∆2 = 2. Therefore, our distributed signature scheme for this access structure runs with ∆ = 6. Note that this access structure can be seen as a composition of two threshold structures, and so we could apply directly the scheme of Shoup. However, in this case participants 1 and 2 would each receive two shares of the secret, and the value ∆ would be 5!, so the resulting scheme would be less eﬃcient. Now we give a simple (and not realistic) example of the functioning of our scheme for these structures. Suppose that the parameters of the scheme, generated by the dealer, are: p = 23, q = 29, p = 47 and q = 59. This implies m = 667 and n = 2773. Suppose that the public key is e = 355, and so the secret value d is d = 605. Then the dealer chooses a vector w ∈ Z3667 such that w · ψ(D) = 605 mod 667. For example, w = (300, 305, 250). The resulting shares for each participant are s1 = 300, s2 = 305, s3 = 250, s4 = 493 and s5 = 488. Suppose that the players want to sign a message M such that x = h(M ) = 12. Suppose that an attacker has corrupted players 2 and 5, and these players publish wrong partial signatures x2 and x5 . The honest players can detect this fact and reject players 2 and 5 from the protocol. The honest players broadcast

134

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

their correct partial signatures x1 = 122·6·300 mod 2773 = 2092, x3 = 196 and x4 = 296. For this authorized subset A = {1, 3, 4}, we have that ψ(D) = 12 ψ(1) − 1 1 1 A ˜A 1 = ∆c1 = 6 · 2 = 3, and analogously, 2 ψ(3) + 2 ψ(4). Therefore, we have c A A c˜3 = −3 and c˜4 = 3. Then the honest players can compute the value ω = 6 x61 x−6 3 x4 mod 2773 = 1384. We have 4∆2 = 144 and e = 355. Using the Euclidian algorithm, players obtain a = −106 and b = 43 such that 144a + 355b = 1. Then, the ﬁnal signature is y = ω a xb = 1384−106 1243 mod 2773 = 1687. In eﬀect, the veriﬁcation equation y e = 1687355 mod 2773 = 12 = h(M ) is satisﬁed. Example 2. Let us consider the so called multi-level access structure, introduced by Simmons [24]. There are diﬀerent levels l, where l = 1, . . . , L, and every player i is associated with some level l(i). We say that “player i is in level l(i)”. We note as Nl the number of players in level l. Players in lower levels have more power than players in upper levels. Namely, a set of players A is qualiﬁed if and only if A contains at least l players in level at most l, for some l ∈ {1, . . . , L}. That is, if A contains one player i in level 1, or two players i and j in levels 1 or 2, and so on. This access structure can be realized over the rationals. The appropriate assignment is described by Brickell [3]: ψ(D) = (1, 0, . . . , 0) ∈ Z L and for a player l(i)−1 , 0, . . . , 0), i in level l(i), the corresponding vector is ψ(i) = (1, xi , x2i , ..., xi for some integer xi . It is easy to see that the integers xi can be chosen in such a way that for any level l ∈ {1, . . . , L} and for any l players in level at most l, their vectors are linearly independent. This guarantees correctness and privacy, but it also implies that the function ψ is Γ -independent. Therefore, we can consider as the adversary structure all the family of non-authorized subsets, A = Γ . A suﬃcient condition to ensure that Ac ⊂ Γ ⊂ A holds is that Nl ≥ 2l − 1, for some level l = 1, . . . , L. Unfortunately, the value of ∆ will depend on the integers xi that we choose. Furthermore, it seems that there is not a more eﬃcient way to compute ∆ than by using the general method we explain in Section 3.2.

6

Conclusion and Open Problems

We present a distributed RSA digital signature scheme, generalizing the threshold scheme of Shoup in [23]. The scheme proposed by Shoup considers only threshold structures, meaning that subsets which can generate a signature as well as tolerated subsets of corrupted participants are those with a minimum or maximum number of players, respectively. We consider more general access and adversary structures, and state the combinatorial conditions that they must satisfy in order to reach robustness and unforgeability in a distributed signature scheme.

Distributed RSA Signature Schemes for General Access Structures

135

We construct a RSA distributed signature scheme for those access structures that can be realized by a linear secret sharing scheme over the rationals. The scheme is secure against an adversary modeled by a monotone decreasing structure A, if the assignment of vectors corresponding to the linear secret sharing scheme is A-independent. The eﬃciency of the scheme will depend on the complexity of this secret sharing scheme and on the size of the value ∆. Our construction provides, in fact, a deeper analysis of Shoup’s scheme. It would be very interesting to characterize those access structures Γ for which there exists a Γ -independent vector space function realizing Γ over the rationals. These structures will admit eﬃcient construction of RSA distributed signature schemes. For example, the work of Shoup [23] shows that threshold structures verify this condition. If we would want to avoid the presence of a trusted dealer in our construction, we should deal with the problem of the joint generation and distribution of RSA keys, which has been solved for threshold structures [2,4,13]. Finding a solution in the case of more general structures remains as an open problem.

Acknowledgments The authors wish to thank Vanesa Daza, Marta Serra and especially Serge Fehr for their helpful contribution to the realization of this work.

References 1. M. Bellare and P. Rogaway. Random oracles are practical: a paradigm for designing eﬃcient protocols. First ACM Conference on Computer and Communications Security, pp. 62–73 (1993). 2. D. Boneh and M. Franklin. Eﬃcient generation of shared RSA keys. Proceedings of Crypto’97, LNCS 1294, pp. 425–439 (1997). 3. E.F. Brickell. Some ideal secret sharing schemes. Journal of Combinatorial Mathematics and Combinatorial Computing, 9, pp. 105–113 (1989). 4. D. Catalano, R. Gennaro and S. Halevi. Computing inverses over a shared secret modulus. Proceedings of Eurocrypt’00, LNCS 1807, pp. 190–206 (2000). 5. R. Canetti, R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin. Adaptive security for threshold cryptosystems. Proceedings of Crypto’99, LNCS 1666, pp. 98–115 (1999). 6. R. Cramer and S. Fehr. Optimal black-box secret sharing over arbitrary Abelian groups. Proceedings of Crypto’02, LNCS 2442, pp. 272–287 (2002). 7. I. Damg˚ ard and M. Koprowski. Practical threshold RSA signatures without a trusted dealer. Proceedings of Eurocrypt’01, LNCS 2045, pp. 152–165 (2001). 8. A. De Santis, Y. Desmedt, Y. Frankel, and M. Yung. How to share a function securely. Proceedings of STOC’94, pp. 522–533 (1994). 9. Y. Desmedt and Y. Frankel. Threshold cryptosystems. Proceedings of Crypto’89, LNCS 435, pp. 307–315 (1989). 10. P.A. Fouque and J. Stern. Fully distributed threshold RSA under standard assumptions. Proceedings of Asiacrypt’01, LNCS 2248, pp. 310–330 (2001).

136

Javier Herranz, Carles Padr´ o, and Germ´ an S´ aez

11. Y. Frankel and Y. Desmedt. Parallel reliable threshold multisignature. Technical Report TR-92-04-02, University of Wisconsin-Milwaukee. (1992). 12. Y. Frankel, P. Gemmell, P. MacKenzie and M. Yung. Proactive RSA. Proceedings of Crypto’97, LNCS 1294, pp. 440–454 (1997). 13. Y. Frankel, P. MacKenzie and M. Yung. Robust eﬃcient distributed RSA-key generation. Proceedings of STOC’98, pp. 663–672 (1998). 14. R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin. Robust and eﬃcient sharing of RSA functions. Proceedings of Crypto’96, LNCS 1109, pp. 157–172 (1996). 15. R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin. Robust Threshold DSS signatures. Proceedings of Eurocrypt’96, LNCS 1070, pp. 354–371 (1996). 16. S. Goldwasser, S. Micali and R. Rivest. A digital signature scheme secure against adaptative chosen-message attacks. SIAM Journal of Computing, 17 (2), pp. 281– 308 (1988). 17. L. Harn. Group oriented (t, n) threshold digital signature scheme and digital multisignature. IEE Proceedings on Computation and Digital Technologies, 141 (5), pp. 307–313 (1994). 18. M. Hirt and U. Maurer. Complete characterization of adversaries tolerable in secure multi-party computation. Proceedings of PODC’97, pp. 25–34 (1997). 19. T. Pedersen. A threshold cryptosystem without a trusted party. Proceedings of Eurocrypt’91, LNCS 547, pp. 522–526 (1991). 20. T. Rabin. A simpliﬁed approach to threshold and proactive RSA. Proceedings of Crypto’98, LNCS 1462, pp. 89–104 (1998). 21. R.L. Rivest, A. Shamir and L. Adleman. A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 21, pp. 120–126 (1978). 22. A. Shamir. How to share a secret. Communications of the ACM, 22, pp. 612–613 (1979). 23. V. Shoup. Practical threshold signatures. Proceedings of Eurocrypt’00, LNCS 1807, pp. 207–220 (2000). 24. G. J. Simmons. How to (really) share a secret. Proceedings of Crypto’88, LNCS 403, pp. 390–448 (1988). 25. G. J. Simmons, W. Jackson and K. Martin. The geometry of secret sharing schemes. Bulletin of the ICA 1 pp. 71–88 (1991). 26. D.R. Stinson and R. Strobl. Provably secure distributed Schnorr signatures and a (t, n) threshold scheme for implicit certiﬁcates. Proceedings of ACISP’01, LNCS 2119, pp. 417–434 (2001).

Divisible Voting Scheme Natsuki Ishida1 , Shin’ichiro Matsuo2 , and Wakaha Ogata1 1

Tokyo Institute of Technology, 2-12-1 O-okayama, Meguro-ku, Tokyo 152-8552, Japan [email protected] 2 R&D Headquarters, NTT DATA Corporation, 1-21-2, Shinkawa, Chuo-ku, Tokyo 104-0033, Japan [email protected]

Abstract. Electronic voting is a prime application of cryptographic tools. Many researches are addressing election or conﬁdence voting in this area. We address a new type of voting scheme “Divisible Voting Scheme,” in which each voter has multiple ballots where the number of ballots can be diﬀerent among the voters. This type of voting is popular, however there is no secure protocol which achieves this type of voting. We ﬁrst deﬁne the divisible voting scheme and show naive protocols based on existing voting schemes. Then we propose two eﬃcient divisible voting schemes. The ﬁrst scheme uses multisets, the second scheme uses L-adic representation of number of ballots. The total cost for a voter is O(M 2 log(N )) in the ﬁrst scheme and O(M log(N )) in the second scheme where M is the number of candidates to vote for and N is the number of ballots for a voter. Keywords: Secure electronic voting and homomorphic encryption

1

Introduction

Background An electronic voting system is a prime application of cryptographic tools. Many researchers are studying on it, and many protocols have been proposed. Electronic voting system should assure voters’ privacy, as well as the correctness of the result. Most existing research are focuses on conﬁdence voting, that is, each voter votes “Yes” or “No” for a question. An election scheme in which each voter chooses one (or some) option from multiple candidates can be achieved by extending such schemes. This type of electronic voting scheme is realized by homomorphism. On the other hand, there are secure voting schemes in which each ballot represents a candidate’s name. The schemes of this type are based on anonymous channel such as shuﬄing or blind signature systems. In this paper, we focus on another type of voting system in which each voter has multiple ballots. This type of voting is used at a general meeting of stockholders. In such voting systems, there are multiple candidates to vote for and each voter has multiple ballots, where the number of ballots can be diﬀerent among the voters. Moreover, in some cases, each voter can divide his available ballots into some parts and vote each part for each candidate. C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 137–150, 2003. c Springer-Verlag Berlin Heidelberg 2003

138

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

Related work Many electronic voting schemes have been proposed. They are classiﬁed into three types: homomorphism based schemes [2,3,5,6,7,11,20], shufﬂing based schemes [10,13,18,19,21] and blind-signature based schemes [9,15,16]. Homomorphism based schemes are eﬃcient for “Yes” or “No” type voting, and they were extended into multi-way elections in which each voter can vote for one of multiple candidates [7]. Voting schemes of this type require ZKIPs to prove that each ballot is “Yes” or “No”, so they have high computational and communicational costs. Shuﬄing based schemes realize anonymity and privacy of each ballot by using an anonymous channel such as mix-net. Schemes of this type can handle any kinds of ballot, and the communicational costs of voters are light. However they require ZKIPs to prove that each mix server has not altered each message. Thus, they are not eﬃcient for large scale voting. Blind-signature based schemes are eﬃcient in terms of the computational load. In such schemes, each voter requests a blind signature from an authority to permit voting, and then sends the vote to a tallying server. This gives each voter the ability to enter an objection and so prevent tallying server’s abuse. However, this type has no public veriﬁability and needs an anonymous channel such as mix-net. Moreover, each voter must join all phases of the whole protocol. The existence of any voter who fails to complete a process threatens the soundness of the voting result. There has been a lot of research on enhancing the performance of mix-net for this type of voting scheme [1]. As regards ﬁnancial cryptography, several cryptographic protocols have been created for digital stock certiﬁcates. McKenzie et al. proposed a protocol to construct electronic stock certiﬁcates and showed how to assure the rights of stockholders [14]. This protocol allows voting while preserving anonymity and security. However, they showed no eﬃcient protocol for multiple ballots. Our contribution We ﬁrst deﬁne such voting system as “divisible voting,” and deﬁne secure divisible voting scheme. Next, we give some naive divisible voting protocols. They are easily obtained from multi-way voting protocol, however, they are not eﬃcient if the number of ballots each voter has is large. Finally, we propose two eﬃcient constructions of divisible voting. Our ﬁst construction uses multisets with a special property, named divisible multiset. The second one L-adic representation of the numbers of ballots. Both of our protocols are based on homomorphic encryption, and they do not need MIX-net. The total cost for a voter is O(M 2 log(N )) in the ﬁrst scheme and O(M log(N )) in the second scheme where M is the number of candidates to vote for and N is the number of ballots for a voter.

2

Divisible Voting

We deﬁne divisible voting as follows. – There are many voters and some voting servers. Let {V1 , V2 , . . .} be the set of voters.

Divisible Voting Scheme

139

– Each voter has multiple ballots. Let N (i) be the number of ballots Vi has. – There are multiple candidates to vote for. Let M be the number of candidates. – Each voter votes some ballots which are taken from his available ballots for all candidates. We denote the number of ballots Vi votes for j-th candidates (i) by vj . It must be (i)

0 ≤ vj ≤ N (i) and

M j=1

(i)

vj = N (i) .

(1)

The goal is to output the number of total ballots each candidate obtained without revealing any additional information. We can consider that divisible voting is a generalized model of some voting systems. When M = 2 and N (i) = 1 for all i, the system is an ordinal yes/no voting system, in which each voter votes for “yes” or “no”. When M > 2 and N (i) = 1 for all i, the system is a multi-way voting system. We say that a protocol is a secure divisible voting scheme if it satisﬁes following requirements. 1. The voting servers correctly output the result of voting, even if some of voting servers are malicious, and any one can verify the validity of the result. 2. Any voter can not vote in excess of the number of his available ballots N (i) . That is, Eq. (1) must be satisﬁed for all i. 3. Any one can not obtain additional information about the choice of each voter from published information. Formally, consider an adversary who corrupts less than t servers and all voters except two target voters. Assume that (i) (i ) (i) (i ) (vj , vj ) which are choices of two target voters and (vj , vj ) which are other choices of them lead same results, then the views the adversary sees in these two cases are indistinguishable.

3

Previous Voting Protocols Based on a Homomorphic Encryption

Electronic yes/no and multi-way voting has been studied by many researchers, and eﬃcient schemes were already proposed [7]. In this section, we review yes/no voting protocols based on a homomorphic encryption and the extension to multiway voting. 3.1

Requirements of Encryption Schemes

Electronic voting protocols based on a homomorphic encryption use a public-key encryption with some desirable conditions. Let E be a public-key probabilistic encryption function. We denote by E(m) the set of encryptions for a plaintext m and by e ∈ E(m) a particular encryption of m.

140

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

We assume that E satisﬁes following desirable properties. Homomorphic property. There exists a polynomial time computable operation, ⊗, as follows for a large prime q. (e1 ∈ E(m1 ) ∧ e2 ∈ E(m2 ) ) =⇒ e1 ⊗ e2 ∈ E(m1 + m2 mod q) For the simplicity, we write n

ei = e1 ⊗ e2 ⊗ · · · ⊗ en

i=1

and

ea = e ⊗ e ⊗· · · ⊗ e a

for a positive integer a. Then, if ei ∈ E(mi ) then n n ai (ei ) ∈ E ai mi mod q . i=1

i=1

Threshold decryption. For a given ciphertext e ∈ E(m), any k out of n players can decrypt e along with a zero-knowledge proof of the correctness. However, any k − 1 out of n players cannot decrypt e. Non-malleability. A public key cryptosystem is said to be non-malleable [8] if there exists no probabilistic polynomial time adversary such that given a challenge ciphertext e, he can output a diﬀerent ciphertext e such that the plaintexts m, m for e, e are meaningfully related. (For example, m = m+1.) Plaintext membership proof (PMP). There exists an eﬃcient zero-knowledge proof protocol, called plaintext equality test [12], which proves e ∈ E(m) for given e and a known plaintext m. Cramer et al. [4] shows that there exists an eﬃcient construction of witnessindistinguishable proof to prove that e ∈ E(m1 ) or e ∈ E(m2 ) or · · · or e ∈ E(mM ) for given ciphertext e and M known messages m1 , . . . , mM , if there exists a plaintext equality test. This proof system seems like a M times parallelized plaintext equality tests, however, it has a unique challenge which is exclusive OR of all M challenges in plaintext equality tests. In this paper, we denote such a proof system “1-out-of-M plaintext membership proof (PMP).” ElGamal cryptosystem and Paillier cryptosystem [17] satisfy these properties. 3.2

Overview of Yes/No Voting Scheme

In an yes/no voting scheme, each voter has only one ballot, and he votes it for ‘Yes’ or ‘No’. The protocol is summarized as follows.

Divisible Voting Scheme

141

1. In advance, n voting servers share a decryption key of a public-key probabilistic encryption function E. 2. Vi sets v (i) = 1 if he wants to vote for Yes, otherwise v (i) = 0, and opens e(i) ∈ E(v (i) ). Then he proves that e(i) ∈ E(1) or e(i) ∈ E(0) using a 1-outof-2 PMP. 3. After the voting period, (i) e(sum) = e i

is computed. This computation can be done by every one. Then, n servers jointly decrypt e(sum) and obtain v (sum) . v (sum) is the number of voters who voted v (i) = 1. In the above protocol, homomorphism of E assures that e(sum) ∈ E v (i) i

and then v (sum) =

v (i) .

i

Decryption is done correctly and public veriﬁably since it is done by k-out-of-n threshold manner. Then the ﬁrst condition of security is satisﬁed. The second condition is assured, since each voter has to pass a 1-out-of-2 PMP. If ElGamal encryption is used as a homomorphic encryption, the ciphertext of no-vote is (g r , y r ) and that of yes-vote is (g r , gy r ), where y is a public key and r is a random number. Then the message the servers actually obtain is (i) v (sum) = g i v . Since i v (i) is not more than the number of voters, servers can get i v (i) . 3.3

Multi-way Voting

There are two ideas of construction of a multi-way voting scheme. In the ﬁrst one, we call combined-type, each voter opens only one ciphertext. In the other one, separate-type, he opens one ciphertext for one candidate, then totally M ciphertexts. (M is the number of the candidates to vote for.) Combined-type. Let N (sum) be the number of voters. To get a multi-way voting for M candidates, we use M speciﬁed messages, (m1 , . . . , mM ) such that mj = (N (sum) + 1)j−1 . A voter who votes for ˆj-th candidate publishes a ciphertext of mˆj , and proves that the ciphertext is valid by using a 1-out-of-M PMP. The tallying is done as same as yes/no-voting. The plaintext v (sum) does not specify the result explicitly, but v (sum) = T1 + (N (sum) + 1)T2 + · · · + (N (sum) + 1)M−1 TM ,

142

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

where Tj ’s are the results of the election. Since Tj < N (sum) + 1, Tj ’s are determined uniquely. Separate-type. A voter who votes for ˆj-th candidate prepares M ciphertexts as follows.

E(0) if j = ˆj ej ∈ E(1) if j = ˆj Then opens them Mand proves that each ciphertext is valid by using a 1-outof-2 PMP and j=1 ej ∈ E(1). In this case, the tallying is very simple. The servers combine ciphertexts for each candidate and decrypt them. The obtained plaintexts are the results of voting. Comparison of two types. We compare the two types of multi-way voting protocols brieﬂy. Column “#ciphertext” in Table 1 shows the number of ciphertexts each voter has to compute and publish. The next column, “PMP,” shows the number x such that each voter performs 1-out-of-x PMP for each ciphertext. (For example, in separate-type protocol, each voter performs 1-out-of-2 PMP for each ciphertext.) In general, a plaintext equality test costs a few times of computation and communication costs of sending a ciphertext. In this paper, we assume that the cost of a plaintext equality test equals τ times of that of computing and sending a ciphertext3 . Furthermore, we assume that a 1-out-of-x PMP costs x times of a plaintext equality test. Then, the total costs are estimated such as column “Total.” Column “#decryption” shows the number of ciphertexts the servers have to decrypt jointly.

Table 1. Comparison of multi-way voting protocols Type #ciphertext PMP Total #decryption Combined 1 M τM + 1 1 M 2 (2τ + 1)M M Separate

4

Naive Divisible Voting Protocols

Before showing eﬃcient protocols, we give some naive solutions. It is easy to show they are secure protocols. 3

For example, 1 < τ < 2 for ElGamal encryption.

Divisible Voting Scheme

143

Iteration-type. We can easily realize divisible voting in such a way that Vi performs a multi-way voting procedure N (i) times independently. If the multiway voting protocol is secure, then the divisible voting protocol is also secure. We can use both combined-type one and separate-type one. In such protocols, the communicational and computational costs of voter Vi are N (i) times of those in the multi-way voting protocol. Modified separate-type. A voter who gives vj ballots for j-th candidate prepares M ciphertexts as follows. ej ∈ E(vj ) Then opens them andproves that each ciphertext is valid by using a 1-out-of(i) ). (N (i) + 1) PMP and M j=1 ej ∈ E(N Comparison. Table 2 shows the comparison of naive protocols. From this table, we can say that iteration of separate-type is less eﬃcient than others, and the total cost is O(M N (i) ) for all types. Table 2. Comparison of naive protocols Type #ciphertext PMP Total #decryption Iteration+combined N (i) M (τ M + 1)N (i) 1 M N (i) 2 (2τ + 1)M N (i) M Iteration+separate M N (i) + 1 M (τ N (i) + τ + 1) M Modiﬁed separate

5

Eﬃcient Divisible Voting Schemes

In the naive protocols, each voter’s communication and computation costs are O(M N (i) ) where N (i) is the number of ballots he has. When N (i) is large, it is not eﬃcient. In this section, we propose two eﬃcient constructions of secure divisible voting scheme. 5.1

Divisible Voting Scheme Using Multisets

The ﬁrst construction uses multisets of positive integers, called divisible multiset, which satisﬁes special conditions to reduce the number of iterations of iterationtype naive protocols. Deﬁnition 1. For positive integers M and N , we call a multiset X an (M, N )Divisible Multiset (DM) if for all sets of non-negative integers (x1 , . . . , xM ) such that M i=1 xi = N , there exist multisets X1 , . . . , XM ⊆ X such that

144

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

 



Xi = X  ∧

∀i ∈ {1, . . . , M } :

a = xi

.

(2)

a∈Xi

1≤i≤M

Here we define as multiset union such that when A = {a1 , . . . , an } and B = {b1 , . . . , bm }, A B = {a1 , . . . , an , b1 , . . . , bm }. For example, X = {1, 1, . . . , 1} is an (M, N )-DM for any M . For a given set N of integers (x1 , . . . , xM ) such that i xi = N , let Xi = {1, 1, . . . , 1}. Then Xi ’s xi

satisfy Eq. (2). For another example, X = {1, 2, 4, 8, 16, 32, 37} is a (2, 100)-DM. For x1 = 41, x2 = 59, X1 = {1, 8, 32},

X2 = {2, 4, 16, 37}

satisfy Eq. (2). It is clear that a∈X a = N if X is an (M, N )-DM. Here we consider the following protocol. For a publicly known (M, N (i) )DM X = {a1 , a2 , . . . , au }, voter Vi has u bundles of ballots such that the lth bundle consists of al ballots. So, totally he has N (i) ballots. He votes each bundle (instead of each ballot) for one of M candidates using multi-way voting procedure. He can vote u bundles for diﬀerent candidates, but can not divide ballots in a bundle and vote for multiple candidates. The tallying is done as same as the multi-way voting protocol, but a bundle of al ballots is weighted al times. Here N (i) and X are public. However, it is secret which candidate he vote for each bundle. (i) The property of DM assures that the voter can give vj ballots for j-th (i)

(i)

candidate for all (v1 , . . . , vM ). Therefore, the above system is a divisible voting protocol. (In fact, if X = {1, 1, . . . , 1} and u = N (i) , the above protocol is identical to the iteration-type naive protocol.) In this protocol, the number of iterations Vi has to do is the number of elements of the divisible multiset. Next, we show that we can construct an (M, N )DM that includes fewer elements. Then we can save the number of iterations. Theorem 1. For any positive integer N , we can construct a (2, N )-DM that includes log2 N + 1 elements. The proof of this theorem is shown in Appendix A. Theorem 2. For any positive integer N and any integer 3), we can con M(≥ N struct an (M, N )-DM that includes at most (M − 1) log2 M + 1 + 1 elements. The proof of this theorem is omitted due to lack of space, and can be found in the full version of this paper.

Divisible Voting Scheme

5.2

145

Improvement of Modiﬁed Separate-Type

The second eﬃcient construction can be considered as an improved one of modiﬁed separate-type naive protocol. Assume that a voter wants to give vj ballots for j-th candidate. In modiﬁed separate-type naive protocol, the voter encrypts vj for all j and proves that Eq. (1) holds using 1-out-of-(N (i) + 1) PMP. In the second construction, he ﬁrst writes vj with L-adic representation for some L(≤ N (i) +1). Let (bj,t , . . . , bj,1 , bj,0 ) t be the L-adic representation, that is, bj,l ∈ {0, 1, . . . , L−1} and vj = l=0 Ll bj,l , where t = logL N (i) . Then he encrypts bj,l for all j and l and proves that bj,l ∈ {0, 1, . . . , L − 1} holds using 1-out-of-L PMP. Here, t and L are public, however, bj,l fore each j and l is secret. Concrete protocol is described as follows. 1. In advance, n voting servers share a decryption key of a public-key probabilistic encryption function E. (i) (i) (i) (i) 2. Let (bj,t , . . . , bj,1 , bj,0 ) be a L-adic representation of vj (1 ≤ j ≤ M ). (i)

(i)

(i)

For each j, Vi computes (ej,t , . . . , ej,1 , ej,0 ) where (i)

(i)

ej,l ∈ E(bj,l ), (i)

(i)

(i)

then opens (ej,t , . . . , ej,0 ), and proves that ej,l is valid for all l using 1-outof-L PMP. In addition, he shows that M t j=1 l=0

(i)

ej,l

Ll

∈ E(N (i) ).

It is enough for the voter to show above fact by publishing a random number which is used to encrypt. 3. After the voting period, (sum)

ej

=

t i

l=0

(i)

ej,l

Ll

(sum)

is computed. Next n servers jointly decrypt ej is the number of ballots j-th candidate got.

(sum)

and obtain vj

It is clear that (sum) ej

Then

∈E

t i

L

l

l=0

(sum)

vj

=

(i) bj,l

i

=E

i

(i)

vj .

(i) vj

.

(sum)

. vj

146

5.3

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

Eﬃciency

Table 3 shows the comparison of eﬃcient protocols. Similar to Table 1 and 2, column “Total” shows the total complexity of each type when cost of one PMP is τ times of that of computing and sending one plaintext, and one 1-out-of-x PMP equals x times of one PMP. “DM+combined” and “DM+separate” denote the ﬁrst eﬃcient construction in which combine-type and separate-type multiway voting protocol is used, respectively. “L-adic separate” denotes the second construction. Table 3. Comparison of cost for a voter Type

DM+combined

(τ M + 1) (M − 1)

DM+separate

(2τ + 1)M (M − 1)

L-adic separate

Total

log2

log 2

N (i) M

N (i) M

+1 +1

+1 +1

(τ L + 1)M log L N (i) + 1

Comparing with Table 2, our constructions are more eﬃcient than naive protocols. The ﬁrst construction with a separate-type multi-way voting protocol is clearly inferior to the others. Fig. 1 shows that the total costs of L-adic separate construction for L = 2, 3, 4, 5, 10 where τ = 1.2 and M = 5. It shows that L = 3 or L = 4 is most eﬃcient in most cases. Fig. 2 shows that the total cost of 4-adic separate construction and DM+combined construction where τ = 1.2, L = 4 and M = 5. It shows that DM+combined are more eﬃcient only when N = 4, 5, otherwise 4-adic separate construction is more eﬃcient. Next, look at the eﬃciency of tallying. Table 4 shows the number of decryption procedures and maximal number of plaintexts obtained by the decryption. Here we omit the ﬁrst construction with separate-type. Table 4. Comparison of tallying Type #decrypt Message space DM+combined 1 (N (sum) + 1)M 4-adic separate M N (sum)

If Paillier cryptosystem is used, Tj ’s are easily computed from T1 + (N + 1)T2 + · · · + (N + 1)M−1 TM . Therefore, the ﬁrst construction is more eﬃcient.

Divisible Voting Scheme

147

cost 200

100 L=2 L=3 L=4 L=5 L=10 0

1

10

100

1000

N

Fig. 1. Cost of L-adic construction where τ = 1.2 and M = 5

cost

200

100

4−adic DM−Combine 0 1

10

100

1000

N

Fig. 2. Cost comparison between L-adic construction and DM+combined where τ = 1.2, L = 4 and M = 5

148

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

If we use ElGamal scheme, large message space makes the tallying costly. Then the second construction is more eﬃcient. 5.4

Security

Theorem 1 and Theorem 2 assure that the security of the DM construction is equivalent to the that of naive iteration-type construction. The naive construction is multiple executions of yes/no voting. Thus, the security of naive construction is equivalent to that of yes/no voting. Hence our DM construction is secure divisible voting scheme. The security of the L-adic construction is based on the security of the encryption function and the 1-out-of-L PMP used in the protocol. Thus, it is clear that the security is shown in the same way as the security of the yes/no voting protocol.

References 1. M.Abe, “Universally Veriﬁable Mix-net with Veriﬁcation Work Independent of the Number of Mix-servers,” In Proc. of Eurocrypt ’98, LNCS 1403, pp.437-447 (1998). 2. J. Benaloh and D. Tuinstra, “Receipt-Free Secret-Ballot Elections,” In Proc. of STOC ’94, pp.544-553 (1994). 3. J. Benaloh and M. Yung, “Distributing the Power of a Government to Enhance the Privacy of Voters,” In Proc. of PODC ’86, pp.52-62 (1986). 4. R. Cramer, I. Damg˚ ard and B. Schoenmakers, “Proofs of Partial Knowledge and Simpliﬁed Design of Witness Hiding Protocols,” In Proc. of Eurocrypt ’94, LNCS 839, pp. 174–187 (1994). 5. J. Cohen and M. Fischer, “A Robust and Veriﬁable Cryptographically Secure Election Scheme,” In Proc of FOCS ’85, pp.372-382 (1985). 6. R. Cramer, M. Franklin, B. Schoenmakers and M. Yung, “Multi-Authority SecretBallot Elections with Linear Work,” In Proc. of EUROCRYPT ’96, LNCS 1070, pp.72-82 (1996). 7. R. Cramer, R. Gennaro, and B. Schoenmakers, “A Secure and Optimally Eﬃcient Multi-Authority Election Scheme,” In Proc. of Eurocrypt ’97, LNCS 1233, pp. 103– 118 (1997). 8. D. Dolev, C. Dwork and M. Naor, “Non-malleable cryptography,” In Proc. of STOC ’91, pp. 542–552 (1991). 9. A. Fujioka, T. Okamoto and K. Ohta, “A Practical Secret Voting Scheme for Large Scale Elections,” In Proc. of AUSCRYPT ’92, pp.244-251 (1993). 10. J. Furukawa and K. Sako, “An Eﬃcient Scheme for Proving a Shuﬄe,” In Proc. of CRYPTO 2001, LNCS 2045, pp.368-387 (2001). 11. K. R. Iversen, “A Cryptographic Scheme for Computerized General Elections,” In Proc. of CRYPTO ’91, LNCS 576, pp.405-419 (1991). 12. M. Jakobsson and A. Juels, “Mix and Match: Secure Function Evaluation via Ciphertext,” In Proc. of Asiacrypt 2000, LNC Vol. 1976, pp. 162-177 (2000). 13. M. Michels and O. Horster, “Some Remarks on a Receipt-Free and Universally Veriﬁable Mix-Type Voting Scheme,” In Proc. of ASIACRYPT ’96, LNCS 1163, pp.125-132 (1996).

Divisible Voting Scheme

149

14. P. McKenzie and J. Sorensen, “Anonymous Investing,” In Proc. of Financial Cryptography ’99, LNCS 1648, pp.212-229 (2000). 15. T. Okamoto, “An Electronic Voting Scheme,” In Proc. of IFIP ’96, Advanced IT Tools. 16. M. Ohkubo, F. Miura, M. Abe, A. Fujioka and T. Okamoto, “An improvement on a Practical Secret Voting Scheme,” In Proc. of ISW ’99, LNCS 1729, pp.255-234 (1999). 17. P. Paillier, “Public-Key Cryptosystems Based on Composite Degree Residuosity Classes,” In Proc. of Eurocrypt ’99, LNCS 1592, pp.223–238 (1999). 18. C. Park, K. Itoh and K. Kurosawa, “Eﬃcient Anonymous Channel and All/Nothing Election Scheme,” In Proc. of EUROCRYPT ’93, LNCS 765, pp. 248–259 (1993). 19. K. Sako, “Electronic Voting Scheme Allowing Open Objection to the Tally,” IEICE Trans. on Fundamentals, Vol.E77-A, No.1, pp.24–30 (1994). 20. K. Sako and J. Kilian, “Secure Voting Using Partially Compatible Homomorphisms,” In Proc. of CRYPTO ’94. LNCS 839, pp.411-424 (1994). 21. K. Sako and J. Kilian, “Receipt-Free Mix-Type Voting Scheme,” In Proc of EUROCRYPT ’95, LNCS 921, pp.393-403 (1995).

A

Proof of Theorem 1

When N = 1, a multiset X = {1} is obviously a (2, 1)-DM. We will prove in N ≥ 2. For any N , following equation holds. N = 2log2 N − 1 + N − 2log2 N + 1   log2 N −1 2i  + N − 2log2 N + 1 = i=0

Note that N − 2log2 N + 1 ≥ 1 holds from 2log2 N ≤ N . Let deﬁne X as X = 2i | 0 ≤ i ≤ log2 N − 1 N − 2log2 N + 1 . Then a∈X a = N . Hereafter, we prove X is a (2, N )-DM. Let x1 , x2 be integers which are not negative and satisfy x1 + x2 = N . Here we does not lose generality when we assume that 0 ≤ x1 ≤ x2 ≤ N . Then x1 ≤ 2log2 N − 1 holds. When x1 = 0, x2 = N , let X1 = φ , X2 = X. Then eq. (2) holds. When x1 ≥ 1, let βlog2 x1 , . . . , β0 be a binary representation of x1 and X1 = 2i | 0 ≤ i ≤ log2 x1 , βi = 1 , X2 = X − X1 .

(3)

150

Natsuki Ishida, Shin’ichiro Matsuo, and Wakaha Ogata

From eq. (3), log2 x1 ≤ log2 N − 1. Thus, X1 ⊆ 2i | 0 ≤ i ≤ log2 N − 1 ⊂ X. From

log2 x1

a=

a∈X2

eq. (2) holds.

a=

a∈X

βi 2i = x1

i=0

a∈X1

and

a−

a∈X1

a = N − x1 = x2 ,

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment and Secure Two-Party Computations Anderson C.A. Nascimento1 , Joern Mueller-Quade2 , Akira Otsuka1 , Goichiro Hanaoka1 , and Hideki Imai1 1

2

Institute of Industrial Science, The University of Tokyo 4-6-1, Komaba, Meguro-ku, Tokyo, 153-8505 Japan {anderson,otsuka,hanaoka,imai}@imailab.iis.u-tokyo.ac.jp Universitaet Karlsruhe, Institut fuer Algorithmen und Kognitive Systeme Am Fasanengarten 5, 76128 Karlsruhe, Germany {muellerq}@ira.uka.de

Abstract. We study the problem of secure function evaluation in the so called commodity based cryptography model as proposed by Beaver in his STOC 97 paper. We propose very eﬃcient protocols for implementing addition and multiplication over GF (q). Diﬀerently than in previous works, in our protocol each step of the computation is veriﬁable. Moreover, no copying of commitments is necessary, because commitments are not destroyed during the computation. Also, no error correcting techniques are necessary here yielding simpler protocols. The protocol is based on novel veriﬁable primitives (one time multiplication proofs, multiplication gates and pre-distributed commitments) in the commodity based model which allow two players to perform secure multiplication of shares over GF (q) with round-complexity equal to one.

1 1.1

Introduction The Problem

Two-party secure function evaluation consists of a protocol which allows two players, Alice and Bob, to compute a function f (x, y), which depends on inputs from Alice and Bob, such that at the end of the protocol: both parties are sure that the result of the computation is correct; no party has learned more about each other’s input than what can be computed from the output itself; a dishonest player did not obtain signiﬁcant knowledge about the output of the protocol while preventing the honest party from receiving the result of the computation. Secure function evaluation is a central problem in the theory of cryptography and has received considerably attention since its introduction in [20]. Several diﬀerent solutions for this problem were proposed including the ones proposed by Goldreich et al [11], Chaum et al. [7], Crepeau et al. [9], Kilian [14], among others. C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 151–164, 2003. c Springer-Verlag Berlin Heidelberg 2003

152

Anderson C.A. Nascimento et al.

A wide range of assumptions and models were used in the previously cited works. In our paper we focus on protocols which do not rely on unproven assumptions, that is information theoretically secure protocols. The protocols based on the private channels model, such as [11] and [7] are information theoretically secure, but they assume that n players are involved in the computation and that more than 2/3 of these players are honest. Even when a broadcast channel is provided, still the protocols are secure iﬀ the majority of the players is honest. Clearly, that is not the case in a secure two-party computation. Therefore, extra assumptions are needed in order to implement it. In [14], Kilian proposed an information theoretically secure protocol for secure two-party function evaluation based on the existence of a “general” oblivious transfer protocol. However, his reduction, although having polynomial time complexity, is not very eﬃcient. It contains several complicated zero-knowledge proofs and all the operations are performed over binary ﬁelds, what increases the round complexity of the protocol. In [9], a more eﬃcient protocol was proposed but complicated cut-and-chose arguments and operations only over binary ﬁelds were still present. In this paper, we introduce a very eﬃcient protocol for information theoretically secure two-party computations which avoids expensive cut-and-choose based zero knowledge proofs and directly performs operations over GF (q) and not only over binary ﬁelds. The assumption we base the security of our protocols is the existence of a trusted server which pre-distributes cryptographic primitives to Alice and Bob during a setup phase [4]. 1.2

Commodities Based Cryptography

We propose protocols based on the so-called commodity cryptographic model. In [4], Beaver introduced a model, where players buy cryptographic primitives from “oﬀ-line” servers. These primitives can be used later on to implement general cryptographic protocols. The commodity based model was inspired in the internet architecture, which is usually based on the “client-server” paradigm. Once the primitives, or commodities as they are called by Beaver, are acquired, no further interactions between server and users are required. Therefore, the servers need not know the values which are computed by the players. Moreover, if several servers are available, they need not be completely trusted, that is, the system is secure even if some servers collude with the users of the commodities and/or among themselves. Another interesting feature of Beaver’s model is that no interaction among the servers is required. In this contribution, we show that the use of oﬀ-lines servers provides very eﬃcient and simple protocols for secure function evaluation over GF (q). Although this model was formalized just in [4], several independent works share the same ﬂavor. We cite key-pre-distribution schemes [15], unconditionally secure bit commitments [19,6] and unconditionally secure digital signature schemes [13].

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

1.3

153

Our Contribution

In this contribution we introduce a two-party secure function evaluation protocol which has the following interesting features: – It is based on novel veriﬁable primitives (one-time multiplication proofs, multiplication gates and pre-distributed commitments) in the commodity based model which allow two players to perform secure multiplication of shares over GF (q) with round-complexity equal to one. – The veriﬁability of the protocol is not based on any cut-and-choose argument or expensive zero knowledge proofs. – It is information theoretically secure. – It is conceptually very simple. 1.4

Related Work

The work which most overlap with ours is [5]. In [5], Beaver also introduced a primitive in the commodity based model which yields eﬃcient secure two-party computations over GF (q). However, a major diﬀerence between Beaver’s work and ours is that his primitive, which he called a one-time table, is not veriﬁable. Therefore, each step of the computation is not veriﬁed and Alice and Bob should perform a cut-and-choose veriﬁcation algorithm to certify the correctness of the computation. Some of the advantages of our scheme when compared to Beaver’s are: – No error correcting techniques are necessary here yielding simpler protocols; – No copying of commitments is necessary, because commitments are not destroyed during the computation. – No need of speciﬁc gates to compute multiplicative inverses. – As each step of the computation is eﬃciently veriﬁed, players need not compute all the function in order to detect cheating attempts. 1.5

Tools

We make extensive use of pre-distributed commitments [17,6,19]. In a pre-distributed commitment, a trusted party sends some data during a setup phase to Alice (committer) and Bob (receiver). Later on, Alice and Bob use this data to implement a commitment scheme without contacting the trusted party. Predistributed commitments were introduced in [19], in [6] a model, new constructions and bounds on the cheating probability were proved. In [17] bounds on the amount of data which has to be pre-distributed to Alice and Bob were proved, the issue of homomorphism in homomorphic commitments was introduced as well as a new homomorphic construction based on modules of mappings over ﬁnite ﬁelds. Pre-distributed commitments are very much similar to Rabin’s “check-vectors” [18]. The idea of a “check-vector” is that a party A provides some correlated secrets to parties B and C, and these secrets let B send an authenticated message

154

Anderson C.A. Nascimento et al.

to C. This is similar to what we do, except that the typical use of check-vectors in the literature, party A knows the message (whereas in our constructions it does not). Thus, as party A need not know the message when it distributes the check-vectors, it can be used in an oﬀ-line way. Also, we introduce a new veriﬁable primitive called a “multiplication gate”. Our construction of multiplication gates can be viewed as the trusted center implementing multiplication on random inputs, and the two parties then “correct” this multiplication according to their actual inputs. This idea was ﬁrst proposed (in the context of multiparty computation with a dishonest minority) by Beaver in [3].

2 2.1

Preliminaries Homomorphic Commitments

We use the homomorphic commitment schemes which were studied by the authors in [17] as a basic tool to achieve our desired protocols for secure function evaluation. A bit commitment scheme consists of two phases, a commit and an unveiling phase. In the commit phase, a sender, usually called Alice, commits to a bit b and sends a proof of this commitment to a receiver, usually called Bob. During the unveiling phase, Alice opens the commit and reveals the value of the bit b to Bob. A bit commitment protocol is secure if it is concealing, binding and correct. – Binding: A bit commitment is binding if Alice is not able to unveil both b and ¯b with high probability. – Concealing: A bit commitment is concealing if after receiving Alice’s commitment, Bob is unable to learn anything on the committed bit before the unveiling phase. – Correct: A bit commitment is correct if it never fails for honest Alice and Bob. In our model there are three parties, a trusted center, Ted, a sender of the commitment, Alice, and a receiver, Bob. At the beginning of the protocol, Alice and Bob receive some secret data from Ted. We designate Alice’s and Bob’s secret data Ua and Ub and their respective random variables by Ua and Ub . We assume that Ted chooses Ua and Ub from the domains Ua and Ub . The value that Alice wants to commit to and its random variable are represented by S and S. The commit phase consists of Alice making use of a publicly known algorithm Commit(S, Ua ) = C which generates an output value which is sent to Bob. We denote the random variable associated to the output of the algorithm Commit by C. The opening phase consists of Alice announcing the secret data received from Ted, Ua , and the value of the commitment, S, to Bob. Bob performs a test by using a publicly known algorithm T est(Ua , Ub , S, C) and depending on the result accepts Alice’s commitment or not.

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

155

The protocol is concealing if the information sent in the committing phase, C, reveals nothing about the committed value S. Mathematically, I(C : S|Ub ) = 0, where I(· : ·|·) is the Shannon conditional mutual information. The protocol is β-binding if the probability that a dishonest Alice is not caught is at most β, that is: max ∗ P (T est(Ua, Ub , S = b, C) =accept ∧ Ua ,Ub ,b,b

= b∗ ) < β. T est(Ua , Ub , S = b∗ , C) =accept; b Finally, the protocol is correct if it never fails for honest Alice and Bob, P (T est(Ua , Ub , S, C) =reject| Alice is honest) = 0 for any Ua , Ub , S, C. Definition 1 A pre-distributed bit commitment scheme is β−secure if the following conditions hold: 1. I(C : S|Ub ) = 0, 2. max ∗ P (T est(Ua , Ub , S = b, C) = accept ∧ T est(Ua , Ub , S = b∗ , C) = Ua ,Ub ,b,b

accept; b = b∗ ) < β, 3. P (T est(Ua , Ub , S, C) = reject| Alice is honest) = 0, where Ua and Ub are the data pre-distributed to Alice and Bob, S is the value Alice is committing to, C is the output of a publicly known Commit algorithm and T est is another publicly known algorithm. We now show a protocol which can be used to prove any linear relation among commitments, without revealing anything more about them, with optimal space complexity [17,6].

Protocol 1. Setup phase: Ted distributes r and s to Alice and g = rt − s mod p and t to Bob, where r, s and t are random elements belonging to Z p , for some prime p. All the computations are over Z p . Commit phase: To commit to m, an honest Alice sends h = m − r mod p to Bob. Bob calculates z = g + ht mod p, a commitment to m. Opening phase: Alice sends m and s to Bob. Bob accepts the commitment iﬀ z = tm − s mod p Before proving the security of the protocol, we note that as Alice does not learn anything about t, in repeated executions of the protocol, Bob has to receive two elements from Z p just in the ﬁrst execution of the commitment protocol. From the second execution on, Bob needs to receive only one value, since t can be used repeatedly without weakening the security. Theorem 1 The commitment scheme described above is β−secure with β = 1/p. Moreover, it is linear, that is, if [b] denotes a commitment to a value b and λ is a publicly known constant, [b + λc] = [b] + λ[c].

156

Anderson C.A. Nascimento et al.

Proof. The proof of the theorem is as follows: Binding. Suppose that in the commit phase, Alice commits to a number m ∈ Z p . First, we note that in order to successfully cheat, Alice has to ﬁnd values m ¯ = m and s¯ = s such that z = tm ¯ − s¯ mod p. As Alice does not know t and z, the only way she can do that is by guessing one of the values. She can succeed only with probability β = 1/p. Concealing. The concealingness of the protocol is evident, since Bob does not know r. Correct. To prove the correctness condition, we note that if Alice is honest, she sends h = m − r mod p to Bob in the commit phase. Hence, z = g + ht mod p = (rt − s) + (m − r)t mod p = tm − s mod p. Therefore, Bob always accept a commitment from an honest Alice. Linearity. Now, we show the linearity of our commitment scheme. Suppose Alice is committed to m and m , so Alice has received r,s, r , s from Ted, while Bob received g, g and t from the TI and h = m − r and h = m − r from Alice. Let λ be a public known constant belonging to Z p . To construct a commitment to m + λm , Bob computes z = z + λz = (g + λg ) + (h + λh )t z is a commitment to m + λm . The opening information is m + λm and s + λs . Bob accepts the commitment if and only if z = t(m + λm ) − (s + λs ) mod p. In our commitment protocol, Alice can prove to Bob that two commitments are the same by asking Bob to subtract the commitments and unveil the commitments diﬀerence to be equal to zero. We note that Ted can commit Alice to a random number l by changing the Setup phase in Protocol 1: Setup phase: Ted distributes r and s to Alice and g = rt − s, t and h = l − r to Bob, where r, s,t and l are random elements belonging to Z p , for some prime p. All the computations are over Z p . The Opening phase is played as in Protocol 1. It is important to remark that Ted can pre-distribute commitments to values which have a certain relation. This feature will be explicitly used in our protocols for two-party secure computations. 2.2

Proofs of Polynomial Relations Among Commitments

In this section we review results from [17] which show how the proposed homomorphic commitments can be used to provide non-interactive proofs of any polynomial relation among commitments. Suppose Alice is committed to the values x1 , ..., xi , xj , ..., xI and wants to compute a commitment to P (x1 , ..., xi , xj , ..., xI ), where P (·) denotes a polynomial relation among x1 , ..., xi , xj , ..., xI . By opening this commitment she can prove relations among x1 , ..., xi , xj , ..., xI . The proof is private if Bob learns nothing more about x1 , ..., xi , xj , ..., xI apart from what

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

157

can be computed from P (x1 , ..., xi , xj , ..., xI ). It is correct if at the end of the protocol Bob holds a commitment to P (x1 , ..., xi , xj , ..., xI ). In [17] we introduced a pre-distributed cryptographic primitive called a one time multiplication proof (OTMP). We use OTMPs to implement protocols for proofs of polynomial relations among commitments. Protocol OTMP. Ted commits Alice to three random numbers l, l and l , such that l = ll . All the computations are over Z p . Now we present our protocol which provides Alice with proofs of multiplication among commitments. We heavily use the linearity of our commitment scheme. In the following we denote a linear commitments to a number b ∈Z p by [b]. We recall that in linear commitment schemes, Alice can prove to Bob that two commitments are the same by asking Bob to subtract the commitments and unveil the commitments diﬀerence to be equal to zero. We now sketch how Alice can prove multiplicative relations among commitments to Bob. Suppose Alice is committed to x1 , ..., xi , xj , ..., xI and wants to compute a commitment to P (x1 , ..., xi , xj , ..., xI ), where P (·) denotes a polynomial relation among x1 , ..., xi , xj , ..., xI . By opening this commitment she can prove relations among x1 , ..., xi , xj , ..., xI . Proving Linear Relations Among Commitments. Given a known constant λ ∈Z p and two commitments [xi ] and [xj ], to obtain a commitment to [xi + λxj ], Bob computes [xi ] + λ[xj ]. The result should be equal to [xi + λxj ] due to the linearity of the commitment. Proving Multiplicative Relations Among Commitments. Assuming that Alice and Bob have an OTMP, Bob should posses commitments to three random values l, l and l , such that l = ll . Given two commitments [xi ] and [xj ], to obtain a commitment to [xi xj ], Bob computes [y] = [xi ] − [l] = [xi − l] and [y ] = [xj ] − [l ] = [xj − l ] and asks Alice to open [y] and [y ]. Bob calculates [ll ] + y[l ] + y [l] + yy . Alice’s unveil information is computed according to [ll ] + y[l ] + y [l] + yy . We now analyze the privacy and correctness of our protocol for proving multiplicative relations among commitments. To show that it is private, note that Bob only learns the values y and y , which give no knowledge on xi and xj , since l and l are random numbers. To show the correctness of our protocol, we note that [ll ]+y[l ]+y [l]+yy = [ll ] + (xi − l)[l ] + (xj − l )[l] + (xi − l)(xj − l ) = [ll + xi l − ll + xj l − l l + xi xj − lxj − l xi + ll ] = [xi xj ] (due to the linearity of the commitment). By applying addition of commitments and multiplication of commitments we can obtain commitments for arbitrary polynomial relations among commitments. E.g. to prove that mm = m Alice lets Bob compute [mm ]−[m ] = [mm −m ] and unveils this to be zero.

158

2.3

Anderson C.A. Nascimento et al.

Secure Two-Party Computations

A two party computation is a random protocol by which two interacting Turing machines (Alice and Bob) can map pair of inputs (one held by each party) into pair of outputs (one held by each party). Here, we do not attempt to give a rigorous analysis of secure two-party computations. For a detailed exposition and rigorous deﬁnitions, we refer to [2,10,11,12,16]. Informally speaking, a computation is said to be secure if it is private, correct and fair [10]. Informally these properties are: Private: No party learns anything more than what can be computed from the output. Correct: The output received by each party is guaranteed to be the output of the speciﬁed function. Fair: Corrupted parties should receive an output iﬀ honest parties do. The fairness requirement is usually relaxed in the two-party scenario. We assume that the additional information a corrupted party has about the computation’s output can be made arbitrarily small in a security parameter n. A protocol is secure only in respect to a certain adversary behavior. The most used adversary behaviors are the semi-honest model (sometimes also called the passive attack model) and the malicious model (also called the active attack model): Semi-honest Model: In the semi-honest model, the players are supposed to follow the protocol, but they may keep records of all their actions in order to break the privacy condition of the protocol. Malicious Model: In the malicious model a corrupted player (Alice or Bob) may deviate from the original protocol, in an arbitrary way, as to break the privacy, correctness and fairness conditions. Note that there are certain attacks which cannot be prevented by any protocol implementing a secure computation [10]. For example, nothing can prevent the parties from not joining the protocol or prematurely leaving it. In more details, secure computation protocols usually do not address the following kinds of attacks: – Parties refusing to join the protocol. – Parties aborting the protocol before it is ﬁnished. – Parties changing their local inputs before entering in the protocol. Our protocol is secure assuming malicious adversaries. A secure computation usually has three stages: Input Stage: Here the parties enrolled in the protocol commit to their inputs. Computation Stage: In the computational stage, the parties evaluate the circuit which describes the function to be evaluated gate by gate. We consider only multiplication and addition gates, since they are universal. Output Stage: In this stage, the parties receive their correspondent outputs.

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

159

In our protocol we assume an extra stage which happens before the input stage, it is called setup phase. Setup Phase: During the setup phase, Alice and Bob receive commodities from the trusted center (in our protocol, the commodities are commitment schemes, multiplication gates and OTMPs).

3

Model

We work in the commodity-based cryptography model as proposed by Beaver in [4]. There are two players and a trusted center (in the full paper we generalize our result to multiple trusted centers, where any minority of centers can perform malicious attacks, thus reducing the degree of trust on each center). The center is supposed to act only during a setting phase and no sensitive information concerning the players input is ever transmitted to it. It is trusted in the sense that it always behaves according the protocol during the setup phase and never releases pre-distributed information to anyone. The players and the trusted center are connected by private channels. The players (Alice and Bob) may deviate from the protocol in a malicious way as to break the security of the protocol. No computational assumptions are assumed. Alice and Bob receive an amount of pre-distributed commitments, multiplication gates and OTMPs during a setup phase. After the setting phase the trusted server is not used anymore. During the input phase, Alice and Bob commit to their respective inputs by using the commitments which were distributed during the setting phase. They evaluate the function which is being securely computed gate by gate, by using the multiplication gates and the homomorphic property of the commitment schemes.

4

Multiplication Gates

Here we describe the multiplication gates which are used to accomplish our secure computation protocol. They are very simple and are based on the secure commitments which were described in the previous section. Multiplication gates consist of a set of three pre-distributed commitments which are given to Alice and Bob. They are constructed during the setting phase by the trusted center. In the following, [b] denotes a commitment to a number b ∈ Z p . For a commitment to x held by one party we denote by |x| the information used to open the commitment held by the other party. Setup of Multiplication Gates. 1. The trusted center selects three random numbers k1, k2, k3 ∈ Z p . 2. The trusted center sends k1, [k2], [−k3], |k1| and |k1 ∗ k2 + k3| to Alice. 3. Bob receives k2, [k1], [k1 ∗ k2 + k3], |k2| and | − k3| from the trusted center.

160

Anderson C.A. Nascimento et al.

By using multiplication gates, Alice and Bob can perform multiplication of commitments that were performed with Protocol 1. We show how. We assume that before enrolling in the multiplication protocol, Alice and Bob are committed to a and b respectively. Our aim is to have, at the end of the multiplication protocol, Alice and Bob committed to u and v such that u + v = a ∗ b, so that result is already shared. A protocol which achieves this aim is said to be correct. It is private if after the protocol is completed, Alice and Bob have no information on the other party input. Since Alice and Bob received multiplication gates during the setting phase, the values known to each party at the beginning of the multiplication protocol are as follows: Alice: Alice a, [b], k1, [k2], [−k3], |a|, |k1| and |k1 ∗ k2 + k3|. Bob: Bob has b, [a], k2, [k1], [k1 ∗ k2 + k3], |k2|, | − k3| and |b| Alice and Bob then proceed with the following protocol: Multiplication Gate Protocol. 1. Bob computes [y] = [a] − [k1] and asks Alice to open [y]. 2. Alice computes [y ] = [b] − [k2] and asks Bob to open [y ]. 3. Alice computes y ∗ [k2] + [−k3] (= [y ∗ k2 − k3] due to linearity) now Bob is committed to y ∗ k2 − k3. 4. Bob computes y ∗ [k1]+ [k1 ∗ k2 + k3]+ y ∗ y (= [y ∗ k1 + k1 ∗ k2 + k3 + y ∗ y ]) now Alice is committed to [y ∗ k1 + k1 ∗ k2 + k3 + y ∗ y ] A short calculation shows that the sum of these two resulting commitments is a ∗ b: y ∗ k1 + k1 ∗ k2 + k3 + y ∗ y = (b − k2) ∗ k1 + k1 ∗ k2 + k3 + (a − k1)(b − k2) = b ∗ k1 − k2 ∗ k1 + k1 ∗ k2 + k3 + a ∗ b − a ∗ k2 − b ∗ k1 + k1 ∗ k2 = a ∗ b + b ∗ k1 − b ∗ k1 − k1 ∗ k2 + k1 ∗ k2 + k1 ∗ k2 − a ∗ k2 + k3 = a ∗ b + k1 ∗ k2 − a ∗ k2 + k3 = a ∗ b − (a − k1) ∗ k2 + k3 = a ∗ b − y ∗ k2 + k3, so Bob is committed to this number. Alice is committed to y ∗ k2 − k3 and the two commitments sum up to a ∗ b as desired, so the protocol is correct. To show that the protocol is private, we note that at the end of the protocol, Alice knows a, [b], k1, [k2], [−k3], |a|, |k1| and |k1 ∗ k2 + k3| and y and none of those values reveal anything about b. At the end of the protocol Bob knows b, [a], k2, [k1], [k1∗k2+k3], |k2|, |−k3|, |b| and y and none of these values conveys any information on a, so the protocol is private.

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

5 5.1

161

A Protocol Implementing Unconditionally Secure Two-Party Computations Setup Phase

In this stage, Alice and Bob contact the trusted center and receive pre-distributed commitments, OTMP and multiplication gates. We call the union of these primitives a One-Time Computation. 5.2

Input Stage

Here, Alice and Bob share their inputs with each other and commit to their inputs by using the pre-distributed commitments which where received during the setting phase. For instance, let x be one of Alice’s inputs. She chooses two random numbers xa , xb such that x = xa + xb mod p. She then sends xb to Bob and commits to xa by sending [xa ] to Bob. Bob does the same with his inputs. 5.3

Computation Stage

During the computation stage, Alice and Bob evaluate the circuit being computed gate by gate. Below, we describe how additions and multiplications can be securely performed. As addition and multiplication gates are suﬃcient for the implementation of any ﬁnite function it will imply our desired result. Addition Alice and Bob would like to compute c = x + y. Alice has xa , ya (her shares of the inputs) and [xb ],[yb ] (commitments to Bob’s shares of the inputs). Similarly, Bob has xb , yb (his shares of the inputs) and [xa ],[ya ] (commitments to Alice’s shares of the inputs). To compute new shares and commitments to the sum of these values, Alice and Bob just need to sum the shares and commitments they respectively hold. At the end of the protocol Alice has ca = xa + ya and [xb ] + [yb ] = [xb + yb ] = [cb ], due to the linearity of the commitment scheme. Bob has cb = xb + yb and [xa ] + [ya ] = [xa + ya ] = [ca ]. As desired, ca + cb = c and Alice and Bob are committed to ca and cb respectively.

Multiplication To obtain a multiplication procedure from the multiplication gate of Section 4 we use an idea of [9]. Here, Alice and Bob would like to compute c = xy. Alice has xa , ya (her shares of the inputs) and [xb ],[yb ] (commitments to Bob’s shares of the inputs). Similarly, Bob has xb , yb (his shares of the inputs) and [xa ],[ya ] (commitments to Alice’s shares of the inputs). Their goal is to have at the end of protocol Alice in possession of ca , [cb ] and Bob of cb , [ca ] such that ca +cb = c = xy. We have c = xy = (xa +xb )(ya +yb ) = xa ya +xa yb +xb ya +xb yb . For the computation of xa ya they need to use the OTMP primitives of the section 2.2, as Alice has both values. The same for xb yb . So we can assume that Alice is now committed to xa ya and Bob is committed to xb yb . For xa yb we use the

162

Anderson C.A. Nascimento et al.

multiplication gate, i.e., we obtain u, v such that Alice is committed to u, Bob is committed to v and u + v = xa yb . Analogously we can commit Alice to d and Bob to f with d + f = xb ya . Now Alice and Bob just have to add up the commitments they hold. If Alice sums up, xa ya , u and d she obtains a value ca . Bob obtains a value cb by summing xb yb , v and f . Now ca + cb = xy. The security of the protocol follows from the security of OTMP, multiplication gates and pre-distributed commitments. 5.4

Opening Stage

During the opening stage, Alice and Bob open the commitment to the result of the computation. If both parties accept this result, the computation terminates successfully. Here, fairness becomes an issue and in order to achieve it, we can adapt techniques from [8]. The protocol proposed in [8] is based on the assumption that oblivious transfer is available to Alice and Bob. As oblivious transfer can be pre-distributed by the trusted center[19] the results of [8] hold here (of course, the resulting protocol complexity will be increased). Another more eﬃcient solution is to relax the condition that the trusted center never takes part in the protocol after the setup phase. The trusted center could be called to open commitments of cheating parties (parties refusing to open a commitment). A similar idea was also used in [1]. 5.5

Protocol Complexity

We analyze the complexity of our protocol in terms of round complexity, communication complexity and required memory. Round Complexity. Additions are implemented non-interactively due to the linearity of our commitments. Multiplications require one round of communication. Required Memory. Each commitment used in our protocol requires the players to store 2 ﬁeld elements. OTMPs are more expensive, they require the prover to store 9 ﬁeld elements and the veriﬁer to store 6 ﬁeld elements. Multiplication gates require each player to store 9 ﬁeld elements. As each multiplication uses 2 OTMPs and 2 multiplication gates, the players should store 33 ﬁeld elements in order to perform a single multiplication. Communication Complexity. No communication is needed to perform additions. To perform a multiplication, each player sends 8 elements to the other party.

6

Conclusions

We proposed a very simple and eﬃcient protocol for unconditionally secure two-party computations over GF (q). Our solution works under the commodity based cryptography model as proposed by Beaver [4]. It is based on novel

Unconditionally Secure Homomorphic Pre-distributed Bit Commitment

163

veriﬁable primitives (one time multiplication proofs, multiplication gates and predistributed commitments) in the commodity based model which allow two players to perform secure multiplication of shares over GF (q) with round-complexity equal to one. The veriﬁability of the protocol is not based on any cut-and-choose argument or expensive zero knowledge proofs. We leave as an open problem to ﬁnd an eﬃcient protocol for secure two-party computation in the commodity based model with a constant number of rounds (independent of the number of multiplications).

References 1. N. Asokan, Victor Shoup, Michael Waidner,“Optimistic Fair Exchange of Digital Signatures”, IEEE Journal on Selected Areas in Communications, vol 18, n. 4, pp. 593–610 (2000) 2. D. Beaver: “Foundations of Secure Interactive Computing”, CRYPTO 1991: 377391, 1991. 3. D. Beaver: “Eﬃcient Multiparty Protocols Using Circuit Randomization”, CRYPTO 1991: 420-432, 1991. 4. D. Beaver: “Commodity-Based Cryptography (Extended Abstract)”, STOC 1997: 446-455, 1997. 5. D. Beaver: “One-Time Tables for Two-Party Computation”, COCOON 1998: 361370, 1998. 6. C. Blundo, B. Masucci, D.R. Stinson, and R. Wei: “Constructions and Bounds for Unconditionally Secure Non-Interactive Commitment Schemes”, Designs, Codes, and Cryptography, Special Issue in Honour of Ron Mullin,26(1-3): 97-110 (2002). 7. D. Chaum, C. Crepeau, and I. Damgard: “Multiparty Unconditionally Secure Protocols (extended abstract)”, STOC 1988: 11-19, 1988. 8. R. Cleve: “Controlled Gradual Disclosure Schemes for Random Bits and Their Applications”, CRYPTO 1989: 573-588, 1989. 9. C. Crepeau, J. van de Graaf, and A. Tapp, “Committed Oblivious Transfer and Private Multi-Party Computations”, CRYPTO 1995: 110-123, 1995. 10. O. Goldreich: Secure Multi-Party Computation, lecture notes, available from http://www.wisdom.weizmann.ac.il/˜oded/pp.html 11. M. Ben-Or, S. Goldwasser and A. Wigderson, “ Completeness Theorems for NonCryptographic Fault-Tolerant Distributed Computation”, 20th STOC, pp. 1-10, 1988. 12. S. Goldwasser and L.A. Levin: “Fair Computation of General Functions in Presence of Immoral Majority”, CRYPTO 1990: 77-93, 1990. 13. G. Hanaoka, J. Shikata, Y. Zheng, and H. Imai: “Unconditionally Secure Digital Signature Schemes Admitting Transferability”, ASIACRYPT 2000: 130-142, 2000. 14. J. Kilian: “Founding Cryptography on Oblivious Transfer”, STOC 1988: 20-31, 1988. 15. T. Matsumoto and H. Imai: “On the Key Predistribution Systems: A Practical Solution to the Key Distribution Problem”, CRYPTO 1987: 185-193, 1988. 16. S. Micali and P. Rogaway: “Secure Computation (Abstract)”, CRYPTO 1991: 392404, 1991. 17. A.C.A. Nascimento, J. Mueller-Quade, A. Otsuka, and H. Imai: “Unconditionally Secure Homomorphic Commitments”, AAECC 2003: 87-97 ,2003.

164

Anderson C.A. Nascimento et al.

18. T. Rabin: “Robust Sharing of Secrets When the Dealer Is Honest or Cheating”, JACM, 41(6): 1089-1109, 1994. 19. R.L. Rivest, “Unconditionally Secure Commitment and Oblivious Transfer Schemes Using Concealing Channels and a Trusted Initializer”, pre-print available from http://theory.lcs.mit.edu/˜rivest/Rivest-commitment.pdf. 20. A.C. Yao, “Protocols for Secure Computations”, FOCS 1982: 160-164, 1982.

The Design and Implementation of Protocol-Based Hidden Key Recovery Eu-Jin Goh1 , Dan Boneh1 , Benny Pinkas2 , and Philippe Golle1 1

Stanford University {eujin,dabo,pgolle}@cs.stanford.edu 2 HP Labs [email protected]

Abstract. We show how to add key recovery to existing security protocols such as SSL/TLS and SSH without changing the protocol. Our key recovery designs possess the following novel features: (1) The Key recovery channels are “unﬁlterable” — the key recovery channels cannot be removed without also breaking correct operation of the protocol. (2) Protocol implementations containing our key recovery designs can inter-operate with standard (uncompromised) protocol implementations — the network traﬃc produced is indistinguishable from that produced by legitimate protocol implementations. (3) Keys are recovered in real time, hence most or all application data is recovered. (4) The key recovery channels exploit protocol features, rather than covert channels in encryption or signature algorithms. Using these designs, we present practical key recovery attacks on the SSL/TLS and SSH 2 protocols. We implemented the attack on SSL/TLS using the OpenSSL library, a web browser, and a network sniﬀer. These tools allow us to eavesdrop on SSL/TLS connections from the browser to any server.

1

Introduction

Intuitively, protocol key recovery means that a third party, by observing network traﬃc, can recover the secret key protecting the data transferred between two parties. Unlike previous key recovery or escrow schemes that work at the level of encryption and signature algorithms [23, 24], our designs use features of the protocol. We also consider practical issues such as ease of deployment and usage. Our key recovery designs possess the following properties. 1. Unﬁlterability Network ﬁlters cannot remove key recovery channels from protocol messages without also breaking the correct operation of the protocol. Previously suggested key escrow schemes and classic covert channels do not have this unﬁlterable property. For example, timing-based channels introduced by Lampson [14] leak secret bits by using small variations in packet transmission time. The timing-based covert channel is easily ﬁltered by a proxy that ensures all packets are sent at regular intervals. Our key recovery designs do not use such channels and cannot be ﬁltered by such proxies. C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 165–179, 2003. c Springer-Verlag Berlin Heidelberg 2003

166

Eu-Jin Goh et al.

2. Inter-operability A protocol implementation with key recovery works seamlessly with other implementations that do not contain key recovery while still supporting key recovery. Keys can be recovered from any protocol session in which at least one of the participating parties support key recovery. For example, a SSL web server with key recovery inter-operates with a standard (uncompromised) web browser while still leaking key information. Note that maintaining the ability to inter-operate precludes protocol changes. Previously suggested key recovery systems [5, 12, 4] require protocol redesigns. 3. Hidden key recovery The network traﬃc generated by a protocol implementation with key recovery is computationally indistinguishable from traﬃc generated by implementations without key recovery. 4. Real time key recovery Session keys are recovered before user data is exchanged. These properties are essential for any practical key recovery scheme. The inter-operability and hiding properties allow incremental (and unnoticeable) deployment of servers and clients with key recovery. Unﬁlterability ensures key recovery channels cannot be easily circumvented. Real time operation allows instant decryption and analysis of application data without large storage requirements.3 In this paper, we design key recovery schemes for SSL/TLS and SSH2 that possess the stated properties. The basic method for adding key recovery to a security protocol is to change how the protocol implementation generates ﬁelds that are “random looking”. For example, when the server needs a random nonce, the server uses the encryption of the session key as the nonce. Assuming the cipher is semantically secure [1], this ciphertext is a valid nonce because it is indistinguishable from a random string.

2

Applications and Threats

In this section, we discuss several consequences of hidden and unﬁlterable key recovery systems. 2.1

Hackers

A hacker can break into a SSL web server and patch the SSL library with hidden key recovery. This attack allows the hacker to eavesdrop on all SSL connections to the server without ever having to access the server again. From the network point of view, there is no detectable diﬀerence between the original and the hacked server. Therefore, it is hard to detect these attacks without host based intrusion detection system such as Tripwire [13]. 3

This property seems well suited for a wiretapping device such as the government’s Carnivore program [9].

The Design and Implementation of Protocol-Based Hidden Key Recovery

2.2

167

Governments

The government can convince major software vendors to distribute SSL/TLS or SSH2 implementations with hidden and unﬁlterable key recovery. Using a Carnivore device, the government can monitor all encrypted connections established using these protocols in which either the client or server has been compromised. Users will not notice the key recovery mechanism because the scheme is hidden. Even savvy users who use a proxy to counter standard covert channels cannot circumvent key recovery because the channels are unﬁlterable. Our designs provide an easy way of deploying a government key recovery system. For example, key recovery enabled web browsers can be installed at public libraries to ensure that criminals and terrorists do not conduct their business using SSL sessions at these facilities. The social and political implications of a government key recovery system are outside the scope of this paper. 2.3

Trusting Closed Source Products

While the design and implementation of security protocols should be left to experts, end users must verify that the implementation correctly follows the protocol. In particular, users should ensure that implementations do not contain the key recovery mechanisms described in this paper. Unfortunately, validating implementations is often impractical. Most commercial software libraries are closed source and can only be validated using black box testing. Black-box testing is carried out by running the product and observing external state (such as generated network traﬃc) to ensure that it works as promised. Hidden key recovery, however, cannot be detected by observing external state. Hence, black-box testing is insuﬃcient for validating security products. Note that checking MD5 ﬁngerprints and standard code signing techniques is also inadequate for detecting compromised implementations. The problem is much harder for hardware implementations of security protocols. Many vendors already sell hardware implementations of IPsec. Next generation SSL accelerators implement the entire SSL protocol in hardware. Note that even FIPS 140-2 [16] certiﬁed hardware must be checked. Indeed, it is harder to verify FIPS level 3 and 4 certiﬁed hardware because they are designed to be tamper resistant. Furthermore, the FIPS certiﬁcation might provide users with a false sense of security. How can end-users ensure that these implementations do not provide hidden key recovery? It is currently an open problem whether there is a way for a closed implementation to prove to the outside world that it is properly following the protocol and does not implement our hidden key recovery. Therefore, it is fair to say that closed source software and hardware implementations of security protocols cannot be fully trusted since it is hard for end-users to validate them.

3

Assumptions and Definitions

We deﬁne some useful terms and also state our assumptions about the operational model.

168

Eu-Jin Goh et al.

Escrow Agency Field (EAF). In our key recovery system, a key (such as a master key or a session key) that enables decryption of network traﬃc is encrypted with another key (the recovery key). The result of encrypting the session key with the recovery key is called the Escrow Agency Field, or EAF.4 The recovery agency can decrypt the EAF using the recovery key. We also assume that the ciphers used for key recovery are semantically secure [1]. Model. We consider three entities, a client-side user, a server-side user and a recovery agency. The client-side and server-side users use a standard protocol P to communicate securely while the recovery agency aims to decrypt their communication. Both users execute P correctly and neither colludes with the recovery agency. Hidden key recovery. Given a cryptographic protocol P with speciﬁed inputs and outputs, let P be a new protocol created with key recovery. Consider a device implementing P which uses a set of keys K, and a device implementing P that knows the same set of keys K (and possibly some other keys that P uses). We say that P contains hidden key recovery if the inputs and outputs of the implementations of P and P are computationally indistinguishable to everyone except the key recovery agency. Hence, P conforms with the speciﬁcations of P , and P can inter-operate seamlessly with all implementations of P .

4

Design and Implementation

In this section, we provide an outline of the techniques for adding hidden and unﬁlterable real time key recovery to existing security protocols. 4.1

Hidden and Unfilterable Key Recovery

Hidden Key Recovery. The basic idea is to embed the Escrow Agency Field (EAF) in protocol ﬁelds containing random looking data. The rationale is that the EAF is a ciphertext; A semantically secure cipher produces ciphertexts that look random to everyone except the recovery agency. Therefore, the EAF or parts of the EAF can be sent in place of any ﬁeld containing random data. For example, when the protocol requires a random nonce, the nonce is replaced with the EAF. Note that we are excluding standard covert channels because they are easy to ﬁlter (see Section 8). We prefer encrypting the EAF using a asymmetric (public key) encryption scheme as opposed to a symmetric (bulk) encryption scheme. If a symmetric encryption scheme is used, every implementation must contain a unique key so as to prevent a system wide compromise by an attacker extracts the key from a single client. On the other hand, a large number of unique keys results in a key 4

This ﬁeld has the same functionality as the Law Enforcement Agency Field (LEAF) in the Escrow Encryption Standard (EES) scheme [5].

The Design and Implementation of Protocol-Based Hidden Key Recovery

169

management nightmare for the recovery agency. If a asymmetric cipher is used, then only the public key is embedded in every implementation of the protocol. In this case, an adversary that reverse engineers a compromised implementation only recovers the public key and cannot decrypt any messages. Unfilterable Key Recovery. For a key recovery scheme to be unﬁlterable, key information must be hidden in ﬁelds that are essential for the correct operation of the protocol. For example, the SSL protocol requires implementations to verify a checksum of all the messages exchanged before the negotiated cryptographic parameters are used. If any message is altered by a third party such as a ﬁlter, the veriﬁcation will fail, halting further communication. 4.2

Real Time Key Recovery

We use the following criteria to determine which messages in a protocol are suitable for real time key recovery — information hidden in a session must be related to the current session key. We can hide information in a message about the current session key only if we have that information before the message is sent. Otherwise, ﬁelds in that message can be used to store older session keys. Encryption keys shared between two parties are usually generated from a combination of secret and public randomness. Either the encryption key or the secret part of the randomness can be escrowed. Since the encryption key is usually smaller than the secret randomness, it appears that the encryption key should always be escrowed. If, however, the only suitable key recovery channels are in messages exchanged before key generation, and one party generates the entire secret randomness, then the system should hide the secret randomness instead. We will see an example of this in SSL. 4.3

Using Low Capacity Channels

In this section, we describe techniques for hiding the EAF in very short ﬁelds. The motivation for developing these techniques is because in many protocols, ﬁelds suitable for key recovery are usually very short and cannot contain the entire EAF. Recall that the EAF is encrypted with the recovery agency’s public key (recovery key). The shortest public key cipher is a variant of the ElGamal cryptosystem over elliptic curves (ECEG) [15]. ECEG produces ciphertext that is 327 bits (≈ 41 bytes) long if the plain text is no greater than 163 bits (≈ 20 bytes). We therefore assume that 41 bytes is the minimum capacity for hiding an EAF encrypted using an asymmetric cipher. We also assume that the ElGamal cryptosystem over standard elliptic curves is semantically secure. How much information to hide. To minimize the EAF size, the key information should be less than 20 bytes. Recall that we can hide either the session key or the secret randomness used to generate session keys. Without loss of generality, we can assume that the key information a compromised implementation

170

Eu-Jin Goh et al.

discloses is shorter than 20 bytes. If the session key or secret randomness is longer than 20 bytes, the compromised implementation can generate them from a short seed (less than 20 bytes) using a pseudo-random generator. This seed is leaked instead of the full key or randomness. Therefore, at most 41 bytes of capacity is required for hiding the ECEG encrypted EAF. Unfortunately, a 41 byte EAF is often larger than the capacity of a single protocol session. We describe three methods for hiding the EAF even if each protocol session has less than 41 bytes of capacity. Method 1. Since a ECEG encrypted EAF cannot ﬁt into the capacity of one session, the EAF is split and distributed over a few sessions. One drawback is that this method cannot support real time eavesdropping. Another drawback is that the recovery agency, to decrypt a particular session, has to assemble and correlate key information recovered over a number of sessions. The recovery agency also has to store all encrypted traﬃc until they can be decrypted. Method 2. Method 2 is a hybrid method that has comparable security to the ﬁrst while mostly providing real time eavesdropping. The compromised implementation performs the following procedure. 1. Picks a random key K for a symmetric cipher. K is used to encrypt the EAFs. Any semantically secure symmetric cipher can be used. 2. Use ECEG with the public key of the recovery agency to encrypt K. Denote E[K] as the encryption of K under the public key of the recovery agency. Recall that E[K] is 41 bytes long. 3. Divide E[K] up into shares so that each share is no bigger than the capacity of a single session. Let i be the number of shares required to reconstruct E[K]. E[K] is then hidden over i sessions. Note that we cannot hide any other information for those i sessions. Erasure codes can be used to divide the EAF into shares to provide redundancy against lost or missed sessions. 4. Once K has been transmitted, the EAF in future sessions is encrypted using the symmetric encryption scheme instead of ECEG. For example, we can use IDEA with key K and 0 IV. One disadvantage is that the recovery agency cannot eavesdrop on the initial i sessions. Another disadvantage is that the recovery agency has to intercept at least i sessions containing E[K]. If less than i sessions are intercepted, the recovery agency cannot eavesdrop until E[K] is sent out again. In fact, it is a non-trivial task to diﬀerentiate between sessions containing encrypted session keys and those containing E[K]. Therefore, this hybrid method is only suitable if the recovery agency can deduce when E[K] is transmitted. Method 3. This method compromises the security of the cryptosystem protecting the EAF for the ability to carry out real time eavesdropping. For example, the compromised implementation can use ECEG with a shorter key to encrypt the EAF. In this case, the largest ECEG key is used to encrypt the EAF, while

The Design and Implementation of Protocol-Based Hidden Key Recovery

171

ensuring that the EAF still ﬁts in the available capacity. One disadvantage is that an adversary can extract the private key from the public key in reasonable time.

5

Overview of TLS

We provide an overview of the Transport Layer Security (TLS) protocol [8] before describing our key recovery attacks on TLS. Readers who are familiar with TLS can proceed to the next section. TLS provides communication privacy and data integrity between applications. TLS is used on the Internet to secure data traﬃc between HTTPS clients and web servers. TLS is the successor to the Secure Socket Layer 3.0 (SSL3) protocol [10]. TLS and SSL3 are very similar and unless otherwise noted, SSL3 shares the same vulnerabilities as TLS. For brevity, we will only describe TLS. TLS runs on top of a reliable transport protocol such as TCP/IP. It consists of two layers, the record protocol and the handshake protocol. The record protocol provides a private connection using symmetric encryption and keyed MACs. The handshake protocol is layered over the record protocol without any cryptographic parameters, and provides peer authentication and shared secret negotiation. A TLS session occurs in two phases. First the handshake protocol is run to authenticate the server to the client (and optionally vice versa). The TLS handshake protocol supports RSA, Ephemeral Diﬃe-Hellman (EDH) and other key exchange algorithms. In this paper, we will only refer to TLS as it is most commonly used with RSA key exchange and server only authentication. The client and server also agree on a symmetric cipher, a MAC function, and a compression algorithm. The cryptographic keys are derived from a combination of a premaster secret chosen by the client and random strings chosen by both parties. Finally, the application’s protocol runs over the record protocol with the cryptographic parameters negotiated in the handshake. Next, we give a simpliﬁed description of the messages exchanged during the handshake protocol. Figure 1 provides an overview of the messages exchanged during a TLS handshake. 1. Client Hello: The client sends a list of supported ciphers, together with 28 bytes of randomness and a 4 byte time-stamp. These 32 bytes make up the client randomness. 2. Server Hello: The server chooses a cipher among those supported by the client. The server also sends 28 bytes of randomness with a 4 byte timestamp and a session identiﬁer (session ID). The session ID can be up to 32 bytes long. The 28 bytes of randomness and the 4 byte time-stamp make up the server randomness. The session ID is used for resuming sessions with previously established cryptographic parameters. 3. Server certificate: The server sends a chain of X509 certiﬁcates to authenticate itself to the client. If requested by the server, the client may also authenticate itself to the server.

172

Eu-Jin Goh et al.

Client

Server Client Hello Server Hello Certificate Server Hello Done Client Key Exchange Change Cipher Spec Finished (encrypted) Change Cipher Spec Finished (encrypted)

Fig. 1. TLS Handshake with RSA key exchange

TLS Record = headers || encrypted data

encrypted data = E data || MAC(headers || data) || pad

Fig. 2. TLS Record Structure. denotes concatenation, E[ ] and MAC() denote symmetric encryption and message authentication. Padding is unnecessary for stream ciphers

4. Client Key Exchange: The client sends a 48-byte premaster secret encrypted with the public key in the server’s X509 certiﬁcate. 5. Client and Server Finished: The client and server separately derive common cryptographic parameters from the shared premaster secret and randomness. They also verify the key exchange and authentication by exchanging the output of a pseudo-random function applied to a hash of all handshake messages and a predeﬁned string. These two messages are encrypted with the negotiated parameters. After the handshake, the server and client share a common set of cryptographic parameters which are used to secure further communication. The format of TLS messages in the record protocol is shown in Table 2.

6

Key Recovery in TLS

In this section, we examine TLS to ﬁnd subliminal channels for key recovery. We then discuss our implementation of the key recovery scheme in TLS and SSL

The Design and Implementation of Protocol-Based Hidden Key Recovery

173

Table 1. Candidate ﬁelds for key recovery in TLS and SSL. These ﬁelds are all unﬁlterable Field CipherSuites Randomness Time stamp Randomness Time stamp Session ID Pad Contents

Whom Size (bits) Frequency Session Restrictions Client a few session current Client 224 session current Client a few session current Server 224 session previous Server a few session previous Server up to 256 session previous Both 52 record current SSL 3.0

3.0. Table 1 summarizes our ﬁndings on which message ﬁelds in TLS can be used for hidden key recovery. Note that the listed channels are unﬁlterable. For each ﬁeld, – Whom: indicates whether the ﬁeld can be used by either the client, the server or both. – Size: the size (in bits) of data that can be hidden in the ﬁeld. – Frequency: indicates whether a ﬁeld can be used once per TLS session or once per TLS record. – Session: describes the most recent session key that can be leaked in the ﬁeld. – Restrictions: indicates any restrictions that may apply to using the ﬁeld. Surprisingly, even the block cipher padding in SSL 3.0 can be used as a channel. We spend the rest of this section describing how to hide information in padding schemes. If a block cipher is used to encrypt the record, the record has to be padded to the cipher’s block size. At ﬁrst glance, the pad seems useless as a subliminal channel because it is encrypted. However, we can manipulate the pad so that its cipher text serves as a subliminal channel. Padding for block ciphers is diﬀerent in TLS and SSL3. We ﬁrst discuss SSL 3.0 padding. SSL 3.0 Padding. The pad can be up to the block size, which is 8 bytes in most ciphers. The last byte of the pad speciﬁes the pad length excluding the last byte. The following code snippet shows how the pad is checked in the OpenSSL implementation of SSL 3.0: // here bs is the block size l=rec->length; i=rec->data[l-1]+1; if (i > bs) return (SSL_ERROR_BLOCK_CIPHER_PAD_IS_WRONG); rec->length-=i;

Only the last byte of the pad is checked because the other bytes are unspeciﬁed in the protocol.

174

Eu-Jin Goh et al.

We assume that the block size is 8 bytes. We can also assume that the data length in the record is a multiple of the block size because the TLS implementation controls the amount of data in each record. If the data length is a multiple of block size, the pad length will be 8 bytes (64 bits). We create a 52 bit subliminal channel in the following manner — ﬁx the ﬁrst 52 bits of the ciphertext to contain the EAF. Next, iterate over the 212 possible values of the last 12 bits of the cipher text block until the decryption of the last byte is 7. We will be able to ﬁnd the desired cipher text with very high probability because we are iterating over 212 possible values. TLS Padding. The pad can be between 0 and 255 bytes if the record size is a multiple of the block size. All bytes in the pad are set to the length of the pad. Only the pad length can be used as a subliminal channel because the content of the pad is speciﬁed. Given an encrypted record, however, we cannot determine the length of either the data or padding segment. As a result, we cannot use the padding in TLS as a subliminal channel. 6.1

Implementation in SSL/TLS

This section describes our implementation of key recovery in SSL/TLS. Hidden and Unfilterable Key Recovery. The TLS implementation containing key recovery should be indistinguishable from standard TLS. We can achieve this goal by using only the subliminal channels listed in Table 1, which are all unﬁlterable. We ignore the lower capacity channels and focus on the client randomness, server randomness and server Session ID. Real time Key Recovery. To carry out key recovery in real time, the EAF for a TLS session must contain key information for the current session. Examining the session column in Table 1, we see that only the client randomness ﬁeld and the pad contents (for SSL 3.0) are suitable. Session keys in SSL 3.0 and TLS are created by applying a pseudo-random function (PRF) to the concatenation of the public client randomness, public server randomness, and premaster secret. When RSA is used for key exchange, the client creates the premaster secret. The client can generate the session keys only after it receives the server random in the Server Hello message. Unfortunately, the only channel suitable for real time key recovery is the client randomness ﬁeld found in the ﬁrst message exchanged. Therefore, the only way to carry out real time key recovery using a compromised client is to hide the premaster secret instead of the session key. The client can leak the premaster secret in the Client Hello message because the client generates the entire premaster secret when RSA key exchange is used. Even if the server does not contain key recovery capabilities, the client can compromise the communication between them. If Diﬃe-Hellman key exchange is used, the client creates only part of the premaster secret. In this case, the client cannot compromise the secure connection without the help of the server.

The Design and Implementation of Protocol-Based Hidden Key Recovery

175

On the other hand, the server can only generate the session keys after it receives the encrypted premaster secret in the Client Key Exchange message. Therefore, it is impossible to implement real time key recovery in TLS on the server. Although real time key recovery on a SSL 3.0 server is possible, it is infeasible because of the small capacity of the pad contents channel. Furthermore, it is only possible if a block cipher is selected as the symmetric encryption algorithm. We shall concentrate on implementing key recovery in the client. Low Capacity Channels. Recall an ECEG encrypted EAF is 326 bits (41 bytes) long. The client randomness ﬁeld, however, is only 28 bytes long. If a block cipher is used with SSL 3.0, we can use the pad as another channel. The pad has a capacity of 6.5 bytes, giving a total of 34.5 bytes (276 bits). The premaster secret comprises of 46 securely generated random bytes and 2 bytes denoting the client’s TLS version. The client version is a public value sent in the Client Hello message. Hence, we only need to leak the 46 random bytes. As suggested in Section 4.3, we leak a small seed of 16 bytes and derive the premaster secret from it. This derivation is done by applying a SHA-1 hash on thirds of the seed. We only use 46 out of the 60 bytes generated by the hashes. To encrypt the EAF, we can use either a short (224 or 276 bits) RSA key (a variant of method 3 in Section 4.3), or the hybrid scheme (method 2). The hybrid scheme leaks the encrypted symmetric key over two handshake sessions, meaning that the recovery agency cannot decipher the traﬃc of these two sessions. Furthermore, if the recovery agency misses either session, it cannot decrypt any traﬃc until the encrypted symmetric key is sent again. Prototype implementation. We implemented a prototype for the client side key recovery scheme in SSL 3.0 and TLS using OpenSSL [17], a free SSL library. For SSL 3.0, we implemented the hybrid scheme where we use ECEG to protect a 128 bit IDEA key and leak it over two handshakes. We use IDEA in CBC mode to protect the 16 byte seed used to generate the premaster secret. ECEG was implemented using routines provided by Miracl [19]. For TLS, we implemented a variant of method 3 which uses a short (224 bit) RSA key to protect the EAF. Both TLS and SSL 3.0 required only a few lines of additional code to call on our key recovery routines. The key recovery routines are contained in a source ﬁle containing about 400 lines of unoptimized C code. These key recovery routines can be reused for other protocols. The small amount of extra code added to both protocols demonstrates the ease of implementing key recovery. We compiled w3m [11], a web browser, with the modiﬁed SSL library to show compromised HTTPS connections. We also modiﬁed ssldump [18], a SSL packet sniﬀer, to serve as the recovery agency. It decrypts the EAF to obtain the premaster secret which is used to generate the session key. The sniﬀer then decrypts the session traﬃc and prints out the decrypted contents. We do not handle session resumes in our implementation but this can be easily added. The computational overhead imposed by key recovery is trivial compared to the total amount of work done by the client. For SSL 3.0, the IDEA key is generated and encrypted with ECEG oﬀ-line. Hence, no extra work is carried

176

Eu-Jin Goh et al.

out by the client during the initial two SSL handshakes. Subsequent handshakes incur the cost of a encrypting the premaster secret seed with IDEA. For TLS, every handshake incurs the cost of an RSA operation with a very short modulus. Note that the EAF can be generated and encrypted oﬀ-line.

7

Key Recovery in SSH Version 2

In this section, we describe a simple hidden and unﬁlterable real time key recovery attack on SSH2. SSH2 Overview. SSH is a secure shell protocol designed to replace insecure login mechanisms such as telnet. Version 2 of the protocol (SSH2) is designed by the secsh working group in the IETF [20] to solve the ﬁrst version’s shortcomings. Like TLS, SSH2 is divided into several layers. The lowest layer is the Transport Layer Protocol, which runs over TCP/IP. The Transport Layer is analogous to the Record Layer in TLS. The next layer is the Authentication Protocol, which runs over the Transport Layer. The last layer is the Connection Protocol, which runs over the Authentication Protocol. We will focus on the Transport Layer Protocol. All messages in SSH2 are carried at the Transport Layer by the Binary Packet Protocol. This protocol deﬁnes the record structure shown in Table 2. The packet length ﬁeld is the byte length of the packet, not including itself or the MAC. The length of the padding must be between 4 to 255 bytes, and the padding should consist of random bytes. Furthermore, both block and stream ciphers are required to pad the structure so that the total size (in bytes) of the second to ﬁfth ﬁelds is either a multiple of the cipher block size or 8, whichever is larger. The payload length ﬁeld is calculated by the following equation — payload length = packet length - pad length - 1. The length ﬁelds, payload and padding are included in the computation of the MAC. Table 2. Format of a SSH2 Binary Packet ﬁeld type

ﬁeld description

unsigned int (32 bits) byte byte[payload length] byte[pad length] byte[mac length]

packet length pad length payload random padding MAC

SSH2 Key Recovery. When SSH2 is used as the secure equivalent of telnet, a packet is sent and returned for almost every keystroke. This mode of usage results in a network traﬃc pattern consisting of a large number of small packets

The Design and Implementation of Protocol-Based Hidden Key Recovery

177

exchanged between the server and client. Furthermore, every packet contains a single keystroke, resulting in only 1 byte of payload per packet. The total size of the second, third, and fourth ﬁeld is 6 bytes. According to the padding rules stated in the previous paragraph, there will be at least 8 bytes of ciphertext derived directly from the pad. In SSL 3.0, the last byte of the padding speciﬁes the pad length. In contrast, the pad length in SSH2 is speciﬁed in a separate ﬁeld. The pad contents are speciﬁed as random bytes. In a single packet, 8 bytes of the EAF can be hidden as the ciphertext of the pad. For our key recovery attack on SSH2, the symmetric key used to encrypt the binary packets is hidden in the EAF. If ECEG is used to encrypt the EAF, the EAF can be completely disclosed in 5 to 10 packets sent by only one party. The probability of either the client or server sending at least 10 packets is very high because of the network traﬃc pattern. Comparison to SSL. For the padding attack to be viable in SSL 3.0, the symmetric encryption algorithm has to be a block cipher. In SSH2, however, padding is required for all symmetric encryption algorithms, including stream ciphers. Hence, SSH2 is always vulnerable to our key recovery attack. In addition, either the client or the server can carry out the key recovery attack.

8

Related Work

This paper draws on contributions from two complementary lines of research — key escrow mechanisms and subliminal channels. In contrast to previous work, we examine the threat of key escrow through subliminal channels at the protocol level rather than the cryptosystem level. Key escrow refers to methods allowing participants to hold encrypted communication while a third party holds the secret key for the communication. A basic key escrow scheme takes the session key, encrypts it using an escrow agency’s key, and sends this information together with the encrypted session data. Key escrow received a large amount of attention with the (failed) introduction of the Escrow Encryption Standard (EES) [5] by the US government. Proposed key escrow schemes at the protocol level, such as the EES, rely on known key escrow ﬁelds such as the LEAF. Blaze showed that the LEAF is ﬁlterable [2]. Denning [4], Kilian and Leighton [12] provides a survey of key escrow schemes. Simmons [21] gave the ﬁrst deﬁnition of subliminal channels are deﬁned as means to convey information in the output of a cryptosystem such that the information is hidden to everyone except the escrow party. Simmons also gives the ﬁrst practical example of a subliminal channel for ElGamal signatures [22]. Desmedt et. al. provide another example using the Fiat-Shamir authentication protocol [7]. As a solution, Desmedt advocates the use of active wardens to eliminate the possibility of subliminal channels in a variety of protocols [6]. Young and Yung [23] investigated subliminal channels in public key cryptography. In their paper, the compromised key generation algorithms selects keys for the RSA and ElGamal public key cryptosystems such that the public key

178

Eu-Jin Goh et al.

reveals the private key to the escrow agency. Young and Yung later expanded and reﬁned these ideas [24]. Lampson mentions a related idea of covert channels [14]. He deﬁnes covert channels as channels that are not intended for information transfer. An example of a covert channel is the timing delay between transmitting network packets. We do not consider covert channels in this paper because they tend to be easily ﬁlterable. For example, if an adversary uses timing delay between messages to hide information, then adding random delays to messages would degrade the channel. Following Desmedt [6], we only consider channels originally intended to exchange information.

9

Summary and Conclusions

We showed how to add unﬁlterable and hidden key recovery to any security protocol. We also described methods for recovering key information in real time, as well as in low capacity channels. We used these methods to carry out our key recovery attacks on SSL 3.0, TLS and SSH2. We implemented a prototype of hidden and unﬁlterable real time key recovery in SSL 3.0 and TLS. Our results show the ease with which hidden and unﬁlterable key recovery is added to existing security protocols. In particular, we can undetectably add key recovery without changing the protocol. Our prototype implementation illustrates the danger of trusting closed source and hardware implementations of security protocols. It is not easy to design security protocols that resist our hidden key recovery attack. Canetti and Ostrovsky [3] deﬁne a model of distributed computation with honest-looking parties and prove some initial results on the feasibility of secure function evaluation in this model. It is currently an open problem to build a practical conversion procedure that will translate any security protocol into a protocol that will remain secure in the presence of honest looking parties. Despite this, protocol designers should still consider this family of attacks when designing security protocols. The authors of SSH state that SSH2 was “not designed to eliminate covert channels”. As we have shown, it is particularly easy to carry out our key recovery attacks on SSH2 because of its cipher padding scheme. Our attack on SSH2 will be seriously hindered if the protocol used a padding scheme similar to the one used in TLS. We have only examined SSL 3.0, TLS and SSH2. Our ideas will apply equally well to other security protocols such as IPsec and Kerberos.

References [1] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway. Relations among notions of security for public-key encryption schemes. In H. Krawczyk, editor, Proceedings of Crypto 1998, volume 1462 of LNCS, pages 26–45. Springer-Verlag, Aug 1998. [2] M. Blaze. Protocol failure in the escrowed encryption standard. In Proceedings of the 2nd ACM Conference on Computer and Communications Security, pages 59–67. ACM, ACM Press, Nov 1994.

The Design and Implementation of Protocol-Based Hidden Key Recovery

179

[3] R. Canetti and R. Ostrovsky. Secure computation with honest-looking parties: What if nobody is truly honest? In Proceedings of the 31st Symposium on Theory of Computing, pages 255–264. ACM, ACM Press, May 1999. [4] D. Denning. Descriptions of key escrow systems. Technical report, Georgetown University, Feb 1997. http://www.cs.georgetown.edu/∼denning/. [5] D. Denning and M. Smid. Key escrowing today. IEEE Communications, 32(9):58– 68, 1994. [6] Y. Desmedt. Abuses in cryptography and how to ﬁght them. In S. Goldwasser, editor, Proceedings of Crypto 1988, volume 403 of LNCS, pages 375–389. SpringerVerlag, Aug 1988. [7] Y. Desmedt, C. Goutier, and S. Bengio. Special uses and abuses of the FiatShamir passport protocol. In C. Pomerance, editor, Proceedings of Crypto 1987, volume 293 of LNCS, pages 21–39. Springer-Verlag, Aug 1987. [8] T. Dierks and C. Allen. The TLS protocol. RFC 2246, Jan 1999. [9] FBI. Carnivore diagnostic tool. http://www.fbi.gov/hq/lab/carnivore/ carnivore.htm. [10] A. Freier, P. Karlton, and P. Kocher. The SSL protocol version 3.0. http://www.netscape.com/eng/ssl3/draft302.txt, Nov 1996. [11] A. Ito. w3m: text based browser. http://w3m.sourceforge.net/. [12] J. Kilian and T. Leighton. Fair cryptosystems, revisited: A rigorous approach to key-escrow. In D. Coppersmith, editor, Proceedings of Crypto 1995, volume 963 of LNCS, pages 208–221. Springer-Verlag, Aug 1995. [13] G. H. Kim and E. H. Spaﬀord. The design and implementation of Tripwire: A ﬁle system integrity checker. In Proceedings of the 2nd ACM Conference on Computer and Communications Security, pages 18–29. ACM, ACM Press, 1994. [14] B. Lampson. A note on the conﬁnement problem. Communications of the ACM, 16(10):613–615, Oct 1973. [15] A. J. Menezes and S. A. Vanstone. Elliptic curve cryptosystems and their implementations. Journal of Cryptology, 6(4):209–224, 1993. [16] National Institute of Standards and Technology. Security requirements for cryptographic modules. FIPS 140-2, NIST, Jun 2001. http://csrc.nist.gov/publications/fips/. [17] OpenSSL Project. http://www.openssl.org/. [18] E. Rescorla. ssldump version 0.9b2. http://www.rtfm.com/ssldump/. [19] M. Scott. MIRACL - Multiprecision Integer and Rational Arithmetic C/C++ Library v. 4.6. http://indigo.ie/∼mscott/. [20] secsh IETF Working Group. http://www.ietf.org/html.charters/secshcharter.html. [21] G. J. Simmons. The prisoners’ problem and the subliminal channel. In D. Chaum, editor, Proceedings of Crypto 1983, pages 51–67. Plenum Press, Aug 1983. [22] G. J. Simmons. The subliminal channel and digital signatures. In T. Beth, N. Cot, and I. Ingemarsson, editors, Proceedings of Eurocrypt 1984, volume 0209 of LNCS, pages 364–378. Springer-Verlag, Apr 1984. [23] A. Young and M. Yung. The dark side of “black-box” cryptography, or: Should we trust Capstone. In N. Koblitz, editor, Proceedings of Crypto 1996, volume 1109 of LNCS, pages 89–103. Springer-Verlag, Aug 1996. [24] A. Young and M. Yung. Kleptography: Using cryptography against cryptography. In W. Fumy, editor, Proceedings of Eurocrypt 1997, volume 1233 of LNCS, pages 62–74. Springer-Verlag, May 1997.

Intrinsic Limitations of Digital Signatures and How to Cope with Them Ueli Maurer Department of Computer Science ETH Zurich CH-8092 Zurich, Switzerland, [email protected]

Abstract. Digital signatures are a core enabling technology for the automation and digitization of business and government processes. Despite the slow progress in their use for non-repudiation services, there is little doubt that in a few years digital signatures will be a key mechanism in digital business applications. A fundamental intrinsic problem with digital signatures is that they are not linked to any event in the real world, even if enhanced with time stamps and other conﬁrmation information. It is inherently impossible to determine when, where, how, and by whom a digital string was generated. A user takes the abstract risk to be liable for a signature generated without his consent, for instance because of a security problem in the system, a ﬂaw or ambiguity in the user interface, a ﬂaw in the cryptographic mechanism, fraud or errors in the certiﬁcation process, or any other of many possible reasons. The goals of this paper are to discuss the role and limitation of digital signatures and to propose digital declarations as a simple new concept for coping with these limitations. The user signs, in addition to the digital document, the recording of a conscious act related to the document, thereby conﬁrming his consent. Some possible embodiments are the digital recording of the user’s voice, an image, or a video stream. Like a conventional signature, a digital declaration assures that the signer is guaranteed to be aware of whether and what he agreed to and signed, which is essential to make a denial meaningful and thus possible. Digital declarations can also provide a substantial additional level of security. Moreover, they can improve user acceptance by lowering the psychological barrier for committing to a public key, allow illiterate people to participate in e-commerce, facilitate the adoption of signature legislation, and substantially reduce the technical security requirements and hence the overall systems cost.

1

Introduction

Perhaps the main paradigm shift of the emerging information society is that digital information, like software, digital multi-media content, or digital signatures, are becoming a key ingredient of business and government processes and, C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 180–192, 2003. c Springer-Verlag Berlin Heidelberg 2003

Intrinsic Limitations of Digital Signatures and How to Cope with Them

181

more generally, of many activities in the society at large. The full consequences of this paradigm shift seem far from well-understood and remain to be seen, but without doubt they will be far-reaching. 1.1

Digital Signatures as Evidence: Promises and Obstacles

In view of the continuing automation and digitization of many business processes, the transmission, storage, and veriﬁcation of physical evidence, like signed contracts, presents a major problem. In contrast to physical evidence, digital evidence (like digital signatures, certiﬁcates, and time stamps) is easy to transmit, archive, and search. Moreover, digital evidence is generally unambiguous because its veriﬁcation corresponds simply to the evaluation of a well-deﬁned mathematical predicate (e.g. the signature veriﬁcation predicate relative to a given public key). For these reasons, digital signatures promise to provide an elegant solution to the non-repudiation problem in the digitally operating economy. Furthermore, due to the conjectured security of the underlying cryptographic mechanisms, digital signatures also promise substantially higher security compared to conventional signatures, and hence fewer disputes and simpler dispute resolution. Despite the promises, in the context of non-repudiation services digital signatures are currently used only in isolated applications. We are still far from an internationally operational framework and infrastructure. Some of the obstacles are (temporary) technological problems (e.g. integrating PKI-technology into smart-cards and mobile devices), the lack of internationally applicable laws, the lack of standardization, the lack of viable business models for fostering the creation of a global PKI, problems with the integration into business processes, and, last but not least, the abstractness and complexity of the subject matter, resulting in slow user acceptance. A diﬀerent but related obstacle is the intrinsic problem with digital evidence, which is the subject of this paper. 1.2

Goals and Outline of the Paper

In this paper we discuss the fundamental intrinsic problem with purely digital evidence, like a digital signature, that it is not linked to any event in the real world. It is inherently impossible to determine when, where, how, and by whom a digital string was generated. Digital declarations are proposed as a cost-eﬀective pragmatic solution. Legislation is discussed in this paper only at an abstract and generic level, without referring to the various national approaches and their similarities and diﬀerences. Current legislation is not our primary concern as future legislation will adapt to new research results and business practices, including those proposed here. Throughout the paper one should keep in mind that the main purpose of collecting evidence is not to resolve disputes, but to avoid them in the ﬁrst

182

Ueli Maurer

place, by deterring misbehavior. Actual disputes are the rare exception and the technical and legal procedures must therefore be pragmatic, simple and as light-weight as possible, but suﬃciently well-deﬁned to enable actual dispute resolution if needed. In Section 2 we discuss the role of conventional signatures in the context of the non-repudiation of a contract. In Section 3 we analyze the process of entering a contract, for collecting evidence, and for resolving a dispute, at an abstract level. In Section 4 we discuss the use of digital signatures as digital evidence and the intrinsic limitations, and in Section 5 we present digital declarations as a solution to the described problems. Section 6 provides a concluding discussion of some main points.

2

On the Role of Conventional Signatures

As a motivation for this paper, it is instructive to discuss the role of conventional hand-written signatures and why they are so useful in practice. despite the fact that their technical security is generally quite low. Conventional signatures are a pragmatic and ﬂexible mechanism. For obvious reasons, they are generally not applicable for on-line transactions, but understanding their usefulness and value in a conventional setting can help us better understand the corresponding issues in the context of digital transactions. An idealized (but of course na¨ıve) view of the use of conventional signatures can be described as follows. A user’s signature is well-deﬁned, for instance by a master copy he has deposited. In case of a dispute, a signature allegedly issued by the user can be compared to his master signature. If one assumes that forged signatures can be recognized, then a signature is convincing evidence for the person’s consent to the signed document. In practice, however, things are quite diﬀerent from this idealized view. First, most people’s hand-written signatures are not very diﬃcult to forge for a dedicated forger. In fact, some signatures like those often used by illiterates (e.g. “xx”) can trivially be forged. Second, in most settings (except for example in a bilateral business relationship with a bank), a person’s master signature is neither deposited nor deﬁned. Third, a person could use a signature diﬀerent from the master copy in order to be able to later repudiate it. To avoid this last problem, the other party would have to have on-line access to the signer’s master signature. Therefore the value of a hand-written signature is not primarily that it is diﬃcult to forge, but rather that it creates a situation in which a person knows whether or not he or she signed, thus guaranteeing his awareness of performing a conscious and willful act, as discussed in more detail in Section 3. Similarly, forging a signature also requires a conscious act. Due to this guaranteed awareness, the denial of having signed a document is a precise and meaningful claim, equivalent to the (serious) claim that the signature is forged. Requesting the alleged signer to testify takes a conscious denial to an even more serious level. The importance of a typical contract would

Intrinsic Limitations of Digital Signatures and How to Cope with Them

183

not justify perjury. This is a main reason why there are only rare disputes about who signed a document. Most actual disputes are about the interpretation of the content of a contract, a problem we can ignore in this paper. The described view on conventional signatures is in sharp contrast to what digital signature achieve. The existence of a digital signature does not imply the guaranteed awareness of the alleged signer of the act which caused the signature generation. A signature could have been computed by a virus, because of another security problem, a ﬂaw or ambiguity in the user interface, a ﬂaw in the cryptographic mechanism, fraud or errors in the certiﬁcation process, or any other of many possible reasons. Therefore a signer cannot meaningfully deny that a signature was generated by him, even if the probability of the potential problems listed above can be reduced by (expensive) security technology. Rather, a denial is equivalent to the quite useless claim that the user is not aware of having issued a signature.

3

Contracts and Evidence

In this section we discuss, at an abstract level, contract signing, non-repudiation, the role of evidence and witnesses, and the reason why guaranteed signer awareness is important. Evidence is used in this section as a general term, and the special case of digital evidence is discussed in Section 4. 3.1

Entering a Contract

A basic act in business and other contexts is to enter an agreement, often called a contract, between two (or more) entities. Such an agreement requires the clear mutual understanding of all relevant parameters, in particular the terms and conditions. An agreement is valid only if both parties entered it. It is generally understood that a contract has been entered by a user or entity only if he or she (or an authorized representative) performed a well-deﬁned conscious and willful act, for instance by shaking hands and/or by signing a paper document. In order to prepare for a possible future dispute, each party to a contract wants to keep suﬃcient evidence for the fact that the other party performed the relevant act conﬁrming agreement to the contract. This is a symmetric goal, although the evidence gathered by each party may be diﬀerent. Here we consider only one side of the symmetric problem1 : How can an entity V obtain suﬃcient evidence E that the other party U entered the contract C, i.e., that U performed an act A which conﬁrms agreement to C. A typical example, relevant in this paper, is a user U who orders a product or service (for instance a banking transaction) on-line from company V. One can distinguish three types of evidence: physical evidence, statements by witnesses, and digital evidence. A typical example of physical evidence is a signed 1

We leave out of consideration the theoretically interesting, but in many practical settings not very relevant fair-exchange problem, namely that the evidence should be exchanged simultaneously, with no party gaining a temporary advantage.

184

Ueli Maurer

paper document. A typical example of digital evidence is a digital signature. The role and limitations of digital signatures will be discussed in Section 4. 3.2

Basic Requirements

At an abstract level, the two basic requirements for a procedure for U to enter a contract C with V are as follows. – Feasibility. It is feasible for U to perform an act A, resulting in evidence E, which V accepts as suﬃcient to convince a judge if necessary.2 – Unforgeability (security). The risk that convincing evidence E (for the claim that U performed an act A conﬁrming agreement to C) is generated without U’s consent is small enough to be acceptable for U. These two requirements are inherently conﬂicting. As in most other contexts, there is a trade-oﬀ between feasibility and security. As a coarse classiﬁcation, one can perhaps distinguish the following three levels of unforgeability of evidence: – Lowest level: Forging the evidence may be easy but requires a dedicated (e.g. legally prohibited) act of forgery, i.e., it cannot be generated accidentally. An example is a handwritten signature which in many cases is quite easy to forge, but a forgery requires a conscious act. – Medium level: Forging the evidence is technically non-trivial, though perhaps possible for a dedicated powerful forger. An example might be a video showing a person performing a certain act. – Highest level: Forging the evidence is virtually impossible. An example is perhaps the signature and testimony by a notary. For most applications it is infeasible to achieve the highest level. But even the lowest level can be suﬃcient for a pragmatic solution, as the use of conventional signatures illustrates. 3.3

Witnesses and Guaranteed Signer Awareness

It is often too expensive or infeasible to generate evidence that is by itself suﬃciently convincing. For example, a signed contract alone, if denied by one party, is usually not suﬃcient evidence (see the discussion in Section 2). This is why witnesses are needed to resolve disputes, at least as a last resort when the evidence and the parties’ statements remain conﬂicting. However, for most types of contracts (e.g. an on-line transaction) it is impossible, too expensive, or impractical to arrange for an external witness to be present when U performs act A (e.g. clicks “OK”). In this case, the only reasonable alternative for resolving a dispute is to let U and/or V testify as witnesses. 2

For example, in an e-commerce context, feasibility requires that the customer U need not physically meet the seller V.

Intrinsic Limitations of Digital Signatures and How to Cope with Them

185

This signiﬁcantly reduces the chance of false statements because perjury is considered a signiﬁcant crime and punished severely. For most contracts, perjury is not worth the risk of being so convicted. But using an involved party U as a witness is useful only if it is guaranteed that he or she can indeed testify, i.e., if there is a clear (preferably yes/no) question which he can deﬁnitely answer and which, under the assumption that it is answered correctly, would resolve the dispute. This requires that U is guaranteed to be aware of the correct answer because then answers like “I don’t know” or “I am not sure” are unacceptable and can reasonably be held against him. Guaranteed awareness assures that in a dispute, one of the parties is necessarily consciously lying, and hence makes a request to testify meaningful. This fact prevents false denials in the ﬁrst place, avoiding the need for actual dispute resolution.

4

Digital Evidence and Its Limitations

4.1

Non-repudiation Based on Digital Signatures: A Common View

In simpliﬁed terms, a quite common view of how digital signatures could be used for non-repudiation services is as follows. Each user commits to a public key, i.e., declares liability for documents of certain types correctly signed relative to his public key.3 A public-key certiﬁcate issued by a trusted certiﬁcation authority (CA) can be used as evidence for this commitment. Certiﬁcates (or public keys) can be revoked if the need arises, for instance when the private key is lost or leaked. If the public key has not expired nor been revoked at the time of signing, then the user is liable for the signed contract. This requires the ability to determine whether a signature was generated prior to a certain time. For this purpose, one can ask a trusted time stamping service to issue a time stamp. For example, a time stamp on a document (in this case a signature) is a signature by the time stamping authority on the document together with the time when the time stamp was issued. Hence it is, like the signature itself, purely digital information. More generally, the entire evidence resulting from a digital signature process, including certiﬁcates, time stamps and other possible conﬁrmation information like certiﬁcate validation messages, is purely digital. 4.2

Definition and Discussion of Digital Evidence

The entire digital evidence relevant in a given context can be thought of (and represented as) a single bitstring s, even if it consists of several parts (e.g. a digital signature, certiﬁcates, time stamps, and certiﬁcate validation information). 3

A user’s commitment to a public key would typically involve signing a paper document, which in addition to the public key can also specify an expiration date, an upper bound on the value of a transaction, or other limitations of liability. These parameters must be correctly reﬂected in the certiﬁcate.

186

Ueli Maurer

The veriﬁcation of such digital evidence s corresponds to the evaluation of a Boolean predicate v : {0, 1}∗ → {True, False} and is hence unambiguous. The predicate v summarizes the entire veriﬁcation computation that needs to be performed, including the veriﬁcation of the signature, the certiﬁcates, the time stamp, etc. A string s is accepted if and only if v(s) = True. Conceptually, to be committed to a signature public key means to be committed to such a predicate v : {0, 1}∗ → {True, False}. If somebody manages to produce a bitstring s for which v(s) = True, then the committed user is liable for whatever s is evidence for. We call this the digital liability exposure of a user, meaning that the mere appearance of a bitstring s, independently of how, when, and where it was generated, makes the diﬀerence whether or not the user is liable. The fundamental intrinsic problem with purely digital evidence is that it is not linked to any event in the real world. This point deserves some further discussion. One might be tempted to argue that a time stamp guarantees when the evidence was generated. But the time stamp is itself digital and as such not related to time. A time stamp should be interpreted as providing an additional level of security, since forging a time stamp (and the signature) can be assumed to be more diﬃcult than forging the actual signature alone. More precisely, the time stamping authority can be seen as the user’s delegate, with high security standards, trusted (by him) to issue a time stamp (and hence cause liability) only with the correct time. But obviously, if somebody manages to forge the signature and the time stamp, plus the other possible parts of s required to yield v(s) = True, then the user is liable. This view may still seem to be somewhat odd, as the circumstances of how s was generated really do seems to matter. For example, one could try to argue that the digital evidence s is needed only as evidence, possibly together with other (physical) evidence, to conclude that the user performed a well-deﬁned act (i.e., clicked “OK”) on the user interface, and that it is this act which implies liability, not the digital evidence. But the core question is whether or not the digital evidence can make the diﬀerence between liable and not liable. If it never can, because a decision is always ultimately based on other evidence, then it is useless and should not be applied in the ﬁrst place. If it can make a diﬀerence, which is indeed the case in any envisioned scenario for using digital signatures, then the above arguments apply, namely that the mere appearance of a bitstring s satisfying v(s) = True implies liability. This is a problem one needs to address. There is a trade-oﬀ between the usefulness of digital evidence on one hand and the digital liability exposure on the other hand. Digital evidence that is relevant only in rare cases is not useless and would not justify the investments into the necessary infrastructure.

Intrinsic Limitations of Digital Signatures and How to Cope with Them

4.3

187

The User’s Abstract Risk

As recognized by legislators, the use of digital signatures is problematic because of the described digital liability exposure. The owner of a public key is forced to take the substantial and abstract risk to be liable for signatures generated without his consent. What happens when indeed a digital signature shows up for which the user has absolutely no explanation? There are many reasons why this could happen. Some are discussed below. 1. The secret key could have leaked to a third party, for instance due to a security problem in the system or a timing or power attack on the user’s smart-card. 2. The signature could have been generated by the user’s system, but without his consent, for instance due to a virus or other malicious software component on the system with the inserted smart-card. The virus could either a) call the smart-card without the user being aware, or b) display a contract diﬀerent from that actually signed. 3. The signature could have been generated by the user’s system, without any inﬂuence from an outsider or a virus, but nevertheless without the user’s consent and awareness. This could happen for instance if a) the user interface is not suﬃciently clear about which action (e.g. clicking “OK”) initiates the signature generation, b) the user does not carefully follow all the required steps, perhaps because he does not understand the complex matter, or c) another person is using the user’s system or secure signature device. Another possibility is that the user simply forgot that he actually completed a transaction. 4. The cryptographic signature function might be broken, meaning that somebody has found a way to either compute a user’s private key from his public key, or to generate signatures for a given public key without knowing the secret key.4 5. The certiﬁcate could be false, for instance because of a criminal CA employee or because the CA’s private key is compromised. When a user is confronted with a signature (for his public key) for which he has no explanation, the user has no clue which of the above reasons applies. Therefore he cannot even meaningfully deny a digital signature. 4

Current proposals for digital signature schemes depend on the assumed computational hardness of a very speciﬁc mathematical problem, for instance factoring large integers. It is conceivable that a fast algorithm for solving this problem will be discovered. Even worse, such a discovery might not necessarily be reported to the public.

188

4.4

Ueli Maurer

The Envisaged Solution for the Digital Evidence Dilemma

As discussed above, no matter how a system is designed and how legislation is set up, purely digital evidence does imply liability. The envisaged approach to solving this dilemma, followed in certain legislations, is as follows. In order for digital signatures to be legally binding, both the technical infrastructure and the processes must satisfy very high security standards so that it appears virtually impossible that a signature is generated without the user’s consent. Some of the requirements are: 1. Very high security standards for the CA’s technical infrastructure, processes, and personnel supervision and recruitment. 2. High security margins in the choice of the cryptographic security parameters. Possibly use of several signature schemes in parallel. 3. The user interface is required to be highly unambiguous, essentially excluding any misunderstandings by the user.5 4. The user’s private key is stored in a very secure device, without possibility to extract it.6 Signatures are generated in the device. Because of the described virus attack, the device should ideally have its own input and output mechanisms, for instance a keyboard (at least a conﬁrmation button) and a display. 5. The security of a device could be increased further by a biometric identiﬁcation mechanism, allowing only the designated user to activate the device. There is an obvious trade-oﬀ between the achieved level of security on one hand and the cost and practicality on the other hand. Moreover, even if the technical security is carried to an extreme (and impractical) level, it is impossible to eliminate all sources of uncertainty. For instance, no such solution can prevent a disaster in case the cryptographic signature scheme were broken.

5

Digital Declarations: A Pragmatic Approach

5.1

The Awareness Issue

As described above, a digital signature, even if time-stamped or otherwise conﬁrmed, cannot imply that a user agreed to a certain document. Even worse, it does not even imply that the user is aware of the fact that the document was signed, let alone of its content. This is in sharp contrast to hand-written signatures, as described in Section 2. The user is forced to be aware of the act of signing, and since one is supposed not to sign a document without reading it, it is also reasonable to conclude that he is aware of the content. A previously proposed technique for addressing the awareness problem is to ask a user to type a certain word or text on the keyboard. The correctness of the 5 6

However, this also requires more advanced skills on the user’s part. Smart-cards may actually not be suﬃciently secure.

Intrinsic Limitations of Digital Signatures and How to Cope with Them

189

typed character sequence is checked before activating the signature generation. However, this solution does not solve the problems described in Section 4.3. All it can guarantee is that, provided the entire system is working correctly, a user will not accidentally perform the act required to activate the signature generation. Thus it solves only problems 3a) and 3b) of the list in Section 4.3, but it does by no means prove that he performed the act. Similarly, biometric identiﬁcation technology can only solve problem 3c). 5.2

Digital Declarations

We propose a new solution to address the full list of problems stated in Section 4.3. The user performs some act related to the relevant contract, and this act is recorded digitally and combined with characteristic information of the digital document. This is called a digital declaration. In a typical implementation, the digital declaration can be signed together with the actual digital document. It can also be time-stamped. Digital declarations can be embodied in many diﬀerent ways. As an example, a user ordering a product on-line might be asked to speak a certain sentence referring to the product, the price, and the date of purchase.7 As another possibility, the willful act could be documented by a digital image, a video sequence, or by any other recording device possibly invented in the future. Future implantation technology can open another host of possible applications. Digital declarations can be an essential feature of future digital transaction systems. Some of the reasons are: – – – – – –

guaranteed user awareness, higher deterrence of misbehavior, hence fewer disputes, improved security compared to conventional signatures, lower cost8 due to reduced technical security requirements, improved user acceptance of digital signature technology, and usability by moderately educated people.

Let us expand on some of these points. 5.3

A Discussion of Digital Declarations

A digital declaration guarantees a user’s awareness, the most crucial property of conventional signatures. Therefore a user can, in case of a dispute, request 7

8

It should be pointed out that digital declarations are diﬀerent from current standard practices like the recording of phone conversations in the context of brokerage services. The digital declaration is recorded by the user’s device and typically signed together with the digital document. There is no cost for extra hardware as one would the recording hardware of the same device that people are using for other purposes, for example a next-generation mobile phone.

190

Ueli Maurer

the digital declaration to be presented, say in court. Like for a hand-written signature, the user has the possibility to deny the digital declaration. When confronted with the declaration (e.g. the speech signal) he knows precisely whether or not it is forged. Hence a denial is equivalent to the claim that the declaration is forged, bringing such a claim to the same (serious) level as the claim that a particular conventional signature is forged. A user can therefore meaningfully be forced to testify. The refusal to deny the digital declaration can reasonably be taken as evidence against the user. This fact is not only essential in a dispute, it helps prevent fraudulent denials in the ﬁrst place. Most types of digital declarations (like a voice recording) are non-trivial (though not impossible) to forge and oﬀer considerably improved security compared to, say, conventional signatures. Future recording technologies may even be much harder to forge. But digital declarations make of course sense even if they are considered only moderately hard or even easy to forge, as long as a forgery requires a dedicated act. Moreover, they would typically be used together with digital signatures. It is quite possible that some future e-commerce solutions will involve human sales representatives, for various reasons, including the potentially improved sales eﬃciency and the costumers’ need to obtain speciﬁc advice. In such a case, documenting part of the human interaction in the signed contract, i.e., using digital declarations, is a very natural possibility. A digital declaration makes sense even if it is not checked by the recipient, for instance by a human operator. In fact, in the context of e-commerce, it may not even be possible to completely verify a declaration because the person whose voice or image is recorded need not yet be known to the on-line shop. Even in such a case, the digital declaration makes sense if customers can generally be assumed to be honest at the time of the order but must be deterred from later repudiating the transaction. User acceptance is a key issue in e-commerce. Digital declarations lower the psychological barrier for using digital signature technology for non-repudiation services. One knows that if worse comes to worst one could request a digital declaration to be presented, with the possibility of denying it. It is impossible to give such an assurance with the currently envisaged use of digital signatures. Yet another advantage of digital declarations is that they are very intuitive and hence can be used by a substantially larger, moderately educated user community. Perhaps the most important reason for using digital declarations is that they can allow to establish a reasonable compromise between cost eﬀectiveness, user friendliness, security, and legal issues. For the envisaged use of digital signature technology, suﬃciently secure hardware may be too expensive for cost-sensitive large-scale applications. It can be expected that legislation will be adapted to new technical solutions, and digital declarations are closer to a conventional legal understanding. The commercial success of a new technology (e.g. digital signatures) is often determined not by the technology itself but by the cost, the

Intrinsic Limitations of Digital Signatures and How to Cope with Them

191

user friendliness, and the adequacy of the underlying business model. Digital declaration can change this model.

6

Concluding Remarks

A basic dilemma in digital signature legislation (more generally digital evidence legislation) is to specify what constitutes a user’s commitment to a digitally signed contract. Is it the existence (more precisely, the presentation) of the digital signature on the contract, or is it the user’s act (interacting with some user interface) which initiates the computation of the signature? It cannot be both. Both viewpoints are problematic. In the ﬁrst approach, there is not even a chance for the user to argue, when confronted with a valid signature, that he did not sign. However, as was argued in this paper, the fact that purely digital evidence does imply liability is unavoidable. Otherwise digital signatures would be useless. This is true even if digital declarations are used in connection with digital signatures, but in this case the digital signature is less important as it matters primarily when the digital declaration is ambiguous. In the second approach, where it is the act that counts, the digital signature is only supporting evidence for the fact that the user performed the relevant act. In this case it is relevant which other evidence is accepted in a dispute. There is a dilemma: Either a user has no reasonable and fair chance of denying a signature he has not issued (because the signature generation process is supposed to be so secure that errors can virtually be excluded), or the usefulness of digital signatures is severely limited because the recipient of a signature bears the risk of a later denial, which he cannot inﬂuence. This dilemma is intrinsic. The only viable solution appear to be digital declarations, as described in this paper. To make an example, suppose one would allow a user to deny a digital signature because he provably had no access to his signature device at the time of signing. Moreover, it may even be evident that nobody else had access to the device, perhaps because it is known to have been destroyed at the time the signature was generated, or because the device’s biometric identiﬁcation mechanism is known (and testiﬁed by the experts) to be totally secure. If both claims are correct, this implies that the signature could not have been generated in the device. However, accepting such reasoning would be unfair towards the recipient of the signature as he has no way to check these facts. It would open the door for fraudulent denials and would undermine the envisaged advantages of using digital signatures. For example, some witnesses could conﬁrm that the device was destroyed before the signature in dispute was generated. In practice, technology is always used in a pragmatic balance between security on one side and cost-eﬃciency and convenience on the other side, often giving security actually a lower priority. This is often justiﬁed by the underlying business model which determines who takes the risk in case of a security problem. A prime example are credit card transactions which are quite insecure from a technical viewpoint, but the business model still seems to work, despite quite massive fraud. What this paper calls for is a pragmatic solution in the area

192

Ueli Maurer

of non-repudiation of on-line transactions. It seems that the security demands by legislation and other players may have been too high in the past, and this is probably one of the reasons for the slow adoption of digital signatures and public-key infrastructures in practice. There is deﬁnitely room for ﬁnding a more pragmatic and cost-eﬃcient balance. It was unavoidable to make simpliﬁcations in this paper, especially with respect to legislation and how the legal system works. Many subtle aspects were ignored, some of which the author may not be aware of. The paper contains no references because any speciﬁc selection would appear to be arbitrary. However, we refer the interested reader to two classical books [1,2] on security technology. The views on digital signatures presented in this paper also lead to a new interpretation of the role of certiﬁcation authorities, time stamping authorities, certiﬁcate expiration, certiﬁcate revocation, and many other aspects of a publickey infrastructure. For example, a certiﬁcate could be interpreted as the digital statement by the CA that it (the CA) holds physical evidence (a signed document) of the user’s commitment, which it could present if the need arises. In this view, the CA can be seen as the signature recipient’s delegate, and the certiﬁcate owner need not even trust the CA because the certiﬁcate alone, without the physical evidence, implies no liability. These ideas will be presented in a separate paper.

References 1. A.J. Menezes, P.C. van Oorschot und S.A. Vanstone, Handbook of Applied Cryptography, Boca Raton: CRC Press, 1997. 2. B. Schneier, Applied Cryptography, Wiley, 2nd edition, 1996.

On the Security of Fair Non-repudiation Protocols Sigrid G¨ urgens1 , Carsten Rudolph1 , and Holger Vogt2 1

Fraunhofer – Institute for Secure Telecooperation SIT, Rheinstrasse 75, 64295 Darmstadt, Germany {guergens,rudolphc}@sit.fraunhofer.de 2 SRC Security Research & Consulting GmbH, Graurheindorfer Str. 149a, 53117 Bonn, Germany [email protected]

Abstract. We analyzed two non-repudiation protocols and found some new attacks on the fairness and termination property of these protocols. Our attacks are enabled by several inherent design weaknesses, which also apply to other non-repudiation protocols. To prevent these attacks, we propose generic countermeasures that considerably strengthen the design and implementation of non-repudiation protocols. The application of these countermeasures is ﬁnally shown by our construction of a new fair non-repudiation protocol.

1

Introduction

In many applications for electronic business and other binding tele-cooperations one essential security requirement is that either all parties reach their goals or no party reaches its goal. In other words, the protocols have to provide fairness. Furthermore, undeniability of an exchange of data may be required for commercial transactions. While non-repudiation can be provided by standard cryptographic mechanisms like digital signatures, fairness is more diﬃcult to achieve. A variety of protocols has been proposed in the literature to solve the problem of fair message transfer with non-repudiation. One possible solution comprises protocols based on a trusted third party (TTP) with varying degree of involvement. In protocols published at ﬁrst, the messages are forwarded by the TTP. A more eﬃcient solution was proposed by Zhou and Gollmann [ZG96]. Here, the TTP acts as a light-weighted notary. Instead of passing the complete message through the TTP and thus creating a possible bottleneck, only a short term key is forwarded by the TTP and the encrypted message is directly transferred to the recipient. Based on this approach, several protocols and improvements have been proposed. Recent evolution of these protocols resulted in eﬃcient, optimistic versions where the TTP is only involved in case anything goes wrong and resolve and abort sub-protocols shall guarantee that every party can complete

This research was performed while the last author was at Darmstadt University of Technology.

C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 193–207, 2003. c Springer-Verlag Berlin Heidelberg 2003

194

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

the protocol in time without having to wait for actions of the other potentially malicious party [KM00, ZDB99, ZDB00]. These protocols only require that the communication channels to and from the TTP are asynchronous, which means that messages are delivered after an arbitrary but ﬁnite amount of time. As no messages are lost, this guarantees a response from the TTP in the resolve and abort sub-protocols. Remarkably, many of the proposed protocols do not satisfy all security properties they are supposed to provide. Possible attacks are not based on the underlying ideas but are enabled by several inherent design weaknesses concerned with details of the realization. This observation has motivated the development of the design principles proposed in this paper. The remainder of the paper is structured as follows. After deﬁning fair nonrepudiation with timeliness we demonstrate attacks on two protocols for eﬃcient fair non-repudiation with timeliness. Some of these attacks are related to previously published ones [BK00, GR]. Next, the design weaknesses enabling the attacks are discussed and design principles to avoid these known attacks are proposed. Finally, we introduce a new eﬃcient protocol that has been developed in accordance with our design principles.

2

Fair Non-repudiation Respecting Timeliness

This paper concentrates on message transfer protocols with certain security properties: Party A sends message M to party B, such that A can prove that B has received M (non-repudiation of receipt) and B can prove that A has sent M (non-repudiation of origin). Furthermore, the protocol should not give the originator A an advantage over the recipient B, or vice versa (fairness) and both parties should be able to reach, without depending on the other party’s actions, a state where they can stop the protocol while preserving fairness. Non-repudiation of origin and non-repudiation of receipt require evidence of receipt (EOR) and evidence of origin (EOO). All parties participating in the protocol have to agree that these constitute valid proofs that the particular receive or send event has happened. In case of a dispute an arbitrator or judge has to verify EOO and EOR. Therefore, for every non-repudiation protocol one has to specify what exactly constitutes valid EOO and EOR. This can be done by specifying the veriﬁcation algorithm the judge has to execute in order to verify the evidence for dispute resolution. Even in fair non-repudiation protocols there are intermediate states where one party seems to have an advantage, for example, if a TTP has transmitted evidence ﬁrst to one party and the other party is still waiting for the next step of the TTP. We say a protocol is fair if at the end of the protocol execution no party has an advantage over the other party. This means that if there is an unfair intermediate situation for one party this party must be able to reach a fair situation without the help of other untrusted parties. For any party P we say a protocol execution has ended for P if either P has executed all protocol steps or any remaining protocol step depends on the execution of protocol steps

On the Security of Fair Non-repudiation Protocols

195

by other untrusted parties. We say a protocol execution is completed for P if the protocol execution has ended and P can be sure that no action by any other party enables P to continue with the protocol execution. In this paper we consider a reﬁned version of the deﬁnition of fair nonrepudiation with strong fairness and timeliness by Kremer, Markowitch and Zhou [KMZ02]. We specify the security goals relative to the role in the protocol. The security goal of the originator of a message has to be satisﬁed in all scenarios where the originator acts in accordance with the protocol speciﬁcation while the recipient may act maliciously. In contrast, the security goal of the recipient has to be satisﬁed in scenarios where the originator can act maliciously. Deﬁnition 1. A message transfer protocol for originator A and recipient B provides fair non-repudiation with timeliness if the following security goals are satisfied for all possible messages M . Security goal for A: Fair non-repudiation of receipt At any possible end of the protocol execution in A’s point of view either A owns a valid EOR by B for message M or B has not received M and B has no valid EOO by A for M . Security goal for B: Fair non-repudiation of origin At any possible end of the protocol execution in B’s point of view either B has received M and owns a valid EOO by A for M or A has no valid EOR by B for M . Security goal for A and B: Timeliness At any possible state in the protocol execution each party can complete the protocol without any action of other malicious parties.

3

Attacks on Two Non-repudiation Protocols

In this section we show diﬀerent attacks on two non-repudiation protocols that are supposed to provide fairness and respect timeliness. One protocol was proposed by Kremer and Markowitch [KM00, KMZ02]. This protocol has been analyzed in [KR01]. Several other protocols [MK00,MK01,KM01] build on this protocol. The second protocol is a very similar protocol proposed by Zhou, Deng and Bao [ZDB99,ZDB00], which has already been analyzed and improved in [BK00]. Both protocols (which we will call KM protocol and ZDB protocol, respectively, in the remainder of this paper) use an oﬄine TTP, i.e. a TTP is involved only in case of incorrect behavior of a malicious party or of a network error. The basic idea of the main protocol part not involving the TTP stems from [ZG96]. The structure of the two protocols is very similar. However, small details in the protocol design permit several diﬀerent attacks. Both protocols are designed to provide fair non-repudiation with timeliness as described in Deﬁnition 1 and both realizations are based on the same ideas. We ﬁrst describe the general idea of the two protocols. Then we explain the diﬀerences and possible attacks. – Party A generates a label L the purpose of which is to link all protocol messages.

196

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

– In the ﬁrst step of the main protocol, message M is sent to B encrypted using a symmetric key K computed by A: C = eK (M ). Only after evidence of origin and receipt for C are exchanged (EOOC and EORC , essentially the respective signatures on L and C), A sends K to B. B can then decrypt M and evidence of receipt and origin for K are exchanged (EOR and EOO, essentially the respective signatures on L and K). – Two sub-protocols abort and resolve involving a trusted third party TTP shall provide fairness and timeliness. – The abort sub-protocol can be invoked by A at any stage of the protocol. If no resolve has happened before, the TTP conﬁrms the abort and a future resolve is prevented for this combination of A, B and label L. – Missing evidence of origin or receipt of key K and the missing key itself can be obtained by either party by using the resolve sub-protocol. As the ﬁrst message of the main protocol includes K encrypted with the public key of the TTP (ET T P (K)), the TTP can extract this key and therefore produce a signature CONK that serves for B as evidence of origin of K, and for A as evidence of receipt of K. Furthermore, TTP can submit K to B. 3.1

Reuse of ET T P (K) in a Diﬀerent Context

The ﬁrst message of the main parts of both protocols essentially consists of L, C, the respective EOOC , ET T P (K), and a signature subK by A which can be used by B in the resolve sub-protocol. This signature is supposed to conﬁrm to the TTP that A has submitted the key K in the particular context, identiﬁed by participating parties and label L. A subtle diﬀerence in the content of subK enables our attack against the KM protocol which is not possible in the ZDB protocol. In the KM protocol, subK contains only items sent as parts of the ﬁrst message, in particular it contains ET T P (K), while in the ZDB protocol the key K itself is signed. Thus in the KM protocol B can produce a valid subK for a diﬀerent context, i.e. with the same ET T P (K) but diﬀerent parties and label. By using this subK in a resolve sub-protocol of a new exchange while stopping the ﬁrst exchange after having received EOOC , B gains K and A does not receive any evidence of receipt. Thus, the protocol is unfair for A. This attack is not possible in the ZDB protocol because knowledge of K is necessary to generate a valid subK . 3.2

Sending Wrong subK or EK

On the other hand, signing the plaintext K has the drawback that B is not able to check the validity of the signature subK . This enables a diﬀerent attack on the ZDB protocol published by Boyd and Kearney [BK00] which is not possible in the KM protocol. By sending an invalid subK A can prevent the termination of B. However, the improved version proposed in [BK00] is susceptible to a similar attack where A sends a wrong ET T P (K). This again prevents B from terminating. In [Zho01] Zhou proposed a variant that is designed to prevent the original Boyd and Kearney attack, but it fails to do so. Instead this variant only works against our new attack.

On the Security of Fair Non-repudiation Protocols

3.3

197

Reuse of Labels and Keys

Both protocols suﬀer from a new attack that is analogous to the attack on the Zhou-Gollmann protocol presented in [GR]. This leads to unfairness for B. We have found several variants of this attack using the analysis method for cryptographic protocols based on the SH veriﬁcation tool as described in [GR]. The attacks are based on the following facts: – The label L = H(M, K) that is supposed to uniquely deﬁne a protocol run and identify messages belonging to this run cannot be veriﬁed by B before the last step. Furthermore, the label cannot be checked by the TTP as well, because the TTP never receives message M . Therefore, A can start a protocol run for some message M but use the wrong label L = H(M, K), and receive evidence of receipt for K either from B (if B does not check the label at all) or from the TTP in a resolve sub-protocol. – Apart from the label (which is chosen by A and cannot be veriﬁed by the TTP) there is no link between the evidence of receipt of K and message M . Therefore, this evidence serves as evidence of receipt of K for a second protocol run that A starts using the same label H(M, K) and this time the correct message M . B’s response provides A with EORC for M matching the evidence of receipt for K from the ﬁrst protocol run. – There is no obvious reason for B to store evidence from past protocol runs, especially if the protocol run was not completed because of a wrong label. – In the second protocol run A can send wrong ET T P (K) and subK to prevent a successful resolve by B. This attack may also be successful against related protocols proposed in [ZDB99, ZDB00, BK00, Zho01]. Remark: The attack involves a risk for A. A has to reuse the key K which is already known to B. Therefore B might be able to decrypt M after the ﬁrst message of the second protocol run and A would not get any evidence of receipt. However, assuming that A is the malicious party and B the honest party being attacked, as long as B acts in accordance with the protocol speciﬁcation B will not try old keys to decrypt a new message. Furthermore, remembering all old protocol runs and performing a check for every new protocol run would be an undesirable overhead for B.

4

Improving the Security of Fair Exchange Protocols

In order to overcome the weaknesses of previous non-repudiation protocols we propose several improvements for their implementation. As our new design principles are quite generic, we aim at improving every kind of fair exchange protocols. Our work is motivated by the observation that successful attacks on fair exchange protocols are often enabled by exploiting a combination of several small design weaknesses. Thus, we suggest some improvements that enhance the

198

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

security of fair exchange protocols step by step. Even if no attacks are known for a protocol with a weak implementation part, we recommend to replace such a part by the strongest available implementation. As soon as new and stronger attacks are developed, such a redundancy of security mechanisms may just turn out to be the surplus of security that is required to defeat such attacks. Our new design principles deal with diﬀerent parts of fair exchange protocols like choosing a unique label, creating correctly formed messages and implementing the TTP. We ﬁrst motivate why some current implementations suﬀer from attacks and then propose our design principles that improve the security. Finally, we give some examples how our improvements should be implemented in practice. The complete picture of a secure implementation is then demonstrated by an example in Section 5. Some of the design recommendations are related to design principles for cryptographic protocols proposed by Abadi and Needham [AN96]. Especially the design principles concerning the construction of messages given in Section 4.2 coincide with some of the principles about explicit communication and naming given in [AN96]. However, before using these principles to security protocols in general one has to check that they apply for the particular scenario. Naming participants, for example, might be inappropriate in a scenario where anonymity is required. 4.1

Unique Labels

Motivation. All messages in a fair exchange protocol should contain a label which is assigned to identify the transaction to which such a message belongs. An ad hoc solution would be that one party simply chooses a random number for this label. However, such a label is not related to a certain protocol run so that it can be reused in a diﬀerent transaction. Due to this reason, the label is often computed as a hash value of some unique identifying information. Non-repudiation protocols often propose a label of the form L = H(M, K), where M is the exchanged message, K is the symmetric encryption key used to encipher this message M , and H is a cryptographic hash function (e.g. the KM protocol and the ZDB protocol use such a label). This construction has the disadvantage that it is impossible to verify the correct computation of this label, until a party receives M and K. Thus, a cheating party can still send a random label and the receiving party will not be able to detect this before the exchange is already performed. A straightforward improvement is to deﬁne a label L = H(H(M ), H(K)) and reveal H(M ) and H(K) to any party that wants to check the creation of the label. While this construction allows to verify the label L, it reveals too much information: If there is only a limited number of possible values for M (e.g. if M is either “yes” or “no”), then the supposed receiver of the message can simply hash all possible values until he ﬁnds the one matching H(M ). Then he knows the message M and can still abort the exchange.

On the Security of Fair Non-repudiation Protocols

199

Design Principles. For a label that is supposed to identify a certain exchange transaction we propose the following security properties: Veriﬁability: The creation of a label should be veriﬁable by anybody. In other words this means that all parties can compute the label on their own and compare this result to the received label. Uniqueness: It should be ensured that a label uniquely identiﬁes a protocol run and the corresponding messages. Choosing the same label again must always result in an identical exchange. This can be ensured by deriving the label from all the information that uniquely identiﬁes this exchange transaction. Secrecy: The values that are used to compute the label must not reveal any additional useful information about the exchanged items. This prevents the label from leaking information. Example. For a non-repudiation protocol the label L can be computed using a cryptographic hash function H like this: L = H(A, B, T T P, H(C), H(K)) The values A, B, and T T P are unique identiﬁers for the participating parties, while H(C) and H(K) exactly determine the exchanged message. As the ciphertext C = eK (M ) is the encryption of message M with a symmetric key K, the message M is uniquely determined by the decryption M = dK (C). The label is constructed with the hash values of C and K, because a receiving party may not be in the possession of C and K. Instead it is suﬃcient to know H(C) and H(K) to check the correct computation of this label. The hash function must be collision resistant, i.e. it must be hard to ﬁnd two values X, X with X = X and H(X) = H(X ). It follows that if two labels L = H(A, B, T T P, H(C), H(K)) and L = H(A , B , T T P , H(C ), H(K )) are equal, then in practice all components must be equal (A = A , B = B , T T P = T T P , C = C , and K = K ), which means that the same message is exchanged by the same parties. The secrecy property is also met for this construction of a label: Revealing C and H(K) does not help an attacker to ﬁnd M , as we assume the encryption C = eK (M ) to be conﬁdential as long as the key K is unknown. Due to the one-wayness of H(K) it is impossible to ﬁnd K, as the probability of guessing a correct symmetric key K and then testing it against H(K) is negligible in practice. 4.2

Construction of Messages

Motivation. In the ZDB protocol [ZDB99, ZDB00] only some parts of the ﬁrst exchange message are signed by the sender. If the TTP detects an error in the unsigned part of this message, it cannot determine the cheating party and thus fails to resolve such a conﬂict. This example shows that not only the correct construction of a message must be veriﬁable, but also the party responsible for an incorrect message should be detectable.

200

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

The KM protocol [KM00, KMZ02] suﬀers from another problem: The encrypted key can be reused in a diﬀerent exchange transaction. As the TTP cannot detect this kind of cheating, it can be misused as a decryption oracle, thus revealing the secret key even if it belongs to a diﬀerent transaction. Design Principles. These observations motivate our design principles for a more secure construction of protocol messages: Authenticity of messages: All message parts should be included in the respective signature (in plaintext or as hash). This proves its authenticity to every recipient. If a part of a message is not included in the signature, then this part cannot be trusted by the recipient. Veriﬁability of messages: Every recipient of a message should be able to verify this message. Such a veriﬁcation of a message includes syntactic checks (e.g., is the data type of the message correct?) as well as semantic checks (e.g., is the message signed by the right party?). Context of messages: It should be possible for the recipient of a message to identify the transaction to which its parts belong. Furthermore, it must be possible to determine the intention of such a message without doubt. Examples. While signing the complete message may be easy to implement, there may be a conﬂict with the veriﬁability of this message: If the signed message contains a value that is not known to one of its intended recipients and has to be kept secret, then the hash of this secret value may be signed instead. If revealing this hash value still preserves the conﬁdentiality of the secret value, the recipient should be provided with this hash value, which enables at least the veriﬁcation of all other parts of the signed message. For example a signature sigA (L, K) of a secret key K may be replaced by the signature sigA (L, H(K)). Here the one-way property of the hash function is suﬃcient to prevent the computation of K from H(K), as the cryptographically secure key K consists of enough random bits to defend against key guessing attacks (i.e. guessing K until H(K ) equals H(K)). Including the hash value in the signature allows signature veriﬁcation, which ensures that the label L has been signed by A. But note that both signatures diﬀer in the fact that the ﬁrst one proves to the veriﬁer that A knows K while the second one only says that A knows H(K). The possibility to identify the intention of a message is important for the security of many protocols: A standard attack is to use a message intended for step k in step k’. This can be prevented (and is prevented by all protocols mentioned above) by including unique ﬂags in the respective signatures. Otherwise, EOOC of the KM protocol could be taken for EORC and vice versa, as the only diﬀerence besides the ﬂags is the party’s name included in the signature. Furthermore, a uniquely chosen label L shows to which exchange transaction this signature belongs. Thus, this label L should be incorporated in every protocol message. In contrast to signed messages that are relatively easy to verify, an encrypted message can only be veriﬁed at decryption, which demands additional care for

On the Security of Fair Non-repudiation Protocols

201

such a construction. A good example is an encryption like ET T P (fK , L, K) that allows a decrypting TTP not only to recover the key K, but also the ﬂag fK and the label L. These values fK and L should then deﬁne the context in which the TTP is allowed to reveal the key K. To prevent attacks on such a ciphertext, the used encryption scheme should provide non-malleability, i.e. it should be impossible to modify this ciphertext to construct a diﬀerent meaningfully related ciphertext. 4.3

TTP Actions

Motivation. In the ZDB and the KM non-repudiation protocol the TTP cannot fully check the validity of the evidence that both parties want to exchange. This leads to the problem that the TTP may send some values that do not construct valid evidence. But as the TTP is trusted by both parties, it should always send correct responses to these parties. In the KM protocol the TTP sends only once the result of its conﬂict resolution to both parties. If one of these parties does not store the respective message, it is impossible to receive it from the TTP again. This leaves such a party in a state of uncertainty, which should be avoided not only for fairness reasons, but also for fault tolerance reasons. Design Principles. These observations lead to the following requirements for the TTP behavior: Meaningful TTP decisions: The decisions of the TTP should have a clear semantics. A resolve decision should guarantee that both parties can gain the desired items. An abort decision (which was initiated by a request of an honest party) should imply that none of the parties can obtain useful information about the desired items. Reply to every request: The TTP should send an answer to every request. This reply should inform the requesting party about the TTP’s current state. This requirement is also important for fault tolerance reasons, as a lost message can be retrieved from the TTP by resending the previous request. Examples. The TTP has to check all items of a resolve request before making any decisions. If they are correct and it can generate the desired items for both parties, the exchange should be resolved. If at least one item is not correct, the TTP should either send a failure message or abort this exchange. In case of abort the TTP should try to determine who is responsible for this cheating attempt and then take the appropriate measures. For example, if one party creates an incorrect message and signs it, this proves its attempt of cheating. The replies of the TTP should be implemented in such a way that contacting the TTP a second time with the same values results in the same answer as at the ﬁrst time, if the ﬁrst request has already been successfully answered (the ZDB

202

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

protocol uses this feature). This can be implemented by simply remembering all previous decisions. However, in practice the storage of the TTP is limited and the exchanged information cannot be remembered inﬁnitely. To overcome this problem, time limits can be used, for example by adding the time parameters start and duration to the label. We do not discuss this further in this paper.

5

An Improved Asynchronous Optimistic Fair Non-repudiation Protocol

According to the guidelines proposed in the previous section we construct a new asynchronous optimistic fair non-repudiation protocol. We ﬁrst give a short description of the protocol messages and then present our improved protocol. 5.1

Deﬁnition of Protocol Messages

Our fair non-repudiation protocol is designed to exchange a message M chosen by party A for a receipt on this message by party B. Party A encrypts the message M using a symmetric cipher with a random key K resulting in a ciphertext C = eK (M ). It is assumed that the message M contains enough redundancy so that decrypting C with a diﬀerent key K will always result in an invalid message M . For example, we can demand that M is a text signed by A and that the symmetric cipher is AES in CBC mode. According to our design principles for a unique label, in Section 4.1 we deﬁned the label L = H(A, B, T T P, H(C), H(K)). This label is veriﬁable by every party that knows A, B, T T P , C or H(C), and K or H(K). Furthermore, we have shown in Section 4.1 that it ensures secrecy and uniqueness. Most protocol messages are signatures on a publicly known unique ﬂag, a unique label identifying the current transaction, and the data to be signed. While the signature ensures authenticity of such a message, the label deﬁnes the context to which this message belongs. – fK , fEOOC , fEORC , fEOO , fEOR , fcon , fabort , faborted : publicly known unique ﬂags that indicate the purpose of a message. – K: symmetric key which is randomly chosen by A – C = eK (M ): symmetric encryption of A’s message M – L = H(A, B, T T P, H(C), H(K)): unique label that is used to link the messages of one protocol run – EK = ET T P (fK , L, K): the key K encrypted with the public key of the T T P . The asymmetric encryption scheme must be non-malleable to prevent any modiﬁcations of the label L. This ensures that this ciphertext cannot be used in a diﬀerent context. – EOOC = sigA (fEOOC , L, EK) – EORC = sigB (fEORC , L, EK) – EOO = sigA (fEOO , L, K): the evidence of origin issued by A

On the Security of Fair Non-repudiation Protocols

203

– EOR = sigB (fEOR , L, K): the evidence of receipt issued by B – con = sigT T P (fcon , L, K): the TTP’s replacement for the evidence of origin and receipt, respectively – sigA (fabort , L): A’s request to abort an exchange – aborted = sigT T P (faborted , L): The TTP’s decision to abort an exchange The goal of our protocol is to exchange non-repudiation evidence, which we deﬁne as follows: NRO evidence for message M = dK (C): A, B, T T P , C, K, and EOO (in case of an exchange without TTP) or con (with TTP involvement). NRR evidence for message M = dK (C): A, B, T T P , C, K, and EOR (in case of an exchange without TTP) or con (with TTP involvement). These evidence can be checked by any party with the following steps: 1. Compute M = dK (C) and L = H(A, B, T T P, H(C), H(K)) 2. Check signature EOO or con (or EOR or con in the case of NRR evidence). Then check that the signing party is mentioned at the correct position in L. If any of these checks fails, the evidence is considered invalid. 5.2

The Fair Non-repudiation Protocol

Our protocol consists, like the KM and the ZDB protocol, of a main part and two sub-protocols for abort and resolve. The main part performs the exchange of non-repudiation evidence as described in Table 1: Table 1. Our fair non-repudiation protocol. A→B B B→A A A→B B

: : : : : :

A, B, T T P , C, H(K), EK, EOOC Compute L and verify EOOC (if not OK, quit exchange) EORC Verify EORC (if not OK, start abort sub-protocol) K, EOO Test whether this constructs a valid NRO evidence (if not, start resolve sub-protocol) B → A : EOR A : Test whether this constructs a valid NRR evidence (if not, start resolve sub-protocol)

We consider a message not being correct and not being received at all equivalent, as in both cases an abort and/or resolve protocol can be started (see below). The purpose of the sub-protocols is to resolve conﬂicts with the help of the TTP. They are executed mutually exclusive, which is ensured by the TTP by

204

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

remembering the previous actions for this label L. The abort protocol is speciﬁed in Table 2: Table 2. The abort sub-protocol for party A. A → TTP : A, B, H(C), H(K), sigA (fabort , L) TTP : If A has sent a valid abort request: If the exchange has been resolved: TTP → A : con Else // exchange not resolved TTP → A : aborted If A has sent an invalid request: TTP → A : Error: invalid request

The validity of an abort request is checked in the following manner: 1. Compute L = H(A, B, T T P, H(C), H(K)). 2. Check that party A (identiﬁed by the ﬁrst value that is hashed for computing L) supplied a valid signature sigA (fabort , L). Only after this check succeeds the TTP executes this abort sub-protocol. The resolve protocol for party P ∈ {A, B} is deﬁned in Table 3: Table 3. The resolve sub-protocol can be started by A or B. P → TTP : A, B, H(C), H(K), EK, EOOC , EORC TTP : If P has sent a valid request: If the exchange has not been aborted: If the exchange has been resolved before or decrypting EK succeeds: TTP → P : K, con If decrypting EK fails (A cheated and no resolve happened yet): TTP → P : aborted Else // exchange aborted TTP → P : aborted If P has sent an invalid request: TTP → P : Error: invalid request

The validity of a resolve request by party P is checked in the following manner: 1. Compute L = H(A, B, T T P, H(C), H(K)). 2. Check that EOOC and EORC are valid signatures generated by the parties named in the ﬁrst and second message item, respectively. Only after these checks succeed, the TTP executes this resolve sub-protocol for P .

On the Security of Fair Non-repudiation Protocols

205

The success of decrypting EK is checked as follows: 1. The TTP decrypts EK using its private key: DT T P (EK) = (fdecrypt , Ldecrypt , Kdecrypt ) 2. Check that fdecrypt ≡ fK , that Ldecrypt ≡ L, and that Kdecrypt was used to compute L. If any of these checks fails, the T T P considers the decryption of EK not successful. This means that A must have generated an incorrect EK on purpose (i.e. A must have tried to cheat), since EK is contained in EOOC . After the TTP processed a valid request for conﬂict resolution, it has to store either (L, state=aborted, aborted) or (L, state=resolved, K, con) forever. If the TTP detects an invalid request, it just notiﬁes the sender, but does not store anything about it. Altogether, the TTP’s reactions guarantee a response to every request and its decision clearly determines whether an exchange is aborted or resolved. 5.3

Protocol Extensions

Transparent TTP. Our protocol can be modiﬁed to make involvement of the TTP transparent for party B, which means that the NRO evidence looks always the same — no matter whether the TTP was involved or not. We simply deﬁne EK as follows: EK = ET T P (fK , L, K, EOO) In the resolve protocol the TTP decrypts DT T P (EK) = (fdecrypt , Ldecrypt , Kdecrypt , EOOdecrypt ) and additionally checks that this EOO is A’s signature on (fEOO , L, K). If all the checks are successful, the TTP will provide EOO instead of con. Making the NRR evidence transparent requires a major modiﬁcation to our protocol. The idea for such a solution is to enable TTP to generate the signature EOR. This can be achieved with cryptographic primitives like veriﬁable encryption (e.g. [ASW98]) or convertible signatures (e.g. [BF98]). Message Conﬁdentiality. Our protocol can ensure message conﬁdentiality if A sends C to B using an encrypted channel (e.g. SSL/TLS). Then even the TTP learns nothing about the exchanged message M .

6

Conclusions

In this paper we have discussed the analysis of two diﬀerent non-repudiation protocols that are supposed to be fair and provide timeliness, but fail to do so. Our analysis has shown that the KM protocol is not fair for the originator A, that the ZDB protocol does not provide timeliness for the recipient B, and that

206

Sigrid G¨ urgens, Carsten Rudolph, and Holger Vogt

both protocols allow an attack which makes them unfair for B. The attack on the KM protocol that results in unfairness for A is possible because the context of the key K encrypted for the TTP is not determined, which enables B to use this message part in a diﬀerent protocol run. The ZDB protocol allows A to send some signature not being veriﬁable by B, thus hindering B from performing a successful resolve sub-protocol. Finally, the attack possible on both protocols uses the fact that, although all signatures contain the same label, the evidence on origin and receipt of ciphertext C and evidence on origin and receipt of K are in fact not connected, thus allowing the latter to be valid in more than one protocol run. Motivated by our analysis, we have presented countermeasures to these attacks that serve as general design principles for fair exchange protocols. Finally we have presented our own protocol that does not allow the attacks possible for the KM and the ZDB protocol. Our protocol is very eﬃcient, as the main protocol part only requires one signature per message, and EOO and EOR consist of only one signature each.

References [AN96]

Mart´ın Abadi and Roger Needham. Prudent engineering practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1):6–15, 1996. [ASW98] N. Asokan, Victor Shoup, and Michael Waidner. Optimistic fair exchange of digital signatures. In Kaisa Nyberg, editor, Advances in Cryptology – EUROCRYPT ’98, volume 1403 of Lecture Notes in Computer Science, pages 591–606, Espoo, Finland, June 1998. Springer-Verlag. [BF98] Colin Boyd and Ernest Foo. Oﬀ-line fair payment protocol using convertible signatures. In Advances in Cryptology – ASIACRYPT ’98, volume 1514 of Lecture Notes in Computer Science, pages 271–285, Beijing, China, October 1998. Springer-Verlag. [BK00] Colin Boyd and Peter Kearney. Exploring fair exchange protocols using speciﬁcation animation. In Information Security – ISW 2000, volume 1975 of Lecture Notes in Computer Science, pages 209–223, Wollongong, Australia, December 2000. Springer-Verlag. [GR] Sigrid G¨ urgens and Carsten Rudolph. Security analysis of (un-) fair nonrepudiation protocols. In Formal Aspects of Security – BCS FASec 2002, volume 2629 of Lecture Notes in Computer Science. Springer-Verlag. to appear. [KM00] Steve Kremer and Olivier Markowitch. Optimistic non-repudiable information exchange. In J. Biemond, editor, 21st Symposium on Information Theory in the Benelux, pages 139–146, Wassenaar, The Netherlands, May 2000. Werkgemeenschap Informatieen Communicatietheorie, Enschede. [KM01] Steve Kremer and Olivier Markowitch. Selective receipt in certiﬁed e-mail. In Progress in Cryptology – INDOCRYPT 2001, volume 2247 of Lecture Notes in Computer Science, pages 136–148, Chennai, India, 16–20 December 2001. Springer-Verlag. [KMZ02] Steve Kremer, Olivier Markowitch, and Jianying Zhou. An intensive survey of fair non-repudiation protocols. Computer Communications, 25(17):1606– 1621, November 2002.

On the Security of Fair Non-repudiation Protocols [KR01]

[MK00]

[MK01]

[ZDB99]

[ZDB00]

[ZG96]

[Zho01]

207

Steve Kremer and Jean-Fran¸cois Raskin. A game-based veriﬁcation of nonrepudiation and fair exchange protocols. In CONCUR 2001 – Concurrency Theory, volume 2154 of Lecture Notes in Computer Science, pages 551–565, Aalborg, Denmark, August 2001. Springer-Verlag. Olivier Markowitch and Steve Kremer. A multi-party optimistic nonrepudiation protocol. In Information Security and Cryptology – ICISC 2000, volume 2015 of Lecture Notes in Computer Science, pages 109–122, Seoul, Korea, December 2000. Springer-Verlag. Olivier Markowitch and Steve Kremer. An optimistic non-repudiation protocol with transparent trusted third party. In Information Security – ISC 2001, volume 2200 of Lecture Notes in Computer Science, pages 363–378, Malaga, Spain, October 2001. Springer-Verlag. Jianying Zhou, Robert Deng, and Feng Bao. Evolution of fair nonrepudiation with TTP. In Information Security and Privacy – ACISP ’99, volume 1587 of Lecture Notes in Computer Science, pages 258–269, Wollongong, Australia, 7–9 April 1999. Springer-Verlag. Jianying Zhou, Robert Deng, and Feng Bao. Some remarks on a fair exchange protocol. In Public Key Cryptography – PKC 2000, volume 1751 of Lecture Notes in Computer Science, pages 46–57, Melbourne, Australia, January 2000. Springer-Verlag. Jianying Zhou and Dieter Gollmann. A fair non-repudiation protocol. In Proceedings of the IEEE Symposium on Security and Privacy, pages 55–61, Oakland, CA, May 1996. IEEE Computer Society Press. Jianying Zhou. Achieving fair non-repudiation in electronic transactions. Journal of Organizational Computing and Electronic Commerce, 11(4):253– 267, December 2001.

Security Analysis of a Password Authenticated Key Exchange Protocol Feng Bao Institute for Infocomm Research 21 Heng Mui Keng Terrace, Singapore 119613 [email protected]

Abstract. A password authenticated key exchange (PAKE) protocol allows two parties who share a memorable password to obtain a common shared cryptographic key. The central security requirement to such a protocol is that the password should not be subject to (oﬄine) dictionary attack. Following the EKE proposed by Bellovin and Merritt in 1992 [1], many PAKE protocols have been proposed. In this paper we give a security analysis to an RSA-based PAKE protocol proposed in ISC’02 [12]. Our analysis shows that the protocol is subject to dictionary attack when the length of the ID of the second party is small; and therefore the security of the protocol is not related to the security parameters such as the size of the RSA modulo n or the length of the hash function. This violates the security deﬁnition of PAKE protocols. Previously welldesigned PAKE protocols do not have this security ﬂaw.

1

Introduction

Password authenticated key exchange (PAKE) is a protocol making two parties who share a memorable password to obtain a common shared cryptographic key. The application of PAKE is mainly for the authentication situation where neither of the parties has a certiﬁed public key, but they share a password which is not long enough to resist brute force attack. An example of the application of PAKE is that a client and a server want to establish a session key while the server has no certiﬁed public key (if the server has a public key and the client has it and its certiﬁcate, there are many ways to establish session keys immune to dictionary attack). The security requirement for a PAKE protocol is that the password should not be subject to the oﬄine dictionary attack. In other words, an attacker, who is allowed to obtain all the communication data between the two parties or allowed to implement the protocol with any of the two parties, cannot compute the password from the obtained data by brute force. The concept of PAKE was ﬁrst introduced by Bellovin and Merritt in 1992 [1] and a set of PAKE protocols called EKE (encrypted key exchange) were proposed in the same paper. In recent years, the research on PAKE attracted much attention and many PAKE protocols have been proposed and studied [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12]. Most of the PAKE protocols, including the EKE protocols, are based on Diﬃe-Hellman key exchange. The possibility C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 208–217, 2003. c Springer-Verlag Berlin Heidelberg 2003

Security Analysis of a Password Authenticated Key Exchange Protocol

209

of using RSA in PAKE was also studied in [1]. However, it was pointed out that the EKE protocols based on RSA are subject to e-residue attack and hence are not secure. In 1997 Lucks proposed an RSA-based PAKE protocol called OKE (open key exchange) in [8]. But it was later found to be subject to a variant of e-residue attack by MacKenzie, Patel and Swaminathan [9], and therefore, is still insecure. In [9], an RSA-based PAKE protocols is proposed, where the e is chosen to be a prime larger than n. That guarantees that the e must be co-prime with φ(n), which is required in order to resist e-residue and its variant attacks. The protocol of [9] remains secure so far. But due to the large e requirement, the computational burden is heavy for both parties of the protocol. In [12], Zhu, Wong, Chan, and Ye proposed an imbalanced PAKE protocol based on RSA. The computation burden for one of two parties is very light such that it is eﬃcient enough for one party(client) to implement the protocol on most of the low-power devices such as devices in sensor networks, smart cards and low-power PDA etc. The protocol is suitable to the imbalanced wireless network environment where a low-power client communicates with a powerful server. In this paper we give a security analysis to the protocol of [12]. Our results show that the protocol is not well designed and has a security ﬂaw. The main problem of the protocol is that the security is not dependent on the security parameters, while it should be and is claimed to be. Our analysis shows that, instead, the security of the protocol is dependent on the length of the second party’s ID. If the ID is not long enough, the protocol is subject to the dictionary attack. All the other well-designed PAKE protocols do not have this problem. For example in the protocol of [9], dictionary attack is impossible not matter how short the ID is, and the security level goes up with the security parameters’ increasing. The protocol of [12] is a kind of sequential PAKE similar to the protocols of [11] and [9], in the sense that the protocol must be implemented sequentially. In sequential PAKE protocols, one party must authenticate the other ﬁrst, then the latter authenticates the former. This is diﬀerent from the ”parallel” PAKE protocols such as EKE, where there is no requirement on the rank of the authentication. A sequential PAKE protocol is like a chain where the security relies on the weakest ring of the chain. In this paper we identify a weak ring in the protocol of [12] which is much weaker than other rings of the protocol. It largely weakens the security of the protocol. We present two dictionary attacks. By the ﬁrst one, an attacker can exclude two passwords in one implementation of the protocol. In the second attack, the password can be found with a probability larger than it should be. The rest of the paper is organized as follows. In Section 2 we will explain what is the security against dictionary attack in PAKE protocols and give two examples for illustration. In Section 3 we describe the protocol of [12]. In Section 4 we present our analysis and point out an easy counter measure. Section 5 concludes the paper.

210

2

Feng Bao

Security against Dictionary Attack

When the EKE protocols were proposed in 1992, there was no formal deﬁnition of PAKE. The form deﬁnition of PAKE was given very recently in [2], [3], [6] in order to have provable security. In this paper we will not repeat the formal deﬁnitions in [2], [3], [6] in a complete formal deﬁnition manner. Instead, we give an intuitive description on what is the security requirement to PAKE and what is the dictionary attack in a short statement. Model of the PAKE Parties involved - Two parties, Alice and Bob. They can be either equal parties or client and server. Password - Alice and Bob share a password that is practically short and memorable, e.g., 6 digits. Security parameters - κ, the size (number of bits) of the protocol parameters. (For example of Diﬃe-Hellman based protocols, κ = |p| where p is the prime modulo; or in RSA based protocols, κ = |n| where n is the RSA modulo.) And l, the length of the one-way hash function used in the protocol. (For example, l = 128 for MD5 and l = 160 for SHA.) κ and l decide the security level of the protocol. protocol parameters - Given the security parameter κ and l , Alice and Bob generate their own parameters for the protocol, such as n = pq or y = g x etc. These can be viewed as the keys. But these keys are never certiﬁed by any trusted third party or CA. Dictionary Attack A PAKE protocol is an interactive protocol between Alice and Bob. After ﬁnishing the protocol, Alice and Bob obtain a common key that is much longer than the password. An attacker who obtains all the data communicated between Alice and Bob must not be able to compute the password by brute force. If the attacker impersonate Alice (or Bob) to implement the protocol with Bob (or Alice), the attacker should not be able to get more information about password than a random guess. In other words, the attacker can only get the password with a probability of 1/|P| by implementing the protocol once, where P is the password domain and |P| denotes the number of possible password. If the authentication fails, the attacker can exclude only one password. This is like the authentication situation of ATM, where a card theft gets nothing else but knowing that a tried PIN is not correct by guessing PIN once. When we say a PAKE protocol is subject to dictionary attack, it does not necessarily mean that the password can be found by brute force. It means that an attacker can get more information than random guess. Definition Let the security parameters of the protocol be (κ, l) and the password space be P. We say that the protocol is subject to dictionary attack if an attacker, by implementing the protocol t times, can obtain the password with a probability larger than t/|P|+Ω(1/poly(κ, l)), where Ω(1/poly(κ, l)) means a non-negligible

Security Analysis of a Password Authenticated Key Exchange Protocol

211

amount in κ and l. Here the attacker is assumed to be computationally powerful larger than O(|P|). Next we give two examples of PAKE protocols subject to dictionary attack. Example 1. (An insecure EKE based on Diﬃe-Hellman) • System parameters: p = 2q + 1 for primes p and q • Password shared by Alice and Bob: w ∈ P Alice password: w

Bob password: w

a ∈random Zp−1 A = wa mod p

b ∈random Zp−1 B = wb mod p A

(1)−−−−−−−−−−−−−−−−→ B

Ka = B a mod p ha = H1 (Ka )

(2)←−−−−−−−−−−−−−−−−

Kb = Ab mod p hb = H2 (Kb )

ha

(3)−−−−−−−−−−−−−−−−→ hb

(4)←−−−−−−−−−−−−−−−− ?

check hb = H2 (Ka )

?

check ha = H1 (Kb )

Fig. 1. The protocol, where H1 and H2 are two diﬀerent one-way functions.

The above PAKE protocol is subject to dictionary attack. An attacker who pretends to be Alice can determine whether B is a quadratic residue modulo p or not. If B is not quadratic residue, w must not be quadratic residue. In that case the attacker can exclude roughly half of P. If B is a quadratic residue, the attacker cannot determine whether w is quadratic residue since b could be an even number. But considering that b is randomly chosen, the probability of b being even number for t times of implementation of the protocol is 1/2t only. Hence the attacker can exclude half passwords except for a probability of 1/2t after t implementations of the protocol with Bob. The counter measure to the attack is simple, just let A = w2a mod p and B = w2b mod p. Example 2 (An insecure EKE based on RSA) • Password shared by Alice and Bob: w ∈ P • A symmetric key cryptosystem: Ekey () • Key domain of Ekey (): K • Challenge domain: C, large enough for security Unlike the parallel protocol in Example 1 where (1) and (2), as well as (3) and (4), can swap, Example 2 is sequential in the sense that (1), (2), (3), (4) must exactly occur according to the rank.

212

Feng Bao Alice password: w

Bob password: w

generate RSA (n, e) IDAlice , n, e

(1)−−−−−−−−−−−−−−−−→ Ew ((K||CB )e mod n)

decrypt K and CB CA ∈random C

K ∈random K CB ∈random C

(2)←−−−−−−−−−−−−−−−−

EK (CA , CB )

(3)−−−−−−−−−−−−−−−−→

decrypt CA and CB check if CB correct

EK (CA )

check if CA correct

(4)←−−−−−−−−−−−−−−−−

Fig. 2. K is the exchanged key if both Alice and Bob pass the check.

The e-residue attack to the protocol is as follows. e-residue attack An attacker pretends to be Alice and implements the protocol with Bob. But the attacker generates n and e such that e is a factor of φ(n). Bob does not know the factorization of n and hence cannot tell whether e is a factor of φ(n) or not. The attacker, after step (2), tries all the possible w one-by-one to see whether the decryption of Ew ((K||CB )e mod n) is an e-residue (e-residue take a small portion of Zn ). Those w’s that lead to non e-residue are apparently incorrect and hence excluded. A counter measure to e-residue attack was given in [9] for RSA-based PAKE, where e must be a prime larger than n. However, this counter measure sacriﬁces the eﬃciency. In the next section we describe the RSA-based PAKE protocol proposed in [12] where the e can be small so that the computation burden to Bob is much lighter than that of Alice.

3

Description of the Protocol

The following protocol is given in [12]. We take the same notations. – Alice and Bob share a password w ∈ P. – Alice generates an RSA public key pair (n, e) using a public key generator and selects rA ∈random {0, 1}l. She sends (n, e) and rA to Bob.

Security Analysis of a Password Authenticated Key Exchange Protocol

213

– Bob checks if (n, e) is a valid public key by using an interactive protocol. If it is invalid, Bob rejects the connection. Otherwise, it ﬁrst picks rB ∈random {0, 1}l and sB ∈random Zn . Then it computes π = T (w, IDA , IDB , rA , rB ) where IDA and IDB are the identiﬁcation information of Alice and Bob, respectively and T : {0, 1}∗ −→ Zn is a cryptographic hash function. Bob sends rB and z = (sB )e + π mod n to Alice and then destroys π from his memory. – Alice computes the corresponding π and obtains the value of sB from the second message of the protocol. She then generates a temporary symmetric key K and Bob’s session key contribution cB by computing G1 (sB ), and G2 (sB ), respectively where G1 : {0, 1}∗ −→ {0, 1}l and G2 : {0, 1}∗ −→ {0, 1}l are two distinct cryptographic hash functions. She then picks her own session key contribution cA ∈random {0, 1}∗ and sends EK (cA , IDB ) to Bob. She later computes the session key σ = G3 (cA , cB , IDA , IDB ) and destroys sB , cA , cB and K from her memory. – Bob computes K and cB from sB accordingly. He decrypts the incoming message and checks if it contains his own identity IDB along with some l-bit binary string. If it is false, Bob terminates the protocol run with failure. Otherwise, he denotes the l-bit binary string as cA and use it as Alice’s session key contribution and computes the session key σ accordingly. He then destroys sB , cA , cB from his memory. h(σ ) is then sent to Alice and the connection is accepted. – Alice checks if the incoming message h(σ ) = h(σ). If it is true, then Alice accepts the connection. Otherwise, it terminates the protocol run with failure. To resist e-residue attacks, the scheme includes an interactive protocol in step 2 and 3 shown in Figure 3. By having Alice returning hash values of the decrypted challenge numbers, that is {H(mi )}1≤i≤N . The hash function H is deﬁned as H : {0, 1}∗ −→ {0, 1}Q (l) where Q is some polynomial function. It is conjectured that in this way, Alice can no longer be used as a decryption oracle in helping an adversary to invert RSA. The complete protocol is presented in Figure 3 that is copied from [12]. Two more methods to generate z from sB and π are also presented in [12]. Method 1. By specifying the RSA encryption algorithm performed over the multiplicative group Z∗n , that is by choosing sB ∈random Z∗n , z is computed as seB · π mod n. Method 2. Let T : {0, 1}∗ −→ {0, 1}|n|−1 and the z is deﬁned as z = y ⊕ π for all y ∈ {0, 1}|n|−1. Since more than half of the elements in Zn is samller than 2|n|−1 , the expected number of times the RSA encryption needs to perform before picking a sB ∈random Zn such that y = seB mod n is only |n| − 1 bits long is less than 2. Our attack in the next Section also applies to the above two methods.

214

Feng Bao

Alice password: w

Bob password: w

generate RSA (n, e) rA ∈random {0, 1}l

n, e, rA

(1)−−−−−−−−−−−−−−−−→ {me i mod n}1≤i≤N

{mi ∈random Zn }1≤i≤N

(2)←−−−−−−−−−−−−−−−− decrypt in RSA mi , i = 1, ..., N

{H(mi )}1≤i≤N

(3)−−−−−−−−−−−−−−−−→ H(mi ) = H(mi ) if yes for all i’s rB ∈random {0, 1}l sB ∈random Zn π = H(w, IDA , IDB , rA , rB ) z = seB + π mod n ?

z, rB

compute sB cA ∈random {0, 1}l K = G1 (sB )

(4)←−−−−−−−−−−−−−−−− K = G1 (sB ) cB = G2 (sB ) EK (cA , IDB )

cB = G2 (sB ) σ = G3 (cA , cB , IDA , IDB )

(5)−−−−−−−−−−−−−−−−→ h(σ )

decrypt and check IDB σ = G3 (cA , cB , IDA , IDB )

(6)←−−−−−−−−−−−−−−−− h(σ ) = h(σ) ?

Fig. 3. The RSA-based PAKE protocol proposed in [12].

4

Security Analysis

In this section we present two dictionary attacks. In the ﬁrst attack, an attacker, impersonating Alice, can exclude two passwords by implementing the protocol with Bob once. The attacker needs to do a large amount of computation equivalent to O(22|IDB | ), where |IDB | denotes the length (number of bits) of IDB . Hence the attack is valid if |IDB | is not too large, say smaller than 20. In the second attack, we require that |IDB | is smaller than the length (number of bits) of password. By implementing the protocol with Bob once, an attacker can get the password with a probability of 1/2|IDB |, which is ∆ larger than 1/|P| where ∆ an amount non-negligible in l and |n|.

Security Analysis of a Password Authenticated Key Exchange Protocol

4.1

215

Attack 1

An attacker impersonates Alice and implements the protocols with Bob and performs as follows. Denote I = |IDB |. 1. 2. 3. 4. 5. 6.

Implement the protocol honestly before message (5). Compute π = H(w, IDA , IDB , rA , rB ) for all the possible w. Compute all the possible sB from z = seB + π mod n. Compute all the possible K from K = G1 (sB ). Randomly pick C ∈random {0, 1}l+I . Decrypt C by all the K’s in step 4. If there are more than one results equal (∗, IDB ), denote the corresponding K’s by K1 , K2 , · · · ; otherwise go back to step 5. 7. Return C as the message (5) in the protocol. 8. Exclude K1 , K2 , · · · if Bob returns fail. 9. If Bob returns message (6), denoted by β, check which sB in step 3 satisﬁes β = h(G3 (cA , cB , IDA , IDB )) where cA is the ﬁrst l bits of the decryption of C with key K = G1 (sB ) and cB = G2 (sB ).

The above attack is based on the assumption that I is not large, but regardless it is larger or smaller than the password length. The encryption EK () is a block cipher with block size much larger than I, e.g., block size is not smaller than 64 but I = 20 or smaller. We will explain later that the protocol is always insecure with stream cipher EK (). In practical case it is possible that IDA and IDB have small size, especially when the total number of users is not large. And previous protocols are secure with small IDs. It is easy to see that the attack has a computation complexity O(22I ). 4.2

Attack 2

An attack impersonating Alice implements the protocols with Bob and performs as follows. We still denote I = |IDB |. 1. Implement the protocol honestly before message (5). 2. Compute π = H(w, IDA , IDB , rA , rB ) for all the possible w. Compute all the possible sB from z = seB + π mod n. 3. Randomly pick C ∈random {0, 1}l+I . Return C as the message (5) in the protocol. 4. If Bob returns fail, stop. 5. If Bob returns message (6), denoted by β, check which sB in step 2 satisﬁes β = h(G3 (cA , cB , IDA , IDB )) where cA is the ﬁrst l bits of the decryption of C with key K = G1 (sB ) and cB = G2 (sB ). This attack is diﬀerent from Attack 1 in the sense that no heavy computation of O(22I ) is required. The attack is valid if 2I < P since it succeeds in getting w with a probability 1/2I . Therefore when |IDB | is shorter than passwords, the protocol is not secure against dictionary attack by the deﬁnition.

216

4.3

Feng Bao

Counter Measure

Both of the above attacks show that the step (5) of the protocol is the weak ring of the chain, which relies on the length of IDB but irrelevant with the security parameters l and |n|. Previous well-designed PAKE protocols do not have this ﬂaw. The ﬂaw in the protocol can be removed by replacing the message (5) with g = G2 (sB , cA ) and cA . Bob checks whether g = G2 (sB , cA ) with the sB he picked preciously, and then decides to reject or not. In this case, the protocol is safe on the aimed security level 2l . Finally we want to point out that the protocol is not secure with a stream cipher EK (). In the man-in-middle attack, an attacker can change the bits of EK (cA , IDB ) that corresponding only to cA . In that case, Bob cannot detect if EK (cA , IDB ) has been changed since the decrypted message still contain IDB . However, Bob get’s a wrong cA . Hence the protocol is not secure in accordance with the formal deﬁnition of security for authentication [13].

5

Conclusion

In this paper we clariﬁed the real meaning of the security against dictionary attack for PAKE protocols although we did not repeat the formal deﬁnition. Then we showed that the protocol proposed in ISC’02 is not secure against dictionary attack by presenting two attacks. The ﬁrst attack requires more computation than the second one. But the second one has an additional requirement that the length of identity must be shorter than the length of password, which the ﬁrst attack does not need. Our result shows that the security of PKKE against dictionary attack is quite tricky and must be very carefully checked. The security of a PAKE protocol may be compromised by even a tiny weakness in some step. Acknowledgement The author would like to thank anonymous referees for valuable feedbacks.

References 1. S. M. Bellovin and M. Merritt, ”Encrypted key exchange: password based protocol secure against dictionary attack”, Proceedings of 1992 IEEE Symposium on Security and Privacy, pp. 72-84, IEEE Computer Society, 1992. 2. M. Bellare, D. Pointcheval and P. Rogaway, ”Authenticated key exchange secure against dictionary attack”, Proceedings of Eurocrypt 2000, LNCS, Springer-Verlag, 2000. 3. V. Boyko, P. MacKenzie and S. Patel, ”Provably secure password-authenticated key exchange using Diﬃe-Hellman”, Proceedings of Eurocrypt 2000, pp. 156-171, LNCS, Springer-Verlag, 2000. 4. L. Gong, M. L. Lomas, R. M. Needham and J. H. Saltzer, ”Protecting poorly chosen secrets from guessing attacks”, IEEE Journal on Selected Areas in Communicatons, 11(5), pp. 648-656, 1993.

Security Analysis of a Password Authenticated Key Exchange Protocol

217

5. D. P. Jablon, ”Strong password-only authenticated key exchange”, Computer Communication Review, ACM, 26(5), pp. 5-26, 1996. 6. J. Katz, R. Ostrovsky and M. Yung, ”Eﬃcient password-authenticated key exchange using human memorable passwords”, Proceedings of Eurocrypt 2001, LNCS 2045, Springer-Verlag, 2001. 7. T. Kwon, ” Ultimate solution to authentication via memorable password”, Contribution to IEEE P1363 Study Group, 2000. 8. S. Lucks, ”Open key exchange: How to defeat dictionary attacks without encrypting public keys”, Proceedings of the security Protocols Workshop, LNCS 1361, pp. 7990, Springer-Verlag, 1997. 9. P. MacKenzie, S. Patel, and R. Swaminathan, ”Password-authenticated key exchange based on RSA”, Proceedings of Asiacrypt 2000, pp. 599-613, LNCS, Springer-Verlag, 2000. 10. P. MacKenzie and R. Swaminathan, ”Secure network authentication with password identiﬁcation”, Submission of IEEE P1363a, 1999. 11. T. Wu, ”The secure remote password protocol”, Proceedings of 1998 Internet Society Symposium on Network and Distributed System Security, pp. 97-111, 1998. 12. F. Zhu, D. S. Wong, A. H. Chan, and R. Ye, ”Password authenticated key exchange based on RSA for imbalanced wireless networks”, Proceedings of ISC 2002, LNCS 2433, pp. 150-161, Springer-Verlag, 2002. 13. V. Shoup, ”On formal models for secure key exchange”, available at http://philby.ucsd.edu/cryptolib.

Zero-Value Point Attacks on Elliptic Curve Cryptosystem Toru Akishita1 and Tsuyoshi Takagi2 1

Sony Corporation, Ubiquitous Technology Laboratories, 6-7-35 Kitashinagawa Shinagawa-ku, Tokyo, 141-0001 Japan [email protected] 2 Technische Universit¨ at Darmstadt, Fachbereich Informatik, Alexanderstr.10, D-64283 Darmstadt, Germany [email protected]

Abstract. The diﬀerential power analysis (DPA) might break the implementation of elliptic curve cryptosystem (ECC) on memory constraint devices. Goubin proposed a variant of DPA using the point (0, y), which is not randomized in Jacobian coordinates or in the isomorphic class. This point often exists in the standard curves, and we have to care this attack. In this paper, we propose the zero-value point attack as an extension of Goubin’s attack. Note that even if a point has no zero-value coordinate, the auxiliary registers might take zero-value. We investigate these zerovalue registers that cannot be randomized by the above randomization. Indeed, we have found several points P = (x, y) which cause the zerovalue registers, e.g., (1)3x2 + a = 0, (2)5x4 + 2ax2 − 4bx + a2 = 0, (3)P is y-coordinate self-collision point, etc. We demonstrate the standard curves that have these points. Interestingly, some conditions required for the zero-value attack depend on the explicit implementation of the addition formula — in order to resist this type of attacks, we have to care how to implement the addition formula. Finally, we note that Goubin’s attack and the proposed attack assume that the base point P can be chosen by the attacker and the secret scalar d is ﬁxed, so that they are not applicable to ECDSA signature generation. Keywords: side channel attack, diﬀerential power analysis, elliptic curve cryptosystem, addition formula, zero-value register.

1

Introduction

Elliptic curve cryptosystem (ECC) is suitable for the implementation on memory constraint devices, because of its short key size. The diﬀerential power analysis (DPA) is a serious attack on such scare computational devices. If the implementation is careless, the attacker can successfully recover the secret key by observing the power consumption of the device. Several simulational or experimental results show that DPA is eﬀective on the ECC on such devices [6,9].

This work was done while the ﬁrst author stayed at Technische Universit¨ at Darmstadt, Germany. The longer version of this paper is available in [1].

C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 218–233, 2003. c Springer-Verlag Berlin Heidelberg 2003

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

219

In order to resist the DPA we usually randomize the base point P of the underlying curve E. There are two standard approaches. The ﬁrst one is to transform the base point to the random equivalent class in Jacobian (or projective) coordinates [6]. The second one is to map the all parameters including the base point to the random isomorphic class [14]. However, Goubin pointed out that the two methods are not able to randomize the points with zero value, namely (x, 0) and (0, y) [8]. If we use the base point P = (c−1 mod #E)(0, y) for some integer c, the DPA can successfully detect the point cP is computed during the scalar multiplication. The attacker can know the secret key by recursively adapting this attack for diﬀerent c. Several standard curves over prime ﬁeld IFp contain point (0, y), i.e., the curve coeﬃcient b is quadratic residue modulo p. We have to care Goubin’s attack on these curves. In this paper we proposed a novel attack, called the zero-value point attack. On the contrary to Goubin’s attack, the zero-value point attack uses the zerovalue resister of the addition formula. Even if a point has no zero-value point coordinate, the auxiliary registers might take zero-value. We investigate all possible zero-value registers that are not randomized by the above randomization. Indeed we have found non-trivial points which take the zero-value registers in the addition formula of Jacobian coordinate implementation, e.g., (1)3x2 + a = 0, (2)3x4 + 6ax2 + 12bx − a2 = 0, (3)P is y-coordinate self-collision point, etc. These points are diﬀerent from Goubin’s point (x, 0) or (0, y). We show that these points exist on some standard curves. If we choose the curve that does not have these conditions, we can resist the zero-value point attack. Interestingly, the existence condition of these conditions depends how to explicitly implement the addition formula. For example, condition (2) appears if we implement T = −2S + M 2 in the doubling of the elliptic curve as W = −S + M 2 and then T = W − S, but it never appears if we implement it as W = 2S and then T = M 2 − W . This observation suggests that the designer has to care how to securely assemble the multiplication and the addition in the addition formula. Moreover, we show zero-value points for Montgomery-type method. We have found that the security conditions for this method are quite diﬀerent from those of the standard addition formula — the zero-value point attack strongly depends on the structure of the addition formula. In order to perform Goubin’s attack or our attack, we assume that the attacker is able to freely choose the base point P and the secret scalar d is ﬁxed for the scalar multiplication. Hence, we need to care these attacks in only such protocols as ECIES and single-pass ECDH. This paper is organized as follows: In section 2, we describe the basic properties of the elliptic curve cryptosystem. In section 3, we review the side channel attack and Goubin’s attack using the non-randomized point. In section 4, we propose the zero-value point attack and investigate the zero-value points for implementation in Jacobian coordinates. In section 5, we investigate the zero-value points for the Montgomery-type method. Finally we conclude in section 6.

220

2

Toru Akishita and Tsuyoshi Takagi

Elliptic Curve Cryptosystems

Let K = IFp be a ﬁnite ﬁeld, where p > 3 is a prime. The Weierstrass form of an elliptic curve over K is described as = 0). E : y 2 = x3 + ax + b (a, b ∈ K, 4a3 + 27b2 The set of all points P = (x, y) satisfying E, together with the point of inﬁnity O, is denoted by E(K), which forms an Abelian group. We denote by x(P ) and y(P ) the x- and y- coordinate of the point P . Let P1 = (x1 , y1 ) and P2 = (x2 , y2 ) be two points on E(K) that don’t equal to O. The sum P3 = P1 + P2 = (x3 , y3 ) can be computed as x3 = λ(P1 , P2 )2 − x1 − x2 ,

y3 = λ(P1 , P2 )(x1 − x3 ) − y1 ,

where λ(P1 , P2 ) = (3x1 2 + a)/(2y1 ) for P1 = P2 , and λ(P1 , P2 ) = (y2 − y1 )/(x2 − x1 ) for P1 = ±P2 . We call the former, P1 + P2 (P1 = P2 ), the elliptic curve doubling (ECDBL) and the latter, P1 + P2 (P1 = ±P2 ), the elliptic curve addition (ECADD) in aﬃne coordinate (x, y). These two addition formulae respectively need one inversion over K, which is much more expensive than multiplication over K. Therefore, we transform aﬃne coordinate (x, y) into other coordinates where inversion is not required. We give here the addition and doubling formulae in Jacobian coordinates, which are widely used [5]. In this paper we deal with Jacobian coordinates, but all discussions can be also applied to projective coordinates (X : Y : Z) setting x = X/Z and y = Y /Z. In Jacobian coordinates, we set x = X/Z 2 and y = Y /Z 3 , giving the equation EJ : Y 2 = X 3 +aXZ 4 +bZ 6 . Then, two points (X : Y : Z) and (r2 X : r3 Y : rZ) for some r ∈ K ∗ are recognized as the same point. Let P1 = (X1 : Y1 : Z1 ), P2 = (X2 : Y2 : Z2 ), and P3 = P1 + P2 = (X3 : Y3 : Z3 ). The doubling and addition formulae can be represented as follows. ECDBL in Jacobian Coordinates (ECDBLJ ) : X3 = T , Y3 = −8Y1 4 + M (S − T ), Z3 = 2Y1 Z1 , S = 4X1 Y1 2 , M = 3X1 2 + aZ1 4 , T = −2S + M 2 . ECADD in Jacobian Coordinates (ECADDJ ) : X3 = −H 3 − 2U1 H 2 + R2 , Y3 = −S1 H 3 + R(U1 H 2 − X3 ), Z3 = Z1 Z2 H, U1 = X1 Z2 2 , U2 = X2 Z1 2 , S1 = Y1 Z2 3 , S2 = Y2 Z1 3 , H = U2 − U1 , R = S2 − S1 . This addition formula is usually optimized in the sense of the number of multiplications in the base ﬁeld. We require 11 and 16 multiplications for ECDBL and ECADD, respectively. In elliptic curve cryptosystems, it is necessary to compute dP , where P ∈ E(K) and d is an n bit integer. The standard method to compute dP is called as the binary method. d = (dn−1 · · · d1 d0 )2 is the binary representation of d. The binary method is described as follows.

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

221

Algorithm 1: Binary method Input: d = (dn−1 · · · d1 d0 )2 , P ∈ E(K) (dn−1 = 1). Output: dP . 1. Q ← P 2. For i = (n − 2) downto 0 do: Q ← ECDBL(Q), If di = 1 then Q ← ECADD(Q, P ), 3. Return(Q).

When we compute the scalar multiplication using Jacobian coordinates, the point Q in step 2 is represented as Q = (X : Y : Z). In step 3, the point Q must be recovered to aﬃne coordinate by computing x = X/Z 2 and y = Y /Z 3 . Let #E be the order of E(K). For the security of elliptic curve cryptography, we must choose E(K) such that #E is the product of a large prime and a very small integer h, called the cofactor. To avoid the small subgroup attack, it is convenient that h = 1, i.e. #E is prime. In this paper, we are interested in the curves with prime order.

3

Side Channel Attacks on ECC

In this section we review the side channel attack on ECC. The simple power analysis (SPA), the diﬀerential power analysis (DPA), and Goubin’s attack are described. We explain the standard countermeasures that resist the SPA and the DPA. These known countermeasures cannot resist Goubin’s attack if the point (0, y) exists on the underlying curve. 3.1

SPA and Countermeasures

The SPA observes the power consumption of devices, and detects the diﬀerence of operations using the secret key. Algorithm 1 is vulnerable to the SPA. The scalar multiplication is computed by the addition formulae, namely ECDBL and ECADD, based on the bit of the secret scalar. The operation ECADD in Algorithm 1 is computed if and only if the underlying bit is 1, although the operation ECDBL is always computed. The addition formulae are assembled by the basic operations of the deﬁnition ﬁeld. There are diﬀerences between the basic operations of ECDBL and those of ECADD. Thus the SPA attacker can detect the secret bit. In order to resist the SPA, we have to eliminate the relations between the bit information and their addition formulae. Coron proposed a simple countermeasure, which is called as the double-andadd-always method. The double-and-add-always method is described as follows:

222

Toru Akishita and Tsuyoshi Takagi

Algorithm 2: Double-and-add-always method Input: d = (dn−1 · · · d1 d0 )2 , P ∈ E(K) (dn−1 = 1). Output: dP . 1. Q[0] ← P 2. For i = (n − 2) downto 0 do: Q[0] ← ECDBL(Q[0]), Q[1 − di ] ← ECADD(Q[0], P ), 3. Return(Q[0]).

The double-and-add-always method always computes ECADD whether di = 0 or 1. Therefore, attackers cannot guess the bit information of d using SPA. Three more diﬀerent approaches that resist the SPA have been proposed. We show several schemes used for the Weierstrass form in the following. The ﬁrst one is the Montgomery-type method, which always computes both ECADD and ECDBL for bit information di . It was originally proposed by Montgomery [18], and enhanced the Weierstrass form of elliptic curves over K [11,13,2,7]. The second one is to use an indistinguishable addition formula, with which we can compute both ECDBL and ECADD [2,3]. The third one is to use the addition chain with ﬁxed pattern with pre-computed points [16,17,19]. 3.2

DPA and Countermeasures

The diﬀerential power analysis (DPA) observes many power consumptions and analyzes this information together with statistic tools. Even if a method is secure against SPA, it might not be secure against the DPA. The DPA attacker tries to guess that the computation cP for an integer c is performed during the scalar multiplication. He/She gathers many power consumptions cPi for i = 1, 2, 3, ..., and detects the spike arisen from the correlation function based on the speciﬁc bit of cPi . The DPA can break Algorithm 2, because the sequence of points generated by Algorithm 2 is deterministic and the DPA can ﬁnd the correlation for a speciﬁc bit. Coron pointed out that it is necessary to insert random numbers during the computation of dP to prevent DPA [6]. The randomization eliminates the correlation between the secret bit and the sequence of points. The standard randomization methods for the base point P are Coron’s 3rd [6] and Joye-Tymen countermeasures [14]. The main idea of these countermeasures is to randomize the base point before starting the scalar multiplication. If the base point is randomized, there is no correlation among the power consumptions of each scalar multiplication. The DPA cannot obtain the spike of the power consumption derived from the statistical tool. We describe the two standard randomization methods in the following. There are other DPA countermeasures (e.g. randomized window methods [24,10], etc), but in this paper we aim at investigating the security of Coron’s 3rd and Joye-Tymen countermeasures. Coron’s 3rd Countermeasure: Coron’s 3rd countermeasure is based on randomization of Jacobian (or projective) coordinates. To prevent DPA we transform P = (x, y) in aﬃne coordinate to P = (r2 x : r3 y : r) in Jacobian coordi-

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

223

nates for a random value r ∈ K ∗ . This randomization produces the randomization in each representation of point and the randomization of power consumption during the scalar multiplication dP . Joye-Tymen Countermeasure: Joye-Tymen countermeasure uses an isomorphism of an elliptic curve [14]. For a random value r ∈ K ∗ , an elliptic curve E : y 2 = x3 + ax + b and the point P = (x, y) can be transformed to its isomor2 3 phic class like E : y = x + a x + b for a = r4 a, b = r6 b and P = (x , y ) = 2 3 (r x, r y). Instead of computing dP , we compute Q = dP = (xQ , yQ ) on E and then pull back Q = (xQ , yQ ) by computing xQ = r−2 xQ and yQ = r−3 yQ . This countermeasure can hold the Z-coordinate equal to 1 during the computation of dP and it enables good eﬃciency. 3.3

Goubin’s Power-Analysis Attack

Goubin proposed a new power analysis using a point that can be randomized by neither Coron’s 3rd nor Joye-Tymen countermeasure [8]. Goubin focused on the following two points: (x, 0) and (0, y). The points (x, 0) and (0, y) are represented by (X : 0 : Z) and (0 : Y : Z) in Jacobian coordinates. Even these points are randomized by Coron’s 3rd countermeasure, one of the coordinate remains zero, namely (r2 X : 0 : rZ) and (0 : r3 Y : rZ) for some random integer r ∈ K ∗ . Similarly Joye-Tymen randomization cannot randomize these points. Therefore, the attacker can detect whether the point (x, 0) or (0, y) is used in the scalar multiplication using the DPA. The attacker can break the secret scalar using these points as follows: For a given scalar c we can always generate a point P that satisﬁes P = (c−1 mod #E)(0, y), because the order of the curve #E is prime. If the attacker chooses P as the base point for the scalar multiplication, the DPA can detect whether cP is computed or not during the scalar multiplication. Then the attacker can obtain the whole secret scalar by recursively applying this process from the most signiﬁcant bit. Unfortunately, Goubin has not discussed how eﬀective his attack is. In Section 4.6, we discuss the multiplication with zero can be eﬀectively detected for a standard implementation. Goubin’s attack is eﬀective on the curves that have points (x, 0) or (0, y). The point (x, 0) is not on the curves with prime order ( = 2), because the order of the point (x, 0) is 2. The point (0, y) appears on the curve if b is quadratic residue modulo p, which is computed by solving y 2 = b.

4

Zero-Value Point Attack

In this section, we propose a novel attack, called the zero-value point attack. On the contrary to Goubin’s attack, our attack utilizes the auxiliary register which takes the zero-value in the deﬁnition ﬁeld. We investigate the zero-value registers that are randomized by neither Coron’s 3rd nor Joye-Tymen countermeasure.

224

Toru Akishita and Tsuyoshi Takagi

The addition formula is assembled by the operations of the base ﬁeld, namely the multiplication and the addition. We have about 20 diﬀerent operations of the auxiliary registers for both ECDBL and ECADD. There are a lot of possibilities that the value of the auxiliary registers become zero. The zero-value registers of the ECDBL and those of the ECADD are quite diﬀerent. We examine all possible operations that take zero in the auxiliary registers. We show several criteria, with which the proposed attack is eﬀective — the attack is strongly depending on the implementation of the addition formula. We list up all possible security conditions and we discuss their eﬀectiveness. Moreover, we demonstrate the attack is eﬀective on several standard curves. 4.1

Outline of Attack

We describe the outline of the zero-value point attack in the following. The goal of the zero-value point attack is to break the secret scalar by adaptively choosing the base point Q. We assume that the scalar multiplication is computed by Algorithm 2. But, we can apply our zero-value point attack to the SPA countermeasures using the deterministic addition chain described in section 3.1. The attacker breaks the secret key from the most signiﬁcant bit. The second most signiﬁcant bit dn−2 can be broken by checking whether one of addition formulae ECDBL(2Q), ECADD(2Q, Q), ECDBL(3Q), and ECADD(3Q, Q) is computed. If we can generate the zero-value register for these addition formulae, we can detect the second most bit — dn−2 = 0 holds if ECDBL(2Q) or ECADD(2Q, Q) has the zero-value register, and dn−2 = 1 holds if ECDBL(3Q) or ECADD(3Q, Q) has the zero-value register. Next, we assume that (n−i−1) most signiﬁcant bits (dn−1 , · · · , di+1 )2 of d are known. We can break the i-th bit di by checking whether one of ECDBL(2kQ), ECADD(2kQ, Q), ECDBL((2k + 1)Q), and ECADD((2k + 1)Q, Q) is computed, n−1 j−i−1 . We know that di = 0 holds if ECDBL(2kQ) or where k = j=i+1 dj 2 ECADD(2kQ, Q) has the zero-value register, and di = 1 holds if ECDBL((2k + 1)Q) or ECADD((2k + 1)Q, Q) has the zero-value register. Therefore if we ﬁnd a point P that takes the zero-value register at ECDBL, we can use the base point Q = (c−1 mod #E)P for some integer c for this attack. On the other hand, in order to use the zero-value register at ECADD, the base point Q that causes the zero-value register at ECADD(cQ, Q) must be found. Thus the attacker has to ﬁnd the points Q which cause the zero-value register at ECDBL(cQ) or ECADD(cQ, Q) for a given integer c. The ECDBL causes the zero-value register for a given one point Q, but the zero-value register for the ECADD depends on the two points Q and cQ. In this paper we call these points zero-value point (ZVP). 4.2

Possible Zero-Value Points from ECDBL

We investigate the ZVP for addition formulae in Jacobian coordinates, but the same arguments apply to addition formulae in projective coordinates. We search

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

225

the zero-value points in the following. We examine all auxiliary registers of the ECDBL in Jacobian coordinates. There are 21 intermediate values for ECDBLJ , as described. We prove the following theorem. Theorem 1. Let E be an elliptic curve over a prime field IFp defined by y 2 = x3 +ax+b. The elliptic curve E has the zero-value point P = (x, y) of ECDBLJ (P ) if and only if one of the following five conditions is satisfied: (ED1) 3x2 + a = 0, (ED2) 5x4 + 2ax2 − 4bx + a2 = 0, (ED3) the order of P is equal to 3, (ED4) x(P ) = 0 or x(2P ) = 0, and (ED5) y(P ) = 0 or y(2P ) = 0. Moreover, the zero-value points are not randomized by either Coron’s 3rd or Joye-Tymen randomization. Conditions (ED4) and (ED5) are exactly those of Goubin’s attack. We will prove this theorem in the following. Let P1 = (X1 : Y1 : Z1 ), and P3 = (X3 : Y3 : Z3 ) = ECDBLJ (P1 ). The intermediate values of ECDBL can be zero if and only if one of the following values is zero. X1 , Y1 , Z1 , X3 , Y3 , M, −S + M 2 , S − T Here Z1 = 0 implies P = O, which never appears for input of ECDBLJ (P ). The conditions X1 = 0, Y1 = 0, X3 = 0, and Y3 = 0 are equivalent to x(P ) = 0, y(P ) = 0, x(2P ) = 0, and y(2P ) = 0 which are exactly the points discussed by Goubin. Next M = 3X12 +aZ14 = 0 implies the condition 3x2 +a = 0, which is the condition (ED1). Note that neither Coron’s 3rd nor Joye-Tymen randomization can randomize this point. Indeed the randomized point (X1 : Z1 ) = (r2 X1 : rZ1 ) by Coron’s 3rd randomization satisﬁes 3X12 + aZ14 = r4 (3X12 + aZ14 ) = 0, where r ∈ K ∗ . The randomized point (X1 : Z1 ) = (s2 X1 : Z1 ) and curve parameter a = s4 a by Joye-Tymen randomization satisﬁes 3X12 + a Z14 = s4 (3X12 +aZ14 ) = 0, where s ∈ K ∗ . The condition −S+M 2 = 0 implies −4X1 Y12 + (3X12 + aZ14 )2 = 0, which is equivalent to −4xy 2 + (3x2 + a)2 = 0, namely condition (ED2). The condition S − T = 0 implies x1 = x3 . This occurs only if 2P = ±P , which means P = O or the order of P equals to 3, namely condition (ED3). Remark 1. There are two orders of the additions to obtain T = −2S + M 2 . −S + M 2 appears if we compute with the following ordered additions W = −S + M 2 and then T = W − S. If we compute W = 2S and then T = M 2 − W , condition (ED2) does not appear in ECDBL. Thus we should avoid the former order of the two additions for the implementation of ECDBL. 4.3

Possible Zero-Value Points from ECADD

We investigate the possible zero-value points from ECADD, namely all possible zero-value points P which satisfy ECADD(cP, P ) for some integer c. There are 23 auxiliary values in ECADD. We examine the addition formula in Jacobian coordinates. We prove the following theorem.

226

Toru Akishita and Tsuyoshi Takagi

Theorem 2. Let E be an elliptic curve over prime field IFp defined by y 2 = x3 + ax+b. The elliptic curve E has the zero-value point P = (x, y) of ECADDJ (cP, P ) for some c ∈ ZZ if and only if one of the following seven conditions is satisfied: (EA1) P is a y-coordinate self-collision point, (EA2) x(cP ) + x(P ) = 0, (EA3) x(P ) − x(cP ) = λ(P, cP )2 , (EA4) 2x(cP ) = λ(P, cP )2 , x(cP ) = λ(P, cP )2 , or x(P ) = λ(P, cP )2 , (EA5) the order of P is 2c+1, (EA6) x(cP ) = 0, x(P ) = 0, or x((c + 1)P ) = 0, and (EA7) y(cP ) = 0, y(P ) = 0, or y((c + 1)P ) = 0. Moreover, the zero-value points are not randomized by either Coron’s 3rd or Joye-Tymen randomization. A point P = (x, y) is called the y-coordinate self-collision point if there is a positive integer c such that the y-coordinate of the point cP is equal to y. Conditions (EA6) and (EA7) are those of Goubin’s attack. Let P1 = (X1 : Y1 : Z1 ), P2 = (X2 : Y2 : Z2 ), and ECADDJ (P1 , P2 ) = (X3 : Y3 : Z3 ). Here we can set P1 = cP2 for some integer c. If one of the following values is zero, at least one of the intermediate values must be zero. X1 , Y1 , Z1 , X2 , Y2 , Z2 , X3 , Y3 , H, R, U1 H 2 − X3 . Here if one of X1 , Y1 , X2 , Y2 , X3 , Y3 is zero, this provides conditions (EA6) and (EA7). Z1 = 0, Z2 = 0 and H = 0 imply P1 = O, P2 = O, and P1 = ±P2 , respectively, which never appear for input of ECADDJ (P1 , P2 ). Next, R = Y1 Z23 − Y2 Z13 = 0 implies y1 = y2 , where y1 = Y1 /Z13 and y2 = Y2 /Z23 , namely condition (EA1). This is equal to the y-coordinate collision point. Note that neither Coron’s 3rd nor Joye-Tymen randomization can randomize this point. Indeed the randomized point (Y1 : Z1 ) = (r3 Y1 : rZ1 ), (Y2 : Z2 ) = (s3 Y2 : sZ2 ) by Coron’s 3rd randomization satisﬁes Y1 Z23 −Y2 Z13 = r3 s3 (Y1 Z23 −Y2 Z13 ) = 0, where r, s ∈ K ∗ . The randomized point (Y1 : Z1 ) = (t3 Y1 : Z1 ), (Y2 : Z2 ) = (t3 Y2 : Z2 ) by Joye-Tymen randomization satisﬁes Y1 Z23 − Y2 Z13 = t3 (Y1 Z23 − Y2 Z13 ) = 0, where t ∈ K ∗ . Finally U1 H 2 − X3 = 0 implies 3U1 H 2 + H 3 − R2 = 0, which is x1 − x3 = 0. This occurs only if (c + 1)P = ±cP , which means P = O or the order of P equals to 2c + 1, namely condition (EA5). The other possible intermediate values appear only at the computation of X3 = −H 3 − 2U1 H 2 + R2 . We have 6 possible conditions: (a1 ) − H 3 − 2U1 H 2 = 0,

(a2 ) − 2U1 H 2 + R2 = 0,

(a3 ) − H 3 + R2 , = 0 (a4 ) − H 3 − U1 H 2 = 0, (a5 ) − U1 H 2 + R2 = 0, (a6 )(−H 3 − U1 H 2 ) + R2 = 0. We examine these conditions in the following. These above points are randomized by neither Coron 3rd nor Joye-Tymen randomization. Condition (a1) implies H(X2 Z12 + X1 Z22 ) = 0, namely H = 0 or x1 + x2 = 0 in aﬃne coordinate. The condition H = 0 has already appeared. x1 + x2 = 0 implies x(cP ) + x(P ) = 0, which is equal to condition (EA2). Condition (a2) implies −2X1 Z22 (X2 Z12 − X1 Z22 )2 + (Y2 Z13 − Y1 Z23 )2 = 0, which is 2x1 = λ2 in aﬃne coordinate. It is condition (EA4). Condition (a3) implies −(X2 Z12 −X1 Z22 )3 +(Y2 Z13 −Y1 Z23 )2 = 0,

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

227

which is x2 − x1 = λ(P2 , P1 )2 , namely condition (EA3). Condition (a4) implies H = 0 or U2 = 0, which has already discussed. Condition (a5) is converted to −X1 Z22 (X2 Z12 − X1 Z22 )2 + (Y2 Z13 − Y1 Z23 )2 = 0, which is x1 = λ2 in aﬃne coordinate. It is equal to condition (EA4). Condition (a6) implies −(X2 Z12 − X1 Z22 )3 − X1 Z22 (X2 Z12 − X1 Z22 )2 + (Y2 Z13 − Y1 Z23 )2 = 0, which is x2 = λ(P2 , P1 )2 in aﬃne coordinate. It is equal to condition (EA4). Remark 2. If we implement the addition −H 3 − 2U1 H 2 + R2 with either condition (a1), (a2), or (a3), then conditions (a4), (a5), and (a6) never appear in ECADD. Condition (a1), (a2), and (a3) are never simultaneously satisﬁed — only one of them can be occurred. The security of ECADD against the zero-value point attack strongly depends on its implementation, and we should care how to implement it. 4.4

How to Find the ZVP

We discuss how to ﬁnd the ZVP described in the previous sections. A zero-value point is called as trivial, if the order of the point is smaller than that of the curve. The standard curves over prime ﬁelds have prime order, i.e., the orders of these elliptic curves are always prime and there is no trivial ZVP on them. Goubin’s point (0, y) is a non-trivial point. In the following we discuss the non-trivial ZVP that is diﬀerent from Goubin’s point. First we discuss the non-trivial ZVP from ECDBL. There are two non-trivial points (x, y) such that (ED1) 3x2 + a = 0, (ED2) 5x4 + 2ax2 − 4bx + a2 = 0. The solution of these polynomials over ﬁnite ﬁelds can be easily computed using the Cantor-Zassenhaus algorithm [4]. Next we discuss the non-trivial ZVP from ECADD. The existence conditions of these points are determined by not only one base point P but also the scalar c. In order to ﬁnd these ZVP we have to know how to represent the relation between P and cP , for example, x(cP ) + x(P ) = 0. Izu and Takagi discussed a similar self-collision for Brier-Joye addition formula [12]. Here we can similarly apply their approach to ﬁnding the ZVP. We explain it in the following. Let P = (x, y) be the point on the elliptic curve. The division polynomial ψ(P ), φ(P ), ω(P ) is a useful tool for representing these relationships as the polynomials over the deﬁnition ﬁeld K. The point cP can be represented as follows: φc (P ) ωc (P ) , cP = ψc2 (P ) ψc3 (P ) where c is a scalar value (see for example, [20]). For small c, we know ψ1 (P ) = 1, ψ2 (P ) = 2y, and ψ3 (P ) = 3x4 + 6ax2 + 12bx − a2, where P = (x, y). We deﬁne 2 2 φc = xψc2 − ψc−1 ψc+1 and 4yωc = ψc+2 ψc−1 − ψc−2 ψc+1 . For example, the points P = (x, y) which satisfy x(cP ) + x(P ) = 0 are the solutions of φc (P ) + x(P )ψc2 (P ) = 0. The points P = (x, y) with x(P ) − x(cP ) = λ(P, cP )2 are the solutions of polynomial (x(P )ψc2 (P ) − φc (P ))3 = (y(P )ψc3 (P ) − ωc (P ))2 . Similarly we can construct the equations whose solutions

228

Toru Akishita and Tsuyoshi Takagi

imply the ZVP. The polynomials ψc (P ), ωc (P ), φc (P ) have degree with order O(c2 ), which increases exponentially in log c. Therefore, it is a hard problem to ﬁn the solutions of these equations for a large c — we can ﬁnd the ZVP only for a small c using the division polynomials. It is an open problem to ﬁnd a more eﬃcient algorithm of computing the ZVP. 4.5

ZVP on Standard Curves

We have examined the existence of several ZVP over the SECG [22] random curves over prime ﬁelds. Especially we discuss the non-trivial conditions from ECDBLJ , namely (ED1) 3x2 + a = 0, (ED2) 5x4 + 2ax2 − 4bx + a2 = 0. These conditions are most eﬀectively used for the proposed zero-value point attack. We have found enough curves which have the points with condition (ED1) or (ED2). In Table 1 we summarize the existence of these points. Notation ‘o’ means that the curve has the point with one of the aforementioned conditions. For comparison we also show point (0, y) used in Goubin’s attack in Table 1. Some curves, e.g., secp112r1, secp224r1, are secure against Goubin’s attack, but not against ours. SECG secp224r1 is insecure only against condition (ED2).

SECG SECG SECG SECG SECG SECG SECG SECG SECG

secp112r1 secp128r1 secp160r1 secp160r2 secp192r1 secp224r1 secp256r1 secp384r1 secp521r1

(0, y) o o o o o o o

(ED1) o o o o

(ED2) o o o o o -

Table 1. The existence of non-trivial ZVP of ECDBLJ

4.6

Detecting the Zero-Value Registers

We discuss how the DPA can detect the multiplication or the addition with the zero-value register on memory constrained devices such as smart cards. The embedded CPU on a smart card, typically an 8 bit CPU, has only so poor computing power that we usually equip a coprocessor for implementing ECC. In the coprocessor, a multiplication circuit and an addition circuit are generally embedded for computing the modular multiplication and the modular addition of the base ﬁeld IFp , respectively. These circuits compute the outputs by inputting two k-bit values, where we usually choose k = 32. The power consumption of the multiplication circuit might be dominant for the whole power consumption of the device.

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

229

The modular multiplication algorithm suitable for the multiplication circuit is the Montgomery multiplication [15]. Algorithm 3 describes the Montgomery multiplication using a k bit multiplication circuit. The computations of xj yi , a0 m , and mj ui at Step 2 use the k multiplication circuit. Algorithm 3: Montgomery multiplication Input: M = (mn−1 · · · m0 )b , X = (xn−1 · · · x0 )b , Y = (yn−1 · · · y0 )b , b = 2k , R = bn , gcd(m, b) = 1, m = m−1 mod b. . Output: XY R−1 mod M 1. A ← 0 (A = (an · · · a0 )b ). 2. For i from 0 to (n − 1) do: temp ← 0, For j from 0 to (n − 1) do: {temp, aj } ← xj yi + aj + temp, an ← temp, temp ← 0, ui ← a0 m mod b, For j from 0 to n do: {temp, aj } ← mj ui + aj + temp, A ← A/b. 3. If A ≥ M , A ← A − M . 4. Return(A).

Suppose that one of the input X, Y in the Montgomery multiplication equals to 0. If the input X (or Y ) is 0, then values xj (or yj ), a0 , and ui at Step 2 always take 0, respectively. Therefore, one of the inputs of the multiplication circuit is always 0 during the computation of the Montgomery multiplication. We explain the implication of this zero input for the multiplication circuit in the following. A 32-bit multiplication circuit comprises three parts (see [23] for example): (1) AND gates for partial products, (2) carry-save adder trees such as Wallace trees, and (3) fast carry propagate adder. The gate counts of these three parts are roughly estimated to about 2K ,7K, and 1K gates, respectively. If one of the inputs to the multiplication circuit is 0, then it behaves as follows: The output of the AND gate (1) always takes 0 though the other input varies. The inputs and outputs of both the carry save adder (2) and fast carry propagate adder (3) are always 0. This means that the power consumption of ﬁrst part considerably decreases, and those of the latter two parts are almost nothing during the computation of Montgomery multiplication. Thus the power consumption of the zero-value multiplication dramatically decreases, namely more than 80%. We guess that the attacker can distinguish it only by the single observation of the power consumption. On the other hand, modular addition (X + Y mod M ) and subtraction (X − Y mod M ) is implemented by using k bit addition circuit. If one of the input X, Y in modular addition or subtraction equals to zero, one of the inputs of addition circuit is always 0 during the computation of X + Y or X − Y . Thus, the power consumption of the addition circuit considerably decreases. However, because the gate counts of the addition circuit are much smaller than those of the multiplication circuit, it does not reﬂect the whole power consumption as the case of modular multiplication. Thus, the attacker makes much more eﬀorts

230

Toru Akishita and Tsuyoshi Takagi

in order to detect the modular addition and subtraction with the zero value comparing with the modular multiplication with the zero value. In the standard curves such as SECG [22] random curves over prime ﬁelds, the prime p is chosen to be a Mersenne-like prime because of eﬃcient modular reduction. In this case, the multiplication circuit is used only for the multiplication X · Y . Therefore, the modular multiplication with the zero value can be also detected eﬃciently.

5

Application to Montgomery-Type Method

We investigate the ZVP over the Montgomery-type method. It was originally proposed by Montgomery [18], and enhanced the Weierstrass form of elliptic curves over K [11,13,2,7]. The scalar multiplication is computed as follows: Algorithm 4: Montgomery-type method Input: d = (dn−1 · · · d1 d0 )2 , P ∈ E(K) (dn−1 = 1). Output: dP . 1. Q[0] ← P, Q[1] ← mECDBL(P ) 2. For i = (n − 2) downto 0 do: Q[1 − di ] ← mECADD(Q[0], Q[1]), Q[di ] ← mECDBL(Q[di ]). 3. Return(Q[0]).

mECADD and mECDBL are the special elliptic curve addition and doubling for the Montgomery-type method. In this method, we don’t need to use y-coordinate (Y -coordinate in projective coordinates) to compute the scalar multiplication dP . This leads the eﬃciency of the Montgomery-type method. Let P1 = (X1 : Z1 ) and P2 = (X2 : Z2 ) in projective coordinates, which don’t equal to O, by setting x = X/Z. In the following we describe the doubling formula P3 = (X3 : = ±P2 Z3 ) = 2P1 and the addition formula P3 = (X3 : Z3 ) = P1 + P2 , where P1 and P3 = (X3 : Z3 ) = P2 − P1 where (X3 , Z3 = 0). There are also several variations of these formulae [11,13,2,7]. ECDBL in Montgomery-Type Method (mECDBLP ) : X3 = (X1 2 − aZ1 2 )2 − 8bX1 Z1 3 , Z3 = 4(X1 Z1 (X1 2 + aZ1 2 ) + bZ1 4 ). ECADD in Montgomery-Type Method (mECADDP ) : X3 = Z3 ((X1 X2 −aZ1 Z2 )2 −4bZ1 Z2 (X1 Z2 +X2 Z1 )), Z3 = X3 (X1 Z2 −X2 Z1 )2 . If the base point is chosen as P = (0, y), this addition formula mECADDP causes error at the end of scalar multiplication due to the zero Z-coordinate. This point should not be used for the base point. The Montgomery-type method always computes mECADD and mECDBL whether di = 0 or 1. Therefore, attackers cannot guess the bit information of d using SPA (see [11,13,2,7] for further discussions). We can enhance SPA-resistance to DPA-resistance by applying either Coron’s 3rd or Joye-Tymen countermeasure to the Montgomery-type method.

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

231

Here we investigate the zero-value points for mECDBLP and mECADDP in the following. We assume that (n − i − 1) most signiﬁcant bits (dn−1 , · · · , di+1 )2 n−1 of d are known, and let k = j=i+1 dj 2j−i−1 . If di = 0, mECDBLP (kP ) at i-th loop and mECADDP (2kP, (2k + 1)P ) at (i − 1)-th loop will be computed. On the contrary, if di = 1, mECDBLP ((k + 1)P ) at i-th loop and mECADDP ((2k + 1)P, (2k + 2)P ) at (i − 1)-th loop will be computed. Thus the attacker can detect the i-th bit di by checking whether one of mECDBLP (kP ), mECDBLP ((k + 1)P ), mECADDP (2kP, (2k + 1)P ), mECADDP ((2k + 1)P, (2k + 2)P ) is computed. We investigate the ZVP at mECDBLP (P ) and mECADDP (cP, (c + 1)P ) for given integer c in following two theorems. Theorem 3. Let E be an elliptic curve over a prime field IFp defined by y 2 = x3 +ax+b. The elliptic curve E has the zero-value point P = (x, y) of mECDBLP (P ) if and only if one of the following four conditions is satisfied: (MD1) x2 −a = 0, (MD2) x2 + a = 0, (MD3) x(P ) = 0 or x(2P ) = 0, and (MD4) y(P ) = 0. Moreover, the zero-value points are not randomized by either Coron’s 3rd or Joye-Tymen randomization. Theorem 4. Let E be an elliptic curve over a prime field IFp defined by y 2 = x3 +ax+b. The elliptic curve E has the zero-value point P = (x, y) of mECADDP (cP, (c + 1)P ) for c ∈ ZZ if and only if one of the following three conditions is satisfied: (MA1) x(cP )x((c + 1)P ) = a, (MA2) x(cP ) + x((c + 1)P ) = 0, and (MA3) x(cP ) = 0, x((c+1)P ) = 0, or x((2c+1)P ) = 0. Moreover, the zero-value points are not randomized by either Coron’s 3rd or Joye-Tymen randomization. The conditions in Theorem 3 and Theorem 4 are diﬀerent from those of the standard addition formula. The zero-value point attack strongly depends on the structure of the addition formula.

6

Conclusion

We presented the zero-value point attack on elliptic curve cryptosystem, which detect the zero-value auxiliary registers of the addition formulae. These points can be randomized by neither Coron’s 3rd nor Joye-Tymen countermeasure, and we can detect these operations using the DPA. We have found the several nontrivial points P , which take the zero-value, namely (1)3x2 + a = 0, (2)5x4 + 2ax2 − 4bx + a2 = 0, (3)P is a y-coordinate self-collision point, etc. These points exist on several standard curves from SECG. Moreover, we showed the zerovalue points for the Montgomery-type method. These conditions provide us new security criteria for the secure implementation of ECC. We should care the zero-value point attack under the computation environment allowed to perform the DPA. The zero-value point attack could be resisted if we randomized the scalar. We should randomize not only the base point but also the secret scalar.

232

Toru Akishita and Tsuyoshi Takagi

Recently, Smart proposed an eﬃcient countermeasure against Goubin’s attack by mapping the underlying curve to its isogenous class [21]. However, the zero-value points discussed in this paper can exist even on the isogenous class. Acknowledgments. We would like to thank Tetsuya Izu and the anonymous referees of ISC ’03 for their helpful comments, and Nigel Smart for sending his paper [21].

References 1. T. Akishita and T. Takagi, “Zero-Value Point Attacks on Elliptic Curve Cryptosystem”, Technical Report No. TI-1/03, Technische Universt¨ at Darmstadt, 2003. http://www.informatik.tu-darmstadt.de/TI/ ´ Brier and M. Joye, “Weierstrass Elliptic Curve and Side-Channel Attacks”, 2. E. Public Key Cryptography - PKC 2002, LNCS 2274, pp. 335-345, Springer-Verlag, 2002. 3. C. Clavier and M. Joye, “Universal exponentiation algorithm”, Cryptographic Hardware and Embedded Systems - CHES 2001, LNCS 2162, pp.300-308, SpringerVerlag, 2001. 4. H. Cohen, Course in Computational Algebraic Number Theory, Graduate Texts in Mathematics, Vol. 138, Springer-Verlag, 1994. 5. H. Cohen, A. Miyaji, and T. Ono, “Eﬃcient Elliptic Curve Exponentiation Using Mixed Coordinates”, Advances in Cryptography - ASIACRYPT ’98, LNCS 1514, pp. 51-65, Springer-Verlag, 1998. 6. J.-S. Coron, “Resistance against Diﬀerential Power Analysis for Elliptic Curve Cryptosystems”, Cryptographic Hardware and Embedded Systems - CHES ’99, LNCS 1717, pp. 292-302, Springer-Verlag, 2002. 7. W. Fischer, C. Giraud, E. W. Knundsen, and J. -P. Seifert, “Parallel Scalar Multiplication on General Elliptic Curves over IFp Hedged against NonDiﬀerential Side-Channel Attacks”, IACR Cryptology ePrint Archive 2002/007. http://eprint.iacr.org/2002/007/ 8. L. Goubin, “A Reﬁned Power-Analysis Attack on Elliptic Curve Cryptosystems”, Public Key Cryptography - PKC 2003, LNCS 2567, pp. 199-211, Springer-Verlag, 2003. 9. K. Itoh, T. Izu, and M. Takenaka, “Address-bit Diﬀerential Power Analysis on Cryptographic Schemes OK-ECDH and OK-ECDSA”, Workshop on Cryptographic Hardware and Embedded Systems 2002 - CHES 2002, LNCS 2523, pp. 129-143, 2003. 10. K. Itoh, J. Yajima, M. Takenaka, and N. Torii, “DPA Countermeasures by improving the window method”, Workshop on Cryptographic Hardware and Embedded Systems 2002 - CHES 2002, LNCS 2523, pp. 303-317, 2003. 11. T. Izu and T. Takagi, “A Fast Parallel Elliptic Curve Multiplication Resistant against Side Channel Attacks”, Public Key Cryptography - PKC 2002, LNCS 2274, pp. 280-296, Springer-Verlag, 2002. 12. T. Izu and T. Takagi, “Exceptional Procedure Attack on Elliptic Curve Cryptosystems”, Public Key Cryptography - PKC 2003, LNCS 2567, pp. 224-239, SpringerVerlag, 2003.

Zero-Value Point Attacks on Elliptic Curve Cryptosystem

233

13. T. Izu, B, M¨ oller, and T. Takagi, “Improved Elliptic Curve Multiplication Methods Resistant against Side Channel Attacks”, Progress in Cryptology - INDOCRYPT 2002, LNCS 2551, pp. 296-313, Springer-Verlag, 2002. 14. M. Joye and C. Tymen, “Protection against Diﬀerential Analysis for Elliptic Curve Cryptography”, Cryptographic Hardware and Embedded Systems - CHES 2001, LNCS 2162, pp. 377-390, 2001. 15. A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, 1997. 16. B. M¨ oller, “Securing Elliptic Curve Point Multiplication against Side-Channel Attacks”, Information Security - ISC 2001, LNCS 2200, pp.324-334, 2001. 17. B. M¨ oller, “Parallelizable Elliptic Curve Point Multiplication Method with Resistance against Side-Channel Attacks”, Information Security - ISC 2002, LNCS 2433, pp.402-413, 2002. 18. P. L. Montgomery, “Speeding the Pollard and Elliptic Curve Methods of Factorization”, Mathematics of Computation, vol. 48, pp. 243-264, 1987. 19. K. Okeya and T. Takagi, “The Width-w NAF Method Provides Small Memory and Fast Elliptic Scalar Multiplications Secure against Side Channel Attacks”, Cryptographer’s Track RSA Conference - CT-RSA 2003, LNCS 2612, pp. 328-343, 2003. 20. J. Silverman, The Arithmetic of Elliptic Curves, GMT 106, Springer-Verlag, 1986. 21. N. Smart, “An Analysis of Goubin’s Reﬁned Power Analysis Attack”, to appear in Cryptographic Hardware and Embedded Systems - CHES 2003, 2003. 22. Standard for Eﬃcient Cryptography (SECG), SEC2: Recommended Elliptic Curve Domain Parameters, Version 1.0, 2000. http://www.secg.org/ 23. C. S. Wallace, “A Suggestion for a Fast Multiplier”, IEEE Trans. Electron. Comput., pp. 14-17, 1964. 24. C. Walter, “MIST: An Eﬃcient, Randomized Exponentiation Algorithm for Resisting Power Analysis”, Cryptographer’s Track RSA Conference - CT-RSA 2002, LNCS 2271, pp. 53-66, 2002.

Cryptanalysis of an Algebraic Privacy Homomorphism David Wagner University of California, Berkeley [email protected]

Abstract. We use linear algebra to show that an algebraic privacy homomorphism proposed by Domingo-Ferrer is insecure for some parameter settings.

Keywords: Cryptanalysis, number-theoretic cryptosystems

1

The Proposed Scheme

Let Q, R denote two rings, with addition denoted by + and multiplication by × in both cases. Let E : K × Q → R be a symmetric-key encryption scheme, with corresponding decryption D : K × R → Q. We call E additively-homomorphic if Dk (Ek (a) + Ek (b)) = a + b for all a, b ∈ Q and all k ∈ K. Similarly, we will call E multiplicatively-homomorphic if Dk (Ek (a) × Ek (b)) = a × b. Let Z/mZ denote the ring of integers modulo m. At ISC 2002, J. Domingo-Ferrer proposed an encryption scheme that is both additively- and multiplicatively-homomorphic [2]. Let us recall Domingo-Ferrer’s scheme brieﬂy here. First, we choose parameters: Public values: a large integer m with many small divisors, and a small integer d > 2. Private key: a small divisor m of m, and a unit r ∈ (Z/mZ)∗ . def

We form the ring R = (Z/mZ)[X] of polynomials in the indeterminate X with coeﬃcients from Z/mZ. Ciphertexts are elements of R. The plaintext space is def Q = Z/m Z, hence the signature of Domingo-Ferrer’s encryption algorithm is E : K × Z/m Z → (Z/mZ)[X] and D : K × (Z/mZ)[X] → Z/m Z. The scheme is deﬁned as follows: Encryption: The encryption algorithm E is randomized. First, we pick uniformly at random a polynomial p(X) ∈ (Z/mZ)[X] of degree ≤ d satisfying p(0) = 0 and p(1) mod m = a. Then, we calculate the polynomial def p(rX) ∈ (Z/mZ)[X], and this is our ciphertext, i.e., Em ,r (a) = p(rX). The ciphertext p(rX) is represented by its coeﬃcients, so r is never revealed explicitly.

This research was supported in part by NSF CAREER CCR-0093337.

C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 234–239, 2003. c Springer-Verlag Berlin Heidelberg 2003

Cryptanalysis of an Algebraic Privacy Homomorphism

235

Decryption: D is deﬁned by Dr,m (q(X)) = q(r−1 ) mod m , for ciphertexts q(X) ∈ (Z/mZ)[X]. def

Note that Domingo-Ferrer’s scheme is both additively- and multiplicativelyhomomorphic. However, the size of ciphertexts does grow each time we multiply ciphertexts. def For ease of notation, in this paper we deﬁne r = r mod m . Provably secure? Domingo-Ferrer claims that, if we ﬁx the number n of known plaintexts available to the cryptanalyst, then one can choose public parameters large enough so that the cryptanalyst is foiled [2, Corollary 13]. However, what his paper actually proves is that, under these conditions, there are many possible candidates for the private key that remain consistent with the known plaintexts [2, Theorem 7]. It follows that the cryptanalyst cannot recover the entire private key with certainty under these conditions. We ﬁrst note that the size of the parameters in Domingo-Ferrer’s scheme grows with n. It is traditional in the cryptographic community to seek a scheme that takes only polynomial work for legitimate parties to evaluate, while requiring the cryptanalyst to spend super-polynomial work to break the scheme. To avoid confusion, we should emphasize that Domingo-Ferrer’s scheme does not attain this goal, nor does it attempt to; the envisioned applications are chosen so that the number of known texts available to the adversary can be bounded in advance. However, there is a bigger issue lurking in the wings. The paper’s provable security result is unsatisfying, in that it does not rule out all possible attacks. Domingo-Ferrer’s security theorem leaves open the possibility that, though the cryptanalyst cannot recover the entire private key, maybe the cryptanalyst can recover enough information to decrypt any other ciphertext of interest. Indeed, in what follows we show that something like this does happen: in Domingo-Ferrer’s scheme, (m , r ) is all you need to know to decrypt, and we give an attack that recovers (m , r ) eﬃciently, even though the attacker never learns the remainder of the private key (i.e., r). This shows that Domingo-Ferrer’s Corollary 13 is false and demonstrates that the scheme is insecure. By way of analogy, imagine an encryption scheme that completely ignores its key and simply acts as the identity transformation. So long as the key is long enough, it would be straightforward to show that no attack can recover the key with certainty. Nonetheless, such an encryption scheme is obviously insecure. Domingo-Ferrer’s scheme behaves similarly; there is a portion of the key that is completely ignored by both encryption and decryption, so it is not surprising that there is no way to recover the entire key—but this does not promise anything about the security of Domingo-Ferrer’s scheme. This illustrates the importance of using the right deﬁnitions when following the provable security paradigm. We should clarify that our attack does not work for all parameter settings. However, it does work for many choices of parameters, and in particular, it breaks all the speciﬁc instantiations suggested in Domingo-Ferrer’s original paper. Along the way, we show that the proof of security for Domingo-Ferrer’s

236

David Wagner

scheme is ﬂawed. Consequently, Domingo-Ferrer’s original proposal could reasonably be regarded as insecure.

2

Cryptanalysis

In the remainder of the paper, we describe a simple attack on Domingo-Ferrer’s scheme. Equivalent keys. The secret key consists of the pair (m , r), but it is easy to see that the decryption procedure needs only m and r . In other words, the Domingo-Ferrer scheme has many equivalent secret keys1 : (m , r) is equivalent to (m , r∗ ) whenever r ≡ r∗ (mod m ). Put yet another way, the part of the key represented by the value r−r m is completely ignored by both the encryption and decryption procedures. Thus, it suﬃces to recover r mod m , i.e., to recover r . In our attack, we recover the key (up to equivalences) one element at a time: ﬁrst, we show how to ﬁnd m ; then, we show how to recover r . Recovering m . Assume we have a collection of 200 known plaintexts and their encryptions, (ai , pi (X)) where pi (X) = Em ,r (ai ). Notice that the quantities def xi = pi (1) − ai (computed in Z/mZ) are all integer multiples of m , and by construction, they are uniformly distributed on the set {0, m , 2m , . . . , m − m }. It is known that if we take the greatest common denominator of a pair of random, suﬃciently-large integers, the greatest common denominator is 1 with probability about 6/π 2 . Hence, the greatest common denominator of a pair of random multiples of m will be m with probability about 6/π 2 . This suggests a simple method for recovering m . We can use gcd(x1 , x2 ) as an initial guess at m ; this guess will be correct with probability 6/π 2 . If we repeat this procedure 100 times with 100 diﬀerent pairs, then with probability 1−(1−6/π 2) ≈ 1−2−135, the correct value of m will appear somewhere in these 100 results, so we could imagine repeating the rest of the attack with each of these 100 candidates for m . Better still is to note that the most common result among these 100 is almost certain to be m , so taking a majority vote should suﬃce to recover m . Even better is to compute gcd(x1 , x2 , . . . , x200 ). 1

Incidentally, this shows that Domingo-Ferrer’s Theorem 11 is false. We can easily find two private keys (m , r1 ) and (m , r2 ) that both decrypt a random ciphertext the same way with certainty; simply take r2 = r1 + m . The flaw in the proof of Theorem 11 is in the second of the three cases considered, where Lemma 6 is mis−1 /m , where p(X) is applied. Lemma 6 is applied to the quantity p(r −1 1 ) − p(r2 ) ∈ a randomly chosen ciphertext (recall that r1 , r2 are held fixed throughout). Lemma 6 only applies to integers chosen uniformly at random from {0, 1, . . . , m −1}. However, −1 the quantity p(r −1 1 ) − p(r2 ) does not necessarily behave like a uniformly random integer, so Lemma 6 does not apply here. In addition, the proof implicitly assumes that the divisors of this quantity are distributed uniformly on {0, 1, . . . , m − 1}, but this assumption is not justified.

Cryptanalysis of an Algebraic Privacy Homomorphism

237

This gives an eﬃcient algorithm for recovering part of the secret key given only a handful of known plaintexts. All that remains is to learn r . Recovering r . If m is small, ﬁnding r is easy: we can simply enumerate all possibilities for r , and test which ones correctly decrypt all 200 of our known plaintexts. 3 of the 6 parameter sets suggested by Domingo-Ferrer use a value of m that is 5 decimal digits long, so brute-force enumeration would break these schemes with complexity about 217 . However, it is easy to choose larger values of m that would make brute-force search infeasible, and hence we describe next a more clever attack that drastically reduces the complexity of ﬁnding m , namely, from exponential time to polynomial time. Assume that we have a collection of d known plaintexts and their encryptions, d (ai , pi (X)) where pi (X) = j=0 pi,j X j = Em ,r (ai ). Note that if we view the terms X, X 2 , . . . , X d as d formal unknowns, then the identities pi (r−1 ) ≡ ai (mod m ) give d linear equations in d unknowns over Z/m Z. In other words, let Y1 , . . . , Yd denote d formal indeterminates. To aid the intuition, we should think informally of associating the indeterminate Yj with the term X j . Consider the d linear equations d

pi,j Yj ≡ ai

(mod m )

j=1

over Z/m Z in the d unknowns Y1 , . . . , Yd . Note that the assignment Yj = (r )−j ≡ r−j (mod m ) satisﬁes all of these linear equations, since by assumption pi (r−1 ) ≡ ai (mod m ) and pi,0 ≡ 0 (mod m ). A standard fact2 of linear algebra says that if we are given a system of d random linear equations over Z/m Z in d unknowns, then with non-negligible probability there is a unique solution to these equations, and this solution can be found in O(d3 (lg m )2 ) time using Gaussian elimination. Hence, by the above comments, for a random choice of plaintexts ai , we expect to be able to solve the system of equations for a unique solution Y1 , . . . , Yd ∈ Z/m Z. Subsequently, Y1−1 mod m will be a good candidate for r mod m . This attack succeeds with constant probability, so after re-trying this procedure a constant number of times, we expect to learn the true value of r mod m . Once r mod m = r is known, we have everything we need to know to be able to decrypt any ciphertext we like. This attack is applicable so long as n > d. def

2

Let f (n) denote the probability that a random, large matrix over /n is invertible. It is well-known that f (p) is non-negligible when p is prime; for instance, we have f (2) ≥ 0.288, f (3) ≥ 0.560, f (5) ≥ 0.760, and so on [1]. Also, f (p) = (1 − 1p )(1 − 1 ) · · · (1 − p1n ) ≥ exp{−2/(p − 1)} ≥ 1 − 2/(p − 1), so random matrices modulo a p2 large prime have an overwhelming probability of being invertible. Next, a matrix is invertible modulo pe if and only if it is invertible modulo p, so f (pe ) = f (p). (See also [1, Corollary 2.2].) Finally, by the Chinese remainder theorem, if n = pe11 · · · pekk , then f (n) = f (p1 )×· · ·×f (pk ). In particular, f (n) ≥ e−2h(n) where h(n) = p|n 1/(p−1), so in most cases, there is a very good probability that a system of d random linear equations in d unknowns will be solvable uniquely.

238

David Wagner

Combining these two observations, we see that the Domingo-Ferrer proposal is broken when n > d. For instance, the suggested parameter sets in the original paper all had d = 3 and n = 5, 10, or 50, so we have n > d in all 6 of the 6 parameter choices suggested in the original paper, and hence all 6 of those instantiations are all insecure. Another way to recover r : polynomial root-finding. Suppose m has known factorization. Then there is a totally diﬀerent way to recover r , using algorithms for factoring polynomials over ﬁnite ﬁelds rather than linear algebra. The starting point is the following observation: each known plaintext gives an equation of the form q(r ) ≡ 0 (mod m ) where the polynomial q and the modulus m are known, but where the root r is unknown. Since several polynomial-time algorithms for ﬁnding roots of polynomials are known, this suggesting using them to learn r . The method is clearest in the case where m is prime. In this case, we can take any one known plaintext, derive an equation q(r ) ≡ 0 (mod m ) and ﬁnd its roots (of which there are at most d, and which can be found in polynomial time using standard methods for univariate polynomial factorization in polynomial time). Each root of q is a candidate value of r , and we may test it against other known plaintexts for validity. In this way, we recover r in the case where m is prime. If m is prime power, say m = pe , then we obtain the equation q(r ) ≡ 0 (mod pe ). The roots of this equation may also be found eﬃciently [3]: ﬁrst ﬁnd all roots modulo p, and then use Hensel lifting to ﬁnd the roots modulo p2 , then modulo p3 , and so on. There are at most d roots, and each such candidate for r may then be tested against other known plaintexts as before. In general, m may be an arbitrary composite. If m has known factorization m = pe11 · · · pekk , we may ﬁnd r mod pei i for each i using the methods described above, ﬁnally applying the Chinese remainder theorem to recover r mod m . Heuristically, it seems likely that this will succeed with high probability so long as we have a small number of known plaintexts. However, we have no proof of this conjecture, and so it should be viewed with some skepticism. Summary. First, we showed an eﬃcient way to recover m whenever we have a small pool of known plaintexts. Then, we described several ways to recover r . One possibility is exhaustive search; this works whenever m is small (e.g., for 3 of the 6 parameter settings originally suggested). Another possibility is an attack based on linear algebra, which works with reasonable success probability whenever n ≥ d (e.g., for all 6 of 6 parameter settings). A third possibility is an attack based on polynomial root-ﬁnding; this is conjectured to work so long as m can be factored and so long as we have a few known plaintexts, but we have no proof. These known attacks break all schemes proposed in the original paper. To repair the scheme, one might hope that other class of parameter choices might provide better security. Thus, we can ask: Is there any hope for Domingo-Ferrer’s privacy homomorphism to remain secure in the case n < d? We do not know.

Cryptanalysis of an Algebraic Privacy Homomorphism

239

There is one case where no attack strategy is known to us: namely, where m is chosen to be hard to factor and the number of texts encrypted is restricted so that n < d. One might hope for this to be secure. Unfortunately, there is some bad news: if we choose from this restricted class of parameters, then the performance of the scheme suﬀers dramatically. For instance, if we want to securely encrypt up to n = 100 messages, we might reasonably take m to be a random 1024bit RSA modulus, d and s to be slightly larger than n (say, d = s = 105), and m to be a random 1024s-bit multiple of m . However, then we ﬁnd that each ciphertext is 11 million bits long, so the scheme is likely to be extremely cumbersome in practice. For this reason, we do not see any practical way to rescue Domingo-Ferrer’s proposal.

3

Acknowledgements

I thank Dr. Josep Domingo-Ferrer and the anonymous reviewers for several useful comments on an earlier version of this paper. I thank Rob Johnson for showing me the content of Footnote 2.

References 1. R.P. Brent, B.D. McKay, “Determinants and Ranks of Random Matrices Over m,” Discrete Mathematics 66, pp.35–49, 1987. 2. J. Domingo-Ferrer, “A Provably Secure Additive and Multiplicative Privacy Homomorphism,” ISC 2002, LNCS 2433, pp. 471–483, 2002. 3. G. McGuire, “An Approach to Hensel’s Lemma,” Irish Math Soc. Bulletin 47, pp.15– 21, 2001.

Analysis of the Insecurity of ECMQV with Partially Known Nonces Peter J. Leadbitter and Nigel P. Smart Computer Science Department University of Bristol Woodland Road, Bristol BS8 1UB, United Kingdom. {peterl, nigel}@cs.bris.ac.uk

Abstract. In this paper we present the ﬁrst lattice attack on an authenticated key agreement protocol, which does not use a digital signature algorithm to produce the authentication. We present a two stage attack on the elliptic curve variant of MQV in which one party may recover the other party’s static private key from partial knowledge of the nonces from several runs of the protocol. The ﬁrst stage reduces the attack to a hidden number problem which is partially solved by considering a closest vector problem and using Babai’s algorithm. This stage is closely related to the attack of Howgrave-Graham, Smart, Nguyen and Shparlinski on DSA but is complicated by a non-uniform distribution of multipliers. The second stage recovers the rest of the key using the baby-step/giantstep algorithm or Pollard’s Lambda algorithm and runs in time O(q 1/4 ). The attack has been proven to work with high probability and validated experimentally. We have thus reduced the security from O(q 1/2 ) down to O(q 1/4 ) when partial knowledge of the nonces is given.

1

Introduction

An authenticated key agreement protocol is a key agreement protocol in which both sides are guaranteed the identity of the party with which they are agreeing a key. This is usually done through both parties having a static public/private key pair, for which the other party has the certiﬁed public key. To break the authenticity of such schemes it is clearly suﬃcient to obtain the victims private key. There are essentially two types of such protocols, those in which the authenticity is produced via a digital signature and those in which the authenticity is produced as an integral part of the protocol. The MQV [7] protocol is an authenticated key agreement protocol, proposed by Law, Menezes, Qu, Solinas, and Vanstone, based on the standard un-authenticated Diﬃe-Hellman key agreement protocol. It is believed to have known key security, forward secrecy and key-compromise impersonation resilience under the assumption of the intractability of the elliptic curve discrete log problem and the elliptic curve Diﬃe-Hellman problem. There is not yet however any C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 240–251, 2003. c Springer-Verlag Berlin Heidelberg 2003

Analysis of the Insecurity of ECMQV with Partially Known Nonces

241

formal security proof to support these claims. The MQV protocol has the same message ﬂows as the standard Diﬃe-Hellman protocol, but obtains an authentic shared key using a non-standard method for obtaining the shared secret. Hence, MQV achieves better bandwidth performance than simply signing the standard Diﬃe-Hellman message ﬂows. In this paper we introduce a scenario not discussed in [7]. Suppose one party A involved in the key agreement process can, illegitimately or otherwise, recover several of the most signiﬁcant bits of some of the secret ephemeral nonces that the second party B calculates each time A and B generate a shared secret. This partial information can come from many sources, for example a poor implementation of a random number generator or monitoring side channel information like electromagnetic radiation, power consumption or running time. We do not assume A to have any knowledge of B’s static private key. After suﬃciently many runs of the protocol, we show A is able to recover the whole of B’s static private key. Since this is the key that uniquely identiﬁes the user B, the user A is clearly able to impersonate B, possibly without B’s knowledge. Lattices were ﬁrst used in cryptology when Shamir proposed an heuristic attack on the Merkle-Hellman scheme [9] in 1982 [15] which reduced the knapsack problem to an SVP problem. They have played an important role in cryptanalysis since Coppersmith proposed an LLL based technique of ﬁnding small roots of modular polynomials, with applications to low exponent RSA [5]. The recurring theme is to construct a lattice that holds some vital secret in one of its lattice points. The characteristic we use to identify the point we are looking for is its distance from a known non-lattice point, or its distance from zero, (in which case we are searching for a small lattice point). There is no eﬃcient algorithm to ﬁnd the closest lattice point, or indeed to ﬁnd the smallest lattice point. There are however polynomial time algorithms which provably ﬁnd close vectors and small lattice vectors, namely Babai’s algorithm [1] and the LLL algorithm of Lenstra, Lenstra and Lovasz [8]. Since such small (close) vectors are rare, the vectors these algorithms recover, tend to be, or be closely related to, the lattice vector we are looking for. In practice these algorithms work remarkably well. One problem with which we are left, is how to ensure our hidden vector is small. The common approach, as exploited in this paper, is to consider the case where we are given some information, either through poor implementation or other means. The lattice attacks on RSA [2], [5] were limited by the stringent bounds imposed on the size of the decryption exponent or the number of known bits of the factors or the secret key. This is a consequence of their only being able to use the information from the encryption of one message in a given lattice. The scenario introduced by Howgrave-Graham and Smart [6] for DSA and continued by Nguyen and Shparlinkski, [10] and [11], was favourable to the attacker, since the gathering of information could be spread throughout several signatures, making the attack more realistic. It also lets the attacker construct a lattice which takes full advantage of the properties of the l∞ norm. This style of attack needs one run of the scheme to be diﬀerent to the next run (even for the same input data). In DSA, since each of the static and ephemeral keys can

242

Peter J. Leadbitter and Nigel P. Smart

be take any value modulo q the associated lattice attacks are successful. In the paper, we explain how in MQV the variety between successive runs is more limited making it more secure against this style of attack but still not completely secure. In addition we still need to solve a discrete logarithm problem to break the scheme, although one which is considerably easier than the original discrete logarithm. For the attacks on DSA and EC-DSA the lattice attacks recover the secret key without the need for this expensive auxillary step. The paper is structured as follows: In section 2 we set up the notation, in section 3 we describe the MQV protocol and in section 4 we outline our attack model. In section 5 we theoretically analyse the ﬁrst (lattice-based) stage of our attack. In section6 we describe the second stage of our attack which runs in time O(q 1/4 ). In section 7 we present our experimental results using a lattice slightly diﬀerent to that used in section 5 but which is better suited to practical situations. Finally in section 8 we present some conclusions.

2

Notation

For any m, n ∈ Z, we deﬁne mn be the unique r ∈ Z such that 0 ≤ r < n and for some q ∈ Z, r + qn = m. In other words mn returns the positive remainder on division of m by n. We let |m|q = min |m − kq| = min{mq , q − mq }. k∈Z

Let APPl,q (x) denote an approximation to the integer x (mod q), by which we mean any integer u such that |x − u| ≤ q/2l+1 . The hidden number problem is the task of recovering the hidden number b when we are given APPl,q (bti q ) for many random but known ti ∈ Fq . The hidden number problem has been studied quite extensively since ﬁrst being introduced in [4] by Boneh and Venkatesan.

3

The MQV Protocol

We now discuss the MQV protocol, we present the protocol in the elliptic curve context since our attack is only more eﬃcient than standard techniques in this case. This is because the standard discrete logarithm based attack on ﬁnite ﬁeld based MQV takes time O(L#F (1/3, c)), where F is the underlying ﬁnite ﬁeld. √ For ECMQV the discrete logarithm based attack requires time O( q), where q is the size of the large subgroup of the elliptic curve. We let F be a ﬁnite ﬁeld and E be an elliptic curve over F whose order is divisible by a prime q. We set f = log2 q + 1.

Analysis of the Insecurity of ECMQV with Partially Known Nonces

243

For any Q ∈ E(F), let Q = x2f /2 + 2f /2 where f is the bitlength of q and x is the integer obtained by considering the binary representation of the ﬁrst coordinate of Q. We can now describe the MQV protocol in the elliptic curve setting as follows: Let P be a point of order q in E(F). Two entities A and B possess a static private keys wA , wB ∈ {1, . . . , q − 1} and corresponding static public keys WA = wA P, WB = wB P. For each run of the protocol, the following steps are executed: 1. A generates the private ephemeral key rA ∈ {1, . . . , q − 1}, and computes the public ephemeral key RA = rA P . The ephemeral key RA is then passed to B. 2. B generates the private ephemeral key rB ∈ {1, . . . , q − 1}, and computes public ephemeral key RB = rB P . The ephemeral key RB is then passed to A. 3. A computes sA = rA + RA wA q and RB + RB WB = sB P. 4. B computes sB = rB + RB wB q and RA + RA WA = sA P. 5. A and B both calculate the shared secret K=

#E(F) sA sB P. q

244

4

Peter J. Leadbitter and Nigel P. Smart

Attack Scenario

In our scenario we assume that the user A wishes to obtain the static private key wB of the user B. They will aim to do this by performing a number of valid protocol runs with the user B and recording the message ﬂows, their own ephemeral secrets. User B computes both [rB ]P and [sB ]P and we assume that the attacker can determine the upper bits of the multipliers, rB and sB , used by user B. This information could be obtained using a side channel analysis such as SPA for example. So we are assuming that the attacker can compute values of ai , with 0 ≤ ai < q/2m , such that sB = a1 2 m + b 1 , rB = a2 2m + b2 , where the bi are unknown and satisfy 0 ≤ bi < 2m . Note, that in a similar situation in DSA/EC-DSA, where there is only one ephemeral key, the attacker can eﬃciently determine the underlying static secret key in polynomial time by determining only the upper four bits of the single ephemeral secret, see [6], [10] and [11]. In the ECMQV situation we will see that determining a similar number of bits of the ephemeral secrets results in only an exponential algorithm to recover the static secret. We set tB = sB − rB (mod q) (a1 − a2 )2m + (b1 − b2 ) if a1 > a2 , = (a1 − a2 )2m + (b1 − b2 ) + q if a1 < a2 . = u + (b1 − b2 ) = u + x, where u is known and x is unknown. We will ignore the case when a1 = a2 since then it is impossible to deduce the value of u above. We assume that user A interacts in this manner with user B a total of n times, ignoring all cases where a1 = a2 . For the ith run of the protocol, we then have (i) tB = xi + ui where ui is given and |xi | = |b1 − b2 | ≤ max(b1 , b2 ) ≤ 2m (i)

(i)

(i)

(i)

(i)

(i)

is unknown. Hence, ui = APPl,q (sB − rB ) with l ≤ log2 q − m − 1, and xi is less than

2m ≤ 2(log2 q−l−1) = q/2l+1 .

Analysis of the Insecurity of ECMQV with Partially Known Nonces

245

The calculations of the nonces sB = rB + RB wB q then give rise to n equations: xi − ti b + ui = 0 (mod q)

(1)

(i)

where ti = RB and b = wB . Note that: – The xi are all less than q/2l+1 in absolute value and are unknown. – The integer b lies in the range [0, q] and corresponds to user B’s static private key and is completely unknown. – The integer ui lies in [0, q] and is given. – Finally the given integers ti satisfy 2f /2 ≤ ti < 2f /2+1 . We then have that ti b − ui q < q/2l+1 for 1 ≤ i ≤ n, which gives us our hidden number problem. Our attack now proceeds in two stages: – Stage One: We recover the f /2 most signiﬁcant bits of b, using the algorithms of Babai and LLL. – Stage Two: We recover the rest of the bits of b using an analogue of the baby-step/giant-step algorithm, or using Pollard’s Lambda method.

5

Theoretical Analysis of the Lattice Stage

Here we outline the Boneh and Venkatesan algorithm proposed in [4] as presented in [10]. The only modiﬁcation being we do not choose our multipliers ti uniformly in Fq . We present our analysis quite generally, and not just to the MQV speciﬁc problem, in that we assume that the multipliers ti are of the form γαi where αi are chosen uniformly in A = {a ∈ Fq : e1 ≤ aq < e2 }. where 0 ≤ e1 < e2 ≤ q and γ ∈ Fq . Our hidden number problem is then given by ui = APPl,q (bti q ), where b is the only unknown. Note that Boneh, Venkatesan, Nguyen and Shparlinski consider the case (γ, e1 , e2 ) = (1, 0, q − 1) in their analysis, see [4] and [10]. The MQV case as discussed above is (γ, e1 , e2 ) = (1, 2f/2 , 2f /2+1 − 1).

246

Peter J. Leadbitter and Nigel P. Smart

We include the γ variable since it is a non-trivial multiplier if we consider the case where we are given the lower bits of our nonces and rearrange our problem to HNP form similarly to (1). Consider the lattice L(q, l, t1 . . . tn ) generated by the rows of:   q 0 ··· 0 0   . ..  0 q . . . ..  .     .. (2) M =  .. . . . .  . . 0 .  .   0 ··· 0 q 0  −(l+1) t1 · · · · · · tn 2 Since there exist ki ∈ Z such that bti q = bti +ki q and b ∈ Z, there is a “hidden” lattice point h = (k1 , . . . , kn , b) · M = bt1 q , . . . , btn q , b/2l+1 which is close to the known vector u = (u1 , . . . , un , 0). By the deﬁnition of ui and the size of b, we have that h − u∞ < q/2l+1 Given the lattice L(q, l, t1 . . . tn ) and u, Babai’s nearest plane algorithm [1] recovers a lattice point v, which is close to u. We have that u − v ≤ 2(n+1)/4 u − h ≤ (n + 1)1/2 2(n+1)/4 q/2l+1 and so q(1 + (n + 1)1/2 2(n+1)/4 ) . (3) 2l+1 So for suﬃciently small l, we can guarantee that the hidden vector and the recovered vector diﬀer by an extremely short lattice point. Consider the case where γ = 1, so for i = 1 . . . n, the ti are chosen independently and uniformly in [e1 , e2 ] ∩ Z. Let β ∈ Z \ {0}, Q ∈ R and let E(β) be the event that for all i, |βti |q ≤ Q. h − v∞ ≤ h − u∞ + u − v ≤

Note that E(β) = E(β + kq) for any k ∈ Z, so we need only consider −q/2 < β ≤ q/2. Also if −q/2 < β < 0, the problem is then equivalent to considering −β and ti is chosen independently and uniformly in [−e2 , −e1 ] ∩ Z. So ﬁrst consider 0 < β ≤ q/2. We then have that

e2

kq + Q kq − Q #{ti ∈ [e1 , e2 ] ∩ Z : |βti |q ≤ Q} = − +1 β β k=e1

+ max((e1 − 1 + Q)/β − e1 + 1, 0) + max(e2 − (e2 + 1 − Q)/β + 1, 0)

Analysis of the Insecurity of ECMQV with Partially Known Nonces

247

where e1 = βe1 /q and e2 = βe2 /q. Hence, P (E(β)) =

n

P (|βti |q ≤ Q) ≤

i=1

( β(e2q−e1 ) + 1)( 2Q+1 β ) (e2 − e1 ) + 2

We now consider β(e2 − e1 ) ≥ q, in which case we have n 1 4Q + 2 ≤ νn P (E(β)) ≤ q 2

n .

(4)

(5)

taking Q of the form q/(2ν+2 ) − 1/2. Notice that by the comments above, this result holds for all β ∈ Z. Furthermore the event that for all i, |βti |q ≤ Q with ti = αi γ and αi chosen independently and uniformly in A is simply E(βγ). Consider a lattice point w(z, β) = (z1 , . . . , zn , β) · M and let T = {β ∈ Z : |γβ|q ≥ q/(e2 − e1 )}. It is now easy to see that the probability that there exists a z ∈ Zn and a β ∈ T such that w(z, β)∞ ≤ Q, is bounded by q/2νn . We can then deduce that with high probability a short vector w ∈ L, is of the form w(z, β) where |γβ|q < q/(e2 − e1 ). Applying this method to MQV will yield the upper half of the bits of b. However wedo not expect to recover the lower bits since there are at least Q ∗ max(e2 ,−e1 ) values of β ∈ Fq for which w(0, β)∞ ≤ Q. Recall that we recover b completely if and only if β = 0 (mod q). The diﬃculty of recovering the actual hidden vector provides additional security against this style of attack. It substantially slows down the process of recovering the key and if the keylength is too large, this method becomes infeasible.

6

Baby-Step/Giant-Step Stage

We are now faced with a discrete log problem, W = bP , where the upper half of the bits of b are known. There are two ways of solving this problem in time O(q 1/4 ), the ﬁrst is deterministic and requires a large storage requirement, the second has minimal storage requirement and produces an expected run time of O(q 1/4 ). The ﬁrst deterministic method is Shanks’ Baby-Step/Giant-Step method, applied to this restricted discrete logarithm problem. Let d denote the known bits of b, then λ and µ ∈ Z such by the Euclidean division algorithm there exists that d = λ q 1/4 + µ. Note that W − (b − d)P − µP = λ q 1/4 P . 1. Calculate and store U = W − (b − d)P and V = q 1/4 P 2. Calculate and store the “baby steps”, Babyµ = U − µP in a hash table index by the binary representation of the baby steps.

248

Peter J. Leadbitter and Nigel P. Smart

3. DO calculate G = λV WHILE G does not equal any of the stored baby steps. (Using the hash table) 4. Recover d from µ and λ such that Babyµ = λV and hence recover b. The algorithm requires storage of O(q 1/4 ) large integers, but is guaranteed to recover b in time O(q 1/4 ). Using the Pollard Lambda method one can obtain the same eﬀect with constant storage but only in expected run time O(q 1/4 ), see [13] for details.

7

Experiments

In this section we outline the process of recovering the static private key wB in the case of MQV, both in theory and in practice. In each case, we provide evidence of success through probability calculation and experiment respectively. The following calculation does not rely on any idealistic model; it comes from results on Babai’s algorithm. However it hugely underestimates the eﬀectiveness of the algorithm in practice. We have that combining (3) and (5), it is suﬃcient that 2l > 2(p+f )/n+1 (1 + (n + 1)1/2 2(n+1)/4 ) to recover a vector of the form h + w(z, β) where |β|q ≤ 2f /2 with probability greater than 1 − 2−p . Alternatively, using a CVP∞ oracle model, we can recover a vector v which diﬀers from the hidden vector h by no morethan q/2l in the inﬁnity norm. + 2 bits known to recover Applying (5), we expect a lattice attack with f +p n a vector of the form h + w(z, β) where |β|q ≤ 2f /2 with probability greater than 1 − 2−p . Since, |β| ≤ 2f /2 , we have that 2l+1 hn+1 q and b agree on the upper half of their bits. Consequently we can use the BSGS/Pollard Lambda algorithm as described above to recover b. Under the CVP∞ oracle model, we can then break the protocol given 3 bits per nonce for 170 messages using a 160 bit prime with high probability. However, no such CVP∞ oracle exists, hence in practice we need to use a method which is not guaranteed to ﬁnd a closest vector with respect to the ∞-norm. In practice such methods are based on the LLL algorithm [8]. To see how successful we can actually be we implemented the following experiment in C++/LiDIA. For each experiment, we used a newly generated 160 bit prime q and as an alternative to Babai’s algorithm, the close vectors were found by embedding the matrix M and the vector u in the square matrix: M0 N= . (6) u 1 This is a standard technique, see [10] and [12]. The vector (u − h, 1) is then a short vector in the lattice spanned by the rows of N . To recover this vector we used two successive LLL reductions. The ﬁrst being the Schnorr-Euchner

Analysis of the Insecurity of ECMQV with Partially Known Nonces

249

implementation [14] and the second being the de Weger implementation [16]. It was found that applying Schnorr-Euchner on its own did not often produce a suitably reduced basis, whilst applying the de Weger implementation on its own was often too costly. The following table describes our experiments and the resulting success rate on a set of twenty runs. Bits Known Number of Protocol Runs Success Rate 4 30 0.60 4 40 0.50 4 50 0.90 4 60 0.90 5 20 0.55 5 25 0.85 5 30 1.00 6 16 0.40 6 18 0.90 6 20 1.00 A similar attack can also be applied if the bits known are the l least signiﬁcant (i) (i) (i) (i) of sB −rB . Say sB −rB = 2l yi +ci where yi is the only unknown and |yi | < q/2l . l −1 (mod q). We then have a hidden number problem as above with Let τ = (2 ) (i)

(ti , ui ) = (τ RB , τ ci ) and (γ, e1 , e2 ) = (τ, 2f /2 , 2f /2+1 − 1). From our theory, we expect this to be as successful as our initial case.

8

Conclusion

We have shown MQV to be insecure with keys of size less than 2320 if the attacker is able to obtain a small number of bits of each ephemeral secret generated by his victim. For a standard keylength of 2160 , the 4 most signiﬁcant bits were suﬃcient to recover the key. Using the CVP∞ model as a guide, we expect 3 bits may be suﬃcient with a more suitable l∞ -close vector ﬁnding algorithm. Although we cannot improve upon the CVP∞ oracle, we should recall that we calculated this taking upper bounds. In an ideal model where the lattice reduction uses all the information it is given perfectly, we heuristically expect l = f /n to be necessary and suﬃcient, making l = 1 possible for a 160 bit key. We note that our recovery of only half the bits in the ﬁrst stage of our attack is not unique to our hidden number problem scenario. It is a fundamental problem to the nature of our equation set (1). We choose the HNP scenario since it requires less bits known to function partially. The following modiﬁcation optimises MQV against this attack. Recall that generating Q from a point Q is simply a way of generating a random number from Q as in a signature scheme using the Fiat-Shamir heuristic. We have some freedom on the bounds we impose on the size of Q. Recall further that the attack becomes less eﬀective if our multipliers are chosen in a restricted interval. Speciﬁcally, in an interval of length ∆ the attack is only able to recover q/∆ bits. The attack is therefore best avoided as follows:

250

Peter J. Leadbitter and Nigel P. Smart

1. Choose C of minimal size in Z such that RA , RB can be chosen in [2C , 2C+1 ] without comprimising security against other attacks. 2. Choose D of minimal size in Z such that an elliptic curve group of order D is considered secure against the elliptic curve discrete logarithm problem. 3. Choose the base point P of prime order q ≥ 2C D. 4. Instead of deﬁning Q for an elliptic curve point Q = (x, y) to mean x2f /2 + 2f /2 , deﬁne it to mean

x2C + 2C .

In their paper [7] Law, Menezes, Qu, Solinas and Vanstone claimed, in reference to their taking only half the bits of the x coordinate of RA in RA , “The modiﬁcation does not appear to aﬀect to security of the protocol.” Ironically, in this setting the modiﬁcation made the protocol more secure. For this reason the idea of choosing some multipliers in a restricted interval is worth considering the future design of protocols that may be vulnerable to lattice based attacks.

References 1. L.Babai. On Lov` asz lattice reduction and the nearest lattice point problem. Combinatoria, 6, 1–13, 1986. 2. D. Boneh and Glenn Durfee. Cryptanalysis of RSA with private key d less than N 0.292 , In Advances in Cryptology – EuroCrypt ’99, Springer LNCS 1592, 1–11, 1999. 3. D. Boneh, S. Halevi and N. Howgrave-Graham. The Modular Inversion Hidden Number Problem. In Advances in Cryptology – AsiaCrypt 2001, LNCS 2248, 36-51, 2001 4. D. Boneh and R. Venkatesan. Hardness of computing the most signiﬁcant bits of secret keys in Diﬃe-Hellman and related schemes. In Advances in Cryptology – CRYPTO ’96, Springer LNCS 1109, 129–142, 1996. 5. D. Coppersmith. Small solutions to polynomial equations, and low exponent RSA vulnerabilities. J. of Cryptology, 10, 233–260, 1997. 6. N. Howgrave-Graham and N.P. Smart. Lattice attacks on digital signature schemes. Designs, Codes and Cryptography, 23, 283–290, 2001. 7. L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone. An eﬃcient protocol for authenticated key agreement. To appear Designs, Codes and Cryptography 8. A.L. Lenstra, H.W. Lenstra, Jr., and L. Lov´ asz. Factoring polynomials with rational coeﬃcients. Math Ann., 261, 515–534, 1982. 9. R. Merkle, M. Hellman. Hiding information and signatures in trapdoor knapsacks. IEEE Trans. Inform. Theory, IT-24:525-530, September 1978. 10. P.Q. Nguyen and I.E. Shparlinski. The insecurity of the Digital Signature Algorithm with partially known nonces. J. Cryptology, 15, 151–176, 2002. 11. P.Q. Nguyen and I.E. Shparlinski. The insecurity of the elliptic curve Digital Signature Algorithm with partially known nonces. To appear Designs, Codes and Cryptography.

Analysis of the Insecurity of ECMQV with Partially Known Nonces

251

12. P.Q. Nguyen and J. Stern. Lattice reduction in cryptology: An update. In Algorithmic Number Theory – ANTS-IV, Springer LNCS 1838, 85–112, 2000. 13. J.M. Pollard. Monte Carlo methods for index computation (mod p). Math. Comp., 32, 918–924, 1978. 14. C.P. Schnorr and M. Euchner. Lattice basis reduction: Improved practical algorithms and solving subset sum problems. Math. Programming, 66, 181–199, 1994. 15. A. Shamir. A polynomial time algorithm for breaking the basic Merkle-Hellman cryptosystem. In proc. of 23rd FOCS, pages 145-152. IEEE, 1982 16. B.M.M. de Weger. Solving exponential diophantine equations using lattice basis reduction algorithms. J. Number Theory, 26, 325–367, 1987.

Hardware-Focused Performance Comparison for the Standard Block Ciphers AES, Camellia, and Triple-DES Akashi Satoh and Sumio Morioka IBM Research, Tokyo Research Laboratory, IBM Japan Ltd., 1623-14, Shimotsuruma, Yamato-shi, Kanagawa 242-8502, Japan {akashi, e02716}@jp.ibm.com

Abstract. This paper describes compact and high-speed hardware architectures for the 128-bit block ciphers AES and Camellia, and reports on their performances as implemented using ASIC libraries and an FPGA chip. A 3-key tripleDES implementation is included for comparison. Small S-Box hardware designs using composite field inverters are also described, and are contrasted with conventional S-Boxes generated from truth tables. In comparison with prior work, our architectures obtained the smallest gate counts and the highest throughputs for both of the ciphers. The smallest designs were 5.32 Kgates with a throughput of 235 Mbps for the AES, 6.26 Kgates with 204 Mbps for Camellia, and 5.74 Kgates with 170 Mbps for the triple-DES by using a 0.18-µm library. The highest throughputs of 3.46 Gbps with 36.9 Kgates, 2.15 Gbps with 29.8 Kgates, and 1.07 Gbps with 17.0 Kgates were obtained for the AES, Camellia, and triple-DES respectively, using a 0.13-µm library.

1 Introduction Block ciphers are categorized into an SPN (Substitution-Permutation Network) type and a Feistel network type. A round function of the SPN ciphers converts all data bits at once, while that of the Feistel ciphers does half of the data bits at a time. Thus, the SPN ciphers require a smaller number of iteration rounds compared with the Feistel ciphers to thoroughly scramble the data bits. However, the SPN ciphers require two different data paths (round functions) for encryption and decryption, while the Feistel ciphers can use same data path for both of them. Therefore, it is said that the SPN ciphers are fast but require larger resources, and the Feistel ciphers are small but slow. However, this is not always true. In addition to the network structure, the definitions of the round functions and the configurations of each of the components greatly influence the performance in size, and speed. The performance also varies with target platforms, such as software on 32-bit or 8-bit MPUs, or hardware using an ASIC library or an FPGA (Field Programmable Gate Array). In this paper, the hardware performance of two typical 128-bit block ciphers, AES (Advanced Encryption Standard) [1], Camellia [2], and a 64-bit block cipher tripleDES (Data Encryption Standard) [3, 4] is evaluated using ASIC and FPGA implementations. The AES is the US federal standard cipher replacing the DES used for C. Boyd and W. Mao (Eds.): ISC 2003, LNCS 2851, pp. 252-266, 2003.  Springer-Verlag Berlin Heidelberg 2003

Hardware-Focused Performance Comparison for the Standard Block Ciphers

253

more than 20 years, and is a subset of the SPN cipher Rijndael [5] proposed by Daemen and Rijmen. The data size is 128 bits, and key size can be 128, 192, or 256 bits. Camellia is a Feistel cipher jointly developed by NTT (Nippon Telegraph and Telephone Corp.) and Mitsubishi Electric, and has an AES-compatible interface. Camellia has been submitted many standardization task groups [6-10]. The Camellia algorithms with a 128-bit key are described in Appendix. To compare their hardware performance, we developed many architectures, from compact to high-speed, and also optimized many of the primitive components. The most critical hardware component for both size and speed is the S-Box, and the S-Boxes of AES and Camellia have a similar structure, multiplicative inversion on a Galois field followed by an affine transformation. We introduced composite field arithmetic to minimize the size of these S-Boxes, and compared their performance with S-Boxes generated from truth tables. At the end of this paper, we also offer performance comparisons between our circuits and the conventional designs.

2

AES Hardware Architectures

2.1 Compact AES Architecture The smallest AES hardware on record is 5.4 Kgates [11], and its architecture is shown in Fig. 1, with the data I/O buses removed for simplicity. The 128-bit data is divided into four 32-bit columns, and each column is processed by a 32-bit encryption and decryption block. Multiplicative inverters in the S-Boxes are shared between encryption and decryption, and MixColumns and InvMixColumns are also merged by factoring common terms. For encryption, the data path

δ → GF(((2 2 ) 2 ) 2 ) inverters → δ −1 and affine → MixColumns is selected. The functions δ –1and δ are isomorphism functions for field conversion. The S-Box implementations are described in detail in Section 4. For decryption, affine −1 and δ → GF(((2 2 ) 2 ) 2 ) inverters → δ −1 → InvMixColumns

are used. The four 8-bit S-Boxes in the encryption and decryption blocks are reused by the key scheduler. This architecture takes 54 cycles to process a 128-bit data block, both for encryption and decryption. The paper [11] also proposed various implementations by changing the number of S-Boxes. The fastest architecture uses 16 S-Boxes for the data and 4 of them for the key, and takes 11 cycles. 2.2 High-Speed AES Architecture The high-speed architecture in [11] takes 11 cycles for both encryption and decryption, but the first cycle is used only for the AddRoundKey (XOR) operation. In order to eliminate this cycle, we put the initial AddRoundKey operation in front of the SPN loop as shown in Fig. 2. Then a 128-bit data block is stored into the data register after

254

Akashi Satoh and Sumio Morioka

being XORed with the initial key, and the SPN operation is iterated 10 times. A common 128-bit port is used for data and key input. The feedback path to the secret key register on the on the rightmost position is used to set the initial round key for decryption, which is the final round key from encryption. 8-bit Data Reg

Enc/Dec Block ShiftRows InvShiftRows

2:1

Key Scheduler

2:1

2:1

2:1

Information and Communications Security: 5th International Conference, ICICS 2003, Huhehaote, China, October 10-13, 2003, Proceedings

Embedded Software: Third International Conference, EMSOFT 2003, Philadelphia, PA, USA, October 13-15, 2003, Proceedings

Inductive Logic Programming: 13th International Conference, ILP 2003, Szeged, Hungary, September 29 - October 1, 2003, Proceedings

Distributed Computing: 17th International Conference, DISC 2003, Sorrento, Italy, October 1-3, 2003, Proceedings

Object-Oriented Information Systems: 9th International Conference, OOIS 2003, Geneva, Switzerland, September 2-5, 2003, Proceedings

Computer Safety, Reliability, and Security: 22nd International Conference, SAFECOMP 2003, Edinburgh, UK, September 23-26, 2003, Proceedings

Information Security and Cryptology - ICISC 2003: 6th International Conference, Seoul, Korea, November 27-28, 2003, Revised Papers

Information Security: 6th International Conference, ISC 2003, Bristol, UK, October 1-3, 2003, Proceedings

Information and Communications Security: 5th International Conference, ICICS 2003, Huhehaote, China, October 10-13, 2003, Proceedings

Embedded Software: Third International Conference, EMSOFT 2003, Philadelphia, PA, USA, October 13-15, 2003, Proceedings

Genetic Programming: 6th European Conference, EuroGP 2003, Essex, UK, April 14-16, 2003. Proceedings

Infrastructure Security: International Conference, InfraSec 2002 Bristol, UK, October 1-3, 2002 Proceedings

Information Security: 10th International Conference, ISC 2007, Valparaiso, Chile, October 9-12, 2007, Proceedings

Information Security: 4th International Conference, ISC 2001 Malaga, Spain, October 1-3, 2001 Proceedings

Information Security: 14th International Conference, ISC 2011, Xi'an, China, October 26-29, 2011, Proceedings

Multiple Classifier Systems: 4th International Workshop, MCS 2003, Guilford, UK, June 11-13, 2003, Proceedings

Artificial Immune Systems: Second International Conference, ICARIS 2003, Edinburgh, UK, September 1-3, 2003, Proceedings

Inductive Logic Programming: 13th International Conference, ILP 2003, Szeged, Hungary, September 29 - October 1, 2003, Proceedings

Distributed Computing: 17th International Conference, DISC 2003, Sorrento, Italy, October 1-3, 2003, Proceedings

Logic Programming: 19th International Conference, ICLP 2003, Mumbai, India, December 9-13, 2003, Proceedings

Discovery Science: 6th International Conference, DS 2003, Sapporo, Japan, October 17-19,2003, Proceedings

Object-Oriented Information Systems: 9th International Conference, OOIS 2003, Geneva, Switzerland, September 2-5, 2003, Proceedings

Computer Safety, Reliability, and Security: 22nd International Conference, SAFECOMP 2003, Edinburgh, UK, September 23-26, 2003, Proceedings

Information Security and Cryptology - ICISC 2003: 6th International Conference, Seoul, Korea, November 27-28, 2003, Revised Papers

Information and Communications Security: 6th International Conference, ICICS 2004, Malaga, Spain, October 27-29, 2004. Proceedings

php|architect (October 2003)

Scientific american (October 2003)

Artificial Evolution: 6th International Conference, Evolution Artificielle, EA 2003, Marseilles, France, October 27-30, 2003, Revised Selected Papers

High Performance Computing: 5th International Symposium, ISHPC 2003, Tokyo-Odaiba, Japan, October 20-22, 2003, Proceedings

Information Processing in Medical Imaging: 18th International Conference, IPMI 2003

Audio-and Video-Based Biometrie Person Authentication: 4th International Conference, AVBPA 2003, Guildford, UK, June 9-11, 2003, Proceedings

Information Security: 8th International Conference, ISC 2005, Singapore, September 20-23, 2005, Proceedings

Information Security: 9th International Conference; ISC 2006, Samos Island, Greece, August 30 - September 2, 2006, Proceedings

Parallel Computing Technologies: 7th International Conference, PaCT 2003, Novosibirsk, Russia, September 15-19, 2003, Proceedings

Electronic Government: Second International Conference, EGOV 2003, Prague, Czech Republic, September 1-5, 2003, Proceedings

Ad-Hoc, Mobile, and Wireless Networks: Second International Conference, ADHOC-NOW 2003, Montreal, Canada, October 8-10, 2003, Proceedings

COTS-Based Software Systems: Second International Conference, ICCBSS 2003 Ottawa, Canada, February 10-13, 2003

Cooperative Information Agents VII: 7th International Workshop, CIA 2003, Helsinki, Finland, August 27-29, 2003, Proceedings

Information Security: 6th International Conference, ISC 2003, Bristol, UK, October 1-3, 2003, Proceedings

Information and Communications Security: 5th International Conference, ICICS 2003, Huhehaote, China, October 10-13, 2003, Proceedings

Embedded Software: Third International Conference, EMSOFT 2003, Philadelphia, PA, USA, October 13-15, 2003, Proceedings

Genetic Programming: 6th European Conference, EuroGP 2003, Essex, UK, April 14-16, 2003. Proceedings

Infrastructure Security: International Conference, InfraSec 2002 Bristol, UK, October 1-3, 2002 Proceedings

Information Security: 10th International Conference, ISC 2007, Valparaiso, Chile, October 9-12, 2007, Proceedings

Information Security: 4th International Conference, ISC 2001 Malaga, Spain, October 1-3, 2001 Proceedings

Information Security: 14th International Conference, ISC 2011, Xi'an, China, October 26-29, 2011, Proceedings

Multiple Classifier Systems: 4th International Workshop, MCS 2003, Guilford, UK, June 11-13, 2003, Proceedings

Artificial Immune Systems: Second International Conference, ICARIS 2003, Edinburgh, UK, September 1-3, 2003, Proceedings

Inductive Logic Programming: 13th International Conference, ILP 2003, Szeged, Hungary, September 29 - October 1, 2003, Proceedings

Distributed Computing: 17th International Conference, DISC 2003, Sorrento, Italy, October 1-3, 2003, Proceedings

Logic Programming: 19th International Conference, ICLP 2003, Mumbai, India, December 9-13, 2003, Proceedings

Discovery Science: 6th International Conference, DS 2003, Sapporo, Japan, October 17-19,2003, Proceedings

Object-Oriented Information Systems: 9th International Conference, OOIS 2003, Geneva, Switzerland, September 2-5, 2003, Proceedings

Computer Safety, Reliability, and Security: 22nd International Conference, SAFECOMP 2003, Edinburgh, UK, September 23-26, 2003, Proceedings

Information Security and Cryptology - ICISC 2003: 6th International Conference, Seoul, Korea, November 27-28, 2003, Revised Papers

Information and Communications Security: 6th International Conference, ICICS 2004, Malaga, Spain, October 27-29, 2004. Proceedings

php|architect (October 2003)

Scientific american (October 2003)

Artificial Evolution: 6th International Conference, Evolution Artificielle, EA 2003, Marseilles, France, October 27-30, 2003, Revised Selected Papers

High Performance Computing: 5th International Symposium, ISHPC 2003, Tokyo-Odaiba, Japan, October 20-22, 2003, Proceedings

Information Processing in Medical Imaging: 18th International Conference, IPMI 2003

Audio-and Video-Based Biometrie Person Authentication: 4th International Conference, AVBPA 2003, Guildford, UK, June 9-11, 2003, Proceedings

Information Security: 8th International Conference, ISC 2005, Singapore, September 20-23, 2005, Proceedings

Information Security: 9th International Conference; ISC 2006, Samos Island, Greece, August 30 - September 2, 2006, Proceedings

Parallel Computing Technologies: 7th International Conference, PaCT 2003, Novosibirsk, Russia, September 15-19, 2003, Proceedings

Electronic Government: Second International Conference, EGOV 2003, Prague, Czech Republic, September 1-5, 2003, Proceedings

Ad-Hoc, Mobile, and Wireless Networks: Second International Conference, ADHOC-NOW 2003, Montreal, Canada, October 8-10, 2003, Proceedings

COTS-Based Software Systems: Second International Conference, ICCBSS 2003 Ottawa, Canada, February 10-13, 2003

Cooperative Information Agents VII: 7th International Workshop, CIA 2003, Helsinki, Finland, August 27-29, 2003, Proceedings

Recommend Documents