Integration of User Specific Hardware for SecureCore Cryptographic Services (original) (raw)
Hardware Encapsulation of Security Services
Computer Security – ESORICS 2003, 2003
Hardware security modules can be used to encapsulate simple security services that bind security functions such as decryption with authorisation and authentication. Such hardware secured services provide a functional root of trust that can be placed within context of a wider IT solution hence enabling strong separations of control and duty. This paper describes an approach to using such hardware-encapsulated services to create virtual trust domains within a deployed solution. This trust domain is defined by the hardware protection regime, the service code and the policies under which it is managed. An example is given, showing how a TLS session within a web service environment can be protected and how this service can extend the secure communications into the backend systems.
Hardware-rooted Trust for Secure Key Management andTransient Trust
We propose minimalist new hardware additions to a microprocessor chip that protect cryptographic keys in portable computing devices which are used in the field but owned by a central authority. Our authority-mode architecture has trust rooted in two critical secrets: a Device Root Key and a Storage Root Hash, initialized in the device by the trusted authority. Our architecture protects trusted software, bound to the device, which can use the root secrets to protect other sensitive information for many different usage scenarios. We describe a detailed usage scenario for crisis response, where first responders are given transient access to third-party sensitive information which can be securely accessed during a crisis and reliably revoked after the crisis is over.
Secure Kernel Execution with Intel SGX
Anais Estendidos do X Simpósio Brasileiro de Engenharia de Sistemas Computacionais (SBESC Estendido 2020)
Intel SGX is not accessible from the most privileged execution level, known as ring zero, where the operating system kernel is placed. However, it is possible to split the execution responsibility between kernel and userspace by creating a dependency among these two levels that allow internal kernel data to be stored or processed within SGX private enclaves. In this paper we present SKEEN, an enhanced way to isolate internal operating system components and structures with Intel SGX technology, preventing information leak to different components of the same operating system. A proof-of-concept is provided to exemplify its usage.
Third IEEE International Security in Storage Workshop (SISW'05), 2005
The ANSI T10 Object-based Storage Devices (OSD) Standard is a new standard. It evolves the storage interface from fixed size blocks to variable size objects and includes an integrated security protocol that protects storage. This paper presents the requirements, the design tradeoffs, and the final security protocol as defined in the standard. The resulting protocol is based on a secure capability-based model, enabling fine-grained access control that protects both entire storage device and individual objects from unauthorized access. The protocol defines three methods of security based on the applications' requirements. Furthermore, the protocol's key management algorithm allows keys to be changed quickly, without disrupting normal operations. Finally, the protocol is currently being enhanced for version 2.0 of the ANSI T10 OSD standard; future extensions will include privacy and access-control on sections of storage objects.
2010
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to
Design and Implementation of Secure Xenix
IEEE Transactions on Software Engineering, 1987
Secure XenixM is an experimental system designed to run on IBM PC/AT workstations. Like Xenix, it is a UnixT. System V implementation on the PC/AT workstation; unlike Xenix, it eliminates the Unix security deficiencies and it enhances security policies. In this paper, we present the design features of Secure Xenix, their integration within Xenix, and some of the lessons learned from this experiment to date.
Secure Resource Sharing for Embedded Protected Module Architectures
Low-end embedded devices and the Internet of Things (IoT) are becoming increasingly important for our lives. They are being used in domains such as infrastructure management, and medical and healthcare systems, where business interests and our security and privacy are at stake. Yet, security mechanisms have been appallingly neglected on many IoT platforms. In this paper we present a secure access control mechanism for extremely lightweight embedded microcontrollers. Being based on Sancus, a hardware-only Trusted Computing Base and Protected Module Architecture for the embedded domain, our mechanism allows for multiple software modules on an IoT-node to securely share resources. We implement and evaluate our approach for two application scenarios, a shared memory system and a shared flash drive. Our implementation is based on a Sancus-enabled TI MSP430 microcontroller. We show that our mechanism can give high security guarantees at small runtime overheads and a moderately increased size of the Trusted Computing Base.