Aura

Jia, Limin; Vaughan, Jeffrey A.; Mazurak, Karl; Zhao, Jian-Zhou; Zarko, Luke; Schorr, Joseph; Zdancewic, Steve

doi:10.1145/1411203.1411212

Cited by 19 publications

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

Reliable Evidence: Auditability by Typing

Guts

Fournet

Nardelli

2009

Computer Security – ESORICS 2009

View full text Add to dashboard Cite

Many protocols rely on audit trails to allow an impartial judge to verify a posteriori some property of a protocol run. However, in current practice the choice of what data to log is left to the programmer's intuition, and there is no guarantee that it constitutes enough evidence. We give a precise definition of auditability and we show how typechecking can be used to statically verify that a protocol always logs enough evidence. We apply our approach to several examples, including a full-scale auction-like protocol programmed in ML. A Language-Based Approach to AuditingConsider a simple protocol where a client A sends an authenticated mail to a server B. To prove her identity, A signs the message using her secret signing key and appends the signature to the message: A −→ B : text, sign(secret key(A), text)Intuitively, this protocol guarantees the authenticity of the message sent by A. The server B can verify the signature using A's public key and, if the test succeeds, B can be sure of the authenticity of the message. But, in case of dispute between A and B, does B possess enough evidence to prove authenticity to a third party?We say that a protocol is auditable with respect to a property if it logs enough evidence to convince an impartial third party, called a judge, of that property.In our example, A's text and signature, if securely stored by B, constitute sufficient evidence for auditing. Later, a judge can take a decision upon verifying the signature and, inasmuch as all principals agree on the public key infrastructure for signing, they also agree that this judge is impartial. Note that the signature alone may not constitute sufficient evidence: a careless server that discards or alters the received text would not be able to convince the judge.Suppose now that, instead of signing the text, A signs a fresh key k, encrypts it under B's public key, and encrypts the text under k using non-malleable encryption. In this case, B can decrypt and authenticate the key k, then decrypt the message, and infer the authenticity of text. However, an impartial judge cannot attribute the message to A, since both B and A are able to encrypt data using the key k; the authenticity of text for A is not auditable. (For mail, this feature is often called deniability [Roe97].)The concept of auditability is entangled with the figure of the judge. A judge is an entity that evaluates if some evidence enforces a given property, in an impartial and

show abstract

Reliable Evidence: Auditability by Typing

Guts

Fournet

Nardelli

2009

Computer Security – ESORICS 2009

View full text Add to dashboard Cite

show abstract

A Core Calculus for Provenance

Acar

Ahmed

Cheney

et al. 2012

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract.Provenance is an increasing concern due to the revolution in sharing and processing scientific data on the Web and in other computer systems. It is proposed that many computer systems will need to become provenance-aware in order to provide satisfactory accountability, reproducibility, and trust for scientific or other high-value data. To date, there is not a consensus concerning appropriate formal models or security properties for provenance. In previous work, we introduced a formal framework for provenance security and proposed formal definitions of properties called disclosure and obfuscation. This paper develops a core calculus for provenance in programming languages. Whereas previous models of provenance have focused on special-purpose languages such as workflows and database queries, we consider a higher-order, functional language with sums, products, and recursive types and functions. We explore the ramifications of using traces based on operational derivations for the purpose of comparing other forms of provenance. We design a rich class of provenance views over traces. Finally, we prove relationships among provenance views and develop some solutions to the disclosure and obfuscation problems.

show abstract