System-on-chip and method for operating a system-on-chip

Abstract

In different example embodiments, a system-on-chip is provided. The system-on-chip can have a control circuit with a plurality of control circuit areas, wherein the control circuit is configured to control a device, a security circuit which has a separately secured key memory and a hardware accelerator for cryptographic operations, wherein the security circuit is configured to electively enable either a read-only access or a read and write access to at least one of the control circuit areas, wherein the security circuit is furthermore configured to provide a communication path by means of the key memory and the hardware accelerator for the secured communication with a diagnostic system disposed outside the security circuit, to make the selection between the read access and the read and write access to the at least one selected area of the control circuit depending on a certificate supplied to the security circuit and authenticated by means of information stored in the key memory, and to execute the read access or the read and write access.

Claims

1. A system-on-chip, comprising: a control circuit comprising a plurality of control circuit areas, wherein the control circuit is configured to control a device, a security circuit comprising a separately secured key memory and at least one hardware accelerator configured to perform cryptographic operations, wherein the security circuit is configured to selectively enable either a read-only access or a read and write access to at least one of the control circuit areas, and wherein the security circuit is further configured to provide a communication path by means of the key memory and the at least one hardware accelerator for a secured communication with a diagnostic system disposed outside the security circuit, to make the selection between the read-only access and the read and write access to at least one selected area of the control circuit depending on a certificate supplied to the security circuit and authenticated by means of information stored in the key memory, and to execute the read-only access or the read and write access.

2. The system-on-chip as claimed in claim 1, wherein the read-only access or read and write access to the at least one selected area of the control circuit is configured so that at least one diagnostic instruction forwarded from the diagnostic system by means of the communication path to the security circuit is executable therewith.

3. The system-on-chip as claimed in claim 2, wherein the security circuit is configured by means of software to execute the secured communication and/or to supply the diagnostic instruction to the control circuit.

4. The system-on-chip as claimed in claim 3, wherein the security circuit comprises a CPU or a virtual machine which is configured to run the software.

5. The system-on-chip as claimed in claim 3, wherein the software comprises a software communication stack.

6. The system-on-chip as claimed in claim 3, wherein the software comprises an Ethernet software communication stack.

7. The system-on-chip as claimed in claim 4, wherein the CPU or the virtual machine is configured to support a plurality of master tags for access to the at least one selected area of the control circuit, wherein the selected area of the control circuit is configured to refuse or enable the access on the basis of one or more of the master tags.

8. The system-on-chip as claimed in claim 1, wherein the communication path comprises a network.

9. The system-on-chip as claimed in claim 8, wherein the network at least partially comprises a wireless data transmission.

10. The system-on-chip as claimed in claim 1, wherein the at least one selected area of the control circuit has a plurality of selected areas of the control circuit, and wherein the security circuit is configured to make the selection between the read-only access and the read and write access separately for each of the plurality of selected areas of the control circuit.

11. The system-on-chip as claimed in claim 1, wherein the security circuit is configured to enable neither the read-only access nor the read and write access in the event of a failed authentication.

12. The system-on-chip as claimed in claim 1, wherein the security circuit is configured to trigger an alarm in the event of a failed authentication.

13. The system-on-chip as claimed in claim 1, wherein the security circuit is configured to take account of at least one additional parameter in the selection between the read-only access and the read and write access.

14. The system-on-chip as claimed in claim 13, wherein the additional parameter relates to a relevance of the read-only access or read and write access for an operational safety of the device, an operational state of the device, and/or a time of provision of the certificate.

15. The system-on-chip as claimed in claim 14, wherein the relevance of the operational state of the device means that the security circuit is configured to completely prohibit at least the read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit when the device is in a first predefined operational state, and/or to enable read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit when the device is in a second predefined operational state.

16. The system-on-chip as claimed in claim 15, wherein the first predefined operational state is an active and functionally safe operational state.

17. The system-on-chip as claimed in claim 15, wherein the first operational state is an active with restricted/without functional safety operational state.

18. The system-on-chip as claimed in claim 1, wherein the security circuit is configured to make a distinction in the selection between the read-only access and the read and write access between an operational-safety-related read-only access or read and write access and a merely monitoring, non-operational-safety-related read-only access or read and write access.

19. The system-on-chip as claimed in claim 1, wherein the at least one selected area comprises a virtual machine and/or diagnostic hardware and/or debug hardware of the control circuit.

20. The system-on-chip as claimed in claim 19, wherein the diagnostic hardware and/or debug hardware is configurable so that it is usable by the security circuit only.

21. The system-on-chip as claimed in claim 1, which is further configured to close the communication path following an instruction from the diagnostic system, the security circuit, and/or the control circuit.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Example embodiments of the disclosure are shown in the figures and are explained in detail below.

(2) FIG. 1A shows a schematic overview of a system-on-chip according to the prior art and an external debug device connected thereto

(3) FIG. 1B and FIG. 1C in each case show a schematic representation of a host system of the system-on chip from FIG. 1A;

(4) FIG. 2A and FIG. 2B in each case show a schematic overview of a system-on-chip according to different example embodiments; and

(5) FIG. 3 shows a flow diagram of a method for operating a system-on-chip according to different example embodiments.

DETAILED DESCRIPTION

(6) Reference is made in the following detailed description to the attached drawings which form part of said description and in which specific embodiments in which the disclosure can be put into practice are shown by way of illustration. In this respect, the directional terminology such as e.g. “above”, “below”, “in front”, “behind”, “front”, “rear”, etc., are used with reference to the orientation of the described figure(s). Since components of embodiments can be positioned in a number of different orientations, the directional terminology is used for illustrative purposes and is in no way limiting. Other embodiments can obviously be used and structural or logical changes can be made without departing the protective scope of the present disclosure. The features of the different example embodiments described herein can obviously be combined with one another unless specifically otherwise indicated. The following detailed description is therefore not to be interpreted in a limiting sense, and the protective scope of the present disclosure is defined by the appended claims.

(7) In the context of this description, the terms “linked”, “connected”, and “coupled” are used to describe both a direct and an indirect link, a direct or indirect connection and a direct or indirect coupling. Identical or similar elements are denoted with identical reference numbers in the figures, insofar as this is appropriate.

(8) FIG. 2A and FIG. 2B in each case show a schematic overview of a system-on chip 200 according to different example embodiments.

(9) As shown in FIG. 2A, the system-on-chip 200 can have a control circuit 102 with a plurality of control circuit areas 128, 130. The plurality of control circuit areas may be or may have, for example, a CPU 128 or other resource 130 of the control circuit 102, e.g. an interconnect 140, a memory 142 or other resources such as e.g. a virtual machine, diagnostic hardware and/or debug hardware of the control circuit (see the similar control circuits 102 from FIG. 1B and FIG. 1C). Each of the control circuit areas may, for example, be identifiable by its address area.

(10) The control circuit 102 can be configured to control a device (not shown). The device may essentially be any device typically controlled or regulated by means of a control circuit 102, for example an engine of a vehicle or a machine, a medical device, a cash register system or similar.

(11) The system-on-chip 200 can furthermore have a security circuit (also referred to as a cryptography security circuit or security circuit for short) 220. The security circuit 220 can be formed, for example, as a hardware security module (HSM) 220.

(12) The term “secure” refers here to information security and not functional security/safety.

(13) An HSM is a logically, sometimes also physically, separated hardware unit which guarantees an efficient and secure execution of cryptographic operations and security applications.

(14) The security circuit 220 can be configured to supply the control circuit with (data-)security-related functions which may be required, for example, during the operation of the device. The security-related functions may entail, for example, a generation of random numbers, keys and PINs and/or an encryption and decryption of data.

(15) In addition to a processor 118 (a CPU, here also referred to as a security CPU), the security circuit 220 can also have a separately secured key memory (SKM) 144 (to store cryptographic keys) and a hardware accelerator (HA) 146 for cryptographic operations (e.g. for hash functions and/or for symmetric and/or asymmetric cryptography) in order to perform the security-related functions.

(16) The security circuit 220 can furthermore have a separate read/write access to dedicated resources, for example to CPUs and/or memories in the control circuit 102.

(17) In different example embodiments, the security circuit 220 can furthermore be equipped with mechanisms to protect against side-channel attacks. Security standards (such as FIPS 140-1 or Common Criteria) specify criteria for the certification of HSMs.

(18) Current applications for the HSM in the automotive environment are secure boot, secure data communication (via CAN, Ethernet and LIN) and memory protection (for IP security).

(19) As explained above, it may be desirable or necessary to monitor the control circuit 102 and/or the device controlled by it, for example in the field.

(20) A diagnostic system 104 can be or can become provided for this purpose.

(21) An access authorization notification can be forwarded from the diagnostic system 104 to the security circuit 220 in order to provide a (secure) communication path between the diagnostic system 104 and the system-on-chip 200 which enables a secure (in the information technology sense) communication between the system-on-chip 200 (in particular the security circuit 220) and the diagnostic system 104.

(22) The security circuit 220 can be configured to authenticate the access authorization notification by means of the key memory 144 and the hardware accelerator 146 and then to provide the (secure) communication path for the secured communication with the diagnostic system 104 disposed outside the security circuit 220 (and, if necessary, outside the system-on-chip 200 also).

(23) The security circuit 220 can furthermore be configured to evaluate the access authorization notification in such a way that the access authorization notification enables a selection between different facilities for accessing the control circuit areas 128, 130 of the control circuit 102. The security circuit 220 can be configured, for example, either to enable (only) a read access or a read and write access to each of the control circuit areas 128, 130 or to prohibit access.

(24) The access authorization notification authenticated by means of information stored in the key memory 144 (and, if necessary, by means of the hardware accelerator 146) can be matched, e.g. by means of the security CPU 118, with allocations of access authorization notifications stored in the security circuit 220 for access authorizations.

(25) The security circuit 220 can be configured to enable the read access or the read and write access to the at least one selected area 128, 130 of the control circuit 102 on the basis of the allocated access authorization, or to prohibit access.

(26) The security circuit 220 can be configured to execute the read access or the read and write access to the at least one selected area 128, 130 of the control circuit 102.

(27) The read access or the read and write access to the at least one selected area 128, 130 of the control circuit 102 can be designed in such a way that at least one diagnostic instruction forwarded from the diagnostic system 104 by means of the communication path to the security circuit 220 is executable therewith.

(28) This means that, unlike the system-on-chip 100 explained in connection with FIGS. 1A to 1C in which the diagnostic or debug instructions and information are exchanged directly between the diagnostic system 104 and the host system 102 following the opening of the “switch” 126, in the system-on-chip 200 according to different example embodiments, the diagnostic system forwards its monitoring and/or debug instructions to the security circuit 220 and these instructions are forwarded from the security circuit 220 to the control circuit 102, taking account of the read access or read and write authorization for each control circuit area 128, 130 affected by the diagnostic instruction.

(29) The security circuit 220 can be configured by means of software to perform the secured communication with the diagnostic system 104 and/or to supply the diagnostic instruction to the control circuit 102. The software may, for example, in each case have a software package to perform the secured communication with the diagnostic system 104 or to supply the diagnostic instruction to the control circuit 102.

(30) In different example embodiments, the CPU 118 of the security circuit 220 or a virtual machine can be configured to run the software.

(31) The (communication) software may, for example, have a software communication stack, e.g. an Ethernet software communication stack.

(32) The CPU 118 or the virtual machine can be configured to support a plurality of master tags for access to the at least one selected area 128, 130 of the control circuit 102. It can thus be enabled to supply the diagnostic system with fewer or other access facilities than those which the CPU 118 or the virtual machine in principle has at its disposal.

(33) This means that the security circuit 220 or the CPU (or the virtual machine) can be configured in principle to access each of the selected areas 128, 130 of the control circuit 102 by means of a write access, but the plurality of master tags are provided to restrict the access type to individual or all of the selected areas 128, 130 of the control circuit 102, e.g. to read-only access, or as an access prohibition.

(34) As already described, the security authorization of accesses requested by the diagnostic system 104 is checked by the security circuit 220. The safety authorization for the resulting accesses to the control circuit 102 can then be checked by the master tags in the control circuit itself, and the control circuit 102 can thus protect itself against critical attacks. This is necessary, since it cannot be excluded that the security circuit 220, due to a hardware or software error, enables an unauthorized access which has critical consequences.

(35) In order to enable a read access for a predefined master tag, the security circuit 220 can be configured to enter a value corresponding to a read access right in an access enable register at a location allocated to the master tag.

(36) In order to enable a read and write access for a predefined further master tag, the security circuit 220 can similarly be configured to enter a value corresponding to a read and write access right in an access enable register at a location allocated to the further master tag.

(37) In different example embodiments, this access control can in turn be secured by overwriting the access enable register in such a way that the overwrite is permissible only for a master which is designated by means of its master tag in such a way that it not only meets the information technology security requirements, but also ensures the operational safety of the device. In different embodiments, corresponding information can be transmitted, for example, as sideband or inband information in the bus system. These example embodiments are simple in design/implementation, but are relatively expensive, since the master (or the corresponding software) must meet both high (e.g. the highest) safety requirements and high (e.g. the highest) security requirements.

(38) In different example embodiments, a safety CPU of the control circuit 102 can instead be configured (e.g. the CPU 128 or a further CPU can be configured as a safety CPU) in such a way that it locks (defines) the access authorizations in an initialization phase, e.g. as an allocation of master tag(s) to resource(s) 128, 130 which it/they is/are authorized to access. The security circuit 118 can be configured to check the access authorization in the modules that are relevant to it.

(39) Both designs enable the provision of a system-on-chip with a locking which guarantees both operational safety and data security.

(40) In different example embodiments, the communication path to the diagnostic system can entail a network. In different example embodiments, the network can entail at least partially a wireless data transmission.

(41) In different example embodiments, the at least one selected area 128, 130 of the control circuit 102 can entail a plurality of selected areas of the control circuit.

(42) The security circuit 220 can be configured to make a selection between the read access and the read and write access separately for each of the plurality of selected areas 128, 130 of the control circuit 102.

(43) In other words, a read (-only) access can be enabled to a first part (e.g. none, one or more) of the selected areas 128, 130 of the control circuit 102, and a read and write access can simultaneously be enabled to a second part (none, one or more) of the selected areas 128, 130 of the control circuit 102 differing from the first part.

(44) In different example embodiments, the security circuit 220 can be configured to enable neither the read access nor the read and write access in the event of a failed authentication. If necessary, the security circuit 220 can furthermore be configured to trigger an alarm, for example in the device, in the event of a failed authentication.

(45) In different example embodiments, the security circuit 220 can be configured to take account of at least one additional parameter in the selection between the read access and the read and write access. The additional parameter can relate, for example, to a relevance of the read access or read/write access for an operational safety of the device, an operational state of the device and/or a time of provision of the certificate.

(46) The consideration of the relevance of the read access or read/write access for the operational safety of the device can mean that the security circuit 220 is configured, in the selection between the read access and the read and write access (or the complete prohibition of access), to make a clear distinction between a debug instruction which may be critical for operational safety (e.g. “stop”, “pause”, etc.) and other debug instructions which have a monitoring function only (e.g. counting, tracking, etc.). The operational-safety-critical instructions may normally require a write access, whereas a read-only access may normally be sufficient for the monitoring functions. In some cases, for example during a readout of a memory (e.g. one of the memories 130) which is automatically overwritten after the readout, the read-only access can also be categorized, if necessary, as operational-safety-critical.

(47) The consideration of the operational state of the device can mean that the security circuit 220 can be configured to completely prohibit the read and write access (or an operational-safety-critical read access) to all areas of the control circuit 102 or at least to one or more of the selected areas of the control circuit 102 if the device is in a first predefined operational state, and/or to enable read and write access (or an operational-safety-critical read access) to all areas 128, 130 of the control circuit 102 or at least to one or more of the selected areas 128, 130 of the control circuit 102 if the device is in a second predefined operational state.

(48) The first predefined operational state may be an “active” operational state, in other words an operational state in which the device is active or in operation, for example a running engine, a diagnostic medical device during operation or the like.

(49) The first predefined operational state may be an “inactive” operational state, in other words an operational state in which the device is inactive or is not in operation or is in an idle/paused state, for example a motor vehicle which is in a workshop for repair, or the like.

(50) Different diagnostic modes can be created for the system-on-chip 200 on the basis of the criteria described above.

(51) A “safe-enabled mode”, for example, can be provided in which the access authorizations are set in such a way (only read authorizations, or even only those read authorizations in which an overwrite after the reading is excluded) that only a monitoring of states of the control circuit 102 of the device is possible.

(52) Only an on-chip trace system (part of a diagnostic circuit (debug and trace system DTS) 290) needs to be configured by means of write accesses if it is used in this mode. In this case, a configuration of the access-authorized master can be set, e.g. using the master tags, in such a way that the on-chip trace system is configurable only by the security circuit 220. It can thereby be or become ensured that the DTS 290 cannot be used by malware which is running, e.g. on one of the CPUs 128, in order to analyze the control circuit 102, and in particular the software and data, with the trace system.

(53) A mode of this type could, for example, be or become set during the operation of the device. An access, for example by means of a cloud, can be used for a safe and secure remote diagnosis.

(54) As a further example, a “privileged debug mode” can be provided in which, in addition to the read authorization, a write authorization can also be assigned to selected authorized parties only. A debug can thus also be or become enabled in addition to the monitoring of states of the control circuit 102 or the device, for example by individual access-authorized parties. A mode of this type could be or become set, for example during a test operation of the device. A secure (mainly secure in terms of information technology) remote debugging, for example, can be enabled with this or a similar mode, for example in the case of a direct access to a network of the device (e.g. a motor vehicle network).

(55) During or after a manufacture of the SoC 200 and/or its connection to the device, it may be appropriate or necessary not to restrict the access authorizations. In a “setup mode” or “installation mode” of this type, an essentially unlimited read and write access to the control circuit 102 can be enabled.

(56) The consideration of the time of provision of the certificate can enable the provision of certificates with a limited validity period, for example in order to be able to extract information for a limited time period after the manufacture or after a maintenance/repair operation.

(57) The system-on-chip 200 can be configured to close the communication path following an instruction from the diagnostic system 104, the security circuit 220 and/or the control circuit 102. The system-on-chip 200 can furthermore be configured to perform a restart following the closure of the communication path.

(58) According to different example embodiments, the system-on-chip 200 shown in FIG. 2B serves to illustrate that the security circuit 220 can access the entire chip and provides the secure communication path, i.e., for example, by means of a communication (COM) peripheral 140, e.g. via Ethernet. This means that the diagnostic system 104 (not shown) would be connected to the COM peripheral from outside the SoC 200 in FIG. 2B, in other words the CPU is capable of using any communication (COM) peripheral 140, e.g. the Ethernet, in order to communicate with the external host of the diagnostic system 104 as an analytical tool.

(59) It is furthermore illustrated that the security circuit 220 provides the system (e.g. software, provided e.g. on the CPU or as part of a virtual machine) for the diagnostics of the control circuit 102. The diagnostic circuit 290 is denoted here as DTS. Even if special connections are shown in FIG. 2B between the security circuit 220 and the communication (COM) peripheral 140 on the one hand or the DTS 290 on the other hand, these data connections can also be provided by means of conventional on-chip buses or networks.

(60) In this case, it must be or become ensured that the diagnostic circuit (DTS) 290 cannot be used by malware which is running e.g. on one of the CPUs 128. The configuration of the access-authorized masters must therefore allow the latter to be restricted to all masters which are trusted from a security perspective.

(61) This trace system is then allowed to be configurable by the security circuit only. Malware which is running on any of the CPUs 128 could otherwise be used to analyze the control circuit, and, in particular, the software and data, with the trace system.

(62) In summary, a system is provided in which software runs on a security CPU or a security virtual machine which communicates via a network with external tool software and controls diagnostic and debug hardware resources according to instructions from the external tool software. The communication can be protected, i.e., for example, authenticated and/or encrypted, in respect of its data security.

(63) In different embodiments, the software can be configured to upload and/or download data (e.g. monitoring/tracking data), to set breakpoints and/or to configure a monitoring system.

(64) In different example embodiments, different authorization levels can be agreed in advance and a scope of permitted actions can then be or become restricted according to the authorization level (e.g. by means of the security circuit 220).

(65) A scope of permitted actions definable according to the authorization level can be used, for example as described above, to make a clear distinction between operational-safety-related debug actions (stop, pause, etc.) and other debug actions (counting, tracking, etc.).

(66) In different example embodiments, a tracking system can be provided by means of the system-on-chip, said tracking system enabling a scope of actions and tracking operations to be restricted on a virtual machine level. This can mean, for example, that only the program trace and/or data trace is/are possible for a specific virtual machine.

(67) In different example embodiments, a key used for authentication for the certificate can be modified statically or dynamically (e.g. according to a jointly agreed key distribution protocol).

(68) On the one hand, since the diagnostic instructions are supplied to the control circuit by means of the security CPU 118 of the security circuit 220, no CPU provided specifically for this purpose is required. On the other hand, however, the security CPU 118 is independent from the CPUs 228 of the control circuit 102, so that all CPUs 128 can be stopped, if necessary, during the debugging without the diagnostic software failing as a result.

(69) FIG. 3 shows a flow diagram 300 of a method for operating a system-on-chip according to different example embodiments.

(70) The method entails controlling a device by means of a control circuit with a plurality of control circuit areas (at 310), providing a communication path for the secured communication between a security circuit and a diagnostic system disposed outside the security circuit, wherein the security circuit has a separately secured key memory and a hardware accelerator for cryptographic operations and is configured to provide the communication path for the secured communication by means of the key memory and the hardware accelerator (at 320), deciding whether a read access or read and write access is grantable to the at least one selected area of the control circuit depending on a certificate supplied to the security circuit and authenticated by means of information stored in the key memory (at 330), electively enabling the read-only access or the read and write access to at least one of the control circuit areas by means of the security circuit (at 340), and executing the read access or the read and write access (at 350).

(71) Some example embodiments are indicated in summary below.

(72) Example embodiment 1 is a system-on-chip. The system-on-chip can have a control circuit with a plurality of control circuit areas, wherein the control circuit is configured to control a device, a security circuit which has a separately secured key memory and a hardware accelerator for cryptographic operations, wherein the security circuit is configured to electively enable either a read-only access or a read and write access to at least one of the control circuit areas, wherein the security circuit is furthermore configured to provide a communication path by means of the key memory and the hardware accelerator for the secured communication with a diagnostic system disposed outside the security circuit, to make the selection between the read access and the read and write access to the at least one selected area of the control circuit depending on a certificate supplied to the security circuit and authenticated by means of information stored in the key memory, and to execute the read access or the read and write access.

(73) Example embodiment 2 is a system-on-chip according to example embodiment 1, wherein the read access or read and write access to the at least one selected area of the control circuit is designed in such a way that at least one diagnostic instruction forwarded from the diagnostic system by means of the communication path to the security circuit is executable therewith.

(74) Example embodiment 3 is a system-on-chip according to example embodiment 2, wherein the security circuit is configured by means of software to execute the secured communication and/or to supply the diagnostic instruction to the control circuit.

(75) Example embodiment 4 is a system-on chip according to example embodiment 3, wherein the security circuit has a CPU or a virtual machine which is configured to run the software.

(76) Example embodiment 5 is a system-on chip according to example embodiment 3 or 4, wherein the software has a software communication stack.

(77) Example embodiment 6 is a system-on chip according to one of example embodiments 3 to 5, wherein the software has an Ethernet software communication stack.

(78) Example embodiment 7 is a system-on chip according to one of example embodiments 4 to 6, wherein the CPU or the virtual machine is configured to support a plurality of master tags for access to the at least one selected area of the control circuit, wherein the selected area of the control circuit is configured to refuse or enable the access on the basis of the master tag.

(79) Example embodiment 8 is a system-on chip according to one of the preceding embodiments, wherein the communication path entails a network.

(80) Example embodiment 9 is a system-on-chip according to example embodiment 8, wherein the network at least partially entails a wireless data transmission.

(81) Example embodiment 10 is a system-on-chip according to one of the preceding example embodiments, wherein the at least one selected area of the control circuit has a plurality of selected areas of the control circuit, and wherein the security circuit is configured to make the selection between the read access and the read and write access separately for each of the plurality of selected areas of the control circuit.

(82) Example embodiment 11 is a system-on-chip according to one of the preceding example embodiments, wherein the security circuit is configured to enable neither the read access nor the read and write access in the event of a failed authentication.

(83) Example embodiment 12 is a system-on-chip according to one of the preceding example embodiments, wherein the security circuit is configured to trigger an alarm in the event of a failed authentication.

(84) Example embodiment 13 is a system-on-chip according to one of the preceding example embodiments, wherein the security circuit is configured to take account of at least one additional parameter in the selection between the read access and the read and write access.

(85) Example embodiment 14 is a system-on-chip according to example embodiment 13, wherein the additional parameter relates to a relevance of the read access or read/write access for an operational safety of the device, an operational state of the device and/or a time of provision of the certificate.

(86) Example embodiment 15 is a system-on-chip according to example embodiment 14, wherein the consideration of the operational state of the device means that the security circuit is configured to completely prohibit at least the read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit if the device is in a first predefined operational state, and/or to enable read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit if the device is in a second predefined operational state.

(87) Example embodiment 16 is a system-on-chip according to example embodiment 15, wherein the first operational state is an “active and functionally safe” operational state.

(88) Example embodiment 17 is a system-on-chip according to example embodiment 15, wherein the first operational state is an “active with restricted/without functional safety” operational state.

(89) Example embodiment 18 is a system-on-chip according to one of the preceding example embodiments, wherein the security circuit is configured to make a distinction in the selection between the read access and the read and write access between an operational-safety-related read access or read and write access and a merely monitoring, non-operational-safety-related read access or read and write access.

(90) Example embodiment 19 is a system-on-chip according to one of the preceding example embodiments, wherein the at least one selected area has a virtual machine and/or diagnostic hardware and/or debug hardware of the control circuit.

(91) Example embodiment 20 is a system-on-chip according to example embodiment 19, wherein the diagnostic hardware and/or debug hardware is configurable in such a way that it is usable by the security circuit only.

(92) Example embodiment 21 is a system-on-chip according to one of the preceding example embodiments which is furthermore configured to close the communication path following an instruction from the diagnostic system, the security circuit and/or the control circuit.

(93) Example embodiment 22 is a method for operating a system-on-chip. The method entails controlling a device by means of a control circuit with a plurality of control circuit areas, providing a communication path for the secured communication between a security circuit and a diagnostic system disposed outside the security circuit, wherein the security circuit has a separately secured key memory and a hardware accelerator for cryptographic operations and is configured to provide the communication path for the secured communication by means of the key memory and the hardware accelerator, deciding whether a read access or read and write access is grantable to the at least one selected area of the control circuit depending on a certificate supplied to the security circuit and authenticated by means of information stored in the key memory, electively enabling the read-only access or the read and write access to at least one of the control circuit areas by means of the security circuit, and executing the read access or the read and write access.

(94) Example embodiment 23 is a method according to example embodiment 22, wherein the read or the read and write access to the at least one selected area of the control circuit is designed in such a way that at least one diagnostic instruction forwarded from the diagnostic system by means of the communication path to the security circuit is executable therewith.

(95) Example embodiment 24 is a method according to example embodiment 22 or 23, wherein the security circuit is configured by means of software to perform the secured communication.

(96) Example embodiment 25 is a method according to example embodiment 24, wherein the security circuit has a CPU or a virtual machine which is configured to run the software.

(97) Example embodiment 26 is a method according to example embodiment 24 or 25, wherein the software has a software communication stack.

(98) Example embodiment 27 is a method according to one of example embodiments 24 to 26, wherein the software has an Ethernet software communication stack.

(99) Example embodiment 28 is a method according to one of example embodiments 25 to 27, wherein the CPU or the virtual machine is configured to support a plurality of master tags for access to the at least one selected area of the control circuit, wherein the selected area of the control circuit is configured to refuse or enable the access on the basis of the master tag.

(100) Example embodiment 29 is a method according to one of the preceding example embodiments, wherein the communication path entails a network.

(101) Example embodiment 30 is a method according to example embodiment 29, wherein the network at least partially entails a wireless data transmission.

(102) Example embodiment 31 is a method according to one of the preceding example embodiments, wherein the at least one selected area of the control circuit has a plurality of selected areas of the control circuit, and wherein the security circuit is configured to make the selection between the read access and the read and write access separately for each of the plurality of selected areas of the control circuit.

(103) Example embodiment 32 is a method according to one of the preceding example embodiments, wherein the security circuit is furthermore configured to enable neither the read access nor the read and write access in the event of a failed authentication.

(104) Example embodiment 33 is a method according to one of the preceding example embodiments, wherein the security circuit is configured to trigger an alarm in the event of a failed authentication.

(105) Example embodiment 34 is a method according to one of the preceding example embodiments, wherein the security circuit is configured to take account of at least one additional parameter in the selection between the read access and the read and write access.

(106) Example embodiment 35 is a method according to example embodiment 34, wherein the additional parameter relates to a relevance of the read access or read/write access for an operational safety of the device, an operational state of the device and/or a time of provision of the certificate.

(107) Example embodiment 36 is a method according to example embodiment 35, wherein the consideration of the operational state of the device means that the security circuit is configured to completely prohibit at least the read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit if the device is in a first predefined operational state, and/or to enable read and write access to all areas of the control circuit or at least to one or more of the selected areas of the control circuit if the device is in a second predefined operational state.

(108) Example embodiment 37 is a method according to example embodiment 36, wherein the first operational state is an “active and functionally safe” operational state.

(109) Example embodiment 38 is a method according to example embodiment 36, wherein the first operational state is an “active with restricted/without functional safety” operational state.

(110) Example embodiment 39 is a method according to one of the preceding example embodiments, wherein the security circuit is configured to make a distinction in the selection between the read access and the read and write access between an operational-safety-related read access or read and write access and a merely monitoring, non-operational-safety-related read access or read and write access.

(111) Example embodiment 40 is a method according to one of the preceding example embodiments, wherein the at least one selected area has a virtual machine and/or diagnostic hardware and/or debug hardware of the control circuit, wherein the selected area of the control circuit is configured to refuse or enable the access on the basis of the master tag.

(112) Example embodiment 41 is a method according to one of the preceding example embodiments which furthermore entails closing the communication path following an instruction from the diagnostic system, the security circuit and/or the control circuit.