1 Introduction↩︎

The increasing integration of iot devices into cyber-physical systems is enhancing automation, process optimization, and safety [1], [2]. However, the constraints of such devices and networks make it challenging to deploy advanced resource-consuming security mechanisms [3]–[6]. Thus, iot devices represent attractive targets for attackers seeking to exploit weak protections to access sensitive data or launch distributed attacks [7]–[9]. To mitigate this expanded attack surface, the ietf recently introduced the mud standard [10]. mud enables manufacturers to disclose the expected network behavior required for the proper functioning of their iot devices, i.e., the MUD profile[11]. These profiles are formalized into mud files, which are signed by the manufacturer and stored on a MUD Server. A dedicated MUD Controller to be deployed on the user side can retrieve the mud file referenced by the mud URL issued by the iot device at network joining time. Then, the Controller can translate the mud file into network policies and restrictions where any behavior not described in the file is considered unauthorized [10]–[12].

Despite growing interest, several open problems in management, security, and implementation limit the real-world adoption of mud today [11]–[15]. A critical concern is the mudb vulnerability, which affects the security of the standard dhcp-based URL issuance procedure [16], [17]. Given the public nature of mud URLs, a compromised device can issue a spoofed URL that points to an incorrect, yet authentic, mud profile, thereby leading to the enforcement of incorrect network restrictions [12], [16]. The key factor enabling such attacks is that mud decouples policy retrieval from device authentication. The Controller accepts a mud URL based on the authenticity of the retrieved file rather than any proof that the requesting device is entitled to use that profile [10], [13]. Thus, a spoofed mud URL does not inherently raise inconsistencies detectable by the Controller, and any device capable of advertising a valid URL can trigger the installation of (possibly incorrect) corresponding policies. An extension based on X.509 is available for secure URL issuance [10]. However, it is not supported in practice and current mud implementations rather rely on the insecure dhcp extension, due to more convenient plug-and-play device installation [11], [13], [18]–[21]. At the same time, symmetric-key alternatives raise security concerns. The Controller would require access to device-specific secret keys, but an attacker could set up a malicious Controller to recover secret keys of target devices and reuse them to impersonate other devices. Furthermore, the solutions proposed in the literature present additional limitations, such as lack of standard compliance and secure mud profile update mechanisms and excessive manufacturer involvement during mudb verification. Such operational challenges make solving the mudb vulnerability particularly challenging, and motivate the following Research Question (RQ) driving this work:

Contribution. In this paper, we introduce FIDEM, a standard-compliant framework for secure dhcp-based MUD URL issuance. FIDEMestablishes a cryptographic binding between the issuing device and the retrieved mud profile leveraging Schnorr-based zkp authentication, without relying on pki and minimizing manufacturer involvement. We design FIDEMto withstand a stronger, yet realistic threat model compared to prior work, explicitly capturing supply chain compromise scenarios and adversaries capable of exploiting legitimate devices as cryptographic oracles in place of compromised devices. Furthermore, FIDEMalso introduces a unique formal mmm, which explicitly specifies how manufacturers could efficiently maintain and associate mud profiles within the system model. We formally evaluate FIDEMsecurity properties with ProVerif and evaluate its performance against baseline HMAC- and certificate-based approaches in a poc implementation with commercial iot devices (ESP32-S3 and ESP32-C6). Our results show minimal overhead compared to the insecure dhcp extension (\(\sim 7\%, 5 ms\)), and significant savings compared to certificate-based approaches, i.e., FIDEMis up to \(\times 20\) times faster and \(\sim 35\%\) less energy-consuming compared to the X.509 extension with TLS. In summary, this paper makes the following contributions:

• We formalize a stronger yet realistic threat model for mud than prior work, which also considers supply-chain compromise and adversaries capable of exploiting legitimate devices as cryptographic oracles.

• We present FIDEM, a standard-compliant framework that enforces cryptographic binding between iot devices and mud profiles via lightweight zkp. Compared to prior work, FIDEMavoids pki, minimizes manufacturer involvement, and supports secure profile updates.

• We introduce a unique class-based mmm enabling scalable profile association, efficient key management, and lifecycle support.

• We implement FIDEMon real iot devices, compare it to state-of-the-art benchmark approaches, and make the source code available open source ¹ (anonymized for submission).

Roadmap. The remainder of this paper is organized as follows. Sec. 2 introduces the mud standard. Sec. 3 reviews vulnerabilities and limitations in existing solutions. Sec. 4 outlines our system and threat model. Sec. 5 provides the details of FIDEM. Sec. 6 presents a discussion on its security guarantees. Sec. 7 reports experimental results. Sec. 8 discusses limitations and future directions. Finally, Sec. 9 concludes the paper.

2 Preliminaries on mud↩︎

mud grounds on the observation that most iot devices have a narrow operational scope and, therefore, require only a restricted set of network interactions [12]. To enforce this principle, manufacturers formally define the expected network behavior of their iot devices through a set of acls. These specify the minimal set of necessary and allowed network communications for the correct functioning of the iot device [21]. The collection of the acls constitutes the device’s MUD profile, which is expressed in a mud file using yang modules and serialized in JSON format [10], [22]. Thus, the mud file serves as a formal declaration of the device’s native operational requirements. Architecture and File Retrieval. Fig. 1 illustrates the mud architecture and file retrieval procedure [10]. The process begins when the iot device issues a mud url to the network router (step 1), which identifies the location of the device’s mud file. The router forwards the url to the MUD Controller (step 2), which in turn retrieves the mud file from the MUD Server via HTTPS (step 3). Before applying the rules, the MUD Controller verifies the profile authenticity using the associated cms object (step 4). Once validated, the MUD Controller translates the acls specified in the file into enforceable network policies, which the router applies to restrict the device’s communications. According to the standard, the MUD profile remains valid as long as the device is connected to the network [10]. In some deployment scenarios, such as smart homes, the MUD Controller logic can be integrated directly into the router, avoiding url relaying [12], [19], [22].

URL Issuance. The mud standard defines three extension for URL issuance. [10]. The X.509 extension introduces a non-critical certificate field compliant with IEEE 802.1AR, that contains a single url pointing to the online mud file. In this case, the legitimacy of the mud url relies on the authenticity of the certificate used for device authentication. Conversely, the dhcp and lldp extensions embed the url into a string \(\texttt{MUDstring} = \texttt{MUDurl} \,,\, \left[^"\,\,\,^" \,,\, \texttt{reserved}\right]\), where MUDurl is an HTTP-based url compliant with RFC7230 [23], and reserved is reserved for future extensions. Unlike X.509, dhcp and lldp do not provide any built-in mechanism to authenticate the transmitted url and ensure mudb. This lack of protection introduces security issues, such as spoofed mud advertisements, which can lead to incorrect enforcement of overly permissive profiles. Such misconfigurations can expose the network to compromise, enable lateral movement, and facilitate privilege escalation attacks [12], [17].

3 Related Work↩︎

The MUD URL issuance mechanism for mud retrieval is the cornerstone of the mud, determining which set of network policies (i.e., MUD file) the Controller should enforce based on the received url. dhcp and lldp extensions lack security guarantees to ensure the integrity of the issued url [10], [11]. To the best of our knowledge, no prior work focuses on securing these extensions, although dhcp is extensively considered in mud implementations and other works using mud [12], [19], [21], [24], [25]. Table 1 summarizes existing approaches specifically designed to secure the mud URL issuance mechanism.

• * No specific url issuing method is provided. However, we can reduce to one of the standard approaches.

• ** mudb assurance for profile updates relies on manufacturer’s secure urls management.

Device Authentication vs. MUD-Binding. Solutions such as eMUD [22], MUDscan [26], and MUDThread [8] authenticate devices before retrieving the mud file. However, eMUD is vulnerable to replay attacks as it relies on static dcs with no challenge-response interaction. MUDscan introduces challenge-response authentication, but using the manufacturer’s public key. Thus, it mainly ensures that the device belongs to the specific manufacturer, rather than providing mudb. Similarly, MUDThread and MeshGuard leverage IEEE 802.15.4 link layer encryption and authentication [27], [31], but do not ensure mudb. Lastly, proposals from Jimenez J. [29] and Richardson et al. [30] do not provide any cryptographic mechanism to protect the issued url. These examples show that mudb is a distinct security property than device authentication. A compromised device can first authenticate using legitimate credentials, then issue a spoofed mud URL. Thus, mudb is a challenging security property to ensure beyond traditional device authentication.

Manufacturer-Involved Approaches. Garcia et al. [16] and Matheu et al. [28] adopt a different strategy for mud file retrieval: the MUD Controller receives the url directly from the manufacturer after successful device authentication. While this strategy guarantees binding (assuming correct authentication), it introduces significant operational overhead for manufacturers. In fact, they must maintain live authentication services, perform cryptographic operations, and handle additional traffic for mud purposes. We argue that such a workload primarily serves end users and rather discourages manufacturers from adopting mud, thus limiting its widespread adoption. To promote adoption, any solution for secure mudb should minimize manufacturers involvement beyond generating, updating, and serving mud files.

pki Limitations. A proposal from Richardson et al. [17] offers secure binding and is fully compliant with the mud standard, without requiring active manufacturer involvement during mud file retrieval. However, it relies on X.509 certificates and a pki, which have seen limited support in practice. Although RFC 8520 defines a non-critical X.509 extension, to the best of our knowledge, no available or open implementations currently support it [11], [13], [18]–[21]. Furthermore, native X.509/802.1AR support remains limited in consumer iot devices due to operational issues related to the certificate size, computational overhead, and lifecycle management challenges for constrained devices [4], [5], [16], [28], [32]. This is also highlighted by the fact that the majority of related works avoid relying on pki (see Table 1). Recent efforts, such as C509 certificates, aim to provide compact encodings for constrained environments [33]. However, these are still in draft status and have not yet been standardized. By contrast, dhcp remains the de facto baseline for IP address assignment in iot [34], driving industry preference for dhcp extension over X.509. This trend creates a deployment-driven motivation to focus on strengthening the dhcp extension.

Standard Compliance. None of the previous works, except [17], is standard-compliant (see Table 1). Breaking the standard compliance for mud file retrieval creates interoperability issues and increases the complexity of management and enforcement. In contrast, a standard-compliant solution is highly desirable, as it favors interoperability and adoption.

Secure MUD Profile Update. A secure mud profile update mechanism is crucial to maintain the integrity and consistency of enforced policies over time. Without it, attackers could exploit outdated or tampered profiles, potentially bypassing security restrictions. Despite its importance, existing solutions except Richardson et al. [17] do not address this aspect, leaving a remarkable gap in the overall security of the mud framework.

Alternative Approaches. Alternative approaches, such as remote attestation or certificateless encryption, may seem viable solutions to ensure mudb. Remote attestation verifies that the device is in a genuine state [35]–[37], which could indirectly support trust in the issued url. However, its scope is broader than mudb, as it focuses on device integrity rather than the correctness of specific configuration data. Moreover, secure attestation typically requires expensive hardware roots-of-trust and computational energy [35], [37]. On the other hand, certificateless encryption aims to reduce dependence on traditional dcs. However, it still relies on a trusted key generation center and introduces key escrow concerns [38]–[40]. These limitations make both approaches impractical for lightweight, standard-compliant mud deployments, where simplicity and interoperability are key factors.

In summary, existing solutions fail to guarantee the mudb property, impose excessive operational overhead on manufacturers, or lack standard compliance. Furthermore, existing proposals overlook secure profile updates, leaving devices vulnerable to outdated or tampered configurations. Alternative approaches, such as remote attestation or certificateless encryption, introduce complexity and hardware requirements incompatible with constrained environments. These gaps highlight the need for a lightweight, standard-compliant mechanism that enforces mudb without relying on heavy cryptographic infrastructures or requiring active manufacturer involvement.

4 System and Threat Model↩︎

System Model. Fig. 2 illustrates the system model considered in this work. We consider a local mud-enabled network composed of heterogeneous resource-constrained iot devices, produced by various manufacturers and connected to a central router. Devices issue their mud URL using the available dhcp extension. We consider a local iot network composed of heterogeneous iot devices, produced by various manufacturers and connected to a central router. Following common practice, we integrate the MUD Controller into the router [12], [19]. To clearly delineate the scope of this work, we distinguish between the mud Domain and the Operational Domain. The former includes the MUD Controller, the MUD Server, and all traffic and operations governed by the mud framework. Conversely, the latter encompasses all existing infrastructure, services, and procedures required for device functionality, independent of mud. Within the Operational Domain, we model an Operating Server that handles routine device operations such as updates, authentication, and management tasks. These are performed using pre-existing mechanisms and are outside the scope of mud and this work. By contrast and according to the limitations identified in Sec. 3, we assume that the MUD Server is a passive entity whose sole role is to serve the mud file corresponding to a given url. It does not participate in cryptographic operations related to authentication and mudb verification. Finally, we adopt a standard cryptographic model in which secret material stored on devices is protected in secure hardware. Although we acknowledge that some iot devices lack strong hardware protections, this assumption is consistent with a large body of prior work [26], [41]–[44].

Threat Model. We consider an advanced, yet realistic and conservative threat model, drawing on examples and motivations from real life. We consider that iot devices cannot be assumed trustworthy at the time of deployment, as they can be compromised at any stage of their lifecycle, including manufacturing or distribution, reflecting well-documented exposure of iot supply chains [45]–[47]. We thus focus on two representative compromise scenarios, namely Compromised Legitimate Device and Counterfeit Device Impersonation, both leveraging binding limitations of the mud standard architecture [10]. In the former, the attacker compromises a genuine device and aims to induce the enforcement of a more permissive network policy than the one originally intended for that device. Since mud URLs are publicly accessible, an attacker can systematically analyze the product ecosystem of a manufacturer identifying those with more permissive policies. Compromised devices thus advertise spoofed URLs corresponding to other devices from the same manufacturer, whose mud profile grants broader communication privileges. This behavior is consistent with prior observations in the literature [22], [26]. In the latter scenario, the attacker introduces counterfeit devices into the system, presenting them as legitimate products of a target manufacturer. Although this may appear an overly strong adversary, it is in fact supported by real-world incidents involving fraudulent networking and iot equipment commercialized through third-party vendors or online marketplaces [45]–[47]. In such a scenario, since the attacker does not need to break cryptographic protections or impersonate manufacturer signatures, counterfeit devices can simply advertise a valid URL associated with a legitimate mud file. Device-level authentication, if any, typically occurs at later stages (e.g., during Cloud-based onboarding), and it does not prevent such attack, leading to the enforcement of (incorrect) network policies based on the spoofed URL [13], [16], [28]. In line with our system model, we consider an attacker that cannot directly access secret material stored on devices or the manufacturer’s private keys. However, the attacker can access to one or more legitimate devices of the target manufacturer. This reflects a realistic capability, as such devices are commercially available and can be freely acquired. Thus, the attacker can leverage them as cryptographic oracles, enabling cryptographic operations without possessing the underlying secrets. We model the set of all such devices as a logical entity \(D_{oracle}\), which may be locally or remotely accessible. Communication between a compromised device \(D_1\) and \(D_{oracle}\) is assumed to occur through the network infrastructure, in particular via the router enforcing mud policies. This interaction can be facilitated by permissive rules commonly observed in mud profiles, such as those allowing communication among devices from the same manufacturer [12], [13], [26]. These rules make such communication appear as legitimate from the network perspective, further complicating detection. We explicitly exclude out-of-band channels (e.g., Bluetooth, cellular) from the model, to maintain focus on network-enforced policies.

Attacker objectives. Within this threat model, the attacker aims to achieve three objectives: (i) recover secret material through passive observation of communications (O1), mislead the Controller into classifying a device as belonging to a different manufacturer (O2), and induce the enforcement of an unintended mud profile within the same manufacturer domain (O3). The latter captures the core mudb vulnerability, namely, the ability of an attacker to exploit the lack of binding between devices and their declared mud profile. We analyze the security of FIDEMagainst these objectives in Sec. 6.

5 FIDEM↩︎

This section presents FIDEM, our framework designed to enforce cryptographic mudb. First, Sec. 5.2 introduces the concept of mmm, and Sec. 5.3 presents our proposed mud file extension to enable the MUD Controller to retrieve the necessary cryptographic material to carry out mudb verification. Then, in Sec. 5.4 we detail FIDEMzkp-based verification procedure, including parameter embedding and profile update. Table 3 (Appendix 10) summarizes the terminology used in this work.

5.1 Design Requirements↩︎

FIDEMrelies on five main design requirements, summarized in Table 2. Although pkis provide a natural way to bind identities and resources, setting up and maintaining such an infrastructure introduces considerable complexity and management costs [48], [49]. Therefore, although an extension for MUD based on X.509 is available for secure URL issuance [10], current mud implementations rather rely on the insecure dhcp extension [11], [13], [16], [18]–[21]. These considerations motivate our design requirement of avoiding reliance on pki (R1), and rather rely on the plug-and-play dhcp extension. This consideration creates a deployment-driven need to secure the dhcp extension for URL issuance. However, several security and implementation challenges arise when establishing secure dhcp-based mudb against our advanced threat model (Sec. 4) without relying on a pki infrastructure. A major limitation of the solutions proposed in the literature is their lack of standard compliance. Adopting non-standard compliant solutions significantly reduces interoperability and increases implementation complexity. This particularly holds for the Controller, which would need to support multiple non-standard URL issuance mechanisms. Therefore, any security mechanism and mud extension should fit the standard by design, seamlessly integrating with the existing specification to increase interoperability and avoid increasing complexity. This directly motivates the need for standards compliance and backward compatibility (R2), ensuring that the proposed solution can be incrementally deployed without disrupting existing infrastructures.

Another challenge arises when considering symmetric-key approaches. At first glance, mechanisms based on shared secrets (e.g., HMAC) appear attractive due to their efficiency. However, the mud Controller would need access to device-specific secret keys, which require secure key provisioning from manufacturers. Besides increasing operational costs due to secure key provisioning, such a strategy introduces critical security issues. An attacker could legitimately set up a malicious Controller to recover secret keys of target devices and reuse them to impersonate other devices. Preventing such misuse leads to the requirement of resistance to mud URL redirection and impersonation attacks (R3). Moreover, an overlooked implementation aspect in the literature involves the role of manufacturers in the mud ecosystem. Existing approaches heavily rely on manufacturer-assisted authentication, where devices or controllers interact with manufacturer-operated services at runtime. However, manufacturers of iot devices typically produce and maintain tens or even hundreds of products. Thus, it would be extremely expensive for such manufacturers to maintain an additional always-on infrastructures that actively responds to authentication requests at every device deployment. We argue that such operational costs would ultimately discourage the adoption of mud in their products. Therefore, a key challenge is to design a solution that enforces secure mudb without requiring active manufacturer participation, motivating the requirement of minimizing manufacturer involvement (R4) and limiting them to hosting and maintaining information on a public web page rather than actively interacting with online parties. Finally, a further challenge lies in the dynamic nature of iot devices. mud profiles could change over the life of a device, e.g., due to a software update, firmware upgrade or inadvertent mistakes [11], [17]. For example, a smart camera may receive a firmware update with new functionalities requiring it to contact new vendor analytics servers that were not part of its original mud profile. Ensuring that updates are correctly propagated and securely enforced considering aforementioned challenges is a non-trivial problem. This leads to the requirement of supporting secure mud profile updates (R5).

5.2 mud Management Model↩︎

An efficient mud management strategy is essential to balance security, system complexity, updates, and overhead related to keys, mud files, and certificate storage. Despite its importance, existing works focus on the technical implementation of mud-based solutions, overlooking how manufacturers are expected to manage their mud files in practice. Assigning a unique mud file and url to each device, although technically feasible, is inefficient. Devices with the same network behavior would unnecessarily be associated with distinct files and URLs, resulting in an increased management and signing overhead. At the same time, we observe that mud files tend to be oriented toward classes of devices rather than individual instances [10], [29]. Building on this observation, we propose a mmm in which devices are grouped into classes, each assigned a single mud profile. Devices within the same class share identical network requirements and are therefore linked to the same mud file and url. For instance, a smart camera and a smart doorbell from the same manufacturer, although having different purposes, may require the same network services, thus having the same network profile. This model significantly reduces management and storage overhead, as the number of mud files to sign and store scales with the number of distinct MUD profiles, rather than with the total number of iot devices.

Manufacturers are uniquely identified using standardized identifiers, such as the oui or eui [50]. Different firmware versions may result in different network profiles, leading to distinct mud files classes. Conversely, different firmware versions that however exhibit the same network behavior belong to the same MUD class.

mud File Update. During a device’s operational lifecycle, software updates may alter its network behavior [11], [17], thereby requiring a change in the associated MUD profile and reassignment to a different MUD class. In this case, the device must receive the new mud url as part of the update content. This triggers a url reissuance process, in which the MUD Controller obtains the new mud file and updates the device’s network policy accordingly. Additionally, mud files may occasionally contain errors or incomplete information, which requires corrections or replacements [17]. In this second case, the device and the MUD Controller are typically unaware of the change [17]. To address this, we adopt a publish-subscribe model [13]: the MUD Controller stores the signature of the current mud file and periodically checks for updates. A change in the signature indicates a file update, triggering the MUD Controller to retrieve and validate the new file, updating network policies accordingly.

5.3 Key Management and mud File Extension↩︎

We propose a key management approach that associates a secret key \(K_c\) with each mud class \(C\). Every manufacturer provides iot devices with the secret key corresponding to their mud class, namely \(K_c\). According to our system model, we consider this key to be stored in secure hardware, ensuring protection against physical extraction. For each class, we also define public cryptographic parameters: an ec, a base point \(G\) of prime order \(n\), and the point \(X_c = K_c \cdot G\) on the curve. The point \(X_c\) binds the secret key \(K_c\) to the MUD class \(C\), enabling verifiable association without exposing the secret. We thus propose extending the standard mud file template with a cryptographic module containing these parameters together with \(MUD_{ID}\). We provide the extended mud file template in Appendix 11. In this extension, manufacturer-id and class-id represent the manufacturer identifier and the mud class identifier, respectively; curve specifies the elliptic curve name, which determines the base point \(G\); p-format indicates whether the elliptic curve point \(X_c\) is given in compressed or uncompressed format; class-key contains the public point \(X_c\); hash-alg defines the hashing algorithm used during mudb verification. Upon signature verification, the Controller extracts this cryptographic information to carry out the mudb procedure. This approach is efficient since it leverages the mud class abstraction, reducing the number of keys to manage from per-device to per-class.

5.4 MUD Binding Verification↩︎

Binding Verification Problem. Ensuring mudb under the defined design constraints and mmm requires an iot device to prove to the Controller that it possesses the secret key \(K_c\) associated with the public value \(X_c\) specified in the MUD file. At the same time, such a proof must not reveal \(K_c\) to the Controller, and neither require its direct disclosure or transfer. This requirement is fundamental to prevent key leakage, preserve security under the considered threat model, and avoid the limitations of symmetric-key approaches. zkp schemes provide a well-suited cryptographic primitive to address this mentioned challenge, allowing us to design a scheme to enforce mudb while satisfying the constraints of standard compliance, scalability, and minimal manufacturer involvement.

Binding Verification Mechanism. During manufacturing, the iot device is equipped with the mud url associated to the MUD class it belongs to, the corresponding secret key \(K_c\), and the MUD class public parameters \(X_c\), \(EC\), \(G\), \(n\). At network joining time, the iot device has to securely deliver its mud url, proving the mudb property. To this end, it performs the mudb verification procedure shown in Fig. 3 and discussed below.

1. The iot device samples a random value \(r \sim \mathcal{U}\left(n\right)\) and stores it in secure memory. Then, it computes the EC point \(R = r \cdot G\) as commitment for the sampled \(r\). It then sends a dhcp Discovery message including option 161 (see Sec. 5.4.1), which carries the mud url and the commitment \(R\).

2. The MUD Controller extracts the url, retrieves the referenced mud file, and verifies its authenticity. Upon verification, it retrieves the curve name \(EC\) with the corresponding parameters \(G\), \(n\), and the key commitment \(X_c\). It then samples a random challenge \(C\) and includes it in option 161 of the dhcp Offer message.

3. The iot device computes the zkp response as \(Z = r + H \cdot K_c\), where \(H = Hash\left(R \; || \; X_c \; || \; C \; || \; URL\right)\), and \(Hash(\cdot)\) is a secure hash function [51]. The device includes \(Z\) in option 161 of the dhcp Request message. In parallel, the MUD Controller computes the expected hash value \(H\) as well.

4. The MUD Controller extracts the received zkp response, and verifies the equality \(Z \cdot G \stackrel{?}{=} R + H \cdot X_c\). If the check passes, the mudb verification is successful. In such a case, the MUD Controller responds with a dhcp Ack message, translates the acls in the mud file into network polices, and enforces them. Otherwise, the procedure is aborted and network access is denied.

Upon device authentication, the MUD Controller saves a table, termed as MUD table, with entries the device MAC address, its \(MUD_{ID}\), the received mud url, and the mud file signature.

5.4.1 zkp Parameters Embedding↩︎

As backward compatibility is one of our priorities and constraints, it is essential to preserve message formats as defined by the standard. To achieve this, we leverage the available reserved field in the MUDstring to carry the commitment \(R\) as illustrated in Fig. 4 (a) [10]. However, the space available in the reserved field may not suffice to include the full ec point. In fact, dhcp messages impose strict size limitations: each option can carry at most 255 bytes, and the entire dhcp message cannot exceed 576 bytes [52]. These constraints can make it challenging to embed all required data within a single option. To address this limitation, we propose an alternative approach: include the commitment \(R\) in a separate available dhcp option and specify the option number used in the reserved field, as shown in Fig. 4 (b). This design ensures interoperability with devices from different vendors, which may already use custom dhcp options for other purposes. By providing flexibility in option allocation, we avoid collisions and maintain compatibility across heterogeneous environments.

5.4.2 mud Profile Update↩︎

Maintaining correct and updated network restrictions on mud-enabled iot networks requires a secure mud profile update mechanism. To address potential changes in mud files due to corrections, FIDEMleverages a publish-subscribe approach [13]. The mud Controller periodically verifies whether the mud file signatures of connected devices differ from those stored in the mud table. If a mismatch is detected, the Controller automatically retrieves the updated mud file, refreshes its signature, and enforces the new network restrictions. Conversely, when an iot device already registered in the mud table issues a new url, the mudb verification procedure must be executed again. In this case, an additional check is required compared to the initial registration. We observe that a device cannot change its manufacturer during its lifecycle [17]. Therefore, if the new url points to a mud file associated with a different manufacturer, the MUD Controller aborts the procedure, and if possible, alerts the network administrator of suspicious behavior. In scenarios where a software update does not alter the device profile, the device typically reboots to apply the update. This reboot triggers a new dhcp handshake. Since the profile remains unchanged, the url matches the entry stored in the mud table. In this specific case, the Controller can skip the verification procedure, and omit the challenge \(C\) in the dhcp Offer message. Appendix 12 provides a flowgraph summarizing the update procedure described above.

6 Security Analysis↩︎

This section presents the security analysis of the mudb verification procedure proposed in FIDEM  explaining how attacker objectives O1–O3 are mitigated.

6.1 Security Considerations↩︎

Security Foundations. The security of the mudb verification mechanism presented in Sec. 5.4 relies on two fundamental considerations. First, each device stores the private key \(K_c\) in tamper-resistant memory, making physical extraction infeasible, in line with assumptions in prior works [26], [41], [43], [44]. Moreover, recovering \(K_c\) from \(X_c\) is computationally infeasible under the ecdl assumption [53]. The same holds for the nonce \(r\) with respect to the commitment \(R\). Under these assumptions, an adversary observing the pair (\(R\), \(Z\)), and knowing the ec parameters cannot recover \(K_c\) or \(r\). Consequently, a malicious iot device unaware of the correct \(K_c\) cannot compute a valid response to the challenge of the MUD Controller. Since the \(K_c\) and \(r\) are never transmitted, these properties address the attacker objective O1 (secret key recovery).

Manufacturer and Profile Integrity. FIDEMenforces manufacturer and profile integrity through two mechanisms. During initial verification, the MUD Controller validates the signature of the mud file retrieved at the supplied url, ensuring authenticity of the device manufacturer. During profile updates, FIDEMguarantees that a device cannot change manufacturer over its lifetime. If a newly-issued mud url points to a file signed by a different manufacturer, the MUD Controller aborts the protocol and flags the event as suspicious. This prevents compromised or counterfeit devices from migrating across manufacturers or issuing unauthorized urls. Such properties address the attacker objective O2 (cross-manufacturer impersonation).

Resistance to Replay Attacks and Oracle Abuse. The attacker may record legitimate \((R', Z')\) pairs and replay them to bypass verification, luring the MUD Controller to enforce incorrect restrictions. Alternatively, the attacker may leverage \(R_{oracle}\) as a cryptographic oracle to compute zkp values on behalf of the compromised device \(D_1\). To prevent such attacks, FIDEMrelies on an interactive Schnorr protocol in which each execution uses a fresh challenge \(C\). Since a previously recorded zkp response \(Z'\) is bound to an old challenge \(C'\) sampled by the MUD Controller, it cannot be replayed in a new session. In fact, \(H' = Hash\left(R \; || \; X_c \; || \; C' \; || \; URL\right)\) used to compute \(Z'\), differs from \(H = Hash\left(R \; || \; X_c \; || \; C \; || \; URL\right)\) since \(C \neq C'\). Furthermore, the mudb verification occurs during the dhcp handshake, before the device obtains network access. Therefore, a compromised device \(D_1\) cannot communicate with \(R_{oracle}\) during the verification phase. These properties eliminate adaptive oracle attacks and address the attacker objective O3 (mud profile escalation).

Security Under Nonce Reuse Scenarios. Nonce uniqueness is critical for interactive zkp-based security. If the same \(r\) is reused across two sessions with different challenges, an adversary can eliminate it and compute \(K_c = (Z_1 - Z_2)(H_1 - H_2)^{-1} \quad mod \; n\), breaking the binding mechanism. Therefore, the MUD Controller must track past commitments \(R\) to detect reuse. Conversely, using different nonces with the same challenge does not compromise security, as \(H\) incorporates \(R\), ensuring unlinkability.

In summary, FIDEMaddresses all security concerns raised by the threat model and ensures that the MUD Controller can securely prove mudb even in the presence of compromised or counterfeit devices.

6.2 Security Assessment with ProVerif↩︎

To rigorously validate the security of the proposed zkp-based binding mechanism (Sec. 5.4), we use ProVerif [54], a widely recognized tool for automated protocol analysis [55]–[58]. ProVerif is especially useful when creating new protocols that leverage existing cryptographic primitives, whose security has already been proven, as is the case for FIDEM. ProVerif evaluates the security of the protocol under the Dolev-Yao attacker model [56]. If an attack is possible, ProVerif provides a trace to reproduce it. We formally modeled FIDEMin a single protocol round and executed multiple queries to verify secrecy, resistance to guessing attacks, and authentication properties. Interested readers can find the source code of FIDEMwithin ProVerif in our GitHub repository. Fig. 5 summarizes the results of our formal security analysis. Appendix 13 provides detailed query explanation and interpretation. Queries Q1 and Q2 prove that secrets r and Kc are not exposed to the adversary. They represent the secret nonce \(r\) and the MUD class key \(K_c\), respectively. Successful queries Q3, Q4, Q5 confirm injective correspondence between successful bindings, commitments \(R\), challenges \(C\), and responses \(Z\), respectively, thereby preventing replay attacks and ensuring freshness. In summary, our automated analysis through ProVerif shows that FIDEMprovides strong secrecy and mudb guarantees.

7 Experimental Evaluation↩︎

This section presents our extensive experimental evaluation of FIDEM. Our poc source code is available on GitHub, while implementation details are in Appendix 14.

7.1 Experimental Setup and Settings↩︎

Setup. Fig. 6 illustrates the setup of our experimental poc implementation of FIDEM. We use two reference iot devices. We first consider the ESP32-S3, an embedded resource-constrained iot device equipped with a dual-core XTensa LX7 MCU, 512 KB of internal SRAM, and integrated with a 2.4 GHz, 802.11 b/g/n WiFi-4 card. ² This device does not feature secure storage capabilities, allowing us to deploy and test our solution on a general-purpose hardware not equipped with advanced security features. Moreover, we also consider the ESP32-C6 microcontroller, equipped with a 32-bit RISC-V processor, a 320 KB ROM and a 512 KB SRAM, and integrated with a 2.4 GHz, 802.11 b/g/n WiFi-6 card. ³ It also features a hardware tee, providing secure storage and protected cryptographic operations. Including such a device in our poc and testing performance on it allows us to evaluate the impact on performance of a hardware capable of enforcing protection of cryptographic secrets stored onboard the device. We implement the MUD Controller using a DELL Latitude 7400 laptop equipped with Ubuntu 22.04.5 LTS and an AlfaNetwork antenna. ⁴ We collect energy consumption using a Power Profiler Kit II from Nordic, ⁵ a high-precision measurement tool designed to monitor real-time current draw and energy usage of embedded devices. It connects directly to the iot device and provides accurate profiling of power consumption during different operational phases. For implementation, we use the standard ec secp256r1 [59].

Settings. We experimentally evaluate FIDEMwith respect to two key metrics: (i) computational overhead and (ii) additional energy consumption induced by the zkp-based mudb verification procedure. For comparison, we consider three benchmarks: (i) standard dhcp, following the standard RFC8520 [10]; (ii) X.509 with HTTP, using the standard X.509 certificate extension, shared via HTTP payload; and (iii) X.509 with TLS, using the standard X.509 certificate extension, used for TLS handshake [60]. Where possible, we implement FIDEMwith and without using the tee, to assess the overhead due to tee involvement and computations. For each scenario, we collect data from 100 protocol runs and report results through boxplots, showing the median value of the metric of interest. We assess the computational overhead by measuring the time required to carry out the mudb verification procedure presented in Sec. 5.4. Therefore, we consider the elapsed time of the overall mudb verification procedure at MUD Controller side, from the reception of the dhcp Discovery message, up to reception and verification of the zkp response received. Note that this is the overall time to complete the procedure, including also operations executed on the iot device under test. We evaluate energy consumption only on the iot device, as the MUD Controller is not resource-constrained and its energy usage is considered not to be a concern. We consider the energy consumed starting from system setup (including cryptographic context initialization) up to the reception of the dhcp Ack message, signaling successful mudb.

7.2 Results↩︎

Figure 7 reports our complete experimental results in terms of computational and energy overhead for mudb verification using FIDEM  with ESP32-S3 (Fig. 7 (a), 7 (c)) and ESP32-C6 (Fig. 7 (b), 7 (d)) devices.

Considering the execution time with the ESP32-S3 device (Fig. 7 (a)), FIDEMintroduces minimal delay compared to the standard DHCP method. FIDEMrequires a median time of \(9.06ms\), which is \(\sim 30\%\) more than the time required by the standard dhcp issuing method (\(6.99ms\)). We recall that, although lightweight, the standard DHCP mechanism does not ensure mudb, being thus unsuitable for secure deployments. At the same time, FIDEMsignificantly outperforms X.509 leveraging both HTTP and TLS, which require a median time of \(1.05~s\) and \(1.79~s\), respectively. Such a large time difference is due to the additional operations required by connection establishment. X.509 with HTTP requires setting up a TCP connection, and X.509 with TLS adds several further cryptographic pki-based operations during the handshake to set up a secure connection. We acknowledge that such a secure connection provides many more usable security guaranties beyond secure device enrollment and mudb; however, it requires a pki, expensive to deploy and manage for IoT manufacturers. As demonstrated by our proposed FIDEM approach, this is not necessary to ensure mudb.

When considering the energy consumption with the ESP32-S3 (Fig. 7 (c)), we notice that standard DHCP method exhibits the lowest energy usage, i.e., a median of \(354mJ\). We can explain this result by recalling that no security checks are performed when using this mode. Our proposed solution, FIDEM, introduces a slight increase compared to DHCP, i.e., a median consumption of \(385mJ\), for an overhead of \(\sim8\%\). This negligible energy overhead demonstrates that ec-based zkp operations are suitable for constrained devices. X.509 with HTTP shows an energy consumption comparable to FIDEM  i.e. a median of \(370 mJ\). Here, we notice an apparent mismatch between the relationship of time and energy consumption between X.509 with HTTP and FIDEM: although FIDEMis quicker, it consumes approximately the same energy. We can explain these results by recalling that FIDEMrelies on cryptographic operations executed in the caam module of the ESP-32 device. Activating and using such dedicated hardware requires additional energy, partly outweighing the energy gained from the reduced duration of the protocol compared to X.509 over HTTP. Moreover, we recall that using HTTP to issue the X.509 certificate lacks security guarantees: the certificate is transmitted as a plain payload and can be replayed, failing to ensure the binding property (R3, see Sec. 5.1). Conversely, X.509 over TLS incurs a substantial energy overhead, i.e., a median of \(574 mJ\), nearly double that of FIDEM, with wide variance due to the complexity of the TLS handshake. This high consumption is due to the time required to complete message exchange (as noticed for Fig. 7 (a)) and due to the higher number of cryptography operations involved. Furthermore, during the tests, we observed several network failures, which have an additional influence on the time required to complete the mudb process.

When experimentally evaluating FIDEMon the ESP32-C6 device, we observe that the performance trend follows the one already discussed for the ESP32-S3 device:FIDEMis \(\times 20\) faster and consumes \(\sim35\%\) less energy compared to X.509 over TLS. At the same time, compared to the trends observed for the ESP32-S3 device, we notice that using the ESP32-C6 device increases the baseline time required for dhcp handshake. This is evident when comparing the standard DHCP data series between Fig. 7 (a) and Fig. 7 (b). This is due to several factors, including differences in architecture, hardware, and wifi cards between the two models, which lead to a larger fixed connection plus stack cost. Nevertheless, the ESP32-C6 device is natively optimized for cryptographic operations, allowing to reduce FIDEMtime overhead compared to standard DHCP to \(\sim7\%\) (\(\sim 5 ms\)). Furthermore, we also compare the performance of FIDEMon the ESP32-C6 device with and without using the tee secure hardware, to evaluate the additional delay and energy consumption introduced by such a component. Fig. 7 (b) shows that leveraging the tee introduces limited computational delay of \(\sim 3.5 ms\) and \(\sim6 mJ\) increased energy. This overhead is induced by the execution of required operations for switching from the insecure to the secure worlds. Finally, we notice that although taking longer execution times, the ESP32-C6 requires less energy consumption compared to the ESP32-S3. Specifically, FIDEM(with TEE) requires \(\sim334 mJ\). This indicates a lower average power profile and design of the ESP32-C6, which favors idle states during waiting periods.

In summary, our results demonstrate that FIDEMachieves strong security guarantees with negligible impact on the resources and lifetime of constrained iot devices.

8 Discussion↩︎

Out-of-Band Communications. Aligned with the mud standard RFC8520 [10], our system model considers only iot traffic traversing a monitoring entity (e.g., a router), where mud profiles are enforced. Accordingly, out-of-band channels such as cellular networks or direct device-to-device communications (e.g., Bluetooth or ZigBee) are excluded. While resource-constrained devices rarely support cellular connectivity, short-range communication technologies are commonly available in higher-end iot devices. These channels could be exploited by an attacker to bypass the router and offload cryptographic operations to \(D_{oracle}\), thereby undermining mudb verification. However, addressing such scenarios would require extending mud beyond IP-based communications, entailing a fundamentally different architectural model. This would significantly alter both the system and threat models assumptions considered in this work, effectively defining a distinct research problem rather than a direct extension of FIDEM. Investigating native mud integration into non-IP protocol stacks therefore represents a promising direction for future work.

Scalability. FIDEMoperates exclusively during the dhcp handshake, i.e., before the device receives network connectivity and before any operational traffic is allowed. As such, it does not introduce persistent computational or communication overhead during normal device operation. In contrast, the only additional cost is a one-time, bounded delay during onboarding (\(\sim5 ms\)), as quantified in our evaluation. Consequently, scalability in this context is related to the mud Controller’s capability to handle multiple concurrent onboarding requests. However, this is a property inherent to the implementation and deployment of the Controller, not to FIDEMitself. Similarly, potential dos scenarios target the Controller’s exposure during the dhcp phase, which already exists in standard deployments. Thus, FIDEMdoes not amplify this attack surface beyond a minimal and short-lived processing overhead.

Extension to Non-Interactive Scenarios. Our design of FIDEMfocuses on the dhcp extension due to its widespread adoption for IP address assignment and its support in current mud implementations. The mud standard also defines an lldp extension for URL issuance; however, lldp is inherently non-interactive. As a result, FIDEMcannot be directly extended using non-interactive Schnorr-based zkp authentication [61], as this would expose the system to pre-computation and replay attacks. A possible mitigation is to leverage interaction with the Operating Server for device identity authentication. However, as discussed, device authentication alone does not guarantee mudb: a malicious device may successfully authenticate while still issuing a spoofed URL. To address this, after successful authentication, the Controller can rely on the verified device identity to directly retrieve the corresponding mud file from the MUD Server, rather than trusting the URL advertised by the device. While this approach involves the MUD Server during file retrieval, it does not require additional cryptographic operations.

MUD Management Model and Group-Based Authentication. Our proposed mmm associates a single secret key (\(K_c\)) with each mud class. While we assume secure storage of cryptographic material on iot devices, this design introduces an inherent limitation: if \(K_c\) is compromised, all devices within the corresponding mud class are affected. A potential mitigation, while still avoiding reliance on a pki and digital certificates, is the adoption of group-based authentication schemes, where devices share a common public key but hold distinct private keys [62]. In this setting, a class-level public key could be included in the mud file, while each device is provided with a unique private key, thus overcoming the shared-secret limitation of our mmm. However, group signature schemes introduce additional challenges, including complex key revocation, scalability limitations, and dependence on trusted setup procedures [62]–[64]. Considering such limitations and our system model, we believe that the proposed zkp-based approach at the roots of FIDEMoffers the best compromise at present. These trade-offs suggest that alternative mmms require careful evaluation, motivating future research toward designs that better balance security, scalability, and efficiency.

9 Conclusions↩︎

In this paper, we presented FIDEM, a framework designed to address the fundamental gap in the mud standard by securing the widely adopted but insecure dhcp-based mud URL issuance mechanism. FIDEMleverages Schnorr-based zkp authentication to cryptographically enforce the mudb property while remaining fully standard-compliant and backward compatible. By design, FIDEMwithstands a stronger adversarial model than existing approaches, including attackers capable of exploiting legitimate devices as cryptographic oracles. Furthermore, it achieves this without relying on pki, avoiding the associated operational complexity, and without requiring active manufacturer involvement, thus preserving scalability and deployability in heterogeneous iot environments. Experimental results from a real-world poc demonstrate that these security guarantees are achieved with minimal overhead compared to standard dhcp, while significantly outperforming certificate-based solutions (\(\times 20\) faster and \(\sim35\%\) less energy than X.509 over TLS). Future work will investigate extensions to LLDP-based deployments, mitigation of out-of-band communication threats, and alternative strategies such as group-based digital signatures.

10 Notation↩︎

Table 3 summarizes the notation used in this work.

11 Extended MUD File Template↩︎

<-"ietf-mud:mud": { ->
<-"mud-version": 1, ->
<-"mud-url": "<URL>", ->
<-"last-update": "<YY-MM-DD>T<HH:MM:SS>Z", ->
<-"cache-validity": <HOURS>, ->
<-"is-supported": true, ->
<-"systeminfo": "<DESCRIPTION>", ->

<<"crypto-fidem:crypto": {>>
  <<"mud-identity": {>>
    <<"manufacturer-id": "<HEX>",>>
    <<"class-id": "<HEX>">>
  <<},>>
  <<"ec-params": {>>
    <<"curve": "<CURVE-NAME>",>>       
    <<"p-format": "<UNCOMPRESSED/
                    COMPRESSED>",>>
    <<"class-key": "<EC-POINT>">>
  <<},>>
  <<"hash-alg": "<sha-256>">>
<<},>>

<-"from-device-policy": { ->
<-  ... ->
<-}, ->
<-"to-device-policy": { ->
<-  ... ->
<-} ->
<-}, ->

<-"ietf-access-control-list:acls": { ->
<-... ->
<-} ->

Listing [lst:MUDextension] shows the proposed extended MUD file template including the FIDEMblock to include the necessary cryptographic material for mudb verification.

12 MUD Profile Update↩︎

Fig. 8 shows the flowchart diagram for the MUD profile update logic implemented at the MUD Controller side with FIDEM.

13 ProVerif Queries explanation↩︎

With reference to the Proverif queries tested shown in Fig. 5, we provide a detailed description and explanation. The queries output Q1 and Q2 not attacker(elem[]) is true indicates that the attacker cannot retrieve the value of elem[]. Otherwise, if the output is false, the attacker can retrieve it. They represent the secret nonce \(r\) and the mud class key \(K_c\), respectively. The general query inj-event(event_A) \(==>\) inj-event(event_B) expresses an injective correspondence property. It means that for every occurrence of event event_A, there is a unique corresponding occurrence of event event_B earlier in the protocol execution. If the query output is true, every successful event_A is guaranteed to correspond to a unique prior event_B, thus preventing replay attacks and ensuring that protocol steps are correctly linked. In contrast, false output implies the protocol cannot guarantee that every successful event_A is tied to a unique prior event_B, which undermines correctness and freshness guarantees. In our ProVerif code, event successful_binding(true) represents successful mudb verification, tx_commitment(R), tx_challenge(C) and tx_response(Z) represent events of sending commitment \(R\), challenge \(C\), and zkp response \(Z\), respectively. Successful queries Q3, Q4, Q5 confirm injective correspondence between successful bindings, commitments \(R\), challenges \(C\), and responses \(Z\), respectively, thereby preventing replay attacks and ensuring freshness.

14 PoC Implementation Details↩︎

For poc and overhead analysis purposes, we avoid implementing procedures and communications that remain invariant across different mudb verification approaches. For example, MUD file retrieval from a remote server is common regardless of the considered approach. Therefore, MUD files are stored locally and authenticated with a locally generated private key, as if it were the manufacturer’s secret key. The corresponding public key is certified by a locally generated certificate authority. For key generation and cryptographic operations, we leveraged the OpenSSL API.

MUD Controller Implementation The MUD controller logic runs on an Ubuntu laptop equipped with an Alfa Network AR9271 USB antenna configured as an access point. We leveraged hostapd and systemd-networkd to control the network interface and manage Access Point (AP) configuration. The AP uses a static IP address (e.g., 10.42.0.1/24), and a Kea DHCPv4 server handles DHCP connections. Kea exposes API hooks for custom logic and DHCP option management. Specifically, we implemented hooks using the pkt4_receive and pkt4_send callouts to inspect incoming packets and log custom options such as Option 161 (MUD URL). We also leveraged OpenSSL for cryptographic computations and implemented X.509 extensions for MUD URL issuance via HTTP or TLS handshake. To support this, at startup, we launched a dedicated thread listening on the configured port for certificate exchange and URL transmission. We measure the mudb verification time at MUD Controller side using the clock_gettime(\(\cdot, \cdot\)) as part of the POSIX API. Additional relevant aspects include:

• NetworkManager was configured to ignore the Alfa interface to avoid conflicts with hostapd and static IP assignment.

• A wrapper workflow ensures reliable Kea restarts after hot-plug events by cleaning stale PID/lock files and recreating runtime directories.

• ACLs were applied to allow Kea (running as a system user) to write logs under the designated directory.

IoT Device Implementation FIDEM logic was implemented on an ESP32 microcontroller using the Espressif API, which provides hooks to manipulate DHCP packets, similar to the controller. We integrated basic HTTP and TLS clients for X.509 certificate transmission and sharing the MUD URL with the controller. Cryptographic operations leverage hardware acceleration and an asynchronous worker thread. Upon challenge reception, the worker computes the hash value \(H\) and the ZKP response \(Z\) while the main process builds the standard DHCP Request message before invoking the TX hook. This design minimizes latency introduced by cryptographic computations.

FIDEM Implementation FIDEM MUD binding verification uses elliptic curve secp256r1, supported by OpenSSL. The cryptographic parameters include:

• Nonce \(r\): 256 bits

• Challenge \(C\): 256 bits

• Secret key \(K\): 256 bits

Due to DHCP option length restrictions, FIDEM parameters were embedded using custom DHCP options. Specifically, \(R\) and DevID were placed in available custom options 224 and 225, as shown in Fig. 4 (b).

References↩︎