Connecting Tamper-Resistant Hardware Security to the Internet<\/strong><\/p>\n\n\n\n The Internet of Secure Elements (IoSE)<\/strong> is an innovative cybersecurity architecture introduced by Pascal Urien to transform traditional Secure Elements into autonomous, network-accessible cryptographic servers.<\/p>\n\n\n\n The concept builds upon the security capabilities of smart cards, SIM cards, and embedded Secure Elements, extending their use beyond local interfaces to provide trusted cryptographic services directly accessible through the Internet.<\/p>\n\n\n\n Unlike conventional security architectures, where cryptographic operations may depend on general-purpose processors or software-based security modules, IoSE enables Secure Elements to operate as independent TLS 1.3 End Servers<\/strong>, combining hardware isolation, secure communications, and trusted application execution.<\/p>\n\n\n\n The fundamental vision of IoSE is to create an Internet infrastructure in which cryptographic resources are hosted in physically protected hardware and securely accessible through standard Internet protocols.<\/p>\n\n\n\n Traditional Secure Elements are tamper-resistant microcontrollers designed to protect sensitive information and perform cryptographic operations.<\/p>\n\n\n\n Widely deployed in banking cards, mobile SIMs, electronic passports, and connected devices, they provide secure storage, cryptographic acceleration, and protected application execution.<\/p>\n\n\n\n However, these devices traditionally communicate through local interfaces, including ISO 7816, SPI, and I\u00b2C, and do not directly implement conventional TCP\/IP networking.<\/p>\n\n\n\n IoSE overcomes this limitation by combining a network-connected processor with Secure Elements capable of executing the TLS 1.3 protocol.<\/p>\n\n\n\n In this architecture, each Secure Element becomes an independent cryptographic server, communicating securely with remote clients while keeping its cryptographic operations within its tamper-resistant environment.<\/p>\n\n\n\n The network processor provides connectivity and packet forwarding, while the Secure Element remains responsible for TLS security and trusted cryptographic processing.<\/p>\n\n\n\n The IoSE architecture separates network connectivity from cryptographic security through two complementary server components.<\/p>\n\n\n\n The TLS Front Server provides the TCP\/IP interface between Internet clients and the Secure Elements.<\/p>\n\n\n\n Its primary responsibility is to receive incoming TLS connections, inspect the Server Name Indication (SNI) extension in the TLS ClientHello message, and route TLS packets to the appropriate Secure Element.<\/p>\n\n\n\n The Front Server also handles the segmentation and reassembly required to transport TLS records over the Secure Element’s local communication interface.<\/p>\n\n\n\n In this model, the Front Server does not need to terminate the protected TLS session or access its cryptographic secrets.<\/p>\n\n\n\n Each Secure Element embeds its own TLS 1.3 End Server, identified by a Secure Element Name (SEN)<\/strong>.<\/p>\n\n\n\n The Secure Element performs TLS authentication, key establishment, and protected application exchanges within its hardware security environment.<\/p>\n\n\n\n TLS authentication can rely on Pre-Shared Keys (PSK) or public-key cryptography using certificates.<\/p>\n\n\n\n A remote client establishes a secure TLS connection with the designated Secure Element, rather than relying on the Front Server to terminate the cryptographic session.<\/p>\n\n\n\n This separation between network transport and hardware-based security is a fundamental characteristic of the IoSE architecture.<\/p>\n\n\n\n IoSE introduces the concept of individually addressable Secure Elements, each associated with a unique Secure Element Name (SEN).<\/p>\n\n\n\n The SEN is carried in the TLS Server Name Indication (SNI) extension, allowing the Front Server to identify the destination Secure Element.<\/p>\n\n\n\n The architecture also proposes a URI-based addressing mechanism:<\/p>\n\n\n\n In this representation, the URI identifies the communication scheme, the Secure Element, the network gateway, and the requested cryptographic operation.<\/p>\n\n\n\n The proposed addressing mechanism makes it possible to represent remote hardware security services as identifiable Internet resources.<\/p>\n\n\n\n For example, a client application may address a specific remote Secure Element to request a digital signature without transferring the corresponding private key outside the protected hardware.<\/p>\n\n\n\n IoSE distinguishes two complementary functional planes.<\/p>\n\n\n\n The Service Plane provides secure communication between client applications and Secure Elements using the TLS-SE architecture (TLS Server in Secure Element<\/em>).<\/p>\n\n\n\n Each Secure Element executes a TLS server and exposes application-specific services, such as cryptographic key management, digital signatures, and authentication.<\/p>\n\n\n\n The Service Plane allows remote applications to interact with hardware-protected cryptographic resources through standard TLS sessions.<\/p>\n\n\n\n The Administration Plane manages the deployment, configuration, and lifecycle of Secure Element applications.<\/p>\n\n\n\n It relies on the Remote APDU Call Secure (RACS)<\/strong> protocol, which enables remote transmission of ISO 7816 APDU commands over secure network connections.<\/p>\n\n\n\n Combined with GlobalPlatform security mechanisms, RACS supports remote application installation, configuration, and management.<\/p>\n\n\n\n This separation enables a service provider to administer Secure Elements while maintaining distinct secure communication channels for end-user cryptographic operations.<\/p>\n\n\n\n An important innovation of IoSE is its proposed attestation procedure, designed to establish confidence in the authenticity of a remote Secure Element and its embedded application.<\/p>\n\n\n\n The architecture supports the secure deployment of an application into a Secure Element, followed by the generation of a cryptographic key pair within the protected hardware.<\/p>\n\n\n\n The application provider can certify the public key and associate it with the Secure Element identity.<\/p>\n\n\n\n During user enrollment, the remote client establishes a TLS session with the Secure Element and performs a cryptographic challenge-response procedure.<\/p>\n\n\n\n The Secure Element signs information derived from the TLS handshake and a random challenge, allowing the client to verify possession of the corresponding private key and its association with the established session.<\/p>\n\n\n\n After successful verification, the user can replace the initial application provider’s Pre-Shared Key with a dedicated user secret.<\/p>\n\n\n\n This procedure is intended to establish trusted, exclusive access to an authentic Secure Element, subject to the security assumptions and operational constraints of the architecture.<\/p>\n\n\n\n The IoSE concept naturally extends to a Grid of Secure Elements (GoSE)<\/strong>, in which multiple Secure Elements are hosted within a common network-connected infrastructure.<\/p>\n\n\n\n Each Secure Element provides an independent hardware security environment with its own TLS server identity and cryptographic resources.<\/p>\n\n\n\n A shared TLS Front Server enables remote clients to access individual Secure Elements through SNI-based routing.<\/p>\n\n\n\n This approach supports the deployment of multiple hardware-isolated security services within a single physical platform.<\/p>\n\n\n\n It provides an architectural foundation for distributed cryptographic services, dedicated security domains, and network-accessible Hardware Security Modules.<\/p>\n\n\n\n IoSE offers a technological foundation for applications requiring strong hardware-based security.<\/p>\n\n\n\n Its potential applications include:<\/p>\n\n\n\n By making Secure Elements accessible through standard Internet technologies, IoSE enables hardware-based trust to be extended across diverse digital infrastructures.<\/p>\n\n\n\n The IoSE architecture represents an important evolution of earlier research on the Cloud of Secure Elements (CoSE)<\/strong>.<\/p>\n\n\n\n CoSE introduced remote access to grids of Secure Elements, notably through the RACS protocol, allowing remote applications to use smart card resources hosted in dedicated servers.<\/p>\n\n\n\n IoSE extends this approach by introducing native TLS server capabilities within the Secure Elements themselves.<\/p>\n\n\n\n The Secure Element is no longer simply a remotely accessible smart card: it becomes an independently addressable and authenticated Internet security endpoint.<\/p>\n\n\n\n EtherTrust’s Personal Network HSM (pNHSM)<\/strong> applies these architectural principles to a grid of Secure Elements, each operating as a dedicated TLS 1.3 PSK server and integrating its own Key Management System and secure command interface.<\/p>\n\n\n\n In this implementation, the TLS Front Server provides TCP\/IP connectivity and SNI-based routing, while each Secure Element offers an isolated cryptographic security domain.<\/p>\n\n\n\n LeMONOLITH<\/strong> represents a compact implementation of this approach, combining a System-on-Chip acting as the TLS Front Server with a single Secure Element operating as the TLS End Server.<\/p>\n\n\n\n Together, these architectures illustrate the progression from remotely managed smart cards to autonomous, network-connected cryptographic security services.<\/p>\n\n\n\n The Internet of Secure Elements introduces a new perspective on the integration of trusted hardware into Internet infrastructures.<\/p>\n\n\n\n Rather than concentrating cryptographic security within conventional computing environments, IoSE distributes trusted computing functions across independent, tamper-resistant Secure Elements.<\/p>\n\n\n\n Its originality lies in combining established hardware security technologies with Internet-native protocols, individual server identities, secure remote administration, and cryptographic attestation.<\/p>\n\n\n\n The concept provides a foundation for building distributed security infrastructures in which trusted cryptographic operations can be performed remotely without requiring private keys to leave their protected hardware environments.<\/p>\n\n\n\n Through his research on IoSE, TLS-SE, RACS, and secure hardware architectures, Pascal Urien has contributed to the development of a model connecting traditional Secure Element technologies with modern network and cloud security requirements.<\/p>\n\n\n\n Internet of Secure Elements transforms isolated cryptographic chips into independent, network-addressable TLS security servers.<\/strong><\/p>\n\n\n\n By combining hardware isolation, native TLS 1.3 communications, SNI-based addressing, and secure remote administration, IoSE establishes an architectural foundation for distributed, hardware-protected cryptographic services.<\/p>\n\n\n\n It provides a conceptual basis for technologies such as the EtherTrust Personal Network HSM and LeMONOLITH, extending the benefits of tamper-resistant security hardware to Internet-connected applications.<\/p>\n\n\n\n IoSE \u2014 Bringing Hardware-Based Trust Directly to the Internet.<\/strong><\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Internet of Secure Elements Connecting Tamper-Resistant Hardware Security to the Internet Introduction The Internet of Secure Elements (IoSE) is an innovative cybersecurity architecture introduced by Pascal Urien to transform traditional Secure Elements into autonomous, network-accessible cryptographic servers. The concept builds upon the security capabilities of smart cards, SIM cards, and embedded Secure Elements, extending their […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-163","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/pages\/163","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/comments?post=163"}],"version-history":[{"count":1,"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/pages\/163\/revisions"}],"predecessor-version":[{"id":164,"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/pages\/163\/revisions\/164"}],"wp:attachment":[{"href":"https:\/\/ethertrust.com\/index.php\/wp-json\/wp\/v2\/media?parent=163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Introduction<\/h2>\n\n\n\n
1. From Secure Elements to Internet Servers<\/h2>\n\n\n\n
2. IoSE Network Architecture<\/h2>\n\n\n\n
TLS Front Server \u2013 Network Connectivity<\/h3>\n\n\n\n
TLS End Server \u2013 Hardware Security<\/h3>\n\n\n\n
3. Secure Element Identification and Addressing<\/h2>\n\n\n\n
schemeS:\/\/sen@server.com:port\/?query<\/code><\/p>\n\n\n\n4. Service and Administration Planes<\/h2>\n\n\n\n
Service Plane \u2013 TLS-SE<\/h3>\n\n\n\n
Administration Plane \u2013 RACS<\/h3>\n\n\n\n
5. Secure Element Attestation and Trusted Ownership<\/h2>\n\n\n\n
6. Grid of Secure Elements (GoSE)<\/h2>\n\n\n\n
7. Applications and Use Cases<\/h2>\n\n\n\n
\n
8. From Cloud of Secure Elements to IoSE and Personal Network HSM<\/h2>\n\n\n\n
9. Vision and Technological Significance<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n