JP4105552B2 - 小型デバイスにおける暗号署名を使用した否認防止方法 - Google Patents

Description

本発明は、否認防止、アクセス制御、ユーザ照合等を達成するために特に暗号署名が使用される際のネットワークコンピュータデバイスに関するものである。

電子商取引（イー−コマース）又は移動商取引（エム−コマース）等の多種の用途では、ある人が取引を行う権限を有しているという永久的な裏付けを提供する能力を必要とする。また、譲渡証、事業報告書及びその他様々な書式といった、電子資料の署名が近い将来に習慣的になると期待されている。

イー−コマース及びエム−コマースは急速に事業領域を拡大しており、公務及び私務共に電子署名を可能にするために調整が行われているようである。しかし、電子署名の進歩は安全性、改ざん防止並びに単純な手続及び解決法に依存している。署名者は、本人の署名が受信機関で受信したものと同一であると確認する必要がある。受信者は、署名者が本人が申告するとおりの者であると確認する必要がある。さらに、該署名は、ユーザの技術知識を必要としない単純なものであり、時間及び場所と無関係に実施できることが好ましい。

暗号署名は多くの分野で使用されている。これは、典型的には、暗号署名を行うデバイスの所有者であるユーザに加えて、署名を使用するシステム及び署名を受信するシステムを伴う。署名を使用するシステムは、提供されたデータに暗号署名を行うようユーザに求める。ユーザは署名をして、署名を使用するシステムに該署名を返戻する。該署名を使用するシステムは、署名されたデータ及び該署名を、署名を受信するシステムに渡す。該署名を受信するシステムは、署名を使用するシステムが署名のためにユーザに提示したものと、ユーザが署名したものとの間に暗号による結束関係を有する。

ＰＫＩ（公開鍵基盤）は、当業者には周知で広く使用される暗号署名及び認証システムである。ＰＫＩシステムで信頼される部分は、電子鍵の組を発行する。該組は１つの秘密鍵と１つの公開鍵からなる。秘密鍵はユーザ（又はユーザの署名を行うデバイス）にしか認知されていないが、公開鍵は署名されたデータをユーザから受信する者すべてに公開されてよい。ユーザデバイスでは、署名される対象及び秘密鍵は、署名された状態で対象を出力する何らかのアルゴリズムへの入力である。受信側では、署名された対象及び公開鍵が、署名された対象から元の対象を摘出する他の何らかのアルゴリズムへの入力である。該対象は、公開鍵がそれに署名した場合のみ、正しく摘出される。よって、受信側は、ユーザの公開鍵を利用してその摘出を行う際に、特定のユーザが対象に署名したことを確認することができる。

多くの電子デバイスは既に暗号署名をサポートしている。その一例は、インターネットブラウザがインストールされたＰＣである。ブラウザは、１以上の信頼される機関又はいわゆる認証局（ＣＡ）から発行された秘密鍵を含む１以上の証明書を有することができる。

これに関する問題の１つは、ＰＣは通常、一箇所に固定配置されること、及び／又は、持ち運びには大きすぎることである。しかし、署名を行う機材に要求されることは、ＰＣの固定場所又は持ち運び場所に制限されないことである。

さらに、常時又は長時間オンライン中のＰＣはデータスニッフィングに非常に無防備であり、侵入者に秘密鍵を入手されるリスクを負う可能性がある。セキュリティ上の理由で、ユーザは、ＰＣ上に提供された材料に署名するため、ユーザ個人の署名を行うデバイスを利用することを希望する場合がある。

上記問題の解決法は、携帯電話といった小型携帯用デバイスであってもよい。ＷＡＰフォーラムによる「ＷＭＬスクリプト言語規格」は、ＷＡＰ電話による暗号署名を実行可能にする機能の実施形態を開示している。ＷＡＰ電話は、デバイスにＰＩＮコード等を入力して暗号署名することによりテキストの文字列に署名するようユーザにリクエストする。

しかし、このような携帯電話等のデバイスは、メモリ及び処理能力が制限されることを特徴とし、暗号署名機能を使用するにはインターフェースが規定及び限定される。

さらに、携帯電話のような小型デバイスは、通常はグラフィックモニタ又はパワーポイントやワードのような比較的大きなインストールプログラムを具備していない。

その結果、署名されるデータが大きすぎてユーザに提供できない、又はユーザに認識不可能な形式である、或いは署名を行うデバイスとの互換性を有していない場合に問題が生じる。しかし、上記ＷＡＰ規格は、ハードウェア及び表示が制限されたデバイス上で提供できる程度に、認識可能で小容量であることを前提としている。

発明の要旨
本発明の主な目的は上記のような問題を解決し、ユーザ、署名を使用するシステム及び署名を受信するシステム間に否認防止を提供することである。これは、請求項１に記載の方法により達成される。

より具体的には、本発明は、署名を行うデバイスを使用してデータにディジタル署名する方法であって、署名を使用するシステムにおいてデータの一部を摘出することと、該データの一部を署名を行うデバイスが使用する適切なプロトコルに変換することと、データのハッシュコードと共に該データの一部を前記署名を行うデバイスに転送することとを含む方法を提供する。これにより、署名を行うデバイスのユーザには、署名を行うデバイスの制約に従って適応された、ユーザが認識可能なデータの変換された部分が提示される。次いで該ユーザは適切な署名アルゴリズムを使用した署名を行うデバイスを用いてデータに電子的に署名することができる。当該データの、認識可能で適応した部分だけがユーザに提示される場合も、正確なハッシュコードにより、ユーザが本当に対象データに署名することが実証される。その署名は署名を使用するシステムに返戻され、原データ、データの一部、ハッシュコード及び署名は、処理、確認、格納等を行う署名を受信するシステムに送信される。

本発明により、署名を行うデバイスには容量が大きすぎるデータに署名するのに、携帯電話等の小型ハードウェア及びプロセッサが制限された署名を行うデバイスを使用することができる。

本発明の好ましい実施形態
以下に本発明の好ましい実施形態を開示する。本実施形態は、説明を目的としてのみ議論され、請求項１で規定された本発明を限定するものではないことに注意されたい。

開示された実施形態は、ユーザと一組のデータとの間の暗号化による結束を達成する柔軟な方法を提供する。前記一組のデータは、原形のままでは人間が読み取り不可能であるか、或いは、容量が大きすぎて署名のためにユーザに提示できない。このことは、添付図を参照するプロトコル構文に部分的に説明されている。

図３は、署名を使用するシステムが小型の暗号デバイスに接続し、署名リクエストを伝達するプッシュ段階を図示している。プル段階では、小型の暗号デバイスは署名を使用するシステムに接続し、署名されるデータを請求する。

署名を使用するシステム及び署名を受信するシステムは、コンピュータネットワークにおける論理的なエンティティである。これらのシステムは、同じネットワーク構成要素内に存在してもよいし、或いは、署名を使用するシステムがユーザＰＣである場合、上記の例示のように互いに独立していてもよい。

署名を使用するシステムは、ユーザに提示及び理解されるように獲得された（１）メッセージを変換する（２）。該署名を使用するシステムは、獲得された署名されるべきデータ全体を所有する任意のデータシステム、ノード又はコンピュータであってよい。例えば、該署名を使用するシステムは、署名を必要とするドキュメントを受信したユーザＰＣであってもよい。

続いて、変換されたデータは、ＷＡＰ電話等のユーザの暗号が使用可能な小型デバイスに転送される（３）。ユーザは、適切な署名アルゴリズムを用いてこのメッセージに署名する。ユーザは、特定の署名ＰＩＮコードを入力することにより、署名を行うことができる。

その署名は、署名を使用するシステムに返戻されて（４）、少なくとも
１）OriginalData及びハッシュコードアルゴリズム識別子
２）ToBeSignedMessage及び署名アルゴリズム識別子並びに署名
を保存した署名を受信するシステムに送られる（５）メッセージに変換される（図２参照）。

OriginalDataは、署名される予定であった原データである。これは、ドキュメント、プロトコル構造、規約等とすることができる。本発明は、このデータとデバイスユーザとの間を暗号により結束させることができる。

ToBeSignedMessageは、署名するために提示されたメッセージである。署名されるデータ長に関し、当該メッセージはデバイスの制約に支配される。当該メッセージは以下の二つの部分を有する：
１）デバイスユーザが理解し、かつOriginalDataの一部である部分。OriginalDataから読み取り可能な情報を摘出する方法は、その特性に応じて規定することができる。
OriginalDataの特性が読み取り可能なデータを摘出することができないような場合、署名を使用するシステムは、ユーザに表示するための適切なテキストを作成する。署名を受信するシステムは、当該テキストを選択するために使用される規則を認知している必要がある。当該デバイスが、例えば、写真等を保存した大容量のドキュメントに署名するために使用される場合、この領域は、ドキュメントに関する動的情報を保存することができる。例として、Doc name=今年度予算、Doc no=1FR2、Doc rev=A2、Doc size=2345、Pic1 format=jpeg、Pic1 size=123、Table1 size=234などがある。デバイスが写真又は音楽ファイルに署名するために使用される場合、情報の例として、Title=Dance music vol1、Format=mp3、Size=2345、Length=1.16等を挙げることができる。
２）デバイスユーザが認識不能な部分。これは、OriginalDataのハッシュコードである。当該ハッシュコードが存在すると、原データと署名との間に現実的な結束が生じる。これにより、ユーザが自認するように、読み取り可能なテキストだけではなく原データに本当に署名することが保証される。ハッシュ化する前に原データが少しでも変更された場合は、該ハッシュコードは、予期したものとは完全に相違して現れるので、暗号が使用可能なユーザデバイスがデータの変更を認知するところとなり、続いてそれを拒絶する。

この解決法は、署名されるべき情報を含む認識可能なメッセージをデバイスユーザに提供する。また、異なる署名を受信するシステムに対し、署名を使用するシステムとデバイスユーザの両方を認証するのに適したデータを柔軟に提供する。

署名手続き及びデータ収集は、様々な種類のプロトコルを使用して実施することができる。図４は、署名手続き中にＷＡＰ１．２が使用可能な携帯型デバイスと通信するのにＷＭＬスクリプトを使用し、署名を使用するシステムと署名を受信するシステムとの間でＨＴＴＰを使用する、プッシュ署名リクエストを例示している。しかし、これらの目的のため、（ＬＤＡＰ［ＬＤＡＰ］、ＳＱＬ［ＳＱＬ］、Ｉモード対応デバイス及びスクリプト等の）他のスクリプト、プロトコル及び署名を行うデバイスを使用することもできる。

最後に、図５は、（図２のToBeSignedMessage及び図３の変換されたデータとして引用された）変換された認識可能なデータが、暗号が使用可能なデバイスの表示装置上でのユーザ向けの表示例を図示している。

本発明の主な長所は、小型でハードウェアが制限されたデバイスにおいてもユーザが何に自分が署名しているかを認識できることである。これにより、大容量のデータについても暗号が使用可能な携帯型デバイスを使用することができるので、署名者の移動の自由が増す。

更なる長所は、署名される小容量のデータのみがデバイス間で送信され、また該デバイスにより処理されるので、当該手続きがより高速で行われ、転送容量の少なさ及びプロセッサ能力の低さによる制限は受けない。

よって、大量の未構造化情報は、同意された構造の定義メッセージに分解及び検証され、続いてユーザ個人の署名を行うデバイスを用いて署名されることができる。

さらに、本発明は、デバイスがグラフィックモニタを装備しなくとも、例えば、グラフィカルコンテンツを伴うドキュメントに署名するため、小型デバイスを使用することを可能にする。

本発明のさらに別の長所は、一般的に外部ネットワークに接続される署名を使用するシステム（例えば、インターネットに接続されるＰＣ）からユーザの秘密鍵を分離させることができることである。その結果、侵入者が秘密署名鍵を入手するリスクは低減される。

本発明のさらに別の長所は、ＷＡＰ１．２が使用可能な携帯型デバイスといった、署名を行うカスタムデバイスにおける調整を必要としないことである。既に実装済みの署名アプリケーションを利用することができる。

本発明は、ＷＡＰ１．２ＳｉｇｎＴｅｘｔ（）の機能又はＳＩＭアプリケーションツールキット（ＳＡＴ）を使用して実施される暗号署名アプリケーションに適しており、これは、本明細書に記載された実施例で使用されている。しかし、小型の暗号デバイスを使用して人間がデータに署名し、それを認識する必要がある状況に適用可能な他の実施形態も特許請求の範囲に記載された本発明の範囲内であり、利用可能である。

図１は、小型デバイス上で読み取り不可能なテキストに署名する問題を図示している。 図２は、本発明による実施形態におけるデータフローを示すフローチャートである。 図３は、本発明による実施形態に伴う構成要素間のデータ転送方法を図示している。 図４は、署名を使用するシステムと署名を受信するシステムとの間でＨＴＴＰを使用するＷＡＰ１．２が使用可能な携帯型デバイスを使用したプッシュ署名リクエストのデータフローを例示している。 図５は、署名される元の対象物から摘出されたテキストの表示例である。

Claims (10)

1. 電子署名システムを利用した、小型携帯型の署名を行うデバイスを使用してデータに電子署名及び／又はディジタル署名する方法であって、
   ａ） 第１の署名を使用するデバイスにおいて前記データの一部分を摘出するステップと、
   ｃ）第１の署名を使用するデバイスにおいて前記データをハッシュ化して前記データをハッシュコードとするステップと、
   ｄ） 単一のリクエストにおいて、前記データの一部及び前記ハッシュコードを、前記小型携帯型の署名を行うデバイスに転送するステップと、
   ｅ） 前記電子署名システムに従って、小型携帯型の前記署名を行うデバイスにおいて前記リクエストに署名するステップと
   を有し、
   ステップａ）とステップｃ）との間に、
   ｂ） ユーザが読み取り可能な、前記小型携帯型の署名を行うデバイスに適応した形式に前記データの一部分を変換するステップを有することを特徴とする方法。
2. 小型携帯型の署名を行うデバイスから第１の署名を使用するデバイスに対して前記署名の結果としてその署名を返戻するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 第１の署名を使用するデバイスから第２の署名を使用するデバイスに対して前記データ、リクエスト及び署名を転送するステップをさらに含むことを特徴とする請求項２に記載の方法。
4. 小型携帯型の署名を行うデバイスは、特定のプロトコルを使用した暗号が使用可能な小型デバイスであり、第１の署名を使用するデバイスは、前記データの一部分を前記プロトコルに変換するように適応した署名を使用するシステムであることを特徴とする請求項１ないし３のいずれかに記載の方法。
5. 前記第２の署名を使用するデバイスは、少なくとも、署名データの処理、確認及び／又は格納を行う署名を受信するデバイスであることを特徴とする請求項３又は４に記載の方法。
6. 前記プロトコルは、ＷＡＰ（ワイヤレスアプリケーションプロトコル）であり、小型携帯型の署名を行うデバイスはＷＡＰが使用可能な携帯デバイスであることを特徴とする請求項４又は５に記載の方法。
7. 前記電子署名システムは、秘密鍵／公開鍵を使用していることを特徴とする請求項１ないし６のいずれかに記載の方法。
8. 前記データはドキュメントまたは、譲渡証、事業報告書もしくはその他様々な書式であることを特徴とする請求項１ないし７のいずれかに記載の方法。
9. 署名は、ＷＡＰ１．２ｓｉｇｎＴｅｘｔ（）機能を用いて実行されることを特徴とする請求項６ないし８のいずれかに記載の方法。
10. 署名は、ＳＩＭアプリケーションツールキット（ＳＡＴ）を使用して実装された暗号署名アプリケーションを用いて実行されることを特徴とする請求項６ないし９のいずれかに記載の方法。

Images