1. CMPE 252A : Computer Networks
Chen Qian
UCSC Baskin Engineering
Lecture 18
Some slides from Brent Waters and Saiyu Qi

2. Scalable Data Access Control in RFID-Enabled Supply Chain
Saiyu Qi1,2, Yuanqing Zheng2, Mo Li2, Yunhao Liu3 , Jinli Qiu4
HKUST1
Nanyang Technological University2
Tsinghua University3
Xi’an Jiaotong University4
Hello everyone, I’d like to present this paper: Scalable Data Access Control in RFID-Enabled Supply Chain.
As the visa of the original author is still being checked, He cannot come and give a talk. So he authorizes me to give this talk.
In this paper, we propose a scalable data access control system to support secure sharing of product data in RFID-enabled supply chain.

3. Introduction of RFID technique
Basic components of RFID:
RFID Tag:
low cost
limited storage ability
support wireless
communication
RFID Reader:
moderate-ability
retrieve tag carried data via
wireless channel
Database:
Connect with reader
store detailed tag data
tag identification/authentication
First, let me introduce what is RFID technique. Generally, RFID technique consists of three components:
The first is RFID tag, which is low cost, has limited storage ability and supports wireless communication
The second is RFID reader, which has moderate ability and can retrieve tag carried data via wireless channel
And the third is a database, which is connected with reader and stores detailed tag data.
Usually, the database is used to connect the tag with its detailed tag data for identification or authentication purpose.
RFID technique attracts increasing attention due to its good application prospect.
It is widely used in item tracking and localization
The global forecast of RFID hardware, middleware and IT market
Source from DolceraWiki

4. RFID-enabled supply chain1
shared among supply chain participants 2 3 1 2 3 4 5 4 5 6 6 7 8 9
A main application of RFID is supply chain,
(action 1) where tags are attached to products
(action 2)and supply chain participants are equipped with readers
(action 3)By doing so, the participants can efficiently trace their products and create product data to record their states.
(action 4)The product data can be then shared among participants, which facilitates information exchange and supports critical decisions in production operations. 8 7 9

5. Motivation The product data derived by RFID tags is usually sensitive
An instance: pedigree of drugs
created for each tagged drug in a pharmaceutical supply chain
be useful to verify if a drug is fake
often contains counterfeit certificate , time of delivery and manufactures
However, the product data derived by RFID tags is usually sensitive.
For instance, the pharmaceutical supply chain tracks tagged drugs and establishes a pedigree for each drug.
Such drug pedigrees are useful for retailers and consumers to check whether the
drugs are from trustworthy participants.
However, drug pedigrees may contain sensitive business matters and suffer
malicious accesses, such as accesses from drug counterfeiters and competitive manufacturers
suffer malicious accesses by drug counterfeiters and competitive manufacturers

6. The goal of this paper Secure sharing of RFID-derived product data
A scalable data access control system for RFID-Enabled Supply Chain
an item-level data access control mechanism
an item-level privilege revocation mechanism
Advantages:
Our goal is to support secure sharing of RFID-derived product data.
To achieve this goal, we design A scalable data access control system for RFID-Enabled Supply Chain.
It consists of two components：an item-level data access control mechanism and an item-level privilege revocation mechanism
Our system has two advantages: first, it provides data access control in item-level. Second, it is scalable to large amount of tagged products
data access control in item-level
scalable to large amount of tagged products

7. idxi, <Enc(wit, Ki)>sig
System model
product data is sensitive and may be compromised
A participant only needs to contact the provider to retrieve the data of others
idxi, <Enc(wit, Ki)>sig
We aim to provide item-level access policy for product data defined by participants
We consider a system model where supply chain participants rely on a service provider to efficiently share their product data
Each tag carries a tag ID for identification
(action 1,2,3)When a tagged product flows through the supply chain, a participant can identify the product and submits its product data indexed by the tag ID to the service provider.
(action 4)On the other hand, a participant can use the tag ID to retrieve the product data of the product generated by other participants
(action 5) The advantage is that the participant only needs to contact the service provider to do so, and does not to communicate with any other participants
(action 6) Under this system model, We consider a malicious service provider
(action 7) and aim to provide item-level access policy for product data defined by participants

8. Item-level data access control: a strawman method
To provide data access control in item-level,
(action 1,2) a first attempt is to submit encrypted data to the service provider
(action 3) and only distribute the secret key to authorized participants.
(action 4) Such a solution however, requires each participant to distribute a key multiple times when a tagged product flows through the supply chain
and is not scalable to support large-scale tagged products.
(action 5) Also, a participant may not know all the other participants, and is not aware who should acquire the key
Not scalable to support large-scale tagged products
Some participants are unknown in advance

9. Item-level data access control: our idea
Consider a tagged product flowing through the supply chain…
Submit policy enforced encryption:
encryption associated with an access policy
Policy definition:
two types of attributes: role attribute (etc, USA, Retailer) and tag attribute (used as tag ID)
logical expression over role attributes AND tag attribute
e.g., (‘retailer’ AND (‘USA’ OR ‘France’) AND ‘TagAtt’)
Instead, our system provides a new item-level data access control mechanism to avoid these drawbacks.
(action 1) Consider a tagged product flows through the supply chain,
(action 2) Our mechanism enables a participant to submit Policy enforced encryption to the service provider.
This kind of encryption is associated with an access policy
(action 3) We adopt two types of attributes to define a policy. Role attributes are used to describe certain characters of supply chain participants, while tag attributes are used to identify tags.
An access policy is thus defined as a logical expression over role attributes AND the tag attribute

10. Item-level data access control: our idea
Decryption condition of policy enforced encryption:
a credential with satisfiable role attributes and a credential with the tag attribute
Distributed credential management:
role attributes /credentials a key authority
tag attributes/credentials------corresponding tags
(only participants within the supply chain can acquire!)
A participant can acquire:
one credential with a set of role attributes to describe itself from the key authority
credentials of tag attributes from tags
(action 1) To decrypt the policy enforced encryption, an authorized participant must have a credential with satisfiable role attributes and a credential with the tag attribute
(action 2) The credentials are managed in a distributed manner: role attributes /credentials are managed by a key authority.
We use tags as a natural medium to distribute tag attributes and credentials within the supply chain, so that only participants within the supply chain can acquire them
(action 3) As a result, a participant can acquire one credential with a set of role attributes to describe itself from the key authority and credentials of tag attributes from tags

11. Item-level data access control: an example
role attributes published by key authority
tag attribute from tag
credential issuing of role attributes
within the
supply chain but unsatisfiable role attributes
outside the
supply chain
Let’s see an example.
(action 1, 2)During the system initialization, each participant acquires a credential with a set of role attributes to describe itself from the key authority.
(action 3, 4)When a tagged product flows through the supply chain, a participant can use role attributes and the tag attribute to define a proper access policy and submit a policy enforced encryption to the service provider.
(action 5) As the tagged product flows, only the participants within the supply chain can acquire the credential of the tag attribute.
(action 6,7) Finally, the access policy precludes the participant as it within the
supply chain but owns unsatisfiable role attributes. It also precludes the participant as it outsides the supply chain
Location: USA
Location: France
Location: USA
Obligation: retailer
Obligation: producer
Obligation: retailer
TagAtt
TagAtt

12. Item-level data access control: advantage
Advantages:
define an access policy with role attributes (acquired from the key authority) and tag attributes (acquired from tags)---do not need knowing other participants in advance
participants acquire credentials from key authority and tags --- item-level key issuing is avoided
Combing all the above key points, our mechanism enjoys two advantages:
A participant can define its access policy using attributes, and does not need to know other participants
A participant can acquire credentials from key authority and tags, and item-level key issuing is avoided.

13. Item-level data access control: implementation
Policy enforced encryption:
Double encryption pattern: Ciphertext Policy-Attribute Based Encryption (CP-ABE) [Bethencourt, et al., SP '07] and Updatable Encryption (UE) scheme
Symmetric encrypt
the ABE encryption
ABE encrypt the data
Precisely enforce our desired policy:
ABE to enforce role attribute part
Updatable encryption to enforce tag attribute part
Product data
ABE encryption
Policy enforced encryption
We implement policy enforced encryption by using double encryption pattern.
Product data is first encrypted by the ABE encryption scheme and further encrypted by the updatable encryption scheme.
On the other hand, we encode Credentials with role attributes as ABE private keys and Credentials with tag attributes as UE private keys
(action 1)We will see that double encryption pattern precisely implement Policy enforced encryption
Two types of credentials:
Credentials with role attributes: ABE private keys
Credentials with tag attributes: UE private keys

14. Ciphertext-Policy, Attribute-Based Encryption
John Bethencourt
CMU
Amit Sahai
UCLA
Brent Waters
SRI International
test

15. Remote File Storage: Interesting Challenges
Scalability
Reliability
… But we also want security
-- OK, so one thing we do all time is store our files on remote servers. There are a number of reasons why we do so.
-- We may want to provide scalable access to our files to others using additional resources available elsewhere.
-- We may want more reliability in case of failures. In this case we may want to replicate our files in different data centers or with different organizations.
-- But we want security. We may have requirements on who can access which files. The interesting thing is, there is a tension between security and the other properties. The more we replicate our files, the more we introduce potential points of compromise and the more trust we require. It’s this tension which makes this sort of problem interesting, and provides a context in which CP-ABE may be useful.

16. Remote File Storage: Server Mediated Access Control
Sarah:
IT department,
backup manager ?
Good:
Flexible access policies
Bad:
Data vulnerable to compromise
Must trust security of server
Access control list:
Kevin, Dave, and
anyone in IT department
OK, so, moving on, let’s look out how people control access to remotely stored files. One general way you might handle this is to have a server decide for you.
-- So in this case, when we upload a file, we also provide a policy specifying who should be permitted to access the file.
-- Now when another user comes along and authenticates herself to the server somehow, the server can evaluate the policy
-- along with metadata the server may have about the user in order to
-- make a decision about whether allow access.
-- So what are the pros and cons of this general class of approaches to access control?

17. Remote File Storage: Encrypting the Files
More secure, but loss of flexibility
New key for each file:
Must be online to distribute keys
Many files with same key:
Fine grained access control not possible
OK, so what if someone is very concerned about the confidentiality of their files? Well, they can
-- encrypt their file before storing it, using either symmetric or public key encryption. Now the server can freely give out copies of the encrypted file to anyone. Now the problem of
-- controlling access to the file is a matter of
-- distributing the key.
-- But then things get more complicated as you encrypt more files.
-- Do you use a new key for each file? In that case, it probably won’t be feasible to distribute the keys ahead of time, since you don’t know all the files you are going to store in the future.
-- So you, or some other server, has to stay online to mediate access to the keys.
Alternatively, you could use a few keys to encrypt many files.
-- But then you lose the fine grained control we had over access policies.

18. Remote File Storage: We Want It All
Wishlist:
Encrypted files for untrusted storage
Setting up keys is offline
No online, trusted party mediating access to files or keys
Highly expressive, fine grained access policies
Ciphertext-policy attribute-based encryption does this!
User private keys given list of “attributes”
Files can encrypted under “policy” over those attributes
Can only decrypt if attributes satisfy policy

19. Remove File Storage: Access Control via CP-ABE
MSK OR
IT dept.
AND
manager
marketing  PK     
SKSarah:
“manager”
“IT dept.”
(point out that attributes of secret key are mathematically incorporated into the key itself)
(after file is encrypted, say we put it on the server)
(explain that now, the policy checking happens “inside the crypto”. that is, nobody explicitly evaluates the policies and makes an access decision. instead, if the policy is satisfied, decryption will just work, otherwise it won’t.)
SKKevin:
“manager”
“sales”

20. Collusion Attacks: The Key Threat?
Important potential attack
Users should not be able to combine keys
Essential, almost defining property of ABE
Main technical trick of our scheme: preventing collusion
AND A B
SKSarah:
“A”, “C”
SKKevin:
“B”, “D”

21. Collusion Attacks: A Misguided Approach to CP-ABE
Collusion attacks rule out some trivial schemes …
AND A B
PKA
PKB
PKC
PKD
SKA
SKB
SKC
SKD M
= M1 + M2
SKSarah:
“A”, “C”
SKKevin:
“B”, “D”
C = (EA(M1), EB(M2))
CP-ABE has special design to be resilient to this attack

22. Item-level data access control: CP-ABE
ABE master key
ABE private key:
{USA, retailer}
ABE private key:
{France, manufacturer}
USA
To realize double encryption pattern, let’s first see CP-ABE.
(action 1)The key authority with an ABE master key can generate private key with role attributes for participants
(action 2)An ABE encryption can be associated with a logic expression over role attributes.
(action 3,4)CP-ABE guarantees that only the private key with satisfiable role attributes can decrypt
Logic expression over role attributes
ENC(M, ‘USA’ OR ‘CHINA’)

23. Item-level data access control: CP-ABE alone is ill-suited
ABE master key
ABE private key:
{USA, retailer}
ABE private key:
{France, manufacturer}
ABE private key:
{TagAtt}
ABE private key:
{TagAtt}
Now a question is why don’t we use ABE alone to implement the policy enforced encryption?
Actually, a simply idea is to let the key authority to issue private keys with role attributes at the beginning.
(action 1,2,3)Later, when a tagged product flows through the supply chain, the key authority further issue an private key with the tag attribute to all the participants within the supply chain.
(action 4)However, ABE has a security property called collusion resistance which prevents joint usage of multiple private keys for decryption. It’s goal is to prevent a malicious user with several private keys to decrypt large-scale data.
(action 5)Another drawback is that All participants within the supply chain must trust the key authority to manage their keys
Collusion resistance:
Prevent joint usage of multiple private keys for decryption
Single point of failure:
All participants within the supply chain must trust the key authority

24. Item-level data access control: Updatable Encryption
Updatable Encryption (UE):
use UE-private key to further encrypt
Generate UE private keys by themselves as tag attribute credentials
Must within the supply chain can acquire the keys to decrypt
encrypt with the
UE-private key
ABE encryption
Policy enforced encryption
Instead, we use double encryption pattern to overcome the drawbacks of CP-ABE.
Participants further encrypt the ABE encryption with the UE private key to form the policy enforced encryption
Also, Participants separately encode the credentials of tag attributes as UE private keys and store them into the corresponding tags
By doing so, our Policy enforced encryption is precisely implemented and participants can manage the credentials of tag attributes be themselves

25. Item-level data access control: Updatable Encryption
Updatable Encryption (UE):
(UE) re-key to transform an encryption under one UE- private key to an encryption under another UE-private key without decryption
Proxy re-encryption [Blaze
, et al., EUROCRYPT, 1998]:
long private key (1024 bits)
not specific for supply chain setting
Updatable encryption:
short private key (486 bits) to store in commercial tags (512 bits)
two security models for revoked participants and service provider
provable security under the two models
Updatable encryption also provides a new type of key called re-key to
transform an encryption under one private key to an encryption under another private key without decryption.
This property is useful in our privilege revocation mechanism as I will introduce next.
Our Updatable encryption is motivated from Proxy re-encryption which also provide re-keys.
We use new mathematic structure to build our scheme so that the private key is short enough to be stored in tags.
We also formalize two security models to describe the behaviors of revoked participants and service provider, and prove the security of our scheme in the two models

26. Item-level privilege revocation: basic tasks
Upstream participants cannot access the data of downstream ones
Downstream participants still can access the data of upstream ones
Our system also provides an item-level privilege revocation mechanism.
We consider the dynamic property of supply chain where an upstream participant may leave the supply chain. In this case, a downstream participant needs to revoke its data access privilege.
the revocation operation consists of two tasks: Upstream participants cannot access the data of downstream ones and Downstream participants still can access the data of upstream ones.
The first task is simple.
(action 1,2,3,4,5)The downstream participant only need to write new tag attribute credential into the tag.
(action 6,7,8)By doing so, all the following downstream participants can use the new tag attribute credential to encrypt and decrypt their data.
On the other hand, the old tag attribute credential cannot be used to access the data of downstream participants

27. Item-level privilege revocation: complete the second task
A strawman method:
add a tag credential each revocation
old tag credential
old encryption
high tag storage overhead
new tag credential
new encryption
Our solution:
re-encrypt old encryption with re-key
re-key
service provider
old encryption
To complete task 2, a simple solution is to store both the old/new tag attribute credentials into the tag, so that Downstream participants still can use the old credential to access the data of upstream ones.
This solution requires to add a tag attribute credential into the tag in each revocation operation. As revocations may happen multiple times, this solution incurs high tag storage overhead.
Instead, as we encode tag attribute credential as UE private key,
The downstream participant who update the old tag attribute credential to a new one can generate a re-key between the two credentials. re-key can transform an encryption under one private key to an encryption under another private key without decryption.
It then sends the re-key to the service provider and delegate it to update the policy enforced encryptions with the old tag attribute.
After updating, these encryptions can be decrypted by the new tag attribute credential. By doing so, the tag only needs to store the newest tag credential regardless the number of revocation operations.
only need to store the newest tag credential
new tag credential
new encryption

28. Evaluation: environment
PC configuration:16-core AMD Opteron Processor 6320 and 16GB RAM running on Ubuntu OS
Two platforms:
Single PC
Cluster of three PCs with hadoop
Product data is randomly generated following normal distribution
We evaluate our system on two platforms, a single PC and a Cluster of three PCs with hadoop
We randomly generate Product data following normal distribution

29. Evaluation: data submission, data retrieval, and updating
All the three operations for tagged products can be completed within 1 hour
We consider three core operations of our system, namely Encrypt, decrypt and update policy enforced encryptions
We evaluate the computation overhead of the three operations when a large amount of tagged products flow through the supply chain
The experiments on both the platforms show that all the three operations can be completed within one hour for tagged products.

30. Summary
Policy enforced encryption with role attributes and tag attribute
Preclude participants outside supply chain and with unsatisfiable characters
separately manage credentials of role attributes and tag attributes
Enforce item-level access control without item-level key issuing
Enable servicer provider to transform old encryptions to new encryptions by re-key without decryption
Tag only needs to store the newest tag credential
In this paper, we propose a scalable data access control system to support secure sharing of product data in RFID-enabled supply chain.
Our system has several novel ideas.
We implement Policy enforced encryption to encrypt product data. The policy of such an encryption is defined by role attributes and tag attribute.
By doing so, the encryption Preclude participants outside supply chain and with unsatisfiable characters
We separately manage credentials of role attributes and tag attributes through the key authority and tags
By doing so, a participant can use attributes to define the access policy for its policy enforced encryptions and acquire corresponding credentials from the key authority and tags. And no key needs to be issued between participants
We design updatable encryption scheme to Enable servicer provider to transform old encryptions to new encryptions by re-key without decryption.
By doing so, a Tag only needs to store the newest tag credential regardless the number of revocations

31. End
11/27/2018