Proposed IoT framework using third party with enhanced security

Blockchain for IoT security and privacy: The case study of a smart home and Data Security and Privacy Challenges in Adopting Solutions for IOT
Dr.MohitBansal Profile Pic
Published Date:26-10-2017
Your Website URL(Optional)
Trustable Fellowships of Self-Organizing “Things” and Their Software Representatives: An Emerging Architecture Model for IoT Security and Privacy11.1 Introduction Many Internet of Things (IoT) challenges will require more than incremental solutions or the application of models already established. New architectural models will be demanded, since the current cloud and networking technologies and their protocols are inherently limited for several expected scenarios 25. Some examples we will address in this chapter are entities naming, identification, mobility, decoupling of devices’ identifiers from locators, scalability, control and management, data integrity, provenance, and joint physical and virtual resources orchestration, among others. Current Internet naming is very limited and does not favor security 6, 14, 36. Unique identification of “things” is nonexistent. Name resolution is limited to resolve domain names to Internet protocol (IP) addresses. There is no support for service names, among many other relevant names for IoT scenarios. Nam- ing has also an important role in data integrity and provenance, as we will further discuss. Host mobility causes variations to services session states 5, leading to unsta- ble application behavior. IP addresses have two simultaneous purposes: host identification and location. When a node moves from one network to another, its location should change to enable datagram delivery to new position; however, the IP address change affects upper-layer sockets, which employ IP addresses as host identifiers. Identifier/locator splitting is an approach that enables nodes to move without changing their identifiers, maintaining session state invariance 5. The scalability of addressing and routing in the current Internet are also concerns 5, 6, 14.Self-Organizing “Things” and Their Software Representatives  271 Joint orchestration of physical-world resources, services, and contents is also a requirement far ahead of current Internet support. The current model for device control and management was designed in an epoch where the number of devices was orders of magnitude smaller. Control and management in the IoT scenario will require self-driven approaches, reducing operational costs and meeting the upcoming scales on device numbers, interactivity, and traffic. Emerging convergent information paradigms will be required to face these issues in the next decades. Incremental solutions could be intrinsically limited, since they were not projected with any thought for the amazing interaction between physical and virtual worlds we are going to experience in a few years. Many science-fiction scenarios are becoming real at an impressive speed. Biometric sensors, implants, monitoring devices, wearable electronics, smart clothes, residences that welcome us and make our lives easier are among the tech- nologies that are arriving. Augmented reality, tactile systems, haptic interfaces, virtual reality, cyborgs, robotics, self-assembly machines, ubiquitous computing are examples of technologies on the border between the physical world and com- puting systems. In this chapter we discuss the path to a futuristic scenario, where these emerg- ing technologies converge synergistically, gracefully, quietly. We discuss security issues from an architectural perspective, instead of specific points (as is usually done in the literature). We start with a survey of some important current archi- tecture limitations that could limit IoT potential (Section 11.2). We also present contemporary paradigms that are emerging in the literature to address these iden- tified shortcomings. Then, we present a new IoT architecture model that inte- grates these paradigms toward a future IoT architecture (Section 11.3). In this model, “swarms of things” are represented and controlled by trustable “swarms of services,” which self-organize to establish the required security, pri- vacy, and trust levels. Since the number of devices expected is going to be extremely high, more autonomic behavior is expected 28, reducing the degree of human intervention on the control and management of IoT devices. The role of naming and name resolution will be revisited and related to source authen- tication, as well as data integrity and provenance. The support for distributed storage of name bindings enables the representation of real-world relationships among things, services, and contents. What is required is the integration of the life cycling physical resources, contents, and services, life cycling using emerg- ing trust-based security and privacy approaches. This emerging architecture model is being developed in the context of an information and communications technologies (ICT) architecture called NovaGenesis (NG) 1. NG started in 2008 and aims at integrating many future Internet (FI) ingredients toward a convergent information architecture (CIA). A CIA integrates in only one design information processing, storage, and exchange 2. It is broader than an Internet, which was designed to put computer networks272  Security and Privacy in Internet of Things (IoTs) Convergent information architecture Internet Cloud architecture computing architecture Operating systems architecture Figure 11.1: Operating systems and cloud computing architectures are focused on computer nodes, that is, intranode information processing, storage, and exchange. Internet architecture emerged to interconnect computer networks, that is, global internode information exchange. Convergent information architecture integrates all previous information processing, storage, and exchange architectures with global scope. together, enabling end-to-end computer programs (processes) to communicate. CIAs address IoT challenges more deeply than the current Internet, since IoT requirements spread not only through networking technologies, but also through cloud, distributed, and mobile computing. Figure 11.1 illustrates this idea. NG is a CIA that integrates information-centric networking (ICN) 38, service-centric networking (SCN) 8, service-oriented architecture (SOA) 26, software-defined networking (SDN) 1, 20, among other ICT hot topics. In NG, context-aware services establish contract-based coordination toward fulfill- ing network operator objectives, rules, and regulations. Energy awareness and disruptive/delay tolerant communication is enabled. IoT devices, services, and contents are named and synergistically integrated to address the most challeng- ing IoT prerequirements. NG proposes a new control and management model where physical devices are represented by named services called proxy gate- way controllers (PGCs) 1. These PGCs expose node capabilities, negotiate and establish contracts, encapsulate NG messages, and configure devices according to software-implemented controllers. NG has an experimental proof-of-concept implemented. Several aspects of the proposed model have already been tested. In this context, this chapter finishes with Section 11.4 with an example scenario, where an illustration of the proposed architecture is provided based on current proof-of-concept design. Internet of thingsSelf-Organizing “Things” and Their Software Representatives  273 11.2 Current Technologies Limitations and Emerging Solutions for IoT Nowadays, technologies for the IoT are already available, among them 24:  IEEE 802.15.4: This is a wireless communication standard for low- power, low-data rate, and short-distance radio coverage sensor and actua- tor networks 15. It was developed within the IEEE 802.15 personal area network (PAN) group. Its typical data rate is 250 kb/s with maximum packet size of 127 bytes, which limits the available payload to about 86 and up to 116 bytes. It defines a physical layer (16 channels with direct sequence spread spectrum) and media access control (MAC) layer. It can be applied to multihop networks, but requires the radio to be on all the time. It employs single-channel operation, which suffers with multipath fading and shadowing.  IEEE 802.15.4e: This employs a time-synchronized channel hopping (TSCH) technique to avoid interference, shadowing, and multipath fad- ing 24. The IEEE redesigned MAC protocol supports centralized or distributed scheduling of time slots for communication between neigh- boring nodes. A time-frequency structure is used to create virtual links among neighboring stations using specific time slots/frequency channels. The standard does not define how the schedule of the time slot/frequency pairs for a certain virtual link is carried out.  Message queue telemetry transport (MQTT) 17: This is a “lightweight” messaging protocol to run over the transmission control protocol/In- ternet protocol (TCP/IP). It follows a publish/subscribe hub-and-spoke paradigm where a broker server asynchronously forwards messages to one or more interested nodes. Named topics are used to share infor- mation. All messages addressed to a named topic (e.g., “myhome/ groundfloor/livingroom/temperature”) by publishers will be delivered to a broker. Subscribers to a certain topic get published information from the brokers. It provides an agnostic binary payload. Nodes must connect to brokers.  Advanced message queuing protocol (AMQP) 35: AMQP is an open standard message middleware specification, based on a topic-oriented message queue paradigm, where products written for different platforms and in different languages can exchange messages. Despite being a stan- dardized protocol, not all implementations are fully compliant with the standard. The complete AMQP standard is composed by publishers, sub- scribers, and brokers that have internal routing capabilities. The AMQP specification (version 1.0) defines a wire-level protocol for publish- ers’/subscribers’ communication with their message brokers. The broker can modify incoming messages and, based on a set of rules or criteria,274  Security and Privacy in Internet of Things (IoTs) IETF CoAP IETF CoAP IETF TCP/UDP IETF UDP/TCP IETF IPv6 IETF IPv6 IETF 6LoWPAN IETF 6LoWPAN IETF 6top IETF 6top IEEE 802.15.4e MAC IEEE 802.15.4e MAC IEEE 802.15.4 PHY IEEE 802.15.4 PHY Figure 11.2: Possible IoT stack combining IETF and IEEE standards. decide to which queues the messages need to be forwarded to arrive at one or more subscribers.  Data distribution service (DDS) 27: DDS has a global data space (GDS) to where nodes can publish/subscribe to (pub/sub) data using topics and keys. Data objects are manipulated using natural language. Local object caches can be fed by available global data. There is also support for quality of service (QoS) contracts. DDS provides automatic discovery of publishers and subscribers using a protocol called simple discovery protocol (SDP).  Internet Protocol version 6 (IPv6) over low-power personal area network (6LoWPAN): IPv6 packets are too big for IEEE 802.15.4. 6LoWPAN provides an adaptation layer to segment and reassemble IPv6 datagrams. It provides IPv6 header compression and belongs to the Internet engi- neering task force (IETF) stack for IoT 34, as illustrated in Figure 11.2. 6LoWPAN protocol data units (PDUs) can be encapsulated directly over IEEE 802.15.4. However, for 802.15.4e the 6top adaptation protocol was created.  6TiSCH operation sublayer (6top): IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) provides the mechanism to admit or revoke a node from a TSCH network, including the scheduling of virtual channels to this node using available time slots/frequency channels with neighboring nodes. It also makes the adjustments to support the IETF routing protocol for low-power and lossy networks (LLNs) (RPL) over 802.15.4e nodes.  Constrained application protocol (CoAP): Provides a specialized web transfer protocol for LLNs that conforms to the REST style. There is a uniform resource identifier (URI) for every device. Contrary to the hyper- text transfer protocol (HTTP), it employs the user datagram protocolSelf-Organizing “Things” and Their Software Representatives  275 (UDP) instead of TCP. It enables asynchronous message exchange with low complexity parsing. HTTP-CoAP mapping is standardized.  GS1 EPCglobal: EPCglobal is a GS1 initiative to develop industry- driven standards for the electronic product code (EPC) to support the use of radiofrequency identification (RFID) in today’s fast-moving, information-rich, trading networks. In particular, EPC information ser- vices (EPCIS) is an EPCglobal standard designed to enable EPC-related data sharing within and across enterprises. In this way, at least, data cryp- tography is pertinent when transferring data between different compa- nies, since common Internet links are used in this case. MQTT is typically used for machine-to-server (M2S) scenarios, while AMQP is typically employed on server-to-server (S2S). DDS is focused on machine-to-machine (M2M) communications. While MQTT does not support real-time operation, DDS is focused on supporting timely data distribution among devices. Concerning the relation with the current Internet, MQTT and AMPQ relay on TCP/IP sockets, while DDS specifies a reliable real-time pub/- sub wire protocol DDS interoperability wire protocol specification (DDS-RTPS) aimed at a UDP/IP stack or other data encapsulations (TCP/IP or direct shared memory inside a node). Besides the traditional TCP/IP stack, CoAP can also run over 6LoWPAN. MQTT also enables the bypassing of TCP/IP by using a modified standard called MQTT for sensor networks (MQTT-SN). This standard supports direct transport of MQTT-SN messages over 6LoWPAN or even ZigBee. AMQP con- nections are always established by publishers/subscribers to the message bro- ker. First, they must open a TCP socket and the initial exchanged messages define the capabilities and limitations of each side. For constrained networks, it could be expensive to exchange this information on each connection, so AMPQ has a mechanism to omit some negotiation messages on consecutive connec- tions. Although the dependence on the current Internet stack brings a lot of benefits, it also has a number of limitations, as we shall see in the following subsections. A common aspect of MQTT, AMQP, and DDS is the adoption of the pub/- sub communication paradigm. In this paradigm, information owners (principals) publish measured data to authorized peers. The interoperability between publish- ers and subscribers can be a problem in MQTT, since the message payload format needs to be agreed among peers before any data transfer. DDS is an example of pub/sub being applied to mission-critical applications, where constrained delay is required. A challenge here is to deal with a large number of pub/sub nodes. Kyoungho An et al. 4 explore the scalability of the DDS pub/sub discovery protocol. Pub/sub has a direct relation with architecture security and privacy. The IETF stack for IoT does not adopt the pub/sub model. Rather, it is based on the classical request/reply model.276  Security and Privacy in Internet of Things (IoTs) Considering particularly the logistics and supply-chain field, we can high- light the adoption of the EPCglobal Class 1 Gen 2 standard 18, which pro- vides the notion of the EPC to uniquely identify a physical object stored in an RFID tag. Briefly, the main objective of EPCglobal is to provide an architecture to collect vast amounts of raw data from a heterogeneous RFID environment, filter them, compile them into usable data structures, and send them to com- putational systems. To accomplish this, EPCglobal defines the following compo- nents 30: (i) RFID readers (also denoted as RFID sensors); (ii) application level events (ALE) for filtering and collecting EPC data; (iii) EPC information services (EPCIS) to store EPC data, as well as to exchange this data along the EPCglobal network; (iv) EPC capturing applications, as a box-in-the-middle between ALE and EPCIS, regulating how the former sends data to the latter. Each company has its own set of components, so the idea is to generate value by providing a standard way of capturing data from objects between the partners involved in a particular application field (including, for example, suppliers, enterprises, resellers, clients, buildings, and users). Given the potential size of the data generated by sensors and related devices, a trade-off will need to be found between in-network processing and aggregation techniques versus streaming data to the external support system. This trade-off is not an easy one. It depends on the capabilities of the distributed sensor network, the communication channel between sensor network and support system, and the support system itself. In some cases, a networking delay or the intermittent connectivity could hinder external support, requiring more computing power at the IoT nodes. This balance may affect the amount of energy spent on nodes, limiting the energy they could spend on security issues. In the following subsections, we will analyze how these technologies relate to emerging paradigms for future ICT architectures. The idea is that the IoT faces the same challenges that the current Internet does. We will highlight some of the aforementioned technologies’ limitations from the perspective of these state-of- the-art paradigms. We contend that more synergistic approaches are required to maximize IoT potentials. 11.2.1 Naming and name resolution Names inhabit the human mind. People like to denote things by names. Names are symbols used to denote one or more individual existences. In this case, to denote means to represent something by signals. By definition, names denote meaning and sense. However, there are names that are almost randomly gener- ated, having “weak semantics.” One can call a car “xyzwertyu”; however, this name makes sense only for the owner or other closely related people that have been introduced to it. Another example: One can denote a car by a sequence of symbols that typically carry “weak semantics,” that is, the numbers and letters on its license plate (e.g., 1ABC234 in Figure 11.3). Or yet, one can call a carSelf-Organizing “Things” and Their Software Representatives  277 525 Esplanade, Hash 4,6 Chico, California Hash 1 Hash 2 Locators 39°43´ 56.47˝ N Hash 5,7 121°50´ 36.53˝ W Bidwell Raymond PID = 321, ../Readme.txt, 1ABC234 Mansion Kurzweil Hash 6 Hash 7 Identifier Serial 1, Serial 2, Hash 4 Hash 2 Hash 3 Hash 1 Hash 5 Readme.txt PagesTM Bidwell Mansion PID = 321 /home/Readme.txt Bugatti TM Hash 6 Hash 7 525 Esplanade, Veyron Raymond Names Chico, California Kurzweil TM TM 1ABC234 iPAD Nexus N5 39°43´ 56.47˝ N 121°50´ 36.53˝ W Serial Serial Hash 2 Hash 3 number 1 number 2 Hash 1 Hash 5 Hash 4 Services & contents Physical individual existences Figure 11.3: People attribute “weak semantics” and meaningful names to physical (e.g., a car or a house) and virtual existences (a computer program or a file). If they are unique in some scope, they can be used as identifiers and locators. There- fore, bindings among names (or name bindings) can capture all sort of relationships between virtual and physical existences. They can represent semantic relationships like “contains,” “is contained,” or “close to.” In this example scenario, the car is “close to” the house, and “contains” the tablet and smartphone. Also, the person “is contained” in the car. by its brand, for instance “Bugatti Veyron,” which has more “strong semantics.” A last example is the binary word obtained at the output of a hashing algorithm. This binary word (also called hash code) can be used as a name—a self-verifying name (SVN). In this case, the binary input of the hash function can be the phys- ical existence of an item itself (e.g., computer program executable, source code, or information files) or other binary input related to the entity being named (e.g., entities’ immutable attributes). In the first case, the name is said to be self- certifiable, because at any time the existence’s binary words can be hashed again278  Security and Privacy in Internet of Things (IoTs) to get exactly the same name. In the second case, the perennial physical exis- tence attributes can be digitalized again to certify the name. Figure 11.3 illus- trates some hash names calculated for physical and virtual existences. “Hash 1,” for example, can be obtained from the perennial attributes of “Bidwell Mansion” in the USA, such as its physical proportions. “Hash 2” can be obtained from car attributes, like the chassis number or serial numbers. “Hash 3” could be based on the biometrics of human body. “Hash 4” may be obtained from device serial numbers or processors’ unique IDs. “Hash 6” may be generated from entire exe- cutable binaries. Emerging paradigms, like information-centric networking (ICN) 12, 14, 38 and service-centric networking (SCN) 3, 8, 37, put naming at the core of architecture design. According to these approaches, the host-centric Internet is no longer appropriate for modern requirements, like content distribution, in-network caching, name-based routing, name resolution, and named-services chaining. By name-based routing we mean a routing approach that uses content or service names instead of IP network addresses in packet headers. Name resolution means to locate an entity by its name, as with in the current Internet where domain names are resolved to IP addresses. Name-based service chaining means to cre- ate a chain of services using their names instead of their locations. These authors contend that contents and services should be named directly, independently of host naming. Sockets and uniform resource identifiers (URIs) are too limited for this. The only way to implement these new ideas on the current Internet is to use the World Wide Web as an overlay. What these paradigms defend is to replace the current TCP/IP stack “narrow waist” by names. The current Inter- net naming solution, either v4 or v6, will have a great impact on the IoT. The IoT also requires the aforementioned improvements, for instance, information objects naming, in-network caching or named-services chaining, to improve its efficacy, security, provenance, mobility supports. Some of the current IoT technologies propose incremental solutions to overcome Internet naming limitations. MQTT employs a unicode transformation format (UTF-8) string to create hierarchically named topics that facilitate pub- lishers’ and subscribers’ meeting. The MQTT brokers filter messages according to the topics. A topic example is: “Brazil/Minas Gerais/Santa Rita do Sapucai/ Inatel/Room II-17/temperature.” However, MQTT topics fall into the human- readable names category 14 and therefore suffer from: (i) weak binding to the real-world entity that produced the information; (ii) security dependence on name trustworthiness; and (iii) vulnerability to phishing attacks where malicious names are created similar to real ones to confuse people. Sastry and Wagner analyzed security issues for IEEE 802.15.4 32. Addresses are IEEE-defined 64-bit extended unique identifiers (EUI-64). These addresses contain numbers that identify organizations and companies behind nodes. Since IEEE is directly involved in generating these IDs, improved name binding to real-world authority is provided. The same is true for IEEE 802.15.4e.Self-Organizing “Things” and Their Software Representatives  279 IPv6 addressing is considered by many people as the main claim to change between IPv4 and IPv6. This is due to the depletion of globally valid IPv4 addresses. IPv6 is used for naming hosts. Due to its large size (128 bits), 6LoW- PAN emerged. The IETF 6top standard allocates 16-bit identifiers for nodes that join a network. It is not clear how these IDs are generated. CoAP URIs are defined as: coaps: host: port/path query. Observe that a URI has the same dependence on host names. CoAP follows the classical request/response model of HTTP. IETF standardized HTTP-CoAP (HC) mapping using proxies. TCP connections need to be mapped to UDP segments in the HTTP to the CoAP direction. URI mapping is required to map URIs between two different protocols—a complex task—an example that adopting two stacks can create more complexity. The DDS global name space (GNS) provides data-centric communication among nodes. Data objects (content) are addressed by topic name and key. Com- munication among publishers and subscribers only happens if there is a topic match. DDS topics can have different syntaxes and are specified using script programming languages, such as interface definition language (IDL), extensi- ble markup language (XML), or unified modeling language (UML), among oth- ers. Topic names are typically natural language strings, like “TempSensorTopic” for a temperature-related topic. Topic names are bound to domains, which have 32-bit integer identifiers. The key is also an integer used to identify records of the same topic. These examples illustrate the diversity of naming in IoT technologies. Nam- ing has an important role in the security and privacy of ICT architectures, and the IoT is no exception. Ghodsi et al. 14 contend that self-verifying names (SVNs) have better security properties than natural language names (NLNs), since they allow straight verification of the binding between name and entity. The conver- gence of SVNs and the IoT are two topics which are largely underexplored nowa- days. None of the aforementioned technologies use SVNs right now currently and many cannot use them even if desired. This is a huge gap to be overcome for the IoT. 11.2.2 Identifier/locator splitting Names can be used as identifiers if they are unique in some scope. The scope can be a domain, a city, or a country, and so on. Therefore, to be used as an identifier in some scope, a name must be unique in that scope. For example, in a certain small city, the name “John Smith” can be used as an identifier, while in other major cities more than one person could have this name. Thus, we can define an identifier as symbols used to unambiguously identify some individual existence from others to some extent. The name “Raymond Kurzweil” identifies the famous entrepreneur and inventor worldwide.280  Security and Privacy in Internet of Things (IoTs) A locator denotes the current position at which an individual existence inhab- its or is or attached to in some space. A space is the set of all possible positions which some individual existence can inhabit or be attached to. Therefore, from a certain space definition, one can determine how close or far apart two exis- tences are. Interestingly, a name can be a locator if it is possible to derive notions of distance from its interpretation. For instance, a geographic coordi- nate systems is composed of three names: latitude, longitude, and elevation. In Figure 11.3, consider the famous “Bidwell Mansion” in the USA. The name ◦ ′′ ◦ ′ ′′ “39 43’ 56.47 N121 50 36.53 W” can be used as a locator for this physical existence, as well as the address “525 Esplanade, Chico, California.” Even the identifier “Bidwell Mansion” may be used as a locator if it is unique nationwide. Interestingly, using some mapping system it is possible to derive the notion of ◦ ′′ ′ distance between the entities named as “Bidwell Mansion,” “39 43 56.47 N,” and “1ABC234.” The IP network address has a double functionality 5. It works not only as a locator for datagram routing on an IP network (or subnetwork), but also as a host identifier for upper layers on a TCP/IP stack. The IP address is a component of Internet sockets, together with port numbers and the information about the used transport layer protocol (TCP or UDP). Services identify other target services using sockets. Thus, when a computer moves from one network to another, its IP address changes, affecting established sockets, generating instability in the session state 5. Also, observe that this solution enmeshes service names with host locators, hindering services to communication independently of host loca- tions. In addition, it makes identifiers opaque, since they will be restricted to autonomous systems—behind a network address translator (NAT) barrier. With ID/LOC splitting, IDs are used by the application and transport layers to identify a node, while the locators are used by the network layer to logically locate them in the topology and route packets to/from the nodes. Mobility is supported by rebinding the name used to identify the node to the new locators. Figure 11.4 illustrates the current situation of Internet node mobility and what would be a future solution with SVNs as IDs and LOCs. The majority of current IoT technologies do not support ID/LOC splitting for sensor and actuator nodes. The exception could be 6LoWPAN with mobile IPv6 (MIPv6). Montavont et al. 22 contend that MIPv6 can be successfully used together with 6LoWPAN. Kim et al. 19 propose an approach for mobility support on wireless sensor networks (WSNs) using ID/LOC splitting. They also contend that ID/LOC splitting can be supported by IoT nodes despite its energy fingerprint. Regarding IoT services, CoAP does not decouple URIs from locators. DDS employs SDP for service discovery. SDP is based on special topics to provide service advertising and discovery. Therefore, it supports identifiers decoupled from underlaying network locators. For this, topic names should be mapped to DDS-RTPS locators.Self-Organizing “Things” and Their Software Representatives  281 Today ID= ID= LOC= LOC= Local network 1 Local network 2 F Fut utur ure e ID=FFFF12211243865… ID=FFFF12211243865… LOC=FEFEF1421412411… LOC=AAAA2734573453… Local network 1 Local network 2 Figure 11.4: In the current Internet, when a node moves from one network to another, its IP address changes (from to, affecting the node ID and LOC. There is no problem with changing the LOC, but changing the ID causes inconsistent states in upper-layer applications. In future architectures, the ID and LOC are decoupled. The ID never changes unless the entity itself changes. Many emerging ICT approaches use SVNs as IDs or LOCs, but this is far from reality in the IoT panorama. One can expect that a significant portion of IoT devices will be mobile. Therefore, IoT architectures should support devices ID/LOC splitting. However, networked devices are not the only things that will move in IoT scenarios. Mobil- ity of services is also a prerequirement. Service ID/LOC is a widely unexplored problem on in Internet-based SOA. IoT services need to have perennial IDs, mak- ing them accessible independently of their locators. In addition, to improve trace- ability and provenance of information, unique identifiers for services and devices are required. An IoT with NAT creates opaque IDs, which discontinue end-to-end traceability. 11.2.3 Resources, services, and content orchestration We envision the challenge related to spontaneous interactions among devices and the support of a distributed system for that. For example, associations between devices are routinely created and destroyed by identifying and locating a device, such as a sensor. According to Presser et al. 28, the idea of “social devices” requires not only the unique identification of nodes, but also the nodes’ capacity to discover peers and establish trustable relations, including service-level agree- ments (SLAs).282  Security and Privacy in Internet of Things (IoTs) The DDS standard provides mechanisms to expose node interests, as well as the kind of information each node can provide. DDS automatically connects to subscribers to topic-related publishers. Also, the nodes (or a support system) must be capable of semantically interpreting information, allowing them to col- laborate with each other toward a common objective. MQTT provides a similar topic-based coordination among services. Interestingly, MQTT-SN allows mul- tiple broker discovery. CoAP provides representational state transfer (REST) 7 web services ade- quate for LLNs. REST-style resource discovery on constrained environments was defined in IETF RFC 6690 33. This RFC proposes the concept of constrained RESTful environments (CoRE), which aims to perform efficient REST suitable for current IoT nodes. The aim is to discover IoT resources behind a CoAP web server, as well as their attributes and formats. The responses to queries are CoRE- specific links that identify and provide metadata about IoT resources. CoRE pro- vides the means to create IoT-resource directories. The IoT requires joint orchestration of physical resources (sensors and actu- ator nodes), services, and content/information. Current technologies implement the orchestration of these separately, duplicating systems to deal with the life cycle of each of these architectural components. The support for natural language names (NLNs) is required for “semantic- rich” orchestration. However, NLNs need to be bound to SVNs, to provide increased security, as previously discussed. The dissemination of unencrypted NLNs or SVNs to express intent can violate users’ or nodes’ privacy. While disclosure of topics of interest is fundamental to the exchange of contextual- ized information, the public disclosure of all interests may affect people’s and machine privacy. In addition, SLA support for the orchestration of physical resources and ser- vices is missing in all approaches. It is required to tie peers together and create trust networks among IoT resources/services. The absence of agreements govern- ing the degree of privacy and confidentiality among publishers and subscribers is noticeable in current standards. Content processing, exchange, and storage need to be governed by secured contracts (SLAs), which create the required trust net- works for reliable, private, and secure operation, control, and management. Physical-world resources need to be securely exposed by software, which represent them and negotiate SLAs with trustable peers. This process needs to be more automatic, less dependent on human interference. This is very important to meet the impressive IoT scales we are going to achieve in the next decades. The secure, integrated life-cycle management of services and contents, together with physical resources, will require innovative approaches and is required for the success of the IoT. Reputation systems, trust network formation, entities’ social behavior, innovative distributed algorithms, naming, name resolution, and many other emerging approaches should be elegantly inte- grated. The balance between expressiveness, “semantic-rich” exposition andSelf-Organizing “Things” and Their Software Representatives  283 subscription, constrained resources, and security issues poses a fantastic chal- lenge for designers of future IoT technologies. 11.2.4 Security, privacy, and trust The IoT, as a distributed system, would have the same performance hurdles and security threats as distributed mobile ad hoc networks (MANETs) 9. Some common attacks that represent a critical challenge to trust and reputation systems are described by Zhang in 39. Sensitive information can be used by control systems that may represent a threat to safety, or malicious nodes may attempt to disseminate false or corrupted information. The system should be designed to minimize selfish and malicious behavior, as well as to support flexible security and privacy mechanisms. Applications may require a broad range of protocols and security mechanisms. From simple end-to-end secure channels through public key infrastructures (PKIs) to distributed reputation and voting systems, ingenious protocols can be employed using symmetric and asymmetric cryptosystems, cryptographic key management, authentication, authorization and accounting (AAA) systems, threshold cryptography, and so on. On the other hand, security mechanisms to verify authenticity, integrity, and reputation features may be required for the operation and management of the network itself. Several distributed cryptographic, trust, reputation, and currency systems can be combined to promote an integral trust solution, making them ideal to be employed in applications built by service composition. Sophisticated trust and reputation systems have been proposed, some of them even providing distributed reputation and quality assurance for any node, mes- sage, or piece of information. Some models designed include data-centric trust establishment (DCTE) 31 frameworks and distributed emergent cooperation through adaptive evolution (DECADE) 21. The capacity to securely exchange data and learned knowledge is also a prerequirement asserted by Presser et al. 28. MQTT v3.1.1 10 only pro- vides general guidance on security. There is no standardized mechanism for MQTT security. However, it recommends brokers that implement transport layer security (TLS) via TCP Port 8883. According to this standard, MQTT is just a transport protocol and security mechanisms are out of scope. Neisse et al. 23 discuss MQTT security issues and propose policy enforcement rules at the MQTT layer. AMQP security is based on TLS over TCP and the simple authentication and security layer (SASL) or the traditional secure socket layer (SSL) can be used. Authentication may require human intervention to provide a username and password when accessing resources’ URIs. However, digital certificates can be adopted when SSL is selected together with TCP. The AMQP payload can be encrypted to increase security in communication.284  Security and Privacy in Internet of Things (IoTs) DDS standardized a more general security model in 2014 29, where (i) user requirements are specified; (ii) mechanisms to secure topics and data objects are provided; and (iii) authorization exists to perform topics and data objects access or manipulation. The aim is to secure the entire DDS global data space. According to DDS security standard 1.0 29, DDS provides secrecy, integrity, and nonrepudiation of data objects, as well as authentication and authorization of data writers and readers. There are limited functionalities such as domain joining, definition of new topics, publishing or subscribing from a specific topic, or even writing/reading topic values identified by topic keys. IEEE 802.15.4(e) addresses link layer security issues. Sastry et al. 32 men- tion that the aims are (i) authentication of devices; (ii) secrecy and integrity of messages; and (iii) protection against replay attacks. Symmetric cryptography is used to create a checksum that is transmitted on frame headers and verified at the receiver’s end. Therefore, a key is secretly shared between transmitter and receiver. Confidentiality is based on the semantic security technique, which uses nonces to introduce variability into encryption process. Replay protection is based on sequence numbering. Although many of the current IoT technologies provide security solutions, usually they do so incrementally and are focused on individual requirements, often depending on the notoriously problematic protocols we have today. Broader architectural solutions are hardly possible, because new technologies often have to live with the older ones—many of them designed in times when security and privacy concerns did not exist. We advocate for more deep rethinking of archi- tectures to truly address IoT security, privacy, and trust challenges. 11.3 Introducing NG as an IoT Architecture 1 The NG project started in 2008 with this question in mind: Imagine there is no Internet architecture right now; how could we design it using the best con- temporary technologies? A vast survey of emerging paradigms for new Internet architecture was carried out, resulting in a selected list of foundational ingre- dients. Among them there was the so-called IoT. The project aims to integrate these ingredients into a cohesive design, where one ingredient favors others, cat- alyzing the overall potential. In this sense, the IoT was related to many other NG ingredients such as name-based content and service orchestration. The recent development in the future Internet architecture shows that IP-based Internet architecture has limitations when it comes to interconnection of devices in the world of IoT objects and devices. Scalability and portability are two points where NG can score over other Internet architectures. NG archi- tecture will have native support of distributed systems and the ability to evolve 1 “Things” and Their Software Representatives  285 its functionality to accommodate new, as yet unforeseen, requests over time for exchange and distribution of data. A simple NG service is being developed to be embedded at IoT nodes. This service aims to implement some NG novelties at sensors and actuators, enabling them to exchange name-based messages, as discussed at subsection 11.3.1. For small-capacity IoT nodes, proxy/gateway (PG) services can represent them in the NG cloud, enabling dynamic contract establishment in the name of the “things.” The PG service (PGS) model provides a distributed gateway and interoper- ability solution adequate for the heterogeneity of IoT platforms, protocols, and device implementation. The PGS can also be extended to change configurations at controlled IoT nodes, as well as to detect their status. This model goes in the direction of a software-defined IoT, where nodes are controlled by NG services. The Internet architecture follows a “narrow-waist” design, which has a great impact on the success of the present Internet. It forces that applications and proto- cols to be made above the waist, supporting the physical media, physical layers, and access technologies below the waist. But this has a drawback, especially regarding the dual semantics of IP addresses and obsolete fields in headers. As technology evolves, we are talking about the interconnection of billions of devices. This is where the present Internet architecture faces problems. This is where IPv6 comes into play, but it also faces problems because of the same “nar- row waist” and the large size of datagram headers. The NG pub/sub “narrow waist” resembles the DDS link protocol, but with the advantage of integrating several FIA ingredients, such as the naming struc- ture, binding resolutions, software-defined, mobility-friendly, self-organizing, service-oriented designs. In fact, NG extends DDS in many ways, including “semantic-rich” integrated orchestration of contents, services, and IoT resources. NG provides a renewed naming scheme with dynamic messaging, where identi- fiers are decoupled from locators, supporting mobility by rebuilding name bind- ings. NG protocols are implemented as services, enabling dynamic protocol orchestration, self-adaptation, and evolution. They enable the emergence of more efficient and modern protocols for the IoT, which can operate aware of several issues such as energy, delay, communication opportunities, and so on. 11.3.1 Naming and name resolution NG uses natural language names (NLNs) and self-verifying names (SVNs) to identify entities (physical or virtual) at some scope. When a service is initialized, it publishes the bindings among several NLNs and SVNs. It may also publish descriptors exposing its features. Representative services can reveal physical- world resource capabilities and states. Every service can be addressed by subscribing to these initial bindings recur- sively. As the combination of a port number and an IP number addresses a port in the current Internet uniquely, SVN tuples allow the same for NG services.286  Security and Privacy in Internet of Things (IoTs) For example, consider a proxy service that inhabits some OS. This service can generate an SVN, let us say A1, and assume that this name is an address for this service inside of the local OS. Likewise, the OS can generate an SVN, let us say B1, and assume that this name is an address for this OS inside a certain host. The host can also have an SVN, let us say C1, which can be used to address this host inside a domain (D1). The resultant tuple, A1–B1–C1–D1, enables any other service to address a message to this proxy service globally. Additionally, natural language names linked to this tuple facilitate search and discovery of service access points. On the current Internet, when a host moves from an autonomous system to another, its IP address could change, causing a change in the identity of the host. This results in an undesirable loss of traceability, as well as possible loss of connection. In the NG approach, there is no loss of traceability, since the host remains with the same SVN after movement. Suppose the host of the aforemen- tioned proxy service moves to a new domain, let us say D2. The SVN tuple changes to A1–B1–C1–D2, while the host continues with the SVN C1 despite the movement. Therefore, the mobility of a host in the NG approach requires the removal of the first name binding (C1–D1) from the name resolution service and the publication of a new name binding between C1 and D2. This solution is self- similar, since it could be applied for the mobility of any existences, including content, services, hosts, and so on. NG SVNs are generated from entities’ immutable patterns, as illustrated in Figure 11.5. As long as an entity maintains its immutable attributes, its SVN will be the same. Therefore, even in ephemeral ad hoc networks, entities can pre- serve their SVNs, while opportunistically connecting and communicating. NG services maintain contracts that are bound to entities’ SVNs. Thus, an entity’s reputation can be determined based on contract analysis. Additionally, the NG pub/sub service can support new techniques like data-driven trust 31. 11.3.2 Identifier/locator splitting NG allows names to be used as identifiers and locators. NG borrowed the idea of adopting SVNs as identifiers and locators from other ICT architectures, particu- larly NetInf 11 and XIA 16. As previously mentioned, a locator should pro- vide a notion of distance between entities in some space. As one might expect, it is not possible to derive such a notion of distance from SVNs—they are flat (semantic-free names). NG provides a notion of distance by using SVN bindings. SVNs are certified. They can be checked anytime for integrity. They are flat, since they do not depend on a network hierarchy. Only the bindings among SVNs change according to the network hierarchy. SVNs can be globally unique, avoid- ing the current lack of addresses on the IPv4 Internet. In the case of host mobility, the services’ addresses (tuples) change, but their identifiers, that is, SVNs, remain the same (see Figure 11.4). In other words, only the name bindings change.Self-Organizing “Things” and Their Software Representatives  287 Natural language names to approximate machines from human language. Antonio Antonio’s Image.jpg Alberti smartphone 0101010101010101011010110001010010101010101010101 1010101011110100001010011111111110101010100000000 1001010101000101010101011111110000000000000000000 1010101010101010101000010010101010101010101010101 1111111010101010100001010010100101010100010101010 0100000100000010000000001000001000000100000010000 1110000010000000100000010110101111000011100000000 1111111010101010100001010010100101010100010101010 0100000100000010000000001000001000000100000010000 1110000010000000100000010110101111000011100000000 1111111101111110111111011111101111101111101111111 01011223... AA180972... BFEF1216... Self-verifying names generated from immutable patterns of entities to improve security. Name bindings to create a network of relationship representations. Figure 11.5: Naming and name binding on NovaGenesis. Natural language (mean- ingful) names are related each other creating an ontology. Self-verifying names (SVNs) are also bound to create a graph of meaningful free names. NLN to SVN bindings or reverse bindings create the link to accommodate not only “semantic- rich” orchestration, but also the provenance of the contents. The SVNs remain the same while the entities do not change their binary pat- terns or attributes. In summary, NG generalizes ID/LOC splitting to all entities. 11.3.3 Resources, services, and content orchestration An NG service can publish its name (NLNs and SVNs) bindings to other ser- vices. This is similar to publishing a graph of names. This publication can reveal services’ relationships to devices, people, and contents. Figure 11.6 illustrates this process. Services can reveal their features, interests, and intents publicly or privately. This is much more extensive and useful to IoT developers than pub- lishing data in a topic or forwarding topic-based messages. NG accommodates entire service using NLNs and SVNs. After revealing their name graphs, services look for possible peers. Figure 11.7 illustrates the NG service discovery phase. Services subscribe to NLNs related to their contract interests. Of course, developers will need to pro- vide meaning full (semantic-rich) keywords to facilitate finding good candidates. If a service discovers a good candidate (it needs to evaluate this), it publishes a contract/SLA offer. Observe that one can develop representative services for “things.” These ser- vices can reveal the physical features of sensors and actuators, negotiating con- tracts in the name of “things,” and configuring and managing devices to reflect288  Security and Privacy in Internet of Things (IoTs) I do have Antonio’s photos Smartphone 1 e 1 I do store Antonio’s Antonio Photo store photos Alberti Photo Photo app app app 1 I do have Antonio’s photos Smartphone 2 Scalifax Photo app 2 Figure 11.6: Several of Antonio’s applications publish their name bindings using the NovaGenesis pub/sub service. We call this service the exposition phase. In this particular example, “Photo App 1” and “Photo App 2” announce that they have Antonio’s photos, while “Photo store app” announces that it stores Antonio’s pho- tos. Obverse that natural language names are bound to each entity’s self-verifiable names. Thus, semantics orchestration employs NLNs first, and SVNs thereafter, to improve security. Let’s work together? Smartphone 1 e 1 Let’s work Antonio Photo store together? Alberti Photo Photo app app app 1 Let’s work together? Smartphone 2 Scalifax Photo app 2 Figure 11.7: Antonio’s services discover each other using meaningful keywords (NLSs) and publish contract/SLA offers to candidate peers. Pub/sub may be encrypted using asymmetric cryptography. Therefore, SLA offers can be kept secret.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.