Security Architecture and Design 281 Provide the Level of Security They Require

Total Page:16

File Type:pdf, Size:1020Kb

Load more

All-in-1 / CISSP All-in-One Exam Guide, Fourth Edition / Harris / 787-0 CHAPTER Security Architecture 5 and Design This chapter presents the following: • Computer hardware architecture • Operating system architectures • Trusted computing base and security mechanisms • Protection mechanisms within an operating system • Various security models • Assurance evaluation criteria and ratings • Certification and accreditation processes • Attack types Computer and information security covers many areas within an enterprise. Each area has security vulnerabilities and, hopefully, some corresponding countermeasures that raise the security level and provide better protection. Not understanding the different areas and se- curity levels of network devices, operating systems, hardware, protocols, and applications can cause security vulnerabilities that can affect the environment as a whole. Two fundamental concepts in computer and information security are the security policy and security model. A security policy is a statement that outlines how entities ac- cess each other, what operations different entities can carry out, what level of protection is required for a system or software product, and what actions should be taken when these requirements are not met. The policy outlines the expectations that the hardware and software must meet to be considered in compliance. A security model outlines the requirements necessary to properly support and implement a certain security policy. If a security policy dictates that all users must be identified, authenticated, and authorized before accessing network resources, the security model might lay out an access control matrix that should be constructed so it fulfills the requirements of the security policy. If a security policy states that no one from a lower security level should be able to view or modify information at a higher security level, the supporting security model will outline the necessary logic and rules that need to be implemented to ensure that under no cir- cumstances can a lower-level subject access a higher-level object in an unauthorized 279 cch05.inddh05.indd 227979 110/5/20070/5/2007 111:51:431:51:43 AAMM All-in-1 / CISSP All-in-One Exam Guide, Fourth Edition / Harris / 787-0 CISSP All-in-One Exam Guide 280 manner. A security model provides a deeper explanation of how a computer operating system should be developed to properly support a specific security policy. NNOTEOTE Individual systems and devices can have their own security policies. These are not the organizational security policies that contain management’s directives. The systems’ security policies, and the models they use, should enforce the higher-level organizational security policy that is in place. A system policy dictates the level of security that should be provided by the individual device or operating system. Computer security can be a slippery term because it means different things to differ- ent people. Many aspects of a system can be secured, and security can happen at various levels and to varying degrees. As stated in previous chapters, information security con- sists of the following main attributes: • Availability Prevention of loss of, or loss of access to, data and resources • Integrity Prevention of unauthorized modification of data and resources • Confidentiality Prevention of unauthorized disclosure of data and resources These main attributes branch off into more granular security attributes, such as authenticity, accountability, nonrepudiation, and dependability. How does a company know which of these it needs, to what degree they are needed, and whether the operat- ing systems and applications they use actually provide these features and protection? These questions get much more complex as one looks deeper into the questions and products themselves. Companies are not just concerned about e-mail messages being encrypted as they pass through the Internet. They are also concerned about the confi- dential data stored in their databases, the security of their web farms that are connected directly to the Internet, the integrity of data-entry values going into applications that process business-oriented information, internal users sharing trade secrets, external at- tackers bringing down servers and affecting productivity, viruses spreading, the internal consistency of data warehouses, and much more. These issues not only affect productivity and profitability, but also raise legal and liability issues with regard to securing data. Companies, and the management that runs them, can be held accountable if any one of the many issues previously mentioned goes wrong. So it is, or at least it should be, very important for companies to know what security they need and how to be properly assured that the protection is actually being provided by the products they purchase. Many of these security issues must be thought through before and during the design and architectural phase for a product. Security is best if it is designed and built into the foundation of operating systems and applications and not added as an afterthought. Once security is integrated as an important part of the design, it has to be engineered, implemented, tested, audited, evaluated, certified, and accredited. The security that a product provides must be rated on the availability, integrity, and confidentiality it claims to provide. Consumers then use these ratings to determine if specific products cch05.inddh05.indd 228080 110/5/20070/5/2007 111:51:561:51:56 AAMM All-in-1 / CISSP All-in-One Exam Guide, Fourth Edition / Harris / 787-0 Chapter 5: Security Architecture and Design 281 provide the level of security they require. This is a long road, with many entities in- volved with different responsibilities. This chapter takes you from the steps that are necessary before actually developing an operating system to how these systems are evaluated and rated by governments and other agencies, and what these ratings actually mean. However, before we dive into these concepts, it is important to understand how the basic elements of a computer system work. These elements are the pieces that make up any computer’s architecture. Computer Architecture Put the processor over there by the plant, the memory by the window, and the secondary storage upstairs. Computer architecture encompasses all of the parts of a computer system that are necessary for it to function, including the operating system, memory chips, logic cir- cuits, storage devices, input and output devices, security components, buses, and net- working components. The interrelationships and internal working of all of these parts can be quite complex, and making them work together in a secure fashion consists of complicated methods and mechanisms. Thank goodness for the smart people who figured this stuff out! Now it is up to us to learn how they did it and why. The more you understand how these different pieces work and process data, the more you will understand how vulnerabilities actually occur and how countermeasures work to impede and hinder vulnerabilities from being introduced, found, and exploited. NNOTEOTE This chapter interweaves the hardware and operating system architectures and their components to show you how they work together. The Central Processing Unit The CPU seems complex. How does it work? Response: Black magic. It uses eye of bat, tongue of goat, and some transistors. The central processing unit (CPU) is the brain of a computer. In the most general description possible, it fetches instructions from memory and executes them. Although a CPU is a piece of hardware, it has its own instruction sets (provided by the operating system) that are necessary to carry out its tasks. Each CPU type has a specific architec- ture and set of instructions that it can carry out. The operating system must be designed to work within this CPU architecture. This is why one operating system may work on a Pentium processor but not on a SPARC processor. NNOTEOTE Scalable Processor Architecture (SPARC) is a type of Reduced Instruction Set Computing (RISC) chip developed by Sun Microsystems. SunOS, Solaris, and some Unix operating systems have been developed to work on this type of processor. cch05.inddh05.indd 228181 110/5/20070/5/2007 111:51:571:51:57 AAMM All-in-1 / CISSP All-in-One Exam Guide, Fourth Edition / Harris / 787-0 CISSP All-in-One Exam Guide 282 The chips within the CPU cover only a couple of square inches, but contain over 40 million transistors. All operations within the CPU are performed by electrical signals at different voltages in different combinations, and each transistor holds this voltage, which represents 0s and 1s to the computer. The CPU contains registers that point to memory locations that contain the next instructions to be executed and that enable the CPU to keep status information of the data that need to be processed. A register is a temporary storage location. Accessing memory to get information on what instructions and data must be executed is a much slower process than accessing a register, which is a component of the CPU itself. So when the CPU is done with one task, it asks the reg- isters, “Okay, what do I have to do now?” And the registers hold the information that tells the CPU what its next job is. The actual execution of the instructions is done by the arithmetic logic unit (ALU). The ALU performs mathematical functions and logical operations on data. The ALU can be thought of as the brain of the CPU, and the CPU as the brain of the computer. Software holds its instructions and data in memory. When action needs to take place on the data, the instructions and data memory addresses are passed to the CPU registers, as shown in Figure 5-1. When the control unit indicates that the CPU can process them, the instructions and data memory addresses are passed to the CPU for actual processing, number crunching, and data manipulation. The results are sent back to the requesting process’s memory address.
Recommended publications
  • Interrupts and Exceptions CPU Modes and Address Spaces Dual-Mode Of

    Interrupts and Exceptions CPU Modes and Address Spaces Dual-Mode Of

    CPU Modes and Address Spaces There are two processor (CPU) modes of operation: • Kernel (Supervisor) Mode and • User Mode The processor is in Kernel Mode when CPU mode bit in Status Interrupts and Exceptions register is set to zero. The processor enters Kernel Mode at power-up, or as result of an interrupt, exception, or error. The processor leaves Kernel Mode and enters User Mode when the CPU mode bit is set to one (by some instruction). Memory address space is divided in two ranges (simplified): • User address space – addresses in the range [0 – 7FFFFFFF16] Studying Assignment: A.7 • Kernel address space Reading Assignment: 3.1-3.2, A.10 – addresses in the range [8000000016 – FFFFFFFF16] g. babic Presentation B 28 g. babic 29 Dual-Mode of CPU Operation MIPS Privilege Instructions • CPU mode bit indicates the current CPU mode: 0 (=kernel) With CPU in User Mode, the program in execution has access or 1 (=user). only to the CPU and FPU registers, while when CPU operates • When an interrupt occurs, CPU hardware switches to the in Kernel Mode, the program has access to the full capabilities kernel mode. of processor including CP0 registers. • Switching to user mode (from kernel mode) done by setting CPU mode bit (by an instruction). Privileged instructions can not be executed when the Exception/Interrupt processor is in User mode, they can be executed only when the processor is in Kernel mode. kernel user Examples of MIPS privileged instructions: Set user mode • any instruction that accesses Kernel address space • all instructions that access any of CP0 registers, e.g.
  • Examining the Viability of MINIX 3 As a Consumer Operating

    Examining the Viability of MINIX 3 As a Consumer Operating

    Examining the Viability of MINIX 3 as a Consumer Operating System Joshua C. Loew March 17, 2016 Abstract The developers of the MINIX 3 operating system (OS) believe that a computer should work like a television set. You should be able to purchase one, turn it on, and have it work flawlessly for the next ten years [6]. MINIX 3 is a free and open-source microkernel-based operating system. MINIX 3 is still in development, but it is capable of running on x86 and ARM processor architectures. Such processors can be found in computers such as embedded systems, mobile phones, and laptop computers. As a light and simple operating system, MINIX 3 could take the place of the software that many people use every day. As of now, MINIX 3 is not particularly useful to a non-computer scientist. Most interactions with MINIX 3 are done through a command-line interface or an obsolete window manager. Moreover, its tools require some low-level experience with UNIX-like systems to use. This project will examine the viability of MINIX 3 from a performance standpoint to determine whether or not it is relevant to a non-computer scientist. Furthermore, this project attempts to measure how a microkernel-based operating system performs against a traditional monolithic kernel-based OS. 1 Contents 1 Introduction 5 2 Background and Related Work 6 3 Part I: The Frame Buffer Driver 7 3.1 Outline of Approach . 8 3.2 Hardware and Drivers . 8 3.3 Challenges and Strategy . 9 3.4 Evaluation . 10 4 Progress 10 4.1 Compilation and Installation .
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra

    Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra

    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
  • Memory Protection in Embedded Systems Lanfranco Lopriore Dipartimento Di Ingegneria Dell’Informazione, Università Di Pisa, Via G

    Memory Protection in Embedded Systems Lanfranco Lopriore Dipartimento Di Ingegneria Dell’Informazione, Università Di Pisa, Via G

    CORE Metadata, citation and similar papers at core.ac.uk Provided by Archivio della Ricerca - Università di Pisa Memory protection in embedded systems Lanfranco Lopriore Dipartimento di Ingegneria dell’Informazione, Università di Pisa, via G. Caruso 16, 56126 Pisa, Italy E-mail: [email protected] Abstract — With reference to an embedded system featuring no support for memory manage- ment, we present a model of a protection system based on passwords and keys. At the hardware level, our model takes advantage of a memory protection unit (MPU) interposed between the processor and the complex of the main memory and the input-output devices. The MPU sup- ports both concepts of a protection context and a protection domain. A protection context is a set of access rights for the memory pages; a protection domain is a set of one or more protection contexts. Passwords are associated with protection domains. A process that holds a key match- ing a given password can take advantage of this key to activate the corresponding domain. A small set of protection primitives makes it possible to modify the composition of the domains in a strictly controlled fashion. The proposed protection model is evaluated from a number of salient viewpoints, which include key distribution, review and revocation, the memory requirements for storage of the information concerning protection, and the time necessary for key validation. Keywords: access right; embedded system; protection; revocation. 1. INTRODUCTION We shall refer to a typical embedded system architecture featuring a microprocessor inter- facing both volatile and non-volatile primary memory devices, as well as a variety of input/out- put devices including sensors and actuators.
  • RTA-OSEK Binding Manual: TMS470/TI

    RTA-OSEK Binding Manual: TMS470/TI

    RTA-OSEK Binding Manual: TMS470/TI Contact Details ETAS Group www.etasgroup.com Germany USA ETAS GmbH ETAS Inc. Borsigstraße 14 3021 Miller Road 70469 Stuttgart Ann Arbor, MI 48103 Tel.:+49 (711) 8 96 61-102 Tel.: +1 (888) ETAS INC Fax:+49 (711) 8 96 61-106 Fax: +1 (734) 997-94 49 www.etas.de www.etasinc.com Japan France ETAS K.K. ETAS S.A.S. Queen's Tower C-17F, 1, place des États-Unis 2-3-5, Minatomirai, Nishi-ku, SILIC 307 Yokohama, Kanagawa 94588 Rungis Cedex 220-6217 Japan Tel.: +33 (1) 56 70 00 50 Tel.: +81 (45) 222-0900 Fax: +33 (1) 56 70 00 51 Fax: +81 (45) 222-0956 www.etas.fr www.etas.co.jp Korea Great Britain ETAS Korea Co. Ltd. ETAS UK Ltd. 4F, 705 Bldg. 70-5 Studio 3, Waterside Court Yangjae-dong, Seocho-gu Third Avenue, Centrum 100 Seoul 137-889, Korea Burton-upon-Trent Tel.: +82 (2) 57 47-016 Staffordshire DE14 2WQ Fax: +82 (2) 57 47-120 Tel.: +44 (0) 1283 - 54 65 12 www.etas.co.kr Fax: +44 (0) 1283 - 54 87 67 www.etas-uk.net Copyright Notice © 2001 - 2007 LiveDevices Ltd. All rights reserved. Version: M00088-001 No part of this document may be reproduced without the prior written consent of LiveDevices Ltd. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license. Disclaimer The information in this document is subject to change without notice and does not represent a commitment on any part of LiveDevices.
  • Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation

    Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation

    12 Bringing Virtualization to the x86 Architecture with the Original VMware Workstation EDOUARD BUGNION, Stanford University SCOTT DEVINE, VMware Inc. MENDEL ROSENBLUM, Stanford University JEREMY SUGERMAN, Talaria Technologies, Inc. EDWARD Y. WANG, Cumulus Networks, Inc. This article describes the historical context, technical challenges, and main implementation techniques used by VMware Workstation to bring virtualization to the x86 architecture in 1999. Although virtual machine monitors (VMMs) had been around for decades, they were traditionally designed as part of monolithic, single-vendor architectures with explicit support for virtualization. In contrast, the x86 architecture lacked virtualization support, and the industry around it had disaggregated into an ecosystem, with different ven- dors controlling the computers, CPUs, peripherals, operating systems, and applications, none of them asking for virtualization. We chose to build our solution independently of these vendors. As a result, VMware Workstation had to deal with new challenges associated with (i) the lack of virtual- ization support in the x86 architecture, (ii) the daunting complexity of the architecture itself, (iii) the need to support a broad combination of peripherals, and (iv) the need to offer a simple user experience within existing environments. These new challenges led us to a novel combination of well-known virtualization techniques, techniques from other domains, and new techniques. VMware Workstation combined a hosted architecture with a VMM. The hosted architecture enabled a simple user experience and offered broad hardware compatibility. Rather than exposing I/O diversity to the virtual machines, VMware Workstation also relied on software emulation of I/O devices. The VMM combined a trap-and-emulate direct execution engine with a system-level dynamic binary translator to ef- ficiently virtualize the x86 architecture and support most commodity operating systems.
  • Operating System Structure

    Operating System Structure

    Operating System Structure Joey Echeverria [email protected] modified by: Matthew Brewer [email protected] Nov 15, 2006 Carnegie Mellon University: 15-410 Fall 2006 Overview • Motivations • Kernel Structures – Monolithic Kernels ∗ Kernel Extensions – Open Systems – Microkernels – Exokernels – More Microkernels • Final Thoughts Carnegie Mellon University: 15-410 Fall 2006 1 Motivations • Operating systems have a hard job. • Operating systems are: – Hardware Multiplexers – Abstraction layers – Protection boundaries – Complicated Carnegie Mellon University: 15-410 Fall 2006 2 Motivations • Hardware Multiplexer – Each process sees a “computer” as if it were alone – Requires allocation and multiplexing of: ∗ Memory ∗ Disk ∗ CPU ∗ IO in general (network, graphics, keyboard etc.) • If OS is multiplexing it must also allocate – Priorities, Classes? - HARD problems!!! Carnegie Mellon University: 15-410 Fall 2006 3 Motivations • Abstraction Layer – Presents “simple”, “uniform” interface to hardware – Applications see a well defined interface (system calls) ∗ Block Device (hard drive, flash card, network mount, USB drive) ∗ CD drive (SCSI, IDE) ∗ tty (teletype, serial terminal, virtual terminal) ∗ filesystem (ext2-4, reiserfs, UFS, FFS, NFS, AFS, JFFS2, CRAMFS) ∗ network stack (TCP/IP abstraction) Carnegie Mellon University: 15-410 Fall 2006 4 Motivations • Protection Boundaries – Protect processes from each other – Protect crucial services (like the kernel) from process – Note: Everyone trusts the kernel • Complicated – See Project 3 :) – Full
  • Based On: 2004 Deitel & Associates, Inc

    Based On: 2004 Deitel & Associates, Inc

    Based on: 2004 Deitel & Associates, Inc. Operating Systems Computer Science Department Prepared By Dr. Suleyman Al-Showarah 1.9 2000 and Beyond Middleware is computer software that provides services to software applications beyond those available from the operating system. Middleware Links two separate applications Often over a network and between incompatible machines – Particularly important for Web services Simplifies communication across multiple architectures Middleware : Software that acts as a bridge between an operating system or database and applications, especially on a network. 1.9 2000 and Beyond A Web service is a method of communication between two electronic devices over a network. Web services Encompass set of related standards Ready-to-use pieces of software on the Internet Enable any two applications to communicate and exchange data 1.10 Application Bases Application base Combination of hardware and operating system used to develop Applications Developers and users unwilling to abandon established application base Increased financial cost and time spent relearning What does Application Base mean? The application base is the directory, which contains all the files related to a .NET application, including the executable file (.exe) that loads into the initial or default application domain. 1.11 Operating System Environments Operating systems intended for high-end environments Special design requirements and hardware support needs Large main memory Special-purpose hardware Large numbers of processes Continue ... Embedded systems Characterized by small set of specialized resources Provide functionality to devices such as cell phones and PDAs (see next slide) Efficient resource management key to building successful operating system PDAs A personal digital assistant (PDA), also known as a handheld PC, or personal data assistant, is a mobile device that functions as a personal information manager.
  • Kafl: Hardware-Assisted Feedback Fuzzing for OS Kernels

    Kafl: Hardware-Assisted Feedback Fuzzing for OS Kernels

    kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo, Cornelius Aschermann, and Robert Gawlik, Ruhr-Universität Bochum; Sebastian Schinzel, Münster University of Applied Sciences; Thorsten Holz, Ruhr-Universität Bochum https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/schumilo This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo Cornelius Aschermann Robert Gawlik Ruhr-Universität Bochum Ruhr-Universität Bochum Ruhr-Universität Bochum Sebastian Schinzel Thorsten Holz Münster University of Applied Sciences Ruhr-Universität Bochum Abstract free vulnerabilities, are known threats for programs run- Many kinds of memory safety vulnerabilities have ning in user mode as well as for the operating system been endangering software systems for decades. (OS) core itself. Past experience has shown that attack- Amongst other approaches, fuzzing is a promising ers typically focus on user mode applications. This is technique to unveil various software faults. Recently, likely because vulnerabilities in user mode programs are feedback-guided fuzzing demonstrated its power, pro- notoriously easier and more reliable to exploit. How- ducing a steady stream of security-critical software bugs. ever, with the appearance of different kinds of exploit Most fuzzing efforts—especially feedback fuzzing—are defense mechanisms – especially in user mode, it has limited to user space components of an operating system become much harder nowadays to exploit known vul- (OS), although bugs in kernel components are more nerabilities.
  • Distribution and Operating Systems

    Distribution and Operating Systems

    Distributed Systems | Distribution and Operating Systems Allan Clark School of Informatics University of Edinburgh http://www.inf.ed.ac.uk/teaching/courses/ds Autumn Term 2012 Distribution and Operating Systems Overview I This part of the course will be chiefly concerned with the components of a modern operating system which allow for distributed systems I We will examine the design of an operating system within the context that we expect it to be used as part of a network of communicating peers, even if only as a client I In particular we will look at providing concurrency of individual processes all running on the same machine I Concurrency is important because messages take time to send and the machine can do useful work in between messages which may arrive at any time I An important point is that in general we hope to provide transparency of concurrency, that is each process believes that it has sole use of the machine I Recent client machines such as smartphones, have, to some extent, shunned this idea Distribution and Operating Systems Operating Systems I An Operating System is a single process which has direct access to the hardware of the machine upon which it is run I The operating system must therefore provide and manage access to: I The processor I System memory I Storage media I Networks I Other devices, printers, scanners, coffee machines etc http://fotis.home.cern.ch/fotis/Coffee.html Distribution and Operating Systems Operating Systems I As a provider of access to physical resources we are interested in the operating system providing: I Encapsulation: Not only should the operating system provide access to physical resources but also hide their low-level details behind a useful abstraction that applications can use to get work done I Concurrent Processing: Applications may access these physcial resources (including the processor) concurrently, and the process manager is responsible for achieving concurrency transparency I Protection: Physical resources should only be accessed by processes with the correct permissions and then only in safe ways.
  • Metro Ethernet Design Guide

    Metro Ethernet Design Guide

    Design and Implementation Guide Juniper Networks Metro Ethernet Design Guide August 2016 ii © 2016 Juniper Networks, Inc. Design and Implementation Guide Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Copyright © 2016, Juniper Networks, Inc. All rights reserved. © 2016 Juniper Networks, Inc. iii Design and Implementation Guide Table of Contents Chapter 1 Introduction ............................................................................................................... 1 Using MPLS with Metro Ethernet ........................................................................................... 1 Metro Ethernet Solutions ......................................................................................................... 2 Chapter 2 Metro Ethernet Overview ......................................................................................... 3 Metro Ethernet Service Types ..................................................................................................... 5 Carrier Ethernet Overview........................................................................................................... 5 Carrier Ethernet Certification ................................................................................................... 6 Chapter 3 Architecture Overview .............................................................................................. 7 Juniper Networks Portfolio for Metro Ethernet Networks .........................................................
  • 130 Demystifying Arm Trustzone: a Comprehensive Survey

    130 Demystifying Arm Trustzone: a Comprehensive Survey

    Demystifying Arm TrustZone: A Comprehensive Survey SANDRO PINTO, Centro Algoritmi, Universidade do Minho NUNO SANTOS, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa The world is undergoing an unprecedented technological transformation, evolving into a state where ubiq- uitous Internet-enabled “things” will be able to generate and share large amounts of security- and privacy- sensitive data. To cope with the security threats that are thus foreseeable, system designers can find in Arm TrustZone hardware technology a most valuable resource. TrustZone is a System-on-Chip and CPU system- wide security solution, available on today’s Arm application processors and present in the new generation Arm microcontrollers, which are expected to dominate the market of smart “things.” Although this technol- ogy has remained relatively underground since its inception in 2004, over the past years, numerous initiatives have significantly advanced the state of the art involving Arm TrustZone. Motivated by this revival ofinter- est, this paper presents an in-depth study of TrustZone technology. We provide a comprehensive survey of relevant work from academia and industry, presenting existing systems into two main areas, namely, Trusted Execution Environments and hardware-assisted virtualization. Furthermore, we analyze the most relevant weaknesses of existing systems and propose new research directions within the realm of tiniest devices and the Internet of Things, which we believe to have potential to yield high-impact contributions in the future. CCS Concepts: • Computer systems organization → Embedded and cyber-physical systems;•Secu- rity and privacy → Systems security; Security in hardware; Software and application security; Additional Key Words and Phrases: TrustZone, security, virtualization, TEE, survey, Arm ACM Reference format: Sandro Pinto and Nuno Santos.