A Parallelized & Scalable Multi-Secure Element Secure Execution Environment Architecture


Secure Computing are usually reserved for those who can afford to pay for expensive security appliance with hardware protected Secure Execution Environments (i.e Thales nCipher HSM, Safenet ProtectServer HSM and Bull's Trustway HSM). These solutions can be highly expensive just for the purpose of securely executing mission critical codes for Small and Medium Enterprises within a secure and trusted environment. These HSMs usually relies on a general purpose processor encased in layers of tamper protection mechanisms and secure booting with a small and trusted TCB for it's kernel which it may share with generic HSM management processes and activities.

Small and Medium Enterprises also have valid rights for the access to such better protected Secure Execution Environments to execute mission critical applets without needing to pay for such highly expensive solutions for protecting critical enterprise assets from attacks carried out by skilled and unskilled adversaries. The cheaper alternatives for introducing a highly scalable and parallelized Secure Execution Environment would be Secure Elements (i.e. smart card chips).

Secure Elements have desirable properties making them the suitable candidate for a cheap , highly scalable and parallelized Secure Execution Environment. The low cost of the Secure Elements and mass production for use in smart cards, TPMs, eSE ...etc... make them ideal for those who require security but are tight on resource and funds. A sizable body of literature on the security of Secure Elements are available as these Secure Elements have their security time tested for a few decades since the 1970s and having survived for many years of security research and real world attacks are still considered secure enough for the mission critical jobs they are required to host and carry out.

Communication between Secure Elements and controller units have to be flexible enough for being able to scale and be parallelized as needed. Flexible communication brings both risk and opportunities for enabling Secure Elements and their controller units to be scalable and parallelized. How a Secure Element is exposed to the external world and how multiple Secure Elements interact amongst themselves would have an impact on both the overall security of the entire architecture and the the security of each Secure Element.

In a traditional context most Secure Elements either have the capability to communicate with the external world via in-built processor units or via a MCU or FPGA (usually a 1-to-1 relationship). This MCU or FPGA can be used as both an interface to the external world and also at the same time a hardware firewall to protect the Secure Element from direct exposure to the external world. This approach not only limits the speed of secure execution capability and scalability to a single Secure Element, it also makes detection of possibly malicious Secure Elements difficult as the assumption of trust would be pegged onto the single Secure Element. The MCU or FPGA attached to the Secure Element (if one exists) maybe used as an insecure execution environment for detecting malicious patterns coming from the Secure Element but this will cause a performance bottleneck and also the insecure execution would become problematic in terms of data security compliance and in an event where software or hardware tampering were to actually take place, the MCU or FPGA (assuming without any security capabilities of a Secure Element) would be left naked to intruders logically or physically probing at the MCU or FPGA that may contain sensitive secrets while attempting to execute security operations to detect traitorous patterns from the Secure Element.

Secure Execution, scalability, parallelization of resources and traitorous pattern detection can be achieved by the act of having a common and open platform across all Secure Elements to allow a single language where Secure Elements can be parallelized and scaled in real-time which can be used for secure detection of malicious patterns in a pool of Secure Elements.

Ledger have brought into existence an Operating System architecture for Secure Elements called the BOLOS for their Ledger Blue personal security device product. The concept is to host an open and secure OS within the Secure Element while introducing a proprietary HAL layer for portions of the Secure Element requiring NDA (common within the Secure Hardware industry). Leveraging on the Secure Element's hardware MPU capabilities, BOLOS can provision security applets to be securely executed and managed by the Secure Element's MPU without needing to worry about malicious applets trying to interfere with other applets running within the Secure Element. With the exposing of open APIs and platform, different varieties of Secure Elements can be used to host BOLOS as the kernel with their individual proprietary HAL and MPU capabilities. The more the variety of Secure Elements can operate BOLOS, the more this scheme for scalable and parallelized Secure Elements would benefit by the fact that different varieties of Secure Elements can be used to play the game of detection of each other's possibly traitorous habits and not easily collude due to the difference in their hardware designs.

Arranging the Secure Elements in a Group-Tree-Star style architecture with low capability MCUs as message routers and low power processing units can help to scale the architecture infinitely and also provide pattern matching and checking for traitorous behaviours amongst Secure Elements even to the extent when the message requests for the Secure Elements are specifically encrypted where the low power MCUs cannot decrypt the secure messages.

In order to execute the Group-Tree-Star architecture, at least 2 or more Secure Elements would have to be paired to an overseeing MCU and derive a shared secret amongst the Secure Elements group. A request sent is always targeted on the group level encrypted with the shared secret. The message would usually be sent to the overseeing MCU and the MCU would dispatch the encrypted message to the desired Secure Element for processing (or to all the Secure Elements in it's group). By comparing the encrypted results of the Secure Elements within the group under a common shared secret, the MCU would be able to assert the possibility of traitorous patterns by observing the computed encrypted results for inconsistencies amongst the group of Secure Elements. Nonce and IV generation would either be determined by the overseeing MCU or the Secure Elements must agree on a shared IV or Nonce (to encrypt the response) and reveal the IV or Nonce to the MCU for asserting the encrypted results. Groups can be linked up to form Branches and Trees via multiple overseeing MCUs grouping together and routing messages amongst each other and also the capability of getting a Group to assert another Group's execution patterns for cross checking of results using shared secrets. A centralized MCU can be used for job delegation, managing scaling of newly added or removed groups and as an interface with the external world.

This highly parallelized and scalable Secure Execution scheme is not so far fetched as the main components (low powered MCUs and Secure Elements) are already existing or just coming into practical existence and maturing (for BOLOS). What is required is the transformation of this concept into actual protocols and schematics on the software and hardware layer to actualized a cheap, self-checking and secure environment for mission critical operations while continuously evolving this scheme as needed for additional features or fixing flaws in the concepts and protocols.

References & Links:


Publication Info
Written On: 16 Jun 2016
Published On: 17 Jun 2016
Author: Thotheolh


CONTACT