WO2020080510A1 - 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム - Google Patents
認証認可システム、情報処理装置、機器、認証認可方法及びプログラム Download PDFInfo
- Publication number
- WO2020080510A1 WO2020080510A1 PCT/JP2019/041048 JP2019041048W WO2020080510A1 WO 2020080510 A1 WO2020080510 A1 WO 2020080510A1 JP 2019041048 W JP2019041048 W JP 2019041048W WO 2020080510 A1 WO2020080510 A1 WO 2020080510A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- authentication
- authorization
- identifier
- devices
- extended identifier
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
- H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
- H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
Definitions
- the present invention relates to an authentication and authorization system, an information processing device, a device, an authentication and authorization method, and a program.
- IoT Internet of Things
- gateway devices gateway devices
- server devices on the cloud etc.
- authentication for confirming the validity of each other
- Authorization for allowing access to data, functions, etc. held by IoT devices has become important.
- authentication and authorization are performed independently of each other, and generally, authentication is first performed to confirm the validity of each other, and then the accessible data and functions as authorization information are confirmed.
- a smartphone operates an electric home appliance
- the authentication is performed between the smartphone and the electric home appliance to confirm each other's legitimacy, and after the mutual legitimacy is confirmed, the electric home appliance authorizes the smartphone to operate. To do. This allows home appliances to be operated with a smartphone.
- authentication and authorization are performed independently of each other, basically both authentication and authorization (hereinafter, authentication and authorization are collectively referred to as “authentication authorization”) are generally performed.
- authentication authorization both authentication and authorization (hereinafter, authentication and authorization are collectively referred to as “authentication authorization”) are generally performed.
- Target both authentication and authorization (hereinafter, authentication and authorization are collectively referred to as “authentication authorization”) are generally performed.
- authentication protocols for IoT devices for example, passwords, electronic certificates using PKI (Public Key Infrastructure), key sharing protocols with authentication using ID-based encryption, etc. are known.
- PKI Public Key Infrastructure
- key sharing protocols with authentication using ID-based encryption etc.
- a password is used as the authentication protocol, it is necessary to set a password for each IoT device, and it is preferable to change the password regularly. Therefore, when a large number of IoT devices are used, the operation is not possible. It can be difficult. Therefore, as an authentication protocol for IoT devices, a key sharing protocol with authentication using an electronic certificate using PKI or ID-based encryption is often used.
- the key sharing protocol is also called a key exchange protocol.
- the ID-based encryption is a public key encryption in which an identifier such as an ID represented by an arbitrary character string can be used as a public key.
- the public key can be, for example, the manufacturing number, the manufacturing code, or the serial number of the IoT device. Key sharing with authentication is also possible using this feature.
- the authentication key sharing protocol is generally shared by devices (eg, IoT devices and server devices) that want to perform key sharing for encrypted communication after mutual authentication, and when this authentication is successful. It is a protocol for generating a key.
- Examples of the key sharing protocol with authentication include M-Pin Full, which is a key sharing protocol with authentication using Pin (Personal identification number) input, and FSU (Fujioka-Suzuki-), which is a key sharing protocol with authentication based on pairing. Ustaoglu), Chen-Cheng-Smart, etc. are known.
- the master secret key is held by a key generation center (KGC: Key Generation Center, hereinafter also referred to as “KGC”), and the secret key of each device is generated from this master secret key. Authentication is done.
- KGC Key Generation Center
- the authorization protocol the OAUTH2 protocol and the like are known.
- the device acquires the access token from the authorization server and presents the access token to the access destination device, so that the device can use the data and functions held by the access destination device. At this time, the authenticity of the device is confirmed by some authentication, and the access token is issued after the authenticity is confirmed.
- an access token is described in an electronic certificate, and the electronic certificate (hereinafter, the electronic certificate in which the access token is described is referred to as an “authority certificate”).
- an electronic certificate using PKI Public Key Infrastructure
- the authorization can be realized by variously combining the authentication protocol and the authorization protocol.
- a narrow band wireless network is often used due to power consumption restrictions, etc., and the communication speed may be slow or communication may be unstable. For this reason, when performing authentication and authorization with an IoT device, it is desirable that the communication load (that is, the communication amount, the number of times of communication, etc.) is small.
- the present invention has been made in view of the above points, and an object thereof is to reduce the communication load associated with authentication and authorization.
- an embodiment of the present invention is directed to a plurality of devices, an extended identifier including an identifier for generating a secret key of the device and an identifier for identifying the device, and authorization information of the device, and the secret key.
- An authentication and authorization system including a server that distributes the device, wherein the server includes a holding unit that holds an identifier of the device and authorization information of the device, an identifier that identifies the device, and authorization information of the device.
- Each of the above devices succeeds in authenticating with the other device by the authenticating means for mutually authenticating with the other device by using the extended identifier and the secret key of the own device. did If, in accordance with authorization information contained in the extension identifier of the other device and characterized by having a authorization means for permitting a request to its own device from the other device.
- the communication load associated with authentication and authorization can be reduced.
- the authentication process and the authorization process are performed in the same process (in other words, the authorization process is also performed in the authentication process).
- the authentication authorization system 1 capable of reducing the communication load (communication amount, communication frequency, etc.) associated with the authentication authorization will be described.
- an identifier including information (for example, authorization information) used for authorization as an identifier of an authentication protocol using ID-based encryption (hereinafter, this identifier is referred to as “extended identifier”). .) Is used to realize authentication and authorization in the same process. Therefore, unlike the conventional KGC, the KGC according to the embodiment of the present invention (hereinafter, also referred to as “AuthID-KGC” (authentication authorization ID & key issuing center)) manages information used for authorization and an extended identifier. And means for distributing the extended identifier in addition to the private key.
- AuthID-KGC authentication authorization ID & key issuing center
- the device A and the device B authenticate and authorize
- the device A and the device B mutually confirm the legitimacy by using the private key corresponding to their own extension identifier.
- the device A and the device B respectively refer to the authorization information and the like included in the extended identifier of the other party and confirm whether the other party has the authorization.
- the secret key corresponding to the extended identifier is generated by AuthID-KGC and distributed in advance to each device. Therefore, in the embodiment of the present invention, it can be said that AuthID-KGC gives authorization to the device corresponding to the extended identifier by generating and distributing the private key using the extended identifier.
- each device can reduce the communication load for authorization (for example, the load that occurs in communication with the authorization server).
- FIG. 1 is a diagram showing an example of the overall configuration of an authentication and authorization system 1 according to an embodiment of the present invention.
- an authentication and authorization system 1 includes an authentication and authorization base 10 and one or more devices 20. Further, the authentication / authorization base 10 and each device 20 are communicably connected via a communication network N such as the Internet.
- the authentication and authorization base 10 is a computer or a computer system that functions as an AuthID-KGC.
- the authentication and authorization infrastructure 10 registers an extended identifier in the authentication and authorization infrastructure 10 in response to a request (a registration request for an extended identifier) from a manager of the device 20 (hereinafter, also referred to as “device administrator”), and A secret key is generated from this extended identifier, and the secret key is distributed to the device 20 corresponding to the extended identifier.
- the device administrator may make a registration request for the extended identifier using, for example, a terminal connected to the authentication and authorization base 10 via the communication network N, or by operating the authentication and authorization base 10 Registration request may be made.
- the device 20 is, for example, various IoT devices such as various sensor devices, embedded devices, wearable devices, digital home appliances, surveillance camera devices, lighting devices, medical devices, and industrial devices.
- the device 20 authenticates with another device 20 by an authentication protocol using ID-based encryption (that is, confirms the correctness), and performs authentication and authorization. At this time, the device 20 authenticates with another device 20 using the private key distributed from the authentication and authorization base 10.
- each of the plurality of devices 20 when each of the plurality of devices 20 is distinguished and represented, they are represented as “device 20A”, “device 20B”, and the like. Further, when the device 20 operates (including access) or uses the data or function of the other device 20, the other device 20 confirms the authorization of the device 20, so that the device 20 ( That is, the device 20 on the side that operates the data or uses the function is the “licensed device 20”, and the other device 20 (that is, the authorized device 20) is authorized and the device itself operates the data or The device 20) that permits the use is also referred to as “authorized device 20”. Note that, for example, two devices 20 may mutually operate or use data or functions, so that one device 20 may be the authorized device 20 and the authorized device 20.
- the device 20 is described as being an IoT device or the like having less hardware resources (for example, processor processing performance and memory amount) than a general PC (personal computer).
- the device 20 may be other than the IoT device.
- the device 20 may be a smartphone, a tablet terminal, or the like.
- the configuration of the authentication and authorization system 1 shown in FIG. 1 is an example, and other configurations may be used.
- the terminal used by the device administrator described above may be included in the authentication and authorization system 1.
- the device 20 performs authentication and authorization with any device or device other than the device 20 (for example, a gateway device or a server), the device or device is included in the authentication authorization system 1. May be.
- FIG. 2 is a diagram showing an example of the hardware configuration of the authentication and authorization base 10 in the embodiment of the present invention.
- the authentication and authorization base 10 includes an input device 11, a display device 12, a RAM (Random Access Memory) 13, a ROM (Read Only Memory) 14, and a processor 15. And an external I / F 16, a communication I / F 17, and an auxiliary storage device 18.
- an input device 11 a display device 12, a RAM (Random Access Memory) 13, a ROM (Read Only Memory) 14, and a processor 15.
- an external I / F 16 a communication I / F 17, and an auxiliary storage device 18.
- Each of these pieces of hardware is communicatively connected via a bus 19.
- the input device 11 is, for example, a keyboard, a mouse, a touch panel, etc., and is used by the user to input various operations.
- the display device 12 is, for example, a display or the like, and is used to display various processing results and the like to the user.
- the authentication and authorization base 10 may not include at least one of the input device 11 and the display device 12.
- RAM 13 is a volatile semiconductor memory that temporarily holds programs and data.
- the ROM 14 is a non-volatile semiconductor memory that can retain programs and data even when the power is turned off.
- the processor 15 is, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or the like, and is an arithmetic device that reads a program or data from the ROM 14, the auxiliary storage device 18, or the like onto the RAM 13 to execute processing. It should be noted that the authentication and authorization base 10 may have both the CPU and the GPU as the processor 15, or may have only one of the CPU and the GPU.
- the external I / F 16 is an interface with an external device.
- the external device includes the recording medium 16a and the like.
- Examples of the recording medium 16a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.
- the recording medium 16a may have recorded therein one or more programs or the like that realize the respective functions of the authentication and authorization base 10.
- the communication I / F 17 is an interface for connecting the authentication authorization base 10 to the communication network N.
- the authentication and authorization base 10 can perform data communication with the device 20 via the communication I / F 17.
- the auxiliary storage device 18 is a non-volatile storage device such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive).
- the auxiliary storage device 18 stores one or more programs and the like that implement each function of the authentication and authorization base 10.
- the authentication and authorization infrastructure 10 can realize various processes described later by having the hardware configuration shown in FIG.
- FIG. 2 shows the case where the authentication and authorization base 10 in the embodiment of the present invention is realized by one information processing device (computer), the present invention is not limited to this.
- the authentication and authorization base 10 in the embodiment of the present invention may be realized by a plurality of information processing devices (computers).
- FIG. 3 is a diagram showing an example of a hardware configuration of the device 20 according to the embodiment of the present invention.
- the device 20 includes a processor 21, a memory device 22, and a communication I / F 23.
- the respective pieces of hardware are communicatively connected via a bus 24.
- the processor 21 is, for example, an MPU (Micro Processing Unit), a CPU, or the like, and is an arithmetic device that reads a program or data from the memory device 22 and executes processing.
- MPU Micro Processing Unit
- CPU Central Processing Unit
- the memory device 22 is, for example, a RAM, a ROM, a flash memory, or the like, and stores various data and programs.
- the memory device 22 stores one or more programs and the like that implement each function of the device 20 according to the embodiment of the present invention.
- the communication I / F 23 is an interface for connecting the device 20 to the communication network N.
- the device 20 can perform data communication with the other device 20, the authentication and authorization base 10, and the like via the communication I / F 23.
- the device 20 according to the embodiment of the present invention can realize various processes described later by having the hardware configuration shown in FIG.
- FIG. 4 is a diagram showing an example of a functional configuration of the authentication and authorization system 1 in the embodiment of the present invention.
- the authentication and authorization infrastructure 10 includes a communication unit 101 and a registration processing unit 102. Each of these functional units is realized by a process that causes the processor 15 to execute one or more programs installed in the authentication and authorization base 10.
- the authentication / authorization base 10 has a storage unit 103.
- the storage unit 103 can be realized by using, for example, the auxiliary storage device 18 or the like.
- the storage unit 103 may be realized using a storage device or the like connected to the authentication and authorization base 10 via the communication network N.
- the communication unit 101 performs various communications with the device 20 and other devices (for example, terminals used by device managers).
- the registration processing unit 102 registers the extended identifier in the authentication and authorization base 10 and generates and distributes the private key, for example, in response to a request from the device administrator (request for registering the extended identifier).
- the extended identifier is information including an identifier of the device 20 and information used for authorization (for example, authorization information, etc.), as described later.
- the identifier of the device 20 is information for identifying the device 20, and is, for example, a manufacturing number, a manufacturing code, or a serial number of the device 20. Other than these, a telephone number, a mail address, or the like may be used as the identifier of the device 20. Further, as the identifier of the device 20, information that combines a manufacturing number, a manufacturing code, a serial number, a telephone number, an email address, etc. may be used.
- the storage unit 103 stores the extended identifier registered by the registration processing unit 102.
- the storage unit 103 may store, for example, a secret key corresponding to the extended identifier.
- the device 20 includes a communication unit 201 and an authentication / authorization processing unit 202. Each of these functional units is realized by a process that causes the processor 21 to execute one or more programs installed in the device 20.
- the device 20 has a storage unit 203.
- the storage unit 203 can be realized by using the memory device 22 or the like, for example.
- the communication unit 201 performs various communications with other devices 20, the authentication and authorization base 10, other devices, and the like.
- the authentication and authorization processing unit 202 mutually authenticates with another device 20 by using its own extended identifier, secret key, and the like, and refers to the extended identifier of the other party to obtain the authorization given to the other party. To confirm.
- the storage unit 203 stores its own private key, extended identifier, etc. distributed from the authentication and authorization infrastructure 10.
- the storage unit 203 also stores an extended identifier of the device 20 that is a partner of mutual authentication, various information necessary for mutual authentication, and the like.
- FIG. 5 is a diagram showing an example of extended identifier registration processing according to the embodiment of the present invention.
- the registration processing unit 102 receives a request for registration of an extended identifier from, for example, a device administrator (step S101).
- the device administrator may issue a request for registration of the extended identifier using a terminal connected to the authentication and authorization base 10 via the communication network N, or operate the authentication and authorization base 10.
- the extended identifier registration request may be made by.
- the device administrator when requesting registration of the extended identifier of the authorized device 20, the device administrator specifies the identifier of the authorized device 20 and the authorization information.
- the authorization information includes the identifier of the authorized device 20 and the operation authority for the authorized device 20 (that is, the authority of the operation permitted to the authorized device 20) and the like.
- the device administrator may specify the date (or the date and time) indicating the expiration date.
- the device administrator when requesting registration of the extended identifier of the authorized device 20, the device administrator specifies the identifier of the authorized device 20.
- the device administrator requests the registration of the extended identifier by designating at least the identifier of the device 20.
- a certain device 20 may be the authorized device 20 and the authorized device 20 at the same time.
- authorization information or the like is specified in the registration request for the extended identifier of the certain device 20.
- the registration processing unit 102 creates an extension identifier based on the extension identifier registration request received in step S101 described above, and stores the extension identifier in the storage unit 103 (step S102).
- FIG. 6 is a diagram showing an example of the configuration of the extended identifier.
- FIG. 6A is an extended identifier of the licensed device 20, and includes the identifier of the licensed device 20, the date, and the authorization information. Further, the authorization information includes the identifier of the authorized device 20. This extended identifier indicates that the access from the authorized device 20 to the authorized device 20 is permitted (authorized) when the mutual authentication between the authorized device 20 and the authorized device 20 is successful. Note that the date may be the expiration date of the authorization information, the generation date of the extended identifier, the expiration date of the extended identifier itself, or a combination thereof. good.
- the extended identifier of FIG. 6A is represented as, for example, “#A” as the identifier of the licensed device 20, “YYYYMMDD” as the date, and “# A_YYYYMMDD_ # B” when the identifier of the authorized device 20 is “#B”. be able to.
- FIG. 6B is an extended identifier of the licensed device 20, and includes the identifier of the licensed device 20, the date, and the authorization information.
- the authorization information includes the identifier of the authorized device 20 and the permission operation for the authorized device 20.
- this extended identifier is an operation (for example, a data operation) designated by the authorized device 20 to the authorized device 20 when the mutual authentication is successful. And the use of functions, etc.) are permitted (authorized).
- the date may be the expiration date of the authorization information, the generation date of the extended identifier, the expiration date of the extended identifier itself, or these dates, as in the above. It may be a combination.
- the extended identifier of FIG. 6B is, for example, the identifier “#A” of the licensed device 20, the date “YYYYMMDD”, the identifier of the authorized device 20 “#B”, and the permission operation “#OPEN” (for example, refer to a file. ), It can be expressed as “# A_YYYYMMDD_ # B_ # OPEN” or the like.
- FIG. 6C is an extended identifier of the authorized device 20, and is composed of the identifier of the authorized device 20 and the date.
- the date may be the generation date of the extended identifier, the expiration date of the extended identifier itself, or a combination thereof.
- the extended identifier in FIG. 6C can be represented as, for example, “#B” of the identifier of the authorized device 20 and “#B_YYYYMMDD” when the date is “YYYYMMDD”.
- the extended identifier (for example, FIGS. 6A and 6B) of the authorized device 20 is associated with the authorization information of the authorized device 20 with respect to the identifier of the authorized device 20. Accordingly, the authorized device 20 can authorize the authorized device 20 to operate the data or use the function by referring to the authorization information.
- the authorization information may include various information other than this. For example, if it is desired to explicitly specify a prohibited operation, function, or the like for the licensed device 20, a prohibited operation may be included.
- the authorization information may include, for example, revocation information indicating whether or not the authorization information is revoked.
- the registration processing unit 102 generates a private key from the extended identifier created in the above step S102 (step S103).
- the registration processing unit 102 distributes the extended identifier of the device 20 and the private key generated from the extended identifier to the device 20 (step S104).
- the extended identifier may be distributed (or disclosed) to all the devices 20, or the extended identifier of the licensed device 20 may be distributed (or disclosed) to the authorized device 20. .
- the extended identifier and the secret key distributed from the authentication and authorization infrastructure 10 are stored in the storage unit 203 of the device 20.
- the communication unit 101 may distribute it via the communication network N, or may distribute it via an external recording medium or the like. May be.
- the extended identifier including the identifier of the device 20 is registered in the authentication authorization base 10, and the extended identifier and the private key generated from the extended identifier are distributed to the device 20.
- FIG. 7 is a flowchart showing an example of authentication and authorization processing according to the embodiment of the present invention.
- the authorized device 20 is the “device 20A” and the authorized device 20 is the “device 20B” and the authentication and authorization process is performed between the devices 20A and 20B will be described.
- FSU is a key sharing protocol with authentication using ID-based encryption.
- ID A Extended identifier of device 20A
- ID B Extended identifier of device 20B D A
- 1 Private key of device 20A D B
- 2 Private key of device 20B
- k Security parameter p
- q Prime number satisfying p ⁇ q
- G 1 Elliptic curve on finite field
- G 2 Elliptic curve on k-th extension field of F p
- mutual authentication (mutual authentication using FSU) is performed between the device 20A and the device 20B (step S201). Details of the mutual authentication process using the FSU will be described later.
- the authentication authorization processing unit 202 of the device 20B determines that the extended identifier ID of the device 20A.
- the device 20A is authorized by referring to the authorization information included in A (step S202). That is, the authentication and authorization processing unit 202 of the device 20B permits a request (for example, a data operation request or a function execution request) from the device 20A according to the authorization information.
- the authentication and authorization processing unit 202 of the device 20B authorizes (permits) the device 20A to access itself when only the identifier of the device itself is specified in the authorization information.
- the authentication authorization processing unit 202 of the device 20B specifies its own identifier and the permitted operation in the authorization information, the operation indicated by the permitted operation (for example, data Approve (permit) operations and use of functions.
- the authentication authorization processing unit 202 of the device 20B refers to the date included in the extended identifier ID A to determine whether the authorization information is within the expiration date, and only when the authorization information is within the expiration date, the device 20A. May be authorized. Alternatively, when the authorization information of the extended identifier ID A includes prohibited operation, revocation information, etc., the authentication / authorization processing unit 202 of the device 20B refers to the information and authorizes (permits) other than the prohibited operation. Alternatively, it may be determined whether or not the authorization information has expired.
- the device 20A executes the operation authorized by the above step S202 (for example, the operation of the data or the use of the function) to the device 20B via the communication unit 201 (step S203). That is, the communication unit 201 of the device 20A transmits a data operation request, a function execution request, or the like to the device 20B according to the operation authorized in step S202 described above.
- step S204 when the mutual authentication in step S201 described above fails (that is, when the validity is not confirmed in at least one of the devices 20A and 20B), the authentication and authorization processing unit 202 of the device 20B, Access from the device 20B is denied (step S204).
- the authorized device 20 refers to the authorization information included in the extended identifier of the authorized device 20 to obtain the authorized device 20. It is possible to authorize a predetermined operation of the device 20 (for example, data operation, use of a function, etc.). Therefore, the authorized device 20 and the authorized device 20 do not need to perform communication for authorization (for example, communication to the authorization server), and the communication load can be reduced.
- a predetermined operation of the device 20 for example, data operation, use of a function, etc.
- FIG. 8 is a flowchart showing an example of mutual authentication processing according to the embodiment of the present invention.
- the secret keys D A, 1 and D B, 2 are generated by the authentication and authorization infrastructure 10. These secret keys D A, 1 and D B, 2 are generated by the registration processing unit 102 of the authentication and authorization infrastructure 10 calculating the following.
- the registration processing unit 102 of the authentication and authorization infrastructure 10 must multiply Q A, 1 and Q B, 2 by z.
- the private keys D A, 1 and D B, 2 are generated respectively.
- the registration processing unit 102 of the authentication authorization base 10 performs the calculation for generating the private key in parallel using the GPU instead of the CPU, thereby efficiently using the private key for a large number of extended identifiers. Can be generated. Further, in this case, since the GPU is generally cheaper than the CPU, the cost required for constructing the authentication authorization base 10 can be reduced.
- the short-term secret key x A and the short-term public keys X A, 1 and X A, 1 are stored in, for example, the storage unit 203 of the device 20A.
- the short-term secret key x B and the short-term public keys X B, 1 and X B, 1 are stored in, for example, the storage unit 203 of the device 20B.
- the communication unit 201 of the device 20A transmits the extended identifier ID A , the extended identifier ID B , the short-term public key X A, 1 and the short-term public key X A, 2 to the device 20B (step S303).
- the GROUPMEMBERSHIPTEST function is a function in which the elliptic curve E and the point P are designated as arguments, and is 1 when the point P is a point on the elliptic curve E, and is 0 otherwise.
- the authentication and authorization processing unit 202 of the device 20B calculates the shared values ⁇ 1 , ⁇ 2 , ⁇ 3 , and ⁇ 4 as follows (step S305).
- ⁇ 1 e (Q A, 1 , D B, 2 )
- ⁇ 2 e (Q A, 1 + X A, 1 , D B, 2 + x B Z 2 ).
- ⁇ 3 x B X A, 1
- ⁇ 4 x B X A, 2
- the communication unit 201 of the device 20B transmits the extended identifier ID A , the extended identifier ID B , the short-term public key X B, 1 and the short-term public key X B, 2 to the device 20A (step S306).
- step S307 if the GROUPMEMBERSHIPTEST function value is 0 or e (X B, 1 , g 2 ) ⁇ e (g 1 , X B, 2 ), the mutual authentication process is considered to have failed, and the process is performed. The process is ended or the process is restarted from step S301.
- the authentication authorization processing unit 202 of the device 20A calculates the shared values ⁇ 1 , ⁇ 2 , ⁇ 3 , ⁇ 4 by the following (step S308).
- ⁇ 1 e (D A, 1 , Q B, 2 )
- ⁇ 2 e (D A, 1 + x A Z 1 , Q B, 2 + X B, 2 )
- sid is a session ID.
- the authentication authorization processing unit 202 of the device B calculates the sid as follows (step S310), as in step S309 described above.
- the authentication authorization processing unit 202 of the device 20A generates the shared key K by the following (step S311).
- the shared key K is stored in the storage unit 203 of the device 20A, for example.
- the authentication and authorization processing unit 202 of the device 20B generates the shared key K by the following (step S312), as in step S311 described above.
- the shared key K is stored in, for example, the storage unit 203 of the device 20B.
- the shared key K is shared between the device 20A and the device 20B. Then, the device 20A and the device 20B perform mutual authentication with the shared key K (step S313).
- the device 20A can efficiently perform the processing required for mutual authentication.
- the device 20A is an IoT device or the like having less hardware resources than a general PC or the like, it is possible to more efficiently perform the process required for mutual authentication by calculating ⁇ 1 in advance. (That is, the processing load on the CPU can be reduced and the processing can be executed at high speed).
- ID A Extended identifier of device 20A
- ID B Extended identifier of device 20B
- A Secret key of device 20A
- D B Secret key of device 20B
- k Security parameter p
- q Prime number satisfying p ⁇ q
- G 1 Finite body F p on the elliptic curve
- E 1: E (F p ) in subgroup
- G 2 F p elliptic curve over k-th extension field of
- the secret keys D A and D B are generated by the authentication and authorization infrastructure 10. These secret keys D A and D B are generated by the registration processing unit 102 of the authentication and authorization infrastructure 10 by calculating the following.
- i A and i B may be generated by the authentication and authorization infrastructure 10 or the device 20. That is, for example, when the secret key D A is generated, i A may be generated by the authentication and authorization base 10, or i A may be generated by the device 20 A and disclosed to the authentication and authorization base 10. Similarly, for example, when generating the private key D B , i B may be generated by the authentication and authorization base 10 or i B may be generated by the device 20 B and disclosed to the authentication and authorization base 10.
- the calculation resource of the device 20 is limited, and a large amount of calculation resource is required to calculate H 1. In some cases, it is preferable to generate i A and i B with the authentication and authorization base 10.
- FIG. 9 is a flowchart showing a modification of the mutual authentication process according to the embodiment of the present invention.
- the authentication and authorization processing unit 202 of the device 20A randomly selects r A ⁇ Z q and then selects the short-term secret key.
- a short-term public key X A x A (z + i B ) g 1 (step S401).
- the short-term secret key x A and the short-term public key X A are stored in, for example, the storage unit 203 of the device 20A.
- the authentication and authorization processing unit 202 of the device 20B randomly selects r B ⁇ Z q and then selects the short-term secret key.
- the short-term public key X B x B (z + i A ) g 1 (step S402).
- the short-term secret key x B and the short-term public key X B are stored in, for example, the storage unit 203 of the device 20B.
- the communication unit 201 of the device 20A transmits the extension identifier ID A and short public key X A to the device 20B (step S403). At this time, the communication unit 201 of the device 20A may also transmit the extended identifier ID B to the device 20B.
- the communication unit 201 of the device 20B transmits the extended identifier ID B and the short-term public key X B to the device 20A (step S404). At this time, the communication unit 201 of the device 20B may also transmit the extended identifier ID A to the device 20A.
- the authentication authorization processing unit 202 of the apparatus 20A deletes the short-term private key x A generated in step S401 in the from the storage unit 203 (step S405). Similarly, the authentication and authorization processing unit 202 of the device 20B deletes the short-term secret key x B generated in the above step S402 from the storage unit 203 (step S406).
- the short-term secret key x A and the short-term secret key x B are deleted in the above steps S405 and S406, respectively, this is done until the extended identifier and the short-term public key are received from the other device 20. This is to prevent the short-term secret key from leaking. That is, for example, after the device 20A transmits the extended identifier ID A and the short-term public key X A to the device 20B, until the device 20A receives the extended identifier ID B and the short-term public key X B from the device 20B. It may take some time.
- the device 20A deletes the short-term secret key x A after transmitting the extended identifier ID A and the short-term public key X A to the device 20B. is doing.
- it is possible to operate without deleting the short-term secret keys x A and x B that is, it is possible to operate without executing steps S405 to S406 and steps S407 to S408 described later).
- the device 20A can execute subsequent steps S405, S407, S409, S411, S413, and S415 at the time when the device 20A receives the extended identifier ID B and the short-term public key X B from the device 20B. .
- the device 20B can execute subsequent steps S406, S408, S410, S412, S414, and S416.
- the authentication and authorization processing unit 202 of the device 20A uses the short-term secret key.
- the short-term secret key x A is stored in the storage unit 203 of the device 20A.
- the authentication and authorization processing unit 202 of the device 20B uses the short-term secret key.
- the short-term secret key x B is stored in the storage unit 203 of the device 20B.
- the authentication and authorization processing unit 202 of the device 20A generates public information d A and d B as follows (step S409).
- d A H 3 (X A , ID A , ID B )
- d B H 3 (X B , ID A , ID B )
- the authentication and authorization processing unit 202 of the device 20B generates public information d A and d B as follows (step S410).
- the public information d A and d B H 3 (X A , ID A , ID B )
- the public information d A and d B H 3 (X B , ID A , ID B )
- the public information d A and d B is generated by the device 20A and the device 20B, but it may be generated by the authentication and authorization base 10. It is easy to generate the public information d A and d B in each of the device 20A and the device 20B, but for example, the calculation resource of the device 20 is limited, and a large amount of calculation resource is required for the calculation of H 3. In some cases, it is preferable to generate public information d A and d B with the authentication and authorization infrastructure 10.
- the public information d A and d B may be generated at any timing after the short-term public keys X A and X B are generated and before the shared value ⁇ described later is generated.
- the authentication and authorization processing unit 202 of the device 20A calculates the shared value ⁇ by the following (step S411).
- the authentication and authorization processing unit 202 of the device 20B calculates the shared value ⁇ by the following (step S412).
- the authentication and authorization processing unit 202 of the device 20B calculates sid as follows (step S414).
- the authentication and authorization processing unit 202 of the device 20A generates the shared key K as follows (step S415).
- the shared key K is stored in the storage unit 203 of the device 20A, for example.
- the authentication and authorization processing unit 202 of the device 20B generates the shared key K by the following (step S416).
- the shared key K is stored in, for example, the storage unit 203 of the device 20B.
- the shared key K is shared between the device 20A and the device 20B. Then, the device 20A and the device 20B perform mutual authentication with the shared key K (step S417).
- the device 20A and the device 20B can communicate with each other. Authentication can be performed.
- the short-term public keys transmitted and received between the device 20A and the device 20B are only X A and X B , the device 20 A and the device 20 A It is possible to reduce the amount of communication with 20B. Further, since the number of pairing calculations in the devices 20A and 20B is one each, it is possible to reduce the calculation amount of the devices 20A and 20B. Therefore, even when the device 20 is an IoT device or the like, the process required for mutual authentication can be performed more efficiently.
- the authorized device 20 after performing the mutual authentication between the authorized device 20 and the authorized device 20, the authorized device 20 refers to the extended identifier of the authorized device 20. By doing so, the authorization from the authorized device 20 to the authorized device 20 can be performed. Therefore, according to the authentication and authorization system 1 in the embodiment of the present invention, the authorized device 20 and the authorized device 20 do not need to perform communication for authorization (for example, communication to the authorization server), and communication load Can be reduced.
- the device administrator can easily authorize the devices 20 by simply changing or updating the authorization information included in the extended identifier. Can be controlled.
- the authentication server and the authorization server are generally constructed separately, but in the authentication and authorization system 1 in the embodiment of the present invention, authentication and authorization are realized only by the authentication and authorization infrastructure 10. You can therefore, for example, the cooperation between the authentication server and the authorization server is not required, and the server required for the authentication and the authorization can be easily constructed. Therefore, for example, even in the case of constructing an environment in which a large number of devices 20 are used to experimentally try some processing, the environment can be easily used by using the authentication and authorization system 1 according to the embodiment of the present invention. Will also be able to build.
- the devices 20 are authorized to perform authentication, assuming that one is the authorized side and the other is the authorized side.
- the present invention is not limited to this, and the authorized side may be a server device, for example. And so on.
- Authentication Authorization System 10 Authentication Authorization Infrastructure 20 Equipment 101 Communication Unit 102 Registration Processing Unit 103 Storage Unit 201 Communication Unit 202 Authentication Authorization Processing Unit 203 Storage Unit N Communication Network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Algebra (AREA)
- Mathematical Analysis (AREA)
- Mathematical Optimization (AREA)
- Mathematical Physics (AREA)
- Pure & Applied Mathematics (AREA)
- Storage Device Security (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムであって、前記サーバは、前記機器の識別子及び前記機器の認可情報を保持する保持手段と、前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、前記生成手段により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手段と、を有し、前記複数の機器の各々は、自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手段と、前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、を有することを特徴する。
Description
本発明は、認証認可システム、情報処理装置、機器、認証認可方法及びプログラムに関する。
近年、IoT(Internet of Things)機器同士で通信を行ったり、IoT機器とゲートウェイ機器やクラウド上のサーバ装置等とが通信を行ったりする場合に、互いの正当性を確認するための認証と、IoT機器が保持するデータや機能等へのアクセスを許可するための認可とが重要になってきている。通常、認証及び認可はそれぞれ独立に行われ、一般的には、まず認証を行って互いの正当性を確認した後に、認可情報であるアクセス可能なデータや機能等を確認する。例えば、スマートフォンが家電を操作する場合、まずスマートフォンと家電との間で認証を行って互いの正当性を確認し、互いの正当性が確認された後に、家電はスマートフォンに対して操作権限を認可する。これにより、スマートフォンで家電が操作できるようになる。
このように、IoTの分野では、認証及び認可はそれぞれ独立に行うものの、基本的には認証及び認可(以降、認証及び認可をまとめて「認証認可」とも表す。)の両方を行うことが一般的である。
ここで、IoT機器を対象とする認証プロトコルとしては、例えば、パスワード、PKI(Public Key Infrastructure)を用いた電子証明書、IDベース暗号を用いた認証付き鍵共有プロトコル等が知られている。認証プロトコルとしてパスワードを用いた場合、各IoT機器に対してパスワードを設定する必要があり、また定期的にパスワードを変更することが好ましいため、IoT機器の数が膨大である場合にはその運用が困難となることがある。したがって、IoT機器を対象とする認証プロトコルとしては、PKIを用いた電子証明書やIDベース暗号を用いた認証付き鍵共有プロトコルが用いられる場合が多い。なお、鍵共有プロトコルは、鍵交換プロトコルとも呼ばれる。
ところで、IDベース暗号とは、任意の文字列で表されたID等の識別子を公開鍵とすることができる公開鍵暗号である。IoT機器でIDベース暗号を用いる場合には、例えば、IoT機器の製造番号や製造コード、シリアルナンバー等を公開鍵することができる。この特徴を用いて認証付き鍵共有も可能となる。
認証付き鍵共有プロトコルとは、一般に、暗号化通信のための鍵共有を行いたいデバイス(例えば、IoT機器やサーバ装置等)同士が互いに認証を行った上で、この認証に成功した場合に共有鍵を生成するプロトコルである。認証付き鍵共有プロトコルとしては、例えば、Pin(Personal identification number)入力を用いた認証付きの鍵共有プロトコルであるM-Pin Full、ペアリングベースの認証付き鍵共有プロトコルであるFSU(Fujioka-Suzuki-Ustaoglu)、Chen-Cheng-Smart等が知られている。認証付き鍵共有プロトコルでは、マスター秘密鍵を鍵生成センタ(KGC:Key Generation Center、以降、「KGC」とも表す。)が保持し、このマスター秘密鍵から各デバイスの秘密鍵が生成されることで認証が行われる。
一方で、認可プロトコルとしては、OAUTH2プロトコル等が知られている。OAUTH2プロトコルでは、デバイスは、認可サーバからアクセストークンを取得し、そのアクセストークンをアクセス先デバイスに提示することで、アクセス先デバイスが保持するデータや機能等を利用することができるようになる。このとき、何等かの認証によりデバイスの正当性確認を行い、この正当性が確認された後にアクセストークンが発行される。これ以外にも、PKIの枠組みで認可を実現する方法として、アクセストークンを電子証明書内に記載し、その電子証明書(以降、アクセストークンが記載された電子証明書を「権限証明書」と表す。)をアクセストークンとして用いる方法もある。IoT機器の認証プロトコルとしてPKI(Public Key Infrastructure)を用いた電子証明書が用いられる場合、この方法を用いることで、PKIのみで認証認可が可能となる。
以上のように、デバイス同士が認証認可を行う場合は、まず何等かの認証を行って互いの正当性を確認した後に、アクセス元のデバイスがアクセストークン又は権限証明書の発行を受けて、そのアクセストークン又は権限証明書をアクセス先のデバイスに提示することで実現される。したがって、認証認可は、認証プロトコルと認可プロトコルとを様々に組み合わせることで実現することができる。
小松文子, 日本電気(株), 「プライバシ保護のためのアーキテクチャ」, IPSJ Magazine Vol.48 No.7, pp.737-743, 2017.7
ここで、IoT機器は、消費電力の制約等から狭帯域の無線ネットワークが用いられることが多く、通信速度が遅かったり、通信が不安定であったりする場合がある。このため、IoT機器で認証認可を行う場合には、通信負荷(つまり、通信量や通信回数等)が少ないことが望ましい。
本発明は、上記の点に鑑みてなされたもので、認証認可に伴う通信負荷を削減することを目的とする。
上記目的を達成するため、本発明の実施の形態は、複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムであって、前記サーバは、前記機器の識別子及び前記機器の認可情報を保持する保持手段と、前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、前記生成手段により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手段と、を有し、前記複数の機器の各々は、自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手段と、前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、を有することを特徴する。
認証認可に伴う通信負荷を削減することができる。
以下、本発明の実施の形態について説明する。本発明の実施の形態では、IDベース暗号を用いた認証プロトコルによる認証を行う場合に、認証処理と認可処理とを同一の処理内で行う(言い換えれば、認証処理内で認可処理も行う)ことで、認証認可に伴う通信負荷(通信量や通信回数等)を削減することが可能な認証認可システム1について説明する。
ここで、本発明の実施の形態では、IDベース暗号を用いた認証プロトコルの識別子として、認可に用いる情報(例えば、認可情報等)を含む識別子(以降では、この識別子を「拡張識別子」と表す。)を用いることで、認証認可を同一の処理内で行うことを実現する。そのため、従来のKGCとは異なり、本発明の実施の形態におけるKGC(以降、「AuthID-KGC」(認証認可ID&鍵発行センタ)とも表す。)には、認可に用いる情報を管理し、拡張識別子を生成する手段と、秘密鍵の他に拡張識別子を配布する手段とが含まれる。
すなわち、例えば、機器Aと機器Bとで認証認可を行う場合、機器A及び機器Bはそれぞれ自身の拡張識別子に対応する秘密鍵を用いて相互に正当性を確認する。そして、相互に正当性が確認された場合、機器A及び機器Bはそれぞれ相手の拡張識別子に含まれる認可情報等を参照すること、相手に認可があるか否かを確認する。ここで、拡張識別子に対応する秘密鍵はAuthID-KGCにより生成され、各機器に予め配布される。したがって、本発明の実施の形態では、AuthID-KGCが拡張識別子を用いて秘密鍵を生成及び配布することで、当該拡張識別子に対応する機器に対して認可を与えている、ということができる。
このように、本発明の実施の形態では、IDベース暗号を用いた認証プロトコルによる相互認証を行った後、相手の拡張識別子を参照するだけで、相手の認可を確認することができる。このため、各機器は認可のための通信負荷(例えば、認可サーバとの通信に発生する負荷等)を削減することができる。
<全体構成>
まず、本発明の実施の形態における認証認可システム1の全体構成について、図1を参照しながら説明する。図1は、本発明の実施の形態における認証認可システム1の全体構成の一例を示す図である。
まず、本発明の実施の形態における認証認可システム1の全体構成について、図1を参照しながら説明する。図1は、本発明の実施の形態における認証認可システム1の全体構成の一例を示す図である。
図1に示すように、本発明の実施の形態における認証認可システム1には、認証認可基盤10と、1台以上の機器20とが含まれる。また、認証認可基盤10と、各機器20とは、例えばインターネット等の通信ネットワークNを介して通信可能に接続されている。
認証認可基盤10は、AuthID-KGCとして機能するコンピュータ又はコンピュータシステムである。認証認可基盤10は、例えば機器20の管理者(以降、「機器管理者」とも表す。)からの要求(拡張識別子の登録要求)に応じて、拡張識別子を認証認可基盤10に登録すると共に、この拡張識別子から秘密鍵を生成し、当該拡張識別子に対応する機器20に当該秘密鍵を配布する。なお、機器管理者は、例えば、認証認可基盤10と通信ネットワークNを介して接続される端末を用いて拡張識別子の登録要求を行っても良いし、認証認可基盤10を操作することで拡張識別子の登録要求を行っても良い。
機器20は、例えば、各種センサデバイスや組込み機器、ウェアラブルデバイス、デジタル家電、監視カメラ装置、照明機器、医療機器、産業用機器等の種々のIoT機器である。機器20は、他の機器20との間でIDベース暗号を用いた認証プロトコルにより認証(つまり、正当性の確認)を行って、認証認可を行う。このとき、機器20は、認証認可基盤10から配布された秘密鍵を用いて、他の機器20との間で認証を行う。
以降では、複数の機器20の各々を区別して表す場合は、「機器20A」、「機器20B」等と表す。また、機器20が他の機器20のデータや機能等を操作(アクセスも含む)又は利用する場合、当該他の機器20は当該機器20の認可を確認することから、以降では、当該機器20(つまり、データの操作や機能の利用を行う側の機器20)を「被認可機器20」、当該他の機器20(つまり、被認可機器20を認可して、自身がデータへの操作や機能の利用を許可する側の機器20)を「認可機器20」とも表す。なお、例えば、2台の機器20が相互にデータや機能等の操作又は利用することもあるため、1台の機器20が被認可機器20かつ認可機器20となることも有り得る。
なお、本発明の実施の形態における機器20は、一般的なPC(パーソナルコンピュータ)よりもハードウェア資源(例えば、プロセッサの処理性能やメモリ量等)が乏しいIoT機器等であるものとして説明するが、機器20はIoT機器以外であっても良い。例えば、機器20は、スマートフォンやタブレット端末等であっても良い。
なお、図1に示す認証認可システム1の構成は一例であって、他の構成であっても良い。例えば、上述した機器管理者が利用する端末が認証認可システム1に含まれていても良い。また、機器20が、機器20以外の何等かの機器又は装置(例えば、ゲートウェイ機器やサーバ等)との間で認証認可を行う場合には、当該機器又は装置が認証認可システム1に含まれていても良い。
<ハードウェア構成>
次に、本発明の実施の形態における認証認可基盤10及び機器20のハードウェア構成について説明する。
次に、本発明の実施の形態における認証認可基盤10及び機器20のハードウェア構成について説明する。
≪認証認可基盤10≫
以降では、本発明の実施の形態における認証認可基盤10のハードウェア構成について、図2を参照しながら説明する。図2は、本発明の実施の形態における認証認可基盤10のハードウェア構成の一例を示す図である。
以降では、本発明の実施の形態における認証認可基盤10のハードウェア構成について、図2を参照しながら説明する。図2は、本発明の実施の形態における認証認可基盤10のハードウェア構成の一例を示す図である。
図2に示すように、本発明の実施の形態における認証認可基盤10は、入力装置11と、表示装置12と、RAM(Random Access Memory)13と、ROM(Read Only Memory)14と、プロセッサ15と、外部I/F16と、通信I/F17と、補助記憶装置18とを有する。これら各ハードウェアは、それぞれがバス19を介して通信可能に接続されている。
入力装置11は、例えばキーボードやマウス、タッチパネル等であり、ユーザが各種操作を入力するのに用いられる。表示装置12は、例えばディスプレイ等であり、ユーザに対して各種処理結果等を表示するのに用いられる。なお、認証認可基盤10は、入力装置11及び表示装置12のうちの少なくとも一方を有していなくても良い。
RAM13は、プログラムやデータを一時保持する揮発性の半導体メモリである。ROM14は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。プロセッサ15は、例えばCPU(Central Processing Unit)やGPU(Graphics Processing Unit)等であり、ROM14や補助記憶装置18等からプログラムやデータをRAM13上に読み出して処理を実行する演算装置である。なお、認証認可基盤10は、プロセッサ15として、CPU及びGPUの両方を有していても良いし、CPU及びGPUのいずれか一方のみを有していても良い。
外部I/F16は、外部装置とのインタフェースである。外部装置には、記録媒体16a等がある。記録媒体16aとしては、例えば、CD(Compact Disc)、DVD(Digital Versatile Disk)、SDメモリカード(Secure Digital memory card)、USB(Universal Serial Bus)メモリカード等が挙げられる。記録媒体16aには、認証認可基盤10が有する各機能を実現する1以上のプログラム等が記録されていても良い。
通信I/F17は、認証認可基盤10を通信ネットワークNに接続するためのインタフェースである。認証認可基盤10は、通信I/F17を介して、機器20との間でデータ通信を行うことができる。
補助記憶装置18は、例えばHDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性の記憶装置である。補助記憶装置18には、認証認可基盤10が有する各機能を実現する1以上のプログラム等が記憶されている。
本発明の実施の形態における認証認可基盤10は、図2に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。なお、図2では、本発明の実施の形態における認証認可基盤10が1台の情報処理装置(コンピュータ)で実現されている場合を示したが、これに限られない。本発明の実施の形態における認証認可基盤10は、複数台の情報処理装置(コンピュータ)で実現されていても良い。
≪機器20≫
以降では、本発明の実施の形態における機器20のハードウェア構成について、図3を参照しながら説明する。図3は、本発明の実施の形態における機器20のハードウェア構成の一例を示す図である。
以降では、本発明の実施の形態における機器20のハードウェア構成について、図3を参照しながら説明する。図3は、本発明の実施の形態における機器20のハードウェア構成の一例を示す図である。
図3に示すように、本発明の実施の形態における機器20は、プロセッサ21と、メモリ装置22と、通信I/F23とを有する。これら各ハードウェアは、それぞれがバス24を介して通信可能に接続されている。
プロセッサ21は、例えばMPU(Micro Processing Unit)やCPU等であり、メモリ装置22からプログラムやデータを読み出して処理を実行する演算装置である。
メモリ装置22は、例えばRAMやROM、フラッシュメモリ等であり、各種データやプログラム等を記憶する。メモリ装置22には、本発明の実施の形態における機器20が有する各機能を実現する1以上のプログラム等が記憶されている。
通信I/F23は、機器20を通信ネットワークNに接続するためのインタフェースである。機器20は、通信I/F23を介して、他の機器20や認証認可基盤10等との間でデータ通信を行うことができる。
本発明の実施の形態における機器20は、図3に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。
<機能構成>
次に、本発明の実施の形態における認証認可システム1の機能構成について、図4を参照しながら説明する。図4は、本発明の実施の形態における認証認可システム1の機能構成の一例を示す図である。
次に、本発明の実施の形態における認証認可システム1の機能構成について、図4を参照しながら説明する。図4は、本発明の実施の形態における認証認可システム1の機能構成の一例を示す図である。
≪認証認可基盤10≫
図4に示すように、本発明の実施の形態における認証認可基盤10は、通信部101と、登録処理部102とを有する。これら各機能部は、認証認可基盤10にインストールされた1以上のプログラムがプロセッサ15に実行させる処理により実現される。
図4に示すように、本発明の実施の形態における認証認可基盤10は、通信部101と、登録処理部102とを有する。これら各機能部は、認証認可基盤10にインストールされた1以上のプログラムがプロセッサ15に実行させる処理により実現される。
また、本発明の実施の形態における認証認可基盤10は、記憶部103を有する。記憶部103は、例えば補助記憶装置18等を用いて実現可能である。なお、記憶部103は、認証認可基盤10と通信ネットワークNを介して接続される記憶装置等を用いて実現されていても良い。
通信部101は、機器20や他の装置(例えば、機器管理者が利用する端末等)等との間で各種通信を行う。登録処理部102は、例えば機器管理者からの要求(拡張識別子の登録要求)に応じて、拡張識別子を認証認可基盤10に登録すると共に、秘密鍵の生成及び配布を行う。
ここで、拡張識別子とは、後述するように、機器20の識別子と、認可に用いられる情報(例えば、認可情報等)とが含まれる情報である。また、機器20の識別子とは、当該機器20を識別する情報のことであり、例えば、機器20の製造番号、製造コード、シリアルナンバー等である。これら以外にも、機器20の識別子として、電話番号やメールアドレス等が用いられも良い。また、機器20の識別子として、製造番号や製造コード、シリアルナンバー、電話番号、メールアドレス等を組み合わせた情報が用いられても良い。
記憶部103は、登録処理部102によって登録された拡張識別子が記憶される。なお、記憶部103には、拡張識別子以外にも、例えば、当該拡張識別子に対応する秘密鍵等が記憶されていても良い。
≪機器20≫
図4に示すように、本発明の実施の形態における機器20は、通信部201と、認証認可処理部202とを有する。これら各機能部は、機器20にインストールされた1以上のプログラムがプロセッサ21に実行させる処理により実現される。
図4に示すように、本発明の実施の形態における機器20は、通信部201と、認証認可処理部202とを有する。これら各機能部は、機器20にインストールされた1以上のプログラムがプロセッサ21に実行させる処理により実現される。
また、本発明の実施の形態における機器20は、記憶部203を有する。記憶部203は、例えばメモリ装置22等を用いて実現可能である。
通信部201は、他の機器20や認証認可基盤10、他の装置等との間で各種通信を行う。認証認可処理部202は、自身の拡張識別子や秘密鍵等を用いて、他の機器20との間で相互に認証を行うと共に、相手の拡張識別子を参照することで、相手に与えられた認可を確認する。
記憶部203は、認証認可基盤10から配布された自身の秘密鍵や拡張識別子等を記憶する。また、記憶部203は、相互認証の相手の機器20の拡張識別子や相互認証に必要な各種情報等も記憶する。
<処理の詳細>
次に、本発明の実施の形態における認証認可システム1の処理の詳細について説明する。
次に、本発明の実施の形態における認証認可システム1の処理の詳細について説明する。
≪拡張識別子の登録処理≫
以降では、認証認可基盤10に拡張識別子を登録する処理(拡張識別子の登録処理)について、図5を参照しながら説明する。図5は、本発明の実施の形態における拡張識別子の登録処理の一例を示す図である。
以降では、認証認可基盤10に拡張識別子を登録する処理(拡張識別子の登録処理)について、図5を参照しながら説明する。図5は、本発明の実施の形態における拡張識別子の登録処理の一例を示す図である。
まず、登録処理部102は、例えば機器管理者からの拡張識別子の登録要求を受け付ける(ステップS101)。上述したように、機器管理者は、例えば、認証認可基盤10と通信ネットワークNを介して接続される端末を用いて拡張識別子の登録要求を行っても良いし、認証認可基盤10を操作することで拡張識別子の登録要求を行っても良い。
ここで、被認可機器20の拡張識別子の登録要求を行う場合、機器管理者は、当該被認可機器20の識別子と、認可情報とを指定する。認可情報としては、認可機器20の識別子や当該認可機器20に対する操作権限(つまり、被認可機器20に許可する操作等の権限)等が含まれる。更に、認可情報に有効期限を設ける場合等には、機器管理者は、当該有効期限を示す日付(又は日時)を指定しても良い。
一方で、認可機器20の拡張識別子の登録要求を行う場合、機器管理者は、当該認可機器20の識別子を指定する。
このように、機器管理者は、少なくとも機器20の識別子を指定することで、拡張識別子の登録要求を行う。なお、或る機器20が被認可機器20であると同時に認可機器20である場合も有り得る。この場合は、当該或る機器20の拡張識別子の登録要求には、認可情報等が指定される。
次に、登録処理部102は、上記のステップS101で受け付けた拡張識別子の登録要求に基づいて、拡張識別子を作成し、記憶部103に保存する(ステップS102)。
ここで、拡張識別子の構成の一例について、図6を参照しながら説明する。図6は、拡張識別子の構成の一例を示す図である。
図6Aは、被認可機器20の拡張識別子であり、当該被認可機器20の識別子と、日付と、認可情報とで構成されている。また、認可情報には、認可機器20の識別子が含まれている。この拡張識別子は、被認可機器20と認可機器20とで相互認証が成功した場合に、被認可機器20から認可機器20へのアクセスが許可(認可)されることを示している。なお、日付は、認可情報の有効期限であっても良いし、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図6Aの拡張識別子は、例えば、被認可機器20の識別子の「#A」、日付を「YYYYMMDD」、認可機器20の識別子を「#B」とした場合、「#A_YYYYMMDD_#B」等と表すことができる。
図6Bは、被認可機器20の拡張識別子であり、当該被認可機器20の識別子と、日付と、認可情報とで構成されている。また、認可情報には、認可機器20の識別子と、当該認可機器20への許可動作とが含まれている。この拡張識別子は、被認可機器20と認可機器20とで相互認証が成功した場合に、被認可機器20から認可機器20に対して、当該許可動作に指定されている動作(例えば、データの操作や機能の利用等)が許可(認可)されることを示している。なお、日付は、上記と同様に、認可情報の有効期限であっても良いし、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図6Bの拡張識別子は、例えば、被認可機器20の識別子の「#A」、日付を「YYYYMMDD」、認可機器20の識別子を「#B」、許可動作を「#OPEN」(例えば、ファイル参照)とした場合、「#A_YYYYMMDD_#B_#OPEN」等と表すことができる。
図6Cは、認可機器20の拡張識別子であり、当該認可機器20の識別子と、日付とで構成されている。なお、日付は、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図6Cの拡張識別子は、例えば、認可機器20の識別子の「#B」、日付を「YYYYMMDD」とした場合、「#B_YYYYMMDD」等と表すことができる。
このように、被認可機器20の拡張識別子(例えば図6Aや図6B)には、当該被認可機器20の識別子に対して、当該被認可機器20の認可情報が対応付けられている。これにより、認可機器20は、この認可情報を参照することで、被認可機器20に対してデータの操作や機能の利用等の認可することができるようになる。なお、上記の図6Bでは、一例として、拡張識別子の認可情報に許可動作が含まれる場合を示したが、認可情報には、これ以外にも、種々の情報が含まれていても良い。例えば、被認可機器20に対して禁止する操作や機能等を明示的に指定したい場合には、禁止動作が含まれていても良い。また、認可情報には、例えば、当該認可情報が失効しているか否かを示す失効情報が含まれていても良い。
次に、登録処理部102は、上記のステップS102で作成した拡張識別子から秘密鍵を生成する(ステップS103)。
最後に、登録処理部102は、機器20に対して、当該機器20の拡張識別子と、当該拡張識別子から生成された秘密鍵とを配布する(ステップS104)。このとき、拡張識別子は全ての機器20に対して配布(又は公開)されても良いし、被認可機器20の拡張識別子が認可機器20に対して配布(又は公開)されるようにしても良い。
これにより、当該機器20の記憶部203には、認証認可基盤10から配布された拡張識別子及び秘密鍵が保存される。なお、認証認可基盤10から機器20へ拡張識別子及び秘密鍵を配布する方法としては、例えば、通信部101により通信ネットワークNを介して配布されても良いし、外部記録媒体等を介して配布されても良い。
以上のように、機器20の識別子が含まれる拡張識別子が認証認可基盤10に登録され、当該機器20に対して、当該拡張識別子と、当該拡張識別子から生成された秘密鍵とが配布される。
≪認証認可処理≫
以降では、機器20同士で認証及び認可を行う処理(認証認可処理)について、図7を参照しながら説明する。図7は、本発明の実施の形態における認証認可処理の一例を示すフローチャートである。
以降では、機器20同士で認証及び認可を行う処理(認証認可処理)について、図7を参照しながら説明する。図7は、本発明の実施の形態における認証認可処理の一例を示すフローチャートである。
図7に示す認証認可処理では、一例として、被認可機器20を「機器20A」、認可機器20を「機器20B」として、機器20Aと機器20Bとの間で認証認可処理を行う場合について説明する。また、一例として、IDベース暗号を用いた認証付き鍵共有プロトコルであるFSUを用いて、機器20Aと機器20Bとの間の相互認証を行うものとする。
(記号の定義)
以降で用いる記号を次のように定義する。
以降で用いる記号を次のように定義する。
IDA:機器20Aの拡張識別子
IDB:機器20Bの拡張識別子
DA,1:機器20Aの秘密鍵
DB,2:機器20Bの秘密鍵
k:セキュリティパラメータ
p,q:p≠qを満たす素数
G1:有限体Fp上の楕円曲線E1:=E(Fp)における部分群
G2:Fpのk次拡大体上の楕円曲線
IDB:機器20Bの拡張識別子
DA,1:機器20Aの秘密鍵
DB,2:機器20Bの秘密鍵
k:セキュリティパラメータ
p,q:p≠qを満たす素数
G1:有限体Fp上の楕円曲線E1:=E(Fp)における部分群
G2:Fpのk次拡大体上の楕円曲線
g1:G1の生成元
g2:G2の生成元
Zq:qを法とする剰余類
z∈Zq:マスター秘密鍵
Zv=zgv∈Gv(v=1,2):マスター公開鍵
H1:文字列(すなわち、オクテット列)からG1上の元を生成する関数
H2:文字列からG2上の元を生成する関数
H:鍵導出関数
e:BN(Barret-Naehrig)曲線上のOptimal Ateペアリング
なお、BN曲線上のOptimal Ateペアリングについては、例えば、以下の参考文献1を参照されたい。
[参考文献1]
K. Kasamatsu, S. Kanno, T. Kobayashi and Y. Kawahara: Optimal Ate Pairing draft-kasamatsu-optimal-ate-pairings-00. Network Working Group Internet-Draft: to apper.
ここで、上記で定義した各記号のうち、マスター秘密鍵z、秘密鍵DA,1及びDB,2以外は公開情報であるものとする。
K. Kasamatsu, S. Kanno, T. Kobayashi and Y. Kawahara: Optimal Ate Pairing draft-kasamatsu-optimal-ate-pairings-00. Network Working Group Internet-Draft: to apper.
ここで、上記で定義した各記号のうち、マスター秘密鍵z、秘密鍵DA,1及びDB,2以外は公開情報であるものとする。
まず、機器20Aと機器20Bとの間で相互認証(FSUを用いた相互認証)を行う(ステップS201)。FSUを用いた相互認証の処理の詳細については後述する。
上記のステップS201での相互認証が成功した場合(すなわち、機器20Aと機器20Bとの間で互いに正当性が確認された場合)、機器20Bの認証認可処理部202は、機器20Aの拡張識別子IDAに含まれる認可情報を参照して、当該機器20Aを認可する(ステップS202)。すなわち、機器20Bの認証認可処理部202は、当該認可情報に応じて、当該機器20Aからの要求(例えば、データの操作要求や機能の実行要求等)を許可する。例えば、機器20Bの認証認可処理部202は、自身の識別子のみが当該認可情報に指定されている場合、機器20Aに対して、自身へのアクセスを認可(許可)する。また、例えば、機器20Bの認証認可処理部202は、自身の識別子と、許可動作とが当該認可情報に指定されている場合、機器20Aに対して、当該許可動作が示す動作(例えば、データの操作や機能の利用等)を認可(許可)する。
なお、機器20Bの認証認可処理部202は、拡張識別子IDAに含まれる日付を参照して、認可情報が有効期限内であるか否かを判定し、有効期限内である場合にのみ機器20Aを認可しても良い。又は、機器20Bの認証認可処理部202は、拡張識別子IDAの認可情報に禁止動作や失効情報等が含まれる場合には、これらの情報を参照して、禁止動作以外を認可(許可)したり、認可情報が失効しているか否かを判定したりしても良い。
次に、機器20Aは、通信部201を介して、上記のステップS202で認可された動作(例えば、データの操作や機能の利用等)を機器20Bに対して実行する(ステップS203)。すなわち、機器20Aの通信部201は、上記のステップS202で認可された動作に応じて、データの操作要求や機能実行要求等を機器20Bに送信する。
一方で、上記のステップS201での相互認証が失敗した場合(すなわち、機器20A及び機器20Bの少なくとも一方の機器20で正当性が確認されなかった場合)、機器20Bの認証認可処理部202は、機器20Bからのアクセスを拒否する(ステップS204)。
以上のように、認可機器20と被認可機器20との間で相互認証が成功した場合、認可機器20は、被認可機器20の拡張識別子に含まれる認可情報を参照することで、この被認可機器20の所定の動作(例えば、データの操作や機能の利用等)を認可することができる。このため、認可機器20及び被認可機器20は認可のための通信(例えば、認可サーバへの通信等)を行う必要がなくなり、通信負荷を削減することができる。
≪相互認証処理(FSU)≫
次に、上記のステップS201の相互認証処理の詳細について、図8を参照しながら説明する。図8は、本発明の実施の形態における相互認証処理の一例を示すフローチャートである。
次に、上記のステップS201の相互認証処理の詳細について、図8を参照しながら説明する。図8は、本発明の実施の形態における相互認証処理の一例を示すフローチャートである。
ここで、上述したように、秘密鍵DA,1及びDB,2は認証認可基盤10により生成される。これらの秘密鍵DA,1及びDB,2は、認証認可基盤10の登録処理部102が以下を計算することにより生成される。
DA,1=zQA,1=zH1(IDA)∈G1
DB,2=zQB,2=zH2(IDB)∈G2
また、QA,1=H1(IDA)及びQB,2=H2(IDB)は、認証認可基盤10から機器20A及び機器20Bに配布(又は公開)されているものとする。ただし、QA,1=H1(IDA)及びQB,2=H2(IDB)は、機器20A及び機器20Bでそれぞれ計算されても良い。
DB,2=zQB,2=zH2(IDB)∈G2
また、QA,1=H1(IDA)及びQB,2=H2(IDB)は、認証認可基盤10から機器20A及び機器20Bに配布(又は公開)されているものとする。ただし、QA,1=H1(IDA)及びQB,2=H2(IDB)は、機器20A及び機器20Bでそれぞれ計算されても良い。
なお、上記の秘密鍵DA,1及びDB,2の計算方法に示されるように、認証認可基盤10の登録処理部102は、QA,1及びQB,2をそれぞれz倍することで秘密鍵DA,1及びDB,2をそれぞれ生成している。このため、認証認可基盤10の登録処理部102は、秘密鍵を生成するための計算を、CPUの代わりにGPUを用いて並列実行することで、多数の拡張識別子に対して秘密鍵を効率的に生成することができる。また、この場合、一般にGPUはCPUに比べて安価であることが多いため、認証認可基盤10の構築に要するコストも削減することができるようになる。
機器20Aの認証認可処理部202は、短期秘密鍵xA∈Zqをランダムに選択した上で、短期公開鍵XA,1=xAg1と短期公開鍵XA,2=xAg2とを計算する(ステップS301)。これにより、短期秘密鍵xAと、短期公開鍵XA,1及びXA,1とが生成される。なお、短期秘密鍵xAと、短期公開鍵XA,1及びXA,1とは、例えば、機器20Aの記憶部203に記憶される。
機器20Bの認証認可処理部202は、短期秘密鍵xB∈Zqをランダムに選択した上で、短期公開鍵XB,1=xBg1と短期公開鍵XB,2=xBg2とを計算する(ステップS302)。これにより、短期秘密鍵xBと、短期公開鍵XB,1及びXB,1とが生成される。なお、短期秘密鍵xBと、短期公開鍵XB,1及びXB,1とは、例えば、機器20Bの記憶部203に記憶される。
機器20Aの通信部201は、拡張識別子IDAと、拡張識別子IDBと、短期公開鍵XA,1と、短期公開鍵XA,2とを機器20Bに送信する(ステップS303)。
機器20Bの認証認可処理部202は、楕円曲線E1及びXA,2に関するGROUPMEMBERSHIPTEST関数値と、楕円曲線E2及びXA,1に関するGROUPMEMBERSHIPTEST関数値とが共に1であり、かつ、e(XA,1,g2)=e(g1,XA,2)であるか否かを確認する(ステップS304)。ここで、GROUPMEMBERSHIPTEST関数は、引数として楕円曲線Eと点Pとが指定される関数であり、点Pが楕円曲線E上の点である場合に1、そうでない場合に0となる関数である。
なお、上記のステップS304において、GROUPMEMBERSHIPTEST関数値が0又はe(XA,1,g2)≠e(g1,XA,2)である場合、相互認証処理が失敗したものとして、処理を終了するか又は上記のステップS301からやり直す。以降では、上記のステップS304において、GROUPMEMBERSHIPTEST関数値が共に1で、かつ、e(XA,1,g2)=e(g1,XA,2)であると確認されたものとする。
機器20Bの認証認可処理部202は、以下により共有値σ1,σ2,σ3,σ4を計算する(ステップS305)。
σ1=e(QA,1,DB,2)
σ2=e(QA,1+XA,1,DB,2+xBZ2)
σ3=xBXA,1
σ4=xBXA,2
次に、機器20Bの通信部201は、拡張識別子IDAと、拡張識別子IDBと、短期公開鍵XB,1と、短期公開鍵XB,2とを機器20Aに送信する(ステップS306)。
σ2=e(QA,1+XA,1,DB,2+xBZ2)
σ3=xBXA,1
σ4=xBXA,2
次に、機器20Bの通信部201は、拡張識別子IDAと、拡張識別子IDBと、短期公開鍵XB,1と、短期公開鍵XB,2とを機器20Aに送信する(ステップS306)。
機器20Aの認証認可処理部202は、楕円曲線E1及びXB,2に関するGROUPMEMBERSHIPTEST関数値と、楕円曲線E2及びXB,1に関するGROUPMEMBERSHIPTEST関数値とが共に1であり、かつ、e(XB,1,g2)=e(g1,XB,2)であるか否かを確認する(ステップS307)。
なお、上記のステップS307において、GROUPMEMBERSHIPTEST関数値が0又はe(XB,1,g2)≠e(g1,XB,2)である場合、相互認証処理が失敗したものとして、処理を終了するか又は上記のステップS301からやり直す。以降では、上記のステップS307において、GROUPMEMBERSHIPTEST関数値が共に1で、かつ、e(XB,1,g2)=e(g1,XB,2)であると確認されたものとする。
機器20Aの認証認可処理部202は、以下により共有値σ1,σ2,σ3,σ4を計算する(ステップS308)。
機器20Aの認証認可処理部202は、以下により共有値σ1,σ2,σ3,σ4を計算する(ステップS308)。
σ1=e(DA,1,QB,2)
σ2=e(DA,1+xAZ1,QB,2+XB,2)
σ3=xAXB,1
σ4=xAXB,2
次に、機器20Aの認証認可処理部202は、以下によりsidを計算する(ステップS309)。なお、sidはセッションIDである。
σ2=e(DA,1+xAZ1,QB,2+XB,2)
σ3=xAXB,1
σ4=xAXB,2
次に、機器20Aの認証認可処理部202は、以下によりsidを計算する(ステップS309)。なお、sidはセッションIDである。
また、機器20Bの認証認可処理部202は、上記のステップS311と同様に、以下により共有鍵Kを生成する(ステップS312)。
これにより、機器20Aと機器20Bとの間で共有鍵Kが共有される。そして、機器20Aと機器20Bとは、この共有鍵Kにより相互認証を行う(ステップS313)。
以上のように、FSUを用いて、機器20Aと機器20Bとの間で相互認証を行うことができる。ここで、上記のステップS308で機器20Aが計算するσ1に着目すると、σ1=e(DA,1,QB,2)となっている。このため、機器20Aが接続する接続先のQB,2(=H2(IDB))が固定的な場合には、このσ1を一度計算した上で、その計算結果を記憶部203等に保持しておくことで、次回の計算ではσ1の計算を省略することができる。また、QB,2自体は公開情報であるため、QB,2が一定の規則で生成される場合は当該QB,2を事前に計算した上で、σ1も事前に計算しておくことも可能である。
これにより、機器20Aは、相互認証に要する処理を効率的に行うことができるようになる。特に、機器20Aは、一般的なPC等よりもハードウェア資源が乏しいIoT機器等であるため、σ1を事前に計算しておくこと等により、相互認証に要する処理をより効率的に行うことができる(つまり、CPUの処理負荷を少なくすることができると共に、高速に実行することができる)ようになる。
<相互認証処理の変形例>
以降では、図7のステップS201の相互認証処理の変形例として、機器20間の通信量がより少なくなり、かつ、各機器20での計算量がより少なくなるようにFSUを改良したプロトコルによって相互認証処理を行う場合について説明する。
以降では、図7のステップS201の相互認証処理の変形例として、機器20間の通信量がより少なくなり、かつ、各機器20での計算量がより少なくなるようにFSUを改良したプロトコルによって相互認証処理を行う場合について説明する。
(記号の定義)
まず、本変形例で用いる記号を次のように定義する。
まず、本変形例で用いる記号を次のように定義する。
IDA:機器20Aの拡張識別子
IDB:機器20Bの拡張識別子
DA:機器20Aの秘密鍵
DB:機器20Bの秘密鍵
k:セキュリティパラメータ
p,q:p≠qを満たす素数
G1:有限体Fp上の楕円曲線E1:=E(Fp)における部分群
G2:Fpのk次拡大体上の楕円曲線
IDB:機器20Bの拡張識別子
DA:機器20Aの秘密鍵
DB:機器20Bの秘密鍵
k:セキュリティパラメータ
p,q:p≠qを満たす素数
G1:有限体Fp上の楕円曲線E1:=E(Fp)における部分群
G2:Fpのk次拡大体上の楕円曲線
g1:G1の生成元
g2:G2の生成元
Zq:qを法とする剰余類
z∈Zq:マスター秘密鍵
Z=zg1∈G1:マスター公開鍵
H1:文字列(すなわち、オクテット列)からZq上の元を生成する関数
H2:文字列からZq上の元を生成する関数
H3:文字列からZq上の元を生成する関数
H:鍵導出関数
K:共有鍵
e:G1×G2上で定義されたペアリング演算
ここで、上記で定義した各記号のうち、マスター秘密鍵z、秘密鍵DA及びDB以外は公開情報であるものとする。なお、G1とG2とは逆であっても良い。また、群の元やZqの元を関数に入力する場合には、当該元を表す文字列を関数に入力するものとする。
また、上述したように、秘密鍵DA及びDBは認証認可基盤10により生成される。これらの秘密鍵DA及びDBは、認証認可基盤10の登録処理部102が以下を計算することにより生成される。
≪相互認証処理の変形例≫
次に、図7のステップS201の相互認証処理の変形例について、図9を参照しながら説明する。図9は、本発明の実施の形態における相互認証処理の変形例を示すフローチャートである。
次に、図7のステップS201の相互認証処理の変形例について、図9を参照しながら説明する。図9は、本発明の実施の形態における相互認証処理の変形例を示すフローチャートである。
機器20Aの認証認可処理部202は、rA∈Zqをランダムに選択した上で、短期秘密鍵
同様に、機器20Bの認証認可処理部202は、rB∈Zqをランダムに選択した上で、短期秘密鍵
次に、機器20Aの通信部201は、拡張識別子IDAと短期公開鍵XAとを機器20Bに送信する(ステップS403)。なお、このとき、機器20Aの通信部201は、拡張識別子IDBも機器20Bに送信しても良い。
同様に、機器20Bの通信部201は、拡張識別子IDBと短期公開鍵XBとを機器20Aに送信する(ステップS404)。なお、このとき、機器20Bの通信部201は、拡張識別子IDAも機器20Aに送信しても良い。
次に、機器20Aの認証認可処理部202は、上記のステップS401で生成した短期秘密鍵xAを記憶部203から削除する(ステップS405)。同様に、機器20Bの認証認可処理部202は、上記のステップS402で生成した短期秘密鍵xBを記憶部203から削除する(ステップS406)。
なお、上記のステップS405及びステップS406で短期秘密鍵xA及び短期秘密鍵xBをそれぞれ削除しているが、これは、他方の機器20から拡張識別子及び短期公開鍵を受信するまでの間に短期秘密鍵が流出することを防止するためである。すなわち、例えば、機器20Aが拡張識別子IDA及び短期公開鍵XAを機器20Bに送信した後、機器20Aが拡張識別子IDB及び短期公開鍵XBを機器20Bから受信するまでの間には或る程度の時間を要することがある。このため、この時間の間における短期秘密鍵xAの流出を防止するために、機器20Aは、拡張識別子IDA及び短期公開鍵XAを機器20Bに送信した後、短期秘密鍵xAを削除している。短期秘密鍵xBを削除している理由についても同様である。ただし、短期秘密鍵xA及びxBを削除しない運用も可能である(つまり、ステップS405~ステップS406と、後述するステップS407~ステップS408とを実行しない運用も可能である。)。
ここで、機器20Aは、拡張識別子IDB及び短期公開鍵XBを機器20Bから受信した時点で、以降のステップS405、ステップS407、ステップS409、ステップS411、ステップS413及びステップS415を実行可能である。同様に、機器20Bは、拡張識別子IDA及び短期公開鍵XAを機器20Aから受信した時点で、以降のステップS406、ステップS408、ステップS410、ステップS412、ステップS414及びステップS416を実行可能である
機器20Aの認証認可処理部202は、短期秘密鍵
機器20Aの認証認可処理部202は、短期秘密鍵
同様に、機器20Bの認証認可処理部202は、短期秘密鍵
次に、機器20Aの認証認可処理部202は、以下により公開情報dA及びdBを生成する(ステップS409)。
dA=H3(XA,IDA,IDB)
dB=H3(XB,IDA,IDB)
同様に、機器20Bの認証認可処理部202は、以下により公開情報dA及びdBを生成する(ステップS410)。
dB=H3(XB,IDA,IDB)
同様に、機器20Bの認証認可処理部202は、以下により公開情報dA及びdBを生成する(ステップS410)。
dA=H3(XA,IDA,IDB)
dB=H3(XB,IDA,IDB)
ここで、上記のステップS409及びステップS410では公開情報dA及びdBを機器20A及び機器20Bが生成するものとしたが、認証認可基盤10が生成しても良い。機器20A及び機器20Bのそれぞれで公開情報dA及びdBを生成することが簡便であるが、例えば、機器20の計算リソースが限られており、H3の計算に多くの計算リソースが必要な場合等には認証認可基盤10で公開情報dA及びdBを生成することが好ましい。なお、公開情報dA及びdBが生成されるタイミングは、短期公開鍵XA及びXBの生成後、後述する共有値σの生成前であれば、任意のタイミングで良い。
dB=H3(XB,IDA,IDB)
ここで、上記のステップS409及びステップS410では公開情報dA及びdBを機器20A及び機器20Bが生成するものとしたが、認証認可基盤10が生成しても良い。機器20A及び機器20Bのそれぞれで公開情報dA及びdBを生成することが簡便であるが、例えば、機器20の計算リソースが限られており、H3の計算に多くの計算リソースが必要な場合等には認証認可基盤10で公開情報dA及びdBを生成することが好ましい。なお、公開情報dA及びdBが生成されるタイミングは、短期公開鍵XA及びXBの生成後、後述する共有値σの生成前であれば、任意のタイミングで良い。
次に、機器20Aの認証認可処理部202は、以下により共有値σを計算する(ステップS411)。
FA=(xA+dA)(XB+dB(z+iA)g1)
σ=e(FA,DA)
同様に、機器20Bの認証認可処理部202は、以下により共有値σを計算する(ステップS412)。
σ=e(FA,DA)
同様に、機器20Bの認証認可処理部202は、以下により共有値σを計算する(ステップS412)。
FB=(xB+dB)(XA+dA(z+iB)g1)
σ=e(FB,DB)
次に、機器20Aの認証認可処理部202は、以下によりsidを計算する(ステップS413)。
σ=e(FB,DB)
次に、機器20Aの認証認可処理部202は、以下によりsidを計算する(ステップS413)。
同様に、機器20Bの認証認可処理部202は、以下により共有鍵Kを生成する(ステップS416)。
これにより、機器20Aと機器20Bとの間で共有鍵Kが共有される。そして、機器20Aと機器20Bとは、この共有鍵Kにより相互認証を行う(ステップS417)。
以上のように、機器20間の通信量がより少なくなり、かつ、各機器20での計算量がより少なくなるようにFSUを改良したプロトコルを用いて、機器20Aと機器20Bとの間で相互認証を行うことができる。ここで、本変形例では、図8で説明した相互認証処理と比較すると、機器20Aと機器20Bとの間で送受信される短期公開鍵がXA及びXBのみであるため、機器20Aと機器20Bとの間の通信量を削減することが可能となる。また、機器20A及び機器20Bでのペアリング演算の回数がそれぞれ1回であるため、機器20A及び機器20Bの計算量も削減することが可能となる。このため、機器20がIoT機器等である場合であっても、相互認証に要する処理をより効率的に行うことができるようになる。
<まとめ>
以上のように、本発明の実施の形態における認証認可システム1では、被認可機器20と認可機器20との間で相互認証を行った後、認可機器20が被認可機器20の拡張識別子を参照することで、認可機器20から被認可機器20への認可を行うことができる。このため、本発明の実施の形態における認証認可システム1によれば、認可機器20及び被認可機器20は認可のための通信(例えば、認可サーバへの通信等)を行う必要がなくなり、通信負荷を削減することができる。
以上のように、本発明の実施の形態における認証認可システム1では、被認可機器20と認可機器20との間で相互認証を行った後、認可機器20が被認可機器20の拡張識別子を参照することで、認可機器20から被認可機器20への認可を行うことができる。このため、本発明の実施の形態における認証認可システム1によれば、認可機器20及び被認可機器20は認可のための通信(例えば、認可サーバへの通信等)を行う必要がなくなり、通信負荷を削減することができる。
また、各機器20の認可情報が拡張識別子に含まれているため、例えば機器管理者は、この拡張識別子に含まれる認可情報を変更や更新等するだけで、各機器20間での認可を容易に制御することができる。
更に、通常、認証サーバと認可サーバとが別々に構築されることが一般的であるが、本発明の実施の形態における認証認可システム1では、認証及び認可を認証認可基盤10のみで実現することができる。このため、例えば、認証サーバと認可サーバとの間の連携が不要になり、認証及び認可に必要なサーバの構築を容易に行うこともできるようになる。したがって、例えば、多数の機器20を用いて実験的に何等かの処理を試行するような環境を構築する場合にも、本発明の実施の形態における認証認可システム1を用いることで、容易に環境を構築することもできるようになる。
なお、上記の実施の形態では、機器20同士で、一方が被認可側、他方が認可側であるものとして認証認可を行う場合について説明したが、これに限られず、例えば、認可側はサーバ装置等であっても良い。
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変形が可能である。
本願は、日本国に2018年10月19日に出願された基礎出願2018-197875号に基づくものであり、その全内容はここに参照をもって援用される。
1 認証認可システム
10 認証認可基盤
20 機器
101 通信部
102 登録処理部
103 記憶部
201 通信部
202 認証認可処理部
203 記憶部
N 通信ネットワーク
10 認証認可基盤
20 機器
101 通信部
102 登録処理部
103 記憶部
201 通信部
202 認証認可処理部
203 記憶部
N 通信ネットワーク
Claims (8)
- 複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムであって、
前記サーバは、
前記機器の識別子及び前記機器の認可情報を保持する保持手段と、
前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、
前記生成手段により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手段と、を有し、
前記複数の機器の各々は、
自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手段と、
前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、
を有することを特徴する認証認可システム。 - 前記認可情報には、前記自機器の識別子と、前記自機器が許可する前記他の機器からのデータ操作又は機能の利用とが含まれ、
前記認可手段は、
前記認可情報に含まれる前記データ操作又は前記機能の利用の要求を許可する、ことを特徴とする請求項1に記載の認証認可システム。 - 前記拡張識別子には、前記認可情報の有効期限が含まれ、
前記認可手段は、
現在の日又は日時が前記有効期限以内である場合、前記認可情報に応じて、前記他の機器から自機器への要求を許可する、ことを特徴とする請求項1又は2に記載の認証認可システム。 - 前記認証手段は、
IDベース暗号を用いた認証付き鍵共有プロトコルにより前記他の機器との間で相互に認証を行う、ことを特徴とする請求項1乃至3の何れか一項に記載の認証認可システム。 - 相互に認証及び認可を行う複数の機器それぞれの秘密鍵を生成する情報処理装置であって、
前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、
前記機器に対して前記秘密鍵及び前記拡張識別子を配布する配布手段と、
を有することを特徴とする情報処理装置。 - 他の機器との間で認証及び認可を行う機器であって、
前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から生成された秘密鍵を用いて、前記他の機器との間で相互に認証を行う認証手段と、
前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、
を有することを特徴とする機器。 - 複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムに用いられる認証認可方法であって、
前記機器の識別子及び前記機器の認可情報を保持するサーバが、
前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手順と、
前記生成手順により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手順と、を実行し、
前記複数の機器の各々が、
自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手順と、
前記認証手順で前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手順と、
を実行することを特徴する認証認可方法。 - コンピュータを、請求項5に記載の情報処理装置における各手段又は請求項6に記載の機器における各手段として機能させるためのプログラム。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020553332A JP7115556B2 (ja) | 2018-10-19 | 2019-10-18 | 認証認可システム及び認証認可方法 |
CN201980064745.5A CN112805960B (zh) | 2018-10-19 | 2019-10-18 | 认证授权系统、信息处理装置、设备、认证授权方法及程序 |
EP19872926.1A EP3836482A4 (en) | 2018-10-19 | 2019-10-18 | AUTHENTICATION AUTHORIZATION SYSTEM, INFORMATION PROCESSING DEVICE, DEVICE, AUTHENTICATION AUTHORIZATION METHOD AND PROGRAM |
US17/285,455 US20210344515A1 (en) | 2018-10-19 | 2019-10-18 | Authentication-permission system, information processing apparatus, equipment, authentication-permission method and program |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018197875 | 2018-10-19 | ||
JP2018-197875 | 2018-10-19 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020080510A1 true WO2020080510A1 (ja) | 2020-04-23 |
Family
ID=70283936
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2019/041048 WO2020080510A1 (ja) | 2018-10-19 | 2019-10-18 | 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム |
Country Status (5)
Country | Link |
---|---|
US (1) | US20210344515A1 (ja) |
EP (1) | EP3836482A4 (ja) |
JP (1) | JP7115556B2 (ja) |
CN (1) | CN112805960B (ja) |
WO (1) | WO2020080510A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022091183A1 (ja) * | 2020-10-26 | 2022-05-05 | 日本電信電話株式会社 | 認証認可システム、機器、認証認可方法、及びプログラム |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009033402A (ja) * | 2007-07-26 | 2009-02-12 | Mitsubishi Electric Corp | Idベース暗号システム及び送信端末装置及び配送サーバ装置及び受信端末装置 |
JP2010016465A (ja) * | 2008-07-01 | 2010-01-21 | Mitsubishi Electric Corp | 権限検証装置及び利用者端末装置及び鍵生成装置及びアクセス制御システム及びコンピュータプログラム及び権限検証方法及び操作要求通知方法及び鍵生成方法及びアクセス制御方法 |
JP2017126970A (ja) * | 2016-01-15 | 2017-07-20 | 富士通株式会社 | 共有鍵生成プログラム、共有鍵生成方法および情報処理端末 |
JP2018197875A (ja) | 2013-08-06 | 2018-12-13 | 華為技術有限公司Huawei Technologies Co.,Ltd. | オーディオ信号分類方法及び装置 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101254209B1 (ko) * | 2004-03-22 | 2013-04-23 | 삼성전자주식회사 | 디바이스와 휴대용 저장장치간에 권리 객체를 이동,복사하는 방법 및 장치 |
CN101521569B (zh) * | 2008-02-28 | 2013-04-24 | 华为技术有限公司 | 实现服务访问的方法、设备及系统 |
US9025767B2 (en) * | 2010-03-24 | 2015-05-05 | Nokia Corporation | Method and apparatus for querying content protected by identity-based encryption |
JP5553914B1 (ja) * | 2013-01-08 | 2014-07-23 | 日本電信電話株式会社 | 認証システム、認証装置、及び認証方法 |
KR102186012B1 (ko) * | 2014-02-05 | 2020-12-04 | 애플 인크. | 제어기와 액세서리 사이의 통신을 위한 균일한 통신 프로토콜 |
US9674705B2 (en) * | 2015-04-22 | 2017-06-06 | Kenneth Hugh Rose | Method and system for secure peer-to-peer mobile communications |
CN106603586B (zh) * | 2015-10-14 | 2020-09-29 | 阿里巴巴集团控股有限公司 | 一种生成设备标识的方法、装置和系统 |
WO2017167771A1 (en) * | 2016-03-29 | 2017-10-05 | Koninklijke Philips N.V. | Handshake protocols for identity-based key material and certificates |
WO2017178054A1 (en) * | 2016-04-14 | 2017-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Registration of data packet traffic for a wireless device |
CN109905877B (zh) * | 2017-12-08 | 2020-11-10 | 大唐移动通信设备有限公司 | 通信网络系统的消息验证方法、通信方法和通信网络系统 |
-
2019
- 2019-10-18 JP JP2020553332A patent/JP7115556B2/ja active Active
- 2019-10-18 CN CN201980064745.5A patent/CN112805960B/zh active Active
- 2019-10-18 US US17/285,455 patent/US20210344515A1/en active Pending
- 2019-10-18 WO PCT/JP2019/041048 patent/WO2020080510A1/ja unknown
- 2019-10-18 EP EP19872926.1A patent/EP3836482A4/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009033402A (ja) * | 2007-07-26 | 2009-02-12 | Mitsubishi Electric Corp | Idベース暗号システム及び送信端末装置及び配送サーバ装置及び受信端末装置 |
JP2010016465A (ja) * | 2008-07-01 | 2010-01-21 | Mitsubishi Electric Corp | 権限検証装置及び利用者端末装置及び鍵生成装置及びアクセス制御システム及びコンピュータプログラム及び権限検証方法及び操作要求通知方法及び鍵生成方法及びアクセス制御方法 |
JP2018197875A (ja) | 2013-08-06 | 2018-12-13 | 華為技術有限公司Huawei Technologies Co.,Ltd. | オーディオ信号分類方法及び装置 |
JP2017126970A (ja) * | 2016-01-15 | 2017-07-20 | 富士通株式会社 | 共有鍵生成プログラム、共有鍵生成方法および情報処理端末 |
Non-Patent Citations (5)
Title |
---|
AKIRA NAGAI; SAKURAKO TAMURA; KAZUHIRO HAYAKAWA: "On the Implementation of FSU Key Exchange on ARM Cortex-M", SUMMARIES OF 2018 SYMPOSIUM ON CRYPTOGRAPHY AND INFOMATION SECURITY - SCIS 2018, 23-26 JANUARY 2018, 23 January 2018 (2018-01-23), pages 1 - 8, XP009526326 * |
KOMATSUFUMIKO: "IPSJ Magazine", vol. 48, July 2017, NEC, article "Architecture for Privacy Protection", pages: 737 - 743 |
SATO RYOTA, CHIKARA SAKAE, OKUDA TETSUYA, KAYAGUCHI SHIGERU: "A proposal of situation sensitive function controller for smart devices and its evaluation", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 55, no. 1, 15 January 2014 (2014-01-15), pages 267 - 279, XP055784970, ISSN: 1882-7764 * |
See also references of EP3836482A4 |
TAMURA SAKURAKO ; AKIRA NAGAI; KAZUHIRO HAYAKAWA: "On the Implementation of Functional Encryption on ARM Cortex-M", SUMMARIES OF 2018 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY - SCIS 2018, 23-26 JANUARY 2018, 23 January 2018 (2018-01-23), pages 1 - 8, XP009526325 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022091183A1 (ja) * | 2020-10-26 | 2022-05-05 | 日本電信電話株式会社 | 認証認可システム、機器、認証認可方法、及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
CN112805960B (zh) | 2024-05-17 |
US20210344515A1 (en) | 2021-11-04 |
JP7115556B2 (ja) | 2022-08-09 |
JPWO2020080510A1 (ja) | 2021-09-02 |
EP3836482A1 (en) | 2021-06-16 |
EP3836482A4 (en) | 2022-05-04 |
CN112805960A (zh) | 2021-05-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI738835B (zh) | 資料安全保障系統及方法、裝置 | |
US20240073003A1 (en) | Method of data transfer, a method of controlling use of data and cryptographic device | |
US9467430B2 (en) | Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware | |
CN109479049B (zh) | 用于密钥供应委托的系统、设备和方法 | |
JP3999655B2 (ja) | レベル化された機密保護があるアクセス制御のための方法及び装置 | |
JP4723251B2 (ja) | 機器固有の機密保護データの安全な組み込みと利用 | |
EP2262164A1 (en) | Secure data transfer | |
JP7115556B2 (ja) | 認証認可システム及び認証認可方法 | |
KR20150016802A (ko) | 보안장치 및 이를 이용하는 데이터 이동 방법 | |
JP4499575B2 (ja) | ネットワークセキュリティ方法およびネットワークセキュリティシステム | |
WO2021010444A1 (ja) | 鍵交換システム、通信装置、鍵交換方法及びプログラム | |
JP2019057827A (ja) | 分散認証システムおよびプログラム | |
WO2020240741A1 (ja) | 鍵交換システム、通信装置、鍵交換方法及びプログラム | |
Omote | Is the Blockchain Useful for Sharing Sensitive Data? | |
JP2021196428A (ja) | 暗号システム、ユーザ端末、方法及びプログラム | |
JP2021034979A (ja) | 鍵交換システム、機器、情報処理装置、鍵交換方法及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19872926 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2020553332 Country of ref document: JP Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 2019872926 Country of ref document: EP Effective date: 20210310 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |