(57)【要約】【課題】異なる利用者が所有する数多くのＩｏＴ機器に、クライアント証明書を容易に配布可能なシステムを実現する。【解決手段】仮のクライアント証明書を格納した記憶装置を備えるＩｏＴ機器１０と、ＩｏＴ機器１０にクライアント証明書を発行する第１のサーバ２０と、を備え、ＩｏＴ機器１０は、初回起動時に、仮のクライアント証明書を第１のサーバ２０に送信し、第１のサーバ２０は、クライアント証明書に基づくクライアント認証を行い、クライアント認証が成功すると、正式なクライアント証明書を発行してＩｏＴ機器１０に送信し、ＩｏＴ機器１０は、第１のサーバから送信された正式なクライアント証明書によって記憶装置に格納された仮のクライアント証明書を更新する。【選択図】図３
2020113868.tif 000002
【特許請求の範囲】
【請求項１】
電子証明書を発行する第１のサーバと、前記第１のサーバが認証可能な仮の証明書情報を含む第１の電子証明書を格納した証明書記憶装置を備える情報機器と、を備え、
前記情報機器は、初回起動時に前記第１の電子証明書を前記第１のサーバに送信し、
前記第１のサーバは、前記情報機器から送信された前記第１の電子証明書に基づく認証を行い、前記認証が成功すると、正式な証明書情報を含む第２の電子証明書を発行して前記情報機器に送信し、
前記情報機器は、前記第１のサーバから送信された前記第２の電子証明書によって前記証明書記憶装置に格納された前記第１の電子証明書を更新する、
ことを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記情報機器にファームウェアを供給する第２のサーバを備え、
前記情報機器は、少なくとも外部装置との通信を可能にする第１のファームウェアを格納したファームウェア記憶装置を備え、
前記情報機器は、前記第１のサーバから送信された前記第２の電子証明書を前記第２のサーバに送信し、
前記第２のサーバは、前記情報機器から送信された前記第２の電子証明書に基づく認証を行い、前記認証が成功すると、第２のファームウェアを前記情報機器に送信し、
前記情報機器は、前記第２のサーバから送信された前記第２のファームウェアによって前記ファームウェア記憶装置に格納された前記第１のファームウェアを更新する、
ことを特徴とする情報処理システム。
【請求項３】
第１のサーバが認証可能な仮の証明書情報を含む第１の電子証明書を格納した証明書記憶装置と、
初回起動時に、前記第１の電子証明書を前記第１のサーバに提示することによって認証をうけ、当該認証が成功することによって前記第１のサーバから、正式な証明書情報を含む第２の電子証明書を取得する証明書取得手段と、
前記第２の電子証明書によって、前記証明書記憶装置に格納された前記第１の電子証明書を更新する証明書更新手段と、
を備えることを特徴とする情報機器。
【請求項４】
請求項３に記載の情報機器において、
前記証明書取得手段と、前記証明書更新手段と、を含む第１のファームウェアを格納したファームウェア記憶装置を備え、
前記第１のファームウェアは、
前記第２の電子証明書を第２のサーバに提示することによって認証をうけ、当該認証が成功することによって第２のファームウェアを取得するファームウェア取得手段と、
前記ファームウェア記憶装置に格納された前記第１のファームウェアを、前記第２のファームウェアによって更新するファームウェア更新手段と、
を、さらに備えることを特徴とする情報機器。
【請求項５】
情報機器に対して電子証明書を発行するサーバ装置であって、
前記情報機器から仮の証明書情報を含む第１の電子証明書が送信されたときに、送信された前記第１の電子証明書に基づく認証を行う認証手段と、
前記認証手段による認証が成功すると、正式な証明書情報を含む第２の電子証明書を発行して前記情報機器に送信する証明書発行手段と、
を備えることを特徴とするサーバ装置。
【請求項６】
電子証明書を発行する第１のサーバと、前記第１のサーバが認証可能な仮の証明書情報を含む第１の電子証明書を格納した証明書記憶装置を備える情報機器と、を備えた情報処理システムの情報処理方法であって、
前記情報機器は、初回起動時に前記第１の電子証明書を前記第１のサーバに送信し、
前記第１のサーバは、前記情報機器から送信された前記第１の電子証明書に基づく認証を行い、前記認証が成功すると、正式な証明書情報を含む第２の電子証明書を発行して前記情報機器に送信し、
前記情報機器は、前記第１のサーバから送信された前記第２の電子証明書によって前記証明書記憶装置に格納された前記第１の電子証明書を更新する、
ことを特徴とする情報処理方法。
【請求項７】
請求項６に記載の情報処理方法において、
前記情報処理システムは、前記情報機器にファームウェアを供給する第２のサーバを備え、
前記情報機器は、少なくとも外部装置との通信を可能にする第１のファームウェアを格納したファームウェア記憶装置を備え、
前記情報機器は、前記第１のサーバから送信された前記第２の電子証明書を前記第２のサーバに送信し、
前記第２のサーバは、前記情報機器から送信された前記第２の電子証明書に基づく認証を行い、前記認証が成功すると、第２のファームウェアを前記情報機器に送信し、
前記情報機器は、前記第２のサーバから送信された前記第２のファームウェアによって前記ファームウェア記憶装置に格納された前記第１のファームウェアを更新する、
ことを特徴とする情報処理方法。
【請求項８】
認証手段と、証明書発行手段と、を備え、情報機器に対して電子証明書を発行するサーバ装置の証明書発行方法であって、
前記認証手段が、前記情報機器から仮の証明書情報を含む第１の電子証明書が送信されたときに、送信された前記第１の電子証明書に基づく認証を行うステップと、
前記証明書発行手段が、前記認証手段による認証が成功すると、正式な証明書情報を含む第２の電子証明書を発行して前記情報機器に送信するステップと、
を備えることを特徴とする証明書発行方法。
【請求項９】
請求項８に記載の証明書発行方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子証明書の発行方法に関し、特に、ＩｏＴ機器向けに多数の電子証明書を発行するための方法に関する。
【背景技術】
【０００２】
モノのインターネットすなわちＩｏＴ（Internet of Things）と呼ばれる仕組みが注目され、普及が進んでいる。
センサーネットワークとも呼ばれるＩｏＴでは、センサーやカメラを備えた通信機器をネットワークに接続し、インターネットを介して収集したカメラ画像やセンサー情報を用いた様々なサービスが展開されている。
そして、ネットワークインターフェイスを備え、インターネットに接続可能とされた情報機器は一般にＩｏＴ機器と呼ばれる。
ＩｏＴ機器は、様々な場所に設置される性質上、その数も多く、また一度環境内に設置されると手動でのメインテナンスは非常に困難である。
このようなＩｏＴ機器を制御する内蔵ソフトウェア（ファームウェア）の機能追加や不具合修正などの管理を行うために、ファームウェアの更新をオンライン（Over The Air：ＯＴＡ）で行うクラウドサービスが知られている（例えば、特許文献１）。
また、このようなクラウドサービスでは、ＩｏＴ機器がカメラやセンサーによって取得した情報を収集し、データ処理を行うサービスを提供する場合もある。
このようなクラウドサービスを提供するクラウドサーバは、接続してくるＩｏＴ機器を認証する。一般的に、ここで行われる認証は、電子証明書（クライアント証明書）を用いたクライアント認証である。クライアント証明書は、特定の機器にのみサービスへのアクセスを許可する「アクセス制御」等に用いられる。
クライアント証明書をはじめとした「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１８−４１２２４公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のようにＩｏＴ環境が普及するなかで、様々な利用者が夫々多くのＩｏＴ機器を利用している。
クライアント証明書をはじめとした電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、当然、クライアント証明書の所有者、すなわちＩｏＴ機器の利用者によって内容が異なる。
クライアント証明書を発行する認証局では、利用者毎に内容が異なる証明書を大量に発行することは管理上非常に難しい。
またＩｏＴ機器は、セキュアエレメントと呼ばれる安全性が高いチップを内蔵しており、クライアント証明書は、鍵ペア（公開鍵、私有鍵）などとともにセキュアエレメントに格納されている場合がある。その場合、セキュアエレメントにクライアント証明書を書き込んだ後で、セキュアエレメントをＩｏＴ機器に組み込む。
利用者毎に内容が異なる証明書を大量に発行して、夫々の利用者用のセキュアエレメントに書き込む工程は、管理上やはり困難である。
本発明は上記の問題点を鑑みてなされたものであり、異なる利用者が所有する数多くの情報機器（ＩｏＴ機器）に、電子証明書（クライアント証明書）を容易に組み込み可能なシステムを実現することを目的とする。
【課題を解決するための手段】
【０００５】
上記の課題を解決するために、本発明は、電子証明書を発行する第１のサーバと、前記第１のサーバが認証可能な仮の証明書情報を含む第１の電子証明書を格納した証明書記憶装置を備える情報機器と、を備え、前記情報機器は、初回起動時に前記第１の電子証明書を前記第１のサーバに送信し、前記第１のサーバは、前記情報機器から送信された前記第１の電子証明書に基づく認証を行い、前記認証が成功すると、正式な証明書情報を含む第２の電子証明書を発行して前記情報機器に送信し、前記情報機器は、前記第１のサーバから送信された前記第２の電子証明書によって前記証明書記憶装置に格納された前記第１の電子証明書を更新する、情報処理システムを特徴とする。
【発明の効果】
【０００６】
上記のように構成することにより、本発明によれば、異なる利用者が利用する数多くの情報機器（ＩｏＴ機器）に、電子証明書を容易に組み込み可能なシステムを実現することができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態のシステム構成を説明する図である。
【図２】本実施形態のシステムで行われる処理の前提として、ＩｏＴ機器が製造されるまでの工程を説明する図である。
【図３】図２の工程を経て製造されたＩｏＴ機器の初回起動時において、本実施形態のシステムで行われる処理を概説するタイミングチャートである。
【図４】本実施形態のシステムを構成するＩｏＴ機器の機能構成を示す図である
【図５】本実施形態のシステムを構成する証明書発行サーバの構成を示す図である。
【図６】本実施形態のシステムを構成する機器管理サーバの構成を示す図である。
【図７】本実施形態の情報機器のプロセッサが、装置の初回起動時に実行する処理を説明する図である。
【図８】本実施形態の証明書発行サーバのＣＰＵが実行する証明書発行処理を説明するフローチャートである。
【図９】本実施形態のクラウドサーバのＣＰＵが実行する証明書発行処理を説明するフローチャートである。
【発明を実施するための形態】
【０００８】
以下に、図面を参照して本発明の実施の形態を詳細に説明する。
まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することができる一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
【０００９】
[電子証明書]
公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
ＰＫＩでは、例えば、信頼できる第三者機関(ＴＴＰ： Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は持ち主の情報を正しく保障する「身分証明書」である。
電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
【００１０】
電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことができる。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
電子証明書、特にデバイスに組み込まれるクライアント証明書は、デバイスのアクセス制御に用いられる。特定のクライアント証明書を提示しないと、サービスにアクセスできないようにすることで、サービスにアクセス可能なデバイスを制限し、不特定多数によるアクセスを防止してセキュリティを確保することができる。
【００１１】
図１は、本実施形態のシステム構成を説明する図である。
図１に示すように、本実施形態のシステム１は、利用者の利用に係るＩｏＴ機器１０と、ＩｏＴ機器１０に組み込むための電子証明書（クライアント証明書）を発行する、認証局（ＣＡ）に属する証明書発行サーバ（認証局サーバ）２０と、ＩｏＴ機器１０に対してファームウェアの更新や機器の管理機能などのクラウドサービスを提供するクラウドサーバ（機器管理サーバ）３０と、を備える。
証明書発行サーバ２０、クラウドサーバ３０はインターネットに公開されている。またＩｏＴ機器１０は、後述するように例えばＬＴＥ通信モジュールを内蔵しており、通信キャリアのネットワークを通じてインターネットに接続することができる。
従って、ＩｏＴ機器１０は、インターネットを介して証明書発行サーバ２０、クラウドサーバ３０に接続することができる。
これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である（例えば、ＨＴＴＰＳを利用するなど）。
【００１２】
ＩｏＴ機器１０は、工場や一般家庭、企業の構内などに数多く設置され、それ自体でインターネットに接続可能に構成された情報機器である。ＩｏＴ機器１０は、カメラやセンサーなどを備え、取得した情報や画像を外部に送信可能である。送信された情報や画像は、図示しない他のサーバによって収集・解析されて様々な用途に供される。
また、図１に示すように、ＩｏＴ機器は多くの利用者（利用者Ａ、利用者Ｂ・・・）によって利用されている。そして通常、各利用者は複数のＩｏＴ機器を利用している。
例えば利用者Ａが機器Ａ−１、機器Ａ−２、機器Ａ−３・・・を利用し、利用者Ｂが機器Ｂ−１、機器Ｂ−２、機器Ｂ−３・・・を利用する。
これら一つひとつのＩｏＴ機器１０が、内蔵するセキュアエレメント内にクライアント証明書を保持している。ＩｏＴ機器１０は、クライアント証明書を提示することで、クラウドサーバ３０へのアクセスを許可されてファームウェア更新などのサービスを受けることができる。
基本的に、鍵ペア（秘密鍵、公開鍵）及びクライアント証明書は、ＩｏＴ機器一つひとつに対して作成、発行され、発行された一のクライアント証明書には一意のシリアル番号が割り当てられる。
【００１３】
証明書発行サーバ２０は、電子証明書を発行する認証局に属している。上記したように、認証局は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）で用いられる私有鍵の所有者を確認するために用いられる電子証明書を発行する機関である。
特に、本実施形態において証明書発行サーバ２０はクライアント証明書を発行する。
クライアント証明書は、特定の機器にのみサービスへのアクセスを許可する「アクセス制御」等に用いられる。
クライアント証明書をはじめとして、電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されている。
【００１４】
クラウドサーバ３０は、ＩｏＴ機器１０を管理するためのクラウドサービスを提供するサーバであり、上記のように、接続を求めるＩｏＴ機器１０からのアクセスをうけてクライアント証明書を用いたクライアント認証を行う。
クライアント認証を行うことで、不特定多数の機器に接続されることによるセキュリティの問題もさることながら、ファームウェア更新の際、適合しないファームウェアが機器にインストールされることを回避することもできる。
クライアント認証が成功すると、ＩｏＴ機器１０に対して接続を許可し、ファームウェア更新などのサービスを提供する。
【００１５】
なお、本実施形態のシステムの場合のように、複数の利用者が利用するＩｏＴ機器について、利用者毎に異なる内容を有するクライアント証明書を証明書発行サーバ２０（認証局）で発行し、そらに、それらの証明書を夫々の利用者のＩｏＴ機器に間違いなく組み込むことは管理上、非常に困難をうむ。
複数の利用者であっても夫々が多数のＩｏＴ機器を利用して多数の証明書を発行するのではあればコスト上許容できる面があるが、多数の利用者が、それほど多くない数のＩｏＴ機器及び対応するクライアント証明書を必要とする場合、特定の利用者の向けの証明書を対応するＩｏＴ機器用のセキュアエレメントに書き込むための管理コストを許容することが出来ない。
【００１６】
そこで、本実施形態のシステムでは、ＩｏＴ機器のセキュアエレメントには、その製造工程において、利用者別の情報を含まず、証明書発行サーバ２０にのみ接続可能な仮のクライアント証明書を格納しておく。製造工程では、公開鍵の情報以外、利用者の情報をほとんど区別することなく、証明書をセキュアエレメントに書き込んでいけるため、コスト的にも、管理上も非常に有利である。
仮のクライアント証明書は、クラウドサーバ３０で認証されるものではないが、装置の初回起動時に、仮のクライアント証明書に基づいて正式なクライアント証明書を発行することで、クラウドサーバ３０にも接続することができるようになる。
【００１７】
本実施形態のＩｏＴ機器１０は、初回起動時には、証明書発行サーバ２０に接続することしかできず、ＩｏＴ機器１０を制御するファームウェアについても、当初は最低減の機能をもった仮のファームウェアを備える。
ＩｏＴ機器１０は、正式なクライアント証明書を発行されたあとでクラウドサーバ３０に接続し、正式なファームウェアを取得する。
ＩｏＴ機器の製造段階では、機器の種類によらず、最低減の機能を持った共通のファームウェアをインストール可能となることで製造工程を簡略することができるし、正式なファームウェアの提供タイミングを初回起動時まで遅らせることで、ファームウェアの開発時間を長く確保することができるメリットがある。
【００１８】
図２は、本実施形態のシステムで行われる処理の前提としてＩｏＴ機器が製造されるまでの工程を説明する図である。
図２（１）に示すように、セキュアエレメントのベンダ（以下、チップベンダと記載する）におけるセキュアエレメントの製造工程において、利用者の公開鍵に基づいて仮のクライアント証明書が発行される。
公開鍵を含む鍵ペアは、証明書発行サーバ２０に係る認証局で作成されてチップベンダに供給される。基本的に鍵ペアは一のＩｏＴ機器について一組作成される。
クライアント証明書は、利用者の公開鍵に電子署名を付すことで作成されるため、仮のクライアント証明書に含まれる公開鍵は利用者毎に異なっている。
複数のＩｏＴ機器のために発行されるクライアント証明書のシリアル番号（ＳＮ）の所定範囲は特定の利用者に割り当てられ、シリアル番号から利用者が特定可能となっている。
仮のクライアント証明書は、利用者毎にシリアル番号（ＳＮ）が異なるが、証明書の所有者情報や連絡先情報、ＣＡ（認証局）の名前などの情報（証明書情報）はすべて同じに作成されている。
【００１９】
図２（２）に示すように、チップベンダでは、作成した仮のクライアント証明書を、鍵ペア（私有鍵、公開鍵）とともにセキュアエレメントに書き込んでＩｏＴ機器１０の製造工程にまわす。
上記したが、証明書の正式な所有者情報や連絡先情報を記入した正式なクライアント証明書を、セキュアエレメントの製造段階で作成して格納できるのであれば、そのままセキュアエレメントをＩｏＴ機器１０に組み込んでクラウドサーバ３０にアクセスさせることができる。しかしながら、膨大な数のセキュアエレメントを製造するうえで、利用者情報等が異なるクライアント証明書を個別に発行、管理してセキュアエレメントに格納することは難しい。
従って、上記図２（１）、（２）に示すように、セキュアエレメントの製造段階では、シリアル番号（ＳＮ）（と公開鍵）が異なるクライアント証明書を発行して、各セキュアエレメントに格納する。
その後、ＩｏＴ機器１０の初回起動時等に証明書発行サーバ２０にアクセスさせ、クラウドサーバ３０で認証可能なクライアント証明書を発行して、セキュアエレメントに格納させるのである。
【００２０】
本実施形態のシステムにおいて、チップベンダでは、利用者別に、公開鍵以外の利用者情報が異なったクライアント証明書を作成する必要がなく、（公開鍵以外は）同じ利用者情報を有し、シリアル番号のみを異ならせたクライアント証明書を用意すればよいため、利用者毎に証明書を管理するために煩雑な手間をかけることなく、多くの利用者のための大量の証明書発行に対応することができる。
【００２１】
図２（３）に示すように、ＩｏＴ機器等の工場では、図２（ｂ）で準備された、仮のクライアント証明書や鍵ペア（私有鍵、公開鍵）を予め格納してあるセキュアエレメントを機器に組み込む。
また、各ＩｏＴ機器用に用意された初期（仮の）ファームウェアも製造工程においてＩｏＴ機器１０にインストールされる（例えば、記憶領域であるフラッシュＲＯＭ等に格納する）。初期ファームウェアは、ＩｏＴ機器の初回起動時にクラウドサーバ３０から取得される正式なファームウェアに更新される。
従って、図２（３）でインストールされる初期ファームウェアは、ＩｏＴ機器１０が、その機能を十分に果たすためにカメラやセンサーなどのデバイスを制御である必要がなく、最低限、搭載しているＬＴＥ通信モジュールを起動させて、証明書発行サーバ２０に接続可能な程度に作り込まれていればよい。
初期ファームウェアは、フラッシュＲＯＭではなく、セキュアレメントに書き込まれてもよい。この場合、初期ファームウェアは、チップベンダによるセキュアエレメントの製造時に書き込まれてもよい。
【００２２】
なお、図２（３）では機器別に異なる初期ファームウェアがインストールされるように記載されているが、初期ファームウェアは、ＩｏＴ機器１０に共通したファームウェアであってもよい。
同じ種類のＳｏＣを搭載し、且つ初回起動時においてカメラやセンサーなどの周辺デバイスの制御を行わないのであれば、少なくともＬＴＥ通信モジュールを制御可能なファームウェアに共通化することができる。
そのようにすることで、ＩｏＴ機器１０の製造段階で、機器毎にファームウェアの差異を管理する必要がないため、製造工程を大幅に簡略することができるとともにＩｏＴ機器の製造コストを著しく削減することができる。
【００２３】
なお上記したように、本実施形態のＩｏＴ機器１０は、図１のクラウドサーバ３０の管理下にあってファームウェアの更新を受けることができる。
当然、製造時点（出荷時点）で組み込まれている仮のクライアント証明書によっては、クラウドサーバ３０にアクセスしてクライアント認証をうけることが出来ず、ファームウェアの修正や更新を行うことが出来ない。
チップベンダによって書き込まれた仮のクライアント証明書は証明書発行サーバ２０に対するアクセスはできるが、クラウドサーバ３０では認証されないのである。
そして、上記したようにファームウェアも仮のものであるため、ＩｏＴ機器１０はこの時点では十分な機能を発揮することが出来ない。
本実施形態の特徴として、仮のクライアント証明書、仮のファームウェアを備える本実施形態のＩｏＴ機器１０は、初回起動時にこれらを正式なバージョンに更新する処理を行う。
【００２４】
以下に、詳細に説明する。
図３は、図２の工程を経て製造されたＩｏＴ機器の初回起動時に本実施形態のシステムで行われる処理を概説するタイミングチャートである。
上記したように、ＩｏＴ機器１０はＬＴＥ通信モジュールを備えており、随時、インターネットへの接続が可能である。
ステップＳ１において、工場での検品時などに電源が投入されて、ＩｏＴ機器１０が初回起動される。
【００２５】
ステップＳ２において、初期ファームウェアをインストールされているＩｏＴ機器１０は、インターネット経由で証明書発行サーバ２０にアクセスする。この際、仮のクライアント証明書を証明書発行サーバ２０に提示する。
ステップＳ３において、証明書発行サーバ２０はクライアント認証を行う。クライアント認証では、提示された仮の電子証明書が、信頼されたＣＡ（認証局）で発行（署名）されたかどうかが検証される。
この認証局は、証明書発行サーバ２０が係る認証局自体であってよいし、他の認証局（チップベンダ）であってもよい。
仮のクライアント証明書が認証された場合、ステップＳ４において、証明書発行サーバ２０は、アクセスしてきたＩｏＴ機器１０が提示したクライアント証明書のシリアル番号から利用者を識別し、それに基づいて正式な利用者情報を書き込んだ正式なクライアント証明書を発行し直す。
【００２６】
後述するが、証明書発行サーバ２０は、クライアント証明書のシリアル番号を利用者毎に管理しており、提示された仮のクライアント証明書から、そのＩｏＴ機器が属する利用者を特定することができる。
正式なクライアント証明書の発行に際しては、仮のクライアント証明書から公開鍵を取り出し、取り出した公開鍵に対して認証局の署名をすることによりクライアント証明書を発行する。発行された正式なクライアント証明書においてＣＮと呼ばれる利用者情報（証明書の所有者やＣＡの名前など）は利用者固有のものとなっている。
ステップＳ５において、ＩｏＴ機器１０は、発行された正式なクライアント証明書をセキュアエレメントに格納する。
【００２７】
次に、ステップＳ６において、ＩｏＴ機器１０は、インターネット経由でクラウドサーバ３０にアクセスする。この際、ステップＳ５でセキュアエレメントに格納した正式なクライアント証明書をクラウドサーバ３０に提示する。
ステップＳ７において、クラウドサーバ３０は、クライアント認証を行う。クライアント認証では、ＩｏＴ機器１０から提示されたクライアント証明書が、信頼された認証局で発行（署名）され、クライアント証明書が有効であり（失効しておらず）、利用者情報がクラウドサーバ３０に登録されたものであるか、などを検証する。
ここでは、信頼できる認証局とは証明書発行サーバ２０に係る認証局である。
【００２８】
クライアント証明書が認証された場合（クライアント認証が成功した場合）、ステップＳ８において、クラウドサーバ３０は、後述するように利用者別、機器別に前もってアップロードされている最新の（正式の）ファームウェアをＩｏＴ機器１０に送信する。
利用者や装置に紐付けられたクライアント証明書を使った認証によってクラウドサーバにログインすることで、ＩｏＴ機器１０は、クラウドサーバ３０における固有の領域から、装置に適合したファームウェアを取得することができる。
ステップＳ９において、ＩｏＴ機器１０は、正式なファームウェアで仮のファームウェアを更新する。
【００２９】
以下に、本実施形態のシステムを構成する各装置、サーバの構成及び機能を詳細に説明する。
図４は、本実施形態のシステムを構成する情報機器（ＩｏＴ機器）の機能構成を示す図であり、（ａ）はハードウェア構成を示す機能ブロック図、（ｂ）はソフトウェアによる機能構成を示すブロック図である。
図４（ａ）に示すように、ＩｏＴ機器１０は、機器全体の制御を行うファームウェアや各種用途のアプリケーションプログラムを実行するプロセッサ１２と、プロセッサ１２による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）１３と、ファームウェアやその他プログラム、データが格納される記憶部としてのフラッシュメモリ（フラッシュＲＯＭ）１４と、を備えている。
【００３０】
また、ＩｏＴ機器１０は、不図示のアンテナと、例えばＬＴＥによる無線通信を行うためのモデムやベースバンド部を含む無線部（ＬＴＥ通信モジュール）１５と、鍵ペア（秘密鍵、公開鍵）や電子証明書等の重要な情報、データを安全に格納するための上記のセキュアエレメント１６を備えている。ファームウェアは、セキュアエレメント１６に格納されていてもよい。
プロセッサ１２、ＲＡＭ１３、フラッシュＲＯＭ１４、無線部１５は、単一のＳｏＣ（System on Chip）１１として統合されている。セキュアエレメント１６はＳｏＣ１１に統合されていてもよい。
【００３１】
図４（ｂ）に示すように、プロセッサ１２は、本実施形態の処理に関連する機能として、証明書取得処理部５１、証明書格納処理部５２、ファームウェア取得処理部５３、ファームウェア格納処理部５４、通信制御部５５を備えている。
証明書取得処理部５１は、ＩｏＴ機器１０の起動とともに、初期証明書発行サーバ２０にアクセスし、クライアント認証をうけて正式なクライアント証明書を証明書発行サーバ２０から取得する処理を行う処理部である。
証明書格納処理部５２は、証明書取得処理部５１が取得したクライアント証明書を、セキュアエレメント１６に格納する処理を行う処理部である。
ファームウェア取得処理部５３は、クラウドサーバ３０にアクセスし、クライアント認証をうけて正式なファームウェアをクラウドサーバ３０から取得する処理を行う処理部である。
ファームウェア格納処理部５４は、ファームウェア取得処理部５３が取得したファームウェアを、フラッシュＲＯＭ１４あるいはセキュアエレメント１６に格納する処理を行う処理部である。
通信制御部５５は、無線部１５を制御してＩｏＴ機器１０をネットワークに接続するための処理を行う。
証明書取得処理部５１、証明書格納処理部５２は、ファームウェア取得処理部５３、ファームウェア格納処理部５４は、いずれも仮のファームウェアに属する処理部である。通信制御部５５は、仮のファームウェア、正式なファームウェアの双方に属し得る処理部である
【００３２】
図５は、本実施形態のシステムを構成する証明書発行サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図５（ａ）に示すように、証明書発行サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）２１と、ＣＰＵ２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）２２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）２３や不図示のＲＯＭ（Read Only Memory）と、証明書発行サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。
ＨＤＤ２３には、仮のクライアント証明書のシリアル番号と、利用者と、を関連付けた利用者証明書関連付けテーブル（ＴＢＬ）が格納されている。
【００３３】
また、図５（ｂ）に示すように、ＣＰＵ２１は、処理部として、クライアント認証処理部６１と、電子証明書発行処理部６２と、通信制御部６３と、を実行する。
クライアント認証処理部６１は、ＩｏＴ機器１０から、正式なクライアント証明書の発行要求をうけたときに、ＩｏＴ機器１０に対するクライアント認証を行う処理部である。
電子証明書発行処理部６２は、クライアント認証処理部６１による認証が成功した場合に、仮のクライアント証明書に含まれていた公開鍵に基づいて、正式なクライアント証明書を発行する処理部である。
通信制御部６３は、ネットワークＩ／Ｆ２４を制御して証明書発行サーバ２０をネットワークに接続するための処理を行う。
【００３４】
図５（ｃ）は、利用者証明書関連付けテーブル（ＴＢＬ）を示す図である。
図５（ｃ）に示すように、利用者証明書関連付けテーブルには、利用者と、クライアント証明書のシリアル番号が関連づけられて格納されている。利用者証明書関連付けテーブルにおいて、一の利用者に対して割り当てられた範囲のシリアル番号の一つが、その利用者が有する一のＩｏＴ機器のためのクライアント証明書に対応する。
また、利用者証明書関連付けテーブルには、利用者に関して、証明書の所有者情報、連絡先などの情報を格納しておくことができる。
電子証明書発行処理部６２は、図５（ｃ）は、利用者証明書関連付けテーブルに基づいて、シリアル番号から利用者を特定し、テーブルに格納される利用者の情報と、公開鍵を用いてクライアント証明書の発行を行う。
【００３５】
図６は、本実施形態のシステムを構成する機器管理サーバ（クラウドサーバ）の構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
図６（ａ）に示すように、クラウドサーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、クラウドサーバ３０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）３１と、ＣＰＵ３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）３２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）３３や不図示のＲＯＭ（Read Only Memory）と、クラウドサーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。
ＨＤＤ３３には、正式なファームウェアが、利用者毎に管理されて格納されている（図６（ｃ））。
【００３６】
また、図６（ｂ）に示すように、ＣＰＵ３１は、処理部として、クライアント認証処理部７１と、ファームウェア処理部７２と、通信制御部７３を実行する。
クライアント認証処理部７１は、ＩｏＴ機器１０から、正式なファームウェアの要求をうけたときに、ＩｏＴ機器１０に対するクライアント認証を行う処理部である。
ファームウェア処理部７２は、クライアント認証処理部７１による認証が成功した場合に、クライアント証明書に含まれる利用者情報や、アクセスしてきたＩｏＴ機器の情報に基づいて、最新の（正式な）ファームウェアをＩｏＴ機器に提供する処理を行う処理部である。
通信制御部７３は、ネットワークＩ／Ｆ３４を制御してクラウドサーバ３０をネットワークに接続するための処理を行う。
【００３７】
図６（ｃ）は、ＨＤＤ３３におけるファームウェア格納領域を示す図である。
図６（ｃ）に示すように、ＨＤＤ３３には、利用者毎にアカウントに関連づけられたファームウェア格納領域が用意されている。また、利用者毎の格納領域にはＩｏＴ機器毎に最新のファームウェアが格納されている。
ファームウェア処理部７２は、ＨＤＤ３３に格納された最新のファームウェアのなかから利用者、ＩｏＴ機器に基づいて適切なファームウェアを選択し、ＩｏＴ機器１０に提供する（送信する）。
【００３８】
図７は、本実施形態の情報機器のプロセッサが、装置の初回起動時に実行する処理を説明する図である。
ＩｏＴ機器１０のプロセッサ１２は、ＩｏＴ機器１０の電源が投入されると、ステップＳ１０１において、セキュアエレメント１６に格納されている仮のファームウェアを読み出して実行し、起動処理を開始する。
プロセッサ１２は、ステップＳ１０２においてＩｏＴ機器１０の起動処理を完了する。
プロセッサ１２（通信制御部５５）は、ステップＳ１０３において、仮のファームウェア（証明書取得処理部５１）による制御に基づいて、無線部１５（ＬＴＥ通信モジュール）を制御して通信を行い、認証局の証明書発行サーバ２０にアクセスする。
【００３９】
プロセッサ１２（証明書取得処理部５１）は、ステップＳ１０４において、クライアント認証のために、仮の電子証明書を証明書発行サーバ２０に提示する。
プロセッサ１２（証明書取得処理部５１）は、ステップＳ１０５において、認証が成功して正式な電子証明書が発行されたか否かを判定する。
正式な電子証明書が発行されたと判定した場合（ステップＳ１０５でＹｅｓ）、プロセッサ１２（証明書取得処理部５１）は、ステップＳ１０６において、証明書発行サーバ２０から正式な電子証明書を取得する。
そして、プロセッサ１２（証明書格納処理部５２）は、ステップＳ１０７において、正式な電子証明書をセキュアエレメントに書き込む。すなわち、セキュアエレメント１６において、仮の電子証明書を、正式な電子証明書によって更新する。
【００４０】
次に、プロセッサ１２（ファームウェア取得処理部５３）は、ステップＳ１０８において、クラウドサーバ３０にアクセスする処理を行う。
プロセッサ１２（ファームウェア取得処理部５３）は、ステップＳ１０９において、クライアント認証のために、仮の電子証明書をクラウドサーバ３０に提示する。
プロセッサ１２（ファームウェア取得処理部５３）は、ステップＳ１１０において、認証が成功して正式なファームウェアが提示されたか否かを判定する。
正式なファームウェアが提示されたと判定した場合（ステップＳ１１０でＹｅｓ）、プロセッサ１２（ファームウェア取得処理部５３）は、ステップＳ１１１において、クラウドサーバ３０から正式なファームウェアを取得する。
そして、プロセッサ１２（ファームウェア格納処理部５４）は、ステップＳ１１２において、正式なファームウェアをセキュアエレメント１６、あるいはフラッシュＲＯＭ１４に書き込む。すなわち仮のファームウェアを正式なファームウェアによって更新する。
【００４１】
図８は、本実施形態の証明書発行サーバのＣＰＵが実行する証明書発行処理を説明するフローチャートである。
証明書発行サーバ２０のＣＰＵ２１（クライアント認証処理部６１）は、ステップＳ２０１において、ＩｏＴ機器１０から、電子証明書の発行を求めるためのクライアント認証要求があったか否かを判定すする。
クライアント認証要求があったと判定した場合（ステップＳ２０１でＹｅｓ）、ＣＰＵ２１（クライアント認証処理部６１）は、ステップＳ２０２において、ＩｏＴ機器１０によるクライアント認証要求に含まれる仮の電子証明書を検証する。この検証は、仮の電子証明書が信頼できる認証機関によって発行（署名）されているか否かを検証するものである。
仮の電子証明書が信頼できる認証機関で発行されていると判定された場合（ステップＳ２０３でＹｅｓ）、認証は成功する。
そして、ＣＰＵ２１（電子証明書発行処理部６２）は、ステップＳ２０４において、電子証明書のシリアル番号に基づいて利用者を特定し、ステップＳ２０５において、仮の電子証明書から利用者の公開鍵を抽出し、ステップＳ２０６において、ステップＳ２０４で特定した利用者毎の設定に応じた正式な電子証明書を発行する。
【００４２】
図９は、本実施形態のクラウドサーバのＣＰＵが実行する証明書発行処理を説明するフローチャートである。
クラウドサーバ３０のＣＰＵ３１（クライアント認証処理部７１）は、ステップＳ３０１において、ＩｏＴ機器１０から、ファームウェアの提供を求めるためのクライアント認証要求があったか否かを判定すする。
クライアント認証要求があったと判定した場合（ステップＳ３０１でＹｅｓ）、ＣＰＵ３１（クライアント認証処理部７１）は、ステップＳ３０２において、ＩｏＴ機器１０によるクライアント認証要求に含まれる仮の電子証明書を検証する。この検証は、仮の電子証明書が信頼できる認証機関によって発行（署名）されているか否かを検証するものである。
【００４３】
仮のクライアント証明書が信頼できる認証機関で発行されていると判定された場合（ステップＳ３０３でＹｅｓ）、認証は成功する。
そして、ＣＰＵ３１（ファームウェア処理部７２）は、ステップＳ３０４において、電子証明書のシリアル番号に基づいて利用者を特定し、ステップＳ３０５において、利用者と、アクセスしてきたＩｏＴ機器１０の情報に基づいて、ＨＤＤ３３のファームウェア格納領域から適切なファームウェアを選択する。
この場合、クラウドサーバ３０は、図５（ｃ）と同様の利用者証明書関連付けテーブルに加え、クライアント証明書とＩｏＴ機器の機種とを紐付けたテーブルを、データベースに有する必要がある。
そして、ＣＰＵ３１（ファームウェア処理部７２）は、ステップＳ３０６において、ステップＳ３０５で選択したファームウェアをＩｏＴ機器１０に送信する。
【００４４】
上記のように、本実施形態のシステムでは、ＩｏＴ機器に組み込むクライアント証明書を書き込んだセキュアエレメントの製造工程では、仮のクライアント証明書をセキュアエレメントに書き込み、ＩｏＴ機器の初回起動時に、証明書発行サーバにおいて、仮のクライアント証明書に基づいて正式な利用者情報を含むクライアント証明書を発行して、セキュアエレメントのクライアント証明書を正式なものに更新させるようにした。従って、セキュアエレメントの製造時点で、利用者情報が夫々異なった（正式な証明書情報を記載した）正式なクライアント証明書を利用者別に作成する必要がなく、（公開鍵以外）同じ内容でシリアル番号のみが異なった仮のクライアント証明書を用意すればよい。従って、セキュアエレメントの製造時に利用者毎に証明書を管理するために煩雑な手間をかけることなく、多くの利用者のための大量の証明書発行に対応することができる。
【００４５】
また、ＩｏＴ機器の製造時には、仮のファームウェアをインストールしておき、装置の初回起動時に仮のクライアント証明書を正式なクライアント証明書に更新した後で、クラウドサーバ３０に接続してファームウェアを可能としたので、ＩｏＴ機器の製造段階では、最低減の機能を持った共通のファームウェアをインストール可能となり製造工程の簡略化が可能であるとともに、正式なファームウェアの提供タイミングを初回起動時まで遅らせることで、ファームウェアの開発時間を長く確保することができる。
【００４６】
［第１の発明］
電子証明書を発行する第１のサーバ（証明書発行サーバ２０）と、証明書発行サーバ２０が認証可能な仮の証明書情報を含む第１の電子証明書（仮のクライアント証明書）を格納した証明書記憶装置（セキュアエレメント１６）を備える情報機器（ＩｏＴ機器１０）と、を備え、情報機器は、初回起動時に第１の電子証明書を第１のサーバに送信し、第１のサーバは、情報機器から送信された第１の電子証明書に基づく認証を行い、認証が成功すると、正式な証明書情報を含む第２の電子証明書（正式なクライアント証明書）を発行して情報機器に送信し、情報機器は、第１のサーバから送信された第２の電子証明書によって証明書記憶装置に格納された第１の電子証明書を更新する、情報処理システムを特徴とする。
第１の発明の情報処理システムによれば、セキュアエレメントの製造時点で、利用者情報が夫々異なった（正式な証明書情報を記載した）正式なクライアント証明書を利用者別に作成する必要がなく、（公開鍵以外）同じ内容でシリアル番号のみが異なった仮のクライアント証明書を用意すればよい。従って、セキュアエレメントの製造時に利用者毎に証明書を管理するために煩雑な手間をかけることなく、多くの利用者のための大量の証明書発行に対応することができる。
【００４７】
［第２の発明］
第１の発明の情報処理システムにおいて、情報機器にファームウェアを供給する第２のサーバ（クラウドサーバ３０）を備え、情報機器は、少なくとも外部装置との通信を可能にする第１のファームウェア（仮のファームウェア）を格納したファームウェア記憶装置（セキュアエレメント１６又はフラッシュＲＯＭ１４）を備え、情報機器は、第１のサーバから送信された第２の電子証明書を第２のサーバに送信し、第２のサーバは、情報機器から送信された第２の電子証明書に基づく認証を行い、認証が成功すると、第２のファームウェアを情報機器に送信し、情報機器は、第２のサーバから送信された第２のファームウェアによってファームウェア記憶装置に格納された第１のファームウェアを更新する情報処理システムを特徴とする。
第２の発明の情報処理システムによれば、ＩｏＴ機器の製造時には、仮のファームウェアをインストールしておき、装置の初回起動時に仮のクライアント証明書を正式なクライアント証明書に更新した後で、クラウドサーバ３０に接続してファームウェアを可能としたので、ＩｏＴ機器の製造段階では、最低減の機能を持った共通のファームウェアをインストール可能となり製造工程の簡略化が可能であるとともに、正式なファームウェアの提供タイミングを初回起動時まで遅らせることで、ファームウェアの開発時間を長く確保することができる。
【００４８】
［第３の発明］
第１のサーバ（証明書発行サーバ２０）が認証可能な仮の証明書情報を含む第１の電子証明書（仮のクライアント証明書）を格納した証明書記憶装置（セキュアエレメント１６）と、初回起動時に、第１の電子証明書を第１のサーバに提示することによって認証をうけ、当該認証が成功することによって第１のサーバから、正式な証明書情報を含む第２の電子証明書（正式なクライアント証明書）を取得する証明書取得手段（証明書取得処理部５１）と、第２の電子証明書によって、証明書記憶装置に格納された第１の電子証明書を更新する証明書更新手段（証明書格納処理部５２）と、を備える情報機器を特徴とする。
第３の発明の情報機器によれば、セキュアエレメントの製造時点で、利用者情報が夫々異なった（正式な証明書情報を記載した）正式なクライアント証明書を利用者別に作成する必要がなく、（公開鍵以外）同じ内容でシリアル番号のみが異なった仮のクライアント証明書を用意すればよい。従って、セキュアエレメントの製造時に利用者毎に証明書を管理するために煩雑な手間をかけることなく、多くの利用者のための大量の証明書発行に対応することができる。
【００４９】
［第４の発明］
第３の発明の情報機器において、証明書取得手段（証明書取得処理部５１）と、証明書更新手段（証明書格納処理部５２）と、を含む第１のファームウェア（仮のファームウェア）を格納したファームウェア記憶装置（セキュアエレメント１６又はフラッシュＲＯＭ１４）を備え、第１のファームウェアは、第２の電子証明書を第２のサーバ（クラウドサーバ３０）に提示することによって認証をうけ、当該認証が成功することによって第２のファームウェアを取得するファームウェア取得手段（ファームウェア取得処理部５３）と、ファームウェア記憶装置に格納された第１のファームウェアを、第２のファームウェアによって更新するファームウェア更新手段（ファームウェア格納処理部５４）と、を、さらに備える情報機器を特徴とする。
第４の発明の情報機器によれば、ＩｏＴ機器の製造時には、仮のファームウェアをインストールしておき、装置の初回起動時に仮のクライアント証明書を正式なクライアント証明書に更新した後で、クラウドサーバ３０に接続してファームウェアを可能としたので、ＩｏＴ機器の製造段階では、最低減の機能を持った共通のファームウェアをインストール可能となり製造工程の簡略化が可能であるとともに、正式なファームウェアの提供タイミングを初回起動時まで遅らせることで、ファームウェアの開発時間を長く確保することができる。
【００５０】
［第５の発明］
情報機器（ＩｏＴ機器１０）に対して電子証明書を発行するサーバ装置（電子証明書発行サーバ２０）であって、情報機器から仮の証明書情報を含む第１の電子証明書（仮のクライアント証明書）が送信されたときに、送信された第１の電子証明書に基づく認証を行う認証手段（クライアント認証処理部６１）と、認証手段による認証が成功すると、正式な証明書情報を含む第２の電子証明書（正式なクライアント証明書）を発行して情報機器に送信する証明書発行手段（電子証明書発行処理部６２）と、を備えるサーバ装置を特徴とする。
第５の発明のサーバによれば、セキュアエレメントの製造時点で、利用者情報が夫々異なった（正式な証明書情報を記載した）正式なクライアント証明書を利用者別に作成する必要がなく、（公開鍵以外）同じ内容でシリアル番号のみが異なった仮のクライアント証明書を用意すればよい。従って、セキュアエレメントの製造時に利用者毎に証明書を管理するために煩雑な手間をかけることなく、多くの利用者のための大量の証明書発行に対応することができる。
【符号の説明】
【００５１】
１０…ＩｏＴ機器、１１…ＳｏＣ、１２…プロセッサ、１３…ＲＡＭ、１４…フラッシュＲＯＭ、１５…無線部、１６…セキュアエレメント、２０…証明書発行サーバ、２１…ＣＰＵ、２２…ＲＡＭ、２３…ＨＤＤ、２４…ネットワークＩ／Ｆ、３０…クラウドサーバ、３２…ＲＡＭ、３１…ＣＰＵ、３３…ＨＤＤ、３４…ネットワークＩ／Ｆ、５１…証明書取得処理部、５２…証明書格納処理部、５３…ファームウェア取得処理部、５４…ファームウェア格納処理部、６１…クライアント認証処理部、６２…電子証明書発行処理部、７１…クライアント認証処理部、７２…ファームウェア処理部
【図１】
2020113868.tif 000003
【図２】
2020113868.tif 000004
【図３】
2020113868.tif 000005
【図４】
2020113868.tif 000006
【図５】
2020113868.tif 000007
【図６】
2020113868.tif 000008
【図７】
2020113868.tif 000009
【図８】
2020113868.tif 000010
【図９】
2020113868.tif 000011