Burdens of Proof: Cryptographic Culture and Evidence Law in the Age of Electronic Documents

Attacks and Adversaries

74 Chapter 4 and that the document has not been modified since the signature’s creation (data integrity). Non-repudiation has subsequently migrated back from the standardization universe into the scientific cryptography literature. To the three objectives of historical concern to the discipline—confidentiality, data integrity, and authentication—the Handbook of Applied Cryptography adds a fourth, non-repudiation, defined as “a service which prevents an entity from denying previous commitments or actions.”26 This is an ambitious goal. Legal scholar Jane Winn humorously notes, “As anyone with children knows, you cannot prevent someone from ‘falsely denying’ an action.”27 Nevertheless, it is under the umbrella of non-repudiation that cryptography has staked a claim as a forensic science essential to the network society. Attacks and Adversaries To these security services, cryptographers would add a taxonomy of attacks, a taxonomy that models an adversary’s resources as he tries to break the system and defeat the security properties of signatures. That is, if signatures provide authentication, then a corresponding threat is the ability for an Figure 4.6 The scene at the courtroom during evaluation of signed documents. From Birgit Pfitzmann, Digital Signature Schemes: General Framework and Fail-Stop Signatures (Berlin: Springer, 1996), 13. Used by permission. The Equivalent of a Written Signature 75 adversary to substitute someone’s identity for his own (see figure 4.3). If signatures provide data integrity, a corresponding threat is the ability for an adversary to forge signatures on messages of her choice (see figure 4.4). If signatures must “convince a judge” and “protect against false denials,” a corresponding threat is the ability for the signer to create signatures that can be easily denied and fail to convince a third party (see figure 4.5). The development of means to effectively protect against these threats has signi ficant implications for the design and usability of cryptographic signature technologies and the infrastructure necessary for their large-scale deployment. The Threat of Substitution Diffie and Hellman argued that public-key cryptography solved a fundamental obstacle to electronic commerce by eliminating the need for parties for prior communication in order to establish common keys. If Alice wants to send a confidential message to Bob, she acquires Bob’s public key and encrypts her message with it. If she wants to send him a signed message, she encrypts it instead using her private key, and Bob can verify the resulting signature using Alice’s public key. But how exactly do Alice and Bob gain access to each other’s public key? In both scenarios, Diffie and Hellman proposed that the public key simply “be made public by placing it in a public directory along with user’s name and address.”28 Provided with access to such a centralized telephone book, each user could simply obtain the necessary public key whenever required. But such a scenario prompted the question of how Alice and Bob can be certain they have obtained each other’s authentic public keys. A simple subversion of the public directory seemed immediately possible: by substituting Bob’s public key with his own, an adversary may send messages to Alice that will appear to have originated from Bob, given that the signature verification process will proceed using the subverted public key. The precise details of how parties might obtain authentic public keys would turn out to have great practical import for the implementation of public-key cryptosystems . To understand why, it is useful to retrace the history of the technical design of what came to be known as public-key infrastructures. Rivest, Shamir, and Adleman addressed the issue in their RSA paper, suggesting that the authority managing the public file be assigned its own public/private key pair with which to authenticate its communications 76 Chapter 4 with users. They proposed the following scenario: whenever a user joins a network, she (a) registers her public key with the public file in person or through any suitable offline channel; in return, she (b) receives (in similar offline manner) the public key of the public file authority. Each time the user requires the public key of another user, she (c) requests it from the public file authority. The authority (d) sends a copy of that key, itself signed with the public file authority’s private key. The user then (e) verifies the public file’s...