Supporting User Privacy Preferences on Information Release in Open Scenarios Claudio A. Ardagna 1 Sabrina De Capitani di Vimercati 1 Sara Foresti 1 Stefano Paraboschi 2 Pierangela Samarati 1 (1) DTI - Università degli Studi di Milano (2) DIIMM - Università degli Studi di Bergamo W3C Workshop on Privacy and Data Usage Control October 5, 2010 – Cambridge, MA, USA c Pierangela Samarati 1/20 Starting scenario (1) • Open scenarios where clients interact with remote parties and access remote resources • Depart from the assumption that clients are authenticated before evaluating access requests • The policy at the server refers to credentials/properties that the client must have (in contrast to client’s identity) = ⇒ Attribute-based/credential-based access control c Pierangela Samarati 2/20
18
Embed
Release in Open Scenar ios Suppor ting User Pr ivacy Pref ... · Suppor ting User Pr ivacy Pref erences on Inf or mation Release in Open Scenar ios Claudio A. Ardagna 1 Sabr ina De
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Supporting User Privacy Preferences on InformationRelease in Open Scenarios
Claudio A. Ardagna1 Sabrina De Capitani di Vimercati1
Sara Foresti1 Stefano Paraboschi2 Pierangela Samarati1
(1) DTI - Università degli Studi di Milano
(2) DIIMM - Università degli Studi di Bergamo
W3C Workshop on Privacy and Data Usage ControlOctober 5, 2010 – Cambridge, MA, USA
c!Pierangela Samarati 1/20
Starting scenario (1)
• Open scenarios where clients interact with remote parties andaccess remote resources
• Depart from the assumption that clients are authenticated beforeevaluating access requests
• The policy at the server refers to credentials/properties that theclient must have (in contrast to client’s identity)
=⇒ Attribute-based/credential-based access control
c!Pierangela Samarati 2/20
Starting scenario (2)
• Attribute-based access control requires re-thinking how accesscontrol process works
• Most proposals focus on the server side aspect of the problem
◦ regulate how the server specifies policies
◦ provide partial evaluation of the policy
◦ define how to communicate policies to the client
◦ they assume to adopt a symmetric approach at the client
c!Pierangela Samarati 3/20
Motivation
Access-control based specifications do not fit well the problem at theclient side
+ they allow users to specify whether some information can be orcannot be released
− they do not allow users to express the fact that they might prefer torelease some information over other when given choices
=⇒ Need to provide users with means to effectively regulate therelease of their information
c!Pierangela Samarati 4/20
Goal of our work
Enable users to effectively regulate disclosure of their properties andcredentials
• identify requirements and concepts that need to be captured
• organize of users properties and credentials in the user portfolio
• enable users to specify how much she values the disclosure ofdifferent components of the portfolio
• provide possible technical approaches for supporting user’spreferences
• provide a basis for investigating user-friendly/user-understandableapproaches for regulating release of user’s properties
c!Pierangela Samarati 5/20
Client portfolio modeling
• The information of the client forms a client portfolio
• Credential: certificate issued and signed by a third party
◦ certifies a set of properties
◦ has a type, an identifier, and an issuer
• Declaration: property stored as a self-signed credential
• Hierarchy of abstractions of credential types H (T ,$isa)(e.g., id_card$isaid , id$isacredential)
c!Pierangela Samarati 6/20
Client portfolio – Properties
• Credential-independent:the value depends onlyon the credential’sowner (e.g., birth date)
Credential-dependent :the value depends onthe certifying credential(e.g., credit cardnumber)
!"#$%&'!"#$
(")!%&'()'(*+,
*+,-!-./#0123
*./0*+,-!/./+,
122&-33!45
-4+.5!/6789:12
67"$-!+;*<:::<)==
c!Pierangela Samarati 7/20
Client portfolio – Properties
• Credential-independent:the value depends onlyon the credential’sowner (e.g., birth date)
• Credential-dependent:the value depends onthe certifying credential(e.g., credit cardnumber)
!!"#$!"#$#%%&'
!%#&'()!()*
*%+!&#+',+'-.$
",$-!/01)2345
"./0",$-!101.$
122(-33!67
!!"#$!$8"#%%%'9
-4,.5!1:;<=%34
67%&-!.9->%%%>,""
c!Pierangela Samarati 7/20
Client portfolio – Credentials
• Atomic: released as awhole (e.g., X.509)
non-atomic: propertiescan be selectivelyreleased,proof-of-possession canbe certified (e.g., Idemix,U-Prove)
!"#$%&!"#$%&'(")#%
!"$'!&%(")#%
!"()!"#$%&'(")#%
!!"#$!*+,+--./
!%#&'()!012
*%+!.+3/43/56,
",$-!7891:&';
"./0",$-!9896,
122(-33!<=
!!"#$!,>*+---/?
-4,.5!9@A)"-&'
67%&-!6?5B---B4**
c!Pierangela Samarati 8/20
Client portfolio – Credentials
• Atomic: released as awhole (e.g., X.509)
• Non-atomic: propertiescan be selectivelyreleased,proof-of-possession canbe certified (e.g., Idemix,U-Prove)
!"#$%&!"#$%&'(")#%
!"$'!&%(")#%
'()*!%$"*)#)'&+,
!"+,!"#$%&'(")#%
!"-.)(/0(!%#(*&"$,-$
!!"#$!./0/1123
!%#&'()!456
*%+!2/738739:0
",$-!;+<5=&'>
"./0",$-!<+<:0
122(-33!?@
!!"#$!0A./1113B
-4,.5!<-C)"1&'
67%&-!:B9D111D8..
c!Pierangela Samarati 8/20
Disclosure
A disclosure is a subsetof the client portfolio thatsatisfies:
• certifiability: eachproperty is certified by acredential
• atomicity: if a property ofan atomic credential isdisclosed, all itsproperties are disclosed
!"#$%&!"#$%&'(")#%
!"$'!&%(")#%
'()*!%$"*)#)'&+,
!"+,!"#$%&'(")#%
!"-.)(/0(!%#(*&"$,-$
!!"#$!./0/1123
!%#&'()!456
*%+!2/738739:0
",$-!;+<5=&'>
"./0",$-!<+<:0
122(-33!?@
!!"#$!0A./1113B
-4,.5!<-C)"1&'
67%&-!:B9D111D8..
Does not satisfy atomicity!
c!Pierangela Samarati 9/20
Disclosure
A disclosure is a subsetof the client portfolio thatsatisfies:
• certifiability: eachproperty is certified by acredential
• atomicity: if a property ofan atomic credential isdisclosed, all itsproperties are disclosed
!"#$%&!"#$%&'(")#%
!"$'!&%(")#%
'()*!%$"*)#)'&+,
!"+,!"#$%&'(")#%
!"-.)(/0(!%#(*&"$,-$
!!"#$!./0/1123
!%#&'()!456
*%+!2/738739:0
",$-!;+<5=&'>
"./0",$-!<+<:0
122(-33!?@
!!"#$!0A./1113B
-4,.5!<-C)"1&'
67%&-!:B9D111D8..
E
Does not satisfy atomicity!
c!Pierangela Samarati 9/20
Privacy preferences – Requirements
• Clients may prefer to disclose some properties/credentials overothers =⇒ different portfolio elements have different sensitivity
• Privacy preference specifications are needed to:
◦ automatically regulate the disclosure of sensitive information
◦ minimize the disclosure of sensitive information
• A solution to express privacy preferences must support:
◦ fine-grained control on sensitive information
◦ specifications on the sensitivity of associations
◦ constraints on the disclosure of information
c!Pierangela Samarati 10/20
Portfolio sensitivity
• Privacy preferences expressed as sensitivity labels
• Sensitivity labels reflect how much a client values the disclosure ofcredentials/properties in the portfolio
• Sensitivity labels are characterized by:
◦ partial order relationship %
◦ composition operator ⊕ for computing sensitivity of a set ofelements, can be based on− additivity: the sensitivity of a combined disclosure is the sum of the
sensitivities of the disclosed elements
− maximum: the sensitivity of a combined disclosure is the upperbound of the sensitivities of the sensitivities of the disclosed elements
c!Pierangela Samarati 11/20
Sensitivity labels – Examples
• Sensitivity labels as integer values
◦ % is the ≥ total order relationship
◦ ⊕ is the sum + of values (additivity)
(e.g., ! (Name)=1, ! (DoB)=5, ! (Name)⊕! (DoB)=6)
• Sensitivity labels as multilevel security classifications
◦ % is the total order relationship on security classes