Home.md

-Home
\ No newline at end of file
+## Acknowledgements
+
+SecBus has been supported by the [TRESCCA][trescca] project (European Community’s Seventh Framework Programme - FP7/2007-2013 - project number 318036). It also received support from the TOISE project (ENIAC Joint Undertaking - ENIAC-2010-1, project number 282557-2), the French "_[Provence Alpes Côte d'Azur][paca]_" region, [STMicroelectronics][stm] and the French "_[Association Nationale de la Recherche et de la Technologie][anrt]_" (ANRT).
+
+----
+
+# SecBus, a hardware / software architecture protecting the external memories of an SoC
+
+* [Short introduction to the SecBus architecture](#short-introduction-to-the-secbus-architecture)
+* [Getting started](#getting-started)
+* [Tips and tricks](#tips-and-tricks)
+* [Contacts](#contacts)
+* [Bibliography](#bibliography)
+
+SecBus is a hardware / software architecture that protects a System-on-a-Chip (SoC) against tampering with its external memories. Thanks to a Hardware Security Module (HSM) SecBus allows enciphering and integrity checking of sensitive memory regions. On top of a SecBus equipped SoC it is possible to build a complete trustworthy computing system that remote users can trust even if it is operated by adversaries. A bit like a smartcard can be trusted by its issuer while in the hands of potential enemies... but with the computing power of a high end computer. SecBus is available in the form of a virtual prototype for simulation on a regular computer and also in the form of true hardware and software for experimentation on [Xilinx] [Zynq cores] and, in particular, on the [ZedBoard] prototyping board.
+
+## Short introduction to the SecBus architecture
+
+Embedded systems can be attacked by many different kinds of attackers, with various goals and means. SecBus focusses on logical or physical attacks against external memories, that is, attacks that aim at extracting or modifying memory contents to access confidential information or to alter the nominal behaviour of the system. A SecBus-equipped platform is able to guarantee the confidentiality and the integrity of critical software applications even in the presence of an adversary who has a physical access to every components of the system, except the internals of the main SoC. The SecBus architecture is also designed to counter a large family of pure software attacks based on the exploit of Direct Memory Access (DMA) capable peripherals like, for instance, Graphics Processing Units (GPUs), Hard Disk Drive (HDD) controllers or network cards.
+
+### Threat model
+
+SecBus assumes that the adversary has a complete physical access to the target embedded system, except the internals of the main SoC. SecBus does not deal with on-silicon attacks, fault attacks or side channel attacks. A lot of research works deal with them and many countermeasure have been proposed and implemented. SecBus considers that such countermeasures are used every time it is required to protect the internals of the SoC. As usual in the security field, SecBus follows a modular approach, where each problem is dealt with as independently as possible from the others.
+
+On the software side SecBus considers embedded systems on which arbitrary applications can be loaded and launched, even by adversaries.
+
+With a complete physical access to the hardware (except the internals of the main SoC), the adversary can spy at every communication between the computer system and the outside world (network, sensors, actuators...) She can also spy at the communications between the hardware discrete components that compose the system itself like, for instance, the exchanges between the main SoC and its external memories. And last but not least, she is not limited to passive probing : she can also tamper with these communications and inject her own data on the communication channels.
+
+The attacks can be either software attacks, hardware attacks, or a combination of the two.
+
+A pure software attack can be the exploit of a software flaw in the embedded software that controls a DMA capable peripheral. Such attacks have been successfully mounted against game consoles, through the exploit of their DVD drives. Similar attacks have been reported on HDD, GPU, etc.
+
+A pure hardware attack can consist in extracting the content of external memory chips (flash or DDR), as has been demonstrated with the famous [cold boot attack]. Memory bus probing and injection is another example that has been used against game consoles ([\[AbH\]](#bibliography)) or crypto processors ([\[MGK\]](#bibliography)).
+
+A typical example of combined attack can be the attacker populating as much external memory as allowed with custom code and probing the memory bus to flip an address bit while the embedded system runs in privileged mode, forcing the embedded system to run the custom code in privileged mode and leading to a privilege escalation.
+
+To make it short: the main SoC cannot trust its environment. Anything that it sends to the outside can be spied at. And anything that comes in can be under control of an attacker, even a piece of data that the SoC has written in its external memory and that it reads back can have been modified.
+
+### Security objective
+
+The main security objective of the SecBus hardware and software architecture is to allow the design of a trustworthy computing platform. The platform shall remain trustworthy even when operated by adversaries. On top of SecBus it is possible to design a software stack that can be attested remotely: a remote operator or user of the platform can get the guarantee that the integrity of the platform has not been compromised and that it behaves as expected.
+
+In order to guarantee that the software stack currently running on an embedded system is really what it should be and that the sensitive information it processes remain confidential, it is necessary to protect all physical external interfaces of the main SoC. The protection shall cover both the confidentiality and the integrity of the external communications. Most of these communications can be protected by software-implemented classical cryptography. Enciphering and deciphering can be used to guarantee the confidentiality. Integrity checking against hash digests or Message Authentication Codes (MAC) can be used to protect the integrity. A network interface, for instance, can be protected when needed by encryption of the payload of the data packets and by messages signature. The same software-implemented cryptographic primitives can be used to protect the communication with mass storage (HDDs or non volatile memories). These techniques are well known and massively used: there are many secure network protocols or HDD encryption solutions available. There is one important exception to the list of the communication channels between the SoC and the external world that these software-implemented techniques can protect: the channel between the SoC and its external memories. Indeed, if an attacker tampers with the content of the external memories, there is no way any more to guarantee that the running software and the cryptographic primitives it is supposed to implement is really what it is. Flipping one single bit of the address or data bus during a read or write transaction can be sufficient to execute arbitrary code in privileged mode.
+
+Countermeasures based on Trusted Platform Modules (TPM) and attestation of the installed software stack can not defeat these attacks because their integrity checks are performed when software components are loaded, not at run time.
+
+The SecBus architecture has been designed in order to defeat the above-mentioned attacks in the context of the discussed threat model. The next section lists several important requirements that have been considered during the design of the SecBus architecture:
+
+* Performance
+* Transparency
+* Software assistance
+
+### Architecture design
+
+The SecBus architecture protects the confidentiality and integrity of the communications between the on-chip CPUs and their off-chip external memories. This protection guarantees that sensitive information do not leave the SoC in clear form and can not be tampered with without this being trapped by an integrity check. This protection is applied on-chip, as transparently as possible. In order to limit the performance overhead, SecBus relies on hardware acceleration: a Hardware Security Module (HSM) is added to the system to take the cryptographic operations in charge.
+
+The HSM embeds cryptographic engines to encipher and decipher the written and read data, to check the integrity of read data and, on write accesses, to compute the digests against which the integrity is checked. A very important design choice characterizes the SecBus architecture and makes it very different from other proposals with similar goals: it tries to be as transparent as possible. The HSM is added to the SoC with as few hardware modification as possible, especially of the CPUs, as such modifications have a rather low acceptance level. Off-the-shelve CPUs, like ARM cores, for instance, are very complex Industrial Property (IP) blocks. Their validation is an enormous workload. Modifying them would require access to confidential information about their internals and would also require to re-validate the modified architecture. The same applies to less complex, still sophisticated, blocks like memory controllers.
+
+In order to be protected, all read - write accesses to the external memories must flow through the HSM so that it is given a chance to apply cryptographic primitives if needed. The best possible location for the HSM is thus between the on-chip interconnect and the on-chip memory controller. This is where the SecBus architecture puts the HSM, as shown in the following figure.
+
+![The HSM in an SoC][HSM-in-SoC]
+
+As the HSM performs cryptographic operations and as these operations take time, the HSM possibly increases the latency of external memory accesses. When fetching an encrypted data, for instance, the data must first be decrypted before being sent to the CPU. One of the major challenges SecBus deals with is this performance overhead. It is as limited as possible and applies only on protected memory areas; when non-sensitive data are stored to and loaded from the external memory there is no penalty at all or a negligible one. This performance constraints lead to an important conclusion: the HSM alone can not decide what memory area stores sensitive data and what other stores regular data; it must thus be driven by the software stack. This software assistance consists in deciding what security policy to apply to what memory area, a bit like a Memory Management Unit (MMU) is driven by the memory manager of the Operating System (OS) to decide what translation to apply between virtual and physical addresses. In the SecBus architecture the HSM is driven by the Software Security Manager (SSM), a software component responsible for the definition of Security Policies (SP) and the binding between memory pages and SPs.
+
+The definition of SPs can be very simple as, for instance, splitting the address space in a small number of fixed size contiguous regions and assigning each a SP. One region could be defined as unprotected, another as protected in integrity only, another in confidentiality only, etc. These simple definitions could be set during the boot sequence by configuring a few interface registers of the HSM. If required, the boundaries between the different regions could be adjusted during operation to reflect the current memory consumption of each kind. The main advantage of such solutions is their simplicity. Allocating a new memory page with a given SP simply consists in allocating it in the right memory region. Their main drawbacks are their lack of flexibility and, as will be shown later, the difficulty to mitigate the performance degradation with the use of different cryptographic primitives for read-only and read-write memory pages. For all these reasons the SecBus architecture is as flexible as possible and allows the definition of SPs at the granularity level of individual memory pages. This is another major difference with related alternate proposals.
+
+The model of the cooperation between the memory manager and the MMU is a very good image to illustrate the cooperation between the SSM and the HSM. The granularity of the memory bus protection is the physical memory pages, with as many different pages sizes as for the MMU. For each physical memory page the SSM assigns a SP, both in terms of confidentiality and integrity, and the HSM applies this policy on all memory accesses falling in the page. This clean and simple organization eases the design of the SSM and of the HSM. It also allows to protect only sensitive memory pages, with the best available cryptographic primitives for the defined SP. In the SecBus terminology, the data structure that binds a SP to a memory page is the Page Security Parameters Entry (PSPE). Each memory page has a corresponding PSPE and this PSPE points to a SP. When the external memories are accessed, the HSM fetches the PSPE of the memory page in which the access falls, uses it to retrieve the SP to apply and performs the required cryptographic operations.
+
+## Getting started
+
+* [Download area]: Archives, documentations...
+* [SecBus architecture (PDF)]: Detailed description of the SecBus architecture.
+* [Virtual prototype]: Simulate the SecBus hardware / software architecture on a PC.
+* [AXI simple bridge]: A tutorial that demonstrates that it is indeed possible to run Linux on a ZedBoard with all DDR accesses from CPU routed to the Programmable Logic (PL). The PL is configured with a simple AXI-AXI bridge. This is the same set up that is used to demonstrate the SecBus HSM, with a much simpler PL configuration.
+* [AXI bridge]: A tutorial to experiment attacks against the memory bus (or the content of external memories) of a processor. It is about the same as the [AXI simple bridge], but with a AXI-AXI bridge that allows sniffing and tampering with the AXI transactions, that is, the memory accesses of the processor.
+* [HSM in transparent mode]: A tutorial to run Linux on a ZedBoard with all DDR accesses from CPU routed to the Programmable Logic configured with the disabled SecBus HSM.
+* [TRESCCA final demonstration]: The set-up of the final demonstration of the SecBus technology for the TRESCCA project. BusyBox/Linux running on a ZedBoard with all DDR accesses from CPU routed to the PL in which the SecBus HSM is mapped. The PL also embeds another hardware module that allows to access the DDR of the ZedBoard from an attacker PC. The HSM protects several memory pages with various security policies. The demonstration shows that attacks against the protected memory pages are prevented/detected.
+* [Secure boot sequence]: Overview of several important Zynq characteristics and of what a complete, secure, boot sequence could be on a ZedBoard equipped with SecBus.
+
+## Tips and tricks
+
+* [Sharing the wireless connection of a laptop with the ZedBoard through an Ethernet cable]: Very useful when travelling with your ZedBoard to places where only a wireless network access is available.
+* [Building a small GNU/Linux software stack for the ZedBoard]: Configure and compile the Linux kernel, U-Boot, the device tree and use [buildroot] to build a small `initramfs` root file system (not SecBus specific). 
+* [Running a Debian distribution on the ZedBoard using tftp and NFS]: A nice and convenient set up for hardware / software development on Zynq (not SecBus specific). 
+* [Running Linux on a Zynq core with CPU caches disabled]: Disabling the L1 and L2 caches to augment the observability on DDR accesses.
+
+## Contacts
+
+Please send an e-mail to `contact` dash `secbus` at `telecom` dash `paristech` dot `fr`.
+
+## Bibliography
+
+* \[SG\]: "_A Memory Encryption Engine Suitable for General Purpose Processors_", S. Gueron. Cryptology ePrint Archive, Report 2016/204, 2016, ([Online version][SG])
+* \[LWL\]: "_Hardware-assisted memory tracing on new SoCs embedding FPGA fabrics_", L.W. Li, G. Duc, R. Pacalet. Annual Computer Security Applications Conference (ACSAC 2015), December 2015.
+* \[SO\]: "_Performance Optimizations of Integrity Checking based on Merkle Trees_", S. Ouaarab, G. Duc, R. Pacalet. Hardware and Architectural Support for Security and Privacy (HASP 2015), June 2015.
+* \[JBTP\]: "_SecBus, a software/hardware architecture for securing external memories_", J. Brunel, R. Pacalet, G. Duc, S. Ouaarab. International Workshop on Trusted Platforms for Mobile and Cloud Computing (TPMCC 2014), April 2014.
+* \[JBMC\]: "_SecBus, a software/hardware architecture for securing external memories_", J. Brunel, S. Ouaarab, R. Pacalet, G. Duc. 2nd IEEE International Conference on Mobile Cloud Computing, Services, and Engineering (MobileCloud 2014), April 2014.
+* \[LSPhD\]: "_Confidentiality and Integrity of the Memory Bus_", Lifeng Su, PhD dissertation. Telecom ParisTech, March 2010.
+* \[LS\]: "_SecBus: Operating System controlled hierarchical page-based memory bus protection_", Lifeng Su, S. Courcambeck, P. Guillemin, C. Schwarz, R. Pacalet. Design, Automation & Test in Europe Conference & Exhibition (DATE 2009), April 2009.
+* \[AbH\]: "_Hacking the Xbox: An Introduction to Reverse Engineering_", Andrew "bunnie" Huang. No Starch Press, July 2003, 288 pp. ISBN: 978-1-59327-029-2 (available as a free ebook to download from the [No Starch Press web site][AbH])
+* \[MGK\]: "_Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller DS5002FP_", Markus G. Kuhn. IEEE transactions on computers, vol. 47, n°. 10, october 1998
+
+[trescca]: http://www.trescca.eu/
+[paca]: http://www.regionpaca.fr/
+[stm]: http://www.st.com/
+[anrt]: http://www.anrt.asso.fr/
+
+[Xilinx]: http://www.xilinx.com/
+[Zynq cores]: http://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html
+[ZedBoard]: http://www.zedboard.org
+[cold boot attack]: http://citp.princeton.edu/memory/
+[SG]: https://eprint.iacr.org/2016/204
+[AbH]: http://www.nostarch.com/
+[buildroot]: http://buildroot.uclibc.org/
+
+[HSM-in-SoC]: images/HSM-in-SoC.png
+
+[Download area]: downloads
+[SecBus architecture (PDF)]: secbus.pdf
+[Virtual prototype]: virtual-prototype
+[AXI simple bridge]: axi-simple-bridge
+[AXI bridge]: axi-bridge
+[HSM in transparent mode]: hsm-as-a-bridge
+[TRESCCA final demonstration]: trescca-demo
+[Secure boot sequence]: secure-boot
+[Sharing the wireless connection of a laptop with the ZedBoard through an Ethernet cable]: sharing-laptop-wireless-connnection-with-zedboard
+[Building a small GNU/Linux software stack for the ZedBoard]: zedboard-linux-uboot-dtb-buildroot
+[Running a Debian distribution on the ZedBoard using tftp and NFS]: zedboard-tftp-nfs
+[Running Linux on a Zynq core with CPU caches disabled]: disabling-zynq-caches
+
+<!-- vim: set tabstop=4 softtabstop=4 shiftwidth=4 noexpandtab textwidth=0: -->