JP2004304227A - 公開鍵証明書検証システム - Google Patents
公開鍵証明書検証システム Download PDFInfo
- Publication number
- JP2004304227A JP2004304227A JP2003091206A JP2003091206A JP2004304227A JP 2004304227 A JP2004304227 A JP 2004304227A JP 2003091206 A JP2003091206 A JP 2003091206A JP 2003091206 A JP2003091206 A JP 2003091206A JP 2004304227 A JP2004304227 A JP 2004304227A
- Authority
- JP
- Japan
- Prior art keywords
- public key
- certificate
- key certificate
- mobile terminal
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】大量のリソースを必要とせず、公開鍵証明書の有効性の検証をオフラインで実現することができる技術を提供する。
【解決手段】ＩＣカード２０ａは、公開鍵証明書Ｃａに対応する属性証明書ＡａをＡＡサーバ装置４０から取得し、ＩＣカード２０ａの書き換え可能な領域に書き込む。 ＩＣカード２０ａは、公開鍵証明書Ｃａおよび属性証明書書Ａａを携帯端末１０ｂへ送信する。ＩＣカード２０ｂは、公開鍵証明書Ｃａおよび属性証明書書Ａａを受信し、受信された前記属性証明書Ａａに記録されている有効期限を用いて、公開鍵証明書Ｃａの有効性を検証する。
【選択図】 図１
【解決手段】ＩＣカード２０ａは、公開鍵証明書Ｃａに対応する属性証明書ＡａをＡＡサーバ装置４０から取得し、ＩＣカード２０ａの書き換え可能な領域に書き込む。 ＩＣカード２０ａは、公開鍵証明書Ｃａおよび属性証明書書Ａａを携帯端末１０ｂへ送信する。ＩＣカード２０ｂは、公開鍵証明書Ｃａおよび属性証明書書Ａａを受信し、受信された前記属性証明書Ａａに記録されている有効期限を用いて、公開鍵証明書Ｃａの有効性を検証する。
【選択図】 図１
Description
【０００１】
【発明の属する分野】
本発明は、公開鍵証明書の有効性を検証するための技術に関する。
【０００２】
【従来の技術】
公開鍵暗号技術において、秘密鍵（私有鍵）および公開鍵のペア（以後、「鍵ペア」という）の有効性を証明する証明書が公開鍵証明書である。受け取った公開鍵証明書の有効性の検証方法としては、公開鍵証明書が正当な第三者機関に発行されたものであることを検証したり、公開鍵証明書が改竄されていないことを公開鍵等を用いて検証する方法以外に、有効期限内の証明書であるか否かを判定する第１の方法と、失効した証明書であるか否かを判定する第２の方法がある。
【０００３】
第１の方法では、現在時刻が公開鍵証明書に記録された有効期限内であるか否かを判定することになる。したがって、公開鍵証明書を有効とし続けるためには公開鍵証明書を更新し続ける必要がある。公開鍵証明書を更新する際には鍵ペアをも更新すべきであるから、第１の方法は、公開鍵証明書および鍵ペアが更新されることを前提としている。
【０００４】
第２の方法には、ＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）レスポンダを用いる方法とダウンロードしたＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を用いる方法がある。前者の方法では、公開鍵証明書の検証時に、オンラインで、当該証明書が失効しているか否かをＯＣＳＰレスポンダ（サーバ）に問い合わせる。後者の方法では、予め定められたサーバから最新のＣＲＬをネットワークを介して一定周期でダウンロードしておき、ダウンロードしたＣＲＬを用いて公開鍵証明書が失効しているか否かを判定する（非特許文献１参照。）。
【０００５】
【非特許文献１】
カーライル・アダムス，スティーブ・ロイド著，鈴木優一訳，「ＰＫＩ−公開鍵インフラストラクチャの概念、標準、展開」ピアソンエディケーション，２０００年７月１５日発行，Ｐ１０５
【０００６】
【発明が解決しようとする課題】
ところで、公開鍵証明書の有効性の検証をもって当該証明書を格納したＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カードの有効性の検証に代えることが行われている。この種のＩＣカードの耐タンパー性を向上させるために、鍵ペアを書き換え不可能な記憶領域に書き込むことが考えられる。
【０００７】
この場合、鍵ペアの更新が不可能となるから、公開鍵証明書の更新も無意味または不可能となる。公開鍵証明書が更新されないということは、有効期限が更新されないことを意味するから、有効期限を用いて検証する第１の方法の採用は不適当である。
【０００８】
また、ＩＣカードやＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの小型機器では、記憶や演算などの情報処理のために使用可能なリソースに限りがある。したがって、ＣＲＬを用いる方法の採用は困難である。ＯＣＳＰを用いる方法であれば、そのような携帯機器でも採用可能である。しかし、ＯＣＳＰを用いることができるのはインターネットと接続されているオンライン時のみである。つまり、公開鍵証明書の有効性をオフラインで検証する機会の多い小型機器については、上記の第２の方法を採用し難い。
【０００９】
本発明は、上述した事情に鑑みて為されたものであり、大量のリソースを必要とせず、公開鍵証明書の有効性の検証をオフラインで実現することができる技術を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上述した課題を解決するため、本発明は、秘密鍵を記憶した、記憶内容の書き換えが許容されていない第１の記憶手段と、公開鍵の正当性を証明する公開鍵証明書を記憶した第２の記憶手段と、第３の記憶手段と、前記公開鍵証明書に対応する属性証明書を予め定められたサーバ装置から取得し前記第３の記憶手段に書き込む更新手段と、前記公開鍵証明書および前記属性証明書を通信相手へ送信する送信手段とを有する第１の電子機器と、前記第１の電子機器から送信された前記公開鍵証明書および前記属性証明書を受信する受信手段と、前記受信手段により受信された前記属性証明書に記録されている有効期限を用いて、前記受信手段により受信された前記公開鍵証明書の有効性を検証する検証手段とを有する第２の電子機器とを有する公開鍵証明書検証システムを提供する。
【００１１】
本発明によれば、前記第１の電気機器は、前記公開鍵証明書に対応する属性証明書を前記サーバ装置から取得し、前記第３の記憶手段に書き込む。また、前記第１の電気機器は、前記公開鍵証明書および前記属性証明書を通信相手へ送信する。
前記第２の電気機器は、前記第１の電子機器から送信された前記公開鍵証明書および前記属性証明書を受信し、受信された前記属性証明書に記録されている有効期限を用いて、前記受信手段により受信された前記公開鍵証明書の有効性を検証する。
【００１２】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
［１．構成］
まず、本実施形態の構成について説明する。
［１．１．全体構成］
図１は、本発明の実施形態に係る通信システムの構成例を示す図である。図１に示されるように、この通信システムは、ＩＣカード２０ａが装着された携帯端末１０ａと、ＩＣカード２０ｂが装着された携帯端末１０ｂと、公開鍵証明書を発行する認証局（以下、「ＣＡ」（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）という）としてのＣＡサーバ装置４０と、属性証明書を発行する属性認証局（以下、「ＡＡ」（Ａｔｔｒｉｂｕｔｅ Ａｕｔｈｏｒｉｔｙ）という）としてのＡＡサーバ装置３０と、インターネットや移動通信網から構成される通信ネットワーク５０と、電子チケット等の電子バリューを携帯端末１０ａ、１０ｂに対して発行するインターネットショップサーバ６０とを備えている。
なお、図１には、携帯端末１０ａと携帯端末１０ｂとを図示しているが、携帯端末１０ａと携帯端末１０ｂとの構成は同一であるため、以下の説明では、特に両者を区別する必要がない限り、各々を携帯端末１０として説明する。また、同様に、ＩＣカード２０ａとＩＣカード２０ｂとについても、必要がない限り、各々をＩＣカード２０として説明する。
【００１３】
ＣＡサーバ装置４０と、ＡＡサーバ装置３０と、インターネットショップサーバ６０とは、通信ネットワーク５０のインターネットに接続されている。
携帯端末１０は、図示せぬ基地局を介して通信ネットワーク５０の移動網と接続されている。また、移動網は、図示せぬゲートウェイサーバを介してインターネットと接続されている。
【００１４】
携帯端末１０は、オンライン時には、インターネットショップサーバ６０より電子バリューを購入したり、ＣＡサーバ装置４０に公開鍵証明書の有効性を問い合わせたり、ＡＡサーバ装置３０より属性証明書の発行を受ける。
また、携帯端末１０は、オフライン時には、ＩＣカード２０に記憶されている電子バリューを、他の携帯端末１０に譲渡する。
ここで、「オンライン時」とは、携帯端末１０が、インターネットを介してＣＡサーバ装置４０やＡＡサーバ装置３０等の各種サーバ装置に接続されている状態をいう。
また、「オフライン時」とは、携帯端末１０が、インターネットを介して各種サーバ装置に接続されていない状態をいう。本実施形態においては、オフライン時には、携帯端末１０同士は、非接触ＩＣカード技術による通信を用いて、ピアツーピアで電子バリューを譲渡する。
【００１５】
［１．２．ＡＡサーバ装置］
次に、ＡＡサーバ装置３０について説明する。
ＡＡサーバ装置３０は、一般的なＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ装置の機能を備えており、例えば、携帯端末１０等の他の装置とＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルに従って、データを送受する。ＡＡサーバ装置３０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と記憶部と通信インターフェースとを備えている。
【００１６】
ＡＡサーバ装置３０の記憶部には、ＣＰＵに実行されることにより、以下の機能をＡＡサーバ装置３０に実現させるためのプログラムが記憶されている。
（１）公開鍵証明書を内包した、属性証明書の発行を依頼するためのＨＴＴＰリクエストを、携帯端末１０より受信したときに、公開鍵証明書の正当性を検証する機能。なお、属性証明書とは、詳細は後述するが、公開鍵証明書が発行された主体者の属性や権限を表すための証明書である。
（２）（１）の検証によって、公開鍵証明書が正当であると判定された場合に、当該公開鍵証明書と関連付けられた、１日限り有効な属性証明書を発行し、携帯端末１０に送信する機能。
【００１７】
次に、ＣＡサーバ装置４０について説明する。
ＣＡサーバ装置４０は、ＡＡサーバ装置３０と同様に、一般的なＷＷＷサーバ装置の機能を備えており、他の装置とＨＴＴＰプロトコルに従って、データを送受する。
また、ＣＡサーバ装置４０は、ＣＰＵと記憶部と通信インターフェースとを備えている。
ＣＡサーバ装置４０の記憶部には、ＣＰＵに実行されることにより、公開鍵証明書を発行したり、ＣＲＬを送信する機能を実現させるためのプログラムが記憶されている。
【００１８】
［１．３．携帯端末］
次に、図２を参照しつつ、携帯端末１０の構成について説明する。携帯端末１０は、携帯端末１０の各部を制御するＣＰＵと、操作に応じた情報をＣＰＵに引き渡すための操作部と、データを表示する表示部と、無線通信を行う無線通信部と、無線通信用のアンテナと、プログラムを記憶するプログラムエリアとを備えている。さらに、携帯端末１０は、ＩＣカード２０を装着するための装着部と、ＩＣカード２０とのデータの送受信を制御するＩＣ用無線通信部と、電波を発信したり、ＩＣカード２０とデータを送受信するためのＩＣ用アンテナとを備えている。
【００１９】
プログラムエリアには、例えば、１日に１回という周期で、ＡＡサーバ装置３０に対して、属性証明書の発行を要求するためのＨＴＴＰリクエストを、無線通信部より送信するための属性証明書用プログラムが記憶されている。当該属性証明書用プログラムは、図示せぬサーバ装置より携帯端末１０にダウンロードされて記憶される。また、この属性証明書用プログラムは、１日に１回タイマー起動されるようになっている。
また、プログラムエリアには、ＩＣ用アンテナより電波を発信し、他の携帯端末１０に装着されたＩＣカード２０とデータを送受信するためのプログラムが記憶されている。
また、プログラムエリアには、ＨＴＴＰプロトコルに従って、他の装置とデータを送受するためのプログラムが記憶されている。また、プログラムエリアには、図８に示されるシーケンスに従って、他の携帯端末１０との間で、公開鍵暗号方式に基づく相互認証を行うためのプログラムや、携帯端末１０から受信した属性証明書に記述されている有効期限の検証を行うためのプログラムや、当該検証を行った後に、ＩＣカード２０に記憶された電子バリューを、共通鍵暗号方式による暗号通信を用いて送信するためのプログラムが記憶されている。
【００２０】
［１．４．ＩＣカード］
次に、図２に示されるＩＣカード２０について説明する。
ＩＣカード２０は、非接触ＩＣカードであり、ＣＰＵや、記憶領域や、入出力部を備えている。
入出力部は、携帯端末１０とデータの授受を行う。
記憶領域には、記憶内容の書き換えが許容されていない記憶領域（以下、「書き換え不可な領域」という）と、記憶内容の書き換えが許容されている記憶領域（以下、「書き換え可能な領域」という）とが設けられている。
ここで、「書き換え不可な領域」とは、ＩＣカード２０の製造時に、当該記憶領域に書き込まれた記憶内容を、書き換えることができない領域をいう。
また、「書き換え可能な領域」とは、携帯端末１０より送信されるデータを当該記憶領域書き込んだり、当該データで記憶されている記憶内容を書き換えたりすることができる領域をいう。
【００２１】
ＩＣカード２０の書き換え不可な領域には、当該ＩＣカード２０の製造時に、公開鍵暗号方式における鍵ペア、及び、ＣＡが発行した公開鍵証明書（Ｃｅｒｔ）が記憶される。これらは、ＩＣカード２０を識別するためのＩＣカードＩＤが正当な情報であることを証明するためのものである。
また、ＩＣカード２０の書き換え可能な領域には、属性証明書や、インターネットショップサーバ６０から受信した電子バリューが記憶される。
【００２２】
図３には、公開鍵証明書のデータ構成を示す。
公開鍵証明書のデータ形式は、Ｘ．５０９形式に従っている。
図３に示されるように、公開鍵証明書には、当該公開鍵証明書を識別するための「シリアル番号」、証明される主体であるＩＣカードＩＤを表す「主体者」、当該公開鍵証明書が有効である期限を表す「有効期限」、ＩＣカード２０に記憶されている公開鍵や暗号アルゴリズムを表す「主体者情報」、公開鍵証明書を発行したＣＡを表す「発行者」、及びＣＡの署名を表す「ＣＡ署名」が含まれている。
【００２３】
図４には、属性証明書のデータ構成例を示す。
属性証明書のデータ形式は、Ｘ．５０９形式に従っている。
図４に示されるように、属性証明書には、公開鍵証明書と関連づけるための情報である「保持者（公開鍵証明書のシリアル番号）」や、属性証明書が有効である期間を表す「有効期限」や、保持者の権限やセキュリティ区分等を表す「属性」や、発行者であるＡＡの署名を表す「ＡＡ署名」が含まれている。
【００２４】
［２．動作］
次に、本実施形態の動作について説明する。
以下の説明では、ＩＣカード２０ａに記憶されている公開鍵証明書を公開鍵証明書Ｃａとし、同じく、ＩＣカード２０ａに記憶されている属性証明書を属性証明書Ａａとする。また、ＩＣカード２０ｂに記憶されている公開鍵証明書と属性証明書を、それぞれ公開鍵証明書Ｃｂ、属性証明書Ａｂとする。また、携帯端末１０ａに記憶されている公開鍵を公開鍵ＰＫａとし、携帯端末１０ｂに記憶されている公開鍵を公開鍵ＰＫｂとする。
【００２５】
［２．１．属性証明書発行時の動作］
まず、携帯端末１０ａが、ＡＡサーバ装置３０に対して、属性証明書Ａａの発行を要求するときの動作について説明する。
なお、前提として、携帯端末１０ａには、ＩＣカード２０ａが装着されており、携帯端末１０ａの記憶部には、図示せぬサーバ装置より属性証明書用プログラムがダウンロードされて記憶されているものとする。これにより、携帯端末１０ａのＣＰＵは、１日に１回、属性証明書用プログラムをタイマー起動する。また、ＩＣカード２０ａの書き換え不可な領域には、図６に示すデータ内容の公開鍵証明書Ｃａが記憶されているものとする。
【００２６】
以下では、日付“０３／０３／０１”に、属性証明書用プログラムが起動されたときの動作を、図５を参照しながら説明する。
属性証明書用プログラムが起動されると、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより、公開鍵証明書Ｃａを読み出す。そして、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃａを内包した、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストをアンテナより、ＡＡサーバ装置３０宛に送信する（プロセスＰ１）。
ＡＡサーバ装置３０のＣＰＵは、ＨＴＴＰリクエストを受信し、当該メッセージに内包されている公開鍵証明書Ｃａの有効性を検証する（プロセスＰ２）。
具体的には、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａを、一般的な公開暗号証方式を用いて検証する。すなわち、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書ＣａのＣＡ署名以外のデータを、ハッシュ関数を用いて演算した値と、ＣＡ署名をＣＡの公開鍵を用いて復号した値とを比較し、一致しているか否かを判定する。一致しない場合には、ＡＡサーバ装置３０のＣＰＵは、エラーメッセージを送信して処理を終了する。
一致していた場合には、ＡＡサーバ装置３０のＣＰＵは、ＣＲＬを要求するためのＣＲＬ要求データを内包したＨＴＴＰリクエストを、ＣＡサーバ装置４０宛に送信する。
ＣＡサーバ装置４０のＣＰＵは、当該ＨＴＴＰリクエストを受信し、ＡＡサーバ装置３０宛にＣＲＬを内包したＨＴＴＰレスポンスを送信する。
ＡＡサーバ装置３０のＣＰＵは、受信したＨＴＴＰレスポンスに内包されたＣＲＬを参照することにより、公開鍵証明書Ｃａが失効しているか否かを判定する。失効していた場合には、ＡＡサーバ装置３０のＣＰＵは、エラーメッセージを送信して処理を終了する。
【００２７】
ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａが失効していないと判定された場合には、属性証明書Ａａを発行するための処理を行う。
具体的には、ＡＡサーバ装置３０のＣＰＵは、まず、属性証明書に必要な情報を編集する。詳細には、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａのシリアル番号“１２３４”と同一の番号を属性証明書Ａａの「保持者」とし、「有効期限」を１日後の“２００３／０３／０２”とし、その他、Ｘ．５０９に定義された属性証明書に必要な情報を編集する。次に、ＡＡサーバ装置３０のＣＰＵは、編集された情報を、ＡＡの秘密鍵で暗号化することにより、ＡＡの署名を生成する。
そして、ＡＡサーバ装置３０のＣＰＵは、上述した情報や生成されたＡＡの署名が記述された、図７に示す属性証明書Ａａを生成する。ＡＡサーバ装置３０のＣＰＵは、属性証明書Ａａを内包したＨＴＴＰレスポンスを生成し、携帯端末１０ａ宛に送信する（プロセスＰ３）。
【００２８】
携帯端末１０ａのＣＰＵは、ＨＴＴＰレスポンスを受信し、当該ＨＴＴＰレスポンスに内包されている属性証明書Ａａを、ＩＣカード２０ａの書き換え可能な領域に記憶する。
【００２９】
［２．２．電子バリュー譲渡時］
次に、携帯端末１０ａを用いて、インターネットショップサーバ６０より電子チケット等の電子バリューを購入したユーザＡが、携帯端末１０ｂを所有するユーザＢに対して、電子バリューをオフラインで譲渡するときの動作について、図８を参照しながら説明する。
【００３０】
前提として、ユーザＢの所有する携帯端末１０ｂには、携帯端末１０ａと同様に、ＩＣカード２０ｂが装着され、１日毎に属性証明書Ａｂを受信している。
また、携帯端末１０ａに装着されたＩＣカード２０ａには、“０３／０３／０２”を有効期限とする属性証明書Ａａ（図７参照）と、図６に示すデータ内容の公開鍵証明書Ｃａとが記憶されているものとする。また、ユーザＡがインターネットショップサーバ６０より購入した電子バリューは、ＩＣカード２０ａの書き換え可能な領域に記憶されているものとする。
また、ＩＣカード２０ｂ内には、図９に示すデータ内容の公開鍵証明書Ｃｂと属性証明書Ａｂが記憶されているものとする。
【００３１】
まず、ユーザＡは、携帯端末１０ａの操作部を操作して、携帯端末１０ｂに対してオフラインで電子バリューを送信するための指示を行う。
これにより、携帯端末１０ａのＣＰＵは、ＩＣ用アンテナより電波を送出する。
携帯端末１０ｂのＣＰＵは、電波を受信して、携帯端末１０ａにＩＣカード２０ｂのＩＤを内包したレスポンスを返す。これにより、携帯端末１０ａに装着されたＩＣカード２０ａと携帯端末１０ａに装着されたＩＣカード２０ｂとの間の通信が確立する。
次に、携帯端末１０ａのＣＰＵは、公開鍵暗号方式に基づく相互認証を行う。具体的には、まず、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより、公開鍵証明書Ｃａと属性証明書Ａａを読み出す。そして、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃａと属性証明書Ａａとを内包した、メッセージＤ１をＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３２】
携帯端末１０ｂのＣＰＵは、メッセージＤ１を受信し、ステップＳ１０１の処理を行う。
具体的には、まず、携帯端末１０ｂのＣＰＵは、メッセージＤ１に内包されている公開鍵証明書Ｃａの検証を行う。すなわち、携帯端末１０ｂのＣＰＵは、公開鍵証明書Ｃａに記述されているＣＡ署名と公開鍵ＰＫａとを用いて、一般的な公開鍵暗号方式により、公開鍵証明書Ｃａの正当性を検証する。さらに、携帯端末１０ｂのＣＰＵは、現在日付“２００３／０３／０１”が、公開鍵証明書Ｃａの有効期限“２００３／１２／３１”を過ぎていないことを検証する。
次に、携帯端末１０ｂのＣＰＵは、メッセージＤ１に内包されている属性証明書Ａａの検証を行う。具体的には、携帯端末１０ｂのＣＰＵは、属性証明書Ａａに記述されている有効期限“０３／０３／０２”と属性“１日限り正当性を保証”とから、属性証明書Ａａが１日だけ有効であることを証明するものであり、現在日時“２００３／０３／０１”が有効期限“０３／０３／０２”を過ぎていないことを確認する。
【００３３】
次に、携帯端末１０ｂのＣＰＵは、一般的な方法により、乱数Ｒｂを生成する。そして、携帯端末１０ｂのＣＰＵは、受信した公開鍵証明書Ｃａに記述されている公開鍵ＰＫａを用いて、生成した乱数Ｒｂを、例えば、Ｓｈａｒｅｄ Ｓｅｃｒｅｔにより暗号化することにより、暗号化データＥｂを生成する。
次に、携帯端末１０ｂのＣＰＵは、ＩＣカード２０ｂより、公開鍵証明書Ｃｂと属性証明書Ａｂとを読み出す。そして、携帯端末１０ｂのＣＰＵは、読み出した公開鍵証明書Ｃｂと属性証明書Ａｂと、生成した暗号化データＥｂとを内包したメッセージＤ２を、ＩＣ用アンテナより携帯端末１０ａ宛に送信する。
【００３４】
携帯端末１０ａのＣＰＵは、メッセージＤ２を受信し、ステップＳ１０２の処理を行う。
具体的には、ステップＳ１０１における処理と同様に、携帯端末１０ａのＣＰＵは、まず、メッセージＤ２に内包されている公開鍵証明書Ｃｂを検証する。すなわち、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃｂに記述されているＣＡ署名と公開鍵ＫＢｂとを用いて、一般的な公開鍵暗号方式で、公開鍵証明書Ｃｂの正当性を検証する。また、携帯端末１０ａのＣＰＵは、現在日付“２００３／０３／０１”が、公開鍵証明書Ｃｂに記述されている有効期限“２００４／０１／０７”を過ぎていないことを検証する。
次に、携帯端末１０ａのＣＰＵは、属性証明書Ａｂを検証する。具体的には、携帯端末１０ａのＣＰＵは、属性証明書Ａｂに記述されている有効期限“０３／０３／０２”と属性“１日限り正当性を保証”とから、属性証明書Ａａが１日だけ有効であることを証明するものであり、現在日時“２００３／０３／０１”が有効期限“０３／０３／０２”を経過していないことを確認する。
【００３５】
次に、携帯端末１０ａのＣＰＵは、一般的な方法により、乱数Ｒａを生成する。そして、携帯端末１０ｂのＣＰＵは、受信した公開鍵証明書Ｃａに記述されている公開鍵ＰＫａを用いて、生成した乱数Ｒａを、例えば、Ｓｈａｒｅｄ Ｓｅｃｒｅｔにより暗号化することにより、暗号化データＥａを生成する。
次に、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより公開鍵証明書Ｃａと属性証明書Ａａとを読み出す。そして、携帯端末１０ａのＣＰＵは、読み出した公開鍵証明書Ｃａと属性証明書Ａａと、生成した暗号化データＥａとを内包したメッセージＤ３をＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３６】
携帯端末１０ｂのＣＰＵは、メッセージＤ３を受信し、ステップＳ１０３の処理を行う。
具体的には、携帯端末１０ｂのＣＰＵは、まず、一般的な方法で、乱数Ｒａと乱数Ｒｂとから、特定の関数を用いて、共通鍵Ｋａｂを生成する。
次に、携帯端末１０ｂのＣＰＵは、メッセージＤ１、Ｄ２、Ｄ３に対するメッセージ認証コード（メッセージ認証コード；Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）ＭＡＣｂを、共通鍵Ｋａｂを用いて生成する。
そして、携帯端末１０ｂのＣＰＵは、生成したメッセージ認証コードＭＡＣｂを内包したメッセージＤ４を、ＩＣ用アンテナより携帯端末１０ａ宛に送信する。
【００３７】
携帯端末１０ａのＣＰＵは、メッセージＤ４を受信し、ステップＳ１０４の処理を行う。
具体的には、まず、携帯端末１０ａのＣＰＵは、一般的な方法で、乱数Ｒａと乱数Ｒｂとから、特定の関数を用いて、共通鍵Ｋａｂを生成する。
そして、携帯端末１０ａのＣＰＵは、受信したメッセージＤ４に内包されるメッセージ認証コードＭＡＣｂを、一般的なＭＡＣの認証方法で検証する。
次に、携帯端末１０ａのＣＰＵは、メッセージＤ１、Ｄ２、Ｄ３、Ｄ４に対するメッセージ認証コード（メッセージ認証コード；Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）ＭＡＣａを、共通鍵Ｋａｂを用いて生成する。
携帯端末１０ａのＣＰＵは、生成したメッセージ認証コードＭＡＣａを内包したメッセージＤ５を、ＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３８】
携帯端末１０ｂのＣＰＵは、メッセージＤ５を受信し、メッセージＤ５に内包されているメッセージ認証コードＭＡＣａを、一般的なＭＡＣの認証方法で検証する（ステップＳ１０５）。
以上の検証結果や認証結果が全て正当であった場合に、携帯端末１０ａと携帯端末１０ａのＣＰＵは、相互認証が成功したと判定する。
なお、上述した検証結果や認証結果に正当でないものが存在した場合には、正当でないと判定された時点で、ＣＰＵはエラーメッセージを送信して処理を終了する。
【００３９】
認証が成功したと判定された場合には、携帯端末１０ａと、携帯端末１０ｂとは、共通鍵Ｋａｂ用いた共通暗号方式による通信を行う（ステップＳ１０６）。
ここでは、携帯端末１０ａは、ＩＣカード２０ａに記憶されている電子バリューを読み出し、共通鍵Ｋａｂで暗号化して、携帯端末１０ｂに送信する。
携帯端末１０ｂは、暗号化された電子バリューを受信し、共通鍵Ｋａｂで復号して、ＩＣカード２０ｂの書き換え可能な領域に記憶する。
【００４０】
以上のように、本発明によれば、公開鍵証明書の有効期限を変更せずに、オフラインで有効期限の検証を行うことが可能となる。
また、鍵ペアや公開鍵証明書をＩＣカード２０内の書き換え不可な領域に記憶させたことにより、安全性を高めることができる。
また、オフラインで有効期限の検証を行うことができるようにしたため、携帯端末１０は、インターネットに接続することなく、相手の携帯端末１０に装着されているＩＣカード２０の有効性の検証を容易に行うことが可能となる。
また、データ量の大きいＣＲＬを使用する必要がないために、携帯端末１０やＩＣカード２０のような記憶容量が少ない装置であっても、有効期限の検証を容易に行うことができる。
【００４１】
［３．変形例］
以上、本発明の実施形態について説明したが、この実施形態はあくまでも例示であり、本発明の趣旨から逸脱しない範囲で様々な変形が可能である。変形例としては、例えば以下のようなものが考えられる。
【００４２】
（１）上記実施形態においては、オフライン時における携帯端末１０間のピアツーピアの通信を、非接触ＩＣカードの技術を利用した通信として説明したが、これに限定されず、例えば、ピアツーピアの通信は、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）や、ブルートゥース（登録商標）等の近距離無線通信手段や、通信ケーブルを介した有線通信手段を用いたり、また、インターネットを利用せずに移動網のみを介した通信でもよい。
（２）上記実施形態における属性証明書発行時には、ＡＡサーバ装置３０は、携帯端末１０ａより、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストを受信したときに、属性証明書Ａａを発行する処理を行ったが、これに限定されず、１日に１回定期的に属性証明書Ａａを生成し、記憶部に記憶しておいてもよい。
【００４３】
（３）上記実施形態においては、［２．２．電子バリュー譲渡時］において、オフラインを前提として、公開鍵証明書の有効性を検証したが、これに限定されず、オンラインでＣＡサーバ装置４０にアクセスできなかった場合にのみ、オフラインで公開鍵証明書の有効性を検証するようにしてもよい。
（４）上記実施形態においては、属性証明書用プログラムは、１日に１回という周期で起動されることとしたが、起動される周期はこれに限定されず、例えば、２日に１回起動されてもよい。
【００４４】
（５）上記実施形態においては、ＩＣカード２０の製造時に、ＩＣカード２０の書き換え不可な領域に公開鍵証明書や鍵ペアが予め記憶されているとして説明したが、公開鍵証明書や鍵ペアを記憶するのは製造時に限定されない。例えば、製造後に、販売店にてＩＣカード２０に公開鍵証明書や鍵ペアが書き込まれて、書き込まれた領域が書き換え不可な領域に設定されてもよい。また、携帯端末１０にＩＣカード２０が装着された後に、ＩＣカード２０に公開鍵証明書や鍵ペアが書き込まれ、書き込まれた領域が書き換え不可に設定されてもよい。
（６）上記実施形態においては、図８に示されるシーケンスによる相互認証を行ったが、相互認証の方法はこれに限定されない。例えば、パスワードを用いた相互認証でもよい。
（７）上記実施形態においては、ステップＳ１０１とステップＳ１０２において、有効期限を検証する際に、公開鍵証明書と属性証明書との有効期限が現在日付を過ぎていないことを検証したが、属性証明書の有効期限のみを検証してもよい。
（８）上記実施形態においては、ＡＡサーバ装置３０が、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストを受信したときに、ＣＲＬを用いて公開鍵証明書Ｃａが失効しているか否かを確認したが、これに限定されず、ＯＣＳＰレスポンダに問い合わせることによって、公開鍵証明書Ｃａが失効しているか否かを確認してもよい。
【００４５】
（９）上記実施形態においては、属性証明書用プログラムをタイマー起動するようにしたが、ユーザＡが、１日に１回、携帯端末１０ａを操作して、手動で属性証明書用プログラムを起動するようにしてもよい。
また、属性証明書用プログラムを自動起動したときに、携帯端末１０ａが、電波が届かない位置に位置していたために、属性証明書Ａａを要求するためのデータをＡＡサーバ装置３０に送信できなかった場合には、携帯端末１０ａの表示部に、ユーザＡが手動で属性証明書用プログラムを起動することを促すためのメッセージを表示するようにしてもよい。
（１０）上記実施形態においては、ＣＡサーバ装置４０とＡＡサーバ装置３０とを使用したが、ＣＡサーバ装置４０とＡＡサーバ装置３０の機能を備えた１つのサーバ装置を使用することも可能である。
【００４６】
【発明の効果】
以上説明したように、本発明によれば、大量のリソースを必要とせず、公開鍵証明書の有効性の検証をオフラインで実現することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る通信システムの構成を示すブロック図である。
【図２】同実施形態に係る携帯端末のハードウェア構成を示すブロック図である。
【図３】同実施形態に係る公開鍵証明書のデータ構成を示す図である。
【図４】同実施形態に係る属性証明書のデータ構成を示す図である。
【図５】同実施形態に係る属性証明書発行時の処理を示す図である。
【図６】同実施形態に係る属性証明書発行時のＩＣカード２０ａに記憶されている公開鍵証明書Ｃａのデータ構成を示す図である。
【図７】同実施形態に係る属性証明書発行時のＩＣカード２０ａに記憶される属性証明書Ａａのデータ構成を示す図である。
【図８】同実施形態に係る電子バリュー譲渡時のシーケンスを示す図である。
【図９】同実施形態に係る電子バリュー譲渡時のＩＣカード２０ｂに記憶されている公開鍵証明書Ｃｂと属性証明書Ａｂとのデータ構成を示す図である。
【符号の説明】
１０、１０ａ、１０ｂ……携帯端末、２０、２０ａ、２０ｂ……ＩＣカード、３０……ＡＡサーバ装置、４０……ＣＡサーバ装置、５０……通信ネットワーク、６０……インターネットショップサーバ。
【発明の属する分野】
本発明は、公開鍵証明書の有効性を検証するための技術に関する。
【０００２】
【従来の技術】
公開鍵暗号技術において、秘密鍵（私有鍵）および公開鍵のペア（以後、「鍵ペア」という）の有効性を証明する証明書が公開鍵証明書である。受け取った公開鍵証明書の有効性の検証方法としては、公開鍵証明書が正当な第三者機関に発行されたものであることを検証したり、公開鍵証明書が改竄されていないことを公開鍵等を用いて検証する方法以外に、有効期限内の証明書であるか否かを判定する第１の方法と、失効した証明書であるか否かを判定する第２の方法がある。
【０００３】
第１の方法では、現在時刻が公開鍵証明書に記録された有効期限内であるか否かを判定することになる。したがって、公開鍵証明書を有効とし続けるためには公開鍵証明書を更新し続ける必要がある。公開鍵証明書を更新する際には鍵ペアをも更新すべきであるから、第１の方法は、公開鍵証明書および鍵ペアが更新されることを前提としている。
【０００４】
第２の方法には、ＯＣＳＰ（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ）レスポンダを用いる方法とダウンロードしたＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）を用いる方法がある。前者の方法では、公開鍵証明書の検証時に、オンラインで、当該証明書が失効しているか否かをＯＣＳＰレスポンダ（サーバ）に問い合わせる。後者の方法では、予め定められたサーバから最新のＣＲＬをネットワークを介して一定周期でダウンロードしておき、ダウンロードしたＣＲＬを用いて公開鍵証明書が失効しているか否かを判定する（非特許文献１参照。）。
【０００５】
【非特許文献１】
カーライル・アダムス，スティーブ・ロイド著，鈴木優一訳，「ＰＫＩ−公開鍵インフラストラクチャの概念、標準、展開」ピアソンエディケーション，２０００年７月１５日発行，Ｐ１０５
【０００６】
【発明が解決しようとする課題】
ところで、公開鍵証明書の有効性の検証をもって当該証明書を格納したＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カードの有効性の検証に代えることが行われている。この種のＩＣカードの耐タンパー性を向上させるために、鍵ペアを書き換え不可能な記憶領域に書き込むことが考えられる。
【０００７】
この場合、鍵ペアの更新が不可能となるから、公開鍵証明書の更新も無意味または不可能となる。公開鍵証明書が更新されないということは、有効期限が更新されないことを意味するから、有効期限を用いて検証する第１の方法の採用は不適当である。
【０００８】
また、ＩＣカードやＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）などの小型機器では、記憶や演算などの情報処理のために使用可能なリソースに限りがある。したがって、ＣＲＬを用いる方法の採用は困難である。ＯＣＳＰを用いる方法であれば、そのような携帯機器でも採用可能である。しかし、ＯＣＳＰを用いることができるのはインターネットと接続されているオンライン時のみである。つまり、公開鍵証明書の有効性をオフラインで検証する機会の多い小型機器については、上記の第２の方法を採用し難い。
【０００９】
本発明は、上述した事情に鑑みて為されたものであり、大量のリソースを必要とせず、公開鍵証明書の有効性の検証をオフラインで実現することができる技術を提供することを目的とする。
【００１０】
【課題を解決するための手段】
上述した課題を解決するため、本発明は、秘密鍵を記憶した、記憶内容の書き換えが許容されていない第１の記憶手段と、公開鍵の正当性を証明する公開鍵証明書を記憶した第２の記憶手段と、第３の記憶手段と、前記公開鍵証明書に対応する属性証明書を予め定められたサーバ装置から取得し前記第３の記憶手段に書き込む更新手段と、前記公開鍵証明書および前記属性証明書を通信相手へ送信する送信手段とを有する第１の電子機器と、前記第１の電子機器から送信された前記公開鍵証明書および前記属性証明書を受信する受信手段と、前記受信手段により受信された前記属性証明書に記録されている有効期限を用いて、前記受信手段により受信された前記公開鍵証明書の有効性を検証する検証手段とを有する第２の電子機器とを有する公開鍵証明書検証システムを提供する。
【００１１】
本発明によれば、前記第１の電気機器は、前記公開鍵証明書に対応する属性証明書を前記サーバ装置から取得し、前記第３の記憶手段に書き込む。また、前記第１の電気機器は、前記公開鍵証明書および前記属性証明書を通信相手へ送信する。
前記第２の電気機器は、前記第１の電子機器から送信された前記公開鍵証明書および前記属性証明書を受信し、受信された前記属性証明書に記録されている有効期限を用いて、前記受信手段により受信された前記公開鍵証明書の有効性を検証する。
【００１２】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
［１．構成］
まず、本実施形態の構成について説明する。
［１．１．全体構成］
図１は、本発明の実施形態に係る通信システムの構成例を示す図である。図１に示されるように、この通信システムは、ＩＣカード２０ａが装着された携帯端末１０ａと、ＩＣカード２０ｂが装着された携帯端末１０ｂと、公開鍵証明書を発行する認証局（以下、「ＣＡ」（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）という）としてのＣＡサーバ装置４０と、属性証明書を発行する属性認証局（以下、「ＡＡ」（Ａｔｔｒｉｂｕｔｅ Ａｕｔｈｏｒｉｔｙ）という）としてのＡＡサーバ装置３０と、インターネットや移動通信網から構成される通信ネットワーク５０と、電子チケット等の電子バリューを携帯端末１０ａ、１０ｂに対して発行するインターネットショップサーバ６０とを備えている。
なお、図１には、携帯端末１０ａと携帯端末１０ｂとを図示しているが、携帯端末１０ａと携帯端末１０ｂとの構成は同一であるため、以下の説明では、特に両者を区別する必要がない限り、各々を携帯端末１０として説明する。また、同様に、ＩＣカード２０ａとＩＣカード２０ｂとについても、必要がない限り、各々をＩＣカード２０として説明する。
【００１３】
ＣＡサーバ装置４０と、ＡＡサーバ装置３０と、インターネットショップサーバ６０とは、通信ネットワーク５０のインターネットに接続されている。
携帯端末１０は、図示せぬ基地局を介して通信ネットワーク５０の移動網と接続されている。また、移動網は、図示せぬゲートウェイサーバを介してインターネットと接続されている。
【００１４】
携帯端末１０は、オンライン時には、インターネットショップサーバ６０より電子バリューを購入したり、ＣＡサーバ装置４０に公開鍵証明書の有効性を問い合わせたり、ＡＡサーバ装置３０より属性証明書の発行を受ける。
また、携帯端末１０は、オフライン時には、ＩＣカード２０に記憶されている電子バリューを、他の携帯端末１０に譲渡する。
ここで、「オンライン時」とは、携帯端末１０が、インターネットを介してＣＡサーバ装置４０やＡＡサーバ装置３０等の各種サーバ装置に接続されている状態をいう。
また、「オフライン時」とは、携帯端末１０が、インターネットを介して各種サーバ装置に接続されていない状態をいう。本実施形態においては、オフライン時には、携帯端末１０同士は、非接触ＩＣカード技術による通信を用いて、ピアツーピアで電子バリューを譲渡する。
【００１５】
［１．２．ＡＡサーバ装置］
次に、ＡＡサーバ装置３０について説明する。
ＡＡサーバ装置３０は、一般的なＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）サーバ装置の機能を備えており、例えば、携帯端末１０等の他の装置とＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルに従って、データを送受する。ＡＡサーバ装置３０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と記憶部と通信インターフェースとを備えている。
【００１６】
ＡＡサーバ装置３０の記憶部には、ＣＰＵに実行されることにより、以下の機能をＡＡサーバ装置３０に実現させるためのプログラムが記憶されている。
（１）公開鍵証明書を内包した、属性証明書の発行を依頼するためのＨＴＴＰリクエストを、携帯端末１０より受信したときに、公開鍵証明書の正当性を検証する機能。なお、属性証明書とは、詳細は後述するが、公開鍵証明書が発行された主体者の属性や権限を表すための証明書である。
（２）（１）の検証によって、公開鍵証明書が正当であると判定された場合に、当該公開鍵証明書と関連付けられた、１日限り有効な属性証明書を発行し、携帯端末１０に送信する機能。
【００１７】
次に、ＣＡサーバ装置４０について説明する。
ＣＡサーバ装置４０は、ＡＡサーバ装置３０と同様に、一般的なＷＷＷサーバ装置の機能を備えており、他の装置とＨＴＴＰプロトコルに従って、データを送受する。
また、ＣＡサーバ装置４０は、ＣＰＵと記憶部と通信インターフェースとを備えている。
ＣＡサーバ装置４０の記憶部には、ＣＰＵに実行されることにより、公開鍵証明書を発行したり、ＣＲＬを送信する機能を実現させるためのプログラムが記憶されている。
【００１８】
［１．３．携帯端末］
次に、図２を参照しつつ、携帯端末１０の構成について説明する。携帯端末１０は、携帯端末１０の各部を制御するＣＰＵと、操作に応じた情報をＣＰＵに引き渡すための操作部と、データを表示する表示部と、無線通信を行う無線通信部と、無線通信用のアンテナと、プログラムを記憶するプログラムエリアとを備えている。さらに、携帯端末１０は、ＩＣカード２０を装着するための装着部と、ＩＣカード２０とのデータの送受信を制御するＩＣ用無線通信部と、電波を発信したり、ＩＣカード２０とデータを送受信するためのＩＣ用アンテナとを備えている。
【００１９】
プログラムエリアには、例えば、１日に１回という周期で、ＡＡサーバ装置３０に対して、属性証明書の発行を要求するためのＨＴＴＰリクエストを、無線通信部より送信するための属性証明書用プログラムが記憶されている。当該属性証明書用プログラムは、図示せぬサーバ装置より携帯端末１０にダウンロードされて記憶される。また、この属性証明書用プログラムは、１日に１回タイマー起動されるようになっている。
また、プログラムエリアには、ＩＣ用アンテナより電波を発信し、他の携帯端末１０に装着されたＩＣカード２０とデータを送受信するためのプログラムが記憶されている。
また、プログラムエリアには、ＨＴＴＰプロトコルに従って、他の装置とデータを送受するためのプログラムが記憶されている。また、プログラムエリアには、図８に示されるシーケンスに従って、他の携帯端末１０との間で、公開鍵暗号方式に基づく相互認証を行うためのプログラムや、携帯端末１０から受信した属性証明書に記述されている有効期限の検証を行うためのプログラムや、当該検証を行った後に、ＩＣカード２０に記憶された電子バリューを、共通鍵暗号方式による暗号通信を用いて送信するためのプログラムが記憶されている。
【００２０】
［１．４．ＩＣカード］
次に、図２に示されるＩＣカード２０について説明する。
ＩＣカード２０は、非接触ＩＣカードであり、ＣＰＵや、記憶領域や、入出力部を備えている。
入出力部は、携帯端末１０とデータの授受を行う。
記憶領域には、記憶内容の書き換えが許容されていない記憶領域（以下、「書き換え不可な領域」という）と、記憶内容の書き換えが許容されている記憶領域（以下、「書き換え可能な領域」という）とが設けられている。
ここで、「書き換え不可な領域」とは、ＩＣカード２０の製造時に、当該記憶領域に書き込まれた記憶内容を、書き換えることができない領域をいう。
また、「書き換え可能な領域」とは、携帯端末１０より送信されるデータを当該記憶領域書き込んだり、当該データで記憶されている記憶内容を書き換えたりすることができる領域をいう。
【００２１】
ＩＣカード２０の書き換え不可な領域には、当該ＩＣカード２０の製造時に、公開鍵暗号方式における鍵ペア、及び、ＣＡが発行した公開鍵証明書（Ｃｅｒｔ）が記憶される。これらは、ＩＣカード２０を識別するためのＩＣカードＩＤが正当な情報であることを証明するためのものである。
また、ＩＣカード２０の書き換え可能な領域には、属性証明書や、インターネットショップサーバ６０から受信した電子バリューが記憶される。
【００２２】
図３には、公開鍵証明書のデータ構成を示す。
公開鍵証明書のデータ形式は、Ｘ．５０９形式に従っている。
図３に示されるように、公開鍵証明書には、当該公開鍵証明書を識別するための「シリアル番号」、証明される主体であるＩＣカードＩＤを表す「主体者」、当該公開鍵証明書が有効である期限を表す「有効期限」、ＩＣカード２０に記憶されている公開鍵や暗号アルゴリズムを表す「主体者情報」、公開鍵証明書を発行したＣＡを表す「発行者」、及びＣＡの署名を表す「ＣＡ署名」が含まれている。
【００２３】
図４には、属性証明書のデータ構成例を示す。
属性証明書のデータ形式は、Ｘ．５０９形式に従っている。
図４に示されるように、属性証明書には、公開鍵証明書と関連づけるための情報である「保持者（公開鍵証明書のシリアル番号）」や、属性証明書が有効である期間を表す「有効期限」や、保持者の権限やセキュリティ区分等を表す「属性」や、発行者であるＡＡの署名を表す「ＡＡ署名」が含まれている。
【００２４】
［２．動作］
次に、本実施形態の動作について説明する。
以下の説明では、ＩＣカード２０ａに記憶されている公開鍵証明書を公開鍵証明書Ｃａとし、同じく、ＩＣカード２０ａに記憶されている属性証明書を属性証明書Ａａとする。また、ＩＣカード２０ｂに記憶されている公開鍵証明書と属性証明書を、それぞれ公開鍵証明書Ｃｂ、属性証明書Ａｂとする。また、携帯端末１０ａに記憶されている公開鍵を公開鍵ＰＫａとし、携帯端末１０ｂに記憶されている公開鍵を公開鍵ＰＫｂとする。
【００２５】
［２．１．属性証明書発行時の動作］
まず、携帯端末１０ａが、ＡＡサーバ装置３０に対して、属性証明書Ａａの発行を要求するときの動作について説明する。
なお、前提として、携帯端末１０ａには、ＩＣカード２０ａが装着されており、携帯端末１０ａの記憶部には、図示せぬサーバ装置より属性証明書用プログラムがダウンロードされて記憶されているものとする。これにより、携帯端末１０ａのＣＰＵは、１日に１回、属性証明書用プログラムをタイマー起動する。また、ＩＣカード２０ａの書き換え不可な領域には、図６に示すデータ内容の公開鍵証明書Ｃａが記憶されているものとする。
【００２６】
以下では、日付“０３／０３／０１”に、属性証明書用プログラムが起動されたときの動作を、図５を参照しながら説明する。
属性証明書用プログラムが起動されると、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより、公開鍵証明書Ｃａを読み出す。そして、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃａを内包した、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストをアンテナより、ＡＡサーバ装置３０宛に送信する（プロセスＰ１）。
ＡＡサーバ装置３０のＣＰＵは、ＨＴＴＰリクエストを受信し、当該メッセージに内包されている公開鍵証明書Ｃａの有効性を検証する（プロセスＰ２）。
具体的には、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａを、一般的な公開暗号証方式を用いて検証する。すなわち、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書ＣａのＣＡ署名以外のデータを、ハッシュ関数を用いて演算した値と、ＣＡ署名をＣＡの公開鍵を用いて復号した値とを比較し、一致しているか否かを判定する。一致しない場合には、ＡＡサーバ装置３０のＣＰＵは、エラーメッセージを送信して処理を終了する。
一致していた場合には、ＡＡサーバ装置３０のＣＰＵは、ＣＲＬを要求するためのＣＲＬ要求データを内包したＨＴＴＰリクエストを、ＣＡサーバ装置４０宛に送信する。
ＣＡサーバ装置４０のＣＰＵは、当該ＨＴＴＰリクエストを受信し、ＡＡサーバ装置３０宛にＣＲＬを内包したＨＴＴＰレスポンスを送信する。
ＡＡサーバ装置３０のＣＰＵは、受信したＨＴＴＰレスポンスに内包されたＣＲＬを参照することにより、公開鍵証明書Ｃａが失効しているか否かを判定する。失効していた場合には、ＡＡサーバ装置３０のＣＰＵは、エラーメッセージを送信して処理を終了する。
【００２７】
ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａが失効していないと判定された場合には、属性証明書Ａａを発行するための処理を行う。
具体的には、ＡＡサーバ装置３０のＣＰＵは、まず、属性証明書に必要な情報を編集する。詳細には、ＡＡサーバ装置３０のＣＰＵは、公開鍵証明書Ｃａのシリアル番号“１２３４”と同一の番号を属性証明書Ａａの「保持者」とし、「有効期限」を１日後の“２００３／０３／０２”とし、その他、Ｘ．５０９に定義された属性証明書に必要な情報を編集する。次に、ＡＡサーバ装置３０のＣＰＵは、編集された情報を、ＡＡの秘密鍵で暗号化することにより、ＡＡの署名を生成する。
そして、ＡＡサーバ装置３０のＣＰＵは、上述した情報や生成されたＡＡの署名が記述された、図７に示す属性証明書Ａａを生成する。ＡＡサーバ装置３０のＣＰＵは、属性証明書Ａａを内包したＨＴＴＰレスポンスを生成し、携帯端末１０ａ宛に送信する（プロセスＰ３）。
【００２８】
携帯端末１０ａのＣＰＵは、ＨＴＴＰレスポンスを受信し、当該ＨＴＴＰレスポンスに内包されている属性証明書Ａａを、ＩＣカード２０ａの書き換え可能な領域に記憶する。
【００２９】
［２．２．電子バリュー譲渡時］
次に、携帯端末１０ａを用いて、インターネットショップサーバ６０より電子チケット等の電子バリューを購入したユーザＡが、携帯端末１０ｂを所有するユーザＢに対して、電子バリューをオフラインで譲渡するときの動作について、図８を参照しながら説明する。
【００３０】
前提として、ユーザＢの所有する携帯端末１０ｂには、携帯端末１０ａと同様に、ＩＣカード２０ｂが装着され、１日毎に属性証明書Ａｂを受信している。
また、携帯端末１０ａに装着されたＩＣカード２０ａには、“０３／０３／０２”を有効期限とする属性証明書Ａａ（図７参照）と、図６に示すデータ内容の公開鍵証明書Ｃａとが記憶されているものとする。また、ユーザＡがインターネットショップサーバ６０より購入した電子バリューは、ＩＣカード２０ａの書き換え可能な領域に記憶されているものとする。
また、ＩＣカード２０ｂ内には、図９に示すデータ内容の公開鍵証明書Ｃｂと属性証明書Ａｂが記憶されているものとする。
【００３１】
まず、ユーザＡは、携帯端末１０ａの操作部を操作して、携帯端末１０ｂに対してオフラインで電子バリューを送信するための指示を行う。
これにより、携帯端末１０ａのＣＰＵは、ＩＣ用アンテナより電波を送出する。
携帯端末１０ｂのＣＰＵは、電波を受信して、携帯端末１０ａにＩＣカード２０ｂのＩＤを内包したレスポンスを返す。これにより、携帯端末１０ａに装着されたＩＣカード２０ａと携帯端末１０ａに装着されたＩＣカード２０ｂとの間の通信が確立する。
次に、携帯端末１０ａのＣＰＵは、公開鍵暗号方式に基づく相互認証を行う。具体的には、まず、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより、公開鍵証明書Ｃａと属性証明書Ａａを読み出す。そして、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃａと属性証明書Ａａとを内包した、メッセージＤ１をＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３２】
携帯端末１０ｂのＣＰＵは、メッセージＤ１を受信し、ステップＳ１０１の処理を行う。
具体的には、まず、携帯端末１０ｂのＣＰＵは、メッセージＤ１に内包されている公開鍵証明書Ｃａの検証を行う。すなわち、携帯端末１０ｂのＣＰＵは、公開鍵証明書Ｃａに記述されているＣＡ署名と公開鍵ＰＫａとを用いて、一般的な公開鍵暗号方式により、公開鍵証明書Ｃａの正当性を検証する。さらに、携帯端末１０ｂのＣＰＵは、現在日付“２００３／０３／０１”が、公開鍵証明書Ｃａの有効期限“２００３／１２／３１”を過ぎていないことを検証する。
次に、携帯端末１０ｂのＣＰＵは、メッセージＤ１に内包されている属性証明書Ａａの検証を行う。具体的には、携帯端末１０ｂのＣＰＵは、属性証明書Ａａに記述されている有効期限“０３／０３／０２”と属性“１日限り正当性を保証”とから、属性証明書Ａａが１日だけ有効であることを証明するものであり、現在日時“２００３／０３／０１”が有効期限“０３／０３／０２”を過ぎていないことを確認する。
【００３３】
次に、携帯端末１０ｂのＣＰＵは、一般的な方法により、乱数Ｒｂを生成する。そして、携帯端末１０ｂのＣＰＵは、受信した公開鍵証明書Ｃａに記述されている公開鍵ＰＫａを用いて、生成した乱数Ｒｂを、例えば、Ｓｈａｒｅｄ Ｓｅｃｒｅｔにより暗号化することにより、暗号化データＥｂを生成する。
次に、携帯端末１０ｂのＣＰＵは、ＩＣカード２０ｂより、公開鍵証明書Ｃｂと属性証明書Ａｂとを読み出す。そして、携帯端末１０ｂのＣＰＵは、読み出した公開鍵証明書Ｃｂと属性証明書Ａｂと、生成した暗号化データＥｂとを内包したメッセージＤ２を、ＩＣ用アンテナより携帯端末１０ａ宛に送信する。
【００３４】
携帯端末１０ａのＣＰＵは、メッセージＤ２を受信し、ステップＳ１０２の処理を行う。
具体的には、ステップＳ１０１における処理と同様に、携帯端末１０ａのＣＰＵは、まず、メッセージＤ２に内包されている公開鍵証明書Ｃｂを検証する。すなわち、携帯端末１０ａのＣＰＵは、公開鍵証明書Ｃｂに記述されているＣＡ署名と公開鍵ＫＢｂとを用いて、一般的な公開鍵暗号方式で、公開鍵証明書Ｃｂの正当性を検証する。また、携帯端末１０ａのＣＰＵは、現在日付“２００３／０３／０１”が、公開鍵証明書Ｃｂに記述されている有効期限“２００４／０１／０７”を過ぎていないことを検証する。
次に、携帯端末１０ａのＣＰＵは、属性証明書Ａｂを検証する。具体的には、携帯端末１０ａのＣＰＵは、属性証明書Ａｂに記述されている有効期限“０３／０３／０２”と属性“１日限り正当性を保証”とから、属性証明書Ａａが１日だけ有効であることを証明するものであり、現在日時“２００３／０３／０１”が有効期限“０３／０３／０２”を経過していないことを確認する。
【００３５】
次に、携帯端末１０ａのＣＰＵは、一般的な方法により、乱数Ｒａを生成する。そして、携帯端末１０ｂのＣＰＵは、受信した公開鍵証明書Ｃａに記述されている公開鍵ＰＫａを用いて、生成した乱数Ｒａを、例えば、Ｓｈａｒｅｄ Ｓｅｃｒｅｔにより暗号化することにより、暗号化データＥａを生成する。
次に、携帯端末１０ａのＣＰＵは、ＩＣカード２０ａより公開鍵証明書Ｃａと属性証明書Ａａとを読み出す。そして、携帯端末１０ａのＣＰＵは、読み出した公開鍵証明書Ｃａと属性証明書Ａａと、生成した暗号化データＥａとを内包したメッセージＤ３をＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３６】
携帯端末１０ｂのＣＰＵは、メッセージＤ３を受信し、ステップＳ１０３の処理を行う。
具体的には、携帯端末１０ｂのＣＰＵは、まず、一般的な方法で、乱数Ｒａと乱数Ｒｂとから、特定の関数を用いて、共通鍵Ｋａｂを生成する。
次に、携帯端末１０ｂのＣＰＵは、メッセージＤ１、Ｄ２、Ｄ３に対するメッセージ認証コード（メッセージ認証コード；Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）ＭＡＣｂを、共通鍵Ｋａｂを用いて生成する。
そして、携帯端末１０ｂのＣＰＵは、生成したメッセージ認証コードＭＡＣｂを内包したメッセージＤ４を、ＩＣ用アンテナより携帯端末１０ａ宛に送信する。
【００３７】
携帯端末１０ａのＣＰＵは、メッセージＤ４を受信し、ステップＳ１０４の処理を行う。
具体的には、まず、携帯端末１０ａのＣＰＵは、一般的な方法で、乱数Ｒａと乱数Ｒｂとから、特定の関数を用いて、共通鍵Ｋａｂを生成する。
そして、携帯端末１０ａのＣＰＵは、受信したメッセージＤ４に内包されるメッセージ認証コードＭＡＣｂを、一般的なＭＡＣの認証方法で検証する。
次に、携帯端末１０ａのＣＰＵは、メッセージＤ１、Ｄ２、Ｄ３、Ｄ４に対するメッセージ認証コード（メッセージ認証コード；Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）ＭＡＣａを、共通鍵Ｋａｂを用いて生成する。
携帯端末１０ａのＣＰＵは、生成したメッセージ認証コードＭＡＣａを内包したメッセージＤ５を、ＩＣ用アンテナより携帯端末１０ｂ宛に送信する。
【００３８】
携帯端末１０ｂのＣＰＵは、メッセージＤ５を受信し、メッセージＤ５に内包されているメッセージ認証コードＭＡＣａを、一般的なＭＡＣの認証方法で検証する（ステップＳ１０５）。
以上の検証結果や認証結果が全て正当であった場合に、携帯端末１０ａと携帯端末１０ａのＣＰＵは、相互認証が成功したと判定する。
なお、上述した検証結果や認証結果に正当でないものが存在した場合には、正当でないと判定された時点で、ＣＰＵはエラーメッセージを送信して処理を終了する。
【００３９】
認証が成功したと判定された場合には、携帯端末１０ａと、携帯端末１０ｂとは、共通鍵Ｋａｂ用いた共通暗号方式による通信を行う（ステップＳ１０６）。
ここでは、携帯端末１０ａは、ＩＣカード２０ａに記憶されている電子バリューを読み出し、共通鍵Ｋａｂで暗号化して、携帯端末１０ｂに送信する。
携帯端末１０ｂは、暗号化された電子バリューを受信し、共通鍵Ｋａｂで復号して、ＩＣカード２０ｂの書き換え可能な領域に記憶する。
【００４０】
以上のように、本発明によれば、公開鍵証明書の有効期限を変更せずに、オフラインで有効期限の検証を行うことが可能となる。
また、鍵ペアや公開鍵証明書をＩＣカード２０内の書き換え不可な領域に記憶させたことにより、安全性を高めることができる。
また、オフラインで有効期限の検証を行うことができるようにしたため、携帯端末１０は、インターネットに接続することなく、相手の携帯端末１０に装着されているＩＣカード２０の有効性の検証を容易に行うことが可能となる。
また、データ量の大きいＣＲＬを使用する必要がないために、携帯端末１０やＩＣカード２０のような記憶容量が少ない装置であっても、有効期限の検証を容易に行うことができる。
【００４１】
［３．変形例］
以上、本発明の実施形態について説明したが、この実施形態はあくまでも例示であり、本発明の趣旨から逸脱しない範囲で様々な変形が可能である。変形例としては、例えば以下のようなものが考えられる。
【００４２】
（１）上記実施形態においては、オフライン時における携帯端末１０間のピアツーピアの通信を、非接触ＩＣカードの技術を利用した通信として説明したが、これに限定されず、例えば、ピアツーピアの通信は、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）や、ブルートゥース（登録商標）等の近距離無線通信手段や、通信ケーブルを介した有線通信手段を用いたり、また、インターネットを利用せずに移動網のみを介した通信でもよい。
（２）上記実施形態における属性証明書発行時には、ＡＡサーバ装置３０は、携帯端末１０ａより、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストを受信したときに、属性証明書Ａａを発行する処理を行ったが、これに限定されず、１日に１回定期的に属性証明書Ａａを生成し、記憶部に記憶しておいてもよい。
【００４３】
（３）上記実施形態においては、［２．２．電子バリュー譲渡時］において、オフラインを前提として、公開鍵証明書の有効性を検証したが、これに限定されず、オンラインでＣＡサーバ装置４０にアクセスできなかった場合にのみ、オフラインで公開鍵証明書の有効性を検証するようにしてもよい。
（４）上記実施形態においては、属性証明書用プログラムは、１日に１回という周期で起動されることとしたが、起動される周期はこれに限定されず、例えば、２日に１回起動されてもよい。
【００４４】
（５）上記実施形態においては、ＩＣカード２０の製造時に、ＩＣカード２０の書き換え不可な領域に公開鍵証明書や鍵ペアが予め記憶されているとして説明したが、公開鍵証明書や鍵ペアを記憶するのは製造時に限定されない。例えば、製造後に、販売店にてＩＣカード２０に公開鍵証明書や鍵ペアが書き込まれて、書き込まれた領域が書き換え不可な領域に設定されてもよい。また、携帯端末１０にＩＣカード２０が装着された後に、ＩＣカード２０に公開鍵証明書や鍵ペアが書き込まれ、書き込まれた領域が書き換え不可に設定されてもよい。
（６）上記実施形態においては、図８に示されるシーケンスによる相互認証を行ったが、相互認証の方法はこれに限定されない。例えば、パスワードを用いた相互認証でもよい。
（７）上記実施形態においては、ステップＳ１０１とステップＳ１０２において、有効期限を検証する際に、公開鍵証明書と属性証明書との有効期限が現在日付を過ぎていないことを検証したが、属性証明書の有効期限のみを検証してもよい。
（８）上記実施形態においては、ＡＡサーバ装置３０が、属性証明書Ａａの発行を要求するためのＨＴＴＰリクエストを受信したときに、ＣＲＬを用いて公開鍵証明書Ｃａが失効しているか否かを確認したが、これに限定されず、ＯＣＳＰレスポンダに問い合わせることによって、公開鍵証明書Ｃａが失効しているか否かを確認してもよい。
【００４５】
（９）上記実施形態においては、属性証明書用プログラムをタイマー起動するようにしたが、ユーザＡが、１日に１回、携帯端末１０ａを操作して、手動で属性証明書用プログラムを起動するようにしてもよい。
また、属性証明書用プログラムを自動起動したときに、携帯端末１０ａが、電波が届かない位置に位置していたために、属性証明書Ａａを要求するためのデータをＡＡサーバ装置３０に送信できなかった場合には、携帯端末１０ａの表示部に、ユーザＡが手動で属性証明書用プログラムを起動することを促すためのメッセージを表示するようにしてもよい。
（１０）上記実施形態においては、ＣＡサーバ装置４０とＡＡサーバ装置３０とを使用したが、ＣＡサーバ装置４０とＡＡサーバ装置３０の機能を備えた１つのサーバ装置を使用することも可能である。
【００４６】
【発明の効果】
以上説明したように、本発明によれば、大量のリソースを必要とせず、公開鍵証明書の有効性の検証をオフラインで実現することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係る通信システムの構成を示すブロック図である。
【図２】同実施形態に係る携帯端末のハードウェア構成を示すブロック図である。
【図３】同実施形態に係る公開鍵証明書のデータ構成を示す図である。
【図４】同実施形態に係る属性証明書のデータ構成を示す図である。
【図５】同実施形態に係る属性証明書発行時の処理を示す図である。
【図６】同実施形態に係る属性証明書発行時のＩＣカード２０ａに記憶されている公開鍵証明書Ｃａのデータ構成を示す図である。
【図７】同実施形態に係る属性証明書発行時のＩＣカード２０ａに記憶される属性証明書Ａａのデータ構成を示す図である。
【図８】同実施形態に係る電子バリュー譲渡時のシーケンスを示す図である。
【図９】同実施形態に係る電子バリュー譲渡時のＩＣカード２０ｂに記憶されている公開鍵証明書Ｃｂと属性証明書Ａｂとのデータ構成を示す図である。
【符号の説明】
１０、１０ａ、１０ｂ……携帯端末、２０、２０ａ、２０ｂ……ＩＣカード、３０……ＡＡサーバ装置、４０……ＣＡサーバ装置、５０……通信ネットワーク、６０……インターネットショップサーバ。
Claims (4)
- 秘密鍵を記憶した、記憶内容の書き換えが許容されていない第１の記憶手段と、
公開鍵の正当性を証明する公開鍵証明書を記憶した第２の記憶手段と、
第３の記憶手段と、
前記公開鍵証明書に対応する属性証明書を予め定められたサーバ装置から取得し前記第３の記憶手段に書き込む更新手段と、
前記公開鍵証明書および前記属性証明書を通信相手へ送信する送信手段と
を有する第１の電子機器と、
前記第１の電子機器から送信された前記公開鍵証明書および前記属性証明書を受信する受信手段と、
前記受信手段により受信された前記属性証明書に記録されている有効期限を用いて、前記受信手段により受信された前記公開鍵証明書の有効性を検証する検証手段と
を有する第２の電子機器と
を有する公開鍵証明書検証システム。 - 前記サーバ装置は、
記憶手段と、
前記記憶手段に記憶されている属性証明書を周期的に更新する更新手段と
を有することを特徴とする請求項１に記載の公開鍵証明書検証システム。 - 前記第２の電子機器は、
前記検証手段を制御し、通信不能の場合にのみ前記検証手段による検証を許可する制御手段を有する
ことを特徴とする請求項１に記載の公開鍵証明書検証システム。 - 前記第１の電子機器は、周期的に前記サーバ装置より前記属性証明書を取得し、前記更新手段により前記第３の記憶手段に前記属性証明書を書き込む周期更新手段を有する
ことを特徴とする請求項１に記載の公開鍵証明書検証システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091206A JP2004304227A (ja) | 2003-03-28 | 2003-03-28 | 公開鍵証明書検証システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091206A JP2004304227A (ja) | 2003-03-28 | 2003-03-28 | 公開鍵証明書検証システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004304227A true JP2004304227A (ja) | 2004-10-28 |
Family
ID=33404629
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003091206A Pending JP2004304227A (ja) | 2003-03-28 | 2003-03-28 | 公開鍵証明書検証システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004304227A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006154125A (ja) * | 2004-11-26 | 2006-06-15 | Ntt Docomo Inc | ローカル認証システム、ローカル認証装置、ローカル認証方法 |
| JP2008544593A (ja) * | 2005-03-31 | 2008-12-04 | クゥアルコム・インコーポレイテッド | 多重署名−強力な多者ディジタル署名のためのプロトコル |
| US8321680B2 (en) | 2005-03-31 | 2012-11-27 | Qualcomm Incorporated | Multisigning—a protocol for robust multiple party digital signatures |
| JP2013513256A (ja) * | 2009-10-07 | 2013-04-18 | テルコーディア テクノロジーズ インコーポレイテッド | 限られた数のインフラ・サーバを有する自動車ネットワーク向け公開鍵インフラに関する方法 |
| JP2014155043A (ja) * | 2013-02-08 | 2014-08-25 | Toppan Printing Co Ltd | Ｉｃカード |
-
2003
- 2003-03-28 JP JP2003091206A patent/JP2004304227A/ja active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006154125A (ja) * | 2004-11-26 | 2006-06-15 | Ntt Docomo Inc | ローカル認証システム、ローカル認証装置、ローカル認証方法 |
| JP2008544593A (ja) * | 2005-03-31 | 2008-12-04 | クゥアルコム・インコーポレイテッド | 多重署名−強力な多者ディジタル署名のためのプロトコル |
| JP2011188521A (ja) * | 2005-03-31 | 2011-09-22 | Qualcomm Inc | 多重署名−強力な多者ディジタル署名のためのプロトコル |
| JP4938760B2 (ja) * | 2005-03-31 | 2012-05-23 | クゥアルコム・インコーポレイテッド | 多重署名−強力な多者ディジタル署名のためのプロトコル |
| US8321680B2 (en) | 2005-03-31 | 2012-11-27 | Qualcomm Incorporated | Multisigning—a protocol for robust multiple party digital signatures |
| JP2013513256A (ja) * | 2009-10-07 | 2013-04-18 | テルコーディア テクノロジーズ インコーポレイテッド | 限られた数のインフラ・サーバを有する自動車ネットワーク向け公開鍵インフラに関する方法 |
| JP2014155043A (ja) * | 2013-02-08 | 2014-08-25 | Toppan Printing Co Ltd | Ｉｃカード |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4589758B2 (ja) | データ通信システム，代行システムサーバ，コンピュータプログラム，およびデータ通信方法 | |
| JP4750695B2 (ja) | コンテンツ提供システム、情報処理装置及びメモリカード | |
| JP4372446B2 (ja) | 文書およびサービスへの安全なアドホックアクセス | |
| JP4800377B2 (ja) | 認証システム、ｃｅ機器、携帯端末、鍵証明発行局および鍵証明取得方法 | |
| JP4690389B2 (ja) | 認証書廃棄目録を利用したデジタル著作権管理方法及び装置 | |
| KR100682263B1 (ko) | 모바일을 이용한 원격 권한인증 시스템 및 방법 | |
| WO2002087149A1 (fr) | Systeme de communication de terminaux | |
| JP2004046430A5 (ja) | ||
| JP2004046430A (ja) | リモートアクセスシステム、リモートアクセス方法、リモートアクセスプログラム及びリモートアクセスプログラムが記録された記録媒体 | |
| WO2003105400A1 (ja) | データ処理システム、データ処理装置、および方法、並びにコンピュータ・プログラム | |
| JP2001313636A (ja) | 認証システム、認証方法、認証装置及びその方法 | |
| CN106209373B (zh) | 密钥生成系统、数据签章与加密系统及方法 | |
| KR101007375B1 (ko) | 스마트 카드 인증서 관리 장치 및 방법 | |
| JP6464511B2 (ja) | 認証システムおよび認証方法 | |
| JP5264548B2 (ja) | 認証システムおよび認証方法 | |
| JP2001251297A (ja) | 情報処理装置、該情報処理装置を具備する暗号通信システム及び暗号通信方法 | |
| KR100559958B1 (ko) | 이동통신 단말기간의 인증도구 중계 서비스 시스템 및 방법 | |
| JP2010251974A (ja) | データ転送方法、データ転送システム及びデータ中継プログラム | |
| JP2004304227A (ja) | 公開鍵証明書検証システム | |
| JP2021073564A (ja) | 通信装置、通信方法、およびコンピュータプログラム | |
| JP2004302835A (ja) | デジタルコンテンツ管理システム、利用者端末装置、ライツマネジメント方法 | |
| KR100501172B1 (ko) | 무선 인터넷을 위한 무선 인증서 상태 관리 시스템 및방법과 이를 이용한 무선 인증서 상태 검증 방법 | |
| JP2004064181A (ja) | ホームゲートウェイ装置およびプログラム | |
| JP4504130B2 (ja) | 通信装置、通信システム、証明書送信方法及びプログラム | |
| WO2004088557A1 (ja) | 情報処理システム、情報処理装置および方法、並びにプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050407 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060524 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060530 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060905 |