eMUD: Enhanced Manufacturer Usage Description for IoT Botnets Prevention on Home WiFi Routers

Distributed Denial of Service (DDoS) attacks have caused significant disruptions in the operations of Internet-based services. These DDoS attacks use large scale botnets, which often exploit millions of compromised Internet of Things (IoT) devices worldwide. IoT devices are traditionally less secure and are easy to be exploited. The extent of these exploitations has increased after the publication of the Mirai botnet source code on GitHub that provided a foundation for the attackers to develop and launch Mirai botnet variants. The Internet Engineering Task Force (IETF) proposed RFC 8520 Manufacturer Usage Description (MUD) so that an IoT device can convey to the network the level of network access it requires to accomplish its standard functionality. Though MUD is a promising effort, there is a need to evaluate its effectiveness, identify its limitations, and enhance its architecture to overcome its weakness and improve its efficiency. The latest Mirai variant malware is exploiting vulnerabilities of Internet of Things devices. As MUD does not consider identifying and patching vulnerabilities present in the device before the issuance of the MUD profile, a device can be compromised even in the presence of the Manufacturer Usage Description profile by exploiting either the configuration vulnerabilities or firmware vulnerabilities present in the device. This paper presents an evaluation study of the Manufacturer Usage Description (MUD), identifies its weaknesses, and proposed enhancements in its architecture. This research proposed a mechanism for identifying and eliminating the configuration vulnerabilities before creating the MUD profile for a device to minimize the attack surface. This research adopts the OWASP firmware testing methodology for discovering vulnerabilities in the firmware of WiFi home routers. The device is allowed to request the MUD profile only if the identified firmware vulnerabilities are low. The identified firmware vulnerabilities are patched in case the score of the identified firmware vulnerabilities is moderate or high. The device is allowed to request the MUD profile after the vulnerabilities are patched. The firmware vulnerabilities are shared with other peers using blockchain smart contracts. There is a possibility that the MUD URL might be pointing to a corrupted or malicious MUD profile hosted at the attacker file server due to the absence of an authentication mechanism in the MUD process. This research also proposed an authentication mechanism for device MUD profile, MUD file generator, and MUD file server. Implementation results show that proposed enhancements improve the security services provided by the Manufacturer Usage Description (MUD).


I. INTRODUCTION
Internet of Things (IoT) presents a global paradigm of smart computing devices, communicating with each other to achieve common goals [1]- [4]. Large scale deployments The associate editor coordinating the review of this manuscript and approving it for publication was Md. Arafatur Rahman .
of IoT devices and evolving applications in a variety of areas have not only tremendously transform the technology Landscape, but it is also gradually impacting human behavior and culture [5]. Besides innovators, designers, vendors, and users, IoT has also attracted the attackers' attention. IoT devices are usually deployed with less secure security controls. This weakness has made the IoT as a network of millions of insecure devices [6]. The bigger volume of the Internet of Things makes its attack surface larger [7], [8]. Time to market, low-cost consideration, and lack of related regulations have encouraged vendors to manufacture less secure devices. Security experts have often issued warnings regarding the usage of these less protected devices [9]. In February 2018, numerous autonomous systems and hosts hit Github by a 1.35 Tbps attack [10]. In May 2018, a malware infecting home routers and specific network-attached storage devices were identified as 'VPNFilter.' As of May 24, 2018, it has affected approximately 500,000 routers worldwide [11]. BrickerBot.1, found on March 20, 2019, infected around 2000 devices in the initial few days of its setup [11]. In October 2016, Dyn, a domain name service provider, experienced a well-coordinated attack causing its services outage [12]. IoT devices were compromised as bots, and DDoS attack was launched on Dyn, affecting the accessibility of well-known websites including Soundcloud, Twitter, Reddit, Spotify, Etsy, Netflix, The New York Times and Airbnb [13]. Dyn attack was caused by Mirai IoT malware and gained enormous media coverage. Mirai malware exposed how insecure IoT devices can be exploited for launching coordinated Distributed Denial of Service (DDoS) attacks. Manufacturer Usage Description (MUD) based on an access control mechanism is proposed in [14], [15]. MUD enables the devices to deliver the type of access they need for operating correctly.
This study presents the evaluation of Manufacturer Usage Description (MUD), its limitation, and its enhancement in its architecture. Main contributions of this paper are • This research evaluated the effectiveness of Manufacturer Usage Description (MUD) and identified its limitations • In home networks WiFi home router acts as MUD Controller. This study discusses the compromisation of the MUD Controller in the home network.
• Proposed a mechanism of identification and elimination of configuration vulnerabilities in devices.
• Adaptation of OWASP firmware testing methodology [3] for the identification of firmware vulnerabilities in devices.
• Proposed a mechanism by which a device can request a MUD profile if the score of the vulnerabilities present in it is low or the vulnerabilities are patched.
• Proposed a mechanism for the distribution of firmware vulnerabilities to software suppliers using blockchain to patch them.
• A compromised device might point to a corrupted or illegitimate profile as the DHCP and LLDP methods present in a MUD does not provide the device authentication. This work proposed a mechanism for authenticating both device MUD profile and the MUD file generator.
• Presents a mechanism of MUD profile enforcement using a firewall in home networks. The rest of the paper is organized as follows. Section II covers the description of the working of the Manufacturer's Usage Description. This section also discusses the compromisation of the MUD Controller (WiFi home router) in a home scenario. The limitation of the MUD is also discussed in this section. This section also contains a discussion about the need for collaboratively eliminating the vulnerabilities in devices. Section III provides the proposed enhanced MUD. This section includes identification and elimination of default configuration vulnerabilities, identification of vulnerabilities in firmware, Augmented MUD Profile generation based on vulnerabilities scoring, blockchain based distribution of firmware vulnerabilities to vendors for patching, Mutual authentication mechanism for device MUD profile and MUD Server and MUD profile enforcement using a firewall in home networks. Deployment details are presented in section IV. Section V provides results and analysis. Finally, section VI concludes the paper.

II. MANUFACTURER USAGE DESCRIPTION
Manufacturer Usage Description (MUD) [14], [15] is an Internet Engineering Task Force (IETF) standard intended to describe the expected behavior of the IoT device using Access Control Lists (ACLs), to confine the communication to/from a specific device. MUD outlines a structural design for attaining MUD files where those policies are indicated by using the Yet Another Next Generation (YANG) [16] and JavaScript Object Notation (JSON) [17] standards. The research community and standardization bodies, e.g., National Institute Standards and Technology (NIST) has given away a keen interest in the MUD [18]. The working of the Manufacturer Usage Description is shown in Figure 1. An IoT device initially refers to a pre-embedded URL of its MUD file to the network gateway; thus, the MUD controller is given the MUD-URL. Each MUD-URL has a corresponding MUD file that will be delivered by the MUD file server. The received file is converted into policy by the MUD controller. The enforcement of the access control of the intended device is carried out by these policies.

A. COMPROMISING MUD CONTROLLER IN HOME NETWORK
In home network, a WiFi access router, will act as a MUD Controller. There are numerous security attacks on these home routers. Moreover, the MUD controller has a trust relationship with the IoT devices present in the home network. The security threat posed by the MUD Controller in the home scenarios is a challenge and limitation of the MUD. There is'nt any policy rules for dealing with such threats. To assess the MUD's efficacy in the home network, we assume a scenario in which the home WiFi access router acts as a MUD Controller. As the MUD standard lacks the specification of the strength of the MUD Controller's access policy in the home network scenario, there is ample chance that the MUD Controller itself got compromised from Mirai like malware. IoT devices compromised by Mirai malware acts as a scanner, MUD Controller compromised as bot will serve as a scanner and compromised the device even in the presence of MUD profile for the IoT devices. Figure 2 demonstrates  the compromisation of the MUD Controller in home networks. The following are the main steps for compromising the MUD controller in the home network. The IoT device points to an embedded MUD URL to WiFi Access Router (MUD Controller). WiFi access router then obtains the MUD file of the IoT device from the MUD file server using the embedded URL to that the device was pointing and translated it into policy. The scanner server is trying to brute-force the WiFi access router, i.e., MUD Controller. The scanner server, after scanning vulnerabilities, sends the report to the leader server. Lader server loads Mirai Malware on to the WiFi access router. After being compromised, the device becomes a bot and establishes its connection with the command and control server. The newly form Bot scans for new vulnerable devices to make them part of the botnet. The bot, i.e., WiFi access router reports them to the loader server after identifying new vulnerable devices. Later, the CNC server sends an attack command to the bot. In the end, bot lunches attack. When the WiFi access router is compromised, all the devices attached to it can be compromised. The MUD profile can be bypassed in case vulnerabilities are present in a home gateway. Therefore, the MUD effectiveness in home network's is questionable due to the non-presence of criteria for the security strength of the applied policies for MUD Controller in home scenarios. There is a need for specific criteria for applied-MUD policies to mitigate the risk of weak MUD policies. Moreover, a compromised device might point to a corrupted or illegitimate profile as the DHCP and LLDP methods present in a MUD does not provide the device authentication.

B. LIMITATIONS OF MUD
Some of the identified limitations of the MUD are described below; • Manufacturer Usage Description does not evaluate and eliminate the configuration and firmware vulnerabilities before the generation of MUD profile. This situation leads to a scenario where a device is compromised as bot, in prepense of the MUD profile, by exploiting the vulnerabilities as explained in previous section.
• A compromised device might point to a corrupted or illegitimate profile hosted at the attacker file server. This situation arises from the non-presence of an authentication mechanism of the MUD profile, MUD file generator, and MUD file server.
• The MUD does not define particular approaches for attaining and forcing such policies in a secured and trusted way. There is a need to establish an enforcement mechanism for applying the MUD policies on the devices.

C. NEED FOR COLLABORATIVE STRATEGY FOR THE ELIMINATION OF VULNERABILITIES
There is a need to establish a collaborative mitigation strategy in which different entities, vendors, and software suppliers form a trust relationship. Then they participate in protecting each other from being compromised. In this type of collaborative mitigation strategy, if one entity detects vulnerabilities in their devices, this entity can share the identified vulnerabilities information with its peer trusted nodes. Those peer nodes can pro-actively take precautionary measures to protect from compromised malware and patched the identified vulnerabilities. This mitigation strategy is in line with the ''collective responsibility'' and ''think globally, act locally'' principles [19]. This paper presents a secure and trusted mechanism for the distribution of identified vulnerabilities to peer. Although sharing the information with peers in a secure means results in proactive security, there are many reasons why sharing and coordinated efforts do not regularly happen [20], [21]. Some of them are • Secrecy and Privacy of victim security posture: Exchanging basic attack information can leak private data related to the victim's atmosphere and sensitive information. It unveils insights into the victim's infrastructure and its security posture. This situation can empower and inspire other potential attackers. This coincidental revelation can further hurt the repute and business of the victims [22].
• Attacker's tradecraft on Victim Data: Requesting and interchanging data can alarm adversaries that an investigation and examination are happening. This alarm can enable adversaries to update their strategies and escalate their likelihood of circumventing future detection by intrusion detection systems and controls at the victim side [23], [24].
• lack of context and structure: Shared data does not explicitly mention the context. It also lacks the methods of the acquisition of the data. This scenario originates a circumstance in which shared data is untrustworthy, the relevancy to the receiver is not promptly evident, and the data must be processed again or altered over casual networks to be helpful for the recipient. In this case, considerable time and interference are essential to intake the feeds in the receiver's private work-flow [25].
• The absence of appropriate records: No comprehensive technique is available that can track in a certain form that who shared what, with whom, and when. This state of affairs leaves less potential to distinguish guilty parties of trust and fewer chances to consider crediting profitable information [26].
• lack of incentive: There is no obvious monetary advantage to network-wide sharing. Moreover, security organizations might be reluctant to share because of the fear of reducing their business advantage [27]. Altogether, these details produce an atmosphere where individuals and organizations are hesitant to share. If sharing happens, the facts are exposed to the level that instant significance became doubtful. Regrettably, this terminates into a paradigm where possibly essential points that can stop threats regularly by no means reach the prospective peers in time. The security and transparency of the platforms in blockchain could improve the problems of cybersecurity. A blockchain-based cybersecurity system can securely connect devices by using digital signatures to catalog them into the decentralized network. This formation is very much decentralized, minimizing the chance of a central point of attack for the adversary. Therefore, stealing information from a blockchain system would be similar to a situation where the crook has to take from hundreds of banks at the same time, without notifying anybody, which is almost impossible. Once a threat occurs, the information regarding the incident can be overlooked, confused, and complicated. Nevertheless, blockchain can efficiently outline what happened. Fundamentally, blockchain can take along the world to establish a consensus amongst themselves to unwraps exciting prospects in the areas ranging from asset management, supply chain management to threat intelligence. Blockchain can create the threat sharing market impartial and economical by letting users access data based on its performance and merits. Recently there have been some efforts in the literature regarding the suitability of a framework having user confidence and a solution to the problems incurred during threat sharing [28], [29]. In this regard, blockchain is being evaluated and extended for threat information sharing due to its multitude of properties [30]- [34]. Wenjuan et al. [28] proposed a challenged based collaborative intrusion detection mechanism for establishing trust in detecting insider threats. Although this model builds trust for detecting insider attacks, it does not propose a threat sharing model. Alexopoulos et al. [29] present an innovative, collaborative platform that intent to permit and incentivize parties to interchange network alert data, thereby increasing their overall detection proficiency. Although this model uses blockchain to incentivize the sharing of attacker information, the game-theoretic model's utilization made it complicated. The ishare platform [31] utilizes the concept of a digital signature of the transaction for the security, privacy, and non-repudiation of the exchanged information. The game theocratic approach made it infeasible for threat data sharing. Kang et al. [35] describes a blockchain-based datasharing model for vehicular edge computing. Zhang et al. [36] proposed a blockchain-based clinical data-sharing model. Fan et al. [37] presented a privacy-preserving data sharing mechanism for content-centric networking in 5G. Zheng et al. [38] describes a blockchain-based mechanism for data sharing. Although these efforts are a step towards blockchain-based collaborative mitigation approaches, none has presented a comprehensive threat information sharing framework. The blockchain is a distributed arrangement of information that is shared amongst the members in the network. A protocol anticipated to digitally assist, authenticate, or carry out a contract arbitration is termed as a smart contract. The initial idea of smart contracts for validating and safeguarding computerized connections emerged in the 1990s [39]. The first executions of the concept were KARMA [40]. Nakamoto proposed a proof of work framework [41]. Ethereum blockchain provides a turning-complete language for the implementation of smart contracts [42]. Kosba et al. presented a blockchain-based transactional privacy-aware smart contract framework HAWK [43]. These efforts feature many fundamental issues and give answers in parts for challenges present in the sharing of security data.
Nonetheless, these efforts just distinguish the issues or give answers for a particular issue that are encompassing the difficulties of sharing attacker information, our work joins and expands upon these efforts and consolidates these ideas to handle the all-encompassing issue of building up a system for exchanging threat information while defeating the subjects of protection, privacy, tradecraft, lineage, construction, incentives, and ledger. In this study, we put forward a blockchain and smart-contract-based collaborative mitigation system. The proposed blockchain-based collaborative mitigation system's core notion is to share the attacker information, detected by the detection system, with numerous fellows through smart contracts.

III. PROPOSED ENHANCED MANUFACTURER USAGE DESCRIPTION
This section details the enhancement of the Manufacturer's Usage Description. Figure 3

B. VULNERABILITIES IDENTIFICATION IN ROUTER FIRMWARE USING FIRMWARE TESTING METHODOLOGY
The exploitation of the router firmware's vulnerabilities is the primary cause of compromising home WiFi router as bots. Issuing MUD profiles to devices having less secure firmware will provide the least significant security protection. Detection of critical vulnerabilities in the home WiFi router before issuing the MUD profile is necessary to issue the device's MUD profile. There is a need for the security testing of device firmware before the issuanc of MUD profile. This will enhance devices' security protection. The OWASP firmware testing methodology [3] consists of the following nine steps: 1) Collection of information and Exploration 2) Attaining Firmware 3) Analyzing Firmware 4) Extracting the Filesystem 5) Analyzing the filesystem Contents 6) Emulating Firmware 7) Dynamic Analysis 8) Runtime Analysis 9) Binary Exploitation These steps will identify the vulnerabilities present in the firmware of the WiFi home router (MUD Controller).

C. MUD PROFILE GENERATION BASED ON VULNERABILITY SCORING
Once the vulnerabilities are identified, the CVSS score is calculated for the CVE of each vulnerability. This process leads us to the calculation of the overall risk score of a device. If the score is not low and the patch of the vulnerability exists, vulnerabilities are patched. The device is then allowed to request the MUD profile. If the vulnerabilities are not patched, the device is not allowed to request a MUD profile. Similarly, if the score of the device's vulnerabilities is moderate or high, the device is not allowed to generate a request for the MUD profile until the vulnerabilities are patched. Figure 5 demonstrates this process. VOLUME 8, 2020

D. PROPOSED BLOCKCHAIN-BASED DISTRIBUTION OF FIRMWARE VULNERABILITIES TO SOFTWARE VENDORS FOR PATCHING
The proposed Blockchain-based Distribution of Firmware vulnerabilities to software suppliers for patching is depicted in Figure 6. Table 1 illustrates the mathematical notations used in the proposed system. In the suggested Firmware Vulnerabilities System, members in the Blockchain-based smart contract have an agreement of sharing identified vulnerabilities of firmware to the member present in the smart contract through its collaborator. As an initial phase, a smart contract based on Blockchain is made. This smart contract bounds every participating member to share firmware vulnerabilities with the member of the smart contract. This smart contract is joined by diverse enterprises of IoT devices, including the software supplier of the home WiFi router and vendors/manufacturers of the home WiFi routers.
The following are the steps of the proposed collaborative mitigation.
1 As a first step, a blockchain-based smart contract is formed. This smart contract contains the condition of sharing attack detection reports with the member of the contract, in case there is an attack on IoT devices of any member. 2 Different vendors of IoT devices join the smart contract. 3 Each firmware is tested for the identification of vulnerabilities. The report of the vulnerabilities is given to the collaborator. 4 Collaborator signs it digitally using its private key and an algorithm. This process can be represented as E(SP r K (T x )) = ST x . 5 Collaborator at that point encrypts this signed transaction with Group public key or with public keys of the corresponding receiver as E(RP p K (ST x )) = EST x and broadcast it to all the fellow's participants in the smart contract. 6 The receiver Collaborator decrypt the receiving transaction with its private key as D( The receiver Collaborator then verifies the digital signature of the receiver by decrypting the signed message with the sender public key as D(SP P K (ST x )) = T x . 8 Upon receipt of the firmware vulnerabilities report, a collaborator at receiving members, report the vulnerabilities to the firmware loading team.

E. PROPOSED MUTUAL AUTHENTICATION MECHANISM FOR DEVICE MUD PROFILE AND MUD SERVER
Existing MUD does not provide the authentication of the MUD File Generator, MUD file server, and the MUD profile device. Figure 7 depicts the proposed mechanism for authenticating the MUD file generator, MUD file server, and the device. The functionality of the proposed algorithm is as follows.
• Initially, Device request MUD Maker to initialize the process of MUD profile generation.
• Device request MUD Maker for the certificate generation for MUD File server presenting identity and the MUD file server's public key.
• MUD maker generates and sends a certificate to the device containing the MUD file server's public key.
• Device request MUD Maker for the certificate generation for device himself presenting his identity and public key.
• MUD maker generates and sends a certificate to the device containing the public key of the device. VOLUME 8, 2020 • The Device gives both the certificates to the MUD file server.
• The Device then requests MUD maker for the generation of MUD profile.
• MUD maker responds with the generated profile.
• The Device sends the generated profile to firewall and firewall convert MUD profile to a firewall policy and implement it.
• device digitally signed the MUD profile with its private key.
• Device request the MUD profile URL by sending the Public key of the MUD maker, device own certificate, signed MUD profile, and actual profile to the MUD file server. The device encrypts all these credentials with the public key of the MUD file server. This way, an only MUD file server can decrypt this Request with its private key. This step provides authentication of the MUD file server.
• MUD file server hosts all these files and gives the corresponding URL to the device.
• Device point to the URL of the MUD profile. The URL consists of the MUD maker's public key, device own certificate, signed MUD profile, and actual profile.
• Any user wishes to access the device profile will access the URL containing the MUD maker's public key, device own certificate, signed MUD profile, and actual profile.
• The Device will verify the device certificate with the issuer (MUD maker Public Key). This verification will authenticate the MUD maker. Additionally, by this verification, the user will have access to the public key of the device. The user will verify the signed device profile with the obtained public key of the device. This verification will verify the authenticity of both the device MUD profile and device himself.

F. PROPOSED PROFILE ENFORCEMENT USING A FIREWALL IN HOME NETWORKS
As explained in the previous section, the device converts the received MUD profile to a firewall policy. The WiFi home router has a built-in firewall. This built-in firewall implements the policy. As this firewall is a first entry or exit point, the policy is implemented for the network devices.

IV. DEPLOYMENT AND IMPLEMENTATION
This section presents the deployment and implementation of the Attack model that comprises of Mirai attack setup, proposed detection and identification of configuration and firmware vulnerabilities, Implementation of Ethereum and Hyperledger for Blockchain-based distribution of firmware vulnerabilities to vendors, implementation of open-source MUD (osMUD), and Firewall deployment for enforcement of MUD profile.
To set up the attacker model, the researcher deployed the Mirai command and control server from its publicly available source code [44] having a scanner, loader, and a database.
A DNS server has IP address 192.168.2.53 is set up to resolve the domain queries of the devices. We used Two WiFi Access Routers, one as a controller and another as Potential IoT devices. Router is used as a target bot. The domain name of the CNC is set as ''cnc.sajjad.local.'' The DNS server resolves this domain. In the first phase, a scanner server connects with the Mirai Command and Control Server by resolving the CNC domain (cnc.sajjad.local) and scanning for compromised devices. On successfully compromising the controller WiFi Access Router, the scanner server reports the loader server's scan result. The loader server loads Mirai malware binaries on the compromised WiFi Access Router. An attacker can access Command and Control Server via a remote access application, i.e., putty. The remote access interface shows the number of bots currently connected to the CNC. It also displays possible DDoS attacks that the CNC server can launch by issuing attack commands to the connected bots. We used a script for the identification of default vulnerabilities present in the device. For the testing of the firmware, we used Embed OS. Embed OS is an embedded security testing operating system based on Ubuntu 18.04 preloaded with firmware security testing tools. The proposed distribution of identified vulnerabilities system uses the blockchain technique for information sharing among peer mitigators. As several blockchain technologies are available, to assess which blockchain technology will be more suitable, we implement the proposed collaborative mitigation system using two popular blockchain technology, i.e., hyperledger and ethereum. We configured the smart contract on both of them. In hyperledger, the smart contract is implemented in the form of a chaincode [45]. Ethereum blockchain supports and provides a complete smart contract language [46]. This research set up Ethreum Virtual Machine and hyperledger in our lab on Ubuntu 16.04 operating systems to evaluate the proposed system's performance in both hyperledger and ethereum virtual machines. This research configures a Smart contract on both of them. The collaborator reports the identified vulnerabilities to all the peers' collaborators present in the smart contract via blockchain. In the proposed distribution of identified vulnerabilities system, a smart contract is deployed on each node. Identified Vulnerabilities are shared with the members of the smart contract. The operational flow of a smart contract is depicted in figure 8. A smart contract is compiled using an online solidity browser [47]. The variables returns by Web3 are executed in the geth terminal [48]. After the compilation, a Smart contract is deployed on all the nodes. The contract Application Binary Interface (ABI) is obtained from a solidity compiler.
This research implemented open source MUD called OSMUD [49]. In this study implementation of the MUD policy is performed through a built-in firewall in the MUD Controller (WiFi access router).

V. RESULTS AND DISCUSSION
The following subsection describes the attained results and presents their analysis.

A. RESULT AND ANALYSIS OF PROPOSED CONFIGURATION VULNERABILITIES IDENTIFICATION AND TREATMENT
Most of the Internet of Things devices are made bots by compromising their default credentials. The evaluation of the Proposed 'Configuration Vulnerabilities Identification and Treatment' is carried out by launching a Mirai Malware attack on the WiFi Access Router with and without the proposed solution. As shown in figure 9, without the deployment of the proposed configuration vulnerabilities identification and treatment, the attacker was 100 percent successful in compromising the target system. Comparatively, the Mirai malware attack success rate was 2 percent in the presence of the proposed solution.

B. RESULT AND ANALYSIS OF PROPOSED RISK AUGMENTED MUD PROFILE
As discussed in the MUD evaluation section, the device having a MUD profile without the vulnerability assessment can still be compromised. The evaluation of the proposed risk augmented MUD profile was carried out by launch- ing an attack on a device with and without risk augmented MUD. The attack success rate was 80 percent on a device having a MUD profile without Risk augmentation, as shown in figure 10, while the attack success rate on device having risk augmented MUD profile was 2 percent. In the first case, the device was compromised by exploiting the vulnerabilities in the firmware.

C. RESULT AND ANALYSIS OF AUTHENTICATION IN MUD PROCESS
MUD process involving the generation of MUD profile at MUD maker for a device, hosting the said profile on VOLUME 8, 2020 the MUD file server, and point to the URL of the generated MUD profile does not possess authentication of the entities involved. This scenario may cause bypassing the MUD profile. We evaluate the proposed authentication of the MUD profile, MUD maker, and MUD file server by carrying out an attack comprising of pointing to a rough MUD profile hosted on an authorized MUD file server. The attack was carried out using a phishing attack on the MUD controller. The attack success rate was Eighty percent without the proposed authentication in the MUD process, as shown in figure 11. Contrary to the proposed authentication mechanism in the MUD process, the attack success was 2 percent.

D. RESULT AND ANALYSIS OF ENFORCEMENT OF MUD PROFILE
Around 97 percent attack success rate was achieved when the MUD profile was not enforced, as shown in figure 12.
The attack success percent reduced to 3 percent in case of enforcement of the MUD profile.

E. TIME TAKEN BY THE GENERATION OF MUD PROFILE WITH AND WITH RISK AUGMENTATION
Generation of MUD profile with Risk Augmentation takes more than 600 seconds, as shown in figure 13, as compared to the generation of MUD profile with Risk Augmentation.    hyperledger takes around 7 seconds for its first transaction. For 10,000 transactions, it takes 60 seconds for hyperledger as compared to 430 seconds for the ethereum virtual machine. Figure 16 demonstrates the scalability comparison of the mitigation algorithm. Ethereum implementation of the proposed mitigation scheme is more scalable than hyperledger. It is also noted that transactions per second also decreased with the number of peer nodes. The main reason is the computational complexity of the consensus algorithms.

3) LATENCY
Latency is the measurement of the time taken in disseminating the information to the peer. Timely dissemination of attacker information to the peer involved in collaborative mitigation will help stop the source of IoT Botnets. As can be observed from Figure 16, the first transaction occurs at 350 seconds, and it takes 440 seconds for 10,000 transactions due to the higher difficulty level of ethereum's ''proof of work'' consensus algorithm. Hyperledger first transaction occurs at around 4 seconds, and it takes around 60 seconds for 10,000 transactions.

VI. CONCLUSION
This paper presented an evaluation study of the Manufacturer Usage Description (MUD), identified its weaknesses, and proposed enhancements in its architecture for its effectiveness. It proposed a mechanism for authenticating both the device MUD profile and the MUD file generator. It also proposed a mechanism of MUD profile enforcement using a firewall in home networks. It also proposed a mechanism for the distribution of firmware vulnerabilities to the vendor using blockchain for patching. The implementation results show that proposed improvements improve the security services provided by the Manufacturer Usage Description (MUD). The proposed vulnerabilities distribution system implementation with 'Hyperledger' gives high throughput and less latency due to less complexity of its consensus algorithm than its implementation in 'Ethereum Virtual Machine.' The complexity of Ethereum ''Proof of work'' is higher than the consensus algorithm of Hyperledger. On the other hand, its implementation in 'Ethereum Virtual Machine' demonstrates high scalability compared to its implementation in 'Hyperledger'.