 being a well-known example in the automotive embed- ded world of "how not to do things". Prevention of unauthorized (e.g., modified) firmware from running to eliminate threats from (1) loss of functionality (unauthorized re-purposing of the hardware for a different use), (2) loss of end-user data (e.g., providing third party access to unciphered end-user data), and (3) loss of uniqueness [protection of Intellectual Property Rights (IPR)] are supported by secure boot. Chapter 5 System software 185 The concept of secure boot implies that during the boot process (which we learned multiple boot stages for a modern os such as Linux), each image verifies the validity of the next image that is loaded and executed. There are multiple varieties of secure boot, defined by chip or IP manufacturers such as Intel and Arm. The underlying approaches, though, are mostly common and work on the assumption that none of the images, that are being loaded (including the bootloader itself), can be trusted. To do so, the boot process relies on digital signatures (Fig. 5-1). A digital signature centers around having two keys. A private key that is only known to the originator (author) of the source and used to "sign" a message (or a software image). The signing process generates a unique value ("signature") associated with the message that is appended to it. The public key (that, as the name indicates can be made public) can be used to validate the correctness of the image by comparison to the signature value. It is important to keep in mind that the public key can't be used to generate the signa- ture, but only to validate it. The combination of private and public key allows us to validate the origins of the image and to ensure that it was not modified-otherwise the signature would no longer be matching. During the manufacturing process, the public key of the first image (say, the bootloader) is stored (directly or indirectly) in a one-time programmable (fuse) memory of the device. The initial boot code itself is also stored in memory 