A Solution for Resource Service-Discovery Challenges within the Internet of Things.
By now, most of us are familiar with the concept of the Internet of Things (IoT). With the surge of systems and devices flooding the IoT, engineers are struggling with the challenge of interoperability. The effectiveness and intelligence of IoT use cases rely on data being shared between all different types of devices on a large scale. Communication protocols such as MQTT and XMPP are well known and can be applied to IoT use cases, but another important interoperability component is resource discovery. There is no point in communicating with a device if you cannot first determine what kind of information is available. If different devices all perform resource discovery in a different way, with a different data format, interoperability at scale would be an engineer’s worst nightmare. Consequently, a group of companies formed the Hypercat Alliance to address the need for a standard in this area.
Hypercat was developed under the IoT Ecosystem Demonstrator program as a solution for IoT interoperability and data sharing. Research and development of Hypercat was carried out by over 40 UK companies including BT, ARM and Rolls Royce under HyperCat consortium on a grant of £8 million funded by the UK government Technology Strategy Board (now called Innovate UK).
Hypercat provides information on how to structure data repositories’ catalogues and offers standard ways of sharing them across different domains over web technologies. It creates an interoperable system and a means of resource discovery for IoT systems. Using this protocol, developers can make applications that discover suitable services and obtain data from different repositories.
As demonstrated in Figure 1, Hypercat-based interaction starts when an application uses HTTP/S to send a request to the Hypercat server (1). The requester then receives a HyperCat file consisting of the catalogues of available resources (2). The application can interact with those resources (3) in the way specified in HyperCat protocol. A catalogue provides a list of resources, and some information about how to interact with them. HyperCat defines standard response format for catalogues and metadata within a catalogue and an API for interacting with the catalogue to search, insert and remove items. To read a catalogue, clients GET the catalogue URL in JSON object format from the server. To insert/create an item, they can POST an item in JSON object format to the catalogue URL. To update an existing catalogue item, clients can PUT or POST an item object to a catalogue URL.
Each catalogue uses a set of relation-value metadata. A set of mandatory metadata exists for each Hypercat item. Developers can also add non-mandatory metadata to the catalogue as needed, which increases Hypercat’s flexibility and extensibility.
Hypercat shares some common goals with other service-discovery tools in the context of service oriented architecture (SOA). As a results, the objectives and ideas of Hypercat resemble those of Universal Description Discovery and Integration (UDDI) and Web Services Description Language (WSDL). While the goals are the same, there are various differences. For example, Hypercat is mainly based on JSON/RESTful web services while WSDL is based on XML/SOAP (See this link for a more detailed description of the differences).
Threat Modeling of Hypercat Workflow
According to NIST 800–95, threat modeling should be considered when designing a system to prevent variety of vulnerabilities and security issues. It helps detect flaws and analyze weak components of an attack surface toward the design and implementation security controls. Threat modeling can be employed for a variety of Hypercat components including domains, servers, data repositories or catalogues and metadata. The distinction between protecting the resources and protecting the catalogues is essential.
A common tool for threat modeling is the STRIDE method, which groups threats into categories of Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. A STRIDE exercise commonly begins with the analysis of the data flow diagrams in a system. A look at Figure 1 helps us identify the main weaknesses and requirements for securing Hypercat interactions (SD Elements, as an enterprise security requirements management platform, provides more comprehensive security requirements for Hypercat projects) . With less emphasis on the process and just to report some results, these are the main security requirements for using Hypercat:
- Prevent information disclosure: At Security Compass, we advise against unrestricted access to WSDL. Consider that web services frameworks sometimes generate a WSDL automatically and publish that WSDL to a browseable URL. Attackers can use the WSDL to gain an understanding of the web services that will help them craft their attacks. Where possible, disable automatic publication of WSDLs unless there is a legitimate business reason not to. This exposure contributes to Denial of Service attacks, and other weaknesses.
- Guard against spoofing: Authentication can be used to prevent spoofing or impersonation. Authentication in Hypercat can be performed by using a valid key (such as a single time token) that can provide access to an entire catalogue or just a part of it. “accessHint” metadata clarifies the authentication methods and its linked resources. The Presence of multiple “accessHint” elements in a Hypercat catalogue indicates that there are multi-authentication factors for accessing the resource. This metadata could point to an invalid resource, and therefore only an “accessHint” which belongs to the same domain as the Hypercat catalogue should be trusted by clients. A key point here is that the purpose of Hypercat authentication is to protect access to the catalogues, and not the resources that they point to. The resources need to have their own security guards and probably their own authentication mechanisms. Hypercat can only help the applications to find the suitable resource. It is the responsibility of those resources to protect themselves.
- Prevent Tampering: Catalogues, and items within them, can be digitally signed to provide more confidence over their sources and to prevent tampering. Digital signatures can either be used for an individual item (that may have the signature added to the item-metadata with the digest for that item), or the entire Hypercat document (that has the signature added to catalogue-metadata with the digest for all item-metadata and the catalogue-metadata). A public key is required to verify the signature. To the greatest possible extent, only use resources with license and access control metadata. “hasLicense” metadata can be used in both catalogue-metadata and item-catalogue to clarify the license conditions of the Hypercat item and its linked resources.
The point worth reiterating is that you should protect each resource and you should not rely on the fact that the resource location is unknown to adversaries (security by obscurity). Protect access to the resource itself, through authentication and use of encrypted channels. Hypercat documents state that “one should not rely on ‘security through obscurity’ in HyperCat…HyperCat security does not protect Resources”.
In conclusion, Hypercat helps to unify service and resource discovery in IoT, and makes it easier for engineers to design and develop systems that achieve interoperability on a large scale. Although Hypercat has some security features, it is important to be aware of the possible threats, and take the necessary steps in design and development to avoid them. If we build security in from the start, we can do this in a cost effective manner that results in safer devices and systems for our customers.
Share this Article on Linkedin
Resources for this article:
- https://connect.innovateuk.org/web/internet-of-things-ecosystem-demonstrator
- https://www.youtube.com/watch?v=xe7WWCtEBUE
- http://www.hypercat.io/standard.html
- http://iot.ieee.org/newsletter/january-2016/hypercat-resource-discovery-on-the-internet-of-things.html
- https://www.youtube.com/watch?v=6Ps8iEGRi1U
Authored by
Mina Miri, Application Security Researcher, Security Compass
Farbod H. Foomany, Lead Application Security Researcher, Security Compass