Systems and methods for storing data records to be protected

Abstract

Systems and methods for storing data records to be protected. A system (100) for controlling access to data records (111, 112) to be protected is described. The system (100) includes a secure runtime environment (103) that is configured to implement decryption software (103), wherein the decryption software (103) is configured to decrypt an encrypted data record (111) to be protected and store it decrypted on a secure storage unit (106). The secure storage unit (106) is configured such that access to the secure storage unit (106) is only possible through the secure runtime environment (103). The secure runtime environment (103) is also configured to prevent the decryption software (103) from being implemented again.

Description

Technical Field

[0001] The present invention relates to a system and a corresponding method for storing data records to be protected and for providing secure access possibilities to the data records to be protected, in particular to keys for encrypting data. Background Art

[0002] On networked devices, especially on household devices, one or more data records to be protected can be stored, and the one or more data records to be protected should be protected against unauthorized access. Examples of data records to be protected are: a WIFI password with which the device can establish a WLAN connection to a WLAN access point; and / or a private TLS (Transport Layer Security) key that can be used to authenticate the device on a backend server and / or to encrypt data when communicating with the backend server. Summary of the Invention

[0003] This document is devoted to the following technical task: to provide a system and a corresponding method with which data records to be protected can be efficiently and securely protected against unauthorized access.

[0004] This task is solved respectively by the subject matter of the independent patent claims. Advantageous embodiments are defined especially in the dependent patent claims, described in the following description or shown in the accompanying drawings.

[0005] According to one aspect of the invention, a system for controlling access to (at least one) data record to be protected is described. Here, the data record to be protected can include, for example, an encryption key and / or an authentication key (such as a TLS key) and / or a password (such as a WLAN password). The data record to be protected can be configured to enable secure communication between a device (including the system) and other units (such as a server). The system can be implemented on one or more microprocessors.

[0006] The system includes a secure runtime environment which is set up to implement decryption software. The secure runtime environment can in particular be a so-called Trusted Execution Environment (TEE). Exemplary secure runtime environments are: TrustZone of ARM; Platform Security Processor of AMD; Secure Extension Mode of AMD; and / or Trusted Execution Technology and / or Software Guard Extension of Intel.

[0007] The decryption software is configured to: decrypt the encrypted data record to be protected and store it decrypted on a secure storage unit. The decryption software can in particular be configured to: read the encrypted data record to be protected from another (first) storage unit; decrypt the data record to be protected; and store the decrypted data record to be protected on a secure (second) storage unit. Here, the other (first) storage unit can be a non-volatile memory (such that the encrypted data record to be protected is also stored in the other (first) storage unit before the system starts running and / or after the system stops running). Preferably, the decryption of the encrypted data record to be protected is only carried out when the system starts running, in particular such that the data record to be protected does not exist in unencrypted form before the system starts running and / or after the system stops running.

[0008] The secure storage unit is part of the system. Preferably, the secure storage unit is part of the secure runtime environment. Preferably, the secure storage unit is a RAM (Random Access Memory) which is substantially and / or fixedly (in particular cannot be removed without damage) built into the system or into the secure runtime environment. The secure storage unit is configured such that access to the secure storage unit is only and / or only possible through the secure runtime environment. Preferably, the secure storage unit includes a RAM memory. Alternatively or additionally, the secure storage unit can include a volatile memory.

[0009] The secure runtime environment is also configured to: prevent (during the operation of the system) the re-implementation of the decryption software. The secure runtime environment can in particular be configured such that the decryption software can only be implemented exactly once (in particular when the system starts running) during the uninterrupted operation of the system and is then (for the remaining, uninterrupted operation of the system) prevented.

[0010] The system can efficiently implement a monitored access to the data records to be protected. In particular, it is possible to reliably avoid that an attacker accesses the decrypted data records to be protected; and that an attacker can decrypt the encrypted data records to be protected (since an attacker cannot technically have access to the decryption key).

[0011] The decryption software can be configured to use a data record key for decrypting the encrypted data records to be protected. Here, the data record key can be configured as a hardware key (such as a dongle). The hardware key can be integrated, for example, in a cryptographic accelerator. Alternatively or additionally, the hardware key can be extracted in a component that can be separated by a secure runtime environment, in particular in hardware (HW) that is only known to the secure runtime environment (since the secure runtime environment is configured in such a way). If necessary, this can be achieved by means of a USB controller.

[0012] Alternatively or additionally, the system can be configured such that access to the data record key is only possible via the decryption software. This can reliably ensure that an attacker does not gain access to the data record key and thus decrypt the encrypted data records to be protected.

[0013] The secure runtime environment can be configured to store a flag for the feasibility of the decryption software. Here, the flag can be reliably stored in a secure storage unit.

[0014] The secure runtime environment can be set up to change the state of the flag in order to prevent a renewed implementation of the decryption software and / or in order to block the decryption software. For example, the flag can be set (or reset) (when the system starts up) when the decryption software is first called (for example, before or after the first call to the decryption software) in order to block the decryption software.

[0015] The secure runtime environment can be set up to check the state of the flag (always first) before implementing the decryption software and to implement or block the implementation of the decryption software based on the state of the flag. In this way, it is possible to efficiently and reliably cause the decryption software to be implemented exactly once during the operation of the system.

[0016] The system may include a Bootloader which is configured to first start a secure runtime environment when the system starts to operate, so as to decrypt the encrypted data record to be protected by means of decryption software and store the decrypted data record to be protected in a secure storage unit. The Bootloader may also be configured to: only then (i.e., only after decrypting the data record to be protected once) start an operating system (such as Linux) to execute a software application using the data record to be protected. In this way, it can be reliably avoided that an attacker accesses the data record to be protected within the scope of the system starting to operate. In particular, it can be reliably avoided that an attacker causes a one-time execution of the decryption software.

[0017] The operating system of the system may be configured to execute one or more software applications during the operation of the system. The secure runtime environment may be configured to: check the queries of the software application for the data record to be protected; and (only if necessary) read the decrypted data record to be protected from the secure storage unit as a reaction to a positive check result; and if necessary, transfer the decrypted data record to be protected to the software application and / or use the decrypted data record to be protected in combination with the software application (especially in the case of passwords). Alternatively or additionally, the decrypted data record to be protected (especially in the case of a key) may be protected within the secure runtime environment to perform calculations within the scope of a Challenge-Response method. Then, the decrypted data record to be protected may remain within the secure runtime environment, and the software application will only obtain the response determined within the secure runtime environment. In this way, reliable access to the data record to be protected can be ensured.

[0018] The system may be configured such that the decrypted data record to be protected stored in the secure storage unit is deleted when the system operation ends, especially such that the data record to be protected only exists in an encrypted manner after the system operation ends. For example, the system may be part of a device that is repeatedly turned on and off. The turning on of the device may (automatically if necessary) cause the system to start operating, while the turning off of the device may (automatically if necessary) cause the end of the system operation. Each time the system starts to operate, the data record to be protected can be decrypted once by a one-time execution of the decryption software and stored in the secure storage unit. Then, when the system operation ends, the decrypted data record to be protected can be deleted again. In this way, unauthorized access to the data record to be protected can be reliably avoided.

[0019] The system can be configured such that when the system starts operating, the trustworthiness of the components of the system, in particular the bootloader and / or decryption software, can be checked and / or ensured. In other words, when the system starts operating, an assurance of the authenticity of the firmware for the secure runtime environment can be determined. Stated yet another way, a Secure Boot mechanism can be provided. In this way, for example, it can be ensured that the check of the flag is performed for the enforceability of the decryption software.

[0020] According to another aspect of the invention, a device, in particular a household device or a household appliance, is described. The device includes a communication unit which is set up to exchange data with an external unit (such as a backend server) via a communication connection (such as WLAN). The device further includes the system described in this document, which is set up to control access to the data records to be protected. The communication unit of the device can be set up to: obtain the data records to be protected from the system and exchange data with the external unit using the data records to be protected. In this way, the device can be securely incorporated into the device network.

[0021] According to another aspect of the invention, a method for controlling access to data records to be protected is described. The method includes: decrypting the encrypted data records to be protected by means of decryption software within a secure runtime environment. The method further includes: storing the decrypted data records to be protected on a secure storage unit, where the secure storage unit is configured such that access to the secure storage unit is only possible via the secure runtime environment. The method further includes: preventing subsequent implementation of the decryption software (during a (continuous) operating phase).

[0022] It should be noted that any aspects of the system described in this document and the method described in this document can be combined with each other in various ways. In particular, the features of the patent claims can be combined with each other in various ways. Description of the Drawings

[0023] Hereinafter, the invention will be described in detail based on the embodiments shown in the accompanying drawings. Here:

[0024] Figure 1 A block diagram of a system for storing data records to be protected and for managing access to the data records to be protected is shown;

[0025] Figure 2 A block diagram of an exemplary household device is shown; and

[0026] Figure 3 A flowchart of an exemplary method for storing data records to be protected and for managing access to the data records to be protected is shown. Detailed implementation manners

[0027] As described at the beginning, this document is dedicated to protecting the data records to be protected in a (cost) - efficient and secure manner against unauthorized access. As described in this document, cost - efficiency can be achieved in particular by not requiring other storage media in addition to the code memory (RAM) and the data memory (Flash).

[0028] Figure 1 An exemplary system 100 is shown, which includes a first (e.g., non - volatile) storage unit 107 on which the data record 111 to be protected in encrypted form is stored. Due to the encryption of the data record 111 to be protected, the data record 111 to be protected is protected against unauthorized access. However, it is conceivable that an unauthorized person learns the data record key used to encrypt the data record 111 to be protected and may thus indirectly gain access to the data record 111 to be protected.

[0029] The system 100 includes a second (secure) storage unit 106 on which the data record 112 to be protected in unencrypted form is stored. The second storage unit 106 is constructed such that it can only be accessed through the TEE 102 (i.e., through the trusted execution environment), so that access to the data record 112 to be protected in unencrypted form can be reliably monitored.

[0030] Storing the data record 112 to be protected in unencrypted form enables the software application 105 to access the data record 112 to be protected even without knowing the data record key used to decrypt the encrypted data record to be protected. In this way, unmonitored distribution of the data record key used to decrypt the data record 111 to be protected in encrypted form can be avoided.

[0031] Decryption of the data record 111 to be protected in encrypted form and storage of the data record 112 to be protected in unencrypted form can be carried out once by the TEE 102 when the system 100 starts running. Here, repeated execution of the decryption software 103 can be blocked after the one - time execution (e.g., by setting a flag). In this way, unauthorized access to the data record 111 to be protected in encrypted form can be reliably avoided.

[0032] Figure 1Illustrates exemplary action steps of system 100 when system 100 starts to operate (steps 121 to 126) and exemplary action steps of system 100 when system 100 is running (steps 131 to 135). When system 100 starts to operate, the TEE 102 is started by means of the boot loader 101 (step 121). The decryption software 103 is also started by and / or within the TEE 102 (step 122). The decryption software 103 performs the decryption of the data record 111 to be protected in encrypted form once (step 123) and stores the data record 112 to be protected in unencrypted form in the secure second storage unit 106 (step 124).

[0033] After the decryption software 103 is executed once, the decryption software 103 is blocked by the TEE 102 (step 125), and the TEE 102 performs the next boot process of the operating system 104 of the device on which the system 100 runs (step 126).

[0034] During the operation of system 100, the software application 105 can be implemented by the operating system 104 (such as LINUX) (step 131), where the software application 105 may need to access the data records 111, 112 to be protected. For example, the data records 111, 112 to be protected may include the WIFI password, and the WLAN connection with the WLAN access point can be established using this WIFI password. The software application 105 can be designed, for example, to enable communication with the WLAN access point.

[0035] If software application 105 needs to access the protected data records 111, 112, the software application 105 can request the TEE 102 to provide the protected data records 111, 112 (but not deliver them here) (step 132). Here, the TEE 102 can check whether the software application 105 is authorized to obtain the protected data records 111, 112. The TEE 102 can then access the second storage unit 106 (step 133) and transfer the protected data record 112 in unencrypted form to the software application 105 and / or use the protected data record 112 in unencrypted form (e.g., for creating a response in a challenge-response method), without transferring the protected data record 112 in unencrypted form to an external software application (step 134). In addition, the software application 105 can end (e.g., after establishing a WLAN connection) (step 135). If necessary, the operating system 104 can also be set up to access the second storage unit 106. However, access to the address where the protected data record 112 is stored can be blocked for the access of the operating system 104 here (in particular, this access can be blocked by the TEE 102 on the hardware side).

[0036] The system 100 can be part of a device 200, especially a household device such as a washing machine, a dishwasher, an oven, a stove, a refrigerator, a dryer, a kitchen multifunctional machine, etc. The device 200 can have a control unit 201 (e.g., having one or more microprocessors), on which part of the system 100 is implemented. The device 200 can also have (if necessary, separate) security hardware unit 202, on which, for example, the TEE 102 with the second storage unit 106 can be implemented if necessary. In addition, the device 200 can include, for example, a communication unit 203, which is set up to enable communication between the device 200 and a backend server. The software application 105, which needs to access the protected data records 111, 112, can be implemented on the communication unit 203.

[0037] Thus, the system 100 and / or the device 200 are described, in which case, for the system and / or the device, the software of the system host starts the electronic device (i.e., the electronic device of the control unit 201) in the bootloader 101. The bootloader 101 first starts the TEE 102. A trusted Trustlet 103 (e.g., minimalist software that can perform critical atomic tasks) (i.e., that can implement a secure boot mechanism as described above) is started in the TEE 102. The Trustlet or the software 103 first sets a flag in the "Secure RAM" of the TEE 102 so that subsequent calls to the Trustlet 103 are blocked. The "Secure RAM" (e.g., the second storage unit 106) is an area in the RAM that can only be used starting from the TEE 102. Thereby, tampering with the flag is protected on the hardware side.

[0038] Secondly, the Trustlet 103 decrypts the encrypted data record 111 on the non-volatile memory 107 by means of a Hardware Master Key (i.e., a data recording key). The plaintext (i.e., the data record 112) corresponds, for example, to an encryption key or an authentication key in order to enable subsequent decryption processes of the device 200. The TEE 102 can be configured in such a way and method (for providing hardware protection) that the Hardware Master Key cannot be accessed by software from the so-called "Normal World" (in the case of the control unit or the system host 201, this is, for example, the operating system 104). That is to say, access to the Hardware Master Key can only be achieved by the Trustlet 103, where however the Trustlet 103 has already been "blocked" at the time point when the operating system 104 runs.

[0039] Through the system 100 shown in Figure 1 , direct access to the data record 111 to be protected in encrypted form is protected by encryption. Access to the Trustlet 103 is protected by blocking the Trustlet 103, and access to the data record 112 to be protected in unencrypted form is protected by the fact that this access can only be achieved via the TEE 102. In addition, an attacker cannot access the Hardware Master Key in the Secure RAM, so that physical attacks are also blocked.

[0040] Figure 3FIG. 0 shows a flowchart of an exemplary method 300 for controlling access to protected data records 111, 112. The method 300 may be implemented by the system 100 described in this document. The method 300 includes decrypting 301 the encrypted protected data record 111 by means of a decryption software 103 in a secure runtime environment 103 (i.e., in the TEE).

[0041] The method 300 further includes storing 302 the decrypted protected data record 112 on a secure storage unit 106 (e.g., stored on a secure RAM), wherein the secure storage unit 106 is configured such that access to the secure storage unit 106 is only possible through the secure runtime environment 103 (such that unauthorized access can be reliably prevented). The method 300 further includes blocking 303 the next execution of the decryption software 103, such that unauthorized decryption of the encrypted protected data record 111 can be reliably avoided.

[0042] The advantage of the TrustZone- or TEE-based Secure Storage solution described in this document is that there are only hardware requirements for implementing the TEE (e.g., by providing a flash memory and a RAM memory). All other components can be implemented in pure software. Therefore, a cost-effective solution can be provided.

[0043] Other advantages from the perspective of Cyber Security are that it is impossible to directly obtain the hardware host key (for decrypting the encrypted data record 112); it is impossible to call the Trustlet 102 to decrypt the encrypted data record 112; and / or it is impossible to directly access the encrypted data record 111.

[0044] The described solution also has Performance advantages, because the decrypted data record 111 can always (i.e., during the entire operation of the system 100) be kept in the secure RAM (which is faster than the flash memory), which would otherwise be considered insecure if the secret were in the RAM for a longer time than for the actual purpose of use. In the described solution, this has no impact on the security of the protected data record 111.

[0045] The present invention is not limited to the illustrated embodiments. In particular, it should be noted that the description and the drawings are only intended to illustrate the principles of the proposed system and / or the proposed method.

Claims

1. A system (100) for controlling access to data records (111, 112) to be protected, wherein - the system (100) includes a secure runtime environment (103), which is configured to implement decryption software (103); - the decryption software (103) is configured to: decrypt the encrypted data record (111) to be protected and store it decrypted on a secure storage unit (106); - the system (100) includes the secure storage unit (106), which is configured such that access to the secure storage unit (106) is only possible through the secure runtime environment (103); and - the secure runtime environment (103) is configured to prevent the re - implementation of the decryption software (103) during system operation, wherein each time the system starts up, the data record to be protected is decrypted once by implementing the decryption software once and stored in the secure storage unit, and wherein - the secure runtime environment (103) is configured to: store a flag for the implementability of the decryption software (103); - the secure runtime environment (103) is configured to: change the state of the flag to prevent the re - implementation of the decryption software (103); and - the secure runtime environment (103) is configured to: check the state of the flag before implementing the decryption software (103) and implement or prevent the implementation of the decryption software (103) based on the state of the flag.

2. The system (100) according to claim 1, wherein the secure runtime environment (103) is configured to use a hardware key for decrypting and / or encrypting the data records (111, 112) to be protected.

3. The system (100) according to any one of the above claims 1 to 2, wherein - the system (100) includes other non - volatile storage units (107); and - the decryption software (103) is configured to: read the encrypted data record (112) to be protected from the other storage unit (107).

4. The system (100) according to any one of the above claims 1 to 2, wherein - the secure storage unit (106) includes a volatile memory; and / or - the secure storage unit (106) is part of the secure runtime environment (103).

5. The system (100) according to claim 4, wherein the volatile memory includes a RAM memory.

6. The system (100) according to claim 1 or 2, wherein the flag is stored in the secure storage unit (106).

7. The system (100) according to any one of the above claims 1 to 2, wherein the system (100) includes a bootloader (101), which is configured to: when the system (100) starts up, - First, start the secure runtime environment (103) to store the decrypted data record to be protected (112) in the secure storage unit (106); and - Only then start the operating system (104) for implementing the software application (105), where the software application uses the data record to be protected (111, 112).

8. The system (100) according to any one of the preceding claims 1 to 2, wherein - The system (100) includes an operating system (104) configured to implement a software application (105); and - The secure runtime environment (103) is configured to: check the queries of the software application (105) for the data record to be protected (111, 112), and in response to a positive check result, read the decrypted data record to be protected (112) from the secure storage unit (106), and use the decrypted data record to be protected (112) in combination with the software application (105).

9. The system (100) according to any one of the preceding claims 1 to 2, wherein - The decryption software (103) uses a data record key to decrypt the encrypted data record to be protected (111); and - The system (100) is configured such that access to the data record key is only possible through the decryption software (103).

10. The system (100) according to any one of the preceding claims 1 to 2, wherein the data record to be protected (111, 112) includes an encryption key, an authentication key, and / or a password.

11. The system (100) according to any one of the preceding claims 1 to 2, wherein the system (100) is configured such that the decrypted data record to be protected (112) stored in the secure storage unit (106) is deleted at the end of the operation of the system (100), such that after the operation of the system (100) ends, the data record to be protected (111, 112) still only exists in an encrypted manner.

12. The system (100) according to any one of the preceding claims 1 to 2, wherein the secure runtime environment (102) includes: - A trusted execution environment; - AMD's platform security processor; - AMD's secure extension mode; and / or - Intel's trusted execution technology and / or software protection extension.

13. The system (100) according to claim 12, wherein the trusted execution environment includes ARM's TrustZone.

14. A device (200), wherein - The device (200) includes a communication unit (203) configured to exchange data with an external unit through a communication connection; - The device (200) includes a system (100) according to any one of the preceding claims, the system being configured to control access to the data record to be protected (111, 112); - The communication unit (203) is configured to obtain the data records to be protected (111, 112) from the system (100) and communicate data with the external unit using the data records to be protected (111, 112).

15. A method (300) for controlling access to data records to be protected (111, 112) in a system according to any one of claims 1 to 13, wherein the method (300) comprises: - decrypting (301) the encrypted data record to be protected (111) by means of decryption software (103) in a secure runtime environment (103); - storing (302) the decrypted data record to be protected (112) on a secure storage unit (106), wherein the secure storage unit (106) is configured such that access to the secure storage unit (106) is only possible through the secure runtime environment (103); and - preventing (303) further execution of the decryption software (103).

Images