The Role of Contract Law and Evidence in Online Security

As noted in Chapter 2, security, even from a purely technical standpoint, has negative and positive aspects: it is both a barrier to entry and a portal for privileged access. This chapter builds on the positive aspect of security by describing how it can also, literally, “secure the law.”

While there is a general appreciation of this symbiosis between law and security, it is evident that too much security is still applied unthinkingly. Few would dispute the truism that “security is a process, not a product.” Despite that, “security” is too often viewed as a fit-and-forget panacea. It isn’t. All security is applied security.

By itself, the term “security” does not support a precise definition. Security is a mere shopping list of technical products and technical and human processes and procedures. Panic or comfort buying of security products may have a counterproductive effect. More security can result in worse security. If you know that your PC/system is unsecured, you may at least exercise some caution when using it.

Conversely, greater business misfortunes are likely to befall someone who acts in ignorance of technical vulnerabilities. Such complacency is often exacerbated by a blinkered reliance on a security product that may provide strong but incomplete security. Ironically, the greatest commercial calamities are likely to befall those users who, despite being technically aware, remain ignorant of the negative legal implications of such technical vulnerabilities. We need to be able to justify our security spending by reference to defined security and legal benefits. We need to ask ourselves: “If security is the answer, then exactly what is the question?”

The following part of this chapter suggests what that “clarifying question” should be, and then attempts to demystify both law and security by isolating the main components of each, and by considering where and why they relate to each other.

If Security Is the Answer, Then Exactly What Is the Question?

The question is unequivocal: What security do you need to contract online? In generic terms, which security items do you need from that list? Why do you need them?

Culturally, we have been conditioned to think narrowly of online security as a tangible, often technical response to a range of equally tangible and mostly technical issues. However, the value of technology does not stop there. Most societies depend on a stable and impartial system of justice to rein back, and provide a bulwark against, abuses of commercial and political power. For instance, it is a truism that businesses cannot function in a society where courts are corrupt and where, as a consequence, contracts may be flouted with impunity.

Up to now, societies have looked to the checks and balances of their constitutions as the guarantors of those bedrock systems of justice. In the 21st century, when so many relationships with and between businesses and with government departments are already being conducted online, it is clear that traditional checks and balances are struggling to cope with the vulnerabilities of online contracting. This is where technical security measures can also play a wider legal role—by positively securing the legal components of a contract. Citizens and businesses alike depend on a shared framework of fundamental legal conceptual components.

Until we remind ourselves of what those fundamental legal components are, we cannot begin the technical process of securing them in a systematic manner.

Legal Components: A Primer

Two definitions of “contract” are extant in common law. The classical common law definition holds that a contract is “. . .a promise or set of promises which the law will enforce"^[1] . A hybrid, civil law–influenced definition holds that a contract is “. . .an agreement giving rise to obligations which are enforced or recognized by law^[2]. The second limb of each definition—enforceability by law—inhabits a shared conceptual space. That aspect is directly relevant to the issues considered in this chapter. Generally, in common law jurisdictions, a validly formed contract comprises four components:

Offer The terms of the offer must be clear and unambiguous.
Acceptance The acceptance must be final and unequivocal.
Consideration In other words, “money or money’s worth.” It goes without saying that a recipient of goods or services must pay for them (apart from the limited instances where a promise is contained in a deed, under seal). Incidentally, note that “payment” does not have to be monetary; and, in the absence of fraud or mistake (and apart from various consumer protection laws), the law generally has little interest in investigating the commercial adequacy of any consideration.
Intention to create legal relations The parties must have intended to form and be bound by a contract. Historically, this stipulation has been imported into the common law from civil law jurisdictions where no doctrine of consideration exists. Practically, courts assume that (for instance) business-to-business contracts are attended by the requisite legal intent.

In other (perhaps more intuitive) words, online contracting depends on an ability to prove

What was agreed?
When was it agreed?
Who agreed to it?

Since much of the remainder of this chapter assumes a working knowledge of digital signatures and of public key encryption, the next section is a brief reminder of information set out in greater detail in Chapter 2.

Note

The rash of e-commerce and digital signature laws enacted in most jurisdictions the world over neither significantly add to nor detract from those component principles. They do not prescribe any technical standards. Generally (there are some residual exceptions that are outside the scope of this chapter), they confine themselves to bland confirmatory statements. The following extract from the Electronic Signatures in Global and National Commerce Act is typical of similar provisions in European Union (“EU”) directives and in domestic EU enactments: “…a signature, contract, or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form…”

Digital Signing

Public key cryptography is a mathematical transformation based on key pairs. The sender and the recipient at either end of a communication channel will each have a key pair containing a public key and a corresponding private key. Public key signatures and encryption ensure

Authenticity and integrity Data encrypted by the sender’s private key can only be decrypted by the sender’s public key. Both the data and the validating public key must be correct if validation is to be positive. “Correct data” means that the data’s integrity has been protected; “correct public key” means that the sender has been authenticated (details below).
Confidentiality Data encrypted with the recipient’s public key can only be decrypted with the recipient’s private key. Hence, only the recipient can decrypt the data.

This key-pair system is an essential component of a legally binding virtual infrastructure. By contrast, symmetric key cryptography (where sender and recipient rely on one so-called “shared secret” key) is susceptible to a “man in the middle attack.” A “shared secret” is a contradiction in terms; and, if one party decides subsequently to renege on a contract and deny that he or she ever sent a particular communication, they need only claim that the key has been intercepted and used by a third party—or even by the other party.

Note

Benjamin Franklin once observed: “…three may keep a secret, provided two of them are dead…”

The key-pair system means that it is computationally infeasible to derive the private key from knowledge of the public key.

This is what happens during a digital signing:

The sender prepares a string of data; for example, a purchase order expressed in XML.
To save processing power and time, the sender prepares a “hash” (essentially a short, unique, mathematically derived summary) of this document.
The sender encrypts the hashed document with the sender’s private key. This encrypted hash is the actual digital signature.
The sender sends the digital signature and, if required, the original data (if confidential, this original data can be further encrypted) to the recipient.
The recipient verifies the sender’s digital signature with the sender’s public key. The signature will either contain the public key or point to the relevant directory. This authenticates the sender’s identity.
The recipient then repeats step 2 to create a duplicate hash of the original data, using the same hash algorithm as the sender.
The recipient compares the two hashes. If they are identical, the recipient is assured thereby that the data has not been altered after signing by the sender.
Finally, the recipient obtains a digital certificate from a certificate authority (or from the sender) and validates it. Validation confirms the authenticity of the sender. This will confirm the sender’s public key, name, and other specified information. The digital certificate will have been itself signed by the certificate authority.

At this point, it is useful to look at how the law deals with electronic and ink signatures, and to address some of the more prevalent misconceptions.

Dispelling the Myths

A digital signature is simply a particular kind of electronic signature; the terms are not synonymous. As yet, there has been no narrowly exclusive statutory or judicial definition of “electronic signature.” That term could include methods as diverse as facsimile signatures, a typed name at the bottom of a plain e-mail message, an e-mail origination header, a digital signature, a biometric method, a personal identification number (“PIN”), a smartcard, and so forth.

Caution

Digital signatures are sometimes also confused with digitized electronic signatures. These are graphical representations of a handwritten signature, such as those that UPS and Federal Express use. These are not bound to signed data. Their stand-alone evidential value is slight. They must not be confused with digital signatures proper.

Section 2 (8) of the Uniform Electronic Transactions Act provides a typical legislative definition of an electronic signature:

“[a digital signature is]…an electronic sound, symbol, or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record.”

Similarly, Article 2 of the EU’s Digital Signatures Directive provides a typical legislative definition of a digital signature:

“…[an] electronic signature [is one] which…is uniquely linked to the signatory…is capable of identifying the signatory…is created using means that the signatory can maintain under his sole control; and…is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable…”

Such legal definitions are open-ended. They try to balance forward-looking technical agnosticism with legal stipulations deriving directly from the four legal elements of a contract set out previously. Such stipulations do little more than reflect the common law evidential fundamentals that an ink signature must also satisfy.

Apart from some classes of contracts falling under residual aspects of the Statute of Frauds, neither statute law nor common law seeks to stipulate or define the mechanics of the contractual signing process. The reason for this is obvious: the legal fundamentals of a contract (set out previously) are self-contained. There is no legal need for lawyers also to concern themselves with mandating signing or with the mechanics of signing. Any misguided common law or statutory incursions into this area would do little but add confusion and inflexibility into clear and settled common law rules governing the creation of a contract.

Note

In early Bavaria, certain commercial deals were only concluded once the youngest male present had had his ears boxed. Similarly, illiterate signatories still mark an “X” in lieu of signing their name. Equally, in the Irish Supreme Court decision in Casey v. Irish Intercontinental Bank [1979] I.R. 325 (S.C.), a lawyer instructed a secretary to type out the material terms of an agreement on headed notepaper. The lawyer did not sign the typed letter. Despite this, the Irish Supreme Court held that the lawyer had adopted the heading as his signature, with legally binding effect.

In strict legal theory then, a contract doesn’t depend on any signature; it depends on the will of the contracting parties. Practically, it also depends on there being an incontrovertible means of proving that contracting will. While a traditional ink signature is a useful evidential tool, it is important not to become confused between the contract itself, and the means of signifying consent to it. Technical purists often point out, with justification, that a digital signature is not directly analogous to an ink signature. In one sense, this is a technical truism: a digital signature involves a necessary separation of initial creation and subsequent usage.

This separation does not exist in the paper world. This is an obvious point, but it bears stressing. While an ink-on-paper signature can be forged, it is almost impossible to re-create or to reuse. A forger could not cut out an existing paper signature with a pair of scissors and affix it to a subsequent contract! However adept the forger, minute differences are inevitable, and a handwriting expert (doubtless aided by a handwriting analysis software product) will be able to detect these. By stark contrast, an unsecured private key on a PC might, in theory, have been used by anyone.

However, this carping, while based on factual technical distinctions, is in danger of missing the legal point. It is not legally material that the technical mechanisms involved in a digital signing are not sequentially congruent with the technically trite process of putting pen to paper. What matters is that either process is understood to be, and is capable of being, a reliable means of signifying the signer’s consent to the contents of an e-mail or a document.

From a legal standpoint then, it is arguable that the loose use of the word “signature” to describe the process whereby one signifies consent to a contract by electronic means is legally efficient. Everyone understands the legal effect of signing a document—you are signifying that you both understand the terms of a contract and that you agree to be bound by these terms. The widespread use of the traditional word “signature” to describe the (admittedly technically distinct) process of denoting understanding and consent online will obviate any arguments that might otherwise have arisen. If a less familiar term than “digital signature” had been adopted, it is likely that individuals, out of cynicism or genuine error, might have claimed that they “failed to realize” that they had in fact given their consent to a contract.

See also the discussions under the headings “Digital Signatures: Legally Neutral Until Secured” and “Digital Signatures: An Emerging Legal Hierarchy,” later in this chapter.

Mapping Legal Components to Technical Security Components

Each of the conceptual legal components previously outlined (together with the practical proof component) maps directly to a number of technical security approaches/components. This is summarized in Table 14-1.

Table 14-1: Linking Law to Security
Legal Component	Maps To	Security Components Needed
What was agreed?	→	Data security Internet security
When was it agreed?	→	Time stamping
Who agreed to it?	→	Certificate security Private key security
Proof: trustworthy audit trails	→	System security LAN internal security LAN perimeter security

What Was Agreed?

All commercial systems, be they paper or virtual, depend on the absolute inviolability of agreed contractual data. If you buy x amount of shares in Solid PLC from your access point to an online system, you do not expect to find that, by the time it arrives on the recipient’s machine, your agreement has been altered to now record that a third party has purchased x-times-10 shares in Shaky PLC. Effectively, data security is Internet security. It would be a quixotic endeavor to attempt to secure the multiplicity of routes and systems that make up the open Internet. In any event, much modern commercial data needs to be transported in a manner that permits a variety of access permissions.

As we saw in Chapter 3, the security of XML traffic over the Internet requires security in the message (that is, in the SOAP message). Transport security protects data while it is in transit. Message-level security acts on the data itself. This point is best illustrated by a physical-world analogy. Assume you have sent a postcard from San Francisco to London. While it is in transit, it is protected from being modified or read because it is locked in a container on a freight train, or locked in the back of a mail truck. However, when the postcard is stored overnight at a mail depot, it can be read. The message itself is not secured. The stages in the journey (the “hops” in Figure 14-1) are secured, but the message itself is not secured.

Now assume, by contrast, that instead of sending an open postcard, you have sent the same message in an envelope with a wax seal, or in a locked metal dispatch box. The message itself is now secured. The hops continue to be secured (the locked container on the freight train, the locked mail truck), but the message itself has now been secured as well.

That analogy works for electronic mails. A single e-mail message may pass through many e-mail servers before it reaches its destination. The message will be secured during those “hops” between e-mail servers. However, while the message is sitting on a particular e-mail server, the administrator of that server or a third-party hacker can read the message. This is why simply securing the transportation between each e-mail server is insufficient. We must also secure the e-mail message itself (see Figure 14-1).

click to expand
Figure 14-1: Security in the message

Note

In many cases, we need to think in terms of securing against disclosure as much as we already do in terms of securing against attack. For instance, mere disclosure of trade secrets or the contents of patent applications will destroy their commercial value.

When Was It Agreed?

At common law, any agreement without an express or obvious effective date will normally be void for uncertainty. However, merely stipulating an effective date is not in itself proof against a “replay attack,” even in a paper environment. Assume that you have faxed signed instructions to your bank to transfer money to a previously nominated third party. If an agent of the third party intercepts and resends the fax, the bank may well transfer a further amount.

Messages that have been sent electronically, and that have been digitally signed, are just as vulnerable to such replay attacks. The potential for fraudulent repeat contracting is obvious—a hacker intercepts your message and sends it again. However, the corollary of such replay attacks can have equally damaging legal consequences. Where a system receives two identical (but genuine) messages from another system (for example, at 11:00 p.m. “Sell 100,000” and at 11:01 p.m. “Sell 100,000”), then it may ignore the second message on the assumption that it is a replay attack.

However, since the second message may have been sent before the first message, but received secondly because of network delays, there is in fact no way to ascertain which of the messages might be a replay attack. Legally, no safe assumptions can be made about either message; and both will need to be discarded. However, once you are aware of such legal issues, you can look to a variety of technical solutions.

Tip

You can secure your digital signature solution against replay attacks by making sure that the signature data includes a timestamp; or you can include a “nonce” in your messages. A nonce, standing for “number once,” is a value that changes with each transmitted message, thereby ensuring that no two valid messages can be identical.

Who Agreed to It?

Legally, the “key to online contracting is in the key.” How and where private keys are respectively distributed and stored has important legal consequences. Clearly, if a key issuer makes only a cursory effort to verify that I am who I say I am before allocating a private key to me, then it follows that I could, if I wished, readily obtain a false online identity. However, even a rigorous system of identity checking will be undone if I am then permitted (or even required) to store my private key in an insecure place.

In the latter scenario, while the key may originally have corresponded to the real me, this initial identity matching will be negated as soon as an impostor uses my key to impersonate me. In the XML Signature specification, the W3C organization readily admits that this point of legal vulnerability is partly a policy issue that technology by itself cannot fully guard against:

“. . .signer authentication is an application decision (e.g., does the signing key actually correspond to a specific identity) that is supported by, but out of scope, of this specification." ^[3]

This is a restatement of the “security is a process, not a product” truism mentioned earlier. It follows that private keys must be stored securely. Ideally, they should be stored on a hardware token that may itself have additional PIN and/or biometrics security. The evidential implications of a range of private key storage methods are developed in the section “An Emerging Legal Hierarchy,” later in this chapter.

Built-in Safeguards

Much of the legal debate about digital signatures focuses on a key security aspect. We tend to overlook the fact that digital signatures provide two additional, built-in legal safeguards that traditional ink signatures cannot match:

A digital signature is bound to the data that is signed. If the data changes, the signaturebecomesinvalid.Thisisnotthecaseforahandwrittensignature. If I sign the last page of a 300-page legal agreement, and then page 77 is replaced with a new and slightly—but materially—changedpage77,there is no way of detecting this change purely by examining my ink signature.
Chapter 2 explains how, if used properly, digital signatures can guarantee data integrity. This is distinct from their role in linking a signer’s identity to signed data. In the case of a handwritten signature, there is no guarantee of such integrity. There is only a link to the signer’s identity.

Trustworthy Audit Trails

We have already noted that all commercial systems, be they paper or virtual, depend on the absolute inviolability of agreed contractual data. Inviolability in this context carries the additional sense of being inviolable from attack or destruction for a period sufficient to ensure that, if need be, the courts can refer back to a contracting party’s obligations so as to enforce that party’s compliance with them. This is the stuff of conventional, defensive online security: Internet usage policies for employees, continually updated antivirus software, firewalls, and daily backups stored off-site.

Note

EU and U.S. data protection laws provide additional justifications for storing data securely. Increasingly, they are also starting to prescribe adherence to best technical practice and approaches.

Broadly speaking, all of the preceding working legal principles have been settled law in all key commercial jurisdictions for generations. They have a strategic importance to online security that eludes the merely operational significances of more narrowly focused laws (for instance, those laws dealing with data protection, or with spam). Once we start to prioritize law into the essential and the merely important, it is then a relatively simple matter to look at any technological product or context and ask oneself the anchor question: “legally, does this work?”

Let’s put that question to a number of important security technologies.

^[1]Chitty on Contracts (26th ed.) Volume

^[2]Treitel, The Law of Contract (9th ed. 1995)

^[3]XML-Signature Syntax and Processing-W3C Recommendation, February 12, 2002