ESTABLISHING THE CRITICAL ELEMENTS OF ELECTRONIC COMMERCE
The ball is rolling and there's no stopping it now! Far beyond a theoretical possibility, serious business solutions such as electronic commerce and collaborative work applications via the Internet are fast becoming everyday realities. But most present implementations only foreshadow what is to come. Current systems use encrypted sessions to guard against eavesdroppers, but can these systems really stand up to the test when faced with a full-fledged legal challenge? What happens when one party to an ill-fated electronic deal denies the terms of such a contract, when it was sent, or that it was even sent? The move to web-centric business/work models will require solid technical solutions that provide solid answers to such questions. Fortunately, a powerful synergy between two presently available technologies, Trusted Time-Date Stamping (TTDS) and Public Key Infrastructure (PKI), provides assurances that come close to achieving the elusive "holy grail" of nonrepudiation to meet this challenge. Electronic TTDS is being pioneered with the Digital Notary® Service by Surety.com Inc.,[2] and is increasingly recognized as a powerful complement of PKI.
The concept of agreement is the fundamental keystone of business relationships, whether multi-billion dollar contracts or group work-flow processes are involved. Successful commerce requires that parties have the power to create legally enforceable agreements that are acknowledged by both parties. To this end in both the paper-based and online worlds, if Bob seeks to enforce his agreement with Alice, he first needs to attribute the particular agreement to Alice before tackling the further question of Alice's intent to be bound. When dealing with attribution in the online world, attorneys are increasingly borrowing the term nonrepudiation from the information security field to describe a situation where Alice's agreement is robustly attributed to her. Specifically, nonrepudiation refers to the inability of a party to falsely deny sending the particular document or message upon which a legal agreement is founded.
For example, after making an online deal that turns out to be unprofitable to her, Alice might try to deny that she was in fact a party to an agreement with Bob, by claiming that an imposter "spoofed" her identity. However, to the extent that nonrepudiation can be established, Bob (the relying party) can effectively block a lying Alice from wriggling out of her bad deal. More demanding than authentication (which merely requires Alice to prove her identity to Bob), nonrepudiation requires proof that Bob can use to persuade a third party as to the attribution of the transaction to Alice, notwithstanding Alice's attempted denial. Alas, such nonrepudiation is fully achievable only in a world of ideal, theoretically perfect security. In the real and imperfect world, where technology must interface with legal principles used for dispute resolution in commercial transactions, the emerging concept of legal nonrepudiation is where the rubber meets the road, because it helps decide who pays – Alice or Bob. Legal nonrepudiation is generally established by strong and substantial evidence, sufficient for Bob to convince a judge, jury, or other third party that Alice's denial of the who, what or when of the document is false.[3]
Traditionally, agreements have been proven, and given legal significance via signed paper documents that evidence who the parties are, what duties and obligations the parties intend to establish, and when the legal relationship begins and ends. Complex and overlapping sets of statutes and court decisions have accumulated over centuries to govern the commercial relationships of private parties, under the assumption that the transaction is evidenced by trustworthy physical documents. With the natural inertia and conservatism of a common law judicial system, these rules, with their basis in printing press technology, are not about to radically change. And yet it's clear that the models for doing business are radically changing, and within an incredibly short time frame. What happens when worlds collide? And what can be done to reconcile the old with the new?
The answer lies in the ability of new technology to provide trustworthiness that is functionally equivalent (and often superior) to traditional methods. For example, a paper document is generally trusted to fix the time of an event because methods exist to establish the age of the document. It requires special forgery techniques to alter a time-date stamp on a paper, or to defeat expert forensics regarding aging. Thus, if an electronic document could be marked in a trusted way to certifiably prove its age, then for the purposes of supporting existing legal assumptions, the electronic document would be functionally equivalent to its paper counterpart. With this assumption restored, the existing legal rules may be applied to achieve contract enforceability.
TTDS and PKI are available, proven technologies that can be used to establish the elements of nonrepudiation, with results that can exceed our expectations for a paper-based system. Each of these technologies brings its own cards to the table, and the combination draws a winning hand. As noted above, a useful way to think of nonrepudiation is in questioning when an electronic document was created, what was the content of the document at the time of creation, and who created it. The questions of when and what are authoritatively answered by the Surety.com Digital Notary® Service TTDS, which provides a painless and routine way to freeze the content of electronic documents in time. To round out the package, PKI systems address the who and what questions using digital signatures, which provide a powerful means of binding a person's identity to the content of an electronic document "signed" by that person.
The patented Digital Notary® Service provides assurance that both document creation time and content cannot be repudiated, even when transmitted through a completely open and insecure environment such as the Internet. To accomplish this, the Digital Notary® Service uses an elegant but simple approach to resolve when and what issues. Local user software generates a small but unique digital fingerprint of the data in the document. This fingerprint (also called a hash) is transmitted to a central server computer which notes the time of receipt, combines it with other hashes received at that time, to generate its own superhash, after which it returns a Notary Record to the user. At a later time, when the user needs to authenticate the time and content of the document, the local software can regenerate the superhash from the stored document and its Notary Record. This regenerated superhash is then compared to the actual superhash that was originally created by the server. If they match, then both the document time of creation (when) and content (what) are unassailably verified. No one - not even the folks at Surety - can go back in time to insert different content with superhashes that match. Additional Digital Notary® technical details are available at http://www.surety.com.
PKI addresses nonrepudiation of identity using a public/private, dual-key encryption system that allows users to uniquely sign documents with a digital signature. The details of this system are documented in the PKI tutorial contained in the ABA Digital Signature Guidelines published in 1996.[4] Under this system, Alice (the subscriber) attaches a digital signature to a document using her own privately-held encryption key (the private key). The private key has a public counterpart (the public key) which is available to be used by anyone to verify that the digital signature was signed with the corresponding private key. By binding the identity of Alice to her public key in a digital certificate, a trusted third party known as a certification authority (CA) completes a factual chain of inference that Alice signed the document. This factual chain of inference in turn provides proof to support a legal claim by Bob (the relying party) that Alice signed the document. Under the Digital Signature Guidelines[5] and digital signature laws enacted in some jurisdictions,[6] a rebuttable legal presumption that Alice signed the document facilitates Bob's effort to achieve legal nonrepudiation in the face of denials by Alice. In addition, the digital signature system also uses a hash process to establish that there has been no modification of the signed material since it was signed. Thus, the digital signature strategy supports nonrepudiation as to both the who and what attributes of the electronic document.
In comparing TTDS to PKI, two significant differences are immediately apparent. First, unlike TTDS, PKI requires the use of a pair of keys that require special handling. If the private key owner should lose control of his/her private key, such a compromise of the private key would require revocation of the key pair and the public key certificate. If control of the private key passes to an unidentified imposter and reliance upon the certificate occurs before it can be revoked, then two innocent parties could end up in a dispute as to which one will bear the loss caused by the imposter. On the other hand, by fixing content to a particular time rather than to a particular signer, the Surety Digital Notary® Service entirely avoids the use of keys, and thus sidesteps this disadvantage of a key-based digital signature system when providing assurance as to the what attribute. Second, PKI needs a trusted third party CA to vouch for the fact that a public key belongs to a particular individual, while in TTDS, the third party server computer simply creates the necessary superhash at a given absolute time.
These differences, and the inherent simplicity of TTDS, are of great importance when the two technologies are combined, because the TTDS system and the PKI system can strengthen and complement each other. The Digital Notary® Service acts as a powerful complementary ally of a digital signature system by bolstering trust in the functions of the CA. Since the Digital Notary® Service provides a keyless when/what authentication system, and PKI systems provide a key-based who/what authentication system, the combination of the two systems provides critical backup as to document integrity. But more critically, the combination of the two systems working together provides a highly robust infrastructure for the delivery of all three security services: when, who, and what.[7]
How is this so? Consider a simple example showing how TTDS eliminates critical temporal ambiguities in a contracting transaction using PKI. Suppose that Alice uses PKI to digitally sign and send an e-mail order to stockbroker Bob, instructing Bob to immediately buy a volatile stock at the market price. Unfortunately, due to unknown delays (perhaps a computer overload caused by a large number of orders), Bob actually places Alice's order hours later when the market price is much higher. Consequently, Alice then attempts to rescind the unprofitable purchase because of Bob's unreasonably delayed execution. If the parties dispute the critical issue of the time the e-mail message was sent by Alice or received by Bob, PKI provides no assurance as to when these events occurred (although it does provides legal nonrepudiation as to the who and what issues). But such assurance is necessary because Alice might have changed her PC system time before signing the message, or Bob might have tampered with the received message. In the absence of TTDS, other forensic means, perhaps expensive and uncertain, may be needed to prove the times when critical events actually occurred. How much simpler and predictable the case would be if Alice's digitally-signed message and/or the receipt of the message by Bob's system had been time-stamped using TTDS!
As communications between contracting parties becomes increasingly reliant upon electronic document transfers, nonrepudiation techniques must be robust in protecting against exposure to fraud. The use of digital signatures closes many avenues of misrepresentation, but does not by itself totally guard against the age-old scam known to lawyers as “fraud in the factum.” To illustrate this fraud, consider a situation where the victim of the scam, without negligence, signs a contractual document that is radically different from that which he believes he is signing. In the electronic context, it goes something like this: Alice and Bob have been exchanging e-mail messages and telephone calls to negotiate the terms of a lengthy agreement. Revised copies of the agreement have been sent back and forth as e-mail attachments, redlined to show changes from prior drafts. At the conclusion of negotiations, Alice has drafted the final agreement, and both sides have read and approved this completed electronic version of the document. The plan is now for Alice to digitally sign the final document, and send it to Bob for his digital signature. Bob assumes that the digital signature will prove that Alice signed the document, and that its contents have not been altered. He’s right isn’t he? Well, maybe not…
Assume that just before she signed the document, Alice modified some small, but significant terms buried pages deep in the agreement, in a way that would not be obvious to Bob, who has already reviewed and approved the previous “final” version. Here, we assume that Bob did not take the precaution of performing a last, independent redlining comparison against the previously-approved version. In this situation, Alice’s digital signature does not provide assurance as to the particular “what” attribute that Bob needs to establish, in order to block fraud in the factum. True, the digital signature proves that Alice signed the document, and true also, it proves that the document was not altered after Alice signed it. But unfortunately, the digital signature fails to prove that the document was not altered after Bob reviewed it and before Alice signed it.
Again, TTDS could have prevented this potential fraud when used in conjunction with the digital signature. If the mutually approved version of the contract had been reliably time-date stamped at the time of final review, prior to final signature, then Alice’s ploy would have been immediately detected, and the fraud in the factum blocked. Had Alice tried to alter the final version upon signing it, the Digital Notaryâ Service software would unmask the change. Here, Bob could simply compare the superhash regenerated from the document as received, with the superhash published at the known time of final agreement, and if these superhashes did not match, Bob would know that the content of the document had been altered. This would be true even if Alice's alteration consisted only of one deletion or substitution of the word "not", or of a switch of a single inconspicuous character. By combining TTDS and PKI in this situation, TTDS assures that Bob is signing what he thinks he’s signing, and PKI assures that the final document can be attributed to Alice as a signing party to the contract.
But the relationship between PKI and TTDS goes even further. An important legal parameter of a PKI certificate is its operational period. The operational period defines the period of time during which a verifiable digital signature must occur – beginning with the time the certificate is issued, and ending with the time the certificate expires according to its terms, or is sooner revoked.[8] If a document is digitally signed after the end of the operational period, Bob's reliance on that digital signature would be considered unreasonable.[9] Moreover, Bob will not benefit from the rebuttable presumption that the signature was indeed Alice's in those jurisdictions where that rule exists. So far, so good.
But what happens when a private key is stolen or otherwise compromised before the natural expiration of the operational period? In this case, Alice, the owner of the key has a duty to notify the CA regarding this security breach. The CA then revokes the certificate, thus truncating the original operational period, and publishes this fact of revocation either in a directory of certificates or in a separate certificate revocation list. This means that only those signatures that were made prior to the revocation are legally verifiable by Bob, the relying party, and can entitle him to enjoy a favorable presumption that Alice signed the message. Note that when Bob attempts to verify a digital signature, he will normally receive immediate notice of a revocation. During the process of verification, a relying party will retrieve a new certificate from the CA (or ask the CA to freshly validate an existing certificate). If the certificate has been revoked, the CA will so notify in the retrieved certificate, and Bob will now be warned that he may not be reasonable in relying on the digital signature. But in some situations, the party intending to rely may not receive this immediate notice. To reduce delays and network traffic, relying party systems may store or cache a local address book of certificates for use in verifying received digital signatures. If this is the case, Bob might not have notice that a cached certificate had in fact been revoked, until after reliance has occurred and it is too late.
Under these combined circumstances (i.e., revocation by the subscriber, and caching by the relying party), legal nonrepudiation of the signer's identity might be weakened. To see how this is so, consider the following example. On Wednesday, Alice’s certificate is revoked, but on Thursday, Bob uses a cached certificate to verify Alice’s signature in a message. Bob then relies to his detriment on the content of the message and suffers financial loss. Had Bob freshly validated the cached certificate by checking with the CA for a possible revocation, he would have been on notice that Alice’s certificate had been revoked. He then would have known not to rely on the message without further proof of its authenticity. However, Bob used a cached certificate and did not receive this notice, and so he now seeks to recover his losses against Alice by claiming that Alice had signed the message prior to the revocation (say, on Tuesday). Alice, of course seeks to avoid the presumption of attribution to her, and thus states that she never signed such a message, and that the signature must have been affixed by an imposter after the Wednesday revocation.
Thus in this scenario, the dispute revolves around the time at which the message was signed. Was it signed by Alice before the revocation? Or was it signed by an imposter after the revocation? From the given facts we don’t really know, and as before, forensic proofs will be required to establish the time of an event critical to legal nonrepudiation. Once again TTDS nicely dovetails with PKI to bolster non-repudiation. If all messages were routinely and automatically time-stamped upon transmission, then with little sweat or cost, the parties would know whether the digital signature was affixed before or after the certificate had been revoked.
This interlocking relationship between TTDS and PKI may actually be pervasive throughout the chain of PKI operations. When a CA issues a certificate binding an owner’s identity to a private key, the CA also signs the certificate with its own digital signature so that the relying party receiving the certificate knows that the certificate came from the trusted CA, and is not a rogue certificate. But how does a relying party know that the CA’s signature is valid? In a hierarchical system of CAs, a number of CAs may be involved, and each CA’s certificate needs to be validated up the chain - that is, verified by another, higher level CA until the master, “root” CA is reached. The root CA’s public key is so well known and established that it is unnecessary to further verify its signature.
Again, so far so good, so what’s the problem? The problem is that PKI only indicates who is vouching for the CA’s certificate, but not when this took place. If a certificate issued to a CA’s certificate has expired or been revoked, all certificates the CA issues to Alice after that time will not be valid, because the CA has signed them outside of the operational period of its certificate. Perhaps years later, when an old transaction between Alice and Bob becomes the subject of dispute, there will be a need for a practical method to confirm upon audit that all certificates up the chain were issued during their operational period. A possible elegant solution is to have each certificate issued by a CA (and the CA's certificate issued by a higher CA) be time-date stamped at the time it is issued, providing convenient and cost-effective proof that all digital signatures occurred during the operational period of their certificates.
The value-added possibilities of TTDS/PKI synergy have not gone unnoticed in the PKI industry. The combination of TTDS and PKI has been recognized by the ABA Digital Signature Guidelines to be critically important to many aspects of a trustworthy system of digital signatures.[10] The Certification Practice Statement of VeriSign, Inc., a CA industry leader, provides that a number of its critical messages, including all its certificates and certification revocation lists, are to be reliably time-stamped, with cryptographic-based time stamps to be implemented incrementally for all relevant messages of issuing authorities.[11] In addition, in its FAQ at http://www.rsa.com, RSA Data Security Inc. (a leading provider of public key encryption software) agrees with the need for combination of TTDS and PKI services.[12]
In summary, the who/what/when nonrepudiation resulting from the use of both TTDS and PKI technologies is likely to take the security of electronic commerce to a new plateau of acceptance. From a legal perspective, this combination permits the formulation of simple and fair rules of legal nonrepudiation that will nurture rather than confuse the electronic commerce explosion presently in progress. By preserving and sometimes exceeding the legal and functional equivalence between paper-based and electronic signatures, these technologies will further facilitate the application of the existing commercial law to brand new web-centric business models that will arise in the future. As the premier TTDS system, Surety.com’s Digital Notary® Service mitigates the risk of using electronic documents in electronic commerce by providing a reliable and non-repudiatable system for authenticating the when and the what of digital information.
|
NWK3: 421589.09 |
[1] Charles R.
Merrill (cmerrill@mccarter.com) is a partner of the 240-attorney law firm of
McCarter & English, L.L.P., headquartered in Newark, New Jersey
(www.mccarter.com), where he chairs the firm’s Computer and High Tech Law
Practice Group. He is Co-Reporter of
two pioneering projects of the ABA Information Security Committee dealing with
the law and technology of public key infrastructure (PKI) and time-date
assurances, Digital Signature Guidelines (1996), and
PKI Assessment Guidelines
(in progress), Mr. Merrill writes
and speaks frequently on the legal issues of e-commerce and internet security,
and is webmaster of the website www.pkilaw.com. Robert Burger, Esq., his colleague in the
McCarter & English Computer and High-Tech Law Practice Group, contributed
significantly to the preparation of this article. The views expressed in this article are Mr. Merrill's personal
views, and not necessarily those of any other person or organization.
[2] Surety.com Inc. (http://www.surety.com), headquartered in Reston, VA.
[3] See Information Security Committee of ABA Section of Science and Technology, Digital Signature Guidelines (1996), Section 1.20 (Nonrepudiation) (specifically mentioning identity and integrity only) (http://www.abanet.org/scitech/ec/isc/dsgfree.html).
[4] Id.
[5] See Digital Signature Guidelines, Guideline 5.6(2) (Presumptions in Dispute Resolution).
[6] E.g., States of Utah, Washington, Minnesota, Illinois.
[7] See Digital Signature Guidelines, Guideline 1.33 (Time Stamp).
[8] Digital Signature Guidelines, Guidelines 1.22 (Operational Period of a Certificate), 1.36 (Valid Certificate), and 1.29 (Revoke a Certificate).
[9] Digital Signature Guidelines, Guideline 5.4 (Reasonableness of Reliance).
[10] Digital Signature Guidelines, Guideline
1.33 (Time-stamp), Comment 1.33.2; and Guideline 1.35 (Trustworthy System),
Comment 1.35.7.
[11] See VeriSign Inc., §3.7 Certification Practice Statement v 1.2 (5/30/97) (https://www.verisign.com/repository/CPS1.2/CPSCH3.HTM#_toc361806984) (Visited June 11, 1999).
[12] See RSA Labs FAQ 7-11, "What is digital timestamping?" (http://www.rsa.com/rsalabs/faq/html/7-11.html) (visited June 11, 1999).