A New Approach to Secure Logging - Welcome to Sproutsprout.ics.uci.edu/pubs/a2-ma.pdf · A New Approach to Secure Logging DI MA and GENE TSUDIK University of California, Irvine The

2

A New Approach to Secure Logging

DI MA and GENE TSUDIK

University of California, Irvine

The need for secure logging is well-understood by the security professionals, including bothresearchers and practitioners. The ability to efficiently verify all (or some) log entries is impor-tant to any application employing secure logging techniques. In this article, we begin by examiningthe state of the art in secure logging and identify some problems inherent to systems based ontrusted third-party servers. We then propose a different approach to secure logging based upon re-cently developed Forward-Secure Sequential Aggregate (FssAgg) authentication techniques. Ourapproach offers both space-efficiency and provable security. We illustrate two concrete schemes—one private-verifiable and one public-verifiable—that offer practical secure logging without anyreliance on online trusted third parties or secure hardware. We also investigate the concept ofimmutability in the context of forward-secure sequential aggregate authentication to provide finergrained verification. Finally we evaluate proposed schemes and report on our experience withimplementing them within a secure logging system.

Categories and Subject Descriptors: H.2.0 Information Systems [Database Management]: Gen-eral—Security, integrity, and protection

General Terms: Design, Security

Additional Key Words and Phrases: Secure logging, forward-secure stream integrity, forward se-cure sequential aggregate (FssAgg) authentication, MACs, signatures, truncation attack

ACM Reference Format:Ma, D. and Tsudik, G. 2009. A new approach to secure logging. ACM Trans. Stor., 5, 1,Article 2 (March 2009), 21 pages. DOI = 10.1145/1502777.1502779 http://doi.acm.org/10.1145/1502777.1502779

1. INTRODUCTION

System logs are an important part of any secure IT system. They record note-worthy events, such as user activity, program execution status, system resourceusage and data changes. Logs provide a valuable view of past and current statesof almost any type of a complex system. In conjunction with appropriate toolsand procedures, audit logs can be used to enforce individual accountability,reconstruct events, detect intrusions and identify problems. Keeping systemaudit trails and reviewing them in a consistent manner is recommended by

Author’s address: D. Ma. University of California, Irvine, email: [email protected] to make digital or hard copies of part or all of this work for personal or classroom useis granted without fee provided that copies are not made or distributed for profit or commercialadvantage and that copies show this notice on the first page or initial screen of a display alongwith the full citation. Copyrights for components of this work owned by others than ACM must behonored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers,to redistribute to lists, or to use any component of this work in other works requires prior specificpermission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 PennPlaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or [email protected]© 2009 ACM 1553-3077/2009/03-ART2 $5.00DOI 10.1145/1502777.1502779 http://doi.acm.org/10.1145/1502777.1502779

ACM Transactions on Storage, Vol. 5, No. 1, Article 2, Publication date: March 2009.

2:2 • D. Ma and G. Tsudik

NIST as one of the good principles and practices for securing computer systems[Swanson and Guttman 1996]. Many types of (especially distributed) softwareinclude some sort of logging mechanism.

Because of their forensic value, system logs represent an obvious attack tar-get. An attacker who gains access to a system naturally wishes to remove tracesof its presence in order to hide attack details or to frame innocent users. In fact,the first target of an experienced attacker is often the logging system [Bel-lare and Yee 1997; Bellare and Yee 2003]. To make the audit log secure, wemust prevent the attacker from modifying log data. Secure versions of auditlogs should be designed to defend against such tampering. Providing integritychecks, the primary security requirement for any secure logging system, is in-formally stated in the Orange Book [U.S. Department of Defense 1985] as:

Audit data must be protected from modification and unauthorizeddestruction to permit detection and after-the-fact investigation ofsecurity violations.

In addition to the traditional meaning of data integrity which stipulates noinsertion of fake data and no modification or deletion of existing data, integrityof a log file also requires no reordering of log entries. We call this property logstream integrity.

In many real-world applications, a log file is generated and stored on a un-trusted logging machine that is not physically secure enough to guarantee im-possibility of compromise [Schneier and Kelsey 1998]. Compromise of a loggingmachine can happen as long as the Trusted Computing Base (TCB)—the systemcomponent responsible for logging—is not totally bug-free, which is unfortu-nately always the case. In systems using remote logging (which send audit datato a remote trusted server), if the server is not available, the log is buffered andstored temporarily at the local machine. Once an attacker obtains the secretkey of the compromised logging machine, it can modify post-compromise dataat will. In this case, one important issue is forward integrity: how to ensurethat pre-compromise data cannot be manipulated? That is, the attacker whoobtains the current secret key, must be unable to modify audit data generatedbefore compromise.

No security measure can protect log entries created after an attacker gainscontrol of a logging machine, unless the logging machine’s keys are periodi-cally updated with the help of a remote trusted server or a local trusted hard-ware component (e.g., using key-insulated and intrusion-resilient authentica-tion schemes [Bellare and Palacio 2002; Dodis et al. 2002, 2003]). We focuson the security of log entries pre-dating the compromise of a logging machine.Consequently, we require forward-secure stream integrity, that is, resistanceagainst post-compromise insertion, alteration, deletion and reordering of pre-compromise log entries.

Traditional log integrity techniques involve using specialized write-only harddisks or remote logging whereby copies of log entries are sent to several geo-graphically distributed machines. With the former, disk substitution can resultin a complete integrity compromise of the entire log. In the latter, the remoteserver may go offline (or become unreachable) and the logging machine then


A New Approach to Secure Logging • 2:3

has to locally buffer new log entries, which, in turn, become subject to attacks.Furthermore, if the remote server is compromised, log file integrity cannot beguaranteed.

Recently, a number of cryptographic approaches have been proposed toaddress security for audit logs that are generated and stored on local loggingservers [Bellare and Yee 1997, 2003; Schneier and Kelsey 1998; Holt 2006].Bellare and Yee were the first to define the forward-secure stream integrityproperty required in an audit log system and proposed to use forward-secureMACs and index log entries [Bellare and Yee 1997, 2003]. Schneier and Kelseyproposed a similar system based on forward-secure MACs and one-way hashchain [Schneier and Kelsey 1998]. Holt extended Schneier and Yee’s systemto the public key setting [Holt 2006]. Unfortunately, none of these schemesdefends against truncation attack—a special kind of deletion attack wherebythe attacker deletes a contiguous subset of tail-end log entries. Furthermore,private key-based schemes—such as Schneier-Kelsey and Bellare-Yee—alsosuffer from delayed detection attack1 since they need a trusted server to aidusers in verifying log integrity; modifications cannot be detected until theentire log data is uploaded to the trusted server. Moreover, all prior schemesare inefficient in storage and communication which makes them impracticalfor platforms with meager resources, such as implantable medical devices[Halperin et al. 2008]. We overview prior work in more detail in Section 2.

To mitigate aforementioned shortcomings of prior schemes, we propose anew approach which provides forward-secure stream integrity for audit logsgenerated and stored on untrusted machines. Our scheme is based on a newcryptographic technique called forward-secure sequential aggregate (FssAgg)authentication recently proposed in [Ma and Tsudik 2007; Ma 2008]. In a Fs-sAgg authentication scheme, forward-secure signatures (or MACs) generatedby the same signer are sequentially combined into a single aggregate signa-ture. Successful verification of an aggregate signature is equivalent to thatof each component signature. Whereas, as discussed later, failed verificationof an aggregate signature implies that at least one component signature isinvalid. A FssAgg signature scheme is thus a good match for secure logging ap-plications: it resists truncation attacks due to its all-or-nothing (aggregate andforward-secure) signature verification. In our scheme, users can verify the logwithout relying on any trusted server; this obviates delayed detection attacks.Our scheme offers storage and bandwidth efficiency inherited from the under-lying FssAgg scheme. Also, depending on the specific FssAgg scheme used, ourscheme can be either private- or public-verifiable.

In a FssAgg scheme, individual signatures are erased once they are foldedinto the aggregate signature. Subsequent validity of individual log entries isimplied by the validity of the aggregated signature computed over all log entries.This indirect verification process is costly if the verifier is only interested in thevalidity of one specific log entry. The need to provide finer-grained verification incertain applications motivates us to keep individual log entry signatures in thelog file. However, since the aggregation function is public, revealing individual

1For a precise definition, see Section 2.



signatures enables anyone to truncate log entries and create new aggregatesignature based on existing ones. To prevent this truncation attack (even whenindividual component signatures are revealed), we need the property referred toas “immutability” of aggregate authentication. (Informally, immutability is thecomputational infeasibility of computing new valid aggregated signatures fromexisting signatures.) We extended existing FssAgg MAC/signature schemes tobe immutable.

1.1 Contributions

Our contributions are as follows:

(1) We identify some fundamental security issues and architectural limitationsin prior secure logging schemes.

(2) We propose new secure logging schemes based on recently proposed FssAggauthentication techniques. Our schemes provide forward-secure stream in-tegrity for audit logs generated and stored on untrusted logging machinesand avoid the undesirable features of prior schemes. Our schemes inheritthe provable security of the underlying FssAgg schemes.

(3) We study immutability in the context of FssAgg authentication and extendexisting FssAgg MAC/signature schemes to support immutability and pro-vide finer-grained verification.

(4) We evaluate proposed schemes by comparing them with previous schemes,in terms of security as well as communication and computation efficiency.Our evaluation shows that our schemes offer better security and incur lesscomputation and communication overhead.

(5) We implement existing FssAgg signature schemes and compare their per-formance in the context of secure logging systems.

A preliminary version of this article appeared in Ma and Tsudik [2008].Organization. We begin with the analysis of the state of the art in Section 2,

followed by introduction of forward-secure aggregate authentication inSection 3. We then show how to use FssAgg schemes in logging applications: wepropose a private-verifiable scheme in Section 4 and a public-verifiable schemein Section 5. Next, we present immutable FssAgg schemes in 6. We evaluateour schemes in Section 7 and report on some experience with a prototype im-plementation in Section 8. Section 9 overviews related work and Section 10concludes the paper.

2. CURRENT APPROACH ANALYSIS

In this section, we examine the state-of-the-art represented by the Schneier-Kelsey scheme [Schneier and Kelsey 1998]. It has been used as a foundationby many subsequently proposed secure logging systems. Readers interestedin further details of the Schneier-Kelsey scheme are referred to Schneier andKelsey [1998].



2.1 Overview of Schneier-Kelsey Scheme

In the Schneier-Kelsey scheme, a logging machine U opening a new audit logfirst establishes a shared secret key A0 with a trusted remote server T . Aftereach audit entry is generated, the current secret key Ai is evolved into Ai+1through a one-way function. Log entries are linked using a hash chain. Eachlog entry Li is composed of three parts:

(1) Log entry data Mi.2

(2) Element Yi in the hash chain, where

Yi = H(Mi||Yi−1) and Y0 = H(M0)

(3) Forward-secure MAC denoted Zi, computed as: Zi = M ACAi (Yi).

U closes the log file by creating a special final-record entry, M f , and erasing A fas well as other secrets, if any.

There is no constant high-bandwidth channel betweenU and T . It is assumedthat U communicates log entries to T infrequently. At times, a moderatelytrusted entity, called V, may need to verify or read the audit log, while it is stillon U . V receives from U a copy of the audit log, [L0, L1, · · · , L f ], where f is theindex value of the last record, from U . V goes through the hash chain in the logentries (the Yi values), verifying that each entry in the hash chain is correct. Vthen sends Y f and Z f to T . T knows A0 so it can compute A f ; this allows it toverify that Z f = M ACA f (Y f ). T informs V about the verification result and Vdiscovers whether the received copy of the log has any problem.

2.2 Analysis

We claim that the Schneier-Kelsey scheme has two security-related drawbacks:Truncation Attack. a kind of deletion attack whereby the attacker erases a

contiguous subset of tail-end log messages. This attack is realistic, since, afterbreaking in, it is natural for an attacker to modify the audit log by deleting themost recent log entries generated right before break-in.

The Schneier-Kelsey scheme uses a hash chain to link log entries such thatundetectable log (link) deletion is impossible. This pertains to log entries al-ready off-loaded to T . However, log entries still residing on U are vulnerableto the truncation attack since there is no single authentication tag protectingthe integrity of the entire log file. A hash chain element Yi only protects datarecords generated before time i. Thus, truncating log entries generated aftertime i is not detected by T , unless there is synchronization between U and Tand the latter knows the current value of f . Without a continuous communi-cation channel, synchronization between U and T would require U to generatelog entries at a fixed rate. However, most logging systems are event-driven andevents are unevenly spaced. Logging events at a fixed rate hinders the loggingmachine’s ability to fully utilize its computation and storage resources.

2Schneier and Kelsey [1998] provide access control to audit log. Each log entry Li contains a logentry type Wi and Ci = EKi (Di): the actual log data Di is encrypted with an access control keyKi . Since we focus on log integrity in this paper, to make our discussion clearer, we refer to thecombination of Wi and Ci as Mi .



Fig. 1. Delayed detection attack. Data in shaded area is controlled by the attacker. a: time whenlog entries are uploaded to T ; b: time of break-in; f : index of last log entry as well as time when Vreceives a copy of log file from U .

Delayed Detection. Recall that V cannot verify a log file by itself and needsto ask for help from T . If this occurs before T receives a copy of the most up-to-date log from U , and before U has closed the log file, an attacker can modifypre-compromise records without being detected. Albeit, such modification willbe eventually detected, after T receives the updated version of a log file.

We illustrate the delayed detection attack in Figure 1. Suppose that, at timea (≥ 0), U has transmitted log entries [L0, · · · , La] to T . At time b (> a), anattacker breaks into U and obtains the current secret key Ab. Even though theattacker cannot recover secret keys used in time intervals [a +1, b−1], she canmodify the values of Mi and corresponding Yi in this interval without touchingZi. At time f (≥ b), V receives a copy of log entries L0, · · · , L f . V sends Y fand Z f to T . Since the attacker knows Ab at break-in, she can generate validMACs from time b. Thus, verification of Y f with Z f at T will succeed. Themodified log file will translate false information to V and activities conductedwithin interval [a + 1, f ] will elude V ’s detection. In Figure 1, values in theshaded area (M and Y values in time interval [a +1, b−1], all Z values within[b, f ]) can be manipulated by an attacker. Since there is no continuous high-bandwidth U ↔ T communication channel and U only communicates with Tinfrequently, the time interval [a + 1, f ] can be long.

Since the attacker cannot fake any values Zi (for i ∈ [a + 1, b − 1]), anymanipulation in this period can be detected whenever the corresponding logentries are uploaded to T and T scan-verifies all individual MACs.3

The two drawbacks of the Schneier-Kelsey scheme seem to be quite funda-mental. However, it is rather surprising that they have not been addressedin any later work. In addition to the security issues discussed previously, theSchneier-Kelsey scheme has some architectural limitations:

Online Server. As mentioned earlier, the scheme employs an assisted ver-ification process and a trusted server T must be present whenever V wantsto pose an integrity query. In other words, the scheme requires a continuouschannel (not necessarily high-bandwidth in this case) between V and T . Asany centralized solution, the scheme has the problem with T being the single

3Actually, the authors do not mention any scan-verification (verification of individual MACs) in thepaper. They only claim that verification of Z f equals to verification of all the individual MACs.



point of failure. Furthermore, the overall security of the scheme relies on thefrequency of communication between U and T . The need for T can be avoidedby adopting a public key approach, as in Holt [2006].

Storage Inefficiency. Each log entry contains a hash Yi and a MAC Zi. Toprovide reasonable long-term security guarantees, a minimum security over-head of 512 bits per log entry is needed to accommodate a 256-bit hash and a256-bit MAC. This per-log-entry overhead makes the Schneier-Kelsey schemeimpractical for resource-poor platforms, such as sensors or implantable med-ical devices. (The latter, especially, need a lightweight secure logging system[Halperin et al. 2008].)

The same set of vulnerabilities/limitations is equally applicable to theBellare-Yee private key–based scheme [Bellare and Yee 1997; Bellare and Yee2003]. The Holt scheme [Holt 2006] involves a public key–based approach.Therefore, it avoids the need for an online server and gains security againstdelayed detection attacks. However, it is still vulnerable to truncation attacksand suffers from storage inefficiency.

3. FORWARD SECURE SEQUENTIAL AGGREGATE AUTHENTICATION

In this section, we briefly introduce FssAgg scheme components. We refer toMa and Tsudik [2007] and Ma [2008] for a more formal and complete definitionof a FssAgg scheme.

A FssAgg scheme includes the following components:

[FssAgg.Kg]—key generation algorithm used to generate public/private key-pairs. It also takes as input T—the maximum number of time periods (keyevolvements).[FssAgg.Asig]—sign-and-aggregate algorithm which takes as input: a pri-vate key, a message to be signed and a signature-so-far (an aggregated sig-nature computed up to this point). It computes a new signature on the inputmessage and combines it with the signature-so-far to produce a new ag-gregate signature. The final step in FssAgg.Asig is a key update procedureFssAgg.Upd which takes as input the signing key for the current periodand returns the new signing key for the next period (not exceeding T ). Thekey update is part of the sign-and-aggregate algorithm in order to obtainstronger security guarantees.[FssAgg.Aver]—verification algorithm, which, on input of: a putative ag-gregate signature, a set of presumably signed distinct messages and apublic key, outputs a binary value indicating whether the signature isvalid.

A secure FssAgg scheme must satisfy the following properties:

(1) Correctness: Any aggregated signature produced with FssAgg.Asig must beaccepted by FssAgg.Aver.

(2) Forward-secure aggregate unforgeability: No one, even knowing the currentsigning key, can make a valid FssAgg forgery.

The forward-secure aggregate unforgeability implies two things.



First, a secure FssAgg scheme is append-only—no one can change any mes-sage generated before the compromise. Therefore a FssAgg signature can pro-vide integrity protection for the whole message body. An attacker who compro-mises a signer has two choices: (1) either it includes the intact aggregate-so-farsignature in future aggregate signatures, or (2) it ignores the aggregate-so-farsignature completely and starts a brand new aggregate signature. What it can-not do is to selectively delete components of an already-generated aggregatesignature.4 Second, it is computationally hard to remove a component signa-ture without knowing it. Thus, a secure FssAgg scheme is resistant to deletion(including truncation) attacks. These two properties are very useful and weexploit them in our design below.

We claim that FssAgg authentication implies forward-secure stream in-tegrity, that is:

Forward Security: In a FssAgg scheme, the secret signing key is updated viaa one-way function. An attacker thus cannot recover previous keys from thecurrent (compromised) key and therefore cannot forge signatures from priorintervals.5

Stream Security. The sequential aggregation process in a FssAgg schemepreserves the message order and provides stream security; thus, re-orderingof messages is impossible.Integrity. Any insertion of new messages as well as modification and deletionof existing messages renders the final aggregate unverifiable.

Based on the above, we can now construct a secure logging system from anysecure FssAgg authentication scheme.

4. PRIVATE-VERIFIABLE SCHEME

In this section, we describe a private-verifiable scheme that provides forward-secure stream integrity. In a private-verifiable scheme, verifiers are drawn froma small “private” group. Our scheme is based on the FssAgg MAC scheme pro-posed in Ma and Tsudik [2007], and its forward-secure stream integrity is inher-ited from the FssAgg MAC scheme. To avoid an online server, two FssAgg MACsare computed over the log file with different initial signing keys. A semi-trustedverifier can only verify one of them. The other MAC is used by the trusted serverto finally validate the log file. No one—including the semi-trusted verifier—canalter the contents of the log file without being detected.

In the following, we first present the trust model and system assumptions,followed by the description of system operation. Then, we show how to addoperations to start/open and close a log file such that total deletion and abnormalstop attacks can be detected. We finally evaluate the proposed scheme.

4This append-only property resembles the property of a special write-only disk used in traditionallog systems.5Assuming, of course, that the plain signature scheme—upon which the FssAgg scheme is built—isCPA-secure.



4.1 Security and System Model

There are three types of players in our scheme:(1) U is a untrusted log generator. By “untrusted,” we mean that it is not phys-

ically secure, bug-free, or sufficiently tamper-resistant to guarantee that itcannot be taken over by an attacker. U does not behave maliciously, unlesscontrolled by the attacker. It generates log entries and replies to V ’s query.It only interacts with T to start a log file or after a log file is closed.

(2) V is a semi-trusted verifier that reads and verifies the log file on U . Usually,audit logs can only be accessed by a small group of people, such as systemadministrators, security personnel and auditors. Therefore,V is drawn froma small group of authorized entities; it can obtain and verify a copy of the au-dit log from U . However, V is not trusted as far as the integrity of the log file.

(3) T is a trusted machine in a secure location. It has secure storage sufficientto store audit logs from U . It can authorize a legitimate verifier V to accessthe audit log and gives V the verification key. It also finally validates thelog file. T does not interfere in the verification process.

As in Schneier and Kelsey [1998], we assume that there is no constantly avail-able reliable high-bandwidth channel between U and trusted storage on T .Consequently, U and T communicate infrequently.

The attacker’s goal is to tamper with the log file by deleting, modifying,inserting, or reordering log entries. Clearly, the attacker who compromises Uobtains the signing key used at the time of compromise. We consider two types ofattackers: outsiders and insiders. An outsider is an attacker that knows none ofU ’s secrets before compromising U . A malicious V is considered to be an insiderattacker as it knows some of U ’s secrets. An insider is obviously more powerfulas far as its ability to tamper with the integrity of the log file. Our scheme isdesigned to detect both insider and outsider attacks.

4.2 Scheme Description

We use the following notation from here on:— Li: i-th message, i.e., the i-th log entry. (We assume that log entries are time-

stamped and generally have a well-defined format).—F : k-bit full-domain hash function with strong collision resistance F :

{0, 1}k → {0, 1}k .—H: one-way hash function with strong collision resistance and arbitrarily long

input: H : {0, 1}∗ → {0, 1}k .—mac: secure MAC function mac : {0, 1}k × {0, 1}∗ → {0, 1}t that, on input of a

k-bit key x and an arbitrary message m, outputs a t-bit macx(m).—UPD: key update frequency (as follows).At any given time, an authenticated log file consists of two parts: (1) log entries:[L1, . . . , Li] and (2) two authentication tags (forward-secure aggregate MACs):μT ,i and μV,i that will be defined.

4.2.1 Log File Initialization. Before the logging system starts, we requireT to be accessible to U and assume that U is not compromised (yet). U generates



two random symmetric keys, A1 and B1. Then, it commits these keys to T alongwith the other information about the specific log file and the key update intervalUPD. We are not concerned with the details of the commitment process. Sufficeit to say that, after the commitment process, T can go off-line and U can bedeployed in an adversarial and unattended environment.6

Meanwhile, U creates the initial “dummy” log entry L1 which commits to afixed message (e.g., set to “START”) and computes two MACs on L1 with keys A1and B1, respectively: μT,1 = macA1 (L1) and μV ,1 = macB1 (L1). Next, U evolvesits keys through a one-way function F : A2 = F(A1), and B2 = F(B1).

Through the initial interaction, T knows that U has started a log file at time1 with initial secrets A1 and B1. T stores these values in its database andthereafter knows that a valid log must exist on U and that log must containat least one log entry L1. The purpose of this initial commitment step is toprevent a total deletion attack; that is, an attacker breaking into U at a latertime should not be able to delete the whole log and simply claim that no suchlog has been started.

4.2.2 Update Frequency. We make no assumptions about key update fre-quency, except that it must be fixed at log initialization time by T or U (or both).Moreover, it must be encoded in the first message fromU to T . UPD can be basedon time (e.g., every hour), volume of activity (e.g., every 10 log entries) or somecombination thereof. However, to simplify our discussion below, we assume thatkeys are updated for each log entry.

4.2.3 Generating Log Entries. Before the i-th entry is generated, the logfile contains L1, · · · , Li−1 and two FssAgg MACs μT,i−1, μV ,i−1. Current keys ofU are: Ai and Bi. Now, a new i-th event occurs and U creates a correspondinglog entry Li. U updates7 authentication tags as follows:

1 U first generates a MAC for V as: macAi (Li). It then computes μV ,i as: μV ,i =H(μV ,i−1||macAi (Li)). Here, H acts as the aggregation function. Note that μV ,ican be represented (unrolled) as:

μV ,i = H(H(· · ·H(μV ,1||macA1 (L1)) · · ·)||macAi (Li)) (1)

2 U updates the second FssAgg MAC (for T ) in the same manner:μT,i = H(μT,i−1||macBi (Li))

3 Finally, U evolves both keys: Ai+1 = F(Ai), and Bi+1 = F(Bi). Prior keysAi and Bi and MACs macAi (Li) and macBi (Li) are immediately and securelyerased (e.g., from disk and RAM) [Gutmann 1996].8

4.2.4 Log File Closure. U officially closes the log file by creating a specialclosing message as the final log entry (L f ), updating the two authenticationtags (μV , f and μT, f ) and securely erasing the remaining keys (A f and Bf ).

6We also assume that the initial commitment as well as each subsequent log entry contains atime-stamp.7We use the term “updates,” since, at all times, there are only two authentication tags in the securelog.8Subsequent recovery of prior keys implies system compromise has occurred at an earlier time,when recovered keys were used.



This special step is necessary in order to inform users that the log file is closedproperly and no longer accepts any new data. Consider that an attacker mightprevent the logging system from functioning after gaining control of the loggingmachine. Without the explicit closing step, we cannot determine whether thelog file has been closed normally or the logging process has been impeded byan attacker. Once the log file is properly closed, an attacker who breaks into Ucannot modify anything since no keys are available.

4.2.5 Log File Validation. An authorized verifier V starts the validationprocess by obtaining A1—one of the two initial signing keys—from T . Next, Vqueries U and obtains a copy of log entries L1, · · · , L f as well as μV , f . V com-putes A2, · · · , A f through the key update function, computes μ′

V , f and checksthat it matches μV , f . Verifier’s computation costs amount to f invocations ofF , H and mac.

When T receives the complete and already-closed log file, it can indepen-dently validate it using B1 and μT, f . The validation mimics that performed byV.Note that a malicious verifierV, knowing A1, has full control and can modify anylog entries by generating its own version of μV , f . However, it cannot forge μT, f .

4.3 Discussion

The private-verifiable scheme is simple and very computation-efficient, since itonly involves fast hashing and symmetric key operations. V can verify a log filewithout consulting T ; thus, no online trusted party is needed. Furthermore, it isvery storage-efficient: compared with previous schemes which require either for 2∗ f units to store authentication-related values, our scheme only needs twostorage units for two FssAgg MACs. Considering that log files tend to be verylarge and can contain millions of log entries, the benefits of storage-efficiencyare quite apparent.

Our scheme provides forward-secure stream integrity through the use of asingle FssAgg MAC that covers all log entries. An attacker cannot forge thisMAC without knowing any pre-compromise MAC keys. Deletion and trunca-tion attacks are readily detectable by any verifier. Furthermore, our schemedetects a total deletion attack, since we use an explicit commitment processwhen starting a log file. Also, by explicitly closing the log file, our scheme candetect certain DoS attacks that aim to incapacitate the logging system.

However, we concede that a malicious verifier V can tamper with the logwithout being detected by other verifiers. This tampering can only be detectedwith the help of T . It is thus possible for a malicious insider to mount a de-layed detection attack. This is a definite drawback that leads us to constructan alternative scheme based on public key techniques.

5. A PUBLIC-VERIFIABLE SCHEME

We now describe a public-verifiable scheme. It can be based on any FssAggsignature scheme proposed in Ma and Tsudik [2007] and Ma [2008]. A public-verifiable scheme allows auditors outside the system to make sure no tamperingtakes place within the system. Therefore, it can be used for systems which



require public auditing, such as financial records and voting systems. A public-verifiable scheme also avoids the shortcoming of a private-verifiable schemeswhich, as pointed out above, suffers from delayed detection attacks.

As in the previous section, we begin with the trust model and system assump-tions. Next, we describe and evaluate the new scheme. To avoid unnecessaryrepetition, we focus on the difference between private- and public-verifiableschemes.

5.1 Trust Model

In this scheme we no longer require a trusted server T . Instead, we need aCertification Authority (CA) that can certify/register U ’s public key. The scopeof V moves from a small private group of semi-trusted entities to the publicdomain, i.e., anyone who has a copy of the log file can verify it. We no longerneed to differentiate between inside and outside attackers. An attacker is thusanyone who behaves maliciously and does not know the system’s initial secrets.

5.2 Scheme Description

An authenticated log file in the present scheme consists of two parts: log entries[L1, · · · , L f ] and a single FssAgg signature σ1, f .

5.2.1 Log File Initialization. To initiate a log file, U uses FssAgg.Kg togenerate the initial secret key sk1 and the public key pk. Then it registerspk with a public CA. U ’s certificate for log file contains (at least) essentialinformation, such as: the log creator, the log ID, starting time and the public key.For example, CA’s signature inU ’s certificate for log file IDlog might be as follows:

CERT(IDlog) = SIGNCA(U , IDlog, t, T, pk, timestamp, · · ·)U keeps sk1. Next, it creates the initial log entry L1 which is set to CERT(IDlog).Then, U generates a signature σ1,1 on L1 with FssAgg.Asig using the initialprivate key sk1. Finally, U updates its key from sk1 to sk2 and securely erasesall copies of sk1.

5.2.2 Generating Log Entries. Before the i-th entry occurs, the log file con-tains [L1, · · · , Li−1] and the FssAgg signature σ1,i−1. U ’s current secret key isski. Now, a new event occurs and triggers U to creates a new log entry Li. Uupdates its FssAgg signature by invoking FssAgg.Asig with input: Li, σ1,i−1 andski. Finally, U evolves its ski into ski+1 via FssAgg.Upd and securely erases ski.(FssAgg.Upd is invoked immediately after the aggregate signature is gener-ated.)

Since the maximum number of key update periods T is fixed a priori, as thelog file grows, the number of updates might eventually exceed T . To address thisissue we can dynamically extend the scheme to support additional key updateperiods without sacrificing security. One straightforward way is to generate apublic key for the next T number of time periods and to use the last (initiallycertified) secret key skT to, in turn, certify a new set of public keys to be usedthereafter. In fact, the certification of the next batch of public keys should betreated as a special log entry LT .



5.2.3 Log File Closure. As in the private-verifiable scheme, U closes thelog file by creating a special closing message as the final log entry L f , updatingthe FssAgg signature accordingly, and securely erasing its secret key.

5.2.4 Validating Log File. After receiving a copy of the log file, V extractspublic keys from CERT(IDlog) contained in the initial log entry L1 and V veri-fies CA’s signature on CERT(IDlog). Then, V validates the actual log file usingFssAgg.Aver.

5.3 Discussion

Compared with its private-verifiable counterpart, the present scheme offersbetter security because of its resistance to delayed detection attacks. It allowsanyone—not just a group of semi-trusted verifiers—to validate a log file. It isthus suitable for applications where scalability is important and, more gener-ally, where public verification is required. Except for the log initialization time,no trusted entity is needed for any system operations.

6. IMMUTABLE FORWARD-SECURE AGGREGATE AUTHENTICATION

In Sections 4 and 5, we proposed secure logging systems that are very efficientin term of storage and communication—only ONE aggregate tag is kept in theaudit log and individual tags are erased once they are folded into the aggre-gate. So they are very suitable to be used on platforms with meager resources,especially storage, as such devices require a light-weight audit log system. Ver-ification of individual log entry is implied by the verification of the entire logfile.

However, this indirect verification is very costly if only one particular logentry is interested. For example, users of a versioning file system might be onlyinterested in one particular version [Burns et al. 2005]. Verifying all versionsis computationally expensive (especially, in a public-verifiable scheme) and in-volves transferring unwanted data (i.e., all other versions) to the user. Further-more aggregate verification failure does not tell the user anything about theauthenticity of this particular version—there might be something wrong withother versions. It is also desirable to keep individual authentication tags in someapplications. For example, in outsourced audit log applications (SYMANTEC9;DSHIELD10) where audit logs from different log servers are submitted to athird party repository, an auditor may want to search log entries satisfying cer-tain properties, such as destination address or port number. Log entries in thequery result set may come from different log servers. In this scenario, we needindividual signatures so that the untrusted repository can use the techniquesproposed in Mykletun et al. [2004a] to answer queries.

This motivates us to keep individual signatures in the log file—in applica-tions where storage is not a problem—to provide finer grained verification. Theaggregate signature is used to protect the integrity of the whole log file whileindividual signatures are used for individual log entry verification. However,

9https://tms.symantec.com.10http://www.dshield.org.



the aggregation functions in all aforementioned FssAgg schemes are public.Thus, revealing individual signatures or MACs allows anyone to create newauthentic aggregate signatures or MACs.

For example, suppose an attacker obtains a copy of log entries [L1, · · · , L f ],their corresponding individual authentication tags as well as the aggregate au-thentication tag. In our private-verifiable scheme, the attacker can truncate thelog file from (i+1)-st log entry and then compute a new valid aggregate tags μT,iand μV ,i using Eq. 1 for log entries [L1, · · · , Li] (i < f ). In our public-verifiablescheme, the attacker can similarly generate a new aggregate signature by re-moving [σi+1, · · · , σ f ] from σ1, f by computing: σ1,i = σ1, f /

∏ fj=i+1 σ j .

To prevent truncation attacks when individual component signatures are re-vealed, we need immutable FssAgg (iFssAgg) authentication schemes. We notethat mutability is not a flaw of the underlying FssAgg signature schemes butrather an issue with some specific audit log applications. The immutability ofan iFssAgg authentication scheme in our specific log scenario means the diffi-culty of computing new valid FssAgg signatures from a set of other aggregatesignatures (an individual signature σi can be regarded as an aggregate sig-nature σi,i). We note the difference between a FssAgg signature and a normalaggregate signature: a FssAgg signature for a log file is bound to a unique ini-tial public key and covers a set of continuous log entries starting from L1, whilean aggregate signature may cover isolated log entries. For example, σ1 · σ2 · σ3(where each σi is generated with a different secret key) is a FssAgg signature fora log file containing three log entries, while σ2 ·σ3 is just an aggregate signatureof the last two log entries.

Immutable aggregate signatures have been previously considered inMykletun et al. [2004b] to prevent computation of a new aggregate signatureσ j ,k when one “sees” both σi, j and σi,k where i < j < k. However this is nota problem in our envisaged log applications since such a signature, althoughit might be a valid aggregate signature for log entries from L j to Lk , is nolonger a valid FssAgg signature for a log file bound to a fixed initial verificationkey.

6.1 Immutable FssAgg MAC Scheme

The immutability extension for the private-verifiable FssAgg MAC scheme isvery simple: U generates a “phantom” MAC and places it as the first componentinto the aggregate when the system starts; this phantom MAC is then erasedright after aggregation. We modify the log file initialization (in Section 4) asfollows:

(1) U computes μ1 = macA1 (L1) over a fixed (well-known) initialization mes-sage L1;

(2) U evolves A1 into A2;(3) When the first real log entry L2 occurs, U generates μ2 = macA2 (L2) and

aggregates: μV ,2 = H(μ1||μ2);(4) U stores both μ2 and μV ,2 in the log file, evolves A2 into A3, securely erases

μ1 and A2, and officially moves to next time period.



Note that we do not change anything involving the use of B1 and subsequentkeys Bi involved in the generation of MACs for T . In other words, only thecomputation of V-verifiable values is altered. μ1 is the “phantom MAC” whichis erased immediately after aggregation.

The resulting log file format—supporting both immutability and (efficient)individual log entry verification—is as follows:

{[L1, (L2, μ2), (L3, μ3), · · · , (L f , μ f )], μV , f , μT, f }.If V is only interested in verifying a particular log entry Li, it uses μi directlywithout involving the aggregate μV , f . However, note that, to verify Li, V stillneeds to recompute Ai which requires i hash operations.

Security of the iFssAgg MAC scheme relies on the forward-secure aggregateunforgeability of the FssAgg MAC scheme. An attacker who obtains all logentries, their exposed MACs: [μ2, · · · , μ f ] and the iFssAgg MAC μV , f , cannotconstruct a new valid iFssAgg MAC, since doing so requires either:

(1) Violating forward security of the FssAgg MAC scheme, for example, theattacker computes μ1.

or:(2) Compromise of aggregation security in the plain FssAgg MAC scheme; this

is equivalent to breaking collision-resistance of the underlying hash func-tion, for example, the attacker does not learn μ1, but learns a set of messageswith the same iFssAgg MAC as the original set of log entries.

6.2 Immutable FssAgg Signature Scheme

The iBGLS scheme in Mykletun et al. [2004b] achieves immutability by combin-ing a signature of the database server with the aggregate-so-far BGLS signa-ture of the data owner. Different query result sets and different queriers lead todistinct server signatures. The server signature is computed over all the mes-sages in the query result set and thus acts as an “umbrella” signature. Thisumbrella signature is never revealed to public. It is impossible to remove sucha signature since it is hard to remove a component signature without knowingit—a property of aggregate signature schemes.

In our context, we still exploit this property and use the same idea by fold-ing into the aggregate an umbrella signature generated over all current logentries. However, since our security model assumes eventual compromise of Uwe must fold umbrella signatures into the aggregate before an attacker breaksin. We define the time period at which an umbrella signature is generated andaggregated as an anchor point and the corresponding log entry generated inthis time period is called an anchor log entry.

For each anchor log entry L j ,U computes two signatures: a normal individualsignature σ j over L j , and an umbrella signature σ ∗

j over k + 1 log entries ofL j−k , · · · , L j . The umbrella signature σ ∗

j is aggregated with the aggregate-so-far signature. After the aggregation, σ ∗

j is securely erased. σ j is kept in the logfile for individual log entry verification. For non-anchor-log entries, U proceedsas usual except that now individual signatures are stored in the log file (insteadof being deleted after aggregation). Let L denote the set of normal log entries



and L∗ the set of anchor log entries. An iFssAgg signature can be representedas:

σ1, f =∏

Li∈Lσi

∏

L j ∈L∗σ ∗

j . (2)

So far, three FssAgg signature schemes, the BLS-FssAgg scheme [Ma andTsudik 2007], the BM-FssAgg scheme, and the AR-FssAgg scheme [Ma 2008],have been proposed. Now we show how to extend them to provide immutability.

It is easy to modify the BLS-FssAgg scheme to support immutability. σ j isnow computed as:

σ j = H1(index||L j )x j

and σ ∗j is computed as:

σ ∗j = H1(index||L j−k||L j−k+1|| · · · ||L j )x j .

where H1 is full-domain hash function defined as H1(·): {0, 1}∗ → G and G is acyclic prime order group with bilinear maps.

Constructing an immutable version of BM-FssAgg is a little more involved.First, during the key generation stage, we select two random values r0, r∗

0 andgenerate two common commitments: y = (r0)2T+1

and y∗ = (r∗0)2T+1

. We use r jto generate a normal signature (σ j ) and r∗

j to generate an umbrella signature(σ ∗

j ) . σ j is computed as:

σ j = r j

l∏

i=1

scii, j (c1 · · · cl ← H(t, y , L j ))

and σ ∗j is computed as:

σ ∗j = r∗

j

l∏

i=1

scii, j (c1 · · · cl ← H(t, y∗, L j−k , · · · , L j )).

An authenticated log file supporting immutability and individual log entry ver-ification has the following format:

{[(L1, σ1), (L2, σ2), (L3, σ3), · · · , (L f , σ f )], σ1, f },where σ1, f is computed as in Equation (2).

We can use the same idea to construct an immutable version of AR-FssAggsignature scheme. We omit the details because of page limitation.

Note that our iFssAgg signature schemes only protect log entries generatedbefore the last anchor entry. Let f ′ be the index of the last anchor log entryand f ′ ≤ f . If k > 1 and f ′ �= f , the attacker can truncate log entries afterthe f ′-th, that is, from L f ′+1 to L f . Therefore, the maximum number of logentries that the attacker can truncate is k − 1. If k = 1, every log entry is ananchor log entry and the attacker cannot mount any truncation attacks. In thiscase, U generates two sets of signatures: one for aggregation and the other—for individual verification. This extreme case requires twice the computationover the FssAgg signature schemes. Obviously, the choice of k represents a



Table I. Comparisons of Various Schemes

Private Key Public KeyBased Schemes Based Schemes

SK BYOurs

HoltOurs

FssAgg iFssAgg FssAgg iFssAggResilience to No No Yes Yes No Yes Yestruncation attack?Resilience to delayed No No No No Yes Yes Yesdetection attack?No on-line server? No No Yes Yes Yes Yes YesStorage efficient? O(n) O(n) O(1) O(n) O(n) O(1) O(n)

tradeoff between computation and security. In the following, we discuss securityof iFssAgg signature schemes constructed above by assuming f ′ = f .

Security of iFssAgg signature schemes rely on forward-secure aggregate un-forgeablity of the underlying FssAgg signature schemes. It is computationallyhard to remove an umbrella signature from the aggregate. We informally provethis by contradiction: an attacker who can forge an iFssAgg signature can alsoforge a plain FssAgg signature, which contradicts the assumption that FssAggsignature schemes are forward-secure aggregate unforgeable.

Suppose the attacker obtains all log entries L1, · · · , Li, · · · , L f with theirexposed individual signatures: [σ1, · · · , σ f ] and the iFssAgg signature σ1, f cal-culated with Equation (2). Suppose the attacker can compute a valid iFssAggsignature σ ′

1, f over log entries L1, · · · , L′i, · · · , L f where the i-th log entry is

different from the original i-th entry: Li �= L′i.

Let message Mi = Li if Li ∈ L and Mi = Li−k|| · · · ||Li if Li ∈ L∗. If L′i is

not an anchor log entry, let a be the index of the first anchor log entry after i,then σ ′

1, f is a valid FssAgg signature over messages M1, · · · , M f where Mi andMa are not queried by the attacker. If L′

i is an anchor log entry, σ ′1, f is a valid

FssAgg signature over messages M1, · · · , M f where Mi is not queried by theattacker.

7. EVALUATION

We evaluate the proposed schemes by comparing them with prior schemes.We compare our private-verifiable scheme with two existing private key–basedschemes: Schneier-Kelsey [Schneier and Kelsey 1998] and Bellare-Yee [Bellareand Yee 2003]. We also compare our public-verifiable scheme with Holt’s scheme[Holt 2006]. Our comparison is based on four factors: 1) resilience to truncationattacks; 2) resilience to delayed detection attacks; 3) on-line server require-ments; 4) storage efficiency. Comparison results are summarized in Table I.

All proposed schemes are resilient to truncation attacks and require no onlineservers. Moreover, those based on FssAgg schemes (both private- and public-verifiable) incur constant storage overhead. Therefore, they are suitable forplatforms with low storage or applications where fine-grained verification isnot required. On the other hand, iFssAgg-based schemes offer fine-grained ver-ification and incur O(n) storage overhead, the same as in all prior approches.



Table II. Comparisons of FssAgg Signature Schemes. (Operation Timing in msecs.)

BLS-FssAgg BM-FssAgg AR-FssAggSigner Asig 30 2.09 4.39

Computation Cost U pd 0.002 3.46 7.27(per log entry) total 30.00 5.55 11.66

Signer t = 100 2% 162% 3%Storage Cost t = 1000 0.2% 16.2% 0.3%

t = 10000 0.02% 1.62% 0.03%

Verifier Costt = 100 3.30 × 103 211.97 810.88t = 1000 29.3×103 2.13×103 8.16×103

t = 10000 330.72×103 21.35×103 80.84×103

8. IMPLEMENTATION

We investigated the viability of the proposed schemes on an Intel dual-core 1.73GHz Laptop with 1GB RAM running Linux. We used the NTL11

and the PBC12 libraries as for necessary cryptographic and number-theoreticprimitives.

We prototyped all the three FssAgg signature schemes, the BLS-FssAgg sig-nature scheme in Ma and Tsudik [2007] and the AR-FssAgg and BM-FssAggsignature schemes in Ma [2008], to provide heuristics for choosing among themin practice. For the BM-FssAgg and AR-FssAgg schemes, we selected securityparameters k = 1024 and l = 160. For the BLS-FssAgg scheme, we used a sin-gular curve Y 2 = X 3 + X defined on a field Fq for |q| = 512 and the group order|p| = 160, where p is a Solinas prime. Such groups have the fastest pairingoperations. We measured signer’s computation costs by signature generationand key update on a per-log-entry basis. We measured verifier’s computationcosts over an aggregate signature σ1,t when t = 100, 1, 000 and 10, 000 whichcorresponds to a small, medium, and large log file, respectively. Experimentalresults shown in Table 8 show that the BM-FssAgg scheme is the most efficientin terms of computation for both signer and verifier. Its signature generation isapproximately twice faster than that of AR-FssAgg and 5.5 times faster thanthat of the BLS-FssAgg. Its signature verification is 4 times faster than that ofthe AR-FssAgg and 16 times faster than that of the BLS-FssAgg. However, itincurs the most storage overhead.

We also investigated storage overhead incurred by each scheme. Let Ia denotethe amount of storage needed to to store the secret key and the aggregatesignature—the overhead incurred by authentication. Let |S| denote the size ofa signature or a key. Let I denote the number of log entries and |L| denote theaverage size of a log entry. We measure storage efficiency by Ia∗|S|

I∗|L| . BLS-FssAggneeds 1 unit of space each for both secret key and signature. BM-FssAgg needs162 units of storage for secret key and 1 unit for the aggregate signature. BM-FssAgg needs 2 units for secret key and 1 for the aggregate signature. To simplymeasurements, we assumed log entry size comparable to the size of a signatureor a secret key, that is, |S| ≈ |L|. The comparison results are also shown in

11http://www.shoup.net/ntl/12http://crypto.stanford.edu/pbc/times.html.



Table II. BLS-FssAgg is the best in term of storage efficiency, As the number oflog entries grows, storage overhead in BLS-FssAgg becomes negligible.

9. RELATED WORK

A number of cryptographic approaches to address secure logging have beenproposed to date. Most prior work focused on three areas: (1) data in-tegrity/authentication, (2) data confidentiality and access control, and (3)searchable encryption. Since we are primarily interested in integrity, only thefirst area directly relates to this paper.

Bellare and Yee [1997; 2003] were the first to define the forward-securestream integrity property required in an audit log system and proposed to useforward-secure MACs. They focused on formal definition and construction offorward-secure MAC schemes and applied them to secure audit log applica-tions. In their secure log scheme, multiple log entries are indexed and taggedindependently within one time period. At the end of each time period, a speciallog entry containing the number of log entries in the current time period is cre-ated to indicate the end of the current time period. This scheme has the samesecurity as well as the architectural limits as the Schneier and Kelsey schemeanalyzed in Section 2.

Schneier and Kelsey proposed a similar system (the SK scheme we analyzedin Section 2) based on forward-secure MAC and one-way hash chains [Schneierand Kelsey 1998, 1999; Kelsey and Schneier 1999]. Unlike Bellare and Yee’sscheme, in the SK scheme, rekeying is performed after each log entry is made.Therefore, they no longer use per-stage sequence numbers in tagging logs. In-stead, each log entry now contains a link in a hash chain and a forward-secureMAC computed over this link to authenticate the values of all pervious entries.Moreover, they presented a precise protocol design for its implementation ina distributed system, describing how messages are sent to external trustedmachines upon log creation and closing.

Chong, et. al. [2002] discussed the feasibility of using of tamper-resistenthardware in conjunction with a system like Schneier and Yee’s. Holt [2006]extended Schneier and Yee’s system to the public key setting.

Waters, et. al. [2004] designed encrypted and searchable audit log. Thisshowed how identity-based encryption (IBE) can be used to make audit logsefficiently searchable. Keywords which relate to each log entry are used to formpublic keys in an IBE system. Administrators allow searching and retrievalof entries matching a given set of keywords by issuing clients the correspond-ing IBE private keys. They recommended the use of the Schneier and Yee’stechnique as their authentication scheme. The two security attacks, truncationattack and delayed detection attack, which we outlined in Section 2, seem tobe very fundamental to all the secure audit log schemes as far as we know. Itis surprising that they have not been addressed by any later work so far.

10. CONCLUSION

In this article, we identified some issues in current secure logging techniques.We then proposed two concrete schemes to provide forward-secure stream



integrity for logs generated on untrusted machines. Our approach supportsforward security and compact aggregation of authentication tags (MACs or sig-natures). Both of our proposed schemes offer practical secure logging withoutreliance on trusted third parties or secure hardware. Our schemes are based onthe recent proposed FssAgg authentication schemes where a unique authen-tication tag is used to protect the integrity of underlying message body. Weevaluated the performance of proposed schemes and reported on our experi-ence with the prototype implementation of a secure logging system. We alsoconstructed and analyzed immutability extensions.

REFERENCES

BELLARE, M. AND PALACIO, A. 2002. Protecting against key exposure: strongly key-insulatedencryption with optimal threshold. In Cryptology ePrint Archive, Report 2002/64.

BELLARE, M. AND YEE, B. 1997. Forward integrity for secure audit logs. Tech. rep. University ofCalifornia at San Diego ftp://www.cs.ucsd.edu/pub/bsq/pub/fi.ps.

BELLARE, M. AND YEE, B. 2003. Forward-security in private-key cryptography. In Proceedings ofthe RSA Conference Cryptography Track.

BURNS, R., GENTRY, C., LYNN, B., AND SHACHAM, H. 2005. Verifiable audit trails for a version-ing file system. In Proceedings of the Workshop on Storage and Security (StorageSS’05). 416–432.

CHONG, C., PENG, Z., AND HARTEL, P. 2002. Secure audit logging with tamper resistant hardware. InTechnical Rep. TR-CTIT-02-29, Centre for Telematics and Information Technology, Univ. Twente,The Netherlands.

DODIS, Y., KATZ, J., XU, S., AND YUNG, M. 2002. Key-insulated public key cryptosystems. In Proceed-ings of the Annual International Conference on Theory and Practice of Cryptographic Technique(Eurocrypt’02). 65–82.

DODIS, Y., KATZ, J., XU, S., AND YUNG, M. 2003. Strong key-insulated public key cryptosystems. InProceedings of the Conference on Public Key Cryptography. 130–144.

GUTMANN, P. 1996. Secure deletion of data from magnetic and solid-state memory. In Proceedingsof the 6th USENIX Security Symposium. 22–25.

HALPERIN, D., KOHNO, T., HEYDT-BENJAMIN, T., FU, K., AND MAISEL, W. 2008. Security and privacyfor implantable medical devices. IEEE Pervas. Comput. 7, 1.

HOLT, J. 2006. Logcrypt: forward security and public verification for secure audit logs. InProceedings of the 2006 Australasian Workshops on Grid Computing and E-Research. 203–211.

KELSEY, J. AND SCHNEIER, B. 1999. Minimizing bandwidth for remote access to cryptographicallyprotected audit logs. In Proceedings of the Recent Advances in Intrusion Detection (RAID’99).

MA, D. 2008. Practical forward secure sequential aggregate signatures. In Proceedings of theACM Symposium on Information, Computer and Communications Security (ASIACCS’08).

MA, D. AND TSUDIK, G. 2007. Forward-secure sequentical aggregate authentication. In Proceed-ings of the IEEE Symposium on Security and Privacy..

MA, D. AND TSUDIK, G. 2008. A new approach to secure logging. In Proceedings of the 22nd AnnualIFIP WG 11.3 Working Conference on Data and Applications Security (DBSEC’08).

MYKLETUN, E., NARASIMHA, M., AND TSUDIK, G. 2004a. Authentication and integrity in outsourceddatabases. In Proceedings of the ACM Annual Symposium on Network and Distributed SystemSecurity (NDSS’04).

MYKLETUN, E., NARASIMHA, M., AND TSUDIK, G. 2004b. Signature bouquets: immutability for aggrea-gated/codensed signatures. In Proceedings of the European Symposium on Research in ComputerSecurity (ESORICS’04). 160–176.

SCHNEIER, B. AND KELSEY, J. 1998. Cryptographic support for secure logs on untrusted machines.Proceedings of the 7th USENIX Security Symposium.

SCHNEIER, B. AND KELSEY, J. 1999. Secure audit logs to support computer forensics. ACM Trans.Inform. Syst. Secur., 159–176.



SWANSON, M. AND GUTTMAN, B. 1996. Generally accepted principles and practices for securing in-formation technology systems. In National Institute of Standards and Technology Data Gateway800–14.

U.S. DEPARTMENT OF DEFENSE, C. S. C. 1985. Trusted computer system evaluation criteria.WATERS, B., BALFANZ, D., DURFEE, G., AND SMETERS, D. K. 2004. Building an encrypted and search-

able audit log. In Proceedings of the ACM Annual Symposium on Network and Distributed SystemSecurity (NDSS’04).

Received May 2008; revised October 2008; accepted December 2008


Documents

A New Approach to Secure Logging - Welcome to Sproutsprout.ics.uci.edu/pubs/a2-ma.pdf · A New Approach to Secure Logging DI MA and GENE TSUDIK University of California, Irvine The