Applying the Law to Particular Technologies

Clearly, law mainly has relevance to those technologies that claim to secure the conceptual legal components listed in Table 14-1. Technologies such as digital signatures, SAML, SSL, and biometrics variously concern themselves with technical issues such as user authentication and data integrity. Effectively, such technical issues are indistinguishable from legal issues. Before considering those individual technologies, it is helpful briefly to consider the amalgam of technologies and technical approaches that make up Web Services.

Web Services: An Overview of Legally Relevant Technical Trends

It may be helpful to view Web Services as being an important milestone in the development of the Internet as a tool for business, as opposed to being some sort of overnight technological paradigm shift. Previously, communication between software applications across networks used complex protocols such as CORBA and DCOM. Increasingly, however, standards vendors are using Web technologies (such as HTTP and XML) for automated communications processes.

Despite the fact that there are several standards vendors still jostling for market position, it is clear that there is a shared trend towards application integration at increasingly specific (and therefore increasingly useful) levels, and that this drive towards greater integration is accelerating. This growing convergence, despite its unruly nature, is now sufficiently significant that it has been dignified with its own name—hence Web Services. It may be a new departure, but it still contains many of the broad characteristics of a PKI structure.

However, the underlying technology has been simplified. For instance, previously, a certificate request was sent to a certificate authority as a PKCS#10 message; that is, not using the Web. By contrast, in Web Services architecture, XKMS is used to send a semantically equivalent key validation message, formatted as XML, over the Web. The advantages of this new approach are simplicity (many programmers and applications already know XML and may not have been familiar with complex and specialized cryptographic formats such as PKCS#10) and interoperability (many firewalls block all ports apart from Web and e-mail ports).

One can also receive information about the status of a key in an XML format. This is also part of the XKMS specification. Apart from the fact that XML is being used, and that the information flow uses the Web, the underlying processes are the same. The user applies for a secured public key (now using X-KRSS instead of PKCS#10) and then the recipient of a signed document checks the status of the public key in question through an online key validation service (now an XKMS “trust utility” with an XML/SOAP interface).

In addition, XML Signature is a means of representing a digital signature as XML, and also has special provision for the case where the signed information is itself written in XML. While an XML signature is almost semantically equivalent to the older PKCS signature format, the advantage of an XML signature is that it can be understood by a wide variety of applications.

From a legal perspective, there are two noteworthy aspects to the foregoing:

• The Web is being used increasingly as a communications channel for embedded communications processes.

• In keeping with this greater use of the Web, private keys are more likely to be stored in a key store that is directly accessible by a Web browser.

Legally, is either of those technical trends material?

Evidential Credibility of a Web Services Architecture

Web Services’ drive towards greater integration convenience carries within it a commercial pressure not to use awkward security methods that may be viewed as disproportionate to the vulnerabilities of the medium.

SECURITY ALERT

As far back as 1885, Justice Stephen remarked that “Laws ought to be adjusted to the habits of society, and not aim at re-moulding them…custom, and what is called common sense, regulate the great mass of human transactions. If…the law deviates from these guiding principles, it becomes a nuisance. If you require people to take precautions which they feel to be practically unnecessary, and which are alien to their habits of life, the only practical result is that they will prefer the risk of the penalties of neglect to the nuisance of taking the precaution.”
Quoted in Section 17 of the Statute of Frauds, 1 LQR 1, 6 (1885)

The next two sections examine the varying legal implications of the three main types of private key storage that may ensue. From a purely evidential perspective, such differing storage methods create at least three types of digital signature. Obviously, digital signatures are not peculiar to Web Services; the following observations about digital signatures have a general applicability to digital signatures in any online context.

We should be aware of any legal implications of a typical Web Services architecture platform. Where security vulnerabilities are manifestly inherent in the design of a network systems architecture, there is a greater likelihood that people who wish to repudiate their contractual liabilities will point to the statistical probability of an attack on that network to strengthen their arguments for such repudiation. From a legal standpoint, the perceived statistical likelihood of an attack could be more damaging than an actual attack.

The convenience of using Web Services must be weighed against the precautions that must be taken to ensure the legality of Web Services transactions. However, provided that, for instance, the SAML assertions used in Web Services are kept secure (discussed later), the attacks that should concern us are those that may be capable of compromising private key security.

Digital Signatures: Legally Neutral Until Secured

The legal validity of any online trading model that relies on stand-alone digital certificates (see next section) depends largely on the likelihood of key theft (effectively, identity theft) being statistically unimportant enough that a court could reasonably discount it.

Law is a pragmatic discipline. It operates to certain working assumptions. For instance, it assumes that you are innocent. In fact, you may not be. However, the prosecution is obliged, in criminal matters, to prove otherwise. In contractual matters, courts assume that your ink signature at the end of a paper contract is in fact yours. It does not automatically assume that your ink signature must be someone else’s and thereby require you to prove otherwise in each disputed case.

The obvious fact that paper documents and signatures are at least as susceptible to fraudulent manipulation as their online equivalents has never been a bar to their providing a legally binding mechanism and context for paper-based contracting. Theoretically, paper documents and signatures can easily be falsified and forged. This is understood and accepted as the trade-off for having a generally efficient system. No one has ever suggested that pen and paper should be scrapped, despite the reality of these vulnerabilities. Instead, the pragmatic emphasis in the paper world is on understanding the vulnerabilities of the paper contracting process so that business and legal communities can best accommodate and manage them.

Similar working assumptions (confirmed by statutes) hold for electronic (including digital) signatures. The positive assumption of legitimate private key usage could only be displaced if, as noted, digital signatures were to become widely discredited in fact. This is unlikely. Digital signatures are expected to match, not surpass, the legal effects of ink signatures.

It is important to keep this aspect in perspective by looking critically at ink signatures. A written signature on paper is nothing more than a convenient method by which contracting parties signify that they are willing to accept rights and obligations set out in the wording of a contract, and that the terms of the contact have been agreed upon and are fully understood by all parties. However, once someone can demonstrate fraud, the influence of drugs/alcohol, forgery, insanity, duress, or mistake, then that contract, despite its being in paper-and-ink format, will be null and void.

Digital signatures are no different. E-commerce laws the world over tend only to give negative clearance to digital signatures by stating simply that they shall not be denied legal effectiveness and admissibility as evidence solely on the grounds that they are in electronic form. No one can guarantee that every single digital signature will always be capable of being verified. By itself, this will be of limited legal significance. Online attacks can only undermine the legal credibility of digital signatures generally if the volume and seriousness of such online attacks are such that digital signatures become widely discredited. Given the intrinsic qualities of public key cryptography, and that related security continues to mature, it is unlikely that this will happen.

Digital Signatures: An Emerging Legal Hierarchy

Not all digital signatures are of equal standing. Some digital signatures may be linked to “self-signed” certificates. Legally, the status of these do-it-yourself (DIY) signatures is more akin to train tickets than that of (say) national passports, in that they are only notionally linked to the user. However, the legal limitations of such so-called digital signatures are widely understood; and, if they are to be used in a critical online environment, they will invariably be augmented with other identity checks (such as personal questions carried out over the telephone or by e-mail) in real time.

This means that there is an emerging hierarchy of digital signatures. For convenience, these may be described as being linked to

• Stand-alone digital certificates Given out after an exhaustive series of identity checks, including face-to-face identity checks; and where the private key is thereafter stored as securely as possible, perhaps on a hardware token that may itself have additional PIN or biometrics security, such as RSA Security’s SecurID product. Their intrinsic evidential value is likely to be prima facie conclusive.

• Corroborative digital certificates Given out after a rigorous series of identity checks (which may rely mainly on an exchange of paper correspondence concerning individual specific matters such as banking or share-ownership details), and where the private key may thereafter be either stored on a hardware token (or smart card) or on a Web repository. Legally, their intrinsic evidential value is high. In addition, where they are used in conjunction with additional real-time identity checking (such as using personal question checks conducted by telephone or over e-mail), their evidential value is likely to be prima facie conclusive.

• Disposable digital certificates Self-signed, without being linked to any third-party identity provider. Legally, their intrinsic evidential value is slight, though they may assist in corroborating paper-based or affidavit evidence.

The Web-centric nature of a Web Services environment means that stand-alone digital signatures may not always feature in it. Corroborative digital signatures may on occasion be used. This means that any assessment of the legally binding nature of a particular Web Service will need to be a holistic assessment of the entire service. One needs to assess not only how the certificates are managed and how the private keys are stored, but also how the wider implementation aspects (such as corroborative identity checks) will be carried out.

Incidentally, it is worth noting that this approach differs little in principle from the kind of legal scrutiny that would have been directed towards policy details in a classical PKI environment. All that is different about the approach to legal scrutiny required by the Web Services model is that the scrutiny is directed towards a de facto entire-service implementation policy, as opposed to a formalistic written set of PKI policies that typically concentrated more narrowly on key issuance and storage.

SAML: The Legality of “Distributed Trust”

Security Assertion Markup Language, or SAML, is a means of reporting and vouching for a prior act of user authentication or authorization, or a user’s attribute (for example, credit status). However, any such “SAML assertion” (discussed later in the chapter) is not in itself an act of user authentication. This seemingly trite distinction has important legal liability and legal security implications.

This section discusses those legal implications and makes some practical suggestions. That discussion is prefaced by, respectively, a short lay guide to SAML assertions and a summary of the differing legal effects of the two main kinds of prior authenticating acts.

What Are SAML Assertions?

SAML uses XML to encode messages relating to user authentication and user authorization. A SAML assertion is an automated assertion describing (or related to) a prior act of online authentication by an individual person, or to an act of authorization relating to that person. Assertions and profiles are important components of the SAML specification. SAML profiles are sets of rules describing how to put SAML assertions into particular use-case protocols as such protocols evolve to meet particular commercial/ user requirements.

Currently, there are SAML profiles for single sign-on to Web sites; and the OASIS Security Services Technical Committee is developing a profile for SAML assertions to be contained in SOAP messages. Typical SAML assertions include

• Authentication assertions Asserting that the user has proved her or his identity. Note that SAML does not mandate a particular type of prior authenticating act.

• Attribute assertions Asserting that, for example, the user has certain spending limits.

• Authorization assertions Asserting that, for example, the user is authorized to access a particular database or is authorized to purchase a particular item.

Browser/Artifact Profile: A Typical SAML Deployment

The simple browser/artifact profile depicted in Figure 14-2 (below) involves a user logging onto, and being authenticated at, one particular site. SAML assertions allow that user to access related sites without having to reauthenticate herself or himself.

Figure 14-2: SAML assertions in action

What Is an Authenticating Act?

Legally, an authenticating act is any action by you that establishes your individual identity. This rarely needs to be an absolute identification, it need only be proportionate to the value of the situation requiring the identification. Online, the two main types of authenticating act are

• Usernames + passwords These are “something you know.” Incidentally, companies such as RSA Security develop credit-card-sized hardware password- generating devices—”something you have.” These provide stronger authentication security than usernames + passwords.

• Digital signatures These authenticating acts have overlapping legal effects (see Table 14-2 on the next page).

  Table 14.2: Legal Effects of Authenticating Acts

  Authenticating Act	Legal Effect
  Username + password	Weak authentication No guarantee of (contractual) data integrity Very weak (contractual) nonrepudiation
  Digital signature	Strong authentication* Guaranteed (contractual) data integrity Strong (contractual) nonrepudiation* * Provided that, as noted earlier, the digital certificate has only been issued after an exhaustive series of identity checks, including (ideally) face-to-face identity checks, and provided that the private key is thereafter stored as securely as possible, perhaps on a hardware token that may itself have additional PIN or biometrics security.

SAML Assertions: Legal Implications

Paradoxically, even though SAML is itself a security technology, it must itself be securely deployed—and it must be deployed in a network that has already been separately secured.

SAML Is Not a Guarantor

A SAML assertion is a mere messenger. It is not a guarantor. While it should be abundantly clear that the reliability of a SAML assertion is wholly dependent on the reliability of the original authenticating act, this obvious point must be highlighted. Otherwise, there is a human tendency to become seduced by the plausibility of the intervening SAML technology; and to overlook the fact that, in legal reality, little, of any, stand-alone legal merit may have been asserted to.

For instance, technical papers on SAML tend to describe a SAML authentication assertion as an assertion that the user has “proved” his or her identity. This overstates the legal effect of, for instance, a mere username + password combination. In that case, it would be more accurate to state that the user has attested to his or her identity. This caveat applies especially to SAML assertions derived from prior digital signature authentication, such as are required by the Browser/Post SAML Profile. No amount of subsequent SAML assertions can transform an insecurely obtained digital certificate into a legally binding digital certificate.

Currently, SAML assertions are primarily designed to assert to acts of authentication and authorization, and issues directly relating thereto. SAML assertions are not in themselves about issues of contractual data integrity or contractual nonrepudiation. SAML assertions typically occur in a user-access context. That context typically occurs prior to any transmission of additional contractual data (as opposed to authentication data) by the user. Accordingly, SAML assertions have little direct relevance to contractual data-integrity issues. Further, a SAML assertion only goes to prove that a designated user accessed system x at y hours. Beyond that, a SAML assertion is not an activity log. Of itself, a SAML assertion is of little relevance in refuting attempts by a user to deny that she or he had entered into a particular contract.

Securing SAML Assertions

Throughout, this chapter stresses the importance of online security in helping to create a legally binding architecture. The same principles apply to SAML assertions. When SAML assertions communicate between different networks, the initiating server (server A in Figure 14-2) creates and stores the SAML data locally. Potentially, the SAML data exchange and the underlying data storage both are points of technical and legal vulnerability. It is essential that commercial and legal planners should be aware of such vulnerabilities, and of the obvious remedies.

To prevent replay attacks, the latest Web Services Security Addendum document^[4] recommends the following:

“In order to trust Ids and timestamps, they SHOULD be signed using the mechanisms outlined in WS-Security. This allows readers of the IDs and timestamps information to be certain that the IDs and timestamps haven’t been forged or altered in any way. It is strongly RECOMMENDED that Ids and timestamp elements be signed. Note that since the Timestamp header is mutable, signatures need to be associated with individual elements. Timestamps can also be used to mitigate replay attacks. Signed timestamps MAY be used to keep track of messages (possibly by caching the most recent timestamp from a specific service) and detect replays of previous messages. It is RECOMMENDED that timestamps and nonces be cached for a minimum of five minutes to detect replays, and that timestamps older than five minutes be rejected in interactive scenarios.”

Ideally, such data exchanges should also be encrypted separately, instead of needing to rely on any surrounding channel encryption. In Figure 14-2, server A’s SAML assertions must only be capable of being accessed or interrogated by server B, not by an unauthorized third-party server.

In this context, commercial and legal planners should keep abreast of evolving SAML security standards. SAML 1.1 looks set to resolve many of the legal issues. In particular, there is a growing recognition that SAML 1.1 needs to provide more complete information about the authentication context of differing authentication methods. This should resolve the legal error, already noted, of appearing to confer parity of legal status on a disparate range of weak and strong authentication methods.

Liability

In a typical scenario, a SAML assertion generated by company A’s server will be instrumental in securing access to company B’s confidential database system for user X. Effectively, B is relying on A’s assertion about X’s credentials. If A’s SAML deployment is insecure, untold commercial damage to B may ensue at the hands of X. Prima facie, B could sue A. Contractually, such liability trapdoors can easily be avoided by A’s prior insistence on some prudent apportionment and limitation of liability/hold harmless clauses. Otherwise, it is not difficult to see the scope for fractious and technically involved lawsuits.

The Value of SAML

Commercially, SAML is a timely mechanism; both for solving the repeat authentication logjam for users and for simplifying automated back-office machine-to-machine trading. Provided that commonsense security and liability issues are addressed in the manner outlined, SAML assertions can be relied upon as being authoritative distributors of trust between disparate companies and sites.

SSL: Legally, How Secure Is It?

The contractual effect of Secure Sockets Layer (SSL) differs dramatically, depending on its use context. SSL uses encryption and digital certificates as normal, but usually does so to authenticate the server only. SSL allows a confidential “secure pipe” to be established for the duration of a communications session. This suffices to allow the confidential communication of the user’s input to the Web site. In this way, SSL can operate without the complexities of a full PKI infrastructure.

Effectively, SSL is one half of a normal PKI structure. It is indicated in a business- to-consumer model whereby consumers order goods over the Internet. While consumers have an obvious requirement to verify the identity of the retailer company at the server side, any legal requirement that this verification be mutual is mostly negated by the deployment advantages of concentrating the technology and the legality at the server. Accordingly, one-way SSL has obvious legal limitations in a mutual, “at-arms-length” business-to-business context.

Biometrics: Is Seeing Believing?

Biometrics is the generic term for a variety of scientific methods for measuring and statistically analyzing biological data. In information technology, “biometrics” usually refers to technologies for measuring and analyzing human body characteristics such as fingerprints, eye retinas and irises, voice patterns, facial patterns, hand measurements, keystroke patterns, and DNA profiling. For instance, biometric fingerprint devices are security systems that claim to offer a secure means of access to online systems (or buildings) by identifying you from your fingerprint.

Fingerprint and other biometric devices consist of a reader or scanning device, software that converts the scanned information into digital form, and a database where the biometric data is stored for comparison with the biometric data entered when a user tries to gain access. In converting the biometric input, the software identifies specific points of data as match points. Using an algorithm, the match points are processed to a value that can be compared with biometric data scanned when a user tries to gain access.

For decades, popular science fiction films have familiarized us to such biometric devices. This factor, together with their dramatic and tangible user effects, means that biometric devices enjoy a popular security credibility that, for instance, digital signatures struggle to match.

However, in this instance, popular intuition errs on the generous side. Biometric devices have a role as secondary security/authentication methods, but their value as frontline, or sole, legal authentication methods is questionable. The theoretical vulnerability in any biometric device lies in the fact that the user’s unique details will be checked against a database on each occasion that the device is used. Theoretically, it is possible to hack into a database holding a set of individual biometric records and to map them to a false identity.

^[4]Published at www.-106.ibm.com/developerworks/webservices/library/ws-secureadd.html?dwzone=webservices . Copyright International Business Machines Corporation, Microsoft Corporation, VeriSign, Inc. 2002