IDfusion partners with MY Innovate for securing their HaveFund Blackbox

IDfusion is excited to announce that we have partnered with MY Innovate for securing their HaveFund loan trading platform. HaveFund is a secure loan trading platform based on distributed ledger and secure enclave technologies. It enables the efficient buying and selling of loans without revealing sensitive data. The sensitive data is secured inside the HaveFund Blackbox, powered by IDfusion’s Secure Runtime Development Environment (SRDE).

Learn more about how IDfusion’s SRDE is securing HaveFund’s Blackbox here.

IDfusion invited by Intel alongside a select-few SGX experts and developers for the 2019 Cyber Week

IDfusion was honored to be invited by Intel alongside a select-few SGX experts and developers for the 2019 Cyber Week in Tel Aviv, Israel. IDfusion joined Intel and other partners at Cyber Week to learn more about how Intel’s innovation, together with partners and customers, is building the trusted foundation for computing in a data-centric world. It was a great week full of great discussions and feedback.

Learn more about the 2019 Cyber Week in Tel Aviv here.

USAFA cadets demonstrated IDfusion’s SRDE at the NDIA Cyber-Augmented Operations Technical Symposium

Cadet Lee and Cadet Taglieri demonstrated their application of IDfusion’s Secure Runtime Development Environment to the problem of secured command and control of critical INED infrastructure during the NDIA Symposium on 26 March 2019 at the University of Texas at Austin. As part of their senior capstone project, the cadets leveraged IDfusion’s SRDE to provide more security for Supervisory Control and Data Acquisition (SCADA) device command-and-control using the MODBUS protocol.

Learn more about the NDIA demonstration from the USAFA cadets and IDfusion here.

IDfusion LLC Presents at NDIA Cyber-Augmented Operations Technical Symposium

IDfusion, LLC, a technology company specializing in security solutions for Intelligent Network Endpoint Devices (INEDS) has partnered with the US Air Force Academy to demonstrate IDfusion’s innovative approach to help secure these devices. IDfusion and the cadets of the US Air Force will present a real time demonstration of its groundbreaking security technology, Autonomous IntrospectionTM (or the other AI) at the National Defense Industry Association’s Cyber-Augmented Operations Technical Symposium in Austin, TX on March 26, 2019. In reading this article, understand that no product or component can be absolutely secure.

IDfusion’s Autonomous IntrospectionTM technology provides a powerful modeling framework that allows the ultimate ‘whitelist’ to be defined for a platform. It has never been more important that the millions of intelligent devices we are becoming more dependent on have security features. Now, undesired platform behaviors can be intercepted and blocked before they can be used by an aggressor to modify a platform to do their will, rather than the intention of the platform designer.

The underlying technology for Autonomous IntrospectionTM is IDfusion’s Secure Runtime Development Environment (SRDE). The SRDE leverages Intel®Software Guard Extensions (Intel® SGX) to provide developers with a rich environment for providing more security for INED- class devices. The SRDE features C-based enhancements to Intel® SGX SDK technology and an independent, C-based implementation of the Intel® SGX Platform SoftWare (PSW). The SRDE also includes development libraries that include pre-built enclaves for rapid development and implementation of security solutions.

Dr. Greg Wettstein, Principal Engineer and co-founder of IDfusion LLC noted, “Secure Runtime Development Environment introduces a new paradigm for security architectures by enabling platform developers to use Intel SGX technology to help enforce precisely defined behaviors for either an entire hardware platform or container. IDfusion has been pleased to partner with the Air Force Academy, through its Center of Innovation, to extend its strong history of innovation in Intel SGX based security architectures”.

The US Air Force Academy’s involvement features work by five cadets from their Cyber Science and Computer Science programs. As part of their Senior Capstone project, the cadets leveraged IDfusion’s SRDE to provide more security for Supervisory Control And Data Acquisition (SCADA) device command-and-control using the MODBUS protocol which is commonly used to control them.

Major Bobby Birrer, the project mentor for the cadets, stated, “Being able to collaborate with an industry partner such as IDfusion to work on a real-world problem is an amazing opportunity for our cadets. Their work has the potential to significantly improve the security of critical SCADA systems, and I am very proud of them for being selected to present their work at a venue such as the NDIA Cyber-Augmented Operations Technical

IDfusion’s Autonomous IntrospectionTM leverages the Intel SGX security model to apply enclave technology to help secure IoT devices. IDfusion uses the Intel SGX security model to help ensure that the entire operating system and the application stack is doing the bidding of its designer and owner. IDfusion’s Secure Runtime Development Environment empowers developers to use modern DevOps technologies to build platforms with these important security features.

Cadet Lee and Cadet Taglieri will demonstrate their application of IDfusion’s Secure Runtime Development Environment to the problem of secured command and control of critical INED infrastructure during the NDIA symposium on March 26th at 12:30pm CDT. To learn more about the demonstration or to participate in the limited beta of Autonomous IntrospectionTM coming in the second quarter of 2019, contact IDfusion LLC at or visit our website.

IDfusion’s Secure Runtime Development Environment: Bringing Intel® SGX Security Features to Edge Devices

With the introduction of the Secure Runtime Development Environment (SRDE), IDfusion LLC brings the power of Intel® Software Guard Extensions (Intel® SGX) hardware security technology to help meet the challenges of edge device security. When combined with its Autonomous Introspection™ technology, The Other AI™, IDfusion provides a powerful spectrum of tools that brings a new dimension of additional security for Intelligent Network Endpoint Devices (INED’s). In reading this article, understand that no product or component can be absolutely secure.

About Intel ® SGX
Creating applications that take advantage of Intel’s SGX-based enclave security features requires that developers partition security-sensitive functionality into separate code that is compiled and linked against an Intel SGX Software Development Kit (SDK). This SDK provides support for the standalone execution environment that characterizes an enclave with security features. A Platform SoftWare (PSW) run time environment is then required to implement the functionality that loads, initializes and executes the enclave with security features. In addition, the PSW provides support for the Enhanced Privacy ID (EPID) provisioning process that joins and anonymously identifies a platform to a security group that enables support for some remote attestation.

About IDfusions Secure Runtime Development Environment
IDfusion’s SRDE provides an alternative PSW, specifically designed for minimum footprint embedded applications of Intel SGX. It enables a toolkit-based approach to all of the functionality that an embedded developer needs to provide platform security features via enclave technology with security features. Implemented in the form of a simple to use C-based object library, it provides developers the tools to implement Intel ® SGX-based solutions using GLIBC as well as the MUSL C library popular with embedded developers.

The IDfusion library extends the Intel SGX SDK with capabilities that enable seamless source code interoperability between non-Intel SGX and enclave-based software implementations. Applications can be conceived, debugged and tested using standard development tools and techniques and then converted into an enclave-based application with security features simply by recompiling. This greatly accelerates developer productivity and time-to-solution.

To these PSW and SDK solutions IDfusion adds a set of pre-built enclaves that provide rich functionality that can be immediately leveraged by platform developers and architects. This functionality includes enclave-to-enclave communications with IDsecure conduits featuring IDfusion’s Host Specific Enclave Authentication (HSEA). Purpose built to take advantage of Intel ® SGX-based remote attestation features, HSEA-based network communications enables platform developers to provide some degree of physical processor-based attestations as to which platforms are allowed to connect and communicate. This provides developers of automation and SCADA systems a compelling potential answer for organizations reluctant to open network access required for device deployments.

IDfusion LLC completes the package for advanced device security by building its Autonomous Introspection™ technology on top of this Intel SGX development and run time framework. Using Autonomous Introspection™, platform developers can create very precise definitions of behavior for either an entire platform or a container-based application stack. Ready-to-use IDsecure-based tools allow real-time monitoring of device security posture including characterizations of possible security critical behaviors.

As a licensed Intel SGX Independent Software Vendor, IDfusion LLC can provide enclave technology with security features in ready-to-be-signed or pre-signed configurations. Contact IDfusion LLC for further details on how Intel SGX and IDfusion’s SRDE can help differentiate your platforms.

Cooperative Research and Development Agreement (CRADA) between IDfusion and United States Air Force Academy (USAFA) cadets

IDfusion is excited to announce that we have signed a CRADA with the United States Air Force Academy. IDfusion has developed an independent implementation of the SGX Platform Software infrastructure suitable for intelligent network endpoint devices (INED’s). This infrastructure will be used to provide root of trust and integrity support for implementing INED’s which feature advanced Cybersecurity guarantees based on autonomous introspection. The objective for this infrastructure will be to demonstrate command and control facilities capable of providing security frameworks for environments consisting of thousands of intelligent devices capable of independently maintaining their Cybersecurity posture.

Listen to Cadet Taglieri and Dr. Wettstein’s talk about solving cyber security issues on KFGO.

SGX After Spectre and Meltdown: Status, Analysis and Remediations

Much has been written about the recently disclosed micro-architectural cache probing attacks named in the title of this document. These attacks, while known as a possibility for some time, have created significant concerns and remediation activity in the industry, secondary to the significant confidentiality threats they pose. These attacks are particularly problematic since they evade long standing protections that the industry has used as foundational constructs in the security design of modern operating systems.

While the threats to operating system protections have undergone significant discussion, there has been little official information surrounding the impact of this new threat class to Intel’s Software Guard eXtension (SGX) technology. This document is intended to provide support for system security architects and software engineers with respect to the impact of this new class of attack on SGX security guarantees. The development of this document was inspired by dialogue on the Intel SGX developer’s forum surrounding whether or not enclaves provide credible security guarantees in the face of these new threats.

Hardware and microcode enhancements introduced in the Intel Skylake micro-architecture provide the framework for the SGX Trusted Execution Environment (TEE). The SGX security architecture uses the notion of an enclave, which is an area of memory which contains data and code which can only be referenced by the enclave itself. Unauthorized access to these protected memory regions are blocked regardless of the privilege level of the context of execution attempting the access. As a result the premise is that enclaves will provide confidentiality and integrity guarantees even if the hardware, BIOS, hypervisor or operating system are compromised.

In addition to providing protections against malware or compromised operating platforms, the technology focuses on providing security guarantees for ‘cloud’ based computing models. The notion is that clients cam forward computational tasks, encased in enclaves, into cloud based infrastructures. with an expectation that data and computational activity conducted inside the enclave, will be protected from possible surveillance by the cloud service provider.

The most important security finding currently available is that there is no credible engineering rationale to support the contention that SGX enclaves will provide confidentiality guarantees in the face of these new micro-architectural cache probing attacks. This is disappointing for a technology that was designed to provide security guarantees in the face of an IAGO threat model or in the previously described service provider models.

The analysis supporting this conclusion is derived from several foundational sources of SGX architecture and design information. Readers are encouraged to reference the following documents for additional background information. The foundational document for readers interested in the SGX architecture is the MIT SGX review paper by Costan and Devadas. The design and implementation of the SGX Management Encryption Engine (MEE), which is the foundation for the SGX integrity and confidentiality guarantees, is fully described by Shay Gueron in the following paper. Finally, a comprehensive review of the x86 micro-architecture has been done by Agner Fog.

The prima facie rationale for security concerns by SGX developers is that a functional implementation of Variant 1 (conditional branch misprediction) of the Spectre vulnerability has been published. An independent implementation of this exploit was confirmed in our lab using the Linux operating system and an alternative implementation of the Intel SGX Platform SoftWare (PSW). The exploit is demonstrating an 88% accuracy rate in exfiltrating secrets from an enclave.

At the time of this writing it is unclear how the published exploit would be functional given what appears to be an error in its implementation. Since this may have been the intent of the authors we are currently not disclosing the modifications needed to achieve our functional implementation.

Since the Variant 1 implementation essentially involves an application spying on itself, the concern is not over the exploit itself but rather in its demonstration that SGX enclaves do not enjoy unfettered guarantees with respect to protection of their contents from the surrounding host system. With this finding, security architects must operate under the premise that content in an enclave enjoys no more protections from micro-architectural cache probing attacks then data in standard user or kernel space.

While this finding is initially disturbing, given the design intent of SGX, it is not without precedent, nor is it unexpected after a review of the SGX literature. The original description of the potential for SGX to provide disruptive security guarantees was followed by a sobering study of the vulnerability of TEE’s to controlled side channel attacks. Official guidance from Intel advises caution with respect to the need to employ algorithms and software design strategies in SGX enclaves that are resistant to side-channel timing attacks.

An obvious response to these findings is to question how this could have have happened from an engineering perspective. A review of the SGX security model and architecture is useful in understanding the rationale for vulnerability and measures for responding to the implications of this new threat scenario.

Without descending deeply into the technical details of the SGX architecture, the micro-architectural vulnerabilities, while significant and troubling, are not inconsistent with the design decisions behind the technology. The fundamental underpinning in any trusted system is the designation of the root of trust for the system. Reviewing the SGX trust model is helpful in understanding the nature of the vulnerability.

In the development of SGX, the decision was made to trust the processor itself, under the notion that the processor had to be inherently trusted. The micro-architectural vulnerabilities can be argued as an example of the processor failing to properly implement protection domains and is thus a failure in the security design of the processor. As a result, the impact of these vulnerabilities on SGX would not be unexpected, since it could be argued that the processor could not be ‘trusted’.

The root of the protection domain violation can be understood by tracing backwards to fundamental design decisions that date back decades. The x86 Instruction Set Architecure (ISA) initially carried a taxonomical classification as a Complex Instruction Set Computer (CISC). The design intent of such architectures was to maximize programmer productivity by providing high level abstractions for desired computational functions.

The competing design taxonomy was the Reduced Instruction Set Computer (RISC) architecture. In this model instructions are designed to be much more concise and targeted with respect to their functionality, with an objective of decreasing the complexity of decoding and executing these instructions.

In approximately the Pentium era Intel merged these architectures and the CISC ISA was implemented as a RISC architecture with respect to the physical implementation of the processor logic. This can be thought of, in the abstract sense, as the operating system and applications running on a virtualized CISC architecture implemented on a physical RISC architecture. This model unlocked the potential for pipelined, superscalar architectures capable of implementing out-of-order and speculative execution.

For the purposes of clarity, this document will mint the term, ‘representational level‘, to refer to the CISC emulation level of the processor as seen by the OS and application layer. The term. ‘operational level‘,will be applied to the RISC implementation level of the processor.

Virtual memory, the fundamental protection tenant required for secure and stable operating system environments, is notionally implemented at the representational level of the processor. Illegal memory accesses are denied by delivering an exception to the OS or application when the operational state completes execution of the representational form of the instruction.

The security design of SGX is based on a virtual memory implementation strategy. As a result, its integrity and confidentiality guarantees rely on the ability of the processor to enforce strict security domain partitioning between the operational and representational levels of the processor with respect to memory access protection. Since the micro-architectural probing attacks are a breakdown in the integrity of this partitioning, it would not be unexpected for SGX security guarantees to be compromised.

A brief review of the SGX virtual memory protection architecture is useful in understanding these issues. In an SGX capable platform the BIOS allocates an array of ‘protected’ memory referred to as Processor Reserved Memory (PRM). This memory region can only be accessed by microcode running on the processor or by a virtual to physical memory mapping which has been defined by a validated enclave loading and initialization process.

PRM is sub-divided into two separate regions; referred to as Enclave Page Cache (EPC) memory and Enclave Page Cache Map (EPCM) memory. EPC contains memory which is allocated to enclaves and accessible through validated virtual memory mappings. EPCM memory is only accessible by processor microcode and contains metadata that is used by the Memory Encryption Engine (MEE) and page fault handlers to validate memory that is fetched from the EPC.

The processor Page Miss Handler (PMH) is implemented in microcode and runs at the operational level of the processor. When an instruction at the representational level of the processor requires access to a page of EPC memory, the SGX modified PMH validates that the access is valid by referencing metadata in the EPCM. A denied access is implemented at the operational level by the delivery of an exception fault to the executing instruction.

These access protections operate AFTER the operational level of the processor has conducted the actual memory fetch with consequent population of the on-chip caches. As a result, SGX protection guarantees do not extend to memory accesses conducted at the operational level of the processor. Any breakdown in the ability of the processor to implement effective partitioning between the operational and representational levels would thus be expected to result in a compromise of SGX security guarantees.

The micro-architectural probing attacks are based on the fact that the operational state of the processors are capable of reading memory in advance of the representational state of the processor. This is a basic requirement needed to support both out-of-order and speculative execution. The operational level of the processor thus possesses data that may not be technically allowed at the representational level of the processor. As these attacks demonstrate, this data can be exfiltrated across the operational/representational security domain barrier by probing the cache state of the processor.

This analysis thus supports the premise that the virtual memory based SGX security guarantees would be ineffectual in the face of these attacks. This would seem to be in contrast to a finding that the SGX virtual memory security model has been formally proven.

The MIT review paper contains a formal and extensive proof of the SGX virtual memory security model. The proof relies heavily on the invariant premise that the processor Translation Lookaside Buffer (TLB) can only contain mappings consistent with the execution domain (trusted or untrusted) that the processor is operating in. Entry and exit of an enclave results in the TLB being invalidated which forces the PMH to validate subsequent page accesses against the SGX virtual memory security constraints, as it applies to the current execution domain.

As with all formal proofs, the correctness of the proof is dependent on the validity of the assumptions that the proof is based on. The proof assumes that data transfers will occur only by virtual memory mediated transfers and its validity thus fails in the face of data transfers which can occur without violating the virtual memory security constraints embodied in the design of SGX. Exfiltration of data from the processor caches is an example of such a transfer.

A central tenant of SGX security protections is that the contents of EPC memory are encrypted and integrity protected by the MEE. This is designed to thwart cold-boot and bus snooping attacks. This proves to be ineffective in the micro-architectural probing attacks since the MEE sits at the ‘edge’ of the memory controller and thus at the ‘base’ of the cache hierarchy. Operational level memory fetches, in support of out-of-order or speculative execution, results in the decryption of the data, which is then available in plaintext form in the cache heirarchy. As a result the plaintext form of the data is available to be targeted by cache probing strategies.

The important question to the SGX community is the possibility for mitigating this security regression, either through external action or by a change in SGX itself.

At the time of this writing, a rogue cache fill, aka Meltdown, style attack has not been demonstrated. Given that this attack works by probing for operational level induced changes in cache state, prudence would dictate that page table isolation techniques be immediately deployed on all platforms implementing security guarantees through the use of SGX enclaves. If proven to be successful, this attack would be particularly devastating to enclaves, as is the case with standard operating system protections.

The SGX architecture literature indicates its implementation was done in microcode in order to support security changes if that were to become necessary. The ability to induce major functional changes would presume to be limited by the minimal amount of space that is available for microcode patching.

With that being said. there is reason to believe that SGX will be an attractive environment for the implementation of Spectre style mitigations. As part of a general mitigation strategy for these attacks, Intel has used microcode modifications to implement three ‘barrier’ strategies to thwart the ability for speculation to be used to probe memory. These enhancements implement an Indirect Branch Prediction Barrier (IBPB), a Single Thread Indirect Branch Prediction (STIBP) barrier and Indirect Branch Restricted Speculation (IBRS) support.

The IBRS functionality is used to protect regions of higher privilege from speculation in lower privileged regions. Available guidance specifically indicates that IBRS is not required in order to isolate branch prediction for either SGX enclaves or System Management Mode (SMM) routines.

The ENCLU[EENTER] and ENCLU[EEXIT] instructions are implemented in microcode. It would thus be a reasonable assumption that an effort will be made to modify the behavior of these instructions to implement appropriate speculations barriers on enclave entry or exit. This would be consistent with the current virtual memory protection architecture which issues a full TLB invalidation as a component of the operational implementation of these instructions.

This would presumably thwart the transfer of covert speculation information between trusted and untrusted execution domains. It should be possible to validate this by testing the Spectre variant 1 attack on an SGX capable platform running updated microcode. Given current stability concerns surrounding current microcode updates, any potential implementation may not yet be available or arguably be very unstable. If this is the approach being taken it would be beneficial to the SGX community to have solid guidance on potential microcode interventions or improvements.

In advance of the availability of such fixes, standard software development mitigation practices can also be employed. Support is emerging for compilers which implement ‘retpoline’ support as a means of blocking indirect branch prediction poisoning. Index masking and the use of explicit fencing instructions (lfence and/or mfence) can also be employed.

If microcode based speculation fencing on enclave entry and exit become available, the case can be made that defensive practices inside of the enclave may not be strictly necessary. The Spectre vulnerabilities represent a class of attack dependent on the execution of untrusted code. It would be a reasonable assumption that code being executed in enclave context would be fully trusted.

The SGX enclave environment provides an additional, immediately practical, defensive measure as well. Within an enclave the ENCLU[EGETKEY] instructions provide the basis for generating keys which support either platform or enclave specific sealing keys. These keys can be used to encrypt high value data within the enclave, thus blocking its exfiltration, since the data would then exist in the operational level of the processor as ciphertext. The protected data would need to be decrypted before use but this strategy would require a speculative attack which would need to cope with a highly dynamic target in what could be engineered to be an extremely narrow security vulnerability window.

It is important to note that all of these micro-architectural attacks are only capable of breaching confidentiality, not integrity of data. By retaining their strong integrity guarantees SGX enclaves provide a framework which guarantees the integrity of mitigation modalities such as intra-enclave encryption.

An important consideration moving forward is the possibility of enclaves being used as a modality to support the remote exfiltration of data obtained by micro-architectural probing. This is a possibility secondary to the SGX memory model which allows a process running in trusted enclave context full access to untrusted memory. A preliminary review of the SGX2 architecture suggests this may be a concern on such platforms if interventions are not implemented.

We will update this document with additional findings and guidance as more information becomes available.

Dr. Greg

IDfusion Announces Intel SGX Commercial License

IDfusion, LLC, the industry leader in autonomously introspected security platforms, is pleased to announce that it has been granted a commercial license to release software products based on Intel’s SGX technology. SGX, or Software Guard Extensions, is a powerful hardware security capability used to create regions of memory called enclaves that protect code and data from disclosure or modification.  With this licensing Agreement IDfusion joins a select group of companies, worldwide, which can distribute enclave-enabled security products.

To support its focus on applying SGX security guarantees to Intelligent Network Endpoint Devices (INEDs), IDfusion has produced an independent implementation of the SGX Platform Software (PSW) for the Linux operating system. The PSW is the support environment that enables the SGX capabilities of  Intel  processors to be used to create and remotely attest the security characteristics of enclave enabled software. IDfusion is the first company to announce an alternative PSW implementation designed for the needs of INED and related devices.

The alternative PSW is one component of the SGXfusion development environment available from IDfusion.  While initially designed as a cloud technology, the SGXfusion environment allows companies to bring the strongest possible SGX integrity guarantees to the Internet of Things (IoT), SCADA and other embedded application environments. In addition to an absolute minimum footprint, support for C only applications and popular embedded libraries such as MUSL, the SGXfusion environment provides the unique capability to create standalone SGX enabled binaries.  This framework encapsulates all functionality needed for an SGX enabled application into a single standalone binary with no external dependencies.

For more information contact IDfusion using the information request form at or send an email to

Dr. Greg Wettstein Invited Speaker at DARPA HCSS Conference

IDfusion, LLC’s chief scientist, Dr. Greg Wettstein, has been invited to speak at the upcoming DARPA High Confidence Software and Systems conference in Washington, DC on May 10, 2017 at 3:15 p.m. Dr. Wettstein will be speaking about the scientific basis for the behavioral model he developed to provide run-time security for IDfusion’s  Firenode™ and for the new, secure container model we call a “canister.”

The abstract for the presentation can be found here. Complete slides for the presentation will be available after May 10th.