Trusted Execution Environments (TEEs) enable secure code execution on machines that are not fully trusted by the user who runs the workload. However, existing TEE solutions mostly target CPUs and are typically tied to one specific instruction set architecture. Although some accelerators also provide support for TEEs, this leads to multiple, different TEE implementations on the same system, increasing its complexity and trusted computing base (TCB). This challenge becomes particularly apparent when workloads span heterogeneous processing units, because the diversity of TEE implementations complicates the creation of secure communication channels between the individual TEEs.

The rise of Hardware Trojans (HTs) presents a major threat to the dependability of contemporary electronic systems. Logic testing-based HT detection can identify HTs without a reference-free or golden circuit. In this work, we present a survey of current logic testing-based HT detection that considers Sandia Controllability/ Observability Analysis Program (SCOAP) factors. In order to detect HTs with unique features, the community may use this survey to summarize how SCOAP parameters have been modified over time and are widely utilized as features for machine learning and threshold-based HT detection. We evaluate the state of work to date and outline the main areas for future research in our conclusion.

Nowadays, digital devices like sensors, cell phones, and home servers are deeply embedded in our world to make our daily lives easier. Since we heavily rely on these systems, it is crucial to guarantee their correct functionality and to ensure security and privacy properties. As systems become increasingly complex, it is difficult to maintain security since it necessitates a thorough understanding of all functionalities in hardware and software. Complexity may lead to vulnerabilities that malicious components can exploit. These components can compromise security features provided by the processing cores and the operating system (OS), jeopardizing the overall trustworthiness of the system. In this article, we provide a secure-by-default hardware/OS co-design to build a substrate for trustworthy computing in digital devices. The design is based on a tiled architecture that can integrate untrusted hardware components. Instead of relying on isolation mechanisms of potentially malicious components, isolation is achieved by dedicated and independent hardware components called trusted communication units (TCUs). By keeping the attack surface small and isolating all components by default, malicious hardware and software are restricted in access permissions and, hence, cannot easily break the system’s security. We implemented a TCU-based multiprocessor architecture in a silicon research chip, called Masur23, and ran transfer workloads and selected portions of the microkernel-based OS M3. Our measurements demonstrate the feasibility of such a hardware/OS co-design for trustworthy computing. Compared to the entire chip implementation, security features require minimal latency, area, and power consumption overhead.

A key challenge faced by small and medium-sized business entities is securely managing software updates and changes. Specifically, with rapidly evolving cybersecurity threats, changes/updates/patches to software systems are necessary to stay ahead of emerging threats and are often mandated by regulators or statutory authorities to counter these. However, security patches/updates require stress testing before they can be released in the production system. Stress testing in production environments is risky and poses security threats. Large businesses usually have a non-production environment where such changes can be made and tested before being released into production. Smaller businesses do not have such facilities. In this work, we show how “digital twins”, especially for a mix of IT and IoT environments, can be created on the cloud. These digital twins act as a non-production environment where changes can be applied, and the system can be securely tested before patch release. Additionally, the non-production digital twin can be used to collect system data and run stress tests on the environment, both manually and automatically. In this paper, we show how using a small sample of real data/interactions, Generative Artificial Intelligence (AI) models can be used to generate testing scenarios to check for points of failure.