(57)【要約】      （修正有）【課題】正当なデバイスに対して正当なプロビジョニングデータを提供し、不正なデバイスが入り込むことを防ぐことのできる、プロビジョニングシステムを提供すること。【解決手段】デバイス４ａ１〜４ａ３、４ｂ１〜４ｂ３・・・のプロビジョニングを行うためのプロビジョニングデータを各デバイスへ提供する、デバイスプロビジョニングシステムであって、デバイスごとに一意である第１の公開鍵と第１の証跡とを紐づけて格納するブロックチェーン２より、第１の証跡を用いた問い合わせに応じて第１の公開鍵を取得する、公開鍵提供手段と、各デバイスからの第１の証跡を用いた問い合わせに応じて、公開鍵提供手段によって第１の公開鍵を取得し、当該第１の公開鍵によって暗号化したプロビジョニングデータをデバイスに送信する、プロビジョニングデータ提供手段と、を備えることを特徴とする。【選択図】図１
2019004391.tif 000002
【特許請求の範囲】
【請求項１】
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、デバイスプロビジョニングシステムであって、
前記デバイスごとに一意である第１の公開鍵と前記デバイスごとに一意である第１の証跡とを紐づけて格納するブロックチェーンより、前記第１の証跡を用いた問い合わせに応じて前記第１の公開鍵を取得する、公開鍵提供手段と、
前記デバイスからの前記第１の証跡を用いた問い合わせに応じて、前記公開鍵提供手段によって前記第１の公開鍵を取得し、当該第１の公開鍵によって暗号化した前記プロビジョニングデータを前記デバイスに送信する、プロビジョニングデータ提供手段と、を備え、
前記デバイスが、
前記第１の公開鍵に対応する第１の秘密鍵を格納するセキュア領域と、前記第１の証跡を格納する通常領域と、を含む記憶部と、
前記第１の証跡を用いた前記プロビジョニングデータ提供手段への問い合わせによって前記プロビジョニングデータを取得し、前記プロビジョニングデータを前記第１の秘密鍵を用いて復号する、プロビジョニング実行手段と、を備えることを特徴とする、デバイスプロビジョニングシステム。
【請求項２】
前記ブロックチェーンへの前記第１の公開鍵の登録による前記第１の証跡の取得を行う証跡登録手段を更に備え、
前記デバイスが、前記プロビジョニングデータの提供を受けていない初期状態において、
前記セキュア領域に前記デバイスごとに一意な初回用秘密鍵を、
前記通常領域に前記初回用秘密鍵に対応する初回用公開鍵を含むデバイス識別データを、それぞれ格納した状態であり、
前記プロビジョニングデータ提供手段が、前記デバイスより送信される前記デバイス識別データに基づいた当該デバイスの正当性の検証に成功した場合に、
前記第１の秘密鍵及び前記第１の公開鍵の生成と、
前記証跡登録手段による前記第１の公開鍵の前記ブロックチェーンへの登録による前記第１の証跡の取得と、
前記第１の秘密鍵と、前記第１の証跡と、を含み、前記初回用公開鍵によって暗号化された初回用データの当該デバイスへの送信と、を行い、
前記プロビジョニング実行手段が、前記初回用秘密鍵を用いた前記初回用データの復号と、前記第１の秘密鍵の前記セキュア領域への格納と、前記第１の証跡の前記通常領域への格納と、を行うことを特徴とする、請求項１に記載のデバイスプロビジョニングシステム。
【請求項３】
前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化を行う証跡無効化手段を更に備え、
新たな初回用秘密鍵と、前記新たな初回用秘密鍵に対応する新たな初回用公開鍵を含む新たなデバイス識別データと、を前記デバイスへと送信する、再初期化指示手段を更に備え、
前記デバイスが、前記新たな初回用秘密鍵の前記セキュア領域への格納と、前記第１の秘密鍵の前記セキュア領域からの抹消と、前記新たなデバイス識別データの前記通常領域への格納と、前記第１の証跡の前記通常領域からの抹消と、前記証跡無効化手段への前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化の依頼と、を行う、再初期化手段を更に備えることを特徴とする、請求項２に記載のデバイスプロビジョニングシステム。
【請求項４】
前記プロビジョニングデータ提供手段が、
前記ブロックチェーンに登録された前記第１の証跡及び前記第１の公開鍵の更新の要否の確認を行い、前記第１の証跡及び前記第１の公開鍵の更新が必要だと判定された場合に、
新たな第１の秘密鍵及び新たな第１の公開鍵の生成と、
前記証跡登録手段による前記ブロックチェーンへの前記新たな第１の公開鍵の登録による新たな第１の証跡の取得と、を行い、
前記プロビジョニングデータに、前記新たな第１の秘密鍵及び前記新たな第１の証跡を含め、
前記プロビジョニング実行手段が、
前記新たな第１の秘密鍵の前記セキュア領域への格納と、
前記新たな第１の証跡の前記通常領域への格納と、
前記第１の秘密鍵の前記セキュア領域からの抹消と、
前記第１の証跡の前記通常領域からの抹消と、を行うことを特徴とする、請求項３に記載のデバイスプロビジョニングシステム。
【請求項５】
前記プロビジョニングデータが、前記デバイス上で動作するプログラムファイルを含むことを特徴とする、請求項１から請求項４の何れかに記載のデバイスプロビジョニングシステム。
【請求項６】
前記プログラムファイルが前記デバイスの起動プログラムファイルであり、
プロビジョニング実行手段が、前記デバイスの起動時に前記プロビジョニングデータの取得を行うことを特徴とする、請求項５に記載のデバイスプロビジョニングシステム。
【請求項７】
前記ブロックチェーンが、更に、第２の証跡と第２の公開鍵を紐づけて記憶し、
前記プロビジョニングデータ提供手段が、前記プロビジョニングデータに前記第２の公開鍵に対応する第２の秘密鍵による電子署名を付した状態で前記暗号化を行い、
前記通常領域が、前記第２の証跡を更に格納し、
前記プロビジョニング実行手段が、前記公開鍵提供手段への前記第２の証跡を用いた問い合わせによる前記第２の公開鍵の取得と、前記第２の秘密鍵による電子署名の前記第２の公開鍵を用いた検証と、を行うことを特徴とする、請求項１から請求項６の何れかに記載のデバイスプロビジョニングシステム。
【請求項８】
前記公開鍵提供手段を有するデバイス認証サーバと、
前記プロビジョニングデータ提供手段を有するプロビジョニングサーバと、を備えることを特徴とする、請求項１から請求項７の何れかに記載のデバイスプロビジョニングシステム。
【請求項９】
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、プロビジョニング方法であって、
前記デバイスが、
前記デバイスごとに一意である第１の公開鍵に対応する、第１の秘密鍵を格納するセキュア領域と、
前記第１の公開鍵と紐づけられた状態でブロックチェーンに格納される、前記デバイスごとに一意である第１の証跡を格納する通常領域と、を含む記憶部を備えるものであって、
前記デバイスからの前記第１の証跡を用いた問い合わせに基づいて、前記ブロックチェーンより前記第１の公開鍵を取得するステップと、
前記第１の公開鍵によって前記プロビジョニングデータを暗号化し、前記デバイスに送信するステップと、
前記デバイスが、前記プロビジョニングデータを前記第１の秘密鍵を用いて復号するステップと、を備えることを特徴とする、プロビジョニング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスに対して適切なリソースの提供などを行う、デバイスプロビジョニングシステムに関する。
【背景技術】
【０００２】
現在では、携帯電話やスマートフォン、パーソナルコンピュータといった、ユーザが直接的に利用するデバイスや、センサによって取得した情報などを自動でサーバへと送信するようなＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）デバイスなど、様々なデバイスが普及している。
【０００３】
そして、上述したようなデバイスに対して、多くの場合には、ソフトウェアの更新プログラムが行われる。これは、古くは、物理メディアなどがデバイスのベンダからユーザへと配布され、各自が更新作業を行う、といったものであった。しかし、高速なインターネット網が普及した昨今においては、インターネットを経由してのダウンロードによって更新プログラムが配布され、それをユーザの操作によって、あるいは自動で、デバイスへと適用する、といった方式がとられることが多い。
【０００４】
また、デバイス上で使用するアプリケーションプログラムやオペレーティングシステム、ファームウェアなどのプログラムファイル、それらによって利用される設定ファイルといったようなリソースを、デバイスへと提供するような形態がとられることもある。このように、デバイスに対してリソースの提供を行い、所定の動作を行う準備を整える、といった処理を、プロビジョニングと呼称する。
【０００５】
例えば、特許文献１には、コンピュータなどのハードウェアプラットフォームのブート時にファームウェアの有効性を確認し、不足がある場合や破損している場合などに、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）ポートやＥｔｈｅｒｎｅｔ（登録商標）ポートといった外部インターフェースからファームウェアを取得する、プロビジョニング方法が記載されている。
【０００６】
また、ＩｏＴデバイスを利用したシステムにおいては、エッジコンピューティングという手法がしばしば用いられる。図３０に、従来のＩｏＴシステムの構成の一例を示す。これは、８ａ１、８ａ２、８ａ３、８ｂ１、８ｂ２、８ｂ３として示す複数のＩｏＴデバイス８によって取得したデータの、管理サーバ６による収集や解析などを行うものである。ここで、このようなシステムを構成する際に、ＩｏＴデバイス８と管理サーバ６との直接的な通信を行わず、それらの間に７ａ、７ｂとして示すようなエッジサーバ７を用意する構成を採用する場合がある。
【０００７】
これにより、個々のエッジサーバ７とそれによって管理されるＩｏＴデバイス８との間はＬＡＮａ、ＬＡＮｂとして示すようなＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等を介して接続され、エッジサーバ７と管理サーバ６との間はインターネットなどのＷＡＮを介して接続される、といったように、ネットワークが複数のセグメントに分割される構成となる。
【０００８】
エッジサーバ７を用いず、ＩｏＴデバイス８をＷＡＮに直接接続する場合、セキュリティ面のリスクが高まり、個々のＩｏＴデバイス８における対応を行う必要が生じてしまう。例えば、ＳＳＬ（Ｓｅｃｕｒｉｔｙ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）を利用したセキュアな通信を行うことや、それに使用するための個々のＩｏＴデバイス８についての電子証明書の発行などが挙げられる。これには、通信の暗号化などのためのＩｏＴデバイス８における処理コストの増加や、電子証明書の発行、管理に係る運用コストの増大などの問題がある。
【０００９】
こういった点から、図３０に示すような、エッジサーバ７と個々のＩｏＴデバイス８とをＷＡＮと比較してセキュリティリスクの低いＬＡＮによって接続し、ＩｏＴデバイス８よりも処理コストに余裕のあるエッジサーバ７のみをＷＡＮへと接続する、といった構成がとられる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特表２０１７−５１１５３０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上述したように様々なデバイスが使用される中で、デバイスが、それを正しく管理する者が不在な状況での使用や、何らかの事情で管理対象から外れてしまうことにより、セキュリティ面での問題などが生じる事態が発生している。特に、ＩｏＴデバイスに関しては、このように正しい管理が行われなくなった、いわゆる野良ＩｏＴデバイスによるセキュリティリスクが高く、気づかないうちに攻撃の踏み台に利用されていた、といったケースも実際に発生している。
【００１２】
特許文献１に記載されるような方法によれば、コンピュータなどの起動時に必要に応じてファームウェアを外部インターフェースから取得することにより、コンピュータが不正な動作をすることを防ぐことができる。しかし、特にＩｏＴデバイスのように、様々な場所で使用されるようなデバイスにおいて使用することを考えると、上述した野良ＩｏＴデバイスのような不正なデバイスがシステムに入り込むのを防ぐ、といった向きでは、デバイスの正当性を十分に確保し、管理できるとは言えない。
【００１３】
また、図３０を参照して説明したようなエッジサーバ７を介して個々のＩｏＴデバイス８からのデータの収集などを行う構成においては、個々のＩｏＴデバイス８がＬＡＮなどのプライベートネットワークにのみ接続されるため、これらの管理をＷＡＮなどのグローバルネットワークをまたいで統合的に行うことが難しいという問題があった。
【００１４】
そこで、本発明では、正当なデバイスに対して正当なプロビジョニングデータを提供し、不正なデバイスが入り込むことを防ぐことのできる、デバイスプロビジョニングシステムを提供することを課題とする。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、本発明に係るデバイスプロビジョニングシステムは、
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、デバイスプロビジョニングシステムであって、
前記デバイスごとに一意である第１の公開鍵と前記デバイスごとに一意である第１の証跡とを紐づけて格納するブロックチェーンより、前記第１の証跡を用いた問い合わせに応じて前記第１の公開鍵を取得する、公開鍵提供手段と、
前記デバイスからの前記第１の証跡を用いた問い合わせに応じて、前記公開鍵提供手段によって前記第１の公開鍵を取得し、当該第１の公開鍵によって暗号化した前記プロビジョニングデータを前記デバイスに送信する、プロビジョニングデータ提供手段と、を備え、
前記デバイスが、
前記第１の公開鍵に対応する第１の秘密鍵を格納するセキュア領域と、前記第１の証跡を格納する通常領域と、を含む記憶部と、
前記第１の証跡を用いた前記プロビジョニングデータ提供手段への問い合わせによって前記プロビジョニングデータを取得し、前記プロビジョニングデータを前記第１の秘密鍵を用いて復号する、プロビジョニング実行手段と、を備えることを特徴とする。
【００１６】
このように、デバイスごとに一意な秘密鍵、公開鍵のペアを用いてプロビジョニングデータの提供を行うことにより、プロビジョニングデータが第三者に不正に取得されるような可能性を排除し、高いセキュリティを保ってデバイスのプロビジョニングを行うことができる。そして、公開鍵をブロックチェーンへ格納し、それをもって正当性の担保を行うことによって、それぞれのデバイスごとに電子証明書を用意するような費用や手間をかけずとも、デバイスごとの公開鍵の正当性を担保することができる。ここで、デバイスごとに一意な公開鍵をブロックチェーンへ格納しておくことは、すなわち、ブロックチェーンへの登録状況によってデバイスを管理することとなり、管理外の不正なデバイスのシステムへの混入を防ぐことができる。また、対象とするデバイス以外ではプロビジョニングデータの展開ができないという特性から、デバイスとの間の通信経路の暗号化などを簡略化、あるいは省略することができるため、処理能力の比較的低いデバイスを用いる場合においても、プロビジョニングデータの提供をセキュアに行うことができる。
【００１７】
本発明の好ましい形態では、デバイスプロビジョニングシステムが、前記ブロックチェーンへの前記第１の公開鍵の登録による前記第１の証跡の取得を行う証跡登録手段を更に備え、
前記デバイスが、前記プロビジョニングデータの提供を受けていない初期状態において、
前記セキュア領域に前記デバイスごとに一意な初回用秘密鍵を、
前記通常領域に前記初回用秘密鍵に対応する初回用公開鍵を含むデバイス識別データを、それぞれ格納した状態であり、
前記プロビジョニングデータ提供手段が、前記デバイスより送信される前記デバイス識別データに基づいた当該デバイスの正当性の検証に成功した場合に、
前記第１の秘密鍵及び前記第１の公開鍵の生成と、
前記証跡登録手段による前記第１の公開鍵の前記ブロックチェーンへの登録による前記第１の証跡の取得と、
前記第１の秘密鍵と、前記第１の証跡と、を含み、前記初回用公開鍵によって暗号化された初回用データの当該デバイスへの送信と、を行い、
前記プロビジョニング実行手段が、前記初回用秘密鍵を用いた前記初回用データの復号と、前記第１の秘密鍵の前記セキュア領域への格納と、前記第１の証跡の前記通常領域への格納と、を行うことを特徴とする。
このように、デバイス識別データの正当性の検証に基づいて、初期状態であるデバイスに対してプロビジョニングデータの提供を行うことにより、システムへのデバイスの登録を安全に行うことができる。
【００１８】
本発明の好ましい形態では、デバイスプロビジョニングシステムが、前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化を行う証跡無効化手段を更に備え、
新たな初回用秘密鍵と、前記新たな初回用秘密鍵に対応する新たな初回用公開鍵を含む新たなデバイス識別データと、を前記デバイスへと送信する、再初期化指示手段を更に備え、
前記デバイスが、前記新たな初回用秘密鍵の前記セキュア領域への格納と、前記第１の秘密鍵の前記セキュア領域からの抹消と、前記新たなデバイス識別データの前記通常領域への格納と、前記第１の証跡の前記通常領域からの抹消と、前記証跡無効化手段への前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化の依頼と、を行う、再初期化手段を更に備えることを特徴とする。
このように、ブロックチェーン上での証跡、公開鍵の無効化と、デバイス上からのデータの削除などを行うことにより、システムにおけるデバイスの無効化を確実なものとし、また、デバイスを初期状態へと戻すことができる。
【００１９】
本発明の好ましい形態では、前記プロビジョニングデータ提供手段が、
前記ブロックチェーンに登録された前記第１の証跡及び前記第１の公開鍵の更新の要否の確認を行い、前記第１の証跡及び前記第１の公開鍵の更新が必要だと判定された場合に、
新たな第１の秘密鍵及び新たな第１の公開鍵の生成と、
前記証跡登録手段による前記ブロックチェーンへの前記新たな第１の公開鍵の登録による新たな第１の証跡の取得と、を行い、
前記プロビジョニングデータに、前記新たな第１の秘密鍵及び前記新たな第１の証跡を含め、
前記プロビジョニング実行手段が、
前記新たな第１の秘密鍵の前記セキュア領域への格納と、
前記新たな第１の証跡の前記通常領域への格納と、
前記第１の秘密鍵の前記セキュア領域からの抹消と、
前記第１の証跡の前記通常領域からの抹消と、を行うことを特徴とする。
このように、必要に応じてデバイスごとに一意な鍵を再生成し、ブロックチェーンに格納するデータと、デバイスに格納するデータとの更新を行うことで、プロビジョニングに使用するデバイスごとの鍵の更新を行い、システムをセキュアな状態に保つことができる。
【００２０】
本発明の好ましい形態では、前記プロビジョニングデータが、前記デバイス上で動作するプログラムファイルを含むことを特徴とする。
このように、プロビジョニングデータにプログラムファイルを含めることによって、デバイスに対して期待する動作をさせることが可能となる。
【００２１】
本発明の好ましい形態では、前記プログラムファイルが前記デバイスの起動プログラムファイルであり、
プロビジョニング実行手段が、前記デバイスの起動時に前記プロビジョニングデータの取得を行うことを特徴とする。
このように、デバイスの起動時に起動プログラムファイルの配布を行うことによって、デバイスを正常な状態で起動することができる。
【００２２】
本発明の好ましい形態では、前記ブロックチェーンが、更に、第２の証跡と第２の公開鍵を紐づけて記憶し、
前記プロビジョニングデータ提供手段が、前記プロビジョニングデータに前記第２の公開鍵に対応する第２の秘密鍵による電子署名を付した状態で前記暗号化を行い、
前記通常領域が、前記第２の証跡を更に格納し、
前記プロビジョニング実行手段が、前記公開鍵提供手段への前記第２の証跡を用いた問い合わせによる前記第２の公開鍵の取得と、前記第２の秘密鍵による電子署名の前記第２の公開鍵を用いた検証と、を行うことを特徴とする。
このように、電子署名によってプロビジョニングデータの正当性の担保を行うことにより、デバイスに対する不正なプロビジョニングデータの提供を防ぐことができる。
【００２３】
本発明の好ましい形態では、デバイスプロビジョニングシステムが、前記公開鍵提供手段を有するデバイス認証サーバと、
前記プロビジョニングデータ提供手段を有するプロビジョニングサーバと、を備えることを特徴とする。
このように、デバイス認証サーバと、プロビジョニングサーバとを備える構成とすることによって、プロビジョニングの対象とするデバイスごとや、デバイスを製造するベンダごとといった態様でプロビジョニングサーバを用意し、様々なデバイスのプロビジョニング処理を行うことができる。
【００２４】
本発明に係るプロビジョニング方法は、
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、プロビジョニング方法であって、
前記デバイスが、
前記デバイスごとに一意である第１の公開鍵に対応する、第１の秘密鍵を格納するセキュア領域と、
前記第１の公開鍵と紐づけられた状態でブロックチェーンに格納される、前記デバイスごとに一意である第１の証跡を格納する通常領域と、を含む記憶部を備えるものであって、
前記デバイスからの前記第１の証跡を用いた問い合わせに基づいて、前記ブロックチェーンより前記第１の公開鍵を取得するステップと、
前記第１の公開鍵によって前記プロビジョニングデータを暗号化し、前記デバイスに送信するステップと、
前記デバイスが、前記プロビジョニングデータを前記第１の秘密鍵を用いて復号するステップと、を備えることを特徴とする。
【発明の効果】
【００２５】
プロビジョニングデータが第三者に不正に取得されるような可能性を排除し、高いセキュリティを保ってデバイスのプロビジョニングを行うことができ、また、デバイスごとに一意な公開鍵をブロックチェーンへ格納し、デバイスを管理することで、管理外の不正なデバイスのシステムへの混入を防ぐことができる、デバイスプロビジョニングシステムを提供することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態に係るデバイスプロビジョニングシステムの構成図である。
【図２】本発明の一実施形態に係るデバイスの生産拠点のシステム構成図である。
【図３】本発明の一実施形態に係るデバイスの機能ブロック図である。
【図４】本発明の一実施形態に係るプロビジョニングサーバの機能ブロック図である。
【図５】本発明の一実施形態に係る生産拠点システムの機能ブロック図である。
【図６】本発明の一実施形態に係るデバイス認証サーバの機能ブロック図である。
【図７】本発明の一実施形態における初期状態のデバイスの記憶部のデータ構造を示す図である。
【図８】本発明の一実施形態におけるプロビジョニング後のデバイスの記憶部のデータ構造を示す図である。
【図９】本発明の一実施形態において製造時にデバイスに書き込まれるデータの構造を示す図である。
【図１０】本発明の一実施形態に係る初期プロビジョニングデータの構造を示す図である。
【図１１】本発明の一実施形態に係るプロビジョニングデータの例を示す図である。
【図１２】本発明の一実施形態におけるデバイス製造時の処理の流れを示すフローチャートである。
【図１３】本発明の一実施形態におけるデバイス起動時の処理の流れを示すフローチャートである。
【図１４】本発明の一実施形態における初期プロビジョニング処理の流れを示すフローチャートである。
【図１５】本発明の一実施形態における初期プロビジョニングデータの生成処理の流れを示すフローチャートである。
【図１６】本発明の一実施形態における証跡の登録処理の流れを示すフローチャートである。
【図１７】本発明の一実施形態における初期プロビジョニングデータの展開処理の流れを示すフローチャートである。
【図１８】本発明の一実施形態における電子署名の検証処理の流れを示すフローチャートである。
【図１９】本発明の一実施形態におけるプロビジョニング処理の流れを示すフローチャートである。
【図２０】本発明の一実施形態におけるプロビジョニングデータの生成処理の流れを示すフローチャートである。
【図２１】本発明の一実施形態におけるプロビジョニングデータの展開処理の流れを示すフローチャートである。
【図２２】本発明の一実施形態における証跡の無効化処理の流れを示すフローチャートである。
【図２３】本発明の一実施形態においてデバイスの再初期化に使用するデータの構造を示す図である。
【図２４】本発明の一実施形態におけるデバイスの再初期化処理の流れを示すフローチャートである。
【図２５】本発明の一実施形態におけるアクティベート秘密鍵の格納処理の流れを示すフローチャートである。
【図２６】本発明の一実施形態における指示データの構造を示す図である。
【図２７】本発明の一実施形態におけるプロビジョニングサーバからの指示に基づいたプロビジョニング処理の流れを示すフローチャートである。
【図２８】本発明の一実施形態におけるデバイスからの指示に基づいたプロビジョニング処理の流れを示すフローチャートである。
【図２９】本実施形態に係るデバイスの論理的な構成の概略を示す図である。
【図３０】従来のＩｏＴシステムの構成の一例を示す図である。
【発明を実施するための形態】
【００２７】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。図１は、本実施形態に係るデバイスプロビジョニングシステムの構成を示す図である。ここに示すように、本実施形態に係るデバイスプロビジョニングシステムは、デバイス認証サーバ１と、ブロックチェーン２と、３ａ、３ｂを含むプロビジョニングサーバ３（以下、特に区別の必要がない場合、単にプロビジョニングサーバ３と呼称する）と、４ａ１、４ａ２、４ａ３、４ｂ１、４ｂ２、４ｂ３を含むデバイス４（以下、特に区別の必要がない場合、単にデバイス４と呼称する）を備えるものである。
【００２８】
デバイス認証サーバ１は、ブロックチェーン２、プロビジョニングサーバ３とインターネットなどのネットワークＮＷを介して通信可能に構成される。また、プロビジョニングサーバ３ａはデバイス４ａ１、４ａ２、４ａ３とネットワークＮＷａを介して、プロビジョニングサーバ３ｂはデバイス４ｂ１、４ｂ２、４ｂ３とネットワークＮＷを介して、それぞれ通信可能に構成される。ここでのネットワークＮＷａとしては、例えば、インターネットから独立したＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）や、ＺｉｇＢｅｅ（登録商標）のような、近距離無線通信規格によって構成されるネットワークなどを採用することができる。また、デバイス４ｂ１、４ｂ２、４ｂ３のネットワークＮＷへの接続については、３Ｇや４Ｇといったような移動体通信網を介し、行われるような構成とすることができる。
【００２９】
ここで、プロビジョニングサーバ３ａ、デバイス４ａ１、４ａ２、４ａ３を囲む枠組みは、これらの装置を特定の企業や団体などの組織（ここでは、「エンタープライズ」と呼称する）が管理する領域を示すものである。プロビジョニングサーバ３ｂ、デバイス４ｂ１、４ｂ２、４ｂ３についても同様であり、また、図示しない他のプロビジョニングサーバ３やデバイス４を管理する他のエンタープライズが更に存在するような構成としてよい。このように、エンタープライズごとにプロビジョニングサーバ３、デバイス４を設けるような構成とすることにより、各エンタープライズの業務内容などに特化したデバイス４を、本実施形態に係るデバイスプロビジョニングシステムの管理下に置くことができる。
【００３０】
なお、ブロックチェーン２は元来、仮想通貨であるビットコインにおいて分散型台帳として利用されるものであり、多数のノードによって構成されるものであるが、ここでは説明の簡単のために、図１に示すように、単一の構成要素として示す。
【００３１】
ブロックチェーン２は、ブロックと呼ばれるデータの連鎖によって構成されるものであり、各ブロックはその前のブロックのハッシュ値の情報を含むものであるため、何れかのブロックの改ざんが行われた場合には、連鎖関係に不整合が生じる。また、多数のノードによって構成される分散型のシステムであることからも、単一のノードの操作などによって、そのような不正な改ざん処理や、ブロックの削除などを行うことができないという特性を有する。なお、本明細書においては、デバイス４に関する情報やデバイス４ごとに一意な公開鍵（デバイス公開鍵）などのデータの登録によって生成されたブロックを、証跡と呼称する。
【００３２】
なお、ここでの公開鍵とは、秘密鍵とペアで公開鍵暗号方式に用いられるものである。これは、秘密鍵によって暗号化されたデータは対応する公開鍵によってのみ復号することができ、逆に公開鍵によって暗号化されたデータは対応する秘密鍵によってのみ復号することができる、というものである。
【００３３】
本実施形態に係るデバイスプロビジョニングシステムにおいては、大別すると３種類の秘密鍵、公開鍵、及び公開鍵のブロックチェーン２上への登録によって得られる証跡の組を利用する。１つ目は、上述したデバイス公開鍵とそれに対応するデバイス秘密鍵、及びデバイス公開鍵のブロックチェーン２への登録によって得られるデバイス証跡であり、これらは、各々のデバイス４に対して一意なものである。２つ目は、デバイス４の開発チームや開発プロジェクトといった単位ごとに一意に用意される、開発秘密鍵、開発公開鍵、開発証跡である。これはすなわち、デバイス４の製品種別ごと、といった単位で一意になるものである。そして、３つ目は、デバイス４の製造を行うベンダなどの組織ごとに一意に用意される、組織秘密鍵、組織公開鍵、組織証跡である。このように、同一の組織に属する開発チームや開発プロジェクトにおいて同一の組織秘密鍵、組織公開鍵、組織証跡を、同一の開発チームや開発プロジェクトに属するデバイス４において同一の開発秘密鍵、開発公開鍵、開発証跡を、そして、デバイス秘密鍵、デバイス公開鍵、デバイス証跡については、デバイス４ごとに一意なものをそれぞれ利用する、といったように、これらの鍵や証跡には、上下関係があるものといえる。
【００３４】
なお、本実施形態においては、後述する各処理において必要となるため、上述したような組織ごと、開発チームや開発プロジェクトごと、デバイス４ごとの、３階層の秘密鍵、公開鍵、証跡を用いる構成を示したが、本発明はこれに限るものではない。必要に応じて、より多くの、あるいは少ない種別の秘密鍵、公開鍵、証跡を用いるような構成としてもよい。また、例えば、同一の開発チームや開発プロジェクトによって扱われる同一の製品種別であるデバイス４に対して、使用される地域ごとに異なる開発秘密鍵、開発公開鍵、開発証跡を用いるといったように、本実施形態において例示する３階層の秘密鍵、公開鍵、証跡を用いながら、より詳細に使い分けることで、セキュリティを高めるような構成としてもよい。
【００３５】
また、本実施形態においては、組織公開鍵のブロックチェーン２への登録による組織証跡の取得、開発公開鍵のブロックチェーン２への登録による開発証跡の取得については、予め完了しているものとする。これには、プロビジョニングサーバ３、あるいは図示しない他のコンピュータ装置の操作などに基づいて、予め、ブロックチェーン２へのそれぞれの公開鍵の登録による証跡の取得を行っておけばよい。
【００３６】
そして、組織秘密鍵、組織証跡、開発秘密鍵、開発証跡は、任意の方法により、予め必要な個所に配備されるものである。それぞれの使用については後述する各処理の説明において詳細に述べるが、プロビジョニングサーバ３には組織証跡、組織秘密鍵、開発証跡、開発秘密鍵が、生産拠点システム５には、組織秘密鍵が、それぞれ配備される。そして、各処理において必要となる公開鍵の取得は、後述するような、証跡を用いたデバイス認証サーバ１への問い合わせによって行われる。ただし、生産拠点システム５については、ネットワークＮＷと隔絶された環境とするために、開発公開鍵についても予め生産拠点システム５に配備されることが好ましい。なお、それぞれの秘密鍵、証跡の配備はそれらを管理する組織、開発チームや開発プロジェクトの管理者等により、任意の方法によって配備されればよいが、特に、秘密鍵の配備に際しては、流出等のリスクを考慮し、物理記憶媒体による移動などのセキュアな手段によって行われる必要がある。また、それぞれの証跡や秘密鍵、公開鍵については、それらを管理する組織や開発チーム等により、定期的な更新等、適切な管理が行われることが好ましい。
【００３７】
また、更に、デバイス認証サーバ１が使用する秘密鍵、公開鍵を別途用意し、上述したような証跡の配布に際して、この秘密鍵による電子署名を付与する、あるいは証跡に含めるような構成としてもよい。このような構成とすれば、証跡を用いた公開鍵の取得要求をデバイス認証サーバ１が受信した際に、その証跡が自身で発行した正規のものであるか、公開鍵を用いた電子署名の検証によって確認することができる。
【００３８】
本実施形態に係るプロビジョニングシステムにおいては、デバイス４のプロビジョニングなどの処理に際して使用する公開鍵の信頼性の担保を、ブロックチェーン２を利用して行うものである。これはすなわち、上述したような、不正な改ざん処理や、ブロックの削除などを行うことができないというブロックチェーン２の特性を利用し、後述するようなデバイス認証サーバ１による正当な処理によってのみブロックチェーン２上への公開鍵の登録、証跡の生成を可能とすることにより、ブロックチェーン２上に有効な状態で存在する公開鍵が、不正な改ざん処理などを受けていない正当なものであるということを担保することができる、というものである。
【００３９】
なお、本実施形態においては、ブロックチェーン２上に公開鍵等を登録し、証跡を得る構成を示したが、本発明はこれに限るものではない。例えば、ブロックチェーン２上への、デバイスに関する情報や開発チームに関する情報、組織に関する情報といったような情報の登録によって証跡の取得を行い、公開鍵自体については、別途セキュアに管理されるデータベースなどを用意し、証跡と紐づけて管理する、といった構成としてもよい。
【００４０】
図２は、各エンタープライズのデバイス４の生産拠点のシステム構成を示す図である。図２（ａ）は、デバイス４ａ１、４ａ２、４ａ３の管理を行うエンタープライズの生産拠点を示すものであり、ここでは、生産拠点システム５ａによってデバイス４ａ１、４ａ２、４ａ３へとデータの書き込みなどが行われる。また、図２（ｂ）は、デバイス４ｂ１、４ｂ２、４ｂ３の管理を行うエンタープライズの生産拠点を示すものであり、ここでは、生産拠点システム５ｂとデバイス４ｂ１、４ｂ２、４ｂ３が、生産拠点内におけるＬＡＮなどのネットワークＮＷｂを介して接続され、データの書き込みなどが行われる。各エンタープライズの生産拠点内におけるシステム構成は、後に詳細に説明するような、生産拠点システム５によるデバイス４への必要なデータの書き込みが可能であれば、任意のものであってよい。
【００４１】
＜各部の構成＞
図３は、デバイス４の機能ブロック図である。ここに示すように、デバイス４は、自身が初期状態であるか否かを判定する初期プロビジョニング確認手段４１と、プロビジョニングサーバ３からのプロビジョニングデータの取得や、取得したプロビジョニングデータの展開などを行うプロビジョニング実行手段４２と、デバイス４の起動時における種々の処理を行うシステム起動手段４３と、自身を初期状態へと戻すために再初期化処理を行う再初期化手段４４と、記憶部４５と、を備える。
【００４２】
ここで、記憶部４５は、セキュア領域４５ａと通常領域４５ｂとを含むものである。セキュア領域４５ａは、通常領域４５ｂとは扱いが異なる領域であり、初期プロビジョニング確認手段４１やプロビジョニング実行手段４２などによってのみアクセスが可能なものである。
【００４３】
デバイス４としては、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算装置、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）などの主記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）、フラッシュメモリなどの補助記憶装置、ネットワークへの接続手段を含む種々の入出力装置等を備えた、一般的なコンピュータ装置を利用することができる。なお、演算装置や主記憶装置、補助記憶装置などを単一のチップとして実装した、ＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）を備えるような構成であってもよい。より詳細には、製造時などに、補助記憶装置に上述したような各手段としてデバイス４を動作させるためのプログラムを格納しておき、それらのプログラムを主記憶装置上に展開して演算装置による演算を行い、入出力手段の制御などを行うことで、コンピュータ装置を本実施形態に係るデバイスプロビジョニングシステムにおけるデバイス４として利用することができる。このようなコンピュータ装置として、例えば、監視カメラや車載機器のような、いわゆるＩｏＴデバイスなどであってもよいし、パーソナルコンピュータやスマートフォンなどのような端末であってもよい。
【００４４】
なお、セキュア領域４５ａは、例えば、ＴＰＭ（Ｔｒａｓｔｅｄ  Ｐｌａｔｆｏｒｍ  Ｍｏｄｕｌｅ）のような、専用のハードウェアを利用するような構成であってもよいし、補助記憶装置上の一部の領域を物理的に、あるいは論理的に切り離し、それを利用するような構成であってもよい。すなわち、上述したように、初期プロビジョニング確認手段４１やプロビジョニング実行手段４２などによってのみアクセスが可能な構成とすることができればよい。また、セキュア領域４５ａに対する読み出しや書き込みなどのアクセスに際しては、常にログが取得され、管理されるような構成とすることが好ましい。
【００４５】
図２９は、デバイス４の論理的な構成の概略を示す図である。ここに示すように、デバイス４では、ＣＰＵやＲＡＭなどのハードウェア資源を利用して、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）が動作する。そして、ＯＳ上で、設定情報やアプリケーションデータを利用するアプリケーションプログラムが動作する。ここで、初期プロビジョニング確認手段４１、プロビジョニング実行手段４２、再初期化手段４４等を含むプロビジョニング処理部は、ＯＳを介さずにハードウェア資源を利用して、独立した動作を行えるよう構成されるものである。プロビジョニング処理部は、プロビジョニング対象として図中に破線で示す、ＯＳやアプリケーションプログラム、設定情報などを含むプロビジョニングデータをプロビジョニングサーバ３より受信し、展開する。なお、ここで、プロビジョニング処理部自体を破線の内側に示している通り、プロビジョニング処理部自体についてもプロビジョニング処理の対象とするような構成としてよい。
【００４６】
また、デバイス４上では、例えば、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）、組み込み機器に利用されるようなＲＴＯＳなど、任意のＯＳが動作する。このようなＯＳは、予めデバイス４の補助記憶装置上に配されるような構成としてもよいし、後述するようなデバイス４のプロビジョニング処理において、起動プログラムとしてプロビジョニングサーバ３からの提供を受けるような構成としてもよい。
【００４７】
図４は、プロビジョニングサーバ３の機能ブロック図である。ここに示すように、プロビジョニングサーバ３は、プロビジョニングデータの生成やデバイス４への提供などを行うプロビジョニングデータ提供手段３１と、デバイス４の再初期化処理を行うためのライブラリであるデバイス初期化ライブラリ３２と、デバイス４の起動時に実行されるプログラムである起動プログラムを記憶する起動プログラム記憶部３３と、エンタープライズによって管理されるデバイス４についての情報を記憶するデバイス情報記憶部３４と、を備える。デバイス初期化ライブラリ３２は、デバイス４の再初期化処理に際して、後述するデバイス識別データの提供を行うデバイス識別データ提供手段３２ａと、同じく後述するアクティベート鍵の提供を行うアクティベート鍵提供手段３２ｂと、を有する。
【００４８】
なお、ここでの起動プログラムとは、図２９中にプロビジョニング対象として示したように、デバイス４上で稼働するＯＳそのものを含むようなプログラムファイルであってもよいし、ＯＳ上で稼働するアプリケーションプログラムやその設定情報などのリソースを含むものであってもよい。また、デバイス４の補助記憶装置上に予め格納されるＯＳを呼び出すためのプログラムなどであってもよい。
【００４９】
プロビジョニングサーバ３としては、ＣＰＵなどの演算装置、ＲＡＭなどの主記憶装置、ＨＤＤやＳＳＤ、フラッシュメモリなどの補助記憶装置、ネットワークＮＷへの接続手段を含む種々の入出力装置等を備えた、一般的なコンピュータ装置を利用することができる。より詳細には、補助記憶装置に予め、あるいはプロビジョニングサーバ３の管理者の操作などによって、上述したような各手段としてプロビジョニングサーバ３を動作させるためのプログラムを格納しておき、それらのプログラムを主記憶装置上に展開して演算装置による演算を行い、入出力手段の制御などを行うことで、コンピュータ装置を本実施形態に係るデバイスプロビジョニングシステムにおけるプロビジョニングサーバ３として利用することができる。なお、本実施形態においては、単一のコンピュータ装置によってプロビジョニングサーバ３を実現する構成を示したが、本発明はこれに限るものではない。例えば、各記憶部を別のコンピュータ装置に備えるような構成など、複数のコンピュータ装置によってプロビジョニングサーバ３を実現するような構成としてもよい。
【００５０】
図５は、生産拠点システム５の機能ブロック図である。ここに示すように、生産拠点システム５は、デバイス４の製造時における初期化処理を行うためのライブラリであるデバイス初期化ライブラリ５１と、生産拠点において初期化処理を行ったデバイス４に関する情報を記憶するデバイス情報記憶部５２と、を備える。デバイス初期化ライブラリ５１は、デバイス４の初期化処理に際してデバイス識別データの提供を行うデバイス識別データ提供手段５１ａと、アクティベート鍵の提供を行うアクティベート鍵提供手段５１ｂと、を有する。なお、生産拠点システム５の備えるデバイス初期化ライブラリ５１は、プロビジョニングサーバ３の備えるデバイス初期化ライブラリ３２と同様のものでよい。
【００５１】
生産拠点システム５は、デバイス４の製造設備により実現することができる。これは例えば、デバイス４へのデータの書き込みなどを行う専用の装置などにデバイス初期化ライブラリ５１やデバイス情報記憶部５２を付加する構成としてもよいし、上述したような専用の装置を介して、あるいは、直接的にデバイス４へのデータの書き込みを行うための、デバイス初期化ライブラリ５１やデバイス情報記憶部５２を備えるコンピュータ装置を設けるような構成としてもよい。
【００５２】
図６は、デバイス認証サーバ１の機能ブロック図である。ここに示すように、デバイス認証サーバ１は、ブロックチェーン２への証跡の登録を行う証跡登録手段１１と、ブロックチェーン２上の証跡の無効化を行う証跡無効化手段１２と、ブロックチェーン２上の公開鍵のプロビジョニングサーバ３などへの提供を行う公開鍵提供手段１３と、を備える。
【００５３】
デバイス認証サーバ１としても、ＣＰＵなどの演算装置、ＲＡＭなどの主記憶装置、ＨＤＤやＳＳＤ、フラッシュメモリなどの補助記憶装置、ネットワークＮＷへの接続手段を含む種々の入出力装置等を備えた、一般的なコンピュータ装置を利用することができる。より詳細には、補助記憶装置に予め、あるいはデバイス認証サーバ１の管理者の操作などによって、上述したような各手段としてデバイス認証サーバ１を動作させるためのプログラムを格納しておき、それらのプログラムを主記憶装置上に展開して演算装置による演算を行い、入出力手段の制御などを行うことで、コンピュータ装置を本実施形態に係るデバイスプロビジョニングシステムにおけるデバイス認証サーバ１として利用することができる。なお、本実施形態においては、単一のコンピュータ装置によってデバイス認証サーバ１を実現する構成を示したが、本発明はこれに限るものではない。例えば、各記憶部を別のコンピュータ装置に備えるような構成など、複数のコンピュータ装置によってデバイス認証サーバ１を実現するような構成としてもよい。あるいは、プロビジョニングサーバ３の備える手段や記憶部をデバイス認証サーバ１が備えるような構成として、プロビジョニングサーバ３とデバイス認証サーバ１とを単一のコンピュータ装置としてもよい。
【００５４】
＜デバイス製造時の処理＞
図１２は、生産拠点システム５による、デバイス４の製造時の初期化処理の流れを示すフローチャートである。初期化処理においては、まず、ステップＳ１０１において、開発公開鍵の取得処理が行われる。ここで、開発公開鍵は、上述したように、任意の方法による生産拠点システム５への配備が予めなされているものである。
【００５５】
続くステップＳ１０２では、アクティベート鍵提供手段５１ｂによるアクティベート鍵ペアの生成処理を行う。ここでのアクティベート鍵ペアとは、後述するデバイス４の初期プロビジョニング処理において利用するアクティベート秘密鍵とそれに対応するアクティベート公開鍵のペアであり、これはデバイス４ごとに一意となるよう生成される。
【００５６】
ステップＳ１０３では、初期プロビジョニング処理においてデバイス４を識別するためのデバイス識別データの生成を行う。これは、ステップＳ１０２において生成したアクティベート公開鍵に対し、組織秘密鍵による電子署名を付与し、それらを開発公開鍵によって暗号化したものである。ここで、組織秘密鍵は、上述したように、任意の方法による生産拠点システム５への配備が予めなされているものである。
【００５７】
ステップＳ１０４では、ステップＳ１０２で生成したアクティベート秘密鍵と、ステップＳ１０３で生成したデバイス識別データのデバイス４への書き込みを行う。ここで書き込むデータを、製造時書き込みデータＤＭとして図９に示す。これは、先に説明したように、アクティベート公開鍵ＵＡに組織秘密鍵による電子署名ＳＯを付与し、それを開発公開鍵によって暗号化したデバイス識別データＩＤと、アクティベート秘密鍵ＲＡを含むものである。この内、デバイス識別データＩＤを記憶部４５の備える通常領域４５ｂに、アクティベート秘密鍵ＲＡを記憶部４５の備えるセキュア領域４５ａに、それぞれ書き込む。
【００５８】
そして、ステップＳ１０５において、ステップＳ１０２で生成したアクティベート公開鍵ＵＡを、初期化処理を行ったデバイス４についての情報として、デバイス情報記憶部５２へと記録する。ここで、更に、デバイス４を一意に識別するための情報として、例えば、ネットワークインタフェースの持つＭＡＣアドレスや、デバイス４のシリアル番号などを、共に記録するような構成としてもよい。このようにしてデバイス情報記憶部５２へと記録されたデバイス４に関する情報は、後にデバイス４の初期プロビジョニング処理に使用するために、プロビジョニングサーバ３へと提供され、デバイス情報記憶部３４に格納される。
【００５９】
以上の処理によって初期化処理が完了した後の記憶部４５に含まれるデータの構造を、図７に示す。ここに示すように、セキュア領域４５ａには、アクティベート秘密鍵ＲＡが、通常領域４５ｂには、デバイス識別データＩＤが、それぞれ含まれる状態となる。なお、通常領域４５ｂには、開発公開鍵と紐づく開発証跡ＥＤと、組織公開鍵と紐づく組織証跡ＥＯも含まれる。これらの証跡は、同一の組織における、同一の開発チーム等によって製造されるデバイス４については、すべて同一である。そのため、図１２を参照して説明したデバイスの初期化処理の前、あるいは後に、生産拠点システム５によって製造されるすべてのデバイス４に対して書き込むような処理としてもよいし、ステップＳ１０４において、同時に書き込むような構成としてもよい。以上のような、生産拠点における初期化処理が完了した後に、デバイス４は出荷される。
【００６０】
＜プロビジョニング処理＞
図１３は、デバイス４の起動時における処理の流れを示すフローチャートである。これは、電源、ネットワークケーブルなどの必要な接続といった作業が行われた後に、デバイス４の電源が投入された際に実行される処理である。
【００６１】
まず、ステップＳ２０１において、デバイス４の起動確認が行われる。ここでは、デバイス４の機種ごとに必要な処理が行われる。例えば、デバイス４ｂ１、４ｂ２、４ｂ３のようにインターネットなどのネットワークＮＷへと接続されるデバイス４であれば、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバへの接続やゲートウェイ情報の設定、ＩＰアドレスの取得といった、ネットワーク接続に関する処理が挙げられる。また、デバイス４ａ１、４ａ２、４ａ３のように、ネットワークＮＷとは異なるネットワークへの接続がなされるデバイス４についても、接続するネットワークの種別に適したネットワーク接続設定などを行えばよい。また、デバイス４の利用（設置）場所の気温などについて、デバイス４が適切に動作するための条件を満たしているか、といった確認や、後述するプロビジョニング処理による解消が不可能であるデバイス４の構成上の不備（例えばハードウェア自体の欠損や故障等）の有無の確認など、デバイス４に合わせた処理を行うような構成とすればよい。なお、ここで起動確認に失敗した場合においては、例えばデバイス４の備えるスピーカからのビープ音の出力や、ＬＥＤ（Ｌｉｇｈｔ  Ｅｍｉｔｔｉｎｇ  Ｄｉｏｄｅ）による表示などにより、デバイス４の起動確認に失敗したことを通知し、デバイスの起動処理を終了することが好ましい。
【００６２】
ステップＳ２０１における起動確認が正常に完了した後には、ステップＳ２０２において、デバイス４が初期状態であるか否かの判定が行われる。ここでの判定は、記憶部４５に格納されるデータの状況を確認することによって行うことができる。すなわち、デバイスの初期状態においては、図７に示したように、セキュア領域４５ａにアクティベート秘密鍵ＲＡが、通常領域４５ｂにデバイス識別データＩＤがそれぞれ含まれる状態である。このような場合に、デバイス４が初期状態であると判定することができる。
【００６３】
ステップＳ２０２において、デバイス４が初期状態であると判定された場合には、ステップＳ２０３へと進み、デバイス４の初期プロビジョニング処理が行われる。図１４は、初期プロビジョニング処理の流れを示すフローチャートである。
【００６４】
まず、ステップＳ３０１において、通常領域４５ｂに格納されるデバイス識別データＩＤをプロビジョニングサーバ３へと送信し、初期プロビジョニングデータの提供を依頼する。そして、ステップＳ３０２でプロビジョニングサーバ３はそれを受信し、デバイス４への初期プロビジョニングデータの提供に係る処理を開始する。
【００６５】
ステップＳ３０３では、プロビジョニングサーバ３による、デバイス４より受信したデバイス識別データＩＤの検証処理が行われる。ここでの検証は、デバイス識別データＩＤに含まれるアクティベート公開鍵ＵＡが、デバイス情報記憶部３４に格納されているか否かの確認によって行うことができる。すなわち、上述したように予めプロビジョニングサーバ３に配備された開発秘密鍵と組織証跡を用いて、開発秘密鍵によるデバイス識別データＩＤの復号、組織証跡による公開鍵提供手段１３への問い合わせによる組織公開鍵の取得、組織公開鍵を用いた、組織秘密鍵による電子署名ＳＯの検証を行い、復号、正当性の検証が完了したアクティベート公開鍵ＵＡが、デバイス情報記憶部３４に格納されるものであるか、確認する。
【００６６】
ここで、デバイス情報記憶部３４には、生産拠点におけるデバイス４の初期化処理時にデバイス情報記憶部５２へと記録されたアクティベート公開鍵ＵＡが格納されているため、デバイス識別データＩＤから取り出したアクティベート公開鍵ＵＡと同一のものがデバイス情報記憶部３４に格納されていることをもって、デバイス４が生産拠点システム５によって初期化された正当なものであることが担保できる。なお、デバイス４の初期化処理時に、アクティベート公開鍵ＵＡの他に、更に、デバイス４を一意に識別するための情報が共に記録される場合には、デバイス識別データＩＤと共にそれに対応する情報を送信し、ステップＳ３０３においてそれらの情報を用いた検証を併せて行うことができ、デバイスの正当性の担保をより強固なものとすることができる。
【００６７】
ステップＳ３０３におけるデバイス識別データの検証が成功し、デバイス４が正当なものであると判定された場合には、ステップＳ３０４からステップＳ３０５へと進み、初期プロビジョニングデータの生成処理が行われる。
【００６８】
図１５は、プロビジョニングデータ提供手段３１による初期プロビジョニングデータの生成処理の流れを示すフローチャートである。まず、ステップＳ４０１においては、デバイス認証サーバ１によるブロックチェーン２へのデバイス証跡の登録処理が行われる。ここで、デバイス証跡とは、先に述べたようにそれぞれのデバイス４ごとに一意なものであり、同じくデバイス４ごとに一意であるデバイス秘密鍵、デバイス公開鍵と対応するものである。図１６に、デバイス証跡の登録処理の流れを示す。
【００６９】
デバイス証跡の登録処理においては、まず、ステップＳ５０１で、プロビジョニングサーバ３により、デバイス秘密鍵とそれに対応するデバイス公開鍵のペアを生成する。そして、ステップＳ５０２で、デバイス公開鍵のブロックチェーン２への登録をデバイス認証サーバ１へと要求する。
【００７０】
そして、ステップＳ５０４で、証跡登録手段１１によるデバイス公開鍵のブロックチェーン２への登録によってデバイス証跡が取得され、ステップＳ５０４で、それがプロビジョニングサーバ３へと返却される。ステップＳ５０５でプロビジョニングサーバ３はデバイス証跡を受領し、ステップＳ５０１で生成したデバイス秘密鍵と、デバイス証跡とを得ることになる。
【００７１】
以上のような処理によってデバイス証跡の登録を完了した後、ステップＳ４０２で、セキュア領域４５ａに格納するデータを初期プロビジョニングデータへと追加する。図１０に、初期プロビジョニングデータＰＩの構造を示す。ここに示すように、セキュア領域４５ａへと格納するデータは、ステップＳ４０１で得たデバイス秘密鍵Ｒ１であるため、それを初期プロビジョニングデータへと追加する。
【００７２】
続くステップＳ４０３では、通常領域４５ｂに格納するデータを初期プロビジョニングデータへと追加する。ここでは、図１０に示すように、ステップＳ４０１で得たデバイス証跡Ｅ１を、通常領域に格納するデータとして初期プロビジョニングデータへと追加する。
【００７３】
そして、ステップＳ４０４においては、プロビジョニングサーバ３の所持する開発秘密鍵による電子署名ＳＤの付与を行う。これは、例えば、ここまでに初期プロビジョニングデータへと追加したデータのハッシュ値を算出し、それに対して、開発秘密鍵による暗号化を行う、といった処理によって行えばよい。なお、先に述べたように、開発秘密鍵はプロビジョニングサーバ３に予め配備されるものである。
【００７４】
その後、ステップＳ４０５において、ここまでに初期プロビジョニングデータに追加したデバイス秘密鍵Ｒ１、デバイス証跡Ｅ１、開発秘密鍵による電子署名ＳＤを、デバイス識別データＩＤより取り出したアクティベート公開鍵によって暗号化し、初期プロビジョニングデータの生成が完了する。
【００７５】
このように、アクティベート公開鍵によって暗号化することにより、それに対応するアクティベート秘密鍵を所持するデバイス４、すなわち、プロビジョニングサーバ３へとデバイス識別データＩＤを送信し、初期プロビジョニングデータの提供を依頼したデバイス４においてのみ、初期プロビジョニングデータを展開可能な構成とすることができる。
【００７６】
以上のようにしてステップＳ３０５における初期プロビジョニングデータの生成処理が完了した後には、ステップＳ３０６でそれをプロビジョニングサーバ３よりデバイス４へと送信する。そして、ステップＳ３０７で、初期プロビジョニングデータの受信と展開処理を行う。
【００７７】
なお、ここで送信される初期プロビジョニングデータは、先に述べたように、デバイスごとに一意であるアクティベート公開鍵によって暗号化されたものである。すなわち、それに対応するアクティベート秘密鍵を保持するデバイス４以外に不正に取得された場合においても、復号を行うことはできないといえる。そのため、ここでのプロビジョニングサーバ３からデバイス４への初期プロビジョニングデータの送信に際しては、ＨＴＴＰＳ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｅ）のような、セキュリティを確保するために処理コストを要する通信プロトコルでなく、通常のＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などの、比較的軽量な通信プロトコルを用いることができる。
【００７８】
図１７に、デバイス４による初期プロビジョニングデータの展開処理の流れを示す。まず、ステップＳ６０１において、アクティベート秘密鍵による初期プロビジョニングデータの復号が行われる。
【００７９】
続くステップＳ６０２では、開発秘密鍵による電子署名ＳＤの検証処理が行われる。図１８に、デバイス４による電子署名の検証処理の流れを示す。まず、ステップＳ７０１において、電子署名の検証に必要となる公開鍵のプロビジョニングサーバ３への要求が、それに対応する証跡を送信することによって行われる。ここでは、開発秘密鍵による電子署名ＳＤの検証を目的としており、それに必要となるのは開発公開鍵であるため、通常領域４５ｂに格納される開発証跡ＥＤが送信される。
【００８０】
ステップＳ７０１でデバイス４よりプロビジョニングサーバ３へと送信された開発公開鍵の取得の要求は、ステップＳ７０２で、プロビジョニングサーバ３から公開鍵提供手段１３へと送信される。公開鍵提供手段１３は、ステップＳ７０３において、ブロックチェーン２を参照し、受信した開発証跡に紐づいてブロックチェーン２上に登録される開発公開鍵の取得を行う。
【００８１】
ステップＳ７０３においてブロックチェーン２より取得された開発公開鍵は、ステップＳ７０４でプロビジョニングサーバ３へと返却され、更に、ステップＳ７０５において、プロビジョニングサーバ３からデバイス４へと返却される。デバイス４は、ステップＳ７０６でそれを受領する。
【００８２】
ステップＳ７０７では、ステップＳ７０６で受領した開発公開鍵を用いて、開発秘密鍵による電子署名ＳＤの復号を行う。ここで、先に述べたように、開発秘密鍵による電子署名ＳＤは、初期プロビジョニングデータＰＩに含まれるデバイス秘密鍵Ｒ１、デバイス証跡Ｅ１のハッシュ値を開発秘密鍵によって暗号化したものである。そのため、それらのデータのハッシュ値の算出を行い、その結果と開発秘密鍵による電子署名ＳＤの復号結果が一致すれば、初期プロビジョニングデータＰＩの不正な改ざん等は行われていないと判断することができる。
【００８３】
本実施形態に係るデバイスプロビジョニングシステムにおいては、上述したように、ブロックチェーン２上に証跡が登録されていることをもって、それに対応する公開鍵の信頼性の担保を行うものである。そのため、従来の電子証明書による公開鍵の正当性の担保が行われる場合のように、電子証明書の発行者の確認、発行者の公開鍵の取得、電子証明書に含まれる発行者による電子署名の検証、といった煩雑な処理をデバイス４上で行わずとも、証跡を用いた問い合わせにより、正当性の担保された公開鍵を得ることができる。
【００８４】
そして、このように、開発秘密鍵による電子署名を初期プロビジョニングデータへ付与し、デバイス４において電子署名の検証を行うことにより、仮にプロビジョニングサーバ３を装った不正なサーバからデバイス４に対して不正なプロビジョニングデータが提供された場合にも、それを判別することができる。
【００８５】
以上のような処理によってステップＳ６０２における開発公開鍵による電子署名の検証を行い、検証が成功した場合には、ステップＳ６０３からステップＳ６０４へと進み、セキュア領域４５ａへのデータの格納を行う。ここでは、初期プロビジョニングデータＰＩに、セキュア領域４５ａに格納するデータとしてデバイス秘密鍵Ｒ１が含まれるので、これをセキュア領域４５ａへと格納する。
【００８６】
ステップＳ６０５では、セキュア領域４５ａ上の旧データの抹消を行う。ここで、セキュア領域４５ａには、ステップＳ６０４において格納したデバイス秘密鍵Ｒ１よりも古いデータとして、先に図７に示した通りアクティベート秘密鍵ＲＡが含まれる状態であるため、これを抹消する。なお、ここでは、ステップＳ６０４におけるデータの格納により不要となるデータの抹消を行えばよく、これは、事前に定義されるものであってもよいし、あるいは、初期プロビジョニングデータＰＩに抹消対象とするデータの指示を含めておくような構成としてもよい。
【００８７】
続くステップＳ６０６では、通常領域４５ｂへのデータの格納を行う。ここでは、初期プロビジョニングデータＰＩに、通常領域４５ｂに格納するデータとしてデバイス証跡Ｅ１が含まれるので、これを通常領域４５ｂへと格納する。
【００８８】
そして、ステップＳ６０７では、通常領域４５ｂ上の旧データの抹消を行う。ここで、通常領域４５ｂには、先に図７に示したようにデバイス識別データＩＤが含まれる状態であるため、これを抹消する。ここでも、ステップＳ６０５におけるセキュア領域４５ａからのデータの抹消と同様、ステップＳ６０６におけるデータの格納により不要となるデータを事前に定義するような構成であってもよいし、あるいは、初期プロビジョニングデータＰＩに抹消対象とするデータの指示を含めておくような構成としてもよい。
【００８９】
このようにして、デバイス４上での初期プロビジョニングデータＰＩの展開処理が完了した後には、記憶部４５上のデータは、図８（ａ）に示すようになる。すなわち、セキュア領域４５ａには、初期プロビジョニングデータＰＩに含まれていたデバイス秘密鍵Ｒ１が、通常領域４５ｂには、同じく初期プロビジョニングデータＰＩに含まれていたデバイス証跡Ｅ１、及び、デバイスの初期状態において含まれている開発証跡ＥＤ、組織証跡ＥＯが含まれる状態となる。
【００９０】
なお、ステップＳ６０２における開発公開鍵を用いた電子署名の検証に失敗した場合には、初期プロビジョニングデータＰＩに不正な改ざんが行われた可能性や、他のデバイス４のための初期プロビジョニングデータＰＩの展開を試みている可能性があり、すなわち、初期プロビジョニング処理の対象とするデバイス４に対する正当な初期プロビジョニングデータＰＩでないデータが用いられようとしていると判断できる。そのため、電子署名の検証に失敗した場合には、ステップＳ６０３の後に処理を終了し、初期プロビジョニングデータＰＩの展開を中止する。
【００９１】
以上のようにして、ステップＳ３０７における初期プロビジョニングデータの展開処理が完了した後には、ステップＳ３０８で、初期プロビジョニング処理の終了通知を行う。これは、デバイス４よりプロビジョニングサーバ３に対し、デバイス４の初期プロビジョニングが正常に完了したこと、あるいは、何れかの処理において失敗した場合には、失敗した原因などの情報を送信するものである。ここで、このような情報を受信したプロビジョニングサーバ３は、それをデバイス認証サーバ１へと送信し、ブロックチェーン２への書き込みを行う。この際、デバイスの起動処理が行われた時刻や場所など、付加的な情報を共に扱うことが好ましい。
【００９２】
デバイス４の初期プロビジョニング処理において特に重要であるのは、デバイス４ごとに一意であるデバイス証跡のブロックチェーン２への登録を行うという点である。これはすなわち、本実施形態に係るデバイスプロビジョニングシステムにおけるデバイス４が、ブロックチェーン２に登録されて管理されるものであるといえる。これにより、いわゆる野良ＩｏＴデバイスのように、素性の不明なデバイスがシステム内に混入することを防ぎ、セキュアなシステムを構築することができるものである。
【００９３】
ここまでに説明したような処理により、ステップＳ２０３におけるデバイス４の初期プロビジョニング処理が完了した後には、ステップＳ２０４で、デバイス４の再起動が指示される。再起動後には、再びステップＳ２０１における起動確認処理が行われ、そして、ステップＳ２０２において、デバイス４が初期状態であるか否かの確認が行われる。
【００９４】
ここで、正常に初期プロビジョニング処理が完了している場合には、先に述べた通り、記憶部４５上のデータ構造は図８（ａ）に示すようになっているはずである。そのため、ここで、セキュア領域４５ａ中のデバイス秘密鍵Ｒ１の有無、通常領域４５ｂ中のデバイス証跡Ｅ１の有無などを確認し、それらのデータが存在するのであれば、デバイス４は初期状態ではないと判定され、ステップＳ２０５のプロビジョニング処理が実行される。
【００９５】
図１９は、デバイス４のプロビジョニング処理の流れを示すフローチャートである。デバイス４のプロビジョニング処理においては、まず、ステップＳ８０１で、デバイス４よりプロビジョニングサーバ３へと、デバイス証跡を送信し、プロビジョニングデータの提供を依頼する。
【００９６】
ステップＳ８０２では、プロビジョニングデータ提供手段３１による、デバイス４より受信したデバイス証跡に基づいた、プロビジョニングデータの生成処理が行われる。図２０に、プロビジョニングデータの生成処理の流れを示す。
【００９７】
まず、ステップＳ９０１では、デバイス証跡の更新の有無の判定を行う。これは例えば、デバイス証跡に予め有効期限を定めておき、それに基づいて更新の有無を決定する、あるいは、プロビジョニングサーバ３の管理者の指示に基づいて更新の有無を決定するなど、任意のタイミングでデバイス証跡の更新を行うか否かを決定するような構成とすればよい。ここで、デバイス証跡に有効期限を定めることは、すなわち、それに対応するデバイス秘密鍵、デバイス公開鍵に有効期限を設けることとなる。
【００９８】
ステップＳ９０１において、デバイス証跡の更新を行うと判定された場合には、ステップＳ９０２へと進み、新たなデバイス証跡の登録処理が行われる。これは、先に図１６を参照して説明した処理と同様の処理によって行うことができる。
【００９９】
続くステップＳ９０３では、セキュア領域４５ａに追加するデータの有無の確認を行い、それがある場合には、ステップＳ９０４で、プロビジョニングデータへの追加を行う。ここでのセキュア領域４５ａへの追加を行うデータとしては、例えば、ステップＳ９０２で生成した新たなデバイス秘密鍵が挙げられる。
【０１００】
ステップＳ９０５では、通常領域４５ｂに追加するデータの有無の確認を行い、それがある場合には、ステップＳ９０６で、プロビジョニングデータへの追加を行う。ここでの通常領域４５ｂへの追加を行うデータとしては、例えば、起動プログラム記憶部３３に格納される、デバイス４に適した起動プログラムや、ステップＳ９０２で登録した新たなデバイス証跡が挙げられる。
【０１０１】
そして、ステップＳ９０７においては、プロビジョニングサーバ３の所持する開発秘密鍵による電子署名ＳＤの付与を行う。これは、例えば、ここまでにプロビジョニングデータへと追加したデータのハッシュ値を算出し、それに対して、開発秘密鍵による暗号化を行う、といった処理によって行えばよい。
【０１０２】
その後、ステップＳ９０８において、ここまでに初期プロビジョニングデータに追加したデータを、プロビジョニングデータの提供対象とするデバイス４のデバイス公開鍵によって暗号化し、初期プロビジョニングデータの生成が完了する。ここで、デバイス公開鍵は、デバイス４より送信されたデバイス証跡を用いた、公開鍵提供手段１３への問い合わせによって取得することができるものである。
【０１０３】
このように、デバイス公開鍵によって暗号化することにより、それに対応するデバイス秘密鍵を所持するデバイス４、すなわち、プロビジョニングサーバ３へとデバイス証跡を送信し、プロビジョニングデータの提供を依頼したデバイス４においてのみ、プロビジョニングデータを展開可能な構成とすることができる。
【０１０４】
以上のような処理により、ステップＳ８０２におけるプロビジョニングデータの生成が完了した後には、ステップＳ８０３でそれをデバイス４へと送信する。デバイス４は、ステップＳ８０４において、プロビジョニングデータの受信と展開処理を行う。
【０１０５】
なお、ここで送信されるプロビジョニングデータは、先に述べたように、デバイスごとに一意であるデバイス公開鍵によって暗号化されたものであり、それに対応するデバイス秘密鍵を保持するデバイス４以外に不正に取得された場合においても、復号を行うことはできない。そのため、初期プロビジョニングデータの送信と同様に、ＨＴＴＰなどの比較的に軽量な通信プロトコルを用いることができる。
【０１０６】
図２１に、デバイス４によるプロビジョニングデータの展開処理の流れを示す。まず、ステップＳ１００１において、デバイス秘密鍵によるプロビジョニングデータの復号が行われる。
【０１０７】
続くステップＳ１００２では、開発秘密鍵による電子署名ＳＤの検証処理が行われる。これは、先に図１８を参照して説明したような処理によって行えばよい。ここでの検証が成功した場合に、ステップＳ１００３からステップＳ１００４へと進む。
【０１０８】
ステップＳ１００４では、プロビジョニングデータに、セキュア領域４５ａへと格納するためのデータが含まれるか否かの確認が行われる。ここでは、先にプロビジョニングデータの生成処理で説明したように、デバイス４のための新たなデバイス秘密鍵などが、セキュア領域４５ａに格納するデータとして扱われる。
【０１０９】
ステップＳ１００４で、セキュア領域４５ａへ格納するデータがあると判定された場合には、ステップＳ１００５にて、それをセキュア領域４５ａへと格納する。そして、ステップＳ１００６で、それに対応する旧データのセキュア領域４５ａからの抹消を行う。これは例えば、デバイス４のための新たなデバイス秘密鍵のセキュア領域４５ａへの格納を行った後に、現状で使用しているデバイス秘密鍵の抹消を行う、といったものである。
【０１１０】
ステップＳ１００７では、プロビジョニングデータに、通常領域４５ｂへと格納するためのデータが含まれるか否かの確認が行われる。ここでは、先にプロビジョニングデータの生成処理で説明したように、デバイス４に適した起動プログラムや、デバイス４のための新たなデバイス証跡などが、通常領域４５ｂに格納するデータとして扱われる。
【０１１１】
ステップＳ１００７で、通常領域４５ｂへ格納するデータがあると判定された場合には、ステップＳ１００８にて、それを通常領域４５ｂへと格納する。そして、ステップＳ１００９で、それに対応する旧データの通常領域４５ｂからの抹消を行う。これは例えば、起動プログラムの格納を行った後に、以前に取得した起動プログラムが通常領域４５ｂ上にある場合には、その抹消を行う、デバイス４のための新たなデバイス証跡の格納を行った後に、現状で使用しているデバイス証跡の抹消を行う、といったものである。
【０１１２】
ステップＳ１０１０では、デバイス４のデバイス証跡の更新を行ったか否か、すなわち、ステップＳ１００５における新たなデバイス秘密鍵のセキュア領域４５ａの格納や、ステップＳ１００８における新たなデバイス証跡の通常領域４５ｂへの格納を行ったか否かの確認を行う。ここで、デバイス証跡の更新があったと判定された場合には、ステップＳ１０１１へと進み、更新前の旧デバイス証跡の無効化処理が行われる。
【０１１３】
図２２に、デバイス証跡の無効化処理の流れを示す。まず、ステップＳ１１０１で、デバイス４より、旧デバイス証跡をプロビジョニングサーバ３へと送信し、無効化を依頼する。プロビジョニングサーバ３はステップＳ１１０１でそれを受信し、デバイス認証サーバ１へと送信する。
【０１１４】
デバイス認証サーバ１は、ステップＳ１１０３において、デバイス４よりプロビジョニングサーバ３を介して送信された旧デバイス証跡を受信し、ブロックチェーン２上での無効化処理を行う。ここで、先に述べたように、ブロックチェーン２上では、一度生成されたブロックの削除や改変は不可能である。そのため、例えば、旧デバイス証跡を無効とすることを示す新たな証跡の登録を行う、といった処理により、旧デバイス証跡のブロックチェーン２上での無効化を行う。
【０１１５】
以上のような処理により、ステップＳ８０４におけるプロビジョニングデータの展開処理は終了する。なお、プロビジョニング処理においては、図２０を参照して説明したプロビジョニングデータの生成処理で、デバイス４へと提供する必要のあるデータを適宜、セキュア領域４５ａに格納するデータ、通常領域４５ｂに格納するデータとして、プロビジョニングデータへ追加し、それを受信したデバイス４が、その内容に合わせて、図２１に示したようなプロビジョニングデータの展開処理を行うような構成とすればよい。
【０１１６】
例えば、起動プログラムＰＧを提供すればよいような場合においては、通常領域４５ｂに格納するデータとして起動プログラムＰＧを含む、図１１（ａ）に示すようなプロビジョニングデータＰ１を生成し、デバイス４へと提供する。これを受信したデバイス４は、復号や電子署名の検証後に、起動プログラムＰＧの通常領域４５ｂへの格納を行い、また、以前のプロビジョニング処理において通常領域４５ｂに格納された起動プログラムが存在する場合には、その抹消を行う。
【０１１７】
また、起動プログラムＰＧに加えて、デバイス証跡の更新を行う場合においては、図１１（ｂ）に示すような、セキュア領域４５ａに格納するためのデータとして新たなデバイス秘密鍵Ｒ２を、通常領域４５ｂに格納するためのデータとして起動プログラムＰＧに加えて新たなデバイス証跡Ｅ２をそれぞれ含むようなプロビジョニングデータＰ２を生成し、デバイス４へと提供する。これを受信したデバイス４は、復号や電子署名の検証後に、新たなデバイス秘密鍵Ｒ２のセキュア領域４５ａへの格納と、現状で使用しているデバイス秘密鍵のセキュア領域４５ａからの抹消と、新たなデバイス証跡Ｅ２、起動プログラムＰＧの通常領域４５ｂへの格納と、現状で使用しているデバイス証跡及び以前のプロビジョニング処理において通常領域４５ｂに格納された起動プログラムの抹消と、を行う。
【０１１８】
ここで、先に述べたように、本実施形態に係るデバイスプロビジョニングシステムは、デバイス４がブロックチェーン２に登録されて管理されるものである。そのため、ブロックチェーン２に登録されたデバイス証跡の更新を行うことは、すなわち、デバイスプロビジョニングシステムにおけるデバイス４の登録の更新を行うことに等しいといえる。
【０１１９】
そして、ステップＳ８０５で、プロビジョニング処理の終了通知を行う。これは、デバイス４よりプロビジョニングサーバ３に対し、デバイス４のプロビジョニングが正常に完了したこと、あるいは、何れかの処理において失敗した場合には、失敗した原因などの情報を送信するものである。ここで、このような情報を受信したプロビジョニングサーバ３は、それをデバイス認証サーバ１へと送信し、ブロックチェーン２への書き込みを行う。この際、デバイスの起動処理が行われた時刻や場所など、付加的な情報を共に扱うことが好ましい。
【０１２０】
以上のようにして、ステップＳ２０５におけるプロビジョニング処理が正常に完了した後には、記憶部４５は図８（ｂ）に示すように、セキュア領域４５ａにデバイス秘密鍵Ｒ１が、通常領域４５ｂに、デバイス証跡Ｅ１、起動プログラムＰＧ、開発証跡ＥＤ、組織証跡ＥＯが、それぞれ含まれる状態となる。
【０１２１】
ステップＳ２０６では、ステップＳ８０５におけるプロビジョニング処理の終了通知の内容や、記憶部４５に含まれるデータの状態より、プロビジョニングが成功したか否かの判定を行う。正常に終了している場合には、デバイス４を正規の手順によって起動する準備が整っているものであるため、ステップＳ２０７へと進み、システム起動手段４３によるシステムの起動を行う。ここでは、例えば、上述したように、起動プログラムＰＧがデバイス４上で稼働するＯＳそのものを含むようなものであれば、それを用いたデバイス４の起動を行えばよいし、あるいは、起動プログラムＰＧがＯＳを呼び出すためのプログラムなどである場合には、デバイス４の補助記憶装置に予め配されるＯＳによるデバイス４の起動を行えばよい。また、デバイス秘密鍵Ｒ１やデバイス証跡Ｅ１、開発証跡ＥＤ、組織証跡ＥＯの内の一部、あるいは全部を、ＯＳ上で使用できるように引き渡すような構成としてもよい。
【０１２２】
なお、ステップＳ２０７におけるシステムの起動後には、デバイス４上でＯＳやアプリケーションプログラムが稼働することになる。これらのログ等について、プロビジョニングサーバ３上に図示しない記憶部を設け、蓄積するような構成とすることが好ましい。これはすなわち、例えば、デバイス４がデータの収集等を目的としたＩｏＴデバイスであれば、その収集対象とするデータの蓄積を行う、といったように、デバイス４の目的に応じたものであればよい。
【０１２３】
＜デバイス再初期化処理＞
図２４は、デバイス４の再初期化処理の流れを示すフローチャートである。これは、デバイスに不具合が生じた場合や、デバイスの使用を停止する場合などに、デバイス４に対する再初期化処理の指示操作を受け、実行されるものである。ここでの指示操作は、例えば、デバイス４に専用のボタンを設けるような構成や、デバイス４に電源を投入するボタンの長押しなど、任意の操作を定めておくような構成とすればよい。
【０１２４】
まず、ステップＳ１２０１において、上述したような再初期化処理の指示を受けたデバイス４より、プロビジョニングサーバ３へと再初期化処理が要求される。ここでは、デバイス４は、自身を特定させるための情報として、セキュア領域４５ａに格納される自身のデバイス証跡をプロビジョニングサーバ３へと送信する。
【０１２５】
プロビジョニングサーバ３は、ステップＳ１２０２で再初期化要求を受け付け、アクティベート鍵提供手段３２ｂによるアクティベート鍵ペアの生成を行う。ここでのアクティベート鍵ペアは、デバイス４の製造時の初期化処理におけるステップＳ１０２において生成したものと同様、デバイス４ごとに一意なアクティベート秘密鍵と、それに対応するアクティベート公開鍵である。
【０１２６】
そして、ステップＳ１２０３において、図２３（ａ）に示すような、ステップＳ１２０２で生成したアクティベート秘密鍵ＲＡをデバイス４に登録するための、アクティベート秘密鍵登録データＲＲの生成が行われる。
【０１２７】
ここでは、まず、開発秘密鍵による電子署名ＳＤの付与が行われる。これは、アクティベート秘密鍵ＲＡのハッシュ値を算出し、それをプロビジョニングサーバ３の保持する開発秘密鍵によって暗号化する、といった処理により行われる。そして、アクティベート秘密鍵ＲＡ、開発秘密鍵による電子署名ＳＤの、デバイス公開鍵による暗号化を行う。ここで、デバイス公開鍵は、ステップＳ１２０２において受信したデバイス証跡を用いた公開鍵提供手段１３への問い合わせによって取得される。
【０１２８】
以上のようにして、ステップＳ１２０３におけるアクティベート秘密鍵登録データＲＲの生成が完了すると、それがデバイス４へと送信される。そして、デバイス４は、ステップＳ１２０４において、受信したアクティベート秘密鍵登録データＲＲを用いたアクティベート秘密鍵の格納処理を行う。図２５に、アクティベート秘密鍵の格納処理の流れを示す。
【０１２９】
まず、ステップＳ１３０１で、自身のデバイス秘密鍵による、アクティベート秘密鍵登録データＲＲの復号を行う。そして、ステップＳ１３０２で、開発公開鍵を用いた、開発秘密鍵による電子署名ＳＤの検証を行う。ここでは、通常領域４５ｂに格納される開発証跡を用いて、図１８を参照して説明したような処理を行えばよい。
【０１３０】
そして、開発秘密鍵による電子署名ＳＤの検証が成功した場合、すなわち、アクティベート秘密鍵登録データＲＲが正当なものであると判定された場合には、ステップＳ１３０３よりステップＳ１３０４へと進み、アクティベート秘密鍵ＲＡをセキュア領域４５ａへと格納する。
【０１３１】
その後、ステップＳ１３０５で、セキュア領域４５ａからの旧データの抹消、すなわち、ここではデバイス秘密鍵の抹消を行い、アクティベート秘密鍵の格納処理は終了する。
【０１３２】
このようにして、ステップＳ１２０４におけるアクティベート秘密鍵の格納処理を行った後、ステップＳ１２０５で、デバイス４よりプロビジョニングサーバ３へ、デバイス識別データの要求がなされる。
【０１３３】
そして、プロビジョニングサーバ３は、ステップＳ１２０６で、図２３（ｂ）に示すような、デバイス識別データＩＤの生成処理を行う。ここでは、まず、組織秘密鍵による電子署名ＳＯの付与が行われる。これは、アクティベート公開鍵ＵＡのハッシュ値を算出し、それをプロビジョニングサーバ３の保持する組織秘密鍵によって暗号化する、といった処理が行われる。そして、アクティベート秘密鍵ＲＡ、組織秘密鍵による電子署名ＳＯの、開発公開鍵による暗号化を行う。ここで、開発公開鍵は、プロビジョニングサーバ３に予め配備される開発証跡を用いた、公開鍵提供手段１３への問い合わせによって取得される。
【０１３４】
以上のようにして、ステップＳ１２０６におけるデバイス識別データＩＤの生成が完了すると、それがデバイス４へと送信される。そして、デバイス４は、ステップＳ１２０７において、受信したデバイス識別データＩＤの通常領域４５ｂへの格納を行う。
【０１３５】
続くステップＳ１２０８では、通常領域４５ｂからの旧データの抹消、すなわち、ここでは、デバイス証跡、起動プログラムの抹消が行われる。そして、ステップＳ１２０９で、ブロックチェーン２上に格納されたデバイス証跡の無効化処理が行われる。これは、先に図２２を参照して説明したように、証跡無効化手段１２への依頼によって行うことができる。
【０１３６】
ここで、先に述べたように、本実施形態に係るデバイスプロビジョニングシステムは、デバイス４がブロックチェーン２に登録されて管理されるものである。そのため、ブロックチェーン２に登録されたデバイス証跡の無効化を行うことは、すなわち、デバイスプロビジョニングシステムにおけるデバイス４の登録の解除を行うことに等しいといえる。
【０１３７】
ステップＳ１２０９におけるデバイス証跡の無効化処理が完了した後には、ステップＳ１２１０で、デバイス４の再初期化処理の終了通知を行う。これは、デバイス４よりプロビジョニングサーバ３に対し、デバイス４の再初期化が正常に完了したこと、あるいは、何れかの処理において失敗した場合には、失敗した原因などの情報を送信するものである。ここで、このような情報を受信したプロビジョニングサーバ３は、それをデバイス認証サーバ１へと送信し、ブロックチェーン２への書き込みを行う。この際、デバイスの再初期化処理が行われた時刻や場所など、付加的な情報を共に扱うことが好ましい。
【０１３８】
以上のような処理により、デバイス４の再初期化が完了した後には、記憶部４５内のデータは図７に示すような、図１２を参照して説明した生産拠点システム５による初期化処理の完了時と同様の状態となる。このようにして再初期化が行われたデバイス４が再度利用される際には、図１３、図１４等を参照して説明した、初期プロビジョニング処理が行われ、ブロックチェーン２上への登録が再度行われることになる。
【０１３９】
＜指示データを用いたプロビジョニングの実行＞
以上に説明した、デバイス４のプロビジョニング処理や再初期化処理は、デバイス４の起動時に実行されるものである。本実施形態に係るデバイスプロビジョニングシステムでは、これらの処理に加えて、図１３を参照して説明したデバイス４の起動時の処理におけるステップＳ２０７の完了後、すなわち、デバイス４上でＯＳやアプリケーションが稼働している状態からも、プロビジョニング処理が実行可能に構成される。
【０１４０】
図２７は、稼働中のデバイス４に対し、プロビジョニングサーバ３からの指示に基づいてプロビジョニング処理を行う場合の処理の流れを示すフローチャートである。まず、ステップＳ１４０１で、デバイス４に対するプロビジョニング指示が必要か否かを判定し、必要と判定されるまで待機する。
【０１４１】
ここでの判定の基準は、プロビジョニングサーバ３に予め登録されていればよい。例えば、所定の期間毎に必ずプロビジョニング処理が行われるような設定や、プロビジョニングサーバ３への操作によって随時プロビジョニング処理を行うことができるような構成とすればよい。また、プロビジョニング指示の対象とするデバイスについても、事前の設定等によって決定できるような構成とすることが好ましい。例えば、前回のプロビジョニング処理から一定以上の期間が経過したデバイス４を対象とする、デバイス４が位置情報をプロビジョニングサーバ３へ送信するような構成であれば、特定の範囲に含まれる地域で稼働するデバイス４を対象とする、といった条件が挙げられる。
【０１４２】
そして、ステップＳ１４０１でプロビジョニング指示が必要であると判定された場合には、ステップＳ１４０２へと進み、図２６に示すような指示データＤＮの生成が行われる。これは、プロビジョニング実行指示ＥＮに対して、開発秘密鍵による電子署名ＳＤを付与し、デバイス公開鍵による暗号化を行う、といった処理となる。なお、ここで用いるデバイス公開鍵は、プロビジョニング指示の対象とするデバイス４のデバイス証跡を用いた公開鍵提供手段１３への問い合わせによって取得できる。なお、ここでプロビジョニングサーバ３より適切なデバイスへのプロビジョニングを行うために、先に図１６を参照して説明した処理によるブロックチェーン２へのデバイス公開鍵の登録、デバイス証跡の取得時に、自身が登録したデバイス４、すなわち、自身が管理の対象とするデバイス４のデバイス証跡をプロビジョニングサーバ３上に蓄積しておくような構成とすることが好ましい。
【０１４３】
そして、ステップＳ１４０２で生成された指示データＤＮが、プロビジョニング指示の対象となるデバイス４へと送信される。指示データＤＮを受信したデバイス４は、ステップＳ１４０３で、セキュア領域４５ａに格納されるデバイス秘密鍵による指示データＤＮの復号を行い、ステップＳ１４０４で、指示データＤＮに含まれる開発秘密鍵による電子署名ＳＤの検証を行う。ここでの開発秘密鍵による電子署名ＳＤの検証処理は、先に図１８を参照して説明したような処理によって行えばよい。
【０１４４】
ステップＳ１４０４における開発秘密鍵による電子署名ＳＤの検証処理に成功し、指示データＤＮ内に正常なプロビジョニング実行指示ＥＮが含まれることが確認された場合には、ステップＳ１４０５よりステップＳ１４０６へと進み、デバイス４の再起動が行われる。そして、ステップＳ１４０７で、先に図１３を参照して説明したようなデバイスの起動時処理が実行される。
【０１４５】
以上のような処理により、稼働中のデバイス４の、プロビジョニングサーバ３からの指示に基づいたプロビジョニング処理を実行することができる。これにより、上述したように、プロビジョニングサーバ３側で予め、あるいは管理者の操作等に基づいた任意のタイミングで、デバイス４のプロビジョニング処理を実行することができる。
【０１４６】
なお、先に述べたように、これは、デバイス４上でＯＳ等が稼働している状況で実行される処理である。すなわち、ステップＳ１４０３における指示データＤＮの受信からステップＳ１４０６における再起動までの処理については、デバイス４のＯＳ上で稼働するサービス等が実行するよう構成すればよい。
【０１４７】
本実施形態に係るデバイスプロビジョニングシステムによるプロビジョニング処理の更なる例として、図２８に、デバイス４側からの指示に基づいたプロビジョニング処理の流れを示す。まず、ステップＳ１５０１で、デバイス４は自身のプロビジョニング処理の実施が必要か否かを判定し、必要と判定されるまで待機する。
【０１４８】
なお、ここでの判定の基準は、デバイス４に予め登録されていればよい。例えば、所定の期間毎に必ずプロビジョニング処理が行われるような設定や、稼働中のデバイス４の操作によって随時プロビジョニング処理を行うことができるような構成とすればよい。また、デバイス４が位置情報の取得手段を備えるのであれば、所定以上の移動が行われた場合にプロビジョニング処理を行うなど、デバイス４の状況の変化に応じてプロビジョニング処理の実行を行うような構成としてもよい。
【０１４９】
そして、ステップＳ１５０１でプロビジョニング指示が必要であると判定された場合には、ステップＳ１５０２へと進み、図２６に示すような指示データＤＮの、プロビジョニングサーバ３への要求が行われる。これは、デバイス４が通常領域４５ｂに記録される、自身のデバイス証跡をプロビジョニングサーバ３に送信することで行われる。
【０１５０】
以降のステップＳ１５０３からステップＳ１５０８までの各処理については、先に図２７を参照して説明した、プロビジョニングサーバ３からの指示に基づいたプロビジョニング処理を行う場合の、ステップＳ１４０２からステップＳ１４０７の処理と同様にして行われる。
【０１５１】
以上のような処理により、稼働中のデバイス４自身からの指示に基づいたプロビジョニング処理を実行することができる。これにより、上述したように、ＯＳ等が稼働中のデバイス４側で予め、あるいは管理者の操作等に基づいた任意のタイミングで、プロビジョニング処理を実行することができる。
【０１５２】
なお、先に述べたように、これは、デバイス４上でＯＳ等が稼働している状況で実行される処理であるため、先に図２７を参照して説明した、プロビジョニングサーバ３からの指示に基づいたプロビジョニング処理を行う場合と同様、ステップＳ１５０４における指示データＤＮの受信からステップＳ１５０７における再起動までの処理については、デバイス４のＯＳ上で稼働するサービス等が実行するよう構成すればよい。
【０１５３】
ここで、図２７ではプロビジョニングサーバ３からの指示に基づいたプロビジョニング処理を、図２８では稼働中のデバイス４自身からの指示に基づいたプロビジョニング処理を、それぞれ実行する例を示したが、デバイス４の再初期化処理についても、同様に行えるような構成とすることが好ましい。すなわち、ステップＳ１４０６、Ｓ１５０７におけるデバイス４の再起動処理時に、再起動後のステップＳ１４０７、Ｓ１５０８において通常の起動時の処理を行うのではなく、図２４に示した再初期化処理を行わせるようなパラメータの受け渡しなどを行うことができるような構成とすることが好ましい。
【０１５４】
以上のように、本実施形態に係るデバイスプロビジョニングによれば、デバイスごとに一意なデバイス秘密鍵、デバイス公開鍵を用いてプロビジョニングデータの配布を行うことにより、高いセキュリティを保ってデバイスのプロビジョニングを行うことができる。
【０１５５】
また、ブロックチェーンの、一度登録されたデータに対する不正な改ざん処理や、ブロックの削除などを行うことが困難であるという特性を活かし、ブロックチェーン上でデバイス公開鍵の管理を行うことにより、デバイスごとの秘密鍵、公開鍵を用いる構成としながらも、多量の電子証明書を必要とすることがない。
【０１５６】
そして、ブロックチェーン上にデバイスごとに一意であるデバイス公開鍵の登録をし、管理をすることはすなわち、ブロックチェーン上でデバイスそのものの管理を行うことにもつながり、不正なデバイスがシステム内に入り込むようなことを防ぎ、セキュアなシステムを構築することができる。
【符号の説明】
【０１５７】
１  デバイス認証サーバ
１１  証跡登録手段
１２  証跡無効化手段
１３  公開鍵提供手段
２  ブロックチェーン
３  プロビジョニングサーバ
３１  プロビジョニングデータ提供手段
３２  デバイス初期化ライブラリ
３２ａ  デバイス識別データ提供手段
３２ｂ  アクティベート鍵提供手段
３３  起動プログラム記憶部
３４  デバイス情報記憶部
４  デバイス
４１  初期プロビジョニング確認手段
４２  プロビジョニング実行手段
４３  システム起動手段
４４  再初期化手段
４５  記憶部
４５ａ  セキュア領域
４５ｂ  通常領域
５  生産拠点システム
５１  デバイス初期化ライブラリ
５１ａ  デバイス識別データ提供手段
５１ｂ  アクティベート鍵提供手段
５２  デバイス情報記憶部
【図１】
2019004391.tif 000003
【図２】
2019004391.tif 000004
【図３】
2019004391.tif 000005
【図４】
2019004391.tif 000006
【図５】
2019004391.tif 000007
【図６】
2019004391.tif 000008
【図７】
2019004391.tif 000009
【図８】
2019004391.tif 000010
【図９】
2019004391.tif 000011
【図１０】
2019004391.tif 000012
【図１１】
2019004391.tif 000013
【図１２】
2019004391.tif 000014
【図１３】
2019004391.tif 000015
【図１４】
2019004391.tif 000016
【図１５】
2019004391.tif 000017
【図１６】
2019004391.tif 000018
【図１７】
2019004391.tif 000019
【図１８】
2019004391.tif 000020
【図１９】
2019004391.tif 000021
【図２０】
2019004391.tif 000022
【図２１】
2019004391.tif 000023
【図２２】
2019004391.tif 000024
【図２３】
2019004391.tif 000025
【図２４】
2019004391.tif 000026
【図２５】
2019004391.tif 000027
【図２６】
2019004391.tif 000028
【図２７】
2019004391.tif 000029
【図２８】
2019004391.tif 000030
【図２９】
2019004391.tif 000031
【図３０】
2019004391.tif 000032
【手続補正書】
【提出日】平成30年2月23日(2018.2.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、デバイスプロビジョニングシステムであって、
前記デバイスごとに一意である第１の公開鍵と前記デバイスごとに一意である第１の証跡とを紐づけて格納するブロックチェーンより、前記第１の証跡を用いた問い合わせに応じて前記第１の公開鍵を取得する、公開鍵提供手段と、
前記デバイスからの前記第１の証跡を用いた問い合わせに応じて、前記公開鍵提供手段によって前記第１の公開鍵を取得し、当該第１の公開鍵によって暗号化した前記プロビジョニングデータを前記デバイスに送信する、プロビジョニングデータ提供手段と、を備え、
前記デバイスが、
前記第１の公開鍵に対応する第１の秘密鍵を格納するセキュア領域と、前記第１の証跡を格納する通常領域と、を含む記憶部と、
前記第１の証跡を用いた前記プロビジョニングデータ提供手段への問い合わせによって暗号化された前記プロビジョニングデータを取得し、暗号化された前記プロビジョニングデータを前記第１の秘密鍵を用いて復号する、プロビジョニング実行手段と、を備えることを特徴とする、デバイスプロビジョニングシステム。
【請求項２】
前記ブロックチェーンへの前記第１の公開鍵の登録による前記第１の証跡の取得を行う証跡登録手段を更に備え、
前記デバイスが、前記プロビジョニングデータの提供を受けていない初期状態において、
前記セキュア領域に前記デバイスごとに一意な初回用秘密鍵を、
前記通常領域に前記初回用秘密鍵に対応する初回用公開鍵を含むデバイス識別データを、それぞれ格納した状態であり、
前記プロビジョニングデータ提供手段が、前記デバイスより送信される前記デバイス識別データに基づいた当該デバイスの正当性の検証に成功した場合に、
前記第１の秘密鍵及び前記第１の公開鍵の生成と、
前記証跡登録手段による前記第１の公開鍵の前記ブロックチェーンへの登録による前記第１の証跡の取得と、
前記第１の秘密鍵と、前記第１の証跡と、を含み、前記初回用公開鍵によって暗号化された初回用データの当該デバイスへの送信と、を行い、
前記プロビジョニング実行手段が、前記初回用秘密鍵を用いた暗号化された前記初回用データの復号と、前記第１の秘密鍵の前記セキュア領域への格納と、前記第１の証跡の前記通常領域への格納と、を行うことを特徴とする、請求項１に記載のデバイスプロビジョニングシステム。
【請求項３】
前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化を行う証跡無効化手段を更に備え、
新たな初回用秘密鍵と、前記新たな初回用秘密鍵に対応する新たな初回用公開鍵を含む新たなデバイス識別データと、を前記デバイスへと送信する、再初期化指示手段を更に備え、
前記デバイスが、前記新たな初回用秘密鍵の前記セキュア領域への格納と、前記第１の秘密鍵の前記セキュア領域からの抹消と、前記新たなデバイス識別データの前記通常領域への格納と、前記第１の証跡の前記通常領域からの抹消と、前記証跡無効化手段への前記ブロックチェーンにおける前記第１の証跡及び前記第１の公開鍵の無効化の依頼と、を行う、再初期化手段を更に備えることを特徴とする、請求項２に記載のデバイスプロビジョニングシステム。
【請求項４】
前記プロビジョニングデータ提供手段が、
前記ブロックチェーンに登録された前記第１の証跡及び前記第１の公開鍵の更新の要否の確認を行い、前記第１の証跡及び前記第１の公開鍵の更新が必要だと判定された場合に、
新たな第１の秘密鍵及び新たな第１の公開鍵の生成と、
前記証跡登録手段による前記ブロックチェーンへの前記新たな第１の公開鍵の登録による新たな第１の証跡の取得と、を行い、
前記プロビジョニングデータに、前記新たな第１の秘密鍵及び前記新たな第１の証跡を含め、
前記プロビジョニング実行手段が、
前記新たな第１の秘密鍵の前記セキュア領域への格納と、
前記新たな第１の証跡の前記通常領域への格納と、
前記第１の秘密鍵の前記セキュア領域からの抹消と、
前記第１の証跡の前記通常領域からの抹消と、を行うことを特徴とする、請求項３に記載のデバイスプロビジョニングシステム。
【請求項５】
前記プロビジョニングデータが、前記デバイス上で動作するプログラムファイルを含むことを特徴とする、請求項１から請求項４の何れかに記載のデバイスプロビジョニングシステム。
【請求項６】
前記プログラムファイルが前記デバイスの起動プログラムファイルであり、
プロビジョニング実行手段が、前記デバイスの起動時に前記プロビジョニングデータの取得を行うことを特徴とする、請求項５に記載のデバイスプロビジョニングシステム。
【請求項７】
前記ブロックチェーンが、更に、第２の証跡と第２の公開鍵を紐づけて記憶し、
前記プロビジョニングデータ提供手段が、前記プロビジョニングデータに前記第２の公開鍵に対応する第２の秘密鍵による電子署名を付した状態で前記暗号化を行い、
前記通常領域が、前記第２の証跡を更に格納し、
前記プロビジョニング実行手段が、前記公開鍵提供手段への前記第２の証跡を用いた問い合わせによる前記第２の公開鍵の取得と、前記第２の秘密鍵による電子署名の前記第２の公開鍵を用いた検証と、を行うことを特徴とする、請求項１から請求項６の何れかに記載のデバイスプロビジョニングシステム。
【請求項８】
前記公開鍵提供手段を有するデバイス認証サーバと、
前記プロビジョニングデータ提供手段を有するプロビジョニングサーバと、を備えることを特徴とする、請求項１から請求項７の何れかに記載のデバイスプロビジョニングシステム。
【請求項９】
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、プロビジョニング方法であって、
前記デバイスが、
前記デバイスごとに一意である第１の公開鍵に対応する、第１の秘密鍵を格納するセキュア領域と、
前記第１の公開鍵と紐づけられた状態でブロックチェーンに格納される、前記デバイスごとに一意である第１の証跡を格納する通常領域と、を含む記憶部を備えるものであって、
前記デバイスからの前記第１の証跡を用いた問い合わせに基づいて、前記ブロックチェーンより前記第１の公開鍵を取得するステップと、
前記第１の公開鍵によって前記プロビジョニングデータを暗号化し、前記デバイスに送信するステップと、
前記デバイスが、暗号化された前記プロビジョニングデータを前記第１の秘密鍵を用いて復号するステップと、を備えることを特徴とする、プロビジョニング方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】変更
【補正の内容】
【００１５】
上記課題を解決するために、本発明に係るデバイスプロビジョニングシステムは、
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、デバイスプロビジョニングシステムであって、
前記デバイスごとに一意である第１の公開鍵と前記デバイスごとに一意である第１の証跡とを紐づけて格納するブロックチェーンより、前記第１の証跡を用いた問い合わせに応じて前記第１の公開鍵を取得する、公開鍵提供手段と、
前記デバイスからの前記第１の証跡を用いた問い合わせに応じて、前記公開鍵提供手段によって前記第１の公開鍵を取得し、当該第１の公開鍵によって暗号化した前記プロビジョニングデータを前記デバイスに送信する、プロビジョニングデータ提供手段と、を備え、
前記デバイスが、
前記第１の公開鍵に対応する第１の秘密鍵を格納するセキュア領域と、前記第１の証跡を格納する通常領域と、を含む記憶部と、
前記第１の証跡を用いた前記プロビジョニングデータ提供手段への問い合わせによって暗号化された前記プロビジョニングデータを取得し、暗号化された前記プロビジョニングデータを前記第１の秘密鍵を用いて復号する、プロビジョニング実行手段と、を備えることを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】変更
【補正の内容】
【００１７】
本発明の好ましい形態では、デバイスプロビジョニングシステムが、前記ブロックチェーンへの前記第１の公開鍵の登録による前記第１の証跡の取得を行う証跡登録手段を更に備え、
前記デバイスが、前記プロビジョニングデータの提供を受けていない初期状態において、
前記セキュア領域に前記デバイスごとに一意な初回用秘密鍵を、
前記通常領域に前記初回用秘密鍵に対応する初回用公開鍵を含むデバイス識別データを、それぞれ格納した状態であり、
前記プロビジョニングデータ提供手段が、前記デバイスより送信される前記デバイス識別データに基づいた当該デバイスの正当性の検証に成功した場合に、
前記第１の秘密鍵及び前記第１の公開鍵の生成と、
前記証跡登録手段による前記第１の公開鍵の前記ブロックチェーンへの登録による前記第１の証跡の取得と、
前記第１の秘密鍵と、前記第１の証跡と、を含み、前記初回用公開鍵によって暗号化された初回用データの当該デバイスへの送信と、を行い、
前記プロビジョニング実行手段が、前記初回用秘密鍵を用いた暗号化された前記初回用データの復号と、前記第１の秘密鍵の前記セキュア領域への格納と、前記第１の証跡の前記通常領域への格納と、を行うことを特徴とする。
このように、デバイス識別データの正当性の検証に基づいて、初期状態であるデバイスに対してプロビジョニングデータの提供を行うことにより、システムへのデバイスの登録を安全に行うことができる。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
本発明に係るプロビジョニング方法は、
デバイスのプロビジョニングを行うためのプロビジョニングデータをデバイスへ提供し、前記デバイス上での前記プロビジョニングデータの展開を行う、プロビジョニング方法であって、
前記デバイスが、
前記デバイスごとに一意である第１の公開鍵に対応する、第１の秘密鍵を格納するセキュア領域と、
前記第１の公開鍵と紐づけられた状態でブロックチェーンに格納される、前記デバイスごとに一意である第１の証跡を格納する通常領域と、を含む記憶部を備えるものであって、
前記デバイスからの前記第１の証跡を用いた問い合わせに基づいて、前記ブロックチェーンより前記第１の公開鍵を取得するステップと、
前記第１の公開鍵によって前記プロビジョニングデータを暗号化し、前記デバイスに送信するステップと、
前記デバイスが、暗号化された前記プロビジョニングデータを前記第１の秘密鍵を用いて復号するステップと、を備えることを特徴とする。