Challenges and Associated Vulnerabilities in IoT-Enabled Technologies
Authentication- and Authorization-Related Challenges
With the growing ubiquitous presence of IoT devices, it has become the need of the hour for each system to possess the secure authentication of the sensitive sensor data being shared. Although the password is one of the most secure authentication methods widely in use in the virtual world, it is considered incompatible with and difficult to implement in IoT systems, owing to the sheer size of the IoT networks at work. One of the industries that heavily employs IoT is the health care industry. Data transmission occurs within the IoT architecture in the health care industry by verifying to the sink node (Medical Services Gateway) before relaying the procured data out. This data is then verified by the cloud upon forwarding the data. Finally, the analysis and operations upon the procured data are performed once the IoT applications and services authenticate to the system. The authentication method in the IoT scheme is based on a security token. The two most frequently used processes for authentication include one-way authentication and mutual authentication.
OAuth-based authentication schemes have been gradually gaining traction in the last few years. This is an open standard authentication, which invokes third-party websites for logging in, without exposing passwords. The key benefit offered in this scheme is that the client is granted a secure delegated access to the server. The OAuth flow is explained in Figure 5.3.
FIGURE 5.3 O-Auth Flow Diagram.
Application program interfaces (APIs) are made available for IoT apps by the OAuth-based scheme, which aids the IoT service and application layers and, by extension, the users, by:
- • Permitting actions to be performed by an untrusted application that is in agreement with the IoT user or end node at the API provider;
- • Granting the authority to perform actions, by verifying the devices’/user’s permission without revealing the user password;
- • Giving certain permissions to untrustworthy users.
OAuth 2.0, which is an authentication technique that is remarkably helpful for web applications, mobile phones, and IoT clients for next-generation, comes with its own set of challenges, involving credible APIs and entrusted credentials. Certain applications in the IoT system use digital IDs furnished by state authorities to identify the user/device. There is a lack of central authorization management. The diverse security management interfaces across various platforms make it difficult for IoT end nodes to manage cloud interactions. Considering both OpenID and OAuth, certain parallels can be drawn between them in terms of basic operations: log-in request; requester authentication; redirecting the URL for the identity provider; identity provider authentication of the user; processing request and the response of the provider by sending a redirect; and, sending the URL to the requester and the response of the requester.
Upon closer inspection of the network, we find that the authentication layer forms the bedrock of the IoT architecture, which relies on identity information for providing and verifying an IoT device. These IoT/M2M devices build a trust relationship, which allows them to access the infrastructure upon the identity of information. Although there exists a large difference between storing and offering identity information to the user predominantly in an enterprise network, the endpoints are identified using human biometrics or passwords. There have been efforts to reduce or eliminate human interaction by using fingerprinting IoT endpoints. The identifiers that have evolved in this quest include RFID, the MAC address of the endpoint, or X.509 certificates. Among these, X.509 certification is regarded as having a strong authentication system, but the paucity of memory to store a certificate and the CPU power used to compute cryptographic operations for authentication pose a challenge to IoT devices as a whole. Along with X.509, there exist a few- other identity footprints, such as 802.1AR, and protocols for authentication, such as IEEE 802. IX, which are beneficial for devices that can handle both the CPU power and memory needed to store strong credentials. These challenges have instigated fresh research, to develop smaller footprint credentials, which is sustainable in less computation-intensive cryptographic frameworks.
The second determining factor of the IoT framework is an authorization that manages a device’s access throughout the entire network architecture. The authorization to access data is based on an authentication operation performed, which employs identity information from a device to initiate and augment trust alliances and trust relationships, to relay suitable information. A trust relationship allows the minimal, obligatory transfer of data, while a trust relationship allows a relatively unconstrained flow of data. The existing architecture and policy mechanisms cater to the needs of endpoints efficiently, both in consumer and enterprise networks. The biggest bottleneck is to further enhance the size of IoT/M2M devices with diverse trust relationships in the construct. The focus might shift toward improving policies and controls, to minimize and segregate network traffic and improve end-to-end communication.
The primary difference in security management in an IoT network is that prior to a new device being added in, a network must authenticate themselves prior to sharing data, unlike websites that are authenticated using Secure Socket Layers (SSL) on browsers or users who have to authenticate using a password. Since the driving force to create an IoT network is to reduce human intervention and increase the coordination among things to render useful data to the user, introducing humans to input credentials to access the network would be taking a step back. So, what are the measures that can ensure devices to correctly ensure authorization to access into an IoT network? Based on user authentication, machine authentication uses a similar set of credentials, which are stored securely in memory
Ensuring that the data transmitted, stored and operated upon remains secure in an IoT network is of prime importance to fend off threats from taking advantage of IoT in an unauthorized manner. Vulnerable points that are susceptible to threats from external actors include:
- • Vehicles, health care systems and control systems that may even be used to access the human body (WBAN) to manipulate and cause injury or even worse.
- • Manipulated health care diagnosis, which could lead to improper treatment or modified health information rendered to a patient
- • Homes or commercial businesses may face attacks against electronic, remote- controlled door lock mechanisms and allow physical access
The devices in a network are often at risk at various levels. First is the single-user level, where illegal surveillance through the persistent remote monitoring offered by small-scale IoT devices is possible. The examination of a network, geographic tracking, and IoT metadata leads to inappropriate profiles and categorization. Asset usage and management develop a usage pattern that can lead to the unauthorized tracking of users’ locations. User location and tracking personal behavior, choices and activities through location-based sensing information could expose patterns that may be stored without prior notice to the user. The second level is at commercial business, with the unauthorized tracking, analysis, and manipulation of financial transactions via POS and POS access. The inability to provide service can lead to monetary losses. The destruction or theft of IoT assets that are employed in obscure areas and lack security controls can further exacerbate the damage. The third and final level is a degree of access in the IoT. with the potential to acquire unauthorized access to IoT end-nodes to exploit data unscrupulously by exploiting the drawbacks concerning upgrading the software and firmware of embedded devices, such as those present in cars, houses, or health care facilities. The potential exists to acquire unauthorized access to the IoT in enterprises to compromise IoT end-nodes by often manipulating, violating, or exploiting the trust relationships and alliances. There is the potential to compromise IoT end-nodes to form botnets. There is also the potential to join a network by faking IoT devices by acquiring keys and other confidential data stored in these devices. The compromised gadgets in the IoT network are unknowingly fielded upon their security concerns.
The most pivotal operation in an IoT system is the authentication of devices and data transmitted at each layer. Beginning from granting access to IoT devices to relaying procured data or to operating upon this data, to the application layer being authorized when requesting data, the entire IoT is centerd around security and authentication. For this purpose, one of the most compatible and optimal methods available in the IoT is security tokens, which verify one application or user or device to the device or application at another layer, using a token received. It helps to verify the first actor to another operational at another layer, thus granting access and authorization. To keep authorization and authentication under check, it is imperative for the user to be aware of how the data gets transmitted, analyzed, or operated on and the extent to which each actor authorizes another to access data.
OpenID Connect 1.0 and OAuth 2.0 are the two most widely used authentication tools that operate along with the above-mentioned model. Both frameworks use a token for authentication to grant privileges and control. One of the salient features of OpenID Connect 1.0 is that it offers a discovery and registration mechanism, which is apposite in scaling the network. OpenID Connect 1.0 and OAuth face the biggest challenges through HTTP, an IoT protocol. The inadequacy of HTTP to operate among various "Things" has been one of its major setbacks. The development of MQTT (Message Queuing Telemetry Transport) and CoAP (Constrained Application Protocol) are proving to be suitable alternatives to HTTP, yet there remain a number of roadblocks ahead to combine IoT-centered frameworks.
