WWW security and trusted third party services

Future Generation Computer Systems 16 (2000) 331–341

WWW security and trusted third party services

Bruno Crispoa, Peter Landrockb, Václav Matyáš Jr.c,∗,1

a Computer Laboratory, University of Cambridge, Pembroke Street, CB2 3QG Cambridge, UKb Cryptomathic a/s, Klostergade 28, 8000 Arhus C, Denmark

c Ubilab, UBS AG, Postfach, Bahnhofstrasse 45, P.O. Box CH-8098, Zurich, Switzerland

Accepted 3 March 1999

Abstract

We provide an overview of major findings from the EC project2 ‘TrustWeb – Security in the WWW, mutual impact of ETSand WWW’. While not all the technical details can be discussed here, we review some of the most relevant ones, referringreaders to documents on the project webpage for details. Our message after the project is: WWW security has many problems,out of which only some can be solved with the use of TTP services, yet TTPs can greatly benefit from the developments of theWWW, where only secure WWW can provide useful interface and communication means for TTP services. ©2000 ElsevierScience B.V. All rights reserved.

Keywords:Trusted third parties; Public-key cryptography; WWW security

1. Introduction

Private and authenticated client/server communica-tion in the open WWW environment is seen as essen-tial to the implementation of many important onlineservices. When considering the most obvious protec-tion requirements for communication over the WWW,we find that easy-to-implement, technically adequateand generally accepted solutions are not available. Thecurrent technologies focus on protecting simple credit

∗ Corresponding author. Tel.:+41-1-234-27-93;fax: +41-1-236-46-71.E-mail addresses:[email protected] (B. Crispo),[email protected] (P. Landrock), [email protected](V. Matyaš Jr.).

1 The research was undertaken while the author was with Up-time Commerce Ltd. and University of Cambridge ComputerLaboratory.

2 Opinions expressed in this document are those of the authorsand do not necessarily reflect the official views and policies ofthe European Union.

card-like transactions using SSL and more recentlySET. Moreover, security on the Web requires morethan just public-key encryption and authentication.Yet, even public-key technology deployment withinthe WWW is far from its true potential. That would re-quire a facilitating infrastructure provided by so-calledTrusted Third Parties (TTPs), offering more than justpublic-key certification in its simplest form (i.e., evenwithout reliable revocation services and alike) as isthe situation today.

TTP services and public-key infrastructure (PKI)deployment are on top of the agenda for computer se-curity professionals and of the market. The EuropeanCommission has also decided to undertake a review ofthe current security status in the WWW, assess the im-pact of new technologies in the context of security andinvestigate the impact of European Trusted Services(ETS), (i.e., TTP services in a broader sense) on theWWW. This was done through the project ‘TrustWeb– Security in the WWW, mutual impact of ETS and

0167-739X/00/$ – see front matter ©2000 Elsevier Science B.V. All rights reserved.PII: S0167-739X(99)00057-6

332 B. Crispo et al. / Future Generation Computer Systems 16 (2000) 331–341

WWW’ [7], within the ETS-II INFOSEC programme.The project started with the review of the current se-curity status of WWW, provided an overview of newWWW-relevant technologies and assessment of theirimpact on security and investigated the mutual impactof ETS and WWW. The project webpage can be foundat http://www.cl.cam.ac.uk/∼vm206/trustweb.html.This paper outlines the major findings and conclu-sions.

We started the TrustWeb project with investigationof risks, vulnerabilities and shortcomings in WWWtools. However, reports like this (both on servicesand on risks) can provide a useful guidance only forabout a year after their publication. This is useful formany situations, but development of a regular ser-vice for a WWW incident reporting mechanism shouldbe the ultimate target in this area. We suggested aWWW-specific incident reporting scheme – Brisk Eu-ropean Web Alert REporter (BEWARE) as we expectthis to be extremely beneficial to the WWW securityin practice.

We then focussed our research on TTP services inthe support of security that a third party could pro-vide, with a particular emphasis on the WWW issues.We have also discussed some WWW-specific servicesas extended TTP services on WWW, and examinedsecurity problems related to the use of WWW as auser interface to access TTP services, suggesting anexample of alternative solutions to today’s implemen-tations. Two of our suggestions are briefly presentedin Sections 6 and 7 of this paper. Obviously, currentWWW security topics like mobile code, problems withPKI implementation in browsers, etc., were also thor-oughly reviewed in the course of our research.

It is sometimes incorrectly understood that the onlybusiness of a TTP is key certification as in the role of aCertification Authority (CA). However, there are otherservices in the support of security that a third partycan provide. Some of them are already identified, liketime-stamping, auditing, trusted delivery, etc., whereasothers are either vaguely mentioned (dispute resolv-ing and notarisation services) or not mentioned in thecontext of TTP at all. We assessed a wide range ofWWW application needs for services that a TTP couldprovide – both from the experience of existing imple-mentations and from research findings.

We tried to provide more focussed assessment inone of the areas discussed in media quite often –

payments in the electronic commerce. We concur-rently compared our findings with current reports onshortcomings of PKI and/or problems with inadequateWWW security in new projects implementing servicesprovided or supported by the future ETS. We then alsoanalysed the influence that new WWW capabilitiesand services can bring to ETS.

2. BEWARE

Let us summarise the existing limits of WWWsecurity problems reporting and distribution of theinformation to the WWW users:

1. The existing incident reporting mechanisms do notsupport WWW-specific incident reporting. Rather,these mechanisms are primarily focussed on issuesconcerning lower layers of network services; theyalso refer to some server vulnerabilities, but hardlyany browser-specific bugs. These incident report-ing mechanisms were mostly initiated at the timewhen WWW was either completely unknown or ofa marginal impact on the Internet. Thus, the aimof such reporting mechanisms is different. In addi-tion, the target audience of these mechanisms aresysadmins and alike, whereas WWW security isof interest to a much broader population, often notvery skilled in the IT terms.

2. The WWW software manufacturers’ informationon products’ bugs is very disperse (the bigger themanufacturer the harder is it to find such informa-tion), too often superficial or even misleading (of-ten only a patch or upgrade is available, withoutmuch information why one should install it). Natureof end-user software business, moreover for soft-ware distributed on the Internet, is unfortunatelylike that. We do not believe that WWW softwaremanufacturers will behave differently in the futureand users/customers will have to seek advice at in-dependent sources.

3. One has to rely on dubious vulnerability informa-tion sources too often. The reality of today’s sit-uation (reflecting to a high degree the precedingproblem) is that users have to watch for news notonly from security research teams, but also fromhacker communities. This creates an ideal environ-ment for hoaxes, misinformation, etc.

B. Crispo et al. / Future Generation Computer Systems 16 (2000) 331–341 333

2.1. Goals of the BEWARE system

The system should provide WWW-specific incidentreporting that would collect, verify and disseminateinformation on WWW security incidents and bugs.The collected information can be of a very similarnature to the one collected by CERT today.

The information should be available:• On the BEWARE WWW pages

1. In keyword-searchable format – e.g., one canenter and search for ‘MS Windows NT 5.67’AND ‘MS Internet Information Server 6.35’AND ‘Foo Cert-Wallet 1.22’.

2. Through organised pages for user-led browsingby categorised reports.

• Via category-specific mailing lists (after an incidentbeing reported and verified, all users interested inincidents of this category are informed).

• FTP archives – for users who have only basic ser-vices available (e.g., after an attack on their site).

• Quarterly or monthly summaries describing activi-ties carried out in that period, summarising the prob-lems discovered.

3. What You See Is What You Sign (WYSIWYS)

WYSIWYS should ideally be one of the underly-ing principles of any digital signature application [5].However, one has to differentiate between situationswhen digital signature techniques are applied routinely(e.g., for signing a random challenge at the start ofa communication/cryptographic protocol) and situa-tions when the circumstances to the digital signatureapplications are non-routine (e.g., legal obligationsfor a document signing). Whereas the first categorymight use a browser performing the digital signatureact without user intervention after the initial requestfor establishing a connection, users will appreciate thepossibility of reading the document that is to be signedand being assured that it is actually this document thatis to be signed using their private key. Even for thefirst category, assurances that, e.g., nothing other thanpackets with (valid) random challenges are signed andthis happens only once after user’s initial request forestablishing a connection, should be provided.

It should be possible to implement browsers thatwill use one key for the routine signing of communi-

cation packets, etc., and another key for signingpotentially sensitive data in WWW forms, etc.

While current WWW applications mostly do notuse digital signatures for the non-routine tasks in dataexchange (in contrast to e-mail clients), this mightchange with applications allowing for a web-pageform content to be signed, etc. In this case, the bestassurance of the WWW clients’ (browsers’) confor-mance to the WYSIWYS property should be guaran-teed. One of the ways to achieve this might be the useof separate cryptographic modules, e.g., via mobilecode that will be short for third-party verification ofcode correctness. This can be done in a similar man-ner as in the Java applets with more generic securityfunctionality described in the following section.

In the ACTS project on electronic commerce SEM-PER, (see www.semper.org) the largest EU project onthe subject, WYSIWYS is provided through a tool, orconcept rather, developed as part of the project, TIN-GUIN, Trusted Interactive Graphical User Interface,which introduces a number of measures to improvethe security. It is of course always possible to circum-vent this unless trusted hardware is being used, butthe point is to make it as difficult as possible withoutenforcing a solution which is prohibitively expensive.

4. How to secure WWW transactions using Javaapplets – a browser security example

One of the important high-level questions beforeusing a Web browser to access WWW securely (e.g.,for the access to ETS services) is: do we want to relyon the cryptographic software in the browser? We haveto consider issues like:• Should we (outside the US) rely on cryptographic

modules of the exportable versions of WWWbrowsers manufactured in the US?

• If we use patches for enabling good (US domestic)level of security, such as Fortify (http://www.fortify.net/) for Netscape, can we trust the cryptographicmodules then?

• Or can users access information on the Web se-curely with their unchanged, normal browsers, andyet without relying on the cryptographic softwarecontained in those browsers?This is important, because cryptographic functions

often need to be separated from both the user inter-


face and the communications routines. It must be pos-sible to acquire the source code for the relevant mod-ules and alternative software vendors must be avail-able, in order to avoid hidden trapdoors and undetectedimplementation problems. A trusted party might thusprovide the necessary security functionality indepen-dently of the large software manufacturers. That wouldcreate opportunities for independent European devel-opers and trusted services providers.

A possible approach is an alternative to solutions atthe protocol level (e.g., SSL), because the unchangedHTTP/TCP/IP stack is maintained. Moreover, it doesnot require the installation of proxies. Existing solu-tion as S-HTTP or SSL, even if technically correct, allpresent the limit to address the problem of end-to-endauthentication at the transport level. In an environmentwhere the same workstation can be shared among dif-ferent users, a malicious user can easily share the sameauthenticated connection. A solution capable to pro-vide end-to-end authentication at the application levelguarantees better security. Full version of paper [4]describing this approach, as well as the software areavailable at http://maga.di.unito.it/fb/SWWWT.

5. ETS Services

The following part reviews the basics of ETS Ser-vices, with a particular emphasis on the services thatwe have assessed as crucial to securing WWW appli-cations. When lists of services are provided, then theWWW-relevant ones will be set inbold. The activityof a TTP concentrates in two major areas (see [6] formore details):• Support services• Independent services

Support services indicate that the TTP is there todirectly support the user, or entity, to make use ofsecurity services. This includes registration and certi-fication (which are not discussed further in this paperunless they are highly relevant to some other subject),service messages related to key management, andpossibly even key generation, key recovery, directoryservices, and more.

Independent services cover the need for indepen-dent third parties to offer special services, be it to wit-ness certain business acts, to certify authorisation andissue so-called user attributes, or whichever. We haveidentified several examples of such services:

• Time-stamping and Reliable Time Provision• Issuance of legal attributes of entities• Issuance of access attributes• Data Certification ServiceandNotary Archiving

Service• Non-repudiation services(e.g., of origin/receipt,

submission/transport)To specify the distinction between the Data Certifi-

cation Service and the Notary Archiving Service: theformer verifies the submitted data content in some way(e.g., given by its policy, contract), certifies, i.e., signs,the data and sends it to another entity (maybe the orig-inal data sender, but not necessarily). The latter alsoverifies the submitted data content, certifies the dataand can possibly send it to another entity; however, itprimarily stores the document so it can be retrievedfrom the service.

5.1. Key generation services

If the user has the ability to generate her ownkeys, some important advantages can be gained byuser-controlled generation. The primary advantage isthat no other person at any time has had potentialaccess to the private key (if we speak of public-keycryptosystems). However, this does not imply that thekeys are generated within user’s own premises, strictlyunder her sole control. Although it seems preferableto build systems where the user is responsible for thekey generation, this does not necessarily mean thatonly the user has an influence on the key generation.The weakness of user-generated keys is that they canbe generated insecurely (e.g., without sufficient ran-domness). A solution to this can be software suppliedby a third party (e.g., a certified applet) used by theuser. In any case, the key generation should always becarried out by an entity independent of the public-keycertification and revocation authorities.

Two factors of the ultimate importance in securekey generation are:1. Generation of a sufficiently large random seed.2. Generation of sufficiently random keys based on

this seed.Let us review one of the more relevant issues.

5.1.1. TTP generated key pairThe user can either personally visit TTP service-

point (e.g., similar to ATMs of banks) or just send a


request to a TTP which offers key generation, and re-ceive in return the generated public–private key pairfrom the TTP. This solution would mostly require useof a tamper-resistant or at least tamper-evident devicesuch as a chipcard. Although the user has to rely on acorrect TTP behaviour (e.g., that the TTP destroys allkey material), this approach has advantages like pos-sible assurance of using good random generators andfor some applications (with personal tamper-resistantcryptographic devices) as well as the feature that theuser herself is unable to directly read her own key.

5.2. Key recovery services

Key recovery services can be useful in some par-ticular systems, which we believe WWW applicationsdo not belong to. We will briefly review the reasonsleading us to this stance:1. Integrity protection will often be achieved by the

means of digital signatures. As digital signaturessafeguard not only data integrity, but also providemeans for verification of data authenticity, escrowof such keys would contradict basic principles ofdigital signature security. Providing non-escrowbased recovery services is also not necessary asthe outcome of a key loss is the situation whenno-one can sign documents, i.e., no forgery can berealised. And although the user has to generate anew key-pair, have her public key certified, etc.,this is a very reasonable price to pay for the digitalsignature security.

2. Access control based on the use of public-key cer-tificates is, with the respect to the key recoveryusefulness, very similar to the integrity protection.Advantage of no third party having even a theoret-ical chance of accessing a service is usually higherthan the disadvantage to have new key-pair gen-erated and public key certified in the case of theprivate key loss/corruption.

3. Confidentiality within the WWW environment isoriented towards communicated, not stored data.Unless the transmitted data cannot be re-sent, keyrecovery is not extremely useful; introducing moredisadvantages rather than advantages. Communica-tion is only rarely initiated without a confirmationof all participating parties that they possess decryp-tion key(s). Disruption in communication will bemore often caused by problems with the commu-

nication line itself rather than loss of a decryptionkey during the communication.

5.2.1. Reliable revocation servicesThe CA is (according to the X.509 standard) re-

sponsible for the status of a certificate (and the relatedkeys) and can declare this to be revoked before theexpiration date. It is however not important for ourdiscussion whether the revocation is done by the CAor another party authorised to act as the revocationauthority – we will henceforth denote therevocationauthority as the entity with authorisation to revokekeys.

Reasons for revocation can be usually set into threegroups:• Compromise, loss or corruption of user’s private

key.• User request (to change the key, to change creden-

tials, to cancel registration).• User is found to be breaking the certification or

certificate use policy (e.g., the registered identity isfound to be false; the private key is provided to athird party with a malicious intent).Legitimate users of a PKI should be able to confirm

the invalidity of the revoked certificate; that is, suchcertificates and the related keys should be put in theDirectory together with CA’s statement of revocation.Also, the owner of the revoked certificate should beinformed.

There exist two elementary approaches to verify acertificate’s validity:1. Liberal – a certificate is considered valid unless the

contrary statement is received. So if we possess ane-mail with a digital signature and also with the rel-evant certificate, this signature is considered validunless we receive a revocation statement originatedby the revocation authority (or until the certificateexpires by its definition). The standard X.509 Cer-tificate Revocation List (CRL) is an example ofthis approach when being distributed to users, whodeem certificates to be valid unless told otherwiseby the CRL.

2. Conservative– a certificate is considered invalidunless the contrary statement (that is recent/fresh)is received. So if we possess an e-mail with adigital signature and also with the relevant cer-tificate, this signature is considered invalid unlesswe can query the appropriate directory service


(e.g., at an address specified in the certificate)whether the certificate is still valid or whether ithas been revoked. Example of this is generationof a so-called revocation certificate, which is thecontent of the revoked certificate, together withits new status, signed by the revocation author-ity. In particular, the revocation certificate has thesame certificate reference number as the originalcertificate. The reason for this is that typically,the revocation only implies that new signaturesshould be verified. But there is still a need to ver-ify signatures generated before the certificate wasrevoked. The revocation certificate replaces theoriginal certificate. The certificates can be avail-able via WWW, so both automated and manualrequests for verification of certificate validity areallowed.If the CA’s private key is compromised then certifi-

cates generated by the CA can no longer be expectedto be authentic. In this case, all the certificates andother security links around the CA should be reset.However, users can still use their public key if mutualtrust has been established between them by exchangeof public keys before CA was compromised. It is im-portant to realise that the compromise of CA’s privatekey does not imply the compromise of users’ privatekeys.

In view of the remarks above, it is imperative tohave amble back-up of the CA public key-pair as it isdone at the user level by incorporating ‘trusted’ CAsin the WWW browser certificates’ database.

6. Non-repudiation of WWW posting

This service should ensure that one could later provethat a particular web page was available at a particu-lar URL at a particular time. This will involve a vari-ation of theData Certification Service, together withmeans of a secure version of the Domain Name System(DNS). The DNS protocol security extensions providethree distinct services:1. key distribution,2. data origin authentication, and3. transaction and request authentication.

Authentication (of both points 2 and 3) is of pri-mary interest to the application –the non-repudiationof WWW posting. Authentication in the DNS protocol

(its new version) is provided by associating with re-source record sets in the DNS cryptographically gen-erated digital signatures. Commonly, there will be asingle private key that authenticates an entire zonebut there might be multiple keys for different algo-rithms, signers, etc. If a security aware verifier reliablylearns a public key of the zone, it can authenticate, forsigned data read from that zone, that it was properlyauthorised and is current. The data origin authentica-tion key(s) are associated with the zone and not withthe servers that store copies of the data. That meanscompromise of a secondary server or, if the key(s)are kept off-line, even the primary server for a zonewill not necessarily affect the degree of assurance thata verifier has that it can determine whether data isgenuine.

A verifier could learn a public key of a zone ei-ther by reading it from the DNS or by having it orits certifying key statically/manually configured. Toreliably learn a public key by reading it from theDNS, the key itself must be signed with a key theverifier trusts. The verifier must be configured withat least a public key, which authenticates one zoneas a starting point. From there, it can securely readpublic keys of other zones, if the intervening zonesin the DNS tree are secure and their signed keysaccessible.

Adding data origin authentication and integrity re-quires no change to the ‘on-the-wire’ DNS protocolbeyond the addition of the signature resource type andthe key resource type needed for key distribution. Fur-ther information on secure DNS protocol can be foundat http://www.ietf.org/ids.by.wg/dnssec.html.

Using secure DNS, one can then not only gain anassurance of host to name address translation, but alsolearn the public keys associated with the host. A TTPproviding non-repudiation services can be used for thispurpose. A simplified information exchange is givenin Fig. 1, with messages 2 and 3 being optional (TTPcan either provide the secure DNS service or haveinformation cached for some hosts).

Service of this kind should not be that hard to im-plement and it would provide a reliable solution insituations when evidence of an information postingis required. Typical examples can be proof of an-other TTP information posting (certificates, CRLs, an-nouncements, etc.), proof of availability of companyannouncements at a certain time, etc.


Fig. 1. Providing non-repudiation of WWW posting.

7. Non-repudiation of origin/receipt for filledforms

When someone uses web-page forms for supply-ing information today, there is no provision of anynon-repudiation service. The only relevant assurancethat one can have with the commonly used SSL pro-tocol is that the web page with the form came from acertain server (by the means of WWW server certifi-cates) and eventually that it is presented and filled ona certificate-containing client machine (by the meansof user certificates). But there is no easy proof that thedata filled into a form has been provided at that clientmachine and/or that it has arrived to the server. Thiscan be achieved in at least two ways:1. Storing the entire log for client–server communi-

cation exchange that would deploy digital signa-tures throughout the entire process – not only thefilled form exchange, but also the exchanged cryp-tographic material – so it can be undeniably ver-ified anytime later on3 . However, this would re-quire substantial changes to the SSL protocol andeven then it might not be acceptable for the practi-cal use – both for the size of such logs to be keptand also for its difficult verification, e.g., in frontof a court. Also, this would be overly demandingnot only on the server, but also on the client sideand overall is not a technically sound way to solvethe problem.

2. Using a specific non-repudiation protocol is tech-nically more sound, but would require more

3 If this does not include digital signatures, it could have beenmanufactured by the receiver, so there is no way that it wouldconstitute non-repudiation. The service offered in SSL is messageauthentication and not non-repudiation.We have to point out thatnon-repudiation cannot be obtained by means of SLL.

modifications to the existing technologies. Whilenon-repudiation of origin will again be easier toachieve, simply by applying digital signature of theclient/user on the information filled into a form,non-repudiation of receipt will require involvementof a TTP in order to assure the service reliability.The specific technical intricacies for non-repudiation

of origin/receipt for filled forms are related to theweb-page (and filled data) structuring and potentiallyalso confidentiality services in the case of form datacontaining sensitive information. Although it is tech-nically possible to provide non-repudiation in thelatter case, this might be not a preferred option forTTPs who avoid signing encrypted messages as partof their good cryptographic practices. This problemwould have to be solved in a similar way as fortime-stamping, where the data content is also notverified, i.e., the TTP would sign the relevant data,for which the non-repudiation of receipt is required,only with a (private) key dedicated solely for this pur-pose. The corresponding public-key certificate wouldinclude the key usage field extension defining thetime-stamping key use policy. Also, the key use pol-icy would explicitly say that the content of the datasigned for the non-repudiation purposes is not verifiedand that the signature is valid as for non-repudiationservice provider as an unread data relier only.

Implementation of this service would necessarilyimply changes to the WWW client and server soft-ware, with a particular concern to the WYSIWYS prin-ciple. Moreover, adding new tags (and their recogni-tion by the browsers and servers) to the HTML setmight also be necessary. Benefits of this service areobvious and it might indeed be the next new secu-rity service supported by WWW client and serversoftware.


8. PKI: trust models

X.509 as well as other PKI introduces the notion ofcertification path, which enables the user to authenti-cate the public key of another when they are not bothserved by the same CA. Chains of certificates werethought to be necessary to allow the infrastructure toscale eventually world-wide.

Unfortunately, this model of the world does notmatch the one adopted by people every day in theconventional world to carry out most of their busi-nesses. Customers usually want to obtain the informa-tion they need (e.g., the public key of the merchant)directly from the person with who they directly ne-gotiate the deal rather than from a chain of unknown‘authorities’ that do not carry any liability in case offraud or malicious behaviour. The fact that the in-formation and the documents we received are digi-tally signed does not provide any assurance about whoused the secret key used to generate that signature.The last step of this chain that binds the key pair toa particular entity needs to be verified directly by theentity that will be damaged in case this binding isfalse.

The chain of trust, in case of open, unstructuredand distributed environment like Internet, must startalways from the user and not descending from visionof rigid infrastructures. Our current experience fromthe work in the public-key technology and servicesmarket shows that there is demand for limited or nothird party service, e.g. in closed user groups or instar topologies such as homebanking systems, whereeverybody communicates with one party only, namelythe bank.

Also, a recent project undertaken by one of theTrustWeb consortium partners [3] has discovered thatit is not clear whether digital signatures and the cur-rent key certification infrastructure based on the X.509standard would support the reliable electronic distri-bution of medical information, such as care protocols,drug formularies and government notices. The reasonis that X.509 provides a ‘credit card’ model of trustthat is suitable for retail financial transactions, but doesnot clearly support the more complex and persistenthierarchies in medical publishing. It appears necessaryeither to consider special new extensions of X.509 orto develop an alternative means of managing trust inelectronic publishing – e.g., we have investigated and

are currently deploying methods involving HTML tagset extensions for security purposes. This might wellbe the case for other applications with long-lived trustrequirements such as electronic contract signing andnotarisation, or applications with specific trust require-ments.

8.1. The Global Trust Register

We have in [1,2] also explored the potential for al-ternative CA services. The original concept behind theX.509 standard had called for a global top-level CA,perhaps administered by the United Nations, whichwould sign the keys of national Policy CA; these inturn would certify the keys of lower level CAs; andbelow this there would be both corporate key hierar-chies and encryption services provided to private in-dividuals. An alternative concept, promoted by com-panies like Microsoft and Netscape, focuses insteadon industry sectors. The top-level key in each applica-tion is provided by the software vendor, with its publiccomponent embedded in the application. Thus, for ex-ample, Microsoft’s top level (‘root’) key would certifythat VISA was a ‘brand bindery’, VISA in turn wouldcertify its member banks, and they would then issuecertificates to their customers. This second model isbeing implemented in the specific context of the SETprotocol for credit card transactions over the Internet,but it is turning out to be less than generally applica-ble. The reason is that the software vendors are un-able or unwilling to certify the top-level keys of allthe organisations that wish to become or to establishCAs. Thus one finds a small number of X.509 CAswhose root certificates are shipped with products suchas Netscape Communicator and Microsoft Internet Ex-plorer; but a large number of CAs find themselves ex-cluded. This is especially a problem for CAs outsidethe USA.

An alternative approach to the hierarchical modelof CAs is given by Pretty Good Privacy (PGP),in which users certify each others’ keys in a ‘webof trust’. The problem here is that the web oftrust is very patchy and uneven; while there arewell-connected components (especially of computersecurity professionals) there are groups of PGP userswho form isolated components and many individ-uals who are not connected at all. As with smallCAs, there is little reason to expect that different


specialities will be connected (indeed, small CAs areoften implemented using PGP technology rather thanX.509).

The upshot of this historical legacy is that there is nocheap and effective way for Internet users to check thevalidity of public keys on which they may wish to rely.The Cambridge team tries to solve this problem bymaking available in the Global Internet Trust Registerbook the fingerprints or other information by which theroot certificates and keys of the X.509 and EDI CAsknown to us can be verified, as well as a number ofthe more important PGP keys used in the web of trustand elsewhere. When downloading such a certificateor key, user can have the browser or PGP softwarecompute the relevant fingerprint and compare it withthe value in this book. This should enable you to get ahigher level of assurance of the key’s authenticity thatwould otherwise be the case. One reason to favour aprinted book for the global root CA is that the securityissues for a book are much clearer and more tractablethan for an electronic service based on a root certificateembedded in common browsers.

Further information on this project can be foundat http://www.cl.cam.ac.uk/Research/Security/Trust-Register/.

9. Conclusions

We believe that only secure WWW can provide use-ful interface and communication means for TTP ser-vices that in turn can be useful to many aspects ofWWW information content security.

We have assessed capabilities of tools and servicesavailable on the WWW, in the context of security.We assessed the areas where TTP will both directlyand indirectly affect the WWW and enhance its se-curity. Although our findings show that this mightnot be such a dramatic enhancement as is often pro-claimed by many players in the market of WWWsecurity and/or TTP services, there is still some roomfor improvement above today’s levels of security.Simply put, things like digital signatures and encryp-tion are important, but taking care of stack-overflowproblems or having reliable audit trails is even moreimportant.

We emphasise our belief that the WYSIWYS prin-ciple should be strongly enforced within the WWW

environment, e.g. for an extended use of digital sig-natures on the WWW that might appear with applica-tions allowing a web-page form content to be signed.

We also discussed alternative means to providingWWW browser security. Mobile code is one of the bestmeans to achieve this, because cryptographic func-tions often need to be separated from both the userinterface and the communications routines. A trustedparty might then provide the necessary security func-tionality independently of the large software manu-facturers. This could also create opportunities for in-dependent European developers and trusted servicesproviders.

We believe that our research has identified the ma-jor security issues in the WWW technologies, togetherwith an effectiveness assessment of the attack detec-tion followed up by mechanisms. We emphasise ourbelief that there is a serious need for a WWW incidentreporting mechanism of the BEWARE type.

After the research exercise undertaken throughoutthe TrustWeb project, the following conclusions canbe drawn:

1. Aspects of WWW client and server vulnerabilities,and maybe also partly of protocols’ vulnerabilities,should be solved by introducing a WWW-specificincident reporting system.

2. Aspects of WWW information content security canbe solved by the means of cryptography, thus ETSservices can be useful to a large extent. However,alternative means requiring limited or no need ofa third party service can also often be used, e.g.in closed user groups or in star topologies such ashomebanking systems where everybody communi-cates with one party only, namely the bank.

3. WWW will be used as the main interface ofaccessing TTP services and WWW security istherefore crucial to TTP success. Also, WWWprotocols and other pieces of technology can beused in providing TTP services.

4. The current approach to security in browsers is notsatisfactory, as the security policy is forced uponthe user.

While investigating the mutual impact of WWWtechnologies and TTP, the picture that became muchclearer to us is: WWW security has many problems,out of which only some can be solved with the useof TTP services. On the other hand, TTPs can greatly


benefit from the developments of the WWW, whereonly secure WWW can provide useful interface andcommunication means for TTP services.

Acknowledgements

Credits go to other members of the Cambridge GTRteam – Ross Anderson, Fabien Petitcolas, Jong-HyeonLee and Harry Manifavas. We would also like tothank Kostas Papanikolaou and David Herson fromEC DGXIII, and Anil Patel and Kirit Ruparelia fromUptime Commerce Ltd. for their support during theresearch.

References

[1] R.J. Anderson, B. Crispo, J.H. Lee, C. Manifavas, V.Matyas Jr., F.A.P. Petitcolas, The Global Trust Register 1998,Northgate, UK, 1998.

[2] R.J. Anderson, B. Crispo, J.H. Lee, C. Manifavas, V. MatyasJr., F.A.P. Petitcolas, The Global Internet Trust Register, MITPress, Boston, MA, USA, 1999.

[3] R.J. Anderson, V. Matyas Jr., F.A.P. Petitcolas, I.E. Buchan,R. Hanka, Secure books: protecting the distribution ofknowledge, in: Proceedings of the 1997 Security ProtocolsWorkshop, Springer, Germany, 1997, pp. 1–11.

[4] F. Bergadano, B. Crispo, M. Eccettuato, Secure WWWtransactions using standard HTTP and Java applets, in:Proceedings of the 3rd USENIX Workshop on ElectronicCommerce, USENIX Association, Boston, MA, USA, 1998,pp. 109–119.

[5] P. Landrock, T.P. Pedersen, What you see is what you sign?in: Information Security Technical Report vol. 3, Elsevier,Amsterdam, 1998.

[6] P. Landrock, TTPs Overview – concepts and review of thestate of the art from a technical point of view, in: B. Preneel,V. Rijmen (Eds.), State of the Art of Applied Cryptology,vol. 1528, Springer, Berlin, 1998.

[7] TrustWeb consortium, reports on the TrustWeb project withinthe ETS-II INFOSEC programme by the EC DG-XIII,preliminary versions of all (three) reports are available throughhttp://www.cl.cam.ac.uk/∼vm206/trustweb.html

Bruno Crispo is a PhD candidate with theUniversity of Cambridge Computer Lab-oratory. His current area of research istrust in distributed system with a partic-ular focus on delegation issues, where hehas already published papers in technicaljournals. He is also a member of the Se-curity Group at the Universita’ di Torino,Italy.

He graduated from Universita’ di Torino in Computer Sciencein 1993, and since then participated in the EU ESPRIT-projectCTS3-NM: Conformance Testing Service 3 – Network Manage-ment and in the ETS-II INFOSEC project TrustWeb. He has alsotaken part in the project Trusted Third Parties in Distributed Sys-tems, funded by EPSRC in 1995 at the Cambridge University,where he worked extensively on the security issues related to thedesign of public key infrastructures. He served as a session chair-man in ESORICS 96 and was co-editor for the last three editionsof the Security Protocol International Workshop proceedings. Heis also a member of the Editorial Board of Computer Communi-cations Security Reviews.

Peter Landrock obtained his PhD inmathematics in 1974 from University ofChicago, and started working on securityin 1984. He served as President of theInternational Association for CryptologicResearch in 1992–95, and has been on theBoard of Directors since. He holds a pro-fessorship at Aarhus University, Denmark,where he built one of the leading researchteams in Europe in Data Security. Further-

more, he is founder and president of Cryptomathic, which offersadvanced cryptographic solutions. The customers include mostmajor vendors and numerous banks, and its software is sold infive continents. Likewise, the company team has been involved ina number of European projects on security. Cryptomathic was re-sponsible for the security in the INFOSEC pilot project, BOLERO,on electronic versions of Bills of Lading and other trading docu-ments, which involves some of the largest shippers and banks inthe world. This has now been built worldwide by SWIFT withthe assistance of Cryptomathic. Recent achievements include apilot running in three European countries on electronic checks,Mandate. The product, which has been patented, was describedin the Financial Times on 5 February 1998, and has since beentested further in SEMPER, the largest pan-European project onElectronic Commerce.

Vàclav Matyàš Jr. is a research staffmember of Ubilab, UBS AG, since Jan-uary 1999. He was a postdoctoral fellowwith the Security Group of the Universityof Cambridge Computer Laboratory since1996, undertaking research on protectingauthenticity of distributed medical infor-mation and of the trusted distribution ingeneral. He was Director, Technology andSecurity, of Uptime Commerce Ltd. in

1997–98. He also holds an assistant professorship at the MasarykUniversity, Czech Republic, since 1995, and finished his doctor-ate there in 1996. His research interests relate mainly to the


areas of applied cryptography and security. He has worked onthe Communication and Privacy Classes for the Common Criteria(Security Evaluation) with the Canadian Communications SecurityEstablishment during his studies and has been working on certi-fication schemes and key management issues within the medicalenvironment during the Royal Society Postdoctoral Fellowship in

1996–97. He was working with the ISO/IEC JTC1 SC27, andhas published a dozen papers and co-authored two books on ITsecurity and cryptography. He was the project coordinator for theINFOSEC ETS-II TrustWeb project and is editing the Computerand Communications Security Reviews, and he is also a memberof the organising committee of Eurocrypt ‘99.

Documents

WWW security and trusted third party services