Cryptographic keys are required not to be duplicated unnecessarily and to be zeroized from memory after use, as mandated by ISO/IEC 19790 and FIPS 140–3. Because applications run on an operating system, verifying key zeroization solely through their interactions is difficult. Although methodologies for enforcing key zeroization have been studied, there is a lack of empirical research confirming that zeroization actually occurs in practice. To address this gap, we propose a live memory forensic technique employing an FPGA to periodically detect AES keys, which we then use to investigate the key zeroization behavior of applications that use AES under Ubuntu Linux (with a FIPS-compliant kernel) on both AArch64 and x86-64, as well as on Windows 11 (x86-64). Our investigation reveals that AES instructions hold round keys in registers, but during OS context switches these register contents are copied into memory and remain unzeroized when the process terminates. Moreover, when an application terminates abnormally, insufficient signal handling prevents key zeroization, and cryptographic keys can be included in core dumps potentially leaking them externally. We further observe that, on non-FIPS-compliant kernels, keys can persist across OS reboots. These findings provide valuable information for developers following key zeroization guidelines and for cryptographic module testers. Finally, we propose and supply developers with feasible mitigation strategies to reduce key duplication and persistence at both the application and library levels.

The goal of this study is to investigate the problem of caches side-channel attacks on the open-source RISC-V architecture. Traditionally, these concerns have been addressed by research into hardware enhancements or software defense strategies. Those methods are, unfortunately, extremely hard to accomplish or lead to significant performance degradation. In this article, we investigate at a system for identifying cache side-channel threats such Spectre in real time. We utilize performance counters inside the processor to track the processor’s cache behavior and a neural network to evaluate the acquired data. Since the presence of cache side-channels typically results in a dramatically altered cache utilization behaviors, our neural network would take advantage of it and detect a Spectre attack in our test environment with an accuracy of more than 99%. To summarize, we are able to inform the user when a cache side-channel attack occurs using data from only four counters.

This poster presents a Trusted Execution Environment (TEE) hardware implementation based on a heterogeneous architecture. The TEE verifies the integrity of software applications based on a chain of trust with the initial authentication. The chain-of-trust is implemented in software, using TEE hardware crypto-processors. The initial authentication is called the Root-of-Trust (RoT), and the isolated 32-bit system handles it. On the peripheral bus, there are several cryptography accelerators implemented such as SHA- 3, ED25519, AES, and a True Random Number Generator (TRNG). The TRNG module has not only the public channel over the peripheral bus but also a special private channel just for the isolated core. The proposed system was implemented in a 5mm x 5mm die by the 180-nm ROHM process library.

Many IoT devices are geographically distributed without human administrators, which are maintained by a remote server to enforce security updates, ideally through machine-to-machine (M2M) management. However, malware often terminates the remote control mechanism immediately after compromise and hijacks the device completely. The compromised device has no way to recover and becomes part of a botnet. Even if the IoT device remains uncompromised, it is required to update due to recall or other reasons. In addition, the device is desired to be automatically disposable after the expiration of its service, software, or device hardware to prevent being cyber debris.

The trusted execution environment protects data by taking advantage of memory isolation schemes. Most of the software implementations on security enclaves offer a framework that can be implemented on any processor architecture. Assuming that privilege escalation is not possible through software means, the only way to access protected data is over authentication over a driver in kernel mode. However, the use of hardware back-doors cannot prevent processor execution in more privileged modes. Implementation of kernel-mode allows the reading of sensitive data over the protected regions of memory. In this work, a proposal of crypto-accelerator is described. The peripheral bus in the proposed architecture features a write-only secure memory. That means the cryptography operations on the software level can not read the sensitive data from that secure memory. This approach suppresses any cache coherence manipulator and fault execution-related attacks against reading sensitive data. The peripheral can be useful to accelerate the cryptography operations, and store securely intermediate calculations as well as storing secure keys. The time of execution compared to the software counterpart can be reduced down to 2.5 decades, and the throughput is risen to 3 decades, reaching speeds of 30MB/s for large chunks of data. The total area represents 10.7% of the total area of a dual-core RISC-V processor with RV64IMAFC extensions and TileLink buses.

Trusted Execution Environment (TEE) becomes a popular security extension on current CPUs (e.g., Arm Trust-Zone, Intel SGX, and RISC-V Keystone), but each TEE has its original SDK and cannot keep software portability. GlobalPlatform (GP) defines the general APIs named “TEE Internal APIs”, and smartphones mainly use them. In addition, the implementation of GP API assumes a Trusted OS, and some TEEs cannot implement it directly. Furthermore, some TEEs offer Enclave Definition Language (EDL) for secure communication between a normal application and a trusted application, which is not assumed by GP APIs. In order to solve these problems, we propose a library implementation of GP TEE internal APIs on each TEE SDK. We selected GP APIs for architecture-dependent or independent (e.g., secure storage and time). The architecture-independent APIs require the help of Linux or can be implemented efficiently with CPU-specific instruction. They are implemented as same as possible on each architecture. The library is designed to fit for each EDL (i.e., “edger8r” on Intel SGX “keyedge” on RISC-V) and keeps the communication security. The library is implemented on Intel SGX and RISC-V Keystone. The performances are measured and compared with the OP-TEE which is a trusted OS style implementation on Arm TrustZone. The comparison shows the feature of each implementation.

The Universal Serial Bus (USB) supports a diverse and wide-ranging set of device types. To enable ease of use, USB devices are automatically detected and classified by common operating systems, without any authentication. This trust-by-default design principle can be easily exploited, and led to numerous attacks in the past (e.g., Stuxnet, BadUSB, BadAndroid), specifically targeting high-value organizations. Administrators' efforts to prevent these attacks may also be threatened by unscrupulous users who may insert any USB device, or malicious users (inside attackers) who may try to circumvent OS/kernel-enforced protection mechanisms (e.g., via OS replacement). The root causes of USB attacks appear to be the lack of robust authentication of individual USB devices and inadequate tamper-proofing of the solution mechanism itself. We propose DeviceVeil to address these limitations. To authenticate individual USB devices, we utilize the tamper-proof feature of Physical Unclonable Functions (PUFs); PUFs extract unique features from physical characteristics of an integrated circuit (IC) at a reasonable cost (less than 1 USD). To make our authentication mechanism robust, we implement it as a small hypervisor, and protect it by a novel combination of security technologies available in commodity PCs, e.g., Trusted Platform Module (TPM), customized secure boot, and virtualization support. The OS disk image with all user data is encrypted by a key sealed in TPM and can be decrypted by the hypervisor only. Customized secure boot allows the loading of the legitimate hypervisor and OS kernel only. The hypervisor enables pre-OS authentication to protect the trust-by-default OS from USB attacks. The chain of trust continues from power-on to the insertion of a USB device and disallows all illegitimate USB devices. DeviceVeil's PUF authentication takes about 1.7 seconds during device insertion.

Determining whether two or more packages cannot be installed together is an important issue in the quality assurance process of package-based distributions. Unfortunately, the sheer number of different configurations to test makes this task particularly challenging, and hundreds of such incompatibilities go undetected by the normal testing and distribution process until they are later reported by a user as bugs that we call “conflict defects”. We performed an extensive case study of conflict defects extracted from the bug tracking systems of Debian and Red Hat. According to our results, conflict defects can be grouped into five main categories. We show that with more detailed package meta-data, about 30 % of all conflict defects could be prevented relatively easily, while another 30 % could be found by targeted testing of packages that share common resources or characteristics. These results allow us to make precise suggestions on how to prevent and detect conflict defects in the future.

Medical information systems carry sensitive data, which necessitates security and privacy. However, there is well-known trade-off between usability and security, and security can harm care providers and patients. This paper addresses the trade-off between security and usability in medical systems, and presents a case where higher security with better usability was achieved through close cooperation between computer scientists and care providers. The direct interaction might be costly for both, but appropriate tools could make the collaboration acceptable and practical.

KNOPPIX is a bootable CD with a collection of GNU/Linux software. KNOPPIX is very convenient but it requires downloading 700MB iso image and burning a CD-ROM when it is renewed. In order to solve this problem we made SFS-KNOPPIX which boots from Internet with SFS (Self-certifying File System). SFSKNOPPIX requires 20MB boot-loader with Linuxkernel and miniroot. Root file system is obtained from Internet with SFS at boot time. It enables to change root file system and makes easy to try new version of KNOPPIX. In this paper we describe the detail of SFSKNOPPIX and its performance.

This paper presents a new approach to dynamic software tuning called the adaptive algorithm selection method (AASM). The AASM is built into the calling sequence of a library. When the library is called, the AASM is activated. The AASM selects and executes the optimum algorithm from registered algorithms in a library, based on data and machine type. As a result, the software is automatically tuned and the execution time is shortened. The relation between the data and the best algorithm for a given machine is learned by a neural network from the results of performance tests of the registered algorithms. We experimented on a multi-strings search problem with the AASM on the following machines: the CRAY X-MP/216, FACOM M 1800/30, and SUN Sparc Station 2. From these experiments we demonstrated that the AASM is able to minimize the execution time.>