Pk-IOTA: Secure OPC UA with IOTA Ledger

• Pk-IOTA is a security architecture for OPC UA that integrates programmable switches with the IOTA distributed ledger to enable decentralized certificate management.
• It automates the issuance, validation, and revocation of certificates directly within the network, reducing configuration errors and attack surfaces.
• Real-world evaluations demonstrate minimal latency overhead and strong scalability, making it suitable for Industry 4.0 deployments.

Pk-IOTA is a security architecture for the industrial communication protocol OPC Unified Architecture (OPC UA), specifically designed for Industry 4.0 deployments. It combines programmable data plane switches with the IOTA distributed ledger (the “Tangle”) to enable scalable, decentralized, and in-network enforcement of certificate-based authentication for machine-to-machine (M2M) communications. Pk-IOTA addresses longstanding challenges in operational certificate management—traditionally a source of configuration errors and attack surface in OPC UA deployments—by automating certificate issuance, revocation, and enforcement directly in the network fabric. The system is evaluated on a physical testbed and demonstrates minimal overhead with strong scalability and security guarantees (Lorenzo et al., 13 Nov 2025).

1. System Architecture and In-Network Enforcement

Pk-IOTA is structured in four logical layers: the Device Layer (OPC UA clients and servers), the Data-Plane Layer (P4-programmable switches), the IOTA-Clients Layer (middleware on the P4 controller and endpoints), and the IOTA Layer (the Tangle itself). The architecture enables all OPC UA SecureChannel initiation (OpenSecureChannel requests and responses) to transit through a P4-programmable switch residing between the IT and OT networks.

The workflow is as follows:

• When an OPC UA client initiates a SecureChannel, its X.509 certificate is parsed on the switch.
• The switch computes or extracts the certificate thumbprint and consults a local table (“thumbprint_table”).
• Action is determined based on the presence of the thumbprint: packets are forwarded (allowed) or dropped.
• The thumbprint_table is populated by the P4 controller, which listens for certificate issuance and revocation transactions on the IOTA Tangle via MQTT or a smart contract interface.
• IOTA nodes (public or private) ensure the immutability and tamper-evidence of published certificate events.

P4 pseudocode specifies the parsing and enforcement logic, including extraction of certificates in fixed-size chunks and a table-driven permit/deny action based on thumbprint lookups.

2. Certificate Lifecycle: Issuance, Distribution, Validation, and Revocation

Pk-IOTA automates the lifecycle of OPC UA certificates using the IOTA Tangle as a decentralized and append-only PKI event log.

The protocol operates according to the following sequence:

1. The administrator generates or obtains an OPC UA certificate.
2. The administrator’s IOTA client submits either a certificate issuance or revocation transaction to the Tangle.
3. The P4 controller’s IOTA listener subscribes to these events, extracts and computes the thumbprint, and applies additions or removals to the switch’s thumbprint_table via P4Runtime API.
4. Upon successful entry registration, OPC UA endpoints can complete handshakes; if a certificate is revoked, future connection attempts are denied in-network.

Mathematically, the certificate thumbprint is computed as

$\text{TP} = H_{\mathrm{SHA1}}(\mathrm{CertBytes})$

Transactions on the Tangle have the form: $$\mathrm{Tx} = \left\{ \text{type}\in\{\text{issue},\text{revoke}\},\ \mathrm{TP},\ \sigma_{\mathrm{admin}} \right\}$$ Thus, the Tangle represents the system of record for all trusted (and revoked) certificates.

3. Integration with the OPC UA Security Model

Pk-IOTA is designed to require no changes to the OPC UA message-flow or application-level security mechanisms apart from the enforcement point for certificates. It supports only SecurityMode=SignAndEncrypt and disables anonymous authentication. Recommended SecurityPolicies include Aes128_Sha256_RsaOaep, Basic256Sha256, or Aes256_Sha256_RsaPss.

During the handshake, the system offloads the "TrustList" check—which in OPC UA is typically a device-side check—to the programmable data plane. Cryptographic validation and chain-of-trust, including signature, are performed as per the standard until the trust decision, which is enforced by the network element. The OpenSecureChannel handshake is either allowed or denied before endpoints receive any application-level data, mitigating Rogue Client, Rogue Server, and many in-path attacks.

4. Performance and Overhead Assessment

Deployment and evaluation on a real-world OT/IT network testbed showed:

Metric	Baseline	Pk-IOTA	Overhead
Packet Processing Time (µs)	6,900	8,500	+38% (~1,600 µs)
Packet Dequeuing Time (µs)	11.2	12.2	+1.04 µs
End-to-End Handshake Time (ms)	100	114	+14% (Δt ≈14 ms)

Resource consumption for memory, CPU, and power remains within industrial device budgets. Variability in latency is low, with overhead consistently below 15%, supporting real-time control system requirements. This suggests that Pk-IOTA is compatible with stringent industrial latency bounds (Lorenzo et al., 13 Nov 2025).

5. Security Model and Formal Guarantees

The threat model assumes a Dolev–Yao attacker positioned above Purdue Reference Model Level 1, capable of intercepting, injecting, and modifying network traffic, but unable to break cryptography or compromise the P4Runtime control channel. Pk-IOTA explicitly handles Rogue Client, Rogue Server, and Middleperson attacks.

• Rogue endpoints are excluded unless their certificate thumbprint is registered on the IOTA Tangle.
• Middleperson attacks are precluded unless the attacker can both forge two valid, trusted thumbprints and insert them into the Tangle (which requires administrator key compromise).
• The formal guarantee: let $T$ be the set of “issued” minus “revoked” thumbprints on the ledger; the switch enforces

$$C.\mathrm{TP}\in T \quad\Longleftrightarrow\quad\text{allow packet}$$

Due to the append-only and authenticated nature of the ledger, modification attacks—and thus unauthorized channel establishment—are prevented.

6. Scalability and Industrial Deployment

Deployment involves:

1. Configuring OPC UA clients/servers for certificate-based mutual authentication.
2. Installing and programming P4-capable switches.
3. Deploying P4 controllers with IOTA-client middleware (MQTT or L2 SDK).
4. Operating or connecting to an IOTA node for Tangle access.
5. Publishing initial certificate events to seed trusted endpoints.

The thumbprint_table is sized for 1,000–10,000 endpoints, and certificate header-stack in P4 is parameterized to accommodate certificates up to 25,600 bytes. For small environments, public IOTA nodes suffice; for autonomy, a local Hornet+Wasp node is needed (≥8 GB RAM, 4 vCPUs). The approach is compatible with both software (bmv2) and hardware (Intel Tofino, Barefoot) switch targets. All P4Runtime control traffic must be protected by TLS authenticated with X.509 certificates.

Benefits include elimination of manual device trust-list configuration, automated and real-time in-network certificate enforcement, tamper-proof and auditable PKI via the IOTA Tangle, low performance overhead, and scaling with the number of endpoints and the underlying ledger.

---

For an in-depth technical exposition and performance data, see "Pk-IOTA: Blockchain empowered Programmable Data Plane to secure OPC UA communications in Industry 4.0" (Lorenzo et al., 13 Nov 2025).