Autonomously booting system with encryption of the entire data storage and method for this

Abstract

Encryption system with an application-specific integrated circuit (ASIC) which has a permanent memory for the non-volatile storage of the operating system (OS) of a processor and software modules for encrypting the data memory of the processor and which has a hardware-implemented encryption algorithm, characterized in that a security module (SM) is integrated in the ASIC for autonomous booting of the operating system (OS), consisting of: - a symmetric cryptosystem (SK) for processing symmetric keys, - an asymmetric cryptosystem (AK) for the use of public and private keys, - a module for generating cryptographic hash functions (KH), - a module for the secure exchange of keys using hardware-implemented key exchange protocols (SP), - a key storage (SS) for the secure storage of root keys (WS), which are protected by appropriate measures in the physical structures of the ASIC and - a key management system (SMS) for the secure introduction of authenticated-encrypted key packets, and that the security module (SM) communicates with a central processing unit (CPU) via a communication interface (CS1), and that the central processing unit (CPU) communicates with at least one internal storage (IS) and one external storage (ES), as well as with at least one internal persistent storage (IP) and one external persistent storage (EP), such that the operating system (OS) is loaded by a second-stage bootloader (SSB) stored in the external persistent storage (EP), and then the operating system (OS) loads the applications, the second-stage bootloader (SSB) itself being decrypted and loaded by a first-stage bootloader (FSB) stored in the internal persistent storage (IP), and a public key (PUBOS) to verify the operating system (OS).and a symmetric key (KOS) to decrypt the operating system (OS), and that the contents of the internal memory (IS) and the external memory (ES) are decrypted by the security module (SM) during read accesses by the central management unit (CMU) or other modules integrated on the ASIC, and re-encrypted during write accesses by the same.

Description

[0001] The invention relates, according to claims 1 or 2, to an encryption system comprising an application-specific integrated circuit (ASIC) and a permanent memory for the non-volatile encrypted storage of software of a personal computer / embedded system. Furthermore, according to claim 13, the invention relates to a method for this.

[0002] Implementing a physical protection mechanism for desktop computers and notebooks relies on existing commercial hardware, which is present in the majority of such devices. The only hardware capable of supporting "Trust Bootstrapping" on desktop computers and notebooks is the "Trusted Platform Module" (TPM), which provides binding, sealing, and remote attestation for software. However, aside from the TPM, there is no other hardware support, and disk encryption keys cannot be stored in dedicated key registers but must be stored in RAM. In contrast, a custom implementation for a given embedded system can utilize specialized hardware that supports "Trust Bootstrapping" and provides dedicated storage for key material.Cryptographic operations can be performed directly on the dedicated memory without using the untrusted RAM.

[0003] Closed consumer platform hardware such as game consoles, cameras or boxes for receiving pay TV are equipped with physical protection mechanisms to prevent both the reading of secret keys embedded in the software images and "jailbreaking", e.g. to prevent an attacker from converting the closed platform device into a "general purpose" device on which user-defined code could be executed.

[0004] A number of related studies have already been conducted in the area of ​​secure code and data storage, particularly concerning permanent physical storage. Besides classic FDE, Microsoft BitLocker [see M. Corporation. Windows BitLocker Drive Encryption: Technical Overview. Microsoft, July 2009.] and MARK [see J. Götzfried and T. Müller. Mutual Authentication and Trust Bootstrapping towards Secure Disk Encryption, volume 17. New York, NY, USA, 2nd edition, 2014] can be characterized as complete full-time disk encryption solutions that provide "trust bootstrapping" involving at least two parties.The "Trusted Platform Module TPM" is not intended for application authentication or software encryption; key storage space is limited, and local and / or remote authentication can take place, with necessary key material being introduced into the module in plaintext.

[0005] In contrast, a custom implementation for a given embedded system can utilize specialized hardware that supports trust bootstrapping and provides dedicated storage for encryption keys. Cryptographic operations can be performed directly on this dedicated storage without using untrusted memory. The concept of storing encryption keys outside of internal / external storage has also been adapted for embedded systems.

[0006] Additionally, there are different approaches to protecting the key material for full-disk encryption solutions that store encryption keys entirely outside of RAM, e.g., Loop Amnesia [see Patrick Simmons. Security Through Amnesia: A Software-Based Solution to the Cold Boot Attack on Disk Encryption, in Annual Computer Security Applications Conference (ACSAC), Orlando, Florida USA, Dec. 2011, University of Illinois at Urbana-Champaign, ACM] and TRESOR [see T. Müller, F. Freiling, and A. Dewald. TRESOR Runs Encryption Securely Outside RAM, in 20th USENIX Security Symposium, San Francisco, California, Aug. 2011. University of Erlangen-Nuremberg, USENIX Association].

[0007] Another approach is a Safe and Secure Bootloader (see datasheet Atmel AT02333: Safe and Secure Bootloader Implementation for SAM3 / 4, published 06 / 2013), which requires a tight coupling between a bootloader and a firmware / application. This approach typically does not support complex key hierarchies and allows only one application. The application is encrypted only during an update and is subsequently stored as plaintext in the internal flash memory, which is protected by appropriate measures. Furthermore, cryptographic material is stored in plaintext in standard memory. Bootloader updates are not supported, and software-based access to the boot area is disabled. Hardware support allows switching between two versions of the same software.

[0008] Furthermore, a method and an arrangement for improving the security of encrypted computer data are known from DE 10 2009 048 756 A1. The method for improving the security of an encrypted data storage device from which a computer boots comprises a hard disk encryption program that is initially loaded from a boot area of ​​the data storage device and that requests user input (so-called CREDENTIALS) to continue the boot process and to decrypt the data storage device. The method further comprises a key device from which the system boots before booting from the boot area of ​​the encrypted data storage device, and which has a memory area secured by a smartcard PIN in hardware, in which the CREDENTIALS are stored in encrypted form. Specifically, the method known from DE 10 2009 048 756 A1 comprises the following steps: - Booting the computer from the key device, - Prompt for the user to enter the smartcard PIN, - Decrypting the CREDENTIALS using the smartcard hardware of the key device and loading them into the computer's RAM; - Continuation of the boot process from the data storage and thus with the hard drive encryption program; - Automatic transfer of the credentials to the hard drive encryption program when the program requests / demands credential entry. The key device known from DE 10 2009 048 756 A1 for carrying out the procedure comprises - an interface for connecting to the computer that allows the computer to boot from the key device before booting from the boot area of ​​the encrypted data storage, - a crypto processor that, based on a smartcard PIN, encrypts the CREDENTIALS and stores them on the key device, so that they are protected at the hardware level and - Means to decrypt the CREDENTIALS after entering the smartcard PIN, in order to then automatically pass them to the hard drive encryption program.

[0009] The solution according to DE 10 2009 048 756 A1 features a smartcard for storing the keys and an additional bootloader to verify the integrity of the actual bootloader and to provide the key for decrypting the hard drive by requiring the user to enter a short PIN. This solution requires a second party and therefore consists of two devices. A potential security vulnerability arises from the unencrypted communication between the smartcard and the bootloader or RAM, which can be intercepted. If physical access to the PC is possible, the entire hard drive can be copied and a listening device installed on the USB port, allowing data exchange to be intercepted and thus both the key and the data to be read.

[0010] Finally, German patent DE 100 569 89 A1 discloses an encryption system with an application-specific integrated circuit (ASIC) for encrypting and decrypting data streams using a CPU and, optionally, a coprocessor, as well as at least one hardware-implemented encryption algorithm. To create an ASIC that offers high security while simultaneously guaranteeing high data throughput, the ASIC features a PCMCIA interface with a direct connection to a PCMCIA card, which serves as a database for key information. Server systems require the rapid availability of numerous keys. Security necessitates that these keys reside in the ASIC's memory and are inaccessible to the host system. To prevent the loss of these keys in the event of a system failure, the key database is stored on a PCMCIA card.Should a system failure occur, the card can be easily inserted into a new system, eliminating the need for complex recovery procedures. Furthermore, the ASIC features an RS232 interface, enabling the direct reading of key data stored on smart cards into the ASIC. This prevents Trojans from intercepting key data on the PC and eliminates the possibility of reading the key data from the ASIC via a PC. The ASIC also includes an embedded flash option, preferably equipped with a write-protection mechanism, as well as an intrusion detection module and a module for generating random numbers based on physical effects. The flash option is necessary to provide non-volatile memory directly on the ASIC for the operating system and software.This has the advantage that no external storage is required that could be accessed. Thus, the integrated program flows are protected. The intrusion detection feature offers the advantage that any unauthorized access to the system is detected, the system is reset, and the extracted data is rendered useless to the attacker. The encryption and decryption units can be operated with different, non-static keys. Finally, the ASIC includes a key management module and a digital signature module. The ASIC achieves its full performance and comprehensive coverage of possible encryption tasks through its additional, separately integrated modules for digital signatures and certification, asymmetric encryption, key exchange protocols, one-way functions (hash algorithms), and standard symmetric algorithms.The availability of standard algorithms enables the use of ASICs within heterogeneous communication environments, thus ensuring compatibility with other products. Furthermore, it is designed that multiple PCI cards, each with an ASIC, can be connected in parallel, together establishing a functional connection to the smartcard and the PCMCIA backup card. Such a PCI card is particularly suitable for online encryption of high-bandwidth communication channels on the internet and in company intranets. This provides the foundation for VPN (Virtual Private Network) applications on gateways and routers. The card is also particularly well-suited for securing storage media (hard drives, backup systems, etc.) and encrypting database applications.Particularly when combined with a design where the program memory is write-protected and cannot be deactivated, specifically where the operating system, random number generator, serial number, certification key, and / or memory for initialization parameters for the analog circuits are write-protected, a particularly high level of security is achieved. The operating system and software running on the integrated CPU manage and control all processes on the ASIC. Therefore, there must be no way to read or manipulate this data. While this possibility would exist with external memory modules, the system avoids this and stores all software directly on the ASIC. A 256 KB flash memory is used for this purpose, permanently storing the operating system, initialization and configuration data, and other software.It is possible to subsequently install customer-specific software in the system memory to achieve higher performance in the end application. A portion of the memory is write-protected and cannot be disabled. This write-protected area includes parts of the operating system, the random number generator, the ASIC's serial number, certain certification keys (e.g., from trust centers), and various initialization parameters for the analog circuits. A 32-bit RISC processor is integrated on the ASIC itself. This processor is additionally equipped with a coprocessor for multiplication and division arithmetic. The processor controls the entire ASIC. Furthermore, it performs various other tasks, such as generating random numbers, creating hash functions, and executing customer-specific algorithms.Furthermore, it is possible to implement complex network protocols on the processor, thus enabling the ASIC to be operated together with a network ASIC, thereby creating a standalone system (network router with encryption functionality) independent of a host computer. The encryption system according to DE 100 569 89 A1 describes a security module in various configurations (coupling multiple ASICs) with different interfaces (PCMCIA, PCI, etc.), which serves as a retrofit option for standard hardware to improve IT security and, compared to a software-based implementation without a security module, also to increase data throughput.DE 100 569 89 A1 does not provide a suggestion for a secure and autonomous boot process, nor does it explicitly state the necessity of a secure boot procedure. Instead, it only describes an accelerator for cryptographic tasks related to hard drive encryption. Key material can be introduced either in plaintext or conditionally encrypted using appropriate key exchange protocols. The keys must be stored within the security module to protect them from unauthorized access. The maximum number of keys that can be used simultaneously is limited by the size of the key storage within the ASIC. Since both the boot process and the system's operation are monitored, it is sufficient to use the integrated internal permanent storage, which may be...Implemented as read-only memory, it is intended for the secure and tamper-proof storage of the software to be executed (OS, algorithms, interfaces, and application). The primary focus is on protecting the software from manipulation, which can be ensured through appropriate hardware measures to prevent compromising the correct functionality of the security module. Due to its design for use as a cryptographic accelerator, the method known from DE 100 569 89 A1 is not applicable for the secure booting of desktop computers or the secure and autonomous booting of embedded systems due to a lack of integration into the processes.

[0011] Furthermore, EP 2 741 228 A2 discloses a system-on-a-chip (SoC, i.e., the integration of all or a large part of the functions of a system onto a single chip (die)) for performing a secure reboot, an image-generating device therewith, and methods for doing so. The system-on-a-chip includes a first memory in the form of a ROM (Read Only Memory) to store a multitude of encryption keys / boot data, a second memory in the form of a Static Random Access Memory (SRAM) to store the decrypted data, and a third memory in the form of an (eFuse) to store a setting value for encryption keys. At least two memory controllers coupled to a CPU by means of switching are also provided. The first memory controller manages exclusive access to the first memory and all subsequent memory locations or registers.The second memory controller manages access to all memory locations and registers except the first. Switching the memory controllers during the boot process prevents the application running in the second memory from accessing sensitive data, such as the numerous encryption keys used to decrypt encrypted data stored in external non-volatile memory. Using an encryption key from the first memory, which corresponds to the encryption key set value from the set of available keys, data is loaded from the external non-volatile memory, decrypted, and the decrypted data is stored in the second memory. A boot process is then performed using the data stored in the second memory. The data can be encrypted using various methods.For example, a Data Encryption Standard (DES) algorithm (a symmetric key encryption algorithm with a 56-bit key), a Triple DES (TDES) algorithm (threefold repetition), an Advanced Encryption Standard (AES) algorithm, a SEED algorithm (an encryption algorithm that uses block encryption with a block size and key length of 128 bits), a Rivest Shamir Adleman (RSA) algorithm, or an ARIA algorithm (a block encryption method that uses a substitution-permutation network structure based on AES, with the same interface as AES: 128-bit block size with a key length of 128, 192, or 256 bits) can be used. The data, especially information about a bootloader, in the first memory is pre-stored by the manufacturer and cannot be modified by the user.The bootloader is a program that runs before an operating system starts, specifically to complete all (necessary) operations before the kernel starts. This means the operating system is divided into a kernel, where real-time instructions are executed. Furthermore, a framework is provided that transfers instructions contained in a program to the kernel, and a user interface is provided, which is controlled by the kernel and the framework. The bootloader refers to a program that prepares the hardware and starts the kernel. In particular, private bootloader information can also be stored in the primary memory. This private bootloader information can contain information required for system initialization. The bootloader can be split into a primary and secondary bootloader if there is insufficient memory available in the secondary memory.The system-on-a-chip (SoC) loads the encrypted data stored in the external memory, decrypts the data, and performs a boot process. Consequently, even if an unauthorized person hacks the data exchanged between the external memory and the SoC, the boot process remains unchanged, thus improving boot security. For example, the SoC can be used in an imaging device such as a printer, a multifunction peripheral, a fax machine, or a scanner. The SoC, known from EP 2 741 228 A2, describes a hardware-supported, single-stage boot process that ensures the confidentiality of the key material, the executed software, and the configuration in the first memory. Using this information, it then loads, authenticates, decrypts, and executes a further software stage from permanent storage.During the boot process, keys are used in plaintext, which does not compromise the key material but requires appropriate precautions (address space switching) in the memory controller to ensure the confidentiality of the key material. The software running in the second memory (OS + applications) does not use cryptographic methods, nor does it store key material in plaintext, as confidentiality cannot be guaranteed against third-party access via the ASIC's available interfaces. The encrypted and authenticated authentication code corresponds to an HMAC or ECDSA checksum, which is generated using a cryptographic hash function (e.g., SHA-1, SHA-512), a cryptographic algorithm (e.g., AES, ECC), and a key. This allows large amounts of data to be protected from alteration and manipulation by means of a short checksum.In the system-on-chip known from EP 2 741 228 A2, this checksum is calculated for the software image that is loaded into the second memory. This calculation relies on a plaintext key stored in the first memory, as a corresponding key is necessary for both generating and verifying such a checksum / signature. Authenticated-encrypted key packets require a plaintext key to perform authentication and decryption. During system startup, a corresponding hardware circuit blocks all communication with the outside world. This communication is only reactivated once the appropriate software has been loaded into the second memory, authenticated, decrypted, and started. Simultaneously, however, access to the first memory, which contains the necessary keys for the authenticated-encrypted key packets, is blocked.The single-stage hardware-assisted secure boot process is performed without the use of a security module, whereby the absence of a security module may lead to the compromise of static key material and therefore only short-lived session keys are used in the application.

[0012] Furthermore, US 8,484,452 B2 relates to a multi-operating-system boot device, a multi-operating-system boot program, and a multi-operating-system boot procedure. Originally, as stated in the introductory section of US 8,484,452 B2, operating systems were developed with the understanding that one operating system runs on a computer. Therefore, to allow multiple operating systems to coexist on a single computer, it is necessary to ensure that the computer resources managed by each operating system (memory, input / output device, etc.) are not destroyed. For example, if the second operating system is booted after the first, a boot loader is needed for the exclusive use of booting the second operating system without destroying the memory space of the first operating system that was previously activated.To prevent an interruption when the second operating system is running important programs such as a control program and an encryption program, and to increase security when loading the second operating system by preventing other programs running on the first operating system from accessing or modifying the memory contents of the second operating system, the multi-operating-system boot device according to US 8 484 452 B2 includes (1) a primary storage unit with a storage area with respect to which a storage space is defined; (2) a secondary storage unit for storing a second bootloader and the second operating system; (3) an operating system execution unit that causes a first bootloader to load the second bootloader and the second operating system from the secondary storage unit into the memory area of ​​the primary storage unit, which is defined as a first memory location managed by the first operating system with respect to the primary storage facility through a first context, wherein the loading is carried out by program execution of the first bootloader, which is to run under the first operating system, in the first context, which is a context displaying control information for a CPU (central processing unit) and a context for the first operating system, under the first operating system operating in the first context; and (4) a loader execution unit that causes the second bootloader to generate a context for the second bootloader that defines a third memory location with respect to the primary memory unit, wherein the third memory location comprises a memory area defined as a second memory location managed by the second operating system and a memory area in which the second bootloader and the second operating system have been loaded, and performs the switching from the first context to the context generated for the second bootloader by executing the second bootloader, which has been loaded into the memory area defined as the first memory location, under the first operating system operating in the first context, and that causes the second bootloader to load the second operating system, which has been loaded into the memory area of ​​the primary memory unit by the first bootloader, into the memory area of ​​the primary memory unit.which is defined as the second storage space contained in the third storage space, and generates a context for the second operating system by executing the second bootloader in the context for the second bootloader, and causes the second bootloader to switch from the context for the second bootloader to the context generated for the second operating system and to boot the second operating system in the context for the second operating system. Furthermore, the multi-operating-system boot device of US 8 484 452 B2 is characterized in that the second operating system stored in the secondary storage unit is encrypted, the second bootloader stored in the secondary storage unit has a function for decoding an encrypted second operating system, and the loader execution unit causes the second bootloader to execute the encrypted second operating system.The system, which was loaded into the memory area of ​​the primary storage unit by the first bootloader, decodes and loads a decoded second operating system into the memory area of ​​the primary storage unit, which is defined as the second memory location contained in the third memory location, by executing the second bootloader in the context for the second bootloader. Furthermore, the multi-operating-system boot device of US 8 484 452 B2 is characterized in that the second bootloader stored in the secondary memory unit has the function to check the second bootloader for tampering, and the

[0013] The loader execution unit causes the second bootloader to determine whether it has been tampered with by executing the second bootloader under the first operating system running in the first context. Finally, the multi-operating-system boot device according to US 8,484,452 B2 is characterized in that the second bootloader stored in the secondary storage unit has the function to check the second operating system for tampering, and the loader execution unit causes the second bootloader to determine whether the second operating system, which was loaded into the memory area of ​​the primary storage unit by the first bootloader, has been modified by executing the second bootloader in the context for the second bootloader.US 8 484 452 B2 (Mitsubishi Electric Corporation) thus describes a boot process for the sequential starting and parallel execution of multiple operating systems on one system.

[0014] From the article "Chip card" in "Wikipedia, the free encyclopedia," experts are familiar with smart cards, which also feature an application-specific integrated circuit and serve as secure information and key storage. Experts know that the data stored on smart cards is protected against unauthorized manipulation and access, particularly through cryptographic methods such as encryption and signing, so that the stored data exists as authenticated and encrypted packets.

[0015] The Wikipedia article "Hybrid encryption" explains that hybrid encryption methods are used where only a symmetric key is encrypted using an asymmetric method, and the actual message is encrypted with this asymmetric key and the actual message with this symmetric key. This is because symmetric encryption methods are very fast even with large amounts of data, whereas asymmetric encryption methods are very slow and therefore only suitable for very small amounts of data. This approach also solves the key distribution problem while retaining the speed advantage of symmetric encryption.

[0016] US patent 2015 / 0012737A1 discloses a method for securely booting unsecured processors in a target system, based on a secure root of trust. This method generates a message authentication code from the boot code and sends it to the target processor. The initial boot code is stored in a more secure chip, such as a secure SoC FPGA, which forms the basis of the root of trust. The security chip sends the target processor an unpredictable nonce (a number or string used only once for authentication), ensuring that the correct response to each boot attempt is different. This prevents a simple replay attack, where the attacker would simply capture the correct response from a successful boot. The secure SoC FPGA is intended for expensive embedded systems.The security of the system described in US 2015 / 0012737A1 depends on the effectiveness of obfuscation of the initial code image. Since the algorithm used (AES-CBC), the symmetric key, and the result in the code are more or less traceable, it is significantly easier to disrupt or compromise the boot process. If the target processor is compromised, the attacker would have access to the key material in plaintext.

[0017] The solution according to US 8,756,417 B1 concerns a multi-mode Trusted Computing Platform TCP (TCP) which includes: a field-programmable gate array (FPGA) device with a Type 1 compliant root of trust (ROT), memory containing a Type 1 security boot image and at least one lower security boot image, and memory containing a Type 1-associated operating system image (OS) and at least one associated lower security operating system image (OS). The multi-mode Trusted Computing Platform TCP is configured to execute a multi-stage boot process that selects and initiates either a Type 1 TCP computing mode or a lower security computing mode, depending on the presence of one or more valid external inputs. A Type 1 platform is typically a dedicated computing platform designed to provide the highest level of security and safety, delivering only the intended functionality.The Multi-Level Assurance Trusted Computing Platform (MLA TCP) is a single computing platform that can be booted in a typical high-security mode according to the Type 1 standard or alternatively in a lower security mode. The necessary functions to understand the complete data flow, detect manipulations, and subsequently intervene would, according to the solution described in US 8,756,417 B1, require duplication of the actual system, and the resulting complexity is virtually impossible to verify. Furthermore, the solution described in US 8,756,417 B1 is designed as a monitoring solution for processors / products and can also be used as an accelerator, which necessitates integration during the product design phase.

[0018] Furthermore, EP 2 635 991 A1 discloses a multi-stage boot process in which the subsequent stage is verified by a preceding stage either by a signature or checksum. If this fails, a repair is attempted by a third party, and otherwise, replacement by a service technician is required. The cryptographic functions and keys are secured by appropriate hardware measures. However, the described solution is limited to the code and data of one or more compiled entities.

[0019] Finally, a two-stage boot process is known from US 2009 / 0 193 211 A1, which verifies a hash table with a signature algorithm and then partially compares data ranges with the hash values ​​from the hash table.

[0020] From a state-of-the-art perspective, various methods and arrangements for improving the security of encrypted computer data are known. Autonomous booting is generally not possible; instead, a second party (e.g., the user) or a third party (e.g., a certification authority / central server) is involved in the integrity check. Achieving complete coverage of all possible encryption tasks requires considerable effort. However, little attention has been paid to the fact that cryptographic primitives can be used to maintain the confidentiality of software stored on separate persistent storage. This persistent storage is easily accessible to attackers and lacks sophisticated physical protection. Furthermore, the integrity and authenticity of the software running on the main CPU must be guaranteed.

[0021] The invention is based on the objective of designing an encryption system in such a way that autonomous booting is enabled, in which all data and code are encrypted and secured by digital signatures and / or message authentication codes (MAC) and are therefore not manipulable / replaceable.

[0022] This problem is solved starting from an encryption system according to claim 1.

[0023] Furthermore, this task is solved starting from an encryption system according to claim 2.

[0024] Finally, according to claim 13, this task is solved by a method for an encryption system with a security module according to claim 1 or 2.

[0025] The encryption system / method enables autonomous booting, where the key material is only present in plaintext within the security module – otherwise it is encrypted – and encryption of all software packages. Furthermore, a flexible key hierarchy can be created, and authentication / integrity verification from the first-stage bootloader (FSB) / BIOS to the application (chain of trust) is enabled. Specifically, integrity verification of all data, user-selectable / fine-grained encryption, updating of key material (except the root key), and bootloader updates are possible.By binding parts of the software to the ASIC, it is more difficult to manipulate and eavesdrop; the security module can implicitly disable a debugging interface, and the generation of keys using a random number generator is hardware-supported (increasing entropy by exploiting physical effects such as noise).

[0026] The following are specific advantages of bootloaders: • Safety: Data transmissions are protected from random bit / byte flips by appropriate protocols. • Safety: Data and code are protected by error-correcting codes (ECC) in permanent memory. • Safety: Reading and writing flash images is made safe through appropriate processes. For example, during an update: There are always two valid versions of a software program. During an update, one of them is overwritten with the newer version and then executed to check if it runs correctly. If not, the old version is executed again, and the old image is restored. If it does run correctly, the old image is overwritten with the new version. Afterward, both software installations are synchronized. • Security: all data and code are encrypted and secured by appropriate signatures, making them unmanipulable / unreplaceable, etc., both during transport and bootstrapping, thus achieving security in all phases.

[0027] Further advantages and details can be found in the following description of preferred embodiments of the invention with reference to the drawing. The drawing shows: Fig. 1. The structure and modules of the security module, Fig. 2. the structure of the encryption system as a mobile solution, Fig. 3. The structure of the encryption system as an integrated solution, Fig. 4. An example of a key hierarchy with multiple applications and multiple keys per application. Fig. 5. An example of a boot process, Fig. 6. The different layers of the software for implementing a chain of trust for accessing the permanent storage and the security module. Fig. 7 a symmetrical key architecture in normal operation with different keys and Fig. 8a, b the writing speed of the different layers.

[0028] The solution is based on a specific attack model: an attacker has physical access to the system but limited capabilities for attacking the hardware. The attacker's goal could be to extract secrets or inject custom code or data that is processed within the structure of the original software.

[0029] For example, an attacker might want to replicate or decrypt the software of a navigation device in order to build an identical product (reverse engineering), or they might want to insert manually generated values ​​into a smart meter to manipulate the meter reading to the detriment of the electricity provider. In these state-of-the-art applications, an attacker has physical access to a flash chip, which serves as permanent storage for code and data. The attacker can read data stored on the flash chip and also modify data on the flash chip page by page. The attacker only needs a small budget, namely a microcontroller that can be connected to the flash via SPI (Serial Peripheral Interface) and send the appropriate commands.However, the system is generally not capable of connecting to a second party during the boot phase. An attacker cannot perform more sophisticated hardware attacks, such as chip probing or monitoring ASIC-internal registers, at runtime. These attacks generally require a much larger budget than simple physical attacks and are significantly more complex. Furthermore, it is assumed that an attacker cannot create images of the RAM while the system is running. This assumption is reasonable, as the RAM is implemented as SRAM and is part of the ASIC.

[0030] The in Fig. The safety module SM shown is part of the system and consists of the following modules, which are interconnected: 1. Symmetric Cryptosystem SK: Hardware accelerator for the application of cryptographic symmetric methods for encryption / decryption and ensuring the integrity and authenticity of data. The keys to be used for the operations are provided by the central key management system SV. For example, the following algorithms are implemented, but the invention is not limited to these: a. Advanced Encryption Standard (AES) b. Data Encryption Standard (DES) c. Cipher-based Message Authentication Code (CMAC) d. Hash-based Message Authentication Code (HMAC) 2. Asymmetric Cryptosystem AK: Hardware accelerators for the application of cryptographic asymmetric methods for encryption / decryption, ensuring integrity / preventing physical attacks, and are significantly more complex. Furthermore, they provide authentication and generate digital signatures using public-private keys. The keys used for operations are provided by the central key management (CSM). The following algorithms are preferably implemented: a. Elliptic Curve Cryptography (ECC) b. Elgamal c. Digital Signature Algorithm (DSA) d. Elliptic Curve Digital Signature Algorithm (ECDSA) 3. Cryptographic Hash Functions (KH): Hardware accelerators for calculating cryptographic hash values ​​using collision-resistant one-way functions, the results of which can serve as input for both symmetric and asymmetric cryptosystems (SK / AK). Furthermore, the SK and AK cryptosystems are designed to allow the input of hash values ​​generated by software hash functions. Preferably, the following algorithms are implemented in hardware: a. SHA-2 / SHA-3 (224 / 256 / 384 / 512 bits) b. BLAKE c. SMASH 4. Key Exchange Protocols (SP): Hardware module for the secure exchange of cryptographic key material over potentially insecure channels. Both symmetric and asymmetric exchange methods are supported, as the following exemplary list of implemented methods shows: a. Diffie-Hellman key exchange (DH) b. Elliptic Curve Diffie-Hellman key exchange (ECDH) c. Needham-Schroeder protocol 5. Key Storage SS: Secure permanent storage for storing one or more root keys for use in the included modules of the Security Module SM for decryption, authentication and integrity verification of encrypted and / or authenticated data, or for generating digital signatures, message authentication codes and encrypting plaintext data. 6. Key Management SV: Hardware module for the secure introduction of authenticated encryption (Authenticated Encryption / Authenticated Encryption with Associated Data) for use in the connected hardware modules of the Security Module SM. This means that authenticated encryption can be stored in insecure external data storage and decrypted and authenticated by the Key Management SV before use, so that the contained cryptographic material can be made available in plaintext to the other modules of the Security Module SM. The resulting plaintext key material is only accessible within the Security Module SM and is protected by appropriate hardware measures and interfaces to ensure this remains the case. The following authenticated encryption methods are supported, for example: a. AES Key Wrap b. Galois / Counter Mode (GCM) c. Encrypt-then-Authenticate-then-Translate (EAX)

[0031] The in Fig. The key hierarchy SH shown in Figure 4 is a possible logical representation of key materials that can be used for system operation. One or more root keys WS form the basis for one or more key hierarchies. The root keys WS are stored in plaintext in the internal permanent memory of the security module SM. Hardware measures prevent the key material from being read, such as preventing direct access via the central administration unit ZVE or hindering or preventing direct reading of the permanent memory using probes on the "die" (i.e., the logical structures of the ASIC) of the chip.

[0032] Furthermore, due to the almost unlimited resources available in the system, the key hierarchy SH can contain any number of branch keys ZS and any number of leaf keys BS.

[0033] Branch keys represent a logical indirection between root keys or other branch keys and can be used for the simple separation of cryptographic key material by placing the operational key material of different entities under different branch keys, thus achieving cryptographic separation between the entities.

[0034] Leaf keys (BS) represent the operational key material used for operations within the security module (SM). These can be added either directly via a root key (WS) or indirectly via branch keys (ZS) of the key hierarchy (SH).

[0035] All keys, with the exception of the root key WS, have been authenticated and encrypted using the procedures described in the key management section SV, by their predecessors (follow the arrow in reverse direction) in the key hierarchy SH. The corresponding key material must be wrapped in a package prepared for the key management section SV.

[0036] This wrapping is enclosed in curly braces ({}) in the key hierarchy SH of the Fig. 4 is displayed. In addition, the enveloping authenticated encryption of the packet is clarified by the subscript name of the predecessor key, which directly follows the curly bracket.

[0037] This method allows for the creation of arbitrarily shallow / deep key hierarchies SH, both statically and dynamically; i.e., the system allows for the direct use of root keys WS as well as the use of leaf keys BS at any depth of the key hierarchies SH.

[0038] The system is preferably available in two versions: an Integrated Solution IL, which is in Fig. 3 is shown, and a mobile ML solution which is in Fig. 2 is shown.

[0039] In the Integrated Solution IL, the safety module SM is integrated as a module in an Application-Specific Integrated Circuit (ASIC) on a die and connected to all other modules of the ASIC as necessary. The safety module SM is integrated via a communication interface KS1 designed for use in an ASIC, preferably a processor bus such as the Advanced Microcontroller Bus Architecture (AMBA).

[0040] Furthermore, the SM security module checks the integrity and authenticity of the software stored in the internal permanent storage IP during the boot process (BP, see step BP1) and thus ensures that no manipulations are made by any attackers.

[0041] Furthermore, the contents of the internal memory (IS) and the external memory (ES) are decrypted by the security module (SM) during read accesses by the central management unit (ZVE) or other modules integrated on the ASIC, and re-encrypted during write accesses by the same. This is intended to make direct data reading using probes and thus reverse engineering of the data and code more difficult or even impossible.

[0042] The internal permanent storage IP, which is preferably designed as an unchangeable permanent storage (such as a read-only memory (ROM)), preferably contains the first stage bootloader FSB during the boot process (see Fig. 5), which is responsible for initializing the hardware, loading, verifying and decrypting the next stage of the boot process BP, which is preferably software in the form of a Second Stage Bootloader SSB (see Fig. 5), which is stored in either internal or external permanent storage (IP / EP) in authenticated and encrypted form.

[0043] The significantly larger external permanent storage devices (EP) preferably contain the code and data for the second-stage bootloader (SSB), the operating system (OS), and one or more applications (APP) in authenticated and encrypted form. However, there is nothing preventing the integration of the aforementioned software into another internal permanent storage device (IP). In this case, both the internal permanent storage device (IP) and the external permanent storage device (EP) should be designed as modifiable permanent storage, for example, in the form of flash memory or an EEPROM, so that modifications are possible and no flexibility regarding application areas is lost.

[0044] Both internal memory (IS) and external memory (ES) are responsible for storing the code and / or data of the executed software. Regardless of their location, the contents of both memory types are encrypted and decrypted as needed using the security module (SM). These two memory types (IS / ES) are preferably implemented as SRAM or DRAM.

[0045] The Central Administration Unit (CAU) is responsible for the execution of the software (FSB / SSB / OS / APPs) and is preferably designed in the form of a processor similar to an ARM Cortex or MIPS.

[0046] As in Fig. As shown in Figure 2, the security module SM can alternatively be designed in the form of a smartcard SC or a USB stick, preferably as a mobile solution ML.

[0047] The communication link between the security module SM on the smart card SC and the central processing unit ZVE of the personal computer PC is established via a detachable communication interface KS2 commonly used in information technology, which is preferably designed as a smart card reader or USB interface.

[0048] In this configuration, it is not possible to encrypt the memory contents of the personal computer (PC) because there is no direct control over the data flow via the central administration unit (ZVE). The smartcard (SC) is provided to the central administration unit (ZVE) as a secure coprocessor for cryptographic tasks, so that cryptographic material does not have to be stored in plaintext on the connected storage media of the personal computer, but only in the form of authenticated and encrypted packets, which can only be used with the corresponding smartcard (SC) with an integrated security module (SM).

[0049] This method ensures that encrypted storage media (see full disk encryption) can be accessed by eavesdropping on the KS2 communication interface between the smartcard (SC) and a personal computer (PC). This allows an attacker to gain access to both the plaintext key material and the encrypted data, which they could have obtained without the user's knowledge. This effectively binds the cryptographic material to the respective smartcard (SC), which the user (similar to a house key) always carries with them, thus keeping it secure from potential attackers. The encrypted storage media are therefore worthless to the attacker, as they are unreadable without the corresponding smartcard (SC).

[0050] For both variants of the system, it is possible to use the in Fig. to fully or largely support the exemplary BP boot process shown in section 5.

[0051] In the integrated solution IL, the security module SM ensures the integrity and authenticity of the initially executed software component through hardware-implemented routines. These routines are described as BP1 in the boot process BP and comprise the following steps: 1. Calculation of a checksum for the software stored in the internal / external permanent storage IS / ES and subsequent comparison with a previously determined checksum. 2. If OK, the software should be executed; otherwise, access to the SM security module should be prevented by appropriate measures. 3. During execution, checksums of the executed software should be continuously compared with previous values, and appropriate measures should be taken if there is a difference.

[0052] The following steps in the boot process BP (identified by BP2, BP3 and one or more BP4 processes) are briefly outlined below: 1. Loading the successor software (for example, FSB loads SSB and SSB loads OS, etc.) into internal / external memory IS / ES. 2. Verification or integrity check using applied cryptographic methods such as digital signatures or message authentication codes using an A- / Symmetric cryptosystem (AK / SK). 3. If the verification is correct, decryption follows using the appropriate cryptographic method via an A- / Symmetric Cryptosystem (AK / SK). 4. Run the decrypted software.

[0053] The autonomously booting system is based on a standard ASIC and a real-time operating system. Most algorithms are implemented in hardware and driven by a suitable driver, but some are purely software implementations.

[0054] The system can be divided into two main components: the implementation of a hierarchical key tree and the various layers for accessing the flash chip. Below is a brief overview of how all components of the autonomously booting system work together. Fig. Figure 6 shows the different software layers for accessing the flash chips.

[0055] At the lower end, the Memory Technology Device (MTD) driver is responsible for communication with the hardware.

[0056] Depending on the flash chip, the driver must communicate via SPI bus (Serial Peripheral Interface) or via a parallel connection.

[0057] At the top of the MTD layer, the safety layer takes care of error correction.

[0058] Application code is stored on the flash chip using the safety layer and is encrypted directly and as a whole, since the security layer only allows encryption on a sector-wise basis.

[0059] The security layer is built on top of the safety layer and is seen by the upper layers simply as an ordinary block device. It transparently provides encryption and integrity checks on a sector-by-sector basis. Log files, for example, are written by the security layer because they can be written cyclically and because it is permitted to overwrite old data. This eliminates the overhead of a separate file system for log files, resulting in significant space efficiency.

[0060] At the top of the security layer, the Safe & Secure Flash File System (SSFFS) is responsible for providing high-level access for applications. This layer allows applications to perform basic file operations without requiring them to manage flash-specific details. The file system handles wear leveling, ensuring that files remain in a consistent state. Essential application data, such as configurations or volatile data, is stored on the flash chip using the file system layer.

[0061] In addition to the three layers above the MTD layer, the "Chain of Trust" is responsible for verifying applications during the boot process. The autonomously booting system was designed with a focus on the (secure) deployment of new application versions, for example, through the use of certain security mechanisms such as introducing redundancy in metadata and code partitions.

[0062] The focus is on preventing the extraction of secrets, for example, maintaining the confidentiality of code and data. The system is characterized by hardware support from a special user-specific integrated circuit (ASIC), which contains a built-in security module, and its interaction with the software.

[0063] This security module (SM) provides basic symmetric encryption routines, asymmetric signature generation routines, and routines for encrypting and decrypting key material. Furthermore, the SM security module manages to store the encryption master keys in appropriate registers, independent of RAM or the flash chip.

[0064] This assumes that the ASIC with the security module can be trusted, i.e., physical attacks such as "fault injection" are excluded, and it is shown that the autonomously booting system according to the invention resists certain attacks.

[0065] The system concept of the autonomously booting system in more detail is: - Based on a low-level driver and software applications of cryptographic primitives, a symmetric key hierarchy was designed and implemented. The hierarchy's master key is securely stored in the hardware registers of the security module (SM), while the other keys are encrypted with their master key and stored in RAM. A security layer providing confidentiality through sector-wise data encryption was designed and implemented. In addition to encryption, data integrity is also ensured on a sector-wise basis, as well as by calculating a message authentication code for each sector. This code is then read and verified during the reading process. - At the top of the security layer, a file system was designed and implemented which, in addition to basic file system operations, guarantees consistent files at all times, performs "basic wear leveling" for the underlying flash chip, and is capable of handling flash chips that are both page-wise and page-wise erasable. A scheme was designed to partition the flash chip for the various applications from potentially different vendors and for the operating system (OS). During the boot process, a "chain of trust" (see Fig. 6) created by verifying digital signatures of user code, which is to be loaded in the next step.

[0066] The ASIC's Security Module (SM) can in some respects be compared to the Trusted Platform Module (TPM) for desktop computers and notebooks [Trusted Computing Group, Incorporated. TPM Main: Part 1 Design Principles, Specification Version 1.2, Revision 116 edition, Mar. 2011]. Many features, such as a dedicated security memory for the master key of a device-specific encryption and the ability to generate digital signatures, are shared between the Security Module and TPMs.

[0067] However, there are many differences, as the SM security module does not support asymmetric encryption and hashing, whereas TPMs, in their minimal configuration, do not support symmetric encryption algorithms. A detailed security evaluation of the SM security module considered a wide range of attack scenarios and patterns, such as physical access to the flash chip, access to the RAM, and downgrade attacks.

[0068] Symmetric keys are used to encrypt the various parts of the application, namely the code, the data, and the log partition, and optionally for sector-wise integrity checks using the CMAC algorithm. The requirements for a symmetric key hierarchy essentially state that multiple parties involved do not trust each other and are not permitted to access each other's software.

[0069] The following requirements were met in detail: Different interest groups must have the opportunity to install their own application software without having access to the operating system code. - Code and data to be stored on the flash chip must be encrypted. Keys must never be exposed in unencrypted form in RAM, but only in wrapped form, i.e., authenticated-encrypted key packets. Code in RAM is considered secure. The operating system handles the separation of applications from each other.

[0070] Fig. Figure 7 shows a symmetrical key architecture in normal operation with different keys that depend on each other.

[0071] During normal operation, i.e., after the operating system has started, the root of the key hierarchy, and a single master key per device, are randomly generated, with each key in the hierarchy being wrapped, meaning that it is encrypted with its parent key.

[0072] At the in Fig. In the tree shown in section 7, there is one key for the operating system (OS) and two keys for customer-defined applications. The key of the first application is K. APP1 It has four further subkeys which are wrapped with the application key, and a specific part of this application is used for finer granular control of the encryption.

[0073] In particular, the keys K Code , K Data and K Log to encrypt the partitions on the flash chip, and the key K CMAC Used to ensure integrity.

[0074] Using subkeys for a specific application makes sense because if the subkey is compromised, only the branch that has the compromised key as its parent needs to be removed.

[0075] The boot process and loading routines are as follows. The operating system (OS) is loaded by a second-stage bootloader (SSB) (see Fig. 5) loaded, and then the operating system (OS) loads the applications.

[0076] The Second Stage Bootloader (SSB) itself is decrypted and loaded by the First Stage Bootloader, and requires a public key to verify the operating system and a symmetric key to decrypt the operating system.

[0077] While the symmetric key KOS is stored directly in the flash memory, the public key PUBOS is in a keyring within the SSB image to prevent unauthorized modifications.

[0078] The operating system (OS) is booted as follows: 1. PUBOS is used to verify the OS signature. 2. KOS is added to an interim SSB key hierarchy. 3. The encrypted operating system code is loaded into RAM, decrypted there, and started.

[0079] Once the operating system (OS) has booted, applications can be loaded. The OS requires a public key for each application it wants to load. These public keys are stored in a keyring within the operating system image to prevent unauthorized modifications. In contrast, the symmetric keys of each application are stored directly in flash memory. An application is loaded as follows: 1. The application's metadata is loaded into RAM. 2. PUB APPn is used to verify the application signature. 3. The main key of application K APPn and the subkeys K Code , K CMAC , K Data and K Logare added to the operating system key hierarchy. 4. Block device-based devices for the data and log partitions are identified using the key K. Data and K Log generated. If integrity checking has been enabled, K CMAC also passed to the block device driver. 5. The data partition's file system is mounted using the passed parameters. 6. The encrypted application code is loaded into RAM, decrypted there, and then started.

[0080] The keys added to the key hierarchy are persistent throughout the lifetime of the application and are implicitly used by the application using the block device driver.

[0081] Encryption and integrity checking are performed as follows. The security layer is capable of encryption with AES-128 [see J. Daemen and V. Rijmen. The Block Cipher Rijndael, in J.-J. Quisquater and B. Schneier, editors, Smart Card Research and Applications, volume 1820 of Lecture Notes in Computer Science, pages 277-284, Springer Berlin Heidelberg, 2000] either in CBC-ESSIV operating mode [National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation, special publication 800-38a edition, Dec. 2001], or in XEX operating mode [P. Rogaway. E_cient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC, in Advances in Cryptology - ASIACRYPT 2004, volume 3329 of Lecture Notes in Computer Science, pages 16-31].

[2004] . The XEX operating mode is usually enabled.

[0082] When using CBC-ESSIV, the initialization vector of each disk sector is determined by encoding the respective disk sector number, i.e., the flash page number. It is important to note that the disk sector number is not based on the offset from the start of the partition, but rather on the global offset from the beginning of the flash memory. This design choice prevents the repetition of initialization vectors for two different partitions.

[0083] In XEX operating mode, the "tweak" for each disk sector is determined by encrypting the respective disk sector number, analogous to how it is done in CBC-ESSIV. The integrity of an application and its metadata is verified using the ECDSA signature and an asymmetric key. Code and metadata do not change frequently and can therefore be verified with a static signature.

[0084] In contrast, data changes frequently, so its integrity cannot be easily verified using a static signature. If data integrity assurance is enabled, a CMAC tag is generated for each sector after any sector encryption during a write operation. During each read operation, the CMAC tag is generated in exactly the same way as during a write operation and compared to the appended CMAC tag.

[0085] If both match, the sector is potentially decrypted and written back to memory.

[0086] If the tags do not match, decryption will not be performed and an input / output error will be returned to the caller.

[0087] A CMAC tag verification error can have several causes. If everything is implemented correctly and error correction is working as intended, a faulty integrity check is a serious indicator of manipulation and should be addressed by the application developer, for example by triggering an alarm and halting the processor.

[0088] However, faulty integrity checks can also result from a faulty implementation. In particular, the integrity check is most likely to fail if a sector that has not been previously written to is read. For this reason, an application developer using the data link layer's integrity checking functionality must ensure that read operations are only performed after at least one write operation to the same sector.

[0089] Preferably, the security and backup flash file system SSFFS was used (see Fig. 6) Designed for very small flash memory, for example, flash memory with a total size of only one megabyte. It works with partitions that have a size of 128 or even 64 kilobytes.

[0090] Furthermore, it was designed to work with raw flashes, i.e., to perform erase operations, prevent modifications of entire flash pages, and ensure that pages of the flash memory are erased evenly.

[0091] The main difference between a regular file system and a flash file system is that the latter has to take care of erasure and perform wear leveling, i.e., erasing the flash sectors must be done evenly.

[0092] Furthermore, the file system does not have a journal or other log information, but it ensures that each file is in a consistent state at all times.

[0093] To achieve this, the files are organized in the form of a tree with a static depth. A node within the tree is either a data node, which contains the actual file data, or an indirect node, which references other nodes. The root node, also called a metanode, has a statically defined number of pointers to indirect nodes, doubly indirect nodes, and triple indirect nodes.

[0094] The remaining pointers are interpreted as pointers to data nodes.

[0095] This concept was based on a Flash-Friendly File System (F2FS) [see JY Hwang. Flash Friendly File System (F2FS), Embedded Linux Conference, Feb. 2013], and has the advantage that data stored at a specific depth within the tree always remains at that depth, which is important for garbage collection (automatic memory management, which in software and information technology refers to automatic memory management that minimizes the memory requirements of a computer program).

[0096] Furthermore, the offset for piecewise conversion can be performed in constant time with this approach. A file is split into pieces and distributed to the data nodes of this tree. The file nodes are physically stored on the flash chip using the security layer. It is ensured at all times that nodes of the same depth are stored with the same flash erase size to simplify garbage collection. This measure was based on LogFS [see J. Brockmeier. LogFS: A new way of thinking about flash filesystems, May 2007].

[0097] In principle, file consistency is guaranteed by writing the modified nodes from the ends (leaves) to new memory locations near the metanode. Until this point, the old nodes are marked as unreferenced, and consequently, after an unexpected reboot, at least one valid tree is found for each file.

[0098] It is ensured that no node is missing in such a tree, since the metanode is written last, and the file corresponding to the tree is in a consistent state because nodes are never modified.

[0099] The entire system is then evaluated with regard to security and performance. Regarding physical security, it is assumed that an attacker can read data stored on the flash chip and, furthermore, that they have the ability to modify data stored on the flash chip page by page. If an application has all security measures enabled, the attacker can only obtain metadata for that application.

[0100] Although the attacker has access to the keys for each application, he is unable to decrypt them because he has the K MasterThe user does not know the key used to encrypt the application. Consequently, they cannot obtain the master key for this application and are therefore unable to decrypt the other keys. Since they cannot obtain the encryption keys for the code and the data partition, they are unable to decrypt these partitions.

[0101] Assuming that all partitions of an application are encrypted using the XEX operating mode, manipulation of both the code and the data is impossible. Therefore, it is impossible for an attacker to force any specific behavior that would lead to the disclosure of the secret key material.

[0102] Nevertheless, an attacker could attempt to violate the integrity properties of an existing application, but this would be immediately detected when the code, metadata, and keys are booted. Essentially, the booting of each level is verified by its predecessor, and therefore the current level cannot be changed without altering the previous one. There are only a few components for each application that are not included in the ECDSA signature: the data and log partitions. If CMAC integrity checks are enabled, any manipulation of the data and log partitions will be detected as soon as the manipulated Flash page is reread.

[0103] All manipulations are either impossible or cannot be achieved due to the integrity checks. They are detected either immediately during the boot-up process or at the latest when the respective Flash page is read. This applies without exception only to manipulations aimed at injecting attacker-specific code or data.

[0104] While this can be completely prevented, the autonomously booting system is vulnerable to another type of attack: downgrade attacks, in which the attacker attempts to introduce pre-existing data that is not of their choosing. If an attacker has access to an outdated version of the flash chip, for example, because they made a copy in the past, they can downgrade each application separately. This works because the signature is verified only for each application, and not for all applications combined.

[0105] A prerequisite for this attack is that the public key, which resides within the operating system (OS) or the second-state bootloader (SSB), has not been changed in the meantime. If the public key has been altered, an attacker cannot downgrade individual applications without also downgrading the operating system (OS) or the second-state bootloader (SSB). Downgrades to other partitions of an application can be performed sector by sector.

[0106] The only requirements are that the sector of the new and old versions must have the same position on the flash chip, and that the encryption key and the CMAC key have not been changed in the meantime.

[0107] Since integrity checks are performed only on a sector-by-sector basis, sectors can be swapped independently of other sectors. The positions must be preserved because the initialization vector for each sector depends on the absolute sector number, and therefore an incorrect position during decryption would lead to an incorrect result.

[0108] In summary, downgrade attacks of the entire application, and even sector-by-sector attacks of partitions, are entirely possible and cannot be prevented by the autonomously booting system. This is primarily due to the lack of a second party that could perform remote attestation, i.e., verify that the currently released version is running. However, since the attacker does not know the data or code they intend to inject via a downgrade attack, the attack surface is quite limited.

[0109] All previous physical attacks were limited to the (external) flash chip. For the implementation of the autonomously booting system, it was assumed that the (external) flash memory was untrusted and the internal RAM was trusted.

[0110] The following section considers the worst-case scenario: what an attacker is capable of doing if they gain access to the contents of RAM while the system is running, such as with a cold boot attack [see JA Halderman, SD Schoen, N. Heninger, W. Clarkson, W. Paul, JA Calandrino, AJ Feldman, J. Appelbaum, and EW Felten. Lest We Remember: Cold Boot Attacks on Encryptions Keys. In Proceedings of the 17th USENIX Security Symposium, pages 45-60, San Jose, CA, Aug. 2008, Princeton University, USENIX Association]. A cold boot attack involves freezing memory cells, which then retain their state for an extended period and can be read by another system.

[0111] Naturally, the data stored in memory depends heavily on the application currently running. It can be assumed that the complete code of the executed software can be read in this way. However, the key material is packaged in so-called key packets and stored in RAM. These can only be unpacked and used in the corresponding hardware registers / modules.

[0112] The only keys stored in plaintext in RAM are the public keys used to verify the signatures of the various applications. Because these keys are public, stealing them offers no benefit to an attacker. In principle, an attacker can obtain the entire contents of RAM in this way. The RAM contents consist of the code and data of the currently running applications.

[0113] Nevertheless, it is unable to obtain additional code and data from applications that are not currently running, as it lacks access to the necessary decryption keys for these applications. To completely prevent the extraction of information (code and data) from RAM, more complex countermeasures are necessary, such as encrypting the RAM [see P. Peterson. Cryptkeeper: Improving security with encrypted RAM. In IEEE International Conference on Technologies for Homeland Security (HST), pages 120-126, Nov 2010].

[0114] In Fig. 8a and Fig. Section 8b shows the writing speed of the different layers.

[0115] In Fig. Figure 8a plots the time required over the continuously growing amount of data to be written to the external storage ES. Fig.Figure 8b shows the data rate. The write time is dominated by the time required to write to the external storage ES. Write accesses via the safety layer and security layer are just as fast as direct write accesses to the flash memory (MTD device).

[0116] This is evident in both diagrams from the fact that all three curves overlap. Write operations via the SSFFS file system are generally four to five times slower than write operations on the lower layers because more flash memory pages need to be written than those containing the actual data. The write time of the SSFFS file system is dominated by the number of nodes that need to be written in addition to the actual data nodes. For example, a meta-node must be rewritten with every change, and possibly an inner node as well.

[0117] The impact of enabling CMAC integrity checks on the security layer is not measurable because all calculations are performed entirely in hardware. When CMAC checks are used in conjunction with the SSFFS file system, the file system is slightly slower than without CMAC checks, as changes in the tree structure have a greater impact. This is due to the fact that indirect nodes are created earlier if fewer pointers are available per node.

[0118] In summary, the file system's write speed of five kilobytes per second is acceptable when considering the supported functionalities of the file system.

[0119] A characteristic of the autonomously booting system is that the system must perform its work without interaction from other people or entities and must ensure the integrity and authenticity of the executed software. A consequence of this characteristic is that, in the example implementation, it is possible to install older software, which essentially means that security vulnerabilities or errors in older software versions can be exploited, even if a newer version has already been installed, by overwriting the current software with an older version.

[0120] In a further development of the invention, this problem can be solved by, for example, introducing a hardware counter that only allows read and increment operations, but does not support write or decrement operations. Software would then only be executed if the version matches the value in the hardware counter.

[0121] The system allows for receiving updates and the installation of functions / routines capable of installing these updates. An interface for updating applications can be provided to implement these functions.

Claims

[1] Encryption system comprising an application-specific integrated circuit (ASIC) which includes a permanent memory for the non-volatile storage of the operating system (OS) of a processor and software modules for encrypting the data memory of the processor and which includes a hardware-implemented encryption algorithm, characterized by , that a security module (SM) is integrated into the ASIC for autonomous booting of the operating system (OS), consisting of: - a symmetric cryptosystem (SK) for processing symmetric keys, - an asymmetric cryptosystem (AK) for the use of public and private keys, - a module for generating cryptographic hash functions (KH), - a module for the secure exchange of keys using hardware-implemented key exchange protocols (SP), - a key storage (SS) for the secure storage of root keys (WS), which are protected by appropriate measures in the physical structures of the ASIC and - a key management system (SMS) for the secure introduction of authenticated-encrypted key packets, and that the security module (SM) communicates with a central processing unit (CPU) via a communication interface (CS1), and that the central processing unit (CPU) communicates with at least one internal storage (IS) and one external storage (ES), as well as with at least one internal persistent storage (IP) and one external persistent storage (EP), such that the operating system (OS) is loaded by a second-stage bootloader (SSB) stored in the external persistent storage (EP), and then the operating system (OS) loads the applications, the second-stage bootloader (SSB) itself being decrypted and loaded by a first-stage bootloader (FSB) stored in the internal persistent storage (IP), and a public key (PUBOS) to verify the operating system (OS).and a symmetric key (KOS) to decrypt the operating system (OS), and that the contents of the internal memory (IS) and the external memory (ES) are decrypted by the security module (SM) during read accesses by the central management unit (CMU) or other modules integrated on the ASIC, and re-encrypted during write accesses by the same. [2] Encryption system comprising a permanent storage for the non-volatile storage of the operating system (OS) of a personal computer (PC) and software modules for encrypting the data storage of the personal computer (PC) and which has a hardware-implemented encryption algorithm, characterized by , that for autonomous booting of the operating system (OS) a security module (SM) in the form of a smart card (SC) or a USB stick is designed, consisting of: - a symmetric cryptosystem (SK) for processing symmetric keys, - an asymmetric cryptosystem (AK) for the use of public and private keys, - a module for generating cryptographic hash functions (KH), - a module for the secure exchange of keys using hardware-implemented key exchange protocols (SP), - a key storage (SS) for the secure storage of root keys (WS), which are protected by appropriate measures in the physical structures of an ASIC / Smartcard (SC) and - a key management system (SMS) for the secure insertion of authenticated-encrypted key packets, and that the security module (SM) communicates via a communication interface (CS2) with a central processing unit (CPU) of the personal computer (PC), such that the operating system (OS) is loaded by a second-stage bootloader (SSB) stored in external permanent storage (EP), and then the operating system (OS) loads the applications, the second-stage bootloader (SSB) itself being decrypted and loaded by a first-stage bootloader (FSB) stored in internal permanent storage (IP), and a public key (PUBOS) to verify the operating system (OS), and a symmetric key (KOS) to decrypt the operating system (OS),required and that the contents of the internal memory (IS) and the external memory (ES) are decrypted by the security module (SM) during read accesses by the central management unit (ZVE) or other modules integrated on the ASIC, and re-encrypted during write accesses by the same. [3] Encryption system according to claim 1, characterized by , that one or more internal storage devices (IS) as well as one or more external storage devices (ES) are operated in encrypted form via the security module (SM), such that the content is encrypted and thus the encrypted storage devices (IS, ES) are considered trustworthy. [4] Encryption system according to claim 1 or 2, characterized by , that both the internal permanent storage (IP) and the external permanent storage (EP) are considered untrusted and that the data is stored in an authenticable encrypted form, or at least in an authenticable form. [5] Encryption system according to claim 1 or 2, characterized by , that key material outside the security module (SM) is wrapped in an authenticated-encrypted key packet and the contained key material can only be used in plaintext within the security module (SM). [6] Encryption system according to claim 1 or 2, characterized by , that for the use of the safety module (SM) in conjunction with inherently insecure permanent storage devices, at least one software layer for correcting unintended changes to the contents of permanent storage devices using error-correcting codes for bit flips / byte errors is provided as a safety layer, and at least one software layer for encrypting the data with subsequent authentication or integrity assurance of the encrypted data is provided as a security layer. [7] Encryption system according to claim 6, characterized bythat one or more key hierarchies (SH) are provided which are based on one or more of the root keys (WS) stored in the key store (SS) and the direct successors are authenticated and encrypted with this key material. [8] Encryption system according to any one of claims 1 to 7, characterized by that the root keys (WS) are not accessible outside the security module (SM). [9] Encryption system according to claim 6, characterized by , that branch keys (ZS) are authenticated and decrypted by their respective predecessors in the key hierarchy within the security module (SM), and that the contained key material can be used for the decryption / encryption of further key packages for branch keys (ZS) and leaf keys (BS). [10] Encryption system according to claim 9, characterized by, that leaf keys (BS) are authenticated and decrypted by their respective predecessors in the key hierarchy within the security module (SM) and that the contained key material can be used for the decryption / encryption of code or data. [11] Encryption system according to claim 1 or 2, characterized by that the Central Administration Unit (CAU) considers the integrated security module (SM) or in its encapsulating form as a smartcard (SC) as a coprocessor for the performance of cryptographic tasks. [12] Encryption system according to claim 1 or 2, characterized by, that an initial software (FSB) is checked for at least its integrity and authenticity before execution, that each subsequent software stage is authenticated, integrity-checked, and decrypted by the preceding software using the Security Module (SM), or at least authenticated and integrity-checked, so that the integrity, authenticity, and confidentiality of the system's executed software is ensured during the boot process. [13] Method for an encryption system with a security module (SM) according to claim 1 or 2, wherein: - secure handling of cryptographic key material outside the security module (SM) is ensured through the use of authenticated-encrypted key packets, - the integrity, authenticity and confidentiality of the executed software through the introduction of a secure autonomous boot process (BP) with hardware-implemented routines that perform the following steps:

1. Calculation of a checksum for the software stored in the internal / external permanent storage (IS / ES) and subsequent comparison with a previously determined checksum, 2. If the checksums match, the software is executed; otherwise, access to the security module (SM) is blocked.

3. During execution, checksums of the executed software are continuously compared with previous values, and if a difference is found, appropriate measures are taken, including ensuring that - secure communication is achieved through the use of secure key exchange protocols, - arbitrarily deep key hierarchies can be built using the root keys (WS), so that the implementations are not unnecessarily restricted to just one application, and - The extensibility of the implemented methods is achieved through the retrofitting of cryptographic methods in software, thus ensuring integrity-assured, authenticated, and encrypted storage in untrusted storage, such that the operating system (OS) is loaded by a second-stage bootloader (SSB) stored in external permanent storage (EP), and then the operating system (OS) loads the applications, whereby the second-stage bootloader (SSB) itself is decrypted and loaded by a first-stage bootloader (FSB) stored in internal permanent storage (IP), and a public key (PUBOS) to verify the operating system (OS), and a symmetric key (KOS) to decrypt the operating system (OS).required and that the contents of the internal memory (IS) and the external memory (ES) are decrypted by the security module (SM) during read accesses by the central management unit (ZVE) or other modules integrated on the ASIC, and re-encrypted during write accesses by the same. [14] Method according to claim 13, characterized by , that the boot process (BP) includes the following steps:

1. Loading the successor software, whereby a First Stage Bootloader (FSB) loads software in the form of a Second Stage Bootloader (SSB), and the Second Stage Bootloader (SSB) loads the operating system (OS), and the operating system (OS) loads one or more applications into the internal / external memory (IS / ES).

2. Verification or integrity check using applied cryptographic methods such as digital signatures or message authentication codes using asymmetric / symmetric cryptosystems (AK / SK).

3. If the verification is correct, decryption follows using an appropriate cryptographic method via an asymmetric / symmetric cryptosystem (AK / SK).

4. Run the decrypted software.

Images