(57)【要約】【課題】機器に対するクライアント証明書の発行をより適切に行う。【解決手段】機器に対して証明書を発行する認証局として動作する情報処理装置は、機器に接続して機器の存在確認をする存在確認手段と、所与のアクセス権限情報を参照して機器の所与のサービスに関するアクセス権限を確認する権限確認手段と、存在確認手段による確認結果と権限確認手段による確認結果とに基づいて機器にクライアント証明書を発行する発行手段と、を有する。【選択図】図３
2019004289.tif 000002
【特許請求の範囲】
【請求項１】
機器に対して証明書を発行する認証局として動作する情報処理装置であって、
機器に接続して該機器の存在確認をする存在確認手段と、
所与のアクセス権限情報を参照して前記機器の所与のサービスに関するアクセス権限を確認する権限確認手段と、
前記存在確認手段による確認結果と前記権限確認手段による確認結果とに基づいて前記機器にクライアント証明書を発行する第１の発行手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記存在確認手段は、ＡＣＭＥ（Automatic Certificate Management Environment）プロトコルに準拠した通信により前記存在確認を実行する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記機器にサーバ証明書を発行する第２の発行手段と、
前記機器から受信したサーバ証明書の証明書署名要求に含まれる第２の公開鍵と、該機器から受信したクライアント証明書の証明書署名要求に含まれる第１の公開鍵と、を比較する比較手段と、
を更に有し、
前記第１の発行手段は、前記比較手段により前記第１の公開鍵と前記第２の公開鍵とが同一であると判定された場合、前記クライアント証明書の発行を抑止する
ことを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記存在確認手段は、前記機器とＴＬＳ通信路を確立することにより前記存在確認を実行する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記存在確認手段は、前記ＴＬＳ通信路を確立する際に前記機器から受信されるサーバ証明書を検証することにより前記存在確認を実行する
ことを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記機器から受信したクライアント証明書の証明書署名要求に含まれる第１の公開鍵の使用用途が所定の用途であるか否かを確認する確認手段を更に有し、
前記第１の発行手段は、前記確認手段により前記第１の公開鍵の使用用途が前記所定の用途ではないと確認された場合、前記クライアント証明書の発行を抑止する
ことを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
前記所与のアクセス権限情報は、機器の識別子と、サービスを示すＵＲＩ（Uniform Resource Identifier）と、該機器の該サービスへのアクセス可否を示す情報と、を関連付けたレコードを含むテーブルとして構成される
ことを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
【請求項８】
機器に対して証明書を発行する認証局として動作する情報処理装置の制御方法であって、
機器に接続して該機器の存在確認をする存在確認工程と、
所与のアクセス権限情報を参照して前記機器の所与のサービスに関するアクセス権限を確認する権限確認工程と、
前記存在確認工程における確認結果と前記権限確認工程における確認結果とに基づいて前記機器にクライアント証明書を発行する発行工程と、
を有することを特徴とする情報処理装置の制御方法。
【請求項９】
コンピュータを、請求項１乃至７の何れか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【請求項１０】
機器と該機器に対して証明書を発行する認証局とを含む情報処理システムであって、
前記認証局は、
前記機器に接続して該機器の存在確認をする存在確認手段と、
所与のアクセス権限情報を参照して前記機器の所与のサービスに関するアクセス権限を確認する権限確認手段と、
前記存在確認手段による確認結果と前記権限確認手段による確認結果とに基づいて前記機器にクライアント証明書を発行する発行手段と、
を有することを特徴とする情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、公開鍵証明書を発行する認証局として動作する情報処理装置およびその制御方法、システムに関するものである。
【背景技術】
【０００２】
ＩＰネットワークの通信路を暗号化するプロトコルであるＴＬＳ（Transport Layer Security）等で、通信相手のなり済ましを防ぐために公開鍵証明書が使用されている。例えば、Ｗｅｂサーバから送信された公開鍵証明書（サーバ証明書）をＷｅｂブラウザが検証することによってＷｅｂサーバが正当な通信相手であることを認証することができる。
【０００３】
サーバ認証に用いる公開鍵証明書であるサーバ証明書は以下の手順で発行される。まず、サーバ上で当該サーバの公開鍵を含んだ証明書署名要求を生成し、認証局に送信する。次に、認証局がサーバの実在性を確認した上でサーバの公開鍵に認証局の秘密鍵を用いて署名し、所定のフォーマットで公開鍵証明書を生成する。
【０００４】
非特許文献１には、サーバ証明書の発行と設定の自動化を目的としたＡＣＭＥプロトコルが提案されている。ＡＣＭＥプロトコルでは、認証局がサーバにアクセスし存在確認することにより、証明書署名要求生成から公開鍵証明書発行までの一連のプロセスを自動化している。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Automatic Certificate Management Environment (ACME), draft-ietf-acme-acme-03，https://datatracker.ietf.org/doc/draft-ietf-acme-acme/，２０１６年
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述のＡＣＭＥプロトコルにおいては、ＴＬＳサーバ機能とＴＬＳクライアント機能とを併せ持つ機器に対する適切なクライアント証明書の発行ルールについての規定が存在しない。そのため、クライアント証明書の発行をサーバ証明書の発行と同様に行った場合、発行したクライアント証明書は「ホスト名が適切に設定されたデバイス」ということを証明しているに過ぎない。すなわち、サービスへのアクセス権限を持つことについては証明することが出来ない。
【０００７】
本発明はこのような問題を鑑みてなされたものであり、機器に対するクライアント証明書の発行をより適切に実行可能とする機構を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述の問題点を解決するため、本発明に係る情報処理装置は以下の構成を備える。すなわち、機器に対して証明書を発行する認証局として動作する情報処理装置は、機器に接続して該機器の存在確認をする存在確認手段と、所与のアクセス権限情報を参照して前記機器の所与のサービスに関するアクセス権限を確認する権限確認手段と、前記存在確認手段による確認結果と前記権限確認手段による確認結果とに基づいて前記機器にクライアント証明書を発行する第１の発行手段と、を有する。
【発明の効果】
【０００９】
本発明によれば、機器に対するクライアント証明書の発行をより適切に実行可能とする機構を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態に係る情報処理システムの構成要素を示したブロック図である。
【図２】デバイス／サービス対応表を例示的に示す図である。
【図３】第１実施形態におけるクライアント証明書の発行動作を示すシーケンス図である。
【図４】第２実施形態におけるクライアント証明書の発行動作を示すシーケンス図である。
【図５】情報処理装置のハードウェア構成を示す図である。
【発明を実施するための形態】
【００１１】
以下に、図面を参照して、この発明の実施の形態の一例を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。
【００１２】
（第１実施形態）
本発明に係る情報処理装置の第１実施形態として、ＡＣＭＥプロトコルに則って機器（デバイス）の存在確認を行う認証局（ＡＣＭＥサーバ）を例に挙げて以下に説明する。ＡＣＭＥは、Automatic Certificate Management Environmentの略である。
【００１３】
＜システム構成＞
図１は、第１実施形態に係る情報処理システムの構成要素を示したブロック図である。情報処理システムは、公開鍵証明書（クライアント証明書など）のインストール先である機器１００と、公開鍵証明書を発行する認証局２００とを含む。機器１００と認証局２００とは任意の通信路を介して通信可能になるように接続されている。
【００１４】
機器１００は、ＨＴＴＰサーバ１０１、ＴＬＳサーバ１０２、ＨＴＴＰクライアント１０３、ＴＬＳクライアント１０４の各機能部を有している。すなわち、機器１００は、ＨＴＴＰプロトコルを介して他の装置にアクセスする機能、及び、他の機器からのアクセスを受け付ける機能を有している。また、当該アクセスにＴＬＳを用いることが可能になるように構成されている。機器１００は、さらに、ＡＣＭＥプロトコル処理で利用されるアカウント公開鍵１０６およびアカウント秘密鍵１０７を有している。なお、アカウント公開鍵１０６およびアカウント秘密鍵１０７を格納した記憶媒体（光学ディスク、半導体記憶メディアなど）にアクセスする構成でもよい。
【００１５】
認証局２００は、ＨＴＴＰサーバ２０１、ＴＬＳサーバ２０２、ＨＴＴＰクライアント２０３、ＴＬＳクライアント２０４の各機能部を有している。すなわち、認証局２００も、ＨＴＴＰプロトコルを介して他の装置にアクセスする機能、及び、他の機器からのアクセスを受け付ける機能を有している。また、当該アクセスにＴＬＳを用いることが可能になるように構成されている。認証局２００は、さらに、デバイス／サービス対応表２０５を備える。デバイス／サービス対応表２０５の詳細については後述する。
【００１６】
図５は、情報処理システムの各装置（機器１００、認証局２００）を構成する情報処理装置５００のハードウェア構成を示す図である。ここでは、一例として一般に普及しているＰＣと同様の構成を示している。情報処理装置５００が、所定のソフトウェアプログラムを実行することにより、機器１００、認証局２００それぞれにおける各機能が実現される。
【００１７】
情報処理装置５００の内部では、バス５１０により後述する各ブロックが接続され、種々のデータの受け渡しが可能である。ＭＰＵ５０１は、情報処理装置５００内部の各ブロックの動作を制御し、あるいはＨＤＤ５０３もしくはＲＯＭ５０４に記憶されたプログラムを実行することができる。主記憶装置５０２は、ＭＰＵ５０１において行われる処理のために、一時的にプログラムや処理対象のデータを格納しておく装置である。
【００１８】
入力インタフェース（Ｉ／Ｆ）５０７は、キーボード５０５もしくはマウス５０６を介してユーザから入力された情報を情報処理装置５００に入力する。また、ディスプレイ５０８は、ユーザのための操作画面を表示する。また、ネットワークインタフェース（Ｉ／Ｆ）５０９は、他の機器との通信に利用される。なお、上述のユーザからの入力および操作画面の表示をネットワークＩ／Ｆ５０９を介して、外部の機器で行うよう構成してもよい。
【００１９】
＜デバイス／サービス対応表＞
図２は、デバイス／サービス対応表２０５を例示的に示す図である。デバイス／サービス対応表２０５は、「デバイスＩＤ」、「ＵＲＩ」、「接続可否」の３つの情報を関連付けたレコードを含むテーブルである。ただし、テーブル形式で構成せず、他の形式の所与のアクセス権限情報として構成してもよい。
【００２０】
「デバイスＩＤ」フィールドは、機器の識別情報（識別子）を値として格納するフィールドである。例えば、機器のシリアル番号が格納される。「ＵＲＩ」フィールドは、所与のサービスにアクセスするためのアクセス先を示す情報を値として格納するフィールドである。ここでは、サービスに対応するＵＲＩ（Uniform Resource Identifier）が格納される。「接続可否」フィールドは、「デバイスＩＤ」フィールドで指定された機器が「ＵＲＩ」フィールドで識別されるサービスにアクセス可能か否かを示す情報を値として格納するフィールドである。例えば、アクセス可能な場合には「許可」、アクセスできない場合には「不許可」の値が入る。
【００２１】
図２では、一例として、デバイスＩＤが”ＡＡＡ”の装置に対する、サーバ”Example.com”で提供される各サービスへのアクセス可否を示すテーブルを示している。ここでは、閲覧（browse）サービスへのアクセスは許可するが、アップロード（upload）サービスへのアクセスは許可しない例を示している。
【００２２】
デバイス／サービス対応表２０５は、操作画面の１つである管理ＵＩを介して管理者が手動で入力し生成してもよいし、少なくとも一部を自動的に生成してもよい。例えば、機器のＭＡＣアドレス等のネットワーク識別子を用いてデバイスＩＤを自動的に生成してもよい。また、所定のＵＲＩを有するサービス提供サーバと通信し当該機器の接続可否を決定してもよい。
【００２３】
＜システムの動作＞
図３は、第１実施形態におけるクライアント証明書の発行動作を示すシーケンス図である。第１実施形態では、「事前準備（Ｓ３０１〜Ｓ３０３）」「存在確認（Ｓ３０４〜Ｓ３１０）」「サーバ証明書発行（Ｓ３１１〜Ｓ３１５）」「クライアント証明書発行（Ｓ３１６〜Ｓ３２５）」の４つのフェーズから構成される。
【００２４】
ステップＳ３０１では、機器１００は、アカウント公開鍵１０６およびアカウント秘密鍵１０７のペアを生成する。ステップＳ３０２では、機器１００は、アカウント公開鍵１０６を認証局２００へ送信する。ステップＳ３０３では、認証局２００は、受信したアカウント公開鍵１０６を登録する。これにより、機器１００は、ＡＣＭＥクライアントとしてＡＣＭＥサーバである認証局２００への登録を完了させておく。
【００２５】
ステップＳ３０４では、機器１００は、ホスト名をＩｄｅｎｔｉｆｉｅｒとして認証局２００へ送信する。ステップＳ３０５では、認証局２００は、機器１００へチャレンジを送信する。ここでのチャレンジは、ｔｏｋｅｎと呼ばれる乱数である。ステップＳ３０６では、機器１００は、ｔｏｋｅｎをアカウント秘密鍵１０７で変換して得られる値であるレスポンスを認証局２００へ送信する。また、機器１００は、認証局２００にアクセスさせるＵＲＩを”ｈｔｔｐ：／／｛ｄｏｍａｉｎ｝／．ｗｅｌｌ−ｋｎｏｗｎ／ａｃｍｅ−ｃｈａｌｌｅｎｇｅ／｛ｔｏｋｅｎ｝”として構成し、認証局２００からアクセス可能にする。
【００２６】
ステップＳ３０７では、認証局２００は、”ｈｔｔｐ：／／｛ｄｏｍａｉｎ｝／．ｗｅｌｌ−ｋｎｏｗｎ／ａｃｍｅ−ｃｈａｌｌｅｎｇｅ／｛ｔｏｋｅｎ｝”にアクセスする。ステップＳ３０８では、機器１００は、アクセスに対するレスポンスを送信する。ステップＳ３０９では、認証局２００は、レスポンスをアカウント公開鍵１０６で変換した結果がｔｏｋｅｎと等しくなることを確認する。ステップＳ３１０では、機器１００は、認証局２００にポーリングし、認証が完了したことを通知する。これにより、認証局２００は、ＡＣＭＥプロトコルに準拠した通信により機器１００が存在することを確認することが出来る。
【００２７】
ステップＳ３１１では、機器１００は、Ｓ３１２〜Ｓ３１５で使用されることになる秘密鍵および公開鍵を生成する。ステップＳ３１２では、機器１００は、証明書署名要求（ＣＳＲ：certificate signing request）を生成する。具体的には、ホスト名、有効期間等に基づいて、サーバ証明書署名要求を生成する。ステップＳ３１３では、機器１００は、サーバ証明書署名要求にアカウント秘密鍵で署名を付与した上で認証局２００へ送信する。
【００２８】
ステップＳ３１４では、認証局２００は、署名されたサーバ証明書署名要求をアカウント公開鍵を利用して検証し、検証に成功すればサーバ証明書を生成する。ステップＳ３１５では、認証局２００は、サーバ証明書と更新用ＵＲＩを機器１００へ送信する。
【００２９】
ステップＳ３１６では、機器１００は、Ｓ３１７〜Ｓ３２５で使用されることになる秘密鍵および公開鍵を生成する。ステップＳ３１７では、機器１００は、証明書署名要求（ＣＳＲ）を生成する。具体的には、デバイスＩＤ、有効期間等に基づいて、クライアント証明書署名要求を生成する。ステップＳ３１８では、機器１００は、クライアント証明書署名要求にアカウント秘密鍵で署名を付与した上で認証局２００へ送信する。
【００３０】
ステップＳ３１９では、認証局２００は、アカウント公開鍵で署名を検証する。検証に失敗したら（Ｓ３１９のＮＯ）、クライアント証明書を発行せずに処理を終了する。検証に成功したら（Ｓ３１９のＹＥＳ）、Ｓ３２０に進む。
【００３１】
ステップＳ３２０では、認証局２００は、Ｓ３１３で受信した証明書署名要求に含まれている公開鍵とＳ３１８で受信した証明書署名要求に含まれている公開鍵とを比較する。もし同一と判定されたならば（Ｓ３２０のＮＯ）、クライアント証明書を抑止し処理を終了する。もし同一でなければ（Ｓ３２０のＹＥＳ）、Ｓ３２１に進む。
【００３２】
ステップＳ３２１では、認証局２００は、Ｓ３１８で受信した証明書署名要求に含まれている使用用途がクライアント証明書として適切である所定の用途であるか否かを確認する。ここでは、「Ｋｅｙ  Ｕｓａｇｅ」及び「Ｅｘｔｅｎｄｅｄ  Ｋｅｙ  Ｕｓａｇｅ」の値を確認する。具体的には、「Ｋｅｙ  ｕｓａｇｅ」の値が「Ｄｉｇｉｔａｌ  ｓｉｇｎａｔｕｒｅ」であり、かつ、「Ｅｘｔｅｎｄｅｄ  ｋｅｙ  ｕｓａｇｅ」の値が「ＴＬＳ  Ｗｅｂ  ｃｌｉｅｎｔ」であるか否かを確認する。適切であれば（Ｓ３２１のＹＥＳ）Ｓ３２２に進み、適切でなければ（Ｓ３２１のＮＯ）クライアント証明書を抑止し処理を終了する。
【００３３】
ステップＳ３２２では、認証局２００は、証明書署名要求中の「Ｓｕｂｊｅｃｔ」フィールドがデバイス／サービス対応表２０５の「デバイスＩＤ」項目と等しく、かつ、「接続可否」項目が「許可」となっていることを確認（権限確認）する。もし、デバイス／サービス対応表２０５に対応するデバイスＩＤが存在しなければ（ステップＳ３２２のＮＯ）、クライアント証明書を抑止し処理を終了する。存在すれば（ステップＳ３２２のＹＥＳ）、Ｓ３２３に進む。
【００３４】
ステップＳ３２３では、認証局２００は、クライアント証明書を生成する。ステップＳ３２４では、認証局２００は、機器１００へクライアント証明書と更新用ＵＲＩを送信する。ステップＳ３２５では、認証局２００は、発行したクライアント証明書を、デバイス／サービス対応表２０５のＵＲＩ項目のサービス提供サーバに送信し、登録させる。
【００３５】
なお、サーバ証明書発行（Ｓ３１１〜Ｓ３１５）に関する処理は省略してもよい。その場合はＳ３２０も不要となる。また、Ｓ３１６における公開鍵・秘密鍵の生成を電源投入時に行うように変更してもよい。
【００３６】
以上説明したとおり第１実施形態によれば、機器の存在の確認結果と当該機器のサービスへのアクセス権限の確認結果とに基づいて、当該機器へのクライアント証明書を発行する。これにより、サービスへのアクセス権限に対応したクライアント証明書を適切に発行することが可能となる。
【００３７】
また、第１実施形態では、ＡＣＭＥプロトコルに則って認証局が機器の存在確認を行った後に、クライアント証明書用のＣＳＲを機器から認証局に送信する。そして、認証局で機器が接続してよいか確認してからクライアント証明書を発行する。したがって、この形態は、ＡＣＭＥを用いて頻繁にサーバ証明書を更新する場合、同時にクライアント証明書を取得するユースケースに適合する。
【００３８】
（第２実施形態）
第２実施形態では、認証局が、サーバ認証を実行するためにＴＬＳ通信路を用いて証明書署名要求（ＣＳＲ）を機器１００から取得し、クライアント証明書を発行する形態について説明する。この形態は、ネットワーク監視サーバのように、常時ＴＬＳクライアントとＴＬＳサーバが稼働する場合に好適に実施され得る。
【００３９】
＜システムの動作＞
図４は、第２実施形態におけるクライアント証明書の発行動作を示すシーケンス図である。第２実施形態では、「ＴＬＳ通信路確立（Ｓ４０１〜Ｓ４０６）」「クライアント証明書発行（Ｓ４０８〜Ｓ４１６）」の２つのフェーズから構成される。
【００４０】
ステップＳ４０１では、機器１００は、認証局２００にＨＴＴＰクライアントとして接続リクエストを送信する。ステップＳ４０２では、認証局２００は、機器１００とのＴＬＳ確立手順を開始する。すなわち、「ＣｌｉｅｎｔＨｅｌｌｏ」メッセージを機器１００に送信する。ステップＳ４０３では、機器１００は、「ＳｅｒｖｅｒＨｅｌｌｏ」メッセージ、サーバ証明書、「ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅ」メッセージを送信する。
【００４１】
ステップＳ４０４では、認証局２００は、サーバ証明書のデジタル署名を検証する。デジタル署名検証に成功したら、Ｓ４０５に進む。ステップＳ４０５では、認証局２００は、暗号化鍵生成に使用するＰｒｅＭａｓｔｅｒＳｅｃｒｅｔをサーバ証明書の公開鍵で暗号化する。暗号化されたＰｒｅＭａｓｔｅｒＳｅｃｒｅｔを「ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ」メッセージで送信する。さらに、「ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ」、「Ｆｉｎｉｓｈｅｄ」メッセージを送信する。ステップＳ４０６は、機器１００は、「ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃ」、「Ｆｉｎｉｓｈｅｄ」メッセージを送信する。
【００４２】
以上のＴＬＳ確立手順が完了すると、機器１００と認証局２００の間でＴＬＳ通信路が確立し、データを暗号化して送受信できる。また、ＴＬＳ確立手順により、認証局２００は、機器１００の存在確認と行うことが可能となる。
【００４３】
なお、上述の説明においては、ＴＬＳ接続確立時に送受信するメッセージは、サーバ証明書を使用し、サーバ証明書の公開鍵を用いて鍵交換する暗号スイートを用いる形態について説明したが、サーバ認証を行う他の暗号スイートを用いてもよい。例えば、ＥＣＤＨ（Elliptic curve Diffie-Hellman）鍵交換方式を用いる暗号スイートが利用可能である。ただし、この場合は、送受信するメッセージは上述の説明と一部異なることになる。
【００４４】
クライアント証明書発行（Ｓ４０８〜Ｓ４１６）は、第１実施形態のＳ３１６〜Ｓ３２５に相当する。ただし、上述したように、サーバ証明書の検証処理（Ｓ４０４）によって認証局２００による機器１００の存在確認が完了している。そのため、認証局２００がアカウント公開鍵での署名検証（Ｓ３１９）は必要ないことになる。
【００４５】
以上説明したとおり第２実施形態によれば、認証局２００は、ＴＬＳ通信路を確立した上で機器１００に証明書署名要求を送信させ、クライアント証明書を発行する。すなわち、ＴＬＳ確立手順の完了をもって機器１００の存在確認とすることにより、より簡易な処理とすることが可能となる。
【００４６】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００４７】
１００  機器；  １０１  ＨＴＴＰサーバ；  １０２  ＴＬＳサーバ；  １０３  ＨＴＴＰクライアント；  １０４  ＴＬＳクライアント；  １０６  アカウント公開鍵；  １０７  アカウント秘密鍵；  ２００  認証局；  ２０１  ＨＴＴＰサーバ；  ２０２  ＴＬＳサーバ；  ２０３  ＨＴＴＰクライアント；  ２０４  ＴＬＳクライアント；  ２０５  デバイス／サービス対応表
【図１】
2019004289.tif 000003
【図２】
2019004289.tif 000004
【図３】
2019004289.tif 000005
【図４】
2019004289.tif 000006
【図５】
2019004289.tif 000007