Methods and systems for ensuring trust between entities

Abstract

This technology simplifies the management of information used to authenticate communication partners. [Solution] The first entity possesses a first identity certificate, and the second entity possesses a second identity certificate. The root certificate authority generates a first relationship certificate between the first entity and the first group. The first entity stores the first relationship certificate. The first entity sends the first identity certificate and the first relationship certificate to the second entity as a first communication. The second entity verifies that the first identity certificate and the first relationship certificate were legitimately created by the root certificate authority. Based on the verification of the first identity certificate and the first relationship certificate by the second entity, the second entity or the first entity activates a predetermined function.

Description

Technical Field

[0001] The present disclosure relates to a technology that permits actions between entities by ensuring reliability among various entities.

Background Art

[0002] Patent Document 1 discloses a configuration in which a vehicle and a mobile device perform wireless communication compliant with the CCC (Car Connectivity Consortium) standard.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When entities need to communicate with each other, a secure protocol can be used. CCC is an organization that sets standards for vehicle accessibility for all smart mobile devices. CCC provides a certificate-based system for establishing sessions between entities for communication. In the communication method proposed by CCC, a session is established and a certificate is generated. The certificate is stored in the entity that performs the communication. One problem with such a communication method is that a lot of time and coordination between logical entities stored in different servers are required when establishing a session and generating a certificate. The time and complexity of coordination are particularly important considerations in a fleet with hundreds or thousands of vehicles and service users.

[0005] One object of the present disclosure is to provide a technology that simplifies the management of information for authenticating communication partners.

Means for Solving the Problems

[0006] The system disclosed herein includes a root certification authority (20) that provides a first identity certificate, The system comprises a first entity (12) that stores a first identity certificate created by a root certificate authority, and a second entity (14) that stores a second identity certificate created by a root certificate authority, wherein the root certificate authority generates a first relationship certificate relating to the relationship between the first entity and the second entity, or the relationship between the first entity and a first group or role, the first entity stores the first relationship certificate, the first entity transmits the first identity certificate and the first relationship certificate to the second entity in a first communication, the second entity verifies that the first identity certificate was created by a root certificate authority, the second entity verifies that the first relationship certificate was created by a root certificate authority, and the second entity or the first entity is configured to activate a predetermined function based on the verification of the first identity certificate and the first relationship certificate by the second entity.

[0007] The method of this disclosure includes: a root certificate authority generating a first identity certificate; a first entity storing the first identity certificate generated by the root certificate authority; a second entity storing a second identity certificate created by the root certificate authority; the root certificate authority generating a first relationship certificate relating to the relationship between the first entity and the second entity, or the relationship between the first entity and a first group or role; the first entity storing the first relationship certificate; the first entity transmitting the first identity certificate and the first relationship certificate to the second entity in a first communication; the second entity verifying that the first identity certificate was created by the root certificate authority; the second entity verifying that the first relationship certificate was created by the root certificate authority; the first entity and the second entity communicating based on the second entity's verification of the first identity certificate and the first relationship certificate; and enabling predetermined functions in the first entity and the second entity.

[0008] In the conventional configuration, where a certificate is issued for each combination of entities, the update procedures resulting from entity replacements and other changes become cumbersome as the number of entities increases. In contrast, the technology disclosed herein guarantees the connection between a first entity and a second entity through the legitimacy of an intermediate group or role. Functionality becomes available once the identity of the first entity and its relationship to the group or role to which it belongs are proven. By introducing the concept of an intermediate group or role, the effort (and in practice, the processing load) required to manage certificates and other documents when the first or second entity changes can be reduced.

[0009] The reference numerals in parentheses in the claims indicate the correspondence with the specific means described later in the embodiments, and do not limit the technical scope of this disclosure.

[0010] Other applicable fields will become apparent from the descriptions contained herein. The descriptions and examples in this summary are for illustrative purposes only and do not limit the scope of this disclosure. [Brief explanation of the drawing]

[0011] The drawings in this disclosure illustrate only selected embodiments and do not represent all possible implementations, nor are they intended to limit the scope of this disclosure. [Figure 1A] This is a block diagram of the communication system disclosed herein. [Figure 1B] This block diagram shows the case where the first entity is a mobile phone and the second entity is a vehicle. [Figure 1C] This is a block diagram where the first entity is a telephone and the second entity is a point-of-sale information management system. [Figure 2] This diagram shows the relationship certificates between groups and the entities belonging to each group. [Figure 3A] This diagram shows the relationship certificate and identity certificate stored by the first entity, and the entity's certificate stored by the second entity. [Figure 3B] This is a perspective view showing the identity document held by the first entity and the entity certification and relationship certificate held by the second entity. [Figure 4] This is a block diagram of a root certificate authority. [Figure 5] This is a block diagram of a typical entity. [Figure 6] This diagram shows that the root certification authority has or is connected to user certification authorities, related certification authorities, and vehicle certification authorities. [Figure 7] This figure illustrates the mutual communication between a first entity and a second entity regarding identity documents. [Figure 8] This is a flowchart showing how to generate an identity document. [Figure 9]This is a flowchart illustrating a method for verifying identity and communicating with each other between two entities. [Figure 10] This is a flowchart illustrating the communication procedure between the server and the entity for using certificate-based functionality. [Modes for carrying out the invention]

[0012] Next, exemplary embodiments will be described with reference to the accompanying drawings. In some of the drawings, corresponding parts are indicated by their corresponding reference numbers.

[0013] As shown in Figure 1A, the communication system 10 is used between a first entity 12 and a second entity 14. The first entity 12 uses the communication system 10 to access functions 16 provided by the second entity 14, or functions 16 provided through the second entity 14. The first entity 12 and the second entity 14 communicate via a network such as Bluetooth® Low Energy, Ethernet, or short-range wireless communication, but the means of communication are not limited to these. For example, the first entity 12 is a portable device such as a cellular phone or mobile phone. The second entity 14 is a vehicle. In a combination of a portable device and a vehicle, the function 16 may be to unlock the vehicle, start it, or authorize / execute a combination thereof. The function may also be to access the device, enable or disable the device, communicate with a third entity, modify a record, or approve a transaction. The device here refers to a device that implements the function, and may be an actuator, display, speaker, wearable device, etc. Alternatively, the device may include a server that performs processing related to the execution of the function. The third entity is also a communication device that realizes a function, and may be a sensor, actuator, display, speaker, etc. The records may be stored data on a variety of items, such as purchase history, browsing history, website access history, destination setting history, user settings, and recorded personal information (e.g., name and password).

[0014] The root certification authority 20 may be a server or a certification authority that functions as a verification source to enable the first entity 12 and the second entity 14 to communicate with each other, as will be described in detail below. The description of "root authority" may be rephrased as "root authority department" or "root module", etc. An example of a method of identity verification (in other words, personal confirmation) is included in this disclosure. Without being limited to the following specific examples, other methods for proving identity (including methods not listed here), such as simple tokens, usernames and passwords that return tokens, zero-knowledge proofs, etc., may be used for personal confirmation.

[0015] The root certification authority 20 has a root public value 20A (also referred to as a public key) and a root secret value 20B (also referred to as a secret key). The public value 20A can be shared with the first entity 12 and the second entity 14. The secret value 20B is used for encrypting or decrypting the communication between the entity and the root certification authority 20. The secret value 20B can also be used for signing certificates or evidence indicating identity and certificates of relationships such as tokens.

[0016] The first entity 12 has a public value 12A, a secret value 12B, an identity certificate 12C, and a relationship certificate 12D. The public value 12A corresponds to the first public value, and the secret value 12B corresponds to the first secret value. The second entity 14 also has a public value 14A, a secret value 14B, an identity certificate 14C, and a relationship certificate 14D. The public value 14A corresponds to the second public value, and the secret value 14B corresponds to the second secret value. The relationship certificates 12D and 14D are optional elements. The public values 12A, 14A may be implemented as public keys. The secret values 12B, 14B may be implemented as secret keys. The identity certificates 12C, 14C can be created and signed by the root certification authority 20, as will be described in detail below. The identity certificates 12C, 14C may be realized by certificates. To ensure the reliability of the communication between the first entity 12 and the second entity 14, the root certification authority 20 signs the identity certificates 12C, 14C.

[0017] Relationship certificates 12D and 14D can be used to establish relationships or connections between entities and groups. Relationship certificates 12D and 14D may also be used to clarify relationships or connections between groups to which entities 12 and 14 belong. Relationship certificates 12D and 14D may be lists of entities related to a group, or lists of other groups related to a group. Relationship certificates 12D and 14D may be updated periodically for updates to the membership list or upon expiration of their validity period.

[0018] The root certificate authority 20 can communicate with the first entity 12 via the first communication device 22. The root certificate authority 20 can communicate with the second entity 14 via the second communication device 24. The first communication device 22 and the second communication device 24 may be the same device or the same type of communication device. The first communication device 22 and the second communication device 24 may be physically different devices. The first communication device 22 and the second communication device 24 may be a network, a beacon, or other type of intermediate storage device configured to store values ​​provided by the root certificate authority 20. That is, the root certificate authority 20 may be configured to communicate indirectly with the first entity 12 and the second entity 14. This is in contrast to a CCC-type system in which the root certificate authority 20 communicates directly with the first or second entity 14 during certificate exchange.

[0019] The root certificate authority 20 may be connected to the user interface 28. The user interface 28 may be used to input data into the root certificate authority 20. The user interface 28 may also be used to add data to the database 30. The database 30 stores relationships between various groups and membership information of various groups, as will be described in detail below. Relationship certificates 12D and 14D provide certificates of relationships with other groups or certificates of being a member of a group. Relationship certificates may include rule data that permits (enables) or restricts the use (also known as access) of different entities, such as multiple vehicles.

[0020] Figure 1B shows a specific example of the communication system 10. In the example in Figure 1B, a mobile phone 40, as a first entity 12, is used to communicate with a vehicle 42, as a second entity 14. The mobile phone 40 and the vehicle 42 can communicate with each other to perform functions by physical access devices (also called actuators), such as a starter function 44 and a door lock function 46 in an electronic door lock. Information about the group 50 to which the mobile phone 40 and / or the vehicle 42 belong can be used to determine whether or not access to a particular function is permitted. The formation of multiple groups 50 and the composition of members within a group will be described in more detail below.

[0021] Figure 1C shows a configuration in which a mobile phone 40 is used together with a point-of-sale (POS) device 60. The POS device 60 may be a credit card or a bank access type machine for direct debit from a bank account. The POS device 60 can enable functions such as purchase authorization 62 (also called payment functions). In this example, a set of groups 64 is established. Group 64 includes routing number group 66 and account number group 68. When a user becomes a member of the two groups 66 and 68, the purchase 62 is finally authorized using the mobile phone 40, and the POS device 60 executes the direct debit from the account.

[0022] Next, Figure 2 illustrates the more complex interrelationships between the first entity 12 and the second entity 14. There can be multiple first entities 12, and there can also be multiple second entities 14. The first entity 12 can belong to one of several groups, such as the rideshare customer group 210, the rental customer group 212, the management group 214, the airport mechanic group 216, and the employee group 218. As shown in the lower left of Figure 2, the first entity 12 may have specific roles (also called titles or statuses), such as manager, mechanic, counter staff, chief mechanic, counter staff, vehicle return, IT leader, and junior mechanic. The rideshare customer group 210 and the rental customer group 212 are exclusively independent groups. At the bottom of Figure 2, the first entity 12 with different titles is shown, and these may belong to multiple groups. For example, the manager, chief mechanic, and IT leader may be included in the management group 214. Airport maintenance group 216 may include maintenance technicians, chief maintenance technicians, and junior maintenance technicians. Employee group 218 may include all of the first entities 12 in the lower left, including managers, maintenance technicians, reception staff, chief maintenance technicians, reception staff, vehicle return staff, IT leaders, and junior maintenance technicians.

[0023] The first entity 12 and the first groups 210-218 are related to each other by links 220, which may be represented by relationship certificates defined in more detail below.

[0024] The first groups 210-218 are each connected to the second groups 230-234 by independent links 222. In the example shown in Figure 2, the airport rental group 230, the airport vehicle group 232, and the airport pool group 234 are illustrated. The links 222 between the first and second groups include, for example, the following relationships: The rideshare customer group 210 and the rental customer group 212 are included in the airport rental group 230. The airport mechanics group 216 and the vehicle return entity belong to the airport vehicle group 232. The employee group 218 is part of the airport pool group 234.

[0025] In the example in Figure 2, the vehicles as the second entity 14 have subgroups. In the example in Figure 2, the first two vehicles correspond to group 240, which consists of full-size or van vehicles. The second group, 242, is the rental / fleet group. The last group, which includes vehicle 244, is the special vehicle group (e.g., luxury SUVs). The two second entities 14 included in the first group 240 belong to the airport pool group 234 and the airport vehicle group 232. The next five vehicles (five second entities 14) belong to the airport rental group 230 and the airport vehicle group 232. The last vehicle, 244, is associated with the management group 214 and a contact person who is a friend of the manager. The manager and some contact persons can use the special vehicle, vehicle 244, on special occasions.

[0026] The membership of entities, the inclusion (or linking) relationships of groups, and the control rules for functionality may be described in the relationship certificate.

[0027] Figures 3A and 3B show an example in which a specific first entity 12 is illustrated as "Jeff's phone" and a second entity 14 is specifically illustrated as "Special Car X". Certificate 310 corresponds to one or more certificates stored in "Jeff's phone" as the first entity 12. Certificate 310 includes, for example, several identity certificates 312, 314, and 316. In this example, the first identity certificate is the root certificate 312. The second optional intermediate certificate corresponds to the user's certificate or identity certificate 314 and is derived from the root certificate 312. The intermediate certificate may be, for example, a certificate issued by the user certification authority 620, which will be described later. CA in the figures means certification authority. The last certificate corresponds to the specific user's (in other words, personal) certificate or identity certificate 316 derived from the intermediate certificate. The identity certificates 312 to 316 form a chain. Therefore, the final identity certificate 316 can be determined to be authentic as it relates to the root certificate 312 through the intermediate certificate.

[0028] Furthermore, the first entity 12 has server-signed data corresponding to relationship certificates representing membership (in other words, affiliation) with groups 210-218 or 230-234 in Figure 2. In this example, the first relationship certificate 320 indicates that "Jeff" is a member of mechanic group 216. The second relationship certificate 322 indicates that the mechanic is assigned to airport vehicle group 232. The third relationship certificate 324 corresponds to special vehicle X belonging to airport vehicle group 232. "Gr" in the figure is an abbreviation for group. The vehicle certificate 330 includes the first root certificate 332, the intermediate certificate 334, and the identity certificate 336 for special vehicle X. The intermediate certificate 334 may be a certificate issued by the vehicle certification authority 624, which will be described later. The identity certificates 312-316 and 332-336 may have no expiration date or may have a sufficiently long expiration date. Membership within a specific group, as indicated by relationship certificates 320, 322, and 324, has a short validity period and may expire periodically. The validity period of relationship certificates 320, 322, and 324 can vary and may, for example, be daily, weekly, or monthly. Of course, the unit of the validity period may be set to other lengths. In this embodiment, the identity certificates are relatively static and do not need to be frequently transmitted to the first entity 12 or the second entity 14. On the other hand, the server-signed data of relationship certificates 320, 322, and 324 may be notified to the first entity 12 before it expires. In the method of this embodiment, the group composition may change. Furthermore, two sets of relationship certificates may be provided to the first entity. For example, in a configuration where new relationship certificates 320, 322, and 324 are provided weekly, a separate set of relationship certificates 320, 322, and 324 that expires after two weeks may also be provided. By providing multiple sets of relationship certificates with different expiration dates, even if connection or renewal becomes impossible due to connection problems, the relationship certificates can be maintained for a period during which the expiration dates of at least two sets of relationship certificates overlap.

[0029] As shown in Figure 3B, the certificate may be held by the first entity 12, the second entity 14, or both. As shown in Figure 3B, relationship certificates 320, 322, and 324 may be included in the certificate held by the vehicle. The difference between Figure 3A and Figure 3B is that the first entity 12, such as "Jeff's Phone" 12, only needs to provide identification documents, such as certificates, to communicate with the second entity 14. Corresponding to Figure 3A, relationship certificates may be provided so that the vehicle can know the members of the group. In Figure 3B, since the relationships between the groups and their members are known in the second entity 14, the only information transmitted from the first entity 12 is the entity's certificates 312-316.

[0030] Next, with reference to Figure 4, the details of the root certificate authority 20 will be described. The root certificate authority 20 includes a user interface 28 and a database 30. In this example, a display 410 is also connected to the root certificate authority 20 in a communicative manner, providing the operator with a means for information presentation and programming. For example, the operator can use the display 410 to create data showing various relationships, such as identity certificates and relationship certificates, and the display 410 can display it. The user can use the user interface 28 to select members of a group located between the first entity 12 and the second entity 14.

[0031] The root certificate authority 20 has a network interface 412, an identity certificate generator 414, and a relationship certificate generator 416. The network interface 412 allows the root certificate authority 20 to send and receive identity certificates and relationship certificates with various entities using various networks. The identity certificate generator 414 is used to generate identity certificates. The identity certificate generator 414 may be used to sign the public key provided by either entity 12 or 14. The relationship certificate generator 416 generates relationship certificates by associating devices with various groups, as shown in Figure 2. The relationship certificate generator 416 may sign the relationship certificates before providing them to entities 12 or 14. Signing is performed using the root private key or using the private key of an optional intermediate certificate authority that signed certificates 314 and 334.

[0032] Root Certificate Authority 20 possesses root public value 418, which can also be called the public key. Root secret value 420 is also included within Root Certificate Authority 20. Root secret value 420 can also be called the private key.

[0033] The root certificate authority 20 may include an expiration control unit 422 and an authentication control unit 424. As described above, relationship certificates can have an expiration date. The relationship certificate generator 416 may be coupled with the expiration control unit 422. The expiration control unit 422 is a software / hardware module that controls the expiration date of relationship certificates. The expiration control unit 422 can set different expiration dates depending on the type of data group. As described above, relationship certificates may have various expiration dates specified during their creation phase. The expiration dates for each relationship certificate may overlap partially or completely to achieve the accessibility desired by various entities.

[0034] The authentication control unit 424 is used to authenticate various entities. Various entities, such as mobile devices, can be authenticated in a variety of ways using components of the mobile device itself or components of the root certification authority 20, such as the authentication control unit 424. The authentication control unit 424 can verify passwords, fingerprints, user IDs, and other authentication means.

[0035] The root certificate authority 20 may also have an encryption control unit 426. The encryption control unit 426 enables encrypted communication in communication between various entities 12, 14. The encryption process can use public and private keys. That is, the received communication data is encrypted with the public value 418, and the private value or key is used to decrypt the communication data. The data transmitted from the root certificate authority 20 is encrypted using the public key of one of the entities 12, 14 and sent to the destination.

[0036] The root certification authority 20 may also have a restriction enforcement control unit 428. The restriction enforcement control unit 428 may evaluate restrictions for providing relationship certificates. The restriction enforcement control unit 428 may set geographical restrictions. For example, in the case of a rental car company associated with an airport, only vehicles associated with that airport may be provided, rather than all vehicles associated with the company.

[0037] The root certificate authority 20 may also include a processor (e.g., a microprocessor) 450 and memory 452. Memory 452 may be programmed to perform various functions; that is, memory 452 may be a non-transient, computer-readable medium containing a program executable by the processor 450 for performing various functions that the root certificate authority 20 may provide. The root certificate authority 20 can communicate with one or more distribution systems 460. In this example, a beacon 462, a Bluetooth device 464, or the internet 466 are exemplified. The Bluetooth device 464 may be a device that performs Bluetooth LE communication.

[0038] Next, referring to Figure 5, the details of entities 12 and 14 will be described. Entities 12 and 14 may have a user interface 510 for sending and receiving data. Entities 12 and 14 are equipped with a display 512. A touchscreen may be provided as a combination of the user interface 510 and the display 512. The user interface 510 may be a keyboard, touchscreen, mouse, etc. The display 512 is used to display various data. Entities 12 and 14 may include a network interface 520 used to communicate with one of the distribution systems 460 in Figure 4. The network interface 520 is sometimes called a modem.

[0039] Entities 12 and 14 may have restriction settings 522 related to data usage. That is, restriction settings 522 may be data setting restrictions related to geography (location), time, purpose of use, etc. For example, if there are geographical constraints, global positioning data may be used. Time restrictions may prevent or permit use during specific time periods of the day. Restrictions stipulated in restriction settings 522 can reduce the traffic of relationship certificates sent and received by entities 12 and 14 within a specific area. Furthermore, restriction settings 522 may prevent a vehicle from being driven or driven for an unauthorized purpose if the vehicle is outside a specific geographical area, such as outside a staging area or an airport.

[0040] Entities 12 and 14 may include an identity verification circuit 524, a relationship verification circuit 526, and a function request circuit 528. The identity verification circuit 524 enables data exchange between entities 12 and 14 and the root certification authority 20 for entities 12 and 14 to obtain identity certificates. Similarly, entities 12 and 14 can obtain and generate relationship certificates using the relationship verification circuit 526. The function request circuit 528 can be used to enable or disable functions based on provided groups and / or certificates. That is, the function request circuit 528 may be a comparator that compares the identity information or authorization information of an entity with membership in a group to enable or disable a particular function. In one example, identity information is provided by the first entity 12 and compared with membership in one of the groups, resulting in the second entity 14 being able to unlock the doors of a vehicle or start the vehicle. Communication between entities can also be performed using an encryption / decryption circuit 530. The encryption / decryption circuit 530 enables encryption and decryption in communication between the entity and the root certification authority 20.

[0041] Entities 12 and 14 are authenticated by the authentication circuit 532. The authentication circuit 532 may perform authentication on the first entity 12, the second entity 14, or the root certification authority 20. Examples of authentication on entities 12 and 14 include fingerprint authentication and facial recognition. The exchange of user IDs and / or passwords may take place between entities 12 and 14 and the root certification authority 20.

[0042] Entities 12 and 14 may include a processor (e.g., a microprocessor) 540 and memory 542. The processor 540 is configured to execute various commands and instructions. Memory 542 is non-transient, computer-readable memory that stores commands executed by the processor 540.

[0043] Figure 6 shows a block diagram of how to add a user to the system. Figure 6 roughly corresponds to the interconnections shown in Figure 2. The root certification authority 20 may have a user certification authority 620 associated with the root certification authority 20. The relational certification authority 622 may also be associated with the root certification authority 20. The vehicle certification authority 624 may also be associated with the root certification authority 20. The user certification authority 620 includes a group of users, such as the user device (entity 12) shown on the left side of Figure 2. Jeff's mobile device 630, who is a single user, is added to the user certification authority 620. The relational certification authority 622 adds Jeff and his mobile device to the mechanics group. In the existing configuration, mechanics have access to the mechanics group 216 and thus to the airport vehicle group 232, and also to special vehicle X, which belongs to the airport vehicle group 232. The vehicle certification authority 624 has special vehicle 638 as part of it. Special vehicle 638 shown in Figure 6 corresponds to vehicle 244 as a special vehicle in Figure 2. Jeff's mobile device 630 is part of the mechanics group, and mechanics have access to all vehicles at the airport, so Jeff (and his mobile device) can access special vehicle 638. This access may include driving special vehicle 638 within the airport grounds. It may also include unrestricted access to open and drive special vehicle 638. Thus, adding Jeff to the mechanics group is simple, and the mechanics group has access to the airport vehicle group. One advantage of this system is that any number of users associated with the group can access the same vehicle without updating the vehicle information. Users provide all necessary identification documents and group-based authentication when approaching the vehicle. The certificates may be signed by cloud-based service logic so that the vehicle can be authenticated offline. Therefore, real-time interconnection between the vehicle and the server is not required.

[0044] Figure 7 shows a root certificate authority 20, Jeff (essentially his mobile device) 630 as the first entity 12, and a special vehicle 638 as the second entity 14. In this example, an interconnection is established between Jeff's mobile device 630 and the special vehicle 638. As illustrated, the root certificate authority 20 has a public key AAAA and a private key BBBB. Jeff or his mobile device 630 has been given the public key AAAA from the root certificate authority 20. The mobile device 630 has a signed certificate, a public key CCCC, and a private key DDDD. The special vehicle 638 (corresponding to the second entity 14) has the public key AAAA provided by the root certificate authority 20 and a signed certificate from the root certificate authority 20. The public key EEEE and private key FFFF are stored in the special vehicle 638. To initiate communication between Jeff's mobile device 630 and the special vehicle 638, the mobile device 630 sends data using the public key EEEE. Special vehicle 638 decrypts the certificate using the private key FFFF. Special vehicle 638 uses the public key AAAA to verify that the root certificate authority 20 has signed Jeff's certificate. That is, signals are sent and received using the public key for encryption, and the private key is used by the root certificate authority 20 to decrypt the received message. Once confirmation is received by special vehicle 638, special vehicle 638 initiates encrypted communication using the public key CCCC of the mobile device 630. The mobile device decrypts the received data using the private key DDDD. In this way, communication between special vehicle 638 and Jeff's mobile device 630 becomes possible, and as a result, Jeff is able to access the special vehicle (and its functions) according to his authorization.

[0045] Figure 8 illustrates a method for providing an identity certificate to a requesting entity. In this example, the requesting entity is either the first or second entity described above. The following example explicitly shows the creation of an identity certificate for the first entity based on a request from the first entity, but the same interpretation may be applied to the second entity. The identity certificate for the first entity corresponds to the first identity certificate, and the communication for creating the identity certificate for the first entity corresponds to the first request. Similarly, the identity certificate for the second entity corresponds to the second identity certificate, and the series of communications for creating the identity certificate for the second entity corresponds to the second request. In step 810, the requesting entity is authenticated. The requesting entity may be authenticated using one or a combination of different methods. The authentication circuits provided by the root certification authority 20 and / or entity 12 may be used for the authentication. Possible authentication methods include fingerprint authentication, facial recognition at the requesting entity, and the provision of a password or other security from the requesting entity to the root certification authority.

[0046] In step 812, public values ​​such as a public key are transmitted from the requesting entity to the root certificate authority 20. In step 814, the public values ​​from the requesting entity are signed using the secret value of the root certificate authority 20. In step 816, a proof of identity is generated based on the server secret value and the signature. This is sometimes called a certificate. In step 818, the proof of identity is sent to the requesting entity. This proof of identity may have an unlimited or predetermined expiration date. The requesting entity stores the received certificate. As shown in Figures 3A and 3B, various types of certificates or proof of identity may be provided by various certificate authorities. The root certificate authority may include or be connected to some or all of the user certificate authority, related certificate authority, and vehicle certificate authority. Each may generate a proof of identity that is ultimately used to achieve secure communication. After identity verification, encryption and decryption are performed.

[0047] Figure 9 illustrates how entities communicate with each other. This process assumes that a certificate has already been created and stored for each entity. In step 910, a request (hereinafter also referred to as the first communication request) containing an identity certificate encrypted with the public key of the first entity 12 is sent from the first entity 12 to the second entity 14. The sending and receiving of data related to the communication request constitutes the first communication. The certificate of the first entity 12 may be one or more identity certificates, as shown in 312, 314, and 316 of Figure 3A. A bundle of multiple identity certificates can also be called a stack. In step 912, the identity certificate (or stack) is decrypted with the public value of the second entity 14. As mentioned above, the public value is sometimes called the public key. In step 914, the root public value is used to verify whether the received identity certificate was signed by the root certificate authority 20. This is also a verification using the public key of the root certificate authority. To ensure that only a root certificate authority can sign the certificate, the private key of the root certificate authority is used to sign the certificate from the first entity 12.

[0048] In step 916, an identity certificate is sent from the second entity 14 to the first entity 12. The communication related to the sending and receiving of the identity certificate of the second entity 14 corresponds to the second communication. In step 918, the first entity verifies that the received identity certificate is signed by the root certification authority. A trust relationship is formed between the first entity 12 and the second entity 14 after the first entity 12 has verified that the identity certificate of the second entity 14 is signed by the root certification authority, and the second entity 14 has verified that the identity certificate of the first entity is signed by the root certification authority. Subsequently, data can be exchanged between the first and second entities. For example, in step 920, the first entity 12 requests data from the second entity 14. In step 922, the requested data is encrypted with the public key of the first entity 12. In step 924, the data is transmitted to the requesting entity. In step 926, the first (or requesting) entity decrypts the received data using a secret value. The secret value of each entity is used to decrypt a value encrypted with the public key of the other entity.

[0049] In the example shown in Figure 9, the first entity 12 and the second entity 14 mutually verify each other's identities, but this is not the only possible configuration. If the first entity 12 is the requester of the function and the second entity 14 has the right to control the function, only the second entity 14 may verify the identity and right to use the function of the first entity 12. That is, the first entity 12 transmits its identity certificate (i.e., the first identity certificate) and relationship certificate (also called the first relationship certificate) to the second entity 14. The second entity 14 verifies, using root public values, that the first identity certificate and the first relationship certificate were created by the root certification authority 20. Based on the verification of the authenticity of the first identity certificate and the first relationship certificate by the second entity 14, the second entity 14 may activate the requested function. The roles of the first entity 12 and the second entity 14 may be swapped. Furthermore, after authentication of the communication partner using two or more types of certificates is completed, the entity that activates the target function may be the first entity 12. The first entity 12 may activate the function after the authentication sequence with the second entity 14 is successful. Activating the function means executing the function, which may be such as unlocking the vehicle or turning on the power. The function may be realized through the cooperation of the first entity 12 and the second entity 14, and if the realization of the function involves multiple processing steps, some processing steps may be executed by the first entity 12 and other processing steps may be executed by the second entity 14. Also, in realizing the function, the second entity 14 may simply function as a relay to relay communication between the actuator related to the realization of the function and the first entity 12.

[0050] Next, we will explain how to use groups using Figure 10. In step 1010, a group is created in a root certificate authority or another type of entity such as a corporate entity. In step 112, users are added to the group. In step 1014, some groups may contain other groups or individual users. This can be done in step 1014. In step 1016, the group relationship is signed by the server for use. The relationship certificate corresponds to the line between the group and the entity shown in Figure 2. In step 1018, the relationship certificate data is stored in the database corresponding to the group. In step 1020, the relationship certificate is propagated to various entities. In step 1022, the relationship certificate is allowed to expire. The expiration date is set when the relationship certificate is created. In step 1024, a query is generated in the first entity 12. In step 1026, the second entity 14 receives information about the group to which the first entity 12 belongs from the first entity 12. The second entity 14 may also hold information about that group. Ultimately, if the first entity 12 belongs to a specific group, functionality will be enabled in the second entity 14 based on that group. When providing certificate data such as identity certificates and relationship certificates for various entities, data that accommodates geographical restrictions or other types of restrictions may be used. For example, vehicles not located within a specific geographical area may not have their certificates updated.

[0051] When the group to which the first entity 12 directly belongs is defined as the first group, the groups connected to the first group, that is, the groups to which the first entity 12 is indirectly connected, become the second group. The second group may be a chain of multiple groups. The second group is connected to the second entity 14. Data that proves the connection between the first group and the second group (e.g., a signature value) corresponds to the second relationship certificate. Data that proves the connection between the second group and the second entity 14 corresponds to the third relationship certificate.

[0052] To belong to a group means to have the title (or role) of being a member of that group. For example, belonging to a group of mechanics means having the role of a mechanic. A certificate of relationship may be data that proves a connection to a group, or it may be a certificate of having a certain role, and may be rephrased as a certificate of role, etc. The term "group" in the above explanation may be replaced with the term "role" as appropriate. The concept of a role also includes the title.

[0053] Several exemplary embodiments are provided for the completeness of this disclosure and to fully convey its scope to those skilled in the art. Numerous specific details are provided, including examples of particular components, apparatus, and methods, to fully understand the embodiments of this disclosure. It will be apparent to those skilled in the art that the exemplary embodiments can be carried out in many different forms, and that none of the embodiments should be construed as limiting the scope of this disclosure. Some exemplary embodiments do not describe in detail well-known processes, well-known device structures, and well-known techniques.

[0054] The terms used herein are for illustrative purposes only and are not intended to limit any particular exemplary embodiment. In this specification, singular expressions are intended to include plural forms unless explicitly indicated in the context. The terms “equip,” “have,” “include,” and “have” are inclusive and thus identify the presence of the described features, integers, steps, operations, elements, and / or components, but do not exclude the addition of one or more other features, integers, steps, operations, elements, components, and / or sets thereof. The steps, processes, and operations of the methods described in this specification should not be construed as requiring a specific order unless specifically identified as such. It should also be understood that additional or alternative steps may be used.

[0055] When an element or layer is referred to as “on top of,” “connected to,” “linked to,” or “joined,” it may be directly on top of, connected to, or joined to another element or layer, and there may also be an intervening element or layer. In contrast, when an element is referred to as “directly on top of,” “directly connected to,” “directly linked to,” or “directly joined to” another element or layer, there is no intervening element or layer. Other words used to describe relationships between elements should be interpreted in a similar manner (e.g., “between” vs. “directly between,” “adjacent” vs. “directly adjacent,” etc.). As used in this specification, the term “and / or” includes any combination and all combinations relating to one or more of the enumerated items relating to the element.

[0056] Terms such as "first," "second," and "third" may be used in this specification to describe various elements, components, areas, layers, and / or partitions, but these elements, components, areas, layers, and / or partitions should not be limited by these terms. These terms may be used only to distinguish one element, component, area, layer, or partition from other elements, components, areas, layers, or partitions. As used herein, "first," "second," and other numerical terms do not imply order or sequence unless explicitly indicated by the context. Thus, a first "element, component, area, layer, or partition" may be referred to as a second "element, component, area, layer, or partition" without departing from the teaching of the exemplary embodiments.

[0057] In this disclosure, spatially relative terms such as “inside,” “outside,” “bottom,” “low,” “top,” and “high” may be used to describe the relationship between one element or feature and another, as shown in the figures, for the sake of clarity. Spatially relative terms may be intended to include different orientations of the device in use or operation, in addition to the orientation depicted in the figures. For example, if the device in the figures is upside down, an element described as “bottom” or “back” of another element or feature would face “top” of the other element or feature. Thus, the illustrative term “bottom” may include both up and down directions. The device may have other orientations (a 90-degree rotation or other orientations), and the spatially relative descriptors used herein may be interpreted accordingly.

[0058] The descriptions of one or more embodiments described above are provided for illustrative and explanatory purposes only. They are not intended to be exhaustive or to limit the disclosure. Individual elements and features of a particular embodiment are generally interchangeable and can be used in selected embodiments, even if not specifically illustrated or described, without limitation to that particular embodiment, if applicable. Furthermore, the elements and features described above may be modified in a variety of ways. Such modifications are not intended to be deviations from the disclosure, and all such modifications are intended to be within the scope of the disclosure.

[0059] <Additional Note> This specification includes the following methods and systems:

[0060] In one aspect of this disclosure, the method and system include a root certificate authority providing a first identity certificate. A first entity and a second entity store the first identity certificate and the second identity certificate, respectively. The root certificate authority generates a first relationship certificate between the first entity 12 and the second entity 14, or between the first entity 12 and a first group (or role). The first entity 12 stores the first relationship certificate. The first entity 12 transmits the first identity certificate and the first relationship certificate to the second entity 14 as a first communication. The second entity 14 verifies that the first identity certificate was created by the root certificate authority. The second entity 14 verifies that the first relationship certificate was created by the root certificate authority. Based on the verification of the first identity certificate and the first relationship certificate by the second entity 14, the second entity 14 or the first entity 12 enables a predetermined function.

[0061] In another aspect of this disclosure, the methods included in this disclosure include: a root certificate authority generating a first identity certificate; the first identity certificate generated by the root certificate authority being stored in a first entity 12; a second identity certificate generated by the root certificate authority being stored in a second entity 14; the root certificate authority generating a first relationship certificate between the first entity 12 and the second entity 14, or between the first entity 12 and a first group or role; the first entity 12 storing the first relationship certificate; and the first entity 12 transferring the second entity This includes sending a first identity certificate and a first relationship certificate to Titi 14 as a first communication; verifying in the second entity 14 that the first identity certificate was created by a root certificate authority; verifying in the second entity 14 that the first relationship certificate was created by a root certificate authority; communicating between the first entity 12 and the second entity 14 based on the verification of the first identity certificate and the first relationship certificate in the second entity 14; and enabling functionality in the first entity 12 and the second entity 14. [Explanation of Symbols]

[0062] 20 Root Certificate Authority, 12 First Entity 12, 14 Second Entity 14

Claims

1. The first identity certificate is provided by the root certification authority (20), A first entity (12) that stores the first identity certificate created by the root certificate authority, The system comprises a second entity (14) that stores a second identity certificate created by the aforementioned root certificate authority, The root certificate authority generates a first relationship certificate relating to the relationship between the first entity and the second entity, or the relationship between the first entity and the first group or role. The first entity stores the first relationship certificate, The first entity transmits the first identity certificate and the first relationship certificate to the second entity in the first communication. The second entity verifies that the first identity certificate was created by the root certificate authority, The second entity verifies that the first relationship certificate was created by the root certificate authority, A system in which, based on the verification of the first identity certificate and the first relationship certificate in the second entity, the second entity or the first entity is configured to activate a predetermined function.

2. The system according to claim 1, The aforementioned root certification authority possesses a root public value and a root secret value, The first entity has a first public value and a first secret value, The second entity has a second public value and a second secret value, The first entity transmits the first public value in the first request for creating the first identity certificate, The root certificate authority receives the first public value in the first request and creates the first identity certificate by signing the first public value using the root secret value. The root certificate authority returns the first identity certificate to the first entity. The second entity transmits the second public value in the second request for creating the second identity document, The root certificate authority receives the second public value in the second request and creates the second identity certificate by signing the second public value using the root secret value. The second entity is a system configured to store the second identity document.

3. The system according to claim 2, wherein the second entity transmits the second identity document to the first entity in a second communication.

4. The first entity encrypts the first communication with the second public value, The system according to claim 3, wherein the second entity decrypts the first communication with the second secret value.

5. The second entity performs the second communication by encrypting it with the first public value. The system according to claim 3, wherein the first entity decrypts the data received in the second communication using the first secret value.

6. The first entity described above is a mobile device, The system according to claim 1, wherein the second entity is a vehicle, a point-of-sale information management system, an electronic door lock, or a physical access device.

7. The system according to claim 1, wherein the first entity stores a second relationship certificate between the first group and one or more other entities or groups.

8. The system according to claim 1, wherein the first relationship certificate includes data relating to permission or restriction of use.

9. The system according to claim 8, wherein the data regarding the restrictions on use corresponds to data relating to at least one of the following items: geography, time, and purpose of use.

10. The system according to claim 1, wherein the first entity stores a second relationship certificate between the second entity and the first group or role.

11. The system according to claim 10, wherein the first group comprises a plurality of entities or roles and at least a second group or role.

12. The first entity described above is Store a second relationship certificate that proves the relationship between the first group or role and the second group or role, The system according to claim 11, which stores a third relationship certificate that proves the relationship between the second group or role and the second entity.

13. The aforementioned second entity is, Confirm that the first relationship certificate was signed by the root certificate authority, The system according to claim 1, which enables the function based on verification of the first relationship certificate.

14. The system according to claim 13, wherein the function includes at least one of unlocking a door, starting a vehicle, accessing a terminal, enabling or disabling a device, communicating with a third entity, modifying a record, and approving a transaction.

15. The root certificate authority generates the first identity certificate, The first entity stores the first identity certificate generated by the root certificate authority, The second entity stores the second identity certificate created by the aforementioned root certificate authority, The root certificate authority generates a first relationship certificate relating to the relationship between the first entity and the second entity, or the relationship between the first entity and the first group or role. The first entity stores the first relationship certificate, The first entity transmits the first identity certificate and the first relationship certificate to the second entity in the first communication, The second entity confirms that the first identity certificate was created by the root certificate authority, The second entity confirms that the first relationship certificate was created by the root certificate authority, Based on the fact that the second entity has verified the first identity certificate and the first relationship certificate, the first entity and the second entity perform communication, A method comprising enabling predetermined functions in the first entity and the second entity.

16. The aforementioned root certificate authority stores the root public value and the root secret value, The first entity stores a first public value and a first secret value, The second entity stores a second public value and a second secret value, The first entity transmits the first public value in a first request for creating the first identity certificate, The root certification authority receives the first public value in the first request and creates the first identity certificate by signing the first public value with the root secret value. The root certificate authority returns the first identity certificate to the first entity, The second entity transmits the second public value in a second request for creating the second identity document, The root certificate authority receives the second public value in the second request and creates the second identity certificate by signing the second public value using the root secret value, The method according to claim 15, wherein the second entity stores the second identity certificate.

17. The first entity described above is a mobile device, The method according to claim 15, wherein the second entity is a vehicle or a point-of-sale information management device.

18. The method according to claim 15, wherein the first group includes a plurality of entities.

19. The second entity confirms that the first relationship certificate was signed by the root certificate authority, The method according to claim 15, further comprising the second entity enabling the function based on the verification result of the first relationship certificate.

20. The method according to claim 19, wherein enabling the aforementioned function includes enabling at least one of the following: unlocking the doors, starting the vehicle, and approving the purchase.

Images