Enabling shared audit data

Int J Inf Secur (2005) 4: 263–276 / Digital Object Identifier (DOI) 10.1007/s10207-004-0061-9

Enabling shared audit data

Adrian Baldwin, Simon Shiu

Hewlett Packard Labs, Bristol, UKe-mail: {adrian.baldwin|simon.shiu}@hp.comPublished online: 8 February 2005 – © Springer-Verlag 2005

Abstract. Audit is an important aspect of good securityand business practice; however, current solutions are notsupportive of electronic data and processes. This paperdescribes an audit service that both acts as a central placefor logging from heterogeneous IT systems and a place tosearch and check the audit data. Notarisation structuresenabling a user to check the integrity of audit recordsand subsets of the audit chain relating to their transac-tions have been developed. The audit system uses a securehardware device to create an alternative trust domain inwhich to run processes, maintaining the integrity of theaudit trail whilst allowing it to be tightly integration andco-located with the overall IT infrastructure.

Keywords: Audit – Secure hardware – Notarisation –Timestamp

1 Introduction

Audit is one of the fundamental security mechanisms;however, in many IT solutions it is often forgotten orweakly implemented. Traditionally, audit involves vari-ous OS functions and applications logging events to a var-iety of log files. These will usually only be examined whenthings have gone wrong. Although audit is an essentialfeature in controlling the actions of those responsible forsystems and business processes, it is only effective whenthose who understand the context review the audit log.To achieve this successfully, trust must both be placedin the integrity of the audit data and be checkable by allinterested parties; this way mistakes or wrongdoing arelikely to be detected, allowing those in charge to be heldto account.This paper describes an audit service that encourages

the sharing of segments of audit data with those involved

in the transaction. To achieve this effectively, any userquerying the system and getting back a set of events mustbe able to gain confidence that they have events that arefrom the audit log, that the events have not changed andthat they have all related events. Various, previously pro-posed, notarisation structures [1–7] protect the integrityof audit events; the structures proposed in this papersolve the additional problems associated with the sharingof audit data.The next section of this paper provides background

to the audit problem describing current approaches toIT audit, audit requirements and the gulf between themthat necessitates paper audit trails to support most busi-ness processes (including e-commerce). This is followedby a description of a third-party audit service that sup-ports and encourages the sharing of data. This service hasa number of security issues; Sect. 4 of the paper concen-trates on the creation of audit information that interestedparties can use to verify the integrity of the data. Thesestructures rely heavily on a third-party audit service, anda secure hardware service delivery model is described thatallows the audit service to be co-located with the IT in-frastructure whilst reducing the possibility of collusionbetween parties. An audit service that creates these struc-tures has been implemented, although using standardhardware instead of secure hardware devices.

2 Traditional audit

Security is largely concerned with enforcing good be-haviour and stopping inappropriate behaviour. Strongaudit processes can reinforce good behaviour as well asstronger enforcement mechanisms. Audit also forms animportant basis for encouraging good behaviour and forresolving disputes over a range of high-level processes.Many current processes create a paper trail that has phys-

264 A. Baldwin, S. Shiu: Enabling shared audit data

ical integrity (and is open to forensic examination) andacts as evidence that a process has been run properly.Moves to make many processes electronic require a simi-lar high-level digital equivalent of the paper trail. Exam-ples exist over a range of applications:

Insurance: Setting up an insurance policy (e.g. cover fora bridge or medical insurance) can become a complexbusiness involving the submittal and flow of manydocuments. Each party (requestor, brokers, under-writers, reinsurers) needs to know others received theappropriate documents.

Health: Medical records are important documents, andregulations require that they be held with integrityfor many years. Moreover, the many complex het-erogeneous workflows complicate the creation of anaudit log keeping medical practitioners accountable.

Manufacturing: Some manufacturing processes such asdrug manufacture are highly regulated, leading toa considerable paper audit trail. There is a real needto create an electronic alternative allowing informa-tion sharing between suppliers, manufacturers, audi-tors and the FDA.

System Administration: System administrators haveprivileges allowing them to obtain user data orchange their configurations. Audit systems (outsideof their control) help ensure that they are held ac-countable for their actions.

In each of these applications, it is essential to havea secure and non-repudiable audit log capable of replac-ing the paper trail. Having more interactive audit sys-tems [8] also enhances accountability of these processesin that detection of mistakes and wrongdoing becomesmore likely. For example, a patient may detect a failure ofa medical workflow.Traditionally, audit systems have a number of prob-

lems that do not lend themselves to function well in theabove scenarios andmake it hard to determine the actionsthat have occurred. A typical IT solution will consist ofa heterogeneous set of IT applications and operating sys-tems each of which can create audit log files. This leads tothree problems:

1. The log files are not secure and are within the con-trol of the administrators; hence, it is hard to use themas evidence in a dispute or as an additional controlon actions. Best practice involves writing log files toWORM (write once read many) devices or maybe touse a timestamp, but the data are still not indepen-dently verifiable.

2. Different sources at different levels of abstraction gen-erate audit logs, making it hard to form a picture ofwhat happened. Equally, it can be difficult to knowthat you have all the relevant evidence from the auditlogs, making it hard to verify that a sequence of eventshappened or did not happen.

3. Audit is only effective when those checking the au-dit logs have some understanding of the events thathave happened. However, current practice will involvesystem administrators or data mining tools exam-ining log files for unusual events and an occasionallook from an auditor. It is hard to make the dataavailable to users involved in a transaction, yet theyare the best placed to validate the audit log (in thesame way that banks encourage us to check our bankstatements).

2.1 Related work

There is a considerable body of work concerning times-tamping and chaining structures created to avoid col-lusion between the timestamp authorities [1–4, 9, 10].These structures demonstrate the integrity of the docu-ment created at a particular time. Techniques rangefrom Merkle’s hash trees involving the periodic pub-lishing of the root of a hash tree in a well-known pub-lication through Haber’s digital timestamp schemes tomixed schemes creating chains of hashes as well as havinga trusted third-party timestamp authority (TSA) sign thebasic timestamp structure. There is even a timestampingstandard defining the format of a digitally signed times-tamp along with the interactions with the timestampservice.Timestamping technologies provide a way of demon-

strating that data existed at a particular time, and times-tamped events can be chained together to produce anaudit log. However, timestamping tends to be expensiveand require a timestamp server. Bellare and Yee [5, 6]and Schneier and Kelsey [10] developed approaches to se-curing audit log files so that when a machine becomessubverted, entries prior to subversion remain valid. Bothsystems rely on having a key that is changed for eachnew entry using a one-way function ensuring that changesto previous entries (using a previous key) become de-tectable. Bellare and Yee use a pseudorandom numbergenerator to generate a sequence of keys used in comput-ing a MAC of each audit record.Schneier and Kelsey designed a scheme that both en-

crypts MACs and maintains a hash chain of events in theaudit log file. Their system uses an authentication keywhose value is derived from the previous authenticationkey Aj+1 = hash(“incremental Hash”, Aj). Encryptionkeys for each audit record are created from this authen-tication key. The log entry keeps both a hash chain thatcan be used by a partially trusted user to verify a con-tinuous segment of the audit trail. A MAC of each hashchain entry is kept using the authentication key to pro-tect the integrity of the structure. A trusted authorityissues the start point and validates and maintains closedlog files. This system allows others to validate the hashchain based on getting encrypted audit records, but ina busy system it may require that a user look at consider-able volumes of data.

A. Baldwin, S. Shiu: Enabling shared audit data 265

The structures proposed in this paper build on theprevious timestamp work from the basic timestampstructure through the publication of summary nodes toroot trust in the system. The structures proposed in thispaper help in allowing others to see not only the integrityof individual events as in a timestamped receipt but alsoto check that the events are from the audit log and thatall events of interest have been retrieved.

2.2 Attacking audit systems

In designing an audit system, it is important to considerdifferent attacks that may occur. A number of differentattack goals are discussed to set the scene for some of thesecurity mechanisms discussed in the rest of the paper.The attacks fall into two broad categories. Firstly, inter-ference with the audit system as events are added:

Denial of service: Where applications require audit at-tacks on the audit system or connectivity to it canhalt the application.

Fake events: The insertion of fake events could later en-able claims that events happened or bring the wholeaudit process into question.

Badly Structured events: Changing the format of auditevents can make them hard to find.

Alternative histories: A rogue application provider couldcreate alternative sets of events and later choosewhich to present.

Secondly, interference with the stored data or abilityto access it:

Removal of events: A user may try to remove events fromthe audit system to cover up their wrongdoing.

Addition of events: Users may try to add additionalevents to the appropriate position in an audit log inan attempt to suggest they took actions.

Damage search: Where audit logs are indexed or audi-tors use search tools subverting these tools could hideevents.

Data destruction: The destruction of audit data wouldleave it unclear as to what happened. As Schneierand Kelsey [10] discuss, cryptographic methods canhelp in detecting tampering, but it is very hard tostop an attacker destroying data without externalbackup.

Data leakage: By its very nature a high-level audit sys-tem contains confidential data that must not be al-lowed to leak.

3 An audit service

This section describes the overall architecture of a third-party audit service that receives, notarises and stores au-dit events and allows the audit logs to be searched andvalidated by those with an interest in the data. Thisinteractive audit service is illustrated using a medical

record example. Details of the notarisation scheme allow-ing users to trust the audit data follow in the next section.As with a traditional audit service, events are added

to the end of a log file as they are received. These eventsreceive some form of timestamp allowing the integrity ofthe event data and the overall audit log to be verified andchecked. Typical audit services do little to worry abouthow audit data are viewed and checked, but this serviceoffers an interface to interested users so that they canquery the system and recover events of interest and rele-vance to themselves.Searching a large log file is obviously time consum-

ing and undesirable, so the audit service holds a databasethat indexes the audit events. The query mechanism usesthis indexing database so that it can efficiently searchover a range of queries and recover the appropriate au-dit records. Events could be managed within a databasestructure; however, it is important to maintain the se-quential nature of the audit log. Keeping this sequenceis necessary for preserving a strong ordering of records,ensuring that records cannot be removed or alternativehistories held.Figure 1 shows the architecture of such an audit

service with a notarisation module that receives andtimestamps events. Events are then stored in the auditlog and indexing information is added to the indexingdatabase. This database includes a query engine thatallows a user with the appropriate authentication and au-thorisations to request a segment of the audit trail. Anauditor may use this query database, but he or she mayalso have programmatic access to the full dataset.A traditional audit record will not be easily format-

ted to support indexing and thus will often be low-levelrecords that have little meaning for the end users such asan underwriter. However, high-level audit data bridge theaudit gap between the paper records and the underlyingIT. As such, this type of audit service may not replacesystem log files but instead encourage applications and

Fig. 1. The basic audit service


workflow systems to generate meaningful audit informa-tion. This information takes the form of an event recordcontaining a set of indexes, values for those indexes anda description. Thus, an event record e will have the form:< Event type<< ind1i, val1k > . . . < indnp, valnq >>

description >where there are n indexing tuples that define each in-

dex of interest and a value within this index. The setof possible indexes will be defined by the audit service,and the application creating each audit event chooses howmany and which indexes are used.A user’s query will be in the form ‘give me all events

where < indi = valk > . . . < indj = valm >’, and the au-dit system will return the whole event set matching thoseindexes. Such searches rely on the audit events havingcorrectly indexed data. Events can be checked againsttemplates before acceptance to ensure they include a min-imal set of indexes.For any query, the user will get back a set of audit

records, and the first concern is with the structure of therecord:

– When was the record created?– Has it been changed?

The user will also be concerned to check the validity of theoverall audit segment:

– Is each record part of the audit log?– Do I have all records?

The notarisation structures described in the next sectionaddress these issues so that for a simple query the user cancheck the integrity of the record, that they are a part ofthe log file and that they have all appropriately indexedrecords. These structures ensure that they get the fullpicture of what has happened and make it very hard tochange records, add alternative histories or hide records.This is done at the level of a requested segment of theaudit record as well as the record as a whole.

3.1 Example

Before delving into the details of the notarisation struc-tures, it is useful to illustrate the importance of the auditservice with a simple example. Consider an electronic pa-tient record (EPR) system that records how patients aretreated. Audit is a critical function in keeping doctors andother medical staff accountable, and it provides an aid inreviewing and dealing with the many disputes.An EPR would typically gather all information and

may include timestamps showing the data have notchanged. The EPR itself may be built on top of a stan-dard database. Typically, these systems would be underthe control of a hospital or health authority. In case ofa dispute, the timestamp may make it hard to inserta new record; however, once treatment is disputed, rele-vant records could be suppressed. Alternatively, on earlyrealisation of a mistake a doctor could record an alterna-tive history and use this instead in the dispute.

This shows the importance of being able to show theintegrity of the whole audit system. Currently this wouldbe done by allowing a discovery process where lawyerscould wade through the millions of treatment events cre-ated over the relevant period. Audit services designed tonot only share the audit data but also to demonstratethe integrity of these data very much simplify this task(the next section describes such structures). Sharing suchevent and audit data between the many interested andauthorised parties can help smooth the underlying pro-cesses in that the audit service now provides a clear viewof all that is happening in these processes.The sharing of audit data in this manner obviously

creates issues as to who the authorised parties are whocan check the audit data. The audit service must first au-thenticate the requestor and then make an access controldecision for each audit record. The authentication stepdepends on the authentication system run on the infras-tructure. Whilst the design of the audit system tries toremain neutral to the underlying identity system, a PKImodel using identity and attribute certificates to iden-tify the user and their credentials has been used. Thisallows authorisation decisions to be made based on therequestor’s identity, their role or other credentials or at-tributes they hold.The authorisation check is based on an access control

expression or policy, which is a set of Boolean expressionsdefined for the various audit event types. Each expressioncan refer to fields within the requestor’s identity includingassociated credentials along with fields within the eventrecord (based on its structure). The following expressioncould be used to control access in this medical recordexample:

(match

(event.GetAttribute(‘‘patient’’),

Requestor.GetName())

or

(match

(event.GetAttribute(‘‘doctor’’),

Requestor.GetName())

and

Requestor.HasCredential(‘‘doctor’’)

))

The expressions specify that a person can get a recordif their name matches that in the patient attribute inthe record or if they have a doctor credential and theyare identified in the doctor attribute of the event record.Richer policies could be allowed, including specificationsconcerning auditor access rights, and perhaps mandatingintent to access is itself audited before continuing. Thisauthorisation approach has been adopted, as it is believedto be simpler to specify and maintain than to generateexplicit ACLs for each search query or audit event.Trust in the notarisation structures heavily relies on

trust in the notarisation process as events are sent foraudit. Audit services naturally have a close relationship


with the entity being audited – they receive much confi-dential data – and this relationship could lead to collu-sion. A further attack on the integrity of the audit datawould be if the hospital’s audit service could be per-suaded to rewind their clock and create a new history.The notarisation structures partially address this prob-lem by publishing elements of the audit log. The proposedservice delivery model also addresses this issue in that itallows the audit service to be an intimate part of the ITinfrastructure, but because it is a service running withina secure hardware component, it is hard to subvert.Audit processes are only useful in helping hold those

being audited to account [8] if their wrongful actions aredetected. The consequences of some actions will becomeobvious, for example a surgeon removing the wrong kid-ney; some are less obvious, for example a doctor lookingat medical records they are not entitled to see. A strongaudit service not only means that data should be keptwith integrity but that those with the necessary con-text should check the data. Take the example of a pa-tient record being accessed by a GP (primary care doc-tor). An auditor may not question a GP from Cornwall(or other holiday destination) accessing the EPR system;they would simply assume that the patient needed to seea doctor while on holiday. The patient has the necessarycontext to knowwhat happened and in this case detect er-roneous accesses. This implies that audit data should beshared with those involved in the processes.

4 Demonstrable integrity

The basic ingredient of an integrity check is the times-tamp. When a verifier “trusts” a timestamp, they es-sentially trust the timestamp authority, their processesfor securely managing their clock and using their privatesigning key. This implies that the security surroundingthe timestamp is critical; this is addressed later in Sect. 6.However, the example above in Sect. 3.1 showed that itis still possible to create alternative fictitious accountsand to choose what to present. For this reason, this workmakes use of a publishing service that allows entities torecord events and clusters of events as “part of the officialrecord”.

4.1 Notarisation structures

The designs of the structures in this section serve twopurposes:

1. To make it more difficult for entities to create alterna-tive fictitious records or to hide records.

2. To allow efficient and sharable ways to verify integritybased on trust in the timestamp authority and thepublishing service.

The chaining structures described in the following dis-cussion constitute the published “official record”. Collect-ing hashes without any structure is not enough, as this

would allow entities to burrow fictitious versions of eventswithin the record. Auditors or sceptics will want ways tocheck the bijective mapping between officially recordedevents and (segments of) the raw log files presented.A sceptical individual checking their records would nothave access to all the audit data; however, they still wantto see that each record is in the official record. An auditormay have access to all records but would not want to haveto process the complete set of audit data to validate oneor two records.The converse check, that everything related to the

query was returned, is harder to achieve. The bijectivemapping would allow such a check in some contexts, e.g.we could check that we have “all records from a givenapplication between given dates”. The index chaining de-scribed in Sect. 4.3 enables richer completeness checks.User queries involve searching for particular values in

one (or more) index. Assuring a requestor that they areseeing all records relevant to a query is in fact assuringthem that they are receiving all the relevant records towhich indexes have ever pointed. More specifically, it isstill possible to edit the indexes to only point at a sub-set of the records. Index chaining resolves this problem bychaining events according to each index value they con-tain. Before being timestamped the hash of each of theprevious records from each of the relevant index files isadded to the message, allowing users to validate that theyhave a continuous set of records for the search key.

4.2 Notarisation chaining

A traditional audit log contains a sequence of all (au-ditable) events occurring within a system. This shouldbe contrasted with a receipting model where individualevents are created but not sequenced. The receipt is a use-ful structure because it can be looked at in its own right;however, the audit log gives the larger picture of the fullsequence of events. The notarisation chaining describedhere achieves a compromise between the two.Before describing the proposed chaining solution, it is

useful to consider the security and integrity of the twodifferent solutions. Audit data can be secured by havingthem signed by an audit service or a timestamp author-ity at the point of creation. Equally, receipts should besigned and timestamped on creation. In each case, thetimestamp authority (TSA) [11] creates a structure [1] in-cluding the hash of the event, coupled with the time itwas seen by the timestamp authority, along with possiblesequence numbers and usage restrictions. This creates in-dividual records whose integrity can be validated basedon trust in the audit or timestamp service. The audit logcontains a sequence, and this should be reflected in thenotarisation or timestamping of the individual records.Chaining timestamped audit records allows an audi-

tor to look at a whole log file and check that an individualevent is validly contained within the file. It also allowsthem to check the order in which the events were inserted.


This ability to validate a sequence is an essential featureof the audit file; it stops alternative histories being cre-ated and individual records being removed from the sys-tem. However, to validate the audit file the auditor musthave access to all the audit records, and the volume ofrecords makes this process time consuming.To see this, consider the following naive chaining ap-

proach. The audit system receives a number of eventse1. . .ei. . .en each of which is given a timestamp andchained in the normal manner, creating a composite au-dit structure ai =< ei, tsi >, where tsi is the timestampcontaining the information tpi =< hash(ei), hash(tsi−1),time, TSA> such that tsi =< tpi, Sig(TSA, tpi)>. This isthe simple form of chaining described above that enforcesa sequence between the various events but does not allowfor an easy validation that an audit record aj is a memberof the overall audit record.A user seeing a small set of audit records relating to

their transactions has no validation path to check thateach event is part of this sequence, and in effect they justsee each signed structure as a receipt. The sequential na-ture of the log is thereby lost.The audit model described in Sect. 3 involved many

people having access to a small subset of the auditrecords. The aim of this first element of the notarisationchaining is to allow users to check that each record theyreceive is a member of the overall audit sequence whilstreducing the amount of other data that they must exam-ine (and have rights to see). At the same time, the auditorshould still be able to check the consistency of the overalllog file, or pieces of it – particularly in cases where usershave suspicions.Figure 2 shows the tree-like notarisation structure

proposed here. At the bottom is the sequence of auditevents a1. . .an. . ., whilst at the top a smaller summary se-quence is published. The tree structure has a predefinednumber of intermediate layers (Fig. 2 shows just one), andthe length of each intermediate layer grows as additionalaudit elements are added. The number of intermediate

Fig. 2. Defining the audit sequence with a singleintermediate layer

layers is a deployment decision taken based on the volumeand frequency of event data. An audit record (with twointermediate layers) now has the form < ai, i1j, i2k, tl >,where ai is the original audit record, i1j is the jth node ofthe first intermediate layer, i2k is the kth node of the sec-ond intermediate layer and so on until the top publishedchain is reached (where tl is the lth node).The first layer of intermediate nodes can be thought

of as breaking the audit trail into a series of blocks,which are themselves chained together. The interme-diate node thus contains a number of hashes and hasa body ibj =< hash(an). . .hash(an+ s), hash(i1,j−1) >;this structure could be signed, but that is not neces-sary. The body thus contains the s hashes of consecutiveevents, and the value of s will be randomly selectedbetween fixed bounds or defined times. This intermedi-ate layer now forms a sequence itself with |a|/mean(s)elements.Subsequent intermediate layers can then be created on

top of this sequence, each time reducing the size of thesequence. Instead of being formed from the hash of theaudit events, the next layer is constructed from the hashesof nodes in the previous layer. Each intermediate layerreduces the volume of events, and since the number ofevents within each node is random, it is harder to ascer-tain exact event numbers, although where a simple prob-ability density function is used to generate s the longer-term traffic trends will become determinable. However,additional padding events could be added to disguise traf-fic volume where this is sensitive.Now the top-level audit trail defines the sequence of

the overall log file so that a user with an audit record cancheck that a particular event is within the audit trail andthey can examine the relative order of events (by compar-ing positions within the intermediate nodes). Since thepublished summary audit trail now defines the sequenceon the overall data structure, the audit authority shouldsign each of these top nodes. This allows the publishedaudit trail to be verified and makes it harder to subvertat some later point without collusion. The published trailcould be interleaved with the public trails from other au-dit systems [2], again reducing the likelihood of collusion.A search of the audit system, for example relating to

all treatment for a particular patient, will result in a setof audit events being returned. Each audit event will havethe form < ai, i1j, i2k, tl >. The patient making the querycan programmatically validate the audit event itself andcheck that the record has integrity. They can also checkthat the hash of the audit record hash(ai) is within the in-termediate node, and so on until the top node is reached.The top-level chain will be published allowing a patientto also check that the top-level node they have been givenmatches that in the chain as well as validating the in-tegrity of the overall audit sequence – now represented bymuch fewer records.A simple validation algorithm can compute these re-

sults, and this could be executed by the user or by a third


party – equally, as the structures are opaque a third partycan write the validation algorithm. The user need not seethe full audit trail. Auditors can still validate the over-all trail, firstly by looking at the chained audit event se-quence and secondly by validating the intermediate struc-tures and the published summary trail.

4.3 Index chaining

The notarisation chaining structures described above arelargely concerned with defining the sequence on auditevents when the user only sees a sparse collection ofevents from the overall sequence. It does not help the userin determining that they have all relevant records – thatthe audit system or those who may have some legitimateor illegitimate control over it have suppressed data – orthat those critical records have been lost through acci-dent. An auditor can, by having access to the full set ofaudit data, check the completeness of the audit log, butin an audit system that can be queried a more accessiblemethod is required.The original description of the audit service at the

beginning of this section describes the structure of theaudit event, which is expected to have a number of de-fined index field value pairs as well as the basic eventdescription. Thus the raw event has the form ei =< Eventtype << ind1i,Val1k > . . . < indnp,Valnq >> description>, that is there is a set of index specifications that listindexes and the value in those indexes for a particularevent. A query takes the form of “find all events with thevalue valv in index inda”, and the user needs the ability tocheck that they have corresponding values.The audit service has structures associated with all in-

dexes that allow all the events to be found. Each indexwithin the audit system would typically be formed fromsome form of tree structure such as a b-tree, which willinclude a reference to each index value seen (for exampleeach patient). For each entry in this index tree therewill be an entry table of relevant audit records such thaton querying for all records for a particular patient theserecords can easily be recovered. These indexing struc-tures, shown in Fig. 3, must sit alongside the basic auditlog file and will have a set of pointers to that file. Anincoming query will firstly lead to a search of the treestructure for that index; this will lead to an entry table forthat value. The system must then collect all these entriesfrom the audit log file, package them up with the notari-sation chaining and send them back to the user. Theseadditional index structures could be created, stored andmanaged using a traditional database.The indexing structures described allow the audit

system to respond to a user’s query without trawlingthrough all the audit data, but it does not directly helpanswer the “have I got all relevant data” problem. Eachtable created for an index entry consists of a series ofpointers to audit events. The entry table contains a se-quence of events with a common attribute for which

Fig. 3. Structures for indexing the audit log

a search may be carried out. Each of these entry tablestherefore represents a subsequence within the audit log inwhich a user may be interested. As a new entry table iscreated, that is when a new value is inserted into an index,a start flag is added to that entry, thereby creating a startpoint. A user needs to gain confidence that they are seeingall values from this start point to the current end point;and therefore, they can have confidence they are seeing allrelevant events.To achieve this, the sequence of pointers within each

index is chained together. An index event contains a setof index–value pairs, and an index chain is added for eachof these. The audit system looks up each value in theappropriate index to find the previous hash of the previ-ous audit record with this value. It then creates an indexchaining record including the hashes of previous recordsfor each of the index–value pairs. This happens beforethe audit record is signed by the timestamp authorityand placed within the audit log. It is worth noting herethat the arrival time and sequence should be recordedfor notarisation such that delays in calculating these in-dexes (particularly in multithreaded and multiprocessorsystems) do not change the event order.The audit record is now sealed (i.e. timestamped)

with the original event message, the time it arrived, itssequence within the overall structure and the sequencewithin each index.The audit recordai nowconsists of a tu-ple < fei, tsi >, where tsi is the timestamp of fei. Theoriginal audit event ei =< Event type << indj ,Valk >. . . < indp,Valq >> description > has a structure includ-ing a set of indexes and associated values < indi, valk >,and an additional element is added to include a list of asso-ciated previous hash values forming the index sequences.The modified event record fei has the following structure:

fei =< eventtype<< indj , valk >, . . . < indp, valq >>

description >< prev(< indj , valk >), . . .prev(< indp,

. . .valq >)>>,


where the prev(< indp, valq >) function gives the hash ofthe previous audit record for the index p and value q.This results in an audit log file where each event maps

into a published official record and that has a number ofchained strands as shown in Fig. 5. There is a chain foreach value used in a particular index field, which resultsfrom including the hash of the previous value in the chainand sealing it with the timestamp. Each record will be ina number of such chains depending on the index values in-cluded in the description. The continuity of the chains canbe validated to show that each record with that value inthat index is included – each record can be validated asbeing part of the overall published audit chain.A user’s query will take the form of “find all records for

a particular index value tuple”. Nowwhen a set of recordsis returned, the service can also return index chains thatallow the user (or more likely trusted software) to checkthat the chain continues from the beginning to the latestrecord (Fig. 4).There are issues related to trusting the start point

and end point of each index. When a new index valueis entered, the prev() function returns no value, the in-dex entry is flagged as the first entry, and a new indexstructure is created. The hash values for each index or thesequence start flag are recorded and sealed by the times-

Fig. 4. The index chaining structures

Fig. 5. Interleaved structures for various indexes

tamp at the time of creation. A user worried that thelatest record might be missing can force a new record tobe added that relates to their query; this should be thelast record, and it binds together the record set.The system now heavily relies on the protection and

proper use of the keys associated with the timestamp ser-vice, but as long as they are well protected, the indexchaining becomes very hard to break. The publication ofthe summary audit trail would make it very hard to re-place one of these records. An auditor could of coursecheck the integrity of the overall system to make surethere are no discontinuities within the records.Users may of course ask complex queries involving

a number of indexes and values or for values within cer-tain ranges. In these cases the indexes are searched in thesame way, but instead of getting the results from a sin-gle event table, multiple tables will be found and can beaggregated or the intersection of the tables computed (de-pending on the user query). Aggregating the event tablesgives a number of index chains, and the user can checkthey have all expected chains and they are all complete.Taking the intersection between event tables, for exampleto find all the times a particular patient was treated bya given doctor, will result in a set of results whose in-tegrity cannot be checked. Here the query can be split intoparts, each part validated and the intersection computedafter the event sets have been validated.

4.4 Efficiency

Each event added to the audit system will need times-tamping, which involves a signing operation. The amountof signing involved in creating the notarisation structuresdepends on the number of intermediate layers and theaverage number of events contained in each node. Witha single intermediate layer as shown and an average blocksize ofm each event has an additional overhead of 1/m+1/m2 signings.Computing the index chains has a higher computa-

tional overhead that depends on the number of indexesspecified in each audit event. For each index, the auditsystem must search a tree structure, which for a b-tree islogt((n+1)/2), where t is the number of elements withineach node and n is the number of nodes in the b-tree. Thisis coupled with one or two more disk accesses to read theentry tables and a disk write to update the tables as en-tries are added. An additional hash must be computedfor each of these indexes. This means that the designerof the audit solution needs to consider the tradeoffs be-tween adding additional index information and the timeto process each event.Creating more complex audit structures has some ob-

vious implications for the efficiency of the audit service ascompared with a timestamped log file, a log file securedwith MACs [6, 10] or just using a regular file. There aretradeoffs that need to be made between the advantages ofsharing audit data and the number of events audited with


this type of system. It is believed that this type of auditservice is powerful when capturing events that are under-standable to users and should work at the process levelrather than replacing lower-level system logs.

5 Checking audit events

The notarisation structures provide a way of demonstrat-ing the integrity of the audit events that are receivedby the audit system. To a large extent, the audit ser-vice can only represent the history that it has been sentby the set of heterogeneous applications and machines.These systems must be adequately secured; a subvertedapplication could be used to send erroneous audit records,but it could equally be used to perform erroneous tasks.For example, if an EPR system is subverted, it could beused to log erroneous requests to the audit system, and,equally, it could be used to undetectably read or alterpatient records. Where security breaches are discovered,they should be recorded in the audit system so that thevalidity of the records can be assessed as part of an ac-countability process.The audit system cannot be expected to assess the

security of the entire IT system being audited, but sim-ple sanity checks can be performed and encoded into anaudit schema. On receiving an audit event, the systemcan check its source and the event type and validate anysubsequent form. Particular applications or parts of ap-plications would be expected to generate particular typesof audit events; other events received from such systemscan be rejected. Each event type can be defined with re-quired and optional sets of index fields again. Any eventthat does not conform to this description can be rejected.Checking that particular index fields are present can beparticularly important in ensuring records cannot be hid-den from the interested parties due to the lack of indexstructure. Combinations of these elements can also bechecked matching the event source with index values. Forexample, an event about a patient consultation comingfrom a GP’s computer (e.g. via SSL) would need to bea patient consultation event with the submitting GP’sidentity in the doctor field, and it would have to havea patient field.In caseswhereprocesses are runon trustedplatforms [12]

or generated by processes running within secure hard-ware [13], further assurances of the correctness of the evi-dence can be given. For example, a patient record systemwhere decryption and authorisation are together run asa secured servicewithin a hardware security appliance [14]can generate audit records that are much harder to sub-vert. Where systems have a boot process measured byTCG devices this information can be logged into the auditsystem, and although it would not be readily available tousers, it would help validate records in case of a dispute.Having certain pieces of evidence from such trusted

systems can help ground trust in the other events that fit

into a consistent sequence. A record suggesting a patienthad been treated when their records had not been ac-cessed through a decryption service would be highly ques-tionable. Further grounding is achieved through a processof interactive review – users accessing their data are likelyto spot erroneous entries. For example, a patient look-ing for information concerning a referral to a consultantwould spot if the GP had not processed it or if othershad accessed their records. Accountability is obviouslyenhanced by having well-run and trustable systems gen-erating event data; without these results may be open toquestion.

6 Realisation

A prototype of the audit service described in Sects. 3and 4 has been built and applied to a medical work-flow process. Audit is a necessary and important fea-ture within many significant electronic services; hence itis important that the service deliverable in an efficientand trustworthy manner. There is a clear tension usinga strong third-party trust service for audit and a need fora local efficient service. Using a remote service could re-sult in the audited processes being blocked due to networkdelays.The obvious way to deliver the described audit service

would be to give it an online presence at some addresson the Internet. Events would be securely sent to the ser-vice where they are notarised and stored. Much of thetrust is rooted in the notarisation process, and thereforethe interaction could just be changed to run the notarisa-tion services remotely. In this case, the hash of the auditrecord (event and index hashes) are sent remotely, anda central service will generate the timestamp along withthe notarisation chain. The event database will be runwithin the IT infrastructure whilst the notarisation is runin a different trust domain at the third party’s site.The other extreme would be to run the entire audit

system locally. Here the notarisation service would be runon a heavily protected server. A well-run IT infrastruc-ture may enforce these separations, but there are cleartrust issues for outside parties who may claim collusion.An alternative solution is to use a secure hardware-basedservice to lock down the keys and processes associatedwith the timestamping. This is the HSA approach de-scribed below.

6.1 Hardware security appliances

The hardware security appliance (HSA) approach [15, 16]offers a way to run a service within its own trust domainwhilst it is physically located with the conventional ITsystems. The HSA itself is a tamper-resistant hardwaredevice, for example based on a hardware security module(HSM), which provides a safe environment for services torun in. Such a device will have active hardware protec-


tion [17], which will detect tampering and destroy crypto-graphic material.An HSM traditionally offers a cryptographic API such

as PKCS#11; an HSA is a very similar – if not identical– physical device but with very different firmware allow-ing a service to be loaded, certified and configured. Indoing so, the service binds together various critical secu-rity functions such as authentication, authorisation andaudit along with cryptographic key usage into a simpleservice API. A trusted clock can be added to the hard-ware that is a clock within the protected domain andpowered from a battery so that it cannot be altered fromthe outside. It may have a suitably secured authenticationfor adjustments from a secure time source. This allows anHSA-based service to ensure that the timestamping keysare only used with a known and carefully controlled timesource, thereby avoiding time rollback.On a service being loaded into the HSA (Fig. 6), it is

configured with its own management policies and givenits own (PKI-based) identity, certified by the serviceprovider. In addition to the service, offering its normalfunctional API, it also defines how it can be managed,and the initialisation binds it very strongly to a servicecontroller. The service now operates within its own trustdomain – physically enforced by the tamper resistance ofthe secure hardware and logically enforced through thelimited service API and these initial management poli-cies. The management policies define not only who con-trols the service but the extent of their control (evenspecifying no management control). These managementfunctions can be carried out remotely using the PKI iden-tities of the HSA-based service and the service controller.This has changed the secure hardware device from of-

fering a simple cryptographic interface to being a service-delivery model. A crypto API helps protect keys fromdisclosure, but a subverted server process can still misusekeys. Research has shown [18–20] how further securitycan be achieved by putting more of the application withinthe secure hardware. The HSA approach tries to take this

Fig. 6. An HSA approach to service delivery

further by using the secure hardware as a service-deliverymodel, creating a strongly controlled domain for limitedbut security-critical processes to run in.

6.2 Integrated audit

Instead of sitting on an Internet port, the notarisationservice provider can create the notarisation service withinan HSA and deliver the service by shipping the hardware.The simplest formwould simply be to have an HSA-basedservice with a trusted clock and a sequence counter. Theservice would receive an event hash and combine it withthe time and sequence number, forming a timestamp thatis then signed with the service identity; this in turn is cer-tified by the service provider. The API does not allow anyother functions, making it hard to subvert.The audit service is slightly more complex in that as

the notarisation service timestamps a record, it is alsobuilding the notarisation chain. Given the limited re-sources of the secure hardware, the chain is stored on thehost system’s disk with the secure hardware recordinga MAC of the current state. As a new event is times-tamped, its hash is added into the chain data and theMAC updated within the HSA. Once the chain block isfilled, it can be signed and sent to the database, witha new open chain block being created that includes thejust-signed hash. The same process happens for each levelof the chain right up to the top published chain.Events must be timestamped as soon as they arrive at

the audit service to ensure the correct event sequence isretained. However, the timestamp needs to be generatedafter the index chain information has been computed,which will delay events and in a multiprocessor systemcould cause events to be reordered at busy times. To pre-vent this, the event is initially sent to the timestampservice that registers the event, keeping an association be-tween the time, sequence number and hash of the event.Once the complete audit record has been created, it ispassed back to the timestamp service, the hash is com-pared with the appropriate part of the audit record andthe timestamp with the original time is produced.A busy system could become overloaded when many

timestamps need to be created each second, but a numberof HSA-based devices can be combined to form a scal-able notarisation solution. Figure Fig. 7 shows a suitablestructure having a central registration point providing aclock and sequence counter and several signing modulesthat use these values to form a timestamp and sign thestructure (the most time-consuming part). This structureensures that the order of events is preserved. These mod-ules need to work in cooperation, exchanging the sessioninformation and chaining details. A session can be set upand maintained as units are added to the system by theauthority that controls the notarisation service domain.In this discussion, it is important to note that the ser-

vice is provided by an external authority and this serviceis protected by the secure hardware. Further trust can be


Fig. 7. Structures for indexing the audit log

gained by publishing the service code so others can ver-ify the lack of back doors, for example demonstrating thatthe signing keys cannot be removed from the secure hard-ware device.

7 Implementation

The audit system was implemented in C# to form theaudit structures and store them as described. The times-tamping and chaining services were initially part of theC# implementation subsequently being ported to C andrun on a separate (Linux) device to test the interfaces ne-cessary for a secure hardware-based solution. The auditservice was created as a Web service within Microsoft’sdotNet framework. New audit events arrive in the form ofXML records via SOAP and are added to the audit struc-tures as described. A client-side application allows theaudit service to be queried, again using SOAP, resultingin the return of an XML package containing the matchingset of audit records. The client-side code then checks theintegrity of the various audit chains.Whilst the implementation covers creation of the ba-

sic audit structures, data storage and indexing along withclient-side verification code, validation of the incommingaudit messages is limited to checking that the XML iswell formed. A major issue with the implementation isthat the audit service is not transactional. To achieve thisin a production environment (and ease maintainability),it may be sensible to use a DBMS to store all the auditrecords rather than using carefully optimised file struc-tures, as is currently the case.Simulations based on creating agents to generate mes-

sages such as those that would come from typical businessworkflows were used to test and demonstrate the sys-tem. This was done (based on discussions with domainexperts) in the areas of pharmaceutical manufacture, fi-nancial services and healthcare. The service was also in-tegrated as a single centralised audit solution to a securehealthcare e-mail system [14, 21]. In all these cases, the

focus was on auditing high-level workflow events, whichhave a relatively low transaction rate. The signing timestend to dominate in terms of performance, particularlywhen using signing keys of a suitable size for long-termtimestamps.

8 Distributed audit systems

The above account discussed having an audit system thatwould store information concerning a number of pro-cesses. It is clearly not feasible or desirable to have a cen-tral store for all information, but IT processes and work-flows are often associated and it is therefore useful to havelinks between audit systems, allowing for a wider assess-ment of what happened. Following the medical example,each hospital (or large department) may have an auditsystem, but a patient’s treatment may span several hos-pitals. A patient wishing to look at their treatment wouldneed to look across several audit systems.A user trying to check what has happened within

a process should not be expected to understand how theIT infrastructure is organised or how to find all the au-dit systems. In cross-organisational situations, it wouldbe hard for an auditor to find all the related audit sys-tems. It should be easy for a user using or associatedwith a process to find the relevant audit service. Auditrecords should include links as interactions occur acrossboundaries. Links can be represented by simple hyperlinkmechanisms placed within the event description. An ad-ditional attribute could be used so that the audit servicecan easily check that links have been specified and thatlinks match index information.Each audit service has a well-defined sequence (within

the timestamp) for all events that it contains, and this se-quence is independent of information within the originalevent. This ensures that users can trust the informationabout the order and time at which events were receivedby the audit service. This will no longer be the case whenmultiple audit services are being used. Each has its ownindependent sequence counter and clock, making it hardto compare events within the multiple services.Accurate global times could be used to provide order-

ings across multiple audit services, but the synchronisa-tion process itself could be attacked. Independent clocksgive some idea of ordering but within windows of theaccuracy of each clock. Ties can be inserted by havingprotocols between services to have marked synchronisa-tion points placed within the audit trail. A set of auditservices that are often linked could send each other au-dit messages to act as ties, or alternatively one servicecould be nominated as a synchronisation point. Each au-dit service could then send audit messages into this syn-chronisation audit service, and these messages should in-clude the source service, the sequence number and thetime. Messages should be sent over a secured authenti-cated link such as TLS with the audit service checking


that the specified source service matches the authenti-cated sender.This lack of ordering may present some difficulties to

a judgement process, but with orderings defined withinthe bounds of the clock, accuracies are considered eas-ier to handle than the many technical issues associatedwith running a large central evidence store. As eventsneed transmitting across IP networks, they travel differ-ent routes and are delayed at proxies, and hence accurateordering might still not be guaranteed.

9 Defending against attacks

Section 2.2 discussed a range of different goals that a usermay have in attacking an audit service. This section re-views some of these threats in light of the description ofthe audit service and structures. The first set of attacksconcerned affecting the audit system as data entered thesystem.The use of a local audit service based in secure hard-

ware means that remote connections are not necessaryfor the audit service to continue running. Attempts toblock processes based on cutting connectivity now be-come much harder, and an external denial-of-service at-tack will not block links to the audit service, which sitswithin the local network. Virus or other attacks caus-ing network storms within a subnet will of course delayconnectivity to the audit service but will also delay theprocesses themselves so that the audit service does notbecome a point of attack. Keeping the service within thelocal infrastructure makes it harder to send bad or fakemessages (to either delay or mislead the audit service)from external sources.The audit service does a certain amount of validation

of audit messages to check that they are well formed andcome from the right place. These validation processes canhelp reduce the chance of fake or badly structured mes-sages, but it is beyond the scope of any audit system todeal with subverted applications.The notarisation structures ensure all audit messages

are with an overall published audit trail; therefore it be-comes very hard to add messages later on. The removalof messages or the decision on which messages to show(alternative histories) is much harder to achieve. Towardsthis goal the notarisation messages are chained togetheraccording to index values, allowing a user to check thatthey are presented with a consistent set of records. Val-idation of the structure of the records makes it hard toinclude audit events that do not fit into these chains andthe search schema. The notarisation structures deal withmany of the basic attacks on audit systems.An attacker may try to attack the notarisation system

by colluding with the audit service provider. Publishingthe summary audit trail makes it hard to backdate anevent such that it fits into this published trail. Even ifthe published trail for a particular audit service could

be subverted, it would be hard to gain access to signingkeys that are generated within secure hardware and sub-sequently protected by active physical protection. Thesystem is still rooted in social or brand trust in the devicemanufacturer, but the manufacturer is so remote from thesolution being audited that collusion is very unlikely.The notarisation structures have been designed such

that a user can receive a package of data related to theirquery, and this package will be relatively small. The usercan therefore run a verification process on these data –they must of course trust the code performing the ver-ification. This code should come from a trusted sourceand be signed as such so that users can trust the results.Allowing many users to check the data means that notari-sation errors should be found in addition to simply beingdetectable.A determined attacker may wish to cover any tracks

by simply destroying all evidence (e.g. with a fire), andthese types of attacks are very hard to prevent. Althoughthe audit service has been described as a service run-ning locally to the IT systems being audited, care shouldbe taken to protect the data. Once audit logs have beenproduced, a backup process can ship the data to a ser-vice provider’s site (either over a network or by collectingbackup tapes). This would ensure that there is an off-site backup of the data whose integrity is still maintainedby the notarisation structures. The service provider couldalso manage access to the records and the publishing ser-vice; however, great care should be taken regarding theconfidentiality of the data.

10 Discussion

This paper has concentrated on verifiable integrity withinthe context of sharing audit data. If these structures werenot created, this type of audit service would not be trust-able. A number of other issues that need addressing whencreating a complete audit service are discussed below.

10.1 Presentation

A query of the audit system will result in a set of eventsalong with associated integrity information showing thatthe data set represents all the evidence relevant to thequery. When presented with raw event data the user maystruggle to sort out what it means in terms of the in-teractions in which they are involved. Hence, the eventrecords should be superimposed on models of the pro-cesses or interactions to aid the user through the eventset. Logic-based pattern-matching techniques could beused to aggregate events into larger processes (based onknowledge of the underlying processes) [22]. This type ofanalysis could be used to display sets of events in linearlinked sequences.Given a grouping of events, users will find it easier to

spot discontinuities or invalid events within the overall


data set. The event-aggregation process that forms suchgroups should be able to mark odd events and exceptionalpaths within a process. The audit system must supportsome form of organised browsing of events if it is to pro-vide a system to support wider accountability. Withoutit, those involved in the processes will not be able to re-view the event data and detect problems.

10.2 Trust in the audit service

The audit service must be trustable by a wide variety ofusers for it to be effective; hence it is useful to examineimplicit trust relationships. The user examining their au-dit data will firstly get a set of records from a service anduse some client-side software to validate the structures.This software can come from a source trusted by the clientrather than the audit service provider or the IT provider;it could be open source. The user should be able to gaintrust in the software.The software scans through the result set making sure

all the chains are complete and reporting summarisedresults that the user can further examine. Trust in thechains of derived events relies on trust in the individualevent timestamps and the published audit trail informa-tion (which is in turn timestamped). Section 6 describeshow the timestamp is generated within secure hardware.The HSA model [13] involves having a hardware manu-facturer certifying hardware and a service provider (e.g.timestamp provider) certifying the service. Using this de-ployment model the user can see who is providing thetimestamp and the security grounding that this brings.To gain trust in this way the user needs to trust a genericsecure hardware device along with the code running on it,which ideally would be published by the service provider.It is harder for a user to trust in the correct function-

ing of the wider audit service ensuring that the eventsare correctly validated and inserted. It is, of course, inthe interests of the IT provider to ensure that the systemis running correctly as badly formed event data cannotbe removed from the system. A further audit process orregular audit checks should be made on the data withinthe system to check that badly formed or badly indexedrecords are not present. The reporting of these checks,carried out by an independent party, allows the user togain confidence in the data they are seeing.

10.3 Data protection

Audit data, by their very nature, summarise the eventsoccurring within a solution, for example they will containevents summarising a patient’s medical treatment. A tra-ditional audit system will contain internal log files thatare protected along with the applications that createdthe data. The proposed audit service involves sharing au-dit data that present some interesting confidentiality andaccess control requirements. Access control policies canrange from an auditor seeing all events to a user seeing

events where their name is in a particular index valuetuple.Audit data often must be retained for considerable

periods, particularly when they are replacing a papertrail. For example, some medical data need to be storedfor 7 years after the death of an individual. This presentssome interesting security and survivability issues. Dataneed to be backed up and retained on one or more sitesto ensure a degree of protection from disaster. Given thisneed to replicate data, it is important to ensure data areprotected against unauthorised access (including by thosewith physical access to the storage media).The audit prototype provides for encrypting all index

data along with obscuring search indexes and providinga policy-based access control system to control releaseof the data. The approach taken in [8] is to use an en-cryption/decryption service that manages symmetric en-cryption keys and applies access control policies. Thesepolicies allow the identity and associated credentials ofthe requestor to be linked to information within the pol-icy, for example specifying that patients can see their ownmedical records. Only when the policy is satisfied are datareturned (ideally re-encrypted for the requestor). Thiskey management and authorisation service can be runwithin an HSA, resulting in a high degree of confidential-ity for the audit data.

11 Conclusion

This paper presented a study of the audit problem andproposed that audit data should be available to all in-terested parties, ensuring it will be checked. Extendedtimestamp structures based on chaining over time and in-dex features are described that enable this trustworthysharing of audit data. They allow users to ask for particu-lar segments of audit data and validate the integrity ofboth the data and the data set. Secure hardware createsa virtual trust domain, allowing trust in an efficient localservice to be rooted. This type of audit service providesa strong root of trust in ensuring those in control of IT in-frastructures and solutions are held to account for theiractions.

References

1. Haber S, Stornetta WS (1991) How to time-stamp a digitaldocument. J Cryptol 3:99–111

2. Bayer D, Haber S, Stornetta WS (1993) Improving the effi-ciency and reliability of digital time-stamping. In: CapocelliRM, De Santis A, Vaccaro U (eds) Sequences II: Methodsin communication, security, and computer science. Springer,Berlin Heidelberg New York, pp 329–334

3. Merkle RC (1980) Protocols for public key cryptography. In:IEEE symposium on security and privacy, pp 122–134

4. Merkle RC (1989) A certified digital signature. In: Advancesin Cryptology

5. Bellare M, Yee B (2003) Forward-security in private-key cryp-tography. In: Joye M (ed) Topics in Cryptology – CT-RSA 03.Lecture notes in computer science, vol 2612. Springer, BerlinHeidelberg New York


6. Bellare M, Yee B (1997) Forward integrity for audit logs. Tech-nical report, UCSD tech report

7. Schneier B, Kelsey J (1998) Cryptographic support for se-cure logs on untrusted machines. In: Proceedings of the 7thUSENUX security symposium

8. Baldwin A (2004) Enhanced accountability for electronic pro-cesses. In: 2nd international conference on trust management.Lecture notes in computer science, vol . Springer, Berlin Hei-delberg New York

9. Buldas A, Laud P, Lipmaa H, Villemson J (1998) Time-stamping with binary linking schemes. In: Krawczyk H (ed)Advances on Cryptology – CRYPTO ’98, Santa Barbara, CA.Lecture notes in computer science, vol 1462. Springer, BerlinHeidelberg New York, pp 486–501

10. Schneier B (1996) Applied cryptography, 2nd edn: Proto-cols, algorithms and source code in C. Wiley, NewYork

11. Adams C, Cain P, Pinkas D, Zuccherato R (2001) Rfc 3161Internet x.509 public key infrastructure time stamp proto-col (tsp).http://www.ietf.org/rfc/rfc3161.txt

12. Pearson S (ed) (2002) Trusted computing platforms: TCPAtechnology in context. HP Books, Prentice Hall, EnglewoodCliffs, NJ

13. Baldwin A, Shiu S (2003) Hardware encapsulation of secu-rity services. In: Compter Security: Proceedings of ESORICS2003. Lecture notes in computer science, vol 2808. Springer,Berlin Heidelberg New York

14. Ferreira A, Shiu S, Baldwin A (2003) Towards secure elec-tronic patient records. In: 1st MEDINF international confer-ence on medical informatics and engineering

15. Baldwin A, Shiu S (2002) Encryption and key management ina san. In: IEEE workshop on security in storage (SISW02)

16. Baldwin A, Shiu S (2003) Hardware security appliances fortrust. In: 1st international conference on trust management.Lecture notes in computer science, vol 2692. Springer, BerlinHeidelberg New York

17. FIPS (2001) Security requirements for cryptographic modules.fips 140-2. http://csrc.nist.gov/cryptval/140-2.htm

18. Smith SW, Palmer ER, Weingart S (1998) Using a high per-formance programmable secure coprocessor. In: 2nd interna-tional conference on financial cryptography. Lecture notes incomputer science, vol . Springer, Berlin Heidelberg New York

19. Itoi N (2000) Secure coprocessor integration with kerberos V5.In: Usenix security symposium, pp 113–128

20. Smith SW, Safford D (2000) Practical private informationretrieval with secure coprocessors. Technical report, IBM Re-search TJ Watson Research Center, Yorktown Heights, NY.http://www.research.ibm.com/secure_systems_department/projects/scop/papers/rc21806.pdf

21. Casassa Mont M, Bramhall P, Harrison K (2003) A flexiblerole-based secure messaging service: Exploiting ibe technologyfor privacy in health care. In: DEXA Workshops. IEEE Press,New York

22. Schank R, Abelson R (1977) Scripts, Plans, Goals and Under-standing. Erlbaum, Hillsdale, NJ

Documents

Enabling shared audit data