JP2020532215A - Secure communication of IoT devices for vehicles - Google Patents

Abstract

A method for establishing secure communication between multiple IoT devices in one or more vehicles is to provide each of the multiple IoT devices with a unique identifier, a digital identity token, and an encryption key for the multiple IoT devices. To establish a secure communication line between multiple IoT devices by proposing each IoT device, authenticating each communication line between each IoT device, and issuing a digital certificate to each communication line. Includes grouping multiple IoT devices into different groups based on predetermined criteria and including group membership for one of the different groups in a group characteristic attribute certificate. [Selection diagram] Fig. 3

Description

Mutual Reference to Related Applications This international application is a partial continuation of US Patent Application No. 15 / 621,982 filed June 13, 2017 and filed July 25, 2017 in the United States. Claiming the interests of Patent Provisional Application No. 62 / 536,884, claiming priority and interests based on the US partial continuation application of US Patent Application No. 15 / 686,076 filed on August 24, 2017. To do.

The aforementioned U.S. Patent Application No. 15 / 621,982 is U.S. Patent Application No. 62 / 313,124 filed on March 25, 2016, and No. 62/326 filed on April 24, 2016. , 812, No. 62 / 330,839 filed May 2, 2016, No. 62 / 347,822 filed June 9, 2016, filed August 1, 2016. Claiming the interests of Nos. 62 / 369,722, Nos. 62 / 373,769 filed on August 11, 2016, and Nos. 62 / 401,150 filed on September 28, 2016. A continuation of US Patent Application No. 15 / 469,244 (issued as US Pat. No. 9,716,595) filed on March 24, 2017, and filed on September 19, 2016. A partial continuation of U.S. Patent Application No. 15 / 269,832 filed, and the aforementioned U.S. Patent Application No. 15 / 269,832 is U.S. Patent Application No. 15 / filed on January 20, 2016. It is a continuation application of US Pat. No. 002,225 (issued as US Pat. No. 9,455,978), and the aforementioned US Pat. No. 15,002,225 is US Pat. No. 14,218,897 (US Pat. It is a continuation application (issued as Nos. 9,270,663), and the aforementioned U.S. Patent Application Nos. 14 / 218,897 is a U.S. Patent Provisional Application No. 61/792 filed on March 15, 2013. It claims the interests of No. 927. U.S. Patent Application Nos. 15 / 002,225 are also U.S. Patent Application Nos. 61 / 650,866 filed May 23, 2012 and No. 61/490 filed May 27, 2011, This is a partial continuation of US Patent Application No. 13 / 481,553, filed May 25, 2012, claiming the interests of No. 952.

The aforementioned U.S. Patent Application No. 15 / 002,225 is also U.S. Patent Application No. 61 / 416,629 filed on November 23, 2010, and No. 61 / filed on July 26, 2010. Claiming the interests of Nos. 367,576, Nos. 61 / 367,574 filed on July 26, 2010, and Nos. 61 / 330,226 filed on April 30, 2010, April 2011 This is a partial continuation of US Patent Application No. 13 / 096,764 filed on 28th March.

The aforementioned U.S. Patent Application No. 15 / 469,244 is a continuation of U.S. Patent Application No. 15 / 154,861 (issued as U.S. Patent No. 9,578,035) filed on May 13, 2016. This is a partial continuation of US Patent Application No. 15 / 409,427 filed on January 18, 2017, and the aforementioned US Patent Application No. 15 / 154,861 is March 15, 2015. US Patent Provisional Application Nos. 62 / 133,371 filed on the same day, 61 / 994,885 filed on May 17, 2014, and 61/367 filed on July 26, 2010. , 576 is a continuation of US Patent Application No. 14 / 715,588 (issued as US Patent No. 9,356,916) filed on May 18, 2015, claiming the interests of No. 576. The aforementioned U.S. Patent Application No. 14 / 715,588 is also filed on March 18, 2014, claiming the interests of No. 61 / 792,927, filed March 15, 2013. This is a partial continuation application of US Pat. No. 218,897 (issued as US Pat. No. 9,270,663). The aforementioned U.S. Patent Application No. 15 / 154,861 filed on May 13, 2016 is the U.S. Patent Application No. 61 / 650,866 filed on May 23, 2012 and May 2011. This is a partial continuation of US Patent Application No. 13 / 481,553 filed May 25, 2012, claiming the interests of Nos. 61 / 490,952 filed on 27th.

The aforementioned U.S. Patent Application No. 15 / 154,861 filed on May 13, 2016 is U.S. Patent Application No. 61 / 416,629 filed on November 23, 2010, July 2010. A U.S. patent filed April 28, 2011, claiming the interests of Nos. 61 / 367,574 filed on 26th and 61 / 330,226 filed on April 30, 2010. This is a partial continuation application of Application No. 13 / 096,764.

The entire contents of all of the above applications are expressly incorporated herein by reference.

The present invention generally relates to IoT (Internet of Things) security and management, and more specifically to systems and methods for IoT security and management of vehicles.

Many companies, organizations, and governments responsible for the security, operation, support, and maintenance of IoT (Internet of Things) devices are facing increasing challenges. IoT devices are playing an increasingly important role in many areas of the modern economy, including equipment for manufacturing, public facilities, distribution, recreation, military, residential, commercial, health care, and more. In addition, IoT devices are incorporated into industrial products that may or may not be associated with the above equipment such as automobiles, aircraft, medical devices. With respect to the manufacture of such products, the protection, control and management of IoT devices (usually manufactured by third parties) can be difficult and carry with risks, risks or potential responsibilities.

Guaranteeing and licensed control of the data generated for both industrial products (along with their embedded IoT devices) and companies deploying IoT devices in operating equipment (eg factories, power grids, etc.) It has the ability to control access so that unspecified persons cannot access the device, instruct the device to listen only to authorized persons, and the device has the ability to ignore unauthorized persons. It is desirable to provide strong identity management to external authorized systems or entities, and / or typical IoT devices and devices that may be within such operating IoT devices.

It is also desirable that a typical device be configurable and easily updatable only with licensed and verified firmware. IoT devices also include confidential personal or corporate information that the entity may desire to control external access or otherwise protect, own, control, or have a direct interest in those devices. You may obtain or have access to the information.

In some embodiments, the present invention is a method for establishing secure communication between multiple IoT devices, each including a hardware processor and associated memory, in one or more vehicles. The method is to provision multiple IoT devices by providing each of the multiple IoT devices with a unique identifier, digital identity token, and encryption key, and to authenticate each communication line between each IoT device, respectively. It is different from establishing a secure communication line between multiple IoT devices by issuing a digital certificate to the communication line of IoT, and grouping multiple IoT devices into different groups based on a predetermined standard. Includes group membership for one of the groups in the attribute certificate showing the group characteristics.

In some embodiments, the present invention provides secure communication between multiple IoT devices in one or more vehicles, each including a hardware processor, associated memory, a unique identifier, a digital identity token, and an encryption key. It's a way to establish it. The method is to invite the second IoT device by the first IoT device to establish a communication line with the first IoT device by receiving the digital identity token from the second IoT device, and the first By authenticating the communication line between the IoT device and the second IoT device and issuing a digital certificate to the communication line, a secure communication line between the first IoT device and the second IoT device can be established. Includes establishing, grouping multiple IoT devices into different groups based on predetermined criteria, and including group membership for different groups in their respective attribute certificates for each device.

In some embodiments, each of the secure communication lines may include a digital contract that establishes conditions for the use of each secure communication line between the respective IoT devices. In some embodiments, an attribute certificate containing relevant rules for group membership may be issued to the group. In some embodiments, different groups may include subgroups, each different vehicle may have a different group, and each subgroup of each group may include components of said vehicle.

These and other features, aspects, and advantages of the present invention will be better understood from the following description, the accompanying claims, and the accompanying drawings.

It is a figure which shows the security system for performing the exemplary provisioning process of the IoT device which concerns on some embodiments of this invention. It is a figure which shows the security system for inviting an IoT device to mutually establish a secure communication line which concerns on some embodiments of the present invention. FIG. 5 illustrates a security system for establishing a secure communication line between a plurality of pairs of IoT devices in a vehicle according to some embodiments of the present invention. FIG. 5 illustrates an exemplary type of IoT device in a vehicle, according to some embodiments of the present invention. It is a figure which shows the security system for authenticating a new product including an IoT device which concerns on some embodiments of this invention. FIG. 5 illustrates a security system for product maintenance, including IoT devices and possible replacements thereof, according to some embodiments of the present invention. It is a figure which shows some element of the secure authenticated communication line which concerns on some embodiments of this invention. It is a figure which illustrates some element of the security ecosystem which concerns on some embodiments of the present invention. FIG. 5 illustrates exemplary use of two application programming interfaces (APIs) according to some embodiments of the present invention. It is a flow of an exemplary process for establishing secure communication between a plurality of IoT devices according to some embodiments of the present invention. FIG. 5 illustrates an exemplary method of using a digital signature in a bandwidth-constrained environment, according to some embodiments of the present invention. FIG. 5 illustrates an exemplary method of transmitting a digital signature while minimizing the bandwidth required for such transmission, according to some embodiments of the present invention.

In some embodiments, the present invention is a method for establishing secure communication between multiple IoT devices associated with one or more vehicles such as automobiles, boats, motorcycles, and aircraft.

In some embodiments, the security ecosystem of the present invention is a certificate authority, registration authority, hardware security module (HSM), verification authority (VA, potentially online certificate status protocol (OCSP)) or Of Certificate Revocation List (CRL), Authority Management Infrastructure (PMI), Virtual Network Protocol (VPN) Technology, Device-Side Client Applications, Cloud Hosting, Authentication, and Lite Active Directory Access Protocol (LADP) Configured with one or more of the Attribute Authority (AA) acting as a trusted third-party intermediary service provider by using one or more of the Public Key Infrastructure (PKI), including one or more. It provides many of the above capabilities through the use of central servers. In some embodiments, the security ecosystem of the present invention is also potentially combined with other solutions to a third party IoT device manufacturer, the IoT product of which may later be managed by the security ecosystem. Specifications can be provided. A typical industry practice today is to issue a certificate from the Central Certificate Authority (CA) only to each endpoint. However, the security ecosystem of the present invention not only issues certificates to endpoints, but also issues certificates to each authenticated communication line 705 that establishes (establishes) a pair of endpoints and can be used. ..

In some embodiments, this security ecosystem can result in real-time management of credentials, identity profiles, communication lines, and / or keys. Adjustable rights can be distributed to authorized users / devices. Using the Invite-Invite Protocol Suite, which is managed by users of the security ecosystem, managed by devices, managed by operators, or managed by artificial intelligence, inviters are supplied, for example, by the security ecosystem. It can guarantee the identity of the invited guest who can successfully complete the protocol that establishes a secure communication line with the identity support information to be provided. The user / device may establish and respond to authorization requests and other real-time validations related to access to typical communication lines (not endpoints) that may share encrypted communication.

Typically, the communication line may be accompanied by a digital contract that establishes conditions (eg, rules and / or business logic) for the use of the communication line between endpoints. These contracts are generally auditable, mediated, trusted relationships, and such relationships / digital contracts may be independent (generally for privacy). Or it can influence the building of identity trust levels across relationships. These relationships can be organized into defined "groups". In some embodiments, the cryptographically protected group may include all or one or more subset groups of devices embedded within a single industrial product, eg, in different embodiments, groups. May include endpoint IoT devices in automobiles, aircraft, medical devices, household appliances and the like.

According to some embodiments of the present invention, individually manufactured IoT devices and industrial products (incorporating IoT devices) include one or more of the following capabilities: They ensure that data is protected (eg, using encryption) and control of the generated data, which can potentially involve the movement of data, to prevent unauthorized access to the device. It has the ability to instruct the device to listen only to authorized persons so that it can control and prevent or mitigate man-in-the-middle attacks. These devices may also provide strong identity management not only for multiple IoT devices that may be in the product, but also for authorized systems or devices external to the product.

Many devices are authorized, signed firmware that is signed with a private key that corresponds to the subject public key, usually in a code signing certificate issued by a host computer or a certificate authority recognized by the device. It can only be configurable in code and easily updated. An example of an industrial product that can benefit from the solutions described herein is the automobile. There are several reports that cars have been hacked remotely. Once the system is accessed, hackers use the vehicle's Controller Area Network (CAN) bus to access multiple electronic control units (ECUs) such as engine, brake, speed, steering, and / or others. I was able to control it at least partially. The present invention may be applicable to various ECUs such as human machine interfaces, engine control units, transmission control units, steering control units, telematics control units, speed control units, battery management systems, seat and door control units.

In some embodiments, the present invention leverages the unique properties of a secure component or physical replication difficulty function (PUF) to ensure that the identity of the IoT device is established, the basis of traditional firewall security gaps. Provides one or more of resolution, remote identity authentication, authenticated public key exchange, prevention of random device access, data protection and control, and / or device update with signed firmware. To do.

In some embodiments, devices incorporating the present invention can control and use a protected cryptographic key. In some embodiments, by integrating an IoT device (incorporating cryptographic and security features according to the present invention) into the assembled product, a complex or integration that may otherwise require a specialized skill set. Multiple IoT devices may be used together in a product that is coordinated or assembled to provide a solution.

For the purposes of the system of the present invention, IoT devices are endpoints and generally consist of two broad types:

A "control IoT" or "CIOT" device is a type of client IoT device that can also be used to control or manage one or more similar IoT devices or IoT devices of more limited nature. For example, a CIOT device may include an ECU in an automobile.

A "limited IoT" or "LIoT" device usually does not include the processing or storage capacity or other capacity of a typical CIOT device (having larger memory, processing power, etc.). The LIOT device may include sensors, switches, actuators, controllers and the like.

Given the limited processing power and other power of LIOT devices, all or part of the complete inviter-invite provisioning protocol of the ecosystem type system is partially pre-completed during its manufacturing process. May be installed on the device with. Also pre-assigned to such LIOT devices is the unique protocol address or identifier assigned to the device and one or more trusted CIOT devices or other trusted devices in the security ecosystem. Can be the key. For example, public keys may be provided to specify a LIOT device when these public keys are associated with a device or endpoint that the LIOT device should trust. These are devices that can provide trusted services to LIOT devices, such as firmware signatories, administrator / user controlled devices, trusted management devices (eg CIOT), trusted group devices, etc. Let's go. Throughout the disclosure, the term "IoT device" or "IoT endpoint" can be used to refer to either a CIOT or LIOT device. The term "device" or "endpoint" is controlled by the user such as "IoT device", "IoT endpoint", user / endpoint, CIOT, LIOT device, "container", or mobile device, computing device, etc. Can point to a device that is

Generally, limited IoT (LIoT) device assignments can be reported, managed, or controlled to control IoT (CIOT) devices. Based on the aforementioned information collected and certified by the CIOT device, the AA may create a digital certificate for each LIOT device along with the collected and validated information. For example, such a digital certificate may include the unique identity of the device, the type of the device, and the capabilities. It may also optionally include the relationship between the LIOT device and the CIOT device, the address, where it will be installed, the relationship between the inviter-inviter provisioning process, group membership, manufacturer proof, and other information. Such certificates may be automatically and continuously renewed and maintained throughout the product life cycle.

The security ecosystem of the present invention enables multiple ways of provisioning a device to achieve the endpoint unique identifier of the device. In some embodiments, the IoT device manufacturer's specifications for the manufacturer of the IoT device or the product incorporating the IoT device (TV, refrigerator, security system, thermostat, etc.) to incorporate the technology into the device accordingly at the time of manufacture. Can be created. In some embodiments, the technology is fully custom digital logic, IP logic blocks built into the device's existing digital logic, programmable logic implemented using the firmware on the device, and device-specific. It can be in the form of a full custom firmware included with the custom firmware, or an open source or owned firmware stack that is added to the device firmware. For devices with updatable programmable logic resources and / or firmware, this technique can also be embodied in post-manufacturing devices. Some embodiments that conform to the specification prove the communication line between the endpoint device and another endpoint, and the conditions for the use of the communication line established between the endpoints (eg, rules and / or). It will be about the firmware of the IoT device to help the device comply with some rules contained in the digital contract normally recorded in the digital certificate that establishes the business logic). Such specifications may also require the IoT device to communicate only with already authenticated endpoints and not with others. An IoT device endpoint is usually established between it and one or more other endpoints, usually devices that need to communicate with it to meet operational or other needs. It may have a communication line.

The rules, procedures, and policies described herein are the manufacturers of IoT devices and potentially various supply chain suppliers to those manufacturers (eg, Chips, Field Programmable Gate Arrays (FPGAs)). Etc.) may be incorporated into the written specifications that will be provided to contribute to the fabrication of IoT devices that are integrated into the security ecosystem by designing, producing, manufacturing, assembling, or otherwise. Included in such specifications may be a way for the security ecosystem to manage secure firmware updates for all managed IoT devices.

Device firmware that meets the specifications of such IoT device endpoints will reject or ignore communication from any unknown endpoint that has not yet been authenticated through the establishment of a secure communication line, and the established communication line. Will only communicate with already authenticated endpoints that have and are supported by digital certificates. The device firmware may first meet the specifications, or may later meet the specifications by updating the firmware. IoT devices can be made to the specifications, or by installing the appropriate application that will cause such devices to operate as IoT devices that generally conform to the specifications and features described in the security ecosystem. As a better and more basic device, the owner of the device (eg, the owner, the manufacturer, etc. who wants to increase the security and control capabilities of the IoT device that can be owned or controlled) can be made.

By applying the same principles and procedures described for the manufacturer of the product (incorporating the IoT device) and leveraging the capabilities of the security ecosystem, the owner may obtain or control such IoT. Strengthen the security of the device, as well as the owner's control and control over such owned or controlled IoT devices, potentially the capabilities, features, and / or advantages described in this application, and others. Get things. In addition, all or part of the provisioning step may be performed by the manufacturer of the IoT device, and / or all or part of it may be performed by (or instead) the customer of the device.

In some embodiments, manufacturers of IoT devices may provide comprehensive installation support procedures as well as configuration options to use and optimize both their manufacturing process and operational performance. Within the security ecosystem environment, IoT devices are given a unique address, such as an Internet Protocol (IP) address or other identifier, when servicing the device as a step in its manufacturing process or upon request. Can be assigned. The address can be safely stored in rewritable memory on the IoT device or in a secure component in a permanent manner. The manufacturing specifications of devices in the security ecosystem may require that the address of the device be visible on the device itself, by alphabet / number and / or QR code.

The specification is that when the device is powered on, the device will send a "Hello" message along with its address, along with other identification information such as its model number, serial number, public key, current whitelist, and current firmware version. Allows the device to be optionally programmed to broadcast a confirmation message such as. An example of the use of this feature is during the period when components are installed in an automobile in a manufacturing facility. At any time during testing, assembly, installation, quality inspection, etc., the technician may power on and test the device, thereby giving the device a unique "hello" message that comprehensively identifies the device. take in. This feature can be useful for classifying and assigning unique device names associated with installation locations in the vehicle (these messages may later be disabled).

In some embodiments, an immutable manufacturer's certificate prior to delivery of the IoT device may be included in the manufacturer's specifications for the IoT device. Such non-disputable certificates are acceptable, such as PKI certificates or other digital tokens stored in secure components, or physical data records on locally or remotely readable devices. It can be one of the forms. When manufacturing an IoT device intended for incorporation into the security ecosystem of the present invention, the manufacturer may be required to certify one or more of the following: (a) exit or receive by the device: All communications made may be controlled by a designated application running on the IoT device (eg, the device firmware recognizes and supports the secure communication line technology of the security ecosystem), (b) exits the device or the device. All or specified communications received by the device are associated with an IP address on an updatable whitelist and / or an entity authenticated through the Invite-Invite Protocol and / or by an authorized endpoint. No additional conditions may be created that may only be sent to the address provided in the manner of (c) and may be deemed appropriate, and (d) a manufacturer's certificate.

In some embodiments, in some IoT device cases, the unique identifier or encryption key may be pre-installed during the device manufacturing process, or in some cases, introduced after the device is manufactured. .. In some embodiments, a trusted platform module (TPM) or physical duplication difficulty function (PUF) may be used to provide a unique identifier or encryption key on the device. According to PUF technology, security keys and unique identifiers can be extracted from the essential features of the semiconductor in the device. These unique keys are usually generated only when needed and usually do not remain stored on the system, thus providing a high level of protection. The unique key generated by PUF technology enables bootstrapping of cryptosystems (such as those required within the IoT / endpoint client of the security ecosystem) to establish a root key. In some embodiments, the cryptographic algorithm and / or key is protected or isolated from the application software / firmware in some security subsystems inside the device.

In some embodiments, the security ecosystem's IoT device client application may be installed on a field programmable gate array (FPGA) or on another type of integrated circuit (IC). For example, an FPGA, controller, or microprocessor can be a local keystore module (LKSM), a globally unique identifier (GUID) assigned to a device by the security ecosystem, a public key associated with the device, and an endpoint that the IoT device should trust. It can be provisioned with an IoT device client that may include one or more of (eg, a firmware signing authority, an IoT management device, an IoT support group, etc.). LKSMs are usually installed, for example, some of them in secure components: (a) key pairs for signature generation and verification, (b) key pairs for encryption and decryption, (c) data. A symmetric key to verify the integrity of, and (d) a digital asset (potentially first generated by a device client or cryptographic microprocessor, or potentially by a security ecosystem server or something else). Includes cryptographic management systems in devices that manage cryptographic wrapping / unwrapping of unique keys, such as which may provide symmetric, asymmetric, elliptical, and / or cryptographic functions.

FIG. 1 shows an exemplary provisioning process for IoT devices according to some embodiments of the present invention. Typically, the installer will supervise this process with a computing device 114, or may control the process with a computing device controlled by a program such as an IoT device or artificial intelligence program with internal intelligence. If the security ecosystem client application is not yet installed on the IoT device, it will be downloaded from the installer's computing device (114) or from the security ecosystem platform 108 (101). Security ecosystem platform 108 includes one or more of PKI, PMI, AA and the like. At 102, a unique GUID may be associated with a client instance during the installation of a client registered in the security ecosystem (eg, transmitted via the installer's computing device 114). At 103, an ID generated by the unique PUF, if not yet generated, can be created on the device. At 104, the encryption function on the processor in the device is sent to the security ecosystem 108 directly or through the installer's computing device 114, with one or more public / plurality of public keys. A private key pair may be created and may also be transmitted with device identification information such as its model number, serial number, type name, current whitelist, and current firmware version.

At 105, AA provides a certificate to a device that certifies the device's identity with one or more of the following: device client GUID, device ID, device public key, device public identity (eg, type name, etc.) Serial number etc.). At 106, the device is a digital identity token that asserts the identity of the device, including one or more of the device's specifications, identity, role or function, its public key, and potentially other information (below). DIT) as described further in the paragraph may be created and signed. This DIT presents to the installer's computing device or potentially to a security ecosystem (or, in other embodiments, to an IoT device with internal intelligence, or to a computing device controlled by an artificial intelligence computer program). It can review and confirm device assertions, then potentially certify that confirmation to device assertions, and then digitally sign the device's digitally signed assertions and then Send to the security ecosystem at 107. Optionally, the security ecosystem 108 may review these assertions and create an attribute certificate or DIT that affirms them. The security ecosystem is the public key certificate of other devices and / or groups that IoT devices should trust and digitally sign (eg, the Firmware Signing Authority, the auto mechanic group described in more detail later in this application). Can provide a public key certificate to the IoT device at 109 (potentially transmitted via the installer's computing device 114). ). In some embodiments, the CIOT device (as described herein) may be replaced with the installer's computing device in one or more of the above steps.

In some embodiments, the IoT device comprises a DIT. Typically, the DIT token may be created from within an existing IoT device client, thereby leveraging the digital signature capabilities of the IoT device client. The token typically contains the digital signature of the issuing device. In step 107, tokens can be created with various configurable identification fields. In the case of IoT devices, these may include the device manufacturer, serial number, device type, device model, GUID, issue date, and the like.

In some embodiments, secure boot and software certification features are provided to detect unauthorized changes in the bootloader and / or critical operating system files by checking digital signatures and product keys. Invalid files are blocked from execution before attacking or infecting the system or device, giving the IoT device a basis of trust in operation. In addition, trusted execution techniques use cryptographic (or other) techniques to create unique identifiers for the target component, making an accurate comparison of the elements of the boot (or operating) environment with known good sources. To prevent the start of mismatched code (or send a warning to the appropriate device or endpoint or security ecosystem). In some embodiments, the detection may be a digital fingerprint of a device firmware installation such as PUF. Such fingerprints (or cryptographic hashes or other derivatives thereof) may be incorporated into the DIT or digitally signed and used as a separate verification. One or more of these components may be integrated into one or more separate processors. (See, for example, steps 105 and 109 in FIG. 1).

In some embodiments, the provisioning process will also include adding the public key associated with a trusted user, device, entity, etc. to the LKSM or secure component or other acceptable storage. For example, one of the most important additional public keys that will be trusted is the security ecosystem, and the signer of the public key certificate for all future trusted public keys that will be used. Would be from.

Reliable verification can be achieved in several ways. In some embodiments of vehicle assembly, the security ecosystem is a new brake control unit that will only be accessed by that IoT device client (eg, by using the public key of the IoT device client of the brake control unit). Issue a trusted public key certificate in the form of a unique ID or digital certificate to the IoT device firmware client installed in. The IoT device client of the brake control unit may independently decrypt its unique ID. The IoT device then creates a digitally signed token consisting of its unique ID, which is potentially encrypted with its private key, and returns it to the security ecosystem.

The security ecosystem validates that the brake control unit's IoT device client has provided an acceptable digital token confirming that it has uniquely received the unique ID and / or public key certificate of the device to be trusted. To do. The security ecosystem then creates a message confirming correct key verification, digitally signs it with the private key associated with the public key that will be trusted, and sends this to the IoT device client of the brake control unit. return. The authenticity of the signed confirmation is verified with the public key that will be trusted and the confirmation is completed. Further trusted keys may then be added and other verified messages from the security ecosystem may be verified through this or similar digital signature feature. Examples of trusted entities to which the trusted public key can be added include code signing authorities, mechanic groups, designated devices, and so on.

In some embodiments, provisioned IoT devices may be added through the use of the inviter-invite guest protocol for IoT devices. Security eco with access to users, security ecosystems, master IoT device management entities (eg CIOT devices), IoT devices with internal intelligence, security ecosystems (eg to PKI / PMI and / or attribute stations) Several authorized entities, such as artificial intelligence (AI) systems that guide the actions of the system, may determine the unique relationships between the specified IoT devices. One or more of these will be one for a designated IoT device, including (or potentially limited to modifying existing rules and / or business logic) the establishment of rules and / or business logic. Alternatively, the security ecosystem may be used to direct the establishment of secure communication lines with multiple other designated IoT devices. Proper instructions will typically include proper identification of both the invitee device and the invitee device, along with a digitally signed authorization for such a request.

To facilitate authentication in the inviter-invite process, the AA of the security ecosystem will ask the inviter-invite guest, or both, questions and / or the questions that will be used during the inviter-invite guest protocol. Can provide answers to questions. Through the process guided or approved by such a security ecosystem, the device (potentially through the additional use of artificial intelligence capabilities or by an IoT device with internal intelligence) requires direct human intervention or action. It may be possible to execute such instructions with or without, and to establish a secure communication line between them with the support of a trusted third party AA. In some embodiments, the inviter-invite guest process is controlled or controlled by a human installer or by an automated process. Successful execution of the IoT device inviter-inviter protocol results in X.I. It provides the establishment of the desired communication line and attribute certificate along with the digital contract (as described herein) created and recorded by the AA of the 509 compliant security ecosystem.

FIG. 2 shows a security system for inviting IoT devices to mutually establish secure communication lines according to some embodiments of the present invention. This figure shows an example automotive use case for a security ecosystem user / endpoint (eg, system or device installer 214) who wants to invite a human-machine interface unit 212 to join the security ecosystem 204. The installer on this system ensures that the IoT device client, which is subsequently identified as belonging to the human-machine interface unit, is installed, controlled with respect to this unique human-machine interface unit, and not captured by fraudsters. I hope I can know. Security ecosystem platform 204 includes one or more of PKI, PMI, AA and the like. The installer 214 may also wish to know that the IoT device client for this human-machine interface unit is the only one on the security ecosystem network. Through this chain of digital record management processes with IoT devices, clients can be certified by the security ecosystem.

When a new user / device (human-machine interface unit 212 in this exemplary case) is invited (201) and proceeds to the IoT device client installation process, whether the IoT device client has a digital identity token. You may be asked. If so, the IoT device client loads the digital identity token as indicated by 202. The installer 214 may provide a certificate to the DIT and at 203 send it to the security ecosystem. The security ecosystem network represented by 204 can then analyze tokens for authenticity. Each token is unique and can only be installed for a single security ecosystem user. In some embodiments, further out-of-band confirmation of successful installation for the IoT device client is included. An example of out-of-band verification may be included in the verification process, in which case the security ecosystem 204 is a newly installed human-machine interface unit that it will only access, as indicated by 205. Issue a unique ID (which can be encrypted using the public key of the human-machine interface unit) to the IoT device client. Then, at 206, the IoT device client of the human-machine interface unit 212 decides to provide its unique ID (potentially digitally signed with its private key) to the confirming system installer. Become.

In some embodiments, at 207, the system installer issues a certificate to the security ecosystem 204 that he has personally confirmed the completion of the installation of the human machine interface unit 212, optionally, for example, himself. Include such a unique ID along with its own certificate to the security ecosystem through the use of its client applications. Such confirmation (especially by the use of a one-time unique ID issued by the security ecosystem) will confirm the completion of the secure installation link, and then the IoT, as indicated by 209. It can support a chain of management of future digital records sent between device clients and IoT device clients in other validated security ecosystems. In some embodiments, the inviter-invite guest process described produces an audit trail based in part on a digital signature. In addition, other actions and activities in Security Ecosystem 204 may generate audit trails based in part on digital signatures.

Successful completion of guest processing can be understood to imply acceptance of any digital contract submitted by the inviter. This may include the use of a signature-generating private key by the guest's host computer / client / device that corresponds to the subject public key in the certificate referenced by the newly generated attribute certificate owned by the guest. In some embodiments, X. The 509 Protocol Attribute Certificate (AC) is the basis for inviter / guest processing. As a result of inviter-inviter processing, the security ecosystem 204, under mutual agreement, pairs an identity managed at the enterprise level with a unique communication line to each authenticated and authorized user / endpoint. To.

Secure communication line and device group management may be applied to provide more than one layer of device and / or data security and / or privacy. Such characteristics can be achieved by applying one or more of the following: (a) rules / business logic that can be associated with secure communication lines, (b) rules / business that can be associated with groups. Logic and / or (c) Communication between specified groups and / or subgroups and / or external endpoints (whether the endpoint is an IoT device or another computing device) Allow. These capabilities may provide security tiering, either individually or collectively.

In some embodiments, the group can be controlled both directly (by an authorized endpoint) and through the use of the API (by an authorized user). Such controls include creating groups and subgroups, adding and removing devices or other endpoints as members, naming groups, creating and modifying rules for group members to follow, and It may contain other actions or data. There may be a gradient of authority on the part of the authorized endpoint or API user to create or modify such group parameters. Artificial intelligence (AI) software can be an authorized user.

FIG. 3 illustrates a security system for establishing a secure communication line between a plurality of pairs of IoT devices in a vehicle according to some embodiments of the present invention. Through the use of one or more device provisioning methods and the inviter-inviter process, IoT devices within the user / device and / or manufactured or assembled product establish a unique presence on the device and authenticate their identities. It is possible to link and establish authenticated, verified and secure communication lines between each other. This is done by the end user device 302, the end user device operated by multiple humans, or one or more devices supervised via the human machine interface control unit 305 by the installer 301 operating the end user device. Can be

These are the relationships between devices 303 (eg, human-machine interface control unit 305 and telematics control unit 306), where the addition of other similarly paired devices can optionally be organized into defined groups. May be used to form. For example, cryptographically protected groups may be incorporated into a single industrial product such as a vehicle 304, aircraft, medical device, etc. to establish secure, protected, auditable communication with said group 307. Can include all devices with communication lines of. One or more subgroups of devices may be formed within group 308, or potentially in combination with devices and devices in or out of group. In addition, records of group members, their information, communication lines between members, group membership, and / or other relevant information may be established, recorded, and / or revoked in the security ecosystem. Device group membership and the rules associated with that group membership may be included on the certificate attached (directly or indirectly by AA) to one or more communication lines of the devices in the group. ..

One possible application of this technology to improve security is the Controller Area Network (CAN) bus in a vehicle. Device group management provides more than one layer of security by allowing only communication between specified groups and / or subgroups, and thus provides a layer of security. Also, the use of rules associated with communication lines and / or groups may further direct the handling of information regarding data privacy, for example by including data encryption requirements, or any device / endpoint. It can indicate whether the specified data can be received or not. This technique can address communication granularity and data security requirements in such use cases.

Further application examples of such techniques include applications where data from industrial products incorporating IoT devices (eg, vehicles, aircraft, medical devices, etc.) can be transmitted to external endpoints. For example, in the automotive field, various such applications are: (A) vehicle-to-vehicle (V2V) automotive technology designed to enable vehicles to communicate with each other, (b) between vehicles and road infrastructure. Selling electricity to demand response services by returning electricity to the vehicle-infrastructure (V2I), (c) grid, or by curbing their charge rate, including wireless exchange of critical safety and operational data. Vehicle-grid (V2G), (d) All vehicles and infrastructure systems are interconnected to each other, thus a system in which a particular electric vehicle or hybrid vehicle communicates with the power network, and thus traffic conditions throughout the road network. Refers to an intelligent transportation system that provides more accurate knowledge, between vehicle and X (V2X), (e) Vehicle self-diagnosis and reporting capabilities to vehicle owners or repair engineers to various vehicle subsystem states On-board diagnostics (OBD) used in automobiles, and (f) access to this type of industrial product (which may include government access) or from such type of industrial product, which may provide access to. It is expected to become popular, such as other external sources that can request information.

For example, V2V communication is expected to form a wireless ad hoc network on the road. V2V communication works by using the inputs of IoT devices such as sensors that monitor the driving and conditions of the vehicle, such as speed, braking action, mileage, and location. The collected data may be protected by encryption and may be automatically uploaded to the server using a wireless network after the event occurs.

Group of systems, secure communication lines, and rules / business logic are useful for controlling unique external access to devices and / or data. For example, the external sensors required for V2V activity can be grouped into an "external sensor group". With respect to privacy concerns, external sensor groups may have controlled or limited identifying information (eg, only general manufacturers and models of vehicles). Personal information about the driver or vehicle registration may remain private from the device in the external sensor group (eg) through the use of rules associated with the membership of that group. Other vehicle devices (or potentially stationary or other types of computing devices) that are allowed to communicate with V2V sensors are typically devices or information in vehicles other than these sensors in external sensor groups. It does not have credentials to access and can therefore be restricted by rules / business logic. Such sensors may typically have carefully defined, limited, authenticated access to unique devices and information in the vehicle.

In some embodiments, the external sensor group may have a variable configuration for its own identity that may be transmitted externally. The configuration of the system provides endpoints capable of maintaining multiple identities that can change dynamically based on certain operating modes and / or operating times of the vehicle or its sensors (IoT devices). That is, a vehicle or vehicle device group can have multiple identities. One identity can, at a minimum, be the identity used by the general manufacturer and model of the vehicle, eg, an "external sensor group". The vehicle may also have one or more more detailed identities such as license plates, registration information, insurance information and the like. Such variable identifier configurations can be modified automatically or manually. In some embodiments, the choice of vehicle identifier may be provisioned to a defined class of vehicle, eg, an emergency vehicle. In some embodiments, a fire engine that is not operating in an emergency may broadcast the identity of a large vehicle or a non-emergency fire engine. However, if the fire engine changes its operation to an emergency call response mode, the fire engine's identity can be broadcast as an emergency vehicle responding to the request.

Vehicles that receive such different signals will usually respond differently. For example, if a fire engine is broadcasting the identity of a "non-emergency fire engine", there is no or near change in behavior, but the same fire engine changes that identity to the identity of an "emergency vehicle that responds to requests". If so, the driver of another vehicle will usually move to the side of the road (in the case of an autonomous vehicle, moving to the side of the road can be automatic). The message broadcast by the fire engine is also slowing down to the side of the road, stuffing forward to the next intersection and leaving the road completely, stuffing forward so that this fire engine can turn left, or desired. It can contain instructions such as any message to get.

FIG. 3A shows an exemplary type of IoT device in a vehicle according to some embodiments of the present invention. As illustrated, reference numeral 31 represents (eg) an IoT device in the "internal IoT device group". In some embodiments, these IoT devices are typically not externally connected. Examples may include electronic control units (ECUs) and other devices used in vehicle operations. Reference number 32 represents an IoT device in an "external sensor device group" that may include, for example, a sensor that monitors an external region of the vehicle and a device that communicates with and shares information with other devices outside the vehicle. .. In some embodiments, some or all of the devices of reference numbers 31 and 32 may be combined into a "vehicle device group" that includes all the devices in the same vehicle.

Due to the fact that the system supports digital certificates, digital identity tokens, trusted public keys, group keys, etc., fire truck broadcast messages are such as receiving nodes, such as vehicle nodes or traffic signal lights. Non-vehicle nodes, such as infrastructure components, can be digitally signed to believe that the message being broadcast is legitimate and credible. In some embodiments, the system's public key infrastructure (PKI), digital certificates, authenticated communication lines, digital signatures, etc. support features such as message authentication, secure grouping, privacy, and security.

There are various emergency vehicle and other government vehicle group types other than fire engines, as well as infrastructure group types that allow such functions to be used, such as ambulances, police vehicles, tow trucks, dangerous goods. (HAZMAT) Includes vehicles, military vehicles, traffic signal lights, street lights, fire protection equipment, etc. Sender IDs, messages sent, particle size of digital authentication, etc. can vary for different use cases. In some embodiments, the message or information shared and broadcast by the vehicle, infrastructure, or other supported device may vary depending on the request type and / or the requester's specific requirements.

A layered system of information or a layered set of identities that can be provided by a vehicle (or other endpoint device or industrial product) upon receipt of a request from a member of one or more approved agencies. It can be released automatically or manually. For example, a police vehicle may request a vehicle license plate or registered identity or information based on the authority associated with the police officer. Requests for additional sensitive information (eg, insurance information) may require higher authority than a normal police officer may have. Requests for such confidential information must come from a higher authority, or when a police officer files a report or request for such information that will be released by the vehicle, the police officer is authorized. May be provided.

Controlled information requests and responses may be made automatically or manually and may be accompanied by appropriate digital certificates, digital signatures, or methods supported by other systems. A defined level of restricted access may be provided to any external device. However, as mentioned above, a higher level of granular access may be provided to external groups defined by particle size based on authenticated relationships or group membership. Examples of such access include (a) a vehicle mechanic group, (b) a group approved by the government to access an on-board diagnostic (OBD) port due to the need for appropriate government monitoring. Can include

FIG. 4 shows a security system for authenticating new products, including IoT devices, according to some embodiments of the present invention. Industrial products incorporating IoT devices are typically sold to purchasers, renters, or other end users, or otherwise provided. In some embodiments, such a product is a car, in which case the purchaser 411 buys the car 412. In such cases, the purchaser's purchase is made more secure through the incorporation of a digital certificate 401 that includes the vehicle, relevant and authenticated information about the vehicle, the IoT device associated with the vehicle, and other information. Such a digital certificate 401 may be delivered from the security ecosystem 402 to the purchaser's mobile device 403, tablet device 404, computer 405, or other device. Security ecosystem platform 402 includes one or more of PKI, PMI, and AA. Buyer 411 may execute his purchase contract, for example, by digitally signing with a mobile device 406 supported by a security ecosystem that is certified through the security ecosystem. These digital records 407 may then be transferred to the lessor or other interested party, and the lease or loan agreement may also be digitally signed (408).

Purchase records combined with digital records of cars (potentially lease or loan documents (409)) are then recorded in an immutable manner (by the lessor, security ecosystem, or otherwise) (410). .. An example of such a record can be on Blockchain ™ or similar media 418, as indicated by 410. The relationship between the buyer 411 and the car is also with the buyer's client application on the buyer device 413, and the car (through one of its IoT devices 414) and the car's passive key entry system (key fob device) ) Can be authenticated with both 415. The purchaser's mobile device, vehicle, and passive key entry system are all then members of an authenticated group, such as the "IoT Device Group" 416.

FIG. 5 shows a security system for servicing products including IoT devices according to some embodiments of the present invention. When transporting a product, eg, vehicle 501, to vehicle distributor 502 for servicing, access to the vehicle's internal IoT device can be protected by security features already installed in vehicle 501. For example, the mechanic 503 attempting to access 510 has the appropriate credentials 504 to access the human interface control unit 505 of the vehicle through an application on the terminal device 506 already registered within the security ecosystem 507. Would have to be. A mechanic, application, or other acceptable identity will need to manifest proper certification for this purpose. For example, one of them is a certified member of a group of distributor mechanics who has the right to access IoT devices in the car with definable rights to perform certain types of maintenance work on the car. possible. For example, the mechanic may determine that the engine control unit is defective, remove it (508), and then install a replacement (509). The mechanic will typically remove the defective engine control unit from the car record in the security ecosystem 507 and replace it with a new engine control unit record. The exchange process reflects the appropriate inviter-guest process (and potentially the provisioning process described above) between IoT devices 511 and its updated IoT device group within the IoT device exchange and security ecosystem 507. Will include record update 510 for car 501 for IoT. Security ecosystem platform 507 includes one or more of PKI, PMI, and AA.

FIG. 6 shows some elements of a secure and authenticated communication line according to some embodiments of the present invention. As shown, the IoT endpoint 601 should typically have a secure root key provisioned as a way to establish a unique identifier or encryption key on the device. One way to do this is by using PUF602. Cryptographic algorithms, secure key storage, and client applications are provided on the device. A unique DIT may be created by device 601 or provided by the security ecosystem 604. The security ecosystem 604 includes one or more of PKI, PMI, and AA. Through the application of the inviter-guest process between the two endpoints 601/601, with facilitative support from the AA within the security ecosystem 604, these endpoints have a secure authenticated communication line 605 between them. Can be established. Typically, the communication line is a digital contract that can be recorded in a digital certificate that certifies the communication line and establishes the conditions (eg, rules and / or business logic) for the use of the communication line established between the endpoints. 606 is attached.

FIG. 7 illustrates some elements of the security ecosystem 701 according to some embodiments of the present invention. One of the unique elements of the security ecosystem 701, which primarily enables security, is based on the communication line 702 between the endpoints 703 as well as the endpoint itself. However, the security ecosystem 701 of the present invention not only issues a certificate 704 to the endpoint 703, but also a certificate to each authenticated communication line 705 where a pair of endpoints can be established (established) and used. Is issued. By building relationships only with the individual communication lines that have the certificate, it can be considered that the communication lines of the endpoint thus effectively established will be whitelisted. Whitelisting a device's communication lines is usually considered to enhance security. Rather than being centrally managed, communication lines are typically established at the endpoint level between pairs of endpoints. This allows authenticated endpoints to establish secure communication lines with other authenticated devices that they need to communicate with in order to meet their operational needs. Communication 707 from an unknown endpoint 706, which has an already authenticated, issued certificate 708 and no secure communication line, is prevented or ignored 709 (unknown for establishing secure communication). Invitations from endpoints are not ignored, but such invitations are managed by the AA, which supports authentication of both devices). This is a result of anti-spoofing measures, with properly provisioned endpoints with secure communication lines communicating only with already authenticated endpoints and not with others.

FIG. 8 illustrates exemplary use of two application programming interfaces (APIs) according to some embodiments of the present invention. Broadly speaking, an API is a well-defined set of communication methods between various software components. The security ecosystem may support two separate APIs. In some embodiments, the API 802 may be used by a client application on the IoT endpoint 803 to access, control, use, etc. the functions of the security ecosystem 801. In some embodiments, the IoT endpoint and the security ecosystem may communicate using other methods without APIs. The second API 804 can be used by external users, such as users from the IT department, for multiple uses. One such use is the status of all or some of the devices (including IoT and non-IoT devices), secure communication lines, certificates that are created, maintained, and / or supported by the security ecosystem. , Groups, relationships, etc. Such APIs can provide comprehensive, fine-grained visibility into such information. Such information may optionally be used by external systems or users for a variety of analytical purposes. Optionally, the API may provide the ability to guide all or part of the activities that the security ecosystem can perform. In some embodiments, external systems operating under the guidance of an artificial intelligence computer program can use this API.

In some embodiments, the present invention may uniquely provide software / firmware updates for a device. For example, an image of the firmware (or certificate associated with the firmware) is, for example, established firmware recognized by a trusted public key held by the LKSM of the secure component of the target device to be updated. Digitally signed by the signing authority. Using industry standard code signing technology, firmware can be digitally signed using the code signing authority's private key. The signed code is sent to the target device. Upon receipt, the target device first uses the trusted public key it possesses to verify that the code signing authority actually signed the code. After such verification, the target device may complete the firmware update.

In some embodiments, a device digital record of a unique image of the device's firmware installation may be provided, which can then be digitally signed by the device or institution. If desired, a new image can be created at a later point and compared to a previously created image to determine if the two images match. If they do not match, other issues associated with the attack or device may be investigated or other actions may be taken.

In some embodiments, an audit trail is generated from actions such as inviter / guest processing, provisioning, and group establishment, along with other actions taken within the security ecosystem, based in part on digital signatures. Some embodiments provide an audit trail for a combination of invitee and guest processing.

FIG. 9 is an exemplary process flow for establishing secure communication between a plurality of IoT devices according to some embodiments of the present invention. As shown in the optional block 902, the first and second IoT devices provide and authenticate the unique identifier, digital identity token, and encryption key to the first and second IoT devices, respectively. Can be provisioned by. As mentioned above, provisioning establishes communication between products, including several IoT devices, when installing IoT devices within the product, when programming the product or IoT devices, or between such IoT devices. It can be done at any time before. In either case, the IoT device will have a unique identifier and encryption key, which will be authenticated before establishing a secure communication line.

At block 904, a first digital certificate is issued to the device by a trusted third party, such as the Attribute Authority (AA). At block 906, the first IoT device sets up a second IoT device to establish a (unsecured) communication line with the first IoT device by receiving a digital token from the second IoT device. invite. At block 908, the second IoT device is authenticated to the first IoT device using the unique identifier, digital identity token, and encryption key of the second IoT device, as described in detail throughout the disclosure. To. At block 910, the first by authenticating the insecure communication line with the second digital certificate provided for the communication line between the first IoT device and the second IoT device. A secure communication line is established between the IoT device and the second IoT device. In this way, the security ecosystem of the present invention not only issues a (first) certificate to the IoT device (endpoint), but also each certified used by a pair of IoT devices (endpoints). Issue a (second) certificate to the communication line as well.

At block 912, another (third) IoT device for which a secure communication line to the first or second IoT device has not been established is prevented from communicating with the first or second IoT device.

Using the methods and systems of the present invention, various licensed persons establish and / or monitor and / or modify various groups and / or rules / business logics that may be present in the industrial product. It becomes possible to do. These may include manufacturers, industrial product owners, courts of jurisdiction, etc.

In some embodiments, a group is a function such as an external sensor group, a group or subgroup of devices on a CAN bus, all devices in a vehicle, endpoints, and an external entity responsible for servicing a designated vehicle. And / or define the role. An active group may contain only one active member. Group managers are considered members of the group. The attribute certificate for the group indicates the group characteristics (eg, external sensor group, vehicle, department, and / or role) and refers to a public key certificate that includes a signature verification public key. The corresponding signature generation private key is held by the group administrator. For example, in the case of a vehicle, this can be a master IoT device management entity (eg, a CIOT device) that can be controlled by human or artificial intelligence functions. For example, in the case of a vehicle mechanic group, this can be a designated endpoint computing device that can be controlled by humans or artificial intelligence functions. This key is used to assign a group public key used for encryption or key establishment. This mechanism allows the group administrator to (re) assign a value to the group public key unless the attribute certificate (or its replacement) is currently valid and the signature verification public key has been revoked. ..

In some embodiments, there are at least two ways for the group administrator to securely provide the group private key to other current members of the group: (a) Promising group members (creating a certificate or generating a certificate). An encrypted public key or key establishment public key (which is otherwise authenticated) can be used, (b) a prospective group member who corresponds to a signature verification public key that produces a certificate or is otherwise authenticated. Digital signature generation A temporary key establishment public key that is digitally signed with a private key can be used. If access for a group member (not a group administrator) should be removed, the group administrator assigns a new value to the group public key and assigns the corresponding group private key to the remaining group members (and this). Can be distributed (to new group members) when added in this way / when added in this way.

Attribute certificates typically allow for a secure and persistent private point-to-point communication line, a successful action performed by the invitee intended by the invitee (secure as described in this application). Generated by the Security Ecosystem Attribute Authority (AA) as a result of all device / endpoint authentication methods for establishing communication lines, as well as when creating groups. The attribute certificate issued by each AA refers to one or more digital certificates containing the target public key. Such public key certificates can be issued by a certificate authority in the security ecosystem or by a mutually certified external certificate authority.

In some embodiments, the attribute certificate explicitly refers to a public key certificate (or other encapsulation of the public key (eg, "certificateless" identity-based cryptography (IBE)), in this case. , Issued by a unique (eg, inviter) within the attribute certificate creation request message / invited guest processing message (including all device / endpoint authentication methods for establishing a secure communication line as described in this application). The cryptographic association with the PKC / public key (in the guest's answer to the secret question) provides protection against false attributes attempted by, for example, a server insider attack where the AA is not threatened. The AA is a self-proclaimed guest. You can determine if the answer provided by is correct based on the data provided by the invitee, and such data will take advantage of randomness to prevent exposure to the outside of the AA. In addition, guest communications and processing are designed to be phishing resistant to information leaks to impostors.

X. in the Internet Protocol. 509 Defines a profile for the use of attribute certificates RFC 5755 http: // datatracker. IETF. According to org / doc / rfc5755 /, "When making an access control decision based on AC, the access control decision function may need to confirm that the AC owner is the entity that requested access. Alternatively, one way the link between the identity and the AC can be achieved is to include a reference to the PKC in the AC and use the PKC-corresponding private key for authentication in the access request. ". It should be noted that such proof of possession of the private key can be used preemptively within the guest protocol as a condition to include a reference to the corresponding PKC in the resulting AC. RFC5755 describes the authentication of access requests, as would be expected, for example, by utilizing the corresponding public key to securely convey a digital asset key that remains inaccessible without knowledge of the private key. Note, the evidence of the use of the private key can be implicit. The use of secret questions asked by the invitee can be considered voluntary, but when they are called, the methodology briefly described above is for the communication line between the invitee and the intended invitee. Prevent attempts to take over construction.

In some embodiments, the mapping between the attribute certificate and the public key certificate is flexible. For example, an attribute certificate may be issued to a device / endpoint / owner / owner at the individual device / endpoint level or group level or department level (ie, at the device / endpoint level / endpoint level). As mentioned in accordance with RFC5755, the access control decision function may need to verify that the AC owner is the entity that requested access. One way the link between the request or identity and the AC can be achieved is by including a reference to the PKC in the AC and using the PKC-corresponding private key for authentication in the access request. is there. It should be noted that such proof of possession of the private key can be used preemptively within the guest protocol as a condition to include a reference to the corresponding PKC in the resulting AC. RFC5755 describes the authentication of access requests, as would be expected, for example, by using the corresponding public key to securely convey a digital asset key that remains inaccessible without knowledge of the private key. Note, the evidence of the use of the private key can be implicit. The use of secret questions asked by the invitee can be considered voluntary, but when they are called, the methodology briefly described above is for the communication line between the invitee and the intended invitee. Prevent attempts to take over construction. This may also correspond to, for example, a master IoT device management entity or a private key owned and held by the entity's IT department server, so multiple attribute certificates may commonly refer to the public key certificate. .. Digital signature generation For private keys (as opposed to decryption and / or key establishment private keys), digital (plain text) digital assets, messages, or other digital assets at the device / endpoint / endpoint level. Exceptions to signatures can be created (while digital signatures of communications / requests to the security ecosystem are done on the master IoT device management entity or the entity's IT department server).

For outbound digital assets / digital assets, digital asset key generation, digital asset encryption, and targeted encryption of digital asset keys can be performed on the entity's IT department server. For inbound digital assets, decryption and / or restoration of the digital asset key using the key establishment private key, and ciphertext digital asset decryption can be performed, for example, on the entity's IT department server. Hybrid techniques may be used such that live digital asset encryption or decryption is performed on the endpoint / endpoint / device for a particular sensitive operation and / or a particular key device / endpoint / employee. In such cases, in addition to the outbound digital assets that are prepared at the end node and sent to the intended recipient, they are generated at the end node / endpoint accessible to the entity under certain conditions. A copy of each outbound digital asset may be retained or archived. The generation of this copy may necessarily involve the use of an encrypted or key-establishing public key in which the corresponding private key is escrowed on behalf of the entity. Similarly, for inbound digital assets, end node decryption or key establishment private keys may be available from escrow under certain circumstances.

In some embodiments, a relevant attribute certificate may be issued to reference the relevant public key certificate. For example, two related attribute certificates may be issued, one referring to a public key certificate containing the target public key for use in encryption or key establishment, and the other digital. Refer to the public key certificate including the target public key to be used for signature verification. Some conventional methods indicate that only a single PKC can be referenced by the AC in the base certificate ID option of the AC holder field (as "issuer and serial number of the holder's public key certificate"). However, the AC serial number field does not have any unique requirements for assignment other than uniqueness, i.e. there is no requirement that the serial numbers used by the AC issuer follow a particular order. In particular, they do not have to increase monotonically over time. Each AC issuer must ensure that each AC it issues contains a unique serial number. As a result, one way to deal with the limitation of associating at most a single PKC with each AC is to refer to the relevant PKC with the officially associated serial number within the AC (eg, except for additional sub-serial numbers). Same) can be used. This method can be used for indirect but explicit proof of possession of a private key by taking over the explicit proof of possession of the private key prior to generation by the AA of the relevant AC that references the PKC.

For example, the presentation of a properly digitally signed message (demonstrating possession of a signature-generating private key) may be used to justify an encrypted communication / digital asset / file that will be received later. If the cryptographic public key or key establishment public key in PKC referenced by the AC associated with the AC that references the signature verification public key that corresponds to the signature generation private key that was used to generate the digitally signed message. The digital asset key is encrypted based on the use of. For example, this "U-shaped" association between PKC1 and PKC2 (by proving possession of the subject private key corresponding to PKC1 referenced by AC1 referenced by serial number and AC1 referencing PKC2) is associated with PKC1. It should be noted that PKC2 does not rely on any direct linkability (such as through the relevant choices of subject or alternative names that may include such data as email addresses or IP addresses). Note that PKC1 and PKC2 can be generated by separate CAs.

In some embodiments, the security ecosystem provides targeted distribution and / or cryptography of digital assets, messages or files, and / or other communications across domains so that end-to-end credit exists in routing. It is desirable to be able to provide services that mediate encryption / decryption. Authority management includes authorization (and / or in particular other attributes that may include names and / or identifiers) and one or more identity certificates (public key certificates) that include the subject public key and subject name, respectively. It is known that an attribute certificate, which can be configured to (preferably apparently) refer to (also known as), can be addressed. For example, the public key certificate may be referenced within the attribute certificate by the hash of the public key certificate, by the hash of the target public key, or by the hash of other fields of the public key certificate. Such a hash may be a one-way hash. The actual hash value used can be sparse among all possible sets of hash values.

In some embodiments, the attribute certificate can be used as the basis for mediation of digital assets and communications distribution as described below, in which case, for example, a reference to a "pointer value" is a pointer value is an attribute certificate. It can consist of a hash of or a hash of one or more fields of an authorization certificate. Such a hash can be a one-way hash. The actual hash value used can be sparse among all possible sets of hash values. In some embodiments, the pointer value may be alternative or additionally based on external data associated with the attribute certificate. Such data may include indexes in the database.

In some embodiments, the attribute certificate is not necessarily considered public information within this model. Rather, knowledge of a "pointer value" (or direct or indirect access to it) that (preferably apparently) refers to an attribute certificate associated with the intended recipient or group is the originator of the digital asset. An intermediary security eco that (eg, an endpoint / device, entity or individual or group) may be considered eligible to interact with the entity or endpoint / device / individual or group represented by the particular authorization certificate. Used as an indicator to the system. However, to address the possibility of unauthorized distribution / transfer of attribute certificates and / or pointer values, the security ecosystem or recipient device or other endpoint is available to the requester in the security ecosystem. Queries / requests related to a particular attribute certificate may be rejected if they are not currently eligible based on the database.

For convenience, in some embodiments, the endpoint / device, entity or individual or group represented by a particular authorization certificate is hereinafter referred to as the "owner" of the authorization certificate. This is similar to thinking of the owner of the identity certificate as the owner of the private key that corresponds to the target public key in the identity certificate. A given endpoint, device, entity, individual, or group can be represented by multiple distinct attribute certificates. Referencing a public key certificate that is commonly held across two or more such attribute certificates and / or is common across two or more such attribute certificates. There can be attributes.

Access to knowledge of one or more pointer values that reference each of a particular attribute certificate owner's attribute certificate, if any, other attribute certificates (or their pointers) to that attribute certificate owner. Does not necessarily imply access to (value). The pointer value does not necessarily have to be known by a potential digital asset / communication uploader, or to a potential digital asset / communication uploader, to provide the recipient with eligibility for uploading or transmitting. It does not necessarily have to be directly accessible to the host computer or other computing device of a digital asset / communication uploader (including endpoints, devices). For example, such a pointer value may be part of the data associated with a potential digital asset / communication uploader endpoint, device. A potential digital asset / communication uploader, as a device / endpoint / subscriber of the security ecosystem, is a pointer value held in the account data or recorded information of the device / endpoint / device / subscriber of the security ecosystem. Can have a previously given "nickname" for the attribute certificate holder to.

Knowledge of the pointer value (or direct or indirect access to it) potentially allows successful communication with the owner of the corresponding attribute certificate, and the pointer of the inviter, device, endpoint itself. It can be advantageous to offer a value offer. Requests can be made to the mediated security ecosystem as to which pointer values and / or attribute certificates are available to devices / endpoints / subscribers in a particular security ecosystem, and these pointer values are In the requesting device / endpoint / subscriber account data or recorded information, regardless of whether the requesting device / endpoint / subscriber owns one or more of these attribute certificates. possible. There may be conditions associated with the transfer of pointer values for temporary and / or persistent use. Such conditions are set by the system and / or by the devices / endpoints / subscribers of the individual security ecosystem and / or by the devices / endpoints / subscriber groups or other aggregates of the security ecosystem. Can be done. Such conditions can be associated with, for example, the invite process / inviter process.

One of the reasons the invitee attempts to transfer the pointer value in addition to owning it is that the invitee has direct or indirect access to the pointer value to the attribute certificate for such colleagues / peers, devices / endpoints / groups. Because of the successful acceptance of the invitation, the invitee may be able to successfully communicate with the invitee's colleagues and / or other peers or with the device or endpoint associated with the invitee (such as a group). Is. The invitee protocol (also known as the invitation acceptance process) itself may include the use of one or more of the inviter's and / or the inviter's colleagues' or endpoint's or device's attribute certificates. In particular, during the execution of the invitee protocol, the host computer or device used by the invitee may be exposed to data allegedly digitally signed with the invitee's private key. It may be important for the invitee to independently validate the source of such data before entrusting the process with the data it owns that is required to meet the invitee's requirements. An attribute certificate that references the public key that will be used to verify the digital signature may contain information about the invitee that the invitee can consider, perhaps as part of the decision to continue. If the guest protocol is successfully executed (including all device / endpoint authentication methods for establishing a secure communication line as described in this application), one or more attribute certificates owned by the guest will be issued. Can be done. The invitee protocol specifically uses the inviter's host computer or device or other endpoint to determine from such an attribute certificate whether the intended invitee was actually involved in the execution of the invitee protocol. It may be designed to be able to. A preferred embodiment may be designed to provide an audit trail in combination with invitee and guest processing.

In some embodiments, as part of the invitation protocol / inviter protocol, including all device / endpoint authentication methods for establishing secure communication lines as described in this application, the inviter is capable of A (preferably unambiguous) reference to one or more of the attribute certificates (eg, achieved by hashing, which can be one-way hashing) is the attribute of the guest that is the result of successful execution of the guest protocol. You may be able to choose whether or not you are allowed to be included in the certificate. Invited guests may be able to choose whether to include such references in the resulting attribute certificate. This "chaining method" of attribute certificates can be used to supply a chain of endorsements. Such endorsements can be a component of reputation scoring methods enabled through inviter / guest processing. Knowledge of such other attribute certificates is released by the security ecosystem, even if references to certain other attribute certificates are contained within the attribute certificate. Not necessarily released by the security ecosystem each time it is done. The owner of the included attribute certificate and / or the owner of the included attribute certificate may potentially specify one or more conditions for such a release. If one-way hashing is used as a means of referencing an attribute certificate, it can be difficult to reconstruct the attribute certificate without such a release.

The invention allows for an attribute certificate pointer value that references an attribute certificate, and an attribute certificate that references a public key certificate, so that software and / or hardware suitable for such configurations of the system. Ware can be used to independently verify these relationships at end entities, endpoints, and devices. The certificate issuer may be trusted directly, or a public key certificate for the issuer may occur within the chain of certificates so that higher entities in the hierarchical chain are directly trusted. The Attribute Authority (AA) may be assigned the responsibility to issue an attribute certificate, such responsibility may be represented by the public key certificate of the entity or the direct trusted knowledge of the AA's public key. The validity of an attribute certificate can be judged, at least in part, through the testing of digital signatures that are part of a properly generated attribute certificate. These digital signatures may be verified with AA's public key (eg, as judged from AA's public key certificate or from direct knowledge of AA's associated public key), and thus as a result. Brings end-to-end verifiability.

In some embodiments, the system of the present invention is not necessarily so exposed and is to be processed by the user's / device / endpoint / subscriber's client, browser, host computer, and / or peripheral device. In contrast, may be configured in various ways so that there may be options for what is exposed to the user interface. Full or partial verifiability can occur repeatedly for the same data. This is because such data is not always retained. For example, a "nickname" may be used to refer to an item, such as an attribute certificate pointer value or an attribute certificate, such a nickname may be retained or stored locally, or perhaps outside the security ecosystem. It may be accessible from the source of. The security ecosystem may be able to receive a nickname and return the intended item (perhaps because of the previous assignment of the nickname to the item), and the recipient independently validates the returned item. obtain. Nicknames can be used in this "pull" fashion for items that will be searched and possibly verified by the nickname submitter. Nicknames, or alternatives, are also "pushed" on items that will be made available to and possibly validated by devices / endpoints / subscribers identified through the security ecosystem (individuals or devices / endpoints or entities). Can be used in style. In some embodiments, validation can be done randomly rather than regularly or regularly. It is known to use random checks to detect system anomalies (maliciously imposed and / or spontaneously) as a means of reducing costs and / or inconveniences.

The preemptive invitation process between entities according to some embodiments of the present invention can establish a matrix of exchanged pointer values corresponding to existing attribute certificates. The process enables an intermediary security ecosystem as a bridge for bulk exchange of attribute certificate entities through the security ecosystem. This can be an alternative to an invitation addressed to each individual, where devices / endpoints / entity members / users / subscribers of the security ecosystem are opt-out by the security ecosystem to their devices / endpoints / entity members. Attribute certificate pointer values specified by names or other identifiers from the list of device / endpoint / entity members made available (for members who do not) and possibly related information (and / or full attribute certificates) You can set up an updatable whitelist that "preemptively" invites other selected devices / endpoints / entity members by pushing to the account data held by the guest entity's security ecosystem. This preemptive invitation / inviter process follow-up is encrypted using the invitee's cryptographic public key associated with the attribute certificate presented to the invitee's digital assets by the inviter entity for this purpose. When responding to a digital asset (preferably digitally signed), the invitee who uses the encrypted public key associated with the received pushed authorization certificate receives the inviter's corresponding authorization authorization data (potentially). Consists of a list of (and / or full attribute certificates) (appropriate subsets of) the attribute certificate pointer values of the uploading entity and perhaps related information (and / or the complete attribute certificate) that will be matched against (in matrix format). You may be limited to submitting digital assets (preferably digitally signed).

An intermediary security ecosystem may be responsible for providing a public key certificate for an encrypted public key as a target key. An intermediary security ecosystem is a public key or (if the invitee and / or guest gives the security ecosystem a pointer value for an attribute certificate or a "nickname" that maps to such a pointer value). Can be responsible for presenting an attribute certificate that references a public key certificate. In this description, the "encrypted public key" is used for key establishment, where the resulting shared secret value is used to derive the symmetric key used for encryption and decryption. May point to a key. Such key establishment may be based on Diffie-Hellman. In some embodiments, the cryptographic public key may also refer to the key used for encryption, in which case the corresponding decryption private key is used for decryption.

The device / endpoint of an entity / company or other computer user is public key / asymmetric cryptography using a client (potentially installed on a host computer or on a peripheral such as a smart card or across multiple platforms). The law may have already been adopted. In some embodiments, a system mediated by a security ecosystem may allow the import of such existing public keys. Such public keys are mediated by the security ecosystem (eg, under authentication by the CA of the security ecosystem of the CA that originally issued such public key certificate or the CA to which the issuing CA is dependent). You may already have a certificate that you can use in your system. Alternatively (or in combination), all or some such public keys of a given user can be the subject public keys of a certificate issued by the CA of the security ecosystem. The following description relates to signature verification, signature generation keys, and encryption / decryption keys, but as those skilled in the art will recognize, such descriptions are likely to include the keys used to establish the keys. Can be spread to. In all cases, the private key is used by the owner of the certificate, including the corresponding public key, while the public key is used by other / certificate users.

In some embodiments, instead of a digital asset / communication management application mediated by the security ecosystem, bypassing the entity's or other original key usage policy for decryption through the routing of the data to be decrypted. Protective measures can be taken to avoid it. The security ecosystem server may not be able to access the private key on a regular basis (thus not necessarily validating the presumed encrypted digital asset key or other encrypted data submitted. All security ecosystem clients / devices / endpoints (or at least those that interact with the security ecosystem client / device / endpoint associated with the imported public key) cannot be determined). It may be designed to format data packets so that they can be distinguished (with high probability) from any data. The use of the decrypted private key based on the imported public key is then configured to reject data based on the presumed security ecosystem that does not reveal the expected pattern / formatting when the decrypted private key is applied. can do. If the expected pattern / formatting is present, the release of the digital asset key or other data to the digital asset / communication management system client mediated by the security ecosystem may be permitted.

Potentially depending on the security given to plaintext digital assets (in terms of security consistency), digital asset keys relate to ciphertext digital asset decryption when such transmissions are outside the protected environment. For its use it may or may not be protected by encryption during local transmission. If the digital asset key is protected during transmission, the ciphertext digital asset decryption module must first decrypt the encrypted digital asset key for transmission by applying its knowledge of the key to be transmitted. there will be. Security ecosystem with respect to the use of signature generation private keys on host computers / devices / endpoints (or peripherals), both as devices / endpoints / subscribers in the business and security ecosystems not mediated by service providers. The use of always contains an argument that is signed in the "security ecosystem marker field" that helps prevent false attributes of signed messages provided by the security ecosystem system for businesses that are not mediated by service providers. In some cases, the non-repudiation aspect can be positively disambiguated. This specifically corresponds to the signature verification public key in which the signature generation private key has a certificate issued by the entity's CA, and the signature generation private key is provided by the entity on the device / endpoint computer (or peripheral). The hash of the message that will never leave the scope of the execution environment to be signed on behalf of the security ecosystem client is consistent with the operational paradigm entered into the execution environment provided by the entity. The security ecosystem marker field may be added to the end, first, or exclusive OR of the input message hash before being signed. Other methods of applying security ecosystem marker fields may be implemented. Such applications may include additional hash operations, such as hashing after the security ecosystem marker field has been added to the input message hash. To ensure that the message hash input is legitimately sourced from the security ecosystem client software, the execution environment provided by the entity and the service provider client software that generates the message hash are provided by the entity with the message hash. Authentication keys, such as message authentication code (MAC) keys, can be shared when generated outside the execution environment.

Including digital signatures in message transmissions typically increases the latency of the entire message, so how to reduce the overhead of using digital signatures for message authentication to some extent is described below. In many lightweight messaging protocols, such as MQTT (Message Queue Telemetry Transport) used over the TCP / IP protocol, bandwidth is limited. This is especially true when message transmission completion latency is important. The message packet size is preferably reduced to keep latency short. The availability of limited bandwidth can make it difficult to use techniques such as digital signatures of transmitted data due to the overhead of adding a relatively large digital signature to each packet.

FIG. 10 illustrates an exemplary method of using a digital signature in a bandwidth-constrained environment, according to some embodiments of the present invention. This method reduces the bandwidth required to transmit data. In some embodiments, the value "n" is chosen so that the digital signature is transmitted every "nth" payload, rather than transmitting the digital signature attached to each data payload. This allows for a trade-off between security and bandwidth by adjusting the value of n for a variety of applications. Thus, potential intruders / hackers are detected after at most n-1 payload packets.

In some embodiments, an encrypted or unencrypted sequence number 1001 can be added to each packet 1002. Instead of the normally expected contiguous integers, the sequence number can be, for example, a contiguous word of hash value generated when the first digital signature 1003 for the transmission of n payload packets is created. .. The hash value is known only to the sender and receiver of the digital signature, so any packet introduced by an attacker will be immediately detected.

In some embodiments, the contents of each sequence number 1001 and payload packet 1002 are presented as a mathematical function of the sequence number created as described in the previous paragraph. This process will protect not only against packet injection, but also against packet changes in existing, otherwise valid packets.

FIG. 11 shows an exemplary method of transmitting a digital signature while minimizing the bandwidth required for such transmission, according to some embodiments of the present invention. In some embodiments, this is achieved by using a sliced digital signature. For example, the digital signature 1103 is cut into n slices 1101, and each slice 1101 is included as part of each individual payload 1102 that will be transmitted. The receiving entity of the transmission then captures each slice of the digital signature from each payload. Upon receiving n payload packets, n digital signature slices are reassembled into a complete digital signature, which is then verified through the application of known digital signature techniques. By adjusting the value of n, the implementer can trade off the overhead load of digital signatures with signature verification latency, for example, a larger n results in a lower overhead load, but a message. The overall latency can increase with increasing size of n.

It will be appreciated by those skilled in the art that various modifications can be made to the above-described embodiments of the present invention and other embodiments without departing from their broad inventive scope. Accordingly, the invention is not limited to the particular embodiments or configurations disclosed, but rather includes any changes, adaptations, or modifications within the scope of the invention as defined by the accompanying claims and drawings. It will be understood that it is intended to be.

Claims (23)

A method for establishing secure communication between multiple IoT (Internet of Things) devices, each containing a hardware processor and associated memory, in one or more vehicles.
Provisioning the plurality of IoT devices by providing each of the plurality of IoT devices with a unique identifier, a digital identity token, and an encryption key.
By authenticating each communication line between each IoT device and issuing a digital certificate to each communication line, a secure communication line between the plurality of IoT devices can be established.
Grouping the plurality of IoT devices into different groups based on predetermined criteria, and
Including group membership for one of the different groups in the attribute certificate showing the group characteristics
Including methods. The method of claim 1, wherein each of the secure communication lines comprises a digital contract that establishes conditions for the use of the secure communication line, respectively, between the respective IoT devices. The method according to any one of claims 1 to 2, wherein the attribute certificate containing the relevant rules regarding group membership is issued to the group. The method according to any one of claims 1 to 3, wherein the different groups include subgroups. The method according to any one of claims 1 to 4, wherein each different vehicle has a different group, and each subgroup of each group includes a component of the vehicle. One or more IoT devices are coupled to the vehicle's Controller Area Network (CAN) bus and securely communicate with another IoT device that is coupled to or not to the CAN bus. The method according to any one of claims 1 to 5, wherein a line can be established. One or more IoT devices are coupled to the vehicle's Controller Area Network (CAN) bus and made into a group of IoT devices characterized with the CAN bus recorded in the authorization certificate. The method according to any one of claims 1 to 6, wherein the associated attribute certificate is used by a qualified caller to communicate between one or more of the groups. The secure communication line is a group consisting of vehicle-to-vehicle (V2V), vehicle-infrastructure (V2I), vehicle-grid (V2G), vehicle-X (V2X), and vehicle on-board diagnostics (OBD). The method according to any one of claims 1 to 7, which is used to communicate between one or more of the above. The method according to any one of claims 1 to 8, wherein the group relating to a particular vehicle comprises a variable identifier relating to the particular vehicle for transmission to an external device. 8. The method of claim 8, wherein the variable identifier dynamically changes based on one or more of certain operating modes or operating times of the particular vehicle or its IoT device. The different groups monitor an external device group that includes a device in the particular vehicle and an internal area of the particular vehicle that monitors the external area of the particular vehicle that communicates with other devices outside the particular vehicle. The method according to any one of claims 1 to 10, which includes an internal device group including a device. 11. The method of claim 11, wherein the external device group or the internal device group comprises a related rule that prevents the group from transmitting certain information to another device. A claim that further comprises preventing a device that is not a member of a group having an unestablished secure communication line to the plurality of IoT devices or having an approved attribute certificate from communicating with the plurality of IoT devices. The method according to any one of items 1 to 12. The method according to any one of claims 1 to 13, further comprising authenticating each of the plurality of IoT devices using each unique identifier and digital identity token of the plurality of IoT devices. The method of any of claims 1-14, wherein authenticating the IoT device comprises using an inviter-invite guest protocol. 15. Of claims 1 to 15, said one or more vehicles include one or more of ambulances, police vehicles, tow trucks, dangerous goods vehicles, military vehicles, or other defined vehicle types. The method described in either. Establishing a second group of external devices
Issuing a second group private key to each member of the second group
To establish an attribute certificate for the second group to one or more members of the different groups.
The method according to any one of claims 1 to 16, further comprising. A method for establishing secure communication between multiple Internet of Things (IoT) devices, each containing a hardware processor, associated memory, unique identifier, digital identity token, and encryption key, in one or more vehicles. There,
Inviting the second IoT device by the first IoT device to establish a communication line with the first IoT device by receiving a digital identity token from the second IoT device.
By authenticating the communication line between the first IoT device and the second IoT device and issuing a digital certificate to the communication line, the first IoT device and the second IoT device can be obtained. Establishing a secure communication line between
Grouping the plurality of IoT devices into different groups based on predetermined criteria, and
Including group membership for the different groups in each attribute certificate for each of the devices.
Including methods. 18. The security line of claim 18, wherein the secure communication line comprises a digital contract that establishes conditions for the use of each secure communication line between the first IoT device and the second IoT device. Method. The method of any of claims 18-19, wherein an attribute certificate containing relevant rules for group membership is issued to the group. The method of any of claims 18-20, wherein the different groups include subgroups, each different vehicle has a different group, and each subgroup of each group comprises a component of the vehicle. A group of specific vehicles includes a variable identifier for the specific vehicle for transmission to an external device, the variable identifier being one of a certain operating mode or operating time of the specific vehicle or its IoT device. The method according to any one of claims 18 to 21, which is dynamically changed based on a plurality of the same. Establishing a second group of external devices
Issuing a second group private key to each member of the second group
To establish an attribute certificate for the second group to one or more members of the different groups.
The method according to any one of claims 18 to 22, further comprising.

Images