2025-24963 証明書状態確認装置及び証明書状態確認方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025024963

(43)【公開日】2025-02-21

(54)【発明の名称】証明書状態確認装置及び証明書状態確認方法

(51)【国際特許分類】

   H04L 9/08 20060101AFI20250214BHJP

【ＦＩ】

H04L9/08 F

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023129373

(22)【出願日】2023-08-08

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000279

【氏名又は名称】弁理士法人ウィルフォート国際特許事務所

(72)【発明者】

【氏名】橋本 洋子

(72)【発明者】

【氏名】越出 和磨

(57)【要約】

【課題】属性情報が動的に変更される情報を含む場合であっても電子証明書の管理コストの増加を抑制することが可能な証明書状態確認装置提供する。
【解決手段】認証状態応答サーバ１２は、接続要求を受信した業務サーバ１４が接続要求の送信元であるクライアント機器１５から電子証明書を取得した場合、その電子証明書に含まれる属性情報の状態を確認し、その確認結果である状態確認結果を業務サーバ１４に通知する。
【選択図】図１

【特許請求の範囲】

【請求項1】

電子証明書の状態を確認する証明書状態確認装置であって、
接続要求を受信した通信装置が前記接続要求の送信元から電子証明書を取得した場合、当該電子証明書に含まれる属性情報の状態を確認し、当該確認結果である状態確認結果を前記通信装置に通知する制御部を有する証明書状態確認装置。

【請求項2】

前記属性情報は、前記状態が決定されている静的な情報と、前記状態が変化する動的な情報とを含み、
前記電子証明書は、前記静的な情報の状態を予め示し、
前記制御部は、前記動的な情報の状態を確認する、請求項１に記載の証明書状態確認装置。

【請求項3】

前記動的な情報は、前記送信元の脆弱性に対する対応状況を前記状態として示す脆弱性対応情報である、請求項２に記載の証明書状態確認装置。

【請求項4】

前記確認結果は、前記送信元の脆弱性のそれぞれを示す脆弱性情報のうち、対応していない脆弱性を示す脆弱性情報を含む、請求項３に記載の証明書状態確認装置。

【請求項5】

前記制御部は、前記通信装置が電子証明書を取得した場合、当該電子証明書が失効されているか否かをさらに確認し、当該確認結果である失効確認結果を前記状態確認結果と共に通知する、請求項１に記載の証明書状態確認装置。

【請求項6】

前記制御部は、前記属性情報の状態を管理する管理装置に前記属性情報の状態を問い合わせることで、前記属性情報の状態を確認する、請求項５に記載の証明書状態確認装置。

【請求項7】

電子証明書の状態を確認する証明書状態確認装置による証明書状態確認方法であって、
接続要求を受信した通信装置が前記接続要求の送信元から電子証明書を取得した場合、当該電子証明書に含まれる属性情報の状態を確認し、
当該確認結果である状態確認結果を前記通信装置に通知する、証明書状態確認方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、証明書状態確認装置及び証明書状態確認方法に関する。

【背景技術】

【0002】

近年、複数の情報処理装置が連携して様々な処理を行っている。このとき、連携先となる情報処理装置の脆弱性に対する対応状況などの信用性が分からず、連携の可否を判断できない場合がある。

【0003】

これに対して情報処理装置の信用性を示す信用性情報を属性情報として電子証明書に記述することで、情報処理の信用性を把握することが考えられる。しかしながら、脆弱性に関する情弱性情報は日々新たに公開されており、脆弱性対応状況などの信用性も日々変化する。このため、信用性を電子証明書に記述する場合、状況が変化するたびに、電子証明書の再発行が必要となり、電子証明書の更新のための運用が煩雑となったり、失効した電子証明書を記載する証明書失効リストであるＣＲＬ（Certificate Revocation List）の容量が増加したりするなどの問題が生じる。

【0004】

これに対して特許文献１には、電子証明書の発行対象となる情報処理装置の属性情報を示す属性証明書を電子証明書とは別に発行することで、電子証明書の運用管理の効率化を図る技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００３－２３３５９４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、特許文献１に記載の技術では、信用性情報のような動的に変更される属性情報が更新されるたびに、属性証明書の再発行が必要となるため、属性情報を把握するための管理コストが高いという問題がある。

【0007】

本開示の目的は、属性情報が動的に変更される情報を含む場合であっても電子証明書の管理コストの増加を抑制することが可能な証明書状態確認装置及び証明書状態確認方法を提供することにある。

【課題を解決するための手段】

【0008】

本開示の一態様に従う証明書状態確認装置は、電子証明書の状態を確認する証明書状態確認装置であって、接続要求を受信した通信装置が前記接続要求の送信元から電子証明書を取得した場合、当該電子証明書に含まれる属性情報の状態を確認し、当該確認結果である状態確認結果を前記通信装置に通知する制御部を有する。

【発明の効果】

【0009】

本発明によれば、属性情報が動的に変更される情報を含む場合であっても電子証明書の管理コストの増加を抑制することが可能になる。

【図面の簡単な説明】

【0010】

【図1】本開示の一実施形態の通信システムを示す図である。

【図2】証明書発行処理の一例を示すシーケンス図である。

【図3】信確立処理の一例を説明するためのシーケンス図である。

【図4】信確立処理の一例を説明するためのシーケンス図である。

【図5】電子証明書の一例を示す図である。

【図6】失効確認要求の一例を示す図である。

【図7】失効確認結果の一例を示す図である。

【図8】業務サーバ画面の一例を示す図である。

【図9】通信システムを構成する各装置のハードウェア構成を示す図である。

【発明を実施するための形態】

【0011】

以下、本開示の実施形態について図面を参照して説明する。

【0012】

図１は、本開示の一実施形態の通信システムを示す図である。図１に示す通信システムは、認証局サーバ１１と、認証状態応答サーバ１２と、脆弱性対応状況管理サーバ１３と、業務サーバ１４と、クライアント機器１５とを有する。認証局サーバ１１、認証状態応答サーバ１２、脆弱性対応状況管理サーバ１３、業務サーバ１４及びクライアント機器１５は、通信ネットワーク１６を介して相互に通信可能に接続できる。

【0013】

認証局サーバ１１、認証状態応答サーバ１２及び脆弱性対応状況管理サーバ１３は、対象機器の信用性（トラスト）を保証するためのトラスト管理システムを構成する。対象機器は、本実施形態では、業務サーバ１４及びクライアント機器１５である。

【0014】

認証局サーバ１１は、電子証明書の発行及び失効を行う電子認証局である。認証局サーバ１１は、例えば、対象機器からの電子証明書の発行要求に応じて電子証明書を発行したり、失効した電子証明書を記載する証明書失効リストであるＣＲＬの生成及び管理をしたりする。

【0015】

認証状態応答サーバ１２は、対象機器からの要求に応じて認証局サーバ１１にて発行された電子証明書の状態を確認して応答する証明書状態確認装置である。

【0016】

脆弱性対応状況管理サーバ１３は、対象機器における脆弱性に対する対応状況である脆弱性対応状況を管理する管理装置である。脆弱性対応状況管理サーバ１３は、管理対象となる対象機器ごと（より具体的には、後述する申請者情報ごと）に、その対象機器の脆弱性に関する脆弱性管理情報を管理する。脆弱性管理情報は、対象機器の脆弱性を示す脆弱性情報ごとに、その脆弱性に対応しているか否かを示す。

【0017】

なお、認証局サーバ１１、認証状態応答サーバ１２及び脆弱性対応状況管理サーバ１３の少なくとも２つ以上が物理的に１つの装置で実現されてもよい。例えば、認証局サーバ１１及び認証状態応答サーバ１２が１つの装置で実現されてもよい。

【0018】

業務サーバ１４及びクライアント機器１５は、トラスト管理システム（１１～１３）を用いて相互に認証し合い、認証に成功した場合、相互に通信を確立する通信装置である。

【0019】

図２は、本実施形態の通信システムによる電子証明書の発行に係る証明書発行処理の一例を示すシーケンス図である。なお、業務サーバ１４及びクライアント機器１５は、証明書発行処理において互いに同一の処理を行うため、ここでは、対象機器と総称する。

【0020】

先ず、対象機器は、電子証明書の発行要求を作成して認証局サーバ１１に送信する（ステップＳ１００１）。発行要求は、対象機器を識別するための申請者情報を含む。

【0021】

認証局サーバ１１は、電子証明書の発行要求を受信する（ステップＳ１００２）。認証局サーバ１１は、発行要求の申請者情報に基づいて、発行要求の送信元である対象機器の本人確認を行う（ステップＳ１００３）。ここでは、本人確認に成功したとする。

【0022】

その場合、認証局サーバ１１は、発行要求の送信元である対象機器の脆弱性対応状況を管理しているか否かの確認を要求する管理確認要求を脆弱性対応状況管理サーバ１３に送信する（ステップＳ１００４）。管理確認要求は、申請者情報を含む。

【0023】

脆弱性対応状況管理サーバ１３は、管理確認要求を受信する（ステップＳ１００５）。脆弱性対応状況管理サーバ１３は、管理確認要求に含まれる申請者情報と脆弱性管理情報に含まれる申請者情報とを照合して、発行要求の送信元である対象機器の脆弱性対応状況を管理しているか否かの確認する管理確認処理を実行する（ステップＳ１００６）。

【0024】

脆弱性対応状況管理サーバ１３は、管理確認処理による確認結果である管理確認結果を認証局サーバ１１に送信する（ステップＳ１００７）。管理確認結果は、対象機器の脆弱性対応状況を管理している場合、その対象機器を識別する識別情報であるデバイスＩＤを含む。デバイスＩＤは、脆弱性対応状況管理サーバ１３にて管理される識別情報であり、申請者情報とは異なる。脆弱性対応状況管理サーバ１３は、例えば、デバイスＩＤを、脆弱性管理情報において申請者情報と予め対応付けていてもよいし、管理確認処理の後に生成してもよい。

【0025】

認証局サーバ１１は、管理確認結果を受信する（ステップＳ１００８）。認証局サーバ１１は、対象機器の電子証明書を発行する（ステップＳ１００９）。電子証明書は、予め規定された基本情報と、基本情報以外の拡張情報とを含む。本実施形態では、拡張情報は、対象機器の属性情報として、対象機器の信用性を示すトラスト情報を含む。トラスト情報には、状態（値）が決定されている静的な情報と、状態が変化する動的な情報とを含む。動的な情報は、対象機器の脆弱性対応状況を示す脆弱性対応情報を含む。本実施形態では、管理確認結果が管理確認処理の成功を示す場合（つまり、対象機器の脆弱性対応状況が管理されている場合）、認証局サーバ１１は、管理確認結果に含まれるデバイスＩＤを、電子証明書の拡張領域（拡張フィールド）に脆弱性対応情報として追加する。なお、管理確認結果が管理確認処理の失敗を示す場合、電子証明書が発行されなくてもよい。

【0026】

そして、認証局サーバ１１は、発行した電子証明書を対象機器に送信する（ステップＳ１０１０）。対象機器は、電子証明書を受信して格納し（ステップＳ１０１１）、処理を終了する。

【0027】

図３及び図４は、業務サーバ１４とクライアント機器１５とが通信を確立するための通信確立処理の一例を説明するためのシーケンス図である。ここでは、クライアント機器１５が業務サーバ１４に対して通信を確立する場合を例にとって説明するが、業務サーバ１４とクライアント機器１５とが相互に通信を確立する場合、業務サーバ１４に対しても同様な処理が行われる。

【0028】

なお、認証状態応答サーバ１２は、定期的に、ＣＲＬの取得要求を認証局サーバ１１に送信する（ステップＳ２００１）。認証局サーバ１１は、ＣＲＬの取得要求を受信すると（ステップＳ２００２）、その取得要求に従って、保持しているＣＲＬを認証状態応答サーバ１２に送信する（ステップＳ２００３）。認証状態応答サーバ１２は、ＣＲＬを受信して格納する（ステップＳ２００４）。

【0029】

また、クライアント機器１５は、業務サーバ１４との通信を確立する場合、接続要求を業務サーバ１４に送信する（ステップＳ２００５）。業務サーバ１４は、接続要求を受信すると（ステップＳ２００６）、電子証明書の送付要求をクライアント機器１５に送信する（ステップＳ２００７）。クライアント機器１５は、送付要求を受信すると（ステップＳ２００８）、図２のステップＳ１０１１にて格納した自身の電子証明書をクライアント証明書として業務サーバ１４に送信する（ステップＳ２００９）。業務サーバ１４は、クライアント証明書を受信すると（ステップＳ２０１０）、そのクライアント証明書の検証を行う（ステップＳ２０１１）。クライアント証明書の検証は、通常の電子証明書の検証と同様な処理のため、その詳細な説明は省略する。

【0030】

続いて、業務サーバ１４は、クライアント証明書が失効しているか否かを確認する失効確認要求と、クライアント証明書の送信元のクライアント機器１５の脆弱性対応状況を確認する状況確認要求とを認証状態応答サーバ１２に送信する（ステップＳ２０１２）。本実施形態では、業務サーバ１４は、失効確認要求の拡張領域（拡張フィールド）に状況確認要求を追加して送信する。また、状況確認要求は、クライアント証明書内のデバイスＩＤを含む。

【0031】

認証状態応答サーバ１２は、状況確認要求を含む失効確認要求受信すると（ステップＳ２０１３）、失効確認要求とステップＳ２００４で格納したＣＲＬとに基づいて、クライアント証明書が失効されているか否かを確認する失効状態確認処理を実行する（ステップＳ２０１４）。

【0032】

その後、認証状態応答サーバ１２は、クライアント証明書に含まれる属性情報の状態を確認する処理を実行する（ステップＳ２０１５～Ｓ２０１８）。

【0033】

ここでは、認証状態応答サーバ１２は、属性情報の状態として、動的な情報である脆弱性対応情報の状態を確認する。具体的には、認証状態応答サーバ１２は、先ず、失効確認要求に含まれる状況確認要求を脆弱性対応状況管理サーバ１３に送信する（ステップＳ２０１５）。脆弱性対応状況管理サーバ１３は、状況確認要求を受信すると（ステップＳ２０１６）、状況確認要求内のデバイスＩＤに対応する脆弱性管理情報を確認して、クライアント機器１５における脆弱性に対する対応状況を確認し、その確認結果を状況確認結果として認証状態応答サーバ１２に送信する（ステップＳ２０１７）。認証状態応答サーバ１２は、状況確認結果を受信することで、脆弱性対応情報の状態を確認する（ステップＳ２０１８）。

【0034】

そして、認証状態応答サーバ１２は、ステップＳ２０１８で受信した状況確認結果とステップＳ２０１４の失効状態確認処理による確認結果である失効確認結果とを、業務サーバ１４に送信する（ステップＳ２０１９）。本実施形態では、認証状態応答サーバ１２は、失効確認結果の拡張領域（拡張フィールド）に状況確認結果を追加して送信する。

【0035】

業務サーバ１４は、状況確認結果を含む失効確認結果を受信すると（ステップＳ２０２０）、その状況確認結果及び失効確認結果を確認して、クライアント機器１５との接続を許可するか否かを判断する接続可否判断処理を実行する（ステップＳ２０２１）。接続可否判断処理では、業務サーバ１４は、状況確認結果及び失効確認結果が予め定められた条件に合致するか否かを判断して、クライアント機器１５との接続を許可するか否かを自動的には判断してもよい。また、業務サーバ１４は、状況確認結果を表示して、クライアント機器１５との接続を許可するか否かを、業務サーバ１４を管理する管理者に問い合わせて入力させてもよい。

【0036】

そして、業務サーバ１４は、接続可否判断処理の処理結果である認証結果をクライアント機器１５に送信する（ステップＳ２０２２）。クライアント機器１５は、認証結果を受信して確認する（ステップＳ２０２３）。

【0037】

認証結果が接続可否判断処理の成功を示す場合、クライアント機器１５は業務サーバ１４との通信を確立して（ステップＳ２０２４）、処理を終了する。

【0038】

以上説明した証明書発行処理及び通信確立処理は、単なる一例であって、これに限定されるものではない。例えば、認証状態応答サーバ１２は、ＣＲＬを予め取得して格納するのではなく、失効確認要求を受信するたびに、その都度、認証局サーバ１１からＣＲＬを取得してもよい。

【0039】

図５は、本実施形態の電子証明書の一例を示す図である。図５に示す電子証明書５００は、基本フィールド５０１と、拡張フィールド５０２とを含む。

【0040】

基本フィールド５０１は、電子証明書として予め規定された基本情報を格納する基本領域である。基本情報は、例えば、電子証明書のバージョン、シリアル番号、署名アルゴリズム、証明書発行者名、有効期間、所有者名及び公開鍵などを含む。

【0041】

拡張フィールド５０２は、基本情報以外の拡張情報を格納する拡張領域である。拡張情報は、本実施形態では、対象機器の属性情報として、対象機器の信用性を示すトラスト情報を含む。トラスト情報は、対象機器を使用する使用者の権限を示す権限情報（privilege）、対象機器が物として正しさの程度を示す真正性（Authenticity）情報、脆弱性対応状況を含む信頼性（Reliability）情報、及び、対象機器が保護されている程度を示す保護性（Protectivity）情報を含む。

【0042】

上記の信頼性情報は、本実施形態では、脆弱性対応状況管理サーバ１３にて脆弱性対応状況が管理されている場合に、デバイスＩＤを含む。また、権限情報、真正性情報、保護性情報は、静的な情報であり、認証局サーバ１１にて対象機器ごとに管理されている。信頼性情報は、動的な情報であり、電子証明書５００には、脆弱性対応状況が管理されているか否かを示す情報として、デバイスＩＤが格納されている。権限情報は、例えば、管理者（root）又は一般ユーザ（user）を示し、真正性情報及び保護性情報は、１～４の数値などを示す。

【0043】

図６は、対象機器の脆弱性対応状況を確認する状況確認要求を含む失効確認要求の一例を示す図である。図６に示す失効確認要求６００は、基本フィールド６０１と、拡張フィールド６０２とを含む。

【0044】

基本フィールド６０１は、失効確認要求として予め規定された基本情報を格納する基本領域である。この基本情報は、例えば、検証対象の電子証明書の発行者名、検証対象の電子証明書の発行者の公開鍵及び検証対象の電子証明書のシリアル番号を含む。なお、発行者名及び公開鍵は所定のハッシュ関数で変換されている。

【0045】

拡張フィールド６０２は、基本情報以外の拡張情報を格納する拡張領域であり、本実施形態では、検証対象の電子証明書に対応する対象機器のデバイスＩＤを、その対象機器の脆弱性対応状況を確認する状況確認要求として含む。

【0046】

図７は、対象機器の脆弱性対応状況を確認した状況確認結果を含む失効確認結果の一例を示す図である。図７に示す失効確認情報７００は、基本フィールド７０１と、拡張フィールド７０２とを含む。

【0047】

基本フィールド７０１は、失効確認情報として予め規定された基本情報を格納する基本領域である。この基本情報は、例えば、検証対象の電子証明書の発行者名、検証対象の電子証明書の発行者の公開鍵、検証対象の電子証明書のシリアル番号、及び、検証対象の電子証明書が失効しているか否かを示す失効状態情報を含む。なお、発行者名及び公開鍵は所定のハッシュ関数で変換されている。

【0048】

拡張フィールド７０２は、基本情報以外の拡張情報を格納する拡張領域であり、本実施形態では、クライアント機器１５の脆弱性対応状況を確認結果である拡張確認結果を格納する。拡張確認結果は、例えば、未対応の脆弱性情報を示す。未対応の脆弱性情報が存在しない場合、拡張確認結果は、所定値（例えば、０）を示す。

【0049】

図８は、図３のステップＳ２０２１において、状況確認結果を表示する業務サーバ画面の一例を示す図である。図７に示す業務サーバ画面８００は、クライアント機器１５との接続を許可するか否かを問い合わせる問い合わせ文８０１と、クライアント機器１５のデバイスＩＤ８０２と、クライアント機器１５との接続を許可するか否かをユーザが判断するためのトラスト情報８０３と、クライアント機器１５との接続を許可するか否かを入力する入力欄８０４とを含む。トラスト情報８０３は、権限者情報８１１、真正性情報８１２、信頼性情報８１３及び保護性情報８１４を含む。

【0050】

図９は、通信システムを構成する各装置（１１～１５）のハードウェア構成を示す図である。

【0051】

図８に示すように各装置は、プロセッサ２１、メインメモリ２２、記録装置２３、入力装置２４、表示装置２５及び通信装置２６を有し、それらがバス２７を介して接続されるコンピュータシステムにて実現される。

【0052】

記録装置２３は、書き込み及び読み出しが可能にデータを記録する装置であり、プロセッサ２１の動作を規定するプログラム、及び、そのプログラムにより生成及び使用される種々の情報を記録する。例えば、認証局サーバ１１及び認証状態応答サーバ１２の記録装置２３は、ＣＲＬを格納し、脆弱性対応状況管理サーバ１３の記録装置２３は、脆弱性管理情報を格納する。

【0053】

プロセッサ２１は、例えば、ＣＰＵ（Central Processing Unit）であり、記録装置２３に記録されたプログラムをメインメモリ２２に読み出し、メインメモリ２２を利用してプログラムに応じた処理を実行する制御部である。プロセッサ２１によって、図２～図４で説明した種々の処理のうち認証状態応答サーバ１２の処理が実現される。入力装置２４は、認証状態応答サーバ１２のオペレータから種々の情報が入力される装置であり、その情報はプロセッサ２１の処理に利用される。表示装置２５は、種々の情報を表示する装置である。通信装置２６は、他の装置（脆弱性対応状況管理サーバ１３、認証局サーバ１１、業務サーバ１４及びクライアント機器１５など）と通信を行い、種々の情報の送受信を行う。

【0054】

なお、プロセッサ２１による処理の少なくとも一部は、ハードウェア回路（例えばＡＳＩＣ（Application Specific Integrated Circuit）又はＦＰＧＡ（Field-Programmable Gate Array）など）によって実現されてもよい。

【0055】

以上説明したように本実施形態によれば、認証状態応答サーバ１２のプロセッサ２１は、接続要求を受信した業務サーバ１４が接続要求の送信元であるクライアント機器１５から電子証明書を取得した場合、その電子証明書に含まれる属性情報の状態を確認し、その確認結果である状態確認結果を業務サーバ１４に通知する。このため、接続時に属性情報の状態が確認されるため、属性情報が更新されるたびに電子証明書又は属性証明書を発行する必要がなくなるため、属性情報が動的に変更される情報を含む場合であっても電子証明書の管理コストの増加を抑制することが可能になる。

【0056】

また、本実施形態では、動的な属性情報は、接続要求の送信元であるクライアント機器１５の脆弱性に対する対応状況示す脆弱性対応情報である。この場合、脆弱性対応情報を電子証明書に記載する場合でも、管理コストの増加を抑制することが可能となる。

【0057】

また、本実施形態では、脆弱性対応情報の確認結果である状態確認結果は、未対応の脆弱性情報を示す。この場合、対象機器の脆弱性を正確に把握することが可能となる。

【0058】

また、本実施形態では、認証状態応答サーバ１２のプロセッサ２１は、電子証明書が失効されているか否かさらに確認し、その確認結果である失効確認結果を状態確認結果と共に通知する。この場合、電子証明書が失効されているか否かの確認時に動的な属性情報の状態を確認することが可能となるため、管理コストの増加を抑制することが可能となる。

【0059】

また、本実施形態では、認証状態応答サーバ１２のプロセッサ２１は、属性情報の状態を管理する脆弱性対応状況管理サーバ１３に問い合わせることで、属性情報の状態を確認する。このため、電子証明書の失効確認を行う認証状態応答サーバ１２に属性情報の状態を管理するための情報を持たせる必要がない。

【0060】

上述した本開示の実施形態は、本開示の説明のための例示であり、本開示の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本開示の範囲を逸脱することなしに、他の様々な態様で本開示を実施することができる。

【符号の説明】

【0061】

１１：認証局サーバ １２：認証状態応答サーバ １３：脆弱性対応状況管理サーバ １４：業務サーバ １５：クライアント機器 １６：通信ネットワーク ２１：プロセッサ ２２：メインメモリ ２３：記録装置 ２４：入力装置 ２５：表示装置 ２６：通信装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】