Method and apparatus for providing individual secure systems to multiple untrusted parties

Abstract

A method and apparatus for intelligent wireless protocol optimization including storing a first user key and a second user key in a memory; receiving, by a processor, a secret key; decrypting, by the processor, the secret key using the first user key to extract a master key; providing, by the processor, an electronic control unit in response to the master key; and deleting, by the processor, the second user key in response to the electronic control unit in response to the provision of the master key.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to electronic computing systems. More particularly, aspects of the present disclosure relate to systems, methods, and apparatuses for providing a same computing system to a plurality of untrusted parties, wherein each party utilizes a secure credential to access and provide the computing system. BACKGROUND

[0002] Manufacturers of electronic components, such as processors, electronic control units, and electronic computing systems, often provide these systems to a plurality of competing parties. These systems often require secure data access to the device, secure communication between devices, and can contain proprietary algorithms, electronic data, and the like. As such, these systems can require installation of each competing party’s proprietary information on the system prior to delivery to each party. This creates a problem in that a different system must be created for each party so that the proprietary information is not distributed and / or shared between parties. Creating a separate system for each user results in a proliferation of components, which increases the cost associated with the system and increases the complexity of supply and distribution. It is desirable to overcome these problems and provide a single portion of a computing system to mutually untrusted parties to protect each party’s secure credential.

[0003] The information disclosed in this Background section is for the purpose of enhancing the understanding of the background of the application and it can contain information not prior art in this country that is not known to be relevant to the patentability of the claimed application in this country. SUMMARY

[0004] Various secure electronic systems and related control logic for providing secure electronic systems, methods of manufacturing and operating such systems, and motor vehicles equipped with on-board secure electronic systems are disclosed herein. By way of example and not limitation, a computing system is presented that can be provided to mutually untrusted parties, the computing system protecting the secure credentials of each party through methods and means for enabling secure access for each party and corresponding control systems.

[0005] According to one aspect of the present disclosure, a method includes storing a first user key and a second user key in a memory, receiving, by a processor, a secret key, decrypting, by the processor, the secret key using the first user key to extract a master key, providing, by the processor, an electronic control unit in response to the master key, and deleting, by the processor, the second user key in response to the providing of the electronic control unit in response to the master key.

[0006] According to another aspect of the present disclosure, wherein the first user key and the secret key are generated using an algorithm associated with the first user in response to a unique identifier of the electronic control unit.

[0007] According to another aspect of the present disclosure, wherein the secret key is received at a controller area network interface.

[0008] According to another aspect of the disclosure, the second user key is associated with a second user.

[0009] According to another aspect of the disclosure, the further provision of the electronic control unit is performed in response to the processor confirming deletion of the second user key.

[0010] According to another aspect of the disclosure, the processor is further configured to allow the provision of security credentials for use by the electronic control unit in response to the master key.

[0011] According to another aspect of the disclosure, the master key is a first security credential associated with a first user.

[0012] According to another aspect of the disclosure, the first user key and the second user key are generated by a supplier of the electronic control unit in response to a unique identifier of the electronic control unit and stored in memory by the supplier.

[0013] According to another aspect of the disclosure, the processor is further configured to change the first user key in response to receiving a default unlock key associated with the first user.

[0014] According to another aspect of the disclosure, a security controller includes a memory configured to store a first key and first data associated with a first user and a second key and second data associated with a second user, an interface to receive a received key, and a processor to decrypt the received key in response to the first key to generate a master key, to provide the electronic control unit in response to the master key, and to delete the second key and the second data in response to the electronic control unit in response to the provision of the master key.

[0015] According to another aspect of the disclosure, the first key and the received key are generated using an algorithm associated with the first user in response to a unique identifier of the security controller.

[0016] According to another aspect of the disclosure, the interface is a controller area network interface.

[0017] According to another aspect of the disclosure, the second data is a control algorithm associated with an ecosystem of the second user.

[0018] According to another aspect of the disclosure, the processor is further operable to confirm that the second data is deleted before allowing the further provision of the electronic control unit.

[0019] According to another aspect of the disclosure, the processor is further configured to allow the provision of security credentials for use by the security controller in response to the master key.

[0020] According to another aspect of the disclosure, wherein the first data is a first security credential associated with the first user system, and wherein the second data is a second security credential associated with the second user system.

[0021] According to another aspect of the disclosure, wherein the first key and the second key are generated by a vendor of the security controller in response to a unique identifier of the security controller, and stored in memory by the vendor.

[0022] According to another aspect of the disclosure, wherein the interface is further configured to receive a default unlock key associated with the first user, and wherein the processor is further configured to change the first key and not change the first data, the second data, and the second key in response to receiving the default unlock key.

[0023] According to another aspect of the disclosure, a vehicle electronic control unit comprises a memory configured to store a first user key associated with a first user, a first provisioning data associated with the first user, a second user key associated with a second user, and a second provisioning data associated with the second user, a network interface configured to receive a received key, and a processor configured to decode the received key to generate a master key, delete the second provisioning data and the second secret key in response to the generation of the master key, and provide the vehicle electronic control unit in response to the master key and the first provisioning data in response to the deletion of the second provisioning data and the second secret key.

[0024] According to another aspect of the disclosure, wherein the first user key and the received key are generated using an algorithm associated with the first user in response to a unique identifier of the vehicle electronic control unit.

[0025] The above advantages and other advantages and features of the disclosure will become apparent from the following detailed description of the preferred embodiments when taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0026] The above and other features and advantages of the present application and the manner of realizing the same can be understood by referring to the following description of a preferred embodiment in connection with the accompanying drawings, in which:

[0027] Figure 1 An exemplary environment for providing separate security systems to a plurality of untrusted parties is shown in accordance with an exemplary embodiment.

[0028] Figure 2 A block diagram of a system for providing separate security systems to a plurality of untrusted parties is shown in accordance with another exemplary embodiment.

[0029] Figure 3A flowchart illustrating a method for providing separate secure systems to multiple untrusted parties, in accordance with an example embodiment, is shown.

[0030] Figure 4 A block diagram illustrating another system for providing separate secure systems to multiple untrusted parties, in accordance with another example embodiment, is shown.

[0031] Figure 5 A flowchart illustrating another method for providing separate secure systems to multiple untrusted parties, in accordance with another example embodiment, is shown.

[0032] The examples set forth herein illustrate preferred embodiments of the present application and should not be construed as limiting the scope of the present application in any way. DETAILED DESCRIPTION

[0033] Embodiments of the present disclosure are described herein. It is to be understood, however, that the disclosed embodiments are merely examples, and other embodiments can take various alternative forms. The figures are not necessarily to scale; some features can be exaggerated to show details, which can be used in making and in understanding the present application. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for the claims. The various features illustrated herein can be combined or combined in various ways to produce embodiments of the application not specifically described. The scope of the application is thus not to be limited to the specific embodiments described and shown, but only by the claims.

[0034] Turning now to the drawings Figure 1 , an example environment 100 for providing separate secure systems to multiple parties, in accordance with an example embodiment, is shown. The example environment 100 includes a vendor 110, a component 120, a first user 130, a second user 140, and a third user 150. The environment 100 also includes a first user key 135, a second user key 145, a third user key 155, and a public key 125. The disclosed systems and methods are configured to facilitate the provision of components by a trusted vendor 110 to mutually untrusted users 130, 140, 150 that need to be able to provide secure credentials for use in their ecosystem in a manner that does not allow other parties to know or improperly use their secure credentials, even if such provision is observed.

[0035] In this example embodiment, the trusted vendor 110 provides the component 120 with a default public key 125 and a unique key generated for each user 130, 140, 150 of the receiving component 120. The component 120 is configured to reject software updates, which can result in the component 120 being modified by one party to behave maliciously in the other party's ecosystem. The component 120 is configured to not allow software updates until the component is configured for use in a particular party's ecosystem, which results in erasure of all other party's secret keys and any related data. The unique keys ensure that each party is able to maintain the trustworthiness of its security credentials even if another party observes the provision of those security credentials.

[0036] To implement separate security systems for multiple parties, the vendor 110 first provides a component 120 to each of a first user 130, a second user 140, and a third user 150, where each component 120 has a unique ID (UID). Each user has a user key 135, 145, 155 that is secret only to that user. A secret key is generated for each component using the UID and the user key 135, 145, 155. The secret key for each party is derived from the UID using the user key 135, 145, 155, which ensures that each user knows only its own secret key and not the secret keys of the other users 130, 140, 150.

[0037] Each of the users 130, 140, 150 that receive a component 120 are able to configure the component 120 for use in their ecosystem by using the UID and their user key 135, 145, 155 to generate the appropriate secret key in the component and provide their security credentials to the component. Without the appropriate user key 135, 145, 155, another user 130, 140, 150 that receives the component is unable to configure the component for use in another party's ecosystem. Furthermore, other users that receive the component 120 are unable to determine the security credentials of the other party if they observe the component being configured, as the security credentials are encrypted with the user key 135, 145, 155 of the party that is unknown to the other users. Once the component 120 is accessed with a particular user key 135, 145, 155, information related to other users is erased to prevent a party from using the security credentials of another party after taking control of the component. This is achieved by not allowing software updates until all other user keys 135, 145, 155 are erased. In one example embodiment, each of the users 130, 140, 150 are located in different regions, where each region has a unique user key 135, 145, 155

[0038] Each component 120 is also provided with a public key 125 for each side of the component 120. Because the component 120 will not allow software updates to occur until it is configured for use by a particular user, a default root public key 125 is used to transition to the user's production root public key, but is not allowed to be used for software updates. When the production root public key is provided, it erases the secret keys for all other sides before allowing the production root public key to be used to change the software. This prevents any side from being able to modify the software of that component and use another user's secret key to determine the security credentials used in that user's ecosystem, or to be able to put malicious software on a component 120 with valid security credentials for another user's ecosystem.

[0039] Turning now to Figure 2 , a system 200 for providing individual security systems to multiple parties is shown, in accordance with an example embodiment. The example system 200 can include a processor 210, a memory 220, and an interface 230. In this example embodiment, the system 200 can be a component, such as an automotive electronic control unit (ECU) provided by one vendor to multiple independent users, each of which requires a unique configuration or provisioning of the component, or which has proprietary software pre-installed on the system 200. These pre-configured individual user software can contain user intellectual property, and therefore it is desirable to limit access to the individual user software to only authorized parties. In this example, the user key can be a provisioning key or the like, which is used to generate a secret key in response to the master key and the provisioning key.

[0040] In this example embodiment, the memory 220 is configured to store multiple sets of user data. This user data can include software algorithms, system or component provisioning data, and / or other sensitive information. In the example of an electronic control unit, the component 200 can include software that is specifically designed to perform control functions for vehicle systems, such as powertrain, climate control systems, infotainment systems, body systems, chassis systems, etc. Further, the memory 220 can include security credentials, such as a user key, which is used to facilitate the provisioning of a master key in the system 200. In this example embodiment, the memory 220 can include a user key that is unique to each user, where the user key is derived in response to the component UID. Each user key is derived from the UID using a different secret process or algorithm that is known only to the vendor and the intended user. Further, the memory 220 can include a default root public key for each side of the component that is received. The default root public key can be used to transition to the user's key, but is not allowed to be used for software updates.

[0041] The interface 230 can be configured to receive and transmit data between the processor 210 and external systems. In one example embodiment, the interface 230 can receive a secret key from a user, which is intended to provide access to the component for the user to provide and / or configure. In one example embodiment, the secret key is a master key encoded in response to a user key. The interface 230 can be a network interface, such as a controller area network (CAN) bus, an Ethernet port, a universal serial bus (USB) port, or a wireless network interface, such as an antenna, etc. Further, the interface 230 can receive programming data or program update data for executing an operational algorithm that controls the external system. The interface 230 can also receive operational data and / or error codes from the processor 210 for coupling to an external diagnostic system, such as an on-board diagnostic system interface (OBD-II), etc.

[0042] The processor 210 is configured to receive data from the interface 230. In response to the received data, the processor 210 can determine whether the received data is a secret key or a default public key. If the data is a default public key, the processor 210 can subsequently receive instructions related to converting the component to a user secret key. However, the processor 210 can not change data or software on the component in response to the default public key to avoid leaking private user algorithms or data and / or avoid installing malicious software on the system. In one example, the received data is a master key encoded using a user key. The processor 210 is configured to decode the secret key using the stored user key to extract the master key. The processor 210 is then configured to use the master key to provision the device. The processor 210 then deletes all data associated with other users from the memory 220. Once the other user data is deleted, the processor 210 can then configure the remaining data in the memory and / or execute a stored algorithm associated with the user in response to additional instructions received at the interface.

[0043] When the processor 210 decodes the secret key using the user key to extract the master key, the processor 210 can initially provision the component by providing the master key in the component and erasing all other parties’ secret keys before allowing the root public key to be generated for changing software. This prevents a party from being able to modify the software of that component and use another party’s secret key to determine secure credentials used in that party’s ecosystem, or being able to put malicious software on a component that has valid secure credentials to another party’s ecosystem. The user can generate the key using the user’s unique key generation algorithm and the UID of the component. The secret key can be an alphanumeric sequence composed of numbers.

[0044] Turning now to Figure 3, showing a flowchart illustrating a method 300 for providing individual secure systems to multiple parties, in accordance with example embodiments. The example method is configured to receive a secret key generated by a user in response to a UID of a component and a master key associated with the component, decode the secret key to extract the master key, provision the component with the master key, delete information stored within the component that is not associated with the user in response to provisioning the component with the decoded master key, and provide access to provision control of the component in response to the deletion of the information. The data can also include a default root public key for each potential user.

[0045] The method first receives data 310 from a component manufacturer and stores the data in memory. The data can include proprietary or confidential information for each potential user of the component. The data can be provided to the manufacturer by the user prior to provision to the component. Additionally, the data can include a secret key for each potential user, where the secret key is generated by the manufacturer in response to an algorithm and the UID of the component and a master key associated with the component. Each key is then stored in memory. A default public key can also be included in the data and stored in memory. The default root public key can be used to convert the component to a user’s key, but cannot be used for software updates to prevent modification of the software of the component, determination and / or use of another user’s key to determine secure credentials used in that user’s ecosystem, or for use of malicious software on a component that has valid secure credentials to another user’s ecosystem.

[0046] The method can next operate to receive 315 a secret key via an interface. The secret key can be an alphanumeric string. The method then determines 320 whether the key is a user secret key. The key can be determined to be a secret key in response to other data received with the key, such as a data header or the like, or by comparing the key to stored keys, depending on the format of the key. Additionally, a provisioning record received with the secret key or as part of the secret key can include a parameter indicating a region in which the user or component is being configured, such that the component can determine which of the stored user keys is associated with the received secret key. If the received key is determined to be a secret key, the method decodes 325 the secret key using the user key stored in memory. If the secret key does not match a secret key stored in memory, access is denied 335 and the method returns to waiting for additional data 310.

[0047] If the secret key is decoded using the user key, the method next determines 330 whether the decoded secret key results in a valid master key. If the decoded secret key is not a valid master key, the method denies 335 access to the component. If the decoded secret key is a valid master key, the method is configured to provide 337 the master key to the component and delete 340 all data associated with other users stored in memory or stored in the component. Data related to the user that submitted the secret key is not deleted. After the other user data is deleted, the method allows 345 the approved user to access the component. The approved user can then reconfigure the component or integrate the component into a user system.

[0048] If the decoded secret key is not determined 320 to be a valid master key, the method next determines 350 whether the received key is a public key. If the received key is a public key, the method can allow 355 access to the component for user key conversion and the like, but does not allow access or deletion of data within the component and does not allow updating, deleting or altering software within the component. The method returns to waiting 310 for the receipt of subsequent data.

[0049] Turning now to Figure 4 , a diagram illustrating an example embodiment of a security controller 400 for providing separate security systems to multiple parties is shown. The example electronic control unit 400 can include a memory 410, a processor 420, and an interface 430. The security controller 400 is configured to receive a secret key from a user generated in response to an algorithm associated with the user and a UID of the security controller. In this example, the secret key is a master key encoded by the algorithm in response to the UID. To provide secure access to the user so as to use the master key associated with the user to provide the security controller 400 in accordance with the user’s ecosystem and not expose proprietary information of other users stored within the memory of the security controller 400, the security controller 400 is configured to delete any information associated with all other users after receiving and verifying the secret key from the user.

[0050] In this example embodiment, the memory 410 is configured to store a first user key and first data associated with a first user, and a second user key and second data associated with a second user. For example, the first data can be a first security credential associated with a first user system, and the second data can be a second security credential associated with a second user system. Alternatively, the first data can be a first provisioning data associated with a first user ecosystem, and the second data can be a second provisioning data associated with a second user ecosystem. The first user key and the second user key can be generated by a vendor of the security controller in response to a unique identifier of the security controller and a first algorithm associated with the first user and a second algorithm associated with the second user. These keys can then be stored in the memory 410 by the vendor. For example, the first user key can be stored in the memory, and in response to the unique identifier of the security controller 400, a master key associated with the first user, and the algorithm associated with the first user, a secret key received from the user via the interface 430 can be generated.

[0051] The interface 430 can be a data port for receiving data and transmitting data to a processor within the security interface 400. The interface 430 can be a CAN bus interface, an Ethernet port, a wireless network interface, or other data coupling port. In one example embodiment, the interface 430 can be configured to receive a secret key from the first user after the security controller has been delivered to the first user by the vendor.

[0052] The security controller 400 can also include a processor 420 for decoding a secret key in response to one of the first user key and the second user key, for generating, decrypting, or decoding a master key, for verifying a master key, for deleting the second user key and the second data in response to a provision of the electronic controller in response to the master key. The processor 420 can then allow additional access to the first data and / or the electronic control unit in response to the provision of the electronic controller and / or an additional security provision of the electronic controller. The processor 420 can further operate to confirm that the second data is deleted before allowing access to the first data. The processor 420 can also be configured to allow a provision of a security credential used by the security controller in response to the provision of the master key and / or the deletion of the second user key and the second data. The interface 430 can also be configured to receive a default unlock key associated with the first user, and wherein the processor 420 is further configured to change the first key and not change the first data, the second data, and the second key in response to receiving the default unlock key.

[0053] In an example embodiment, the security controller 400 can be a vehicle ECU comprising a memory configured to store a first user key associated with a first user, a first provisioning data associated with the first user, a second user key associated with a second user, and a second provisioning data associated with the second user, a network interface configured to receive a received key, and a processor configured to decode the received key to generate a master key, to delete the second provisioning data and the second secret key in response to the generation of the master key, and to provision a vehicle electronic control unit in response to the master key and the first provisioning data, in response to the deletion of the second provisioning data and the second secret key. In one example, the first user key and the received key can be generated using an algorithm associated with the first user in response to a unique identifier of the vehicle electronic control unit.

[0054] Turning now to Figure 5 , a flowchart illustrating an example implementation of a method 500 for intelligent wireless protocol optimization is shown. The method first provides for storing 505 a first user key and a second user key in a memory. The first user key and the second user key can be generated by a provider of the device in response to a UID of the device using an algorithm or process that is unique to each user and private to that user.

[0055] The method next provides for receiving 510 a secret key by a processor. The secret key can be received by a data interface, such as a controller area network interface. The secret key can be generated by a user in response to a master key and a UID of a device, such as an ECU using an algorithm that is unique to each potential user. Thus, the secret generated for each user using the device UID and the unique algorithm generated for each user will generate a unique security key for each user and each device.

[0056] The method next is operable for decrypting 520 the secret key by a processor using the first user key stored in a memory within the device to extract a master key. In this example embodiment, the first secret key and the second secret key are generated by a provider of the device in response to a UID of the device and a unique algorithm for each user and stored by the provider in a memory within the device. The method next provides for provisioning 530 an electronic control unit by a processor in response to the master key. The provisioning in response to the master key can enable communication between other components within the system according to the user’s ecosystem.

[0057] In response to the provision of the master key, the method next deletes 540, by the processor, the second user key in response to the provision of the electronic control unit in response to the master key. In this example embodiment, the first provision data and the first user key are associated with a first user and the second provision data and the second user key are associated with a second user. In response to the first user providing the device interface with the secret key that generates the valid master key, all data stored associated with any other user than the first user can be deleted in order to maintain the confidentiality of the intellectual property of the other users and the security of their ecosystem.

[0058] The method next is configured to provide 550, by the processor, the device such as the ECU in response to the first provision data and the deletion of the second user key and the second provision data. The processor can be configured to allow the provision of the security credentials for use by the electronic control unit in response to the key being decoded to generate the valid master key. In one example, the provision of the electronic control unit in response to the first provision data can be performed in response to the processor confirming the deletion of the second user key and the second provision data to ensure the confidentiality of the other second user data.

[0059] In one example embodiment, the method is further operable to receive a default unlock key associated with the first user and wherein the processor is further configured to change the first user key and not change the first provision data, the second provision data, and the second user key in response to receiving the default unlock key. Further, the first provision data is a first security credential associated with a first user system and wherein the second provision data is a second security credential associated with a second user system. The security credentials can be used for communications on a secure network such as a CAN bus network or the like.

[0060] While at least one example embodiment has been presented in the foregoing detailed description, it should be appreciated that a wide variety of modifications exist. It should also be appreciated that the example embodiment(s) are only examples and are not intended to limit the scope, applicability or configuration of the disclosure in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing an example embodiment of the disclosure. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope of the disclosure as set forth in the appended claims and their legal equivalents.

Claims

1. A method for providing individual secure systems to a plurality of distrusting parties, comprising: storing a first user key and a second user key in a memory; providing a component to each of a first user and a second user, wherein each component has a unique ID, i.e., a unique UID; generating a respective secret key for each component using the respective UID and the respective user key, and receiving the secret key by a processor; decoding the secret key using the first user key by the processor to extract a master key; providing an electronic control unit by the processor in response to the master key; and deleting the second user key by the processor in response to the providing of the electronic control unit in response to the master key.

2. The method of claim 1, wherein, The first user key and the secret key are generated using an algorithm associated with the first user in response to a unique identifier of the electronic control unit.

3. The method of claim 1, wherein, The secret key is received at a controller area network interface.

4. The method of claim 1, wherein, The second user key is associated with the second user.

5. The method of claim 1, wherein, Further providing of the electronic control unit is performed in response to confirmation by the processor of the deletion of the second user key.

6. The method of claim 1, wherein, The processor is further configured to allow providing of a security credential used by the electronic control unit in response to the master key.

7. The method of claim 1, wherein, The master key is a first security credential associated with the first user.

8. The method of claim 1, wherein, The first user key and the second user key are generated by a vendor of the electronic control unit in response to a unique identifier of the electronic control unit and stored in the memory by the vendor.

9. The method of claim 1, further operable to receive a default unlock key, wherein the processor is further configured to change the first user key in response to receiving the default unlock key.

10. A secure controller, comprising: a memory configured to store a first key and first data associated with a first user and a second key and second data associated with a second user, the first user key and the second user key generated by a vendor of the secure controller in response to a unique identifier of the secure controller and a first algorithm associated with the first user and a second algorithm associated with the second user; an interface to receive a secret key from a user generated in response to an algorithm associated with the user and the unique identifier of the secure controller; and a processor to decode the received secret key using the first key to generate a master key, to provide an electronic control unit in response to the master key, to delete the second key and the second data in response to the providing of the electronic control unit in response to the master key.

Images