Authorization, Audit, and Provenance in the AURA System

(1)

Authorization, Audit, and Provenance in the

A

URA

System

Jeff Vaughan

Department of Computer and Information Science University of Pennsylvania

Symposium on Provenance in Software Systems March 30, 2009

(2)

(3)

Who am I?

What do I do?

My thesis research is on the AURAprogramming system. Proof carrying access control

Principled audit logging

Analysis of decryption failures (in progress)

Key idea

Proof checking ensures systems only service high integrity (authentic, high quality) requests

Audit logs comprise a documented record of this.

(4)

Who am I?

What do I do?

Key idea

Proof checking ensures systems only service high integrity (authentic, high quality) requests

Audit logs comprise a documented record of this.

What I’ll talk about today.

(5)

Who am I?

What do I do?

Key idea

Proof checking ensures systems only service high integrity (authentic, highquality) requests

Audit logs comprisea documented record of this.

(6)

What am I doing here?

A Definition

Provenance: . . .

3. The history of the ownership of a work of art or an antique, used as a guide to authenticity or quality; a documented record of this.

—The Oxford English Dictionary

What I’d like to learn about this week.

(7)

What am I doing here?

A Definition

Provenance: . . .

(8)

What am I doing here?

A Definition

Provenance: . . .

3. The history of the ownership of a work of art or an antique, used as a guide toauthenticityorquality;a documented record of this.

What I’d like to learn about this week.

(9)

What am I doing here?

A Definition

Provenance: . . .

(10)

Outline

1 An overview of AURA

2 Auditing access control

3 Auditing and confidentiality

4 Conclusion

(11)

A distributed access control example

Jukebox’s signature:

(12)

A distributed access control example

playFor raw: (s: Song) → (p:prin) → Unit

(13)

A distributed access control example

(DancingQu_{een, Alice)}

(14)

A distributed access control example

(15)

A distributed access control example

(16)

A distributed access control example

(17)

The Record Company’s (RecCo) Music Policy

Policy Statement (Simple):

Songs have one or more owners.

An owner may authorize principals to play songs he owns.

Policy Enforcement Problems (Hard): distributed decision making mutual distrust

(18)

The Record Company’s (RecCo) Music Policy

Policy Statement (Simple):

Songs have one or more owners.

An owner may authorize principals to play songs he owns.

Policy Enforcement Problems (Hard): distributed decision making mutual distrust

prominent use of delegation

(19)

A

URA

: Enforce policy with proof carrying access control.

Programs build proofs attesting to their access rights.

Proof components

standard rules of inference

evidence capturing principal intent (e.g. signatures) Hypothesis: Proofs are provenance metadata! AURAruntime:

checks proof structure (well-typedness) logs appropriate proofs for later audit

Proof Carrying Authentication [Appel+ 93],

(20)

A

URA

’s says constructor represents affirmation.

Notation

“p : P” means “p is a proof of P.”

The proposition “principal Alice affirms proposition P.” Alice says P

Principals actively affirm propositions with signatures. sign(Alice, P): Alice says P

Principals are rational. When p: P, return Alice p: Alice says P

DCC [Abadi+ 06], Logic with Explicit Time [DeYoung+ 08]

(21)

Says + dependent types allow for expressive rules.

Example (Bob acts for Alice)

Alice says ((P: Prop) → Bob says P → P)

Example (Bob acts for Alice only regarding jazz)

Alice says ((s: Song) → isJazz s →

Bobsays (MayPlay Bob s) → MayPlay Bob s)

Example (Kernel allows RPC calls on endorsed strings)

(A: prin) → (x: string ) →

(22)

Says + dependent types allow for expressive rules.

Asays (valid x) → Kernel says (okToRpc x)

(23)

Says + dependent types allow for expressive rules.

(24)

Encoding music policy using says.

shareRule ≡ RecCosays (

(o: prin) → (s: Song) → (r: prin) → (Owns o s) →

(osays (MayPlay r s)) → (MayPlay r s)))

playFor: (s: Song) → (p:prin) →

pf (RecCo says (MayPlay p s)) → Unit

Key Property

A program can only call playFor when it has an appropriate access control proof.

(25)

Encoding music policy using says.

shareRule ≡ RecCosays (

(o: prin) → (s: Song) → (r: prin) → (Owns o s) →

(osays (MayPlay r s)) → (MayPlay r s)))

playFor: (s: Song) → (p:prin) →

pf (RecCo says (MayPlay p s)) → Unit

Key Property

(35)

(36)

Using the RecCo policy.

RecCo says ...

Alice says ... shareRule

RecCo says (MayPlay Bob, TakeFive) ... ... p

⎫

⎪

⎬

⎪

⎭

11/27

(37)

(38)

Using the RecCo policy.

(39)

(40)

Using the RecCo policy.

(41)

Using the RecCo policy.

(42)

Using the RecCo policy.

(43)

Using the RecCo policy.

Signatures used to grant Bob access to TakeFive: sign(RecCo,shareRule):

RecCo says shareRule

sign(Alice, ...) sign(RecCo, ...)

(44)

Auditing access control

(45)

When something unexpected happens: look at the log.

System design guarantees a one-to-one correspondence between log entries and resource state changes.

If a A’s signature does not appear in a log entry, she could not have caused the associated action.

Problem: Malicious principals can try to hinder audit with confusing proofs and irrelevant signatures.

(46)

Sample proofs, clear and convoluted.

Assume we have signaturessign(A, P) and sign(B, Q).

Example (A convoluted proof of Asays P) ..

.

Asays P → B says Q → A says P Asays P

Bsays Q → A says P Bsays Q

Asays P

Proposition Bsays Q is logically irrelevant.

Example (A clear proof of Asays P)

Asays P (By signature.)

(47)

Sample proofs, clear and convoluted.

Assume we have signaturessign(A, P) and sign(B, Q).

Example (A convoluted proof of Asays P) ..

.

Asays P → B says Q → A says P Asays P

Bsays Q → A says P Bsays Q

Asays P

Proposition Bsays Q is logically irrelevant.

Example (A clear proof of Asays P)

(48)

Proof reduction eliminates irrelevant information.

Proof reduction schemes transform complicated proofs to simple ones. [Gentzen 35]

Reduction can easily be stated by writing proofs in lambda-calculus notation. [Curry 58], [Howard 80]

Example

(λ x .λ y .y ) (sign(A, P)) (sign(B, Q)) convoluted −→∗

sign(A, P) clear

(49)

Proof reduction is a total, deterministic algorithm.

AURA₀is a model of AURAproofs and propositions.

Theorem (Confluence for AURA₀)

If p −→∗p1, and p −→∗p2, then there exists p3such that p1−→∗p3and p2−→∗p3.

That is, different reduction strategies can always reconverge.

Theorem (Strong Normalization for AURA0)

If Γ `0p : s, then p is strongly normalizing.

(50)

Auditing and confidentiality

(51)

A

URAconf

extends A

URA

for handling confidential data.

The “real-world” contains lots of confidential information. Financial, medical, social data . . .

Data leaks have consequences: legal, financial. . . . Goals of AURA_conf

✘

1000101 1000101 1111111 1111111 1111111

(66)

A

URAconf

will assign blame using evidence.

Ciphertexts can be represented as bit strings

Bit Strings B ::= 0 | 1 | 00 | 01 | 10 | . . . Justified cast: Assign types to bit strings using evidence.

p :pf B says (B isa t for A) hBip:t for A

Key Idea

Principal A, can check if B decrypts properly, yielding a t.

If not, she assigns blame to B using proof p.

(67)

Decryption failures are audited using justified casts.

Evidence: mentions Mal Action: blame Mal Evidence: ill-formed Action: ignore message

Evidence: mentions Alice

(68)

Decryption failures are audited using justified casts.

Action: blame Alice _1111111

(69)

Decryption failures are audited using justified casts.

(70)

Decryption failures are audited using justified casts.

(71)

Decryption failures are audited using justified casts.

(72)

Decryption failures are audited using justified casts.

(73)

Auditing crypto. failures improves reliability & security.

Understanding decryption failures can help answer the following questions.

Is a host or a network error the source of invalid ciphertexts?

Which host is sending bad data?

Are hosts endorsing ciphertexts against policy? Where was Bisa t signed?

(74)

Conclusion

(75)

Questions and half-baked ideas.

We still don’t know how administrators should best query and monitor AURAlogs. Has this been addressed in the setting of provenance metadata?

Provenance polynomials/semirings share some basic structure with information flow labels. How are these things related?

Key/signature revocation are tricky in AURA’s setting. Can

we treat revocation by associating keys (signatures) with provenance metadata?

There is a tension between preserving privacy of encrypted data and maintaining a full account of its provenance. How can this be resolved?

(76)

Questions and half-baked ideas.

(77)

Questions and half-baked ideas.

(78)

Questions and half-baked ideas.

(79)

Questions and half-baked ideas.

(80)

Conclusion

AURAproofs describe how why and how events occur.

Provenance describes why and how results are included in a query.

I’m looking forward to learning from everyone here!

Interpreter, Coq scripts, and papers available from http://www.cis.upenn.edu/~stevez/sol/aura.html

(81)

Acknowledgments

Thank you to all my collaborators on this work! Limin Jia Karl Mazurak Joseph Schorr Luke Zarko Steve Zdancewic Jianzhou Zhao

(82)

Access control and audit replace trust with scrutiny.

(83)

Access control and audit replace trust with scrutiny.

(84)

Access control and audit replace trust with scrutiny.

Resource

sign(ICFP,shareRule): ICFP says shareRule

sign(Alice, ...) sign(ICFP, ...)

sign(Alice, ...) sign(ICFP, ...) Proof Evidence Log Kernel Code

(85)

Access control and audit replace trust with scrutiny.

Resource

sign(Alice, ...) sign(ICFP, ...) Proof Evidence Log Kernel Code Typed Interface Typed Interface

(86)

Access control and audit replace trust with scrutiny.

Trusted Computing Base

Resource

(87)

Access control and audit replace trust with scrutiny.

Custom Code and Policy _Resource

(88)

Access control and audit replace trust with scrutiny.

(89)

Access control and audit replace trust with scrutiny.

Custom & Trusted _Resource

(90)

Access control and audit replace trust with scrutiny.

Custom & Trusted _Resource

(91)

Strong normalization proof sketch

Fact

The Calculus of Constructions with dependent pairs is SN.

[Geuvers 95]

Proof Idea

Show AURA₀reductions can be simulated in a terminating system based on Constructions.

p0 // [[·]] p1 // [[·]] p2 // [[·]] · · · t0 _cc// t1 _cc// t10 _cc// t2 _cc// · · ·