TRUST Area 3 Overview: Privacy, Usability, & Social Impact Doug Tygar UC Berkeley NSF STC Review September 13th 2004

Security can not be understood in isolation TRUST Security can not be understood in isolation Computer security arises from human needs for information If we view it purely as a mathematical science, we miss important aspects of the problem Example: Problems using e-mail encryption Why Johnny Can’t Encrypt Our project fully incorporates these aspects: Economics, Public Policy and Societal Challenges Digital Forensics and Privacy Human Computer Interfaces and Security We integrate these issues in all aspects of our study 2 NSF STC Review September 13th 2004

Economics, Public Policy & Societal Challenges TRUST Economics, Public Policy & Societal Challenges Team members: : McFadden, Samuelson, Varian, Weber Insurance is often a way of enforcing desirable norms: e.g., business fire insurance require fire safety measures Requirement: party with control bears liability. Example: ATM machines in UK and US Economic analysis changes Attacks can be deliberate and not simply accidents Weakest link model Transaction costs associated with security 3 NSF STC Review September 13th 2004

Human Computer Interfaces & Security TRUST Human Computer Interfaces & Security Team members: Garcia-Molina, Perrig, Reiter, Song, Tygar Most common source of security problems (by far): People can’t figure out how to configure the software Problems System complexity Software complexity People have trouble generating random values (passwords) People have trouble remembering long strings Low tolerance for noticing small changes in repetitive tasks 4 NSF STC Review September 13th 2004

Digital Forensics & Privacy TRUST Digital Forensics & Privacy Team members: Birman, Boneh, Mitchell, Reiter, Samuelson, Tygar, Weber Example challenge problems: Privacy-preserving data mining (law enforcement) Peer-to-peer privacy and security Privacy in sensor networks Identity theft Mechanisms: Strong audit Selective revelation of information Rule processing technologies The next few slides explore this area more deeply 5 NSF STC Review September 13th 2004

Strategy: Selective revelation TRUST Strategy: Selective revelation Architecture based on selective revelation Goal: minimize revelation of personal data while supporting analysis Approach: partial, incremental revelation of personal data Procedure: Initial revelation by statistics & categories Subsequent revelation as justified by earlier results Supports both “standing” & real-time queries 6 NSF STC Review September 13th 2004

Idealized architecture TRUST Idealized architecture Initial revelation of sanitized data ! Discovery via standing queries or real-time search Privacy/ Security Barrier Core Idea: (1) Analyze data behind security barrier; find critical relationships (2) Reveal relationships selectively only through guarded interface 7 Data Repositories NSF STC Review September 13th 2004

Distributed architecture TRUST Distributed architecture Multiple repositories  Multiple privacy/security barriers ! 8 NSF STC Review September 13th 2004

Audit TRUST 9 Protect against abuse by “watching the watchers” Design goals: Distributed audit Everyone subject to audit Cross-organizational audit Measure accuracy of auditors by cross-validation Usage records are tamper-evident Hall of Mirrors: Audit also has a privacy problem Data sets are voluminous Usage records are sensitive 9 NSF STC Review September 13th 2004

Example technology: encrypted search TRUST Queries are sent encrypted Queries are processed but not decrypted by repository Repository prepares response but does not know what search was or whether it was successful. Work by Song (CMU), Perrig (CMU), Wagner (Berkeley) Example technology: encrypted search encrypted queries Repository of private data Analyst encrypted response  Limited trust between parties  10 NSF STC Review September 13th 2004

Labeling derived data TRUST Example: derived restrictions [R2] [R1] Conservative approach: output inherits all restrictions of inputs Often too restrictive Sometimes too liberal Hard problem Seek semi-automated solution to minimize human overhead Build on recent work on program semantics Example: derived restrictions [R2] [R1] [R3] 11 [?] NSF STC Review September 13th 2004

Privacy rules TRUST 12 Need language for expressing rules Related technology: Digital Rights Management Translate English  agent based language Rules differ based on data Types of data (3rd party or self-generated, video vs. textual) Contents of data Need tools for compliance checking Both automated and human in the loop 12 NSF STC Review September 13th 2004