Search Results (3)

The proliferation of Internet of Things (IoT) applications in safety-critical domains, such as healthcare, smart transportation, and industrial automation, demands robust solutions for data integrity, traceability, and security that surpass the capabilities of centralized databases. This paper analyzes how blockchain technology can be integrated with core IoT service functions—including data management, security, device management, group coordination, and automated billing—to enhance immutability, trust, and operational efficiency. Our analysis identifies practical use cases such as consensus-driven tamper-proof storage, role-based access control, firmware integrity verification, and automated micropayments. These use cases showcase blockchain’s potential beyond traditional data storage. Building on this, we propose a novel framework that integrates a permissioned distributed ledger with a standardized IoT service layer platform through a Blockchain Interworking Proxy Entity (BlockIPE). This proxy dynamically maps IoT service functions to smart contracts, enabling flexible data routing to conventional databases or blockchains based on the application requirements. We implement a Dockerized prototype that integrates a C-based oneM2M platform with an Ethereum-compatible permissioned ledger (implemented using Hyperledger Besu) via BlockIPE, incorporating security features such as role-based access control. For performance evaluation, we use Ganache to isolate proxy-level overhead and scalability. At the proxy level, the blockchain-integrated path achieves processing latencies (≈86 ms) comparable to, and slightly faster than, the traditional database path. Although the end-to-end latency is inherently governed by on-chain confirmation (≈0.586–1.086 s), the scalability remains high (up to 100,000 TPS). This validates that the architecture secures IoT ecosystems with manageable operational overhead. Full article

Modern cryptographic systems increasingly depend on certified hardware modules to guarantee trustworthy key management, tamper resistance, and secure execution across Internet of Things (IoT), embedded, and cloud infrastructures. Although numerous FIPS 140-certified platforms exist, prior studies typically evaluate these solutions in isolation, offering limited insight into their cross-domain suitability and practical deployment trade-offs. This work addresses this gap by proposing a unified, multi-criteria evaluation framework aligned with the FIPS 140 standard family (including both FIPS 140-2 and FIPS 140-3), replacing the earlier formulation that assumed an exclusive FIPS 140-3 evaluation model. The framework systematically compares secure elements (SEs), Trusted Platform Modules (TPMs), embedded Systems-on-Chip (SoCs) with dedicated security coprocessors, enterprise-grade Hardware Security Modules (HSMs), and cloud-based trusted execution environments. It integrates certification analysis, performance normalization, physical-security assessment, integration complexity, and total cost of ownership. Validation is performed using verified CMVP certification records and harmonized performance benchmarks derived from publicly available FIPS datasets. The results reveal pronounced architectural trade-offs: lightweight SEs offer cost-efficient protection for large-scale IoT deployments, while enterprise HSMs and cloud enclaves provide high throughput and Level 3 assurance at the expense of increased operational and integration complexity. Quantitative comparison further shows that secure elements reduce active power consumption by approximately 80–85% compared to TPM 2.0 modules (<20 mW vs. 100–150 mW) but typically require 2–3× higher firmware-integration effort due to middleware dependencies. Likewise, SE050-based architectures deliver roughly 5× higher cryptographic throughput than TPMs (∼500 ops/s vs. ∼100 ops/s), whereas enterprise HSMs outperform all embedded platforms by two orders of magnitude (>10 000 ops/s). Because the evaluated platforms span both FIPS 140-2 and FIPS 140-3 certifications, the comparative analysis interprets their security guarantees in terms of requirements shared across the FIPS 140 standard family, rather than attributing all properties to FIPS 140-3 alone. No single architecture emerges as universally optimal; rather, platform suitability depends on the desired balance between assurance level, scalability, performance, and deployment constraints. The findings offer actionable guidance for engineers and system architects selecting FIPS-validated hardware for secure and compliant digital infrastructures. Full article

The security of Industrial Internet of Things (IIoT) systems is a challenge that needs to be addressed immediately, as the increasing use of new communication paradigms and the abundant use of sensors opens up new opportunities to compromise these types of systems. In this sense, technologies such as Trusted Execution Environments (TEEs) and Hardware Security Modules (HSMs) become crucial for adding new layers of security to IIoT systems, especially to edge nodes that incorporate sensors and perform continuous measurements. These technologies, coupled with new communication paradigms such as Blockchain, offer a high reliability, robustness and good interoperability between them. This paper proposes the design of a secure sensor incorporating the above mentioned technologies—HSMs and a TEE—in a hardware device based on a dual-core architecture. Through this combination of technologies, one of the cores collects the data extracted by the sensors and implements the security mechanisms to guarantee the integrity of these data, while the remaining core is responsible for sending these data through the appropriate communication protocol. This proposed approach fits into the Blockchain networks, which act as an Oracle. Finally, to illustrate the application of this concept, a use case applied to wine logistics is described, where this secure sensor is integrated into a Blockchain that collects data from the storage and transport of barrels, and a performance evaluation of the implemented prototype is provided. Full article