The “Internet of Things,” once reality, will have to rely on a global IT infrastructure that provides information about all those “things” in a secure and reliable manner. The EPCglobal Network is a proposal for a widely distributed information system to offer such services. But it may introduce more challenges concerning security, privacy, and political control than was initially anticipated.
If the vision of many RFID proponents becomes true, more and more common objects will soon acquire a cyber presence. Objects will be equipped with RFID tags containing identification data and possibly some additional information about the object in question (data on tag). To keep tag costs low, one may often just store an identifier and use it as a key to access databases containing the actual object information (data on network). This second approach is typical for “EPC tags”—RFID tags that aim to replace the conventional barcode system. They use an Electronic Product Code (EPC, see Figure 1), which is globally unique, as a key to retrieve information from the EPCglobal Network, envisioned as a large distributed system of databases.12 The EPC standard represents a numbering framework that is independent of specific hardware features, such as tag generation or specific radio frequency.
The databases compromising the EPCglobal Network are to be run by manufacturers, logistic providers, retailers, or third parties, and can be accessed via special web services called EPC Information Services (EPCIS). The network architecture is designed and administered by the standardization consortium EPCglobal, which is a joint venture of GS1 U.S. (formerly Uniform Code Council) and GS1 (formerly EAN International).
By improving the information flow, as objects pass from suppliers to manufacturers, distributors, retail stores, and customers, the EPCglobal Network aims to facilitate cooperation within supply chains and thus to make them more efficient. Once established, it could also be used to support a wide range of applications in the area of ubiquitous computing. An often-cited example is the “smart home,” in which “intelligent” cupboards and fridges could be realized using RFID technology. By scanning the RFID tags on objects and using the EPCglobal Network for information retrieval, such devices can identify their current content and offer new services like food counseling or automated replenishing of goods.
As a result of this broadened use of the EPCglobal Network, its security context would change from closed supply chains to the rather open environments of ubiquitous computingjust like the security context of the Internet was changed by moving from relatively closed groups of fellow researchers to the global environment it represents today.
In this article, we first describe the EPCglobal Network architecture, as currently specified. We then discuss its security and privacy risks, as well as possible countermeasures. We conclude with suggestions on how to improve existing design proposals, once appropriate security and privacy requirements have been established.
The EPCglobal Network Architecture
To cope with dynamic data flows on a truly global scale, the EPCglobal Network allows all relevant parties (manufacturers, suppliers, shops, after-sale service providers) to dynamically register EPCIS. This enables the flexible exchange of information about the products they are concerned with. This information will consist of EPC-encoded sensor data but also historical data and business context. For maximum flexibility and compatibility with existing enterprise IT infrastructure, the EPCIS specification framework4 includes several layers. Those define data models, service interfaces, and their concrete realizations for existing data description and transfer protocols, such as XML for business data interchange using SOAP or AS2. The EPCIS framework does not specify actual service operations or specific database implementations.
In order to locate these dynamically registered EPCIS, a static list or a single server would lead to out-of-date information and scalability problems. The EPCglobal Network therefore includes pivotal look-up services called EPCIS Discovery Services and Object Naming Service (ONS).12 Each time someone requests information about a particular object (not already present in local caches, or “stale”), these services are queried for a recent list of relevant EPCIS. After retrieving this list, the requestors directly contact the EPC Information Services they are interested in.
Thus, object information retrieval in the EPCglobal Network generally consists of three main phases (Figure 2):
- RFID Tag-to-Reader and Intranet Communication: An RFID reader reads an EPC from an RFID tag via wireless communication (1a). This EPC is transmitted to a middleware layer for further processing (1b).
- EPCIS Discovery and ONS: This phase will involve EPCIS Discovery Services (2a) that will be able to return address information of heterogeneous information sources (EPCIS) for a specific EPC,12 whereas ONS is mostly concerned with the manufacturer of the item at hand. According to relevant speculation,9 the middleware queries ONS for Uniform Resource Locators (URLs) of corresponding EPCIS of the EPC Manager, usually the manufacturer (2b). The final answer (2c) from the local ONS of an information provider is handed over to the application (2d).
- EPCIS Access: The application needs to resolve the EPCIS DNS names (3a, b) delivered by the EPCIS Discovery Services and ONS, and finally contacts the relevant EPCIS directly to retrieve the object information (3c).
Risks
From a privacy and security perspective, each of these phases presents specific challenges. Phase 1, especially the tag and reader radio communications (1a), has so far caused most concerns in the public perception.7 Though the current EPC tags (UHF Class 1 Generation 2) are equipped with some basic security functions, they do not offer access control for reading the EPC, only for write-protecting data on the tag.12 Limited tag capabilities have inspired much research on light cryptography (see Juels8 for a survey).
Concerning phase 2, the inner workings of EPCIS Discovery Services (2a) are not finalized as of yet. But ONS resolution (2b, 2c) brings about enough hard security challenges in its current design. Before we discuss these in detail, we take a closer look at the inner workings of ONS.
ONS is designed to be an application of Domain Name System (DNS). The idea is to first encode the EPC into a domain name while preserving its structure and field values (for example, 734.4012345.sgtin.id.onsepc.com for the EPC in Figure 1), then to use the existing DNS protocol and delegation procedures. The current ONS specification states that the serial number of the EPC (which differentiates items of the same kind, like two watches of the same model and manufacturer) should not be used for delegation, but leaves room for future extensions.9
Using DNS for ONS implies a potentially dangerous heritage. DNS is a central Internet service with a long history of security issues with respect to the protocol itself and its implementations.10 Some of the threats target availability (denial of service), others target the integrity of DNS information (cache poisoning, man-in-the-middle attacks). DNS, as it is commonly deployed, has no way of authenticating communication partners or the information that is provided. Further, DNS is a clear text protocol, which is necessary to use parts of a domain name for delegation purposes (2b,c). Those weaknesses directly transfer to ONS if no additional countermeasures are implemented and create risks on a new scale for processes relying on a secure “Internet of Things.”
In phase 3, the initial standard DNS lookup (3a, 3b) is subject to similar threats as the ONS resolution. Consistent with its abstract approach, the EPCIS specification4 does not include any threat models or concrete security measures. Like in the case of ONS, this is somewhat unsatisfying from a security engineering perspective where security requirements of all stakeholders should be considered as early as possible in a system development process. This would allow for fundamental design changes, and avoid a “security as add-on” mentality. On the other hand, the EPCIS service layer section4 at least mentions (optional) authentication and authorization possibilities for the EPCIS Capture and Query interfaces, again without discussing any detailed methods, and describes allowed service reactions to client identities. This includes the possibility to refuse an answer to a request, respond with less data than was requested, or with coarser grained or partitioned information.
It is reasonable to assume that authentication and, unlike ONS, encryption of the EPCIS connection (3c) could be implemented without major technical hurdles by using common Internet and web service security frameworks11if the scalability and trust problems of global cryptographic key and certificate management can be solved. However, EPCIS access, even if it is secured from third parties, involves additional risks for individual and corporate privacy.
Starting with its version 1.2, the EPC-global architecture standard12 acknowledged some security challenges. While it presents several optional add-ons related to security, it lacks a comprehensive vision discussing the privacy risks and requirements of the EPCglobal Network stakeholders in depth. Moreover, the standard often only hints at existing problems without providing satisfactory solutions. For example, though RFC 3833 is cited for DNS threat analysis, none of the risks presented there, their impact on ONS, or possible countermeasures are discussed.
Confidentiality and privacy. There are many situations where the EPC stored on an RFID tag should be regarded as sensitive informationbe it in a private context,7 where people fear to be tracked or have their belongings read out by strangers, or in a business context, where product flows constitute valuable business intelligence.
The combination of an EPC company identifier and item reference is usually enough to determine the exact kind of object it belongs to. This information can be used to identify assets of an individual or an organization. If somebody happens to wear a rare item or a rare combination of belongings, one could track that person even without knowing the actual serial numbers (Item-Cluster Tracking). For an overview of possible inferences from query data, see Table 1.
To retrieve the information stored in the EPCglobal Network about a given EPC, it is necessary to locate the corresponding EPCIS servers first. Because the EPC structure is used for delegation, it is not easily possible to use encryption in this phase.
Thus, the partial EPC (consisting of Company Prefix and Item Reference) will first traverse local area networks, potentially involving insecure wireless networks. A local network sniffer, however, could potentially also capture the complete EPC from other Intranet messages (1b, 2d).
Depending on the actual configuration of ONS caching, this partial EPC will also be transmitted to external ONS on the Internet in clear text. This process in general starts at the ONS Root.9 Finally, the query reaches the local ONS (2c) server of the manufacturer. All queried servers and Internet service providers (ISP) on the path could capture and store the partial EPC, as well as the origin (source IP address) of the query. For a very general classification of potential adversaries in terms of user coverage see Figure 3.
Even if the actual connection to an EPCIS server (3c) is encrypted, the EPCIS operator himself (such as the manufacturer) could compile profiles of the subset of EPCglobal Network users who query for information at this particular server. The initial DNS lookup (3a, 3b) could betray the object brand to an even larger set of adversaries.
Integrity. In the EPCglobal Network, integrity refers to the correctness and completeness of the returned ONS information, in particular the addresses of the relevant EPCIS, and of the object information itself (we subsume authenticity here). Attackers who control intermediate ONS, DNS, or discovery servers, or launch a successful man-in-the-middle attack on the communication could forge the returned list of EPCIS and include, for example, a server under their control. Many problematic situations could result from such a security breach. Just imagine, for example, that the query was issued by a “smart” medicine cabinet to prevent harmful drug mixes, or by a business IT system to locate special servers for detecting product counterfeits.
Availability and multipolarity. If the EPCglobal Network becomes widely accepted, an increasing number of business processes (B2B, B2C), as well as personal applications, will be able to use it without human intervention. This would leave these processes highly dependable on a working EPC resolution service for finding matching information sources. The ONS, Discovery Services, and EPCIS will be highly exposed to attacks from the Internet due to their necessary accessibility. This includes distributed denial-of-service attacks overwhelming servers by issuing a large number of queries, or targeted exploits. Especially with ONS the question was raised if its operation will allow for distributed political control, instead of being subject to power concentrations. The current ONS operator model, which favors a single company, may give grounds for economical and political power games.5
Therefore, an integration of the EPCglobal Network (as proposed) into core business processes would increase the dependency of corporations on the Internet and external companies, leading to higher operational business risks.
Countermeasures and Their Effectiveness
In the following, we discuss some countermeasures to mitigate the indicated risks. For a preliminary and very general evaluation of their effect and practicality, see Table 2. Some of these methods could be combined to create alternatives to the current EPCglobal Network design.
VPN. Closed groups of business partners who run a private version of the EPCglobal Network may be able to reduce their confidentiality and integrity risks by using extranets over Virtual Private Networks (VPN). This solution, however, would not scale to the general case of a dynamic global exchange, given the known scalability issues and administrative overhead associated with VPN.
TLS. Using Transport Layer Security (TLS) could solve problems of EPCIS confidentiality and integrity if an appropriate global trust structure could be established, but it would negatively affect the performance of the initial look-up process via ONS and Discovery Services.
DNSSEC. DNS Security Extensions (DNSSEC) are an approach to address some of the security shortcomings of DNS. DNSSEC provides origin authenticity and data integrity (but explicitly no confidentiality1) for the delivered information by using public-key cryptography. DNSSEC has not been widely adopted in practice so far, though recent developments like the signing of important top-level domains may indicate an increase in interest. Reasons for the slow adoption include scalability problems of key management, difficulties in building the necessary chains of trust between servers of many different organizations, and the crucial question who should control the root of trust. Finally, reasonable reservations exist to touch a running critical system, because many IT applications depend on DNS in unexpected ways. DNSSEC could assure ONS information authenticity on a global scale if the Internet community as a whole adopts it, since ONS may return arbitrary DNS names for EPCIS. Otherwise, membership in the EPCglobal Network would remain small, and its impact on global information exchange greatly diminished.
Onion routing. The key idea of onion routing systems such as Tor3 is to cryptographically transform and mix Internet traffic from many different sources, in order to hamper matching a particular IP packet to a particular source. For ONS and Discovery Services, usability would probably be affected by latency and performance issues. However, such approaches could also be used to anonymize traffic directed at EPCIS servers. This could enhance anonymity and perhaps confidentiality, but not the integrity of the received messages. In addition, conflicts between anonymity and identification needs for EPCIS access control will need to be solved.
Private information retrieval. Private Information Retrieval methods could in principle be implemented to obfuscate which client is interested in exactly what kind of information, once the EPCIS have been located. But in the case of a globally distributed look-up system (like ONS), problems of scalability and key management, as well as performance issues, seem to render this approach impractical.
Multipolar ONS. Recent research on ONS has produced some alternative root designs, such as Multipolar ONS (MONS)5. This approach still uses DNS for ONS for compatibility but decentralizes the ONS root to avoid unilateral control about it. Used together with DNSSEC, this approach offers higher availability and integrity than standard ONS but is not designed to fulfill confidentiality or anonymity requirements.
Peer-to-Peer systems. Massively decentralized alternatives to classical network service architectures exist in the form of Peer-to-Peer Systems (P2P), especially structured P2P systems using distributed hash tables (DHT).2 They offer robustness to faults, avoid single points of failures (e.g., they have no single root like DNS), and distribute load among participants more evenly. With ongoing projects like CoDoNS10 that build alternatives to classical DNS, ONS and EPCIS could also be based on DHT.6 Just switching to a P2P architecture, however, will not guarantee integrity and confidentiality, but enhances anonymity by increasing the number of nodes an adversary would have to monitor.
Conclusion
Like in the case of RFID wireless communication, true security is sorely lacking in the design of the EPCglobal Network and especially the ONS so far. It is likely that the final design of the EPCglobal Network will include some kind of central certificate authority (CA), which is indicated by the use of X.509 certificates and the EPCglobal core service “Subscriber Authentication.”12 How scalable this will turn out in real global applications, remains unclear. Moreover, such a CA would constitute another single point of failure and would have to be trusted by all current and future parties involved. The forthcoming EPCIS Discovery Services should be designed carefully, as they are about to introduce major privacy risks (global coverage, transfer of the full EPC).
Instead of adding another level of functionalities to the already burdened and insecure DNS, implementing an “Internet of Things” should be regarded as an opportunity to phase in new technologies (such as P2P) into the Internet infrastructure. Before deploying systems at a global scale that have a possible impact as de facto standard for years to come, it is essential to perform a thorough analysis of multilateral security and privacy requirements, involving the current and potential future stakeholders. As we have learned with the Internet, adding security as an afterthought is usually a very bad idea.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment