Nothing Special   »   [go: up one dir, main page]

JP7115556B2 - 認証認可システム及び認証認可方法 - Google Patents

認証認可システム及び認証認可方法 Download PDF

Info

Publication number
JP7115556B2
JP7115556B2 JP2020553332A JP2020553332A JP7115556B2 JP 7115556 B2 JP7115556 B2 JP 7115556B2 JP 2020553332 A JP2020553332 A JP 2020553332A JP 2020553332 A JP2020553332 A JP 2020553332A JP 7115556 B2 JP7115556 B2 JP 7115556B2
Authority
JP
Japan
Prior art keywords
authentication
authorization
identifier
extended identifier
extended
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2020553332A
Other languages
English (en)
Other versions
JPWO2020080510A1 (ja
Inventor
桜子 田村
彰 永井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of JPWO2020080510A1 publication Critical patent/JPWO2020080510A1/ja
Application granted granted Critical
Publication of JP7115556B2 publication Critical patent/JP7115556B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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

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)

Description

本発明は、認証認可システム及び認証認可方法に関する。
近年、ＩｏＴ（Internet of Things）機器同士で通信を行ったり、ＩｏＴ機器とゲートウェイ機器やクラウド上のサーバ装置等とが通信を行ったりする場合に、互いの正当性を確認するための認証と、ＩｏＴ機器が保持するデータや機能等へのアクセスを許可するための認可とが重要になってきている。通常、認証及び認可はそれぞれ独立に行われ、一般的には、まず認証を行って互いの正当性を確認した後に、認可情報であるアクセス可能なデータや機能等を確認する。例えば、スマートフォンが家電を操作する場合、まずスマートフォンと家電との間で認証を行って互いの正当性を確認し、互いの正当性が確認された後に、家電はスマートフォンに対して操作権限を認可する。これにより、スマートフォンで家電が操作できるようになる。
このように、ＩｏＴの分野では、認証及び認可はそれぞれ独立に行うものの、基本的には認証及び認可（以降、認証及び認可をまとめて「認証認可」とも表す。）の両方を行うことが一般的である。
ここで、ＩｏＴ機器を対象とする認証プロトコルとしては、例えば、パスワード、ＰＫＩ（Public Key Infrastructure）を用いた電子証明書、ＩＤベース暗号を用いた認証付き鍵共有プロトコル等が知られている。認証プロトコルとしてパスワードを用いた場合、各ＩｏＴ機器に対してパスワードを設定する必要があり、また定期的にパスワードを変更することが好ましいため、ＩｏＴ機器の数が膨大である場合にはその運用が困難となることがある。したがって、ＩｏＴ機器を対象とする認証プロトコルとしては、ＰＫＩを用いた電子証明書やＩＤベース暗号を用いた認証付き鍵共有プロトコルが用いられる場合が多い。なお、鍵共有プロトコルは、鍵交換プロトコルとも呼ばれる。
ところで、ＩＤベース暗号とは、任意の文字列で表されたＩＤ等の識別子を公開鍵とすることができる公開鍵暗号である。ＩｏＴ機器でＩＤベース暗号を用いる場合には、例えば、ＩｏＴ機器の製造番号や製造コード、シリアルナンバー等を公開鍵することができる。この特徴を用いて認証付き鍵共有も可能となる。
認証付き鍵共有プロトコルとは、一般に、暗号化通信のための鍵共有を行いたいデバイス（例えば、ＩｏＴ機器やサーバ装置等）同士が互いに認証を行った上で、この認証に成功した場合に共有鍵を生成するプロトコルである。認証付き鍵共有プロトコルとしては、例えば、Ｐｉｎ（Personal identification number）入力を用いた認証付きの鍵共有プロトコルであるＭ－Ｐｉｎ Ｆｕｌｌ、ペアリングベースの認証付き鍵共有プロトコルであるＦＳＵ（Fujioka-Suzuki-Ustaoglu）、Ｃｈｅｎ－Ｃｈｅｎｇ－Ｓｍａｒｔ等が知られている。認証付き鍵共有プロトコルでは、マスター秘密鍵を鍵生成センタ（ＫＧＣ：Key Generation Center、以降、「ＫＧＣ」とも表す。）が保持し、このマスター秘密鍵から各デバイスの秘密鍵が生成されることで認証が行われる。
一方で、認可プロトコルとしては、ＯＡＵＴＨ２プロトコル等が知られている。ＯＡＵＴＨ２プロトコルでは、デバイスは、認可サーバからアクセストークンを取得し、そのアクセストークンをアクセス先デバイスに提示することで、アクセス先デバイスが保持するデータや機能等を利用することができるようになる。このとき、何等かの認証によりデバイスの正当性確認を行い、この正当性が確認された後にアクセストークンが発行される。これ以外にも、ＰＫＩの枠組みで認可を実現する方法として、アクセストークンを電子証明書内に記載し、その電子証明書（以降、アクセストークンが記載された電子証明書を「権限証明書」と表す。）をアクセストークンとして用いる方法もある。ＩｏＴ機器の認証プロトコルとしてＰＫＩ（Public Key Infrastructure）を用いた電子証明書が用いられる場合、この方法を用いることで、ＰＫＩのみで認証認可が可能となる。
以上のように、デバイス同士が認証認可を行う場合は、まず何等かの認証を行って互いの正当性を確認した後に、アクセス元のデバイスがアクセストークン又は権限証明書の発行を受けて、そのアクセストークン又は権限証明書をアクセス先のデバイスに提示することで実現される。したがって、認証認可は、認証プロトコルと認可プロトコルとを様々に組み合わせることで実現することができる。
小松文子, 日本電気(株), 「プライバシ保護のためのアーキテクチャ」, IPSJ Magazine Vol.48 No.7, pp.737-743, 2017.7
ここで、ＩｏＴ機器は、消費電力の制約等から狭帯域の無線ネットワークが用いられることが多く、通信速度が遅かったり、通信が不安定であったりする場合がある。このため、ＩｏＴ機器で認証認可を行う場合には、通信負荷（つまり、通信量や通信回数等）が少ないことが望ましい。
本発明は、上記の点に鑑みてなされたもので、認証認可に伴う通信負荷を削減することを目的とする。
上記目的を達成するため、本発明の実施の形態は、複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムであって、前記サーバは、前記機器の識別子及び前記機器の認可情報を保持する保持手段と、前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、前記生成手段により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手段と、を有し、前記複数の機器の各々は、自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手段と、前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、を有することを特徴する。
認証認可に伴う通信負荷を削減することができる。
本発明の実施の形態における認証認可システムの全体構成の一例を示す図である。 本発明の実施の形態における認証認可基盤のハードウェア構成の一例を示す図である。 本発明の実施の形態における機器のハードウェア構成の一例を示す図である。 本発明の実施の形態における認証認可システムの機能構成の一例を示す図である。 本発明の実施の形態における拡張識別子の登録処理の一例を示す図である。 拡張識別子の構成の一例を示す図である。 拡張識別子の構成の一例を示す図である。 拡張識別子の構成の一例を示す図である。 本発明の実施の形態における認証認可処理の一例を示すフローチャートである。 本発明の実施の形態における相互認証処理の一例を示すフローチャートである。 本発明の実施の形態における相互認証処理の変形例を示すフローチャートである。
以下、本発明の実施の形態について説明する。本発明の実施の形態では、ＩＤベース暗号を用いた認証プロトコルによる認証を行う場合に、認証処理と認可処理とを同一の処理内で行う（言い換えれば、認証処理内で認可処理も行う）ことで、認証認可に伴う通信負荷（通信量や通信回数等）を削減することが可能な認証認可システム１について説明する。
ここで、本発明の実施の形態では、ＩＤベース暗号を用いた認証プロトコルの識別子として、認可に用いる情報（例えば、認可情報等）を含む識別子（以降では、この識別子を「拡張識別子」と表す。）を用いることで、認証認可を同一の処理内で行うことを実現する。そのため、従来のＫＧＣとは異なり、本発明の実施の形態におけるＫＧＣ（以降、「ＡｕｔｈＩＤ－ＫＧＣ」（認証認可ＩＤ＆鍵発行センタ）とも表す。）には、認可に用いる情報を管理し、拡張識別子を生成する手段と、秘密鍵の他に拡張識別子を配布する手段とが含まれる。
すなわち、例えば、機器Ａと機器Ｂとで認証認可を行う場合、機器Ａ及び機器Ｂはそれぞれ自身の拡張識別子に対応する秘密鍵を用いて相互に正当性を確認する。そして、相互に正当性が確認された場合、機器Ａ及び機器Ｂはそれぞれ相手の拡張識別子に含まれる認可情報等を参照すること、相手に認可があるか否かを確認する。ここで、拡張識別子に対応する秘密鍵はＡｕｔｈＩＤ－ＫＧＣにより生成され、各機器に予め配布される。したがって、本発明の実施の形態では、ＡｕｔｈＩＤ－ＫＧＣが拡張識別子を用いて秘密鍵を生成及び配布することで、当該拡張識別子に対応する機器に対して認可を与えている、ということができる。
このように、本発明の実施の形態では、ＩＤベース暗号を用いた認証プロトコルによる相互認証を行った後、相手の拡張識別子を参照するだけで、相手の認可を確認することができる。このため、各機器は認可のための通信負荷（例えば、認可サーバとの通信に発生する負荷等）を削減することができる。
＜全体構成＞
まず、本発明の実施の形態における認証認可システム１の全体構成について、図１を参照しながら説明する。図１は、本発明の実施の形態における認証認可システム１の全体構成の一例を示す図である。
図１に示すように、本発明の実施の形態における認証認可システム１には、認証認可基盤１０と、１台以上の機器２０とが含まれる。また、認証認可基盤１０と、各機器２０とは、例えばインターネット等の通信ネットワークＮを介して通信可能に接続されている。
認証認可基盤１０は、ＡｕｔｈＩＤ－ＫＧＣとして機能するコンピュータ又はコンピュータシステムである。認証認可基盤１０は、例えば機器２０の管理者（以降、「機器管理者」とも表す。）からの要求（拡張識別子の登録要求）に応じて、拡張識別子を認証認可基盤１０に登録すると共に、この拡張識別子から秘密鍵を生成し、当該拡張識別子に対応する機器２０に当該秘密鍵を配布する。なお、機器管理者は、例えば、認証認可基盤１０と通信ネットワークＮを介して接続される端末を用いて拡張識別子の登録要求を行っても良いし、認証認可基盤１０を操作することで拡張識別子の登録要求を行っても良い。
機器２０は、例えば、各種センサデバイスや組込み機器、ウェアラブルデバイス、デジタル家電、監視カメラ装置、照明機器、医療機器、産業用機器等の種々のＩｏＴ機器である。機器２０は、他の機器２０との間でＩＤベース暗号を用いた認証プロトコルにより認証（つまり、正当性の確認）を行って、認証認可を行う。このとき、機器２０は、認証認可基盤１０から配布された秘密鍵を用いて、他の機器２０との間で認証を行う。
以降では、複数の機器２０の各々を区別して表す場合は、「機器２０Ａ」、「機器２０Ｂ」等と表す。また、機器２０が他の機器２０のデータや機能等を操作（アクセスも含む）又は利用する場合、当該他の機器２０は当該機器２０の認可を確認することから、以降では、当該機器２０（つまり、データの操作や機能の利用を行う側の機器２０）を「被認可機器２０」、当該他の機器２０（つまり、被認可機器２０を認可して、自身がデータへの操作や機能の利用を許可する側の機器２０）を「認可機器２０」とも表す。なお、例えば、２台の機器２０が相互にデータや機能等の操作又は利用することもあるため、１台の機器２０が被認可機器２０かつ認可機器２０となることも有り得る。
なお、本発明の実施の形態における機器２０は、一般的なＰＣ（パーソナルコンピュータ）よりもハードウェア資源（例えば、プロセッサの処理性能やメモリ量等）が乏しいＩｏＴ機器等であるものとして説明するが、機器２０はＩｏＴ機器以外であっても良い。例えば、機器２０は、スマートフォンやタブレット端末等であっても良い。
なお、図１に示す認証認可システム１の構成は一例であって、他の構成であっても良い。例えば、上述した機器管理者が利用する端末が認証認可システム１に含まれていても良い。また、機器２０が、機器２０以外の何等かの機器又は装置（例えば、ゲートウェイ機器やサーバ等）との間で認証認可を行う場合には、当該機器又は装置が認証認可システム１に含まれていても良い。
＜ハードウェア構成＞
次に、本発明の実施の形態における認証認可基盤１０及び機器２０のハードウェア構成について説明する。
≪認証認可基盤１０≫
以降では、本発明の実施の形態における認証認可基盤１０のハードウェア構成について、図２を参照しながら説明する。図２は、本発明の実施の形態における認証認可基盤１０のハードウェア構成の一例を示す図である。
図２に示すように、本発明の実施の形態における認証認可基盤１０は、入力装置１１と、表示装置１２と、ＲＡＭ（Random Access Memory）１３と、ＲＯＭ（Read Only Memory）１４と、プロセッサ１５と、外部Ｉ／Ｆ１６と、通信Ｉ／Ｆ１７と、補助記憶装置１８とを有する。これら各ハードウェアは、それぞれがバス１９を介して通信可能に接続されている。
入力装置１１は、例えばキーボードやマウス、タッチパネル等であり、ユーザが各種操作を入力するのに用いられる。表示装置１２は、例えばディスプレイ等であり、ユーザに対して各種処理結果等を表示するのに用いられる。なお、認証認可基盤１０は、入力装置１１及び表示装置１２のうちの少なくとも一方を有していなくても良い。
ＲＡＭ１３は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＲＯＭ１４は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。プロセッサ１５は、例えばＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等であり、ＲＯＭ１４や補助記憶装置１８等からプログラムやデータをＲＡＭ１３上に読み出して処理を実行する演算装置である。なお、認証認可基盤１０は、プロセッサ１５として、ＣＰＵ及びＧＰＵの両方を有していても良いし、ＣＰＵ及びＧＰＵのいずれか一方のみを有していても良い。
外部Ｉ／Ｆ１６は、外部装置とのインタフェースである。外部装置には、記録媒体１６ａ等がある。記録媒体１６ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。記録媒体１６ａには、認証認可基盤１０が有する各機能を実現する１以上のプログラム等が記録されていても良い。
通信Ｉ／Ｆ１７は、認証認可基盤１０を通信ネットワークＮに接続するためのインタフェースである。認証認可基盤１０は、通信Ｉ／Ｆ１７を介して、機器２０との間でデータ通信を行うことができる。
補助記憶装置１８は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の不揮発性の記憶装置である。補助記憶装置１８には、認証認可基盤１０が有する各機能を実現する１以上のプログラム等が記憶されている。
本発明の実施の形態における認証認可基盤１０は、図２に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。なお、図２では、本発明の実施の形態における認証認可基盤１０が１台の情報処理装置（コンピュータ）で実現されている場合を示したが、これに限られない。本発明の実施の形態における認証認可基盤１０は、複数台の情報処理装置（コンピュータ）で実現されていても良い。
≪機器２０≫
以降では、本発明の実施の形態における機器２０のハードウェア構成について、図３を参照しながら説明する。図３は、本発明の実施の形態における機器２０のハードウェア構成の一例を示す図である。
図３に示すように、本発明の実施の形態における機器２０は、プロセッサ２１と、メモリ装置２２と、通信Ｉ／Ｆ２３とを有する。これら各ハードウェアは、それぞれがバス２４を介して通信可能に接続されている。
プロセッサ２１は、例えばＭＰＵ（Micro Processing Unit）やＣＰＵ等であり、メモリ装置２２からプログラムやデータを読み出して処理を実行する演算装置である。
メモリ装置２２は、例えばＲＡＭやＲＯＭ、フラッシュメモリ等であり、各種データやプログラム等を記憶する。メモリ装置２２には、本発明の実施の形態における機器２０が有する各機能を実現する１以上のプログラム等が記憶されている。
通信Ｉ／Ｆ２３は、機器２０を通信ネットワークＮに接続するためのインタフェースである。機器２０は、通信Ｉ／Ｆ２３を介して、他の機器２０や認証認可基盤１０等との間でデータ通信を行うことができる。
本発明の実施の形態における機器２０は、図３に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。
＜機能構成＞
次に、本発明の実施の形態における認証認可システム１の機能構成について、図４を参照しながら説明する。図４は、本発明の実施の形態における認証認可システム１の機能構成の一例を示す図である。
≪認証認可基盤１０≫
図４に示すように、本発明の実施の形態における認証認可基盤１０は、通信部１０１と、登録処理部１０２とを有する。これら各機能部は、認証認可基盤１０にインストールされた１以上のプログラムがプロセッサ１５に実行させる処理により実現される。
また、本発明の実施の形態における認証認可基盤１０は、記憶部１０３を有する。記憶部１０３は、例えば補助記憶装置１８等を用いて実現可能である。なお、記憶部１０３は、認証認可基盤１０と通信ネットワークＮを介して接続される記憶装置等を用いて実現されていても良い。
通信部１０１は、機器２０や他の装置（例えば、機器管理者が利用する端末等）等との間で各種通信を行う。登録処理部１０２は、例えば機器管理者からの要求（拡張識別子の登録要求）に応じて、拡張識別子を認証認可基盤１０に登録すると共に、秘密鍵の生成及び配布を行う。
ここで、拡張識別子とは、後述するように、機器２０の識別子と、認可に用いられる情報（例えば、認可情報等）とが含まれる情報である。また、機器２０の識別子とは、当該機器２０を識別する情報のことであり、例えば、機器２０の製造番号、製造コード、シリアルナンバー等である。これら以外にも、機器２０の識別子として、電話番号やメールアドレス等が用いられも良い。また、機器２０の識別子として、製造番号や製造コード、シリアルナンバー、電話番号、メールアドレス等を組み合わせた情報が用いられても良い。
記憶部１０３は、登録処理部１０２によって登録された拡張識別子が記憶される。なお、記憶部１０３には、拡張識別子以外にも、例えば、当該拡張識別子に対応する秘密鍵等が記憶されていても良い。
≪機器２０≫
図４に示すように、本発明の実施の形態における機器２０は、通信部２０１と、認証認可処理部２０２とを有する。これら各機能部は、機器２０にインストールされた１以上のプログラムがプロセッサ２１に実行させる処理により実現される。
また、本発明の実施の形態における機器２０は、記憶部２０３を有する。記憶部２０３は、例えばメモリ装置２２等を用いて実現可能である。
通信部２０１は、他の機器２０や認証認可基盤１０、他の装置等との間で各種通信を行う。認証認可処理部２０２は、自身の拡張識別子や秘密鍵等を用いて、他の機器２０との間で相互に認証を行うと共に、相手の拡張識別子を参照することで、相手に与えられた認可を確認する。
記憶部２０３は、認証認可基盤１０から配布された自身の秘密鍵や拡張識別子等を記憶する。また、記憶部２０３は、相互認証の相手の機器２０の拡張識別子や相互認証に必要な各種情報等も記憶する。
＜処理の詳細＞
次に、本発明の実施の形態における認証認可システム１の処理の詳細について説明する。
≪拡張識別子の登録処理≫
以降では、認証認可基盤１０に拡張識別子を登録する処理（拡張識別子の登録処理）について、図５を参照しながら説明する。図５は、本発明の実施の形態における拡張識別子の登録処理の一例を示す図である。
まず、登録処理部１０２は、例えば機器管理者からの拡張識別子の登録要求を受け付ける（ステップＳ１０１）。上述したように、機器管理者は、例えば、認証認可基盤１０と通信ネットワークＮを介して接続される端末を用いて拡張識別子の登録要求を行っても良いし、認証認可基盤１０を操作することで拡張識別子の登録要求を行っても良い。
ここで、被認可機器２０の拡張識別子の登録要求を行う場合、機器管理者は、当該被認可機器２０の識別子と、認可情報とを指定する。認可情報としては、認可機器２０の識別子や当該認可機器２０に対する操作権限（つまり、被認可機器２０に許可する操作等の権限）等が含まれる。更に、認可情報に有効期限を設ける場合等には、機器管理者は、当該有効期限を示す日付（又は日時）を指定しても良い。
一方で、認可機器２０の拡張識別子の登録要求を行う場合、機器管理者は、当該認可機器２０の識別子を指定する。
このように、機器管理者は、少なくとも機器２０の識別子を指定することで、拡張識別子の登録要求を行う。なお、或る機器２０が被認可機器２０であると同時に認可機器２０である場合も有り得る。この場合は、当該或る機器２０の拡張識別子の登録要求には、認可情報等が指定される。
次に、登録処理部１０２は、上記のステップＳ１０１で受け付けた拡張識別子の登録要求に基づいて、拡張識別子を作成し、記憶部１０３に保存する（ステップＳ１０２）。
ここで、拡張識別子の構成の一例について、図６を参照しながら説明する。図６は、拡張識別子の構成の一例を示す図である。
図６Ａは、被認可機器２０の拡張識別子であり、当該被認可機器２０の識別子と、日付と、認可情報とで構成されている。また、認可情報には、認可機器２０の識別子が含まれている。この拡張識別子は、被認可機器２０と認可機器２０とで相互認証が成功した場合に、被認可機器２０から認可機器２０へのアクセスが許可（認可）されることを示している。なお、日付は、認可情報の有効期限であっても良いし、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図６Ａの拡張識別子は、例えば、被認可機器２０の識別子の「＃Ａ」、日付を「ＹＹＹＹＭＭＤＤ」、認可機器２０の識別子を「＃Ｂ」とした場合、「＃Ａ＿ＹＹＹＹＭＭＤＤ＿＃Ｂ」等と表すことができる。
図６Ｂは、被認可機器２０の拡張識別子であり、当該被認可機器２０の識別子と、日付と、認可情報とで構成されている。また、認可情報には、認可機器２０の識別子と、当該認可機器２０への許可動作とが含まれている。この拡張識別子は、被認可機器２０と認可機器２０とで相互認証が成功した場合に、被認可機器２０から認可機器２０に対して、当該許可動作に指定されている動作（例えば、データの操作や機能の利用等）が許可（認可）されることを示している。なお、日付は、上記と同様に、認可情報の有効期限であっても良いし、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図６Ｂの拡張識別子は、例えば、被認可機器２０の識別子の「＃Ａ」、日付を「ＹＹＹＹＭＭＤＤ」、認可機器２０の識別子を「＃Ｂ」、許可動作を「＃ＯＰＥＮ」（例えば、ファイル参照）とした場合、「＃Ａ＿ＹＹＹＹＭＭＤＤ＿＃Ｂ＿＃ＯＰＥＮ」等と表すことができる。
図６Ｃは、認可機器２０の拡張識別子であり、当該認可機器２０の識別子と、日付とで構成されている。なお、日付は、拡張識別子の生成日であっても良いし、拡張識別子自体の有効期限であっても良いし、又はこれらの組み合わせであっても良い。
図６Ｃの拡張識別子は、例えば、認可機器２０の識別子の「＃Ｂ」、日付を「ＹＹＹＹＭＭＤＤ」とした場合、「＃Ｂ＿ＹＹＹＹＭＭＤＤ」等と表すことができる。
このように、被認可機器２０の拡張識別子（例えば図６Ａや図６Ｂ）には、当該被認可機器２０の識別子に対して、当該被認可機器２０の認可情報が対応付けられている。これにより、認可機器２０は、この認可情報を参照することで、被認可機器２０に対してデータの操作や機能の利用等の認可することができるようになる。なお、上記の図６Ｂでは、一例として、拡張識別子の認可情報に許可動作が含まれる場合を示したが、認可情報には、これ以外にも、種々の情報が含まれていても良い。例えば、被認可機器２０に対して禁止する操作や機能等を明示的に指定したい場合には、禁止動作が含まれていても良い。また、認可情報には、例えば、当該認可情報が失効しているか否かを示す失効情報が含まれていても良い。
次に、登録処理部１０２は、上記のステップＳ１０２で作成した拡張識別子から秘密鍵を生成する（ステップＳ１０３）。
最後に、登録処理部１０２は、機器２０に対して、当該機器２０の拡張識別子と、当該拡張識別子から生成された秘密鍵とを配布する（ステップＳ１０４）。このとき、拡張識別子は全ての機器２０に対して配布（又は公開）されても良いし、被認可機器２０の拡張識別子が認可機器２０に対して配布（又は公開）されるようにしても良い。
これにより、当該機器２０の記憶部２０３には、認証認可基盤１０から配布された拡張識別子及び秘密鍵が保存される。なお、認証認可基盤１０から機器２０へ拡張識別子及び秘密鍵を配布する方法としては、例えば、通信部１０１により通信ネットワークＮを介して配布されても良いし、外部記録媒体等を介して配布されても良い。
以上のように、機器２０の識別子が含まれる拡張識別子が認証認可基盤１０に登録され、当該機器２０に対して、当該拡張識別子と、当該拡張識別子から生成された秘密鍵とが配布される。
≪認証認可処理≫
以降では、機器２０同士で認証及び認可を行う処理（認証認可処理）について、図７を参照しながら説明する。図７は、本発明の実施の形態における認証認可処理の一例を示すフローチャートである。
図７に示す認証認可処理では、一例として、被認可機器２０を「機器２０Ａ」、認可機器２０を「機器２０Ｂ」として、機器２０Ａと機器２０Ｂとの間で認証認可処理を行う場合について説明する。また、一例として、ＩＤベース暗号を用いた認証付き鍵共有プロトコルであるＦＳＵを用いて、機器２０Ａと機器２０Ｂとの間の相互認証を行うものとする。
（記号の定義）
以降で用いる記号を次のように定義する。
ＩＤＡ：機器２０Ａの拡張識別子
ＩＤＢ：機器２０Ｂの拡張識別子
ＤＡ，１：機器２０Ａの秘密鍵
ＤＢ，２：機器２０Ｂの秘密鍵
ｋ：セキュリティパラメータ
ｐ，ｑ：ｐ≠ｑを満たす素数
Ｇ１：有限体Ｆｐ上の楕円曲線Ｅ１：＝Ｅ（Ｆｐ）における部分群
Ｇ２：Ｆｐのｋ次拡大体上の楕円曲線
Figure 0007115556000001
 における部分群
ｇ１：Ｇ１の生成元
ｇ２：Ｇ２の生成元
Ｚｑ：ｑを法とする剰余類
ｚ∈Ｚｑ：マスター秘密鍵
Ｚｖ＝ｚｇｖ∈Ｇｖ（ｖ＝１，２）：マスター公開鍵
Ｈ１：文字列（すなわち、オクテット列）からＧ１上の元を生成する関数
Ｈ２：文字列からＧ２上の元を生成する関数
Ｈ：鍵導出関数
ｅ：ＢＮ（Barret-Naehrig）曲線上のＯｐｔｉｍａｌ Ａｔｅペアリング
なお、ＢＮ曲線上のＯｐｔｉｍａｌ Ａｔｅペアリングについては、例えば、以下の参考文献１を参照されたい。
［参考文献１］
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.
ここで、上記で定義した各記号のうち、マスター秘密鍵ｚ、秘密鍵ＤＡ，１及びＤＢ，２以外は公開情報であるものとする。
まず、機器２０Ａと機器２０Ｂとの間で相互認証（ＦＳＵを用いた相互認証）を行う（ステップＳ２０１）。ＦＳＵを用いた相互認証の処理の詳細については後述する。
上記のステップＳ２０１での相互認証が成功した場合（すなわち、機器２０Ａと機器２０Ｂとの間で互いに正当性が確認された場合）、機器２０Ｂの認証認可処理部２０２は、機器２０Ａの拡張識別子ＩＤＡに含まれる認可情報を参照して、当該機器２０Ａを認可する（ステップＳ２０２）。すなわち、機器２０Ｂの認証認可処理部２０２は、当該認可情報に応じて、当該機器２０Ａからの要求（例えば、データの操作要求や機能の実行要求等）を許可する。例えば、機器２０Ｂの認証認可処理部２０２は、自身の識別子のみが当該認可情報に指定されている場合、機器２０Ａに対して、自身へのアクセスを認可（許可）する。また、例えば、機器２０Ｂの認証認可処理部２０２は、自身の識別子と、許可動作とが当該認可情報に指定されている場合、機器２０Ａに対して、当該許可動作が示す動作（例えば、データの操作や機能の利用等）を認可（許可）する。
なお、機器２０Ｂの認証認可処理部２０２は、拡張識別子ＩＤＡに含まれる日付を参照して、認可情報が有効期限内であるか否かを判定し、有効期限内である場合にのみ機器２０Ａを認可しても良い。又は、機器２０Ｂの認証認可処理部２０２は、拡張識別子ＩＤＡの認可情報に禁止動作や失効情報等が含まれる場合には、これらの情報を参照して、禁止動作以外を認可（許可）したり、認可情報が失効しているか否かを判定したりしても良い。
次に、機器２０Ａは、通信部２０１を介して、上記のステップＳ２０２で認可された動作（例えば、データの操作や機能の利用等）を機器２０Ｂに対して実行する（ステップＳ２０３）。すなわち、機器２０Ａの通信部２０１は、上記のステップＳ２０２で認可された動作に応じて、データの操作要求や機能実行要求等を機器２０Ｂに送信する。
一方で、上記のステップＳ２０１での相互認証が失敗した場合（すなわち、機器２０Ａ及び機器２０Ｂの少なくとも一方の機器２０で正当性が確認されなかった場合）、機器２０Ｂの認証認可処理部２０２は、機器２０Ｂからのアクセスを拒否する（ステップＳ２０４）。
以上のように、認可機器２０と被認可機器２０との間で相互認証が成功した場合、認可機器２０は、被認可機器２０の拡張識別子に含まれる認可情報を参照することで、この被認可機器２０の所定の動作（例えば、データの操作や機能の利用等）を認可することができる。このため、認可機器２０及び被認可機器２０は認可のための通信（例えば、認可サーバへの通信等）を行う必要がなくなり、通信負荷を削減することができる。
≪相互認証処理（ＦＳＵ）≫
次に、上記のステップＳ２０１の相互認証処理の詳細について、図８を参照しながら説明する。図８は、本発明の実施の形態における相互認証処理の一例を示すフローチャートである。
ここで、上述したように、秘密鍵ＤＡ，１及びＤＢ，２は認証認可基盤１０により生成される。これらの秘密鍵ＤＡ，１及びＤＢ，２は、認証認可基盤１０の登録処理部１０２が以下を計算することにより生成される。
ＤＡ，１＝ｚＱＡ，１＝ｚＨ１（ＩＤＡ）∈Ｇ１
ＤＢ，２＝ｚＱＢ，２＝ｚＨ２（ＩＤＢ）∈Ｇ２
また、ＱＡ，１＝Ｈ１（ＩＤＡ）及びＱＢ，２＝Ｈ２（ＩＤＢ）は、認証認可基盤１０から機器２０Ａ及び機器２０Ｂに配布（又は公開）されているものとする。ただし、ＱＡ，１＝Ｈ１（ＩＤＡ）及びＱＢ，２＝Ｈ２（ＩＤＢ）は、機器２０Ａ及び機器２０Ｂでそれぞれ計算されても良い。
なお、上記の秘密鍵ＤＡ，１及びＤＢ，２の計算方法に示されるように、認証認可基盤１０の登録処理部１０２は、ＱＡ，１及びＱＢ，２をそれぞれｚ倍することで秘密鍵ＤＡ，１及びＤＢ，２をそれぞれ生成している。このため、認証認可基盤１０の登録処理部１０２は、秘密鍵を生成するための計算を、ＣＰＵの代わりにＧＰＵを用いて並列実行することで、多数の拡張識別子に対して秘密鍵を効率的に生成することができる。また、この場合、一般にＧＰＵはＣＰＵに比べて安価であることが多いため、認証認可基盤１０の構築に要するコストも削減することができるようになる。
機器２０Ａの認証認可処理部２０２は、短期秘密鍵ｘＡ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＡ，１＝ｘＡｇ１と短期公開鍵ＸＡ，２＝ｘＡｇ２とを計算する（ステップＳ３０１）。これにより、短期秘密鍵ｘＡと、短期公開鍵ＸＡ，１及びＸＡ，１とが生成される。なお、短期秘密鍵ｘＡと、短期公開鍵ＸＡ，１及びＸＡ，１とは、例えば、機器２０Ａの記憶部２０３に記憶される。
機器２０Ｂの認証認可処理部２０２は、短期秘密鍵ｘＢ∈Ｚｑをランダムに選択した上で、短期公開鍵ＸＢ，１＝ｘＢｇ１と短期公開鍵ＸＢ，２＝ｘＢｇ２とを計算する（ステップＳ３０２）。これにより、短期秘密鍵ｘＢと、短期公開鍵ＸＢ，１及びＸＢ，１とが生成される。なお、短期秘密鍵ｘＢと、短期公開鍵ＸＢ，１及びＸＢ，１とは、例えば、機器２０Ｂの記憶部２０３に記憶される。
機器２０Ａの通信部２０１は、拡張識別子ＩＤＡと、拡張識別子ＩＤＢと、短期公開鍵ＸＡ，１と、短期公開鍵ＸＡ，２とを機器２０Ｂに送信する（ステップＳ３０３）。
機器２０Ｂの認証認可処理部２０２は、楕円曲線Ｅ１及びＸＡ，２に関するＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値と、楕円曲線Ｅ２及びＸＡ，１に関するＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値とが共に１であり、かつ、ｅ（ＸＡ，１，ｇ２）＝ｅ（ｇ１，ＸＡ，２）であるか否かを確認する（ステップＳ３０４）。ここで、ＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数は、引数として楕円曲線Ｅと点Ｐとが指定される関数であり、点Ｐが楕円曲線Ｅ上の点である場合に１、そうでない場合に０となる関数である。
なお、上記のステップＳ３０４において、ＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値が０又はｅ（ＸＡ，１，ｇ２）≠ｅ（ｇ１，ＸＡ，２）である場合、相互認証処理が失敗したものとして、処理を終了するか又は上記のステップＳ３０１からやり直す。以降では、上記のステップＳ３０４において、ＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値が共に１で、かつ、ｅ（ＸＡ，１，ｇ２）＝ｅ（ｇ１，ＸＡ，２）であると確認されたものとする。
機器２０Ｂの認証認可処理部２０２は、以下により共有値σ１，σ２，σ３，σ４を計算する（ステップＳ３０５）。
σ１＝ｅ（ＱＡ，１，ＤＢ，２）
σ２＝ｅ（ＱＡ，１＋ＸＡ，１，ＤＢ，２＋ｘＢＺ２）
σ３＝ｘＢＸＡ，１
σ４＝ｘＢＸＡ，２
次に、機器２０Ｂの通信部２０１は、拡張識別子ＩＤＡと、拡張識別子ＩＤＢと、短期公開鍵ＸＢ，１と、短期公開鍵ＸＢ，２とを機器２０Ａに送信する（ステップＳ３０６）。
機器２０Ａの認証認可処理部２０２は、楕円曲線Ｅ１及びＸＢ，２に関するＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値と、楕円曲線Ｅ２及びＸＢ，１に関するＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値とが共に１であり、かつ、ｅ（ＸＢ，１，ｇ２）＝ｅ（ｇ１，ＸＢ，２）であるか否かを確認する（ステップＳ３０７）。
なお、上記のステップＳ３０７において、ＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値が０又はｅ（ＸＢ，１，ｇ２）≠ｅ（ｇ１，ＸＢ，２）である場合、相互認証処理が失敗したものとして、処理を終了するか又は上記のステップＳ３０１からやり直す。以降では、上記のステップＳ３０７において、ＧＲＯＵＰＭＥＭＢＥＲＳＨＩＰＴＥＳＴ関数値が共に１で、かつ、ｅ（ＸＢ，１，ｇ２）＝ｅ（ｇ１，ＸＢ，２）であると確認されたものとする。
機器２０Ａの認証認可処理部２０２は、以下により共有値σ１，σ２，σ３，σ４を計算する（ステップＳ３０８）。
σ１＝ｅ（ＤＡ，１，ＱＢ，２）
σ２＝ｅ（ＤＡ，１＋ｘＡＺ１，ＱＢ，２＋ＸＢ，２）
σ３＝ｘＡＸＢ，１
σ４＝ｘＡＸＢ，２
次に、機器２０Ａの認証認可処理部２０２は、以下によりｓｉｄを計算する（ステップＳ３０９）。なお、ｓｉｄはセッションＩＤである。
Figure 0007115556000002
 また、機器Ｂの認証認可処理部２０２は、上記のステップＳ３０９と同様に、以下によりｓｉｄを計算する（ステップＳ３１０）。
Figure 0007115556000003
 機器２０Ａの認証認可処理部２０２は、以下により共有鍵Ｋを生成する（ステップＳ３１１）。
Figure 0007115556000004
 なお、この共有鍵Ｋは、例えば、機器２０Ａの記憶部２０３に記憶される。
また、機器２０Ｂの認証認可処理部２０２は、上記のステップＳ３１１と同様に、以下により共有鍵Ｋを生成する（ステップＳ３１２）。
Figure 0007115556000005
 なお、この共有鍵Ｋは、例えば、機器２０Ｂの記憶部２０３に記憶される。
これにより、機器２０Ａと機器２０Ｂとの間で共有鍵Ｋが共有される。そして、機器２０Ａと機器２０Ｂとは、この共有鍵Ｋにより相互認証を行う（ステップＳ３１３）。
以上のように、ＦＳＵを用いて、機器２０Ａと機器２０Ｂとの間で相互認証を行うことができる。ここで、上記のステップＳ３０８で機器２０Ａが計算するσ１に着目すると、σ１＝ｅ（ＤＡ，１，ＱＢ，２）となっている。このため、機器２０Ａが接続する接続先のＱＢ，２（＝Ｈ２（ＩＤＢ））が固定的な場合には、このσ１を一度計算した上で、その計算結果を記憶部２０３等に保持しておくことで、次回の計算ではσ１の計算を省略することができる。また、ＱＢ，２自体は公開情報であるため、ＱＢ，２が一定の規則で生成される場合は当該ＱＢ，２を事前に計算した上で、σ１も事前に計算しておくことも可能である。
これにより、機器２０Ａは、相互認証に要する処理を効率的に行うことができるようになる。特に、機器２０Ａは、一般的なＰＣ等よりもハードウェア資源が乏しいＩｏＴ機器等であるため、σ１を事前に計算しておくこと等により、相互認証に要する処理をより効率的に行うことができる（つまり、ＣＰＵの処理負荷を少なくすることができると共に、高速に実行することができる）ようになる。
＜相互認証処理の変形例＞
以降では、図７のステップＳ２０１の相互認証処理の変形例として、機器２０間の通信量がより少なくなり、かつ、各機器２０での計算量がより少なくなるようにＦＳＵを改良したプロトコルによって相互認証処理を行う場合について説明する。
（記号の定義）
まず、本変形例で用いる記号を次のように定義する。
ＩＤＡ：機器２０Ａの拡張識別子
ＩＤＢ：機器２０Ｂの拡張識別子
ＤＡ：機器２０Ａの秘密鍵
ＤＢ：機器２０Ｂの秘密鍵
ｋ：セキュリティパラメータ
ｐ，ｑ：ｐ≠ｑを満たす素数
Ｇ１：有限体Ｆｐ上の楕円曲線Ｅ１：＝Ｅ（Ｆｐ）における部分群
Ｇ２：Ｆｐのｋ次拡大体上の楕円曲線
Figure 0007115556000006
 における部分群
ｇ１：Ｇ１の生成元
ｇ２：Ｇ２の生成元
Ｚｑ：ｑを法とする剰余類
ｚ∈Ｚｑ：マスター秘密鍵
Ｚ＝ｚｇ１∈Ｇ１：マスター公開鍵
Ｈ１：文字列（すなわち、オクテット列）からＺｑ上の元を生成する関数
Ｈ２：文字列からＺｑ上の元を生成する関数
Ｈ３：文字列からＺｑ上の元を生成する関数
Ｈ：鍵導出関数
Ｋ：共有鍵
ｅ：Ｇ１×Ｇ２上で定義されたペアリング演算
ここで、上記で定義した各記号のうち、マスター秘密鍵ｚ、秘密鍵ＤＡ及びＤＢ以外は公開情報であるものとする。なお、Ｇ１とＧ２とは逆であっても良い。また、群の元やＺｑの元を関数に入力する場合には、当該元を表す文字列を関数に入力するものとする。
また、上述したように、秘密鍵ＤＡ及びＤＢは認証認可基盤１０により生成される。これらの秘密鍵ＤＡ及びＤＢは、認証認可基盤１０の登録処理部１０２が以下を計算することにより生成される。
Figure 0007115556000007
Figure 0007115556000008
 ここで、ｉＡ＝Ｈ１（ＩＤＡ）、ｉＢ＝Ｈ１（ＩＤＢ）である。これらｉＡ及びｉＢは、認証認可基盤１０で生成されても良いし、機器２０で生成されても良い。すなわち、例えば、秘密鍵ＤＡを生成する際に、認証認可基盤１０でｉＡを生成しても良いし、機器２０ＡでｉＡを生成して認証認可基盤１０に公開しても良い。同様に、例えば、秘密鍵ＤＢを生成する際に、認証認可基盤１０でｉＢを生成しても良いし、機器２０ＢでｉＢを生成して認証認可基盤１０に公開しても良い。なお、機器２０Ａ及び機器２０ＢのそれぞれでｉＡ及びｉＢを生成することが簡便であるが、例えば、機器２０の計算リソースが限られており、Ｈ１の計算に多くの計算リソースが必要な場合等には認証認可基盤１０でｉＡ及びｉＢを生成することが好ましい。
≪相互認証処理の変形例≫
次に、図７のステップＳ２０１の相互認証処理の変形例について、図９を参照しながら説明する。図９は、本発明の実施の形態における相互認証処理の変形例を示すフローチャートである。
機器２０Ａの認証認可処理部２０２は、ｒＡ∈Ｚｑをランダムに選択した上で、短期秘密鍵
Figure 0007115556000009
 を生成すると共に、短期公開鍵ＸＡ＝ｘＡ（ｚ＋ｉＢ）ｇ１を生成する（ステップＳ４０１）。なお、短期秘密鍵ｘＡ及び短期公開鍵ＸＡは、例えば、機器２０Ａの記憶部２０３に記憶される。
同様に、機器２０Ｂの認証認可処理部２０２は、ｒＢ∈Ｚｑをランダムに選択した上で、短期秘密鍵
Figure 0007115556000010
 を生成すると共に、短期公開鍵ＸＢ＝ｘＢ（ｚ＋ｉＡ）ｇ１を生成する（ステップＳ４０２）。なお、短期秘密鍵ｘＢ及び短期公開鍵ＸＢは、例えば、機器２０Ｂの記憶部２０３に記憶される。
次に、機器２０Ａの通信部２０１は、拡張識別子ＩＤＡと短期公開鍵ＸＡとを機器２０Ｂに送信する（ステップＳ４０３）。なお、このとき、機器２０Ａの通信部２０１は、拡張識別子ＩＤＢも機器２０Ｂに送信しても良い。
同様に、機器２０Ｂの通信部２０１は、拡張識別子ＩＤＢと短期公開鍵ＸＢとを機器２０Ａに送信する（ステップＳ４０４）。なお、このとき、機器２０Ｂの通信部２０１は、拡張識別子ＩＤＡも機器２０Ａに送信しても良い。
次に、機器２０Ａの認証認可処理部２０２は、上記のステップＳ４０１で生成した短期秘密鍵ｘＡを記憶部２０３から削除する（ステップＳ４０５）。同様に、機器２０Ｂの認証認可処理部２０２は、上記のステップＳ４０２で生成した短期秘密鍵ｘＢを記憶部２０３から削除する（ステップＳ４０６）。
なお、上記のステップＳ４０５及びステップＳ４０６で短期秘密鍵ｘＡ及び短期秘密鍵ｘＢをそれぞれ削除しているが、これは、他方の機器２０から拡張識別子及び短期公開鍵を受信するまでの間に短期秘密鍵が流出することを防止するためである。すなわち、例えば、機器２０Ａが拡張識別子ＩＤＡ及び短期公開鍵ＸＡを機器２０Ｂに送信した後、機器２０Ａが拡張識別子ＩＤＢ及び短期公開鍵ＸＢを機器２０Ｂから受信するまでの間には或る程度の時間を要することがある。このため、この時間の間における短期秘密鍵ｘＡの流出を防止するために、機器２０Ａは、拡張識別子ＩＤＡ及び短期公開鍵ＸＡを機器２０Ｂに送信した後、短期秘密鍵ｘＡを削除している。短期秘密鍵ｘＢを削除している理由についても同様である。ただし、短期秘密鍵ｘＡ及びｘＢを削除しない運用も可能である（つまり、ステップＳ４０５～ステップＳ４０６と、後述するステップＳ４０７～ステップＳ４０８とを実行しない運用も可能である。）。
ここで、機器２０Ａは、拡張識別子ＩＤＢ及び短期公開鍵ＸＢを機器２０Ｂから受信した時点で、以降のステップＳ４０５、ステップＳ４０７、ステップＳ４０９、ステップＳ４１１、ステップＳ４１３及びステップＳ４１５を実行可能である。同様に、機器２０Ｂは、拡張識別子ＩＤＡ及び短期公開鍵ＸＡを機器２０Ａから受信した時点で、以降のステップＳ４０６、ステップＳ４０８、ステップＳ４１０、ステップＳ４１２、ステップＳ４１４及びステップＳ４１６を実行可能である
機器２０Ａの認証認可処理部２０２は、短期秘密鍵
Figure 0007115556000011
 を再度生成する（ステップＳ４０７）。なお、短期秘密鍵ｘＡは、機器２０Ａの記憶部２０３に記憶される。
同様に、機器２０Ｂの認証認可処理部２０２は、短期秘密鍵
Figure 0007115556000012
 を再度生成する（ステップＳ４０８）。なお、短期秘密鍵ｘＢは、機器２０Ｂの記憶部２０３に記憶される。
次に、機器２０Ａの認証認可処理部２０２は、以下により公開情報ｄＡ及びｄＢを生成する（ステップＳ４０９）。
ｄＡ＝Ｈ３（ＸＡ，ＩＤＡ，ＩＤＢ）
ｄＢ＝Ｈ３（ＸＢ，ＩＤＡ，ＩＤＢ）
同様に、機器２０Ｂの認証認可処理部２０２は、以下により公開情報ｄＡ及びｄＢを生成する（ステップＳ４１０）。
ｄＡ＝Ｈ３（ＸＡ，ＩＤＡ，ＩＤＢ）
ｄＢ＝Ｈ３（ＸＢ，ＩＤＡ，ＩＤＢ）
ここで、上記のステップＳ４０９及びステップＳ４１０では公開情報ｄＡ及びｄＢを機器２０Ａ及び機器２０Ｂが生成するものとしたが、認証認可基盤１０が生成しても良い。機器２０Ａ及び機器２０Ｂのそれぞれで公開情報ｄＡ及びｄＢを生成することが簡便であるが、例えば、機器２０の計算リソースが限られており、Ｈ３の計算に多くの計算リソースが必要な場合等には認証認可基盤１０で公開情報ｄＡ及びｄＢを生成することが好ましい。なお、公開情報ｄＡ及びｄＢが生成されるタイミングは、短期公開鍵ＸＡ及びＸＢの生成後、後述する共有値σの生成前であれば、任意のタイミングで良い。
次に、機器２０Ａの認証認可処理部２０２は、以下により共有値σを計算する（ステップＳ４１１）。
ＦＡ＝（ｘＡ＋ｄＡ）（ＸＢ＋ｄＢ（ｚ＋ｉＡ）ｇ１）
σ＝ｅ（ＦＡ，ＤＡ）
同様に、機器２０Ｂの認証認可処理部２０２は、以下により共有値σを計算する（ステップＳ４１２）。
ＦＢ＝（ｘＢ＋ｄＢ）（ＸＡ＋ｄＡ（ｚ＋ｉＢ）ｇ１）
σ＝ｅ（ＦＢ，ＤＢ）
次に、機器２０Ａの認証認可処理部２０２は、以下によりｓｉｄを計算する（ステップＳ４１３）。
Figure 0007115556000013
 同様に、機器２０Ｂの認証認可処理部２０２は、以下によりｓｉｄを計算する（ステップＳ４１４）。
Figure 0007115556000014
 機器２０Ａの認証認可処理部２０２は、以下により共有鍵Ｋを生成する（ステップＳ４１５）。
Figure 0007115556000015
 なお、この共有鍵Ｋは、例えば、機器２０Ａの記憶部２０３に記憶される。
同様に、機器２０Ｂの認証認可処理部２０２は、以下により共有鍵Ｋを生成する（ステップＳ４１６）。
Figure 0007115556000016
 なお、この共有鍵Ｋは、例えば、機器２０Ｂの記憶部２０３に記憶される。
これにより、機器２０Ａと機器２０Ｂとの間で共有鍵Ｋが共有される。そして、機器２０Ａと機器２０Ｂとは、この共有鍵Ｋにより相互認証を行う（ステップＳ４１７）。
以上のように、機器２０間の通信量がより少なくなり、かつ、各機器２０での計算量がより少なくなるようにＦＳＵを改良したプロトコルを用いて、機器２０Ａと機器２０Ｂとの間で相互認証を行うことができる。ここで、本変形例では、図８で説明した相互認証処理と比較すると、機器２０Ａと機器２０Ｂとの間で送受信される短期公開鍵がＸＡ及びＸＢのみであるため、機器２０Ａと機器２０Ｂとの間の通信量を削減することが可能となる。また、機器２０Ａ及び機器２０Ｂでのペアリング演算の回数がそれぞれ１回であるため、機器２０Ａ及び機器２０Ｂの計算量も削減することが可能となる。このため、機器２０がＩｏＴ機器等である場合であっても、相互認証に要する処理をより効率的に行うことができるようになる。
＜まとめ＞
以上のように、本発明の実施の形態における認証認可システム１では、被認可機器２０と認可機器２０との間で相互認証を行った後、認可機器２０が被認可機器２０の拡張識別子を参照することで、認可機器２０から被認可機器２０への認可を行うことができる。このため、本発明の実施の形態における認証認可システム１によれば、認可機器２０及び被認可機器２０は認可のための通信（例えば、認可サーバへの通信等）を行う必要がなくなり、通信負荷を削減することができる。
また、各機器２０の認可情報が拡張識別子に含まれているため、例えば機器管理者は、この拡張識別子に含まれる認可情報を変更や更新等するだけで、各機器２０間での認可を容易に制御することができる。
更に、通常、認証サーバと認可サーバとが別々に構築されることが一般的であるが、本発明の実施の形態における認証認可システム１では、認証及び認可を認証認可基盤１０のみで実現することができる。このため、例えば、認証サーバと認可サーバとの間の連携が不要になり、認証及び認可に必要なサーバの構築を容易に行うこともできるようになる。したがって、例えば、多数の機器２０を用いて実験的に何等かの処理を試行するような環境を構築する場合にも、本発明の実施の形態における認証認可システム１を用いることで、容易に環境を構築することもできるようになる。
なお、上記の実施の形態では、機器２０同士で、一方が被認可側、他方が認可側であるものとして認証認可を行う場合について説明したが、これに限られず、例えば、認可側はサーバ装置等であっても良い。
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変形が可能である。
本願は、日本国に２０１８年１０月１９日に出願された基礎出願２０１８－１９７８７５号に基づくものであり、その全内容はここに参照をもって援用される。
１ 認証認可システム
１０ 認証認可基盤
２０ 機器
１０１ 通信部
１０２ 登録処理部
１０３ 記憶部
２０１ 通信部
２０２ 認証認可処理部
２０３ 記憶部
Ｎ 通信ネットワーク

Claims (5)

  1. 複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムであって、
    前記サーバは、
    前記機器の識別子及び前記機器の認可情報を保持する保持手段と、
    前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手段と、
    前記生成手段により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手段と、を有し、
    前記複数の機器の各々は、
    自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手段と、
    前記認証手段により前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手段と、
    を有することを特徴する認証認可システム。
  2. 前記認可情報には、前記自機器の識別子と、前記自機器が許可する前記他の機器からのデータ操作又は機能の利用とが含まれ、
    前記認可手段は、
    前記認可情報に含まれる前記データ操作又は前記機能の利用の要求を許可する、ことを特徴とする請求項１に記載の認証認可システム。
  3. 前記拡張識別子には、前記認可情報の有効期限が含まれ、
    前記認可手段は、
    現在の日又は日時が前記有効期限以内である場合、前記認可情報に応じて、前記他の機器から自機器への要求を許可する、ことを特徴とする請求項１又は２に記載の認証認可システム。
  4. 前記認証手段は、
    ＩＤベース暗号を用いた認証付き鍵共有プロトコルにより前記他の機器との間で相互に認証を行う、ことを特徴とする請求項１乃至３の何れか一項に記載の認証認可システム。
  5. 複数の機器と、前記機器の秘密鍵を生成並びに前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子及び前記秘密鍵を配布するサーバとが含まれる認証認可システムに用いられる認証認可方法であって、
    前記機器の識別子及び前記機器の認可情報を保持するサーバが、
    前記機器を識別する識別子と前記機器の認可情報とが含まれる拡張識別子から、前記機器の秘密鍵を生成する生成手順と、
    前記生成手順により生成された前記秘密鍵と、前記拡張識別子とを前記機器に配布する配布手順と、を実行し、
    前記複数の機器の各々が、
    自機器の拡張識別子及び秘密鍵を用いて、他の機器との間で相互に認証を行う認証手順と、
    前記認証手順で前記他の機器との間での認証が成功した場合、前記他の機器の拡張識別子に含まれる認可情報に応じて、前記他の機器から自機器への要求を許可する認可手順と、
    を実行することを特徴する認証認可方法。
JP2020553332A 2018-10-19 2019-10-18 認証認可システム及び認証認可方法 Active JP7115556B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018197875 2018-10-19
JP2018197875 2018-10-19
PCT/JP2019/041048 WO2020080510A1 (ja) 2018-10-19 2019-10-18 認証認可システム、情報処理装置、機器、認証認可方法及びプログラム

Publications (2)

Publication Number Publication Date
JPWO2020080510A1 JPWO2020080510A1 (ja) 2021-09-02
JP7115556B2 true JP7115556B2 (ja) 2022-08-09

Family

ID=70283936

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020553332A Active JP7115556B2 (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)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230396614A1 (en) * 2020-10-26 2023-12-07 Nippon Telegraph And Telephone Corporation Authentication-permission system, equipment, authentication-permission method, and program

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009033402A (ja) 2007-07-26 2009-02-12 Mitsubishi Electric Corp Ｉｄベース暗号システム及び送信端末装置及び配送サーバ装置及び受信端末装置
JP2010016465A (ja) 2008-07-01 2010-01-21 Mitsubishi Electric Corp 権限検証装置及び利用者端末装置及び鍵生成装置及びアクセス制御システム及びコンピュータプログラム及び権限検証方法及び操作要求通知方法及び鍵生成方法及びアクセス制御方法
JP2017126970A (ja) 2016-01-15 2017-07-20 富士通株式会社 共有鍵生成プログラム、共有鍵生成方法および情報処理端末

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1675879A (zh) * 2002-06-07 2005-09-28 索尼株式会社 数据处理系统、数据处理装置及其方法和计算机程序
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 日本電信電話株式会社 認証システム、認証装置、及び認証方法
CN106409313B (zh) 2013-08-06 2021-04-20 华为技术有限公司 一种音频信号分类方法和装置
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 大唐移动通信设备有限公司 通信网络系统的消息验证方法、通信方法和通信网络系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009033402A (ja) 2007-07-26 2009-02-12 Mitsubishi Electric Corp Ｉｄベース暗号システム及び送信端末装置及び配送サーバ装置及び受信端末装置
JP2010016465A (ja) 2008-07-01 2010-01-21 Mitsubishi Electric Corp 権限検証装置及び利用者端末装置及び鍵生成装置及びアクセス制御システム及びコンピュータプログラム及び権限検証方法及び操作要求通知方法及び鍵生成方法及びアクセス制御方法
JP2017126970A (ja) 2016-01-15 2017-07-20 富士通株式会社 共有鍵生成プログラム、共有鍵生成方法および情報処理端末

Also Published As

Publication number Publication date
US20210344515A1 (en) 2021-11-04
JPWO2020080510A1 (ja) 2021-09-02
CN112805960A (zh) 2021-05-14
EP3836482A1 (en) 2021-06-16
EP3836482A4 (en) 2022-05-04
CN112805960B (zh) 2024-05-17
WO2020080510A1 (ja) 2020-04-23

Similar Documents

Publication Publication Date Title
TWI738835B (zh) 資料安全保障系統及方法、裝置
US10516654B2 (en) System, apparatus and method for key provisioning delegation
JP6547079B1 (ja) 登録・認可方法、装置及びシステム
US9467430B2 (en) Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
JP3999655B2 (ja) レベル化された機密保護があるアクセス制御のための方法及び装置
JP4723251B2 (ja) 機器固有の機密保護データの安全な組み込みと利用
EP3412001B1 (en) A method of data transfer and cryptographic devices
EP2262164A1 (en) Secure data transfer
CN105993146A (zh) 不访问私钥而使用公钥密码的安全会话能力
CN110912685B (zh) 建立受保护通信信道
CN116671062A (zh) 硬件安全模块的远程管理
CN108352982A (zh) 通信装置、通信方法及计算机程序
KR20150016802A (ko) 보안장치 및 이를 이용하는 데이터 이동 방법
JP7115556B2 (ja) 認証認可システム及び認証認可方法
JP6939313B2 (ja) 分散認証システム
CN116566695A (zh) 加密传输方法及系统
JP7298686B2 (ja) 鍵交換システム、通信装置及びプログラム
JP7377487B2 (ja) 鍵交換システム、通信装置、鍵交換方法及びプログラム
CN116756780B (zh) 基于cp-abe算法的联盟链数据访问控制方法及相关设备
JP7534757B2 (ja) アイデンティティ認証方法、装置、機器、チップ、記憶媒体およびプログラム
Omote Is the Blockchain Useful for Sharing Sensitive Data?
JP2025002278A (ja) 管理システム
KR101304523B1 (ko) 공유 컴퓨터 리소스들에 대한 암호화 장치 및 그 방법
JP2018011190A (ja) 機器リスト作成システムおよび機器リスト作成方法
Guita et al. Anonymous Trusted Data Relocation

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210309

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220531

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220616

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220628

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220711

R150 Certificate of patent or registration of utility model

Ref document number: 7115556

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150