JP2003124927A - 相互認証システム及び相互認証方法、相互認証装置、並びに記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ＮＴＲＵ公開鍵暗号方式を使用して相互認証
を行う。 【解決手段】 ＮＴＲＵ公開鍵暗号方式を用いたプロト
コルによりサーバとクライアント間の相互認証を行う。
また、送信データ中にセッション・キーの種となる乱数
とそのハッシュ値を加えることにより、Ｄｅｃｒｉｐｔ
ｉｏｎ Ｆａｉｌｕｒｅが起きているかどうかをチェッ
クできるようするとともに、セッション・キー用の乱数
を基にセッション・キーを作り出して、認証後のデータ
送受信を暗号化して行う。ＮＴＲＵの暗号化方式は処理
が軽く簡単なプロトコルであることから、組み込み型機
器に実装することが可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、２以上の機器間で
相互認証システム及び相互認証方法、相互認証装置、並
びに記憶媒体に係り、特に、音楽や画像などの有料コン
テンツの配信において課金処理時に相互認証を行う相互
認証システム及び相互認証方法、相互認証装置、並びに
記憶媒体に関する。

【０００２】更に詳しくは、本発明は、公開鍵暗号方式
を用いて相互認証を行う相互認証システム及び相互認証
方法、相互認証装置、並びに記憶媒体に係り、特に、比
較的処理が軽い公開鍵暗号方式を用いて携帯端末のよう
な組み込み機器上でも相互認証を行うことができる相互
認証システム及び相互認証方法、相互認証装置、並びに
記憶媒体に関する。

【０００３】

【従来の技術】昨今、情報通信技術の飛躍的な進歩とも
相俟って、コンピュータを始めとする各種の情報機器が
電話回線やインターネットなどの広域ネットワークに接
続され、コンピュータ資源の共有や、情報の共有・流通・
配布・交換などの協働的作業を円滑に行うことができる
ようになってきている。

【０００４】ネットワークは、単なる情報配信の手段と
してだけではなく、音楽や画像などの有料コンテンツの
販売や、従来の物流に置き換わる「ネット販売」や「オ
ンライン・ショッピング」にも活用されている。また、
コンテンツや商品の購入手続だけではなく、電子マネー
などを利用して課金処理もネットワーク上で無人化・自
動化することができる。

【０００５】例えば、ＰＤＡ（Personal Digital Assis
tant）のような携帯情報端末に携帯電話機を接続するこ
とにより、電話網やインターネット網を介してコンテン
ツをダウンロードすることによって、ＰＤＡ上でコンテ
ンツを再生して楽しむということができる。

【０００６】他方、デジタル形式のデータやコンテンツ
の複製や改竄は極めて容易であり、著作権侵害の危険に
無防備にさらされているとさえ言える。したがって、著
作権法やその他の複製に関する法規制を強化するだけで
は不充分であり、情報技術の観点からもデータやコンテ
ンツの保護を拡充する必要があると思料される。

【０００７】また、従来の物流とは相違し、ネットワー
ク取引においては、顔が見えない相手にコンテンツを渡
したり対価を支払ったりしなければならず、コンテンツ
を無断複製や改竄などの海賊行為から保護したり、ユー
ザのプライバシをなりすましによる侵害から充分に保護
することが充分にできない可能性がある。

【０００８】このため、ネットワーク世界では、正当な
相手とのみ取引を行うべく、「相互認証」という手続が
広く採り入れられている。

【０００９】相互認証には、いわゆる「公開鍵暗号方
式」を適用することが一般的である。ここで、公開鍵暗
号とは、データを暗号化する際に用いる鍵と、復号化す
る際に用いる鍵が異なり、「非対称暗号」とも呼ばれ
る。公開鍵暗号アルゴリズムは、一方の鍵から他方の鍵
を算出することが非常に困難であるという性質を持つこ
とにより、一方の鍵で暗号化した情報は他方の鍵でしか
復号化できないことが保証される。暗号化の鍵は「公開
鍵」と呼ばれ、一般に公開して誰でも使用できるように
する。また、復号化の鍵は「秘密鍵」と呼ばれ、他人に
漏れないように所有者が管理する。

【００１０】公開鍵暗号方式を採用した場合、各自は復
号鍵として自分の秘密鍵を１つ所有するだけでよいの
で、システム全体で使用する鍵の数を少なくすることが
でき、管理が容易になる。

【００１１】しかしながら、公開鍵暗号方式は、一般
に、暗号化並びに復号化の処理が重たく、ＣＰＵパワー
やメモリ容量を要する。量的にかなり小さい情報であれ
ば、暗号化・復号化には実用上の支障はないが、音楽や
画像などの比較的大きな情報の場合には支障が生じる。
また、ＰＤＡのような小型（すなわちＣＰＵパワーが非
力）でバッテリ駆動の組み込み機器の場合には、相互認
証に公開鍵暗号方式を用いるのは困難である。

【００１２】しかしながら、もし、セッション・キー発
生に使用される乱数などのデータが平文のまま通信路を
流れると、通信路のデータが見られた場合には、それら
の乱数を使って悪者がセッション・キーを簡単に作り出
して、さまざまな不正を働く危険がある。

【００１３】このような問題を解消するために、"ＮＴ
ＲＵ（エヌトゥルー）"と呼ばれる、短く且つ用意に鍵
を生成し、高速且つ小メモリ容量で実現可能な公開鍵暗
号方式が開発・提供されている。

【００１４】ＮＴＲＵは世界で最も速く安全な公開鍵暗
号システムであり、その処理速度は従来の公開鍵暗号シ
ステムと比べて２０倍から４００倍にも達する。また、
ＮＴＲＵは、システムの拡張が容易であり、頻繁なワイ
ヤレス取引や音楽やゲームをダウンロードするために接
続される数十億の消費者向けデバイスを保護するインフ
ラストラクチャーの構築も可能である。一方、ＮＴＲＵ
は低価格で大量に販売されるデバイスのセキュリティ
を、小さな構成で確実かつ効率的に守ることもできる。
さらにＮＴＲＵは、新規のセキュリティ・パラダイムを
使用して、付加価値の高いコミュニケーションとコンテ
ンツのセキュリティを厳重に保護することもできる（ht
tp://www.ntru.co.jp/）。

【００１５】ＮＴＲＵは、因数分解や対数問題を使用し
ない、初の安全で実用的な公開鍵暗号システムである。
ＮＴＲＵのアルゴリズムを実行する計算プロセスは単純
であるので、低価格の８ビット・マイクロプロセッサで
も高速に処理することができる。すなわち、ＮＴＲＵの
公開鍵暗号方式は、比較的軽い処理で且つ小メモリ容量
で実現できることから、携帯電話機、デジタル・ミュー
ジック・プレーヤや、ＰＤＡなどのデバイスの使用時
に、プライバシーと信頼性を確立することができると思
料される。

【００１６】しかしながら、ＮＴＲＵは処理が軽い反
面、復号化（Ｄｅｃｒｙｐｔ）の際に基データが異なる
というエラー（Ｄｅｃｒｙｐｔｉｏｎ Ｆａｉｌｕｒ
ｅ）を発生することがある。

【００１７】Ｄｅｃｒｙｐｔｉｏｎ Ｆａｉｌｕｒｅが
起こると、端末間で再度セッション確立などの手続を繰
り返さなければならず、それまでに行われた相互認証な
どの処理がすべて無駄になってしまう。例えば、携帯電
話などの機器からサーバに再接続しなければならず、処
理時間だけでなく通信費も無駄になってしまう。

【００１８】

【発明が解決しようとする課題】本発明の目的は、音楽
や画像などの有料コンテンツの配信において課金処理時
に相互認証を好適に行うことができる、優れた相互認証
システム及び相互認証方法、相互認証装置、並びに記憶
媒体を提供することにある。

【００１９】本発明の更なる目的は、公開鍵暗号方式を
用いて機器間の相互認証を好適に行うことができる、優
れた相互認証システム及び相互認証方法、相互認証装
置、並びに記憶媒体を提供することにある。

【００２０】本発明の更なる目的は、比較的処理が軽い
公開鍵暗号方式を用いて携帯端末のような組み込み機器
上でも相互認証を行うことができる、優れた相互認証シ
ステム及び相互認証方法、相互認証装置、並びに記憶媒
体を提供することにある。

【００２１】

【課題を解決するための手段及び作用】本発明は、上記
課題を参酌してなされたものであり、その第１の側面
は、通信媒体を介して接続される複数の装置間で所定の
公開鍵暗号方式を用いて相互認証を行う相互認証システ
ム又は相互認証方法であって、通信相手が互いにセッシ
ョン・キーの種となる乱数を生成するセッション・キー
の種生成手段又はステップと、相互認証用のデータ中に
セッション・キーの種となる乱数とそのハッシュ値を付
加することによって、復号化の失敗が起きているかどう
かをチェックする復号化検査手段又はステップと、を備
えることを特徴とする相互認証システム又は相互認証方
法である。

【００２２】但し、ここで言う「システム」とは、複数
の装置（又は特定の機能を実現する機能モジュール）が
論理的に集合した物のことを言い、各装置や機能モジュ
ールが単一の筐体内にあるか否かは特に問わない。

【００２３】本発明の第１の側面に係る相互認証システ
ムは、ＣＰＵパワーが非力でメモリ容量が小さな携帯情
報端末の相互認証を行うことを考慮して、ＮＴＲＵ公開
鍵暗号方式を用いた相互認証処理を行う。

【００２４】ＮＴＵＲ公開鍵暗号方式を用いた場合、復
号化の失敗（ＤｅｃｒｉｐｔｉｏｎＦａｉｌｕｒｅ）が
発生する可能性がある。そこで、本発明の第１の側面に
係る相互認証システムでは、通信相手が互いにセッショ
ン・キーの種となる乱数を生成するとともに、相互認証
用のデータ中にセッション・キーの種となる乱数とその
ハッシュ値を付加することによって、復号化の失敗が起
きているかどうかをチェックするようにした。この結
果、確かなセッション確立でセッション・キーを共有す
ることができる。

【００２５】ここで、前記復号化検査手段又はステップ
は、通信相手の公開鍵でセッション・キーの種となる乱
数とそのハッシュ値を暗号化して送信するとともに、通
信相手から受信したデータを自分の秘密鍵で復号化し
て、セッション・キーの種となる乱数とそのハッシュ値
を取り出し、セッション・キーの種となる乱数のハッシ
ュ値を算出してこれを取り出された該ハッシュ値と比較
することによって、公開鍵における復号化に失敗したか
否かを判別することができる。

【００２６】また、復号化の失敗が起きていないと判断
された場合には、通信相手が互いに生成したセッション
・キーの種を基にセッション・キーを生成して、該セッ
ション・キーを用いた暗号データの送受信を行うことが
できる。すなわち、課金処理やコンテンツの配信などの
手続を、安全な通信路を介して行うことが可能となる。

【００２７】また、本発明の第２の側面は、第１の装置
と第２の装置の間で所定の公開鍵暗号方式を用いて相互
認証を行う相互認証方法であって、第１の装置が自分の
公開鍵Ｅ_aを含んだ電子署名Ｃ_aを第２の装置に送信する
ステップと、第２の装置が、第１の装置の電子署名Ｃ_a
を確認した後、相互認証用の乱数Ｎ_b及びセッション・
キーの種Ｓ_bを生成するとともにＳbのハッシュ値Ｈａｓ
ｈ（Ｓ _b）を計算して、Ｎ_b、Ｓ_b、Ｈａｓｈ（Ｓ_b）を第
１の装置の公開鍵Ｅ_aで暗号化したデータＥ_a（Ｎ_b，
Ｓ_b，Ｈａｓｈ（Ｓ_b））を、自分の公開鍵Ｅ_bを含んだ
電子署名Ｃ_bとともに第１の装置に送信するステップ
と、第１の装置が、第２の装置の電子署名Ｃ_bを確認し
た後、自分の秘密鍵で受信データＥ_a（Ｎ_b，Ｓ_b，Ｈａ
ｓｈ（Ｓ_b））を復号化して、セッション・キーの種Ｓ_b
のハッシュ値Ｈａｓｈ'（Ｓ_b）を計算して、受信したハ
ッシュ値Ｈａｓｈ（Ｓ_b）と一致するか否かによって、
公開鍵における復号化に失敗したか否かを判別するステ
ップと、復号化に失敗していないことに応答して、第１
の装置が、相互認証用の乱数Ｎ _a及びセッション・キー
の種Ｓ_aを生成するとともにＳaのハッシュ値Ｈａｓｈ
（Ｓ_a）を計算して、Ｎ_a、Ｓ_a、Ｈａｓｈ（Ｓ_a）を第２
の装置の公開鍵Ｅ_bで暗号化したデータＥ_b（Ｎ_a，Ｓ_a，
Ｈａｓｈ（Ｓ_a））を、受信データから取り出した乱数
Ｎ_bとともに第２の装置に送信するステップと、第２の
装置が、受信した乱数Ｎ_bが自分で生成した乱数と等し
いか否かで第１の装置を本人確認するステップと、本人
確認に成功したことに応答して、第２の装置が、自分の
秘密鍵で受信データＥ_b（Ｎ_a，Ｓ_a，Ｈａｓｈ（Ｓ_a））
を復号化して、セッション・キーの種Ｓ_aのハッシュ値
Ｈａｓｈ'（Ｓ_a）を計算して、受信したハッシュ値Ｈａ
ｓｈ（Ｓ_a）と一致するか否かによって、公開鍵におけ
る復号化に失敗したか否かを判別するステップと、復号
化に失敗していないことに応答して、第２の装置が、相
互認証用の乱数Ｎaを第１の装置に送信するステップ
と、第１の装置が、受信した乱数Ｎ_aが自分で生成した
乱数と等しいか否かで第２の装置を本人確認するステッ
プと、を具備することを特徴とする相互認証方法であ
る。

【００２８】ここで、ＣＰＵパワーが非力でメモリ容量
が小さな携帯情報端末の相互認証を行うことを考慮し
て、ＮＴＲＵ公開鍵暗号方式を用いた相互認証処理を行
う。

【００２９】本発明の第２の側面に係る相互認証方法に
よれば、第１及び第２の装置は、通信相手を相互認証す
るとともに、お互いが正しく公開鍵で暗号化された乱数
を復号化することができたか否かによって、復号化の失
敗を起していないことを確認することができる。また、
復号化の失敗を起していない場合のみ、互いに生成した
種Ｓ_a及びＳ_bからセッション・キーを生成する。そし
て、その後のデータのやり取りを、セッション・キーで
暗号化して送受信することにより、第３者による改竄や
盗聴を防ぐことができる。

【００３０】また、本発明の第３の側面は、通信媒体を
介して接続される他の装置との間で所定の公開鍵暗号方
式を用いて相互認証を行う相互認証装置又は相互認証方
法であって、相互認証用の乱数Ｎを発生する手段又はス
テップと、セッション・キーの種となる乱数Ｓを発生す
る手段又はステップと、セッション・キーの種のハッシ
ュ値Ｈを計算する手段又はステップと、乱数Ｎとセッシ
ョン・キーの種Ｓとセッション・キーの種のハッシュ値
Ｈを通信相手の公開鍵で暗号化して送信する手段又はス
テップと、通信相手から受信した暗号データを自分の公
開鍵で復号化して、通信相手の相互認証用の乱数Ｎ'と
通信相手が生成したセッション・キーの種Ｓ'及びその
ハッシュ値Ｈ'を取り出す手段又はステップと、セッシ
ョン・キーの種Ｓ'のハッシュ値Ｈ"を計算して、Ｈ'と
Ｈ"が一致するか否かによって公開鍵における復号化に
失敗したか否かを検査する手段又はステップと、を具備
することを特徴とする相互認証装置又は相互認証方法で
ある。

【００３１】ここで、ＣＰＵパワーが非力でメモリ容量
が小さな携帯情報端末の相互認証を行うことを考慮し
て、ＮＴＲＵ公開鍵暗号方式を用いた相互認証処理を行
う。

【００３２】また、本発明の第３の側面に係る相互認証
装置又は相互認証方法は、通信相手から受信した暗号デ
ータから取り出した通信相手の相互認証用の乱数Ｎ'を
通信相手に送信する手段又はステップと、通信相手から
受信した自分の相互認証用の乱数が、自分で発生した乱
数Ｎと等しいか否かで、通信相手を本人確認する手段又
はステップとをさらに備えていてもよい。

【００３３】本発明の第３の側面に係る相互認証装置又
は相互認証方法によれば、第１及び第２の装置は、通信
相手を相互認証するとともに、お互いが正しく公開鍵で
暗号化された乱数を復号化することができたか否かによ
って、復号化の失敗を起していないことを確認すること
ができる。また、復号化の失敗を起していない場合の
み、互いに生成した種Ｓ_a及びＳ_bからセッション・キー
を生成する。そして、その後のデータのやり取りを、セ
ッション・キーで暗号化して送受信することにより、第
３者による改竄や盗聴を防ぐことができる。

【００３４】また、本発明の第４の側面は、他の装置と
の間で所定の公開鍵暗号方式を用いて相互認証を行うた
めの相互認証処理をコンピュータ・システム上で実行す
るように記述されたコンピュータ・ソフトウェアをコン
ピュータ可読形式で物理的に格納した記憶媒体であっ
て、前記コンピュータ・ソフトウェアは、相互認証用の
乱数Ｎを発生するステップと、セッション・キーの種と
なる乱数Ｓを発生するステップと、セッション・キーの
種のハッシュ値Ｈを計算するステップと、乱数Ｎとセッ
ション・キーの種Ｓとセッション・キーの種のハッシュ
値Ｈを通信相手の公開鍵で暗号化して送信するステップ
と、通信相手から受信した暗号データを自分の公開鍵で
復号化して、通信相手の相互認証用の乱数Ｎ'と通信相
手が生成したセッション・キーの種Ｓ'及びそのハッシ
ュ値Ｈ'を取り出すステップと、セッション・キーの種
Ｓ'のハッシュ値Ｈ"を計算して、Ｈ'とＨ"が一致するか
否かによって公開鍵における復号化に失敗したか否かを
検査するステップと、を具備することを特徴とする記憶
媒体である。

【００３５】本発明の第４の側面に係る記憶媒体は、例
えば、さまざまなプログラム・コードを実行可能な汎用
コンピュータ・システムに対して、コンピュータ・ソフ
トウェアをコンピュータ可読な形式で提供する媒体であ
る。このような媒体は、例えば、ＣＤ（Compact Disc）
やＦＤ（Floppy Disk）、ＭＯ（Magneto-Optical dis
c）などの着脱自在で可搬性の記憶媒体である。あるい
は、ネットワーク（ネットワークは無線、有線の区別を
問わない）などの伝送媒体などを経由してコンピュータ
・ソフトウェアを特定のコンピュータ・システムに提供
することも技術的に可能である。

【００３６】このような記憶媒体は、コンピュータ・シ
ステム上で所定のコンピュータ・ソフトウェアの機能を
実現するための、コンピュータ・ソフトウェアと記憶媒
体との構造上又は機能上の協働的関係を定義したもので
ある。換言すれば、本発明の第４の側面に係る記憶媒体
を介して所定のコンピュータ・ソフトウェアをコンピュ
ータ・システムにインストールすることによって、コン
ピュータ・システム上では協働的作用が発揮され、本発
明の第３の側面に係る相互認証装置又は相互認証方法と
同様の作用効果を得ることができる。

【００３７】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。

【００３８】

【発明の実施の形態】本発明は、ＮＴＲＵ Ｃｒｙｐｔ
ｏｓｙｓｔｅｍｓ社が発案した公開鍵暗号方式を使用し
た相互認証プロトコルを提案するものである。

【００３９】ＮＴＲＵは、因数分解や対数問題を使用し
ない、初の安全で実用的な公開鍵暗号システムである。
ＮＴＲＵのアルゴリズムを実行する計算プロセスは単純
であり、低価格の８ビット・マイクロプロセッサでも高
速に処理することができる。すなわち、ＮＴＲＵの公開
鍵暗号方式は、比較的軽い処理で且つ小メモリ容量で実
現できることから、サーバとクライアント間、とりわ
け、携帯電話機、デジタル・ミュージック・プレーヤ
や、ＰＤＡなどの携帯型のデバイスにおいて、例えば音
楽などのコンテンツ配信サイトとの間での相互認証手続
に適用することができる。

【００４０】Ａ．ＮＴＲＵ公開鍵暗号システム ここで、ＮＴＲＵの公開鍵暗号システムについて説明し
ておく。

【００４１】ＮＴＲＵの暗号化処理は、多項式代数、並
びに、ｐとｑ２個のレダクション・モジュロに基づく混
合システムを用いる。一方、その復号化処理は、非混合
システムを使用し、その有効性は基本的な確立理論に依
存する。ＮＴＲＵの公開鍵暗号システムのセキュリティ
は、多項式混合システムとリダクション・モジュロｐ及
びｑの独立性との相互作用によって導き出される。この
セキュリティは、ほとんどの格子において、適度に短い
場合とは反対に、極端に短いベクトルを探すことは極め
て難しいという事実（実験的にも観察されている）にも
依拠する。

【００４２】ＮＴＲＵ暗号化システムは、（Ｎ，ｐ，
ｑ）という３つの整数パラメータと、整数係数を持つＮ
−１等級の４組の多項式Ｌ_f，Ｌ_g，Ｌ_φ，Ｌ_mで成り立
つ。ここで、ｐとｑは素数である必要はないがｇｃｄ
（ｐ，ｑ）＝１（最大公約数が１）であることと、ｑは
常にｐよりも相当大きな数であることを前提とする。こ
こで、下式で表されるリングＲを導入する。

【００４３】

【数１】

【００４４】要素Ｆ（∈Ｒ）は、以下に示すような多項
式又はベクトルで表現される。

【００４５】

【数２】

【００４６】また、リングＲの乗算は記号"＊"を丸囲み
した演算子で表記される。この演算子は、巡回畳み込み
積であり、例えばＦとＧの巡回畳み込み積は下式の通り
となる。

【００４７】

【数３】

【００４８】ＮＴＲＵ鍵を生成するために、復号者側で
は２つの多項式ｆ，ｇ（∈Ｌ_g）を選択する。一方の多
項式ｆは、モジュロｑとモジュロｐそれぞれの逆数を持
つという付加的な要件を満足する。ここで、それぞれの
逆数をＦ_q及びＦ_pとおくと、これらは下式のように表さ
れる。

【００４９】

【数４】

【００５０】復号者側では次いで以下の量を計算する。

【００５１】

【数５】

【００５２】復号者側における公開鍵は上式で表される
多項式ｈである。また、復号者側における秘密鍵は、多
項式ｆである。但し、復号側では、Ｆ_pも併せて保管し
ておきたくなるのが実情である。

【００５３】他方、暗号者側が復号者側にメッセージを
送信したい場合、まず、平文の組Ｌ _mの中からメッセー
ジｍを選択する。次いで、１つの多項式φ（∈Ｌ_φ）を
ランダムに選択して、復号者側の公開鍵ｈを用いて以下
の計算を行う。

【００５４】

【数６】

【００５５】上式が暗号者側から復号者側に送信された
暗号化メッセージｅとなる。

【００５６】復号者側が、受信した暗号化メッセージｅ
を復号化したい場合には、自分の秘密鍵ｆを用いる（こ
の復号化処理を効率的に行いたい場合にはＦ_pを用いれ
ばよい）。

【００５７】暗号化メッセージｅを復号化したい場合に
は、まず下式を計算する。

【００５８】

【数７】

【００５９】ここで、復号者はａの係数を−ｑ／２〜ｑ
／２の範囲内で選択する。式ａを整数係数を持つ多項式
として取り扱うことにより、以下の式を計算することで
元のメッセージを再現することができる。

【００６０】

【数８】

【００６１】以上説明してきたように、ＮＴＲＵ公開鍵
暗号方式によれば、適切なパラメータ値を用いることに
より、極めて高い確率で復号化処理により元のメッセー
ジを再現することができる。しかしながら、パラメータ
の選択次第で、Ｄｅｃｒｙｐｔｉｏｎ Ｆａｉｌｕｒｅ
を生じる可能性（すなわち、正確に復号化されないとい
う可能性）がある。

【００６２】Ｂ．相互認証プロトコル 以下、図面を参照しながら、本発明の実施形態について
詳解する。

【００６３】本発明に係る相互認証プロトコルは、例え
ばサーバとクライアント間、とりわけ、携帯電話機、デ
ジタル・ミュージック・プレーヤや、ＰＤＡ（Personal
Digital Assistant）などの携帯型のデバイスにおい
て、例えば音楽などのコンテンツ配信サイトとの間での
相互認証に適用することができる。

【００６４】図１には、携帯端末に対してコンテンツ配
信サービスを提供するネットワーク・システムの構成を
模式的に示している。

【００６５】同図に示すように、ネットワーク・システ
ムは、インターネット１１のような広域的なネットワー
クと、携帯電話機などの移動体に対してパケット通信な
どのサービスを提供する移動体通信網１２と、その他の
図示しないネットワークで構成される。移動体通信網１
２やその他のネットワークは、インターネット１１に相
互接続されている。

【００６６】インターネット１１上には、無数のサーバ
が存在する。このうちの一部は、音楽や画像などのコン
テンツを有料で配信するコンテンツ配信サーバ１３であ
る。コンテンツ配信サーバ１３は、アクセス・ポイント
を介してインターネット接続されているパーソナル・コ
ンピュータなどの情報端末や、携帯電話機１４を接続す
ることで移動体通信網１２経由でインターネット１１に
アクセスするＰＤＡなどの情報端末１５に対して、有料
でコンテンツの配信サービスを行う。

【００６７】［従来の技術］の欄でも既に述べたよう
に、ネットワーク世界では顔が見えない相手とコンテン
ツのの引渡しや対価の支払いなどの手続きを行なわなけ
ればならない。このため、コンテンツを無断複製や改竄
などの海賊行為から保護したり、ユーザのプライバシの
なりすましによる侵害から保護しなければならない。

【００６８】このため、本実施形態に係るネットワーク
・システム上では、コンテンツ配信サーバ１３がパーソ
ナル・コンピュータや情報端末１５に対してコンテンツ
配信サービスを行う際に、相互認証手続を採り入れてい
る。また、携帯情報端末１５の処理能力やメモリ能力を
考慮して、処理が軽く且つ簡単なプロトコルで実装可能
なＮＴＲＵ公開鍵暗号方式（前述）を用いた相互認証を
採用している。

【００６９】図２には、本実施形態に係るネットワーク
・システム上でのコンテンツ配信サービスの流れを概略
的に示している。

【００７０】まず、コンテンツ配信サーバ１３は、取引
相手となる携帯情報端末１５と接続してセッションが確
立すると（ステップＳ１）、相互認証並びにセッション
・キーの生成を行う（ステップＳ２）。

【００７１】次いで、コンテンツ配信サーバ１３は、携
帯情報端末１５に対して課金処理を行う（ステップＳ
３）。課金処理は、前ステップＳ２で生成されたセッシ
ョン・キーを用いることで、安全な通信路を介して行う
ことができる。

【００７２】次いで、コンテンツ配信サーバ１３は、セ
ッション・キーを用いてコンテンツ復号鍵を暗号化し
て、携帯情報端末１５に送信する（ステップＳ４）。そ
して、注文を受けたコンテンツを暗号化してから、携帯
情報端末１５に送信する（ステップＳ５）。

【００７３】これに対し、携帯情報端末１５側では、受
信したコンテンツ復号鍵をセッション・キーで復号化す
るとともに、このコンテンツ復号鍵を用いて受信した暗
号化コンテンツを復号化する（ステップＳ６）。そし
て、コンテンツを再生して視聴して楽しむことができ
る。

【００７４】なお、図２に示したフローにおいて、課金
処理とコンテンツの配信処理の順番を入れ替えてもよ
い。

【００７５】本実施形態では、ＣＰＵパワーが非力でメ
モリ容量が小さな携帯情報端末の相互認証を行うことを
考慮して、ステップＳ２における相互認証処理にＮＴＲ
Ｕ公開鍵暗号方式を用いたプロトコルを使用する。後述
するように、本実施形態に係る相互認証プロトコルで
は、通信相手が互いに乱数生成したセッション・キー用
の種を基にセッション・キーを作り出して、認証後のデ
ータ送受信を暗号化して行うようになっている。

【００７６】また、送信データ中にセッション・キーの
種となる乱数とそのハッシュ値を加えることにより、Ｄ
ｅｃｒｉｐｔｉｏｎ Ｆａｉｌｕｒｅが起きているかど
うかをチェックするようにした。この結果、Ｄｅｃｒｉ
ｐｔｉｏｎ Ｆａｉｌｕｒｅが起きているかどうかをチ
ェックして、確かなセッション確立でセッション・キー
を共有することができる。

【００７７】図３には、コンテンツ配信サーバ１３の機
能構成を模式的に示している。同図に示すように、コン
テンツ配信サーバ１３は、インターネット１１などのネ
ットワーク経由でメッセージの送受信を行うための送受
信部３１と、携帯情報端末１５などの外部の装置から受
信した電子署名を検証する電子署名検証部３２と、乱数
生成部３３と、サーバ１３自身の電子署名を生成する電
子署名生成部３４と、送信メッセージの暗号化や受信メ
ッセージの復号化を行う暗号処理部３５と、発生した乱
数やサーバ１３自身の秘密鍵・公開鍵や通信相手の公開
鍵など所定のデータを保存するメモリ部３６と、認証処
理部３７と、配信コンテンツを蓄積するコンテンツ蓄積
部３８と、コンテンツ配信サービスを受けた外部の装置
に対して課金処理を行う課金処理部３９を備えている。

【００７８】電子署名検証部３２は、送受信部３１で受
信された携帯情報端末１４の電子署名Ｃｅｒｔｉｆｏｃ
ａｔｉｏｎＡを検証するとともに、この電子署名に含ま
れる携帯情報端末１５の公開鍵Ｅ_aを取り出して、メモ
リ部３６に保存しておく。

【００７９】乱数発生部３３は、相互認証に用いられる
乱数Ｎ_bを生成したり、セッション・キーの種となる乱
数Ｓ_bを生成する。これらの乱数Ｎ_b及びＳ_bは、携帯情
報端末１５などの通信相手とセッションが確立している
間はメモリ部３６に保存されている。

【００８０】電子署名生成部３４は、コンテンツ配信サ
ーバ１３自身の公開鍵Ｅ_bをメモリ部３６から取り出し
て、このＥ_bを含んだ電子署名Ｃｅｒｔｉｆｉｃａｔｉ
ｏｎＢを生成して、送受信部３１からコンテンツ配信先
となる携帯情報端末１５に送信する。

【００８１】暗号処理部３５は、携帯情報端末１５など
の通信相手に送信するデータを相手の公開鍵Ｅ_aで暗号
化したり、逆に携帯情報端末１５から受信したデータを
自分自分の秘密鍵で復号化したりする。また、暗号処理
部３５は、通信相手と交換し合った互いのセッション・
キーの種を基にセッション・キーを生成して、認証処理
後の送信データの暗号化に用いることができる。

【００８２】認証処理部３７は、携帯情報端末１５など
のコンテンツ配信先との間で認証処理を行う。例えば、
通信相手からの受信メッセージに含まれるデータのハッ
シュ値を計算して、同じく受信メッセージに含まれるハ
ッシュ値と照合することにより、通信相手が本物である
か否かを判別することができる。また、相互認証処理に
ＮＴＲＵ公開鍵暗号方式を用いているが、認証処理部３
７は、ハッシュ値の照合により、Ｄｅｃｒｉｐｔｉｏｎ
Ｆａｉｌｕｒｅが起きているかどうかをチェックする
ことができる。

【００８３】なお、コンテンツ配信サーバ１３は、専用
のハードウェア装置としてデザインすることも可能であ
るが、ワークステーション（ＷＳ）又はパーソナル・コ
ンピュータ（ＰＣ）と呼ばれる一般的な計算機システム
上で所定のサーバ・アプリケーションを起動させるとい
う形態で実現することも可能である。

【００８４】また、図４には、コンテンツ配信サーバ１
３からコンテンツの配信サービスを受ける携帯情報端末
１５の機能構成を模式的に示している。同図に示すよう
に、携帯情報端末１５は、携帯電話１４経由でネットワ
ークに接続してコンテンツ配信サーバ１３との間でメッ
セージの送受信を行うための送受信部５１と、コンテン
ツ配信サーバ１３などの外部装置から受信した電子署名
を検証する電子署名検証部５２と、乱数生成部５３と、
携帯情報端末１５自身の電子署名を生成する電子署名生
成部５４と、送信メッセージの暗号化や受信メッセージ
の復号化を行う暗号処理部３５と、発生した乱数や携帯
情報端末１５自身の秘密鍵・公開鍵や通信相手の公開鍵
など所定のデータを保存するメモリ部５６と、認証処理
部５７と、コンテンツ配信サーバ１３から受信したコン
テンツを再生利用するコンテンツ再生部５８と、コンテ
ンツ配信サーバ１３からの課金要求を処理する課金処理
部５９を備えている。

【００８５】電子署名検証部５２は、送受信部５１で受
信されたコンテンツ配信サーバ１３の電子署名Ｃｅｒｔ
ｉｆｏｃａｔｉｏｎＢを検証するとともに、この電子署
名に含まれるコンテンツ配信サーバ１３の公開鍵Ｅ_bを
取り出して、メモリ部５６に保存しておく。

【００８６】乱数発生部５３は、相互認証に用いられる
乱数Ｎ_aを生成したり、セッション・キーの種となる乱
数Ｓ_aを生成する。これらの乱数Ｎ_a及びＳ_aは、コンテ
ンツ配信サーバ１３などの通信相手とセッションが確立
している間はメモリ部５６に保存されている。

【００８７】電子署名生成部５４は、携帯情報端末１５
自身の公開鍵Ｅ_aをメモリ部５６から取り出して、この
Ｅ_aを含んだ電子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを
生成して、送受信部５１からコンテンツ配信元となるコ
ンテンツ配信サーバ１３に送信する。

【００８８】暗号処理部５５は、コンテンツ配信サーバ
１３などの通信相手に送信するデータを相手の公開鍵Ｅ
_bで暗号化したり、逆にコンテンツ配信サーバ１３から
受信したデータを自分自分の秘密鍵で復号化したりす
る。また、暗号処理部５５は、通信相手と交換し合った
互いのセッション・キーの種を基にセッション・キーを
生成して、認証処理後の送信データの暗号化に用いるこ
とができる。

【００８９】認証処理部５７は、コンテンツ配信サーバ
１３などのコンテンツ配信元との間で認証処理を行う。
例えば、通信相手からの受信メッセージに含まれるデー
タのハッシュ値を計算して、同じく受信メッセージに含
まれるハッシュ値と照合することにより、通信相手が本
物であるか否かを判別することができる。また、相互認
証処理にＮＴＲＵ公開鍵暗号方式を用いているが、認証
処理部５７は、ハッシュ値の照合により、Ｄｅｃｒｉｐ
ｔｉｏｎ Ｆａｉｌｕｒｅが起きているかどうかをチェ
ックすることができる。

【００９０】図５には、携帯情報端末１５とコンテンツ
配信サーバ１３間で行われる相互認証の処理手順の一例
を示している。但し、携帯情報端末１５は、ＮＴＲＵ公
開鍵暗号方式による公開鍵Ｅ_aとこれに非対称な秘密鍵
を持ち、同様に、コンテンツ配信サーバ１３は、ＮＴＲ
Ｕ公開鍵暗号方式による公開鍵Ｅ_bとこれに非対称な秘
密鍵を持つものとする。

【００９１】まず、クライアントとしての携帯情報端末
１５は、自分の公開鍵Ｅ_aを含んだ電子署名Ｃｅｒｔｉ
ｆｉｃａｔｉｏｎＡを送信する（Ｐ１）。

【００９２】コンテンツ配信サーバ１３側では、この電
子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると、電
子署名検証部３２でこれを検証する。

【００９３】電子署名が正しいと判断された場合には、
乱数発生部３３で、相互認証に用いる乱数Ｎ_bと、セッ
ション・キーの種となる乱数Ｓ_bを発生させる。さら
に、適当なハッシュ・アルゴリズムにより、セッション
・キーの種Ｓ_bのハッシュ値Ｈａｓｈ（Ｓ_b）を計算す
る。そして、Ｎ_b、Ｓ_b、Ｈａｓｈ（Ｓ_b）を携帯情報端
末１５の公開鍵Ｅ_aで暗号化して、これを電子署名生成
部３４で生成した電子署名Ｃｅｒｔｉｆｉｃａｔｉｏｎ
Ｂとともに携帯情報端末１５に送信する（Ｐ２）。

【００９４】携帯情報端末１５側では、電子署名Ｃｅｒ
ｔｉｆｉｃａｔｉｏｎＢと暗号データＥ_a（Ｎb，Ｓb，
Ｈａｓｈ（Ｓ_b））からなるメッセージを受信すると、
相互認証とＤｅｃｒｉｐｔｉｏｎ Ｆａｉｌｕｒｅの検
証を行う。

【００９５】図６には、携帯情報端末１５側で行われる
相互認証とＤｅｃｒｉｐｔｉｏｎＦａｉｌｕｒｅの検証
を合わせて行うための処理手順をフローチャートの形式
で示している。以下、このフローチャートに従って説明
する。

【００９６】まず、電子署名検証部５２で電子署名Ｃｅ
ｒｔｉｆｉｃａｔｉｏｎＢを検証する（ステップＳ１
１）。

【００９７】電子署名が正しいと判断された場合には
（ステップＳ１２）、暗号化処理部５５において、暗号
化データＥ_a（Ｎ_b，Ｓ_b，Ｈａｓｈ（Ｓ_b））を復号化し
て、Ｎ _b、Ｓ_b、Ｈａｓｈ（Ｓ_b）を取り出す（ステップ
Ｓ１３）。

【００９８】次いで、復号化されたセッション・キーの
種Ｓ_bに対して同じハッシュ・アルゴリズムを適用して
そのハッシュ値Ｈａｓｈ'（Ｓ_b）を作成し（ステップＳ
１４）、これが受信データから取り出されたハッシュ値
Ｈａｓｈ（Ｓ_b）と一致するか否かを判別する（ステッ
プＳ１５）。ハッシュ値が等しくなることによって、携
帯情報端末１５側ではＤｅｃｒｉｐｔｉｏｎ Ｆａｉｌ
ｕｒｅが発生していないことを確認することができる。

【００９９】再び図５に戻って説明する。Ｄｅｃｒｉｐ
ｔｉｏｎ Ｆａｉｌｕｒｅがないことが確認された後、
携帯情報端末１５では、乱数発生部５３で、相互認証に
用いる乱数Ｎ_aと、セッション・キーの種となる乱数Ｓ_a
を発生させる。さらに、適当なハッシュ・アルゴリズム
により、セッション・キーの種Ｓ_aのハッシュ値Ｈａｓ
ｈ（Ｓ_a）を計算する。そして、Ｎa、Ｓa、Ｈａｓｈ
（Ｓa）を携帯情報端末１５の公開鍵Ｅ_bで暗号化して、
これを、相互認証用の乱数Ｎ_bとともにコンテンツ配信
サーバ１３に送信する（Ｐ３）。

【０１００】コンテンツ配信サーバ１３側では、乱数Ｎ
bと暗号データＥb（Ｎa，Ｓa，Ｈａｓｈ（Ｓ_a））から
なるメッセージを受信すると、相互認証とＤｅｃｒｉｐ
ｔｉｏｎ Ｆａｉｌｕｒｅの検証を行う。

【０１０１】図７には、コンテンツ配信サーバ１３側で
行われる相互認証とＤｅｃｒｉｐｔｉｏｎ Ｆａｉｌｕ
ｒｅの検証を合わせて行うための処理手順をフローチャ
ートの形式で示している。以下、このフローチャートに
従って説明する。

【０１０２】まず、認証処理部３７で、受信メッセージ
に含まれるＮ_bが、乱数生成部３３で生成した乱数Ｎ_bと
等しいか否かを判別して（ステップＳ２１）、通信相手
が暗号化メッセージＥ_a（Ｎ_b，Ｓ_b，Ｈａｓｈ（Ｓ_b））
からＮ_bを取り出せたか否か、すなわち本物かどうかを
確認する。

【０１０３】乱数Ｎ_bが一致すると判断された場合に
は、暗号化処理部５５において、暗号化データＥ
_b（Ｎ_a，Ｓ_a，Ｈａｓｈ（Ｓ_a））を復号化して、Ｎ_a、
Ｓ_a、Ｈａｓｈ（Ｓ_a）を取り出す（ステップＳ２２）。

【０１０４】次いで、復号化されたセッション・キーの
種Ｓ_aに対して同じハッシュ・アルゴリズムを適用して
そのハッシュ値Ｈａｓｈ'（Ｓ_a）を作成し（ステップＳ
２３）、これが受信データから取り出されたハッシュ値
Ｈａｓｈ（Ｓ_a）と一致するか否かを判別する（ステッ
プＳ２４）。ハッシュ値が等しくなることによって、コ
ンテンツ配信サーバ１３側ではＤｅｃｒｉｐｔｉｏｎ
Ｆａｉｌｕｒｅが発生していないことを確認することが
できる。

【０１０５】再び図５に戻って説明する。Ｄｅｃｒｉｐ
ｔｉｏｎ Ｆａｉｌｕｒｅがないことが確認された後、
コンテンツ配信サーバ１３は、復号化された乱数Ｎ_aを
携帯情報端末１５に送り返す（Ｐ４）。

【０１０６】携帯情報端末１５側では、受信したＮaが
乱数生成部５３で生成したＮ_aと等しいか否かを判別し
て、通信相手が暗号化メッセージＥ_b（Ｎ_a，Ｓ_a，Ｈａ
ｓｈ（Ｓ_a））からＮ_aを取り出せたか否か、すなわち本
物かどうかを確認する。

【０１０７】そして、上述したような手続により、携帯
情報端末１５及びコンテンツ配信サーバ１３が通信相手
を相互認証するとともに、自分自身がＮＴＲＵ公開鍵暗
号方式においてＤｅｃｒｉｐｔｉｏｎ Ｆａｉｌｕｒｅ
を起していないことを確認し終えたならば、交換し合っ
たセッション・キーの種Ｓ_a及びＳ_bを併せてセッション
・キーを作り出す。そして、課金処理や、コンテンツ暗
号鍵の送信などは、このセッション・キーを用いた安全
な通信路上で行うことができる。

【０１０８】２つのセッション・キーの種Ｓ_a及びＳ_bを
用いて、例えば以下の方法によりセッション・キーを生
成することができる。

【０１０９】（１）Ｓ_a及びＳ_bのＸＯＲ（Exclusive O
R：排他的論理和）値をセッション・キーとする。 （２）Ｓ_aの上位バイトとＳ_bの上位バイトを合わせたも
のをセッション・キーとする。

【０１１０】このような、各端末上で生成された種Ｓa
及びＳbからセッション・キーを生成することにより、
お互いが正しく公開鍵で暗号化された乱数を復号化する
ことができた場合（すなわち、Ｄｅｃｒｉｐｔｉｏｎ
Ｆａｉｌｕｒｅがない場合）にのみ、セッション・キー
を作り出すことができる。

【０１１１】そして、その後のデータのやり取りを、セ
ッション・キーで暗号化して送受信することにより、第
３者による改竄や盗聴を防ぐことができる。

【０１１２】図８には、携帯情報端末１５とコンテンツ
配信サーバ１３間で行われる相互認証の処理手順に関す
る他の例を示している。但し、携帯情報端末１５は、Ｎ
ＴＲＵ公開鍵暗号方式による公開鍵Ｅ_aとこれに非対称
な秘密鍵を持ち、同様に、コンテンツ配信サーバ１３
は、ＮＴＲＵ公開鍵暗号方式による公開鍵Ｅ_bとこれに
非対称な秘密鍵を持つものとする。

【０１１３】まず、クライアントとしての携帯情報端末
１５は、自分の公開鍵Ｅ_aを含んだ電子署名Ｃｅｒｔｉ
ｆｉｃａｔｉｏｎＡを送信する（Ｐ１１）。

【０１１４】コンテンツ配信サーバ１３側では、この電
子署名ＣｅｒｔｉｆｉｃａｔｉｏｎＡを受信すると、電
子署名検証部３２でこれを検証する。

【０１１５】電子署名が正しいと判断された場合には、
乱数発生部３３で相互認証に用いる乱数Ｎ_bを発生さ
せ、これを携帯情報端末１５側の公開鍵Ｅ_aで暗号化し
て、これを電子署名生成部３４で生成した電子署名Ｃｅ
ｒｔｉｆｉｃａｔｉｏｎＢとともに携帯情報端末１５に
送信する（Ｐ１２）。

【０１１６】携帯情報端末１５側では、電子署名Ｃｅｒ
ｔｉｆｉｃａｔｉｏｎＢと暗号データＥ_a（Ｎ_b）からな
るメッセージを受信すると、電子署名検証部３２で電子
署名ＣｅｒｔｉｆｉｃａｔｉｏｎＢの検証を行う。電子
署名が正しいと判断された場合には、暗号化処理部５５
において、暗号化データＥ_a（Ｎ_b）を復号化して、Ｎ _b
を取り出して、そのハッシュ値Ｈａｓｈ（Ｎ_b）を作成
する。さらに、乱数生成部５３で相互認証に用いる乱数
Ｎ_aを発生させ、コンテンツ配信サーバ１３側の公開鍵
Ｅ_bでこれを暗号化する。そして、このようにして作成
されたＥ_b（Ｎ_a）及びＨａｓｈ（Ｎ_b）を含むメッセー
ジを、コンテンツ配信サーバ１３に送信する（Ｐ１
３）。

【０１１７】コンテンツ配信サーバ１３側では、Ｅ
_b（Ｎ_a）及びＨａｓｈ（Ｎ_b）を含むメッセージを受信
すると、携帯情報端末１５についての認証処理を行う。
図９には、コンテンツ配信サーバ１３側で行う携帯情報
端末１５についての認証手続をフローチャートの形式で
示している。以下、このフローチャートに従って、携帯
情報端末１５についての認証手続について説明する。

【０１１８】まず、所定のハッシュ・アルゴリズムによ
り乱数発生部３２で発生した乱数Ｎ _bのハッシュ値を計
算する（ステップＳ３１）。そして、計算されたハッシ
ュ値が、携帯情報端末１５から受信したハッシュ値Ｈａ
ｓｈ（Ｎ_b）と等しいか否かを判別する（ステップＳ３
２）。

【０１１９】これらハッシュ値が等しい場合、携帯情報
端末１５が正しくメッセージを復号化できたことを確認
できるので、携帯情報端末１５が本物の通信相手である
ことが判る。

【０１２０】次いで、受信した暗号化データＥ_b（Ｎ_a）
を暗号処理部３５で復号化して、携帯情報端末１５側の
乱数Ｎ_aを取り出す（ステップＳ３３）。

【０１２１】そして、所定のハッシュ・アルゴリズムに
よりこの乱数Ｎ_aのハッシュ値Ｈａｓｈ（Ｎ_a）を計算し
て（ステップＳ３４）、これを携帯情報端末１５に送信
する（ステップＳ３５）（Ｐ１４）。

【０１２２】また、コンテンツ配信サーバ１３は、乱数
発生部３３で発生させた乱数Ｎ_bと、携帯情報端末１５
からの受信データを復号化して得られた乱数Ｎ_aを基
に、セッション・キーを生成する（ステップＳ３６）。

【０１２３】携帯情報端末１５側では、ハッシュ値Ｈａ
ｓｈ（Ｎ_b）を含むメッセージを受信すると、コンテン
ツ配信サーバ１３についての認証処理を行う。図１０に
は、携帯情報端末１５側で行うコンテンツ配信サーバ１
３についての認証手続をフローチャートの形式で示して
いる。以下、このフローチャートに従って、コンテンツ
配信サーバ１３についての認証手続について説明する。

【０１２４】まず、所定のハッシュ・アルゴリズムによ
り乱数発生部５２で発生した乱数Ｎ _aのハッシュ値を計
算する（ステップＳ４１）。そして、計算されたハッシ
ュ値が、コンテンツ配信サーバ１３から受信したハッシ
ュ値Ｈａｓｈ（Ｎ_a）と等しいか否かを判別する（ステ
ップＳ４２）。

【０１２５】これらハッシュ値が等しい場合、コンテン
ツ配信サーバ１３が正しくメッセージを復号化できたこ
とを確認できるので、コンテンツ配信サーバ１３が本物
の通信相手であることが判る。

【０１２６】次いで、携帯情報端末１５は、乱数発生部
５３で発生させた乱数Ｎ_aと、コンテンツ配信サーバ１
３からの受信データを復号化して得られた乱数Ｎ_bを基
に、セッション・キーを生成する（ステップＳ４３）。

【０１２７】図８からも判るように、上述した相互認証
プロトコルによれば、コンテンツ配信サーバ１３と携帯
情報端末１５間の通信路上では、セッション・キーの種
となるＮ_a及びＮ_bなる乱数は、ハッシュがかけられた状
態又は暗号化された状態でのみ現れる。したがって、仮
に認証段階で通信路を傍受されたとしても、セッション
・キーを推測されることは不可能である。また、コンテ
ンツ配信サーバ１３と携帯情報端末１５は、一方から送
られてきたハッシュ値と自分で作り出したハッシュ値が
等しいことから、相手が正常に復号化できたことを確認
することができる。

【０１２８】２つのセッション・キーの種Ｎ_a及びＮ_bを
用いて、例えば以下の方法によりセッション・キーを生
成することができる。

【０１２９】（１）Ｎ_a及びＮ_bのＸＯＲ（Exclusive O
R：排他的論理和）値をセッション・キーとする。 （２）Ｎ_aの上位バイトとＮ_bの上位バイトを合わせたも
のをセッション・キーとする。 （３）Ｎ_aとＮ_bの和のハッシュ値Ｈａｓｈ（Ｎ_a＋Ｎ_b）
をセッション・キーとする。

【０１３０】このような、各端末上で生成された種Ｎ_a
及びＮ_bからセッション・キーを生成することにより、
お互いが正しく公開鍵で暗号化された乱数を復号化する
ことができた場合にのみ、セッション・キーを作り出す
ことができる。

【０１３１】［追補］以上、特定の実施例を参照しなが
ら、本発明について詳解してきた。しかしながら、本発
明の要旨を逸脱しない範囲で当業者が該実施例の修正や
代用を成し得ることは自明である。すなわち、例示とい
う形態で本発明を開示してきたのであり、本明細書の記
載内容を限定的に解釈するべきではない。本発明の要旨
を判断するためには、冒頭に記載した特許請求の範囲の
欄を参酌すべきである。

【０１３２】

【発明の効果】以上詳記したように、本発明によれば、
音楽や画像などの有料コンテンツの配信において課金処
理時に相互認証を好適に行うことができる、優れた相互
認証システム及び相互認証方法、相互認証装置、並びに
記憶媒体を提供することができる。

【０１３３】また、本発明によれば、公開鍵暗号方式を
用いて機器間の相互認証を好適に行うことができる、優
れた相互認証システム及び相互認証方法、相互認証装
置、並びに記憶媒体を提供することができる。

【０１３４】また、本発明によれば、比較的処理が軽い
公開鍵暗号方式を用いて携帯端末のような組み込み機器
のような資源が限られた機器環境でも相互認証を行うこ
とができる、優れた相互認証システム及び相互認証方
法、相互認証装置、並びに記憶媒体を提供することがで
きる。

【０１３５】本発明によれば、ＮＴＲＵ公開鍵暗号方式
を用いたプロトコルによりサーバとクライアント間の相
互認証を行うことができる。また、このプロトコルで送
受信されるセッション・キー用の乱数を基にセッション
・キーを作り出して、認証後のデータ送受信を暗号化し
て行うことができる。また、ＮＴＲＵの公開鍵暗号方式
は、復号化時に元のデータとは異なるＤｅｃｒｉｐｔｉ
ｏｎ Ｆａｉｌｕｒｅがあることが知られているが、送
信データ中にセッション・キーの種となる乱数とそのハ
ッシュ値を加えることにより、Ｄｅｃｒｉｐｔｉｏｎ
Ｆａｉｌｕｒｅが起きているかどうかをチェックできる
ようにして、確かなセッション確立でセッション・キー
を共有することができる。

【０１３６】したがって、本発明によれば、第３者によ
って見破られることがなく、安全にサーバとクライアン
ト間の通信を行うことができる。例えば、Ｅ−Ｃｏｍｍ
ｅｒｃｅなどにおける個人データ送信や、本人認証、課
金システムなどに適用することができる。

【０１３７】従来のＳＳＬ（Secure Socket Layer）な
どの相互認証プロトコルは、処理が重いため端末には不
向きである。これに対し、ＮＴＲＵの暗号化方式は処理
が軽いことや簡単なプロトコルであることから、携帯電
話や携帯情報端末などの組み込み型機器に実装すること
が可能である。

【図面の簡単な説明】

【図１】携帯端末に対してコンテンツ配信サービスを提
供するネットワーク・システムの構成を模式的に示した
図である。

【図２】本実施形態に係るネットワーク・システム上で
のコンテンツ配信サービスの流れを概略的に示したフロ
ーチャートである。

【図３】コンテンツ配信サーバ１１の機能構成を模式的
に示したブロック図である。

【図４】携帯情報端末１５の機能構成を模式的に示した
ブロック図である。

【図５】携帯情報端末１５とコンテンツ配信サーバ１３
間で行われる相互認証の処理手順の一例を示したフロー
図である。

【図６】携帯情報端末１５側で行われる相互認証とＤｅ
ｃｒｉｐｔｉｏｎ Ｆａｉｌｕｒｅの検証を合わせて行
うための処理手順を示したフローチャートである。

【図７】コンテンツ配信サーバ１３側で行われる相互認
証とＤｅｃｒｉｐｔｉｏｎ Ｆａｉｌｕｒｅの検証を合
わせて行うための処理手順を示したフローチャートであ
る。

【図８】携帯情報端末１５とコンテンツ配信サーバ１３
間で行われる相互認証の処理手順に関する他の例を示し
たフロー図である。

【図９】コンテンツ配信サーバ１３側で行う携帯情報端
末１５についての認証手続を示したフローチャートであ
る。

【図１０】携帯情報端末１５側で行うコンテンツ配信サ
ーバ１３についての認証手続を示したフローチャートで
ある。

【符号の説明】

１１…インターネット １２…移動体通信網 １３…コンテンツ配信サーバ １４…携帯電話 １５…携帯情報端末 ３１…送受信部 ３２…電子署名検証部 ３３…乱数生成部 ３４…電子署名生成部 ３５…暗号化処理部 ３６…メモリ部 ３７…認証処理部 ３８…コンテンツ蓄積部 ３９…課金処理部 ５１…送受信部 ５２…電子署名検証部 ５３…乱数生成部 ５４…電子署名生成部 ５５…暗号化処理部 ５６…メモリ部 ５７…認証処理部 ５８…コンテンツ再生部 ５９…課金処理部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ＺＥＣ Ｈ０４Ｌ 9/00 ６７５Ｂ Ｆターム(参考） 5B085 AE04 AE08 5J104 AA07 AA09 AA18 KA01 KA03 KA05 LA03 NA02 NA03 NA12 PA07 PA11

Claims (20)

【特許請求の範囲】
1. 【請求項１】通信媒体を介して接続される複数の装置間
   で所定の公開鍵暗号方式を用いて相互認証を行う相互認
   証システムであって、 通信相手が互いにセッション・キーの種となる乱数を生
   成するセッション・キーの種生成手段と、 相互認証用のデータ中にセッション・キーの種となる乱
   数とそのハッシュ値を付加することによって、復号化の
   失敗が起きているかどうかをチェックする復号化検査手
   段と、を備えることを特徴とする相互認証システム。
2. 【請求項２】前記公開鍵暗号方式は、ＮＴＲＵ公開鍵暗
   号方式である、ことを特徴とする請求項１に記載の相互
   認証システム。
3. 【請求項３】前記復号化検査手段は、通信相手の公開鍵
   でセッション・キーの種となる乱数とそのハッシュ値を
   暗号化して送信するとともに、通信相手から受信したデ
   ータを自分の秘密鍵で復号化して、セッション・キーの
   種となる乱数とそのハッシュ値を取り出し、セッション
   ・キーの種となる乱数のハッシュ値を算出してこれを取
   り出された該ハッシュ値と比較することによって、公開
   鍵における復号化に失敗したか否かを判別する、ことを
   特徴とする請求項１に記載の相互認証システム。
4. 【請求項４】通信相手が互いに生成したセッション・キ
   ーの種を基にセッション・キーを生成するセッション・
   キー生成手段と、 該セッション・キーを用いた暗号データの送受信を行う
   暗号データ送受信手段と、 をさらに備えることを特徴とする請求項１に記載の相互
   認証システム。
5. 【請求項５】通信媒体を介して接続される複数の装置間
   で所定の公開鍵暗号方式を用いて相互認証を行う相互認
   証方法であって、 通信相手が互いにセッション・キーの種となる乱数を生
   成するセッション・キーの種生成ステップと、 相互認証用のデータ中にセッション・キーの種となる乱
   数とそのハッシュ値を付加することによって、復号化の
   失敗が起きているかどうかをチェックする復号化検査ス
   テップと、を備えることを特徴とする相互認証方法。
6. 【請求項６】前記公開鍵暗号方式は、ＮＴＲＵ公開鍵暗
   号方式である、ことを特徴とする請求項５に記載の相互
   認証方法。
7. 【請求項７】前記復号化検査ステップでは、通信相手の
   公開鍵でセッション・キーの種となる乱数とそのハッシ
   ュ値を暗号化して送信するとともに、通信相手から受信
   したデータを自分の秘密鍵で復号化して、セッション・
   キーの種となる乱数とそのハッシュ値を取り出し、セッ
   ション・キーの種となる乱数のハッシュ値を算出してこ
   れを取り出された該ハッシュ値と比較ことによって、公
   開鍵における復号化に失敗したか否かを判別する、こと
   を特徴とする請求項５に記載の相互認証方法。
8. 【請求項８】通信相手が互いに生成したセッション・キ
   ーの種を基にセッション・キーを生成するステップと、 該セッション・キーを用いた暗号データの送受信を行う
   ステップと、をさらに備えることを特徴とする請求項５
   に記載の相互認証方法。
9. 【請求項９】第１の装置と第２の装置の間で所定の公開
   鍵暗号方式を用いて相互認証を行う相互認証方法であっ
   て、 第１の装置が自分の公開鍵Ｅ_aを含んだ電子署名Ｃ_aを第
   ２の装置に送信するステップと、 第２の装置が、第１の装置の電子署名Ｃ_aを確認した
   後、相互認証用の乱数Ｎ_b及びセッション・キーの種Ｓ_b
   を生成するとともにＳ_bのハッシュ値Ｈａｓｈ（Ｓ _b）を
   計算して、Ｎ_b、Ｓ_b、Ｈａｓｈ（Ｓ_b）を第１の装置の
   公開鍵Ｅ_aで暗号化したデータＥ_a（Ｎ_b，Ｓ_b，Ｈａｓｈ
   （Ｓ_b））を、自分の公開鍵Ｅ_bを含んだ電子署名Ｃ_bと
   ともに第１の装置に送信するステップと、 第１の装置が、第２の装置の電子署名Ｃ_bを確認した
   後、自分の秘密鍵で受信データＥ_a（Ｎ_b，Ｓ_b，Ｈａｓ
   ｈ（Ｓ_b））を復号化して、セッション・キーの種Ｓ_bの
   ハッシュ値Ｈａｓｈ'（Ｓ_b）を計算して、受信したハッ
   シュ値Ｈａｓｈ（Ｓ_b）と一致するか否かによって、公
   開鍵における復号化に失敗したか否かを判別するステッ
   プと、 復号化に失敗していないことに応答して、第１の装置
   が、相互認証用の乱数Ｎ _a及びセッション・キーの種Ｓ_a
   を生成するとともにＳ_aのハッシュ値Ｈａｓｈ（Ｓ_a）を
   計算して、Ｎ_a、Ｓ_a、Ｈａｓｈ（Ｓ_a）を第２の装置の
   公開鍵Ｅ_bで暗号化したデータＥ_b（Ｎ_a，Ｓ_a，Ｈａｓｈ
   （Ｓ_a））を、受信データから取り出した乱数Ｎ_bととも
   に第２の装置に送信するステップと、 第２の装置が、受信した乱数Ｎ_bが自分で生成した乱数
   と等しいか否かで第１の装置を本人確認するステップ
   と、 本人確認に成功したことに応答して、第２の装置が、自
   分の秘密鍵で受信データＥ_b（Ｎ_a，Ｓ_a，Ｈａｓｈ
   （Ｓ_a））を復号化して、セッション・キーの種Ｓ_aのハ
   ッシュ値Ｈａｓｈ'（Ｓ_a）を計算して、受信したハッシ
   ュ値Ｈａｓｈ（Ｓ_a）と一致するか否かによって、公開
   鍵における復号化に失敗したか否かを判別するステップ
   と、 復号化に失敗していないことに応答して、第２の装置
   が、相互認証用の乱数Ｎ _aを第１の装置に送信するステ
   ップと、 第１の装置が、受信した乱数Ｎ_aが自分で生成した乱数
   と等しいか否かで第２の装置を本人確認するステップ
   と、を具備することを特徴とする相互認証方法。
10. 【請求項１０】前記公開鍵暗号方式は、ＮＴＲＵ公開鍵
    暗号方式である、ことを特徴とする請求項９に記載の相
    互認証装置。
11. 【請求項１１】第１及び第２の装置がそれぞれ互いに生
    成したセッション・キーの種Ｓ_a及びＳ_bを基にセッショ
    ン・キーを生成するステップと、 第１及び第２の装置が該セッション・キーを用いた暗号
    データの送受信を行うステップと、をさらに備えること
    を特徴とする請求項９に記載の相互認証方法。
12. 【請求項１２】通信媒体を介して接続される他の装置と
    の間で所定の公開鍵暗号方式を用いて相互認証を行う相
    互認証装置であって、 相互認証用の乱数Ｎを発生する手段と、 セッション・キーの種となる乱数Ｓを発生する手段と、 セッション・キーの種のハッシュ値Ｈを計算する手段
    と、 乱数Ｎとセッション・キーの種Ｓとセッション・キーの
    種のハッシュ値Ｈを通信相手の公開鍵で暗号化して送信
    する手段と、 通信相手から受信した暗号データを自分の公開鍵で復号
    化して、通信相手の相互認証用の乱数Ｎ'と通信相手が
    生成したセッション・キーの種Ｓ'及びそのハッシュ値
    Ｈ'を取り出す手段と、 セッション・キーの種Ｓ'のハッシュ値Ｈ"を計算して、
    Ｈ'とＨ"が一致するか否かによって公開鍵における復号
    化に失敗したか否かを検査する手段と、を具備すること
    を特徴とする相互認証装置。
13. 【請求項１３】前記公開鍵暗号方式は、ＮＴＲＵ公開鍵
    暗号方式である、ことを特徴とする請求項１２に記載の
    相互認証装置。
14. 【請求項１４】通信相手から受信した暗号データから取
    り出した通信相手の相互認証用の乱数Ｎ'を通信相手に
    送信する手段と、 通信相手から受信した自分の相互認証用の乱数が、自分
    で発生した乱数Ｎと等しいか否かで、通信相手を本人確
    認する手段と、をさらに備えることを特徴とする請求項
    １２に記載の相互認証装置。
15. 【請求項１５】自身で生成したセッションキーの種Ｓ及
    び他の装置から受信したセッションキーの種Ｓ’を基に
    セッション・キーを生成する手段と、 該セッション・キーを用いて他の装置との暗号データの
    送受信を行う手段と、をさらに備えることを特徴とする
    請求項１２に記載の相互認証装置。
16. 【請求項１６】他の装置との間で所定の公開鍵暗号方式
    を用いて相互認証を行う相互認証方法であって、 相互認証用の乱数Ｎを発生するステップと、 セッション・キーの種となる乱数Ｓを発生するステップ
    と、 セッション・キーの種のハッシュ値Ｈを計算するステッ
    プと、 乱数Ｎとセッション・キーの種Ｓとセッション・キーの
    種のハッシュ値Ｈを通信相手の公開鍵で暗号化して送信
    するステップと、 通信相手から受信した暗号データを自分の公開鍵で復号
    化して、通信相手の相互認証用の乱数Ｎ'と通信相手が
    生成したセッション・キーの種Ｓ'及びそのハッシュ値
    Ｈ'を取り出すステップと、 セッション・キーの種Ｓ'のハッシュ値Ｈ"を計算して、
    Ｈ'とＨ"が一致するか否かによって公開鍵における復号
    化に失敗したか否かを検査するステップと、を具備する
    ことを特徴とする相互認証方法。
17. 【請求項１７】前記公開鍵暗号方式は、ＮＴＲＵ公開鍵
    暗号方式である、ことを特徴とする請求項１６に記載の
    相互認証方法。
18. 【請求項１８】通信相手から受信した暗号データから取
    り出した通信相手の相互認証用の乱数Ｎ'を通信相手に
    送信するステップと、 通信相手から受信した自分の相互認証用の乱数が、自分
    で発生した乱数Ｎと等しいか否かで、通信相手を本人確
    認するステップと、をさらに備えることを特徴とする請
    求項１６に記載の相互認証方法。
19. 【請求項１９】自身で生成したセッションキーの種Ｓ及
    び他の装置から受信したセッションキーの種Ｓ’を基に
    セッション・キーを生成するステップと、 該セッション・キーを用いて他の装置との暗号データの
    送受信を行うステップと、をさらに備えることを特徴と
    する請求項１６に記載の相互認証方法。
20. 【請求項２０】他の装置との間で所定の公開鍵暗号方式
    を用いて相互認証を行うための相互認証処理をコンピュ
    ータ・システム上で実行するように記述されたコンピュ
    ータ・ソフトウェアをコンピュータ可読形式で物理的に
    格納した記憶媒体であって、前記コンピュータ・ソフト
    ウェアは、 相互認証用の乱数Ｎを発生するステップと、 セッション・キーの種となる乱数Ｓを発生するステップ
    と、 セッション・キーの種のハッシュ値Ｈを計算するステッ
    プと、 乱数Ｎとセッション・キーの種Ｓとセッション・キーの
    種のハッシュ値Ｈを通信相手の公開鍵で暗号化して送信
    するステップと、 通信相手から受信した暗号データを自分の公開鍵で復号
    化して、通信相手の相互認証用の乱数Ｎ'と通信相手が
    生成したセッション・キーの種Ｓ'及びそのハッシュ値
    Ｈ'を取り出すステップと、 セッション・キーの種Ｓ'のハッシュ値Ｈ"を計算して、
    Ｈ'とＨ"が一致するか否かによって公開鍵における復号
    化に失敗したか否かを検査するステップと、を具備する
    ことを特徴とする記憶媒体。