署名生成装置
署名生成装置は、データに署名するように構成された署名モジュールを備えている。署名生成装置は、更に、ルールに対してデータをチェックするように構成されたパーサモジュールを備えている。ルールは、署名生成装置に記憶される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、署名生成装置（ＳＣＤ）に係り、特に、例えば、企業バッジの形態のスマートカードに係る。より詳細には、本発明は、「Directive 1993 / 93 EC of the European Parliament」に規定された安全な署名生成装置（ＳＳＣＤ）に係る。ＳＳＣＤは、例えば、ＰＫＩ（パブリックキーインフラストラクチャー）スマートカードである。署名されるべきデータは、例えば、テキストドキュメント、アプリケーション、映像、ＭＰ３音楽、ＭＰＥＧ映画等である。
【背景技術】
【０００２】
一般に、署名生成装置、例えば、ＰＫＩスマートカードは、パーソナルコンピュータ（ＰＣ）に接続されるように構成されている。ユーザは、例えば、ＰＣに書き込まれた購入注文書への署名を希望することがある。ｅ−メールに署名するために、ユーザは、購入注文書をＰＫＩスマートカードに送信し、このスマートカードは、購入注文書に署名するように構成されている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、セキュリティの高い電子署名を計算することである。
【課題を解決するための手段】
【０００４】
本発明の１つの態様によれば、データに署名するように構成された署名モジュールを備えた署名生成装置は、この署名生成装置に記憶されているルールに対してデータをチェックするように構成されたパーサモジュール（parser module）を備えたことを特徴とする。
【０００５】
署名生成装置は、例えば、パーソナルコンピュータ（ＰＣ）に挿入されるように構成されたＰＫＩスマートカードである。署名されるべきデータは、例えば、購入注文書又は契約書のようなドキュメントである。このドキュメントは、ＰＣから送信されて、ＰＫＩスマートカードにおいて署名される。
【０００６】
実際の問題として、ＰＣは、その性質上、安全ではない。ウィルスが、署名されるべきデータを、それがＰＫＩスマートカードへ送信される前に、実際に遮ったり変更したりすることがある。その結果、ＰＣのスクリーンに見られるもの（又はより一般的には、サウンドカード等、ＰＣにインストールされる周辺機器を通して認知されるもの）は、必ずしも、ＰＫＩスマートカードに送信されたものではない。それ故、ＰＫＩスマートカードがいかに安全であっても、ユーザは、彼が署名すると考えているものに必ずしも署名するのではない。更に、以下の例に述べるように、署名されるべきデータは、時々、署名する前後で異なって表示されるような仕方でフォーマットされることがある。
【０００７】
例−詐欺的ドキュメントフォーマット
アタックの基本：
アリスとボブは、アリスがボブに＄１００支払うという契約書に署名することを希望する。アリスは、それをワードドキュメントとしてタイプアップし、そして両者がそれにデジタルで署名する。数日中に、ボブがアリスのところに集金にやって来る。彼が驚くことに、アリスは、彼が彼女に＄１００を支払う義務があることを述べたワード文書を彼に提示する。又、アリスは、その新たなドキュメントに対するボブからの有効な署名も有する。実際に、これは、ボブが署名したことを覚えている契約書のものと厳密に同じ署名であり、そしてボブがびっくりすることに、２つのワード文書は魔法のように実際に同一である。
アリスがしたことは、日付又はファイル名のような外部入力で分岐するＩＦフィールドの挿入である。従って、たとえ署名したコンテンツが同じままであっても、表示されるコンテンツは変化する。というのは、それらが、未署名の入力に一部分依存するからである。基本的な要点は、非常に少数のユーザしかそれらのワードドキュメントの実際のコンテンツを知らず、従って、読めないものに決して署名してはならないことは明らかである。当然、ボブは、その契約について法廷で争うことができる。
概念の証明：
ドキュメントの終りに次のフィールド構造を挿入すると、ファイル名が「ａ．ｄｏｃ」や、その他「Ｂｙｅ」である場合には、「Ｈｅｌｌｏ」が表示される。
{IF {FILENAME ＼*MERGEFORMAT {DATE} } = “a. doc” “Hello” “Bye” ＼* MERGEFORMAT}
【０００８】
本発明では、契約が、ＰＫＩスマートカード自体の中のルールに対してチェックされる。これらルールは、好都合にも、セキュリティポリシーを定義することができる。それ故、契約が変更になり、従って、セキュリティポリシーをもはや満足しない場合には、ＰＫＩスマートカードに通知される。従って、電子署名は、高いセキュリティで計算することができる。
【発明を実施するための最良の形態】
【０００９】
図１は、データに署名するように構成された署名モジュールと、署名生成装置に記憶されたパーシング（構文解析）ルールに対してデータをチェックするように構成されたパーサモジュールとを備えた署名生成装置を示す。署名されるべきデータは、例えば、ＡＳＣＩＩフォーマットでもよいし、又は他のフォーマットでもよい。署名生成装置は、例えば、中央処理ユニット（ＣＰＵ）が設けられた集積回路で構成されたスマートカードでよい。集積回路は、例えば、ＳＴ２２ファミリーのチップとすることができる。集積回路は、カスタマイズされたロジック（即ちＳＰＴＬＡ）及びコンフィギュレーションを含むのが好都合である。又、集積回路には、高い通信速度の特徴、即ち少なくとも３００ｋｂ／ｓ、特に、１Ｍｂ／ｓ以上の速度が与えられるのが好都合である。
【００１０】
パーサモジュールは、パーシングロジック及びパーシングルールを備えている。パーシングロジックは、署名されるべきデータの到来する流れを分析するように構成される。パーシングロジックは、例えば、ＬＥＸ（字句解析ジェネレータ）及びＹＡＣＣ（更に別のコンパイラー・コンパイラー）アナライザーを含む。好都合なことに、ＰＫＩスマートカードの場合には、最適化及び簡単化されたＬＥＸ及びＹＡＣＣアナライザーを使用して、性能を高めることができる。最適化及び簡単化されたＬＥＸ及びＹＡＣＣアナライザーは、好都合にも、ハードウェア手段により加速することができる。このために、ＬＥＸ及びＹＡＣＣアナライザーは、例えば、ハードウェアで実施された限定状態マシンの形態で実施することができる。
【００１１】
パーシングルールは、セキュリティポリシーを定義し、即ち署名されるべきデータを受け入れるか又はそれらを潜在的に非安全として分類するための基準を定義する。パーシングルールは、署名されるべきデータの到来する流れを分析するときにパーシングロジックがどのエレメントを探索しなければならないか決定するコンフィギュレーションデータを保持する。
【００１２】
パーシングルールは、署名されるべきデータにおいて探索されねばならないキーワードの記述を含む。パーシングルールは、更に、「グラマー（文法）」を含む。ＹＡＣＣの分野では、「グラマー」とは、探索されるキーワードの配列を指す。
受信ステップにおいて、署名されるべきデータは、パーサモジュールにより受け取られる。
【００１３】
分析ステップにおいて、パーサモジュールは、署名されるべきデータをパーシングルールに対して分析する。より詳細には、ＬＥＸアナライザーは、パーシングルールで定義されたキーワードが、署名されるべきデータ内に含まれるかどうか分析する。キーワードが見つかったときには、キーワードがＹＡＣＣアナライザーに送信される。次いで、ＹＡＣＣアナライザーは、一致するグラマーを見つけるように試みる。これは、スマートカードの中央処理ユニット（ＣＰＵ）からの関与を必ずしも必要としない。次いで、ＣＰＵは、グラマールールが満足されたときに通知される。この通知は、例えば、割り込みにより行うこともできるし、又は何らかの適当と思われる手段で行うこともできる。
【００１４】
署名されるべきデータが、パーシングルールで定義されたセキュリティポリシーに一致しない場合には、警報ステップにおいて、署名モジュールに警報が送信される。署名モジュールは、次いで、署名要求を拒絶するか又は他の適当なアクションをとるか判断することができる。警報は、ＯＫ／ＮＯＫ通知でよい。又、警報は、更に精巧なものでよく、例えば、禁止／非常に危険／アプリケーションＸにとって潜在的に危険／安全、でもよい。
【００１５】
上述した説明は、データに署名するように構成された署名モジュールを備えた署名生成装置に関するものである。この署名生成装置は、更に、データをルールに対してチェックするように構成されたパーサモジュールも備えている。ルールは、署名生成装置に記憶される。
【００１６】
前記説明は、本発明を例示するもので、これに限定するものではない。特許請求の範囲内に入る多数の変更が明らかであろう。この点について、以下に所見を述べる。
【００１７】
パーシングルールは、エンドユーザ特有のもので、時間と共に変化し得る。アタッカーが不法なルールをロードするのを防止するために、パーシングルールを確実なものにできるのが効果的である。パーシングルールを確実なものにするために、それらにデジタルで署名することができる。従って、後発行ローディング（post issuance loading）が考えられ、確実である。署名生成装置（ＳＣＤ）は、許可されたルール発行者によって署名されていないルール又は無効な署名をもつルールを拒絶するように構成できる。
【００１８】
ＳＣＤにロードされた全ルールのサブセットに対して特定の署名プライベートキーを関連付けることができる。呼び出されたキーに基づいて、パーサは、当該サブセットを使用する。
【００１９】
これは、専用キーが使用されるときに有用である（例えば、内部通信用のキー、外部の承認当局により承認された外部通信用のキー、１Ｍ＄以上の購入注文書に署名するためのキー、ｅ−メール署名用のキー、等）。各キーは、異なる信用レベルに関連付けることができる。承認当局は、登録簿の信頼性レベルに基づいて異なるクラスの承認を与える。面と向っての登録であるか、ユーザがドキュメントに手で署名しなければならないか、ＩＤを写真と共に提示すべきか、等々である。この粒状度は、セキュリティ及び性能上の利益の両方を運ぶことができる。依然、各キーは、多数のルールに潜在的にリンクされており、パーサは、しばしば、多数のパーシングオペレーションを「並列」に管理できねばならない。ほとんどのＳＣＤでは、署名されるべきデータは、ＳＣＤ内に記憶されず、オンザフライで処理されねばならない。同時に多数のルールで機能するために、ＹＡＣＣのようなツールを使用する。
【００２０】
又、パーシングルールは、ＳＣＤユーザ又はＳＣＤ発行者に代わってＳＣＤのアドミニストレータにより構成することもできる。アドミニストレータは、署名の拒絶又は警報をトリガーすべきルールを定義する。アドミニストレータは、ルールのセットをＳＣＤにロードする。次いで、彼は、各プライベートキーのサブセット（そのキーに対して考慮に入れる必要のあるルールのリスト）を初期化する。又、ＳＣＤは、デフォールトにより、全てのルールを全ての署名プライベートキーに適用するように構成することもできる。
【００２１】
新たなアタックが見つかるたびに、アドミニストレータは、付加的なルールセットをダウンロードすることができる。アタックが解消されそしてＳＣＤユーザのＰＣがパッチされると、アドミニストレータは、不必要なルールを任意にアンロードすることができる（例えば、性能上の理由で）。
【００２２】
例えば、消費者アプリケーションのケースでは、ＳＣＤ保持者自体によりルールを管理することができる。郵便局のように、基本的なセキュリティ（キオスクが物理的にいたずらされないことを保障する）をもつパブリックな場所で使用できるパブリックなキオスクを使用することができる。キオスクは、例えば、タッチスクリーン及びスマートカードリーダーが装備され、いたずら防止本体に埋め込まれ、且つ入力装置をもたない（キーボードや、マウスや、ＣＤ／フレキシブルディスク／ＤＶＤドライブ等がない）ハードウェア装置である。キオスクは、いかなるパブリックなネットワークにも接続されないのが好ましい。キオスクは、カードに対する視覚コンフィギュレーションツールとして働く。キオスクは、ユーザが、キオスクによりルールに変換される所定セットの制約間で選択を行えるようにする。例えば、「このようなオンライン商店での購入を許さない」、又は「この商店での購入を最大＄５００に制限する」、又は「このリストの商店でしか購入を許さない」、等々である。
【００２３】
署名されるべきデータは、標準的なひな型に従うドキュメントであるのが好都合である。例えば、ほとんどの国々では、所得税をオンラインで納めるためのフォーマットは、良好に明記される。従って、ＳＣＤのパーシングメカニズムは、以前の良く分からないフォーマット（即ち非常に簡単なルール）の場合より著しく効率的にドキュメント内の選択されたフィールドをチェックするように構成できる。
【００２４】
特にターゲットとなるファイルフォーマットは、非常に普遍的で、多数のドキュメントに使用でき、しかも、他の標準的で且つ普及したフォーマット（例えば、ＲＴＦ及びＨＴＭＬ）をカバーできることからＸＭＬフォーマットであり、そして任意の所有権のあるフォーマットも、それが役立つときには、含まれる。例えば、あるフォームが金額を含むときには、ルールを最初に個人的なものとし、あるフィールドについて、あるスレッシュホールド以上の金額を拒絶する（ＳＣＤの所有者に基づき）ようにすることができる。又、利益についての規定のリストを定義して、これらの利益に向けての資金移動しか行なえないようにすることもできる。
【００２５】
好都合なことに、図３に示すように、署名モジュールは、ハッシュモジュール及びパディングモジュールを備えている。従って、リモートコントロールされる偽造署名計算のおそれが減少される。従って、アタッカーは、署名されるべき全データをＰＣにアップロードしなければならず、これは、非常に複雑なオペレーションである。更に、アップロードは、より容易に検出することができる。従って、彼は、カードにおける膨大なドキュメントに署名しなければならず、これも検出し得るものであり、即ちスマートカードリーダーは、アップロードオペレーション中に明滅することになり、これは、ハッシュを送信しそしてそれに署名するだけの場合より相当に長いものとなる。
【００２６】
本発明を良く説明するために、以下に実施例を挙げる。
【００２７】
実施例１−企業バッジ
従業員は、彼等の経費報告書に電子的に記入し、彼等の企業バッジでそれに署名し、そして上司のバッジで承認してもらうことが求められる。本発明によれば、経費に署名することのできる部下のリストを定義するパーシングルールを生成することができる。従って、許可のない者が同僚の経費に署名することが防止される。ある分類の経費を禁止することもできる。各分類の経費として許された最大金額を定義することもできる。
【００２８】
更に、組織が電子的に購入注文を出し、そして従業員の企業バッジでそれにデジタルで署名することを希望してもよい。この場合には、署名の前に、購入注文の金額が許可された最大値を越えないかどうかチェックするためのパーシングルールを生成することができる。プロバイダーが、会社で受け容れられたプロバイダーの１人であるか等をチェックするための別のパーシングルールを生成することもできる。
【００２９】
他の形式のドキュメント、例えば、契約書についても、同じことが言える。一般に、会社では、ある形式の契約書に署名することが、ある者だけに許されている。従業員の企業バッジは、彼が許された者でない場合に会社に代わって契約書に署名するのを防止することができる。パーシングルールは、契約に関する会社のポリシーに依存するものであり、そして例えば、ドキュメントが企業の標準的なひな型に基づいて書き込まれたものかどうかチェックすることができる。
【００３０】
実施例２−資金移動フォーム
資金移動フォームのＨＴＭＬソースが図２に示されている。
<html>
<body>
<h1>
<center> Fund Transfers for Lukasz Wlodarczyk </center>
</h1>
<center>
<h3>
<form>
<table align = “center” border = “2”>
<tr>
<td> account to debit </td>
<td> <input align = “right”
maxlength = “18”
size = “18”
type = “text”
value = “24368 188234 00300”> </td>
</tr>
<tr>
<td> account to credit </td>
<td> <input align = “right”
maxlength = “18”
size = “18”
type = “text”
value = “28547 487162 00300”> </td>
</tr>
<tr>
<td> Amount </td>
<td> <input align = “right”
maxlength = “5”
size = “7”
type = “text”
value = “1400”> </td>
</tr>
<tr>
<td> Currency </td>
<td> <input align = “right”
type = “radio”
checked> US Dollars <br>
<input align = “right”
type = “radio”> Euros <br> </td>
</tr>
</table> <p>
<input align = “left”
type = “submit”
value = “Sign transaction”>
<input align = “left”
type = “submit”
value = “Cancel transaction”>
</form>
</h3>
</center>
</body>
</html>
【００３１】
上述したＨＴＭＬソースのフォーマットは、次のような幾つかのルールを厳守する。
− ＨＴＭＬタグは全て小文字である。
− パラグラフマークは、ＣＲ及びこれに続くＬＦより成る。
− ２つ（又はそれ以上）のパラグラフマークが連続することはない（１つしか許されない）。
− ブランクデリミッタは、単一スペースで構成されるか、又はパラグラフマーク及びそれに続く任意の数のスペース、最大１４に制限される、で構成される。タブは存在せず（それらはスペースに置き換えられる）、そしてパラグラフマークの直前にスペースは許されない。
− 最初の＜ＨＴＭＬ＞タグの前及び＜／ＨＴＭＬ＞タグの後にはブランクデリミッタがない。
− 最初と最後の名前は、大文字でなければならないが、最初の後は小文字でなければならない。
− その他。
【００３２】
次のパーシングルールを定義することができる。良く理解するために、それらは、自然言語で表現される。実際に、濃密で且つ最適な２進シンタックスが使用される。
【００３３】
ルール１−ドキュメントが正当な資金移動ドキュメントであることをチェックするためのルール。
キーワードの定義：
「delimiters」は、単一スペース、或いはパラグラフマーク及びそれに続く１４個までのスペースを意味する。
「formatting」は、＜h1＞又は＜/h1＞或いは＜center＞又は＜/center＞を意味する。
「card_holder_name」は、「Lukasz Wlodarczyk」を意味する。
「word」は、一連の１６個までの小文字又は大文字のキャラクタである。
「label」は、「delimiters」で分離された一連の５個までの「word」である。
「allowed labels」は、「account to debit」又は「account to credit」又は「Amount」又は「Currency」である。
「field」は、＜td＞の後に「label」そしてその後に＜/td＞が続くことを意味する。
【００３４】
グラマー：
ドキュメントが、＜html＞キーワードで始まり、その後に「delimiters」、その後に「body」キーワード、その後に「delimiters」、その後に「formatting」、その後に「Fund Transfer for」、そしてその後に「card_holder_name」が続くことをチェックする。
全ての「field」が「allowed labels」を含むことをチェックする。
ドキュメントが＜/body＞キーワードで終り、その後に「delimiters」、その後に「/html」キーワードが続くことをチェックする。
【００３５】
ルール２−資金移動がカード所有者に対して定義されたポリシーを満足することをチェックするルール。
キーワードの定義：
「Input field」は、「field」の後に＜td＞、その後に＜/td＞及び「value =」を除く何か、その後に「value =」、その後に＜/td＞及び「value =」を除く何か、その後に＜/td＞が続くものである。
「Allowed account」は、カード所有者が資金移動を受け容れる許された銀行口座番号のリストである（例えば、銀行内部の争いを容易に解決する等の理由で、全ての口座は、カード所有者の銀行と同じ銀行ＩＤから始まる）。
「max amount」は、カード所有者により望まれ且つ銀行により許可された最大金額である。
【００３６】
グラマー：
「Amount」フィールドに続く「Input field」は、「Max amount」より低い金額を含むことをチェックする。
「account to credit」フィールドに続く「Input field」は、「Allowed account」である口座番号を含むことをチェックする。
【００３７】
資金移動フォームがこれらのパーシングルールに従わない場合には、署名がＰＫＩスマートカードによりおそらく拒絶されることになる。
【００３８】
本発明は、署名されるべきデータの重要な部分を、非常に有害となる変更に対して良好に保護する。更に、署名されるべきデータを操作して、アタッカーの意図に基づいて異なる仕方で表示するといったある形式のアタックに対しても良好に保護する。
【図面の簡単な説明】
【００３９】
【図１】署名生成装置を示す図である。
【図２】資金移動フォームを示す図である。
【図３】ハッシュモジュール及びパディングモジュールを備えた署名モジュールを示す図である。
【技術分野】
【０００１】
本発明は、署名生成装置（ＳＣＤ）に係り、特に、例えば、企業バッジの形態のスマートカードに係る。より詳細には、本発明は、「Directive 1993 / 93 EC of the European Parliament」に規定された安全な署名生成装置（ＳＳＣＤ）に係る。ＳＳＣＤは、例えば、ＰＫＩ（パブリックキーインフラストラクチャー）スマートカードである。署名されるべきデータは、例えば、テキストドキュメント、アプリケーション、映像、ＭＰ３音楽、ＭＰＥＧ映画等である。
【背景技術】
【０００２】
一般に、署名生成装置、例えば、ＰＫＩスマートカードは、パーソナルコンピュータ（ＰＣ）に接続されるように構成されている。ユーザは、例えば、ＰＣに書き込まれた購入注文書への署名を希望することがある。ｅ−メールに署名するために、ユーザは、購入注文書をＰＫＩスマートカードに送信し、このスマートカードは、購入注文書に署名するように構成されている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、セキュリティの高い電子署名を計算することである。
【課題を解決するための手段】
【０００４】
本発明の１つの態様によれば、データに署名するように構成された署名モジュールを備えた署名生成装置は、この署名生成装置に記憶されているルールに対してデータをチェックするように構成されたパーサモジュール（parser module）を備えたことを特徴とする。
【０００５】
署名生成装置は、例えば、パーソナルコンピュータ（ＰＣ）に挿入されるように構成されたＰＫＩスマートカードである。署名されるべきデータは、例えば、購入注文書又は契約書のようなドキュメントである。このドキュメントは、ＰＣから送信されて、ＰＫＩスマートカードにおいて署名される。
【０００６】
実際の問題として、ＰＣは、その性質上、安全ではない。ウィルスが、署名されるべきデータを、それがＰＫＩスマートカードへ送信される前に、実際に遮ったり変更したりすることがある。その結果、ＰＣのスクリーンに見られるもの（又はより一般的には、サウンドカード等、ＰＣにインストールされる周辺機器を通して認知されるもの）は、必ずしも、ＰＫＩスマートカードに送信されたものではない。それ故、ＰＫＩスマートカードがいかに安全であっても、ユーザは、彼が署名すると考えているものに必ずしも署名するのではない。更に、以下の例に述べるように、署名されるべきデータは、時々、署名する前後で異なって表示されるような仕方でフォーマットされることがある。
【０００７】
例−詐欺的ドキュメントフォーマット
アタックの基本：
アリスとボブは、アリスがボブに＄１００支払うという契約書に署名することを希望する。アリスは、それをワードドキュメントとしてタイプアップし、そして両者がそれにデジタルで署名する。数日中に、ボブがアリスのところに集金にやって来る。彼が驚くことに、アリスは、彼が彼女に＄１００を支払う義務があることを述べたワード文書を彼に提示する。又、アリスは、その新たなドキュメントに対するボブからの有効な署名も有する。実際に、これは、ボブが署名したことを覚えている契約書のものと厳密に同じ署名であり、そしてボブがびっくりすることに、２つのワード文書は魔法のように実際に同一である。
アリスがしたことは、日付又はファイル名のような外部入力で分岐するＩＦフィールドの挿入である。従って、たとえ署名したコンテンツが同じままであっても、表示されるコンテンツは変化する。というのは、それらが、未署名の入力に一部分依存するからである。基本的な要点は、非常に少数のユーザしかそれらのワードドキュメントの実際のコンテンツを知らず、従って、読めないものに決して署名してはならないことは明らかである。当然、ボブは、その契約について法廷で争うことができる。
概念の証明：
ドキュメントの終りに次のフィールド構造を挿入すると、ファイル名が「ａ．ｄｏｃ」や、その他「Ｂｙｅ」である場合には、「Ｈｅｌｌｏ」が表示される。
{IF {FILENAME ＼*MERGEFORMAT {DATE} } = “a. doc” “Hello” “Bye” ＼* MERGEFORMAT}
【０００８】
本発明では、契約が、ＰＫＩスマートカード自体の中のルールに対してチェックされる。これらルールは、好都合にも、セキュリティポリシーを定義することができる。それ故、契約が変更になり、従って、セキュリティポリシーをもはや満足しない場合には、ＰＫＩスマートカードに通知される。従って、電子署名は、高いセキュリティで計算することができる。
【発明を実施するための最良の形態】
【０００９】
図１は、データに署名するように構成された署名モジュールと、署名生成装置に記憶されたパーシング（構文解析）ルールに対してデータをチェックするように構成されたパーサモジュールとを備えた署名生成装置を示す。署名されるべきデータは、例えば、ＡＳＣＩＩフォーマットでもよいし、又は他のフォーマットでもよい。署名生成装置は、例えば、中央処理ユニット（ＣＰＵ）が設けられた集積回路で構成されたスマートカードでよい。集積回路は、例えば、ＳＴ２２ファミリーのチップとすることができる。集積回路は、カスタマイズされたロジック（即ちＳＰＴＬＡ）及びコンフィギュレーションを含むのが好都合である。又、集積回路には、高い通信速度の特徴、即ち少なくとも３００ｋｂ／ｓ、特に、１Ｍｂ／ｓ以上の速度が与えられるのが好都合である。
【００１０】
パーサモジュールは、パーシングロジック及びパーシングルールを備えている。パーシングロジックは、署名されるべきデータの到来する流れを分析するように構成される。パーシングロジックは、例えば、ＬＥＸ（字句解析ジェネレータ）及びＹＡＣＣ（更に別のコンパイラー・コンパイラー）アナライザーを含む。好都合なことに、ＰＫＩスマートカードの場合には、最適化及び簡単化されたＬＥＸ及びＹＡＣＣアナライザーを使用して、性能を高めることができる。最適化及び簡単化されたＬＥＸ及びＹＡＣＣアナライザーは、好都合にも、ハードウェア手段により加速することができる。このために、ＬＥＸ及びＹＡＣＣアナライザーは、例えば、ハードウェアで実施された限定状態マシンの形態で実施することができる。
【００１１】
パーシングルールは、セキュリティポリシーを定義し、即ち署名されるべきデータを受け入れるか又はそれらを潜在的に非安全として分類するための基準を定義する。パーシングルールは、署名されるべきデータの到来する流れを分析するときにパーシングロジックがどのエレメントを探索しなければならないか決定するコンフィギュレーションデータを保持する。
【００１２】
パーシングルールは、署名されるべきデータにおいて探索されねばならないキーワードの記述を含む。パーシングルールは、更に、「グラマー（文法）」を含む。ＹＡＣＣの分野では、「グラマー」とは、探索されるキーワードの配列を指す。
受信ステップにおいて、署名されるべきデータは、パーサモジュールにより受け取られる。
【００１３】
分析ステップにおいて、パーサモジュールは、署名されるべきデータをパーシングルールに対して分析する。より詳細には、ＬＥＸアナライザーは、パーシングルールで定義されたキーワードが、署名されるべきデータ内に含まれるかどうか分析する。キーワードが見つかったときには、キーワードがＹＡＣＣアナライザーに送信される。次いで、ＹＡＣＣアナライザーは、一致するグラマーを見つけるように試みる。これは、スマートカードの中央処理ユニット（ＣＰＵ）からの関与を必ずしも必要としない。次いで、ＣＰＵは、グラマールールが満足されたときに通知される。この通知は、例えば、割り込みにより行うこともできるし、又は何らかの適当と思われる手段で行うこともできる。
【００１４】
署名されるべきデータが、パーシングルールで定義されたセキュリティポリシーに一致しない場合には、警報ステップにおいて、署名モジュールに警報が送信される。署名モジュールは、次いで、署名要求を拒絶するか又は他の適当なアクションをとるか判断することができる。警報は、ＯＫ／ＮＯＫ通知でよい。又、警報は、更に精巧なものでよく、例えば、禁止／非常に危険／アプリケーションＸにとって潜在的に危険／安全、でもよい。
【００１５】
上述した説明は、データに署名するように構成された署名モジュールを備えた署名生成装置に関するものである。この署名生成装置は、更に、データをルールに対してチェックするように構成されたパーサモジュールも備えている。ルールは、署名生成装置に記憶される。
【００１６】
前記説明は、本発明を例示するもので、これに限定するものではない。特許請求の範囲内に入る多数の変更が明らかであろう。この点について、以下に所見を述べる。
【００１７】
パーシングルールは、エンドユーザ特有のもので、時間と共に変化し得る。アタッカーが不法なルールをロードするのを防止するために、パーシングルールを確実なものにできるのが効果的である。パーシングルールを確実なものにするために、それらにデジタルで署名することができる。従って、後発行ローディング（post issuance loading）が考えられ、確実である。署名生成装置（ＳＣＤ）は、許可されたルール発行者によって署名されていないルール又は無効な署名をもつルールを拒絶するように構成できる。
【００１８】
ＳＣＤにロードされた全ルールのサブセットに対して特定の署名プライベートキーを関連付けることができる。呼び出されたキーに基づいて、パーサは、当該サブセットを使用する。
【００１９】
これは、専用キーが使用されるときに有用である（例えば、内部通信用のキー、外部の承認当局により承認された外部通信用のキー、１Ｍ＄以上の購入注文書に署名するためのキー、ｅ−メール署名用のキー、等）。各キーは、異なる信用レベルに関連付けることができる。承認当局は、登録簿の信頼性レベルに基づいて異なるクラスの承認を与える。面と向っての登録であるか、ユーザがドキュメントに手で署名しなければならないか、ＩＤを写真と共に提示すべきか、等々である。この粒状度は、セキュリティ及び性能上の利益の両方を運ぶことができる。依然、各キーは、多数のルールに潜在的にリンクされており、パーサは、しばしば、多数のパーシングオペレーションを「並列」に管理できねばならない。ほとんどのＳＣＤでは、署名されるべきデータは、ＳＣＤ内に記憶されず、オンザフライで処理されねばならない。同時に多数のルールで機能するために、ＹＡＣＣのようなツールを使用する。
【００２０】
又、パーシングルールは、ＳＣＤユーザ又はＳＣＤ発行者に代わってＳＣＤのアドミニストレータにより構成することもできる。アドミニストレータは、署名の拒絶又は警報をトリガーすべきルールを定義する。アドミニストレータは、ルールのセットをＳＣＤにロードする。次いで、彼は、各プライベートキーのサブセット（そのキーに対して考慮に入れる必要のあるルールのリスト）を初期化する。又、ＳＣＤは、デフォールトにより、全てのルールを全ての署名プライベートキーに適用するように構成することもできる。
【００２１】
新たなアタックが見つかるたびに、アドミニストレータは、付加的なルールセットをダウンロードすることができる。アタックが解消されそしてＳＣＤユーザのＰＣがパッチされると、アドミニストレータは、不必要なルールを任意にアンロードすることができる（例えば、性能上の理由で）。
【００２２】
例えば、消費者アプリケーションのケースでは、ＳＣＤ保持者自体によりルールを管理することができる。郵便局のように、基本的なセキュリティ（キオスクが物理的にいたずらされないことを保障する）をもつパブリックな場所で使用できるパブリックなキオスクを使用することができる。キオスクは、例えば、タッチスクリーン及びスマートカードリーダーが装備され、いたずら防止本体に埋め込まれ、且つ入力装置をもたない（キーボードや、マウスや、ＣＤ／フレキシブルディスク／ＤＶＤドライブ等がない）ハードウェア装置である。キオスクは、いかなるパブリックなネットワークにも接続されないのが好ましい。キオスクは、カードに対する視覚コンフィギュレーションツールとして働く。キオスクは、ユーザが、キオスクによりルールに変換される所定セットの制約間で選択を行えるようにする。例えば、「このようなオンライン商店での購入を許さない」、又は「この商店での購入を最大＄５００に制限する」、又は「このリストの商店でしか購入を許さない」、等々である。
【００２３】
署名されるべきデータは、標準的なひな型に従うドキュメントであるのが好都合である。例えば、ほとんどの国々では、所得税をオンラインで納めるためのフォーマットは、良好に明記される。従って、ＳＣＤのパーシングメカニズムは、以前の良く分からないフォーマット（即ち非常に簡単なルール）の場合より著しく効率的にドキュメント内の選択されたフィールドをチェックするように構成できる。
【００２４】
特にターゲットとなるファイルフォーマットは、非常に普遍的で、多数のドキュメントに使用でき、しかも、他の標準的で且つ普及したフォーマット（例えば、ＲＴＦ及びＨＴＭＬ）をカバーできることからＸＭＬフォーマットであり、そして任意の所有権のあるフォーマットも、それが役立つときには、含まれる。例えば、あるフォームが金額を含むときには、ルールを最初に個人的なものとし、あるフィールドについて、あるスレッシュホールド以上の金額を拒絶する（ＳＣＤの所有者に基づき）ようにすることができる。又、利益についての規定のリストを定義して、これらの利益に向けての資金移動しか行なえないようにすることもできる。
【００２５】
好都合なことに、図３に示すように、署名モジュールは、ハッシュモジュール及びパディングモジュールを備えている。従って、リモートコントロールされる偽造署名計算のおそれが減少される。従って、アタッカーは、署名されるべき全データをＰＣにアップロードしなければならず、これは、非常に複雑なオペレーションである。更に、アップロードは、より容易に検出することができる。従って、彼は、カードにおける膨大なドキュメントに署名しなければならず、これも検出し得るものであり、即ちスマートカードリーダーは、アップロードオペレーション中に明滅することになり、これは、ハッシュを送信しそしてそれに署名するだけの場合より相当に長いものとなる。
【００２６】
本発明を良く説明するために、以下に実施例を挙げる。
【００２７】
実施例１−企業バッジ
従業員は、彼等の経費報告書に電子的に記入し、彼等の企業バッジでそれに署名し、そして上司のバッジで承認してもらうことが求められる。本発明によれば、経費に署名することのできる部下のリストを定義するパーシングルールを生成することができる。従って、許可のない者が同僚の経費に署名することが防止される。ある分類の経費を禁止することもできる。各分類の経費として許された最大金額を定義することもできる。
【００２８】
更に、組織が電子的に購入注文を出し、そして従業員の企業バッジでそれにデジタルで署名することを希望してもよい。この場合には、署名の前に、購入注文の金額が許可された最大値を越えないかどうかチェックするためのパーシングルールを生成することができる。プロバイダーが、会社で受け容れられたプロバイダーの１人であるか等をチェックするための別のパーシングルールを生成することもできる。
【００２９】
他の形式のドキュメント、例えば、契約書についても、同じことが言える。一般に、会社では、ある形式の契約書に署名することが、ある者だけに許されている。従業員の企業バッジは、彼が許された者でない場合に会社に代わって契約書に署名するのを防止することができる。パーシングルールは、契約に関する会社のポリシーに依存するものであり、そして例えば、ドキュメントが企業の標準的なひな型に基づいて書き込まれたものかどうかチェックすることができる。
【００３０】
実施例２−資金移動フォーム
資金移動フォームのＨＴＭＬソースが図２に示されている。
<html>
<body>
<h1>
<center> Fund Transfers for Lukasz Wlodarczyk </center>
</h1>
<center>
<h3>
<form>
<table align = “center” border = “2”>
<tr>
<td> account to debit </td>
<td> <input align = “right”
maxlength = “18”
size = “18”
type = “text”
value = “24368 188234 00300”> </td>
</tr>
<tr>
<td> account to credit </td>
<td> <input align = “right”
maxlength = “18”
size = “18”
type = “text”
value = “28547 487162 00300”> </td>
</tr>
<tr>
<td> Amount </td>
<td> <input align = “right”
maxlength = “5”
size = “7”
type = “text”
value = “1400”> </td>
</tr>
<tr>
<td> Currency </td>
<td> <input align = “right”
type = “radio”
checked> US Dollars <br>
<input align = “right”
type = “radio”> Euros <br> </td>
</tr>
</table> <p>
<input align = “left”
type = “submit”
value = “Sign transaction”>
<input align = “left”
type = “submit”
value = “Cancel transaction”>
</form>
</h3>
</center>
</body>
</html>
【００３１】
上述したＨＴＭＬソースのフォーマットは、次のような幾つかのルールを厳守する。
− ＨＴＭＬタグは全て小文字である。
− パラグラフマークは、ＣＲ及びこれに続くＬＦより成る。
− ２つ（又はそれ以上）のパラグラフマークが連続することはない（１つしか許されない）。
− ブランクデリミッタは、単一スペースで構成されるか、又はパラグラフマーク及びそれに続く任意の数のスペース、最大１４に制限される、で構成される。タブは存在せず（それらはスペースに置き換えられる）、そしてパラグラフマークの直前にスペースは許されない。
− 最初の＜ＨＴＭＬ＞タグの前及び＜／ＨＴＭＬ＞タグの後にはブランクデリミッタがない。
− 最初と最後の名前は、大文字でなければならないが、最初の後は小文字でなければならない。
− その他。
【００３２】
次のパーシングルールを定義することができる。良く理解するために、それらは、自然言語で表現される。実際に、濃密で且つ最適な２進シンタックスが使用される。
【００３３】
ルール１−ドキュメントが正当な資金移動ドキュメントであることをチェックするためのルール。
キーワードの定義：
「delimiters」は、単一スペース、或いはパラグラフマーク及びそれに続く１４個までのスペースを意味する。
「formatting」は、＜h1＞又は＜/h1＞或いは＜center＞又は＜/center＞を意味する。
「card_holder_name」は、「Lukasz Wlodarczyk」を意味する。
「word」は、一連の１６個までの小文字又は大文字のキャラクタである。
「label」は、「delimiters」で分離された一連の５個までの「word」である。
「allowed labels」は、「account to debit」又は「account to credit」又は「Amount」又は「Currency」である。
「field」は、＜td＞の後に「label」そしてその後に＜/td＞が続くことを意味する。
【００３４】
グラマー：
ドキュメントが、＜html＞キーワードで始まり、その後に「delimiters」、その後に「body」キーワード、その後に「delimiters」、その後に「formatting」、その後に「Fund Transfer for」、そしてその後に「card_holder_name」が続くことをチェックする。
全ての「field」が「allowed labels」を含むことをチェックする。
ドキュメントが＜/body＞キーワードで終り、その後に「delimiters」、その後に「/html」キーワードが続くことをチェックする。
【００３５】
ルール２−資金移動がカード所有者に対して定義されたポリシーを満足することをチェックするルール。
キーワードの定義：
「Input field」は、「field」の後に＜td＞、その後に＜/td＞及び「value =」を除く何か、その後に「value =」、その後に＜/td＞及び「value =」を除く何か、その後に＜/td＞が続くものである。
「Allowed account」は、カード所有者が資金移動を受け容れる許された銀行口座番号のリストである（例えば、銀行内部の争いを容易に解決する等の理由で、全ての口座は、カード所有者の銀行と同じ銀行ＩＤから始まる）。
「max amount」は、カード所有者により望まれ且つ銀行により許可された最大金額である。
【００３６】
グラマー：
「Amount」フィールドに続く「Input field」は、「Max amount」より低い金額を含むことをチェックする。
「account to credit」フィールドに続く「Input field」は、「Allowed account」である口座番号を含むことをチェックする。
【００３７】
資金移動フォームがこれらのパーシングルールに従わない場合には、署名がＰＫＩスマートカードによりおそらく拒絶されることになる。
【００３８】
本発明は、署名されるべきデータの重要な部分を、非常に有害となる変更に対して良好に保護する。更に、署名されるべきデータを操作して、アタッカーの意図に基づいて異なる仕方で表示するといったある形式のアタックに対しても良好に保護する。
【図面の簡単な説明】
【００３９】
【図１】署名生成装置を示す図である。
【図２】資金移動フォームを示す図である。
【図３】ハッシュモジュール及びパディングモジュールを備えた署名モジュールを示す図である。
【特許請求の範囲】
【請求項１】
データに署名するように構成された署名モジュールを備えた署名生成装置において、この署名生成装置に記憶されているルールに対してデータをチェックするように構成されたパーサモジュールを備えたことを特徴とする署名生成装置。
【請求項２】
前記署名生成装置は、スマートカードである請求項１に記載の署名生成装置。
【請求項３】
前記スマートカードは、高い通信速度の特徴をもつ集積回路で構成された請求項２に記載の署名生成装置。
【請求項４】
前記署名生成装置は、更に、ハッシュモジュールと、パディングモジュールとを備えた請求項１に記載の署名生成装置。
【請求項５】
署名されるべきデータは、規定のひな型に従う請求項１に記載の署名生成装置。
【請求項６】
署名されるべきデータは、ＸＭＬフォーマットである請求項５に記載の署名生成装置。
【請求項７】
署名されるべきデータは、ＨＴＭＬフォーマットである請求項５に記載の署名生成装置。
【請求項８】
署名されるべきデータは、ＲＴＦフォーマットである請求項５に記載の署名生成装置。
【請求項９】
署名モジュール及びパーサモジュールを備えた署名生成装置を使用してデータに署名する方法において、前記パーサモジュールが、前記署名生成装置内に記憶されたルールに対してデータを分析する分析ステップを備えた方法。
【請求項１】
データに署名するように構成された署名モジュールを備えた署名生成装置において、この署名生成装置に記憶されているルールに対してデータをチェックするように構成されたパーサモジュールを備えたことを特徴とする署名生成装置。
【請求項２】
前記署名生成装置は、スマートカードである請求項１に記載の署名生成装置。
【請求項３】
前記スマートカードは、高い通信速度の特徴をもつ集積回路で構成された請求項２に記載の署名生成装置。
【請求項４】
前記署名生成装置は、更に、ハッシュモジュールと、パディングモジュールとを備えた請求項１に記載の署名生成装置。
【請求項５】
署名されるべきデータは、規定のひな型に従う請求項１に記載の署名生成装置。
【請求項６】
署名されるべきデータは、ＸＭＬフォーマットである請求項５に記載の署名生成装置。
【請求項７】
署名されるべきデータは、ＨＴＭＬフォーマットである請求項５に記載の署名生成装置。
【請求項８】
署名されるべきデータは、ＲＴＦフォーマットである請求項５に記載の署名生成装置。
【請求項９】
署名モジュール及びパーサモジュールを備えた署名生成装置を使用してデータに署名する方法において、前記パーサモジュールが、前記署名生成装置内に記憶されたルールに対してデータを分析する分析ステップを備えた方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００６−５０２５１１（Ｐ２００６−５０２５１１Ａ）
【公表日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【出願番号】特願２００５−５０００７８（Ｐ２００５−５０００７８）
【出願日】平成１５年１０月７日（２００３．１０．７）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００４４０２
【国際公開番号】ＷＯ２００４／０３１９２３
【国際公開日】平成１６年４月１５日（２００４．４．１５）
【出願人】（５０４２３９８４７）アクサルト ソシエテ アノニム (17)
【Ｆターム（参考）】
【公表日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【出願日】平成１５年１０月７日（２００３．１０．７）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００４４０２
【国際公開番号】ＷＯ２００４／０３１９２３
【国際公開日】平成１６年４月１５日（２００４．４．１５）
【出願人】（５０４２３９８４７）アクサルト ソシエテ アノニム (17)
【Ｆターム（参考）】
[ Back to top ]