Jikzi — a new framework for security policy, trusted publishing andelectronic commerce

R. Anderson* ,a, J.-H. Leeb

aComputer Laboratory, University of Cambridge, Pembroke Street, Cambridge CB2 3QG, UKbFilonet Korea Inc., CBS Building, 917-1 Mok-dong, Yangchun-gu, Seoul 158-701, South Korea

Abstract

In this paper, we will describe a thread of research, which we have followed off and on at Cambridge for about three years. Our topic is thesecurity of electronic documents, in the broad sense: how can we be sure of the authenticity of things that are published electronically?

This started off as a relatively small project, which we thought would take only a few weeks. The goal was to help our medical informaticsdepartment publish information such as drug formularies and treatment protocols on the hospital LAN or PC diskettes, in an appropriatelydependable way. It rapidly became clear that the problem was much larger and more complex; a general solution would not only cope with‘content’ — text, audio, video, software, whatever — but also with objects such as public key certificates. If done properly, it would give us asystematic way to deal with security policy on the web.

Our goal now is to let people build integrated publishing and e-commerce services using simple, uniform and appropriate mechanisms. Ourproposed solution is a single transparent markup language that allows us to support multiple security policies, plus supporting materialranging from a test implementation to an authentication logic.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Electronic publishing; Security policy; Electronic commerce

1. Introduction

In 1996, we were approached by a team developing amedical hypertext system at our local hospital. Increasingly,UK doctors have a PC in front of them as they consult theirpatients, and they use it to store the patient’s medical record;so it was felt that the time was ripe to transfer into electronicform all the reference books used routinely during consulta-tions. Funding had been secured from the National HealthService, and a first prototype built. The designers now feltthat they needed to secure the pre-production and laterversions, mainly against errors but also against attacks,and asked us for advice. We thought initially that thiswould be a simple project, lasting only a few weeks, inwhich we would show them how to implement a digitalsignature system based on X.509. How wrong we were!

The system, which is called Wax, challenged our thinkingabout document security in a number of ways. The naivesolution, namely to have the publisher sign each book in the

system, turned out to be too expensive; it is not efficient toverify the signature on a whole book when the typical readersimply wishes to consult a paragraph relating to a particulardrug or disease. There was also a problem with key manage-ment: the X.509 system was originally designed for electro-nic phone books and has since been adapted for financialtransactions, so its model is a key lifetime of 2–3 years anda signature lifetime of 2–3 d. However, an electronic bookwill typically contain long-lived data, and to protect it usingrelatively short-lived objects such as public keys is proble-matic. How, for example, would one handle revocation?One can always use a hash-based timestamping service tocertify that a signature was received in advance of a revoca-tion certificate cancelling the key which certified it, but inthat case why not protect the book using the hashingmechanism rather than the digital signature?

Considerations like these led us to design Wax so thateach publisher has associated with it a tree of hashes: theleaves are hashes of the individual sections, and the nodesprogress up through chapters and books until the root, whichprotects a publisher’s whole catalogue, is authenticated byother means at system startup. (In the initial version of Wax,this was a standard RSA signature, but the cost of licensingthe product for export to the USA led us to use a one-timesignature instead for later versions.) Thus when a user opens

Computer Communications 23 (2000) 1621–1626www.elsevier.com/locate/comcom

0140-3664/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0140-3664(00)00248-6

* Corresponding author. Tel.:144-122333-4600; fax:144-122333-4678.

E-mail addresses:rja14@cl.cam.ac.uk (R. Anderson), jhlee@filonet.com (J.-H. Lee).

a book at the entry corresponding to a particular drug, theentry can be verified quickly without having to check asignature on the entire book. Wax therefore taught us touse hash trees and minimise the amount of signature —preferably to a single signature on each new version of apublisher’s catalogue.

Wax is described in detail in Ref. [1], and has had somesuccess among UK and US medics. But it uses a proprietaryhypertext format, so when we were next asked to look at anonline medical application (the British National Formulary,which is the list of all drugs approved for prescription in theUK [2]) the obvious step was to generalise our ideas to workwith html. The result was the ERL, or eternal resourcelocator, which is described in Ref. [3]. An ERL is essentiallya URL plus a hash of what one should expect to find there.Thus a medical publisher can modify his online catalogue toreplace the URLs of his online books with ERLs, and nowusers whose browsers have a plugin, which can parse andverify the hashes, get the same protection as in Wax; mean-while, users with a standard browser enjoy backwardscompatibility in that the ERLs function perfectly well asordinary URLs.

In order to cope with web pages that change frequently,we added the facility for an ERL to contain the hash of apublic key with which a digital signature of the indicatedcontent could be verified. Such keys do not incur the over-head of a traditional public key infrastructure but are seenrather as ‘flexible links’, which can be inserted in an other-wise static trust structure wherever they are needed. In thisway, a book of largely static information such as drug datacan also incorporate some dynamic content such as links tothe latest safety bulletins.

Having developed this, we realised that we now had asurprisingly powerful and general protection system. Thewriter of a web page or other document can authenticateany digital object by simply including its ERL, and thisenables the construction of webs of trust of the kind familiarfrom PGP but applying to quite general objects rather thanjust to the names of principals. In applications where truststructures are relatively static, many of the problems asso-ciated with public key infrastructures simply go away; oneends up managing a few root keys and doing a lot of versioncontrol.

By late 1998, it had become clear that rather than addingproprietary extensions to html, we ought to support XML asthe emerging framework for commercial markup languages[4]. XML is well positioned between SGML and HTML; itis easier to use than SGML, yet provides more degrees offreedom in extension than HTML. Major software vendorsare committed to supporting it: both major players in thebrowser market already support XML processing partiallyand are expected to support it fully in the near future.

By this time, too, a number of governments and otherorganisations had got hold of the idea that signing electronicdocuments could be a good thing, and further problems hadstarted to emerge as people scrutinised various draft bills on

digital signatures. For example, creating a rebuttablepresumption of validity for electronic signatures couldhave the effect of shifting the burden of proof in disputesfrom the individual to a bank or credit card company, andthus undermine decades of progress in consumer protectionlegislation [5,6].

Another consideration was that by then there were severalother groups doing work on security markup languages,including IBM’s Secure Document Markup Language(SDML), which is designed to support electronic cheques[7], and the World Wide Web Consortium’s DSig initiative,which enables content rating data to be digitally signed [8].None of these was general enough to support the kind offunctionality needed in our application, so we wanted ournext iteration to support a wide range of security policies.

With this in mind, we decided to take a step back and tryto place electronic document security in the broader contextof computer security research.

2. Context

The first, obvious, point about securing publicly availabledocuments against tampering is the imbalance betweenresearch and practice on confidentiality, integrity and avail-ability. Thanks in part to the influence of military fundingand the interests of the crypto community, some 90% ofresearch papers deal with confidentiality, 9% with authenti-cation and 1% with availability. But while the militarymostly wants to keep data secret, business mostly wants topublish it — most e-commerce is publishing of one form oranother (adverts, catalogues, timetables, books, audio,video, software and even public key certificates). So invest-ment by business is the other way round, with the big moneygoing on backup sites and network redundancy, somemoney on audit, but only a small amount on encryption.1

This bias is particularly noticeable when we look at thesecurity policy models that researchers use to provide aconcise and abstract description of the kind of protectionwhich a system requires. The traditional military policy,which we might explain to a layman asa clerk with a secur-ity clearance to‘secret’ can read a file at‘secret’ or ‘confi-dence’ but not a file at‘ top secret’ was formalised by Belland LaPadula in two rules: that a process may not read up toa higher level, or write down to a lower one [9]. A verysubstantial research literature has grown up on top of this,and a number of compliant products have appeared;

R. Anderson, J.-H. Lee / Computer Communications 23 (2000) 1621–16261622

1 The figures are from the authors’ experience of editing ‘Computer andCommunications Security Reviews’. In the first author’s experience ofbanking systems, some 20–40% of the IT budget is spent on availability,2% on audit and an insignificant amount on crypto; the second author’sexperience of telecommunications is that although mobile communicationscarriers recognise the advantages of channel encryption for communicationthat can easily be intercepted, the availability of the service has priorityover crypto because the cost of secure communication still exceeds the lossfrom attacks and fraud.

however, the costs of a rigorous implementation are leadingmore and more governments to restrict this functionality tospecific systems such as firewalls and mail guards.

By the late 1980s, it had already been realised that therequirements of business are different. Clark and Wilsonproposed quite a different security policy model, based onthe traditional practices of double-entry bookkeeping thathad developed in the banking industry since the 12thcentury; this might be explained to the layman asall trans-actions must preserve an invariant of the system, namelythat the books must balance (so a negative entry made onone ledger must be balanced by an equal positive entry onanother one); some transactions require two officers to initi-ate them; and records of payments cannot be destroyed oncemade.

A further model, the Chinese Wall model, attempts todescribe good practice in business such as merchant bankingor advertising where a firm may have clients who arecompetitors. It can be described asan executive who hasworked recently for one company in a business sector maynot have access to the papers of any other company in thatsector. Yet another, the BMA model, codifies accepted goodpractice in handling medical records: its executive summaryis that no-one may see a medical record without thepatient’s consent, and people with read access may alsoappend information; but no deletions are permitted. Detailsof Clark–Wilson and Chinese Wall may be found in Ref.[9], while the BMA model is presented in Ref. [10].

This brings us to our second problem, which is that untilnow there has been little progress at finding ways to imple-ment multiple policies in the same system. A moment’sconsideration will convince us that these policies are struc-turally different in ways that cannot be magicked away. Forexample, Bell–LaPadula is stateless while the others arestateful; the BMA policy pushes access control decisionsto the periphery while the others centralise them; andClark–Wilson localises security state in a different wayfrom Chinese wall. This is inconvenient in real life. Onemight expect, for example, that a military hospital wouldwant to implement something like the BMA policy for itspatient records, Clark–Wilson for its accounts and Bell–LaPadula for its relationship with the outside world. Butalthough there has been extensive discussion of theproblems [11], no one really knows how to do this.

A third problem is that many important applications donot as yet have an agreed security policy model comparableto those mentioned above. The obvious example is the certi-fication of public keys. Here we can quickly state a layman’sexplanation of the requirements — thataccurate copies ofthe public key corresponding to a given role or entity shouldbe made available, together with up-to-date informationabout keys that have been revoked— but so far we arenot aware of anyone having formalised this in the mannerof the above models.

In general, we expect that applications will continue tolead theory, and this led us to believe that rather than

proposing an abstract system that could implement the exist-ing set of models, we needed a tool that could be used forrapid prototyping of protection strategies, while hopefullyalso facilitating analysis and otherwise promoting gooddesign.

Our fourth problem follows from the dual-controlrequirement in Clark–Wilson. We will often need to supporta variety of mechanisms whereby an action is taken only if anumber of other actions have been taken previously by otherprincipals; in fact we need a general syntax to support this.Cryptologic mechanisms such as threshold signatures cancause an action to be taken ifk out ofn principals agree, butreal life is more complicated. Threshold mechanisms canonly do so much.2 To make a real contribution to resilienceand survivability in real applications, separation of dutyusually needs a functional element that is bound in withthe application. Thus, the syntax needs to be accessible tothe application developer, who must be able to make subtledecisions based on content from a number of independentsources; the cryptographic ‘quick fix’ of a threshold signa-ture will usually not be enough.

Our fifth problem follows on from this point: that thecomputer security and cryptology communities divergedabout fifteen years ago, and unfortunately many of the cryp-tologic mechanisms that have become standards, whetherformally or otherwise, are hard to integrate with the compu-ter security mechanisms required in real applications.

These five problems — the erroneous emphasis on confi-dentiality, the multipolicy problem, the need for rapid proto-typing and testing of protection strategies in advance of aformal model, the need to support a variety of resiliencemechanisms and the general difficulty of integrating cryptowith computer security — form the backdrop for our freshlook at secure publishing.

3. The Jikzi model

The prototyping tool that we have built to investigatedocument security is named Jikzi, after the world’s oldestpublication produced using a moveable-type printing press.This was printed in Korea in 1377, some 63 years beforeGuttenberg, and is a Buddhist religious text.

A paper that we presented at the 1999 Security Protocolsworkshop gives much fuller details of our Jikzi system [12].There is also an alpha implementation, which although stillunder development is available for online testing andexperimentation; testers are welcome [13].

Briefly, Jikzi enables a user to play with security policiesby specifying style sheets that define a document type interms not just of the data elements that must or may be

R. Anderson, J.-H. Lee / Computer Communications 23 (2000) 1621–1626 1623

2 A useful parallel is that a disk mirroring system cannot protect usersagainst accidentally typing ‘rmp ’ when in a different directory from theone they thought they were in — and, to a first approximation, all therecoveries from backup done at our site are to recover from user errorslike this.

present, but also of security primitives such as hashing andsignature. The mechanism, Jikzi Markup Language or JML,is based on XML and allows one to define objects such asdigital certificates and electronic cheques. There is also asketch of an authentication logic, inspired by BAN, whichmay be used to verify a particular design constructed usingthese primitives.

The Jikzi model not only supports simple primitives suchas the ERL model of accompanying a URL with a hash ofthe object one expects to find there; it also enables users toimplement document types that inherit properties from othertypes in the manner of cascading style sheets. Thus, forexample, both a cheque and a bill of lading are specialcases of a bill of exchange, and a bank cheque is a specialcase of a cheque; so having agreed a definition of a bill ofexchange, we can refine it to a cheque and then to a bankcheque. The language can be extended to support othersecurity services such as timestamping, and registering adocument to ensure its uniqueness. Examples are given inRef. [12].

In the rest of this paper, we will concentrate on the essen-tials and on the lessons learned. The two critical abstractionsin making the Jikzi model tractable are that persistent filestores exist, and that confidentiality concerns are limited tolabelling.

3.1. Append-only file stores

In practice, many business and professional data storagesystems can be modelled as append-only file stores. Thisholds over a large range of organisations, from banks thatare required by law to retain a six-years transaction history,down to a physician in private practice who uses a CD-ROMas a backup mechanism for the medical records on his PC.As for the academic literature, one of us proposed the Eter-nity Service — a design for a file store distributed across thenet in an anonymous and almost holographic way, such thatthe persistence of the data could be assured even in the faceof exceptionally determined attacks [14].

Append-only file stores suffer from the theoretical vulner-ability that an attacker with unrestricted write access couldfill them up and thus deny the service they are designed toprovide. We consider that this is not a problem in real life; abank’s mainframe operators use applications that generate apredictable quantity of customer account data, journals,audit records and so on per day, while a medical practitionercan see only so many patients and type only so many kilo-bytes of notes. Services made available to the public, suchas backup services or conceivably Eternity servers, arecharged for, and if the demand rises then more storagecan be bought. So we will disregard flooding attacks.

The simplification bought by the assumption of append-only file stores means, for example, that one can sign adocument simply by including it (or a hash of it) in a filedesignated for the purpose and to which no one else has

write access. At the theoretical level, it enables us to sepa-rate the mechanisms designed to provide availability fromthose that support integrity.

3.2. Restricting consideration of confidentiality

Another great simplification is achieved by deciding tolimit our consideration of confidentiality to one of maintain-ing the integrity of labels. Thus a designer may write a stylesheet to ensure that any document initially labelled ‘TopSecret’ remains so, and that any newly created documentincorporating it is labelled appropriately. The mechanismswhereby certain users are prohibited from viewing certaindocuments are considered to be a separate problem, whichmust be solved at a higher level in the system.

At the theoretical level, assuming that confidentialityconcerns are limited to the integrity of labelling, meansthat we can separate the mechanisms designed to provideconfidentiality from those which support integrity.

3.3. A publishing security policy

The two assumptions together give us a world in whichintegrity is essentially our only concern. It may be comparedwith the world of Bell–LaPadula that focuses on confiden-tiality, and the discussion of availability in Ref. [15].

As an example of the value of this, we present in Ref. [12]a simple security policy model for publishing: a file store inwhich each user has append access to exactly one file, andall files are world readable. There we show how somesimple applications fit this model, and indicate its moregeneral usefulness. In particular, it appears to have thepower of Clark–Wilson but much greater clarity and simpli-city.

We will now turn to the more general lessons that wehave learned from experimenting with Jikzi.

4. Lessons learned

The lessons learned so far are largely pragmatic ratherthan theoretical but given the speed with which the commer-cial world is adopting XML and internet technology, andrebuilding business applications on top of them, they arenonetheless important enough to be worth reporting whilethis work is still in progress.

The first thing we have learned is that document securityis much more complicated and involves much more workthan simply signing a digital object with a properly certifiedkey and leaving the reader to draw his own conclusion.

A nice example comes from the electronic version of thedrug formulary mentioned above. This book, which ispublished every six months, contains not just a list of allthe drugs which a UK medical practitioner is legallyallowed to prescribe, but also information such as dosage

R. Anderson, J.-H. Lee / Computer Communications 23 (2000) 1621–16261624

per bodyweight and cross reactions — data that must beinterpreted accurately by applications in future hospitalsystems if the full safety and other benefits are to beextracted.

Furthermore, the book is viewed through a number ofcustomisable filters. The typical hospital has its own drugformulary, which reflects local policy on issues such aswhen generic drugs must be prescribed instead of moreexpensive branded products, or where drugs seen as danger-ous or difficult are restricted to named doctors. In the currentimplementation, the national formulary text is displayed inblack, standard headlines in blue, and local hospital restric-tions in red [2]. This is simple enough; but future editionsare likely to have further filters (e.g. for local groups offamily doctors who do follow-up care for hospital patients)and there may also be experimental drugs that are not yet inthe national formulary but are available under restrictedconditions.

There are many parallels in commercial applications. Forexample, the bundle of documents that enables a companyto collect payment for a shipment of goods may include aletter of credit, an invoice, an insurance certificate and aninspection certificate — all of which come from differentsources and are seen through different filters by differentparties to the transaction. Here, too, the potential complexitygrowth appears to be without limit, especially where thereare intermediate steps such as message processing systems.

Human computer interface may start to pose furtherproblems. In other applications, content produced in colourrather than monochrome may preclude the use of text colouras a means of indicating the source of information. Theapproach taken by the authors of Trusted X, namely colour-ing the browser frame, may give part of the answer [16].How well this can be squared with the paragraph-levellabelling favoured by some government agencies, and theeven more complex structure of documents such as drugformularies, remains to be seen.

The second lesson learned is that designing security inXML is not necessarily easier than in any other environ-ment. Application security often has an inherent complex-ity, which can be shifted to one place or another but still hasto be tackled in the end. We note the opinion expressed bythe perennial IT optimists that the huge costs of makingbusiness systems communicate with each other will some-how magically vanish when the acronym ‘EDI’ is replacedby the acronyms ‘XML’ and ‘extranet’. We beg to differ.Getting a variety of different systems to recognise that agiven field represents a drug dosage and that the unit ismilligrams rather than micrograms, has inherent complexityand criticality.

The third lesson is that tools can still help. Inheritance isimportant, and style sheets can help (so long as we do notend up with a proliferation of incompatible ones). It willalso be important to be able to draw on existing work; itwould be pointless to discard all the work that has been doneon healthcare messaging standards such as HL7 and

reinvent the wheel all over again. So although much stan-dards work may need to be re-done, one might hope that itwill be done more quickly and thoroughly the next timearound. The standards task will involve the markuplanguages themselves; it would be ideal if we could mergethe existing security markup systems into a single languagethat is powerful enough for all requirements, and we havetried to move in this direction with Jikzi and JML. Even ifthe eventual market outcome falls short of this ideal, wehope that our insights may be useful.

Finally, we have learned a lot from considering a realworld problem, namely the publication of medical data,and much of what we learned was not at all obvious whenwe set out. The experience of the Wax-ERL-Jikzi thread ofresearch supports the view that in order to understand whatservices new kinds of systems are likely to require, it isimportant to build prototypes and to exercise them on realapplications. As often in systems research, the sciencecontinues to lag the engineering. Empirical input continuesto be essential, and we encourage readers to apply our ideasand tools to their own areas of interest.

5. Conclusions

The three main aspects of electronic commerce that needto be protected against error and attack are publication,payment and copy control. Payment and copy control areeach the subject of hundreds of research papers, while publi-cation has been largely ignored.

In this paper we discussed the issues as we have come tounderstand them from undertaking a series of projects thatwere largely inspired by practical problems of medicalpublishing. We hope that we have managed to convincethe reader that the authentication of published material isa problem worthy of serious study; it is not just much morecomplex than it seems, but central to electronic commerce.

Acknowledgements

The second author was supported by EPSRC, grantnumber GR/95809 on Resilient Security Mechanisms from4/98 until 10/99. Since February 2000 the work described inthis paper has been continued by Filonet Korea Inc.

References

[1] R.J. Anderson, V. Matya´s, F.A.P. Petitcolas, I.E. Buchan, R. Hanka,Secure books: protecting the distribution of knowledge, SecurityProtocols: Proceedings of the 5th International Workshop, vol.13 611, 1997, pp. 1–12 (http://www.cl.cam.ac.uk/ftp/users/rja14/wax.ps.gz; the Wax home page is at http://www.medinfo.cam.ac.uk/wax/).

[2] British Medical Association and Royal Pharmaceutical Society ofGreat Britain, British National Formulary, ISBN 0 85369 434 6;electronic version published by Pharmaceutical Press.

[3] R.J. Anderson, V. Matya´s, F.A.P. Petitcolas, The Eternal Resource

R. Anderson, J.-H. Lee / Computer Communications 23 (2000) 1621–1626 1625

Locator: an alternative means of establishing trust on the world wideweb, in 3rd USENIX workshop on electronic commerce 1998, pp. 141–153; http://www.cl.cam.ac.uk/~fapp2/papers/ec98-erl/.

[4] T. Bray, J. Paoli, C.M. Sperberg-McQueen, Extensible MarkupLanguage (XML 1.0), W3C Recommendation REC-xml-1998210,World Wide Web Consortium, February 1998; http://www/w3/org/TR/REC-xml.

[5] R.J. Anderson, The Risks and Costs of UK Escrow Policy, in UKHouse of Commons Trade and Industry Committee, seventh report,session 1998–99; HM Stationery Office, 12 May 1999, pp. 164–169;http://www.parliament.the-stationery-office.co.uk/pa/cm199899/cmselect/cmtrdind/187/18702.html and http://www.cl.cam.ac.uk/users/rja14/dtiselcom.html.

[6] R.J. Anderson, Why Cryptosystems Fail, Communications of theACM, vol. 37 no. 11, 1994, pp. 32–40 ( http://www.cl.cam.ac.uk/users/rja14/wcf.html).

[7] J. Kravitz, SDML-Signed Document Markup Language, W3C NoteNOTE-SDML-19980619, World Wide Web Consortium, June 1998;http://www.w3.or/TR/1998/NOTE-SDML-19980619/.

[8] Y.H. Chu, P. DesAutels, B. LaMacchia, P. Lipp, PICS Signed Labels(DSig) 1.0 specification, W3C Recommendation REC-DSig-lable-19980527, World Wide Web Consortium, May 1998; http://www.w3.org/TR/REC-DSig-label.

[9] E. Amoroso, Fundamentals of Computer Security Technology,Prentice Hall, Englewood Cliffs, NJ, 1994.

[10] R.J. Anderson, A Security Policy Model for Clinical InformationSystems, in Proceedings of the 1996 IEEE Symposium on Securityand Privacy, Oakland, CA, 1996, pp. 30–43; conference paper ishttp://www.cl.cam.ac.uk/ftp/users/rja14/oakpolicy.ps.Z; full BMAversion is http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.

[11] H.H. Hosmer, The Multipolicy Paradigm for Trusted Systems, NewSecurity Paradigms Workshop 1993, RI, Little Compton, RI, 1993,pp. 19–32.

[12] R.J. Anderson, J.-H. Lee, Jikzi: A New Framework for SecurePublishing, to appear in Security Protocols: Proceedings of the 5thinternational workshop, to be published by Springer in the LNCSseries; http://www.cl.cam.ac.uk/~jhl21/jikzi-cpw/.

[13] J.-H. Lee, Jikzi system, if you want to be a tester, please contact thesecond author.

[14] R.J. Anderson, The Eternity Service, in Proceedings of Pragocrypt 96,GC UCMP, ISBN 80-01-01502-5, Prague, 1996, pp. 242–252; http://www.cl.cam.ac.uk/ftp/users/rja14/eternity.ps.Z.

[15] R.M. Needham, Denial of Service, Communications of the ACM, vol.37 no. 11, 1994, pp. 42–46.

[16] J. Epstein, R. Pascale, User Interface for a High Assurance Window-ing System, Security Applications 93 (2000) 256–264.

R. Anderson, J.-H. Lee / Computer Communications 23 (2000) 1621–16261626

Ross Anderson is a faculty member of theUniversity of Cambridge ComputerLaboratory, where he teaches and leadsresearch in computer security, cryptologyand software engineering. He is a coauthorof Serpent, a finalist in the current compe-tition to find an Advanced Encryption Stan-dard, and one of the inventors of ‘SoftTempest’ — the use of software techniquesto reduce the radio frequency informationleakage from electronic devices. He alsohas well-known publications on subjects

ranging from the security of cash machines through the tamper resis-tance of smartcards to ways of removing copyright marks from digitalaudio and video. The unifying theme of his research is to provide robustcontrol mechanisms for tomorrow’s heterogeneous distributed systems.

Jong-Hyeon Lee is a PhD candidate at theUniversity of Cambridge ComputerLaboratory. He is a coauthor of “TheGlobal Trust Register 1998” and “TheGlobal Internet Trust Register 1999”, acontributing author of “InformationHiding Techniques for Steganographyand Digital Watermarking”, and a memberof the editorial advisory board of “Compu-ter & Communications Security Review”.His interests include reliable web publish-ing, robust distributed document storage,

security protocols and cryptography.