A logic for reasoning about digital rights Riccardo Pucella, Vicky Weissman Cornell University.

Slides:



Advertisements
Similar presentations
1 Reasoning with Promela Safety properties bad things do not happen can check by inspecting finite behaviours Liveness properties good things do eventually.
Advertisements

Completeness and Expressiveness
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
Computer Science CPSC 322 Lecture 25 Top Down Proof Procedure (Ch 5.2.2)
Comparative Succinctness of KR Formalisms Paolo Liberatore.
Artificial Intelligence Chapter 13 The Propositional Calculus Biointelligence Lab School of Computer Sci. & Eng. Seoul National University.
Techniques for Proving the Completeness of a Proof System Hongseok Yang Seoul National University Cristiano Calcagno Imperial College.
M ODEL CHECKING -Vasvi Kakkad University of Sydney.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Current Techniques in Language-based Security David Walker COS 597B With slides stolen from: Steve Zdancewic University of Pennsylvania.
Temporal Logic and the NuSMV Model Checker CS 680 Formal Methods Jeremy Johnson.
CS6133 Software Specification and Verification
Agents That Reason Logically Copyright, 1996 © Dale Carnegie & Associates, Inc. Chapter 7 Spring 2004.
Nir Piterman Department of Computer Science TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAAA Bypassing Complexity.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Run Time Monitoring of Reactive System Models Mikhail Auguston Naval Postgraduate School Mark Trakhtenbrot Holon Academic Institute of.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
SECTION 3.2 RATIONAL FUNCTIONS RATIONAL FUNCTIONS.
1 Temporal Logic u Classical logic:  Good for describing static conditions u Temporal logic:  Adds temporal operators  Describe how static conditions.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
1 Introduction to Computability Theory Lecture13: Mapping Reductions Prof. Amos Israeli.
A Formal Foundation for XrML Vicky Weissman Joint work with Joe Halpern.
CSE 555 Protocol Engineering Dr. Mohammed H. Sqalli Computer Engineering Department King Fahd University of Petroleum & Minerals Credits: Dr. Abdul Waheed.
A Formal Foundation for XrML Vicky Weissman Joint work with: Joseph Halpern.
Extensible Semantics for XrML Vicky Weissman Joint work with Joe Halpern.
Correctness. Until now We’ve seen how to define dataflow analyses How do we know our analyses are correct? We could reason about each individual analysis.
A Formal Foundation for ODRL What’s ODRL?  An XML-based language for writing software licenses. Language specification includes:  syntax  English interpretation.
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Rights management Vicky Weissman
Automata and Formal Lanugages Büchi Automata and Model Checking Ralf Möller based on slides by Chang-Beom Choi Provable Software Lab, KAIST.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
Derivative of the logarithmic function
Procedure specifications CSE 331. Outline Satisfying a specification; substitutability Stronger and weaker specifications - Comparing by hand - Comparing.
CSE Winter 2008 Introduction to Program Verification January 29 how wang works.
Introduction Algorithms and Conventions The design and analysis of algorithms is the core subject matter of Computer Science. Given a problem, we want.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: Sequencing Properties Copyright , Matt Dwyer, John Hatcliff,
On Reducing the Global State Graph for Verification of Distributed Computations Vijay K. Garg, Arindam Chakraborty Parallel and Distributed Systems Laboratory.
CIS 842: Specification and Verification of Reactive Systems Lecture Specifications: LTL Model Checking Copyright , Matt Dwyer, John Hatcliff,
Pattern-directed inference systems
Slide 1 Propositional Definite Clause Logic: Syntax, Semantics and Bottom-up Proofs Jim Little UBC CS 322 – CSP October 20, 2014.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Course Overview and Road Map Computability and Logic.
LDK R Logics for Data and Knowledge Representation Modal Logic Originally by Alessandro Agostini and Fausto Giunchiglia Modified by Fausto Giunchiglia,
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 05/06 Universität Dortmund Validation - Formal verification -
Lecture 5 1 CSP tools for verification of Sec Prot Overview of the lecture The Casper interface Refinement checking and FDR Model checking Theorem proving.
From Hoare Logic to Matching Logic Reachability Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Copyright 2001, Matt Dwyer, John Hatcliff, and Radu Iosif. The syllabus and all lectures for this course are copyrighted materials and may not be used.
This Week Lecture on relational semantics Exercises on logic and relations Labs on using Isabelle to do proofs.
1 CSEP590 – Model Checking and Automated Verification Lecture outline for July 9, 2003.
1 Temporal logic. 2 Prop. logic: model and reason about static situations. Example: Are there truth values that can be assigned to x,y simultaneously.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Bounded Model Checking A. Biere, A. Cimatti, E. Clarke, Y. Zhu, Symbolic Model Checking without BDDs, TACAS’99 Presented by Daniel Choi Provable Software.
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
1 Lecture 3 The Languages of K, T, B and S4. 2 Last time we extended the language PC to the language S5 by adding two new symbols ‘□’ (for ‘It is necessary.
Today’s Agenda  Quiz 4  Temporal Logic Formal Methods in Software Engineering1.
Logics for Data and Knowledge Representation ClassL (part 1): syntax and semantics.
Towards a Semantic Model for Java Wildcards Sophia Drossopoulou Mariangiola Dezani-Ciancaglini Imperial College London Università di Torino Italy Nicholas.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Criticisms of the Cosmological argument Hume, Mackie and Anscombe.
Complexity of Compositional Model Checking of Computation Tree Logic on Simple Structures Krishnendu Chatterjee Pallab Dasgupta P.P. Chakrabarti IWDC 2004,
Logics for Data and Knowledge Representation
Formal Methods in software development
Why this Paper isn’t useful ?
Finite-Trace Linear Temporal Logic: Coinductive Completeness
Translating Linear Temporal Logic into Büchi Automata
Formal Methods in software development
Programming Languages and Compilers (CS 421)
Presentation transcript:

A logic for reasoning about digital rights Riccardo Pucella, Vicky Weissman Cornell University

2 Licenses A license states the exact conditions under which a resource may be used. Examples: The client must sign a waiver before downloading beta-version software. The client must sign a lease and either pay $490 on the first day or $500 on the second day of each month to live in an apartment.

3 Reasoning about licenses- Properties Examples of properties include: `A religious work may never be viewed after sunset.’ `If a client uses a resource, then the client is obligated to pay for the use at some time.’ Depending on the licenses, a property may or may not be easy to check. Does a property hold for a given set of licenses, regardless of the client’s actions?

4 Reasoning about licenses- Specifications Examples of specifications include: The client never uses a resource illegally. The client is never obligated to pay interest on any debts. Specifications may or may not be easy to check, depending on the given info. Does a property hold for a given set of licenses and client behavior?

5 Our goal To design a logic that we can use to: 1. easily state interesting properties and specifications; 2. prove that a property holds (or a specification is met) for a given license set (and client behavior).

6 Logic features The logic needs to talk about: licenses, client behavior wrt a license, time – temporal operators, permission and obligation.

7 Licenses Follow lead from Gunter, Weeks, Wright ‘Models and languages for digital rights’, Licenses are sets of traces. Each trace describes an action sequence that the client could do to fulfill the license. Can write licenses in various languages. We’ll use regular expressions. l ::= a | l 1 l 2 | l * | l 1 U l 2 where a is an action.

8 Licenses Follow lead from Gunter, Weeks, Wright ‘Models and languages for digital rights’, Licenses are sets of traces. Each trace describes an action sequence that the client could do to fulfill the license. Can write licenses in various languages. We’ll use regular expressions. l ::= a | l 1 l 2 | l * | l 1 U l 2 where a is an action.

9 Licenses Follow lead from Gunter, Weeks, Wright ‘Models and languages for digital rights’, Licenses are sets of traces. Each trace describes an action sequence that the client could do to fulfill the license. Can write licenses in various languages. We’ll use regular expressions. l ::= a | l 1 l 2 | l * | l 1 U l 2 where a is an action.

10 Lease Example Recall the lease example: The client must sign a lease and either pay $490 on the first day or $500 on the second day of each month to live in an apartment. sign lease  pay $500  t o sign lease t 1 pay $490 … t 30  t 2 nothing (  )  t3t3 Viewed as a set of traces:

11 Encoding action sequences License: sign lease  pay $500  t o sign lease t 1 pay $490 … t 30  t 2 nothing (  )  t3t3 Traces: l 1 = pay $490  …  l 2 =  pay $500  …  l = sign lease ( l 1 U l 2 ) *

12 What a client can do (a,n) | Client can do any action  of the form:  ::= do action a wrt license named n do not do action a wrt license n E.g. The client does not pay $490 for the lease is written: (pay $490, lease).

13 Writing properties and specs.  P(  ) n: l A formula f has the form: f ::= |||||| client does action expression  client permitted to do  license l with name n is issued  f | f | f 1 U f 2 next time, always, until f 1  f 2 |  f

14 Obligation Can capture obligation using permission. A client is obligated to do (a, n), if she isn’t permitted to do any other action, including the do-nothing action , wrt license n. The client is obligated to do (a, n) if P(a, n)   P(a, n) holds. In our logic, client is always permitted to do something, possibly , wrt each license. So, P(a, n)   P(a, n) =  P(a, n)

15 Obligation Can capture obligation using permission. A client is obligated to do (a, n), if she isn’t permitted to do any other action, including the do-nothing action , wrt license n. The client is obligated to do (a, n) if P(a, n)   P(a, n) holds. In our logic, client is always permitted to do something, possibly , wrt each license. So, P(a, n)   P(a, n) =  P(a, n)

16 Obligation Can capture obligation using permission. A client is obligated to do (a, n), if she isn’t permitted to do any other action, including the do-nothing action , wrt license n. The client is obligated to do (a, n) if P(a, n)   P(a, n) holds. In our logic, client is always permitted to do something, possibly , wrt each license. So, P(a, n)   P(a, n) =  P(a, n)

17 Obligation Can capture obligation using permission. A client is obligated to do (a, n), if she isn’t permitted to do any other action, including the do-nothing action , wrt license n. The client is obligated to do (a, n) if P(a, n)   P(a, n) holds. In our logic, client is always permitted to do something, possibly , wrt each license. So, P(a, n)   P(a, n) =  P(a, n)

18 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

19 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

20 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

21 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

22 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

23 Examples Property: When the lease is issued, the client must sign it. lease: l  =>  P((sign, lease)) Spec.: The client doesn’t violate the lease. This means that once the lease is issued, the client meets all obligations and only does what’s permitted. For all actions a: lease: l  => [(  P((a, lease)) => (a, lease))  ((a, lease) => P((a, lease)))] l = sign (pay $490  …  U  pay $500  …  ) *

24 Semantics Idea from Halpern and Meyden ‘A logic for SDSI’s linked local name spaces’, We have: a run r that says what happens at any time t. Specifically, r(t) = (L, A) where L are the licenses issued and A are the client’s actions done at time t. a permission interpretation P r (t) says what’s allowed at time t, based on the run r.

25 Example Suppose that at time t in run r the following lease is issued: l = sign (pay $490  …  U  pay $500  …  ) *, the client signs the lease, and the client ignores the credit card. In this case r(t) = (( {lease: l }, {(sign, lease), ( , cc)}) and P r (t) = {(sign, lease)…}.

26 Truth conditions Let r(t) = (L, A) r, t |= (a, n) iff  (a, n)  A r, t |= (a, n) iff  b  a such that (b, n)  A r, t |= P((a, n)) iff (a, n)  P r (t) r, t |= P((a, n)) iff  b  a such that (b, n)  P r (t) r, t |= n: l iff (n: l )  L  f, f, f 1 U f 2, f 1  f 2,  f have standard meanings.

27 How hard is reasoning? We reduce satisfiability for our logic to that for Linear Temporal Logic (LTL). Difference between logics: Our logic has n: l, , and P(  ) LTL has a set of primitives. Easy to encode our `extras’ as primitives. E.g. lease: l becomes the primitive issued(lease, l )’. Also, easy to convert the runs. But this isn’t quite enough….

28 Encoding implied facts No name refers to more than one license. All the permissions and obligations implied by an issued license. The encoding is given in the paper. Our logic has implicit notions that must be made explicit in LTL. These include:

29 Complexity Given our translation to LTL, we can use well-known results for LTL to show that: Validity checking in our logic is PSPACE- complete. Determining if a formula  holds at a particular time t in a given run r takes polynomial time wrt the size of r(t) and exponential time wrt the size of .

30 Conclusions and future work We have introduced a formal framework for reasoning about licenses. Small specifications can be analyzed efficiently. Framework can be modified easily to handle different license languages that have trace- based semantics. Where do we go from here? Use framework to compare different license languages. Compare our framework to other approaches that talk about permissions. Provide an axiomatization for our logic.