Interaction Models in EPC-DS

& the Security Implications

Tieyan Li

Cryptography and Security Department Institute for Infocomm Research (I2R)

19 Jun. 2009

Joint Singapore Taiwan RFID Research Joint Singapore Taiwan RFID Research WorkshopWorkshop

2

Project Summary - why should it be done?Outline• Introduction

– EPC Discovery Services– EPC-DS Terminology and

Scope– Security Properties

• Interaction Models− Directory Service− Query Relay

• Security Implications– Confidentiality– Integrity– Availability

• Conclusions• Further On…

Courtesy to EPCglobal DS & EU bridge project

3

Clients, Intermediary & Resources

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Wishes to retrieve information (e.g. event data)from one or more organizations

Holds information about individual objectsCould be an EPCIS - but also web pages,web services, XML data and other service types

Maintains an internal list of associations and can help clients find resources (or vice versa)

4

Familiar Directory-like Diagram

QueryClient

Intermediarye.g. Discovery

Service

Resourcee.g.EPCIS

Resourcee.g.EPCIS

Resourcee.g.EPCIS

Resourcee.g.EPCIS

Resourcee.g.EPCIS

QueryClient

5

Intermediary'DiscoveryService'

Resourcee.g.EPCIS

QueryClient

Resources hold detailed information about individual objects

Query Clients wish to retrieve complete information from multiple sources

A Discovery Service can help a Query Client to find multiple sources of information

An organization might make queries and might provide resources

Resourcee.g.EPCIS

Resourcee.g.EPCIS

Resourcee.g.EPCIS

Resourcee.g.EPCIS

QueryClient

A query clientqueries a Discovery Service

Resources publish selected records to a DS so that query clients can

find them

and receives links to resources

They may also specify security policies to protect

their records

(if the policy allows them to)

6

Discovery Services

Value-added track & trace applications& supply-chain management applications

• Retrieve complete end-to-end traceability

• including multiple aggregation changes, relabelling

• Analyze event data from across supply chain / lifecycle

• detect problems (delays, deviations, duplicate IDs)

• identify root cause of problems

• predict ahead (when, where expected next)

• analyze trends and optimize for efficiencies

• Handle / choreograph fine-grained product recalls

• Generate alerts re problems (e-mail, SMS)

help authorized authenticated clients to find one or more

possibly relevantinformation resources

for an EPC or ID2 layers

7

Project Summary - why should it be done?Data Integrity & Confidentiality• Query results shall be authentic, accurate, and as complete* as

permissible.

• DS shall protect the confidentiality and data integrity of the data and query and shall support availability of the data.

• Identity of the resource/client shall not be disclosed to non-essential parties , and shall only be shared as a deliberate act.

• DS may accept publishing of digitally signed records(i.e. include as optional part of core DS protocol definition)

• A DS should provide a client with an indication of whether or not the underlying record published into the DS was digitally signed with a signature and if so, whether that was successfully validated by the DS?

• * completeness depends on scope of query (multiple factors, same DS vs universal, % complete, time to wait, industry sector, region, ...)

8

Project Summary - why should it be done?Data Ownership and Trust

• Each company shall have control of the visibility and distribution of their data within the DS Network, subject to regulatory requirements

• Each DS provider may provide the facility for a company to track the usage of their own data within the DS Network, subject to regulatory requirements.

• Users may be reluctant to share more than minimum necessary data with a DS - or sharing of additional data should be optional.

• Reject models that require the resource owner (e.g. company having an EPCIS) to share detailed information with a DS without first gaining details of which clients require the detailed access and being able to refuse or negotiate this access.

9

Project Summary - why should it be done?Access Control• DS shall allow the assertion of security credentials by the querying

client, the data publisher or any other parties with which it interacts (including peering, policy management etc.).

• DS shall perform final authorization and access control on any interface with external parties.

• DS shall allow publishers to maintain their own access control policies separately from other publishers.

• DS shall allow common over-riding access controls (e.g. for regulation).

• Any peering between Discovery Services shall respect the access controls in each individual Discovery Service.

• Each publisher shall be able to access logs of access to their data in order to monitor that the behaviour of the system is in accordance with that expected from their security policies.

10

Project Summary - why should it be done?Threats & Concerns• Revealing sensitive information (volumes, flows of goods) to

unauthorized parties– e.g. where resources lose control over which clients see links– e.g. 'harvesting' of info from client queries by 'honeypot' resources

• Excessive network traffic / unnecessary messages– New vulnerabilities / mechanism for Denial of Service attacks?

• Slow response times– Inability to provide synchronous response– Waiting for response from underlying / proxy query - and maintaining

session state

• Manageability / Complexity of specifying access control policies– versus making a separate assessment for each query / each new

client– reuse / enforcement at both EPCIS and DS layers of architecture– need for consistency (synchronization?) between a resource's

policies at EPCIS & DS layers

• A Discovery Service may need to restrict which clients and which resources can use the DS (to limit DoS, honeypot attacks)

11

Interaction modesSetup

Client & Resource interact with DS to register interests & capabilities and negotiate security rights

Discovery

Provides either client or resource with sufficient info to initiate service fulfillment

Service Fulfillment

Resource becomes aware of client request and is able to meet it

12

Comparison

Client is querying

Resource is publishing

Client Resource

Client may be unknownClient is publishing

Resource is querying

Client Resource

Resource may beunknown

Directory ofResources

Directory ofClients

Notification ofResources

Notification ofClients

SynchronousRequest/Response

AsynchronousPublish & Subscribe

WithDiscoveryphase

13

Directory of Resources

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

EPC, URL

EPC

URL

full EPCIS query

EPCIS result-set

EPC, URL, serviceType

14

Directory of Clients

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

? EPCs

EPC, URL

EPC, Client ID

full EPCIS query

EPCIS result-set

EPC, Client ID

EPC, Client ID

15

Notification of Resources

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

EPC, URL

EPC, Client ID

EPC, URL

full EPCIS query

EPCIS result-set

EPC, Client ID

16

Notification of Clients

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

EPC

EPC, URL

EPC, Client ID

full EPCIS query

EPCIS result-set

EPC, Client ID

EPC, URL,serviceType

17

Comparison

Resource to Client

Client Resource

Client to Resource

Client Resource

Meta Resource

Meta Client

Notification ofEvents

Query Propagation

SynchronousRequest/Response

AsynchronousPublish & Subscribe

Withouta distinctDiscoveryphase

18

Meta Resource

EPCIS events

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Fulfillment

full EPCIS query

EPCIS result-set

EPCIS events

19

Meta Client

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

full EPCIS queryClientID

EPCIS result-set

any queries?

queries,ClientID

ClientID,EPCIS queries

20

Notification of Events

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Fulfillment

full EPCIS queryClientID

full EPCISevents

full EPCISevents

ClientID,EPCIS queries

21

Query Propagation

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Setup

Discovery

Fulfillment

EPC, URL

full EPCIS queryClient ID

full EPCIS queryClient ID

EPCIS result-set

EPC, URL, serviceType

22

EvaluationModel Protection of

Client Confidentiality

Protection of Resource Confidentiality

ResponseLatency

Status

Directory of Resources

Good Concern Good Candidate

Directory of Clients

Concern Good Poor Rejectfor one-off queries

Notification of Resources

Good Concern Good Candidate

Notification of Clients

Concern Good Concern Candidate

Meta Resource

Good Poor Good Reject

Meta Client Concern Good Poor Rejectfor one-off queries

Notification of Events

Good Poor Good Reject

Query Propagation

Concern Good Concern Candidate

23

Interaction modes

• One-off queries– Assist with gathering of historical data (e.g.

trace) up to time of query(DS provides referrals or forwards query)

– Synchronous response may be possible

• Standing queries– Be notified of future updates from new

resources (e.g. companies who handle the object at future times)

– Only asynchronous notification possible

24

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Directory of Resources

Setup

Discovery

Fulfillment

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Notification of Resources

Setup

Discovery

Fulfillment

One-off queries Standing queries

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Query Propagation

Setup

Discovery

Fulfillment

QueryClient

Intermediarye.g. DS

Resourcee.g.EPCIS

Meta Client

Setup

Discovery

Fulfillment

EPC, URL, serviceType EPCIS query, Client ID

EPC, URL, serviceType EPC, Client ID

25

Implications: Confidentiality of Client queries

• In Query Relay model, risk of 'harvesting' by rogue resources ('honeypots').

• Clients may need to check plausibility of records asserted by resources. (e.g. an object cannot be within physical custody of two organizations at the same time)– Might need 'business step' to understand whether physical

custody is being claimed. (to allow for non-custodial resource owners [e.g. insurers ])

• Blacklists and whitelists– Sent by client with client's query, possibly cached in DS– Use of blacklists to prevent relaying of queries to known

competitors or dubious resources– Use of whitelists to restrict forwarding to only a set of

trusted business partners.– May prevent client from discovering unknown yet

trustworthy resources that hold relevant information

26

Implications: Confidentiality of Resource Info.

• In Directory Service model, release of records (links) to client should be controlled via access control policies specified by the resource owner and enforced by the DS operator

• DS operator may also (need to) specify and enforce overall policies for their DS (e.g. who can query, who can publish, regulators' policies) that over-ride individual policies specified by resource owners.

• Resource owners should be aware of these DS policies before publishing to it

• In Directory Service model, scalability & management of security policies is a major concern

• If resource policy hides resource ID from unknown clients, how could those clients begin to negotiate with the resource?

– Possible mediation role for DS using temporary token + relaying of messages?

• In Query Relay model, resource can decide whether to allow access– Without delegation to a DS– Also taking into account real-time info (e.g. current load on resource)

• Query Relay model may work better for unsolicited client communications

27

Overcoming 'deadlock' before trust is established

Discovery Service

QueryClient

Resourcee.g.EPCIS

"I hold information about EPC xyz- but hide my real ID & contact info from unauthorized / unknown clients"

Opaque token0A8274B2845EF

Request for access,Quoting token

Request for accessfrom client with ID...

28

Implications: Information Integrity

• Must prevent compromising the integrity of information held within DS• Deletion / change of information only in accordance with security policies• Resource should retain right to modify or delete - but this might be

over-ridden by DS policies (e.g. to maintain a journal for regulated supply chains)

– Delete => mark as void– Modify/update => mark as void and re-assert

• May need to consider digitally signing: – Client queries (signed by Client)– DS records (signed by the resource owner / publisher)– Responses (signed by DS or by resource if responding directly)

• Potential problem of embedding URLs within DS records since any modification to the URL may break the original digital signature for each record.

– Consider decoupling URL from each DS record - store in 'Resource Profile' instead

• May need DS to indicate to the client whether it was able to validate signatures– For signed DS records it received, where the record is not returned in full to a client– Whether or not the underlying DS record was / was not signed, validated / did not

validate

29

Implications: Service Availability• DS should be designed to be resilient against Denial-of-Service

attacks.

• The DS design should not compromise the clients or resources or make them more vulnerable to Denial-of-Service attacks.

• In Directory Service model, URL of resource is only released to clients fulfilling access policy restrictions - helps prevent attacks on resources. However, resources under attack may need to change their address (URL).

• Need ability to decouple current (possibly mutable) URL of a resource from its immutable resource ID - rather than embedding URL within each DS record.

• In Query Relay design, if clients rely on propagation of full (EPCIS) query via a query relay DS, they would be particularly dependent on DS availability.

30

Decoupling of URLs from Discovery Service records

Discovery Service

Resource ProfileURL

serviceType

DS Record

EPC or IDTimestampResourceID

[other metadata]

ResourceID=...

ResourceID

Resourcee.g.EPCIS

31

Implications: Attack Scenarios

• Possible misuse of Query Relay design to launch DoS attacks on resources.– Possible countermeasures:

• client authentication with DS,• limit how frequently client may make queries

• Registration of non-existent resource addresses for already assigned EPCs– Increases network load, slower responses (timeouts, retries)– Query Relay and each client of a Directory Service could identify resources that

persistently fail - and remove from resource cache or add them to blacklists

• Registration of existent resource addresses - but of incorrect service type– Countermeasure: authenticate resources before allowing them to publish

• Impersonation of valid clients by malicious clients to mislead DS or resources– Countermeasure: authentication of DS clients

32

Implications: Inter-working w/ NATs and Firewalls

• Clients must be able to interact with a DS from behind a firewall or Network Address Translation (NAT) box.

• Stateful firewalls match returning traffic with outbound addresses

• Problem of responses from unexpected network addresses (especially in Query Relay model variant when responses are not returned via the DS but directly from resources)

• Can also be a problem when sending responses via a message transport network. (address of message router might not be expected/recognized)

• Client may need to provide client proxy (listener address) in DMZ for receiving inbound responses, (allow for inspection while quarantined)

33

Implications: Access Control Policies• Need high-level policies about which clients / resources can interact with DS

• Resources need to be able to restrict which clients can access their information (including the links to their information)

• For all models, the underlying resources need an access control mechanism

• For the Directory Service model, resources may need to be able to specify fine-grained access control policies to be enforced by the DS without the DS needing to contact the resource to check authorization

• For Query Relay, policies are stored and enforced primarily at each underlying resource, although less granular policies may be pushed to DS / network to reduce load on resources

• Directory Service model provides clients some opportunity to avoid 'honeypot' harvesting attack ( by allowing inspection of link before contact )

34

Conclusions• Considered different models for interactions between clients,

resources and intermediaries such as Discovery Services

• Choice depends on impact on security, performance & scalability– Not necessarily a single solution for all kinds of supply chains– Friendly community supply chains vs. strongly competitive vs. highly

regulated

• Directory Service is traditional well-proven approach but has unique challenges as a Discovery Service:– Delegated control and scalable expression, evaluation and

enforcement of security policies

• Query Relay model perhaps less obvious - but routing networks are established e.g. in peer-to-peer content retrieval networks.– Major challenges are detection and prevention of:

• Honeypots for harvesting information from client queries• Injection of false information to mislead or cause disruption

– Need secure resource registration and policing of resource behaviour– Need secure client registration and policing to prevent DoS attacks

on resources

35

Project Summary - why should it be done?Further on…RFID Security Team

• http://icsd.i2r.a-star.edu.sg/staff/tieyan/SecureRFID/

Upcoming events:

• Workshop on RFID Security (RFIDsec’10 Asia) Feb. 22-23, 2010, Singapore.

http://RFIDsec2010.i2r.a-star.edu.sg

Thank you for your attention!