The Linux capabilities mechanism divides the root privileges to provide more fine-grained access control, but its effectiveness depends on proper implementation and configuration. The scattered enforcement of capabilities in the kernel and its sporadic usage in programs pose challenges in gathering assessment information. To address this, we propose three tools for diagnosing potential problems in its design, implementation, and utilization. First, we employ LLVM/Clang to examine the capabilities enforcement in the kernel to map capabilities checks to files. This is the first attempt to explore the interaction between capabilities and other mechanisms, such as UGO. Second, We propose a pattern-based method to identify the sensitive kernel functions protected by capabilities, quanti-fying the overlap problem of capabilities. Third, we employ a customized fuzzing approach to determine the minimal set of capabilities required by programs, offering insight for secure usage. Additionally, Our study is further guided by international access management standards, providing structured criteria for the assessment. Leveraging data collected by our tools, we identify imperfections of capabilities and reported to stakeholders. To the best of our knowledge, this is the first systematic assessment of Linux capabilities.

The rapid evolution of GPUs has emerged as a promising solution for accelerating the worldwide used SSL/TLS, which faces performance bottlenecks due to its underlying heavy cryptographic computations. Nevertheless, substantial structural adjustments from the parallel mode of GPUs to the serial mode of the SSL/TLS stack are imperative, potentially constraining the practical deployment of GPUs. In this paper, we propose AsyncGBP${}^{+}$, a three-level framework that facilitates the seamless conversion of cryptographic requests from synchronous to asynchronous mode. We conduct an in-depth analysis of the OpenSSL provider and cryptographic primitive features relevant to GPU implementations, aiming to fully exploit the potential of GPUs. Notably, AsyncGBP${}^{+}$supports three working settings (offline/online/hybrid), finely tailored for various public key cryptographic primitives, including traditional ones like X25519, Ed25519, ECDSA, and the quantum-safe CRYSTALS-Kyber. A comprehensive evaluation demonstrates that AsyncGBP${}^{+}$can efficiently achieve an improvement of up to 137.8$\times$compared to the default OpenSSL provider (for X25519, Ed25519, ECDSA) and 113.30$\times$compared to OpenSSL-compatibleliboqs(for CRYSTALS-Kyber) in a single-process setting. Furthermore, AsyncGBP${}^{+}$surpasses the current fastest commercial-off-the-shelf OpenSSL-compatible TLS accelerator with a 5.3$\times$to 7.0$\times$performance improvement.

ARM TrustZone technology has been widely used to create Trusted Execution Environments (TEEs) for enhancing the security of applications. However, the increasing number of installed security-sensitive applications in the secure world will inevitably enlarge the trusted computing base (TCB) of TEE systems. To minimize the TCB of the secure world and increase application portability, Isolated Execution Environments (IEEs) are proposed to protect applications in enclaves created in the normal world. However, existing IEE systems cannot provide the same level of security as the TEE systems, particularly, on resolving the multi-vector attacks that include both physical memory disclosure attacks and software attacks. In this article, we develop a new cache-assisted IEE system called CacheIEE that creates enclaves in the L1 data cache of the normal world to protect sensitive data against multi-vector attacks. First, by always storing the sensitive data in the L1 data cache, CacheIEE can effectively prevent physical memory disclosure attacks. Second, we protect the L1 data cache against untrusted rich OS running in other cores. To support more applications, CacheIEE can process large-size sensitive data in the L1 data cache with constrained capacity. We implement a system prototype of CacheIEE and verify its security and practicability.

Over-privileged Linux containers might put the underlying OS at risk by permitting pointless system calls that could be exploited as entry points to the kernel. However, finding such security profiles is a difficult task as it demands examining the implementation/operation of containers in the absence of knowledge regarding its required system calls. In this article, we propose a hybrid approach to limit the system call usage during the execution of containers. Specifically, given an application container, we maintain an initial fine-grained whitelist by dynamic tracking to control the run-time security along with a complementary whitelist extracted via static analysis to maintain container's functionality while addressing the coverage limitation of dynamic analysis. Our method automatically analyzes the container behavior to identify three execution phases and dynamically enforce the corresponding fine-grained system call whitelists. The invoked system call will be compared with both whitelists to decide if it should be killed to guarantee the container security or logged for further analysis. Our evaluation results with 193 Docker images demonstrate the effectiveness of our approach in significantly reducing the required system calls during the applications' life-cycle. Furthermore, we discuss the reduced attack surface and demonstrate the efficiency of our approach through empirical analysis results.

Container technology is widely adopted due to its features such as light weight and ease of rapid deployment. However, as an OS-level virtualization mechanism, container isolation relies on the kernel’s security mechanisms and the kernel permission data (usually non-control flow data) used by these mechanisms. None of the existing mitigation schemes for non-control flow data attacks provide an effective and practical solution to container security since they either trigger too much overhead, have limited effectiveness over attacks launched in specific ways, or can only be used to protect some specific kernel data. In addition, none of them accurately identify the kernel data associated with container isolation. In this paper, we provide a solution called Condo that enhances container isolation by protecting the associated kernel permission data. We first present a generic non-control flow kernel data protection mechanism that protects different types of kernel data uniformly with low overhead and is not limited by attack methods or data types. We then demystify the models of various kernel access control mechanisms in the container environment, and identify the subject and object permission data that are critical to container isolation. Finally, we provide a solution named Condo to enhance container isolation, which is completely transparent to the existing container ecosystem, including containerized applications and container management/orchestration tools such as Docker. Experimental results show that Condo can effectively reduce the compromises of container isolation due to memory corruption attacks with an acceptable overhead.

The proliferation of IoT and 5G technologies has led to an explosion of data traffic that data centers must handle while ensuring secure transmission via SSL/TLS. The high volume of cryptographic operations required imposes performance bottlenecks. The GPU-based cryptographic accelerator is one of the competitive solutions. However, significant structural differences with practical applications confine their capacities to specific domains, such as offline cryptanalysis, undermining their potential for real-world cryptographic acceleration.

Secure boot is an effective defense mechanism against attacks on system images. However, traditional secure boot mechanisms could not well serve in the IoT scenario. They usually integrate the root key and cryptographic algorithms used for boot authentication into read-only storage like on-chip ROM, which can only be written by the manufacturer and are unchangeable once written. Modification of cryptographic algorithms and root key is sometimes necessary in the IoT scenario. First, some on-the-market IoT devices are shipped with vulnerable cryptographic algorithms (e.g., SHA-1, RSA-1024) that need to be updated. Second, when transferring the ownership of IoT devices, it may be essential to change the root key of IoT devices. In this paper, we propose a secure boot solution for IoT devices, which supports changing the root key and cryptographic algorithms flexibly. Specifically, we store the secure boot associated codes and data in the eMMC (embedded MultiMediaCard), which is a storage device widely deployed on IoT devices. We leverage the write protection mechanism of eMMC to prevent the codes and data from being tampered with by the runtime codes. In addition, a secure cryptographic algorithms and root key updating mechanism has been introduced, which allows only legal updating requests by verifying the identity of the requester. The experimental results show that the scheme can boot the system securely with negligible overhead.

Streaming music has dominated the digital music industry in recent years, which allows users to enjoy a huge music library online with a low subscription price. Terminal-side audio DRM (Digital Right Management) is very critical for streaming music industry, compromising of which will cause unrestricted listening, dumping and unauthorized secondary distribution. However, existing DRM protection schemes mainly focus on defeating software attacks but lack complete shielding against the physical memory disclosure attacks, which may even be launched by the owner of the terminal device. In this paper, we propose a terminal-side audio DRM solution called TrustSAMP to protect the copyrighted audio data against both software attacks and physical memory disclosure attacks. The basic idea is to process the audio data plaintext only in certain on-SoC components secured by ARM TrustZone. To minimize the TCB (Trusted Computing Base) of the secure world, we separate the control flow and the data flow of the Linux audio subsystem and port only the codes used for audio data decryption and plaintext transfer into the secure world. Moreover, we leave most driver codes of the audio-associated on-SoC components in the rich OS (i.e., in the normal world), and introduce a tiny proxy in the secure world to control the associated registers according to the requests from the normal-world drivers. The prototype implemented on real hardware shows that TrustSAMP can play a variety of wav-format audio with very small overhead and negligible loss of audio quality.

Mobile devices have been widely used to deploy security-sensitive applications such as mobile payments, mobile offices etc. SM2 digital signature technology is critical in these applications to provide the protection including identity authentication, data integrity, action non-repudiation. Since mobile devices are prone to being stolen or lost, several server-aided SM2 cooperative signature schemes have been proposed for the mobile scenario. However, existing solutions could not well fit the high-concurrency scenario which needs lightweight computation and communication complexity, especially for the server sides. In this paper, we propose a SM2 cooperative signature algorithm (SM2-CSA) for the high-concurrency scenario, which involves only one-time client-server interaction and one elliptic curve addition operation on the server side in the signing procedure. Theoretical analysis and practical tests shows that SM2-CSA can provide better computation and communication efficiency compared with existing schemes without compromising the security.

Before Android 5.0, the services in Android applications can be invoked either explicitly or implicitly. However, since the implicit service invocations may suffer service hijacking attacks and thus lead to sensitive data leakage, they have been forbidden since Android 5.0. Thereafter the Android system will simply throw an exception and crash the applications that still invokes services implicitly, so that it was expected that application developers will be forced to convert the implicit service invocations to explicit ones. In this paper, we develop a static analysis framework called ISA to analyze the effectiveness of forbidden policy on removing the vulnerable service invocations. We collect two datasets containing common 1390 apps downloaded 1 to 3 months before the forbidden policy is enforced and 30 months after the forbidden policy is enforced, respectively. Our preliminary analysis indicates a 82.58% reduction in the number of vulnerable service invocations due to the enforcement of forbidden policy. However, upon further investigation, we discover that the forbidden policy fails to resolve service hijacking attacks. We find that 36 popular applications are still vulnerable to service hijacking attacks, which can lead to the leakage of sensitive information such as user login credential. Finally, we analyze the reasons of the residue vulnerable invocations and then propose two countermeasures.

The traditional usage of ARM TrustZone has difficulty on solving the conflicts between the manufacturers that want to minimize the trusted computing base by constraining the installation of third-party applications in the secure world and the third-party application developers who prefer to have the freedom of installing their applications into the secure world. To address this issue, researchers propose to create Isolated Execution Environments (called IEEs) in the normal world to protect the security-sensitive applications. In this paper, we perform a systematic study on the IEE data protection models and the ARM cache attributes, and discover three cache-based attacks called CITM that can be leveraged to manipulate the sensitive data protected in IEEs. Specifically, due to the inefficient and incoherent security measures on the cache that maps to the IEE memory (i.e., memory designated for IEEs), attackers in the normal world may compromise the security of IEE data by manipulating the IEE memory during concurrent execution, bypassing the security measures enforced when a security-sensitive application is suspended or finished, or misusing the incomplete security measures during IEE's context switching processes. We conduct case studies of CITM attacks on three well-known IEE systems including SANCTUARY, Ginseng, and TrustICE to illustrate the feasibility to exploit them on real hardware testbeds. Finally, we analyze the root causes of the CITM attacks and propose a countermeasure to defeat them. The experimental results show that our defense scheme has a small overhead.

The following topics are dealt with: learning (artificial intelligence); mobile computing; security of data; Internet of Things; optimisation; resource allocation; data privacy; protocols; and cloud computing.

The Trusted Execution Environment (TEE) has been widely used to protect the security-sensitive sensing systems on Internet-of-Thing (IoT) devices. In the TEE systems, the execution environment is securely divided into a normal domain and a higher privileged secure domain which executing sensing systems through hardware. One common way to achieve the protection is implementing the sensitive functions of the sensing systems as trusted applications (TAs) in the well-isolated secure domain. Users in rich OS have to call TAs through the client applications (CAs), and the invocations must pass through the rich OS kernel. However, an untrusted rich OS may launch man-in-the-middle attacks on the communication between the CAs and TAs, and the misuse of cross-domain communication channel is becoming one severe threat on the TEE systems. In this paper, we develop a defense system named TrustICT to construct a lightweight trusted interaction channel between CAs and TAs without modifying existing TEE architecture. The main idea is to block attacks on the cross-domain interactions via dynamically setting the access permission of domain-shared memory, locking it from kernel mode and unlocking it only to legal CAs in the user mode. Particularly, we propose a multi-core scheduling strategy to defeat potential attacks from all privileged cores. Compared to existing cryptography-based methods, TrustICT dramatically reduces the system overhead since it does not require time-consuming cryptographic computation or sophisticated real-time kernel protection. We implement a prototype of TrustICT on a Freescale i.MX6Quad platform with the OP-TEE software system and evaluate its impacts on rich OS and the cross-domain transactions.

As an essential component on Android devices, External Storage is frequently used for sharing files between different apps. Therefore, compared to Internal Storage, the access control on the External Storage is usually very loose. However, a lot of sensitive files might be stored on the External Storage, which makes it an attractive target for the attackers. Since Android 10, a security mechanism named Scoped Storage has been introduced to protect the sensitive files on the External Storage. However, this mechanism is mainly used to protect the app-specific files, and can't support the sharing of sensitive files between trusted apps in a secure and flexible way. In this paper, we present a secure External Storage sensitive file sharing solution named SecureESFS. It first extends a Linux kernel security mechanism named ACL on the SDCardFS filesystem to protect the External Storage. With different ACL policy settings, the user can dynamically share sensitive files between trusted apps according to specific business needs. We also enforce the integrity protection on the ACL policies by checking the hash message authentication codes (HMAC) of these policies. Moreover, we design a transparent encryption mechanism in SecureESFS to protect the sensitive files on the External Storage, when the Android devices are physically accessed by the attackers, such as removing the SD card. For versions lower than Android 10, SecureESFS can provide independent protection and secure sharing for the sensitive files on the External Storage. For versions higher than Android 10, SecureESFS can achieve the secure sharing of sensitive files while Scoped Storage provides protection for the app-specific files. SecureESFS may also be used to enhance the security of the Scoped Storage mechanism. Experiments conducted on a prototype show that SecureESFS works well and incurs acceptable overhead.

In lots of security-aware scenarios, trusted user interface (TUI) is indispensable. For example, before signing a payment information, user needs to approve the information. Digital right management (DRM) related applications also need TUI supporting. Although current mobile platforms have provided TEE (Trusted Execution Environment) OS to support trusted applications running, introducing additional drivers into TEE OS is not very secure. The additional drivers may increase the code size of TEE OS and expand the attack surface. In this paper, we present a novel secure UI framework called SuiT based on ARM TrustZone hardware security extension. A secure UI driver and a shadow UI driver are implemented in the normal world. In the secure world, only additional switching code is introduced. When an application needs to interact with user in a trustworthy way, the shadow UI driver will take the place of original UI driver to complete the user interaction. During the UI driver switching process, a temporary trusted execution environment for secure UI driver is dynamically built by the switching code in the secure world. The trusted execution environment ensures that the secure UI driver is executed in a secure way and the potential attacks from rich OS can not tamper with the process of user interaction. We also implement a prototype of SuiT based on Android system and Freescale ARM processor with TrustZone extension. Experimental results demonstrate that SuiT can work well with negligible overhead.

TEE(Trusted Execution Environment) has became one of the most popular security features for mobile platforms. Current TEE solutions usually implement secure functions in Trusted applications (TA) running over a trusted OS in the secure world. Host App may access these secure functions through the TEE driver. Unfortunately, such architecture is not very secure. A trusted OS has to be loaded in secure world to support TA running. Thus, the code size in secure world became large. As more and more TA is installed, the secure code size will be further larger and larger. Lots of real attack case have been reported [1]. In this paper, we present a novel TEE constructing method named ALTEE. Different from existing TEE solutions, ALTEE includes secure code in host app, and constructs a trustworthy execution environment for it dynamically whenever the code needs to be run.

Linux container mechanism has attracted a lot of attention and is increasingly utilized to deploy industry applications. Though it is a consensus that the container mechanism is not secure due to the kernel-sharing property, it lacks a concrete and systematical evaluation on its security using real world exploits. In this paper, we collect an attack dataset including 223 exploits that are effective on the container platform, and classify them into different categories using a two-dimensional attack taxonomy. Then we evaluate the security of existing Linux container mechanism using 88 typical exploits filtered out from the dataset. We find 50 (56.82%) exploits can successfully launch attacks from inside the container with the default configuration. Since the privilege escalation exploits can completely disable the container protection mechanism, we conduct an in-depth analysis on these exploits. We find the kernel security mechanisms such as Capability, Seccomp, and MAC play a more important role in preventing privilege escalation than the container isolation mechanisms (i.e., Namespace and Cgroup). However, the interdependence and mutual-influence relationship among these kernel security mechanisms may make them fall into the "short board effect" and impair their protection capability. By studying the 11 exploits that still can successfully break the isolation provided by container and achieve privilege escalation, we identify a common 4-step attack model followed by all 11 exploits. Finally, we propose a defense mechanism to effectively defeat those identified privilege escalation attacks.

The services in Android applications can be invoked either explicitly or implicitly before Android 5.0. However, since the implicit service invocations suffer service hijacking attacks and thus lead to sensitive information leakage, they have been forbidden since Android 5.0. Thereafter since the Android system will simply throw an exception and crash the application that still invokes services implicitly, it was expected that application developers will be forced to convert the implicit service invocations to explicit ones by specifying the package name of the service to be called.

Based on the observations that spy-on-user attacks by calling Android APIs will be detected out by Android API auditing, we studied the possibility of a "transplantation attack", through which a malicious app can take privacy-harming pictures to spy on users without the Android API auditing being aware of it. Usually, to take a picture, apps need to call APIs of Android Camera Service which runs in mediaserver process. Transplantation attack is to transplant the picture taking code from mediaserver process to a malicious app process, and the malicious app can call this code to take a picture in its own address space without any IPC. As a result, the API auditing can be evaded. Our experiments confirm that transplantation attack indeed exists. Also, the transplantation attack makes the spy-on-user attack much more stealthy. The evaluation result shows that nearly a half of 69 smartphones (manufactured by 8 vendors) tested let the transplantation attack discovered by us succeed. Moreover, the attack can evade 7 Antivirus detectors, and Android Device Administration which is a set of APIs that can be used to carry out mobile device management in enterprise environments. The transplantation attack inspires us to uncover a subtle design/implementation deficiency of the Android security.