WO2022091183A1 - 認証認可システム、機器、認証認可方法、及びプログラム - Google Patents

認証認可システム、機器、認証認可方法、及びプログラム Download PDF

Info

Publication number
WO2022091183A1
WO2022091183A1 PCT/JP2020/040126 JP2020040126W WO2022091183A1 WO 2022091183 A1 WO2022091183 A1 WO 2022091183A1 JP 2020040126 W JP2020040126 W JP 2020040126W WO 2022091183 A1 WO2022091183 A1 WO 2022091183A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorization
authentication
condition
information
unit
Prior art date
Application number
PCT/JP2020/040126
Other languages
English (en)
French (fr)
Inventor
悠介 飯島
幹 安田
彰 永井
雅巳 泉
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2022558616A priority Critical patent/JPWO2022091183A1/ja
Priority to US18/249,120 priority patent/US20230396614A1/en
Priority to PCT/JP2020/040126 priority patent/WO2022091183A1/ja
Publication of WO2022091183A1 publication Critical patent/WO2022091183A1/ja

Links

Images

Classifications

    • 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
    • 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
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • 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
    • 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
    • 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

Definitions

  • the present invention relates to a certification / authorization system, a device, a certification / authorization method, and a program.
  • authorization information generally has an expiration date.
  • the expiration date is specified in the electronic certificate.
  • the device on the authorization side compares the time information synchronized with the NTP (Network Time Protocol) server with the expiration date specified in the electronic certificate to see if the electronic certificate is within the expiration date. Check if it is not.
  • NTP Network Time Protocol
  • One embodiment of the present invention has been made in view of the above points, and an object thereof is to enable confirmation of an expiration date regarding approval.
  • the authentication / authorization system uses a plurality of devices that perform mutual authentication and authorization by an authentication protocol using ID-based encryption, and an ID and a private key used for the mutual authentication and authorization.
  • An authentication / authorization system including an authentication / authorization platform to be generated, wherein the authentication / authorization infrastructure is derived from an ID generation unit that generates an ID including at least an identifier of the device and information about the device, and the ID. It has a generation unit that generates a secret key of the device, and a distribution unit that distributes the ID and the secret key to the device corresponding to the identifier included in the ID, and the device has its own ID and the above.
  • a mutual authentication unit that performs mutual authentication with another device using a private key, and information about the device included in its own ID when mutual authentication is performed with the other device, and Using the information about the device included in the ID of the other device, a confirmation unit for confirming whether or not the predetermined approval condition is satisfied, and when it is confirmed that the approval condition is satisfied, the other device. It is characterized by having an authorization unit that approves the request from the company to itself.
  • FIG. 1 It is a figure which shows the whole structure of the authentication authorization system in Example 1.
  • FIG. It is a figure which shows the hardware configuration of the authentication authorization base in Example 1.
  • FIG. It is a figure which shows the hardware configuration of the apparatus in Example 1.
  • FIG. It is a figure which shows the functional structure of the authentication authorization base in Example 1.
  • FIG. It is a figure which shows the functional structure of the apparatus in Example 1.
  • FIG. It is a flowchart which shows the distribution process of ID and a private key in Example 1.
  • FIG. It is a flowchart which shows the authentication authorization process in Example 1.
  • FIG. It is a flowchart which shows the authorization confirmation process in Example 1.
  • FIG. It is a figure which shows the functional structure of the apparatus in Example 2.
  • FIG. It is a flowchart which shows the authorization confirmation process in Example 2.
  • It is a flowchart which shows the distribution process of ID and a private key in Example 3.
  • FIG. It is a flowchart which shows the authorization confirmation process in Example
  • the authentication / authorization system 1 that enables mutual authentication and confirmation of the expiration date for authorization when communicating between devices even if the devices do not hold time information due to resource restrictions or the like will be described.
  • the authentication / authorization system 1 uses an authentication protocol by ID-based cryptography (hereinafter, also referred to as "ID-based authentication") for mutual authentication when communicating between devices, and the inside of the ID.
  • ID-based authentication an authentication protocol by ID-based cryptography
  • the device on the authorization side can confirm the expiration date.
  • Example 1 First, Example 1 will be described.
  • FIG. 1 is a diagram showing an overall configuration of the authentication / authorization system 1 in the first embodiment.
  • the authentication / authorization system 1 in the first embodiment includes an authentication / authorization platform 10 and one or more devices 20. Further, the authentication / authorization board 10 and each device 20 are communicably connected via a communication network N such as the Internet.
  • the authentication / authorization platform 10 is a computer or computer system that generates an ID that includes at least a device identifier that identifies each device 20 and time information, and also generates a private key from the ID. That is, the authentication / authorization platform 10 functions as a key issuing center (KGC: Key. Generation Center) for ID-based cryptography.
  • KGC Key. Generation Center
  • 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 performs mutual authentication with another device 20 by an authentication protocol using ID-based cryptography, and confirms the expiration date of the authorization.
  • each device 20 performs mutual authentication with another device 20 using the private key distributed from the authentication / authorization platform 10, and confirms the expiration date of the authorization using the time information included in the ID. conduct.
  • each of the plurality of devices 20 is represented separately, it is referred to as “device 20A”, “device 20B”, or the like.
  • the other device 20 confirms the expiration date regarding the approval of the device 20, so that the device 20 (including access) is confirmed. That is, the device 20 on the side that operates data or uses the function) is also referred to as the “device 20 on the authorized side", and the other device 20 (that is, the device 20 on the authorized side is authorized and held by itself).
  • the device 20) on the side that permits the operation or use of the function of the data to be performed is also referred to as the “device 20 on the authorization side”. For example, since two devices 20 may mutually operate or use data, functions, and the like, one device 20 may be the device 20 on the licensed side and the device 20 on the licensed side.
  • the device 20 in this embodiment does not hold the time information synchronized with the NTP server due to reasons such as resource restrictions and a narrow bandwidth of the communication environment.
  • this embodiment can be similarly applied to the device 20 that holds the time information synchronized with the NTP server.
  • the configuration of the authentication / authorization system 1 shown in FIG. 1 is an example, and may be another configuration.
  • the terminal used by the manager of the device 20 (hereinafter, also referred to as “device manager”) may be included in the authentication / authorization system 1.
  • the device 20 performs authentication approval with any device or device other than the device 20 (for example, a gateway device, a server, etc.), the device or device is included in the certification / authorization system 1. You may.
  • FIG. 2 is a diagram showing a hardware configuration of the authentication authorization board 10 in the first embodiment.
  • the authentication / authorization board 10 in the first embodiment includes an input device 11, a display device 12, an external I / F 13, a communication I / F 14, a processor 15, and a memory device 16. Each of these hardware is connected so as to be communicable via the bus 17.
  • the input device 11 is, for example, a keyboard, a mouse, a touch panel, or the like.
  • the display device 12 is, for example, a display or the like.
  • the authentication / authorization board 10 does not have to have at least one of the input device 11 and the display device 12.
  • the external I / F 13 is an interface with the recording medium 13a or the like.
  • the authentication / authorization board 10 can read or write the recording medium 13a via the external I / F 13.
  • Examples of the recording medium 13a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), a USB (Universal Serial Bus) memory card, and the like.
  • the communication I / F 14 is an interface for connecting the authentication / authorization board 10 to the communication network N.
  • the processor 15 is, for example, various arithmetic units such as a CPU (Central Processing Unit).
  • the memory device 16 is, for example, various storage devices such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), a RAM (Random Access Memory), a ROM (Read Only Memory), and a flash memory.
  • the authentication / authorization platform 10 in the first embodiment has the hardware configuration shown in FIG. 2, so that various processes described later can be realized.
  • the hardware configuration shown in FIG. 2 is an example, and the authentication / authorization board 10 may have another hardware configuration.
  • the authentication / authorization board 10 may have a plurality of processors 15 or a plurality of memory devices 16.
  • FIG. 3 is a diagram showing a hardware configuration of the device 20 in the first embodiment.
  • the device 20 in the first embodiment has a communication I / F 21, a processor 22, and a memory device 23. Each of these hardware is connected so as to be communicable via the bus 24.
  • the communication I / F 21 is an interface for connecting the device 20 to the communication network N.
  • the processor 22 is, for example, various arithmetic units such as an MPU (Micro Processing Unit) and a CPU.
  • the memory device 23 is, for example, various storage devices such as RAM, ROM, and flash memory.
  • the device 20 in the first embodiment has the hardware configuration shown in FIG. 3, so that various processes described later can be realized.
  • the hardware configuration shown in FIG. 3 is an example, and the device 20 may have another hardware configuration.
  • the device 20 may have an input device such as various buttons, or may have a display device such as a display panel.
  • FIG. 4 is a diagram showing a functional configuration of the authentication / authorization platform 10 in the first embodiment.
  • the authentication / authorization infrastructure 10 in the first embodiment includes a communication unit 101, a time management unit 102, a device information management unit 103, an authorization condition management unit 104, an ID generation unit 105, and a registration process. It has a unit 106 and a secret key generation unit 107. Each of these parts is realized, for example, by a process of causing the processor 15 to execute one or more programs installed on the authentication / authorization board 10.
  • the authentication / authorization base 10 in the first embodiment has a storage unit 110.
  • the storage unit 110 is realized by, for example, a memory device 16.
  • the storage unit 110 may be realized by, for example, a storage device (for example, a database server or the like) communicably connected to the authentication / authorization board 10.
  • the communication unit 101 performs various communications with each device 20 and other devices (for example, a terminal used by a device manager).
  • the time management unit 102 manages time information (that is, information indicating the current time) synchronized with an external NTP server.
  • the device information management unit 103 manages the device identifier of each device 20. As the device identifier, any information can be used as long as it is information that can identify the device 20, for example, the manufacturing unique number and serial number of the device 20, and the device 20 unique within the authentication / authorization system 1. It is possible to use the number or the like assigned to.
  • the authorization condition management unit 104 manages authorization conditions in association with each device 20 (that is, in association with each device identifier).
  • the approval condition is a condition for the licensed device 20 to approve the licensed device 20, and in this embodiment, a condition indicating an expiration date from a reference time (for example, "within 3 days" or "" Within one day "etc.).
  • the ID generation unit 105 generates an ID including a device identifier, time information, and an authorization condition.
  • the registration processing unit 106 registers an ID related to this request, for example, in response to a request from a terminal or the like used by the device administrator.
  • the private key generation unit 107 generates a private key from the ID.
  • the storage unit 110 stores various information (for example, time information, device identifier, authorization condition, ID, etc.).
  • the functional configuration of the authentication / authorization board 10 shown in FIG. 4 is an example.
  • the authentication / authorization board 10 may not have either the ID generation unit 105 or the registration processing unit 106.
  • FIG. 5 is a diagram showing a functional configuration of the device 20 in the first embodiment.
  • the device 20 in the first embodiment has a communication unit 201, a mutual authentication unit 202, and an authorization confirmation unit 203.
  • Each of these parts is realized, for example, by a process of causing the processor 22 to execute one or more programs installed in the device 20.
  • the device 20 in the first embodiment has a storage unit 210.
  • the storage unit 210 is realized by, for example, a memory device 23.
  • the communication unit 201 performs various communications with another device 20, the authentication / authorization board 10, and the like.
  • the mutual authentication unit 202 performs mutual authentication with another device 20 by ID-based authentication using its own ID, private key, and the like.
  • the authorization confirmation unit 203 confirms the expiration date of the authorization of the other device 20 by using its own ID and the ID of the other device 20. ..
  • the storage unit 210 stores various information (for example, its own ID, private key, etc.).
  • FIG. 6 is a flowchart showing the distribution process of the ID and the private key in the first embodiment.
  • the distribution process of the ID and the private key is preferably executed periodically, for example, at predetermined intervals.
  • the ID generation unit 105 manages the device identifier managed by the device information management unit 103, the time information managed by the time management unit 102, and the device identifier in the authorization condition management unit 104.
  • the ID of each device 20 is generated by using the approval condition (step S101).
  • the ID generation unit 105 generates an ID for each device identifier by associating the device identifier, the time information, and the authorization condition corresponding to the device identifier.
  • the device identifier is "sensor01”
  • the time information is the symbol string “202007212137” indicating the current time "July 21, 2020 21:37”
  • the authorization condition is the symbol string "around 3days” indicating "within 3 days”.
  • the ID may be "sensor01_202007212137_around3days” or the like. This ID indicates that the device 20 having the ID generated within 3 days from the time "21:37 on July 21, 2020" is authorized for the device 20 having the device identifier "sensor01". There is. It is assumed that the meanings of the device identifier and the symbol string constituting the ID are shared by the entire authentication / authorization system 1.
  • the registration processing unit 106 may register these IDs (that is, store them in the storage unit 110 or the like) in response to the ID registration request from the terminal used by the device administrator.
  • the time information included in the ID may be set on the terminal or may be set (or reset) on the authentication / authorization board 10.
  • the ID may be created by, for example, the device administrator directly operating the authentication / authorization platform 10.
  • the private key generation unit 107 generates a private key from each ID generated (or registered) in step S101 above (step S102).
  • the secret key generation unit 107 generates a secret key from the ID by a predetermined ID-based authentication.
  • ID-based authentication an authentication protocol using any ID-based cryptography can be used, and for example, FSU (Fujioka-Suzuki-Ustaoglu) or the like can be used.
  • the communication unit 101 transmits (distributes) each ID generated (or registered) in step S101 and the private key generated from the ID to the device 20 having the device identifier included in the ID. (Step S103).
  • the device 20 stores the ID and the private key in the storage unit 210.
  • the communication unit 101 distributes the ID and the private key to the device 20 by an arbitrary secure method.
  • FIG. 7 is a flowchart showing the authentication / authorization process in the first embodiment.
  • the device 20B accesses the device 20A, and authentication and authorization between the device 20A and the device 20B will be described.
  • the mutual authentication unit 202 of the device 20A and the mutual authentication unit 202 of the device 20B perform mutual authentication by a predetermined ID-based authentication using the ID and the private key distributed from the authentication authorization platform 10 (step S201). If this mutual authentication is successful, the device 20A and the device 20B input each other's ID.
  • the authorization confirmation unit 203 of the device 20A confirms the expiration date regarding the authorization of the device 20B using the ID of the device 20B and its own ID, and the device 20B is authorized. Whether or not it is determined (step S202). The details of the process (authorization confirmation process) in step S202 will be described later.
  • step S202 determines whether the approval is granted. If it is determined in step S202 that the approval is granted, the communication unit 201 of the device 20B requests the execution of the authorized operation (step S203). In this embodiment, it is assumed that the authorized operation is predetermined.
  • the mutual authentication unit 202 of the device 20A denies the access from the device 20B (step S204).
  • FIG. 8 is a flowchart showing the approval confirmation process in the first embodiment.
  • the authorization confirmation unit 203 of the device 20A calculates the difference between the time indicated by the time information included in the ID of the device 20B and the time indicated by the time information included in its own ID (step S301). To be precise, this difference means a difference in date and time based on the time information included in the own ID.
  • the authorization confirmation unit 203 of the device 20A determines whether or not the difference calculated in step S301 above satisfies the authorization condition included in its own ID (step S302).
  • the approval confirmation unit 203 of the device 20A determines that the approval condition is satisfied in the above step S302, it determines that the device 20B has the approval (step S303), and determines that the approval condition is satisfied in the above step S302. If not, it is determined that the device 20B is not approved (step S304).
  • step S301 the difference between "202007221630” and "202007212137” is calculated, and in step S302 above, it is determined whether or not the difference satisfies the approval condition "around 3days" (that is, within 3 days). Will be done. In this example, since the difference between "202007221630" and "202007212137" is within 3 days, it is determined that the device 20B is approved.
  • the ID of the device 20A is "sensor01_202007212137_around3days" and the ID of the device 20B is "sensor02_202007251630_around1day", it is determined that the device 20B is not approved.
  • the time information is embedded in the ID distributed from the authentication / authorization platform 10 (in other words, the ID distributed from a reliable organization), and the authorization side device 20 is the authorized side device 20.
  • the authorization side device 20 is the authorized side device 20.
  • the authorized device 20 only refers to its own ID, but for example, when the time information included in the ID of the authorized device 20 is larger than the time information included in its own ID. (That is, when the time information advanced by the ID of the device 20 on the authorized side is included), the time information included in the own ID is updated with the time information included in the ID of the device 20 on the authorized side. You may. As a result, the device 20 on the authorization side can confirm the authorization from the next time onward by using the ID including the updated time information.
  • the authentication / authorization board 10 and each device 20 may be configured by a secure processor.
  • a secure processor is a processor whose execution environment operates separately in a secure area and a non-secure area. Generally, all data exchange via a communication path is performed in the non-secure area, and the non-secure area is changed to the secure area. Is inaccessible. With this mechanism, the secure processor prevents falsification and fraud of data, program binaries, etc. stored in the secure area.
  • each functional unit of the authentication / authorization board 10 is executed on the secure area.
  • each functional unit of the device 20 is executed on the secure area.
  • the ID, private key, and the like are also stored in the secure area.
  • each device 20 may store the approval conditions in the storage unit 110 in advance, and the approval conditions may be used in the approval confirmation process.
  • the length of each ID can be shortened. For example, if the device identifier is "sensor01" and the time information is the symbol string "202007212137" indicating the current time "July 21, 2020 21:37”, the ID will be "sensor01_202007212137" and the length of the ID will be changed. Can be shortened.
  • Example 2 Next, Example 2 will be described.
  • the current time is calculated by measuring the elapsed time since the ID and the private key are distributed by each device 20 and adding the elapsed time to the time indicated by the time information included in the ID. Will be explained. This makes it possible to more accurately confirm the expiration date for authorization in the second embodiment regardless of the interval at which the ID is distributed.
  • FIG. 9 is a diagram showing a functional configuration of the device 20 in the second embodiment.
  • the device 20 in the second embodiment further has a time measuring unit 204.
  • the time measuring unit 204 is realized, for example, by a process of causing the processor 22 to execute one or more programs installed in the device 20.
  • the time measuring unit 204 measures the elapsed time from the time when the own ID and the private key are received from the authentication / authorization board 10 (that is, the time change of the state of the device 20). When the time measurement unit 204 newly receives its own ID and private key from the authentication / authorization board 10, the time measurement unit 204 resets the elapsed time measured so far and then newly measures the elapsed time.
  • FIG. 10 is a flowchart showing the approval confirmation process in the second embodiment.
  • the device 20A is the device 20 on the licensed side
  • the device 20B is the device 20 on the licensed side.
  • the authorization confirmation unit 203 of the device 20A calculates the time (hereinafter, also referred to as the time after addition) obtained by adding the elapsed time measured by the time measurement unit 204 to the time indicated by the time information included in its own ID. (Step S401). Since the elapsed time is the time elapsed from the time when the ID and the private key are received, the time after addition is the current time (or a time close to the current time).
  • the authorization confirmation unit 203 of the device 20A calculates the difference between the time indicated by the time information included in the ID of the device 20B and the time after addition calculated in step S401 above (step S402).
  • the authorization confirmation unit 203 of the device 20A determines whether or not the difference calculated in step S402 above satisfies the authorization condition included in its own ID (step S403).
  • step S403 determines that the approval condition is satisfied in the above step S403
  • step S404 determines that the device 20B has the approval
  • step S403 determines that the approval condition is satisfied in the above step S403. If not, it is determined that the device 20B is not approved (step S405).
  • step S401 the time after addition "202007220037” is calculated by adding 3 hours to "202007212137”
  • step S402 the difference between "202007221630" and "202007220037” is calculated.
  • step S403 of step S403 it is determined whether or not the difference satisfies the approval condition "around 3 days” (that is, within 3 days). In this example, since the difference between "202007221630" and “202007220037” is within 3 days, it is determined that the device 20B is approved.
  • the ID of the device 20A is "sensor01_202007212137_around3days" and the ID of the device 20B is "sensor02_202007251630_around1day", it is determined that the device 20B is not approved.
  • the time information included in the device 20 on the authorization side is corrected by the elapsed time from the time when the ID is received. This makes it possible to more accurately confirm the expiration date for approval as compared with Example 1.
  • the time information is included in the ID, but the location information may be included in the ID instead of the time information (or together with the time information). That is, when distributing the ID to the device 20, the ID may include position information (or, in addition, the current time) indicating the position of the device 20 at the time of distributing the ID.
  • the position information in the ID
  • each device 20 can determine the moving distance (that is, the positional change of the state of the device 20) by the measuring unit realized by, for example, an acceleration sensor or GPS (Global Positioning System). By measuring, it becomes possible to estimate or specify the current position from the position information included in the own ID.
  • the approval confirmation unit 203 of the device 20A calculates the difference between its current position and the position indicated by the position information included in the ID of the device 20B, and whether or not the difference satisfies the approval condition regarding the position. It is also possible to confirm the approval by determining.
  • the approval condition regarding the position is a condition regarding the position or the distance, for example, "the distance is within 100 m".
  • any information about the device that is, any information indicating the state of the device other than the time and position (for example, battery level, radio wave reception strength, date of manufacture, model number, etc.)
  • the device manager, information indicating the connection destination of the device, etc. may be used.
  • Example 3 Next, Example 3 will be described.
  • the authorization target is data, a function, or the like approved by the device 20 on the authorization side, and examples thereof include browsing of internal data and use of a specific function.
  • the differences from the first embodiment will be described, and the description of the same components as those in the first embodiment will be omitted. That is, the components not described in the present embodiment may be the same as those in the first embodiment.
  • FIG. 11 is a flowchart showing the distribution process of the ID and the private key in the third embodiment.
  • the distribution process of the ID and the private key is preferably executed periodically, for example, at predetermined intervals.
  • the ID generation unit 105 manages the device identifier managed by the device information management unit 103, the time information managed by the time management unit 102, and the authorization condition management unit 104 in association with the device identifier.
  • the ID of each device 20 is generated by using the authorization target and the authorization condition (step S501).
  • the authorization condition management unit 104 manages one or more authorization targets and the authorization conditions in association with the device identifier for each device identifier. Therefore, the ID generation unit 105 generates an ID for each device identifier by associating the device identifier, the time information, one or more authorization targets corresponding to the device identifier, and the authorization conditions thereof.
  • the device identifier is "sensor01”
  • the time information is the symbol string “202007212137” indicating the current time "July 21, 2020 21:37”
  • the first authorization target is the symbol string "data transmission”.
  • the authorization condition corresponding to the authorization target "data transmission” is the symbol string “around 3days” indicating "within 3 days”
  • the second authorization target is the symbol string “attempt” indicating "device operation”
  • the ID may be "sensor01_202007212137_senddata_around3days_attempt_around1day” or the like.
  • the device 20 having the ID generated within 3 days from the time "21:37 on July 21, 2020” is authorized to "transmit data" to the device 20 with the device identifier "sensor01".
  • the device 20 having the ID generated within one day indicates that the "device operation” is authorized. It is assumed that the meanings of the device identifier and the symbol string constituting the ID are shared by the entire authentication / authorization system 1.
  • steps S502 to S503 are the same as steps S102 to S103 in FIG.
  • FIG. 12 is a flowchart showing the approval confirmation process in the third embodiment.
  • the device 20A is the device 20 on the licensed side
  • the device 20B is the device 20 on the licensed side.
  • the authorization confirmation unit 203 of the device 20A calculates the difference between the time indicated by the time information included in the ID of the device 20B and the time indicated by the time information included in its own ID (step S601).
  • the authorization confirmation unit 203 of the device 20A determines whether or not the difference calculated in step 601 above satisfies the authorization condition corresponding to the authorization target among the authorization conditions included in its own ID (step S602). ..
  • the approval confirmation unit 203 of the device 20A determines that the approval condition is satisfied in the above step S602, it determines that the device 20B has the approval for the approval target (step S603), and determines the approval condition in the above step S602. If it is not determined that the condition is satisfied, it is determined that the device 20B is not approved for the approval target (step S604).
  • steps S602 to S604 relating to the authorization target "send data” and steps S602 to S604 relating to the authorization target "attempt” are executed, respectively.
  • the difference between "202007231630" and "202007212137” satisfies the approval condition "within 3 days", but does not satisfy the approval condition "within 1 day”. Therefore, in this example, the device 20B is determined to have approval for the authorization target “senddata” and no authorization for the authorization target “attempt”.
  • the authorization condition is also included in the ID for each authorization target. Therefore, for example, even when it is desired to approve only a part of the data and functions held by the device 20 on the authorization side, the authorization can be flexibly performed.
  • the data, functions, and the like approved by the device 20 on the authorization side are included in the ID, and a symbol string representing such an authorization target is included in the ID, but the ID is not limited to this, and for example, authorization.
  • the identifier of the target may be included in the ID, or the device identification of the device 20 on the authorized side may be included in the ID as the authorization target.
  • Example 4 Next, Example 4 will be described.
  • the authorization side device 20 performs authorization confirmation with reference to the authorization condition included in the ID of the authorization side device 20 will be described. Thereby, for example, by treating the approval condition as a condition indicating the expiration date of the ID, it is possible to confirm whether or not the ID of the device 20 on the authorized side has been revoked.
  • FIG. 13 is a flowchart showing the approval confirmation process in the fourth embodiment.
  • the device 20A is the device 20 on the licensed side
  • the device 20B is the device 20 on the licensed side.
  • the authorization confirmation unit 203 of the device 20A calculates the difference between the time indicated by the time information included in the ID of the device 20B and the time indicated by the time information included in its own ID (step S701).
  • the authorization confirmation unit 203 of the device 20A determines whether or not the difference calculated in step S701 above satisfies the authorization condition included in the ID of the device 20B (step S702).
  • the approval confirmation unit 203 of the device 20A determines that the approval condition is satisfied in the above step S702, it determines that the device 20B has the approval (step S703), and determines that the approval condition is satisfied in the above step S702. If not, it is determined that the device 20B is not approved (step S704).
  • step S701 the difference between "202007221630” and "202007212137” is calculated, and in step S702 above, it is determined whether or not the difference satisfies the approval condition "around 1day" (that is, within one day). Will be done. In this example, since the difference between "202007221630" and "202007212137" is within one day, it is determined that the device 20B is approved.
  • the ID of the device 20A is "sensor01_202007212137_around3days" and the ID of the device 20B is "sensor02_202007251630_around1day", it is determined that the device 20B is not approved.
  • the licensed device 20 confirms the license according to the license conditions included in the ID of the licensed device 20.
  • the authorization condition included in the ID 20 of the device on the authorized side is treated as the expiration date of the ID.
  • the authorized side device 20 can be prevented from being approved.
  • Certification and authorization system 10 Certification and authorization infrastructure 11 Input device 12 Display device 13 External I / F 13a Recording medium 14 Communication I / F 15 Processor 16 Memory device 17 Bus 20 Equipment 21 Communication I / F 22 Processor 23 Memory device 24 Bus 101 Communication unit 102 Time management unit 103 Device information management unit 104 Authorization condition management unit 105 ID generation unit 106 Registration processing unit 107 Private key generation unit 110 Storage unit 201 Communication unit 202 Mutual authentication unit 203 Authorization confirmation Unit 204 Time measurement unit 210 Storage unit N Communication network

Abstract

一実施形態に係る認証認可システムは、ＩＤベース暗号を用いた認証プロトコルによる相互認証及び認可を行う複数の機器と、前記相互認証及び認可に用いられるＩＤ及び秘密鍵を生成する認証認可基盤とが含まれる認証認可システムであって、前記認証認可基盤は、前記機器の識別子と、機器に関する情報とが少なくとも含まれるＩＤを生成するＩＤ生成部と、前記ＩＤから、前記機器の秘密鍵を生成する生成部と、前記ＩＤ及び前記秘密鍵を、前記ＩＤに含まれる識別子に対応する機器に配布する配布部と、を有し、前記機器は、自身の前記ＩＤ及び前記秘密鍵を用いて、他の機器との間で相互認証を行う相互認証部と、前記他の機器との間で相互認証が行われた場合、自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報とを用いて、所定の認可条件を満たすか否かを確認する確認部と、前記認可条件を満たすことが確認された場合、前記他の機器から自身への要求を認可する認可部と、を有することを特徴とする。

Description

認証認可システム、機器、認証認可方法、及びプログラム
　本発明は、認証認可システム、機器、認証認可方法、及びプログラムに関する。
　ＩｏＴ（Internet of Things）機器同士で通信を行ったり、ＩｏＴ機器とゲートウェイ機器やクラウド上のサーバ装置等とが通信を行ったりする場合には、まず、互いの正当性を確認するための認証が行われ、その後、互いの機能の利用やデータ送信等が行われる。しかしながら、認証によってすべての機能利用やデータ送信を許可することは運用上好ましくない。このため、認証後に認可を与えることで、アクセス可能な機能なデータを制限することが行われている。例えば、ＩｏＴ機器同士の通信における認証及び認可の従来技術として特許文献１に記載されている方法が知られている。
　ところで、認可情報には有効期限があるの一般的である。例えば、認可情報として電子証明書を用いる場合、電子証明書内に有効期限が明記される。この場合、認可側の機器は、ＮＴＰ（Network Time Protocol）サーバと同期した時刻情報と電子証明書内に明記された有効期限とを比較することで、その電子証明書が有効期限内であるか否かを確認する。
国際公開第２０２０／０８０５１０号
　しかしながら、例えば、リソース制約等によりＮＴＰサーバと同期した時刻情報を保持していない機器も存在する。また、例えば、ＬＰＷＡ（Low Power Wide Area）等の帯域の狭い通信環境ではすべての機器が必要かつ十分にＮＴＰサーバと通信できない場合もある。このため、ＮＴＰサーバと同期した時刻情報を参照できず、認可に関する有効期限を確認することができない場合がある。
　本発明の一実施形態は、上記の点に鑑みてなされたもので、認可に関する有効期限の確認を可能にすることを目的とする。
　上記目的を達成するため、一実施形態に係る認証認可システムは、ＩＤベース暗号を用いた認証プロトコルによる相互認証及び認可を行う複数の機器と、前記相互認証及び認可に用いられるＩＤ及び秘密鍵を生成する認証認可基盤とが含まれる認証認可システムであって、前記認証認可基盤は、前記機器の識別子と、機器に関する情報とが少なくとも含まれるＩＤを生成するＩＤ生成部と、前記ＩＤから、前記機器の秘密鍵を生成する生成部と、前記ＩＤ及び前記秘密鍵を、前記ＩＤに含まれる識別子に対応する機器に配布する配布部と、を有し、前記機器は、自身の前記ＩＤ及び前記秘密鍵を用いて、他の機器との間で相互認証を行う相互認証部と、前記他の機器との間で相互認証が行われた場合、自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報とを用いて、所定の認可条件を満たすか否かを確認する確認部と、前記認可条件を満たすことが確認された場合、前記他の機器から自身への要求を認可する認可部と、を有することを特徴とする。
　認可に関する有効期限を確認することができる。
実施例１における認証認可システムの全体構成を示す図である。 実施例１における認証認可基盤のハードウェア構成を示す図である。 実施例１における機器のハードウェア構成を示す図である。 実施例１における認証認可基盤の機能構成を示す図である。 実施例１における機器の機能構成を示す図である。 実施例１におけるＩＤ及び秘密鍵の配布処理を示すフローチャートである。 実施例１における認証認可処理を示すフローチャートである。 実施例１における認可確認処理を示すフローチャートである。 実施例２における機器の機能構成を示す図である。 実施例２における認可確認処理を示すフローチャートである。 実施例３におけるＩＤ及び秘密鍵の配布処理を示すフローチャートである。 実施例３における認可確認処理を示すフローチャートである。 実施例４における認可確認処理を示すフローチャートである。
　以下、本発明の一実施形態について説明する。本実施形態では、例えばリソース制約等によって時刻情報を保持していない機器であっても、機器同士で通信する際に相互認証と認可に関する有効期限の確認とを可能にする認証認可システム１について説明する。ここで、本実施形態に係る認証認可システム１は、機器同士で通信する際の相互認証にＩＤベース暗号による認証プロトコル（以下、「ＩＤベース認証」ともいう。）を使用し、そのＩＤの中に時刻情報を含めることで認可側の機器で有効期限の確認が可能となるように構成される。以下、本実施形態の各実施例について説明する。
　［実施例１］
　まず、実施例１について説明する。
　＜全体構成＞
　実施例１における認証認可システム１の全体構成について、図１を参照しながら説明する。図１は、実施例１における認証認可システム１の全体構成を示す図である。
　図１に示すように、実施例１における認証認可システム１には、認証認可基盤１０と、１以上の機器２０とが含まれる。また、認証認可基盤１０と各機器２０は、例えばインターネット等の通信ネットワークＮを介して通信可能に接続されている。
　認証認可基盤１０は、各機器２０を識別するデバイス識別子と時刻情報とが少なくとも含まれるＩＤを生成すると共に、そのＩＤから秘密鍵を生成するコンピュータ又はコンピュータシステムである。すなわち、認証認可基盤１０は、ＩＤベース暗号の鍵発行センタ（ＫＧＣ：Key. Generation Center）として機能する。
　機器２０は、例えば、各種センサデバイスや組込み機器、ウェアラブルデバイス、デジタル家電、監視カメラ装置、照明機器、医療機器、産業用機器等の種々のＩｏＴ機器である。機器２０は、他の機器２０との間でＩＤベース暗号を用いた認証プロトコルにより相互認証を行うと共に、認可に関する有効期限の確認を行う。このとき、各機器２０は認証認可基盤１０から配布された秘密鍵を用いて他の機器２０との間で相互認証を行うと共に、ＩＤに含まれる時刻情報を用いて認可に関する有効期限の確認を行う。
　以降では、複数の機器２０の各々を区別して表す場合は、「機器２０Ａ」、「機器２０Ｂ」等と表す。また、機器２０が他の機器２０のデータや機能等を操作（アクセスも含む）又は利用する場合、当該他の機器２０は当該機器２０の認可に関する有効期限を確認することから、当該機器２０（つまり、データの操作や機能の利用を行う側の機器２０）を「被認可側の機器２０」とも表し、当該他の機器２０（つまり、被認可側の機器２０を認可して、自身が保持するデータへの操作や機能の利用を許可する側の機器２０）を「認可側の機器２０」とも表す。なお、例えば、２台の機器２０が相互にデータや機能等の操作又は利用することもあるため、１台の機器２０が被認可側の機器２０かつ認可側の機器２０となることも有り得る。
　ここで、本実施例における機器２０は、リソースに制約があったり通信環境の帯域が狭かったりする等の理由でＮＴＰサーバと同期した時刻情報を保持していないものとする。ただし、本実施例は、ＮＴＰサーバと同期した時刻情報を保持している機器２０に対しても同様に適用可能である。
　なお、図１に示す認証認可システム１の構成は一例であって、他の構成であってもよい。例えば、機器２０の管理者等（以下、「機器管理者」ともいう。）が使用する端末が認証認可システム１に含まれていてもよい。また、機器２０が、機器２０以外の何等かの機器又は装置（例えば、ゲートウェイ機器やサーバ等）との間で認証認可を行う場合には、当該機器又は装置が認証認可システム１に含まれていてもよい。
　＜ハードウェア構成＞
　実施例１における認証認可基盤１０及び機器２０のハードウェア構成について説明する。
　　≪認証認可基盤１０≫
　実施例１における認証認可基盤１０のハードウェア構成について、図２を参照しながら説明する。図２は、実施例１における認証認可基盤１０のハードウェア構成を示す図である。
　図２に示すように、実施例１における認証認可基盤１０は、入力装置１１と、表示装置１２と、外部Ｉ／Ｆ１３と、通信Ｉ／Ｆ１４と、プロセッサ１５と、メモリ装置１６とを有する。これら各ハードウェアは、それぞれがバス１７を介して通信可能に接続されている。
　入力装置１１は、例えば、キーボードやマウス、タッチパネル等である。表示装置１２は、例えば、ディスプレイ等である。なお、認証認可基盤１０は、入力装置１１及び表示装置１２のうちの少なくとも一方を有していなくてもよい。
　外部Ｉ／Ｆ１３は、記録媒体１３ａ等とのインタフェースである。認証認可基盤１０は、外部Ｉ／Ｆ１３を介して、記録媒体１３ａの読み取りや書き込み等を行うことができる。記録媒体１３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。
　通信Ｉ／Ｆ１４は、認証認可基盤１０を通信ネットワークＮに接続するためのインタフェースである。プロセッサ１５は、例えば、ＣＰＵ（Central Processing Unit）等の各種演算装置である。メモリ装置１６は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等の各種記憶装置である。
　実施例１における認証認可基盤１０は、図２に示すハードウェア構成を有することで、後述する各種処理を実現することができる。なお、図２に示すハードウェア構成は一例であって、認証認可基盤１０は、他のハードウェア構成を有していてもよい。例えば、認証認可基盤１０は、複数のプロセッサ１５を有していてもよいし、複数のメモリ装置１６を有していてもよい。
　　≪機器２０≫
　実施例１における機器２０のハードウェア構成について、図３を参照しながら説明する。図３は、実施例１における機器２０のハードウェア構成を示す図である。
　図３に示すように、実施例１における機器２０は、通信Ｉ／Ｆ２１と、プロセッサ２２と、メモリ装置２３とを有する。これら各ハードウェアは、それぞれがバス２４を介して通信可能に接続されている。
　通信Ｉ／Ｆ２１は、機器２０を通信ネットワークＮに接続するためのインタフェースである。プロセッサ２２は、例えば、ＭＰＵ（Micro Processing Unit）やＣＰＵ等の各種演算装置である。メモリ装置２３は、例えば、ＲＡＭやＲＯＭ、フラッシュメモリ等の各種記憶装置である。
　実施例１における機器２０は、図３に示すハードウェア構成を有することで、後述する各種処理を実現することができる。なお、図３に示すハードウェア構成は一例であって、機器２０は、他のハードウェア構成を有していてもよい。例えば、機器２０は、各種ボタン等の入力装置を有していてもよいし、表示パネル等の表示装置を有していてもよい。
　＜機能構成＞
　実施例１における認証認可基盤１０及び機器２０の機能構成について説明する。
　　≪認証認可基盤１０≫
　実施例１における認証認可基盤１０の機能構成について、図４を参照しながら説明する。図４は、実施例１における認証認可基盤１０の機能構成を示す図である。
　図４に示すように、実施例１における認証認可基盤１０は、通信部１０１と、時刻管理部１０２と、デバイス情報管理部１０３と、認可条件管理部１０４と、ＩＤ生成部１０５と、登録処理部１０６と、秘密鍵生成部１０７とを有する。これら各部は、例えば、認証認可基盤１０にインストールされた１以上のプログラムがプロセッサ１５に実行させる処理により実現される。
　また、実施例１における認証認可基盤１０は、記憶部１１０を有する。記憶部１１０は、例えば、メモリ装置１６により実現される。ただし、記憶部１１０は、例えば、認証認可基盤１０と通信可能に接続される記憶装置（例えば、データベースサーバ等）により実現されていてもよい。
　通信部１０１は、各機器２０や他の装置（例えば、機器管理者が使用する端末等）との間で各種通信を行う。時刻管理部１０２は、外部のＮＴＰサーバと同期した時刻情報（つまり、現在時刻を示す情報）を管理する。デバイス情報管理部１０３は、各機器２０のデバイス識別子を管理する。なお、デバイス識別子は機器２０を識別可能な情報であれば任意の情報を用いることが可能であり、例えば、機器２０の製造固有番号やシリアルナンバー、認証認可システム１内で機器２０に対して一意に割り振られた番号等を用いることが可能である。
　認可条件管理部１０４は、各機器２０にそれぞれ対応付けて（つまり、各デバイス識別子にそれぞれ対応付けて）認可条件を管理する。認可条件とは認可側の機器２０が被認可側の機器２０を認可するための条件であり、本実施例では基準となる時刻からの有効期限を表す条件（例えば、「３日以内」や「１日以内」等）のことである。
　ＩＤ生成部１０５は、デバイス識別子と時刻情報と認可条件とが含まれるＩＤを生成する。登録処理部１０６は、例えば機器管理者が使用する端末等からの要求に応じて、この要求に係るＩＤを登録する。秘密鍵生成部１０７は、ＩＤから秘密鍵を生成する。記憶部１１０は、各種情報（例えば、時刻情報、デバイス識別子、認可条件、ＩＤ等）を記憶する。
　なお、図４に示す認証認可基盤１０の機能構成は一例であって、例えば、認証認可基盤１０は、ＩＤ生成部１０５又は登録処理部１０６のいずれか一方を有していなくてもよい。
　　≪機器２０≫
　実施例１における機器２０の機能構成について、図５を参照しながら説明する。図５は、実施例１における機器２０の機能構成を示す図である。
　図５に示すように、実施例１における機器２０は、通信部２０１と、相互認証部２０２と、認可確認部２０３とを有する。これら各部は、例えば、機器２０にインストールされた１以上のプログラムがプロセッサ２２に実行させる処理により実現される。
　また、実施例１における機器２０は、記憶部２１０を有する。記憶部２１０は、例えば、メモリ装置２３により実現される。
　通信部２０１は、他の機器２０や認証認可基盤１０等との間で各種通信を行う。相互認証部２０２は、自身のＩＤや秘密鍵等を用いて、ＩＤベース認証により他の機器２０との間で相互認証を行う。認可確認部２０３は、他の機器２０との間で相互認証に成功した場合、自身のＩＤと当該他の機器２０のＩＤとを用いて、当該他の機器２０の認可に関する有効期限を確認する。記憶部２１０は、各種情報（例えば、自身のＩＤや秘密鍵等）を記憶する。
　＜ＩＤ及び秘密鍵の配布処理＞
　実施例１におけるＩＤ及び秘密鍵の配布処理について、図６を参照しながら説明する。図６は、実施例１におけるＩＤ及び秘密鍵の配布処理を示すフローチャートである。なお、ＩＤ及び秘密鍵の配布処理は、例えば、予め決められた期間毎に定期的に実行されることが好ましい。
　ＩＤ生成部１０５は、デバイス情報管理部１０３で管理されているデバイス識別子と、時刻管理部１０２で管理されている時刻情報と、認可条件管理部１０４で当該デバイス識別子と対応付けて管理されている認可条件とを用いて、各機器２０のＩＤをそれぞれ生成する（ステップＳ１０１）。ここで、ＩＤ生成部１０５は、デバイス識別子毎に、当該デバイス識別子と、時刻情報と、当該デバイス識別子に対応する認可条件とを対応付けることでＩＤを生成する。
　例えば、デバイス識別子が「sensor01」、時刻情報が現在時刻「2020年7月21日21時37分」を示す記号列「202007212137」、認可条件が「３日以内」を表す記号列「around3days」である場合、ＩＤは「sensor01_202007212137_around3days」等とすればよい。このＩＤは、時刻「2020年7月21日21時37分」から３日以内に生成されたＩＤを持つ機器２０が、デバイス識別子「sensor01」の機器２０に対して認可されることを表している。なお、ＩＤを構成するデバイス識別子と記号列の意味は認証認可システム１全体で共有されているものとする。
　なお、各機器２０のＩＤの全部又は一部が、機器管理者が使用する端末で作成又は生成されてもよい。この場合、機器管理者が使用する端末からのＩＤ登録要求に応じて、登録処理部１０６がこれらのＩＤを登録（つまり、記憶部１１０等に保存）すればよい。このとき、ＩＤに含まれる時刻情報は端末で設定されてもよいし、認証認可基盤１０で設定し（又は設定し直し）てもよい。また、端末でＩＤが作成されるのではなく、例えば、機器管理者が認証認可基盤１０を直接操作することでＩＤが作成されてもよい。
　次に、秘密鍵生成部１０７は、上記のステップＳ１０１で生成（又は登録）された各ＩＤから秘密鍵をそれぞれ生成する（ステップＳ１０２）。ここで、秘密鍵生成部１０７は、予め決められたＩＤベース認証によりＩＤから秘密鍵を生成する。ＩＤベース認証としては任意のＩＤベース暗号による認証プロトコルを用いることができるが、例えば、ＦＳＵ（Fujioka-Suzuki-Ustaoglu）等を用いることが可能である。
　そして、通信部１０１は、上記のステップＳ１０１で生成（又は登録）された各ＩＤとそのＩＤから生成された秘密鍵とを、当該ＩＤに含まれるデバイス識別子の機器２０にそれぞれ送信（配布）する（ステップＳ１０３）。各機器２０は、自身のＩＤ及び秘密鍵を認証認可基盤１０から受信すると、当該ＩＤ及び秘密鍵を記憶部２１０に保存する。なお、通信部１０１は、任意のセキュアな方法によりＩＤ及び秘密鍵を機器２０に配布する。
　＜認証認可処理＞
　実施例１における認証認可処理について、図７を参照しながら説明する。図７は、実施例１における認証認可処理を示すフローチャートである。なお、以降では、一例として、機器２０Ｂが機器２０Ａに対してアクセスする場合を想定し、機器２０Ａと機器２０Ｂの間における認証及び認可について説明する。
　まず、機器２０Ａの相互認証部２０２と機器２０Ｂの相互認証部２０２は、認証認可基盤１０から配布されたＩＤ及び秘密鍵を用いて、予め決められたＩＤベース認証により相互認証を行う（ステップＳ２０１）。この相互認証に成功した場合は、機器２０Ａ及び機器２０Ｂは互いに相手のＩＤを入力する。
　上記のステップＳ２０１で相互認証に成功した場合、機器２０Ａの認可確認部２０３は、機器２０ＢのＩＤと自身のＩＤとを用いて機器２０Ｂの認可に関する有効期限を確認し、機器２０Ｂに認可があるか否かを判定する（ステップＳ２０２）。なお、このステップＳ２０２の処理（認可確認処理）の詳細については後述する。
　そして、上記のステップＳ２０２で認可ありと判定された場合は、機器２０Ｂの通信部２０１は、認可された動作の実行を要求する（ステップＳ２０３）。なお、本実施例では認可された動作は予め決められているものとする。
　一方で、上記のステップＳ２０１で相互認証に失敗した場合、機器２０Ａの相互認証部２０２は、機器２０Ｂからのアクセスを拒否する（ステップＳ２０４）。
　＜認可確認処理＞
　実施例１における認可確認処理（上記のステップＳ２０２の認可確認処理）について、図８を参照しながら説明する。図８は、実施例１における認可確認処理を示すフローチャートである。
　機器２０Ａの認可確認部２０３は、機器２０ＢのＩＤに含まれる時刻情報が示す時刻と、自身のＩＤに含まれる時刻情報が示す時刻との差を算出する（ステップＳ３０１）。なお、この差は、正確には、自身のＩＤに含まれる時刻情報を基準とした日時の差を意味する。
　次に、機器２０Ａの認可確認部２０３は、上記のステップＳ３０１で算出した差が、自身のＩＤに含まれる認可条件を満たすか否かを判定する（ステップＳ３０２）。
　そして、機器２０Ａの認可確認部２０３は、上記のステップＳ３０２で認可条件を満たすと判定した場合は機器２０Ｂに認可ありと判定し（ステップＳ３０３）、上記のステップＳ３０２で認可条件を満たすと判定されなかった場合は機器２０Ｂには認可なしと判定する（ステップＳ３０４）。
　例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007221630_around1day」であったとする。この場合、上記のステップＳ３０１では「202007221630」と「202007212137」との差が算出され、上記のステップＳ３０２では当該差が、認可条件「around3days」（つまり、３日以内）を満たすか否かが判定される。この例では「202007221630」と「202007212137」との差は３日以内であるため、機器２０Ｂに認可ありと判定される。
　一方で、例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007251630_around1day」であった場合、機器２０Ｂには認可なしと判定される。
　このように、本実施例では、認証認可基盤１０から配布されるＩＤ（言い換えれば、信頼できる機関から配布されるＩＤ）に時刻情報を埋め込み、認可側の機器２０で被認可側の機器２０のＩＤと自身のＩＤとの時刻情報を比較することで、認可の有無を確認する。これにより、機器２０がＮＴＰサーバと同期した時刻情報を保持していない場合であっても、認可に関する有効期限を確認することが可能になる。
　　（変形例１）
　本実施例では、認可側の機器２０は自身のＩＤを参照のみしているが、例えば、被認可側の機器２０のＩＤに含まれる時刻情報が自身のＩＤに含まれる時刻情報よりも大きい場合（つまり、被認可側の機器２０のＩＤにより進んだ時刻情報が含まれている場合）、自身のＩＤに含まれる時刻情報を、被認可側の機器２０のＩＤに含まれる時刻情報で更新してもよい。これにより、当該認可側の機器２０は、次回以降、更新後の時刻情報が含まれるＩＤを用いて、認可確認を行うことが可能となる。
　　（変形例２）
　より安全性を高めるために、認証認可基盤１０や各機器２０がセキュアなプロセッサで構成されていてもよい。セキュアなプロセッサとは実行環境がセキュア領域と非セキュア領域とに分かれて動作するプロセッサであり、一般に、通信路を介したデータのやり取りは全て非セキュア領域で行われ、非セキュア領域からセキュア領域へはアクセスすることができない仕組みになっている。この仕組みにより、セキュアなプロセッサでは、セキュア領域に保管されたデータやプログラムバイナリ等の改ざんや詐取が防止される。
　認証認可基盤１０がセキュアなプロセッサで構成されている場合、当該認証認可基盤１０が有する各機能部はセキュア領域上で実行される。同様に、機器２０がセキュアなプロセッサで構成されている場合、当該機器２０の各機能部はセキュア領域上で実行される。また、ＩＤや秘密鍵等もセキュア領域に保存される。
　　（変形例３）
　本実施例では、ＩＤに認可条件を含めているが、ＩＤの配布によって認可条件が変化しない場合はＩＤに認可条件を含めなくてもよい。この場合、各機器２０は認可条件を記憶部１１０に予め保存しておき、認可確認処理では当該認可条件を用いればよい。これにより、各ＩＤの長さを短くすることができる。例えば、デバイス識別子が「sensor01」、時刻情報が現在時刻「2020年7月21日21時37分」を示す記号列「202007212137」である場合、ＩＤは「sensor01_202007212137」等となり、ＩＤの長さを短くすることができる。
　［実施例２］
　次に、実施例２について説明する。実施例２では、ＩＤ及び秘密鍵が配布されてからの経過時間を各機器２０で計測し、当該ＩＤに含まれる時刻情報が示す時刻に当該経過時間を加算することで現在時刻を算出する場合について説明する。これにより、実施例２では、ＩＤが配布される間隔に関わらず、認可に関する有効期限をより正確に確認することが可能となる。
　なお、実施例２では、実施例１との相違点について説明し、実施例１と同様の構成要素についてはその説明を省略する。すなわち、本実施例で説明していない構成要素については実施例１と同様としてよい。
　＜機能構成＞
　　≪機器２０≫
　実施例２における機器２０の機能構成について、図９を参照しながら説明する。図９は、実施例２における機器２０の機能構成を示す図である。
　図９に示すように、実施例２における機器２０は、時間計測部２０４を更に有する。時間計測部２０４は、例えば、機器２０にインストールされた１以上のプログラムがプロセッサ２２に実行させる処理により実現される。
　時間計測部２０４は、自身のＩＤ及び秘密鍵を認証認可基盤１０から受信した時からの経過時間（つまり、当該機器２０の状態の時間的な変化）を計測する。なお、時間計測部２０４は、新たに自身のＩＤ及び秘密鍵を認証認可基盤１０から受信した場合、これまでに計測した経過時間をリセットした上で、新たに経過時間を計測する。
　＜認可確認処理＞
　実施例２における認可確認処理（図７のステップＳ２０２の認可確認処理）について、図１０を参照しながら説明する。図１０は、実施例２における認可確認処理を示すフローチャートである。なお、図１０に示す認可確認処理でも実施例１と同様に、一例として、機器２０Ａを認可側の機器２０、機器２０Ｂを被認可側の機器２０とする。
　機器２０Ａの認可確認部２０３は、自身のＩＤに含まれる時刻情報が示す時刻に対して、時間計測部２０４で計測された経過時間を加算した時刻（以下、加算後時刻ともいう。）を算出する（ステップＳ４０１）。なお、経過時間はＩＤ及び秘密鍵を受信した時から経過した時間であるため、加算後時刻は、現在時刻（又は、現在時刻に近い時刻）である。
　次に、機器２０Ａの認可確認部２０３は、機器２０ＢのＩＤに含まれる時刻情報が示す時刻と、上記のステップＳ４０１で算出された加算後時刻との差を算出する（ステップＳ４０２）。
　次に、機器２０Ａの認可確認部２０３は、上記のステップＳ４０２で算出した差が、自身のＩＤに含まれる認可条件を満たすか否かを判定する（ステップＳ４０３）。
　そして、機器２０Ａの認可確認部２０３は、上記のステップＳ４０３で認可条件を満たすと判定した場合は機器２０Ｂに認可ありと判定し（ステップＳ４０４）、上記のステップＳ４０３で認可条件を満たすと判定されなかった場合は機器２０Ｂには認可なしと判定する（ステップＳ４０５）。
　例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007221630_around1day」であり、機器２０Ａの時間計測部２０４で計測された経過時間が３時間であったとする。この場合、上記のステップＳ４０１では「202007212137」に対して３時間が加算された加算後時刻「202007220037」が算出され、上記のステップＳ４０２では「202007221630」と「202007220037」との差が算出され、上記のステップＳ４０３では当該差が、認可条件「around3days」（つまり、３日以内）を満たすか否かが判定される。この例では「202007221630」と「202007220037」との差は３日以内であるため、機器２０Ｂに認可ありと判定される。
　一方で、例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007251630_around1day」であった場合、機器２０Ｂには認可なしと判定される。
　このように、本実施例では、認可側の機器２０が自身のＩＤに含まれる時刻情報を、当該ＩＤを受信した時からの経過時間で補正する。これにより、実施例１と比較して、認可に関する有効期限をより正確に確認することが可能になる。
　　（変形例）
　本実施例では、ＩＤに時刻情報を含めているが、時刻情報の代わりに（又は、時刻情報と共に）、位置情報をＩＤに含めてもよい。すなわち、機器２０にＩＤを配布する際に、ＩＤ配布時の当該機器２０の位置を示す位置情報（又は、それに加えて現在時刻）をＩＤに含めてもよい。ＩＤに位置情報を含めることで、各機器２０は、例えば、加速度センサやＧＰＳ（Global Positioning System）等で実現される計測部により移動距離（つまり、当該機器２０の状態の位置的な変化）を計測することで、自身のＩＤに含まれる位置情報から現在位置を推定又は特定することが可能になる。したがって、例えば、機器２０Ａの認可確認部２０３は、自身の現在位置と機器２０ＢのＩＤに含まれる位置情報が示す位置との差を算出し、その差が、位置に関する認可条件を満たすか否かを判定することで、認可確認を行うようにすることもできる。なお、位置に関する認可条件とは、例えば、「距離が１００ｍ以内」等といった位置又は距離に関する条件のことである。
　なお、時刻情報や位置情報以外にも、機器に関する任意の情報（つまり、時刻や位置以外に機器の状態を表す任意の情報（例えば、電池残量、電波受信強度、製造年月日、型番、機器管理者、機器の接続先を示す情報等））が用いられてもよい。
　［実施例３］
　次に、実施例３について説明する。実施例３では、１つの機器２０に対して認可の対象が複数存在し、これら複数の認可対象に対して認可条件がそれぞれ存在する場合について説明する。ここで、認可対象とは認可側の機器２０が認可するデータや機能等のことであり、例えば、内部データの閲覧、或る特定の機能の利用等が挙げられる。
　なお、実施例３では、実施例１との相違点について説明し、実施例１と同様の構成要素についてはその説明を省略する。すなわち、本実施例で説明していない構成要素については実施例１と同様としてよい。
　＜ＩＤ及び秘密鍵の配布処理＞
　実施例３におけるＩＤ及び秘密鍵の配布処理について、図１１を参照しながら説明する。図１１は、実施例３におけるＩＤ及び秘密鍵の配布処理を示すフローチャートである。なお、ＩＤ及び秘密鍵の配布処理は、例えば、予め決められた期間毎に定期的に実行されることが好ましい。
　ＩＤ生成部１０５は、デバイス情報管理部１０３で管理されているデバイス識別子と、時刻管理部１０２で管理されている時刻情報と、認可条件管理部１０４で当該デバイス識別子と対応付けて管理されている認可対象及び認可条件とを用いて、各機器２０のＩＤをそれぞれ生成する（ステップＳ５０１）。ここで、本実施例では、認可条件管理部１０４は、デバイス識別子毎に、１以上の認可対象及びその認可条件を当該デバイス識別子と対応付けて管理しているものとする。したがって、ＩＤ生成部１０５は、デバイス識別子毎に、当該デバイス識別子と、時刻情報と、当該デバイス識別子に対応する１以上の認可対象及びその認可条件とを対応付けることでＩＤを生成する。
　例えば、デバイス識別子が「sensor01」、時刻情報が現在時刻「2020年7月21日21時37分」を示す記号列「202007212137」、１つ目の認可対象が「データ送信」を表す記号列「senddata」、認可対象「データ送信」に対応する認可条件が「３日以内」を表す記号列「around3days」、２つ目の認可対象が「機器操作」を表す記号列「attempt」、認可対象「機器操作」に対応する認可条件が「１日以内」を表す記号列「around1day」である場合、ＩＤは「sensor01_202007212137_senddata_around3days_attempt_around1day」等とすればよい。このＩＤは、時刻「2020年7月21日21時37分」から３日以内に生成されたＩＤを持つ機器２０はデバイス識別子「sensor01」の機器２０に対して「データ送信」が認可され、１日以内に生成されたＩＤを持つ機器２０は「機器操作」が認可されることを表している。なお、ＩＤを構成するデバイス識別子と記号列の意味は認証認可システム１全体で共有されているものとする。
　以降のステップＳ５０２～ステップＳ５０３は、図６のステップＳ１０２～ステップＳ１０３と同様である。
　＜認可確認処理＞
　実施例３における認可確認処理（図７のステップＳ２０２の認可確認処理）について、図１２を参照しながら説明する。図１２は、実施例３における認可確認処理を示すフローチャートである。なお、図１２に示す認可確認処理でも実施例１と同様に、一例として、機器２０Ａを認可側の機器２０、機器２０Ｂを被認可側の機器２０とする。
　機器２０Ａの認可確認部２０３は、機器２０ＢのＩＤに含まれる時刻情報が示す時刻と、自身のＩＤに含まれる時刻情報が示す時刻との差を算出する（ステップＳ６０１）。
　以降のステップＳ６０２～ステップＳ６０４は認可対象毎に実行される。
　機器２０Ａの認可確認部２０３は、上記のステップ６０１で算出した差が、自身のＩＤに含まれる認可条件のうち、当該認可対象に対応する認可条件を満たすか否かを判定する（ステップＳ６０２）。
　そして、機器２０Ａの認可確認部２０３は、上記のステップＳ６０２で認可条件を満たすと判定した場合は当該認可対象に関して機器２０Ｂに認可ありと判定し（ステップＳ６０３）、上記のステップＳ６０２で認可条件を満たすと判定されなかった場合は当該認可対象に関して機器２０Ｂには認可なしと判定する（ステップＳ６０４）。
　例えば、機器２０ＡのＩＤがＩＤは「sensor01_202007212137_senddata_around3days_attempt_around1day」、機器２０ＢのＩＤが「sensor02_202007231630_around1day」であったとする。この場合、認可対象「senddata」に関するステップＳ６０２～ステップＳ６０４と、認可対象「attempt」に関するステップＳ６０２～ステップＳ６０４とがそれぞれ実行される。一方で、「202007231630」と「202007212137」との差は、認可条件「３日以内」を満たすが、認可条件「１日以内」は満たさない。したがって、この例では、機器２０Ｂは、認可対象「senddata」に対しては認可あり、認可対象「attempt」に対しては認可なしと判定される。
　このように、本実施例では、認可対象毎にその認可条件もＩＤに含める。これにより、例えば、認可側の機器２０が保持するデータや機能のうち一部のみを認可したい場合等であっても柔軟に認可を行うことができる。
　なお、本実施例では、認可側の機器２０が認可するデータや機能等のことを認可対象として、このような認可対象を表す記号列をＩＤに含めたが、これに限られず、例えば、認可対象の識別子をＩＤに含めてもよいし、被認可側の機器２０のデバイス識別を認可対象としてＩＤに含めてもよい。
　［実施例４］
　次に、実施例４について説明する。実施例４では、認可側の機器２０が、被認可側の機器２０のＩＤに含まれる認可条件を参照して認可確認を行う場合について説明する。これにより、例えば、認可条件をＩＤの失効期限を表す条件と扱うことで、被認可側の機器２０のＩＤが失効されているか否かを確認することが可能となる。
　なお、実施例４では、実施例１との相違点について説明し、実施例１と同様の構成要素についてはその説明を省略する。すなわち、本実施例で説明していない構成要素については実施例１と同様としてよい。
　＜認可確認処理＞
　実施例４における認可確認処理（図７のステップＳ２０２の認可確認処理）について、図１３を参照しながら説明する。図１３は、実施例４における認可確認処理を示すフローチャートである。なお、図１３に示す認可確認処理でも実施例１と同様に、一例として、機器２０Ａを認可側の機器２０、機器２０Ｂを被認可側の機器２０とする。
　機器２０Ａの認可確認部２０３は、機器２０ＢのＩＤに含まれる時刻情報が示す時刻と、自身のＩＤに含まれる時刻情報が示す時刻との差を算出する（ステップＳ７０１）。
　次に、機器２０Ａの認可確認部２０３は、上記のステップＳ７０１で算出した差が、機器２０ＢのＩＤに含まれる認可条件を満たすか否かを判定する（ステップＳ７０２）。
　そして、機器２０Ａの認可確認部２０３は、上記のステップＳ７０２で認可条件を満たすと判定した場合は機器２０Ｂに認可ありと判定し（ステップＳ７０３）、上記のステップＳ７０２で認可条件を満たすと判定されなかった場合は機器２０Ｂには認可なしと判定する（ステップＳ７０４）。
　例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007221630_around1day」であったとする。この場合、上記のステップＳ７０１では「202007221630」と「202007212137」との差が算出され、上記のステップＳ７０２では当該差が、認可条件「around1day」（つまり、１日以内）を満たすか否かが判定される。この例では「202007221630」と「202007212137」との差は１日以内であるため、機器２０Ｂに認可ありと判定される。
　一方で、例えば、機器２０ＡのＩＤが「sensor01_202007212137_around3days」、機器２０ＢのＩＤが「sensor02_202007251630_around1day」であった場合、機器２０Ｂには認可なしと判定される。
　このように、本実施例では、認可側の機器２０は、被認可側の機器２０のＩＤに含まれる認可条件により認可確認を行う。これは、被認可側の機器のＩＤ２０に含まれる認可条件を、当該ＩＤの失効期限と扱っていることを意味する。これにより、例えば、被認可側の機器２０に対して新たなＩＤがしばらく配布されていない場合等に、当該被認可側の機器２０が認可されないようにすることできる。
　本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。また、上記の各実施例は、相互に矛盾の無い限り、適宜、組み合わせることが可能である。
　１　　　　認証認可システム
　１０　　　認証認可基盤
　１１　　　入力装置
　１２　　　表示装置
　１３　　　外部Ｉ／Ｆ
　１３ａ　　記録媒体
　１４　　　通信Ｉ／Ｆ
　１５　　　プロセッサ
　１６　　　メモリ装置
　１７　　　バス
　２０　　　機器
　２１　　　通信Ｉ／Ｆ
　２２　　　プロセッサ
　２３　　　メモリ装置
　２４　　　バス
　１０１　　通信部
　１０２　　時刻管理部
　１０３　　デバイス情報管理部
　１０４　　認可条件管理部
　１０５　　ＩＤ生成部
　１０６　　登録処理部
　１０７　　秘密鍵生成部
　１１０　　記憶部
　２０１　　通信部
　２０２　　相互認証部
　２０３　　認可確認部
　２０４　　時間計測部
　２１０　　記憶部
　Ｎ　　　　通信ネットワーク

Claims (8)

  1. 　ＩＤベース暗号を用いた認証プロトコルによる相互認証及び認可を行う複数の機器と、前記相互認証及び認可に用いられるＩＤ及び秘密鍵を生成する認証認可基盤とが含まれる認証認可システムであって、
    　前記認証認可基盤は、
    　前記機器の識別子と、機器に関する情報とが少なくとも含まれるＩＤを生成するＩＤ生成部と、
    　前記ＩＤから、前記機器の秘密鍵を生成する生成部と、
    　前記ＩＤ及び前記秘密鍵を、前記ＩＤに含まれる識別子に対応する機器に配布する配布部と、を有し、
    　前記機器は、
    　自身の前記ＩＤ及び前記秘密鍵を用いて、他の機器との間で相互認証を行う相互認証部と、
    　前記他の機器との間で相互認証が行われた場合、自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報とを用いて、所定の認可条件を満たすか否かを確認する確認部と、
    　前記認可条件を満たすことが確認された場合、前記他の機器から自身への要求を認可する認可部と、
    　を有することを特徴とする認証認可システム。
  2. 　前記認可条件は、自身の前記ＩＤに含まれる認可条件、前記他の機器の前記ＩＤに含まれる認可条件、又は予め決められた認可条件のいずれかである、ことを特徴とする請求項１に記載の認証認可システム。
  3. 　前記確認部は、
    　自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報との差を算出し、算出した前記差が前記認可条件を満たすか否かを確認する、ことを特徴とする請求項１又は２に記載の認証認可システム。
  4. 　前記機器は、
    　前記認証認可基盤から配布された前記ＩＤ及び前記秘密鍵を受信した時からの前記機器の状態の変化を計測する計測部を有し、
    　前記確認部は、
    　自身の前記ＩＤに含まれる機器に関する情報に対して前記変化を加えた情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報との差を算出し、算出した前記差が前記認可条件を満たすか否かを確認する、ことを特徴とする請求項１又は２に記載の認証認可システム。
  5. 　前記ＩＤには、１以上の認可の対象と前記対象にそれぞれ対応する認可情報とが含まれ、
    　前記確認部は、
    　前記対象毎に、前記対象に対応する認可条件を満たすか否かを確認する、ことを特徴とする請求項１乃至４の何れか一項に記載の認証認可システム。
  6. 　ＩＤベース暗号を用いた認証プロトコルによる相互認証及び認可を行う機器であって、
    　認証認可基盤から配布されたＩＤ及び秘密鍵を用いて、他の機器との間で相互認証を行う相互認証部と、
    　前記他の機器との間で相互認証が行われた場合、自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報とを用いて、所定の認可条件を満たすか否かを確認する確認部と、
    　前記認可条件を満たすことが確認された場合、前記他の機器から自身への要求を認可する認可部と、
    　を有することを特徴とする機器。
  7. 　ＩＤベース暗号を用いた認証プロトコルによる相互認証及び認可を行う複数の機器と、前記相互認証及び認可に用いられるＩＤ及び秘密鍵を生成する認証認可基盤とが含まれる認証認可システムにおける認証認可方法であって、
    　前記認証認可基盤が、
    　前記機器の識別子と、機器に関する情報とが少なくとも含まれるＩＤを生成するＩＤ生成手順と、
    　前記ＩＤから、前記機器の秘密鍵を生成する生成手順と、
    　前記ＩＤ及び前記秘密鍵を、前記ＩＤに含まれる識別子に対応する機器に配布する配布手順と、を実行し、
    　前記機器が、
    　自身の前記ＩＤ及び前記秘密鍵を用いて、他の機器との間で相互認証を行う相互認証手順と、
    　前記他の機器との間で相互認証が行われた場合、自身の前記ＩＤに含まれる機器に関する情報と、前記他の機器の前記ＩＤに含まれる機器に関する情報とを用いて、所定の認可条件を満たすか否かを確認する確認手順と、
    　前記認可条件を満たすことが確認された場合、前記他の機器から自身への要求を認可する認可手順と、
    　を実行することを特徴とする認証認可方法。
  8. 　コンピュータを、請求項１乃至５の何れか一項に記載の認証認可システムに含まれる認証認可基盤又は機器として機能させるプログラム。
PCT/JP2020/040126 2020-10-26 2020-10-26 認証認可システム、機器、認証認可方法、及びプログラム WO2022091183A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022558616A JPWO2022091183A1 (ja) 2020-10-26 2020-10-26
US18/249,120 US20230396614A1 (en) 2020-10-26 2020-10-26 Authentication-permission system, equipment, authentication-permission method, and program
PCT/JP2020/040126 WO2022091183A1 (ja) 2020-10-26 2020-10-26 認証認可システム、機器、認証認可方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/040126 WO2022091183A1 (ja) 2020-10-26 2020-10-26 認証認可システム、機器、認証認可方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022091183A1 true WO2022091183A1 (ja) 2022-05-05

Family

ID=81383767

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/040126 WO2022091183A1 (ja) 2020-10-26 2020-10-26 認証認可システム、機器、認証認可方法、及びプログラム

Country Status (3)

Country Link
US (1) US20230396614A1 (ja)
JP (1) JPWO2022091183A1 (ja)
WO (1) WO2022091183A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024042584A1 (ja) * 2022-08-22 2024-02-29 日本電信電話株式会社 通信システム、及び通信方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020080510A1 (ja) * 2018-10-19 2020-04-23 日本電信電話株式会社 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020080510A1 (ja) * 2018-10-19 2020-04-23 日本電信電話株式会社 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KOBYASHI N, YONEDA T: "Maintenance-free security system", THE 2010 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY, 19 January 2010 (2010-01-19) - 22 January 2010 (2010-01-22), JP , pages 1 - 5, XP008148001 *
MOROHASHI GEMBU: "Technology Development for IoT Security Strengthening", THE JOURNAL OF THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS, vol. 102, no. 5, 1 May 2019 (2019-05-01), JP , pages 458 - 462, XP009537312, ISSN: 0913-5693 *
TANIFUJI, NAOYA; KISHIMOTO, WATARU: "1A2-1 Construction and Security Analysis of Secret Handshake Scheme Based on Hierarchical ID structure", PROCEEDINGS OF THE 2012 SYMPOSIUM ON CRYPTOGRAPHY AND INFORMATION SECURITY; JANUARY 30 - FEBRUARY 2, 2012, vol. 29, 30 January 2012 (2012-01-30) - 2 February 2012 (2012-02-02), JP, pages 1 - 8, XP009537465 *
TSUCHIE, KOTA; YAO, TAKETSUGU; TERANISHI, YUUICHI; NAKAUCHI, KIYOHIDE: "Field evaluation of network access authentication time over wireless multihop networks", IEICE TECHNICAL REPORT, vol. 116, no. 146 (NS2016-65), 13 July 2016 (2016-07-13), pages 81 - 86, XP009537314 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024042584A1 (ja) * 2022-08-22 2024-02-29 日本電信電話株式会社 通信システム、及び通信方法

Also Published As

Publication number Publication date
JPWO2022091183A1 (ja) 2022-05-05
US20230396614A1 (en) 2023-12-07

Similar Documents

Publication Publication Date Title
US11924358B2 (en) Method for issuing digital certificate, digital certificate issuing center, and medium
JP7018109B2 (ja) 機器の安全なプロビジョニングと管理
US10439820B2 (en) Method and apparatus for secure access to a mobile edge computing gateway device based on a subscriber location fingerprint
EP3756328B1 (en) Identity-based certificate authority system architecture
WO2018112946A1 (zh) 注册及授权方法、装置及系统
CN101669128B (zh) 级联认证系统
JP2021504865A (ja) ゲートウェイ装置に接続された非ｉｐエンドポイントデバイスと接続されたサービスとの間のデータ転送を安全にするためのシステム及び方法
JP2019508763A (ja) ローカルデバイス認証
US20200366506A1 (en) Method for securely replacing a first manufacturer certificate already introduced into a device
KR20070097736A (ko) 지역 도메인 관리 모듈을 가진 장치를 이용하여 도메인을지역적으로 관리하는 장치 및 방법
CN102438013A (zh) 基于硬件的证书分发
JP2004072717A (ja) Ｃｒｌ発行通知機能付き認証基盤システム
US11943372B2 (en) Use right information processing device, use right information processing system, and use right information processing method, based on smart contract
CN116671062A (zh) 硬件安全模块的远程管理
WO2022091183A1 (ja) 認証認可システム、機器、認証認可方法、及びプログラム
CN108400875A (zh) 基于键值的授权认证方法、系统、电子设备、存储介质
Ghosal et al. Secure over-the-air software update for connected vehicles
WO2019163040A1 (ja) アクセス管理システム、及びそのプログラム
JP2009212689A (ja) 共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法
CN112968779A (zh) 一种安全认证与授权控制方法、控制系统、程序存储介质
JP6939313B2 (ja) 分散認証システム
CN114329534A (zh) 权限确定方法、装置、计算机设备和计算机可读存储介质
WO2020080510A1 (ja) 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム
US20230036353A1 (en) Communication network node, user equipment, communication network, method
JP2020127109A (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: 20959701

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022558616

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20959701

Country of ref document: EP

Kind code of ref document: A1