The Importance of Accountability and Enforceability of Enterprise Privacy Languages

1
The Importance of Accountability and
Enforceability of Enterprise Privacy Languages

• Dr Siani Pearson
• Trusted Systems Laboratory
• HP Labs, Bristol, UK
• 19th June 2003

2
Contents

• Why is technological enforcement important?
• How does this affect privacy policy languages?
• What type of enforcement and accountability
  mechanisms can be used?
• Can we define richer privacy policies
• to help protect info?
• How can the sender of data be
• assured that its handling will be
• according to policy?

3
Why have technological enforcement?
4
Benefits of enforceability

• Languages should be enforceable
• Need to keep policy associated with data
• Server could lie about privacy policy
• Do natural language policies correspond to how
  the system behaves?
• Social pressure only goes so far
• Legal agreements arent always enough
• Very sensitive information
• New business scenarios e.g. mobile
• Flexible, dynamic, new business partners
• Infringements can go unnoticed
• Underdog difficult/slow to pursue through courts
• Privacy laws can encourage and even require PET

5
Further benefits

• Enables citizens and consumers to participate
  confidently in digital economy
• 34 of users who dont buy online would do so
  with better privacy
• Basis for trust privacy cert.
• Best practice, data protection conformance with
  corporate privacy policy/privacy laws
• Can prevent accidental/deliberate infringements
  of privacy policies

6
Implications for privacy policy language
7
Implications for the policy language

• More expressive language, beyond normal access
  controls, e.g.
• if/how data can be
• forwarded
• displayed on another machines screen
• properties the receiving machine should have
• e.g. certain level of trustworthiness of
• design (can it enforce policies?)
• software state config (will it?)
• execution environment
• protection of stored data

8
Example One

• data can only be displayed on a given device
  used by a given user if it is either not
  sensitive or else the device is trusted and the
  environment has a trust rating of at least 3 and
  the user fulfils the role of a customer relations
  member 
• can_do(display(Data, Current_device, User))-
• is_sensitive(Data) v (trusted_platform(Current_d
  evice)
• env_trust_level(3) role(User,
  customer_relations))

9
Example Two

• Complexity, competences, security gt enforcement
  of high level privacy languages at different
  levels
• ltsticky policygt // privacy policy
  
  
• ltattributegt // name of the attribute
• Data
• lt/attributegt
• ltownergt
• ltreference namegt pseudonym1 lt/reference namegt
  //reference name encryption key
• ltowners detailsgt //encrypted
  owners call back address
• encrypted call back address
• ltowners detailsgt
  
  
  
• lt/ownergt
  
• ltvaliditygt
  
  
• expiration date
• lt/validitygt
• ltactiongt
  
  
• notify_owner_before_disclosure
• lt/actiongt
• ltconstraintgt // constraint that can be
  easily checked by TTP
  
  

10
Implications for the policy language (2)

• The exact constructs to be included depends upon
  what people want to express to protect their data
  
• corporate, consumer, community, citizen,
• Allows varying levels of trust that the system
  will respect privacy policies associated with
  data
• Option to negotiate partial disclosure of info
• Technology can help certify reliability of
• such info e.g. generalisation, ranges,
• selective/anonymised disclosure

11
Progression

• STAGE 1 Policies expressed in natural language
  reliance on law for enforcement
• STAGE 2 (P3P now) machine support for warning
  users where their privacy requirements conflict
  with a web sites policy automated negotiation
• STAGE 3() range of choices offered to users,
  inc.
• sensitive data sent only if given degree of
  trust, enforcement and accountability in
  receivers system
• data modified to minimise privacy risks sent
• no data sent / negotation of benefits if data
  sent anyway

12
Enforceability mechanisms
13
Enforcement of privacy policies

• Via trusted hardware component extended OS
• Strongly associate privacy policies to
  confidential data gt block attempts to remove
  policy
• Policy enforcement across multiple apps and
  enterprise boundaries
• Create end-to-end privacy policy enforcement
  framework that cannot be easily circumvented

14
Building blocks towards privacy

• Trusted platforms provide
• Protection for users secrets
• Can prevent the revelation of secrets unless the
  software state is in an approved state
• Potential for remote trust
• while avoiding users loss of choice and control

15
Use of trusted platforms

• Trusted platforms provide building blocks for
  privacy
• without dictating architecture of resulting
  systems
• designed in full support of data protection
  legislation
• Enable a user to have more confidence in the
  behaviour of the platform in front of them (or
  remote)
• trust a platform to handle private data
• whether privacy mechanisms work
• Doesnt provide a complete privacy solution
• legislation e.g. re. treatment of personal
  information given when applying for credentials
• other mechanisms e.g. identity management

16
Enforceability via data tagging
Data comes with tags
Data owners policy and privacy policies enforced
by OS irrespective of application behaviour
Tags follow data across the network
Tags follow data through multiple applications
Policies specify what controls to apply e.g. HP
Confidential shouldnt leave the company
unencrypted
Policies applied to tagged data
Works on all applications
Transparent and automatic application of policies
17
Accountable identity management

• Ensure that all entities that access confidential
  data are accountable
• In certain contexts a user is given extra
  confidence that their data will be used in
  accordance with their policy
• In other contexts this may not be possible
  better audit trail if user still wants to reveal
  data
• Models with or without IBE
• Tampering with policies prevents access to data
• Policy compliance can be checked by TTPs

18
Accountable management of identities/data

Tracing, Fraud Detection, Forensic Analysis
19
Mobility a special case
20
Using someone elses infrastructure
21
Conclusions

• Policy languages should allow specification of
  the use of trust and security techniques
• In certain cases there is a need for such privacy
  languages to be enforced (end-to-end)
• Another important aspect is management of
  accountability across enterprises wrt policy
  enforcement
• Technology exists to address these problems
• at different levels
• simple, integrated tools for users and
  administrators are needed

22
(No Transcript)
23
Enforceability via trusted computing
Can I trust you to behave in an expected manner?
Can I trust you to protect my data
Do I have confidence in interacting with this
platform?
Can I trust you to be what you say you are?
24
Privacy-positive design

• Owner control
• Ultimate TPM functionality control goes to the
  Owner
• TPM activation controlled by the Owner, and
  deactivation available to the user
• Owner chooses Privacy-CAs involved in issuing IDs
• Pseudonymity
• No single TPM identity is ever
• used across transactions
• Multiple pseudonymous IDs
• (limits correlation)

25
Fear, uncertainty and doubt

• All software that can execute on a trusted
  platform would have to be certified by some
  agency (Not true)
• Unapproved software cant execute on a trusted
  platform (Not true)
• The technology cant be completely disabled (Not
  true)
• Open-source software cant work on trusted
  platforms (Not true)
• Trusted platforms are designed to reinforce
  existing monopolies (Not true)
• Trusted platforms are designed for Digital Rights
  Management (Not true)