Partial FPGA Bitstream Encryption Enabling Hardware DRM in Mobile Environments Mario Barbareschi, Alessandro Cilardo, Antonino Mazzeo Department of Electrical Engineering and Information Technologies University of Naples Federico II CeRICT scrl - Centro Regionale Information Communication Technology Via Claudio, 21 - 80125 Naples, Italy
{mario.barbareschi; acilardo; mazzeo}@unina.it ABSTRACT The concept of digital right management (DRM) has become extremely important in current mobile environments. This paper shows how partial bitstream encryption can allow the secure distribution of hardware applications resembling the mechanisms of traditional software DRM. Building on the recent developments towards the secure distribution of hardware cores, the paper demonstrates a prototypical implementation of a user mobile device supporting such distribution mechanisms. The prototype extends the Android operating system with support for hardware reconfigurability and showcases the interplay of novel security concepts enabled by hardware DRM, the advantages of a design flow based on high-level synthesis, and the opportunities provided by current software-rich reconfigurable Systems-onChips. Relying on this prototype, we also collected extensive quantitative results demonstrating the limited overhead incurred by the secure distribution architecture.
1.
INTRODUCTION
FPGA devices are today adopted in a wide spectrum of different application scenarios, ranging from consumer electronics to mission-critical appliances. In particular, device reprogrammability creates the possibility of distributing hardware cores, e.g. video codecs, pretty much like software digital contents, possibly on payment or on a subscription basis, as pointed out by several research works [22, 10]. As an example of a practical scenario where this distribution may take place, consider a situation where an end user wants to enrich their device, e.g. a hardware reconfigurable smartphone or a set-top box, by installing a high-end video decoder powered by a hardware accelerator. By accessing a suitable billing/market infrastructure, the user is able to download a hardware-accelerated codec to their device, based on an IP core developed by a core vendor. The vendor possibly chooses a pay-per-use billing model, implemented by the billing infrastructure. This scenario resemPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected].
CF’16, May 16-19, 2016, Como, Italy c 2016 ACM. ISBN 978-1-4503-4128-8/16/05. . . $15.00
DOI: http://dx.doi.org/10.1145/2903150.2911711
bles very closely the mechanisms of digital right management (DRM), particularly in mobile environments [2, 3], where however the concept of digital content is limited to the software domain. This work builds on recent developments towards device architectures and a related infrastructures able to effectively extend the above scenario to the secure distribution of hardware digital contents (HDCs) [22, 10]. Aimed at the practical realization of the proposed infrastructure, the paper analyzes the security-related limitations and features of the current FPGA devices, e.g. (partial) bitstream encryption, and takes them as the underlying constraints for the definition of the security architecture. The paper also presents a prototypical implementation of a user mobile device supporting secure HDC distribution where for the first time a combined design flow relying on high-level synthesis and secure distribution of hardware components is demonstrated. The prototype extends the Android operating system [2] with support for hardware reconfigurability and is used to derive extensive experimental data providing a few quantitative results and demonstrating the limited overhead incurred by the proposed solution.
2.
RELATED WORK
Digital Right Management (DRM) refers to the protection, distribution, modification, and enforcement of the rights associated with the use of digital contents [16, 23]. In a DRM scenario, a client platform guarantees that a proper license has been obtained by the user and enforces rules for playing contents. All DRM mechanisms rely on some form of specialized hardware [11] to achieve secure delivery of contents, usage rights, and authentication. Indeed, since user identification, cryptographic capabilities, and the ability to resist external tampering are vital to DRM systems, implementations of DRM are often based on Trusted Computing platforms [18], which provide the above benefits as a native feature. Such platforms mount an additional chip, the Trusted Platform Module (TPM), similar to a smartcard in its internal structure, providing security functions such as platform attestation, protected storage, and sealing, to measure and validate the hardware and/or software configurations of the platform [1]. In particular, the Open Mobile Alliance (OMA) DRM specification [4] provides a reference architecture for DRM in mobile and handheld devices. Based on Trusted Computing facilities, the OMA DRM architecture defines four actors that interact with each other in order to distribute protected digital contents to end-users. The Content Issuer (CI), as the owner of the digital con-
443
tent, firstly converts the content to an appropriate format and then negotiates a Right Object (RO) with one or more Right Issuers (RI). The RO describes constraints and permissions granted to the DRM Agent for a specific content. Before selling a RO to the end-user, the RI sets up a trusted relationship with the DRM Agent, enabling such features as mutual authentication and encryption needed to distribute copyrighted contents. In OMA DRM specification, these trust relationships are based on Public-Key Infrastructure (PKI) certificates issued by a third-party Trusted Authority, attesting both user’s and Right Issuer’s identity. DRM plays an important role in current mobile environments. For example, Android 3.0 [2] and higher platforms provide an extensible DRM framework that lets applications manage protected content using a variety of DRM mechanisms. The DRM framework offers an abstract, unified API hiding the complexity of content management operations. The architecture of the framework is plugin-based, allowing device manufacturers, content owners, and Internet digital media providers to easily implement and extend the mechanisms enforcing content protection through Android applications. A prominent example of an extension is the Widevine third-party plugin [3], built on top of the Android DRM framework, offering advanced DRM and copy protection features. Protected content is secured using an encryption scheme based on the open AES (Advanced Encryption Standard). An application can decrypt the content only if it obtains a license from the Widevine DRM licensing server for the current user. The Widevine DRM plugin integrates with the hardware platform to leverage the available security capabilities. The level of security offered is determined by a combination of the security capabilities of the hardware platform and the integration with Android and the Widevine DRM plugin. In fact, Widevine DRM security supports the three levels of security [3], essentially depending on the portion of the underlying system that is physically secured from hacking (e.g. DRM master keys, system boot, content rendering hardware, etc). Clearly, the availability of suitable security-related features at the hardware level is essential in this scenario. This work focuses particularly on platforms embedding an FPGA fabric within their secured perimeter. Low-level security aspects in FPGAs have been extensively studied in the technical literature. In fact, FPGA devices pose a number of security challenges which might deeply affect the system operation, They are usually programmed through a JTAG interface, so most attacks exploit the JTAG backdoor to manipulate the bitstream or download a malicious one. In [8] the authors show an easy and reproducible technique where it is possible to insert additional logic to the original bitstream. The access to the bitstream could be used, with a suitable reverse engineering technique, to retrieve an IP [6]. A few works propose a security-hardened version of JTAG. In [12] the authors present an anti-tamper JTAG protocol where a simple challenge/response is implemented on chip with the aim of authenticating and integrity checking. A set of secret keys is adopted to guarantee an access control for each JTAG command and some temporary keys are generated by a ringoscillator RNG. The authors of [9] present a secure test wrapper, based on AES, to be applied in IEEE 1500 architecture, the evolution of IEEE 1149.1. Another JTAG hardening is proposed in [21] consisting in a multi-level priv-
ileges for the JTAG protocol, in order to avoid a binary lock system that could allow a full access to the user once authenticated. The architecture adopts a SAM module for securing JTAG accesses. Dynamic partial reconfiguration (DPR) also opens up potential security threats for the FPGAs. It is often meant to be a self-reconfiguration process, where the FPGA reprograms a sub-part of itself using a partial bitstream stored in a non-volatile memory (NVM) instead of using JTAG. JTAG can thus be disabled, in order to avoid the readback feature, although we still need to protect the partial bitstream. Several proposals in the literature protect the IP of partial bitstreams by using encryption schemes. In [19] the authors implement on a Virtex5 a partial reconfiguration module exploting AES-GCM in order to implement encryption and authentication. Some performance analysis are provided. In [7] the authors propose an efficient Authenticated Encryption scheme tailored for FPGA bitstream protection. It is based on the AES based authenticated encryption scheme (ALE). The authors of [15] focus on spoofing and reply attacks. With spoofing, an attacker can replace the data with fake information. With a reply attack, an attacker can record the bitstream sent by the user to the FPGA and re-send it in order to delete subsequent configurations. The authors propose a frame tailored for trusted FPGAs or trusted boards whereby they guarantee confidentiality, integrity, authenticity, and up-to-dateness based on AES and HMAC algorithms. The authors of [17] propose a technique to make Xilinx low-cost FPGAs as secure as high-end FPGAs without adopting an encryption scheme. They use one or more PUFs to generate a signature used by a host to obfuscate the HDL code, such as a FSM state coding. The generated bitstream is well-functioning only for a specified device. In [20] the authors propose a methodology to defend an IP by using trusted platforms based on FPGA dynamic reconfiguration capability. They identify the players, such as the system integrator, trusted authority, FPGA fabric vendor, and so on, and define a few solutions to add, update, store, and catalog an IP. They provide a proof-of-concept implementation on a Virtex-II FPGA. No details about the protocols are given. [13] extends a licensing approach to hardware components. The authors conclude that this approach requires a modified FPGA architecture equipped with a secure NVM and a tamper-resistant unique identifier.
3.
HARDWARE-LEVEL DRM ARCHITECTURE
This work is based on the notion of hardware digital contents (HDCs), i.e. the digital contents concept extended to reconfigurable hardware components. In fact, device reprogrammability creates the possibility of distributing hardware cores, e.g. video codecs, pretty much like software digital contents, possibly on payment or on a subscription basis. As part of the application logic, hardware accelerators can be perceived as add-ons that can be downloaded, possibly on payment, and installed on the user’s device to extend its processing capabilities. This resembles very closely the scenario where software digital contents, e.g. tones, MP3 files, or mobile application themselves, are distributed through a controlled licensing service. We summarize below the architecture of a hardware recon-
444
Figure 1: Physical architecture of a device compliant with the proposed secure core distribution infrastructure.
figurable device supporting secure HDC distribution as suggested by a few recent reseach contributions. Later, the section describes the distribution infrastructure and the main interactions involved. The device architecture is shown in Figure 1. The hardware execution environment contains a partially reconfigurable region that can host additional processing components, e.g. codecs. Third-party developers can implement and distribute their own components, i.e. HDCs, which must comply with an Application Programming Interface (API) exposed by the hardware environment. Most likely, the whole application downloaded by the user will be made of a software part containing non-critical parts and a hardware-accelerated portion implemented in the form of a HDC. The FPGA is equipped with two native security mechanisms. In particular, the Master Reconfiguration Key (MRK) is a symmetric encryption key used by the on-chip configuration circuitry to decrypt the (partial) bitstreams downloaded to the FPGA. The FPGA device Identifier (FID) is a unique code associated with each different physical instance of the device, used to uniquely bind a bitstream to a user device. The FID is non-critical in terms of security and can be possibly accessed from the outside. Notice that both mechanisms reflect existing securityrelated measures available on current medium-end FPGA devices [14, 24]. Two key components are built around the FPGA device on top of the basic architecture. The secure initialization interface is essentially used to initialize the MRK. It is meant to be accessed in a secure environment under the sole control of the Trusted Third-Party and possibly of the FPGA Fabric Vendor. The secure authentication module (SAM) is a tamper-resistant device with encryption capabilities, supporting symmetric and public-key cryptography and secure non-volatile storage. It is associated with the user identity and can be remotely accessed by the Trusted Third-Party online. In a real scenario, the SAM is likely to coincide with a Subscriber Identification Module (SIM) normally available in handheld devices, which precisely fulfils the above requirements. In this case, the Trusted Third-Party can coincide with the Mobile Network Operator (MNO), or can obtain the access to the user SIM from the MNO as a service. The SAM is vital in the envisioned architecture in that it provides a cryptographically secure storage for the Right objects associated with each HDC, making the application stateful (unlike the FPGA itself), and linking the device identity
Figure 2: Architecture of the secure core distribution infrastructure with the user identity. Based on the above architecture, the following assumptions can be made concerning the security at the level of the device: • The architecture surrounding the FPGA is not necessarily secure, in particular it must not necessarily be a trusted computing platform. • The device can be physically tampered. • The SAM, along with the Right Objects in its NVM, can be removed and replaced with a fake SAM. • The secure initialization interface is always accessible for writing the MRK (although the genuine MRK is always initialized in a secure environment).
3.1
Secure core distribution infrastructure
Figure 2 describes the corresponding infrastructure for HDC distribution along with the interactions between the players. The MRK initialization involves a Trusted ThirdParty and an End User, relying on the secure initialization interface. The process is write-only, meaning that the MRK can never be readback. Any attempt to access the initialization interface will result in the loss of previous MRK, making the bitstreams specific to this device unusable. Notice that the physical architecture is constrained by existing FPGA security mechanisms. In particular, the MRK key enters the FPGA in a plain form and can be read by probing the device pins during initialization. That implies that the initialization process must always take place in a secure environment, possibly at manufacturing time. Notice that current technologies, such as Xilinx bitstream encryption, allows the non-volatile storing of the decryption key by either storing it in a RAM powered by a small backup battery or by using non-volatile one-time programmable fuses. The Trusted Third-Party can also interact with the SAM in the device to securely transfer the secret key used by the SAM to authenticate the FPGA requesting access to the Right Objects. Since the SAM (e.g. the user SIM card) represents a secure perimeter with its onw identity and cryptographic capabilities, the interaction between the Trusted
445
Third-Party and the SAM can take place at any time, possibly mediated by the MNO, in a secure way, even when the SAM and the FPGA are placed in an untrusted device. A bitstream registration/validation/encryption procedure takes place between the Trusted Third-Party and the IPCore Vendor. This interaction takes place online through a standard secure channel, most likely an SSL-secured connection, in order to authenticate the Trusted Third-Party and preserve confidentiality of the HDC bitstream. Having full access to the bitstream, the Trusted Third-Party validates its structure by both checking its compliance with the standard API as well as its trustworthiness, e.g. the absence of hardware trojans. Notice that it is very unlikely that the user device can autonomously perform such check directly on their device: On the one hand, that would expose the bitstream outside a secure perimeter and, on the other hand, it would require overly large analysis capabilities to reside on the user device. This is a major reason explaining the role of the Trusted Third-Party. Once the validated and encrypted HDC bitstream is obtained from the Trusted Third-Party, the IPCore Vendor can distribute it directly to the end user, through possibly unsecure channels. It also creates and issues the Right Objects (ROs) associated with the HDC. The ROs can define permissions, constraints, and obligations enforced on the use the HDC. For instance, a limited number of uses can be granted for the distributed HDC, e.g. for a trial installation. The management of the ROs (e.g. the count of the different uses) requires a non-volatile memory which, because of the above technological constraints, is hosted outside the FPGA in the SAM. The API available from the static part of the design to the HDC exposes the required interface to authenticate the HDC to the SAM through a challenge-response process before reading/updating the ROs associated with the HDC stored on the SAM. Notice that, as discussed later, the authentication of the FPGA to the SAM is key to guaranteeing a trustworthy manipulation of the ROs, which do not reside on the HDC itself because of the lack of non-volatile memory in the FPGA.
3.2
Security implications
In case an IPCore Vendor wants to inject a malicious HDC bitstream into the end user device without the user’s collusion, the software environment on the device is still genuine and prevents FPGA configuration outside the secure environment accessed only by the Trusted Third-Party (see Figure 1). In particular, no Master Reconfiguration Key update can take place. The architecture also prevents IP theft and reverse engineering. This is impossible through network sniffing, since HDC bitstreams exist in an unencrypted form only within the IPCore Vendor’s and the Trusted Third-Party’s perimeter. Furthermore, they need to travel from the IPCore Vendor to the Trusted Third-Party across an untrusted communication channel. For this type of interaction, however, the channel can be easily secured through standard mechanisms, particularly an SSL connection. Right Object tampering based on cryptanalysis is unfeasible, since Right Objects are securely stored within the SAM, which only grants access to authenticated external components, namely the HDCs running within the FPGA. Last, if the device surrounding the FPGA is not a trusted computing platform in itself, the software environment can be easily tampered. In particular, an
attacker can easily reverse engineer the software part accompanying the HDC. In fact, in a real-world scenario, HDCs are likely to implement only a performance-critical kernel of an application (e.g. a intra-frame predictor as a part of a software video codec). By analyzing the interface of the hardware component, the attacker could reproduce in software the functionality implemented by the HDC and hack the high-level application by replacing the FPGA with their own software routine.
4.
HDC CASE STUDY
The DRM approach has been realized as a prototype in order to prove the feasibility of the proposed scheme. In particular, adopting the Zedboard development kit, which includes a Xilinx Zynq 7Z020, we realized both the hardware and software layers. As for the hardware, the Zynq provides a processing system (PS), equipped with an ARM dual-core Cortex A9 32/32 KB I/D caches, 512 KB L2 cache and with some I/O interfaces, such as USB, ethernet, SDIO, etc. Moreover, being the Zynq a System on Programmable Chip, it has available a programmable logic (PL) in form of FPGA Artix-7. The PS and PL communicates each other by means of some AXI interfaces and the PS is able to configure, with full or partial bitstreams, the PL through the Device Configuration (DevC) peripheral. The DevC is able to configure both plain or ciphered bitstreams, since it is designed with a hardened AES decryption engine, coupled to the Hashed Message Authentication Code (HMAC) engine that adopts SHA-256, which enable a private key authentication mechanism. The key is defined by the user, programmed through the JTAG interface and stored in either volatile Battery Backed RAM (BBRAM) or permanently within the eFUSE array. Together with on chip memory, L1 and L2 cache, AXI block RAM, PL configuration memory, the BBRAM and eFUSE registers reside within the Zynq secure perimeter. The static design, which is programmed at boot time onto the PL, contains an additional AES decryption engine, since the one provided with the DevC cannot be externally accessed, and an empty HDC slot. As for the deployed software, we adopted the Google Android operating system stack, exploiting the project Zedroid illustrated in [5]. The hardware and software configuration allows to use the HDMI, audio, ethernet and USB OTG interfaces.
4.1
HDC lifecycle managing framework
To guarantee the system integrity and some basic facilities that are in common among all the HDCs, we developed a framework which is directly integrated within the Zedroid software stack and exposes some APIs. They are accessible to the developers which aim is to dynamically configure a new hardware unit, by means of the DevC, within the Android SDK. The APIs provide synchronized accesses to the HDC slot integrated in the Linux Kernel space. Other mechanisms to preserve the system integrity, such as the denying the access attempts to a blank HDC, are provided at higher level by means of JNI interfaces. Android activities or services are able to manage the HDC lifecycle. Indeed, the APIs expose some functions to install, check, remove and activate the HDC. These functions enable each Activity and Service to match its state (paused, active, resumed, etc.) with the HDC one.
446
4.2
HDC Development Automation
The envisioned hardware and software architecture, adopting a high level synthesis (HLS) approach, is able to provide a fully automatic design methodology. In particular, as HLS techniques are able to provide both the hardware description and the low-level drivers for a peripheral, which is originally described in high-level programming languages, the HDC can be quickly obtained and integrated into the Android stack. For instance, if a developer (the IPCore Vendor) wants to accelerate an algorithm, which is written in C/C++, he/she can define a custom peripheral using Vivado HLS, which produces as output the hardware description of the component, fully integrated in a bus communication system, and the low-level driver compatible with Linux, which can accessed by the Android application through the JNI interfaces. The drivers are compiled within the same Android SDK, consequently the bare Linux drivers are run in the user space rather that the kernel space. This is not a prohibitive limitation, since there are no differences between the user and kernel space for applications that have the aim to access the peripheral registers and control their flows. Therefore, this approach has the advantage to enable the dynamically loading of required drivers directly with the software applications. Then, exploiting JNI, the developing of the application, which is accomplished in Java language in Android, does not introduce significant alterations of the programming methodology. Moreover, in the Zedroid project, we provided some wrapping classes, which are realized with the singleton pattern, that are able to mask the JNI accesses and, consequently, to make the application developing independent from the specific driver instance.
4.3
Case Study and performance evaluation
To demonstrate the proposed solution, we also present a realistic scenario where we reproduce the main interactions of the proposed distribution infrastructure. We will also quantify the related overhead by providing a few significant experimental results. Assume that an application, which processes images, is downloaded from the app store and includes some hardware accelerators to dynamically configure onto the system as a HDC, available at an extra fee. The IPCore Vendor has realized these accelerating units, maybe recurring to a HLS development software, implementing some image processing filters in order to enhance the application speed. The End User, by accessing the billing system, provided by the TTP as a normal online store, is able to complete the payment transaction to access the wanted accelerating units, provided within the application. In particular, the right to get the access to a specified accelerator, i.e. the authorization to partially configure the FPGA with a bitstream which contains the hardware image processing algorithm, is issued by the TTP and granted by the End User as a right object (RO), which has to be written in the SIM. Each accelerator can be provided within the app or downloaded on-demand by means of an URI. As previously illustrated, each accelerator is distributed as a ciphered bitstream. When the Android Activity loads the ciphered bitstream onto the FPGA, an accelerator is configured as new system’s peripheral. Initially, such peripheral is locked, waiting for the proper RO. Hence, the application interacts with the SIM to check the proper RO for the accelerator unit. If available, the SIM returns a chipered token which
LUTs FFs DSP48E BRAM 18k Latency Speed-up
Sobel 874 565 1 3 2.66 · 105 2.55
Sepia 872 579 1 3 2.66 · 105 2.67
Posterize 752 451 0 0 2.64 · 105 2.41
Median 983 536 0 0 7, 88 · 105 2.9
Table 1: Resource occupation and time values for four different hardware image processing filter engines. the application exploits for the activation of the accelerator. Only after such interactions, the configured hardware unit can be accessed by the application through provided APIs. The activation mechanism of accelerating units, as anticipated before, is a concern of the IPCore Vendor. When requested by the application, an image processing accelerating unit is configured and accessed through the driver developed together with the Android application. We realized four different image processing filters, i.e. Sobel, Sepia, Posterize and Median filters, integrated in an image processing application developed in the Android SDK. The filters have been synthesized by means of Xilinx Vivado HLS and integrated with the system using an AXI interface and the Linux driver automatically produced. Moreover, since each image has to be transferred in the PL before the elaboration, we integrated in each core the Video Direct Access Memory (VDMA), provided as IPCore in Xilinx Vivado tool, to buffer the image and avoid the performance degradation. Drivers for both the hardware components (image filer and VDMA) are automatically provided by Vivado. In Table 1 we report some information about the resources required by each filter and about the timing. As for the speedup, we evaluated it by comparing the execution time when an image of 512x512 pixel is filtered in software against the case in which the filtering is ran in hardware. It is worth to notice that the resources occupied by the hardware units are less than 1%, hence this solution has a insignificant cost compared to the speed-up which is about 2.5. Differently, the overhead introduced by the dynamic reconfiguration of partial ciphered bitstreams, the HDC installation and activation is non-zero. Indeed, in the prototype, the SIM card is connected through a UART bridge with USB (USB VCP) and the AES decryptor, which is used to decipher the RO downloaded from the SIM card, introduces an unavoidable latency. Considering a simple RO that is able to activate the core (like a full-license) and a SIM card which baudrate is 9600 bps, the time to save the RO is on average 240 ms, while the querying time is on average 180 ms. Considering also the latency introduced by the partial reconfiguration, the API checks and the Android overhead, the overall introduced overhead evaluated from the HDC installation request for the image process units is 650 ms.
5.
DISCUSSION AND CONCLUSIONS
This work demonstrated the adoption of an infrastructure for the secure distribution of hardware digital contents. The prototype system is a software-rich hardware reconfigurable System-on-Chip running the Android mobile operation system, while the development cycle of the hardware digital contents also involves high-level synthesis. Aimed at the practical realization of the distribution infrastructure, the architecture for secure distribution of hardware cores only
447
relied on the features of existing FPGA devices, e.g. (partial) bitstream encryption, and took them as the underlying constraints for the definition of the security architecture. Relying on this prototype, we collected extensive quantitative results demonstrating the limited overhead incurred by the distribution architecture. In addition to the definition of the infrastructure and device architecture, a major lesson learned from this work lies in the analysis of the securityrelated features and limitations of current FPGA devices. First, for the ideal realization of the secure distribution scenario, FPGAs should support separate encryption mechanisms for static and partial bitstreams. This would prevent independent developers from accessing the IP of other developers (a limitation overcome here by letting only the Trusted Third-Party know the encryption key and encipher the bitstreams in place of the developers). Further, in an ideal scenario FPGAs would be provided with an on-chip authentication mechanism, allowing them to directly establish a secure channel with the Trusted Third-Party, simplifying the interactions and allowing the MRK initialization process to take place remotely at any time. Having nonvolatile memory on the FPGA would then remove the need for an external SAM device. Last, while we developed an AES core on the static part of the FPGA, only required by DRM-related operations, the FPGA is already provided with an AES hardened core: making such core available to the DRM-related operations would of course save a significant amount of hardware resources that could be exploited for the user design.
6. [1] [2] [3] [4] [5]
[6]
[7]
[8]
[9]
[10]
REFERENCES Trusted mobile platform project: Introduction. What is android, 2011. Widevine home page, 2014. O. M. Alliance. DRM specification v2. 0. Open Mobile Alliance Ltd, 2004. M. Barbareschi, A. Mazzeo, and A. Vespoli. Network traffic analysis using android on a hybrid computing architecture. In Algorithms and Architectures for Parallel Processing, pages 141–148. Springer International Publishing, 2013. F. Benz, A. Seffrin, and S. A. Huss. Bil: A tool-chain for bitstream reverse-engineering. In Field Programmable Logic and Applications (FPL), 2012 22nd Int. Conf. on, pages 735–738. IEEE, 2012. A. Bogdanov, A. Moradi, and T. Yalcin. Efficient and side-channel resistant authenticated encryption of FPGA bitstreams. In Reconfigurable Computing and FPGAs (ReConFig), 2012 International Conference on, pages 1–6. IEEE, 2012. R. Chakraborty, I. Saha, A. Palchaudhuri, and G. Naik. Hardware trojan insertion by direct modification of FPGA configuration bitstream. Design Test, IEEE, 30(2):45–54, April 2013. G.-M. Chiu and J.-M. Li. A secure test wrapper design against internal and boundary scan attacks for embedded cores. Very Large Scale Integration (VLSI) Systems, IEEE Transactions on, 20(1):126–134, 2012. A. Cilardo, M. Barbareschi, and A. Mazzeo. Secure distribution infrastructure for hardware digital contents. IET Computers & Digital Techniques, 8:300–310(10), November 2014.
[11] A. Cilardo, A. Mazzeo, L. Romano, and G. Saggese. An FPGA-based key-store for improving the dependability of security services. In Object-Oriented Real-Time Dependable Systems, 2005. WORDS 2005. 10th IEEE International Workshop on, pages 389–396, Feb 2005. [12] C. J. Clark. Anti-tamper JTAG TAP design enables DRM to JTAG registers and p1687 on-chip instruments. In Hardware-Oriented Security and Trust (HOST), 2010 IEEE International Symposium on, pages 19–24. IEEE, 2010. [13] N. Couture and K. B. Kent. Periodic licensing of FPGA based intellectual property. In Field Programmable Technology, 2006. FPT 2006. IEEE International Conference on, pages 357–360. IEEE, 2006. [14] G. Crow. Advanced security schemes for Spartan-3A/3AN/3A DSP FPGAs. Xilinx Corp. White Paper, ref, 267, 2007. [15] F. Devic, L. Torres, J. Crenne, B. Badrignans, and P. Benoit. Secure DPR: Secure update preventing replay attacks for dynamic partial reconfiguration. In Field Programmable Logic and Applications (FPL), 2012 22nd International Conference on, pages 57–62. IEEE, 2012. [16] A. M. Eskicioglu, J. Town, and E. J. Delp III. Security of digital entertainment content from creation to consumption. In International Symposium on Optical Science and Technology, pages 187–211. International Society for Optics and Photonics, 2001. [17] S. G¨ oren, O. Ozkurt, A. Yildiz, H. F. Ugurdag, R. S. Chakraborty, and D. Mukhopadhyay. Partial bitstream protection for low-cost FPGAs with physical unclonable function, obfuscation, and dynamic partial self reconfiguration. Computers & Electrical Engineering, 2012. [18] T. Group et al. TCG specification architecture overview revision 1.2, 2004. [19] Y. Hori, A. Satoh, H. Sakane, and K. Toda. Bitstream encryption and authentication with AES-GCM in dynamically reconfigurable systems. In Field Programmable Logic and Applications, 2008. FPL 2008. International Conference on, pages 23–28. IEEE, 2008. [20] K. Kepa, F. Morgan, K. Kosciuszkiewicz, and T. Surmacz. Serecon: A secure dynamic partial reconfiguration controller. In Symposium on VLSI, 2008. ISVLSI’08. IEEE Computer Society Annual, pages 292–297. IEEE, 2008. [21] L. Pierce and S. Tragoudas. Enhanced secure architecture for joint action test group systems. Very Large Scale Integration (VLSI) Systems, IEEE Transactions on, 21(7):1342–1345, July 2013. [22] M. R., S. D., and V. I. A pay-per-use licensing scheme for hardware ip cores in recent sram-based fpgas. Information Forensics and Security, IEEE Transactions on, 7(1):98–108, Feb 2012. [23] W. Rosenblatt, S. Mooney, and W. Trippe. Digital rights management: business and technology. M&T Books, 2003. [24] M. Smerdon. Security solutions using Spartan-3 generation FPGAs. In Xilinx Inc. Citeseer, 2008.
448
