JP3890959B2 - 公開鍵証明書の生成システム及び検証システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、公開鍵基盤（PKI（Public Key Infrastructure））に於ける、公開鍵証明書を発行する技術と、その公開鍵証明書の有効性を確認する技術とに関する。
【０００２】
【従来の技術】
電子文書などディジタルデータを送付する際に、対象となるデータに対して、署名と送信者の公開鍵証明書を添付することが行われる。受信者では、受信データに添付されたディジタル署名（以下署名という）と公開鍵証明書の検証を行い、送付されたデータが改ざんされていないことと、確かに本人から送られた電子データであることを確認する。
【０００３】
公開鍵証明書の発行と有効性の確認は、公開鍵基盤において行われ、その標準仕様はＲＦＣ２４５９（Internet X.509 Public Key Infrastructure Certificate and CRL Profile）や、ＲＦＣ２５１０（Internet X.509 Public Key Infrastructure Certificate Management Protocols）等にて規定されている。
【０００４】
ＲＦＣ２４５９（３章）や、ＲＦＣ２５１０（１．3）の構成モデルに示されるように、認証局の業務は主に、登録業務と発行業務から構成される。登録業務とは、利用者の登録ならびにその審査を行う業務であり、登録機関（Registration Authority、以下ＲＡという）において行われる。
【０００５】
発行業務とは主に、登録された利用者に対する公開鍵証明書の発行を行う業務であり、発行機関（Issuing Authority、以下ＩＡという）によって行われる。
【０００６】
なお、ＲＦＣ２４５９およびＲＦＣ２５１０では、発行業務を行う機関を認証局（Certificate Authority、以下ＣＡという）と定義しているが、本明細書においていは、発行業務を行う機関を発行機関ＩＡと定義し、ＣＡはＲＡとＩＡとからなると定義する。
【０００７】
発行業務は、セキュアな設備や機器を必要とするため、高い維持費用と構築費用を要する。そのため、認証局を構築する組織は、発行業務処理を外部へ委託（以下、アウトソーシング（outsourcing）という）する場合がある。
【０００８】
従来、発行業務をアウトソーシングする次の２つの方法がある。
【０００９】
方法１では、認証局を構築する組織は、エンドエンティティ（End Entity、以下ＥＥという。利用者やエンドユーザともいう）の本人確認や審査を、自機関のＲＡで行い、ＩＡの業務全般（機器、設備、ＩＡの運用等）を他機関へアウトソーシングする。アウトソーシング先機関は、複数のＲＡの公開鍵証明書発行業務を代行する。このとき、アウトソーシング先機関の秘密鍵が公開鍵証明書の発行に用いられ、アウトソーシング先機関名が公開鍵証明書発行者名（Issuer）として記載される。
【００１０】
方法２では、認証局を構築する組織は、ＲＡの業務を自機関で行い、ＩＡの機器管理等の業務を他機関へアウトソーシングする。そこでは、認証局を構築する組織毎に専用のＩＡの機器や秘密鍵が用いられる。例えば、異なるＲＡ毎のＩＡとＩＡ秘密鍵とが、アウトソーシング先機関へ設けられる。この場合、認証局を構築する組織名（ＲＡ運営者名）が公開鍵証明書発行者名（Issuer）として記載される。
【００１１】
以上の二つの方法が採用されている例として、日本認証サービス株式会社（ＪＣＳＩ）のＳｅｃｕｒｅＳｉｇｎという証明書発行サービスがある。ＪＣＳＩの「ＳｅｃｕｒｅＳｉｇｎパブリックサービス標準規定（Ｖ１．０）」（ＪＣＳＩ，ＳｅｃｕｒｅＳｉｇｎは、日本認証サービス株式会社の登録商標である）５ページには、以下のことが記述されている。
【００１２】
ＳｅｃｕｒｅＳｉｇｎには、「パブリックサービス」「プライベートサービス」という二種類のサービスがある。プライベートサービスの場合、証明書ポリシーならびにＣＰＳは顧客により決定され、顧客が必要とするネットワーク上のドメイン内に開示される。一方、パブリックサービスでは、ＪＣＳＩがパブリックサービスの証明書発行者であり、証明書に署名する当事者であるということを意味する。
【００１３】
【発明が解決しようとする課題】
発行業務と登録業務とを異なる組織で運営すると、利用者に対するＩＡとＲＡの責任範囲が明確にならないという問題点がある。ＩＡとＲＡの責任範囲は、認証局運用規程（Certificate Practice Statement、以下CPSという）等で明確にすることとなっている。しかし発行された公開鍵証明書の内容において生じた問題（例えば、記載事項に間違いがあった場合など）の責任の所在を判断するには、ＩＡやＲＡの内部データ（ログ等）を調べる必要があり、判断が難しい、時間がかかる、などの問題がある。
【００１４】
【課題を解決するための手段】
本発明は、複数の当事者機関が作成に係わる公開鍵証明書について、公開鍵証明書の内容に対する各当事者の責任範囲を明確にする技術を提供する。
【００１５】
また、本発明は複数の当事者機関が作成に係わる公開鍵証明書の検証技術を提供する。
【００１６】
また、本発明は複数の当事者機関が作成に係わる公開鍵証明書について、その内容を利用者に分かりやすく示す技術を提供する。
【００１７】
また、本発明は、上記技術に基づいた、公開鍵証明書の発行、登録、検証に係わる装置、またはそれらの装置を用いたシステム、または、各装置やシステムで用いられる処理方法を提供する。
【００１８】
具体的には、本発明では、発行業務全般を他機関へアウトソーシングする場合において、以下のような公開鍵証明書発行の処理および検証処理を行う。
【００１９】
本発明における公開鍵証明書の発行処理において、次の処理を行う。
【００２０】
ＲＡ装置は、ＲＡにおいて行われるＥＥの本人確認、審査等の後、ＥＥがもつ情報のうち、公開鍵証明書に記載する情報、例えばＥＥ名（subject）、公開鍵（subjectPublicKeyInfo）、に対してその内容を保証するＲＡの署名を生成する。ＲＡは、生成したＲＡ署名を添付した公開鍵証明書発行要求をＩＡへ送付する。
【００２１】
ＩＡがＲＡから受け取った公開鍵証明書発行要求に応じて、ＩＡ装置は公開鍵証明書を作成する。公開鍵証明書にはＲＡの名前とＲＡの署名とその署名対象情報が格納され、公開鍵証明書全体に対するＩＡの署名が生成され付与される。
【００２２】
上記手順で発行されたＥＥの公開鍵証明書の効力を停止するには、その登録に係わったＲＡの公開鍵証明書を失効させればよい。具体的には、ＲＡ装置は自身の公開鍵証明書の発行機関へ証明書失効要求を送付する。それを受け取ったＲＡの公開鍵証明書の発行機関は、ＲＡの証明書を失効させる（失効リストに載せる）。この方法は、例えば、ＲＡの運営終了時等に、ＲＡが登録を行った全てのＥＥの公開鍵証明書を、一括して失効させる場合などに有効である。
【００２３】
本発明による公開鍵証明書を、取引の過程などで受け取ったＥＥは、その公開鍵証明書を検証するために、次の検証処理を行う。
【００２４】
まず、ＥＥ装置は、検証を行うＥＥが信頼する認証局の自己署名証明書から、当該公開鍵証明書までのパス構築およびパス検証を行う。次に、公開鍵証明書に記載されたＲＡの署名を、ＲＡの公開鍵で検証する。そして、検証を行うＥＥの信頼する認証局の自己署名証明書から、ＲＡの公開鍵証明書までのパス構築および検証を行う。この際、ＲＡの公開鍵証明書が失効していた場合、検証対象の公開鍵証明書は有効でないものとなる。
【００２５】
本発明による公開鍵証明書には、ＲＡの名前と、署名と、検証者が署名による保証対象を知ることができる情報とが記載されているので、公開鍵証明書を受け取ったＥＥは、ＲＡが何を保証しているのかを知ることができる。ＲＡの保証範囲以外の記載事項は、ＩＡが保証していることになり、この結果、ＩＡとＲＡの責任範囲を明確化することができる。
【００２６】
【発明の実施の形態】
図１は、本発明の実施形態が適用されたＰＫＩシステムの概略構成を示す図である。
【００２７】
本実施例のＰＫＩシステムは、電子的に手続を行うＥＥ１装置（１５）、ＥＥ２装置（１６）（ＥＥ装置と総称する）と、公開鍵証明書発行業務を行うＣＡ１装置（１３）、ＣＡ２装置（１４）（ＣＡ装置と総称する）と、それぞれを接続するインターネット等のネットワーク（以下、ＮＥＴという）１７からなる。ＣＡ装置１（１３）は、登録業務を行うＲＡ装置（１１）と、公開鍵証明書の発行業務と管理を行うＩＡ装置（１２）とから構成され、それぞれがＮＥＴ（１７）に接続されている。
【００２８】
ＮＥＴ（１７）を介して互いに接続しているＩＡ装置（１２）とＲＡ装置（１１）は、論理的にはＣＡ１（１３）を構築するものであれば、物理的に同じ場所にある必要はない。
【００２９】
さらに、ＣＡ１装置（１３）を運営する組織は、ＩＡ装置（１２）を用いたＩＡ業務を別機関にアウトソーシングしているため、ＩＡ装置（１２）とＲＡ装置（１１）を運営する組織は異なるものとする。
【００３０】
また、点線で示すように、ＣＡ１（１３）は、ＣＡ２（１４）と相互認証し、ＣＡ１（１３）は、ＥＥ１（１５）に対してその公開鍵証明書を発行し、ＣＡ２（１４）は、ＥＥ２（１６）に対してその公開鍵証明書を発行するものとする。ＥＥ１（１５）、ＥＥ２（１６）は、自身の公開鍵証明書を発行したＣＡ１（１３）、ＣＡ２（１４）を信頼するものとする。
【００３１】
次に、図１のＰＫＩシステムを構成する各装置について説明する。
【００３２】
図２を用いて、ＥＥ装置を説明する。
【００３３】
ＥＥ装置は、処理部３０ａと記憶部３０ｂと、ＮＥＴ１７を介して他装置と通信を行うための通信部３６と、ユーザが作成した電子文書や他のＥＥから受け取った電子文書の入出力や利用者からの指示の受付を行う入出力部３７と、を有する。
【００３４】
処理部３０ａは、電子文書に対する署名を生成する署名生成部３４と、署名の検証を行う署名検証部３５と、ＥＥ装置の各部を統括的に制御する制御部３８と、を有する。
【００３５】
記憶部３０ｂは、利用者が作成した電子文書を保持する電子文書保持部３１と、秘密鍵（署名鍵）と、これと対になる公開鍵の公開鍵証明書と、当該ＥＥ装置を運用するＥＥが信頼するＣＡの自己署名証明書を保持する鍵保持部３２と、他のＥＥから受け取った署名付きの電子文書と公開鍵証明書を保持する検証対象保持部３３と、を有する。
【００３６】
このような構成において、制御部３８は、入出力部３７を介して利用者から、電子文書保持部３１に保持してある電子文書を他のＥＥに送信すべき旨の指示を受け付けると、当該電子文書を電子文書保持部３１から読み出し、これを署名生成部３４に渡す。署名生成部３４は、鍵保持部３２に保持されている秘密鍵を用いて渡された当該電子文書に対する署名を生成する。
【００３７】
制御部３８は、電子文書保持部３１から読み出した電子文書に署名生成部３４で生成された署名を付して、署名付き電子文書を作成する。
【００３８】
作成した署名付き電子文書と鍵保持部３２に保持されている公開鍵証明書とを、通信部３６を介して、利用者から指示された送信先のＥＥへ送信する。
【００３９】
制御部３８は、通信部３６を介して、他のＥＥ装置から署名付き電子文書と公開鍵証明書を受け取ると、これらを関連づけて検証対象保持部３３に保持させると共に、これらの検証要求を署名検証部３５に通知する。
【００４０】
これを受けて、署名検証部３５は、検証対象保持部３３に保持されている署名付き電子文書の署名を、対応する公開鍵証明書を用いて検証する。
【００４１】
それから、署名検証部３５は、鍵保持部３２に保持されている信頼するＣＡであるＣＡ１（１３）の自己署名証明書から当該公開鍵証明書までのパスに含まれる証明書を、通信部３６を介して各ＣＡから取得して、パスを構築し、そのパスを検証する。そして、これらの検証により正当性が確認できた場合にのみ、署名付き電子文書を正当な物として扱い、必要に応じて入出力部３７から出力する。
【００４２】
次に、図３を用いてＲＡ装置を説明する。
【００４３】
ＲＡ装置は、処理部４０ａと記憶部４０ｂと、ＮＥＴ１７を介して他装置と通信を行うための通信部４４と、公開鍵証明書等の入出力やＲＡ装置操作者からの指示の受付を行う入出力部４５と、を有する。
【００４４】
処理部４０ａは、ＩＡ装置への公開鍵証明書の発行依頼や失効依頼を行うための電子文書を作成する依頼文書作成部４３と、ＲＡ装置の各部を統括的に制御する制御部４６と、を有する。
【００４５】
記憶部４０ｂは、ＲＡに登録されたＥＥの情報を保持する登録者リスト保持部４１と、ＲＡの秘密鍵とこれに対になる公開鍵証明書とを保持する鍵保持部４２と、を有する。
【００４６】
制御部４６は、入出力部４５を介してＲＡ装置の操作者から、ＥＥ１の公開鍵証明書の発行要求依頼文書を、ＩＡ（１２）へ送信すべき旨の指示を受け付けると、ＲＡ装置の操作者から入力された登録情報を登録者リスト保持部４１へ保持させると共に、その旨を依頼文書作成部４３に通知する。これを受けて、依頼文書作成部４３は、ＥＥ１装置（１５）による署名生成に用いる秘密鍵と、それに対する、検証に用いる公開鍵とをを作成し、登録情報とＥＥ１の公開鍵に対する署名を、鍵保持部４２に保持されているＲＡ（１１）の秘密鍵を用いて署名を生成し、当該署名と、ＥＥ１の公開鍵と登録情報とを記述した公開鍵証明書発行依頼文書を作成する。
【００４７】
そして、作成した公開鍵証明書発行依頼文書を、通信部４４を介して、ＩＡ装置（１２）へ送信する。
【００４８】
また、制御部４６は、通信部４４を介してＩＡ装置（１２）から、公開鍵証明書発行要求に対して発行された証明書を受け付けると、入出力部４５あるいは通信部４４を介してＥＥ１（１５）に送信するか、あるいは郵送できるように入出力部４５から出力する。
【００４９】
また、制御部４６は、入出力部４５を介してＲＡ装置操作者から、ＥＥ１（１５）の公開鍵証明書の失効要求依頼文書を、ＩＡ（１２）へ送信すべき旨の指示を受け付けると、その旨を依頼文書作成部４３に伝える。これを受けて、依頼文書作成部４３は、失効依頼文書を作成し、通信部４４を介してＩＡ装置（１２）へ送信する。
【００５０】
また、制御部４６は、通信部４４を介してＩＡ装置（１２）から、公開鍵証明書の失効依頼に対する応答である確認の文書を受け付けると、登録者リスト保持部４１に保持されている登録者リストから、失効した証明書に対する登録者情報を削除する。
【００５１】
次に、図４を用いてＩＡ装置を説明する。
【００５２】
図示するように、ＩＡ装置は、処理部５０ａと記憶部５０ｂと、ＮＥＴ１７を介して他装置と通信を行うための通信部５５と、公開鍵証明書等の入出力やＩＡ装置の操作者から指示を受け付ける入出力部５６と、を有する。
【００５３】
処理部５０ａは、公開鍵証明書を発行する発行部５３と、発行部５３が発行した公開鍵証明書の管理を行う管理部５４と、ＩＡ装置の各部を統括的に制御する制御部５７と、を有する。
【００５４】
記憶部５０ｂは、発行部５３が発行した公開鍵証明書を保持する公開鍵証明書データベース５１と、失効証明書リスト保持部５２と、を有する。
【００５５】
このような構成において、制御部５７は、通信部５５を介してＲＡ装置（１１）から公開鍵証明書の発行依頼を受け付けると、その旨を発行部５３に伝える。これを受けて、発行部５３は、これに対する公開鍵証明書を作成する。この際、ＲＡ（１１）の名称や、ＲＡ（１１）の署名や、必要に応じて他の項目を記述し、自ＩＡ（１２）の秘密鍵で公開鍵証明書に署名をする。そして、作成した公開鍵証明書を通信部５５を介して、ＲＡ装置（１１）へ送信する。また、この公開鍵証明書を公開鍵証明書データベース５１に登録する。
【００５６】
また、制御部５７は、通信部５５を介して、ＲＡ装置（１１）から公開鍵証明書の失効依頼を受け付けると、その旨を管理部５４に伝える。これを受けて、管理部５４は、失効対象の公開鍵証明書を公開鍵証明書データベース５１から削除する。そして、管理部５４は、失効依頼により、公開鍵証明書データベース５１から削除した公開鍵証明書に関する情報が記述された失効証明書リスト（一般に、ＣＲＬ（Certification Revocation List）、ＡＲＬ（Authority Revocation List）と呼ばれている）を、定期的に作成し、これを失効証明書リスト保持部５２に保持させる。なお、管理部５４は、作成した失効リストに、次回の失効証明書リストの作成予定日時を記述するものとする。
【００５７】
また、管理部５４は、公開鍵証明書データベース５１に格納されている各公開鍵証明書の有効期限を調査し、有効期限を過ぎている公開鍵証明書を公開鍵証明書データベース５１から削除する処理も行う。
【００５８】
図２〜図４に示すＥＥ装置、ＲＡ装置とＩＡ装置の各々は、例えば、図５に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体６９から情報を読み取れる読み取り装置６４と、ＮＥＴ１７を介して他装置と通信を行うための通新装置６５と、キーボードやマウス等の入力装置６６と、モニタやプリンタ等の出力装置６７と、これらの各装置間のデータ送受を行うインタフェース６８とを備えた、一般的な電子計算機上に構築できる。
【００５９】
そして、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、各処理部を実現できる。すなわち、通信部３６、４４、５５は、ＣＰＵ６１が通信装置６６を利用することにより、入出力部３７、４５、５６は、ＣＰＵ６１が入力装置６６や出力装置６７や読み取り装置６４を利用することにより、そして、記憶部３０ｂ、４０ｂ、５０ｂは、ＣＰＵ６１がメモリ６２や外部記憶装置６３を利用することにより実現される。また、処理部３０ａ、４０ａ、５０ａは、ＣＰＵ６１のプロセスとして実現される。
【００６０】
上記所定のプログラムは、読み取り装置６４を介して記憶媒体６９から読み出され、あるいは、通信装置６６を介してネットワークに接続された他の装置からダウンロードされて、外部記憶装置６３に導入されるものであってもよい。
【００６１】
次に、上記構成のＥＥ１（１５）、ＲＡ（１１）およびＩＡ（１２）が、図１に示すようなＣＡ１（１３）とＥＥ1（１５）の関係にある場合を例にとり、ＥＥ１（１５）、ＲＡ（１１）およびＩＡ（１２）の動作について説明する。
【００６２】
本実施形態のＥＥ１（１５）、ＲＡ（１１）およびＩＡ（１２）の動作は、公開鍵証明書の発行動作と、失効動作とに分かれる。
【００６３】
上記構成のＥＥ１（１５）、ＲＡ（１１）およびＩＡ（１２）が行う公開鍵証明書の発行動作を説明する。
【００６４】
図６は、本実施形態のＥＥ１（１５）、ＲＡ（１１）およびＩＡ（１２）で行われる公開鍵証明書の発行動作を説明するためのフロー図である。
【００６５】
ＥＥ１装置（１５）の利用者は、公開鍵証明書の発行申請に必要な情報を記載した申請書を作成し（ステップＳ１００１（Ｓ１００１と表す。以下同様。））、その申請書に記載された情報が確かなものである事を示す証明書等とともに、郵送や対面等によってＲＡ装置（１１）の操作者へ渡す（Ｓ１００２）。
【００６６】
ＲＡ装置（１１）の操作者は、公開鍵証明書発行の申請書および証明書等を受け付け（Ｓ１００３）、その申請書の内容が、確かにＥＥ１（１５）の利用者に対する情報であり、公開鍵証明書を発行できる者である事を目視や対面等によって確認する（Ｓ１００４）。
【００６７】
次に、ＲＡ装置（１１）の操作者は、申請書に記載されたＥＥ装置１（１５）の利用者の登録情報を、入出力部４５を介して入力し、そして当該ＥＥ１（１５）に対する公開鍵証明書発行依頼をＩＡ装置（１２）へ送信すべき旨の指示を行う。依頼文書作成部４３は公開鍵証明書発行依頼文書を作成する（Ｓ１００５）。
【００６８】
依頼文書作成部４３の具体的な動作は、すでに説明したとおりである。図７に示すように、作成した公開鍵証明書発行依頼文書９０は、登録情報９１と、ＥＥ１装置（１５）が電子文書の署名に使用する秘密鍵に対応する公開鍵９２と、ＲＡの名前と署名と署名対象情報が記載されたＲＡ（１１）が保証する情報９３と、これらの情報（９１、９２、９３）に対するＲＡ（１１）の署名９４から構成される。
【００６９】
依頼文書作成部４３は、作成した公開鍵証明書発行依頼文書を、通信部４４とＮＥＴ１７を介してＩＡ装置（１２）へ送信する（Ｓ１００６）。
【００７０】
ＩＡ（１２）は、公開鍵証明書発行依頼文書９０を、ＲＡ（１１）が発行したことを周知の技術で認証し、受け付ける。（Ｓ１００７）。
【００７１】
発行部５３は、公開鍵証明書発行依頼に応答して、図８に示す公開鍵証明書１００を作成する（Ｓ１００８）。
【００７２】
公開鍵証明書に記載する情報には、公開鍵の発行者名であるＩＡ（１２）の名称１０５や、ＩＡ（１２）に割り当てられた証明書のシリアル番号１０４などＩＡが設定すべき情報と、発行部５３が公開鍵証明書依頼文書９０に含まれる情報から抽出した、公開鍵証明書の主体者であるＥＥ１名１０６や、公開鍵９２や、ＲＡ（１１）が保証する情報９３などがある。
【００７３】
図８に示すように、公開鍵証明書１００は、基本領域１０１と、拡張領域１０２と、ＩＡ署名１０３と、からなり、基本領域１０１には、シリアル番号１０４と、ＩＡ名１０５と、ＥＥ名１０６と、ＥＥ１（１５）の公開鍵９２などが記載され、ＲＡが保証する情報９３などの、拡張領域が記載される。
【００７４】
次に、発行部５３は、基本領域１０１と拡張領域１０２の情報に対して、ＩＡの秘密鍵で署名１０３を生成し、公開鍵証明書１００を作成する。
【００７５】
ＩＡ装置（１２）は、作成された公開鍵証明書１００を、公開鍵証明書データベース５１に登録し、ＮＥＴ１７を介してＲＡ装置（１１）に送信する（Ｓ１００９）。
【００７６】
ＲＡ装置（１１）は、ＮＥＴ１７を介して公開鍵証明書１００を受け付けたら（Ｓ１０１０）、通信部３６または入出力部３７を介して、通信または郵送による安全な方法により、ＥＥ１（１５）に公開鍵証明書１００とそれに対する秘密鍵を渡す（Ｓ１０１１）。
【００７７】
ＥＥ１装置（１５）は、ＲＡ装置（１１）から公開鍵証明書１００と、それに対する秘密鍵を受け付け（Ｓ１０１２）、鍵保持部３２へ保持する。
【００７８】
次に、公開鍵証明書発行依頼文書９０や、公開鍵証明書１００の拡張領域１０２に記載される、ＲＡが保証する情報９３を、説明する。
【００７９】
まず、図９を参照し、署名対象識別子を用いて、ＲＡが保証する情報９３を示す方法を説明する。
【００８０】
図示するように、署名対象識別子を用いる場合、ＲＡが保証する情報９３は、ＲＡ名１１１と、ＲＡが保証する情報を示す署名対象識別子１１２と、ＲＡの秘密鍵で生成したＲＡ署名１１３と、から構成される。
【００８１】
署名対象識別子１１２を具体的に説明する。署名対象識別子は、ＲＡがＳ１００４で確認および審査した情報のうち、公開鍵証明書に記載される情報を示すものである。ＲＡが保証する情報は、例えば、ＥＥ名（SubjectName）や、公開鍵（PublicKey）や、ＥＥの属性情報などがあり、対象情報の選び方がいろいろ考えられる。そのため、対象情報の一つ以上の組み合わせを指定する識別子を一つ以上あらかじめ、システムで定めてＲＡ、ＥＥ、ＩＡがアクセス可能な状態で登録しておく。ＲＡは、この識別子が示す情報に対して署名を生成する（ＲＡの署名１１３）。
【００８２】
上記実施形態のように、署名対象識別子を用いてＲＡが保証する情報部９３を記載する場合、ＲＡがどのような情報を保証するかによって署名対象識別子を登録する。そのため、様々な組み合わせを署名対象情報に指定できることから、ＣＡの運営者のニーズに柔軟に対応することができる。
【００８３】
また、次に示す、署名対象情報のハッシュ値を用いる方法も可能である。
【００８４】
図１０に示すように、署名対象情報のハッシュ値を用いる場合、ＲＡが保証する情報９３は、登録機関名１２１と、登録機関が保証する情報のハッシュ値部１２２〜１２３と、これらの情報に対してＲＡ（１１）の秘密鍵で生成した登録機関名１２４と、から構成される。
【００８５】
登録機関が保証する情報のハッシュ値部１２２〜１２３は、ＲＡ（１１）がＳ１００４で確認および審査した情報のうち、公開鍵証明書に記載される情報のそれぞれのハッシュ値が記載される。ＲＡが保証する情報は、例えば、ＥＥの名称（subjectName）や、公開鍵（publicKey）や、その他のＥＥの属性情報がある。
【００８６】
ＲＡ（１１）は、ＲＡ名１２１と、登録機関が保証する情報のハッシュ値部１２２〜１２３に対して、署名を生成する（登録機関の署名１２４）。
【００８７】
署名対象情報のハッシュ値を用いて、ＲＡが保証する情報部９３を記載する場合、各署名対象情報のハッシュ値に対して、証明書に記載された情報と対応しているかを確認する必要があるものの、署名対象識別子を登録すること無しに署名による保証対象情報を示すことができる。
【００８８】
次に、ＲＡ（１１）およびＲＡの公開鍵証明書発行機関における、ＲＡ（１１）の公開鍵証明書の失効動作について説明する。
【００８９】
ＲＡ（１１）の運営者（責任者）は、ＲＡ（１１）の公開鍵証明書を失効させる場合、公開鍵証明書失効依頼文書を確実な方法（通信による署名付文書の送付や、手渡し等）でＲＡの公開鍵証明書発行機関へ送付する。
【００９０】
ＲＡ（１１）の公開鍵証明書発行機関は、公開鍵証明書失効依頼文書を、ＲＡ（１１）が発行したことを周知の技術で認証し、受け付ける。
【００９１】
ＲＡ（１１）の公開鍵証明書発行機関は、周知の技術でＲＡ（１１）の公開鍵証明書を失効させる。すなわち、ＲＡ（１１）の公開鍵証明書発行機関のデータベースからＲＡ（１１）の公開鍵証明書を削除し、証明書発行機関の署名が付与された証明書失効リストを定期的に発行する。
【００９２】
このように、本実施形態による公開鍵証明書は、ＲＡの公開鍵証明書を失効させることにより、ＲＡ毎に一括で有効でないものとできる。この方法により、全てのＥＥの公開鍵証明書を失効させる場合に比べて、証明書失効リストの容量が削減できる。
【００９３】
次に、図１に示す構成において、ＥＥ２装置（１６）がＥＥ１装置（１５）の公開鍵証明書を検証する場合の動作を説明する。
【００９４】
ＥＥ２装置（１６）は、ＥＥ１装置（１５）から、署名付き電子文書と公開鍵証明書を受け付けると、上述の通り、その電子文書の署名検証と、公開鍵証明書の検証を行う。
【００９５】
図１１は、ＥＥ２装置（１６）の署名検証部３５が行う公開鍵証明書の検証動作を説明するためのフロー図である。
【００９６】
署名検証部３５は、ＥＥ２から公開鍵証明書の検証の指示を受け付けると、ＥＥ２装置（１６）の信頼する認証局ＣＡ２（１４）の自己署名証明書から、ＥＥ１（１５）の公開鍵証明書までのパスを構築する（Ｓ３００１）。
【００９７】
具体的には、ＥＥ２装置（１６）の署名検証部３５は、ＥＥ１（１５）の公開鍵証明書から、当該証明書の発行機関名の情報（ＩＡ名）を得る。
【００９８】
そして、ＩＡ装置（１２）の公開鍵証明書データベース１８１へアクセスし、ＣＡ２（１４）からＩＡ（１２）へ発行された公開鍵証明書を得て、鍵保持部３２に保持する。
【００９９】
ＣＡ２（１４）は、ＥＥ２（１６）の信頼する認証局であるため、ＥＥ１装置（１５）から送付されたＥＥ１（１５）の公開鍵証明書と、ＩＡ装置（１２）から入手したＩＡ（１２）の公開鍵証明書と、鍵保持部３２に保持されているＣＡ２（１４）の自己署名証明書を集めることにより、認証パスが構築できたことになる。
【０１００】
署名検証部３５は、各証明書の検証を行うことにより、Ｓ３００１で構築されたパスについて、以下の通り検証を行う。（Ｓ３００２）
署名検証部３５は、ＣＡ２（１４）の自己署名証明書に含まれるＣＡ２（１４）の公開鍵を用いて、ＩＡ（１２）の公開鍵証明書に付与された署名の検証を行うと共に、これらの公開鍵証明書の内容が整合しているかを確認する。次に、ＩＡ（１２）の公開鍵証明書に含まれるＩＡ（１２）の公開鍵を用いて、ＥＥ１の公開鍵証明書に付与された署名の検証を行うと共に、これらの公開鍵証明書の内容が整合しているかを確認する。
【０１０１】
以上のように、認証パスを構成する全ての証明書に関して、署名検証と整合性を確認することにより、パスの検証を行う。
【０１０２】
次に、署名検証部３５は、検証対象の公開鍵証明書に記載されたＲＡを特定する情報（例えばＲＡ名）に基づいて、ＲＡ（１１）の公開鍵証明書をその発行機関のデータベースから入手し、そのＲＡの公開鍵証明書に含まれるＲＡ（１１）の公開鍵を用いて、ＥＥ１（１５）の公開鍵証明書の拡張領域に記載されたＲＡの署名を検証する。（Ｓ３００３）
また、ＲＡの公開鍵証明書は、検証対象の公開鍵証明書の拡張領域に記載しておくことにより、検証者が入手する方法も可能である。
【０１０３】
署名検証部３５は、Ｓ３００３で用いたＲＡ（１１）の公開鍵証明書へのパスを構築する（Ｓ３００４）。
【０１０４】
すなわち、ＥＥ２（１６）の信頼するＣＡ２（１４）から、ＲＡ（１１）までのパスを構築する。このＲＡ（１１）までのパスは、ＲＡ（１１）の公開鍵証明書がどこから発行されているかによって異なる。
【０１０５】
まず、図１４に示すように、ＲＡ（１１）の公開鍵証明書が、ＩＡ（１２）から発行されている場合において、ＲＡ（１１）の公開鍵証明書までのパスを構築する例について説明する。
【０１０６】
署名検証部３５は、ＲＡ（１１）の公開鍵証明書から、当該証明書を発行したＩＡの情報を得る。
【０１０７】
そして、その発行したＩＡ装置（１２）の公開鍵証明書データベース１８１にアクセスし、ＩＡ（１２）がＣＡ２（１４）から発行された公開鍵証明書を得る。
【０１０８】
ＣＡ２（１４）は、ＥＥ２（１６）が信頼する認証局であるため、認証パスを構成する証明書は、Ｓ３００３で用いたＲＡ（１１）の公開鍵証明書と、ＩＡ装置（１２）の公開鍵証明書データベース１８１から入手したＩＡ（１２）の公開鍵証明書と、鍵保持部３２に保持されているＣＡ２（１４）の自己署名証明書となる。
【０１０９】
ここで、ＩＡ（１２）の公開鍵証明書と、ＣＡ２（１４）の自己署名証明書は、Ｓ３００１で既に使用されているため、本ステップで再度利用することができるものとする。
【０１１０】
ＥＥ２装置（１６）の制御部３８は、Ｓ３００２と同様の方法にて、Ｓ３００４において構築されたＲＡ（１１）までのパスの検証を行う（Ｓ３００５）。
【０１１１】
以上のＳ３００２、Ｓ３００３、Ｓ３００５における全ての検証に成功した場合、ＥＥ１（１５）の公開鍵証明書の有効性が確認できたことになる。確認結果は、ＥＥ２装置（１６）の入出力部３７を介して、利用者に示される（Ｓ３００６）。
【０１１２】
また、上記実施形態とは異なり、図１５に示すように、ＲＡ（１１）の公開鍵証明書が、ＣＡ２（１４）と相互認証を行っているＣＡ３（１９２）から発行されていてもよい。その場合は、以下のように、ＲＡ（１１）の公開鍵証明書までのパスを構築する。
【０１１３】
署名検証部３５は、Ｓ３００３で用いたＲＡ（１１）の公開鍵証明書から、ＲＡ（１１）の公開鍵証明書の発行機関ＣＡ３（１９２）の情報を入手する。そして、そのＣＡ３（１９２）の公開鍵証明書データベース（１９３）へアクセスし、ＣＡ３（１９２）がＣＡ２（１４）から発行された証明書を入手する。
【０１１４】
ＣＡ２（１４）は、ＥＥ２（１６）の信頼する認証局であるため、認証パスを構成する公開鍵証明書は、Ｓ３００３で用いたＲＡ（１１）の公開鍵証明書と、ＣＡ３（１９２）の公開鍵証明書データベース１９３から入手したＣＡ３（１９２）の公開鍵証明書と、鍵保持部３２に保持されているＣＡ２（１４）の自己署名証明書となる。
【０１１５】
また、ＲＡの署名の検証方法は、ＲＡ（１１）が保証する情報部９３を示す方法によって異なる。
【０１１６】
まず、署名対象識別子を用いて、ＲＡが保証する情報部９３を示す場合において、ＲＡの署名１１３を検証する方法を示す。
【０１１７】
図１２は、署名対象識別子を用いた場合において、ＥＥ２（１６）が、ＲＡの署名１１３の検証を行う動作を説明するためのフロー図である。
【０１１８】
ＥＥ２（１６）の署名検証部３５は、ＥＥ１（１５）の公開鍵証明書に記載される署名対象識別子１１２が示す項目（図９の例では登録機関名、ＥＥ名、公開鍵を示す）を、当該公開鍵証明書から集め（Ｓ４００１）、そのハッシュ値を取る（Ｓ４００２）。それと共に、ＲＡ（１１）の公開鍵証明書に記載された公開鍵を用いて、ＥＥ１（１５）の公開鍵証明書に記載されたＲＡの署名１１３を復号化する（Ｓ４００３）。そして、Ｓ４００２とＳ４００３からそれぞれ出力される値を比べ、等しいかどうかを確認する（Ｓ４００４）。
【０１１９】
この結果が等しければ、ＲＡの署名１１３が有効であることを検証できたことを意味する（Ｓ４００５）。逆に、等しくない場合、ＲＡの署名１１３が有効でないことを意味する（Ｓ４００６）。
【０１２０】
次に、署名対象情報のハッシュ値を用いて、ＲＡが保証する情報部９３を示す場合における、登録機関の署名１２４の検証方法を示す。
【０１２１】
図１３は、署名対象情報のハッシュ値を用いた場合において、ＥＥ２（１６）が、ＲＡの署名１１３の検証を行う動作を説明するためのフロー図である。
【０１２２】
ＥＥ２（１６）の署名検証部３５は、ＲＡ名１２１と、署名対象情報のハッシュ値部１２２〜１２３に対して、ハッシュ値を取る（Ｓ５００１）。それと共に、ＲＡ（１１）の公開鍵証明書に記載された公開鍵を用いて、ＥＥ１（１５）の公開鍵証明書に記載されたＲＡの署名１２４を復号化する（Ｓ５００２）。そして、Ｓ５００１とＳ５００２からそれぞれ出力される値を比べ、等しいかどうかを確認する（Ｓ５００３）。これらの値が等しくない場合、ＲＡの署名１２４は有効でないことになる（Ｓ５００６）。等しい場合はＳ５００４へ進む。
【０１２３】
Ｓ５００４では、登録情報のハッシュ値部１２２〜１２３の各値が、公開鍵証明書の各情報と対応しているかを確認する。すなわち、公開鍵証明書のＥＥ名１０６のハッシュを取った値と、ＥＥ名のハッシュ値１２２が同じであることを確認し、同様に公開鍵９２のハッシュ値を取った値と、公開鍵のハッシュ値１２３が同じであることを確認する。
【０１２４】
この結果が等しければ、ＲＡの署名１２４が有効であることを検証できたことを意味する（Ｓ５００５）。逆に、等しくない場合、ＲＡの署名１２４は有効でないことを意味する（Ｓ５００６）。
【０１２５】
以上、本発明の実施形態について説明した。
【０１２６】
上記の各実施形態では、ＥＥ１（１５）の公開鍵証明書の拡張領域に、ＲＡ（１１）の署名１１３（または１２４）を含んだＲＡの保証する情報部９３を記載している。そして、その公開鍵証明書を受け取った他のＥＥは、当該公開鍵証明書のＲＡの署名を検証することで、そのＲＡが保証する情報部９３が示す記載事項がＲＡ（１１）により保証されていることを確かめることができる。すなわち、公開鍵証明書に記載されたＥＥ１（１５）は、ＲＡ（１１）により本人確認および審査されたことを、その公開鍵証明書を受け取ったＥＥが確認することができる。ＲＡが保証する情報部９３が示す記載事項以外の事項は、当該公開鍵証明書のＩＡの署名を検証することで、ＩＡにより保証されていることになる。
【０１２７】
なお、本発明は、上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１２８】
例えば、上記の実施形態では、一箇所のＲＡで本人確認および審査を行う形態であるが、本発明はこれに限定されない。ＥＥ１（１５）の本人確認および審査を、複数のＲＡで行い、公開鍵証明書の拡張領域に、各ＲＡで確認された情報が何かを示すために、ＲＡが保証する情報部９３を、複数記載してもよい。
【０１２９】
また、上記実施形態においては、公開鍵証明書に、検証者が署名対象範囲を知ることができる情報が含まれていた。これらに対し、公開鍵証明書に記載する情報のうち、ＲＡが保証する署名対象情報をシステム内であらかじめ決めておく方法を用いても良い。その場合、ＲＡ（１１）は、あらかじめ指定された情報に対してＲＡ（１１）の署名を生成する。ＲＡが保証する情報部９３には、ＲＡの名前と署名を記載するだけで良い。
【０１３０】
この方法における、登録機関の署名の検証方法を示す。
【０１３１】
まず、あらかじめ署名対象情報として指定されている項目を、公開鍵証明書から集め、それに対してハッシュ値をとる。そして、登録機関の署名をＲＡの公開鍵で復号化し、上記の値と同じであるかを調べる。この結果が等しければ、ＲＡの署名が有効であることを確認できたことを意味する。逆に、等しくない場合、ＲＡの署名は有効でないことを意味する。
【０１３２】
ＲＡが、あらかじめ指定されている場合、署名対象情報のハッシュ値が公開鍵証明書のどの項目に対応しているかを確認する必要がないため、署名対象情報のハッシュ値を取る場合に比べて検証処理が軽減される。
【０１３３】
【発明の効果】
本発明によれば、公開鍵証明書に記載される情報のうち、登録機関が保証する情報の範囲および内容を、それを受け取ったＥＥが確認することができる。すなわち、その公開鍵証明書の内容（誰が何を保証しているか）を、ＥＥが確認することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態が適用されたＰＫＩシステムの構成図である。
【図２】図１に示すＥＥの概略構成を示す図である。
【図３】図１に示すＲＡの概略構成を示す図である。
【図４】図１に示すＩＡの概略構成を示す図である。
【図５】図２〜図４に示すＥＥ、ＲＡおよびＩＡの各々のハードウェア構成例を示す図である。
【図６】図１に示すＥＥ１、ＲＡおよびＩＡで行われる公開鍵証明書の発行動作を示すためのフロー図である。
【図７】図６のステップＳ１００５で作成される公開鍵証明書発行依頼文書の概略構成を示す図である。
【図８】図６のステップＳ１００９で作成される公開鍵証明書の概略構成を示す図である。
【図９】図８に示す情報９３を署名対象識別子を用いて示す場合の概略構成を示す図である。
【図１０】図８に示す情報９３を登録情報のハッシュ値を用いて示す場合の概略構成を示す図である。
【図１１】図１に示すＥＥ２が、ＥＥ１の公開鍵証明書を検証する動作を示すためのフロー図である。
【図１２】署名対象識別子を用いてＲＡが保証する情報９３を示した場合において、ＲＡの署名１１３の検証動作を示すためのフロー図である。
【図１３】登録情報のハッシュ値を用いてＲＡが保証する情報９３を示した場合において、ＲＡの署名１２４の検証動作を示すためのフロー図である。
【図１４】ＲＡの証明書がＩＡから発行されている場合の概略構成を示した図である。
【図１５】ＲＡの証明書が、他の認証局であるＣＡ３から発行されている場合の概略構成を示した図である。
【符号の説明】
１１・・・ＲＡ、１２，２０５・・・ＩＡ、１３・・・ＣＡ１、１４・・・ＣＡ２、１５・・・ＥＥ１、１６・・・ＥＥ２、１７・・・ＮＥＴ、３０ａ，４０ａ，５０ａ・・・処理部、３０ｂ，４０ｂ，５０ｂ・・・記憶部、３１・・・電子文書保持部、３２，４２・・・鍵保持部、３３・・・検証対象保持部、３４・・・署名生成部、３５・・・署名検証部、３６，４４，５５・・・通信部、３７，４５，５６・・・入出力部、３８，４６，５７・・・制御部、４１・・・登録者リスト保持部、４３・・・依頼文書作成部、５１・・・公開鍵証明書データベース、５２・・・失効証明書リスト保持部、５３・・・発行部、５４・・・管理部、６１・・・ＣＰＵ、６２・・・メモリ、６３・・・外部記憶装置、６４・・・読取装置、６５・・・通信装置、６６・・・入力装置、６７・・・出力装置、６８・・・インタフェース、６９・・・記憶媒体
９１・・・登録情報、９２・・・公開鍵、９３・・・ＲＡが保証する情報、９４・・・ＲＡの署名、１０１・・・基本領域、１０２・・・拡張領域、１０３・・・ＩＡの署名、１０４・・・シリアル番号、１０５・・・ＩＡ名、１０６・・・ＥＥ名、１１１，１２１・・・ＲＡ名、１１２・・・署名対象識別子、１１３，１２４・・・ＲＡの署名、１２２・・・ＥＥ名のハッシュ値、１２３・・・公開鍵のハッシュ値、１８１、１９３・・・証明書データベース、１９２・・・ＣＡ３、２０１，２１１・・・ＲＡ１、２０２，２１２・・・ＲＡ２、２０３，２１７・・・アウトソーシング先機関、２０４・・・ＩＡの秘密鍵、２１３・・・ＩＡ１、２１４・・・ＩＡ２、２１５・・・ＩＡ１の秘密鍵、２１６・・・ＩＡ２の秘密鍵。

Claims (10)

1. 公開鍵基盤において、登録機関装置と発行機関装置を備える公開鍵証明書生成システムであって、
   前記登録機関装置は、
   公開鍵証明書への登録情報である第1の情報に対して署名を生成する第1の署名生成手段と、
   前記第1の情報と、前記第1の署名生成手段によって生成された第1の署名とから構成される証明書発行依頼を作成する証明書発行依頼作成手段と、
   を備え、
   前記発行機関装置は、
   前記第1の情報と、前記第1の署名と、前記発行機関装置が発行する情報である第2の情報に対して署名を生成する第2の署名生成手段と、
   前記第1の情報と、前記第1の署名と、前記第2の情報と前記第2の署名生成手段によって生成された第2の署名とから構成される公開鍵証明書を生成する生成手段と
   を備えることを特徴とする公開鍵証明書の生成システム。
2. 請求項1記載の公開鍵証明書の生成システムにおいて、
   前記第1の情報は、
   前記第1の情報を指定する識別子を有することを特徴とする公開鍵証明書の生成システム。
3. 請求項1記載の公開鍵証明書の生成システムにおいて、
   前記第1の情報は、
   前記第1の情報にハッシュ関数を作用させて求められるハッシュ値と、
   前記登録機関装置が前記ハッシュ値に対して生成する第3の署名と
   を有することを特徴とする公開鍵証明書の生成システム。
4. 公開鍵基盤において、登録機関装置と発行機関装置とエンドエンティティ装置を備える公開鍵証明書の検証システムであって、
   前記公開鍵証明書は、
   該公開鍵証明書への登録情報である第 1 の情報と、前記登録機関が前記登録情報に対して生成した第 1 の署名と、前記発行機関装置が発行する情報である第 2 の情報と、前記発行機関装置が前記第 1 の情報、前記第 2 の情報及び第 1 の情報に対して生成する第 2 の署名とから構成され、
   前記エンドエンティティ装置は、
   公開鍵証明書を受け付ける受付手段と、
   前記第1の署名と前記第2の署名を検証する検証手段と、
   前記第1の署名及び前記第2の署名の対象となった情報を利用者に表示する表示手段と
   を備えることを特徴とする公開鍵証明書の検証システム。
5. 公開鍵基盤において、登録機関装置と発行機関装置とエンドエンティティ装置を備える公開鍵証明書の検証システムであって、
   前記エンドエンティティ装置は、
   公開鍵証明書を受け付ける受付手段と、
   検証手段とを備え、
   前記公開鍵証明書は、
   該公開鍵証明書への登録情報である第 1 の情報と、前記登録機関が前記登録情報に対して生成した第1の署名と、前記発行機関装置が発行する情報である第2の情報と、前記発行機関装置が前記第1の情報、前記第2の情報及び前記第1の署名に対して生成する第2の署名とから構成され、
   前記第1の情報は該第1の情報を指定する識別子を有し、
   前記検証手段は、
   前記第1の情報を前記公開鍵証明書から取得し、該取得した第1の情報のハッシュ値を求め、前記第1の署名を前記登録機関装置の公開鍵で復号化し、前記ハッシュ値と前記復号化した値が等しいかどうかを調べることを特徴とする公開鍵証明書の検証システム。
6. 公開鍵基盤において、登録機関装置と発行機関装置とエンドエンティティ装置とを備える公開鍵証明書の検証システムであって、
   前記エンドエンティティ装置は、
   公開鍵証明書を受け付ける受付手段と、
   検証手段とを備え、
   前記公開鍵証明書は、
   該公開鍵証明書への登録情報である第１の情報と、前記登録機関が前記登録情報に対して生成した第1の署名と、前記発行機関装置が発行する情報である第2の情報と、前記発行機関装置が前記第1の情報、前記第2の情報及び前記第1の署名に対して生成する第2の署名とから構成され、
   前記第1の情報は該第1の情報にハッシュ関数を作用させて求められる第1のハッシュ値と、前記登録機関装置が前記ハッシュ値に対して生成する第3の署名を有し、
   前記検証手段は、
   前記公開鍵証明書に記載された情報のハッシュ値である第2のハッシュ値と前記第1のハッシュ値とを比較することを特徴とする公開鍵証明書の検証システム。
7. 請求項4記載の公開鍵証明書の検証システムにおいて、
   前記エンドエンティティ装置は、
   前記利用者が信頼する認証局から、前記公開鍵証明書までのパス構築と該パスを検証し、前記第1の署名を前記登録機関装置の公開鍵で検証することを特徴とする公開鍵証明書の検証システム。
8. 請求項7記載の公開鍵証明書の検証システムにおいて、
   前記エンドエンティティ装置は、
   前記公開鍵証明書に記載された前記登録機関装置の名前に基づいて、該公開鍵証明書を発行した前記発行機関装置の情報を取得し、該発行機関装置の公開鍵証明書データベースから、前記登録機関装置の公開鍵証明書を取得することを特徴とする公開鍵証明書の検証システム。
9. 請求項7記載の公開鍵証明書の検証システムにおいて、
   前記エンドエンティティ装置は、
   前記パス構築の際、前記公開鍵証明書に記載された前記登録機関装置の公開鍵証明書を取得することを特徴とする公開鍵証明書の検証システム。
10. 請求項1記載の公開鍵証明書の生成システムにおいて、
    前記登録機関装置は、該登録機関装置の公開鍵証明書の発行機関装置へ証明書失効要求を送付し、
    前記発行機関装置は、前記証明書失効要求を受け取り、該証明書失効要求に基づいて、前記登録機関装置の前記発行機関装置用のデータベースから公開鍵証明書を削除し、前記登録機関装置の署名を付与した証明書失効リストを定期的に発行することを特徴とする公開鍵証明書の生成システム。

Images