Content uploaded by Pietro Nannipieri
Author content
All content in this area was uploaded by Pietro Nannipieri on Oct 25, 2024
Content may be subject to copyright.
A PUF-based Secure Boot for RISC-V
Architectures
Stefano Di Matteo1[0000−0002−5711−432X], Luca Zulberti1[0000−0001−9599−2652] ,
Federico Cosimo Lapenna, Pietro Nannipieri1[0000−0002−2538−5440], Luca
Crocetti1[0000−0001−8504−8203], Luca Fanucci1[0000−0001−5426−4974], and Sergio
Saponara1[0000−0001−6724−4219]
Department of Information Engineering, University of Pisa
Via G. Caruso 16, Pisa, Italy
stefano.dimatteo@dii.unipi.it
Abstract. Recently, there has been a growing interest in Physically Un-
clonable Functions (PUFs). These electronic circuits possess several key
characteristics such as unpredictability and uniqueness that make them
particularly attractive for security applications. PUFs offer an appeal-
ing solution for secure boot applications, providing a hardware-based
mechanism for generating unique cryptographic keys. These keys can be
used to encrypt the bootloader and operating system, thereby enhanc-
ing security. In this paper, we propose an innovative, secure boot scheme
that leverages the functionality and characteristics of a PUF. Our ap-
proach eliminates the need for physical storage of the encryption key
of the boot code, which enhances security and provides the possibility
of securely updating the firmware. We will present an architecture that
comprises essential components, along with a demo board on FPGA. The
demo board features a general-purpose 64-bit RISC-V-based system that
leverages the proposed PUF-based secure architecture, enabling secure
boot and firmware update functionalities.
Keywords: PUF, RISC-V, Secure Boot, Hardware, FPGA
1 Introduction
In today’s digital age, security has become an increasingly critical concern for
individuals, organizations, and governments. With the growing complexity and
sophistication of cyber threats, it is crucial to implement robust security mea-
sures to protect computer systems and sensitive data. Secure boot technology
is one of such security measure that is integrated into modern computer sys-
tems [5, 7, 10]. Its primary aim is to verify the digital signatures of the boot-
loader and operating system before loading, ensuring that only trusted software
is executed during the boot process. This is achieved by creating a chain of trust
that begins with the system firmware and continues through the bootloader and
operating system [8]. If any of these components are compromised, the secure
boot process will fail, and the system will not boot, ensuring that only reliable
software is executed.
2 S. Di Matteo et al.
Dedicated hardware can adopted to enhance the security of the chain of
trust [8,9] and the performance of the entire system [2,3]. Physically Unclonable
Functions (PUFs) are electronic circuits that have gained increasing interest
in recent years due to their unique properties, making them ideal for security
applications [11,12, 14]. PUFs can generate unpredictable and unique responses
to input stimuli, which is advantageous for creating cryptographic keys that are
difficult to replicate or guess. The most attractive properties of a PUF, in fact,
are the unpredictability of its response and the uniqueness of the response to
each instance of the circuit. These properties result from the inherent variations
in the manufacturing process fabricating the circuit. The response generated
by the PUF can serve as a cryptographic key for encrypting the boot code,
firmware, and operating system. Furthermore, another advantage of using the
PUF response as a key is that it eliminates the need to preserve the secret key
within the device.
Our paper presents a novel approach for enhancing security during boot-
up, utilizing a security subsystem that leverages the functionality and unique
characteristics of a PUF. By implementing this approach, we aim to address
certain security concerns associated with secure boot, while also enabling se-
cure firmware updates when necessary or in the event of a successful attack on
a chip. This is crucial in preventing potential security breaches that could im-
pact other chips of the same type. The paper is organized as follows: Chapter
2 explains our PUF-based secure boot concept and the hardware components
needed to implement it. Chapter 3 presents a complete RISC-V-based system
prototype composed of a general-purpose subsystem enhanced by a secure sub-
system equipped with an FPGA-based Ring-Oscillator PUF to perform secure
boot and secure firmware updates. Chapter 4 will draw the conclusions of this
work.
2 Proposed PUF-based Secure Boot
One of the classical approaches to verify the authenticity and integrity of the boot
code is to include Original Equipment Manufacturer (OEM)-related information
in the system. For instance, the public key of the system owner can be used to
verify the ownership of the boot code at the startup; in this way, the owner’s
public key shall be embedded in a Read Only Memory (ROM), and it shall be
used at the startup of the system to verify the signature of the boot code that
has been previously signed with the corresponding private key. This approach
implies that all devices use the same public key. As reported in [1], ”storage
of the public key for the root of trust can be problematic; embedding it in
the on-SoC ROM implies that all devices use the same public key. This makes
them vulnerable to class-break attacks if the private key is stolen or successfully
reverse-engineered”. The same concept can be applied to symmetric keys in case
they are used to encrypt the boot code. Starting from these issues, the main
goals of our secure boot concept are:
A PUF-based Secure Boot for RISC-V Architectures 3
–Avoid the physical storage of secret keys: this eliminates the possibility of
disclosure of secret keys stored in memories.
–Unique secret key for each physical device: if the secret key of a device is
discovered, it cannot affect the security of the other devices as each key
generated by the PUFs is unique.
–Possibility to modify OEM public key stored in the device: in case of disclo-
sure of the OEM private key, the OEM should be able to update its public
key stored in the device.
–Unpredictability of the secret keys for each physical device: this resolves
issues related to the trustiness of the electronic manufacturers and supply
chain.
NVM
Encrypted
VPK, FSB
Secure Environment Non-Secure Environment
reset
Secure
Element
OTP
boot
addr
Secure
Memory
PUF
Secure
API
update VPK-FSB
CPU Peripherals
Main
Memory
Fig. 1. Concept Architecture of the Secure System. NVM is a Non-Volatile Memory.
OTP is a One-Time Programmable memory. VPK is the Vendor’s Public Key. FSB is
the First-Stage Bootloader of the CPU.
The system we propose is illustrated in Figure 1, and it is composed of three
main parts:
–Secure Environment (S-Env): provides PUF-based encryption and authenti-
cation (hardware fingerprint) and can reset the Non-Secure part. We expect
the need of an OTP memory to store the PUF challenge plus auxiliary infor-
mation to retrieve the corresponding response (e.g. redundancy of correction
codes, if needed).
–Non-Secure Environment (NS-Env): is a standard CPU-based SoC whose
boot sequence is regulated by the Secure part.
–A Non-Volatile Memory (NVM): contains the encrypted Vendor Public Key
(VPK) and the encrypted First-Stage Bootloader (FSB) for the CPU.
The S-Env exposes the following Secure Application Program Interface (SAPI)
to the NS-Env, based on the status of the OTP memory:
–WriteNVM: this operation initializes the S-Env. It can be issued only if the
OTP memory is not written.
4 S. Di Matteo et al.
–UpdateNVM: the NS-Env can request an update of the NVM employing
Publick Key Authentication using the VPK. It can be issued only if the
OTP memory has been written.
The boot sequence of the system depends on the S-Env status. As long as the
S-Env is not initialised (fresh OTP memory), the Secure Element (SE) copies
the content of the NVM into the Secure Memory (SMem) and wakes up the
CPU. No verification is performed in this procedure, and the boot is not secure.
START
Vendor writes
plain VPK-FSB
into NVM
System Boot
(OTP is fresh)
SE copies NVM
into SMem
SE wakes up
the CPU
CPU issues a
WriteNVM operation
CPU writes
VPK-FSB into SMem
SE halts the CPU
SE saves the
BootChallenge into
the OTP
SE retrieves the BootKey from the PUF
using the BootChallenge
requested within the WriteNVM issue
SE reads the
VPK-FSB couple
from the SMem and
encrypts it with
the BootKey
System Shutdown
END
Vendor can ship
the system with
Secure-Boot
enabled
SE stores the
encrypted VPK-FSB
couple into the NVM
Fig. 2. Secure Environment Initialisation Procedure
Secure Environment Initialisation. The vendor of the system can initialise the
S-Env by performing the following procedure, illustrated in Figure 2:
1. Vendor prepares the NVM with the VPK-FSB couple and a bootable code
executed by the CPU to perform the initialisation sequence.
2. At system boot, the SE will perform a non-secure boot sequence (the OTP
is fresh) by coping the NVM content at the boot address of the SMem and
waking up the CPU.
3. The code executed by the CPU prepares the SMem with the VPK-FSB
couple and the Boot Challenge (BC). The latter can be hard-coded into
the initialisation code or determined at run-time. Then, the CPU issues a
WriteNVM request to the SE.
4. After halting the CPU, the SE retrieve the Boot Key (BK) from the PUF
by providing the BC.
5. The SE encrypts the VPK-FSB couple found in the SMem with the BK using
an encryption algorithm (e.g. Advanced Encryption Standard) and stores
it in the NVM with a hash digest used for integrity check during secure
boot. Depending on the computational capabilities of the SE, the vendor
may employ a Digital Signature Algorithm (DSA) or a Hash-based Message
Authentication Code (HMAC) to ensure the integrity and authenticity of
the FSB code.
A PUF-based Secure Boot for RISC-V Architectures 5
6. Finally, the SE saves the BC into the OTP (with any other required pa-
rameters related to PUF implementation), and the S-Env can be considered
initialised.
7. From now, the WriteNVM operation cannot be issued any more, and the
vendor can ship the system with Secure-Boot enabled.
START
System Boot
(OTP is written)
SE reads the
BootChallenge
from the OTP
SE reads the
Encrypted VPK-FSB
from the NVM
SE copies the VPK
and the FSB
into the SMem
SE decrypts the
VPK-FSB couple
and verify its integrity
SE wakes up
the CPU
END
SE retrieve
the BootKey from
the PUF with the BC
CPU boots with
Secure Boot code
Fig. 3. Flow Diagram Describing the Secure-Boot Sequence
Secure Boot Sequence. When the S-Env is initialised, the boot sequence includes
the PUF-based verification of the NVM, illustrated in Figure 3:
1. At system boot, the SE reads the BC from the OTP and retrieves the BK
by challenging the PUF.
2. The SE reads the encrypted VPK-FSB couple from the NVM, decrypts it
with the BK using an encryption algorithm (e.g. Advanced Encryption Stan-
dard) and verifies its integrity and authenticity using DSA or HMAC.
3. Finally, the VPK and the FSB are copied into the SMem, and the CPU is
woken up.
START
System Running
CPU store thenew
signedVPK-FSB
couple into the SMem
SE copies the
encrypted VPK-FSB
into the NVM
SE encryptsthe
newVPK-FSB couple
SE wakes up
the CPU
END
CPU issues an
UpdateNVM
operation
CPU boots with
newSecure Boot
SE halts the CPU
SE verify the signature using the
activeVendor Public Key
Fig. 4. Flow Diagram for Updating the NVM
6 S. Di Matteo et al.
Update NVM Sequence. During normal operation, the CPU can issue an Up-
dateNVM operation to update the VPK or the FSB contained in the NVM, as
illustrated in Figure 4:
1. While the system is running, the CPU prepares a new VPK-FSB couple and
signs it with the active private key.
2. The CPU store the signed content into the SMem and issues the UpdateNVM
operation.
3. The SE halts the CPU and verifies the signature in the SMem using the
active VPK.
4. If successful, the SE encrypts the new VPK-FSB couple and stores it in the
NVM.
5. Finally, the CPU is woken up, and the new Secure Boot process is performed.
The proposed PUF-based Secure Boot procedure and SAPI avoid the physical
storage of secret keys and allow to have unpredictable and unique secret keys
for each physical device. In addition, the update sequence allows modifying the
OEM VPK in case of private-key class-break attacks to limit the number of
compromised devices.
3 Implementation on FPGA
To prototype the proposed PUF-based Secure Boot procedure, we implemented
a System-on-Chip (SoC) on a Xilinx ZCU106 FPGA Board that emulates the
architecture of Figure 1.
SE
Secure Environment
RISC-V CPU
(CV32E40P)
Secure
Memory
RO-PUF JTAG
UART
Main
Memory
AXI4 Interconnect
Program
Memory
Host
PC
Non-Secure Env.
RISC-V CPU
(CVA6)
AXI4 Interconnect
OTP
Memory
SD
Fig. 5. SoC implemented on a Zynq Ultrascale+ FPGA.
As illustrated in Figure 5, the system is divided into a Non-secure Environ-
ment and a Secure Environment. The former (that emulates a general-purpose
application system) includes a RISC-V CPU (i.e., the CVA6 64-bit proces-
sor [13]) connected through an AXI4 interconnect to its Main Memory (DDR4
A PUF-based Secure Boot for RISC-V Architectures 7
controller) and the UART JTAG peripheral provided as Xilinx IPs. The latter
implements the SE using a smaller RISC-V CPU (i.e., the CV32E40P 32-bit
processor [4]) with its Program Memory. On-chip memory is used to emulate
the SMem shared between the two environments and the OTP of Figure 1.
The VPK-FSB couple is stored encrypted on the external SD memory (NVM
in Figure 1). The PUF we implemented is a Ring Oscillator PUF (RO-PUF),
generating a response of 325 bits using a challenge of 220 bits. To improve the
reliability of the responses, the output is corrected using an Error Correcting
Code (ECC) based on the Reed-Muller code, and we used the VHDL implemen-
tation published in [6]. The Red-Muller ECC needs a helper generated during
the initialisation procedure and stored on the OTP memory. To generate the
AES-CBC-128 key, the SHA256 algorithm is applied to the PUF response and
truncated to 128 bits. While to ensure the integrity and authenticity of the
VPK-FSB couple, the ECDSA-256 algorithm is used.
4 Conclusions
Our research paper presents a novel implementation of a Secure Boot process,
which leverages PUF technology to eliminate the requirement of storing secret
keys in physical storage. PUF technology enables the generation of unique and
unpredictable secret keys for each individual device. Furthermore, our updating
process streamlines the ability to modify VPK in order to mitigate the effect of
class-break attacks in case of disclosure of the vendor’s private key. As a proof-
of-concept, we implemented the proposed PUF-based Secure Boot procedure on
a Xilinx ZCU106 FPGA board, which includes a 32-bit RISC-V-based secure
environment exposing a Secure API for the 64-bit RISC-V application-class pro-
cessor.
Acknowledgments. This work has been partially supported by the European
Union within the Horizon 2020 Research and Innovation Programme “European
Processor Initiative—Specific Grant Agreement 2” (EPI-SGA2) under Grant
101036168.
References
1. ARM security technology – Building a secure system using TrustZone technology
(2005-2009), https://developer.arm.com/documentation/PRD29-GENC-009492/
c
2. Baldanzi, L., Crocetti, L., Di Matteo, S., Fanucci, L., Saponara, S., Hameau,
P.: Crypto accelerators for power-efficient and real-time on-chip implemen-
tation of secure algorithms. In: 2019 26th IEEE International Confer-
ence on Electronics, Circuits and Systems (ICECS). pp. 775–778 (2019).
https://doi.org/10.1109/ICECS46596.2019.8964731
3. Di Matteo, S., Lo Gerfo, M., Saponara, S.: Vlsi design and fpga implementation of
an ntt hardware accelerator for homomorphic seal-embedded library. IEEE Access
11, 72498–72508 (2023). https://doi.org/10.1109/ACCESS.2023.3295245
8 S. Di Matteo et al.
4. Gautschi, M.e.a.: Near-threshold risc-v core with dsp extensions for scalable iot
endpoint devices. IEEE Transactions on Very Large Scale Integration (VLSI) Sys-
tems 25(10), 2700–2713 (2017). https://doi.org/10.1109/TVLSI.2017.2654506
5. Haj-Yahya, J., Wong, M.M., Pudi, V., Bhasin, S., Chattopadhyay, A.: Lightweight
secure-boot architecture for risc-v system-on-chip. vol. 2019-March, p. 216 – 223
(2019). https://doi.org/10.1109/ISQED.2019.8697657, https://www.scopus.com/
inward/record.uri?eid=2-s2.0-85065164064&doi=10.1109%2fISQED.2019.
8697657&partnerID=40&md5=dbd40305c40b567a1f6089561f3d8863, cited by: 17;
All Open Access, Green Open Access
6. Liguori, P.: Reed-muller-decoder, https://github.com/piliguori/
Reed-Muller-Decoder
7. Liu, Y., Briones, J., Zhou, R., Magotra, N.: Study of secure boot
with a fpga-based iot device. vol. 2017-August, p. 1053 – 1056 (2017).
https://doi.org/10.1109/MWSCAS.2017.8053108, https://www.scopus.com/
inward/record.uri?eid=2-s2.0-85034084065&doi=10.1109%2fMWSCAS.2017.
8053108&partnerID=40&md5=9cba3d9340f4b2807acc0ab560f9da3f, cited by: 24
8. Nannipieri, P., Crocetti, L., Di Matteo, S., Fanucci, L., Saponara, S.: Hard-
ware design of an advanced-feature cryptographic tile within the euro-
pean processor initiative. IEEE Transactions on Computers pp. 1–14 (2023).
https://doi.org/10.1109/TC.2023.3278536
9. Nannipieri, P., Matteo, S.D., Baldanzi, L., Crocetti, L., Zulberti, L.,
Saponara, S., Fanucci, L.: Vlsi design of advanced-features aes cryptoproces-
sor in the framework of the european processor initiative. IEEE Transac-
tions on Very Large Scale Integration (VLSI) Systems 30(2), 177–186 (2022).
https://doi.org/10.1109/TVLSI.2021.3129107
10. Sabt, M., Achemlal, M., Bouabdallah, A.: Trusted execution environ-
ment: What it is, and what it is not. vol. 1, p. 57 – 64 (2015).
https://doi.org/10.1109/Trustcom.2015.357, https://www.scopus.com/inward/
record.uri?eid=2-s2.0-84967164163&doi=10.1109%2fTrustcom.2015.357&
partnerID=40&md5=358ca116c45a82c981b7654c287b8ef6, cited by: 275; All Open
Access, Green Open Access
11. Shamsoshoara, A., Korenda, A., Afghah, F., Zeadally, S.: A sur-
vey on physical unclonable function (puf)-based security solutions
for internet of things. Computer Networks 183, 107593 (2020).
https://doi.org/https://doi.org/10.1016/j.comnet.2020.107593, https:
//www.sciencedirect.com/science/article/pii/S1389128620312275
12. Wang, W., Chen, Q., Yin, Z., Srivastava, G., Gadekallu, T.R., Alsolami, F., Su,
C.: Blockchain and puf-based lightweight authentication protocol for wireless med-
ical sensor networks. IEEE Internet of Things Journal 9(11), 8883–8891 (2022).
https://doi.org/10.1109/JIOT.2021.3117762
13. Zaruba, F., Benini, L.: The cost of application-class processing: Energy and perfor-
mance analysis of a linux-ready 1.7-ghz 64-bit risc-v core in 22-nm fdsoi technology.
IEEE Transactions on Very Large Scale Integration (VLSI) Systems 27(11), 2629–
2640 (Nov 2019). https://doi.org/10.1109/TVLSI.2019.2926114
14. Zhang, J., Qu, G.: Physical unclonable function-based key sharing via machine
learning for iot security. IEEE Transactions on Industrial Electronics 67(8), 7025–
7033 (2020). https://doi.org/10.1109/TIE.2019.2938462