Pascal Cotret

Florian Devic
email: f.devic@netheos.net

Guy Gogniat

Benoît Badrignans
email: b.badrignans@netheos.net

Lionel Torres

Security enhancements for FPGA-based MPSoCs: a boot-to-runtime protection flow for an embedded Linux-based system

Nowadays, embedded systems become more and more complex: the hardware/software codesign approach is a method to create such systems in a single chip which can be based on reconfigurable technologies such as FPGAs (Field-Programmable Gate Arrays). In such systems, data exchanges are a key point as they convey critical and confidential information and data are transmitted between several hardware modules and software layers. In case of an FPGA development life cycle, OS (Operating System) / data updates as runtime communications can be done through an insecure link: attackers can use this medium to make the system misbehave (malicious injection) or retrieve bitstream-related information (eavesdropping). Recent works propose solutions to securely boot a bitstream and the associated OS while runtime transactions are not protected. This work proposes a full boot-to-runtime protection flow of an embedded Linux kernel during boot and confidentiality/integrity protection of the external memory containing the kernel and the main application code/data. This work shows that such a solution with hardware components induces an area occupancy of 10% of a xc6vlx240t Virtex-6 FPGA while having an improved throughput for Linux booting and lowlatency security for runtime protection.

I. INTRODUCTION

In embedded systems, MPSoCs (Multi-Processor Systems-on-Chip) are managed by an embedded OS (for instance, uCLinux [START_REF] Uclinux | uCLinux -Embedded Linux/Microcontroller Project[END_REF]). This OS manages the tasks distribution over all the processor and hardware IPs connected through a dedicated communication link (which is a security breach usable by the incoming attacker) implemented in the target FPGA chip. Bitstream download can be protected to prevent attacks such as replay. Hardware accelerators are also made for providing a user-defined protection layer during the boot of the OS or the execution of the main application running on an embedded system. Devic et al. [START_REF] Devic | Securing boot of an embedded linux on FPGA[END_REF] proposed a solution to secure the boot of an embedded Linux on a Xilinx ML605 FPGA platform. In such a solution, designers can securely set a Linux-based embedded system; unfortunately, during runtime execution, there is no additional protection mechanism to protect the system against attacks. For instance, an attacker can easily modify memory contents to make the system misbehave or create denial-of-service. This work presents an extension of the work of Devic et al. [START_REF] Devic | Securing boot of an embedded linux on FPGA[END_REF] to provide the final user a complete protection flow from bitstream download to runtime applications execution. This paper is organized as follows. Section II describes the threat model taken into account in this work. Section III summarizes works related to bitstream, boot and runtime communication protection. Section V shows how a bus-based MPSoC can be protected with a flexible and reconfigurable solution relying on security-enhanced interfaces. Then, Section VI presents implementation results. Finally, Section VII discusses the security of the solution presented in this work while section VIII concludes and highlights the main perspectives we envision.

II. THREAT MODEL

It is assumed that the FPGA system is exposed to hostile environment where physical but non-invasive attacks, excepted side-channel ones, introduced by Kocher et al. [START_REF] Kocher | Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems[END_REF], are feasible. Besides that, it is assumed that the target FPGA is trusted. Typically, off-chip bus probing and active probing (injection) are considered in our threat model. We consider all attacks aiming to read, modify or replay code or data directly on the external memory: Linux kernel or application modifications should be detected by security mechanisms. This work focuses on three main attacks:

• Spoofing: an attacker provides a random data value on the external bus. • Relocation: an instruction put on the external bus by the attacker is copied from a different bus address (i.e. the attacker puts the instruction from address #5 while expected value is from address #2). • Replay: similarly to a relocation attack, the attacker intercepts a valid packet and replays it at an opportune time to make the system misbehave. While spoofing and relocation affects current memory contents, replay can be used to make a downgrade of the FPGA chip: a former bitstream or an obsolete version of the embedded OS can be uploaded in the FPGA itself: this leads to misbehaviors and denial-of-service which makes the system unusable. Therefore, the only way to access the system is through the external memory and the external bus. A solution would be to encrypt and authenticate the whole external memory. Unfortunately, this solution has a high cost in terms of resources consumption and latency overhead. For many applications, building a flexible solution where only the most critical code and/or data sections to be stored in the external memory are protected with cryptographic services is a good choice. Other parts of the memory can be in plaintext or only authenticated [START_REF] Crenne | Configurable memory security in embedded systems[END_REF]. In this case, attackers still have possibilities to compromise the system by tampering unprotected parts of the external memory. Therefore, the system designer needs additional mechanisms to monitor system activity and detect any abnormal behavior.

III. RELATED WORK

A. Bitstream protection

To ensure a complete boot-to-runtime protection, we need to secure the FPGA configuration (the bitstream) against spoofing, relocation and replay attacks. These latter are particularly dangerous because the current approaches proposed by FPGA vendors like Xilinx [START_REF]Virtex-6 FPGA Configuration, user guide. Xilinx corporation[END_REF] or Microsemi with the ISP (In-System Programming) [START_REF]System Programming (isp) of Actel low-power flash devices using flashpro3[END_REF] to ensure bitstream confidentiality and integrity are inefficient against replay. Even if an update may typically be performed to correct a critical security flaw, it is possible to downgrade a system, in order to exploit vulnerabilities present in a previous version. Nevertheless, academic literature proposes mechanisms against downgrades.

In [START_REF] Drimer | A protocol for secure remote updates of FPGA configurations[END_REF], Drimer describes a solution that ensures up-todateness for SRAM FPGAs considering that not only the FPGA chip is trusted but also the whole board. This system with several flash memory slots allows the FPGA to start thanks to a bitstream present in a rescue slot, in case of update failure.

Braeken et al. propose STRES (Secure Techniques for Remote reconfiguration of Embedded Systems) [START_REF] Touhafi | Secure Techniques for Remote configuration of Embedded Systems[END_REF] based on STS (Station-to-Station) protocol also requiring processor instantiation. It uses elliptic curve communicating through a TCP/IP connection.

Similarly, Devic et al. propose a protocol [START_REF] Devic | Secure protocol implementation for remote bitstream update preventing replay attacks on FPGA[END_REF] that ensures up-to-dateness for non-volatile FPGAs embedding a nonvolatile memory.

B. Boot protection

As described in section II, the kernel is typically stored in an external Flash memory due to the large storage capacity requirement. Generally this memory is off-chip, allowing an attacker to modify the kernel in order to introduce malicious code.

Hash algorithms are classically used to ensure kernel integrity like in [START_REF]Discretix Secure Boot (DxSB)[END_REF] where Discretix used such a mechanism for a secure processor. It is the same principle for Atmel [START_REF]Safe and secure bootloader implementation[END_REF] and several others companies.

AEGIS [START_REF] Suh | AEGIS: Architecture for tamper-evident and tamper-resistant processing[END_REF] is a well accomplished example of hardware to OS securing but requires having a specific processor with a modified operating system.

More recently, ARM conceived TrustZone [START_REF]Building a secure system using trustzone technology[END_REF] to build a boot-to-OS chain of trust. In this scheme the software is protected and monitored thanks to a secure bit added to the bus in the hardware. TrustZone uses RSA-PSS (Rivest, Shamir and Adleman -Probabilistic Signature Scheme) to secure the boot. This asymmetric cryptographic protocol verifies the signature of a second level bootloader but is vulnerable to replay attacks.

In [START_REF] Devic | Securing boot of an embedded linux on FPGA[END_REF], Devic et al. implement on FPGA a boot mechanism that precludes kernel modifications using SHA-256 (Secure Hash Algorithm) hash function preventing from replays attacks and supports updates. Three implementations, (last twos based on hardware acceleration mechanisms), are proposed to offer three performance/area overhead trade-offs:

• First based on a soft SHA-256 function.

• Second based on a hard SHA-256 crypto core.

• And the last one based on a hard SHA-256 crypto core accessed with DMA (Direct Memory Access) transfers. This work proposed also a flexibility improvement involving asymmetric cryptography (RSA-1024 signature verification) that allows changing the kernel in external memory without changing the bitstream.

C. Runtime protection

In the literature, several studies have addressed the security of embedded systems [START_REF] Ravi | Security in embedded systems: Design challenges[END_REF]. At the communication level, these systems can be protected either by software or hardware mechanisms. Software solutions generally do not require additional hardware but offer low efficiency in terms of latency which can be critical for applications where reactivity is essential to fend off attacks. Regarding NoC (Network-on-Chip)-based architectures, Evain et al. [START_REF] Diguet | NOCcentric security of reconfigurable SoC[END_REF] propose a solution where security controls are done in each network interface in a distributed manner. Fiorin [START_REF] Fiorin | A data protection unit for NoC-based architectures[END_REF][8] describes a similar approach with a more detailed implementation. For bus-based communication architecture, one of the most significant work was done by Coburn et al. [START_REF] Coburn | SECA: Security-Enhanced Communication Architecture[END_REF] by an approach similar to Fiorin's work with a centralized security manager aiming to check read/write access rules without cryptographic features (more latency overhead due to the communication between individual interfaces and the manager). Cotret et al. [START_REF] Cotret | Bus-based MPSoC security through communication protection: A latency-efficient alternative[END_REF] proposes a latency-efficient alternative for MPSoC based on the ARM AXI bus protocol with flexible security configurations and additional cryptographic features. This work describes further how this solution can be added to the Linux boot protection flow of Devic et al. [START_REF] Devic | Securing boot of an embedded linux on FPGA[END_REF] to provide a completely secure chain from bitstream download to runtime application execution: such a system should be able to manage updates of OS and protection of runtime transactions in the target multiprocessor system.

IV. A SECURED BOOT-TO-RUNTIME FLOW

This work proposes a solution based on some works described in Section III to provide a complete secure flow from bitstream to runtime execution of an embedded Linux OS on a FPGA-based MPSoC architecture. It should prevent an attacker to run its own malicious code introduced in an external memory unit.

A. Flexible boot of an embedded Linux

In the existing scheme provided by Xilinx, the bitstream is securely copied from an external Flash to the FPGA and started. In the meantime, block RAMs embedded within the FPGA chip are initialized with a small software called "bootloader" run by a GPP (General Purpose Processor): the Linux kernel starts once it has been copied by the loader in the DDR external memory (alternatively, the Linux kernel can be transferred from the Flash to the DDR (Double Data Rate) memory using a DMA controller improving the boot time as it can be seen in implementation results). Unfortunately, there is a security breach in such a flow: an attacker can easily update the Flash memory with a malicious kernel because there is no integrity verification of the Flash. That is the reason why Devic et al. [START_REF] Devic | Securing boot of an embedded linux on FPGA[END_REF] add blocks in the previous flow (Figure 1) to provide a flexible integrity protection layer. In this case, the kernel is copied into the DDR memory. An hash function, implemented in the FPGA (the only trusted area referring to Section II), computes a hash value which is compared by the bootloader with its own kernel hash value: the kernel is started only if values are equal. The other implementation, based on an RSA asymmetric cryptographic function allows the final user to change the kernel (in the DDR external memory) without changing the bitstream. This secure boot flow is done in two steps:

• First, the hash function generates the kernel hash value.

• Then, the bootloader (run by the GPP) verifies the signature of the hash value stored in the external Flash memory with the previously generated hash value and its public key. In Figure 1, the RSA function does not improve the security level of the solution, the only motivation is to add flexibility. At this point, the embedded Linux OS is stored in plaintext in the DDR external memory. This is a major security flaw as an attacker can easily modify DDR contents after boot in order to make the system misbehave: that is why security features must be implemented at the DDR level.

B. Security of the external memory after boot

This work proposes to add confidentiality and integrity features to the DDR external memory, these two features are embedded in a block called CF (Cryptographic Firewall), implementation details are given further in this work. The CF, based on a AES-GCM algorithm, allows the designer to protect the Linux Kernel stored in the DDR external memory with confidentiality and integrity or integrity only, depending on the main application requirements. The schematic of Figure 2 shows the CF implemented in a flow similar to the previous one (Figure 1). In this case, the Linux kernel is not the only entity protected by the Cryptographic Firewall. Any application/data used by a processor in the architecture implemented in the trusted FPGA chip can be protected with flexible security features thanks to the additional logic in the CF (in Figure 2, app1 is protected in confidentiality and integrity while data2 is in plaintext). The decision to protect such and such DDR memory section with full or without security is up to the system designer and depends on the security requirements of the target embedded system. Section V gives details about the structure of runtime security enhancements provided in this work.

V. SECURITY ENHANCEMENTS FOR RUNTIME

PROTECTION

In order to prevent a generic MPSoC system from the threat model detailed in Section II, firewalls are implemented within the system. The target system is composed of processors (including a GPP), internal memories, dedicated IPs embedded within an FPGA and connected to an external memory. Each interface between a peripheral and the communication bus is enhanced with a firewall that aims to monitor communications before they reach the bus and propagate within the system. On the MPSoC shown in Figure 3, there are two categories of firewalls: Local Firewalls and a Cryptographic Firewall (this later adds a layer of cryptographic services towards the external RAM memory).

A. Firewall features

Even if the external RAM memory is protected with confidentiality and integrity, this work considers that plaintext memory are available and may be used by the attacker to make the system misbehave. Therefore, protecting the external memory with cryptographic services (defined in Section V-D) is not enough: this work proposes to check read/write accesses and data format rules according to designer-defined security policies. These security policies aim to define a security context for a given address space in terms of communications protection (read/write. . . ) and cryptographic services (some address spaces must be ciphered while others are in plaintext). These security policies must be stored in entities with adaptivity facilities: updating the security of our system is a key point when an attack is detected. That is the reason why Block RAMs where used: these memory units are easily configurable through a dual-port interface with a dedicated processor. Each firewall (Figure 3) is mainly based on three components:

• Firewall Interface: Communication between the system bus (based on the ARM AXI standard) and the associated IP (custom IP, I/O controller, memory controller): synchronization of handshake signals with datapathrelated values. This task is performed by the Firewall Interface.

• Reading Module: Reading security policies defined in on-chip Block RAMs and extracting the parameters. This is done by the Reading Module. • Firewall Interface: Once parameters were extracted, their values are compared with some signals of the AXI communication bus. The Checking Module computes a value indicating the validity of bus values from these comparisons and transmits it to the Firewall Interface which blocks or not the datapath within the firewall. In case of attack, read and write access are blocked: if the current request is a write, the firewall simulates the correctness of a write request using handshake signals of the AXI bus standard; in case of read, malicious data is blocked and the firewall sends an error code to the required host processor.

B. Security policies storage

A 16Kb Block RAM (with 32-bit ports) is attached to each firewall (Local and Cryptographic) for SPs (Security Policies) storage. Local Firewall SPs are stored on a single 32-bit block while Cryptographic Firewall SPs are stored on 6 32-bit blocks (LF and CF in Figure 4). Each block is indexed by an address (for instance, address 0) which helps the Reading Module to know where to read the first block of the target Security Policy. In case of reading a Cryptographic Firewall Security Policy, a few logic is added to the Reading Module in order to read all the SP blocks only knowing the address of the first block.

Figure 4 shows a layout of Block RAMs containing Security Policies for Local and Cryptographic firewalls. As BRAMs data ports are 32-bit wide, a Security Policy for a LF is read in 1 clock cycle instead of 6 cycles for a Cryptographic Firewall SP. Each firewall has its own Block RAM separated from cryptography-related memories (Section V-D).

The structure of fields labeled as #1, #2, #3, #4 and #5 is described in Table I. For confidentiality and authentication, related bits allow to correctly connect data ports to the AES-GCM core in order to perform all the needed cryptographic modes (authentication only, plaintext and so on).

C. Security policies update

In case of an attack event, Block RAM contents have to be updated with new SPs through a "trustworthy processor" in order to keep a safe environment for the target MPSoC. Figure 5 presents the solution implemented in this work.

All the components are connected on an AXI-Lite bus (also known as Reconfiguration bus). An attack monitoring IP has a trusted custom bus connected with each firewall: when an attack event is detected, information is sent back to this IP. The trustworthy processor launches the reconfiguration processes on a specific interruption routine from the attack monitoring IP. Depending on the ability of IPs to Critical IPs (for instance, ciphering algorithms implementation) must not reveal any information when an attack event is detected. In that case, critical IPs are isolated from the system (in the error code mode, a fixed designerdefined value is sent instead of the incoming data). For noncritical IPs, an intermediate protection layer is authorized where reading accesses are still allowed but not writing ones. Then, the designer can define a time window where an IP protection mode can be set to a lower security level: in that case, without any attack event detected during a fixed amount of cycles, an IP protection mode can go from "error code" to the initial configuration.

D. Cryptographic services

This work considers that external memories may not be entirely protected in terms of confidentiality and authentication in order to keep a satisfying area/latency overhead. In this approach, memory sections can be in plaintext, protected with confidentiality and authentication or even authentication only: it allows the system designer to protect only the most critical parts of applications. The simplest implementation consists in a combination of a basic AES ciphering algorithm and an hash function (such as MD5 or SHA-2) while muxs and demuxs are used to route signals according to SP parameters related to confidentiality and authentication modes (Cmode and Imode). Unfortunately, this solution has a quite large latency overhead: MD5 computes a hash value in 64 clock cycles while SHA-2 takes 80 cycles to do so. A latency-efficient alternative based on the AES-GCM algorithm [START_REF] Crenne | Configurable memory security in embedded systems[END_REF] is proposed in Figure 6. This work uses an AES function to generate a keystream (with timestamp, address inputs and a cryptographic key read from the Block RAM linked with the Cryptographic Firewall) which is XORed with the plaintext to compute the ciphertext. Then, if authentication is required (depending on Cmode and Imode values), datapath goes through the GHASH authentication function [START_REF] Crenne | Efficient key-dependent message authentication in reconfigurable hardware[END_REF]. Modes routing (confidentiality/authentication, authentication only, plaintext) is done by one mux and one demux. The use of timestamps and data addresses in the keystream generation within AES-GCM ensures protection against replay and relocation attacks. In Figure 6, encryption of a 32-bit data block is done in 10 clock cycles and authentication in 2 clock cycles: using the AES-GCM algorithm, the Cryptographic Firewall is able to perform low-latency cryptographic services.

E. SMPs extensions

Up until now, embedded systems were supposed to embed only one processor, the General Purpose Processor (GPP). Most of current applications require now, high performance systems: that is the reason why MPSoCs embed several processors; such platforms are also known as SMPs (Symmetric Multiprocessor platforms). OSs must manage tasks repartition between all the processors of the architecture. From version 2.2, Linux kernel can be configured to manage SMPs: the kernel does all the tasks repartitions by itself according to the availability of all the processors in the target SMPs. Therefore, for each read/write request, firewalls must be aware of the requesting processor. That is the reason why an ID have to be associated with each transaction between a processor and an IP. The solution proposed in this work is shown in Figure 7. Here, there is a compromise between The option we chose is to transmit an ID to be written within a register of the firewall before the transaction itself. In Figure 7, the 4-bit ID (4 bits can code up to 16 IDs) is written in the IDreg register. Then, the transaction (read or write of a data) is processed by the firewall which takes into account the ID in order to block or not the current transaction. Therefore, in terms of latency, the transaction time is doubled because of the register writing before the transaction itself; on the contrary, the architecture of security enhancements is not more complicated as the only change is done in the firewall: an additional register and a few logic (to process the register value as the ID) is enough to make firewalls SMPs-compliant.

VI. IMPLEMENTATION RESULTS

All the following results have been implemented on a Xilinx ML605 development board including a xc6vlc240t1156-1 Virtex-6 FPGA. This device has around 240,000 logic cells and 15 Mb of Block RAM. First, area and latency overheads of the solution presented in this work are given. Then, some benchmarks are used to study different scenarios overheads for a given case study architecture.

A. Area

First, the idea is to measure the impact of the security enhancements proposed in this work in terms of area. Table II shows the area of a base system composed of a Microblaze processor running at 100 MHz booting a 2.8MB Linux kernel (version 2.631) in a DDR3 external memory connected through an AXI bus. Then, the area of each individual block is given and the overhead is accumulated for each additional block aiming to protect the boot-toruntime flow (between brackets). As it can be seen in Table II, the area overhead of the boot protection part (SHA, DMA transfer and RSA) is mainly due to the hash function (around 27%). Nevertheless, the whole secured flow applied to a single processor architecture occupies around 10% of a Virtex-6 xc6vlx240t FPGA: some IPs, at least cryptographic ones (SHA, RSA) and DMA, are reusable in the system design.

B. Latency

Latency efficiency is measured through the throughput and the boot time overhead of security enhancement blocks. The throughput of the kernel boot part (first half of Table III) is around 65 MB/s. In case DMA is used to copy the kernel from Flash to DDR, the performance overhead is nil: using the memcpy function, the kernel is booted in 280 ms using the classic Xilinx scheme (the corresponding throughput is 10 MB/s). The security-enhanced boot proposed here is faster with a 12.6 MB/s throughput. Regarding the protection of the external memory, the boot time overhead is acceptable (in both confidentiality/integrity and integrity only modes). From an overall point of view, this AES-GCM core is the main bottleneck of the boot-to-runtime flow (throughput is low compared to the secure boot part), this must be improved by enabling pipelining within the AES-GCM function.

C. Benchmark applications

In order to measure the impact of the solution proposed in this work for the runtime protection (i.e. once Linux is booted), some applications from miBench benchmark suite and a set of custom applications such as FFT (Fast Fourier Transform) and CRC (Cycle Redundancy Check) computations have been considered. We consider the following case study: an architecture with a single Microblaze running an embedded Linux has been securely booted using the flow presented in this work. Benchmark applications are stored in a non-volatile memory and have to be copied in the external memory passing through the Cryptographic Firewall CF. For each application, the boot time (i.e. time to copy the application code in the DDR without security enhancement) serves as a reference while three different scenarios are considered: each application is stored in plaintext (PT), with integrity only (I only) or with confidentiality and integrity (C+I) depending on the requirements of the final use of such an application. For all the scenarios, latency

VII. DISCUSSIONS AND SECURITY ANALYSIS

Communication architectures considered in this work are based on buses. Such architectures are made for small scale systems (around 16 processors and 16 IPs). If the firewall approach has to be fitted to large-scale embedded systems (NoCs), there are pros and cons to be considered. Large-scale firewalls have basically the same structure as small-scale firewalls: the main difference is the communication protocol managed by the Firewall Interface; otherwise, firewalls behavior is unchanged (it is assumed all the information needed for communication analysis can be extracted). The main bottleneck is at the architecture level: Local Firewalls do not imply a considerable area overhead. The drawback is due to the number of connections of a firewall each time an IP is instantiated:

• A bus connection for the reconfiguration process.

• Another bus connection for the system bus (dealing with the GPP). • A custom bus connection (for monitoring purposes). Number of connections increases with the number of firewalls. At a certain point, custom bus must be managed by an arbiter to decide which firewall has the priority on each other in order to avoid deadlocks and denials of service. In this work small-scale systems are targeted, the proposed protection mechanisms through Local and Cryptographic Firewalls allows the system to be protected against the threat model defined in Section II. With the flexible DDR ciphering approach where some parts of the external memory can be ciphered while other are in plaintext, the only security breach should be in these "unprotected" memory. An attacker can read or write in plaintext memory to create malicious code/data: as soon as malicious contents go through a firewall (Local or Cryptographic), read/write rights, format and address memory map validity are checked. Therefore, the only real breach of the solution presented in this work is an attacker reading plaintext memory sections: it is assumed that such contents were defined by the designer (according to system requirements) as minor information we do not care about if they are disclosed.

VIII. CONCLUSION AND PERSPECTIVES

This paper proposes a solution for a secure boot-toruntime flow of a MPSoC system running an embedded Linux OS. This solution has several advantages: first, thanks to the RSA core, this system is flexible from a software point of view as the OS kernel can be updated without changing the bitstream. Then, on runtime, a low-latency DDR memory protection is given to protect applications with flexible confidentiality and integrity (address space granularity) providing a good area/latency overhead for embedded systems requirements (instead of ciphering the whole external memory). The AES-GCM used for this purpose could also be used for the kernel boot: it would noticeably decrease the area overhead of the solution proposed in this work. As for the Linux kernel, firewalls security policies can be easily updated through a dedicated interface if an attack is detected.

Fig. 1 .

 1 Fig. 1. Flexible boot of an embedded Linux

Fig. 2 .

 2 Fig. 2. Protection enhancements of the external memory

Fig. 3 .

 3 Fig. 3. Security-enhanced generic MPSoC architecture

# 3 : 3 Fig. 4 .

 334 Fig. 4. Security Policy memory layout for Local and Cryptographic Firewalls

Fig. 5 .

 5 Fig. 5. Architecture of the reconfiguration/monitoring area

Fig. 6 .

 6 Fig. 6. Cryptographic core based on AES-GCM algorithm

Fig. 7 .

 7 Fig. 7. SMPs extension for firewalls

ACKNOWLEDGMENT

The work presented in this paper was realized in the frame of the SecReSoC project number ANR-09-SEGI-013, supported by a grant of the French National Research Agency (ANR).


Pascal Cotret

Jérémie Crenne
email: jeremie.crenne@lirmm.fr

Guy Gogniat

Jean-Philippe Diguet

Bus-based MPSoC security through communication protection: A latency-efficient alternative

Keywords: communication, security, MPSoC, bus, cryptography, external memory, firewall, latency

Security in MPSoC is gaining an increasing attention since several years. Digital convergence is one of the numerous reasons explaining such a focus on embedded systems as much sensitive and secret data are now stored, manipulated and exchanged in these systems. Most solutions are currently built at the software level; we believe hardware enhancements also play a major role in system protection. One strategic point is the communication layer as all data goes through it. Monitoring and controlling communications enable to fend off attacks before system corruption. In this work, we propose an efficient solution with several hardware enhancements to secure data exchanges in a bus-based MPSoC. Our approach relies on low complexity distributed firewalls connected to all critical IPs of the system. Designers can deploy different security policies (access right, data format, authentication, confidentiality) in order to protect the system in a flexible way. To illustrate the benefit of such a solution, implementations are discussed for different MPSoCs implemented on Xilinx Virtex-6 FPGAs. Results demonstrate a reduction up to 33% in terms of latency overhead compared to existing efforts.

I. INTRODUCTION

In daily life as in many industrial environments, electronic devices (smartphones, computers...) manage numerous information that must be protected from potential attackers. These devices generally perform high-performance algorithms in a single chip while manipulating sensitive data (passwords, private information). For these systems, a trade-off between area, latency and memory consumption is mandatory when building security mechanisms to meet implementation requirements while guaranteeing an efficient protection against attacks. Reconfigurable technologies such as FPGAs can be a good candidate to build such systems as they embed processors, memories and application-specific IPs in a single chip with moderate development costs [START_REF] Badrignans | Security trends for fpgas[END_REF]. A way to reduce the performance impact of security mechanisms is to consider hardware solutions and to develop a distributed protection [START_REF] Cotret | Distributed security for communications and memories in a multiprocessor architecture[END_REF]. One strategic point is the on-chip communication architecture as all data is exposed to its structure. Thus it is of paramount importance to protect these data exchanges in order to keep critical information within the system. Indeed many attacks can be detected through a thorough monitoring of data exchanges within the system. The goal of this work is to propose a solution based on security-enhanced interfaces between IPs in a MPSoC implemented on a FPGA technology.

The paper is organized as follows. Section II presents related work. Section III details the threat model. Section IV describes our contribution and Section V proposes several results. Section VI highlights main perspectives.

II. RELATED WORK

In the literature, several studies have addressed the security of embedded systems [START_REF] Ravi | Security in embedded systems: Design challenges[END_REF]. At the communication level, these systems can be protected either by software or hardware mechanisms. Software solutions generally do not request additional hardware but offer low efficiency in terms of latency which can be critical for applications where reactivity is essential to fend off attacks. From an hardware point of view, several solutions have been proposed depending on the communication architecture: network-on-chip (NoC) or bus. Regarding NoC-based architectures, Evain et al. [START_REF] Diguet | Noccentric security of reconfigurable soc[END_REF] propose a solution where security controls are done in each network interface in a distributed manner. A management unit gathers all information from network interfaces according to a userdefined security policy. Fiorin et al. [START_REF] Fiorin | A monitoring system for nocs[END_REF] propose an alternative to this work by adding probes within the interface structure to refine the protection mechanisms. Each security-enhanced interface, considered as a trusted component, is composed by a set of probes, protection units and a kernel providing network management services. These probes can block incoming traffic according to parameters stored in an embedded context-addressable memory. A security manager collects information from individual security-enhanced interfaces to detect any collision or error in the traffic. For bus-based communication architectures, one of the most significant work was done by Coburn et al. [START_REF] Coburn | Seca: security-enhanced communication architecture[END_REF]. This approach is similar to Fiorin's work and is based on SEI (Security Enforcement Interface) implemented in each interface between an IP and the bus. Each SEI computes information from the data handled by the IP and sends it to a global manager (SEM, Security Enforcement Module). The main limitation of this solution is that all controls are performed in the SEM. It leads to a latency penalty which should be avoided to mitigate security overhead. Other works provide solutions for the protection of embedded systems: Huffmire et al. [START_REF] Huffmire | Moats and drawbridges: An isolation primitive for reconfigurable hardware based systems[END_REF] introduce the approach of physi- cal isolation using moats and drawbridges; ARM proposes a commercial architecture name Trustzone [START_REF] Yan-Ling | Design and implementation of secure embedded systems based on trustzone[END_REF] which is based on a normal/secure separation using a secure kernel and an access driver. This work is an in-depth description and implementation study of the solution introduced in [START_REF] Cotret | Distributed security for communications and memories in a multiprocessor architecture[END_REF]. It takes advantages of both NoC/bus-based approaches by proposing hardware security enhancements distributed on each IP with low-latency control features. This approach targets bus-based MPSoCs where a limited number of IPs are connected together. Our solution aims to be a latency-efficient protection mechanism with an additional cryptographic layer for protection of external memory units (see Table I). Our solution only relies on hardware enhancements (LF and CF as will be explained in Section IV) and does not require modification at the application level neither in the operating system. Compared to existing efforts, we address a wide range of software attacks through a distributed approach and handle cryptographic features to deal with confidentiality and authentication.

The key contributions of this paper include:

• Design and demonstration of dedicated firewalls.

• Promotion of flexible security policy (access right, data format, authentication, confidentiality).

• Development of several applications to analyze security overheads.

III. THREAT MODEL

A. Attack vectors

This work considers that attackers can only tamper with the embedded system using logical attacks (side-channel and other physical threats are not considered). Besides that, it is assumed that the target FPGA is trusted. Therefore, the only way to access the system is through the external memory and the external bus (Figure 1). A solution would be to encrypt and authenticate the whole external memory. Unfortunately, this solution has a high cost in terms of resources consumption and latency overhead [START_REF] Vaslin | Memory security management for reconfigurable embedded systems[END_REF]. For many applications, building a flexible solution where only the most critical code and/or data sections to be stored in the external memory are protected with cryptographic services is a good choice. Other parts of the memory can be in plaintext or only authenticated [START_REF] Crenne | Configurable memory security in embedded systems[END_REF]. In this case, attackers still have possibilities to compromise the system by tampering non protected parts of the external memory. Indeed, when code and/or data are protected, any change will be detected; but if code and/or data are considered uncritical, no check is performed. Thus, such solutions need to be extended and system designers need other mechanisms to monitor system activity and detect any abnormal behavior. This work proposes to address this point. All communications are checked by security mechanisms mentioned further as firewalls. This additional layer of security provides an efficient solution while maintaining a good area/latency trade-off.

B. Security policies

Security enhancements presented in this work are based on built-in Security Policies (SP) stored in trusted memory units which include a set of parameters required for abnormal behavior detection (see Section IV-D). Basically, it contains read/write access specifications (read/write, writeonly, read-only), authorized data format (i.e. 8, 16 and 32 bits) and cryptographic information (confidentiality/authentication modes, encryption key and MAC). Threat model defined in [START_REF] Cotret | Distributed security for communications and memories in a multiprocessor architecture[END_REF] is covered using these parameters. Timestamp tags are used to monitor the access time to the external memory (to detect replay attacks). Spoofing and relocation attacks are also addressed (using address and authentication primitives).

IV. HARDWARE FIREWALLS

In order to prevent any MPSoC system from the threat model previously defined, firewalls are implemented within the system. This section first presents an overview of these blocks. Then a detailed analysis of their architecture from an hardware point of view with latency and memory requirement information is proposed. The target system is composed of processors, internal memories, dedicated IPs embedded within an FPGA and connected to an external memory. All resources within the FPGA are connected to a bus based on the AXI communication standard from ARM. We propose to add a specific interface to each resource (IP or processor) in order to build a secure gateway to the bus. Using these interfaces (also known as firewalls in this work), we can monitor all communications before they reach the bus and propagate within the system. Figure 1 shows such a system with internal resources and an external memory. Each resource is connected to a specific interface called Local Firewall providing services for read/write access control and so on. The external memory is also connected to a specific interface called Cryptographic Firewall adding cryptographic features (confidentiality, authentication...). As security parameters can be applied only to specific parts of IPs (defined through security policies), firewalls are also responsible for filtering access to/from the external memory. This feature is of paramount importance when plaintext data or code (which may not have been ciphered) is manipulated. In this case, even processors executing malicious code (that could have been stored in plaintext in the external memory) can be blocked by firewalls. Any illegal read or write access will be detected and discarded. Security Policies are stored in Block RAMs (memory blocks embedded within the FPGA) which are considered as trusted (no attack is taken into account).

A. Overview of the solution

Mem. ctrl

B. Common blocks

Each firewall is composed of several blocks (such as Security Builder and Firewall Interface) connected to each others (Figure 2). While Security Builder is the core managing security policies, Firewall Interface is the crossing point with the external world. It acts as a bridge between the system AXI-4 communication bus and the associated IP (custom IP, I/O controller, external memory controller). The whole firewall structure is considered as trusted, the only untrusted area is the external bus and the external memory itself (i.e. everything beyond the external memory controller). • Once a data is declared as valid, the FI transmits the data to the target element (communication bus or IP), it is performed by the Decision Module.

• The FI synchronizes handshake communication signals (such as AXI WSTRB, AXI WLAST, AXI WVALID, AXI RREADY...) in order not to misbehave communication traffic (duplication or omission of data). Synchronization Module is based on a set of flip-flops where the clock input signal (i.e. a rising edge) is the acknowledgment signal check out sent by the Security Builder when all the SP-checking operations are completed. As all these flip-flops are connected in parallel, the latency of Firewall Interface is two clock cycles for a 32-bit data (one for the Decision Module and one for the synchronization). For N 32-bit data (without burst or pipeline management), the equation is:

latency(N )=N * 2.
(

) 1
In case pipeline is activated (not yet considered in this work), the equation for an m-stage pipeline architecture becomes latency(N )=m + N -1. Firewall Interface would need 2 cycles for the first data and 1 cycle for each following data (while data n is processed by the Synchronization Module, data n+1 is processed by the Decision Module).

2) Security Builder: Security Builder is the main component of firewalls (tagged 2 in Figure 2). It is based on four modules:

• Correspondence Table (CorrTable). Security Policies
are stored in a trusted Block RAM (left side of Figure 2) and can be identified by an address. CorrTable defines the SP address for a given bus target address space in 1 clock cycle. For instance, bus address 0x1234ABCD (in the address space [0x12340000;0x1234FFFF]) is managed by the Security Policy located at BRAM address 0xFF00FF00. The correspondence between these addresses will be performed in the CorrTable module.

• Reading Module (ReadMod). ReadMod is responsible for reading the Security Policy from the dedicated Block RAM and extracting the security parameters to be sent to the Checking Module. For a single 32-bit data, a read buffer is filled in 1 clock cycle then SP parameters extraction (to be sent to the Checking Module) requires 1 additional cycle.

• Checking Module (CheckMod). In fact, the Checking Module is a set of individual comparators specific to each security parameter (read/write, format...) defined in the Security Policies and computed in parallel (Figure 3). Inverters allow the output to be an overall flag. If The solution presented in this work provides flexible cryptographic services based on the AES-GCM algorithm [START_REF] Mcgrew | The security and performance of the galois/counter mode (gcm) of operation[END_REF]. As shown in Figure 5, a single core has been developed to perform "confidentiality and authentication" or "authentication only" (mux and demux ports are routed according to Security Policy parameters related to confidentiality and authentication modes Cmode and Imode); keys needed for encryption/decryption are sent by the Security Builder (as for MAC information). In Figure 5, encryption of a 32-bit data (E k uses a 128-bit key and a 128-bit vector containing the 32-bit data padded with zeros), is done in 10 clock cycles and authentication is done in 2 clock cycles (through 2 multipliers mult H [START_REF] Crenne | Configurable memory security in embedded systems[END_REF]). The overall latency for a set of N 32-bit data protected by confidentiality and authentication is:

latency(N ) = 10 + (10 + 2) * N (3)
Using the AES-GCM algorithm, firewalls can perform lowlatency cryptographic features with an acceptable resources consumption. Especially for authentication, AES-GCM takes 2 clock cycles while implementation of hash functions such as MD5 (respectively SHA-2) takes 64 (respectively 80) cycles to do so. The tag issued from the AES-GCM core is not ciphered since it is stored in a trusted embedded memory (Block RAM) separated from the SP memory. As Block RAMs are dual-port memories, one port is left empty for further reconfiguration by a dedicated processor.

D. Security Policies

Each firewall (Local and Cryptographic) has its own 16KB Block RAM containing Security Policies directly connected to the Reading Module. Security Policies are indexed by the Correspondence Table previously defined. Local Firewall SP is stored on a single 32-bit block while Cryptographic Firewall SP is stored on 6 blocks (LF and CF in Figure 6). Each block is indexed by an address (for instance, address 0) which helps the Reading Module to know where to read the first block of the target Security Policy. In case of reading a Cryptographic Firewall Security Policy, a few logic is added to the Reading Module in order to read all the SP blocks only knowing the address of the first block. Figure 6 shows a layout of Block RAMs containing Security bits allow to correctly connect data ports to the AES-GCM core in order to perform all the needed cryptographic modes (authentication only, plaintext and so on).

V. R ESULTS All the following results have been implemented on a ML605 Xilinx board including a Virtex-6 xc6vlx240t1156-1 FPGA. This device has around 240,000 logic cells and 15 Mb of Block RAM. First, performances of firewalls are given as standalone blocks. Then, case studies are proposed to verify performances of such security enhancements and compare their efficiency to existing efforts.

A. Standalone results

Area: All the measures were compared to the Xilinx Microblaze softcore processor (default configuration with 8KB data and instructions caches). Each firewall (Local and Cryptographic) is implemented with two dummy security policies. A Local Firewall has low area consumption while Cryptographic Firewall exceeds Microblaze results. This is mainly due to CM (the AES-GCM core) which consumes around 90% of the CF area (see Table III). Otherwise, firewalls are lightweight in terms of consumed area compared to the Microblaze microprocessor (in terms of registers, a Local Firewall takes around 10% of resources needed for a Microblaze processor).

Once we know the resources needed for each firewall, a set of rules can be defined to estimate the area needed for a multiprocessor architecture with x Local and y Crypto Firewalls. Following equations set takes into account the "worst case" implementation values with 10 SPs for each Correspondence Table (

Latency:

In order to measure the latency of firewalls, simulations were done to generate the following scenarios:

• S0: Latency of a Local Firewall.

• S1: Communication between two on-chip components.

• S2: Communication between a processor and the external memory in C+A mode.

• S3: Communication between a processor and the external memory in Authentication only mode.

• S4: Communication between a processor and the external memory in plaintext mode. Each scenario was run for a single 32-bit data: S0 is a reference measure, others scenarios involve two components of a firewall-enhanced MPSoC architecture (S2 to S4 involve one Local and one Crypto Firewall while S1 needs two Local Firewalls). Figure 7 shows the results of these implementations. Of course, the most critical scenario in terms of latency (28 cycles) is when a data is written in the external memory in S2 (in case of a read, the penalty is not so high). S1 and S4 are quite close because, in this implementation, there is no Checking Module (1 cycle saved) in a CF and reading a Cryptographic SP takes 5 more cycles than for Local Firewall: therefore, S4 takes 4 more cycles than S1.

Memory occupancy: In this section, only Security Policies are considered. Timestamps and Tags (MACs) memories occupancies are not considered as they depend on the number of data required by Figure 7. Latency scenarios the application [START_REF] Vaslin | Memory security management for reconfigurable embedded systems[END_REF]. According to the formulation of Security Policies, a single policy for a Local Firewall takes 4 Bytes (24 Bytes for a CF because of cryptographic material). Two options are considered in this work:

• Each CPU has uniform rights on other IPs: for instance, 1 CPU can write the whole DDR memory in plaintext mode. This case can be represented by one Security Policy.

• Each CPU has N "options" on each target IP: in this case, for example, 1 processor can read a plaintext address space of the external memory and write a ciphered and authenticated data in another address space (see Figure 1). Several Security Policies are used in this option.

The second option is a generalization of a basic implementation. The more instances of SPs we have for each component of an architecture, the more memory is needed. Figure 8 shows the number of bytes consumed for N IPs (X axis) over M Security Policies. For a fixed number of IPs, memory The case study is based on a dual-processor architecture (Xilinx Microblaze softcores with 8KB data and instruction caches). There are two IPs: "Shared Memory" is a shared Block RAM of 64 KB and Hard. Acc. is an image processing IP (threshold function) with a set of registers (Figure 9). The external memory contains data and code sections for both processors. This work considers that external memory is split in five parts (64KBytes each): two parts for processor #1 (code and data) and three sections for processor #2 (code and two data sections, with different cryptographic policies). Contents can be either protected by confidentiality and authentication (C11 and D11), authentication only (D12) or even plaintext (C2 and D2). Each processor also has specific access to the two internal IPs (in terms of Read/Write access context): for Hard. Acc., MB 1 can read and write while MB 2 can only write; for Shared BRAM, MB 1 can only read, MB 2 read and write.

2) Benchmark application: In order to set up this system as a base for further analysis, an application was defined to make all key situations happen (accesses to the external memory, internal communications and so on). This benchmark application, represented by the sequence diagram in Figure 10, is based on a symbolic JPEG file (previously ciphered and written in the external memory by a configuration processor) which is processed and transmitted from one block to another. According to the former hardware description, the external memory contents are split in different sections with several Security Policy instances. When the case study is implemented with security enhancements, the area consumption is around 40% higher than the unprotected version (nearly 46% for LUTs in Table IV).

Table V shows latency overheads for a couple of applications: • picProc is the application described in the sequence diagram.

• picDrm is a sample DRM application run by one processor while the other processor does read/write operations.

• picDec is a classic software AES decryption done by one processor which also accesses the external memory. picProc is the largest application (in terms of code size): as there are more accesses to the external memory, the penalty induced by firewalls is higher.

C. Case study #2: other platforms

We also evaluated our solution for two platforms. The first one is the NEC's MP21x application SoC, also studied by Coburn et al. [START_REF] Coburn | Seca: security-enhanced communication architecture[END_REF]. Figure 11 shows a simplified view of this system. There are 3 ARM 926 CPUs, a cryptoprocessor able to run several algorithms (RSA, AES and so on). NEC MP21x platform also has Security Policies (as it has been defined in previous sections). For this case study, it is considered that each CPU has uniform rights on other IPs (for instance, 1 CPU has only one set of rights on the cryptoprocessor). The second platform is the Samsung Exynos 4210 SoC based on a dual-core ARM Cortex A9 platform used, for instance, in smartphones such as the Galaxy SII (from Samsung). It also has secure memory blocks, video peripherals and a cryptographic engine.

1) Area: According to the NEC platform schematic, we consider that SDRAM and Flash are critical memory units 2) Memory occupancy: We consider that in a MPSoC system, each IP needs only 1 Security Policy. To calculate the equation giving the memory occupancy for x LF and y CF, it is assumed that:

• Each IP attached to a LF has access to all other IPs of the system (including external memories). There are x + y IPs in the system, an IP cannot interact on itself and each LF security policy takes 32 bits. Therefore, total memory occupancy of LFs follows the equation (x + y -1) * 32x.

• Each IP attached to a LF has access to the external memory (in this case, each IP needs 1 Security Policy).

In the external memory mapping, there is an address space for each IP, each address space is managed by a 192-bits CF security policy. Memory occupancy of a Cryptographic Firewall is governed by the equation 192x (192xy if y CF in the system). The evolution of memory occupancy for NEC and Samsung platforms follows the surface equation 32x 2 + 224xy -32x. Even with a high protection granularity (20 Security Policies for each IP), SP memory occupancy costs are quite acceptable (864 Bytes for Samsung Exynos 4210 platform and 360 Bytes for NEC MP21x). In this analysis, tags storage is not considered and this point can significantly increase the memory overhead if a uniform security policy is considered [START_REF] Vaslin | Memory security management for reconfigurable embedded systems[END_REF].

D. Comparison over existing works

A comparison with related works is done in terms of area overheads. The area results for our work does not take into account the Cryptographic Module because Coburn [START_REF] Coburn | Seca: security-enhanced communication architecture[END_REF] and Fiorin [START_REF] Fiorin | A monitoring system for nocs[END_REF] do not have ciphering features in their solutions. Xilinx Microblaze processor was taken as a reference for VII, our solution has a ratio lower than the Data Protection Unit system [START_REF] Fiorin | A monitoring system for nocs[END_REF]: this may be due to the CAM system which is more complex than a Block RAM. SECA-based solution has a lower impact because the kernel (containing security configurations) is not included in this estimation while security policies stored in firewall BRAMs are taken into account in this analysis.

In order to compare our solution to a centralized approach like SECA where controls are done in the manager entity, it is assumed that each transfer requires 4 more cycles (a normal transfer on AXI bus takes 2 clock cycles [START_REF] Chang | Analysis of sharedlink AXI[END_REF]): it represents the latency to communicate between a firewall and the security manager of the system. Therefore, giving the picDec application defined in Section V-B, a centralized implementation like SECA would give a 6.27% latency overhead while our solution has a 4.18% overhead: it represents a 33% latency decrease.

VI. CONCLUSION AND PERSPECTIVES

This work proposes distributed and flexible security enhancements for bus-based MPSoC that embed protection mechanisms where existing solutions are mainly centralized (which involves additional latency overhead for communication between security elements). Our solution low latency overheads and can be further improved by pipelining data management. In terms of area, LF and CF have low resources consumption: the major penalty is due to the AES-GCM core. Our solution is a layer above the communication protocol as our security enhancements do not modify the communication protocol between the processors and the other parts of the system. We plan to integrate reconfiguration of security services (i.e. modification of security policies) to counter some attacks against the system: this could be done quite easily because Block RAMs containing Security Policies have one data port left for a reconfiguration processor (it raises other issues such as firewall behavior during reconfiguration of SPs). In this work, policies are defined using address domains, it can be interesting to study the adaptation to thread-specific security where each thread has its own security policy. Finally, there is the question of scalability: a single-layer bus allows around 32 IPs; we can imagine to study benefits of firewall implementations on a multi-layer bus or a network-on-chip.

  2012 IEEE 20th International Symposium on Field-Programmable Custom Computing Machines 978-0-7695-4699-5/12 $26.00 © 2012 IEEE DOI 10.1109/FCCM.2012.42

Figure 1 .

 1 Figure 1. Embedded distributed architecture with security enhancements

1 Figure 2 .

 12 Figure 2. Structure of a firewall 1) Firewall Interface: Firewall Interface is tagged 1 in Figure 2. Two main tasks are performed by a Firewall Interface (FI):

Figure 3 .

 3 Figure 3. Checking module

Figure 4 . 2 )Figure 5 .

 425 Figure 4. Security Builder timing diagram

Figure 6 .

 6 Figure 6. SP memory layout for Local and Cryptographic Firewalls

Figure 8 .

 8 Figure 8. Memory occupancy

Figure 9 .

 9 Figure 9. Case study architecture

Figure 10 .

 10 Figure 10. Benchmark sequence diagram

  this limit is due to the implementation of the Correspondence Table which needs 3 registers for each security policy while implementation tools allow 32 configurable registers at most for each firewall).Using this equations set, a designer is able to compute the area consumed by security enhancements on his own MPSoC for a fixed number of Security Policies embedded in each firewall. It is important to note that the Correspondence Table area increase regarding the number of SPs is acceptable: from 9 up to 48 slices and 32 up to 117 regarding LUTs (respectively for 1 and 10 SPs).

	numSlices = 138 * x +1, 304 * y	(4)
	numRegs = 123 * x +2, 161 * y	(5)
	numLuts = 293 * x +2, 689 * y	(6)

Table VII ,

 VII individual configurations are indicated between brackets (caches size and clock frequency). In Table

Code MB1 (64 KB) Data MB2 (64 KB) Data MB1 (64 KB) Code MB2 (64 KB) Data MB1 (64 KB)


Lubos Gaspar
email: lubos.gaspar@univ-st-etienne.fr

Florent BERNARD Viktor Fischer
email: fischer@univ-st-etienne.fr

Lilian Bossuet
email: lilian.bossuet@univ-st-etienne.fr

Pascal Cotret
email: pascal.cotret@univ-ubs.fr

HCrypt: A Novel Concept of Crypto-processor with Secured Key Management

Keywords: HCrypt, secured crypto-processor, register separation, key management

The paper presents a novel concept of processor aimed at symmetric-key cryptographic applications. Its architecture is optimized for implementation of common cryptography tasks. The processor has 128-bit separated data and key registers, dedicated instruction set optimized for key generation and management, embedded cipher, and embedded random number generator. From an architectural point of view, the most important characteristic of the proposed crypto-processor is the physical separation of data and key registers and buses, insuring that confidential keys will never leave the system in clear. This way, the processor enables to separate protected and unprotected security zones easily and also achieve complete physical isolation of key management and data zones inside the single FPGA. The first version of the processor implemented in Xilinx Virtex 5 FPGA device achieves the frequency of 160 MHz and it occupies 1343 configurable logic blocks and 21 embedded memory blocks.

I. INTRODUCTION

Hardware cryptographic systems must fulfill contradictory requirements: fast parallel structures implementing computationally extensive cryptographic functions must co-exist with complex sequential structures used to implement cryptographic algorithms such as cipher modes, key management operations and cryptographic protocols. Implementation of cryptographic algorithms and protocols in hardware necessitates employing many complex state machines that make the logic very unstable and vulnerable. Furthermore, upgrades of a hardwired logic can become complicated, long and expensive. Because of this, cryptographic systems based on processor/coprocessor architectures were frequently employed in the past.

The most common solution employed in the past decade consists in the use of a general-purpose processor featuring one or more cryptographic co-processors. This solution permits to implement sequential algorithms (that evolve very frequently as a consequence of attacks and/or algorithm standard modifications) by the processor program, while the tasks that can be executed in parallel are implemented in the co-processor placed inside the same logic device. The biggest part of this research has been devoted to elliptic curve cryptography [START_REF] Sakiyama | Multicore curve-based cryptoprocessor with reconfigurable modular arithmetic logic units over GF (2 n )[END_REF], [START_REF] Machhout | Coupled FPGA/ASIC Implementation of Elliptic Curve Crypto-Processor[END_REF]. A lot of attention has also been given to optimizations in symmetric key cryptography (block cipher coprocessors) [START_REF] Crowe | Single-chip FPGA implementation of a cryptographic co-processor[END_REF], [START_REF] Eslami | An area-efficient universal cryptography processor for smart cards[END_REF]. Combined cryptographic system based on NIOS II processor with ECC, SHA-1, RSA and AES co-processors has been proposed by Hani et al. [START_REF] Hani | Design and implementation of a private and public key crypto processor for next-generation it security applications[END_REF].

Some architectures employ a general-purpose processor that is modified and optimized for implementation of cryptographic algorithms. Wu et al. [START_REF] Wu | CryptoManiac: a fast flexible architecture for secure communication[END_REF] and Pereira et al. [START_REF] Pereira | VLIW Cryptoprocessor: Architecture and Performance in FPGAs[END_REF] used several processors based on Very-Long-Instruction-Word (VLIW) architecture, while profiting from parallelism to some extent. Other way for optimizing execution of cryptographic algorithms is to use a configurable architecture. The most common reconfigurable processors are COBRA [START_REF] Elbirt | An instruction-level distributed processor for symmetric-key cryptography[END_REF], PipeRench [START_REF] Goldstein | PipeRench: a co/processor for streaming multimedia acceleration[END_REF], MorphoSys [START_REF] Singh | MorphoSys: an integrated reconfigurable system for data-parallel and computation-intensive applications[END_REF], GARP [START_REF] Hauser | Garp: A MIPS processor with a reconfigurable coprocessor[END_REF] and Xtensa [START_REF] Gonzalez | Xtensa: A configurable and extensible processor[END_REF].

The use of processors brings a security weakness in all of the above mentioned solutions: the processor manipulates the keys as ordinary data and modification (intentional or unintentional) of the program memory contents can enable reading the keys in clear outside the system. In [START_REF] Ashkenazi | Platform independent overall security architecture in multi-processor system-on-chip integrated circuits for use in mobile phones and handheld devices[END_REF] authors use two processors with different security level and different tasks. They create virtual zones inside a physical memory that is shared by both processors, in order to be able to separate red and black zones dedicated to key and data storage, respectively. The secure specific-purpose processor can access both private (red) and public (black) virtual zones and the general-purpose processor is allowed to access only public (black) virtual zone. However, both zones are located in the same physical memory thus still allowing certain types of remote attacks, such as protocol attacks [START_REF] Anderson | Cryptographic processors -a survey[END_REF].

In order to face protocol attacks and fault injection attacks, we propose a new architectural concept of the cryptoprocessor that allows physical separation of data and key registers and buses. The data flow between the embedded cipher and key and data registers is designed so that the confidential keys generated inside the system will never leave it in clear, even if the processor was subject of a protocol (modification of the program code) or fault injection attack (modification of the data flow).

The paper is organized as follows: Section II introduces application background of the global multi-processor system on chip containing the crypto-processor. Section III presents the novel architecture of the crypto-processor. Section IV describes the implementation of the processor in FPGA. Results are presented in Section V. Section VI discusses the results and Section VII concludes the paper.

II. GENERAL CONTEXT AND COMMUNICATION NEEDS

Embedded systems including Multi-Processor Systems on Chip (MPSoC) are employed increasingly in applications needing higher security levels [START_REF] Kocher | Security as a new dimension in embedded system design[END_REF], [START_REF] Ravi | Security in embedded systems: Design challenges[END_REF]. The cryptoprocessor described in this paper is proposed as a construction element of such a Secured Multi-Processor System-on-Chip (MPSoC). This system is studied with the objective of improving the security shield of reconfigurable technologies such as FPGAs at logical, architectural and system levels.

A. Architecture of the System

It is supposed that the proposed MPSoC will contain at least three types of processors (see Fig. 1): one or more general-purpose application processors, one or more cryptoprocessors and one security processor responsible for reconfiguration of the system. Besides processors, the system will include internal and external memories and one or more data interfaces such as Ethernet, USB, serial interface, etc. The architecture should be modular and sufficiently general in order to fulfill various security and performance requirements in numerous applications such as Set-top boxes, software radios, security video systems etc..

B. Communication Protocol

In order to maintain high order of modularity and connectivity to external networks, the embedded processors are supposed to communicate between them using network protocol and packets. The crypto-processor is responsible for ciphering (or deciphering) internal and external data frames coming via the communication ports. The ports for plaintext and ciphertext packets are separated.

III. HCRYPT: A NOVEL CONCEPT OF CRYPTO-PROCESSORS

Next, we will describe our novel concept of a secure crypto-processor called HCrypt.

A. Processor Structure and Data Flow

General principle of the processor is illustrated in Fig. 2. Dedicated architecture is composed of two sets of registers and buses: common data register set connected to common data bus and dedicated key data register set connected to dedicated key data bus.

The keys are saved in clear in key data registers. When reading the key from a key register, the key data is enciphered before being saved in general-purpose data registers. In the same way, key blocks manipulated as cipher-text are deciphered before being saved in the key memory. This way, the key data can never leave the processor in clear (even by modifying anyhow the program of the processor). Session key management is illustrated in the Fig. 3.

The key data memory is a true dual port memory. In this memory, the keys are accessible as data using one bi-directional port for reading and writing after ciphering/deciphering (as mentioned before), but also as effective encryption/authentication keys (in clear) during encryption/decryption process via one dedicated one-directional port. Note that this second port is independent from the data buses (common or key data bus).

At least, two session keys and master keys are available in the proposed processor: one for data (and key) enciphering/deciphering and one for data (and key) authentication. While manipulating ordinary data, the session keys will be used. When manipulating the session keys, the master keys will be used.

The processor contains a true-random number generator that is used to generate session keys. Note that before saving the key to the key data registers, the generated random data is post-processed by deciphering the generated block using a master key.

The processor contains also two blocks guaranteeing the flexibility: the program memory block and the cipher/decipher block. The contents of the program memory could be eventually changed using the security processor from Section II that is responsible for the system reconfiguration. We recall that the cipher/decipher is considered as a black box in this architecture and that it does not have a direct impact on the control logic and the data flow. The processor can thus use any encryption/decryption algorithm, with selected side-channel attack countermeasures.

B. Instruction Set

Besides common instructions, the instruction set takes advantage of the processor specific structure. Namely, it uses different instructions for handling ordinary data and keys. Also, arithmetic and logic instructions are optimized for implementing common cryptographic functions and modes.

The instruction set is be divided into four main groups:

. . . Session key reg.

R2

Instructions entry

Master key reg.

Data inputs (32 bit)

Data outputs (32 bit)

Figure 2: Concept of HCrypt

• Instructions for key generation and transport between ordinary data registers and key data registers

• Data processing instructions: optimized for implementation of cipher modes and key management

• Control instructions: aimed at the program control (branching) The proposed instruction set with respect to this grouping is shown in Tab. I.

C. Assembler -Compiler

Complex instruction set makes writing programs in machine code more difficult. Long machine code is only hardly readable. In order to address this issue, we developed a processor-specific assembler (compiler) tool. In the case of the processor in development, frequent changes in hardware architecture (changes in instruction set) impose frequent

LEGEND

Data bus

Cipher key access Key transport bus

Data registers

Session key reg.

Master key reg.

D. Examples of Execution of Basic Modes

The operation of the processor can be illustrated on the program examples in Tab. II that realize various basic encryption modes. In this table, PTI means plaintext input, PTO plaintext output, CTI ciphertext input and CTO ciphertext output.

1) CBC Encryption Block Cipher Mode Example:

The code illustrated in Tab. II (part A) enables to encrypt the packet consisting of N 128-bit data blocks (N is given in the first data block in the packet) in the CBC mode (see NIST SP 800-38A, p. 10 [17]).

2) CFB Encryption Block Cipher Mode Example:

The code illustrated in Tab. II (part B) enables to generate the session key that is then used to encrypt the packet consisting of N 128-bit data blocks (N is given in the first data block in the packet) in the CFB mode (see NIST SP 800-38A, p. 12 [START_REF] Dworkin | NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation-Methods and Techniques[END_REF]).

IV. IMPLEMENTATION OF HCRYPT

A. Specifications

As previously mentioned, the objective is to physically separate registers and buses carrying keys from those carrying data. For this reason, two sets of registers are implemented, so that keys and data are stored separately. In order to achieve higher performance, the processor has a 128-bit datapath.

HCrypt exchanges data with external/internal environment using input/output FIFOs. The processor is able to implement a serial communication protocol using packets. It permits to analyze and create packets efficiently. Data processing operations needed for implementation of cipher modes are carried out in a special-purpose arithmetic logic unit (ALU) that constitutes an important part of the processor.

For security reasons, the key lifetime should be limited (the same key should be used only for a limited amount of data). One of adopted solutions is to use two hierarchical key levels: master keys and session keys. The session keys are used to encrypt data and they are generated inside the system. In order to enable data decryption, the session key has to be exchanged with the communication party. It is therefore encrypted by the master key (shared with the party) and sent together with encrypted data. In order to generate keys inside the system, true random number generator (TRNG) is embedded in the processor. Although the cipher/decipher blocks should be included in the processor's datapath, they are considered as black boxes in our project. We used AES cipher and decipher for testing purposes.

B. Design of the HCrypt Processor

The crypto-processor consists of the following parts: Key data bus and key data registers for the key management are shown in Fig. 2. The Master key (aimed at Session key encryption/decryption) is stored in the Master key register. This register is capable of storing two 128-bit keys: one for encryption and one for decryption. This register is implemented in the logic area of the FPGA. Before the operation, the master key has to be transferred to the cryptoprocessor via a 32-bit separated data bus by the Security processor from Session II.

Session key registers are implemented using two 128bit dual-port RAM blocks. Session keys can be generated inside the processor using embedded TRNG or they can be received by the crypto-processor in an encrypted form and subsequently decrypted using the master key. If generated inside the processor, the session key has to be encrypted using a master key and sent out according to the protocol.

Note that multiplexers included in the datapath are organized in such a way, that unintentional or intentional transfers of unencrypted keys outside the crypto-processor would never be possible.

The cipher and decipher blocks that implement the AES encryption algorithm in their current version, are connected to the processor from outside. The keys and data are transported to them by two separate 128-bit buses. Encrypted/decrypted data are registered in cipher/decipher blocks in 128-bit registers accessible by the processor.

This first version of the datapath is partially optimized for the Xilinx Virtex 5 FPGA. In the future, further optimizations will be carried out and authentication will be implemented. In addition, the crypto-processor will be optimized for other FPGA technologies as well.

2) Control Logic: The first version of the control logic is responsible for instruction fetching, decoding and execution. Instructions are carried out in 2, 3, 6 or more clock cycles, depending on the type and complexity of the operation. The pipelining is not implemented. However, it is supposed to be implemented in the future. Instructions are 32-bit wide. Current instruction set consists of 32 instructions.

The program is stored in the program memory that is initialized by an external 32-bit interface. The program memory is implemented as one dual port RAM block capable of storing 1024 instructions. The program memory can be expanded if necessary (by concatenating two or more memory blocks).

3) Input/Output FIFOs: There are four input/output FI-FOs in the current version of the processor. They serve as input/output data ports, which convert 32-bit data words into 128-bit words used inside the crypto-processor and vice versa. Additionally, the FIFOs allow interfacing external clock domains with the internal clock domain of cryptoprocessor.

V. RESULTS

HCrypt was described in VHDL language using Xilinx ISE Web ver. 11.1 and implemented in Xilinx Virtex 5 XC5VLX110T FPGA. System utilizes just fine-grain FPGA The crypto-processor was then tested in Virtex 5 XC5VLX110T FPGA using the XUPII development board. In the first stage of tests, the processor was initialized by the master key and the program. Afterwards, data packets were written into the input plain-text FIFO. Next, the cryptoprocessor carried out encryption in the CFB128 AES encryption mode and the resulting packets were written to the ciphertext output FIFO. A stable operation has been achieved at the clock frequency up to 160 MHz, thus confirming estimations.

Assembler compiler tool with configurable instruction set was also developed. Various short programs were written for testing purposes. Assembler was tested by compiling source code for HCrypt. No compilation errors were observed.

VI. DISCUSSION

The main difficulty concerning the portability of the proposed VHDL code concerns embedded memory employment. As mentioned above, current processor was mapped to Xilinx Virtex 5 device where each true dual port memory block has two 32-bit input and output ports. However, in Altera Stratix III FPGA each true dual port memory block has two 16-bit input and output ports, thus twice more memory blocks have to be instantiated in order to maintain the same width of the datapath (128-bit). Moreover, when adapting to Actel Fusion or SmartFusion devices, where each embedded true dual port memory block has two 8bit input and output ports, 16 memory block have to be instantiated to maintain the same width of the datapath.

It has been observed that current cipher and decipher blocks constitute the longest critical path, therefore optimization of the cipher can result in better performance. Some long critical paths were also reported in the ALU, thus this part has to be optimized in the future as well.

Resource distribution report showed that the most logic resources are dedicated to ALU. On the contrary, the most embedded RAM blocks were used for Input/Output FIFO instantiations, in order to interconnect 32-bit external buses with 128-bit internal datapath with different clocks.

In the current version, only basic encryption block cipher modes are supported [START_REF] Dworkin | NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation-Methods and Techniques[END_REF]. Flexibility of the architecture al-lows its further extension, in order to implement new authentication modes (such as CMAC) and combined encryption and authentication modes (such as CCM and GCM).

To support a future discussion, HCrypt project is available on the SecReSoC project webpage: http://labh-curien.univst-etienne.fr/secresoc/ VII. CONCLUSION We proposed a novel architecture of the crypto-processor with secured key management. The architecture is based on physical separation of registers and buses aimed at key management from registers and buses aimed at data exchange and data processing. The physical separation of the processor blocks increases its robustness against protocol and fault injection attacks. Cipher and decipher blocks are independent from the processor structure and can be easily upgraded or secured by including side-channel countermeasures. Internal structure of the processor and its arithmetic-logic unit are optimized for cipher modes implementation enabling all the necessary mathematical operations. Moreover, the processor can easily analyze and create packets needed in communication protocols and it is thus suitable as a component in multi-processor networks. In order to achieve higher level of data security, only two-level symmetric-key management have been considered up to now. Nevertheless, the structure of the processor will be soon extended in order to support also the asymmetric key cryptography.

Figure 1 :

 1 Figure 1: General system architecture

Figure 3 :

 3 Figure 3: Session key management (left: encryption and transmission, right: reception and decryption)

  • Datapath -Data manipulation part -Key management part -Key generation part -TRNG • Control logic • Input/Output FIFOs 1) Datapath: The datapath is the most area-and performance-critical path of the crypto-processor. It consists of data bus, data registers and ALU. Data registers are implemented in four 32 bits wide true dual-port RAM blocks. They are accessible through two 128-bit data ports. The ALU has a 128-bit datapath. It carries out all arithmetic and logic operations (XOR, AND, NOT, CMP, ROR, ROL, CLR, INC, DEC, ADD, SUB) necessary for implementation of most encryption/decryption modes. The authentication modes are not taken into account, yet.

FIFOs Key Bus ALU SKauth MKenc PTo PTi CTo CTi Master key (enciph.) Master key (authent.) Session key (enciph.) Session key (authent.) Program memory Control unit Isolated master key entry

	RNG Data Registers (128 bits) Data Bus	Rn I/O Enciph./ Cipher Decipher authent. R1
			key
		SKenc
		MKauth	Key
		registers
		(128 bits)
		LEGEND
		Data bus
		Cipher key access
		Key transport bus
		Programmable or
		reconfigurable units
		Data registers

Table I :

 I The dedicated instruction set

	A) Data transfer instructions
	Instruction	Description
	init #,rx	Initialize Rx with a constant
	getpt rx	Get one block from plain-text input FIFO and put it to Rx
	putpt rx	Put data from data reg. Rx to the plain-text output FIFO
	getct rx	Get one block from cipher-text input FIFO to data register Rx
	putct rx	Put data from data register Rx to cipher-text output FIFO
	move rx, ry	Move the contents of data register Rx to data register Ry
	B) Instructions for key generation and manipulation
	Instruction	Description
	genk kx	Generate the key and save it in the key data register Kx
	getk rx, ky	Decipher encrypted key from data reg. Rx to key reg. Ky
	putk kx, ry	Encipher the key from key reg. Kx to data reg. Ry
	C) Data processing instructions
	Instruction	Description
	enc rx,ry	Encipher the contents of Rx and save it in Ry
	xor rx,ry	Rx XOR Ry and save the result in Ry
	dcr rx	Decrement Rx
	clr rx	Clear Rx
	cmp rx, ry	Compare Rx with Ry, set the flag Z accordingly
	D) Control instructions
	Instruction	Description
	goto displ	Unconditional branching
	bneq displ	Conditional branching if not equal (Z = 0)

Table II :

 II Block encryption modes

	A) CBC encryption mode
		getpt r3	;Get N from PTI→R3
		getpt r1	;Get IV from PTI→R1
		putct r1	;Send IV to CTO
	cbce: getpt r2	;Get data block from PTI→R2
		xor	r1, r2	;R1 XOR R2→R2
		enc	r2, r1	;Encipher R2→R1
		putct r1	;R1→CTO
		dcr	r3	;Decrement R3 (R3 -1→R3)
		bneq	cbce	;Branch to cbce if not zero
	B) CFB encryption mode
		genk	kx	;Generate new session key
		putk	kx, r1 ;Encipher session key and put it to R1
		putct r1	;Send session key to CTO
		getpt r3	;Get N from PTI→R3
		getpt r1	;Get IV from PTI→R1
		putct r1	;Send IV from R1 to CTO
	cfbe:	enc	r1, r2	;Encipher R1→R2
		getpt r1	;Get plain-text block from PTI→R1
		xor	r2, r1	;R2 XOR R1→R1
		putct r1	;Put R1 to CTO
		dcr	r3	;Decrement R3 (R3 -1→R3)
		bneq	cfbe	;Branch to cfbe if not zero

Table III :

 III Utilization of resources in XC5VLX110T

		Slices	RAM(36kb)/FIFO
	Total	17280	100.0%	148	100.0%
	Crypto-Proc.	1343	7.7%	21	14.2%
	AES Cipher	286	1.6%	9	6.1%
	AES Decipher	361	2.1%	9	6.1%
	resources and embedded RAMs/FIFOs as illustrated in Tab.
	III. Functionality was simulated using Xilinx ISim tool.
	Subsequently, timing simulation was carried out. The period
	estimated from the longest critical path was 6.45 ns, thus the
	highest clock frequency was 155 MHz.

978-0-7695-4314-7/10 $26.00 © 2010 IEEE DOI 10.1109/ReConFig.2010.38

• Data transfer instructions: data manipulation between data registers and input/output FIFOs

ACKNOWLEDGMENT

The work presented in this paper was realized in the frame of the SecReSoC project number ANR-09-SEGI-013, supported by the French National Research Agency (ANR).