1 / 21

Privacy is Linking Permission to Purpose

This presentation explores the importance of linking permission to purpose in maintaining privacy on the web. It discusses regulatory solutions, technological solutions, and real-life examples to highlight the challenges and solutions in protecting private information.

othaa
Télécharger la présentation

Privacy is Linking Permission to Purpose

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Privacy is Linking Permission to Purpose F.Massacci N. Zannone Presented by Fabio Massacci (DIT - University of Trento - www.dit.unitn.it) (Create-NET - www.create-net.it)

  2. Privacy On the Web • Regulatory solutions • Mandatory - HIPAA • Third Party Certified - TRUSTe • Client-based technological solutions • Anonymizers • Remailers • Server-based technological solutions • VPNs/Firewalls • Client-Server-based technological solutions • P3P • EPAL (a classification borrowed from IEEE Security & Privacy Magazine)

  3. Observation 1 • If private information is not really relevant to the service… • No Need of Crypto! • Just create your own fake identity • My Identity • Babbo Natale (Santa Claus) • Born in Fortezza BZ (Italy) on 25/12/1900 (or 1901 if 1900 not accepted), • Resident in Fortezza (BZ), via della Stazione 5, • Phone 0472-458772, Fax: 39045, • Email: sono_babbo_natale@libero.it • Social Security Number/Tax Code: NTLBBB00T25D731U (or V)

  4. Observation 2 • If private info really relevant for the service • Eg delivery some goods at your house • No crypto can help… • Server must see the plaintext • And once they have it, they have it… • Credentials don’t help that much either • Issuer gives credential that somebody has a property • Just shift faith from server to credential issuer • Possibly worse because you are likely to have less issuers than servers (so concentrating data)

  5. Real life • Delegation of permissions can never be as fine grained as you would need them • Cleaning lady has the key to open the room • She can empty the wastebin or look at papers on the desk. • Real life contracts or data submissions have purpose tagged to permissions • Special power of attorney for contracts • Privacy statement according EU or Italian Legislation (Our starting point defining policy for Genetic Data for local health authority) • You got that (permission, data, thing) to do that • If you breach trust (use for other purposes) then you can be sued

  6. Alias Privacy=‘ln -s Purpose Permission’ • Fact of Life • We want something done • We give private information (or access to it) to get it done • If private information is used for the purpose we have given it • Happy user • If private information can be used for other purposes • Consent must be sought (eg according Law) • Unhappy or unwilling users

  7. Privacy & Purpose II • All interesting proposals add purpose • Hyppocratic Databases • EPAL • P3P • Allow to specify other purposes and other recipients of private info • Marketing, • Analysis etc. • Also specify what data is added

  8. Exercise 1: Spot the Purpose in P3P <POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY name="forBrowsers” discuri=”someUrl.html” xml:lang="en"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogExample</DATA> </DATA-GROUP> </ENTITY> <ACCESS><nonident/></ACCESS> <DISPUTES-GROUP> <DISPUTES resolution-type="independent” service="http://www.PrivacySeal.example.org" <REMEDIES><correct/></REMEDIES> </DISPUTES> </DISPUTES-GROUP> <STATEMENT> <PURPOSE><admin/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.clickstream"/> <DATA ref="#dynamic.http"/> </DATA-GROUP> </STATEMENT> </POLICY>

  9. Solution (??) • Thick appropriate Box • Web site basic.example.com uses a variety of images, all of which it hosts. It also includes some forms, which are all submitted directly to the site. • Web site busy.example.com uses a content distribution network called cdn.example.com to host its images so as to reduce the load on its servers. • Web site busy.example.com also has a contract with an advertising company called clickads.example.com to provide banner ads on its site. • Web site busy.example.com also has a contract with funchat.example.com to host a chat room for its users. When users enter the chat room they are actually leaving the Busy site. However, the chat room has the Busy logo and is actually covered by the Busy privacy policy. • Web site bigsearch.example.com also has a form that allows users to type in a search query and have it simultaneously performed on ten different search engines. Bigsearch submits the queries, gets back the results from each search engine, removes the duplicates, and presents the results to the user. • Web site bigsearch.example.com also has banner advertisements provided by a company called adnetwork.example.com. Adnetwork uses cookies to develop profiles of users across many different Web sites so that it can provide them with ads better suited to their interests. Because the data about the sites that users are visiting is being used for purposes other than just serving ads on the Bigsearch Web site, Adnetwork cannot be considered an agent in this context. Adnetwork must create its own P3P policy and use its own policy reference file to indicate what content it applies to. • Answer: you have no clue

  10. Requirements Eng. Security & Privacy • Where’s purpose? • Focus on “modelling and implementing” privacy statements for other services • Privacy Declaration and Authorizations derives from (implicit) (dis)trust relationships for some functional goals different from the original goal the data has been collected for • Modelling Trust/Privacy/Functional Model together • In Model-based Development Architecture appropriate privacy declarations and authorizations should be automatically derived from original purpose • All we need is Functional/Trust/Ownership relations

  11. Exercise 2: Spot Purpose in Hipp. DB • Hippocratic Privacy Policy Table • That’s better… • Yet not linked to design: ex-post addition

  12. Idea… • Specify (Functional) Requirements from the User Perspective • Users have certains goals and delegate some of them to the system • Explicit purpose when delegating goals to system • Essentially data submission is a credential mentioning not only the information/permission but also the goal for which the permission can be used • You can even make chain of credentials • Each with a refinement of purpose • You have the data, but can you show the police a valid chain?

  13. Requirements Engineering Methodology • Agent-Oriented RE Methodology - Tropos • Agents, Roles • Goals, Tasks, Resources • Dependency among agents (A depends on B on G, if A wants G to be done and B agrees to look after that) • Goal Decomposition (AND/OR, positive, negative contribution) • Easy to Understand by Users for Early RE • Good for Modelling Organizations • Formal Reasoning Tools Available

  14. Security-Aware RE Methodology • Add-ons • Distinction between wanting/offering/owning a goal • Trust relationship on Agent/goals/Agents • Some agents want some goal/task to be done • Hospital doctor wants to consult medical record • Other agents offer this goal/task • Nephrology ward locker stores medical records • Another agent owns this goal/task • Patient owns the medical record • Agents trust other agents on the goal • Patient trust Hospital to store medical record

  15. Trust Obtain Medical Treatment Hospital Dep Dep Dep Dep Dep Dep Trust Trust Obtain Medical Treatment Analys Pers. Data Owns Dep Dep Patient Dep Dep Dep Dep Trust Clinician Security-Aware Tropos - Informal II • Use Diagram to communicate requirements • Nice drawing with ovals and arrows • Model Dependency and Trust Relationships Hosp Deleg Clinician And now derive permissions automatically

  16. Security-Aware Tropos - Informal III

  17. Security-Aware Tropos - Informal IV • Beware: NOT all “permissions” and “auth. processes” are mapped onto digital certificates • Remember • Fabio’s “Real-Life Dominance Rule” • Some “credentials” will be papers signed by an individual • Others corresponds to oral or physical permissions • Examples • Permission to use donor’s placenta genetic data for research and “self” usage (collected on the day of childbirth…) • Parents’ or Guardian approval for blood samples to be used in case of unexpected outcome in “wet” surgery • University visiting professor’s request for temp. IP address

  18. Security-Aware RE Methodology • Design Functional Dependency Model • Design Trust/Ownership Model • Refinements by • Goal Decomposition • Goal (Functional) Delegation to other agents • Modify Trust Relationship • Design/Synth Trust Management Implementation • Goal (Permission) Delegation to other agents MENTION functional goal • (Computer Supported) Analysis • Goal Fulfillment (Functional Delegation Chain) • Trusted Execution (Trust Chain Match Funct. Deleg. Chain) • Trusted Delegation (Trust Chain Match Permis. Deleg. Chain) • Privacy Protection (Permis. Deleg. Chain match Funct. Deleg Chain)

  19. Security-Aware Tropos - Formal Model • Semi-formal Analysis • Annotate diagrams with formulae • Partial checks at type level • Eliminate already many errors in the chains • Formal Analysis • Full model at instance level • Define instances of agents and goals • instantiate delegation in many ways • Finite State Model checking and (to be done) infinite state analysis • Allows Discovery of subtler relationships between parties • Patient trusts “her” clinician, and hospital • Analys relationships with third parties • Delegation of permissions can create unexpected breach of trust • “natural & simple” permission chain may not match “natural” trust chain

  20. Implementation • Submission of data to server is delegation cert • Data • Purpose • Need common language to define purpose • Semantic web… • Needed PKI from servers. • Server needs to sign acknolwedgement of data & policy • But they already have it (if they have HTTPS…) • Is a PKI needed from the client? • Maybe a MAC with a secret value is enough • Maybe a full signature is needed

  21. SIC LECTIO FINITA EST • Questions? • Suggestions? • Comments? • Dead cats? • …

More Related