JP2017175226A - 公開鍵証明書を発行するためのプログラム、方法およびシステム - Google Patents

Abstract

【課題】デバイスに対して安全かつ自動的に公開鍵証明書を発行するシステムを提供する。【解決手段】アプリケーション発行サービスシステム３０は、公開鍵証明書を発行する認証局サービスシステム２０によって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラム５０を、クライアントデバイス１０−ｎに配布する。認証局サービスシステム２０は、クライアントデバイス１０−ｎから、公開鍵証明書申請プログラム５０−ｎを用いて行われた公開鍵証明書の申請を、受信する。認証局サービスシステム２０は、該申請が自身によって定められた申請手続きに従って行われたものであることを確認した後に、申請された公開鍵証明書を、クライアントデバイス１０−ｎに対して発行する。【選択図】図２

Description

本発明は、デバイスに対する公開鍵証明書の発行を自動化することを可能にするプログラム、方法およびシステムに関する。

現在、デバイスに対する公開鍵証明書の発行を自動化する方法として、ＳＣＥＰ（Simple Certificate Enrollment Protocol）（例えば、非特許文献１を参照）が広く利用されている。ＳＣＥＰでは、公開鍵証明書の発行を自動化するためにデバイスと認証局との間で秘密のチャレンジパスワードを事前に共有しておき、デバイスから識別情報と一緒に提出されたチャレンジパスワードが正しいことを認証局側で確認できれば、デバイスに対して公開鍵証明書を自動で発行する。ＳＣＥＰを用いる場合、例えば、デバイスが、ＭＤＭアプリケーション（Mobile Device Management Application）へＭＤＭ構成情報（MDM CONFIG）を要求して、ＭＤＭ構成情報と共にチャレンジパスワードを受け取る。そして、デバイスは、認証局への仲介役として配置されたＳＣＥＰサービス（SCEP Service）へ、公開鍵証明書の申請と共にチャレンジパスワードを送り、チャレンジパスワードについての認証を受ける。ＳＣＥＰサービスは、デバイスからのチャレンジパスワードが正しいことを確認できれば、デバイスの代理として認証局に公開鍵証明書の申請を行い、認証局は、ＳＣＥＰサービスを通じてデバイスに公開鍵証明書を自動で発行する。

しかし、このＳＣＥＰによる方法では、デバイスの認証に問題があり、例えば、悪意を持ったデバイス利用者が正しいチャレンジパスワードと一緒に詐称した識別情報を提出することで、認証局が騙されて不正な公開鍵証明書を発行してしまう権限昇格攻撃に関する脆弱性が指摘されている。そのため、ＳＣＥＰ確認サービス（SCEP Validation Service）を追加することによって権限昇格攻撃を防ぐ方法が提案されている（例えば、特許文献１を参照）。この方法によれば、例えば、ＳＣＥＰ確認サービスに、信頼できる情報源からのデバイス情報などをチャレンジパスワードに紐付けて登録しておき（例えば、ＳＣＥＰ確認サービスが、ＭＤＭアプリケーションからチャレンジパスワードおよびこれに紐付くデバイス情報などを受け取って登録しておき）、認証局は、ＳＣＥＰサービスでのチャレンジパスワードの確認を行うことに加えて、ＳＣＥＰ確認サービスに問い合わせることによりデバイスから提出された識別情報が詐称されていないことの確認も行うことができる。但し、このような方法では、認証局による識別情報の審査自体は自動化できるものの、その前提として、組織の正式なディレクトリサービスなどの信頼できる情報源に正しいデバイス情報を予め登録しておく必要があるため、公開鍵証明書の発行を本質的には自動化できていない。

アップル社が提供するｉＯＳでは、デバイスに対するＯＴＡ（Over-The-Air、無線接続）による構成プロファイルの配布が実現されており、構成プロファイルを安全に配布するための暗号化に使用するために、前述のＳＣＥＰを利用してデバイスの公開鍵証明書を発行している（例えば、非特許文献２を参照）。デバイスの識別情報については、構成プロファイルを配布するプロファイルサービスによって必要な識別情報の項目名を指定してデバイスに要求することができ、例えば「ｉＯＳのバージョン番号」、「デバイスのシリアル番号」、「ＩＭＥＩ（International Mobile Equipment Identity）」などの識別情報をデバイスから取得することができる。この仕組みで取得された識別情報を認証局が信頼できるのであれば、公開鍵証明書の発行を自動化することができるため、大量のデバイスに対しても低コストで公開鍵証明書を発行することができる。しかし実際には、デバイスがマルウェアに汚染されて管理者権限が奪取されていたり、悪意を持ったデバイス利用者によって意図的な不正が行われたりする可能性が想定されるため、認証局にとって信頼できる識別情報が取得されることを保証できないと考えられる。また、ディレクトリサービスなどと連携して識別情報の検証を行う場合は、やはり予め正しいデバイス情報を登録しておく必要があるため、公開鍵証明書の発行を本質的には自動化できない。

なお、公開鍵証明書の発行、更新、失効といった管理に関するプロトコルであるＣＭＰ（Certificate Management Protocol）（例えば、非特許文献３を参照）では、公開鍵証明書の発行方式として、これまでに説明したようなクライアントで鍵ペアを生成して公開鍵証明書の申請を開始する基本認証方式（Basic Authenticated Scheme）の他に、認証局でクライアントの鍵ペアを生成して公開鍵証明書と一緒にクライアントに配布する一括生成配布方式（Centralized Scheme）が規定されている。一括生成配布方式では、認証局が公開鍵証明書に記載するための識別情報を組織の正式なディレクトリサービスなどの信頼できる情報源から取得できる場合は、認証局においてデバイスの識別情報についての審査を行う必要はない。しかし、そうしたディレクトリサービスなどに正しいデバイス情報を予め登録しておく必要があることには変わりなく、公開鍵証明書の発行を本質的には自動化できない。また、デバイスに対して鍵ペアを配布する必要があるため、私有鍵が漏洩する可能性が高まる懸念もある。更に、認証局などで一括して生成される電子署名用途の鍵ペアは、個々のデバイスの否認防止には利用できないという問題もある。

米国特許第８７４５３７８号明細書

P. Gutmann著「Simple Certificate Enrolment Protocol」 Internet-Draft, IETF（2015）［https://tools.ietf.org/html/draft-gutmann-scep-01］ 「無線経由のプロファイルの配布と構成」Apple Inc.（2014）［https://developer.apple.com/jp/documentation/iPhoneOTAConfiguration.pdf］ 「Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)」RFC 6712, IETF（2012）［https://tools.ietf.org/html/rfc6712］

従来技術において安全に公開鍵証明書を発行するためには、認証局がデバイスから提出された識別情報についての審査を行う必要があるため、公開鍵証明書の発行に関する安全性と自動化の両立が困難である。

デバイスから提出された識別情報が詐称されていないことを検証するには、組織の正式なディレクトリサービスなどの信頼できる情報源から取得される正しいデバイス情報が必要となり、審査のために予め正しいデバイス情報を登録しておかなければならないから、公開鍵証明書の発行に関する一連の処理を自動化できず、発行を自動化することが本質的に困難である。通常、このようなデバイス情報は、公開鍵証明書の発行対象となる全てのデバイスを管理するデバイス管理者によって登録されるものであり、特に、ＩｏＴ（Internet of Things）などのように大量のデバイスが扱われる状況においては、デバイス管理者の負荷増大が問題となる。

特定組織のプライベート認証局ではなく、広く開放されたパブリック認証局から公開鍵証明書の発行を受ける場合には、公開鍵証明書の発行を自動化することが更に困難になると考えられる。なぜならば、パブリック認証局が公開鍵証明書の発行対象となる全てのデバイスについて、識別情報の審査に必要な信頼できる正しい情報を取得しておくことが難しいためである。そのため、デバイス利用者が認証局の公開鍵証明書申請窓口に物理的にデバイスを持ち込み、認証局の審査担当者による実機を使った審査が行われることも考えられる。しかしながら、このような方法では、大量のデバイスを扱うことが現実的に難しい。

デバイスからネットワーク経由で識別情報を取得できる仕組みの場合は、取得された識別情報を認証局が信頼できるのであれば公開鍵証明書の発行を自動化することができるため、大量のデバイスを扱う場合でも審査担当者もしくはデバイス管理者の負荷を最小限に抑えることができる。しかし、現実には、デバイスがマルウェアに汚染されて管理者権限が奪取されていたり、悪意を持ったデバイス利用者によって意図的な不正が行われたりする可能性が想定されるため、認証局にとって信頼できる識別情報が取得されることを保証できないことが問題となる。

また、クライアントで鍵ペアを生成して公開鍵証明書の申請を開始する基本認証方式では、デバイスが生成した鍵ペアや証明書署名要求の生成手続きが正しいかどうか（認証局にとって信頼できる手続きかどうか）について、公開鍵証明書を発行する責任者である認証局による確認が難しいことが問題となる。具体的には、鍵ペアや証明書署名要求の生成のために脆弱性が修正されていないバージョンのソフトウェアやライブラリを使用していないかどうか、鍵ペアの使い回しをしていないかどうかなどを正確に把握することが困難である。

一方で、認証局でクライアントの鍵ペアを生成して公開鍵証明書と一緒にクライアントに配布する一括生成配布方式では、認証局にとって信頼できる手続きによって公開鍵証明書を発行することができる。しかし、生成した鍵ペアをデバイスに配布する必要があるために私有鍵が漏洩する可能性が増加することは問題であり、また電子署名用途の鍵ペアを個々のデバイスの否認防止に利用できないことも問題となる。

本発明は、公開鍵証明書を発行する認証局が、特定組織のプライベート認証局である場合も、広く開放されたパブリック認証局である場合も、クライアントとなるデバイスに関する識別情報の審査を不要にできるような新しい仕組みを構築して、デバイスに対する安全かつ自動的な公開鍵証明書の発行を可能にすることを目的とする。

本発明の原理に従う一例に係る公開鍵証明書申請プログラムは、公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む。

そして、本発明の原理に従う一例に係る公開鍵証明書発行方法は、上記公開鍵証明書申請プログラムを、デバイスに配布し、該デバイスから、該公開鍵証明書申請プログラムを用いて行われた公開鍵証明書の申請を、認証局サービスが受信し、該認証局サービスは、該申請が自身によって定められた申請手続きに従って行われたものであることを確認した後に、申請された公開鍵証明書を、デバイスに対して発行する。

上記公開鍵証明書申請プログラムは、デバイスに何らかの形で配布でき、デバイスが実行可能なプログラムであればよく、アプリケーションでも、ファームウェアなどでも構わない。このプログラムは、認証局サービスにとって信頼できる公開鍵証明書の申請手続きを含むため、当該プログラムを用いることにより、デバイスに対する安全かつ自動的な公開鍵証明書の発行が可能になる。

上記公開鍵証明書申請プログラムにおいて、前記申請手続きが、公開鍵および該公開鍵の対となる私有鍵を生成する処理と、申請元の識別情報を取得する処理と、前記公開鍵および前記識別情報についての公開鍵証明書を申請する（例えば、証明書署名要求を生成して送信する）処理とを含むようにしてもよい。

この公開鍵証明書申請プログラムを用いてデバイスが申請を行うのであるから、識別情報を取得する処理として、必ず、認証局サービスによって定められた処理が行われることになり、認証局サービスでは、受信した申請が当該プログラムを用いて行われたものであることを確認することで、申請に含まれる識別情報自体についての審査を不要にすることが可能になる。

ここで、識別情報により特定される申請元は、デバイスであってもよいし、ユーザであってもよいし、両者の組合せであってもよい。例えば、上記申請元の識別情報を、デバイスのハードウェアから取得される情報としてもよいし、ユーザからの入力に基づいて取得される情報としてもよいし、両者の組合せとしてもよい。

上記デバイスのハードウェアから取得される情報は、製造番号や固定アドレス等のデバイスに固有の情報としてもよい。あるいは、ＧＮＳＳ受信機から取得される位置情報等、デバイスのソフトウェアによっては操作されない情報としてもよい。

上記公開鍵証明書申請プログラムが、公開鍵証明書の申請が前記申請手続きに従って行われたものであることを、前記認証局サービスが確認するために用いられる、正規手続き認証鍵をさらに含み、前記申請手続きが、前記公開鍵証明書の申請に前記正規手続き認証鍵による電子署名を付与する処理を含むようにしてもよい。

上記正規手続き認証鍵は、共通鍵暗号方式の秘密鍵であってもよいし、公開鍵暗号方式の私有鍵であってもよい。認証局サービスでは、デバイスからの申請に、この正規手続き認証鍵による電子署名が正しく付与されていることをもって、当該申請が、正規の公開鍵証明書申請プログラムを用いて（すなわち、認証局にとって信頼できる申請手続きで）行われたものであることを確認することが可能になる。

共通鍵暗号方式の場合、デバイスは、例えば、公開鍵証明書の申請を正規手続き認証秘密鍵で暗号化して電子署名を作成し、公開鍵証明書の申請とともに、認証局サービスへ送信する。認証局サービスでは、受信した電子署名を、自身が保管している正規手続き認証秘密鍵で復号化して、受信した公開鍵証明書の申請と比較し、一致すれば、受信した公開鍵証明書の申請が正規の公開鍵証明書申請プログラムを用いて行われたものであると判断することができる。

公開鍵暗号方式の場合、デバイスは、例えば、公開鍵証明書の申請を正規手続き認証私有鍵で暗号化して電子署名を作成し、公開鍵証明書の申請とともに、認証局サービスへ送信する。認証局サービスでは、受信した電子署名を、自身が保管している正規手続き認証公開鍵で復号化して、受信した公開鍵証明書の申請と比較し、一致すれば、受信した公開鍵証明書の申請が、正規の公開鍵証明書申請プログラムを用いて行われたものであると判断することができる。

公開鍵暗号方式の場合は、さらに、上記公開鍵証明書申請プログラムが、前記正規手続き認証私有鍵の対となる第二の公開鍵および該第二の公開鍵に前記認証局サービスが付与した第二の電子署名を含み、前記申請手続きが、前記公開鍵証明書の申請に前記第二の公開鍵および前記第二の電子署名を含ませる処理を含むようにしてもよい。

これにより、認証局サービスは、受信した電子署名の検証を、受信した第二の電子署名が自身の電子署名であることの確認および受信した第二の公開鍵（正規手続き認証公開鍵）での復号化によって行うことができるため、認証局サービスが共通鍵暗号方式における正規手続き認証秘密鍵もしくは公開鍵暗号方式における正規手続き認証公開鍵を保管する負荷を、低減することが可能になる。

上記公開鍵証明書申請プログラムにおいては、前記正規手続き認証鍵が秘匿化（例えば、暗号化もしくは難読化）されていることが好ましい。これにより、正規手続き認証鍵を用いることができるのは、公開鍵証明書申請プログラムが配布されたデバイスが当該プログラムを実行する場合に限られ、当該正規手続き認証鍵による電子署名が正しく付与されていることをもって、認証局にとって信頼できる申請手続きで公開鍵証明書の申請が行われたものと判断することが可能になる。

上記公開鍵証明書申請プログラムにおいては、前記申請手続きを実行するためのプログラムコードの少なくとも一部が秘匿化されていることが好ましい。また、前記申請手続きが、前記プログラムコードが改竄されていないことを確認する処理を含むことが好ましい。これにより、認証局にとって信頼できる申請手続きで公開鍵証明書の申請が行われたものと判断することが可能になる。

さらに安全性を高めるために、上記公開鍵証明書申請プログラムが、セキュアな環境でなければ実行されないように、該環境に固有の鍵で暗号化されていてもよい。

もしくは、上記公開鍵証明書申請プログラムが、非セキュアな環境で実行されるものとして、難読化されていてもよい。

上記公開鍵証明書申請プログラムの機能を拡張して、前記申請手続きによる申請に基づいて前記認証局サービスにより発行される公開鍵証明書および前記申請手続きにより生成される該公開鍵の対となる私有鍵を管理するためのプログラムコードをさらに含むようにしてもよい。

上記公開鍵証明書申請プログラムにおいて、前記申請手続きを実行するプログラムコードが複数あり、前記複数のプログラムコードのうち、要求される公開鍵証明書の種類に応じたプログラムコードを選択して、該プログラムコードによる申請手続きを実行するためのプログラムコードを含むようにしてもよい。

上記公開鍵証明書申請プログラムが、前記認証局サービスの公開鍵証明書をさらに含み、前記申請手続きが、前記認証局サービスの公開鍵証明書を用いて、前記公開鍵証明書申請プログラムの管理者もしくは発行者の確認、前記申請手続きにより提出される申請の暗号化による秘匿、前記申請の後に受領される公開鍵証明書が前記認証局サービスにより発行されたことの確認のうち、少なくとも一つを行うようにしてもよい。

本発明の原理に従う一例に係るデバイスは、公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムを記憶するための手段と、前記公開鍵証明書申請プログラムを用いて前記申請手続きを実行するための手段と、前記申請手続きによる申請に基づいて前記認証局サービスにより発行される公開鍵証明書および前記申請手続きにより生成される該公開鍵の対となる私有鍵を管理するための手段とを備える。

上記デバイスが、セキュアな実行環境を備え、少なくとも前記公開鍵証明書申請プログラムを用いて前記申請手続きを実行するための手段が、該セキュアな実行環境を利用するようにしてもよい。さらに、前記公開鍵証明書および／または前記私有鍵の管理を、該セキュアな実行環境を利用して行うようにしてもよい。

上記デバイスにおける公開鍵証明書申請プログラムは、デバイスの出荷時にプリインストールされていてもよい（第一の例）し、デバイスの出荷後に該デバイスを管理するサービスによって強制的にインストールされてもよい（第二の例）し、デバイスで公開鍵証明書が必要となった際に該デバイスが申請プログラムを発行するサービスから取得してインストールしてもよい（第三の例）。

第二の例では、複数のデバイスを管理するサービスに前記デバイスの情報が登録されていない場合に、該情報を取得する処理を前記申請手続きに含む前記公開鍵証明書申請プログラムを受信する手段を、デバイスがさらに備えてもよい。

第三の例では、要求される種類の公開鍵証明書が前記管理の対象として存在しない場合に、該種類に対応する前記公開鍵証明書申請プログラムを外部から取得する手段を、デバイスがさらに備えてもよい。

本発明の原理に従う一例に係る認証局サービスシステムは、公開鍵証明書の申請をデバイスから受信する手段と、前記申請が前記認証局サービスシステムによって定められた申請手続きに従って行われたものであることを確認する手段と、前記確認の後に前記公開鍵証明書を発行する手段と、前記デバイスにおいて前記申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムが用いられることにより前記申請が行われるようにする手段とを備える。

上記認証局サービスシステムが、前記申請に含まれる前記デバイスに関する情報を、複数のデバイスを管理するサービスへ通知する手段をさらに備えてもよい。これにより、デバイス管理サービスにおける管理対象のデバイスの情報の収集を自動化することも可能になる。

本発明の原理に従う一例に係るプログラム発行サービスシステムは、公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムを記憶する手段と、前記公開鍵証明書申請プログラムの少なくとも一部を秘匿化する手段と、前記公開鍵証明書の申請を要するデバイスに対し、前記秘匿化を行った前記公開鍵証明書申請プログラムを、該デバイスに適合した構成で発行する手段とを備える。

以上では、公開鍵証明書申請プログラムの発明、デバイスの発明、認証局サービスシステムの発明、プログラム発行サービスシステムの発明、公開鍵証明書発行方法の発明のいずれかに関連させて、発明の各要素を説明したが、ある発明に関連させて説明した要素を別の発明に適用することも可能である。また、認証局サービスシステムの発明およびプログラム発行サービスシステムの発明は、汎用のサーバにインストールされてそれぞれのシステムを実現するためのプログラム（又はそのプログラムを記録した記録媒体）の発明としても成立するものである。

以上のとおり、本発明によれば、デバイスに対して安全かつ自動的に公開鍵証明書を発行することが可能になる。これにより、例えば、多種多様かつ大量のデバイスがインターネットに接続されるＩｏＴにおいて、ネットワークに接続される様々なデバイスの認証やデータの保護を低コストで実現することが可能になる。

本実施形態の一例に係る公開鍵証明書発行システムの全体構成を示す図。 図１の例におけるデータの流れを示す図。 図１の例における処理手順を示すシーケンス図。 公開鍵証明書申請アプリケーションの構成（一部を公開する場合）の一例を示す図。 公開鍵証明書申請アプリケーションの構成（全て非公開とする場合）の一例を示す図。 公開鍵証明書の申請プログラムの処理内容の一例を示すフロー図。 鍵ペア生成サブプログラムの処理内容の一例を示すフロー図。 証明書署名要求生成サブプログラムの処理内容の一例を示すフロー図。 デバイス識別情報取得サブプログラムの一例を示す図。 図９の例による汚染部分の回避について説明する図。 クライアントデバイスおよびデバイス利用者の信頼できる識別情報の取得と紐付け処理の一例を示すシーケンス図。 実行元の入力値によって公開鍵証明書の申請プログラムを切り替える構成の一例を示す図。 クライアントデバイスにおいて公開鍵証明書申請アプリケーションを保護する構成の一例を示す図。 登録局サーバの公開鍵証明書申請アプリケーション管理データベースの一例を示す図。 登録局サーバの正規手続き認証鍵管理データベースの一例を示す図。 正規手続き認証秘密鍵の発行と電子署名の検証との関係の一例を示す図。 アプリケーション発行サーバのアプリケーション構成・発行方法管理データベースの一例を示す図。 パブリック認証局による公開鍵証明書申請アプリケーションの配布の一例を示す図。 プライベート認証局による公開鍵証明書申請アプリケーションの配布の一例を示す図。 プライベート認証局による公開鍵証明書申請アプリケーションの強制配布の一例を示す図。 パブリック認証局による企業内デバイスへの公開鍵証明書申請アプリケーションの配布の一例を示す図。 パブリック認証局による企業内デバイスへの公開鍵証明書申請アプリケーションの強制配布の一例を示す図。 デバイスベンダによる公開鍵証明書申請アプリケーションの強制配布の一例を示す図。 デバイスベンダによる公開鍵証明書申請アプリケーションの出荷時配布の一例を示す図。 公開鍵証明書申請アプリケーションの要求時配布の一例（専用ライブラリの利用）を示す図。 公開鍵証明書申請アプリケーションの要求時配布の別の例（申請プログラムの取得）を示す図。 公開鍵暗号方式による正規手続き認証鍵の発行と電子署名の検証との関係の一例を示す図。 公開鍵証明書申請アプリケーションにより公開鍵証明書および鍵ペアの管理を行う構成の一例を示す図。 公開鍵証明書申請アプリケーションの機能を拡張した構成の一例を示す図。 ＴＰＭと連携して公開鍵証明書の発行を行う構成の一例を示す図。 本実施形態によるデバイス情報の登録方法について説明する図。 医療データの安全な共有への応用の一例を示す図。 オンラインバンキングのトランザクション保護への応用の一例を示す図。 本実施形態が用いられる証明書認証について説明する図。

以下、本発明の実施の形態に係る公開鍵証明書発行システムについて、例示のために、図面を用いて説明する。

［１］本実施形態の概要
多種多様かつ大量のデバイスがインターネットに接続されるＩｏＴにおいては、デバイスが扱うデータやデバイス自体のセキュリティ対策は重要な課題である。こうした課題の解決には、暗号理論に基づく公開鍵基盤ＰＫＩ（Public Key Infrastructure）によって発行される公開鍵証明書の活用が有効であると考えられる。しかしながら、大量のデバイスが扱われるＩｏＴでは、公開鍵基盤の運用負荷増大が大きな問題となる。

公開鍵証明書は、公開鍵暗号で利用される鍵ペア（公開鍵と私有鍵）における公開鍵と、その公開鍵の主体を特定する識別情報とを紐付けるものである。認証局（登録局を含む）がクライアントに対して公開鍵証明書を発行するには、クライアントから提出された識別情報が詐称されておらず、その識別情報がクライアントを間違いなく特定するものであることを審査し、クライアントの属性を保証しなければならない。どのような方法で識別情報の審査を行うかについては、認証局や発行する公開鍵証明書の保証レベルによって異なり、認証局運用規程ＣＰＳ（Certificate Practice Statements）や認証局の証明書ポリシーＣＰ（Certificate Policy）によって示される（例えば、小松文子「改訂ＰＫＩハンドブック」171-192，株式会社ソフト・リサーチ・センター（2004/11/25）を参照）。

また、ＩｏＴに関するセキュリティ対策の強化が叫ばれる昨今では、ＴＥＥ（Trusted Execution Environment）（例えば、ＴＥＥの標準化団体であるGlobalPlatformの「TEE System Architecture Version 1.0」（2011/12) を参照）や、ＳＥ（Secure Element）（例えば、株式会社ブリリアントサービス「NFC Hacks−プロが教えるテクニック＆ツール」18-20，株式会社オライリー・ジャパン（2013/11/29）を参照）などのハードウェアレベルで実行環境の分離を実現するセキュリティ技術が注目されている。これらは、ネットワークを通じた不正アクセスやマルウェアによる汚染などからデバイスを保護し、アプリケーションを安全に実行できる信頼されたセキュア実行環境を提供する。これらデバイスのセキュア実行環境をクラウドと安全に接続し、様々なサービスに活用していくためには、セキュア実行環境に対して公開鍵証明書を発行することができれば都合がよい。

セキュア実行環境とは、特定の目的のために構成されたデバイス内に、複数の実行環境が備えられ、各実行環境におけるアプリケーションを実行するためのメモリ空間やデータストアなどの領域が、論理的または物理的もしくは両方を組み合わせた手段で、明確に分離されており、ある実行環境が、他の実行環境もしくはデバイス外部からのセキュリティ侵害を防ぐ仕組みを備えている場合の、当該実行環境のことをいう。セキュア実行環境の実現方法は達成するセキュリティレベルに応じて複数存在する。例えば、仮想化（Virtualization）や、上述したＴＥＥ、ＳＥなどの技術によって、セキュア実行環境を実現することができる。

本実施形態における安全かつ自動的な公開鍵証明書の発行方式は、デバイスの非セキュア実行環境だけではなく、これらのセキュア実行環境に対しても適用することができる。また、セキュア実行環境については、その実現方法に関係なく適用することができる。

なお、本実施形態において使用する電子署名は、電子データに署名できるものであればよく、署名の方式は問わない。例えば、共通鍵暗号方式の秘密鍵を用いて署名する方法（メッセージ認証符号など）も、公開鍵暗号方式の私有鍵を用いて署名する方法（デジタル署名など）も、使用可能である。

［２］システム構成
本実施形態においては、認証局（認証局サービスシステム）からデバイス（クライアントデバイス）に対する公開鍵証明書の発行が、自動化される。本実施形態の一例に係るシステムは、図１に示すように、クライアントデバイス１０−ｎで実行され認証局サービスシステム２０に対して公開鍵証明書の申請を行うための「公開鍵証明書申請アプリケーション」５０−ｎを含み、公開鍵証明書申請アプリケーション５０の管理および公開鍵証明書の発行を行うための「認証局サービスシステム」２０と、公開鍵証明書申請アプリケーションをクライアントデバイスに対して安全に配布するための「アプリケーション発行サービスシステム」３０によって構成される。「クライアントデバイス」１０−ｎは、これらのシステムと、ネットワーク４０を介して接続され、認証局サービスシステム２０から公開鍵証明書の発行を受ける。

公開鍵証明書申請アプリケーション５０および５０−ｎには、認証局サービスシステム２０にとって信頼できる公開鍵証明書の申請手続きが含まれる。図２の破線矢印で示すように、公開鍵証明書申請アプリケーション５０は、アプリケーション発行サービスシステム３０によって非改竄性および秘匿性を確保した形式に変換され、クライアントデバイス１０−ｎに対して、公開鍵証明書申請アプリケーション５０−ｎとして、安全に配布される。図２の点線矢印で示すように、クライアントデバイス１０−ｎは、配布された公開鍵証明書申請アプリケーション５０−ｎを実行することで、認証局サービスシステム２０にとって信頼できる手続きで公開鍵証明書の申請に関する一連の処理を実施する。

従来技術では、認証局サーバが公開鍵証明書を発行するにあたり、クライアントデバイスから提出される識別情報の正しさを審査する必要があるため、公開鍵証明書の発行を自動化することが本質的に困難であった。これに対し、本実施形態においては、公開鍵証明書申請アプリケーション５０を利用することで、認証局サービスシステム２０にとって信頼される手続きにより取得された識別情報がクライアントデバイス１０から提出されることになるため、認証局サービスシステム２０による識別情報の審査は不要となり、公開鍵証明書の発行を自動化することが可能となる。認証局サービスシステム２０にとって信頼される手続きで処理されたことを証明するため、クライアントデバイス１０から認証局サービスシステム２０への公開鍵証明書の申請時には、公開鍵証明書申請アプリケーション５０に含まれる正規手続き認証秘密鍵５３０によって付与された電子署名も併せて提出される。

公開鍵証明書の発行を受けるクライアントデバイス１０−ｎとしては、多種多様かつ大量の機器・設備があり得る。これらクライアントデバイスは、無線か有線かを問わず、企業内ネットワークやインターネット、３Ｇ／ＬＴＥネットワークなど、様々なネットワーク４０に接続されうる。一般に、クライアントデバイス１０には、ネットワーク４０を通じた不正アクセスやマルウェアによる汚染などの懸念があり、アプリケーションを実行する環境として安全であることを必ずしも保証できない（図１のクライアントデバイスＢの「非セキュア実行環境」）。その一方で、一部のクライアントデバイスに関しては、上述したＴＥＥやＳＥなどのハードウェアレベルで実行環境の分離を実現するセキュリティ技術によって、不正アクセスやマルウェアによる汚染などを防ぎ、アプリケーションを安全に実行できる環境が内部に確保されている（図１のクライアントデバイスＡの「セキュア実行環境」）。クライアントデバイス１０−ｎは、このような非セキュア実行環境１６０−２もしくはセキュア実行環境１７０−１で公開鍵証明書申請アプリケーション５０−ｎを動作させることにより、認証局サービスシステム２０から公開鍵証明書の発行を受ける（図２の点線矢印）。

認証局サービスシステム２０は、公開鍵証明書の実際の発行を行う認証局サーバ２１０と、クライアントデバイス１０の属性を保証する登録局サーバ２２０から構成される。認証局サーバ２１０が登録局サーバ２２０を兼ねる場合もある。従来技術では、クライアントデバイスの属性を保証するためには、クライアントデバイスから提出される識別情報の正しさを何らかの方法によって審査しなければならず、ＩｏＴのように大量のクライアントデバイスに対して公開鍵証明書を発行する必要がある場合には、識別情報の審査もしくは審査のためのデバイス情報登録作業の負荷が大きく、運用コストの増大が問題となっていた。本実施形態においては、クライアントデバイス１０に対し、登録局サーバ２２０によって管理される公開鍵証明書申請アプリケーション５０および正規手続き認証秘密鍵を利用させることで、識別情報の審査を行わずとも、クライアントデバイス１０の属性を保証できる。

アプリケーション発行サービスシステム３０は、認証局サービスシステム２０から受け取った公開鍵証明書申請アプリケーション５０を安全な形式に変換し、クライアントデバイス１０−ｎに対して配布するためのものである。本実施形態では、公開鍵証明書申請アプリケーション５０に設定された各種手続きが認証局サービスシステム２０にとって信頼できることを安全性の根拠の一つとしているため、各種手続きの改竄や秘密情報の漏洩を防ぐ必要がある。その方法として、公開鍵証明書申請アプリケーション５０−ｎをクライアントデバイス１０−ｎの非セキュア実行環境１６０−２に対して発行する場合には、公開鍵証明書申請アプリケーション５０に対して難読化を行う方法がある。一方、実用上は、公開鍵証明書申請アプリケーション５０をより安全に保護するために、クライアントデバイス１０−ｎの非セキュア実行環境ではなくセキュア実行環境１７０−１を利用することが好ましい。通常、セキュア実行環境１７０−ｎからのみアクセス可能なデバイス固有鍵（もしくはその派生鍵など）１８０−ｎを利用することで、公開鍵証明書申請アプリケーション５０に対して暗号化を行い、より安全に保護することが可能である。

図３は、図１に示したシステムにおける基本的な処理の流れを示す。まず、認証局サービスシステム２０の登録局サーバ２２０が、公開鍵証明書申請アプリケーションの登録を開始し（Ｓ１００）、正規手続き認証秘密鍵５３０を発行し（Ｓ１１０）、これを含めて公開鍵証明書申請アプリケーション５０を構成する（Ｓ１２０）。そして、登録局サーバ２２０は、アプリケーション発行サービスシステム３０のアプリケーション発行サーバ３１０へ、公開鍵証明書申請アプリケーションの発行を依頼し（Ｓ１３０）、アプリケーション発行サーバ３１０は、公開鍵証明書申請アプリケーション５０−ｎを発行する（Ｓ１４０）。ここまでが、公開鍵証明書申請アプリケーションの登録フェーズを構成する。なお、図１の例では、アプリケーション発行サービスシステム３０を独立して設けているが、認証局サービスシステム２０がアプリケーション発行サーバ３１０を含むようにしてもよい。

その後、公開鍵証明書の発行フェーズが実行される。まず、クライアントデバイス１０が、自装置に適合する公開鍵証明書申請アプリケーション５０−ｎを、アプリケーション発行サーバ３１０から取得し（Ｓ２００）、これを実行して（Ｓ２１０）、鍵ペア（証明の対象となる公開鍵およびそのペアとなる私有鍵）と証明書署名要求９０とを生成し（Ｓ２２０）、正規手続き認証秘密鍵５３０による電子署名を証明書署名要求９０に付与する（Ｓ２３０）。そして、クライアントデバイス１０は、証明書署名要求９０を正規手続き認証秘密鍵５３０による電子署名とともに認証局サービスシステム２０へ提出する（Ｓ２４０）。これを受信した登録局サーバ２２０は、正規手続き認証秘密鍵５３０による電子署名を検証し（Ｓ２５０）、検証に成功した場合は、証明書署名要求９０を認証局サーバ２１０へ送る（Ｓ２６０）が、検証に失敗した場合は、証明書署名要求を拒絶する。認証局サーバ２１０は、要求された公開鍵証明書を発行し（Ｓ２７０）、登録局サーバ２２０を介して（Ｓ２８０）、クライアントデバイス１０へ公開鍵証明書を配付する（Ｓ２９０）。これを受領したクライアントデバイス１０は、公開鍵証明書および上記私有鍵を保管する（Ｓ３００）。

［３］公開鍵証明書申請アプリケーション
公開鍵証明書申請アプリケーション５０は、認証局サービスシステム２０の登録局サーバ２２０によって管理され、アプリケーション発行サービスシステム３０により非改竄性および秘匿性を確保した形式に変換されてクライアントデバイス１０−ｎに安全に配布される。安全に配布可能な形式として構成された公開鍵証明書申請アプリケーション５０−ｎの一例を、図４および図５に、それぞれ公開鍵証明書申請アプリケーション５１および５２として示す。

図４に示すように、安全に配布可能な形式として構成された公開鍵証明書申請アプリケーション５１の各要素は、公開部分６０−１と非公開部分６５−１に分類される。公開部分６０−１については非改竄性が要求される。本実施形態では、公開鍵証明書申請アプリケーション５０に設定された各種手続きが認証局サービスシステム２０にとって信頼できることを安全性の根拠の一つとしているため、公開鍵証明書申請アプリケーション５０−ｎがクライアントデバイス１０−ｎに配布されてから実行される過程において、公開鍵証明書申請アプリケーション５０−ｎに設定された各種手続きが改竄されることを防ぐ必要がある。

公開部分６０−１の非改竄性を確保するためには、例えば、非公開部分６５−１に公開部分６０−１のハッシュ値５５０を含める方法がある（図４の「公開部分のハッシュ値」）。公開鍵証明書申請アプリケーション５１は、実行される際にクライアントデバイス１０−ｎの非セキュア領域もしくはセキュア領域のメインメモリに展開される。非公開部分６５−１に設定された起動プログラム５４０が、公開部分６０−１のハッシュ値を計算して検証する（計算した値が非公開部分６５−１に設定されているハッシュ値５５０と一致することを確認する）ことで、公開部分６０−１のデータが改竄されていないことを確認した上で、公開部分６０−１に含まれる公開鍵証明書の申請プログラム５１０を実行することができる。

加えて、非公開部分６５−１については非改竄性および秘匿性が要求される。非公開部分６５−１に含まれる正規手続き認証秘密鍵５３０は登録局サーバ２２０によって管理され、クライアントデバイス１０−ｎで実行された公開鍵証明書の申請手続きが正しく処理されたことを証明するための電子署名の付与に使用される。この正規手続き認証秘密鍵５３０は、公開鍵証明書申請アプリケーション５１が実行されるクライアントデバイス１０−ｎの信頼されない他のプロセスにはもちろんのこと、デバイス利用者１５に対しても秘匿されなければならない。公開部分６０−１の非改竄性の確保、非公開部分６５−１の非改竄性および秘匿性の確保、公開部分のハッシュ値５５０の設定、起動プログラム５４０の設定などは、アプリケーション発行サービスシステム３０によって実施される。

クライアントデバイス１０およびデバイス利用者１５は、信頼できない公開鍵証明書申請アプリケーションを実行する場合に、公開部分６０−１の内容について確認することで、実行される公開鍵証明書の申請手続きが妥当であるかどうかを判断することができる。仮に、クライアントデバイスで実行するのに妥当ではないと判断すれば、クライアントデバイス１０およびデバイス利用者１５は、公開鍵証明書申請アプリケーション５１の実行を中止することができる。

図５に示すように、公開鍵証明書申請アプリケーションが信頼できる発行元から配布される場合やデバイスの工場出荷時にプリインストールされている場合など、クライアントデバイス１０およびデバイス利用者１５が公開鍵証明書申請アプリケーション５２を無条件に信頼し、クライアントデバイスで実行するのに妥当であるかどうかを判断する必要がないのであれば、公開部分６０−１が全て非公開部分６５−２として発行されてもよい。

公開鍵証明書申請アプリケーション５０−ｎをクライアントデバイス１０−ｎで実行するには、公開鍵証明書申請アプリケーションを直接的に実行する方法と、他のアプリケーションから呼び出すことで間接的に実行する方法がある。後者に関しては、例えば、公開鍵証明書を必要とするアプリケーション７０（例えば、認証システムのクライアントアプリケーションなど）が、公開鍵証明書が必要になったときに公開鍵証明書申請アプリケーション５０−ｎを起動して申請する場合などがあり得る。

また、公開鍵証明書申請アプリケーション５０−ｎは、実行される際に何らかの入力値を要求するように構成しておくことができる。例えば、公開鍵証明書を暗号化や電子署名などの用途毎で使い分けるために、公開鍵証明書申請アプリケーション５０−ｎを実行する際に、申請する公開鍵証明書の種類を実行元に指定させるように構成することもできる。公開鍵証明書申請アプリケーション５０に公開鍵証明書の種類に応じた複数の申請手続きを設定しておけば、実行元から与えられた入力値にしたがい、複数の中から適切な申請手続きを選択して実行することもできる。

図６は、公開鍵証明書の申請プログラム５１０の処理内容の一例を示す。公開鍵証明書の申請プログラム５１０には、登録局サーバ２２０によって、公開鍵暗号方式の鍵ペア（公開鍵と私有鍵）を生成する（Ｓ４１０）ためのサブプログラム（鍵ペア生成サブプログラム）および公開鍵証明書を申請するために必要な証明書署名要求ＣＳＲ（Certificate Signing Request）を生成する（Ｓ４３０）ためのサブプログラム（証明書署名要求生成サブプログラム）が設定される。これらのサブプログラムには、鍵ペアや証明書署名要求の生成処理の他に、それらを生成するのに必要となる、クライアントデバイスに予め用意されているソフトウェアおよびライブラリの有無やバージョン、それら自体が改竄されていないかを確認するためのハッシュ値による検証処理などを含むこともできる。

例えば、鍵ペアの生成に利用するＯｐｅｎＳＳＬのバイナリが改竄されていないことを確認した上で鍵ペアの生成を行う場合、公開鍵証明書の申請プログラム５１０に含まれる鍵ペア生成サブプログラム（Ｓ４１０）は、図７に示すように、ＯｐｅｎＳＳＬバイナリのハッシュ値を取得し（Ｓ４１２）、ハッシュ値が想定されたハッシュ値と一致するか否かを調べ（Ｓ４１４）、一致する場合は、鍵ペアを生成して鍵ストアへ保存する（Ｓ４１６）が、一致しない場合は、エラーコードを返す（Ｓ４１８）。

また、公開鍵証明書の申請プログラム５１０に含まれる証明書署名要求生成サブプログラム（Ｓ４３０）は、例えば、図８に示すように、後述するデバイス識別情報取得サブプログラムを実行し（Ｓ４３２）、デバイス識別情報が正常に取得されたか否かを調べ（Ｓ４３４）、取得された場合は、証明書署名要求を生成する（Ｓ４３６）が、取得されなかった場合は、エラーコードを返す（Ｓ４３８）。

公開鍵証明書の申請プログラム５１０に含まれる証明書署名要求生成サブプログラムには、図９および図１０に示すように、クライアントデバイス１０の識別情報として様々なハードウェア１２０の情報を取得するデバイス識別情報取得サブプログラム４３２が含まれる。デバイス識別情報取得サブプログラム４３２には、クライアントデバイス１０のＲＯＭに記録されたシリアル番号１２２やネットワークカードのＭＡＣアドレス１２４などを詐称されることなく正確に読み取るためのプログラムが設定される。

クライアントデバイス１０に予め用意されたカーネル１４０やデバイスドライバ１３０が、マルウェアなどによって汚染されている可能性がある場合、それらを利用することなく動作するようにデバイス識別情報サブプログラム４３２を設定することができる。例えば、図１０の公開鍵証明書申請アプリケーション（a）５３に示すように、マルウェアなどによって汚染の可能性があるカーネル１４１やデバイスドライバ１３１を経由してデバイス識別情報サブプログラム４３２−１が取得する識別情報は、改竄されている可能性があるため、登録局サーバ２２０にとって信頼できる識別情報であることは保証できない。しかし、図１０の公開鍵証明書申請アプリケーション（b）５４に示すように、汚染されていないデバイス識別情報サブプログラム４３２−２を公開鍵証明書申請アプリケーションに含めることにより、クライアントデバイス１０が汚染されているかどうかに関わらず、登録局サーバ２２０にとって信頼できる識別情報を取得することができる。

また、デバイス識別情報取得サブプログラム４３２は、適切なプログラムさえ設定すれば、ＧＮＳＳ受信機が搭載されているクライアントデバイス１０では、位置情報１２６を読み取ることもできるし、タッチパネルなどの入力デバイスを備えているならば、認証情報１２８などをデバイス利用者に入力させて使用することもできる。

例えば、クライアントデバイス１０とデバイス利用者１５が紐付けられた公開鍵証明書を発行したい場合、クライアントデバイス１０自体の識別情報に加えて、そのクライアントデバイスを実際に利用しているデバイス利用者１５の識別情報（利用者ＩＤ）も必要となる。この利用者ＩＤは、クライアントデバイス１０の固有情報ではないため、クライアントデバイス１０から直接読み取ることはできない。また、デバイス利用者１５によって入力された利用者ＩＤは詐称されている可能性があるため、そのままでは信頼することができない。

そこで、図１１に示す例では、利用者ＩＤを管理する外部の信頼できる認証サービス８０と連携するプログラムを公開鍵証明書申請アプリケーション５０に設定することにより、詐称されていない信頼できる識別情報として、利用者ＩＤを取得する。具体的には、本機能を備える公開鍵証明書申請アプリケーションを実行するクライアントデバイス１０は、例えば、図９または図１０に示したデバイスのシリアル番号を、クライアントデバイス１０の信頼できる識別情報として取得する（Ｓ８００）とともに、利用者認証画面を表示し（Ｓ８１０）、デバイス利用者１５に利用者ＩＤおよびパスワードを入力させ（Ｓ８２０）、入力された情報を信頼できる認証サービス８０へ送信して（Ｓ８３０）、利用者ＩＤおよびパスワードの認証に成功した場合（Ｓ８４０）に、その利用者ＩＤを、デバイス利用者１５の信頼できる識別情報として取得する（Ｓ８５０）。そして、このように取得されたデバイスのシリアル番号とデバイス利用者の利用者ＩＤとを含む証明書署名要求を生成する（Ｓ８６０）。

他にも、様々なセンサーによる計測値を読み取るなど、デバイス識別情報取得サブプログラム４３２に設定するプログラム次第で、柔軟に様々な識別情報を取り扱うことが可能である。

図６に示すように、公開鍵証明書の申請プログラム５１０は、鍵ペア生成サブプログラムと証明書署名要求生成サブプログラムの両方がエラーなく正常に処理された場合（Ｓ４２０、Ｓ４４０）に限り、生成された証明書署名要求に対し、公開鍵証明書申請アプリケーションの非公開部分６５に設定された正規手続き認証秘密鍵５３０によって電子署名を付与し（Ｓ４５０）、認証局サービスシステム２０の登録局サーバ２２０に対して証明書署名要求９０を提出する（Ｓ４６０）。正規手続き認証秘密鍵５３０は、既述のとおり、登録局サーバ２２０によって管理され、アプリケーション発行サービスシステム３０によって公開鍵証明書申請アプリケーションの非公開部分６５として秘匿されてクライアントデバイス１０に配布されたものである。

これら一連の手続きの非改竄性が保証され、正規手続き認証秘密鍵が秘匿されているならば、登録局サーバ２２０は、自身が管理している正規手続き認証秘密鍵５３０を使って、受領した証明書署名要求９０の電子署名を検証することにより、登録局サーバ２２０にとって信頼できる手続きで公開鍵証明書の申請が行われたことを確認できる。クライアントデバイス１０では、最終的に認証局サーバ２１０から発行された公開鍵証明書を受領する（Ｓ４７０）が、この際に認証局サーバ２１０の公開鍵証明書５２０を使って受領した公開鍵証明書の電子署名を検証すれば、受領した公開鍵証明書が正しい認証局サーバ２１０によって発行されたものであることを確認できる。

ここで、公開鍵証明書が、認証や暗号化、電子署名などの用途毎に複数の種類があり、それぞれで申請手続きが異なる場合には、図１２に示すように、それらに応じた公開鍵証明書の申請プログラム５１０を複数種類（５１２、５１４、５１６）用意しておき、公開鍵証明書申請アプリケーション５５を実行する際の実行元の入力値に応じて、起動プログラム５４５が、使用する申請プログラムを切り替えるように構成することもできる。

例えば、ＩｏＴなどで利用されるようなクライアントデバイスは処理能力が低い場合も多く、ＲＳＡに比べて処理負荷が低いとされるＥＣＣ（楕円曲線暗号）を適用した鍵ペアを選択したい場合もある。同じＲＳＡによる鍵ペアの中でも、必要とする暗号強度と処理負荷の兼ね合いを考え、あまり重要なデータを扱わず処理負荷を抑えたい場合などでは、生成する鍵ペアの鍵長について短いものを選択する場合もある。逆に、医療情報など安全管理上の重要度が高いデータを扱うシステム・サービスで利用される場合には、生成する鍵ペアには比較的長い鍵長が選択される。

また、一部の認証システムなどでは、接続元となるクライアントデバイスのＭＡＣアドレスとデバイス利用者の利用者ＩＤが要求されるなど、公開鍵証明書を利用するシステム・サービスの実装によって要求される識別情報が変わる可能性もある。例えば、いわゆるマイナンバー法における個人番号カードには、署名用電子証明書（ｅ−Ｔａｘなどの電子申請に利用）と利用者証明用電子証明書（マイナポータルへのログインなどに利用）の二種類の公開鍵証明書が発行されるが、氏名・住所・生年月日・性別の基本四情報は署名用電子証明書にのみ記載されるなど、それぞれの公開鍵証明書では記載内容が異なっている（「電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律（改正：平成２５年５月３１日法律第２８号）」の第７条および第２６条を参照）。

このように、扱うデータの種類やシステム・サービスでの利用要件によって、様々な種類の公開鍵証明書が発行されうる。公開鍵証明書申請アプリケーション５５では、こうした状況を見越して、予め複数の申請プログラムを用意しておくことで柔軟に対応することが可能である。

図４に示した認証局サーバの公開鍵証明書５２０は、クライアントデバイス１０に発行される公開鍵証明書の発行者である認証局サービスシステム２０の認証局サーバ２１０が保有する公開鍵証明書であり、公開鍵証明書申請アプリケーション５０の管理者もしくは発行者の確認や、クライアントデバイスが受領した公開鍵証明書の発行者の確認などに利用される。これにより、クライアントデバイス１０およびデバイス利用者１５は、受領した公開鍵証明書が正しい認証局サービスシステム２０によって発行されたことを確認することができる。

また、公開鍵証明書が発行された後で何らかのサービスやアプリケーションを利用する場合、同じ認証局サーバ２１０から発行された公開鍵証明書を持つサーバとの通信やクライアントデバイス同士での通信を行う際に、その通信相手の公開鍵証明書の有効性を検証する目的に、認証局サーバの公開鍵証明書５２０を利用してもよい。

クライアントデバイス１０から提出される証明書署名要求９０に秘匿すべき情報が含まれる場合などでは、この認証局サーバの公開鍵証明書５２０に含まれる公開鍵によって、証明書署名要求９０をＣＭＳ（Cryptographic Message Syntax）（例えば、「Cryptographic Message Syntax (CMS)」RFC 5652, IETF（2009/9）を参照）などの形式で暗号化してから提出するように構成してもよい。必要であれば、公開鍵証明書申請アプリケーション５０に対して、証明書署名要求９０の暗号化に使用するための専用の暗号鍵（共通鍵暗号方式での秘密鍵もしくは公開鍵暗号方式での公開鍵）を、この認証局サーバの公開鍵証明書５２０とは別に含めることもできる。

［４］クライアントデバイス
公開鍵証明書の発行を受けるクライアントデバイス１０−ｎは、多種多様かつ大量の機器・設備があり得る。例えば、スマートメーターなどの電力量計、ホルター心電計などの医療機器、生産工場などで利用される産業ロボット、自動車、そしてパソコンやスマートフォンなどである。実用上は、公開鍵証明書申請アプリケーション５０−ｎをより安全に保護するために、クライアントデバイス１０の非セキュア実行環境１６０ではなくセキュア実行環境１７０を利用することが好ましい。

公開鍵証明書申請アプリケーション５０は、アプリケーション発行サービスシステム３０によって、非公開部分６５が秘匿化されて、クライアントデバイス１０に配布される。一般に、クライアントデバイス１０−ｎがセキュア実行環境１７０−ｎを備えている場合は、そのセキュア実行環境１７０−ｎからのみアクセス可能なデバイス固有鍵が、クライアントデバイス１０−ｎの出荷時に埋め込まれている。そのため、そのデバイス固有鍵（もしくはその派生鍵など）１８０−ｎを利用することで、公開鍵証明書申請アプリケーション５０−ｎを暗号化して安全にクライアントデバイス１０−ｎのセキュア実行環境１７０−ｎに配布することができる。なお、ここではデバイス固有鍵と説明しているが、そのクライアントデバイスのモデルや出荷ロット毎に固有である場合もあるし、対称鍵（共通鍵暗号方式での秘密鍵）や非対称鍵（公開鍵暗号方式での私有鍵）が埋め込まれる場合もある。

公開鍵証明書申請アプリケーション５０−ｎがクライアントデバイス１０−ｎの非セキュア実行環境１６０−ｎに対して発行される場合には、非公開部分６５の秘匿化のために難読化などの手法が適用される。クライアントデバイス１０−ｎで公開鍵証明書申請アプリケーション５０−ｎが実行される際には、クライアントデバイス１０−ｎで実行される信頼されない他のプロセスやデバイス利用者１５−ｎからの秘匿性が、例えば、図１３に示すように、保たれる。図１３の例では、非セキュア実行環境１６０−ｎにおいては、難読化およびソフトウェアレベルのメモリ空間分離によって、公開鍵証明書申請アプリケーションの非公開部分６５−ｎの秘匿性が保たれ、セキュア実行環境１７０−ｎにおいては、暗号化およびハードウェアレベルのメモリ空間分離によって、公開鍵証明書申請アプリケーションの非公開部分６５−ｎの秘匿性が保たれる。ただし、クライアントデバイスの種類や実行環境の制約などにより、公開鍵証明書申請アプリケーション５０−ｎはセキュア実行環境で実行されるが、非公開部分６５−ｎに関しては暗号化ではなく難読化によって保護するなど、様々な形態があり得る。

［５］認証局サービスシステム
認証局サービスシステム２０は、公開鍵証明書の実際の発行を行う認証局サーバ２１０と、クライアントデバイス１０の属性を保証する登録局サーバ２２０から構成される。

認証局サーバ２１０については、従来の認証局と役割を同じにしてもよい。認証局サーバ２１０は、自身の鍵ペアを厳重に管理し、その私有鍵を使って、クライアントデバイス１０に公開鍵証明書を発行するための電子署名を実施する。また、公開鍵証明書申請アプリケーション５０にも含まれる認証局サーバ自身の公開鍵証明書５２０を管理する。

登録局サーバ２２０では、公開鍵証明書申請アプリケーション５０および公開鍵証明書申請アプリケーションに含める正規手続き認証秘密鍵５３０の管理を行う。

図１４に、公開鍵証明書申請アプリケーション５０を管理するデータベースの一例を示す。公開鍵証明書申請アプリケーション５０は、デバイス種別に合わせた複数のプログラムを用意することで、多種多様なクライアントデバイス１０−ｎにも対応することが可能である。また、特定のクライアント企業向けにカスタマイズした公開鍵証明書申請アプリケーション５０を用意するなど、利用者毎に管理してもよい。これにより、多種多様なクライアントデバイスや利用者などに対しても、統一的なサービス基盤によって公開鍵証明書を発行することができる。

図１５には、正規手続き認証秘密鍵５３０を管理するデータベースの一例を示す。正規手続き認証秘密鍵５３０は、全ての公開鍵証明書申請アプリケーション５０で同一のものを使用することも可能だが、万が一に漏洩した場合の影響範囲を限定するために、対象となるデバイス種別毎や利用者毎に異なるものを使用したり、一定期間毎に更新したりすることも可能である。もし正規手続き認証秘密鍵５３０が漏洩した場合には、直ちに漏洩したものを失効させ、新しく発行し直す。

図１６に示すように、登録局サーバ２２０の正規手続き認証鍵発行モジュール２２２により発行された正規手続き認証秘密鍵５３０は、アプリケーション発行サーバ３１０により公開鍵証明書申請アプリケーション５０−ｎの非公開部分６５に設定されてクライアントデバイス１０−ｎに配布される。また同時に、後の検証処理のために、登録局サーバ２２０の正規手続き認証鍵管理データベース２２６（図１５）に保存される。

クライアントデバイス１０−ｎでは、正規手続き認証秘密鍵５３０を、生成した証明書署名要求９０−ｎに電子署名（正規手続き電子署名）５３８を付与するのに使用する。登録局サーバ２２０は、クライアントデバイス１０−ｎから渡された証明書署名要求９０−ｎに付与された正規手続き電子署名５３８について、検証に必要な正規手続き認証秘密鍵５３０を正規手続き認証鍵管理データベース２２６から取得し、正規手続き電子署名検証モジュール２２４によって検証を行う。公開鍵証明書申請アプリケーション５０の非改竄性が保証され、正規手続き認証秘密鍵５３０が秘匿されているならば、登録局サーバ２２０は、自身が管理している正規手続き認証秘密鍵５３０を使って、受領した証明書署名要求９０−ｎの電子署名５３８を検証することにより、登録局サーバ２２０にとって信頼できる手続きでクライアントデバイス１０−ｎの識別情報が取得され、その結果として公開鍵証明書の申請が行われたことを確認できる。したがって、登録局サーバ２２０は、識別情報の審査を行わずとも、クライアントデバイス１０−ｎの属性を保証できる。

正規手続き認証秘密鍵５３０による電子署名５３８の検証で問題がなければ、登録局サーバ２２０は、認証局サーバ２１０に対してクライアントデバイス１０−ｎの公開鍵証明書を申請し、クライアントデバイス１０−ｎに公開鍵証明書が発行される。認証局サーバ２１０が公開鍵証明書を発行する際には、必要に応じて、登録局サーバ２２０および認証局サーバ２１０が従来の秘密鍵所有の証明ＰＯＰ（Proof-of-Possession）（例えば、小松文子「改訂ＰＫＩハンドブック」116-117，株式会社ソフト・リサーチ・センター（2004/11/25）を参照）を実施することで、発行する公開鍵証明書に対応した私有鍵をクライアントデバイスが確かに所有していることを確認する。

一方で、失効された正規手続き認証秘密鍵によって付与された電子署名の場合などでは検証が失敗し、クライアントデバイス１０−ｎに対してその旨を示すエラーを通知することができる。また、他の何らかの理由によって公開鍵証明書を発行できない場合についても、クライアントデバイス１０−ｎに対してその旨を示すエラーを通知することができる。このような場合、クライアントデバイス１０−ｎは、通知されたエラーの内容に従い、アプリケーション発行サービスシステム３０から新しい公開鍵証明書申請アプリケーション５０を取得して、公開鍵証明書を再申請する、別のパラメータによって再申請する、申請自体を中止するといった選択を行う。

［６］アプリケーション発行サービスシステム
アプリケーション発行サービスシステム３０は、認証局サービスシステム２０から公開鍵証明書申請アプリケーション５０を受け取り、非公開部分６５の秘匿化やデバイス種別に合わせた構成および最適化などを実施して、クライアントデバイス１０に発行する。

アプリケーション発行サーバ３１０は、クライアントデバイス１０がセキュア実行環境１７０を備えている場合に、そのセキュア実行環境１７０に対してアプリケーション５０を発行するためにデバイス固有鍵（もしくはその派生鍵など）１８０を利用する。一般に、セキュア実行環境１７０−ｎからのみアクセス可能になっているデバイス固有鍵１８０−ｎを利用することで、セキュア実行環境１７０−ｎに対してアプリケーション５０−ｎを暗号化して安全に配布することができる。

デバイス固有鍵１８０−ｎは、アプリケーション発行サーバ３１０によって直接管理されるか、もしくはデバイスベンダやセキュア実行環境用ＯＳベンダによって管理される。デバイス固有鍵１８０−ｎがデバイスベンダやセキュア実行環境用ＯＳベンダによって管理されている場合には、アプリケーション発行サーバ３１０は、それらと連携してデバイス固有鍵を利用する。なお、デバイス固有鍵１８０は、対称鍵（共通鍵暗号方式での秘密鍵）であってもよいし、非対称鍵（公開鍵暗号方式での公開鍵をアプリケーション発行サーバ３１０が用い、私有鍵をクライアントデバイス１０が用いる）であってもよい。

また、このデバイス固有鍵１８０−ｎの管理だけではなく、非セキュア実行環境１６０−ｎもしくはセキュア実行環境１７０−ｎにアプリケーションを発行する場合には、デバイス種別に応じた特別なアプリケーション５０−ｎの構成・発行方法が必要な場合もあり得る。例えば、非セキュア実行環境もしくはセキュア実行環境で使用されているＯＳによってアプリケーションの実行形式が異なる場合や、単体では動作させずに他のアプリケーションから利用させるライブラリ形式として発行する場合があり得る。また、クライアントデバイス１０がセキュア実行環境１７０を備えていても、アプリケーション発行サーバ３１０がそのクライアントデバイス１０のデバイス固有鍵１８０を利用できないならば、アプリケーション５０を暗号化ではなく難読化して発行しなければならない場合もある。

これらに対処するため、アプリケーション発行サーバ３１０は、図１７に示すように、暗号化に使用されるデバイス固有鍵１８０もしくはその利用方法、そしてデバイス種別に応じたアプリケーションの構成・発行方法などを管理するデータベースを備えてもよい。アプリケーション発行サーバ３１０は、クライアントデバイス１０−ｎに対して公開鍵証明書申請アプリケーション５０−ｎを発行する際には、アプリケーション構成・発行方法管理データベースから対象となるクライアントデバイスの条件に合致するレコードを検索する。以下にその一例を示す。

例えば、デバイス種別が“スマートフォンＡ”、デバイスベンダＩＤが“VENDOR-001”、デバイスＩＤが“DEVICE-003”の場合、図１７のアプリケーション構成・発行方法管理データベースでは、ＩＤが２，３，５のレコードが条件に合致する。この中から、最も優先度の高いレコードを選択し、その内容にしたがって公開鍵証明書申請アプリケーションを発行する。つまり、前述した例では、ＩＤが２のレコードが選択され、公開鍵証明書申請アプリケーションがデバイス固有鍵“ZZZZZZZZZZ002”で暗号化される。暗号化の方式としては、非改竄性と秘匿性を兼ね備えた暗号利用モードを使用することが考えられる。例えば、非改竄性と秘匿性を兼ね備えた認証付き暗号（Authenticated Encryption）を実現する暗号利用モードとして、NISTで規定されているＣＣＭ（Counter with CBC-MAC）（M. Dworkin著「Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality」NIST Special Publication, 800-38C（2004/5）を参照）やＧＣＭ（Galois/Counter Mode）（M. Dworkin著「Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC」NIST Special Publication, 800-38D（2007/11）を参照）が利用できる。

また、クライアントデバイス１０の条件によっては、非公開部分６５の暗号化ではなく難読化によって秘匿化する場合もある。難読化を施すための様々な手法（例えば、C. Collberg他著「Surreptitious Software」 Addison-Wesley Professional（2009/7/24）を参照）、また専用の商用製品やオープンソースソフトウェアは数多く存在する。ただし、公開鍵証明書申請アプリケーション５０の非公開部分６５をより安全に保護するためには、可能な限り、クライアントデバイス１０のセキュア実行環境１７０および暗号化などのセキュア実行環境に対する適切なアプリケーション５０の構成・発行方法を利用することが望ましい。セキュア実行環境１７０へのアプリケーション５０の発行が行えない場合などに、安全上の理由などから必要であれば、そもそも公開鍵証明書申請アプリケーションの発行を実施しないという方針を採ってもよい。その場合には、当然ながら、その対象となるクライアントデバイスでは公開鍵証明書申請アプリケーションを利用することができない。

アプリケーション発行サービスシステム３０は、十分に信頼できる主体によって運営される必要がある。アプリケーション発行サービスシステムが不正であると、認証局サービスシステム２０が設定した各種手続きの改竄や認証局サーバ２１０の公開鍵証明書のすり替え、正規手続き認証秘密鍵５３０やデバイス固有鍵１８０の漏洩などが故意過失を問わず発生する可能性があるからである。認証局サービスシステム２０は、アプリケーション発行サービスシステム３０が十分に信頼できることを確認することが望ましい。場合によっては、認証局サービスシステム２０自体がアプリケーション発行サービスシステム３０の役割を兼ねてもよい。

また、クライアントデバイス１０およびデバイス利用者１５も、アプリケーション発行サービスシステム３０が十分に信頼できることを確認することが望ましい。そのために必要であれば、公開鍵証明書申請アプリケーション５０に対して、アプリケーション発行サービスシステム３０によるコード署名を追加することもできる。クライアントデバイス１０−ｎおよびデバイス利用者１５−ｎは、公開鍵証明書申請アプリケーション５０−ｎに付与されたコード署名の有効性を検証することで、公開鍵証明書申請アプリケーションの最終的な発行者が信頼できるかどうか確認することができる。

なお、コード署名とは、システムが、コード（アプリケーションのプログラムコード）の出所を特定したり、コードが変化又は破損していないことを保証したりできるように、コードに電子署名を行う処理である。具体的には、コードの署名者のコンピュータが、コードのハッシュ値を作成し、公開鍵暗号方式での私有鍵を使用してこのハッシュ値を暗号化し、この暗号化したハッシュ値及び公開鍵証明書をコードに挿入して送信する。受信者のコンピュータは、受信したコードのハッシュ値を作成し、受信した暗号化されたハッシュ値を、公開鍵証明書に含まれる公開鍵を使用して解読し、これらの結果を比較することにより、署名を検証する。二つのハッシュ値が一致すれば、その署名は正当なものである。

［７］公開鍵証明書申請アプリケーションの配布方法
図３の例では、最初に、認証局サービスシステム２０からアプリケーション発行サービスシステム３０に対して公開鍵証明書申請アプリケーション５０を登録しておき、その後、クライアントデバイス１０−ｎが必要に応じてアプリケーション発行サービスシステム３０から利用可能な公開鍵証明書申請アプリケーション５０−ｎを取得するという方法で、公開鍵証明書申請アプリケーションを配布している。公開鍵証明書申請アプリケーションの配布を適用する具体的なシステムとしては、以下に例示するように、種々のものがあり得る。

図１８は、パブリックな認証局サービスシステム２０−１によってアプリケーション発行サービスシステム３０−１に登録された公開鍵証明書申請アプリケーション５０を、インターネットなどの外部ネットワーク４０−１を介して、一般の利用者が持つクライアントデバイス１０−ｎが取得する様子を示している。

図１９は、企業情報システム４００−１内のプライベートな認証局サービスシステム２０−２によってアプリケーション発行サービスシステム３０−２に登録された公開鍵証明書申請アプリケーション５０を、企業内のクライアントデバイス１０−ｎから取得する様子を示している。

企業情報システムにおいては、ＭＤＭ（Mobile Device Management）などのデバイス管理サービスシステムを利用することで、企業内デバイスを厳格に管理している事例も多い。図２０では、認証局サービスシステム２０−３を備える企業情報システム４００−２において、アプリケーション発行サービスシステム３０−３とデバイス管理サービスシステム３５を連携させることで、企業内のクライアントデバイス１０−ｎに対して、公開鍵証明書申請アプリケーション５０−ｎを強制配信して実行させる様子を示している。このように、デバイス管理サービスシステムと連携させたシステムを構築することによって、企業内デバイスの公開鍵証明書を、デバイス管理者によって一括管理することも可能となる。

また、企業情報システムにおいても、プライベート認証局による公開鍵証明書申請アプリケーションの配布に限らず、パブリック認証局による公開鍵証明書申請アプリケーションの配布を行うことが可能である。このような場合には、例えば、図２１に示すように、企業情報システム４００−３内のキャッシュサーバ４２によって、パブリックな認証局サービスシステム２０−１が登録した公開鍵証明書申請アプリケーション５０をアプリケーション発行サービスシステム３０−１から一旦取得しておき、企業内のクライアントデバイス１０−ｎは、キャッシュサーバ４２から適切な公開鍵証明書申請アプリケーション５０−ｎを取得する。この方法は、ネットワーク４０のトラフィックやアプリケーション発行サービスシステム３０の負荷を低減させるのに効果的である。図２２の例では、企業情報システム４００−４内のキャッシュサーバ４２に、前述したデバイス管理サービスシステム４４を組み合わせることで、公開鍵証明書申請アプリケーション５０−ｎを強制配信して実行させ、企業内デバイスの公開鍵証明書を一括管理可能にしている。

自動車や家電製品などを扱うデバイスベンダが、自社で生産又は販売したデバイスに対するリモートメンテナンスサービスなどを提供する場合、それらのデバイスに対してデバイスベンダが管理するプライベート認証局から公開鍵証明書を発行できると都合がよい。このような場合には、例えば、図２３に示すように、認証局サービスシステム２０−４およびアプリケーション発行サービスシステム３０−４を備えるデバイスベンダ４５０−１のデバイス管理サービスシステム４６から、一般の利用者が持つクライアントデバイス１０−ｎに対して、インターネット４０−１を経由した公開鍵証明書申請アプリケーション５０−ｎの強制配信と実行を行う。別の例として、図２４に示すように、認証局サービスシステム２０−５およびアプリケーション発行サービスシステム３０−５を備えるデバイスベンダ４５０−２のデバイス生産ライン４８によって、公開鍵証明書申請アプリケーション５０−ｎをデバイス１０−ｎに格納し、その状態でデバイス１０−ｎを出荷してもよい。

クライアントデバイス１０−ｎ（またはデバイス利用者１５−ｎ）が公開鍵証明書申請アプリケーション５０−ｎを取得するには、公開鍵証明書申請アプリケーションが登録されているＷｅｂサイトからダウンロードする方法のほかに、ＣＤ−ＲＯＭやＵＳＢメモリなどの可搬型記録媒体によって受け取る方法や、ＭＤＭなどのデバイス管理サービスシステムからの配信を受ける方法などがあり得る。

また、図２５の例に示すように、公開鍵証明書を利用するアプリケーション７０に対して専用のライブラリ７５などを提供することで、これらのアプリケーション７０による公開鍵証明書の要求を検知し、必要に応じて適切な公開鍵証明書申請アプリケーション５０−ｎを自動取得して実行させるように構成することもできる。こうした方法であれば、正規手続き認証秘密鍵５３０が失効したために証明書署名要求９０の検証に失敗する場合でも、その旨のエラー通知を受け取ることによって、新しい正規手続き認証秘密鍵５３０を含む公開鍵証明書申請アプリケーション５０−ｎを自動的に取得しなおすことも可能となる。このような場合には、自動取得した公開鍵証明書申請アプリケーション５０−ｎの初回実行時に、その公開鍵証明書申請アプリケーションの発行元や公開部分６０−ｎについての確認などを実施することになる。

別の例として、図２６に示すように、配布する公開鍵証明書申請アプリケーション５０−ｎ（５６）には、公開鍵証明書の申請プログラム５１０そのものではなく、公開鍵証明書の申請プログラムを取得するクライアントプログラム５１１を含めておき、実行時に、クライアントプログラム５１１によって、アプリケーション発行サービスシステム３０に用意してある複数種類の公開鍵証明書の申請プログラム５１０（５１３，５１５，５１７）の中から、デバイスの種類や用途に応じた最適な申請プログラムを選択して取得するように構成してもよい。こうした方法であれば、クライアントデバイス１０−ｎの型番などの情報に応じた、より柔軟な申請プログラムの構成および実行も可能となる。なお、図２６には、図４の例の公開鍵証明書申請アプリケーション５１に本例を適用した構成を示したが、図５の例の公開鍵証明書申請アプリケーション５２にも同様に本例を適用することができる。

［８］正規手続き認証鍵管理の簡略化
以上に説明した例では、正規手続き認証鍵に、共通鍵暗号方式を利用しているが、代わりに公開鍵暗号方式を利用することで、認証局サービスシステム２０の登録局サーバ２２０における正規手続き認証鍵の管理を簡略化することができる。図２７に、詳細な方法の一例を示す。

登録局サーバ２２０の正規手続き認証鍵発行モジュール２２３では、正規手続き認証鍵ペア（正規手続き認証公開鍵５３２と正規手続き認証私有鍵５３１）を生成し、正規手続き認証公開鍵５３２に登録局サーバ秘密鍵２２７による電子署名５３３を付与する。クライアントデバイス１０−ｎでは、証明書署名要求９０−ｎに対して、公開鍵証明書申請アプリケーション５０−ｎに含まれる正規手続き認証公開鍵５３２およびその登録局サーバ電子署名５３３を設定し、加えて正規手続き認証私有鍵５３１による電子署名５３５を付与する。

証明書署名要求９０−ｎを受け取った登録局サーバ２２０は、正規手続き電子署名検証モジュール２２５によって、証明書署名要求９０−ｎに含まれる正規手続き認証公開鍵５３２に付与された登録局サーバ電子署名５３３の有効性を登録局サーバ秘密鍵２２７で検証し、有効性が確認された正規手続き認証公開鍵５３２により証明書署名要求９０−ｎに付与された正規手続き電子署名５３５の有効性を検証する。

この方法では、正規手続き電子署名の検証のために、全ての発行済み正規手続き認証鍵を管理する必要がなく、一つの登録局サーバ秘密鍵２２７と失効した正規手続き認証鍵２２８の管理を行うだけで済む。共通鍵暗号方式を利用する方法に比べ、正規手続き認証鍵の発行や正規手続き電子署名の検証などに必要となる処理は増加するものの、大量の正規手続き認証鍵を扱う必要がある場合などには特に有効である。

［９］公開鍵証明書申請アプリケーションによる公開鍵証明書および鍵ペアの管理
公開鍵証明書の信頼性を保証するには、公開鍵証明書の発行に関する手続きだけでなく、その後の私有鍵の安全な管理も重要である。このためには、公開鍵証明書申請アプリケーション５０を機能拡張し、発行された公開鍵証明書および対応する鍵ペアの管理機能を持たせることが有効である。

図２８の例では、クライアントデバイス１０−ｎのセキュア実行環境１７０−ｎに配置された公開鍵証明書申請アプリケーション５０−ｎによって、非セキュア実行環境１６０−ｎに配置されるアプリケーション７０−Ａが利用する鍵データ（公開鍵証明書および対応する鍵ペア）１１０−Ａと、セキュア実行環境１７０−ｎに配置されるアプリケーション７０−Ｂが利用する鍵データ（公開鍵証明書および対応する鍵ペア）１１０−Ｂとを管理する。このように、認証局にとって信頼できる手続きを含む公開鍵証明書申請アプリケーション５０−ｎが鍵データを直接管理することで、鍵データの安全性が高いレベルで確保され、クライアントデバイス１０−ｎおよびデバイス利用者１５−ｎにとっても安心して公開鍵証明書を利用できるようになる。また、この例で示すように、セキュア実行環境１７０−ｎで鍵データを管理することで、悪意を持つデバイス利用者やマルウェアなどによる私有鍵への不正なアクセスを防ぎ、より安全な鍵データの管理を実現できる。

図２９では、公開鍵証明書申請アプリケーション５０−ｎを機能拡張することで、公開鍵証明書の管理プログラム５７０と私有鍵の利用（演算）プログラム５８０とを追加する例を示す。公開鍵証明書申請アプリケーション５７に公開鍵証明書が要求されると、公開鍵証明書の管理プログラム５７０は、自身が管理する鍵データストレージを検索し、該当する公開鍵証明書が見つかれば、それを取得して返す。該当する公開鍵証明書が見つからない場合は、公開鍵証明書の申請プログラム５１０によって新しい鍵ペアを生成し、その公開鍵証明書の発行を認証局サービスシステム２０に依頼する。そして、公開鍵証明書が成功裏に発行されれば、その公開鍵証明書を返す。新しく生成された鍵データは、管理プログラム５７０によって、鍵データストレージ６５０に追加されて管理される。

図２９の例において、私有鍵を利用した演算（電子署名の生成や暗号データの復号など）が必要な場合には、それを必要とするアプリケーション７０が、私有鍵の利用（演算）プログラム５８０に、処理を依頼する。通常、私有鍵の利用にはアクセス制御が必要であるため、私有鍵の利用（演算）プログラム５８０によって、処理を依頼したアプリケーション７０が鍵データストレージ６５０に保管されている私有鍵に対するアクセス権限を有するか否かが検査され、アクセス権限に従った利用がなされるように管理される。鍵データストレージ６５０は、少なくとも私有鍵については、セキュア実行環境１７０−ｎに設けることが望ましい。

［１０］ＴＰＭ（Trusted Platform Module）との連携による公開鍵証明書の発行
ＴＥＥによって実現するセキュア実行環境は、ハードウェアレベルで分離される安全な実行環境を提供することで、ネットワークを通じた不正アクセスやマルウェアによる汚染などからアプリケーションやデータを保護することができる。ＴＥＥは、ハードウェアレベルの耐タンパー性を持つものではないため、前述したようなソフトウェアレベルの攻撃へは強い耐性を持つが、物理プロービングや電子顕微鏡によるリバースエンジニアリングなどのハードウェアレベルの攻撃を完全に防ぐことはできない。こうしたハードウェアレベルの攻撃をも防ぐことが可能な、ハードウェアレベルの耐タンパー性を持つセキュリティ技術として、例えば、ＴＰＭ（W. Arthur他著「A Practical Guide to TPM 2.0: Using the Trusted Platform Module in the New Age of Security」Apress Media, LLC（2015/1/28）を参照）のようなセキュリティチップなどが存在する。

ＴＰＭは、ＲＳＡ鍵ペアの生成や利用（演算）のための機能などを備えているため、本実施形態に組み合わせて利用することで、より安全な公開鍵証明書の発行を実現できる。図３０は、ＴＰＭとの連携によって公開鍵証明書を発行する例を示す。クライアントデバイス１０−ｎのセキュア実行環境１７０−ｎに配置された公開鍵証明書申請アプリケーション５０−ｎによって、クライアントデバイス１０−ｎに搭載されているＴＰＭ１８５−ｎに対してＲＳＡ鍵ペアの生成を依頼し、その生成されたＲＳＡ鍵ペアに対する公開鍵証明書を認証局サービスシステム２０に申請する。

ＴＰＭによって生成されたＲＳＡ鍵ペアの私有鍵は、ＴＰＭ１８５−ｎの外部に取り出すことができないようになっているため、前節で説明した公開鍵証明書申請アプリケーションによる公開鍵証明書および鍵ペアの管理などと組み合わせることで、より安全な鍵データの管理を実現することも可能である。

［１１］本実施形態の効果
本実施形態によれば、公開鍵証明書を発行する特定組織のプライベート認証局および広く開放されたパブリック認証局の両方において、クライアントデバイスの識別情報に関する審査が不要となる公開鍵証明書発行方法が実現される。これにより、クライアントデバイスへの公開鍵証明書の発行を本質的に自動化することが可能となるため、公開鍵基盤の運用コストを削減することができる。クライアントで鍵ペアを生成して公開鍵証明書の申請を開始する基本認証方式でありながら、大量のデバイスが扱われるＩｏＴなどにおいても低コストで公開鍵基盤を運用することが可能になる。

公開鍵証明書を申請する際に必要となる鍵ペアや証明書署名要求の生成、クライアントデバイスの識別情報の取得などについて、公開鍵証明書を発行する責任者である認証局にとって信頼できる手続きで実施させることができる。これにより、発行する公開鍵証明書の安全性・信頼性の向上が期待できる。

また、前節や前々節で説明したような公開鍵証明書および鍵ペアの管理などと組み合わせることで、より安全な鍵データの管理を実現することも可能である。こうした効果は、ＩＴスキルの弱いデバイス利用者にとっては特に有用であり、誰もが安心して利用できる公開鍵基盤の実現に繋がる。

公開鍵証明書申請アプリケーションは、デバイス種別に合わせた複数のプログラムを用意することで、多種多様なクライアントデバイスにも対応することが可能である。これにより、統一的なサービス基盤によって、多種多様なクライアントデバイスに対して公開鍵証明書を発行することができる。これは、多種多様なデバイスが扱われるＩｏＴでは特に有用となる。

公開鍵証明書申請アプリケーションによって、公開鍵証明書の申請に必要なクライアントデバイスの識別情報として、クライアントデバイスのＲＯＭに記録されたシリアル番号やネットワークカードのＭＡＣアドレスなどを、詐称されることなく正確に読み取って利用することが可能になる。また、適切なプログラムを設定すれば、ＧＮＳＳ受信機が搭載されているクライアントデバイスでは位置情報を読み取ることも可能になるし、タッチパネルなどの入力デバイスを備えているならば認証情報などをデバイス利用者に入力させて使用することも可能になる。他にも、様々なセンサーによる計測値を読み取るなど、デバイス識別情報取得サブプログラムに設定するプログラム次第で、柔軟に様々な識別情報を取り扱うことが可能である。

公開鍵証明書申請アプリケーションを利用することで、認証局にとって信頼できる手続きで取得される詐称されていない識別情報がクライアントデバイスから提出される。この詐称されていない識別情報を利用することで、組織のディレクトリサービスへのデバイス情報の登録を省力化することができる。従来技術と本実施形態でのデバイス情報登録方法の違いを、図３１に例示する。従来技術では、デバイス管理者が、デバイス管理ディレクトリサービスにデバイス情報を事前登録しておくことで、認証局サービスはその登録情報を利用して公開鍵証明書の発行に必要な識別情報の審査を行うことができた。本実施形態では、公開鍵証明書を発行したクライアントデバイス１０−ｎに限られるが、公開鍵証明書の発行に際して得られる識別情報を利用することで、認証局サービス２０からデバイス管理ディレクトリサービスに対して、デバイス情報を自動登録することが可能となる。

企業などにおいては、社員に貸与している特定のデバイスにのみ公開鍵証明書を発行したいという状況もあり得る。このような場合には、本実施形態による方法であっても、公開鍵証明書を発行する対象を識別するデバイス情報を、デバイス管理者などがデバイス管理ディレクトリサービスに事前登録しておく必要がある。しかしながら、公開鍵証明書に記載される可能性のある全ての識別情報について事前登録しておく必要はなく、あくまでも公開鍵証明書を発行したい対象を識別できるだけの必要最小限のデバイス情報のみを登録すればよい。残りのデバイス情報については公開鍵証明書の発行に際して得られる識別情報から補完することができるため、このような場合でもデバイス情報の登録を省力化できる。

［１２］本実施形態の応用例
本実施形態は、大量のデバイスが扱われるＩｏＴなどのように、多種多様かつ大量の機器・設備で利用されることが可能である。そして、デバイスに対する公開鍵証明書の発行方法であることから、公開鍵基盤を利用する様々なサービス・アプリケーションに応用することが可能である（例えば、カーライル・アダムズ他「ＰＫＩ公開鍵インフラストラクチャの概念、標準、展開」53-68，株式会社ピアソン・エデュケーション（2000/7/15）を参照）。

一般に、個人情報の取り扱いには、十分なセキュリティ水準が必要とされる。特に、医療データのような機微な個人情報を複数のデバイス間で共有する場合には、ＴＬＳ（Transport Layer Security）などによる通信路の保護だけではなく、特定のデバイスのみがアクセスできる形でデータ自体を暗号化することが望ましい。これにより、ネットワークに接続されるデバイスがリモートからの不正アクセスなどによってクラッキングされ、万が一に医療データなどの重要情報が漏洩したとしても、その内容を保護することができる。

デバイスに発行された公開鍵証明書を利用することで、こうした仕組みを容易に構築することができる。図３２に、公開鍵証明書を利用した医療データの安全な共有方法の一例を示す。この方法では、医療データを共有する共有元ホストが、認証局の公開鍵を使って共有先となる各デバイスの公開鍵証明書の有効性を検証することで、医療データを共有するデバイスを確実に特定し、そのデバイスの公開鍵で医療データを暗号化して共有する。この暗号化された医療データは、共有元ホストによって特定されたデバイスのみが復号できるため、患者のスマートフォンやかかりつけの診療所、また様々な医療機器などに対して安全に共有することが可能となる。

また、本実施形態により、デバイスに対して公開鍵証明書を自動で発行できるようになるため、デバイス数が増加しても運用負荷の増大を最小限に抑えることができる。さらに、デバイスのセキュア実行環境に対して公開鍵証明書を発行すれば、セキュア実行環境によって私有鍵が安全に保護されるため、より安心してデータ共有を行うことができる。医療データの共有に限らず、様々なデータの共有基盤として活用が期待できる。

オンラインバンキングに対する攻撃手法としては、本物のサイトに似せて作成した偽物のサイトを用意し、そこに利用者を騙して誘導することで、利用者が入力したＩＤやパスワードを盗み取ってしまうフィッシング型の攻撃などが確認されている。こうした攻撃は、サーバ証明書やＯＴＰ（One Time Password）などの技術によって、ある程度防御可能である。しかし、最近では、サーバ証明書やＯＴＰなどを利用しても防ぐことが困難なＭｉｔＢ（Man-in-the-Browser）攻撃と呼ばれる新たな攻撃手法が確認されている（例えば、中山靖司「ネットバンキングのセキュリティ」6-16, 日本銀行金融機構局金融高度化センター ＩＴを活用した金融の高度化に関するワークショップ第２回「金融取引チャネルとセキュリティ」（2014/11/26）を参照）。ＭｉｔＢ攻撃では、利用者が本物のサイトに接続した際に、利用者のクライアントデバイスに感染したマルウェアによって偽物のログイン画面を表示させてＩＤやパスワードを盗み取ったり、利用者が入力した振込先口座番号などの取引情報を改竄して不正送金を行ったりなど、様々な不正が行われる。

入力された取引情報の改竄については、例えば、図３３に示すように、本実施形態によりクライアントデバイスのセキュア実行環境に公開鍵証明書を発行することで、防ぐことが可能である。この方法では、セキュア実行環境側のユーザインタフェースより入力させた取引情報に対して、セキュア実行環境の私有鍵によって電子署名を付与し、改竄することが困難な電子署名付き取引データを生成する。マルウェアはセキュア実行環境には侵入できないため、生成された電子署名付き取引データを改竄することは困難である。この電子署名付き取引データとクライアントデバイスの公開鍵証明書をバンキングサービスに送信する。バンキングサービスは、認証局の公開鍵を使ってクライアントデバイスの公開鍵証明書の有効性を検証することで、送信元のクライアントデバイスを確実に特定し、そのクライアントデバイスの公開鍵で電子署名を検証することで取引データの改竄の有無を確認することができる。この方法は、オンラインバンキングだけではなく、様々なサービスのトランザクション保護に役立てることができる。

ＳＳＨ（Secure Shell）は、リモートコンピュータと安全に通信するためのプロトコルとして広く利用されている。ＳＳＨを利用するためのオープンソースソフトウェアであるＯｐｅｎＳＳＨでは、接続先となるリモートコンピュータへのログイン認証の方式として、バージョン５．４から証明書認証（Certificate Authentication）に対応している。この証明書認証は、接続先のリモートコンピュータが認証局を信頼することで、その認証局によって発行された公開鍵証明書を持つ接続元のクライアントを認証する方式であり、ネットワーク上にパスワードが流れないためパスワード認証に比べて安全である（図３４の「（a）パスワード認証」と「（c）証明書認証」との比較）。また、事前にクライアントに公開鍵証明書が発行されているならば、証明書認証を行うための設定はリモートコンピュータに認証局の公開鍵を登録しておくだけでよく、公開鍵認証のようにクライアントが増減するたびに公開鍵の登録や削除を行う必要がないため、リモートコンピュータやクライアントが大量にある場合でも容易に運用することができる（図３４の「（b）公開鍵認証」と「（c）証明書認証」との比較）。なお、図３４は、リモートコンピュータによるクライアントの認証についてのみ記載しているが、実際には、クライアントによるリモートコンピュータの認証も行われる双方向認証が可能である。同種のプロトコルにＥＡＰ−ＴＬＳ（例えば、「The EAP-TLS Authentication Protocol」RFC 5216, IETF（2008/3）を参照）などがあり、公開鍵証明書の交換によって双方向認証を行う。

本実施形態によって公開鍵証明書の発行が自動化されることで、ＩｏＴなどのような大量のデバイスが扱われる状況においても、このような証明書認証を利用することにより、パスワードに頼らない強固な認証基盤を容易に構築・運用することができる。また、デバイスのセキュア実行環境に対して公開鍵証明書を発行すれば、セキュア実行環境によって私有鍵が安全に保護されるため、より強固な認証基盤を構築することも可能である。これらは、ＳＳＨによるリモートコンピュータへの接続に限らず、企業内ネットワークに接続するデバイスの認証や、公共サービスの電子申請を行う際にデバイスを認証するなど、幅広い用途に応用することができる。

以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。上述した各例を適宜組み合わせて実施することも、勿論可能である。

Claims (24)

1. 公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含むことを特徴とする公開鍵証明書申請プログラム。
2. 前記申請手続きが、
   公開鍵および該公開鍵の対となる私有鍵を生成する処理と、
   申請元の識別情報を取得する処理と、
   前記公開鍵および前記識別情報についての公開鍵証明書を申請する処理と
   を含むことを特徴とする請求項１に記載の公開鍵証明書申請プログラム。
3. 前記申請元の識別情報が、前記公開鍵証明書および前記私有鍵を利用するデバイスのハードウェアから取得される情報であることを特徴とする請求項２に記載の公開鍵証明書申請プログラム。
4. 前記申請元の識別情報が、前記公開鍵証明書および前記私有鍵を利用するユーザからの入力に基づいて取得される情報であることを特徴とする請求項２または３に記載の公開鍵証明書申請プログラム。
5. 前記公開鍵証明書申請プログラムが、
   前記公開鍵証明書の申請が前記申請手続きに従って行われたものであることを、前記認証局サービスが確認するために用いられる、正規手続き認証鍵をさらに含み、
   前記申請手続きが、
   前記公開鍵証明書の申請に前記正規手続き認証鍵による電子署名を付与する処理を含むことを特徴とする請求項１〜４のいずれか１項に記載の公開鍵証明書申請プログラム。
6. 前記正規手続き認証鍵が、共通鍵暗号方式の秘密鍵であることを特徴とする請求項５に記載の公開鍵証明書申請プログラム。
7. 前記正規手続き認証鍵が、公開鍵暗号方式の私有鍵であることを特徴とする請求項５に記載の公開鍵証明書申請プログラム。
8. 前記公開鍵証明書申請プログラムが、
   前記正規手続き認証鍵である私有鍵の対となる第二の公開鍵および該第二の公開鍵に前記認証局サービスが付与した第二の電子署名をさらに含み、
   前記申請手続きが、
   前記公開鍵証明書の申請に前記第二の公開鍵および前記第二の電子署名を含ませる処理をさらに含むことを特徴とする請求項７に記載の公開鍵証明書申請プログラム。
9. 前記正規手続き認証鍵が秘匿化されていることを特徴とする請求項５〜８のいずれか１項に記載の公開鍵証明書申請プログラム。
10. 前記申請手続きを実行するためのプログラムコードの少なくとも一部が秘匿化されていることを特徴とする請求項１〜９のいずれか１項に記載の公開鍵証明書申請プログラム。
11. 前記申請手続きが、前記プログラムコードが改竄されていないことを確認する処理を含むことを特徴とする請求項１〜１０のいずれか１項に記載の公開鍵証明書申請プログラム。
12. 前記公開鍵証明書申請プログラムが、セキュアな環境でなければ実行されないように、該環境に固有の鍵で暗号化されていることを特徴とする請求項１〜１１のいずれか１項に記載の公開鍵証明書申請プログラム。
13. 前記公開鍵証明書申請プログラムが、非セキュアな環境で実行されるものとして、難読化されていることを特徴とする請求項１〜１１のいずれか１項に記載の公開鍵証明書申請プログラム。
14. 前記申請手続きによる申請に基づいて前記認証局サービスにより発行される公開鍵証明書および前記申請手続きにより生成される該公開鍵の対となる私有鍵を管理するためのプログラムコードをさらに含むことを特徴とする請求項１〜１３のいずれか１項に記載の公開鍵証明書申請プログラム。
15. 前記申請手続きを実行するプログラムコードが複数あり、
    前記複数のプログラムコードのうち、要求される公開鍵証明書の種類に応じたプログラムコードを選択して、該プログラムコードによる申請手続きを実行するためのプログラムコードを含むことを特徴とする請求項１〜１４のいずれか１項に記載の公開鍵証明書申請プログラム。
16. 前記公開鍵証明書申請プログラムが、
    前記認証局サービスの公開鍵証明書をさらに含み、
    前記申請手続きが、
    前記認証局サービスの公開鍵証明書を用いて、前記公開鍵証明書申請プログラムの管理者もしくは発行者の確認、前記申請手続きにより提出される申請の暗号化、前記申請の後に受領される公開鍵証明書が前記認証局サービスにより発行されたことの確認のうち、少なくとも一つを行うことを特徴とする請求項１〜１５のいずれか１項に記載の公開鍵証明書申請プログラム。
17. 公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムを記憶するための手段と、
    前記公開鍵証明書申請プログラムを用いて前記申請手続きを実行するための手段と、
    前記申請手続きによる申請に基づいて前記認証局サービスにより発行される公開鍵証明書および前記申請手続きにより生成される該公開鍵の対となる私有鍵を管理するための手段とを備えることを特徴とするデバイス。
18. セキュアな実行環境を備え、
    少なくとも前記公開鍵証明書申請プログラムを用いて前記申請手続きを実行するための手段が、該セキュアな実行環境を利用することを特徴とする請求項１７に記載のデバイス。
19. 複数のデバイスを管理するサービスに前記デバイスの情報が登録されていない場合に、該情報を取得する処理を前記申請手続きに含む前記公開鍵証明書申請プログラムを受信する手段をさらに備えることを特徴とする請求項１７または１８に記載のデバイス。
20. 要求される種類の公開鍵証明書が前記管理の対象として存在しない場合に、該種類に対応する前記公開鍵証明書申請プログラムを外部から取得する手段をさらに備えることを特徴とする請求項１７または１８に記載のデバイス。
21. 公開鍵証明書の申請をデバイスから受信する手段を備える認証局サービスシステムであって、
    前記申請が前記認証局サービスシステムによって定められた申請手続きに従って行われたものであることを確認する手段と、
    前記確認の後に前記公開鍵証明書を発行する手段と、
    前記デバイスにおいて前記申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムが用いられることにより前記申請が行われるようにする手段とを備えることを特徴とする認証局サービスシステム。
22. 前記申請に含まれる前記デバイスに関する情報を、複数のデバイスを管理するサービスへ通知する手段をさらに備えることを特徴とする請求項２１に記載の認証局サービスシステム。
23. 公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムを記憶する手段と、
    前記公開鍵証明書申請プログラムの少なくとも一部を秘匿化する手段と、
    前記公開鍵証明書の申請を要するデバイスに対し、前記秘匿化を行った前記公開鍵証明書申請プログラムを、該デバイスに適合した構成で発行する手段とを備えることを特徴とするプログラム発行サービスシステム。
24. 公開鍵証明書を発行する認証局サービスによって定められた該公開鍵証明書の申請手続きを実行するためのプログラムコードを含む公開鍵証明書申請プログラムを、デバイスに配布し、
    前記公開鍵証明書申請プログラムを用いて行われた前記公開鍵証明書の申請を、前記デバイスから受信し、
    前記申請が前記認証局サービスシステムによって定められた申請手続きに従って行われたものであることを確認し、
    前記確認の後に前記公開鍵証明書を発行することを特徴とする公開鍵証明書発行方法。
    
    

Images