Method for managing the lifecycle of a system-on-a-chip, and corresponding system-on-a-chip

Abstract

The Lifecycle Management System (LCMS) process for a system-on-a-chip (SoC) with features (IPS) includes multi-actor ownership management (MUOS) that lists feature owners in a directory, and includes the allocation of rights to a feature (IPS) during the SoC lifecycle, based on a configuration command (CmdConfig) that includes an identification of said feature, an identification of a property or access right for the feature, and a signature of the feature owner (SignST>, SignUser>). Figure for the abstract: Fig 1

Description

Title of the invention: Method for managing the lifecycle of a system-on-a-chip, and corresponding system-on-a-chip

[0001] Some embodiments and implementations relate to the management of the life cycle of a system on a chip, in particular the management of system on a chip functionalities during the product's lifetime (the product being for example the system on a chip or an object incorporating the system on a chip).

[0002] There is a demand to benefit from services that can be dynamically activated during the product's life cycle, such as in the context of leasing for end users, in the context of ensuring safety in the use of functionalities, in the context of traceability of uses, in the context of simplifying the initial configuration procedure of the product's original manufacturer, and / or in the context of active recycling of systems on a chip.

[0003] Conventional solutions are typically not suited to these needs, as they do not allow in particular a dynamic configuration of rights holders during the product's lifetime, while ensuring security against hacking or unauthorized access.

[0004] Indeed, classically, system-on-chip functionalities can be activated or not by a configuration at the end of the production line, typically by means of writing to a single-programmable memory, that is to say a non-volatile memory that can only be written once by the circuit manufacturer.

[0005] Other conventional systems may provide for the activation or deactivation of features during the life of a product, but requiring an action from a trusted authority external to the system, such as for example in a client-server operation providing additional online features to the system (client) by the external trusted authority (server).

[0006] Thus, there is a need to provide systems-on-a-chip capable of dynamically activating and deactivating functionalities during the product lifecycle, for example, based on the product owner, without intervention from an external and centralized trusted authority, and advantageously in a reversible manner without time limits. Furthermore, it is desirable that the security of the dynamic activation / deactivation process be guaranteed and strive for immutability.

[0007] The implementation and embodiment methods defined below are proposed in these respects, and allow a system-on-a-chip to benefit from dynamic management of the activation or deactivation of functionalities (for example, by management of access rights to these features) throughout the entire system-on-chip lifecycle, and not just during the production of the integrated circuit.

[0008] Thus, the said implementation and embodiment methods defined below, by allowing dynamic configurations and reconfigurations of the system on chip, can offer: improved traceability of chips; implementation of adaptive rental (“smart renting” in English); a means of guarding against overproduction and counterfeiting; secure provisioning of “new” functionalities to a product; the possibility of multi-ownership; the possibility of transferring ownership and licenses of functionalities; and a means of proving ownership of the system.

[0009] According to one aspect, a method for managing the lifecycle of a system-on-chip having functionalities is proposed, comprising multi-actor ownership management listing owners of functionalities in a directory, and comprising an allocation of rights of a functionality during the lifecycle of the system-on-chip, according to a configuration command comprising an identification of said functionality, an identification of an ownership or access right of the functionality, and a signature of the owner of this functionality.

[0010] According to one embodiment, said directory is contained in a programming script stored in secure memory, and said configuration command is communicated in a modified version of said script, the method comprising an execution of the script in order to carry out said allocation of rights of the identified functionality.

[0011] According to one embodiment, said directory is contained in a single programmable memory, and said configuration command is communicated in a certificate comprising a data string and stored in a secure memory, the method including an interpretation of the certificate in order to carry out said allocation of the rights of the identified functionality.

[0012] By "certificate" is meant a certified data string, for example a signed data string whose public key is contained in said directory; or for example a signed data string whose public key is contained in a signed authentication document attached to the data string, and whose public key (of the authentication document) is contained in said directory. Such an authentication document may, for example, be governed by the X.509 standard (said authentication document being distinctly named "certificate" in the X.509 standard).

[0013] Finally, the term “certificate” will also mean any other equivalent means providing a validation (or certification) mechanism for the data chain, such as, for example, validation within a blockchain-type system (an English term commonly used but without a direct equivalent in French, literally meaning “chain of blocks").

[0014] According to one implementation method, if said configuration command includes the identification of an access right, then the property management includes an allocation of access permissions to the identified functionality.

[0015] According to one implementation method, if said configuration command includes the identification of the ownership right of said functionality to an identified actor, then the ownership management includes an allocation to the identified actor of ownership of the identified functionality.

[0016] According to one implementation method, said ownership management includes a verification that said signature of the configuration command authenticates the last known owner in said directory for the identified functionality.

[0017] For example, said ownership management includes decrypting said configuration command signature with an encryption key of said last known owner.

[0018] According to one embodiment, the system-on-chip further includes a system authorizing and prohibiting access to functionalities, based on the content of a configuration register, said ownership management including programming of the configuration register to allocate said rights of the functionality.

[0019] For example, the system capable of authorizing and prohibiting access to functionalities can be implemented in a system-on-chip access rights management system, such as the resource isolation environment described in publication FR 3103586 Al (28 / 05 / 2021), which notably allows for dynamic access rights management.

[0020] According to one embodiment, the method may include an irreversible recording of a content of the configuration register, i.e. at least a part of the content of the configuration register, if said configuration command further defines an irreversible character of said allocation.

[0021] According to one embodiment, said allocation of the rights of the functionalities is carried out at the start of the system on chip, in cooperation with said system authorizing and prohibiting access to the functionalities, so that all access is prohibited before said allocation.

[0022] According to one embodiment, the method further comprises a continuously active generation of a timestamp, in which said ownership management includes a scheduling at a future time, determined by said timestamp, of said allocation to said actor of the functionality.

[0023] By "always-on generation of a timestamp" is meant an autonomous generation of time information on the order of a date and time, in the system-on-chip; for example, generated by means of an always-on clock circuit active, also called secure timing system (usually "secure timing system" or "secure system time" or "secure RTC" for "secure real time clock" in English).

[0024] According to another aspect, a system-on-chip is also proposed, having functionalities, and comprising a lifecycle management device incorporating a multi-actor ownership management circuit configured to list owners of functionalities in a directory, and to allocate rights of a functionality during the lifecycle of the system-on-chip, according to a configuration command comprising an identification of said functionality, an identification of an ownership or access right of the functionality, and a signature of the owner of this functionality.

[0025] According to one embodiment, said directory is contained in a programming script stored in secure memory, and said configuration command is communicated in a modified version of said script, said property management circuit comprising a control unit configured to execute said script in order to perform said allocation of rights of the identified functionality.

[0026] According to one embodiment, said directory is contained in a single programmable memory, and said configuration command is communicated in a certificate comprising a data string and stored in a secure memory, said property management circuit comprising a control unit configured to interpret said certificate in order to perform said allocation of rights of the identified functionality.

[0027] According to one embodiment, the property management circuit is configured to allocate access permissions to the identified functionality, if said configuration command includes the identification of an access right.

[0028] According to one embodiment, the property management circuit is configured to allocate ownership of the identified functionality to the identified actor, if said configuration command includes the identification of the ownership right of said functionality to an identified actor.

[0029] According to one embodiment, said property management circuit includes an authentication unit configured to verify that said signature of the configuration command authenticates the last known owner in said directory for the identified functionality.

[0030] According to one embodiment, the system-on-chip further comprises a system configured to authorize and prohibit access to the functionalities of the system-on-chip, depending on the contents of a configuration register, said property management circuit being configured to program the configuration register in order to allocate said rights of the functionality.

[0031] According to one embodiment, said configuration register is capable of recording content irreversibly, if said configuration command further defines an irreversible character of the allocation.

[0032] According to one embodiment, the property management circuit is configured to perform said allocation of functionality rights at system-on-chip startup, in cooperation with said system configured to allow and prohibit access to system-on-chip functionalities so that all access is prohibited before said allocation.

[0033] According to one embodiment, the system-on-chip further comprises a secure always-on timestamping circuit, in which said property management circuit is configured to schedule, at a future time determined by said timestamping circuit, said allocation of rights of said functionality.

[0034] Other advantages and features of the invention will become apparent upon examination of the detailed description of embodiments and implementations, which are by no means limiting, and the accompanying drawings in which the figures:

[0035] [Fig.l] ;

[0036] [Fig.2] ;

[0037] [Fig.3] ;

[0038] [Fig.4] ;

[0039] [Fig.5] ;

[0040] [Fig.6] ;

[0041] [Fig.7] ;

[0042] [Fig.8] ;

[0043] [Fig.9] ;

[0044] [Fig. 10];

[0045] [Fig. 11];

[0046] [Fig. 12];

[0047] [Fig. 13];

[0048] [Fig. 14] illustrate embodiments and implementations of the invention.

[0049] Fig. 1 illustrates an example of an embodiment of a system-on-chip (SOC) having functionalities and including an LCMS lifecycle management device capable of dynamically enabling or disabling functionalities throughout the lifetime of the system-on-chip (SOC).

[0050] The system-on-chip lifecycle, which can also be called the lifecycle, begins at the end of the production line, when the integrated circuit is functional and ready to be configured by the manufacturer for a given commercialization, and then includes the commercialization and use of the system-on-chip, until the product becomes waste, potentially recycled.

[0051] The functionalities of the system on chip SOC can be implemented by specifically dedicated IPS resources, such as for example an image sensor and a hardware accelerator for image processing or neural processing, and / or by common resources such as a pC microcontroller; RAM, COMM communication interfaces such as "WiFi" (IEEE 802.11 group standards), "4G / 5G / LTE" (FUIT and 3GPP standards), "USB", "I2C", "SPI", etc.; as well as other hardware or software resources.

[0052] In general, any functionality that can be distinctly identified by the reference "IPS" will be designated, regardless of the means by which it is obtained.

[0053] Thus, and as will appear in the description below, the ability to dynamically activate or deactivate IPS functionalities is advantageous from this first stage of the system-on-chip (SOC) lifecycle, by allowing diversification of possible parameters of the same production of the integrated circuit of the SOC system, for example according to different commercial ranges; while facilitating the parameterization procedure by the manufacturer and the management of its stock.

[0054] During the life of the system, i.e. during its marketing and use, the ability to dynamically activate or deactivate IPS functionalities may allow the manufacturer or owner of the system on chip SOC to, for example, implement adaptive leasing ("smart renting" in English) of certain functionalities, or to make "new" functionalities available to a product, such as in the context of an update.

[0055] The ability to dynamically activate or deactivate functionalities also allows for better management of system-on-chip (SOC) ownership, offering in particular possibilities for multi-ownership and transfer of ownership of functionalities, and means of proving ownership.

[0056] Furthermore, at the end of a product's life cycle, the system-on-chip (SOC) can be actively recycled, i.e., for example, reused with a reconfiguration adapted to the second application, again thanks to the ability to dynamically activate or deactivate functionalities.

[0057] The system-on-chip (SOC) advantageously includes a resource isolation (RIF) system capable of authorizing and denying access to the system-on-chip's IPS functionalities. For example, the RIF system is part of a resource access management system as described in French publication FR 3103586 A1 (May 28, 2021), which is particularly suited to dynamic configurations depending on the system-on-chip applications.

[0058] For example, the RIF resource isolation system may be able to read the contents of one or more CFGBK configuration register(s) in order to configure accordingly the authorization or prohibition of access to a given resource by a device given applicant.

[0059] The CFGBK configuration register(s) may, for example, belong to the RIF resource isolation system, in which case the LCMS lifecycle management device may be able to write the configuration to the CFGBK configuration register(s).

[0060] The CFGBK configuration register(s) may, for example, belong to the LCMS lifecycle management device and be contained in a SECMEM secure memory.

[0061] The LCMS lifecycle management device advantageously includes a SECMEM secure memory, which can contain the CFGBK configuration register mentioned above, as well as CRTF-CFG / SCRPT configuration command instructions allowing for dynamic modification, during the lifetime of the system on chip, of access permissions to IPS functionalities.

[0062] In this regard, the LCMS lifecycle management device includes a MUOS multi-actor ownership management circuit, configured on the one hand to list owners for at least some of said IPS functionalities in a directory; and on the other hand to dynamically allocate rights to an IPS functionality during the lifetime of the system-on-chip SOC, according to a configuration command, for example via the COMM communication interfaces.

[0063] The configuration command may include at least an identification of said IPS functionality, an identification of said actor, and a signature of the owner of this functionality, and may be communicated according to the embodiments described below in relation to Figures 2 to 5 and with Figures 6 to 9.

[0064] Advantageously with regard to the security of operations, the MUOS property management circuit is configured to perform the allocation of rights for features at each startup of the system on chip SOC, and in cooperation with the RIF resource isolation system so that all access is prohibited before said allocation.

[0065] In addition, the LCMS lifecycle management device may include an always-on secure STS timestamping circuit, so that the MUOS property management circuit can schedule its dynamic allocations of feature rights, at a future time, determined by said STS timestamping circuit.

[0066] Indeed, the always active secure time-stamping circuit STS is advantageously able to autonomously generate time information of an order of magnitude of date and time in the system on chip, and is for example usually called "secure timing system" or "secure system time" or "secure RTC" in English.

[0067] Reference is now made to [Fig. 2] to 5, illustrating a first embodiment and implementation relating to said configuration command.

[0068] Fig. 2 illustrates the first implementation method for the lifecycle management process in which configuration commands are communicated in the form of a SCRPT script, i.e. a human-readable programming language.

[0069] This is advantageous from the point of view of end users, who can easily configure scripts according to their needs.

[0070] On the one hand, in lifecycle management, owners of the different functionalities are listed within the framework of multi-actor ownership management.

[0071] Thus, at the end of the manufacturing of the system on chip SOC, the manufacturer ST owns all the functionalities and has all the rights to all the functionalities.

[0072] The manufacturer ST may therefore, for example, stipulate that not all functionalities are activated by default. Activation may be done later for commercial reasons, depending, for example, on the product range offered or the type of offer.

[0073] The manufacturer ST can thus provide an actor A (for example a buyer) with CRTF information enabling the transfer of ownership of at least one IPS functionality to actor A.

[0074] The CRTF information is signed by the manufacturer, and includes an identification of this or these IPS functionality(ies), an identification of said actor A, for example by a communication of a public key of actor A, as well as optionally a validity period of this allocation.

[0075] Actor A will then be able to generate a SCRPT configuration command based on the information provided by the former transferring owner.

[0076] The SCRPT configuration command includes an identification of a property or access right of the feature.

[0077] If the configuration command includes the identification of an access right, then the property management includes an allocation of access permissions to the identified functionality.

[0078] Actor A can thus configure the system-on-a-chip (SOC) by choosing to activate or deactivate the functionalities it owns. Actor A can then provide the SOC in this configuration to another actor, B. Actor B, without knowing the key of owner A and / or manufacturer ST, will not be able to generate any further configuration commands and will not be able to modify the allocation of functional rights established by actor A.

[0079] The configuration command generated by actor A may include the identification of the ownership right of said functionality to an actor B, identified in said order, then the management of ownership includes an allocation of ownership to the identified actor B, that is to say a transfer of ownership from actor A to actor B.

[0080] In this regard, actor A can also provide actor B with CRTF information enabling the transfer of ownership of at least one ISP functionality from actor A to actor B.

[0081] Here too, the CRTF information is signed by actor A, and includes an identification of said at least one IPS functionality, an identification of said actor B, for example by a communication of a public key of actor B, as well as optionally a validity period of this allocation.

[0082] In summary, in the first implementation, said directory is contained in a script, for example, a script stored in the secure memory SECMEM. The configuration command is communicated in a modified version of said script by actor A, B, who has knowledge of said CRTF information for the transfer of ownership. The configuration command includes, in particular, the public key of the new owner A (resp. B) and is signed by the former owner ST (resp. A).

[0083] An interpretation of the script is implemented within the framework of property management, for example by a CONT control unit of the MUOS management circuit, in order to execute in practice said allocation to the identified actor of the identified functionality.

[0084] Fig. 3 illustrates an example of the first embodiment of the MUOS property management circuit, corresponding to, that is to say, particularly capable of processing configuration commands communicated in the form of a script (human-readable programming language).

[0085] The MUOS property management circuit is capable of receiving the CmdConfig configuration command from a USR user, for example via a COMM communication interface present in the system-on-chip SOC.

[0086] The CmdConfig configuration commands are processed by a QPU authentication unit, notably capable of managing and storing KMng encryption keys in a KS register, and of authenticating Auth the signature of the CmdConfig configuration command.

[0087] The QPU authentication unit is configured for example to authenticate the origin of the CmdConfig configuration command by verifying that the signature of the CmdConfig configuration command corresponds to a public key, stored in the KS registry, of the last known owner for the identified functionality, i.e. the owner listed in said directory at the time of receipt of the CmdConfig command.

[0088] Signature verification can be done using conventional methods of symmetric or asymmetric encryption, possibly combined with a hash function of the command.

[0089] The signature of the CmdConfig configuration command can be verified and authenticated by obtaining a fingerprint from the hash of the script, by decrypting with the public key of said last known owner, the encrypted fingerprint of the script.

[0090] If the CmdConfig configuration command is authenticated, then the received script SCRPT is stored in clear text in the secure SECMEM memory; otherwise, the command is rejected. See Figures 4 and 5 below for further details.

[0091] In addition, the MUOS property management circuit is configured for example to program the CFGBK configuration register, for example in a section of the SECMEM secure memory, in order to communicate the configuration of the allocation of functional rights.

[0092] Optionally, the CFGBK configuration register may be capable of recording content irreversibly, for example by means of a FUS-type mechanism (see figures 10-14), if said CmdConfig configuration command further defines an irreversible character of allocation.

[0093] Figure 4 illustrates a method of implementing verification by the QPU authentication unit.

[0094] In an initial state 410, the QPU unit is in a configuration command waiting state.

[0095] When a configuration command is received, then a check of the signature it contains is made in a step 420.

[0096] For example, the configuration command is communicated in a message containing a hash of the command's content, encrypted using a hashing mechanism, and the signature of the command encrypted with the sender's private key. Signature verification typically involves decrypting the signature with a public key associated with the sender, so that message authentication occurs when the decrypted signature matches the hash; the signature is then said to be "valid".

[0097] If the signature is not valid, then the configuration command is ignored and rejected 430, and the QPU returns to the waiting state 410. An error message may be generated. A record of the rejection may be logged.

[0098] For example, the signature is invalid if the message communicating the configuration command is not signed by the owner of the identified feature. The command will also be rejected in step 454 ([Fig. 5]) if an actor requests a modification to a part of the script for which they do not have the appropriate rights.

[0099] If the signature is valid, then the fingerprint of the contents of the confi command The figuration is decoded in a step 440, for example first deciphered by the corresponding hashing mechanism, so as to obtain the command "in plain text", then interpreted, that is to say decoded and executed according to the language of the intended script.

[0100] If the command requires a modification of the script, then the modifications are made in the script in a script modification procedure 450, in particular capable of taking into account and respecting the rights of the different actors.

[0101] Reference is made in this regard to [Fig.5].

[0102] Figure 5 illustrates an example of a method 500 for implementing the procedure for modifying script 450.

[0103] The procedure for modifying script 450 includes a comparison 453 between the modified data received 451 and the current script (before modification) 452, loaded from SECMEM memory.

[0104] Initially, if the differences identified in comparison 453 involve a prohibited deletion of at least one line of script, then the modification command is rejected 454.

[0105] In a second step, proofs of ownership of the IPS features whose rights are modified are verified in step 455. For example, it can be verified in this regard that a transfer of ownership of an IPS feature is signed by the former owner and includes a public key of the new owner. For example, it can be verified that a transfer of the right to use an IPS feature is modified by the owner of the IPS feature.

[0106] The identification of the IPS functionality can be done by an internal identifier of the system on chip SOC, of ​​the type device address or compartmentalization identifier “CID” (see the aforementioned publication).

[0107] In case of infringement of property rights, the modification order is rejected 454.

[0108] If the properties are respected and the new rights are valid, then a new script is generated and is saved in SECMEM memory, during step 456. Note that the new script does not necessarily replace the old script, which can allow for a history of changes.

[0109] We refer again to [Fig.4].

[0110] At the end of the script modification procedure 450, a response can be generated in a step 460, before returning to the state of waiting for a next command 410.

[0111] If the command includes a request to modify the script, then, if successful, the new modified script is sent in response 460 to the sender.

[0112] If the command includes a request to obtain the script(s), then the current script is sent in response 460, as well as possibly one or more previous scripts before modifications.

[0113] Reference is now made to figures 6 to 9, illustrating a second embodiment and implementation method for communicating the configuration command.

[0114] Fig. 6 illustrates the second implementation mode for the lifecycle management process in which configuration commands are communicated in the form of CRTF, CRTF-CFG certificates, i.e. commands encoded in a data string having a pre-established structure, possibly in a human-readable manner.

[0115] As in the first implementation mode described above in relation to [Fig.2], the CRTF, CRTF-CFG configuration commands may include an identification of an access right, so as to allocate access permissions to the identified functionality, or an identification of an ownership right, so as to allocate the identified functionality to a new owner.

[0116] In this regard, actor A can also provide actor B with the CRTF certificate enabling the transfer of ownership of at least one IPS functionality from actor A to actor B, so that the new owner B is the issuer of the CRTF command, without actor A needing to communicate with the system on chip.

[0117] Here too, the CRTF information is signed by actor A, and includes an identification of said at least one IPS functionality, an identification of said actor B, for example by a communication of a public key of actor B, as well as optionally a validity period of this allocation.

[0118] In practice, in the second implementation, the owner directory is, for example, contained in a single-programmable memory PRPOTPM ([Fig. 7]), i.e., for example, a memory in which content can be added, but existing content cannot be modified. The configuration command is communicated in a CRTF certificate containing a data string of the type "command word," and the CRTF certificate can be stored in the secure memory SECMEM. Ownership management includes an interpretation of the CRTF certificate, for example by a control unit CONT, in order to execute said allocation of rights for the identified IPS functionality, for example by adding a property line in the single-programmable memory PRPOTPM, or by storing access permissions in the secure memory SECMEM.

[0119] Fig. 7 illustrates an example of the second embodiment of the corresponding MUOS property management circuit, i.e., particularly capable of processing configuration commands communicated in the form of certificates.

[0120] As in the first embodiment described above in relation to [Fig.3], the CmdConfig configuration commands are communicated by a USR user via the COMM interface and are processed by the QPU authentication unit, in particular with regard to Auth authentication and KS, KMng key management.

[0121] Reference is made to figures 8 and 9 described below concerning the implementation of the verification by the QPU authentication unit.

[0122] [Fig.8] illustrates a process 800 analogous to the process 400 described previously in relation to [Fig.4].

[0123] In particular, the process 800 includes an initial state 810 substantially identical to the state 410 of the process 400; a signature verification step 820 and a possible rejection step 830, substantially identical to the step 420 and the rejection 430 of the process 400; a command decoding step 840 substantially identical to the step 440 of the process 400; a configuration modification procedure 850 in the event of a configuration modification request (reference will be made in this regard to [Fig.9]), a response containing the current state of the configuration generated in a step 860 substantially identical to the step 460 of the process 400.

[0124] In addition, a procedure for registering an owner 870 in the PRPOTPM directory, in case of a request to change ownership. Indeed, the second embodiment and implementation involves modifying the owners internally in the directory stored in the single-programmable memory PRPOTPM; unlike the first embodiment and implementation where the directory is communicated in each script.

[0125] Figure 9 illustrates an example of a method for implementing the procedure configuration modification 850.

[0126] The configuration modification procedure 850 includes a check 854 that the owner who signed the received data 852 (the data string encoding the command) corresponds to the last owner of the identified functionality, according to the contents of the PRPOTPM directory.

[0127] If the signature does not match the last known owner, then there is a violation of ownership and the request to modify the command configuration is rejected 856.

[0128] If the signature matches the last known owner, then the received certificate is accepted, and the obsolete parts of the old certificates are discarded in a SECMEM memory write step 858.

[0129] Reference is now made to figures 10 to 14 illustrating a practical example of the operations of the MUOS multi-actor property management circuit according to the first embodiment and the second embodiment (elements belonging exclusively to the second embodiment PRPOTPM, CRTF-CFG, are drawn with dashed lines).

[0130] For example, in the first embodiment and implementation, the SCRPT scripts are expressed in two parts: - a header defining the properties, that is, the directory in which the pro- Owners of the features are listed, and - a script, or "program code", for configuring IPS features, which, when executed by the CONT control circuit, determines the configuration of IPS features of the system-on-chip SOC.

[0131] The header and program code contain sequences of instructions, for example usually one instruction per line of the script. Since each line of instruction is signed, the control circuit is configured to ensure, at execution time, that each instruction respects the rights of the different actors.

[0132] For example, a script template with a language suitable for basic configuration commands is expressed below. The phrases between / * and * / are comments explaining the function of the corresponding line of instruction.

[0133] SCRPT SignST> ST OWN IPN / *The actor "ST" is the owner of the feature IPN* / SignST> User OWN IPI, IP2, IP3 / *The actor "User" owns the IPI, IP2, IP3 functionalities* / SignUser> ENABLE IPI, IP3 / *command signed by the actor "User" enabling IPI, IP3 functionalities, i.e., granting the system permission to access IPI, IP3 functionalities* / SignUser> FUSE IPI, IP2, IP3 / *command signed by the actor "User" making the configuration of the IPI, IP2, IP3 functionalities irreversible, i.e. IPI, IP3 activated and IP2 deactivated* / SignST> ENABLE IPN for 100 tick / *command signed by the actor "ST" enabling the IPN functionality for a duration of 100 tick signal cycles* /

[0134] Each line of instruction includes: - a signature "SignST>", "SignUser>", allowing proof that the command is indeed added by the owner of the configured feature; - the command, such as an "ENABLE" activation command, a "DISABLE" deactivation command, a "FUSE" configuration irreversibility command, or a "OWN" property definition command; - the list of relevant IPS features; - Optionally, an activation / deactivation condition can be added, including a "for N tick" time condition.

[0135] The time condition will trigger an alarm and will be executed when the always-on timestamping system sends an event. In other words, the allocation of the functionality's rights can be scheduled for a future time.

[0136] For example, in the second embodiment and implementation, the system MUOS configuration consists of two parts: - the uniquely programmable memory PRPOTPM, that is, the directory in which the owners of the features are listed, and - CRFT-CFG configuration certificates, which determine how the system-on-chip (SOC) functionalities should be configured for different stakeholders.

[0137] Once the certificate is signed, the CONT control circuit, which is capable of executing the configuration in practice, can verify the validity of the certificate.

[0138] Each CRTF certificate may, for example, have the structure of a line of instruction described above, that is to say, comprising: - a signature; - the order; - the list of relevant IPS features; - optionally, an activation / deactivation condition.

[0139] Fig. 10 illustrates the case of a change of ownership command for the IPI, IP2, IP3 functionalities.

[0140] In this example, the manufacturing actor "ST" initially owns all the functionalities IPI, IP2, IP3, IPN and cedes a part of them (IP1-3) to an actor "User".

[0141] In the first embodiment, this is expressed in the script header:

[0142] SCRPT SignST> ST OWN IPN SignST> User OWN IPI, IP2, IP3

[0143] In the second embodiment, this is expressed in the single-programmable memory:

[0144] PRPOTPM PKst> Obi 111 / *each bit position 1111 corresponds respectively to the functionalities IPN, IP3, IP2, IPI* / PKuser > ObOl 11 / *The User actor owns IP3, IP2, IPI, the former owner "1" of IPN remains unchanged* /

[0145] The QPU authentication unit registers a new public key of the actor "User", denoted PKuser.

[0146] Fig. 11 illustrates the case of a configuration command, in which the User actor activates the IPI, IP3 functionalities.

[0147] In the first embodiment, this is expressed in the SCRPT script by the instruction "SignUser> ENABLE IPI, IP3"

[0148] In the second embodiment, this is expressed in the part of the SECMEM secure memory containing the CRTF-CFG configuration certificates:

[0149] SIGN(SKuser, {IPI,0],{IP3,0}) / *an example of expression of the cor- respondant, signed with the SKuser secret key of the actor "User"* /

[0150] This is permitted because the User actor is the owner of the IPI, IP3 functionalities; so access is allocated to the IPI, IP3 functionalities in the CFGBK configuration register "IPI: unlock", "IP3: unlock".

[0151] Fig. 12 illustrates the case of a configuration command, in which the User actor wants to make the current configuration of the IPI, IP2, IP3 functionalities irreversible.

[0152] In the first embodiment, this is expressed in the SCRPT script by the instruction "SignUser> FUSE IPI, IP2, IP3"

[0153] In the second embodiment, this is expressed in the CRTF-CFG configuration certificates:

[0154] SIGN(SKuser, “freeze”, IP: 1,2,3) / *an example of an expression for the corresponding certificate, signed with the SKuser secret key of the actor “User”* /

[0155] This is permitted because the User actor is the owner of the IPI, IP3 functionalities; so access is allocated to the IPI, IP3 functionalities in the configuration register.

[0156] CFGBK IPI: unlock / fused IP2: lock / fused IP3: unlock / fused

[0157] Fig. 13 illustrates the case of a configuration command, in which the User actor activates the IPI functionality for a limited time, for example, one week.

[0158] In the first embodiment, this is expressed in the SCRPT script by the instruction "SignUser> IF t < t+1 week Then enable IPI".

[0159] In the second embodiment, this is expressed in the CRTF-CFG configuration certificates:

[0160] SIGN(SKuser, {IPI, 0x240C8400}) / *an example of an expression for the corresponding certificate, signed with the SKuser secret key of the actor "User"* /

[0161] This is permitted because the User actor is the owner of the IPI functionality; therefore, access is allocated to the IPI functionality in the CFGBK configuration register "IPI: unlock". Furthermore, an alarm wake-up time is programmed to be one week after the present time t, "Alarm set to t+1 week", in the always-active STS secure timestamping circuit.

[0162] Fig. 14 illustrates the case of Fig. 13, after expiry of the limited activation time of the IPI functionality (for example one week later), i.e. at the time when the IPI functionality should no longer be activated.

[0163] At this moment, the alarm is generated and communicated as an interrupt to the CONT control circuit, so as to trigger a reallocation of access, henceforth unauthorized, to the IPI functionality in the CFGBK configuration register "IPI: lock".

[0164] There is no longer a planned wake-up in the always-active STS secure timestamping circuit "No alarm set" and the old CRTF-CFG configuration certificates are deleted from the SECMEM secure memory "None".

[0165] Finally, it should be noted that the examples described above in relation to Figures 1 to 14 can be implemented, entirely or partially, in several possible ways, for example: according to a completely hardware configuration, by a "hard-coded" circuit of the state machine type; according to a hardware configuration but including a hidden processor configured in software; according to a hybrid firmware and hardware configuration of the "secure enclave" type; or according to a completely software configuration, for example in a secure environment of a "TEE" processor (acronym for the English terms "Trusted Execution Environment").

[0166] Furthermore, regardless of the embodiment chosen, the implementation of the allocation of rights to the system-on-a-chip (SOC) functionalities advantageously forms part of the SOC startup process. Furthermore, and also advantageously, said implementation of the allocations must be executed to enable access to the protected functionalities, so that otherwise the functionalities are not accessible and only the common part of the SOC is available.

Claims

Demands

1. A lifecycle management method (LCMS) for a system-on-chip (SOC) with features (IPS), comprising a multi-actor ownership management (MUOS) listing owners of features in a directory, and comprising an allocation of rights to a feature (IPS) during the lifecycle of the system-on-chip, based on a configuration command (CmdConfig) comprising an identification of said feature, an identification of an ownership or access right of the feature, and a signature of the owner of that feature (SignST>, SignUser>).

2. A method according to claim 1, wherein said directory is contained in a programming script (SCRPT) stored in secure memory (SECMEM), and said configuration command (CmdConfig) is communicated in a modified version of said script, the method comprising an execution (CONT) of the script in order to perform said allocation of rights of the identified functionality.

3. A method according to claim 1, wherein said directory is contained in a single-programmable memory (PRPOTPM), and said configuration command (CmdConfig) is communicated in a certificate (CRTF-CFG) comprising a data string and stored in a secure memory (SECMEM), the method comprising an interpretation (CONT) of the certificate in order to perform said allocation of rights of the identified functionality.

4. A method according to any one of claims 1 to 3, wherein, if said configuration command (CmdConfig) includes the identification of an access right, then the management of the property includes an allocation of access permissions to the identified functionality.

5. A method according to any one of claims 1 to 4, wherein, if said configuration command (CmdConfig) includes the identification of the ownership right of said functionality to an identified actor, then the ownership management includes an allocation to the identified actor of ownership of the identified functionality.

6. A method according to any one of claims 1 to 5, wherein said ownership management includes a verification that said signature of the configuration command (CmdConfig) authenticates the last known owner in said directory for the identified functionality.

7. A method according to any one of claims 1 to 6, wherein the system on the chip further includes a system (RIF) authorizing and prohibiting access to features (IPS), depending on the contents of a configuration register (CFGBK), said ownership management including programming of the configuration register (CFGBK) to allocate said feature rights.

8. Method according to claim 7, comprising an irreversible (fused) recording of a content of the configuration register (CFGBK), if said configuration command further defines an irreversible character of the allocation.

9. A method according to any one of claims 7 or 8, wherein said allocation of rights to features is carried out at system-on-chip (SOC) startup, in cooperation with said system (RIF) authorizing and prohibiting access to features, so that all access is prohibited prior to said allocation.

10. A method according to any one of claims 1 to 9, further comprising an always-active generation of a timestamp (STS), wherein said ownership management includes scheduling at a future time (t+1 week), determined by said timestamp, of said allocation of the rights of the functionality.

11. System on chip (SOC), having features (IPS), and comprising a lifecycle management device (LCMS) incorporating a multi-actor ownership management circuit (MUOS) configured to list owners of features in a directory, and to allocate rights of a feature (IPS) during the lifecycle of the system on chip (SOC), based on a configuration command comprising an identification of said feature (IP1-IPN), an identification of an ownership or access right of the feature, and a signature of the owner of that feature (SignST>, SignUser>).

12. System on chip according to claim 11, wherein said directory is contained in a programming script (SCRPT) stored in secure memory (SECMEM), and said configuration command is communicated in a modified version of said script (SCRPT), said property management circuit (MUOS) comprising a control unit (CONT) configured to execute said script (SCRPT) in order to perform said allocation of identified functionality rights (IPI, IPN).

13. System-on-a-chip according to claim 11, wherein said directory is contained in a uniquely programmable memory (PRPOTPM), and said configuration command is communicated in a certificate (CRTF) comprising a data string and stored in a secure memory (SECMEM), said property management circuit (MUOS) comprising a control unit (CONT) configured to interpret said certificate (CRTF) in order to perform said allocation of rights of the identified functionality (IPI, IPN).

14. System on chip according to any one of claims 11 to 13, wherein the property management circuit (MUOS) is configured to allocate access permissions to the identified functionality (IPI-IPN), if said configuration command includes the identification of an access right.

15. System on chip according to any one of claims 11 to 14, wherein the property management circuit (MUOS) is configured to allocate to the identified actor (A, B) the ownership (PRP) of the identified functionality (IPI-IPN), if said configuration command includes the identification of the ownership right of said functionality to an identified actor (A, B).

16. System-on-chip according to any one of claims 11 to 15, wherein said property management circuit (MUOS) includes an authentication unit (QPU) configured to verify that said configuration command signature (PKA) authenticates the last known owner (A) in said directory for the identified functionality.

17. System on chip according to any one of claims 11 to 16, further comprising a system (RIF) configured to allow and deny access to system on chip (SOC) functionalities, based on the contents of a configuration register (CFGBK), said property management circuit (MUOS) being configured to program the configuration register (CFGBK) to allocate said functionality rights.

18. System on chip according to claim 17, wherein said configuration register (CFGBK) is capable of irreversibly recording contents (FUS), if said configuration command further defines an irreversible character of allocation.

19. System-on-chip according to claim 17 or 18, wherein the property management circuit (MUOS) is configured to perform said allocation of feature rights at system-on-chip (SOC) startup, in cooperation with said system configured to authorize and deny access to system-on-chip features (SOC) so that all access is prohibited before said allocation.

20. System-on-chip according to any one of claims 11 to 19, further comprising a secure always-on timestamping (STS) circuit, wherein said ownership management circuit (MUOS) is configured to schedule at a future time (t+1 week), determined by said timestamping (STS) circuit, said allocation of rights of said functionality.