JP6571890B1 - 電子署名システム、証明書発行システム、証明書発行方法及びプログラム - Google Patents
電子署名システム、証明書発行システム、証明書発行方法及びプログラム Download PDFInfo
- Publication number
- JP6571890B1 JP6571890B1 JP2019007592A JP2019007592A JP6571890B1 JP 6571890 B1 JP6571890 B1 JP 6571890B1 JP 2019007592 A JP2019007592 A JP 2019007592A JP 2019007592 A JP2019007592 A JP 2019007592A JP 6571890 B1 JP6571890 B1 JP 6571890B1
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- key management
- request
- management system
- issuing
- 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
Links
- 238000000034 method Methods 0.000 title claims description 51
- 238000013475 authorization Methods 0.000 claims abstract description 90
- 230000004044 response Effects 0.000 claims description 27
- 238000012546 transfer Methods 0.000 claims description 7
- 238000012545 processing Methods 0.000 description 82
- 230000008569 process Effects 0.000 description 32
- 238000010586 diagram Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 15
- 230000007246 mechanism Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 7
- 230000008676 import Effects 0.000 description 7
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 4
- VBMOHECZZWVLFJ-GXTUVTBFSA-N (2s)-2-[[(2s)-6-amino-2-[[(2s)-6-amino-2-[[(2s,3r)-2-[[(2s,3r)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-2-[[(2s)-2,6-diaminohexanoyl]amino]-5-(diaminomethylideneamino)pentanoyl]amino]propanoyl]amino]hexanoyl]amino]propanoyl]amino]hexan Chemical compound NC(N)=NCCC[C@@H](C(O)=O)NC(=O)[C@H](CCCCN)NC(=O)[C@H](CCCCN)NC(=O)[C@H]([C@@H](C)O)NC(=O)[C@H]([C@H](O)C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCN=C(N)N)NC(=O)[C@@H](N)CCCCN VBMOHECZZWVLFJ-GXTUVTBFSA-N 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 108010068904 lysyl-arginyl-alanyl-lysyl-alanyl-lysyl-threonyl-threonyl-lysyl-lysyl-arginine Proteins 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵(秘密鍵)を用いて契約文書(電子データ)に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することが出来る。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵(秘密鍵)と、を用いて様々なセキュリティシステムを提供することができる。
この方式では、契約文書の検証時に契約書に電子署名を施した相手方(送り側)の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること(公開鍵の本人性)を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
従来、電子署名は利用者のPC(Personal Computer)上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
例えば、特許文献1には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
特許文献1においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをPKCS#12と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるSSO(Single Sign On)の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出し、そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
この準備作業において、利用者は、認証局に電子証明書の発行させるために、鍵管理システムで私有鍵(秘密鍵)とともに生成された公開鍵を鍵管理システムから取得(ダウンロード)し、公開鍵を含む鍵署名要求(証明書署名要求)を認証局に対して行う必要があった。
このような作業は利用者にとって煩雑なものであるとともに、技術的な負担を強いるものである。さらにこのような準備作業を利用者に行わせると、鍵管理システムの選択を利用者に委ねることになり、認証局側で鍵管理システムのセキュリティーレベルをコントロールすることが難しいという問題もある。
本発明は上記の問題点を鑑みてなされたものであり、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを提供することを目的とする。
まず、本実施形態の説明に先立って前提となる技術を説明する。
[公開鍵基盤]
公開鍵基盤(PKI:Public Key Infrastructure)は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名(電子署名)、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性(私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴)を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Bは、利用者Aに文書を送信するとき、利用者Aが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Aに送信する。利用者Aは受信した暗号化文書を、自身の私有鍵(秘密鍵)を用いて復号化する。
利用者Aの公開鍵を持っていれば誰もが利用者Aに対して暗号化文書を送信することが出来る一方で、利用者Aの公開鍵で暗号化したものは、利用者Aの私有鍵(秘密鍵)でしか復号できないため、仮に悪意の第三者が利用者Aの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
PKIでは、例えば、信頼できる第三者機関(TTP: Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、TTPは私有鍵(秘密鍵)の所有者の本人性を確認し、私有鍵(秘密鍵)と対になる公開鍵とその私有鍵(秘密鍵)の所有者とを紐づける電子証明書(公開鍵証明書)を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するTTPは、特に認証局あるいは認証機関(CA:Certification Authority)と呼ばれる。
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵(秘密鍵)の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにTTPの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことが出来る。また、TTPに信頼される私有鍵(秘密鍵)の所有者を加入者(Subscriber、サブスクライバー)という。
電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことが出来る。
電子署名には、文書のハッシュ値を私有鍵(秘密鍵)で暗号化した値が含まれる(実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い)。利用者Aが利用者Bに対して電子署名を付した文書ファイルを送る場合、利用者Aは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Aの私有鍵(秘密鍵)を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
電子署名付きの文書ファイルを受け取った利用者Bは、電子署名に含まれる暗号化された値を利用者Aの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
様々なクラウドサービス、オンラインサービスが提供され、クラウド上(サーバ上)で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のPC(Personal Computer)上ではなく、サーバ上(クラウド上)で行う「リモート署名(クラウド署名)」と呼ばれる方式の電子署名が普及しつつある。
より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵(秘密鍵)を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵(秘密鍵)を用いた電子署名を実行する仕組みである。
下記に説明するが、私有鍵(秘密鍵)と公開鍵の鍵ペアは鍵管理システムで生成するものであるが、電子証明書は、私有鍵(秘密鍵)の所有者の身分を保障する認証局によって発行されるものであり、前述した理由により、鍵管理システムには、発行された電子証明書を適宜インポートする必要がある。
電子証明書のインポートは、署名システムにおいてリモート署名をおこなうための準備作業である。
すなわち、
(1)利用者が自身の端末装置を用いて鍵管理システムにアカウントを作成する。
(2)利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムで鍵ペアを生成する。
(3)利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムに証明書署名要求(CSR:Certificate Signing Request)を生成させ、ダウンロードする。証明書署名要求は、証明書発行要求ともいう。
(4)利用者が自身の端末装置を用いて、(3)で取得した証明書署名要求(CSR)を認証局に送付する。
(5)認証局が上記証明書署名要求(CSR)に基づいて電子証明書を発行して利用者に送付する。
(6)利用者が鍵管理システムにログインし、(5)で送付された電子証明書を鍵管理システムにインポートする。
また、認証局側の観点では、準備作業を利用者に行わせた結果、鍵管理システムの選択を利用者に委ねることになり、認証局側が鍵管理システムのセキュリティーレベルをコントロールすることが難しい、という問題があった。
そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
保護リソースにアクセスするにはアクセストークン(Access token)と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークン(Access token)を発行する。
なお、図1の参考図は、RFC6749に開示されている図である。
図1を用いて、本実施形態を構成する、認証局としての証明書発行サーバ、鍵管理システム、端末装置と、OAuth2.0で定義される各エンティティとの対応付けを行うとともに、各エンティティによるOAuth2.0の処理を説明する。
なお、本実施形態の証明書発行システムが上記「クライアント」に対応し、本実施形態の端末装置で実行されるウェブブラウザ(後述)が上記「ユーザーエージェント」に対応する。また、本実施形態の鍵管理システムが上記「認可サーバ」に対応し、端末装置の利用者が上記「リソースオーナー」に対応する。
(C)において、認可サーバ(鍵管理システム)がリソースへのアクセスを許可する場合、認可サーバ(鍵管理システム)は、ユーザーエージェント(ウェブブラウザ)を経由してクライアント(証明書発行サーバ)に認可コード(Authorization code)を発行する(RFC6749#4.1.2. 認可応答)。
(D)において、クライアント(証明書発行サーバ)は、認可コード(Authorization code)を提示することによって、認可サーバ(鍵管理システム)に対してアクセストークン(Access token)を要求する(RFC6749#4.1.3. アクセストークン要求)。
(E)において、認可サーバ(鍵管理システム)は、提示された認可コード(Authorization code)の検証に成功した場合、アクセストークン(Access token)をクライアント(証明書発行サーバ)に発行する(RFC6749#4.1.4. アクセストークン応答)。
認証局(証明書発行システム)は、この認可コード(Authorization code)を用いて、アクセストークン(Access token)の要求を鍵管理システムに対して行う(図1(D)のアクセストークン要求)。
認証局(証明書発行システム)は、鍵管理システムからアクセストークン(Access token)を付与される(図1(E)のアクセストークン応答)。
このような本実施形態のシステムによれば、利用者による認証という要件を満たしながら、認証局(証明書発行システム)側で鍵管理システムに対する証明書署名要求(CSR)の要求を行うことで、鍵管理システムから証明書署名要求(CSR)を直接受け取って、電子証明書を発行して鍵管理システムに送信し、インポートさせることが出来る。
図2は、本実施形態のシステム構成を説明する図である。
図2に示すように、本実施形態のリモート署名システム1は、利用者の利用に係る端末装置10と、ユーザの電子証明書を発行する証明書発行サーバ20を含む証明書発行システム2と、ユーザの私有鍵(秘密鍵)及び公開鍵のペア、及び証明書発行サーバ20が発行した電子証明書を管理してリモート署名のサービスを提供するための鍵管理サーバ30を含む鍵管理システム3と、証明書発行サーバ20で発行されて鍵管理サーバ30で管理されている電子証明書の期限管理等を行う証明書管理システム4と、を備える。
これらの装置、システム間でやり取りされるデータの類は、おもにHTTPリクエストやHTTPレスポンスのパラメータとして(HTTPプロトコルを利用して)送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である(例えば、HTTPSを利用する)。
端末装置10で実行されるウェブブラウザがユーザーエージェントに対応する。また、鍵管理システム3が認可サーバに対応し、端末装置10の利用者が上記リソースオーナーに対応する。
従って、証明書発行システム2を構成する証明書発行装置20、鍵管理システム3を構成する鍵管理サーバ30、端末装置10のウェブブラウザは、夫々上記に説明したOAuthに準拠した処理を実行可能に構成されている。
端末装置10のCPUによって実行されるウェブブラウザは、証明書発行システム20から提供する電子証明書発行ページを要求するページ要求手段、証明書発行サーバ20から受信した転送ページ等を表示するページ表示手段、認可要求(Authorization request)を鍵管理サーバ30に送信し、認可コード(Authorization code)を含む認可応答(Authorization response)を受信するOAuth実行手段、KeyAliasとPINの入力を受け付けて鍵管理サーバ30に送信する鍵情報送信手段、鍵管理サーバ30から受信した認可コード(Authorization code)の証明書発行サーバ20への転送等の処理を行う認可コード送信手段等として機能する。
証明書発行システム2は、上記証明書発行サーバ20に加え、利用者のウェブブラウザによるリクエストを受け付けて電子証明書発行ページのデータを端末装置10に供給するウェブサーバをさらに備えてもよい。また、ウェブサーバの機能は、証明書発行サーバ20自体が備えていてもよい。
本実施形態の鍵管理システム3は、例えば、鍵管理サーバ30と、ハードウェアセキュリティモジュール(HSM:Hardware Security Module)100と、を備えている。
HSM100は、利用者の私有鍵(秘密鍵)と公開鍵のペアを生成し、認証局で発行された利用者の電子証明書をインポートして管理するとともに、私有鍵(秘密鍵)を用いて電子署名を生成する装置である。
さらに、HSM100はネットワークインターフェイスを備え、HSM100単独でネットワークに接続可能とされてもよい。HSM100は、鍵管理サーバ30と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ30と通信可能に接続される。
その場合、鍵管理サーバ30は、ネットワーク経由で、端末装置10からの要求に応じてHSM100に鍵ペアの生成を命令し、証明書発行サーバ20(認証局)から送信された電子証明書をHSM100にインポートする。
なお、鍵管理サーバ30に対して認証の要求を行うか否か、認証が成功しても認可を確立させるか否かは、利用者自身の裁量で決定出来る。リダイレクト画面に示される認証要求の可否を確認するダイアログ画面において、利用者は、認証要求の可否を選択することが出来る。あるいは認証成功後に、認可確立の是非を確認するダイアログ画面において、利用者は、認証確立の是非を選択することが出来る。
証明書発行サーバ20は、端末装置10(ウェブブラウザ)より送付された認可コード(Authorization code)を鍵管理サーバ30に送付し、鍵管理サーバ30は、その認可コード(Authorization code)と引き換えにアクセストークン(Access token)を証明書発行サーバ20に送付する。
証明書発行サーバ20がアクセストークン(Access token)を鍵管理サーバ30に提示することで、証明書発行サーバ20は、鍵管理サーバ30より証明書署名要求(CSR)を入手することが出来る。そして、証明書発行サーバ20は、証明書署名要求(CSR)に記載されている公開鍵に対して電子証明書を発行する。
証明書発行サーバ20で発行された電子証明書には、1年間や数年間などの有効期限があり、電子証明書はその失効後、望ましくは失効前に更新される必要がある。
証明書管理サーバ40は、証明書発行サーバ20で発行された電子証明書の有効期限の管理を行い、失効が近い電子証明書、あるいは任意の電子証明書を更新するための指示を証明書発行サーバ20に対して行うことが出来る。
また証明書管理サーバ40は、端末装置10の管理を行う管理装置からの要求に応じて、電子証明書を更新する指示を証明書発行サーバ20に対して行うことが出来る。
なお証明書管理サーバ40は、上記のように証明書発行システム2とは独立した証明書管理システム4に含まれてもよく、証明書発行システム2に含まれていてもよい。
図3(a)に示すように、証明書発行サーバ20は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ20の機能を実現するプログラムを実行するCPU(Central Processing Unit)21と、CPU21による処理のために各種のプログラムや一時データ、変数が展開されるRAM(Random Access Memory)22と、プログラムやデータが格納されるHDD(Hard Disk Drive)23や不図示のROM(Read Only Memory)と、証明書発行サーバ20をネットワークに接続するためのネットワークI/F24と、を備えている。
ウェブページ処理部51は、所謂ウェブサーバとして機能し、端末装置10からのHTTPリクエストに応じて、HDD23に格納されるウェブページ(HTMLページ)のデータから電子証明書発行ページのデータを送信する。上記したように、ウェブページ処理部51は、証明書発行サーバ20とは異なる独立したサーバ装置(ウェブサーバ)として構成されてもよい。
すなわち、証明書発行サーバ20は、電子証明書の発行を受け付けるためのウェブページ(電子証明書発行ページ)を供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、証明書発行システム3は、バックエンドの証明書発行サーバ30と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
署名リクエスト要求処理部53は、OAuth実行処理部52によって取得されたアクセストークン(Access token)を用いて、証明書署名要求(CSR)を鍵管理サーバ20に要求する処理を行う処理部である。
電子証明書発行処理部54は、鍵管理サーバ20から送信された証明書署名要求(CSR)に含まれる公開鍵に基づいて電子証明書を発行する処理を行う処理部である。
図4(a)に示すように、鍵管理サーバ30は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、鍵管理サーバ30の機能を実現するプログラムを実行するCPU(Central Processing Unit)31と、CPU31による処理のために各種のプログラムや一時データ、変数が展開されるRAM(Random Access Memory)32と、プログラムやデータが格納されるHDD(Hard Disk Drive)33や不図示のROM(Read Only Memory)と、鍵管理サーバ30をネットワークに接続するためのネットワークI/F34と、を備えている。
なお、上記したように、HSM100は、鍵管理サーバ30の外部バスに接続されていてもよいし、ネットワークI/Fを有してネットワーク経由で鍵管理サーバ30と接続可能されてもよい。この場合、鍵管理サーバ30と、ネットワーク接続型HSM100と、によって鍵管理システム3が構成される。
OAuth実行処理部61は、証明書発行サーバ30のOAuth実行処理部52とともに、RFC6749に規定されるOAuth2.0の認可処理を制御するための処理部である。
OAuth実行処理部61は、端末装置10(ウェブブラウザ)から認可要求(Authorization request)を受信すると、認証画面を端末装置10に表示させ、ユーザ認証処理部62による認証が成功した場合に、認可応答(Authorization response)として、認可コード(Authorization code)を端末装置10に送信する。
さらに、OAuth実行処理部61は、証明書発行サーバ20から認可コード(Authorization code)とともにアクセストークン(Access token)を要求されると、証明書発行サーバ20に対してアクセストークン(Access token)を送信する処理を行う。
鍵生成処理部63は、HSM100を制御し、私有鍵(秘密鍵)と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵(秘密鍵)は、例えば、端末装置10から受信したKeyAlias、PINに基づいて生成される。
署名要求処理部64は、証明書発行サーバ20から証明書署名要求(CSR)を要求されると、鍵生成処理部63で生成した公開鍵を含む証明書署名要求(CSR)を証明書発行サーバ20に送信する処理を行う処理部である。
証明書格納処理部65は、証明書発行サーバ20から送信された電子証明書を、HSM100に格納(インポート)する処理を行う処理部である。
また、鍵管理サーバ30のCPU31は、電子証明発行要求に応じて、HSM100に電子署名を生成させる処理を行う電子署名生成処理部を実行する。
シングルサインオンの技術において、鍵管理システム3(鍵管理サーバ30)は、認証情報を提供する側であるIdentity Provider(IdP)であり、認証局である証明書発行システム2(証明書発行サーバ20)は、認証情報を利用する側であるService Provider(SP)である。
電子証明書発行ページのリクエストを受けた証明書発行サーバ20は、ステップS2において、利用者を鍵管理サーバ30にリダイレクトするページを端末装置10に供給する。
利用者の操作によって、端末装置10は、ステップS3において、鍵管理サーバ30に対して、認可要求(Authorization request)の送信を行う(RFC6749#4.1.1.)。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。
なお、ステップS4のユーザ認証処理において、認証情報の入力はRFC6749(OAuth2.0)で規定される処理とは異なり、鍵管理サーバ30と端末装置10との間で別途確立されるセッションにおいて行われる。
認証の方法は、ユーザID及びパスワードの組み合わせを認証する形式のみならず、ICカードに格納されたトークンが端末装置か10から鍵管理サーバ30に送付されることにより認証が行われる場合もある。
ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ30は、利用者の確認を得たうえで認可を確立し、ステップS5において、認可応答(Authorization response)として、認可コード(Authorization code)を端末装置10に送信する(RFC6749#4.1.2.)。
それに対して、鍵管理サーバ30は、ステップS7において、利用者が入力したKeyAliasとPINに基づいて、HSM(Hardware Security Module)100に私有鍵(秘密鍵)と公開鍵のペアを生成させ、HSM100に格納させる。
なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求(CSR)の送信時までに行われていればよい。
端末装置10から転送された認可コード(Authorization code)を取得した証明書発行サーバ20は、ステップS9において、この認可コード(Authorization code)を用いて、Access token request(アクセストークン要求)を鍵管理サーバ30に対して行う(RFC6749#4.1.3.)。
すなわち、鍵管理サーバ30は、アクセストークン(Access token)を証明書発行サーバ20に送信する(RFC6749#4.1.4.)。
証明書署名要求(CSR)の要求を受けた鍵管理サーバ30は、ステップS12において、証明書署名要求(CSR)を証明書発行サーバ20に対して行う。証明書署名要求は、鍵管理サーバ30が生成した公開鍵を含む。
証明書署名要求を受けた証明書発行サーバ20は、ステップS13において、電子証明書の発行を行い、ステップS14で、例えば鍵管理サーバ30に対してポストし、ステップS15で、鍵管理サーバ30はそれを受け入れる(HSM100に格納する)。
鍵管理サーバ30は、ポストされた電子証明書を私有鍵(秘密鍵)、公開鍵とともに管理する。
端末装置10からの要求に応じて、証明書発行サーバ20は、ステップS21において、図5の処理で取得したアクセストークン(Access token)を用いて、リモート署名要求を鍵管理サーバ30に送信する。
なお、このリモート署名要求は、遠隔で電子署名の生成を要求する処理であり、上記した電子証明書格納処理における電子証明書の発行(署名)を要求する証明書署名要求とは異なる処理である。
リモート署名要求送信を受信した鍵管理サーバ30は、ステップS22において、電子署名を生成し(HSM100に電子署名を生成させ)、ステップS23において、生成された電子署名を証明書発行サーバ20に送信する。
そして、証明書発行サーバ20は、このアクセストークン(Access token)を、証明書署名要求(CSR)の要求のみならず、鍵管理サーバ30に対するリモート署名の要求にも利用することが出来る。
これにより、利用者の負担を軽減しながら、電子証明書の発行、鍵管理サーバへの電子証明書の登録が安全に実施可能な電子署名システムを実現し、信頼性の高い署名サービスを利用者に利用させることが出来る。
基本的には、端末装置10の利用者が認証局(CA)の証明書発行サーバ20にアクセスする操作を行うことを契機として、図5に示したステップS1〜ステップS15(鍵ペアの生成に係るステップS6、ステップS7は除いてもよい)の処理が再び行われることで、新たな電子証明書が鍵管理サーバ30(HSM100)に格納され、電子証明書の更新を行うことが出来る。
しかしながら、端末装置10の利用者自身が、電子証明書の有効期限を管理し、定期的に電子証明書の更新に係る操作を行うことは非常に煩雑であり、且つ不便である。
鍵管理サーバ30に格納された電子証明書の有効期限を端末装置10の利用者が意識する必要がなく、電子証明書が自動的に更新されていく仕組みが望ましい。
その点に鑑みて、証明書発行サーバ20は、初回格納時に端末装置10の利用者自身の認証と管理のもと発行されたアクセストークン(Access token)を用いて電子証明書の更新処理を行う。
そして、証明書発行サーバ20に電子証明書の更新処理を行わせる命令自体は管理装置等が行うことができるので、端末装置10の利用者は電子証明書の更新処理自体を意識することがなく、その負荷を最大限に抑制することが出来る。
証明書管理システム4が含む証明書管理サーバ40は、端末装置10の管理を行う管理装置からの要求を受けて、証明書発行サーバ20に対する電子証明書の更新(再発行)要求を行う。
図7(a)に示すように、証明書管理サーバ40は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ20の機能を実現するプログラムを実行するCPU(Central Processing Unit)41と、CPU41による処理のために各種のプログラムや一時データ、変数が展開されるRAM(Random Access Memory)42と、プログラムやデータが格納されるHDD(Hard Disk Drive)43や不図示のROM(Read Only Memory)と、証明書管理サーバ40をネットワークに接続するためのネットワークI/F44と、を備えている。
また、HDD43等から構成される記憶部には、証明書発行サーバ20によって発行された電子証明書の状態(有効または失効済み)と有効期限とを管理する証明書管理データベース(DB)81が格納されている。
証明書管理DB81は特定の外部装置(管理装置等)に対して公開されて、電子証明書の有効期限を確認可能であることが望ましい。その場合、証明書管理サーバ40は、外部装置に対して情報を公開するためのフロントエンドとしてのウェブページ処理部(所謂ウェブサーバ)を備えることが望ましい。
証明書管理処理部72は、証明書発行サーバ20によって発行された電子証明書の状態(有効、失効済み)と有効期限を証明書管理DB81に書き込み、またはデータベースの情報の参照を行うデータベース管理処理部である。
管理装置等からの要求を受けた証明書管理サーバ40は、ステップS31において、証明書発行サーバ20に対して、特定の電子証明書の更新要求を行う。更新要求は、一つの電子証明書に対して行われてもよいし、失効が近い複数の電子証明書について一括して行われてもよい。
証明書署名要求(CSR)の要求を受けた鍵管理サーバ30は、ステップS33において、証明書署名要求(CSR)を証明書発行サーバ20に対して行う。
証明書署名要求を受けた証明書発行サーバ20は、ステップS34において、電子証明書の発行を行い、ステップS35で、例えば鍵管理サーバ30に対してポストし、ステップS36で、鍵管理サーバ30はそれを受け入れる(HSM100に格納する)。
鍵管理サーバ30は、ポストされた電子証明書を私有鍵(秘密鍵)、公開鍵とともに管理する。
鍵管理サーバ30から取得されたアクセストークン(Access token)を利用することで、電子証明書の更新にあたり端末装置10による認可操作(図5のステップS1〜S5)を繰り返す必要がなくなり、利用者の作業負担は著しく低減される。
また、上記のように、鍵管理サーバ30から取得されたアクセストークン(Access token)は、端末装置10の利用者自身の認証と管理のもとで発行されたものであり、適正な処理であること保証される。
図6について説明したように、証明書格納処理のステップS10において鍵管理サーバ30から取得されたアクセストークン(Access token)は、リモート署名要求を鍵管理サーバ30に送信する際に用いられるものであるが、これは電子証明書の更新時にも用いることが出来るということである。
それに対し、特定の条件下で、例えば電子証明書の更新用途に限ってアクセストークン(Access token)の有効期限を長く設定するなどすることで電子証明書の更新を確実に行うことが出来る。
以上のように構成したことで、本実施形態のリモート署名システム1では、利用者は、初回の格納処理で認可操作(ステップS1における電子証明書発行ページへのアクセス、ステップSS4における鍵管理サーバに対するログイン認証)を行った後は、電子証明書の鍵管理サーバ30への格納と、格納された電子証明書の更新を、ほぼ完全に自動で行うことが出来る。
例えば、図6に示すリモート署名処理において、端末装置10からの要求に応じて、証明書発行サーバ20は、ステップS21において、図5の処理で取得したアクセストークン(Access token)を用いて、リモート署名要求を鍵管理サーバ30に送信する。
リモート署名要求送信を受信した鍵管理サーバ30は、ステップS22において、電子署名を生成し、ステップS23において、生成された電子署名を証明書発行サーバ20に送信する。
このとき、鍵管理サーバ30は、HSM100に格納されているリモート署名要求に対応する電子証明書の失効が近い場合、電子署名とともに、CSRを証明書発行サーバ20に送信してもよい。この方法によっても、端末装置10の利用者に負担をかけることなく、電子証明書の更新を行うことが出来る。
それに限らず、本実施形態のリモート署名システム1は、複数の端末装置10、複数の証明書発行システム20、複数の鍵管理システム30によって構成されることが出来る。
また、一の証明書発行システム20は、上記に説明した機能を有する複数の鍵管理システム30を信頼し、上記の手順に従って、各鍵管理システムで発行された公開鍵について電子証明書を発行して登録する処理を行う。
各証明書発行システムは、利用者をリダイレクト可能な鍵管理システムが複数ある場合、例えば、証明書発行ページに、利用可能な鍵管理システムのリストを表示し、その中から、利用する鍵管理システムを利用者に選択させることが出来る。
この特許文献1においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵をPKCS#12と呼ばれる形式のファイルに格納し、電子署名サーバに供給する。
そして、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
本実施形態において、私有鍵(秘密鍵)は、そもそも鍵管理サーバで生成されるものであり、認証局と鍵管理サーバとの間で授受されるものではない。
本実施形態では、利用者による鍵管理サーバに対する認証を契機に証明書署名要求、電子証明書のやり取りが行われるため、従来の方法に比べ、より安全に電子証明書の発行が可能である。また、私有鍵(秘密鍵)は、鍵管理システムで生成された後、他のサーバや端末に送信されることがないため、外部に漏れるリスクが低く、より安全な電子署名システムの運用が可能となる。
本実施形態に係る第1の発明は、電子証明書を発行する証明書発行システム2と、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システム3と、を備える電子署名システムであって、鍵管理システム3は、アクセストークンを電子証明書発行システム2に送信し、証明書発行システム2は、アクセストークンを鍵管理システム3に提示することによって、鍵管理システム3から利用者の公開鍵を含む証明書発行要求を取得し、公開鍵に対して電子証明書を発行する電子署名システム1を特徴とする。
第1の発明の電子署名システムでは、リモート署名で求められる電子証明書の発行に際し、公開鍵を含む証明書署名要求及び電子証明書の発行が、アクセストークンを介して、認証局(証明書発行システム2)と信頼された署名サービス(鍵管理システム3)との間で自動的に行われる。
これにより、利用者の負担を軽減しながら電子証明書の安全な発行が可能な電子署名システムを実現することが出来る。
本実施形態に係る第2の発明は、電子証明書を発行する証明書発行システムであって、所定のアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する要求手段(署名リクエスト要求処理部53)と、要求手段による要求に応じて取得した証明書発行要求に含まれる公開鍵に対して電子証明書を発行する発行手段(電子証明書発行処理部54)と、を備える証明書発行システムを特徴とする。
第2の発明の証明書発行システムは、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス(鍵管理システム3)に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、アクセストークンを介して自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
本実施形態に係る第3の発明は、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システムであって、利用者の公開鍵を少なくとも生成する鍵生成手段(鍵生成処理部63)と、アクセストークンを送信した証明書発行システムに対し、公開鍵を含む証明書発行要求を送信し、証明書発行システムに電子証明書を発行させる署名要求手段(署名要求処理部64)と、を備える鍵管理システムを特徴とする。
第3の発明の鍵管理システムは、リモート署名で求められる電子証明書の発行に際し、証明書発行システムに対して公開鍵を含む証明書署名要求を、アクセストークンを介して自動で行い、電子証明書の発行を行わせることが出来る。
これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
Claims (4)
- 電子証明書を発行する証明書発行システムと、発行された電子証明書のライフサイクルを管理する証明書管理システムと、秘密鍵を用いて電子署名を生成する鍵管理システムと、利用者が利用する端末装置と、を備え、
電子証明書の新規発行時において、
前記端末装置は、前記鍵管理システムに対して前記利用者の認証を要求し、
前記認証が成功した場合、前記鍵管理システムは、前記端末装置に対して認可コードを送信し、
前記認可コードを取得した前記端末装置は、前記認可コードを前記証明書発行システムに転送し、
前記認可コードを取得した前記証明書発行システムは、前記認可コードを前記鍵管理システムに送信することによりアクセストークンを要求し、
前記鍵管理システムは、前記アクセストークンを前記証明書発行システムに送信し、
前記証明書発行システムは、前記アクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行し、
前記証明書管理システムは、所定条件の成立に基づく電子証明書の更新時において、前記証明書発行システムに対して証明書更新要求を行い、
前記証明書発行システムは、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを前記鍵管理システムに提示することによって前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行する、
ことを特徴とする電子署名システム。 - 電子証明書を発行する証明書発行システムであって、
電子証明書の新規発行時において、利用者が利用する端末装置が前記利用者の認証を鍵管理システムに要求することによって前記鍵管理システムにより発行された認可コードを取得する認可コード取得手段と、
取得された前記認可コードを用いて前記鍵管理システムにアクセストークンを要求する第1要求手段と、
前記第1要求手段による要求に応じて取得した前記アクセストークンを用いて、前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求する第2要求手段と、
前記第2要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行して前記鍵管理システムに送信する第1発行手段と
所定条件の成立に基づく電子証明書の更新時において電子証明書のライフサイクルを管理する証明書管理システムにより証明書更新要求が行われたとき、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを用いて前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求する第3要求手段と、
前記第3要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行して前記鍵管理システムに送信する第2発行手段と、
を備えることを特徴とする証明書発行システム。 - 認可コード取得手段と、第1要求手段と、第2要求手段と、第3要求手段と、第1発行手段と、第2発行手段と、を備え、電子証明書を発行する証明書発行システムの証明書発行方法であって、
電子証明書の新規発行時において、
前記認可コード取得手段が、利用者が利用する端末装置が前記利用者の認証を鍵管理システムに要求することによって前記鍵管理システムにより発行された認可コードを取得するステップと、
前記第1要求手段が、取得された前記認可コードを用いて前記鍵管理システムにアクセストークンを要求するステップと、
前記第2要求手段が、前記第1要求手段による要求に応じて取得した前記アクセストークンを用いて、前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求するステップと、
前記第1発行手段が、前記第2要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行するステップと、
所定条件の成立に基づく電子証明書の更新時において電子証明書のライフサイクルを管理する証明書管理システムにより証明書更新要求が行われたとき、前記第3要求手段が、前記証明書更新要求に基づいて、前記新規発行時に前記鍵管理システムから取得した前記アクセストークンを用いて前記利用者の公開鍵を含む証明書発行要求を前記鍵管理システムに要求するステップと、
前記第2発行手段が、前記第3要求手段による要求に応じて取得した証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行するステップと、
を含むことを特徴とする証明書発行方法。 - 請求項3に記載の証明書発行方法をコンピュータに実行させるプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019007592A JP6571890B1 (ja) | 2019-01-21 | 2019-01-21 | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム |
PCT/JP2019/028492 WO2020017643A1 (ja) | 2018-07-20 | 2019-07-19 | 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019007592A JP6571890B1 (ja) | 2019-01-21 | 2019-01-21 | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP6571890B1 true JP6571890B1 (ja) | 2019-09-04 |
JP2020120173A JP2020120173A (ja) | 2020-08-06 |
Family
ID=67844826
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019007592A Active JP6571890B1 (ja) | 2018-07-20 | 2019-01-21 | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6571890B1 (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110690966A (zh) * | 2019-11-08 | 2020-01-14 | 北京金茂绿建科技有限公司 | 终端与业务服务器连接的方法、系统、设备及存储介质 |
CN111708991A (zh) * | 2020-06-17 | 2020-09-25 | 腾讯科技(深圳)有限公司 | 服务的授权方法、装置、计算机设备和存储介质 |
US20220191012A1 (en) * | 2019-03-11 | 2022-06-16 | Shanghai Weilian Information Technology Co., Ltd. | Methods For Splitting and Recovering Key, Program Product, Storage Medium, and System |
EP4072064A4 (en) * | 2019-12-03 | 2023-12-06 | Keisuke Kido | ELECTRONIC SIGNATURE SYSTEM AND TAMPER-PROOF DEVICE |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7210037B2 (en) * | 2000-12-15 | 2007-04-24 | Oracle International Corp. | Method and apparatus for delegating digital signatures to a signature server |
JP2004213265A (ja) * | 2002-12-27 | 2004-07-29 | Hitachi Ltd | 電子文書管理装置、文書作成者装置、文書閲覧者装置、電子文書管理方法及び電子文書管理システム |
JP4449899B2 (ja) * | 2005-12-28 | 2010-04-14 | ブラザー工業株式会社 | 管理装置及びプログラム |
JP2017175226A (ja) * | 2016-03-18 | 2017-09-28 | 株式会社インテック | 公開鍵証明書を発行するためのプログラム、方法およびシステム |
US10404680B2 (en) * | 2016-08-11 | 2019-09-03 | Motorola Solutions, Inc. | Method for obtaining vetted certificates by microservices in elastic cloud environments |
JP2018092446A (ja) * | 2016-12-05 | 2018-06-14 | キヤノン株式会社 | 認証認可システム及び情報処理装置と認証認可方法とプログラム |
JP6465426B1 (ja) * | 2018-07-20 | 2019-02-06 | Gmoグローバルサイン株式会社 | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 |
-
2019
- 2019-01-21 JP JP2019007592A patent/JP6571890B1/ja active Active
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220191012A1 (en) * | 2019-03-11 | 2022-06-16 | Shanghai Weilian Information Technology Co., Ltd. | Methods For Splitting and Recovering Key, Program Product, Storage Medium, and System |
CN110690966A (zh) * | 2019-11-08 | 2020-01-14 | 北京金茂绿建科技有限公司 | 终端与业务服务器连接的方法、系统、设备及存储介质 |
CN110690966B (zh) * | 2019-11-08 | 2020-10-09 | 北京金茂绿建科技有限公司 | 终端与业务服务器连接的方法、系统、设备及存储介质 |
EP4072064A4 (en) * | 2019-12-03 | 2023-12-06 | Keisuke Kido | ELECTRONIC SIGNATURE SYSTEM AND TAMPER-PROOF DEVICE |
CN111708991A (zh) * | 2020-06-17 | 2020-09-25 | 腾讯科技(深圳)有限公司 | 服务的授权方法、装置、计算机设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
JP2020120173A (ja) | 2020-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10567370B2 (en) | Certificate authority | |
CN109088889B (zh) | 一种ssl加解密方法、系统及计算机可读存储介质 | |
JP6571890B1 (ja) | 電子署名システム、証明書発行システム、証明書発行方法及びプログラム | |
US8788811B2 (en) | Server-side key generation for non-token clients | |
TWI429256B (zh) | 基於編碼證明之重新驗證的鑑定授權 | |
US9137017B2 (en) | Key recovery mechanism | |
JP4252620B1 (ja) | サーバ証明書発行システム | |
US20110296171A1 (en) | Key recovery mechanism | |
JP6609788B1 (ja) | 情報通信機器、情報通信機器用認証プログラム及び認証方法 | |
US11777743B2 (en) | Method for securely providing a personalized electronic identity on a terminal | |
JP6465426B1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法 | |
US20210392004A1 (en) | Apparatus and method for authenticating device based on certificate using physical unclonable function | |
JP4332071B2 (ja) | クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム | |
KR20100012439A (ko) | 스마트 카드 인증서 관리 장치 및 방법 | |
CN114760070A (zh) | 数字证书颁发方法、数字证书颁发中心和可读存储介质 | |
CN112235276B (zh) | 主从设备交互方法、装置、系统、电子设备和计算机介质 | |
JP5036500B2 (ja) | 属性証明書管理方法及び装置 | |
JP2008129673A (ja) | ユーザ認証システム、ユーザ認証方法、それに用いるゲートウェイ及びプログラムとその記録媒体 | |
KR102288445B1 (ko) | 단체용 인증모듈의 온보딩 방법, 장치 및 프로그램 | |
JP2019134333A (ja) | 情報処理システム、クライアント装置、認証認可サーバー、制御方法とそのプログラム | |
JP2021040278A (ja) | 鍵管理システム、署名装置、鍵管理方法及びプログラム | |
JP2005318269A (ja) | 電子証明書管理システム、電子証明書管理方法、及び、サーバ | |
WO2020017643A1 (ja) | 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム | |
JP4950573B2 (ja) | 認証システムおよび認証方法 | |
JP6254964B2 (ja) | 認証システム、予備鍵管理装置、予備鍵管理方法および予備鍵管理プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190201 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190201 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20190201 |
|
A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20190206 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190416 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190614 |
|
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: 20190806 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190808 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6571890 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |