Interaction Models in EPC-DS

1
Interaction Models in EPC-DS the Security
Implications
Joint Singapore Taiwan RFID Research Workshop
Tieyan Li Cryptography and Security Department
Institute for Infocomm Research (I2R) 19 Jun.
2009
2
Outline
Project Summary - why should it be done?

• 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
Wishes to retrieve information (e.g. event
data)from one or more organizations
Intermediarye.g. DS
Maintains an internal list of associations and
can help clients find resources (or vice versa)
Resourcee.g.EPCIS
Holds information about individual objects Could
be an EPCIS - but also web pages,web services,
XML data and other service types
4
Familiar Directory-like Diagram
QueryClient
QueryClient
Intermediarye.g. DiscoveryService
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
5
Query Clients wish to retrieve complete
information from multiple sources
An organization might make queries and might
provide resources
QueryClient
QueryClient
A query clientqueries a Discovery Service
and receives links to resources
(if the policy allows them to)
Resources publish selected records to a DS so
that query clients can find them
A Discovery Service can help a Query Client to
find multiple sources of information
Intermediary'DiscoveryService'
They may also specify security policies to
protecttheir records
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resourcee.g.EPCIS
Resources hold detailed information about
individual objects
6
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)

Discovery Services
help authorized authenticated clients to find
one or morepossibly relevantinformation
resourcesfor an EPC or ID
2 layers
7
Data Integrity Confidentiality
Project Summary - why should it be done?

• 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
Data Ownership and Trust
Project Summary - why should it be done?

• 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
Access Control
Project Summary - why should it be done?

• 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
Threats Concerns
Project Summary - why should it be done?

• 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 modes
Setup 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
WithDiscovery phase
SynchronousRequest/Response
AsynchronousPublish Subscribe
Client is querying Resource is
publishing Client Resource Client may
be unknown
Directory ofResources
Notification ofResources
Client is publishing Resource is
querying Client Resource Resource may
beunknown
Directory ofClients
Notification ofClients
13
Directory of Resources
EPC
EPC, URL, serviceType
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
EPC, URL
URL
full EPCIS query
Setup
EPCIS result-set
Discovery
Fulfillment
14
Directory of Clients
EPC, URL
EPC, Client ID
? EPCs
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
EPC, Client ID
EPC, Client ID
full EPCIS query
Setup
EPCIS result-set
Discovery
Fulfillment
15
Notification of Resources
EPC, Client ID
EPC, Client ID
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
EPC, URL
EPC, URL
full EPCIS query
Setup
EPCIS result-set
Discovery
Fulfillment
16
Notification of Clients
EPC, URL
EPC, URL,serviceType
EPC
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
EPC, Client ID
EPC, Client ID
full EPCIS query
Setup
EPCIS result-set
Discovery
Fulfillment
17
Comparison
Withouta distinctDiscovery phase
SynchronousRequest/Response
AsynchronousPublish Subscribe
Resource to Client Client Resource
Meta Resource
Notification ofEvents
Client to Resource Client Resource
Meta Client
Query Propagation
18
Meta Resource
full EPCIS query
EPCIS events
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
EPCIS events
EPCIS result-set
Setup
Fulfillment
19
Meta Client
ClientID, EPCIS queries
full EPCIS queryClientID
any queries?
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
queries,ClientID
Setup
EPCIS result-set
Discovery
Fulfillment
20
Notification of Events
full EPCIS queryClientID
ClientID, EPCIS queries
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
full EPCISevents
full EPCISevents
Setup
Fulfillment
21
Query Propagation
EPC, URL, serviceType
EPC, URL
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
full EPCIS queryClient ID
full EPCIS queryClient ID
Setup
EPCIS result-set
Discovery
Fulfillment
22
Evaluation
Model Protection of Client Confidentiality Protection of Resource Confidentiality ResponseLatency Status
Directory of Resources Good Concern Good Candidate
Directory of Clients Concern Good Poor Reject for 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

One-off queries
Standing queries
Directory of Resources
Notification of Resources
EPC, URL, serviceType
EPC, Client ID
Intermediarye.g. DS
Resourcee.g.EPCIS
QueryClient
Intermediarye.g. DS
Resourcee.g.EPCIS
QueryClient
Setup
Setup
Discovery
Discovery
Fulfillment
Fulfillment
EPC, URL, serviceType
EPCIS query, 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
QueryClient
Request for access, Quoting token
Opaque token 0A8274B2845EF
Discovery Service
Request for accessfrom client with ID...
"I hold information about EPC xyz- but hide my
real ID contact info from unauthorized /
unknown clients"
Resourcee.g.EPCIS
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 gt mark as void
• Modify/update gt 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
ResourceID...
DS RecordEPC or ID Timestamp ResourceID other
metadata
Resource ProfileURL serviceType
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
Further on
Project Summary - why should it be done?

• RFID Security Team
• http//icsd.i2r.a-star.edu.sg/staff/tieyan/SecureR
  FID/
• Upcoming events
• Workshop on RFID Security (RFIDsec10 Asia) Feb.
  22-23, 2010, Singapore.
• http//RFIDsec2010.i2r.a-star.edu.sg

Thank you for your attention!