Talk at WPES@CCS, November 9, 2020

1. PRShare: A Framework For
Privacy-Preserving,
Interorganizational
Data Sharing
Lihi Idan
Yale University
(Joint work with Joan Feigenbaum)

2. Interorganizational data sharing
Owner organization (“data owner”), client organization (“data client”).
Data record: data+metadata attributes. Stored on a Cloud server (CSP).
Attribute=<label,value>
Each record is linked to a certain individual, the data subject.
Data users employees of a data client, may need access to owner’s data records in
order to to perform their assigned tasks.
Intermediary organizations enrich shared data with additional information that is
needed for the client’s tasks

3. Interorganizational data sharing – cont.
Employees are assigned a list of time-limited tasks. This list is dynamic.
An employee is only allowed to access shared data records that are needed in order to
execute a task in her tasks list.
“Needed in order to perform a task”?**
Each organization uses its own set of intraorganizational attributes to query and process the
shared data. This set is called VOCABULARY.
We assume that the intersection between different vocabularies is not empty.

4. Privacy preserving Interorganizational data sharing
Privacy of data subjects: sharing of data must be kept to the minimum
required in order to perform a task.
Privacy of each organization: maintaining a proprietary view of the
shared data.
• Preventing unauthorized employees from accessing the shared data.
• Protecting the confidentiality of each organization’s proprietary metadata
attributes
Each organization does not want to expose its internal structure and role
hierarchy to other organizations.

5. Attribute-based encryption (Key-Policy ABE )
Each ciphertext is encrypted by an encryptor under a set of attributes.
Users’ private keys reflect decryption policies (access policies). Keys are
issued offline by a trusted authority.

6. Interorganizational data sharing using ABE
Each data record includes a payload h (data) and a set of attributes S.
Each payload h is encrypted by the owner under its corresponding S and the resulting
data record is stored on the CSP.
A user is issued an attribute-based secret key. Keys are issued by a group of trusted
authorities.
The user can then send data requests to the CSP.

7. Pros
Flexibility ciphertext not necessarily encrypted to one particular user
Expressive, fine-grained access policies
Eliminates the need to rely on the CSP for preventing unauthorized data
access

8. Using existing ABE schemes
Underlying assumption: the attributes in the key and in the ciphertext must belong to the
same vocabulary.
Real-world interorganizational setting: organizations often belong to different professional
domains.
Challenge: attributes in the ciphertext used by the encryptor (owner) and attributes in
keys used by users (client employees) may belong to different vocabularies .

9. Using existing ABE schemes-cont.
Underlying assumption: attributes’ values can always be updated by the owner, at any
time.
Real-world interorganizational setting: some attributes’ true values can only be
determined when a user sends a data request. This update may require client’s or
intermediary’s proprietary auxiliary information that can not be shared with the owner.
Challenge: in many cases, the encryptor (owner) can not update ciphertexts’ attributes
on its own.

10. Payload:
email message
Auxiliary information:
watchlist
efg@gmail.com
uyi@gmail.com
lml@gmail.com
Attributes:
SENDER=abc@gmail.com,
DATE=11/9/2020,
SUBJECT_LINE=important,
IS_FILE_ATTACHED=yes
ON_WATCHLIST=TRUE DATE=112020
∨

11. Payload:
email message
Attributes:
SENDER=abc@gmail.com,
DATE=11/9/2020,
SUBJECT_LINE=important,
IS_FILE_ATTACHED=yes
Auxiliary information:
watchlist
ON_WATCHLIST=TRUE DATE=112020
abc@gmail.com
uyi@gmail.com
Two hours later…
∨

12. Payload:
Credit report
Attributes:
CREDIT-UTILIZATION-RATIO=0.35,
CREDIT-SCORE=650,
DLN=xyz ,
DATE=11/9/2020
Auxiliary information
AVERAGE_CREDIT_UTILIZATION_RATIO
=0.4
CREDIT_SCORE>600 ∧ #ACCIDENTS<2 ∧
IS-CREDIT-RATIO-LESS-THAN-AVERAGE=TRUE
Auxiliary information
Driving records
DLN -> #ACCIDENTS
DLN(xyz)=0

13. Payload:
Credit report
Attributes:
CREDIT-UTILIZATION-RATIO=0.35,
CREDIT-SCORE=650,
DLN=xyz ,
DATE=11/9/2020
Auxiliary information
AVERAGE_CREDIT_UTILIZATION_RATIO
= 0.4 0.3
CREDIT_SCORE>600 ∧ #ACCIDENTS<2 ∧
IS-CREDIT-RATIO-LESS-THAN-AVERAGE=TRUE
Auxiliary information
Driving records (MVR)
DLN -> #ACCIDENTS
DLN(xyz)=0 1
A week later...

14. Goals
Design an interorganizational data-sharing framework with the following features:
Privacy preserving with respect to payloads, attributes and auxiliary information.
Multi-vocabulary: Each organization can use its own set of attributes to describe both the
shared data and access policies to the shared data.
Dynamically reconfigurable attributes: Ciphertext’s attributes are updated dynamically
according to up-to-date auxiliary information. Such updates do not require re-encryption
of the ciphertext.
Offline delegation: The owner does not to need to authorize or serve clients’ data-access
queries.
Key-abuse prevention, direct revocation

15. Attribute based encryption with oblivious
attribute translation

16. Solution: attribute translation
Let uowner be the owner’s attribute universe (owner’s vocabulary) and uclient be the
client’s attribute universe (client’s vocabulary)
A translation algorithm Translate() takes as input a ciphertext ct , ct=[h]S s.t. S ⊆ uowner
and outputs a new ciphertext, ct’=[h]S’ s.t. S’ ⊆ uclient .
Payload: h Payload: h
Att1
Att2
Att3
Att1’
Att2’
Att3
Translate()
CT CT’
S S’

17. Requirements from Translate()
Translate() can be computed dynamically based on up to date auxiliary information held by
the client or an intermediary.
Payload privacy: Translate() can be computed such that only authorized users can learn h.
Attribute privacy: Translate() can be computed such that attributes in S are not revealed to
the client and attributes in S’ are not revealed to the owner
Is this really necessary?
Attribute privacy: Translate() can be computed such that sensitive attributes in S are not
reveled to the client and sensitive attributes in S’ are not revealed to the owner (formal
definition in the paper)
Each organization can choose which attributes are considered sensitive to it.

18. Pros:
Each organization can use its own vocabulary, and yet the attributes in the ciphertext and
key will match
Each organization’s sensitive attributes as well as auxiliary information are not exposed to
other organizations.
How is att1’ computed?
-Numerical comparison (att1>auxiliary)
-Equality check between att1 and(att1=auxiliary)
-List membership test(att1 ∈ auxiliary)
-Keyword search of att1 in auxiliary
-Using pre-configured look up tables
And more…

19. Who performs attribute translation?
Data owner?
Goals:
Division of trust: translation can not be done by a single entity.
Delegation: saving resources by delegating translation operations.

20. Mediated cryptography
Designed by Boneh, Ding and Tsudik (2001) as a method to allow immediate revocation.
Particularly useful in government or corporate environments.
Use an on-line mediator for every transaction, SEM (SEcurity Mediator).

21. Semi-trusted Mediator
• Delegate translation
• Semi trusted server (proxy) will perform the translation.
• Conceptually, one proxy for each intermediary, and one for the client.
• Each proxy may translate a pre-defined subset of attributes . Different proxies’ subsets
may overlap.
• Each proxy prj uses both a generic translation algorithm and an organization-specific
translation function and auxiliary information

22. Oblivious Attribute
Translation
If needed, auxiliary information may also remain hidden from the proxy
Att1=<a,b>
Att2=<c,d>
Att3=<e,f>
Att1=<a,b>
Att2=<c,d>
Att3=<x,y>
M M
Q_j={Att3}
S S’
Translate(ct,j)
CT’
CT

23. Payload:
email message
Auxiliary information:
watchlist
abc@gmail.com
Payload:
email message
Attributes:
SENDER=abc@gmail.com,
DATE=11/9/2020,
SUBJECT_LINE=important,
IS_FILE_ATTACHED=yes
abc@gmail.com ∈ watchlist?
ON_WATCHLIST=TRUE
Attributes:
SENDER=abc@gmail.com,
DATE=11/9/2020,
SUBJECT_LINE=important,
IS_FILE_ATTACHED=yes
ON_WATCHLIST=TRUE DATE=1092020
∨

24. Payload:
Credit report
Attributes:
CREDIT-UTILIZATION-RATIO=0.35,
CREDIT-SCORE=650,
DLN=xyz ,
DATE=11/9/2020
Auxiliary information
AVERAGE_CREDIT_UTILIZATION_RATIO
=0.4
CREDIT_SCORE>600 ∧ #ACCIDENTS<2 ∧
IS-CREDIT-RATIO-LESS-THAN-AVERAGE=TRUE
Auxiliary information
Driving records (DRs)
DLN -> #ACCIDENTS
DLN(xyz)=0
DR[xyz]=?
0.35<AVERAGE_CREDIT_UTILIZATION_RATIO?
Attributes:
CREDIT-UTILIZATION-RATIO=0.35,
CREDIT-SCORE=650,
DLN=xyz ,
DATE=11/9/2020
Attributes:
CREDIT-UTILIZATION-RATIO=0.35,
CREDIT-SCORE=650,
#ACCIDENTS=0,
DATE=11/9/2020
Payload:
Credit report
Payload:
Credit report
#ACCIDENTS=0
IS-CREDIT-RATIO-LESS-THAN-AVERAGE=TRUE

25. What else can we do with translation?
• Key abuse
An authorized user is able to share his secret key with unauthorized users and abuse his
access privilege.
• Revocation
Efficient revocation.
Direct revocation mechanism: revoking the keys of a set U of users does not affect the
keys of users not in U.

26. Our techniques
• Use secret sharing to break the binder term into |translators|+1 shares. Each partial
ciphertext contains only one share of the binder term.
• For each mutable attribute, the ciphertext does not contain the actual attribute.
Instead, the ciphertext contains the output of a given transformation that is applied to
the attribute.
• A second uniformly randomly chosen term, lk , is used to double blind each partial
ciphertext, using dk = fk ∗ lk as a blinding factor.

27. Conclusion
We have designed PRShare, an interorganizational data-sharing framework
Privacy preserving
Multi-vocabulary
Dynamically reconfigurable attributes
Offline delegation
Key-abuse prevention, direct revocation
We have introduced the novel concept of Attribute-Based Encryption With Oblivious
Attribute Translation
More details in ?:
System flows
Security
Construction
Benchmarks

28. Questions?