EP4313696A1

EP4313696A1 - System and method for secure identification, registration and commissioning of security devices

Info

Publication number: EP4313696A1
Application number: EP22779224.9A
Authority: EP
Inventors: Mushabbar Hussain; K V Muralidhara; Kiran KEKUDA
Original assignee: KPIT Technologies Ltd
Current assignee: KPIT Technologies Ltd
Priority date: 2021-03-31
Filing date: 2022-03-09
Publication date: 2024-02-07
Also published as: WO2022208195A1

Abstract

The present disclosure relates to a system and method for secure identification, registration, and commissioning of security devices to an OEM backend. The devices are capable of on-board auto-generation and storage of security keys, and root certificates in the HSM key storage of the corresponding devices, and storage of a self-signed certificate in the OEM backend and devices at factory stage. Further, the system and method involve a second computing unit (TCU) that receives self-signed certificate from the OEM backend, upon verification of unique identifiers associated with the devices by the OEM backend. The TCU further verifies an authentication token received from the device in response to a challenge token generated by the TCU, by extracting a public key of the corresponding device, from the self-signed certificate. Upon verification ofthe authentication token by the TCU, the OEM backend and TCU register the corresponding devices as authorized devices.

Description

SYSTEM AND METHOD FOR SECURE IDENTIFICATION, REGISTRATION AND COMMISSIONING OF SECURITY DEVICES

TECHNICAU FIEUD

[0001] The present disclosure relates to the field of embedded security devices employing Public Key Infrastructure (PKI) based authentication techniques, and more particularly the present disclosure relates to a system and method for identification, registration, and commissioning of embedded security devices comprising but not limited to an electronic control unit (ECU) of vehicles, to an OEM backend.

BACKGROUND

[0002] Background description comprises information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.

[0003] Embedded security devices (device) such as electronic control unit (ECU) of vehicle, IoT device, infotainment device, gaming device, and the likes, require security artefactsto be installed in them before they start functioning. These devices require data such as security keys, certificates, and device secrets to be installed in the devices for successful commissioning. Typically, a unique device detail or identification number associated with multiple devices being originally manufactured in a factory, along with their corresponding security keys, certificates, and device secrets are stored at an original equipment manufacturer (OEM) backend server. Later, at an enrolment or commissioning stage of these devices, these devices are firstly authenticated or verified by the OEM backend server, and accordingly, the security keys, certificates, and device secrets are transferred and installed in the devices for successful commissioning.

[0004] As the data pertaining to security keys, certificates and device secrets of the devices are highly confidential in nature, the data must be securely handled, transferred, and authenticated, to ensure that the data is not leaked out, which may allow unauthorized users to impersonate and register their devices (which were not originally manufactured in the factory) at the OEM backend. As a result, a well-defined process and system is required to verify the identity of these devices before transferring sensitive data from the OEM backend server to originally manufactured devices. [0005] Some devices have unique device details defined in a specific format, which help identify a device by the OEM backend server at the time of enrollment for device identity verification. These device details typically comprise device ID, MAC, and IMEI numbers. However, these device details can be easily obtained from the originally manufactured devices and can be used by hackers to impersonate unauthorized rogue devices as authorized devices.

[0006] The existing methodfor identification and registration of devices to an OEM backend server involves techniques based on pre- shared keys between the OEM backend and the devices. This method comprises the step of generating and installing unique secret keys for each manufactured device at the factory stage, followed bystoring these unique secret keys in the OEM backend server as well. Later, at the enrollment or commissioning stage of these devices, the OEM backend server verifies the identity of the devices by asking the devices to sign a challenge using the pre-shared unique secret keys and return the authentication token to the OEM backend server, where the OEM backend server retrieves the unique secret key from the key store and verifies the authentication token. If the authentication token is successfully verified by the OEM backend server, the corresponding device is marked as an authorized device, and the device registration process is completed. Following the device registration process, the sensitive information such as security keys, certificates, and device secrets are transferred to the device.

[0007] A major drawback associated with the above method is that the pre-shared secret keys can be lost, stolen or copied while they are shared, transferred and distributed with multiple parties from the generation stage to installing them in the devices, and storing the same in the OEM backend server. As a result, the pre-shared keys can easily be compromised, leading to compromising of the devices as well unauthorized devices getting connected to the vehicle networks as authorized devices. In addition to this, managing the pre-shared keys in the OEM backend is also a challenging task as the OEM backend has to generate, store, and distribute hundreds and thousands of security keys associated with all the devices being manufactured.

[0008] There is, therefore, a need to overcome the above drawback and providean efficient, secure and reliable system and method for identification, registration and commissioning of embedded security devices comprising but not limited to an electronic control unit (ECU) of vehicles to an OEM backend, during device commissioning and enrolment. There is also a need to eliminate the need for sharing pre-shared secret keys across multiple parties. Further, there is a need to efficiently and securely manage security keys, certificates, and device secrets associated with the devices, from the factory stage to the commissioning stage. There is also a need to make the key management simpler by eliminating the complexity involved with managing and distributing multiple keys. Further, there is also a need to reduce the complexity and cost involved in managing device- specific keys

OBJECTS OF THE PRESENT DISCLOSURE

[0009] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.

[0010] It is an object of the present disclosure to provide a simple, secure, and efficient system and method for the identification, registration, and commissioning of an electronic control unit (ECU) of vehicles to an OEM backend.

[0011] It is an object of the present disclosure to provide a simple, secure, and efficientsystem and method for identification, registration, and commissioning of embedded security devices such as IoT devices, infotainment devices, gaming devices, and the likes, that employ PKI based techniques, to an OEM backend.

[0012] It is an object of the present disclosure to efficiently, economically, and securely manage the exchange of security keys, certificates, and device secrets associated with multiple devices, from a factory stage to a commissioning stage.

[0013] It is an object of the present disclosure to efficiently and securely manage the exchange of security keys, certificates, and device secrets between the devices and OEM backend, with minimum involvement of intermediate or third parties.

[0014] It is an object of the present disclosure to restrict leakage or theft of security keys, certificates, and device secrets associated with devices.

[0015] It is an object of the present disclosure to provide a system and method for identification, registration, and commissioning of an automotive ECU to an OEM backend, which is capable of generating and securely storing security keys on-board the ECU.

SUMMARY

[0016] The present disclosure relates to an efficient, secure, and reliable system and method for identification, registration, and commissioning of embedded security devices comprising but not limited to an electronic control unit (ECU) of vehicles to an OEM backend, during device commissioning, and enrolment. [0017] An aspect of the present disclosure pertains to a system for secure identification and registration of devices to an OEM backend. The system comprises one or more devices, each having unique identifiers and a root certificate. Each device is configured with a hardware security module (HSM) to auto-generate security keys and store the security keys in the HSM key storage, and also generate a self-signed certificate. The system further comprises a first computing unit associated with the OEM backend, which is configured to receive and store a self- signed certificate generated by the devices, when the devices are firstly connected to the OEM backend via the Factory Testers at factory stage.

[0018] Another aspect of the present disclosure pertains to a method for secure identification, registration, and commissioning of devices to an OEM backend. The method comprises a step of auto-generating a set of unique security keys [Public Private key pair] on board the device using the hardware security module, followed by generating a self-signed certificate using the on-board generated private key, and followed by securely storing the security keys in the HSM, and storing the unique identifiers associated with the devices, the root certificate, and the self-signed certificate within the devices. Finally, the device specific self-signed certificate are readout of the devices (via a factory Tester) and securely transported to the OEM backend server at the factory stage.

[0019] The system and method further involve a second computing unit in communication with the first computing unit. The second computing unit is configured to receive the unique identifiers, and self-signed certificate from the devices, when the devices are communicatively coupled with the second computing unit during the enrollment and commissioning stage, and correspondingly transmit the received unique identifiers to the first computing unit for verification. Upon a positive verification of the unique identifiers by the OEM backend, the OEM backend sends the self- signed certificateto the second computing unit.

[0020] The second computing unit further generates and transmits a challenge token to the devices, upon verifying the self-signed certificate received from the devices by comparing it with the self-signed certificate received from the first computing unit. The system and method allow the devices to generate and transmit, to the second computing unit, an authentication token in response to the challenge token by signing the unique identifiers and the challenge token using a private key of the corresponding device among the set of unique security keys that was auto-generated and stored in the devices at factory stage.

[0021] The second computing unit further extracts a public key from the self- signed certificate received from the first computing unitand verifies the authentication token received from the device using the extracted public key. Further, upon successful verification of the authentication token, the OEM backend, and the second computing unit registers the corresponding devices as authorized devices.

[0022] In an aspect, upon registration, the second computing unit transmits a signed certificate to the corresponding devices, wherein the device certificate is signed using the private key of the second computing unit. The devices are configured to verify the received signed certificate against the root certificate, and correspondingly install the received signed certificate in the corresponding devices, upon a positive verification, thereby completing the enrolmentand commissioning of the devices.

[0023] The step of auto-generation of the Public Private key pair in the factory by the

HSM on-board the devices, and storing the private key securely in the HSM key storage, followed by generating device self-signed certificate and transferring the same to the OEM backend in a secure factory environment, and later using the device self-signed certificate (by OEM backend) to verify the device identity significantly improves the security of the system. The step involving auto-generation of public private keys on-board the devices eliminate the need to generate and transfer the device private keys from the backend servers to the ECU’s over insecure communication channel. The self-signed certificates generated on-board the devices preclude the need to have pre-shared keys installed in the devices to verify the device identity, as the self-signed certificates can now be used by the OEM backend to verify the device identity.Further, getting rid of the pre-shared keysnot only eliminates the risk associated with exposure of keys due to sharing and distribution of the pre-shared keys to third party OEM suppliers, it also takes away the complexity involved in managing tens and thousands of pre-shared keys in the OEM backend server. All these factors make the present invention highly secure, efficient, and reliable.

[0024] Various objects, features, aspects and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings are comprised to provide a further understanding of the present disclosure, and are incorporated in and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The diagrams are for illustration only, which thus is not a limitation of the present disclosure.

[0026] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[0027] FIG. 1 illustrates an exemplary network architecture of the proposed system, in accordance with an embodiment of the present disclosure.

[0028] FIG. 2 illustrates an exemplary architecture of the second computing unit of the proposed system, in accordance with an embodiment of the present disclosure [0029] FIG. 3 illustrates an exemplary flow diagram of steps involved in the proposed method, in accordance with an embodiment of the present disclosure.

[0030] FIG. 4 illustrates an exemplary block diagram illustrating the exchange of data between OEM backend, factory tester, and devices in the proposed system and method at the factory stage, in accordance with an embodiment of the present disclosure.

[0031] FIG. 5A illustrates the exchange of data between OEM backend, devices, and second computing unit in the proposed system and method during the device enrolment process, in accordance with an embodiment of the present disclosure.

[0032] FIG. 5B illustrates an exemplary deployment of the proposed system during the device enrolment process, in accordance with an embodiment of the present disclosure. [0033] FIG. 6 illustrates an exemplary diagram showing the PKI architecture hierarchy for a newly issued certificate up to the root, in accordance with an exemplary embodiment of the present disclosure.

DETAILED DESCRIPTION

[0034] The following is a detailed description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are in such detail as to clearly communicate the disclosure. However, the amount of detail offered is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims. [0035] In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details.

[0036] The present disclosure relates toan efficient, secure and reliable system and method for identification, registration, and commissioning of embedded security devices comprising but not limited to an electronic control unit (ECU) of vehicles to an OEM backend, during device commissioning, and enrolment.

[0037] According to an aspect, the present disclosure elaborates upon a system for secure identification, registration, and commissioning of devices to an OEM backend. The system comprises one or more devices, each having a unique identifier and a root certificate. Each device is configured to auto-generate unique public private key pair (PPK) and securely store the keys in the HSM, and generate a self-signed certificate. The system further comprisesa first computing unit associated with the OEM backend, and configured to receive and store a first set of data packets pertaining to self- signed certificate generated by the one or more devices upon first communicative couplingof the one or more devices with the first computing unit at factory stage.

[0038] The second computing unit is in communication with the first computing unit.

The second computing unit comprising one or more processors operatively coupled to a memory comprising instructions executable by one or more processors, and configured to receive, from the one or more devices, a second set of data packets comprising the one or more unique identifiers, and the self-signed certificate when communicatively coupled with the one or more devices, and correspondingly transmit the received one or more unique identifiers to the first computing unit. The second computing unit receives, from the first computing unit, a third set of data packets comprising the self-signed certificatebeing stored in the first computing unit, upon a positive verification of the transmitted one or more unique identifiers by the first computing unit. Further, the second computing unit verifies the self- signed certificate received from the one or more devices by comparing with the self-signed certificate received from the first computing unit, and correspondingly generates and transmits a challenge token to the corresponding devices upon a positive verification.

[0039] The second computing unit receives an authentication token generated by the corresponding devices in response to the challenge token, where the authentication token is generated by signing the one or more unique identifiers and the challenge token using private key of device. Further, the authentication token is verified by extracting public key from the self-signed certificate received from the first computing unit. Further, upon positive verification of the authentication token, the OEM backend, and the second computing unit register the corresponding devices as an authorized device.

[0040] In an embodiment, upon registration, the second computing unit transmits a signed certificate to the corresponding devices, wherein the device certificates are signed by the second computing unit using its own private key. The one or more devices are configured to verify the received signed certificate against the pre- stored root certificate, and correspondingly install the received signed certificate in the corresponding devices, upon a positive verification.

[0041] In an embodiment, the one or more devices are configured to generate the self- signed certificate in response to a certificate signing request being raised by Factory Tester upon first communicative coupling of the first computing unit with the one or more devices at factory stage.

[0042] In an embodiment, the self- signed certificate is transmitted to the first computing device through the factory tester.

[0043] In an embodiment, the auto -generated set of unique security keys comprises a public/private key pair, and wherein the private key among the set of unique security keys is stored in a hardware security module key storage configured with each of the one or more devices.

[0044] In an embodiment, the authentication token is generated by the one or more devices, by signing the one or more unique identifiers and the challenge token using the device private key.

[0045] In an embodiment, the one or more devices are one or more engine control unit (ECU) associated with vehicles, and the second computing unit are associated with a telematics control unit (TCU) of the vehicles. The one or more unique identifiers are selected from ECUID, MAC, and IMEI.

[0046] According to another aspect, the present disclosure elaborates upon a method for secure identification and registration of a device to an OEM backend. The method comprises the steps of auto-generating, by the device having one or more unique identifiers and a root certificate, a set of unique security keys upon first communicative coupling of the device to a first computing unit associated with the OEM backend at the factory stage, and securely storing the generated set of security keys in the device at factory stage. The method further comprises a step of generating, by the device, a self-signed certificate in response to a certificate signing request being raised by the Factory Testers; and transmitting the self- signed certificate to the first computing unit upon communicative coupling of the device with the first computing unit. The method further comprises a step of receiving, by a second computing unit in communication with the first computing unit, the one or more unique identifiers, and the self-signed certificate from the device upon communicative coupling of the device with the second computing unit.

[0047] The method further comprises a step of transmitting, to the first computing unit, the received one or more unique identifiers. Upon a positive verification of the transmitted one or more unique identifiers by the first computing unit, the first computing unit correspondingly transmits the self-signed certificate to the second computing unit.

[0048] The method further comprises a step of generating and transmitting, by the second computing unit, a challenge token to the device upon a positive verification of the self-signed certificate received from the device. The device is configured to generate and transmit an authentication token to the second computing unit upon signing the one or more unique identifiers and the challenge token using the private keys stored in the device. Further, the method comprises a step of verifying the received authentication token using the device public key, and wherein upon a positive verification of the authentication token, the OEM backendand the second computing unit register the device as an authorized device.

[0049] In an embodiment, upon successful verification of the device, the method comprises the step of transmitting, by the second computing unit, the Certificate chain comprising of Intermediate Certificate, TCU Certificate(the second computing unit Certificate) and signed device Certificate. Certificate chain as shown in Fig 6, Fig 5B, and correspondingly installing the Certificate chain in the device after verifying against the root certificate.

[0050] In an embodiment, the auto-generated set of unique security keys comprises a public/private key pair. Further, a private key among the set of unique security keys is stored in a hardware security module key storage configured with the one or more devices .The method further comprisesthe step of generating, by the one or more devices, the authentication token by signing the one or more unique identifiers and the challenge token using the private key of the device.

[0051] Referring to FIGs.l and 2, the proposed system 100 for secure identification, registration, and commissioning of embedded security devices 104-1 to 104-N (collectively referred to as devices 104, herein) comprises an OEM backend server 102 (also referred to as OEM backend 102, herein) at the original equipment manufacturer end of the devices 104, which acts as a system administrator and facilitates and controls the secure and safe transfer of data and certificates between the OEM backend 102 and the devices 104. System 100 comprises multiple devices 104, each having a unique identifier and a root certificate.The system 100 further comprises a first computing unit (also designated as 102, herein) associated with the OEM backend 102, which isin communication with the devices 104 through a network 108. Each device 104 is configured with a hardware security module (HSM) key storage to auto-generate and securely store a set of unique security keys. Devices 104 are configured to generate a self- signed certificate on a request from a factory tester at the factory stage. The first computing unit/OEM backend 102 is configured to receive and store theself- signed certificate including unique identifiers associated with the devices 104, generated by the devices when the devices 104 are firstly connected to the OEM backend 102 at factory stage.

[0052] The system 100 further comprises a second computing unit 106 in communication with the first computing unit 102 through the network 108. The second computing unit 106 is configured to facilitate secure and safe exchange of data and certificates between the devices 104 and the OEM backend 102 when the devices 104 are communicatively coupled with the second computing unit 106 during the enrollment and commissioning stage. The second computing unit 106 accordingly facilitates authentication of the devices 104, and further, facilitates registration and installation of signed device certificates in the authenticated devices 104.

[0053] In an exemplary embodiment, the devices 104 are electronic control unit

(ECU) (also designated as 104, herein) associated with vehicles. Further, the second computing unit 106 is a telematics control unit (TCU) associated with the vehicles that functions as RoT of the vehicles, and is in communication with the first computing unit 102 positioned at the original equipment manufacturer end of the ECU 104.The unique identifiers of the ECU 104 comprise ECUID, MAC, and IMEI, but not limited to the likes. These unique identifiers associated with the ECU 104 of the vehicles, along with the self-signed certificate generated by the ECU 104 are stored in the ECU 104 as well as the OEM backend 102 when the ECUs 104 are communicatively coupled with the OEM backend 102 for the first time at factory stage. The Hardware security module (HSM) operate as a key storage device, and it also operates as a Crypto engine which performs a variety of cryptographic operations in a trusted environment to generate unique security keys. The unique security keys generated by the HSM are stored in the HSM Key storage area, and is not transferred to the OEM backend 102. [0054] In another exemplary embodiment, device 104 is an embedded security device that employs PKI-based techniques for implementing device security. These devices 104 are selected from IoT devices, infotainment devices, gaming devices, but not to the likes, and the first computing unit 102 is positioned at the original equipment manufacturer end of these devices 104.

[0055] In an embodiment, the proposed system 100 is implemented using any or a combination of hardware components and software components such as a cloud, a server, a computing system, a computing device, a network device, and the like. Further, devices 104 interact with the OEM backend 102 and the second computing unit 106, through an application or software that resides in the devices 104, or first and second computingunit (102, and 106). In an implementation, the system 100 isaccessed by an application that is configured with any operating system, comprising but not limited to, Android™, iOS™, Windows, and the like. It will be understood that the system is implemented as any suitable computing system known in the art, such as a desktop, a laptop, a server, web server, and the like.

[0056] Further, network 108 is a wireless network, a wired network or a combination thereof that is implemented as one of the different types of networks, such as Intranet, Local Area Network (LAN), Wide Area Network (WAN), Internet, and the like. Further, the network is either a dedicated network or a shared network. The shared network represents an association of the different types of networks that uses a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Intemet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like.

[0057] The hardware security module (HSM) is a dedicated processor that provides hardware acceleration of cryptographic functions such as encryption and decryption, creating and verifying digital signatures, hashing, random number generation and other cryptographic functions. HSM provides a platform for the secure generation, storage and usage of the cryptographic keys.

[0058] As illustrated in FIG.2, an exemplary architecture of the second computing unit 106 or TCU 106 of the proposed system 100 is disclosed. Thesecond computing unit 106 comprises one or more processor(s) 202. The one or more processor(s) 202 are implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate data based on operational instructions. Among other capabilities, one or more processor(s) 202 are configured to fetch and execute computer-readable instructions stored in a memory of the computing unit. The memory 204 stores one or more computer-readable instructions or routines, which arefetched and executed to create or share the data units over a network service. Memory 204 comprises any non-transitory storage device comprising, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.

[0059] In an embodiment, the second computing unit 106 also comprises an interface(s) 206. The interface(s) 206 comprises a variety of interfaces, for example, interfaces for data input and output devices referred to as I/O devices, storage devices, and the like. The interface(s) 206 facilitates communication of the second computing unit 106 with various devices coupled to the second computing unit 106. The interface(s) 206 also provides a communication pathway for one or more components of the second computing unit. Examples of such components comprise, but are not limited to, processing engine(s) 208 and database 210. The Interface206 comprisesa platform for communication with the devices to read real-time data /write data or certificates in the second computing unit, and to communicate with the OEM backend. The interfaces 206 compriseGraphical interface that allows user to feed inputs, to type/write/ upload the data and certificates, and other software and hardware interfaces, for example, interfaces 206 for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer.

[0060] In an embodiment, the secondcomputing unit 106 comprises a communication unit operatively coupled to one or more processor(s) 202. The communication unit is configured to communicatively couple the second computing unit 106 to the devices 104 as well as the OEM backend 102. In an exemplary embodiment, the communication unit comprises any or a combination of Bluetooth module, NFS Module, WIFI module, transceiver, and wired media, but not limited to the likes.

[0061] In an embodiment, the processing engine(s) 208 are implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) 208. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) 208 are processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the processing engine(s) 208 comprises a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium stores instructions that, when executed by the processing resource, implement the processing engine(s) 208. In such examples, the second computing unit 106 comprises the machine -readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the computing unit and the processing resource. In other examples, the processing engine(s) 208 is implemented by electronic circuitry. Database 210 comprises data that is either stored or generated as a result of functionalities implemented by any of the components of the processing engine(s).

[0062] In an embodiment, the processing engine(s) 208 comprises a device identifier verification unit 212, a self-signed certificate verification unit 214, a security key verification unit 216, a registration unit 218, and other units (s) 220, but not limited to the likes. The other unit(s) 220 implements functionalities that supplement applications or functions performed by the second computing unit 106 or the processing engine(s) 208. The data (or database 210) serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the units.

[0063] Referring to FIG. 4, each of the devices 104 is configured to auto-generate a set of security keys, and also generate a self-signed certificated upon receiving a request from a factory tester in the factory. The OEM backend 102 is configured to receive and store a first set of data packets generated by each of the devices upon first communicative coupling of the devices 104 with the first computing unit 102 of the OEM backend at the factory stage. The first set of data packets comprises one or more unique identifiers associated with the devices, and the self- signed certificate generated by each of the devices 104. In an exemplary embodiment, device 104 transfers the self-signed certificate to the OEM backend through a factory tester 402 for authentication purposes.

[0064] In an embodiment, the device identifier verification unit 212 enables the second computing unit 106 to receive a second set of data packets comprising the one or more unique identifiers, and the self-signed certificate is stored in the devices when the second computing unit 106 is communicatively coupled with the devices 104 for the first time during the enrollment process. Upon receiving the second set of data packets, the device identifier verification unit 212 enables the second computing unit 106 to transmit the received one or more unique identifiers to the OEM backendl02 for verification. The OEM backend 102 then compares the one or more unique identifiers received from the second computing unit 106 with the one or more unique identifiers pre- stored in the OEM backend 102 at the factory stage. Further, upon positive verification of the one or more unique identifiers by the OEM backend 102, the OEM backend 102 then transmits a third set of data packets comprising the self- signed certificate, and the root certificate, to the second computing unit 106.

[0065] In an embodiment, upon receiving the third set of data packets, the self-signed certificate verification unit 214 enables the second computing unit 106 to verify the self- signed certificate received from the devices 104 by comparing with the self-signed certificate received from the first computing unit 102.

[0066] In an embodiment, upon verification of the self- signed certificate, the security keys verification unit 216 enables the second computing unit 106 to generate and transmit a challenge token to the corresponding devices 104. In an exemplary embodiment, the challenge token requires singing using the set of security keys securely stored with the devices. Devices 104 are configured to generate an authentication token in response to the received challenge token by signing with the unique identifiers and the challenge token using the private key of the corresponding device 104. The security keys verification unit 216 further enables the second computing unit 106 to verify the received authentication token by extracting a public key of the corresponding device, from the self-signed certificate received from the first computing unit.

[0067] In an exemplary embodiment, the auto-generated set of unique security keys comprises a public/private key pair, wherein a private key among the set of unique security keys is stored in a hardware security module (HSM) key storage configured with each of the devices 104. The authentication token generated by devices 104 in response to the challenge token generated by the security keys verification unit 216 is signed using the private key. In another exemplary embodiment, ECC or RSA-2048 Signing algorithms are used to sign the data - Ex, ECDSA, Sign (device Id | Client challenge, ECU_Private_Key)

[0068] In an embodiment, upon a positive verification of the authentication token by the security keys verification unit 216, the registration unit 218 enables the second computing unit 106 to register the corresponding devices 104 as an authorized device with the OEM backend 102 and the second computing unit 106.

[0069] In an embodiment, upon registration of device 104 with the OEM backend

102, the registration unit 218 enables the second computing unit 106 to transmit a signed certificate to the corresponding devices 104 using a private key of the second computing unit 106. Further, devices 104 are configured to verify the received signed certificate against the root certificate stored at the factory stage, and correspondingly install the received signed certificate, upon positive verification of the received signed certificate. [0070] Referring to FIG. 3, the proposed method 300 for secure identification and registration of devices 104 to an OEM backend 102 comprises a step 302 of auto-generating a set of unique security keys using a hardware security module, on-board the devices, followed by securely storing unique identifiers in the devices 104, and storing the root certificate in the corresponding device at factory stage, as illustrated in FIG. 4.

[0071] Further, at the factory stage, method 300 comprises step 304 of generating a self-signed certificate, by device 104, in response to a certificate signing request received from a factory tester. The generated self-signed certificate is stored in device 104 as well as the OEM backend 102 when the devices 104 are firstly connected to the OEM backend 102 atthe factory stage.

[0072] Referring to FIG. 3, and 5A-5B, during the device enrollment process, in an embodiment, the proposed method (300, 500) comprises a step 306, 502 of receiving, by a second computing unit 106 in communication with the OEM backend 102, the unique identifiers, and the self-signed certificate from the device upon communicative coupling of the device 104 with the second computing unit 106.

[0073] The method (300, 500) comprises step 308, 504 of transmitting, to the first computing unit 102, the unique identifiers received at step 306, 502. Further, upon positive verification of the transmitted unique identifiers by the first computing unit 102 at step 506, the OEM backend 102 correspondingly transmits the self-signed certificate to the second computing unit at step 508.

[0074] The method (300, 500) further comprises step 310, 512 of generating and transmitting, by the second computing unit 106, a challenge token to the device 104 upon positive verification of the self-signed certificate by the second computing unit 106 at step 510. At step 510, the second computing unit 106 verifies the self-signed certificate received from the device at step 502 by comparing with the self-signed certificate received from the OEM backend 102.

[0075] Further, device 104isconfigured to generate and transmit an authentication token to the second computing unit 106 at step 516 upon signing the unique identifiers and the challenge token using the private stored in the devicel04 at the factory stage, at step 514. [0076] The method (300, 500) comprises step 312, 518 of verifying, by the second computing unit 106, the authentication token received at step 516, by extracting public key from the self-signed certificate.Further, at steps 314 and 518, upon a positive verification of the authentication token, the OEM backend 102 and the second computing unit 106 register the device 104 as an authorized device. [0077] In an embodiment, the method (300, 500) further comprises a step 520 of transmitting, by the second computing unit 106, upon registration of the device 104 as the authorized device, a signed certificate to the device 104 based on the root certificate being received from the first computing unit 102. Further, the method (300, 500) comprises step 522 of verifying, by the device 104, the received signed certificate with the root certificate, and correspondingly installing the signed certificate in the device 104 upon positive verification. FIG. 6 illustrates an exemplary diagram showing the PKI architecture hierarchy for a newly issued certificate up to the root.

[0078] It is to be appreciated by a person skilled in the art that the auto-generation of the security keys (PPK keys) by the hardware security module key storage on-board the devices in the present invention, and further storing the generated PPK keys securely in HSM storage of the devices, , makes the security keys invulnerable to leakage and theft compared to the existing method involving pre-shared keys. In addition, the step involving auto generation of keys on-board the devices eliminate the need to generate and transfer the confidential private keys from the Backend servers to the ECU’s, secondly precludes the need for having pre-shared keys installed in the devices to prove the device identity, as the self- signed certificates generated on-board the devices can now be used to prove the device identity. Further, the exchange of private keys over secure communication channels and without the involvement of third parties, makes the present invention efficient, secure, and reliable.

[0079] Moreover, in interpreting the specification, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refer to at least one of something selected from the group consisting of A, B, C ....and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc. [0080] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are comprised to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

ADVANTAGES OF THE INVENTION [0081] The proposed invention providesa simple, secure, and efficient system and method for the identification, registration, and commissioning of an electronic control unit (ECU) of vehicles to an OEM backend.

[0082] The proposed invention provides a simple, secure, and efficient system and method for identification, registration, and commissioning of embedded security devices such as IoT devices, infotainment devices, gaming devices, and the likes, that employ PKI-based techniques, to an OEM backend.

[0083] The proposed invention efficiently, economically and securely managesthe exchange of security keys, certificates, and device secrets associated with multiple devices, from a factory stage to a commissioning stage. [0084] The proposed invention efficiently and securely manages the exchange of security keys, certificates, and device secrets between the devices and OEM backend, with minimum involvement of intermediate or third parties.

[0085] The proposed invention restricts leakage or theft of security keys, certificates, and device secrets associated with devices. [0086] The proposed invention provides a system and method for identification, registration, and commissioning of an automotive ECU to an OEM backend, which is capable of generating and securely storing security keys on-board the ECU.

Claims

We Claim:

1. A system for secure identification, registration and commissioning of devices to an OEM backend, the system comprising: one or more devices, each having one or more unique identifiers and a root certificate, wherein each of the one or more devices are configured to auto-generate and securely store a set of unique security keys (public private key), and generate a self-signed certificate; a first computing unit associated with the OEM backend, configured to receive and store a first set of data packets generated by the one or more devices upon first communicative coupling of the one or more devices with the first computing unit at factory stage, wherein the first set of data packets comprises the self-signed certificate comprising the one or more unique identifiers; and a second computing unit in communication with the first computing unit, the second computing unit comprising one or more processors operatively coupled to a memory comprising instructions executable by one or more processors, and configured to: receive, from the one or more devices, a second set of data packets comprising the one or more unique identifiers, and the self-signed certificate when communicatively coupled with the one or more devices, and correspondingly transmit the received one or more unique identifiers to the first computing unit; receive, from the first computing unit, a third set of data packets comprising the self-signed certificate upon a positive verification of the transmitted one or more unique identifiers by the first computing unit; verify the self- signed certificate received from the one or more devices by comparing with the self-signed certificate received from the first computing unit, and correspondingly generate and transmit a challenge token to the corresponding devices upon a positive verification; receive an authentication token generated by the corresponding devices in response to the challenge token, wherein the authentication token is generated by signing the one or more unique identifiers and the challenge token using a private key among the set of unique security keys of the corresponding device; and verify the received authentication token by extracting a public key of the corresponding device, from the self-signed certificate received from the first computing unit, wherein upon a positive verification of the received authentication token, the OEM backend and the second computing unit register the corresponding devices as an authorized device.

2. The system as claimed in claim 1, wherein upon registration, the second computing unit transmits a signed certificate to the corresponding devices, the signed certificate is signed using a private key of the second computing unit, and wherein the one or more devices are configured to verify the received signed certificate against the root certificate, and correspondingly install the received signed certificate in the corresponding devices, upon a positive verification.

3. The system as claimed in claim 1, wherein the one or more devices are configured to generate the self-signed certificate in response to a certificate signing request being raised upon first communicative coupling of the first computing unit with the one or more devices at factory stage.

4. The system as claimed in claim 3, wherein the self-signed certificate is transmitted to the first computing device through a factory tester, and the certificate signing request is raised by the factory tester.

5. The system as claimed in claim 1, wherein the auto-generated set of unique security keys comprises a public/private key pair, and wherein the private key among the set of unique security keys is stored in a hardware security module key storage configured with each of the one or more devices.

6. The system as claimed in claim 5, wherein the authentication token is generated by the one or more devices, by signing the one or more unique identifiers and the challenge token using the private key of the corresponding device.

7. The system as claimed in claim 1, wherein the one or more devices are one or more engine control unit (ECU) associated with vehicles, and the second computing unit is associated with a telematics control unit (TCU) of the vehicles, and wherein the one or more unique identifiers are selected from ECUID, MAC, and IMEI.

8. A method for secure identification, registration, and commissioning of a device to an OEM backend, the method comprising the steps of: auto-generating, by the device having one or more unique identifiers and a root certificate, a set of unique security keys (public private keys) upon first communicative coupling of the device to a first computing unit associated with the OEM backend at factory stage, and securely storing the generated set of security keys (public private keys) in the device at factory stage; generating and transmitting, by the device, a self-signed certificate in response to a certificate signing request being raised upon first communicative coupling of the device to the first computing unit; receiving, by a second computing unit in communication with the first computing unit, the one or more unique identifiers, and the self-signed certificate from the device upon communicative coupling of the device with the second computing unit; transmitting, to the first computing unit, the received one or more unique identifiers, wherein upon a positive verification of the transmitted one or more unique identifiers by the first computing unit, the first computing unit correspondingly transmits, to the second computing unit, the self-signed certificate; generating and transmitting, by the second computing unit, a challenge token to the device upon a positive verification of the self-signed certificate received from the device, wherein the device is configured to generate and transmit an authentication token to the second computing unit upon signing the one or more unique identifiers and the challenge token using a private key among the set of unique security keys stored in the device; and verifying the received authentication token by extracting a public key of the corresponding device, from the self-signed certificate received from the first computing unit, wherein upon a positive verification of the authentication token, the OEM backend and the second computing unit register the device as an authorized device.

9. The method as claimed in claim 8, wherein the method comprises the step of: transmitting, by the second computing unit, upon registration of the device as the authorized device, a signed certificate to the device, which is signed using a private key of the second computing unit, and verifying, by the device, the received signed certificate with the root certificate, and correspondingly installing, upon a positive verification, the signed certificate in the device.

10. The method as claimed in claim 8, wherein the auto-generated set of unique security keys comprises a public/private key pair, and wherein the private key among the set of unique security keys is stored in a hardware security module key storage configured with the one or more devices, and wherein the method comprises the step of the generating, by the one or more devices, the authentication token by signing the one or more unique identifiers and the challenge token using the private key.