JP2018117185A - 情報処理装置、情報処理方法 - Google Patents

Abstract

【課題】 従来よりも簡単な処理ステップで、なりすましの困難なデバイス認証を実現するための技術を提供すること。【解決手段】 RTMコードを実行することで、秘密情報及び公開鍵を記憶するExtend処理と、ブートローダの実行を開始するブート処理と、を実行する。セキュリティ処理は、ハッシュ値に対して秘密鍵で署名処理を行って、ディジタル署名を生成する処理である。【選択図】 図１

Description

本発明は、デバイス認証技術に関するものである。

近年、カメラやスマートフォンなどの組み込みデバイスが、ネットワークに接続してサーバが提供するサービスと連携するケースが増加している。これまでの汎用PCでのサービス接続では、サービス要求ユーザをパスワードなど用いて認証してきた。しかしながら、サーバが要求元のデバイス（例えばデバイスのモデルや製品構成）の正当性に基づいてサービス要求元を認証したい場合には、デバイス認証と呼ばれる異なる技術が必要である。

デバイスを認証する技術の一つとして、TCGが策定するAttestation (構成証明)がある。当該技術によれば、デバイスはモジュールのロード時に計測したハッシュ値をTPM内のPCRに保存（Extend処理）することで、デバイスのシステム構成が正当であることを主張する。つまり、サーバに対してAIK(Attestation Identity Key)鍵ペアを使ってディジタル署名を送信することで、サーバは正当なデバイスからリクエストが届いていることを検証できる。

或いは、SCEP (Simple Certificate Enrollment Protocol)と呼ばれるプロトコルでは、デバイスの公開鍵に対する証明書要求に付随してパスワードを送付する。認証局は、パスワードに基づいてデバイス証明書の発行可否を判断する。つまり、本技術では、ユーザが入力したパスワードに基づいてデバイスの正当性を検証してデバイス証明書を発行している。

TCG Attestation SCEP

TCGによるAttestationでは、PCRに署名したAIK (Attestation Identity Key) 鍵ペアの検証が必要になるため、AIK鍵ペアに対する証明書発行が必要になる。AIK鍵ペアに対する証明書発行プロトコルとしてはAIK Certificate Enrollmentと呼ばれるプロトコルが公開されており、個々のデバイスに対して証明書発行の煩雑な処理が必要である。加えて、AIK Certificate Enrollmentでは、TPMに保存されたEK (Endorsement Key) 証明書（或いは、TPM証明書とも呼ばれる）が必要であるが、EK証明書が初期状態では設定されていないTPMも多い。この場合には、EK証明書を手動で生成するための煩雑な手続きがさらに必要になる。

一方、SCEPでは、ユーザの入力するパスワードに応じて証明書を発行しているため、デバイスのなりすましが可能であるという問題点がある。つまり、パスワードが第三者に漏えいした場合には、不正な証明書発行が行われてしまう。或いは、本来の意図とは異なるデバイスに対するCSRに対して正当なパスワードを付与して証明書発行要求を行った場合には、不正なデバイスに対する証明書の発行が行われてしまう。つまり、デバイスのなりすましが容易である。

本発明はこのような問題に鑑みてなされたものであり、従来よりも簡単な処理ステップで、なりすましの困難なデバイス認証を実現するための技術を提供する。

本発明の一様態は、公開鍵と秘密鍵とのペアである鍵ペア、及び秘密情報を用いたセキュリティ処理を行う情報処理装置であって、秘密情報及びRTMコードを保持する第１の保持手段と、起動信号に応じて前記RTMコードを実行する起動処理手段と、データのハッシュ値を保持する第２の保持手段と、ブートローダ及びシステムの起動イメージを保持する第３の保持手段とを備え、前記起動処理手段は前記RTMコードを実行することで、前記秘密情報及び前記公開鍵を前記第２の保持手段へ記憶するExtend処理と、前記第３の保持手段からロードしたブートローダの実行を開始するブート処理と、を実行し、前記セキュリティ処理は、前記第２の保持手段に保存されたハッシュ値に対して前記秘密鍵で署名処理を行って、ディジタル署名を生成する処理であることを特徴とする。

本発明の構成によれば、従来よりも簡単な処理ステップで、なりすましの困難なデバイス認証を実現することができる。

システムの構成例を示すブロック図。 メッセージ交換のシーケンスを示す図。 セキュアブート処理の一例を示すフローチャート。 メッセージの検証を行う処理の一例を示すフローチャート。 ソフトウェア構成の一例を示す図。 ソフトウェア構成の一例を示す図。 コンピュータ装置のハードウェア構成例を示すブロック図。

以下、添付図面を参照し、本発明の実施形態について説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の１つである。

［第１の実施形態］
以下の説明では、暗号化、復号、ハッシュ処理などを以下のような記法で記載し、以降では、暗号技術に関連する処理及びデータを以下の記述規則によって記載する。暗号化処理C = Enc(K,P) は、秘密鍵Kを使って平文Pを暗号化して暗号文Cを取得する処理である。秘密鍵Kは対称鍵暗号方式の鍵でもよいし、非対称鍵暗号鍵方式の鍵（通常は公開鍵）でもよい。復号処理 P = Dec(K,C)は、鍵Kを使って暗号文Cを復号して平文Pを得る処理である。ここで、RSAなどの非対称鍵暗号方式では、Kは通常は秘密鍵である。署名処理S = Sign(K,D)は、データDに対して鍵ペアKの秘密鍵で署名処理してディジタル署名Sを得る処理である。 Mac (Message Authentication Code)の生成処理はS = Mac(K,D)と記述し、これは秘密鍵KでデータDへのMac値Sを取得する処理である。ディジタル署名及びMac値の検証処理はVerify(K,S)と記述する。この検証処理は、Sがディジタル署名の場合はKはRSA鍵ペアKの公開鍵、SがMac値の場合にはMac値の生成に利用した秘密鍵KによってSの完全性を検証する処理である。検証処理の結果は成功或いは失敗となる。一方で、暗号化されたデータについて、{Data}Kは鍵KでDataが暗号化されていることを示す。KがRSAなどの非対称鍵暗号方式の場合には、鍵ペアKの公開鍵で暗号化されていることを示す。また、演算子”|”はデータの連結を表し、さらにハッシュ関数内の”||“はハッシュ処理の連鎖を表す。つまり、Hash(D1||D2) = Hash( Hash(D1) | D2 ) である。

一方、データの記載方法についてはRSAなどの非対称鍵暗号アルゴリズムを利用した署名データは{Data}K^1と示し、Dataが鍵ペアKの秘密鍵で署名（暗号化）されていることを示す。最後に、Cert{ID,K}caは、CAによって発行された証明書であり、公開鍵Kを保持する主体がIDで示される主体(例えばURL)であることをCAが証明していることを示す。

［第１の実施形態］
＜システムの構成＞
先ず、PC（パーソナルコンピュータ）やスマートフォンに代表される情報処理装置に係るデバイス認証を行うためのシステムの構成例について、図１のブロック図を用いて説明する。図１に示す如く、本実施形態に係るシステムは、認証要求を行う情報処理装置としてのデバイス１０１と、デバイス１０１を認証する認証サーバ１０２と、を有する。本システムの目的は、認証サーバ１０２がデバイス１０１を認証し、デバイス１０１が正当なデバイスと認証された場合に限って、該デバイス１０１に対してサービスを提供することである。このような認証が必要となるサービスの例としては、正当なデバイスにのみ証明書を発行する証明書発行サービス、或いは正当なデバイスにのみ更新ファームウェアを提供するシステムアップデートサービスが挙げられる。これにより、認証サーバ１０２はデバイス１０１の正当性をより厳密に検証することが可能となる。

デバイス１０１は認証サーバ１０２からのサービスを利用するために、デバイス１０１のネットワーク処理部１１０及び認証サーバ１０２のネットワーク処理部１１４を介して、認証サーバ１０２とのデータ通信を行う。データ通信はイーサネット等の有線LANなどを介して行ってもよいし、無線LAN技術を利用してもよい。認証に必要なメッセージの交換シーケンスは後述する。

デバイス１０１は、一般に使われる汎用PC、モバイルフォンやスマートフォンなどの計算装置で実現することが可能である。これらの計算装置におけるソフトウェア構成の一例について図５のブロック図を用いて説明する。図５において、App 501はユーザ権限で実行される１つ以上のアプリケーションであり、Rich OS 502はシステム権限で実行されるOS (Operating System)である。Hardware TPM５０３は、計算装置に搭載されたセキュリティチップである。TPMの仕様については、TCG (Trusted Computing Group)によって公開されており、公知であるため説明は省略する。OSは周辺機器やメモリ等のデバイスの管理を行い、アプリケーションに対してデバイスの機能を抽象化して利用できる環境を提供する。なお、デバイス１０１と認証サーバ１０２とは全く同じ構成であることに限らない。

＜デバイス１０１＞
図１を用いて、デバイス１０１の構成例について説明する。セキュアROM１０４は、認証サーバ１０２と事前に共有した秘密情報Ks及びデバイス１０１の起動時に実行されるRTMコード（Root of Trust for Measurement）が保存された不揮発メモリである。秘密情報Ksはデバイス１０１と認証サーバ１０２との間でだけ安全に共有される鍵である。RTMコードは、例えばBIOSやUEFIなどの初期実行コード、或いは組み込みデバイスのBoot ROMに保存される特殊な実行ソフトウェアである。セキュアROM１０４は、攻撃者からの不正な読み出しを防止するために、機密性を提供する耐タンパな実装となっていることが望ましい。例えば、CPUやGPUを集積したアプリケーションプロセッサ（SoC）上に実装されたOn Chip ROMである。

フラッシュROM１０５は、初期実行コードであるRTMコードから呼び出されるブートローダや、OS（Operating System）などのシステムを含んだ起動イメージが保存された不揮発メモリである。

起動処理部１０３は、起動信号を受けると、システムの起動処理を開始する。起動信号は不図示のボタン入力によって起動処理部１０３に入力されても良いし、仮想化技術などにおけるソフトウェアで実現された信号処理によって起動処理部１０３に入力されても良い。起動信号を受けると、起動処理部１０３はセキュアブート処理を開始する。セキュアブート処理では先ず、RTMコードの実行によるデバイス周辺機器の初期化が行われる。続いて、セキュアROM１０４から読み出された秘密情報KsについてExtend処理が行われる。さらに、セキュリティ処理部１０７内部に保持された鍵ペアDevKの公開鍵についてExtend処理が行われる。鍵ペアDevKとは、デバイス１０１で管理される非対称鍵暗号アルゴリズム(例えばRSA)の鍵ペアであり、公開鍵DevK_pubと秘密鍵DevK_priとで構成される。鍵ペアDevKはデバイス毎に異なるものであり、特に秘密鍵DevK_priは当該デバイス内でだけ安全に保持される。Extend処理とは、PCR記憶部１０８（PCR）に記憶されているハッシュ値（PCR値）を入力データDを使って更新する処理であり、Hn+1=Hash(Hn | D)のようにしてPCR記憶部１０８に記憶されているハッシュ値を更新する処理である。ここで、Hash()関数はSHA1などの一方向性のハッシュ処理であり、Hnは現在のPCRが保持するハッシュ値であり、Hn+1はExtend処理のハッシュ結果を指す。続いて起動処理部１０３は、フラッシュROM１０５から読み出したブートローダの実行を開始する。ブートローダの実行により、フラッシュROM１０５から読み出された起動イメージはOS実行部１０６にロードされ、OSの実行が開始される。

セキュリティ処理部１０７は、デバイス認証に必要なセキュリティ情報を管理する。セキュリティ処理部１０７の一つの実現形態はTPM（Trusted Platform Module）チップである。TPMはハードウェアチップとしての実装でもよいし、ソフトウェアで実現された機能でもよい。

PCR記憶部１０８は、前述のExtend処理によって更新されるハッシュ値（PCR値）を記憶するＲＡＭである。認証データ生成部１０９は、OS実行部１０６からの要求に基づいてPCR記憶部１０８に記憶されたハッシュ値に対してDevKの秘密鍵でディジタル署名処理（Sign(DevK, PCR)）（式におけるPCRはPCR値を表す）を行う。不揮発性メモリ１１１は、デバイス鍵の鍵ペアDevKを安全に管理し、許可された条件下においてDevKの公開鍵及び秘密鍵の利用を可能にする。許可された条件とは、例えばPCR記憶部１０８が保持するハッシュ値が特定の値である場合に限って、秘密鍵の利用を許可する等が挙げられる。

OS実行部１０６は、起動処理部１０３から渡されたOSのシステムイメージ（カーネルやRAMDISK）を使ってシステムをブートする。また、OS実行部１０６は、認証データ生成部１０９と連携してネットワーク処理部１１０を介して認証サーバ１０２と通信を行う。つまり、OS実行部１０６は、認証データ生成部１０９から受け取った認証データをネットワーク処理部１１０に渡し、認証サーバ１０２がこの認証データを参照してデバイス１０１の正当性を検証する。デバイス認証に係るメッセージ交換に関する詳細は後述するが、認証データ生成部１０９はOS実行部１０６から渡されたチャレンジデータNaと、PCR記憶部１０８に保持されたハッシュ値と、に対してDevKの公開鍵で署名する。つまり、チャレンジデータNaに対して以下のようにして認証子を生成する。

{Na, Hash(Ks||DevK)}DevK^1 = Sign(DevK, (Na, Hash(Ks||DevK))
ネットワーク処理部１１０は、OS実行部１０６からの要求に応じて認証サーバ１０２（ネットワーク処理部１１４）との間でメッセージ交換を行う。

＜認証サーバ１０２＞
図１を用いて、認証サーバ１０２の構成例について説明する。認証サーバ１０２は、デバイス１０１からのリクエストを受けて、認証されたデバイスにのみサービスを提供する認証サーバである。

Ks記憶部１１２は、デバイス１０１とあらかじめ共有した秘密情報Ksを安全に保持する。Ks記憶部１１２は、DRAMに代表される不揮発性メモリでもよいし、スマートカードに代表される耐タンパ性のある記録メディアでもよい。スマートカードに記憶する場合には、秘密情報Ksを認証処理部１１３に直接渡すことなく、そのハッシュ値Hash(Ks)を認証処理部１１３に渡す。

認証処理部１１３は、ネットワーク処理部１１４を介してデバイス１０１から受け取った認証子を認証し、該認証に成功した場合には、デバイス１０１にサービスを提供する。認証処理部１１３による認証処理の詳細については後述する。

ネットワーク処理部１１４は、NICに代表される認証サーバ１０２のネットワークインターフェースであり、デバイス１０１（ネットワーク処理部１１０）との間のデータ通信を行うためのものである。ネットワーク処理部１１４は、例えば、認証処理部１１３から渡されたデータを使ったデバイス１０１とのメッセージ交換を行う。

＜認証シーケンス図＞
次に、デバイス１０１がデバイス証明書を取得するユースケースにおけるデバイス１０１と認証サーバ１０２との間のメッセージ交換のシーケンスについて、図２のシーケンス図を用いて説明する。図２に示したメッセージ交換は、デバイス１０１のネットワーク処理部１１０と認証サーバ１０２のネットワーク処理部１１４との間で行われる。

ステップＳ２０１では、起動処理部１０３は、セキュアブート処理によってシステムを起動する。ここで重要なのは、ステップＳ２０１の終了後においてＰＣＲ記憶部１０８のPCRが保持する値は、正常なハッシュ値Hash(Ks||DevK_pub)である、ということである。つまり、ステップＳ２０１の処理前におけるPCR値は初期値（例えば0x00000000）であるが、ステップＳ２０１の終了後におけるPCR値はHash(Ks||DevK_pub)となっている。

次にステップＳ２０２では、デバイス１０１は、認証サーバ１０２にデバイス証明書を発行してもらうためのメッセージを作成する。具体的には、ＯＳ実行部１０６は、デバイス１０１の識別子DevID（例えばシリアル番号やモデル番号）を何れかのメモリから取得し、該識別子DevIDを、ネットワーク処理部１１０を介して認証サーバ１０２に送信する。なお、以降の説明では、デバイス１０１と認証サーバ１０２との間の通信経路はSSLや専用線を用いて保護されているものとし、ネットワーク上でのメッセージの改ざんや挿入は考慮しないものとする。SSL通信においてデバイス１０１から認証サーバ１０２に対してセキュアな通信チャネルを開始する方法に関しては公知であるため、説明を省略する。

ステップＳ２０３で認証処理部１１３は、デバイス１０１から送信された識別子DevIDをネットワーク処理部１１４を介して受信すると、送信元であるデバイス１０１の正当性を検証するために乱数Naを生成する。そして認証処理部１１３は、該生成した乱数Ｎａをチャレンジデータとしてデバイス１０１に送信する。

ステップＳ２０４では、認証データ生成部１０９は、ネットワーク処理部１１０を介して認証サーバ１０２から受信したチャレンジデータNaを、鍵ペアDevKの秘密鍵で署名し、認証子を生成する。つまり、認証データ生成部１０９は署名処理により {Na, PCR}DevK^-1 = Sign(DevK_pri,(Na, PCR))を生成する。ここで、PCRは上記のステップＳ２０１のセキュアブート処理で設定されたハッシュ値を保持しており、PCR=Hash(Ks || DevK_pub)である。署名後、ネットワーク処理部１１０は、{Na, PCR}DevK^-1、PCR、DevK_pub、DevIDをメッセージとして認証サーバ１０２に対して送信する。ここで、認証サーバ１０２に送信されるメッセージにはDevK_pubに対する証明書が含まれていないことに注意されたい。認証サーバ１０２はDevK_pubの正当性をPCRに含まれるハッシュ値を元に検証する。認証サーバ１０２における署名の検証処理の詳細については後述する。

ステップＳ２０５では、認証処理部１１３は、デバイス１０１から受け取ったメッセージを検証し、検証に成功した場合にはデバイス１０１に対してデバイス証明書を発行する。

ステップＳ２０６では、ＯＳ実行部１０６は、認証サーバ１０２から受け取った証明書をフラッシュROM１０５などの不揮発性のストレージに保存する。

＜セキュアブート処理＞
図２のステップＳ２０１において行われるセキュアブート処理の一例について、図３のフローチャートを用いて説明する。本セキュアブート処理の目的は、デバイス１０１内のPCR記憶部１０８に、認証サーバ１０２がデバイス認証できる認証子を設定することである。

ステップＳ３０１では、起動処理部１０３は、デバイス１０１の電源ONやソフトウェアイベントに応じて発生する起動信号を受け取る。ステップＳ３０２では、起動信号を受け取った起動処理部１０３は、セキュアROM１０４からRTMコードを読み出して実行することで、デバイス１０１に接続された周辺機器の初期化処理などを実行する。

ステップＳ３０３では、起動処理部１０３は、フラッシュROM１０５からブートローダ及び起動イメージを読み出して実行することで、完全性の検証を行う。ここで、完全性の検証とは、ブートローダや起動イメージの改ざんを検出するための処理である。完全性はハッシュ値、Mac(Message Authentication Code)値或いはディジタル署名を使って検証することが可能である。ハッシュ値を用いる場合には、セキュアROM１０４に保存されたハッシュ値と起動イメージのハッシュ値とを比較することによって検証を行う。同様にMac値を利用する場合には、Mac鍵をセキュアROM１０４に保存しておき、起動イメージから計算されたMac値がフラッシュROM１０５に保存されたMac値と等しいことを検証する。或いは、ディジタル署名の場合には、検証用の公開鍵をセキュアROM１０４に保存しておき、フラッシュROM１０５に保存されたディジタル署名値が起動イメージに付与された署名と等しいことを確認する。また、完全性の検証は、RTMコードがブートローダ、起動イメージ両方の完全性を検証してもよいし、RTMコードがブートローダの完全性を検証し、続いてブートローダが起動イメージの完全性を検証する、というように検証を連鎖させてもよい。

ステップＳ３０３における起動イメージの完全性検証に失敗した場合(ステップＳ３０４でNo)には、処理はステップＳ３０５に進み、起動処理部１０３は起動処理を中止する。一方、完全性検証に成功した場合(ステップＳ３０４でYes)には、処理はステップＳ３０６に進み、RTMコードの実行を継続する。

ステップＳ３０６において起動処理部１０３は、デバイス１０１に設定されたデバイス認証子生成モードを取得する。デバイス認証子生成モードとは、例えば、ジャンパースイッチ、ユーザ入力のボタン、或いは基板に入力された電気信号から設定されるモード値である。あらかじめ定められたボタンを押し続けた起動処理や、特殊な装置が入力ピンに接続された状態でのデバイス１０１の起動処理であると理解されたい。デバイス認証子生成モードが設定されていない場合(ステップＳ３０６でNo)には、処理はステップＳ３１１に進む。ステップＳ３１１では、起動処理部１０３は、通常の起動処理シーケンスとして、ブートローダに制御を渡して起動イメージの実行を開始する。

一方で、デバイス認証子生成モードが設定されている場合(ステップＳ３０６でYes)、処理はステップＳ３０７に進み、ステップＳ３０７では、起動処理部１０３は、RTMコードの実行により、セキュアROM１０４から秘密情報Ksを読み込む。

ステップＳ３０８では、起動処理部１０３は、秘密情報Ksを使ってExtend処理を行い、PCR記憶部１０８のハッシュ値を更新する。つまり、PCR記憶部１０８が保持するハッシュ値H1は、H0を初期値とするとH1=Hash(H0|Ks)となる。

ステップＳ３０９では、起動処理部１０３は、不揮発性メモリ１１１からDevKの公開鍵DevK_pubを取得してExtend処理を行う。これにより、ＰＣＲ記憶部１０８のPCRはHash(Ks||DevK_pub)を保持することになる。

ここで、ステップＳ３０７〜Ｓ３０９においてPCRにExtend処理を行う順序は変更可能である。つまり、認証サーバ１０２における検証処理と同じであればPCRに設定される値はHash(DevK_pub||Ks)でもよい。さらに、鍵ペアDevKは本実施形態のようにセキュリティ処理部１０７内の不揮発性メモリ１１１に保存されてもよいし、フラッシュROM１０５に暗号化された状態（{DevK}Ksの形式）で保存してもよい。ここで重要なことは、鍵ペアDevKの機密性、特にDevKの秘密鍵DevK_priの機密性を実現できることである。セキュリティ処理部１０７が耐タンパ性を持つTPMチップなどで実現される場合には、不揮発性メモリ１１１に鍵ペアを保存することでDevKの機密性が確保される。一方、{DevK}Ksの形式でフラッシュROM１０５に保存する場合には、秘密情報Ksで暗号化することにより、耐タンパ性のないフラッシュメモリにおいても機密性を確保することが可能である。さらに、ステップＳ３０９において、鍵ペアDevKが存在しない場合には、本ステップにおいて鍵ペアDevKの生成処理を行ってもよい。この場合には、生成した鍵ペアDevKをExtend処理するとともに、不揮発性メモリ１１１或いはフラッシュROM１０５に保存する。

ステップＳ３１０で起動処理部１０３は、秘密情報Ksが後のブート処理において読みだされることを防止するために、秘密情報KsをセキュアＲＯＭ１０４から消去する。これにより、秘密情報Ksがデバイス１０１に対する静的解析による攻撃によって漏えいしないように保護する。或いは、秘密情報Ksがデバイス１０１の起動中に（不図示の）作業用メモリから読みだされることを防止するために、秘密情報Ksを作業用メモリから消去する。これにより、秘密情報Ksがデバイス１０１に対する動的解析による攻撃によって漏えいしないように保護する。

以上説明したステップＳ３０７〜Ｓ３１０の一連の処理ステップによってPCR記憶部１０８に適切なハッシュ値を記憶した後、ステップＳ３１１では、起動処理部１０３は、RTMコードから制御をブートローダに渡してデバイス１０１を起動する。

以上、デバイス１０１におけるセキュアブート処理の一例を示した。なお、鍵ペアDevKの公開鍵のExtend処理は、例えばブートローダ内部で行うことも可能である。しかしながら、デバイス１０１の起動処理のより早い段階でPCR記憶部１０８に正当なハッシュ値Hash(Ks||DevK_pub)を設定することは、本セキュリティシステムに対する攻撃をより困難にさせることが可能である。

＜検証処理＞
図２のステップＳ２０５において行われる、デバイス１０１から送られたメッセージの検証を行う処理の一例について、図４のフローチャートを用いて説明する。この検証処理によって、認証サーバ１０２は、デバイス１０１が正当なシステムとして起動し、DevKの鍵ペアを保持していることを検証することができる。

上記のステップＳ２０４の後、デバイス１０１から{Na, PCR}DevK^-1, PCR, DevK_pub, DevIDを受け取った認証サーバ１０２の認証処理部１１３は、これらのメッセージの正当性の検証を開始する。また、チャレンジデータNaは認証サーバ１０２が生成したデータであるので、このデータを保持しているものとする。

ステップＳ４０１では、認証処理部１１３は、署名値{Na, PCR}DevK^-1の正当性をDevK_pubで検証する。つまり、認証処理部１１３は、Verify(DevK, {Na, PCR}DevK^-1)を実行する。ステップＳ４０１の処理の結果、Na及びPCR値が改ざんされていないこと、加えてこのデータを送信したデバイス１０１がDevKの鍵ペアを保持することの２つを検証することができる。

ステップＳ４０１における検証に失敗した場合(ステップＳ４０２でNo)、処理はステップＳ４０３に進み、ステップＳ４０３では、認証処理部１１３は、署名検証に失敗したものとして処理を中止する。一方、ステップＳ４０１における検証に成功した場合(ステップＳ４０２でYes)、処理はステップＳ４０４に進む。

ステップＳ４０５では、認証処理部１１３は、チャレンジデータNaの値の正当性を検証する。この検証では、チャレンジデータNaの値が、ステップＳ２０３においてデバイス１０１に送信した値と同値であることを検証する。またこの検証では、チャレンジデータNaが、過去一定の時間内に送信されたデータであることを確認する。

チャレンジデータNaの値が、デバイス１０１に送信した値と同値ではなかった場合(ステップＳ４０５でNo)、処理はステップＳ４０３に進み、ステップＳ４０３では、認証処理部１１３は、再送攻撃などの不正になり、デバイス認証を失敗とする。一方、チャレンジデータNaの値が、デバイス１０１に送信した値と同値である場合（検証に成功した場合）(ステップＳ４０５でYes)、処理はステップＳ４０６に進む。

ステップＳ４０６では、認証処理部１１３は、Ks記憶部１１２から秘密情報Ksを読み出し、該読み出した秘密情報Ksと、デバイス１０１から送られてきたDevK_pubと、を用いてそのハッシュ値Hash(Ks||DevK_pub)を生成する。そして認証処理部１１３は、該生成したHash(Ks||DevK_pub)が、デバイス１０１から送信されてきたPCR値と等しいことを確認する。

この確認の結果、生成したHash(Ks||DevK_pub)が、デバイス１０１から送信されてきたPCR値と等しくない場合(ステップＳ４０７でNo)、処理はステップＳ４０３に進む。ステップＳ４０３では、認証処理部１１３は、デバイス１０１は定められたセキュアブート処理を経て起動していないことになるため、デバイス認証を失敗とする。つまり、デバイス１０１は不正な改変が加えられているか、正当な鍵ペアDevKを保持していないことになる。

一方、生成したHash(Ks||DevK_pub)が、デバイス１０１から送信されてきたPCR値と等しい場合(ステップＳ４０７でYes)、処理はステップＳ４０８に進む。ステップＳ４０８で認証処理部１１３は、デバイス認証は成功と判定し、デバイス１０１に対する証明書Cert{DevID, DevK_pub}caを生成し、該生成した証明書をネットワーク処理部１１４を介してデバイス１０１に送信する。

以上説明した一連の処理の結果、デバイス１０１は証明書を受け取ることができる。ここで、図２においてデバイス１０１から認証サーバ１０２に送られるデータにはDevKの公開鍵に対する証明書が含まれていないことに注意されたい。つまり、認証サーバ１０２は、DevKの公開鍵証明書を利用することなくデバイス認証を行うことができることになる。また、デバイス１０１の管理者もDevKの鍵ペアに対する証明書を予め取得する必要はない。

以上、本実施形態において、認証サーバ１０２がデバイス１０１を認証し、サービスを提供する方法について説明した。なお、本実施形態では認証サーバ１０２がデバイス１０１にデバイス証明書を発行するサービスを提供する場合を例として説明を行ったが、別のサービスを提供するようにしても良い。たとえば、認証サーバ１０２はデバイス１０１に対してファームウェアを配信するサービスを提供してもよい。この場合には、ステップＳ２０２の後にデバイス１０１から認証サーバ１０２に送るリクエストをファームウェア送信要求とし、ステップＳ２０５の後に認証サーバ１０２から送られるデータはファームウェアデータとなる。これにより、認証サーバ１０２は正当なデバイスにのみファームウェアデータを、安全に配信することができる。

＜変形例１＞
第１の実施形態では、図５に示すようなOSとアプリケーションの２つの権限でデバイスを管理するモデルでの実現を説明した。しかし、図６の論理構成で示すように、CPUの提供する仮想実行技術を利用することも可能である。仮想実行技術では、デバイスのメモリや周辺機器などのリソースをNormal World 601とSecure World 602とに分割する。Secure World６０２に割り当てられたリソースに対するNormal World６０１からの直接アクセスは防止される。つまり、Normal World６０１におけるRich OS 603はNormal World６０１に割り当てられたデバイス上のリソースを管理し、App 604 に対してリソースの利用を可能にさせる。一方で、Secure World 602 はMonitor Code 605 を介してNormal World ６０１のRich OS６０３からサービスの要求を受け付け、Secure World６０２に割り当てられたリソースを使ったサービスを提供する。つまり、Normal World６０１における実行プロセスからSecure World６０２は論理的に隔離されていることになる。すなわち、デバイスにおけるセキュリティ処理を行う安全な実行環境となる。Trusted OS 606 は、Secure World６０２側のリソースを管理するOSであり、Soft TPM 607及びSecure App 608 に対してリソースを使ったサービスを提供する。

このような構成においては、第１の実施形態におけるPCR記憶部１０８及び認証データ生成部１０９をSecure World６０２側のSoft TPM 607 で実現できる。そして、Rich OS 603はMonitor Code 605を介して認証データ生成部１０９のデバイス認証子生成を依頼する。つまり、ステップＳ２０４では、Soft TPM 607がPCR記憶部１０８に管理されるハッシュ値に対してDevKの秘密鍵でディジタル署名処理を実行してRich OS 605に返す。

また、デバイス１０１のSecure Boot処理における起動処理部１０３は、Secure World６０２で実行される。起動処理部１０３は、暗号化された鍵ペア{DevK}KsをセキュアＲＯＭ１０４から読み出し、復号してSoft TPM 607に入力する。これにより、ハードウェアのTPMチップに供えられたNVRAMを利用することなく鍵ペアDevKを保護することが可能である。

このような構成にすることによって、ハードウェアTPMチップを持たないデバイスにおいても、第１の実施形態と同等のセキュリティ機能を実現することが可能となる。さらに、第１の実施形態における認証サーバ１０２からデバイス１０１へのサービス提供（ステップＳ２０５の後にデバイス１０１に送信されるメッセージ提供）では、データをDevKの公開鍵で暗号化して返信するとさらに強固なセキュリティを実現できる。つまり、認証サーバ１０２からデバイス１０１に送信される証明書は、{ Cert{DevID, DevK_pub}ca }DevKの形式で送信することができる。或いは、第１の実施形態で説明したファームウェア配信の場合においては、認証サーバ１０２はファームウェアデータFirmを{Firm}DevKの形にして送信する。これにより、証明書データ或いはファームウェアデータは、デバイス１０１におけるSecure World６０２で実行されるDevKの秘密鍵を保持するプロセスまで安全に届けることができる。つまり、デバイス１０１におけるNormal World６０１に不正なプロセスが存在していても、その不正なプロセスはSecure World６０２に送信される証明書或いはファームウェアを不正に取得することはできない。

［第２の実施形態］
図１に示したデバイス１０１及び認証サーバ１０２の各機能部の全てはハードウェアで実装しても良い。しかし一部（例えば起動処理部１０３、ＯＳ実行部１０６、認証データ生成部１０９、認証処理部１１３）をソフトウェア（コンピュータプログラム）で実装し、残りの機能部をハードウェア（メモリ、通信インターフェース等）で実装しても良い。この場合、このソフトウェアを実行可能なプロセッサ、メモリ、通信インターフェース、を有するコンピュータ装置は、デバイス１０１及び認証サーバ１０２に適用可能である。

デバイス１０１及び認証サーバ１０２に適用可能なコンピュータ装置のハードウェア構成例について、図７のブロック図を用いて説明する。なお、デバイス１０１と認証サーバ１０２とで異なるハードウェア構成を有する機器を採用しても良い。

ＣＰＵ７０１は、ＲＡＭ７０２やＲＯＭ７０３に格納されているコンピュータプログラムやデータを用いて処理を実行する。これによりＣＰＵ７０１は、コンピュータ装置全体の動作制御を行うと共に、デバイス１０１及び認証サーバ１０２のそれぞれが行うものとして上述した各処理を実行若しくは制御する。

ＲＡＭ７０２は、ＲＯＭ７０３からロードされたコンピュータプログラムやデータを格納するためのエリア、Ｉ／Ｆ（インターフェース）７０６を介して外部から受信したデータを格納するためのエリア、を有する。また、ＲＡＭ７０２は、ＣＰＵ７０１が各種の処理を実行する際に用いるワークエリアを有する。このようにＲＡＭ７０２は、各種のエリアを適宜提供することができる。ＲＡＭ７０２は、例えば、図１のＰＣＲ記憶部１０８として機能する。

ＲＯＭ７０３には、コンピュータ装置の設定データや起動プログラムなどが格納されている。ＲＯＭ７０３は、セキュアＲＯＭ１０４、フラッシュＲＯＭ１０５、不揮発性メモリ１１１、Ｋｓ記憶部１１２として機能する。

操作部７０４は、マウスやキーボード、ボタンなどのユーザインターフェースにより構成されており、ユーザが操作することで各種の指示をＣＰＵ７０１に対して入力することができる。例えば、上記の起動信号は、操作部７０４への操作に応じて入力することができる。

表示部７０５は、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ７０１による処理結果を画像や文字などでもって表示することができる。なお、操作部７０４と表示部７０５とを一体化させてタッチパネル画面を構成しても良い。

Ｉ／Ｆ７０６は、外部の機器との間のデータ通信を行うための通信インターフェースとして機能するものであり、例えば、図１のネットワーク処理部１１０、ネットワーク処理部１１４として機能する。ＣＰＵ７０１、ＲＡＭ７０２、ＲＯＭ７０３、操作部７０４、表示部７０５、Ｉ／Ｆ７０６は何れもバス７０７に接続されている。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０４：セキュアＲＯＭ １０５：フラッシュＲＯＭ １０３：起動処理部 １０６：ＯＳ実行部 １１０：ネットワーク処理部 １０８：ＰＣＲ記憶部 １０９：認証データ生成部 １１１：不揮発性メモリ

Claims (7)

1. 公開鍵と秘密鍵とのペアである鍵ペア、及び秘密情報を用いたセキュリティ処理を行う情報処理装置であって、
   秘密情報及びRTMコードを保持する第１の保持手段と、
   起動信号に応じて前記RTMコードを実行する起動処理手段と、
   データのハッシュ値を保持する第２の保持手段と、
   ブートローダ及びシステムの起動イメージを保持する第３の保持手段と
   を備え、
   前記起動処理手段は前記RTMコードを実行することで、前記秘密情報及び前記公開鍵を前記第２の保持手段へ記憶するExtend処理と、前記第３の保持手段からロードしたブートローダの実行を開始するブート処理と、を実行し、
   前記セキュリティ処理は、前記第２の保持手段に保存されたハッシュ値に対して前記秘密鍵で署名処理を行って、ディジタル署名を生成する処理である
   ことを特徴とする情報処理装置。
2. 前記起動処理手段は、前記Extend処理の後に前記秘密情報を読み込みできない状態にすることを特徴とする請求項１に記載の情報処理装置。
3. 前記起動処理手段は、デバイス認証子を生成するモードの場合に、前記第２の保持手段へのExtend処理を行うことを特徴とする請求項１に記載の情報処理装置。
4. 前記起動処理手段による処理と前記セキュリティ処理とは安全な実行環境で実行されることを特徴とする請求項１に記載の情報処理装置。
5. 前記セキュリティ処理では、前記公開鍵で暗号化されたデータが前記安全な実行環境で復号処理されることを特徴とする請求項４に記載の情報処理装置。
6. 公開鍵と秘密鍵とのペアである鍵ペア、及び秘密情報を用いたセキュリティ処理を行う情報処理装置であって、
   秘密情報及びRTMコードを保持する第１の保持手段と、
   データのハッシュ値を保持する第２の保持手段と、
   ブートローダ及びシステムの起動イメージを保持する第３の保持手段と
   を有する前記情報処理装置が行う情報処理方法であって、
   前記RTMコードを実行することで、前記秘密情報及び前記公開鍵を前記第２の保持手段へ記憶するExtend処理と、前記第３の保持手段からロードしたブートローダの実行を開始するブート処理と、を実行し、
   前記セキュリティ処理は、前記第２の保持手段に保存されたハッシュ値に対して前記秘密鍵で署名処理を行って、ディジタル署名を生成する処理である
   ことを特徴とする情報処理方法。
7. コンピュータに、請求項６に記載の情報処理方法を実行させるためのコンピュータプログラム。

Images