JPH11502331A - 多目的取引カードシステム - Google Patents

Abstract

(57)【要約】 開示されるのは、多目的取引カードシステムであって、発行者(101)と、１以上のカード(102)と、１以上の端末(103)と、必要に応じて１以上の取得者(104)とを含む。これらは、様々な暗号化による秘匿および認証方法を用いて通信する。カードは、公開鍵ベースの暗号化を用いて、このような暗号化と通常関連する大規模な演算をカード自体が行うことなく、メッセージを認証する。複雑な取引シーケンスと複数のカード格納更新との一体化が、カードと端末との間で伝送されるデータの、意図的に生成された割り込み及び／又は改変の下においてさえも維持される。カードは、取引に直接必要でない情報も、端末がアクセスを許可されるべきではない情報も、カードの挙動のうち外部から計量可能な局面を介して端末に対して明らかにすることはない。サポートされる取引タイプは、カードに"open to buy"が維持される、オフラインクレジットカードに適したものを含む。

Description

【発明の詳細な説明】 多目的取引カードシステム 発明の背景 １．発明の分野 本発明は、取引システムに関する。詳しくは、不正改変不可能な装置を含む安 全な取引システムに関する。 ２．従来技術 以下の文献を参照する。PCT公開番号WO 89/08957、EPO出願第89905483.7号、 および1988年3月16日付米国特許第4,987,593号、Chaum、"One-Show Blind Signa ture Systems"。これらは本明細書において参考として引用されている。EPO出願 第90200207.0号、および1990年1月29日付米国特許第5,131,039号、Chaum、"Opti onally moderated transaction systems"。これらは本明細書において参考とし て引用されている。1989年7月24日付米国特許第4,914,698号、Chaum、"One-show blind signature systems"、および1992年7月13日付米国特許第5,276,736号、C haum、"Optionally moderated transaction systems"。これらは本明細書におい て参考として引用されている。 公開鍵ディジタル署名を「裏書き」する基本技術は、上記の最初の参考文献お よびCrypto '88で提出された関連文書に開示された。この技術は上記の第２の参 考文献ならびにその他の後続の出版物、例えば、Crypto '89で提出された文書に 関連するMicaliらの米国特許第5,016,274号およびCWI技術レポートCS-R9035など で使用された。 裏書きスキームは単に一回限り署名スキームであり、一回限り署名スキームで 常に必要とされる公開鍵の認証は、周知の公開鍵証明書技術を用いて行われる。 上記の最初の参考文献で最初に公開されたものに較べて、裏書き機能の効率性 が３つの点で向上したことが当該分野で既知である。最初の２つの点は、一回限 り署名スキームに関係し、第３の点は真の公開鍵ディジタル署名の向上である。 最初の２つの向上点は、「ランポート(Lamport)」署名と呼ばれる周知の最初 の一回限り署名に関してなされたものである。「ランポート」署名は、"New dir ections in cryptography"、IEEE Transaction on Information Theory、644頁 、654頁、1976にLamportによって開示されこの名が付けられたもので、後にSRI 技術レポートCSL 98にもLamportによって記載されている。ランポート署名は単 に、秘密値リストへの公開一方向機能の出力を、公開鍵として認証する。後にこ れら秘密値の下位セットを放出することにより、誰でもこれらが認証されたリス トに対応すること、およびメッセージが下位セットの選択で符号化されることに より署名されることを確認することができる。 第１の向上点は、少なくとも、IBM Technical Disclosure Bulletin、第28巻 第2号、1985年7月、603-604頁、"Matrix digital signature for use with the data encryption algorithm"、およびランポート署名に関するMerkleによるCryp to '87の議事記録に開示されていると考えられ、後にChaumによる上記の第２の 参考文献で組み込まれた。この第１の向上点により、一方向機能への最初の秘密 入力リストのサイズが縮小する。署名を一方向機能の単一の独立したアプリケー ションに基づかせる代わりに、機能は、チェーン内の前の機能アプリケーション の出力が次の機能アプリケーションの入力として働くように構成される、すなわ ち「チェーン化」される。各チェーンは、一回限りスキームによって署名される 数字メッセージのうちの１ディジットを表すものと考えることができる。基数は 、チェーンの長さに１を足したものであり、最初のランポート署名は基数２を有 する。この第１の向上点の結果、格納および伝送が節約されるが、計算量は増大 する。 第２の効率の向上点もまた上記に引用したMerkleによって開示された。これは 、必要な「制御」ディジット数を減らすための、符号化技術では既知であると考 えられる技術を適用している。これらの制御ディジットは、署名が異なるメッセ ージの署名に変更されるのを防止するものである。引用した前の開示では、メッ セージディジット毎に１つの制御ディジットが用いられ、制御ディジットはメッ セージディジットの加法に関する逆元を表した。今回の向上点は、本質的には、 メッセージディジットの合計の加法に関する逆元を表す制御ディジットを２〜３ 個しか用いないことにより得られる。従って、制御ディジット数は、メッセージ デ ィジット数に対して線形の関係から単に対数であることに代わるため減少する。 第３の向上点は、一定の公開鍵ディジタル署名スキームに適用される。これは 、米国特許第4,949,380号、Crypto '89で提示された文書、PCT公開番号US89/046 62号、およびPEO出願第89912051.3号に最初に開示された。こられの文献はすべ て実質的には同じであり、すべてChaumによる。この向上点により、複数の公開 鍵署名を、これらが互いに素の公開指数により作成される限り、１つの公開鍵署 名によって占領されるスペースに「混合」することが可能になる。これらは混合 形態で署名され、この形態で格納され、そして後に提示時に分離され得る。この 技術はまた格納（および通信）を節約するが、潜在的に余分の計算を必要とする 。 裏書きスキームの１つの商業的に興味ある使用は、「プリペードカード」の領 域であると考えられる。 プリペードスマートカードは格納された金額を含み、これを所持する個人が小 売店での支払い時に使うことができる。カードから格納された金額を受け取った 後、小売人は定期的にシステム提供者から実際のお金を弁済してもらう。システ ム提供者は使用者からお金を先に受け取り、対応する金額を使用者のカードに格 納する。こらら３種類の取引のそれぞれにおいて、金額を表す安全データが実際 のお金または商品およびサービスと交換される。フランスなどで使用されている テレホンカードが恐らく最もよく知られたプリペードスマートカードである（テ レホンカードによっては光学技術を使用するものもあり、磁気技術を使用するも のもある）。今日の全国的なプリペードシステムは、典型的には、公衆電話、販 売者、製造者および公的輸送機関を組み合わせることを目的としている。有料道 路の料金自動回収もやがてはこれに含まれ得る。 プリペードスマートカード市場の成長は急速のようである。例えば、本出願が なされた時点では、全国的なプリペードチップカードスキームは、デンマークで は開始され、ポルトガルでは構築中であり、ベルギー、スペインおよびフランス では計画中であると考えられる。米国で最大のATMネットワークであると考えら れるMACネットワークは参入を公表している。また、南アフリカおよびスイスで はシステムは既に作動している。 カードで使用される従来の暗号化方法のみに基づくスキームでは、すべての支 払いポイントで安全モジュール（SAMと呼ばれることもある）が必要とされる。 なぜなら、取引は、外部サイトとの通信は行わずに、取引コストを低額の支払い と釣り合うように維持して完結させる必要があるため、また従来の暗号化認証で は通信者は共通の秘密を共有することが必要であるためである。各安全モジュー ルは、すべてのカードの秘密鍵を生成する能力を必要とすると考えられ、これに よりいくつかの問題が生じる。多数のシステム提供者のカードが同じ支払いポイ ントで受け入れられるとすると、すべての支払いポイントがすべての提供者の鍵 を含む安全モジュールを持たなければならない。これは、多数の提供者の鍵を含 む相互に信頼された１つのモジュールか、または各提供者に１つのモジュールか のいずれかを意味すると考えられるか、前者は実現するのは困難であり、後者は 提供者の数が増えると実現不可能になる。さらに、このようなシステムでは、モ ジュールが普及すると、顕著な小売側の詐欺が促進されるだけでなく、カードベ ース全体が侵犯され得る。 裏書きスキームはこのような安全モジュールを必要としないため、これらの問 題は回避される。支払いポイントでの装置には安全鍵は必要なく、裏書きを認証 するために、関連する詳細すべてが書き込まれた保証小切手のような働きをする 公開鍵が必要なだけである。これらの同じ裏書きは後に弁済のためにシステム提 供者によって検証され得る。（これらのシステムでは完全な隅から隅までの検証 が可能であるが、切り捨てのためにいつでも不正改変不可能な集合体を用いるこ とができる。）またこれらにより、すべての小売店でいかなる数の発行者（issu er）のカードでも受け入れることができる。小売店は発行者を騙すことはできず 、発行者は互いを騙すことができない。 このようなシステムではカードのチップのサイズは本質的に実用的に重要であ る。一定の技術では、記憶領域が大きくなれば、チップの製造コストが高くなり チップのサイズが大きくなる。業界ではチップサイズが大きくなることは、また カード製造コストが高くなり、カードの信頼性および耐久性が低くなると考えら れている。現時点でこのような全国的なプリペードシステムのために使用される と報告されているカードは、従来の暗号化認証のみを使用し、また約１キロバイ トの不揮発性記憶領域しか持たない。裏書き技術が競争力を持つためには、これ らが同じチップに適合し得ることが重要であると考えられる。先行技術では、十 分な裏書きをこのようなチップに格納することができない。 さらに、スマートカードを用いて完結される通常のクレジットカードおよび／ またはデビットカード取引は、取引の詳細をオフライン公開鍵により裏書きする という追加のセキュリティにより恩恵を受けていると考えられる。 不正改変不可能な装置を使用する取引システムは周知である。通常は、不正改 変不可能な装置はスマートカードの形態を有する。ほとんどのスマートカード取 引システムは金融取引を目標とするが、アクセス制御などの多くの他の取引でも 使用される。ほとんどのスマートカードシステムでは、スマートカードはそのス マートカートに特有の１つ以上の秘密鍵を有し、一方、各端末は、不正改変不可 能な装置内に端末がスマートカードの秘密鍵を引き出すのを可能にする１つ以上 の「マスター鍵」を有する。取引の両パーティが秘密鍵を共有すると、従来の暗 号化方法を用いて取引のセキュリティおよび認証性が確実に得られる。端末の「 マスター鍵」がこれらのシステムにおける弱点である。なぜなら、端末からこれ らの鍵を得ることに成功する攻撃が、セキュリティの破滅的な破壊を引き起こす からである。この問題を解決する方法は、通常は、ある種の公開鍵暗号化方法を 適用することである。公開鍵暗号化能力を有するスマートカードを使用すること は１つの解決法ではあるが、このようなスマートカードは単純なカードより費用 が掛かる。 取引中に、スマートカードは、典型的には、例えばEEPROMよりなる不揮発性メ モリ内の１つ以上の位置を更新する。現在のスマートカードは更新中の妨害に脆 いことがあり、これがセキュリティおよび信頼性の問題を引き起こす。不揮発性 メモリでの誤りは間違った取引処理を導くことが多い。EEPROMメモリを用いるス マートカードの別の弱点は、スマートカードが紫外線(UV)光で照射されるという 攻撃である。これはEEPROMに格納されているデータに影響を与えることが知られ ているため、システムのセキュリティを攻撃するために用いられるかもしれない 。いくつかのタイプの取引では、不揮発性メモリ内のいくつかの項目を同時に改 変する必要がある。これは現在のスマートカードではサポートされない要件であ る。 取引を構成する異なる様々な行為はほとんど暗号化手段によってまとめられな いため、複合取引のための十分なセキュリティを提供することが困難であり、ま た特別な行為の使用を必要とすることが多い。支払い目的で使用される金融取引 システムでのスマートカードは、典型的には、暗号化プルーフを支払いが行われ た端末に送る前に、内部に保持した残高から支払い額を差し引く。この更新とプ ルーフの送付との間の期間に妨害があれば、特別な回復手続きが使用されない限 り、金銭の損失が生じる。 ほとんどのスマートカードは積極的に多くの情報を明らかにし、これには、固 有のカードID番号、ディレクトリ構造などが含まれることが多い。この情報は通 常はアプリケーションのセキュリティに直接関連しないが、端末にスマートカー ドの所有者のプライバシを侵害するために使われるかもしれない追加の情報を提 供し得る。 スマートカードの不正改変不可能性は、典型的には、スマートカードが秘密情 報（例えば秘密暗号化鍵）を用いてプロセスを実行することを可能にするために 使用され、取引システムの設計では、スマートカードが端末にいかなる秘密情報 も提供しないように注意が払われる。しかし、端末は、カードによって送られる データを単に見るだけ以上の多くの測定を行い得る。現在の多くのシステムはこ れらの追加の測定を使用する攻撃には脆いというのが本発明者らの考えである。 EMVシステムのための最近出版された仕様書、すなわち、すべてが1994年10月3 1日付けでEuropay International S.A.、MasterCard International Incorporat ed、およびVisa International Service Associationによって出版された"Integ rated Circuit Card Specifications for Payment Systems: Part 1，Electrome chanical Characteristics，Logical Interface，and Transmission Protocols 、version 1.1; Part 2，Data Elements and Commands，version 1.1; and Part 3，Transaction Processing，version 1.0"は、クレジットカードアプリケーシ ョンのために設計されるシステムを定義している。これらにより、いくつかのク レジットカード取引のオフライン処理が可能となる。これらの仕様書は、端末は いかなる秘密鍵へのアクセスも行わないという設定を想定していると考えられ、 特定のオフライン取引は、端末がこの設定でカードおよび取引データの正当性を 検証する手段を含んでいない。EMV仕様書は、クレジットカード支払い、ユーザ の 口座の直接デビット、金銭がカード内に格納されるプリペード支払いなどを含む いくつかのタイプの金融取引で使用されるように構想されている。仕様書は、こ れらのアプリケーションすべてに横たわる構成の類似性について述べていない。 いくつかのタイプの取引、特に金融取引には、清算プロセスも存在する。この プロセスでは、端末は回収したお金に関する情報を取得者（acquirer）および／ または発行者に送る。現在のシステムは、端末が完全な取引情報を取得者に渡す か、または端末の不正改変不可能な装置（SAMと呼ばれることが多い）に切り捨 てを行わせるかのいずれかに依存する。SAMは取引データを受け取り、これらを 検証し、そして必要な合計の追跡を続ける。これにより、取引データのいくつか またはすべてが放棄され、必要な清算情報がSAMから取得者および／または発行 者に渡され、暗号化スキームを用いて認証される。すべての取引情報を渡すこと は費用が掛かり面倒である一方で、端末にSAMを備えるのは費用が掛かる。１つ の端末が多くの異なる発行者／取得者と取引を行わなければならないときは、端 末は発行者／取得者それぞれのための個別のSAMを必要とするか、または発行者 ／取得者すべてによって信頼される単一のSAMを必要とする。前者は費用が掛か り、後者は構成上困難である。 発明の目的 従って、本発明の目的は、 安全で柔軟性があり効率的で信頼性のある多目的取引システムを提供すること 、 スマートカードのための安全で効率的な認証能力であって、スマートカードが 適切な方法で公開鍵暗号化計算を行う能力に依存しない認証能力を提供すること 、 任意の妨害および物理的な攻撃が行われているときでも、スマートカードの不 揮発性メモリ内のデータに１つ以上の改変を加えるために、メモリの安全な極小 の更新を提供すること、 取引を構成する異なるいくつかの行為がまとめて保持され順に実行される適切 な暗号化プルーフおよび検証を提供すること、 適切な鍵へのアクセスを有しない端末にスマートカードが情報を曝露するのを 防ぐこと、 スマートカードが、取引の一部として伝達された情報に加えて、他の情報を外 部の行為を介して曝露することを防ぐこと、 端末の１つ以上の不正改変不可能な装置を使用しなければ、取引データのすべ てを伝達しない清算方法およびシステムを提供すること、 公開鍵に基づいたディジタル認証を取引に加えることによって、オフラインEM V取引での端末の利益を保護すること、 クレジットカード取引、プリペード取引、直接デビット取引などのために使用 され得る一般的な取引構造を提供すること、および 本発明の他の目的を満たす、効率的で経済的で実用的な装置および方法を実現 することである。 本発明の他の目的、特徴および利点は、本発明の記述および添付された請求の 範囲を図面と共に読むことにより理解され得る。 図面の簡単な説明 図39、図42、図43、図44、図45および図46は第１の好適な実施態様の記述の一 部であり、他のすべての図面は第２の好適な実施態様の記述の一部である。 図１は、本発明の教示による、４つのパーティ群を含む多目的取引カードシス テムの１つの好適な実施態様の組み合わせブロックおよび機能図を示す。 図２は、本発明の教示による、ハウスと呼ばれる一回限り署名構造の組み合わ せブロックおよび機能図を示す。 図３は、本発明の教示による、タウンと呼ばれる第１の好適で緻密な裏書き署 名構造の組み合わせブロックおよび機能図を示す。 図４は、本発明の教示による、タウンと呼ばれる第２の好適で緻密な裏書き署 名構造の組み合わせブロックおよび機能図であって、効率的な具現体を可能にす ると考えられる。 図５は、本発明の教示による、タウンと呼ばれる緻密な裏書き署名構造の１つ の好適な実施態様の組み合わせブロックおよび機能図である。 図６は、本発明の教示による、図２の一回限り署名構造を用いて、セキュリテ ィを向上させると考えられる方法で署名されるデータ要素および制御要素の例を 示すブロック図である。 図７は、本発明の教示による、公開鍵検証パーティの組み合わせブロックおよ び機能図を示す。 図８は、本発明の教示による、カード取消プロセスの１つの好適な実施態様の フローチャートであり、図13、図14、図15、図16、図17、図18および図19と共に 、カードの安全なデータ記憶システムを実現すると考えられ、また、特に、セッ ションの終わりに実行されるときは、カードの不揮発性メモリのこのセッション の結果のすべてを返すと考えられる。 図９は、本発明の教示による、ハウスと呼ばれる一回限り署名構造の１つの好 適な実施態様の組み合わせブロックおよび機能図を示す。 図10は、本発明の教示による、公開鍵発行パーティの組み合わせブロックおよ び機能図を示す。 図11は、本発明の教示による、不揮発性メモリモデルのブロックおよび機能図 を示し、当該分野で使用されるほとんどのタイプの不揮発性メモリの書込みおよ び消去行為、特にEEPROMの書込みおよび消去行為を示すと考えられる。 図12は、本発明の教示による、カードの１つの好適な実施態様において揮発性 および不揮発性メモリを使用する場合を示すブロック図である。 図13は、本発明の教示による、カード開始更新プロセスの１つの好適な実施態 様のフローチャートを示し、図８、図14、図15、図16、図17、図18および図19と 共にカードの安全データ記憶システムを実現すると考えられる。 図14は、本発明の教示による、カード削除フレーム[ｉ]プロセスの１つの好適 な実施態様のフローチャートを示し、図８、図13、図15、図16、図17、図18およ び図19と共にカードの安全データ記憶システムを実現すると考えられる。 図15は、本発明の教示による、カード書込みフレーム[t,access,data]プロセ スの１つの好適な実施態様のフローチャートを示し、図８、図13、図14、図16、 図17、図18および図19と共にカードの安全データ記憶システムを実現すると考え られる。 図16は、本発明の教示による、カードリセットプロセスの１つの好適な実施態 様のフローチャートを示し、図８、図13、図14、図15、図17、図18および図19と 共にカードの安全データ記憶システムを実現すると考えられる。 図17は、本発明の教示による、カードコミットプロセスの１つの好適な実施態 様のフローチャートを示し、図８、図13、図14、図15、図16、図18および図19と 共にカードの安全データ記憶システムを実現すると考えられる。 図18は、本発明の教示による、カード見い出しフレーム[t]プロセスの１つの 好適な実施態様のフローチャートを示し、図８、図13、図14、図15、図16、図17 および図19と共にカードの安全データ記憶システムを実現すると考えられる。 図19は、本発明の教示による、カード読出しフレーム[t]プロセスの１つの好 適な実施態様のフローチャートを示し、図８、図13、図14、図15、図16、図17お よび図18と共にカードの安全データ記憶システムを実現すると考えられる。 図20は、本発明の教示による、データをあるセッションステートにより暗号化 し、このセッションステートチェーンのデータをチェーン化し、データをこのセ ッションステートにより復号化し、そしてこのセッションステートのデータをチ ェーン化するメカニズムを示す組み合わせブロックおよび機能図である。 図21は、本発明の教示による、カードの好適な実施態様で行われる、データを あるセッションステートにより「暗号化」しこのセッションステートのデータを チェーン化するメカニズム、およびターミナルの好適な実施態様で行われる、デ ータをこのセッションステートにより「暗号化」しこのセッションステートのデ ータをチェーン化するメカニズムを示す組み合わせブロックおよび機能図であり 、これは図20に示すような暗号化復号化対を実現すると考えられる。 図22は、本発明の教示による、カードの１つの好適な実施態様で行われる、デ ータをあるセッションステートにより「暗号化」しこのセッションステートのデ ータをチェーン化するメカニズムを示す組み合わせブロックおよび機能図であり 、これは、図23に示すメカニズムと共に、図21に示すようなメカニズムを実現す ると考えられる。 図23は、本発明の教示による、ターミナルの１つの好適な実施態様で行われる 、データをあるセッションステートにより「暗号化」しこのセッションステート のデータをチェーン化するメカニズムを示す組み合わせブロックおよび機能図で あり、これは、図22に示すメカニズムと共に、図21に示すようなメカニズムを実 現 すると考えられる。 図24は、本発明の教示による、１つの好適な実施態様のカードおよび端末を含 む「セッション」と呼ばれるプロセスのフローチャートを示す。 図25は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む「開始セッションおよびプルーフ鍵」と呼ばれる 詳細プロセスのフローチャートであり、図26および図27と共に図24のプロセスを 実現すると考えられる。 図26は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む「コマンドおよび交換データ」と呼ばれる詳細プ ロセスのフローチャートであり、図26および図27と共に図24のプロセスを実現す ると考えられる。 図27は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む「コミットセッションおよび終了セッション」と 呼ばれる詳細プロセスのフローチャートであり、図26および図27と共に図24のプ ロセスを実現すると考えられる。 図28は、本発明の教示による、１つの好適な実施態様における、端末による行 為、カードによる行為、およびカードと端末との間および端末と発行者との間の 通信を含むEMV取引プロセスのフローチャートである。 図29は、本発明の教示による、１つの好適な実施態様における、端末によって 発行されカードによって実行されるすべての可能な成功した実行可能コマンドシ リーズを示すフローチャートである。 図30は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含むコミット−チャレンジ−レスポンスプロセスのフ ローチャートを示す。 図31は、本発明の教示による、両方共条件に依存して変数に値を割り当て、割 り当てられた変数に同じ結果を有すると考えられる非単一実行通路プロセスおよ び単一実行通路プロセスのフローチャートを示す。 図32は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「プルーフを得る」プ ロセスのフローチャートを示す。 図33は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「スクリプト」を行う プロセスのフローチャートを示す。 図34は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「セッション１を開始 」、「セッション２を開始」。「フレームを得る」、「フレームを置く」、およ び「フレームを殺す」と呼ばれるプロセスの５つの詳細なフローチャートを示す 。 図35は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「デビットフレーム」 、「再デビットフレーム」、「公開デビット」、「コミット」、および「実行済 」と呼ばれるプロセスの５つの詳細なフローチャートを示す。 図36は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「プルーフを得る」、 「ファイルを選択」、「アプリケーション１を管理」、「アプリケーション２を 管理」、および「データを得る」と呼ばれるプロセスの５つの詳細なフローチャ ートを示す。 図37は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「ファイルを得る」、 「AC 1を生成」、「AC 2を生成」、「外部認証」、および「検証」と呼ばれるプ ロセスの５つの詳細なフローチャートを示す。 図38は、本発明の教示による、端末による行為、カードによる行為、およびカ ードと端末との間の通信を含む、１つの好適な実施態様の「最後のACを得る」と 呼ばれるプロセスの詳細なフローチャートを示す。 図39は、本発明の教示による、４つのパーティセットを含む緻密な裏書き署名 システムの１つの好適な実施態様の組み合わせブロックおよび機能図を示す。 図40は、図５の好適で緻密な裏書き署名構造の本発明の教示による不揮発性メ モリのコンテンツを、タウンの値、表記および行為の表構成によって示す。 図41は、図５の好適で緻密な裏書き署名構造の本発明の教示による動作ステッ プを、タウンの値、表記および行為の表構成によって示す。 図42は、本発明の教示による、裏書きパーティの１つの実施態様の組み合わせ ブロックおよび機能図を示す。 図43は、本発明の教示による、一般的な裏書きスキームプロセスのフローチャ ートを示す。 図44は、本発明の教示による、一回限り署名構造の例を示す。 図45は、本発明の教示による、１つの好適な裏書き構造を示し、図45a〜45dは 第１レベルカスケード構造の例であり、図45eは第２レベルカスケード構造の例 である。 図46は、図45の構造例の本発明の教示による動作ステップを、レジスタ名およ び表記の表構成によって示す。 図47は、図１のようなシステムの好適な実施態様のカードと発行者との間の対 話を、本発明の教示による、いくつかのレジスタに関するカードエンティティに 加えられる詳細、および維持されるデータベースに関する発行者エンティティに 加えられる詳細と共に示す組み合わせブロックおよび機能図を示す。 図48は、本発明の教示による、図47のカードデータベース内の１つのレコード の好適な実施態様のブロック図を示す。 図49は、本発明の教示による、図47のイベントデータベース内の１つのレコー ドの好適な実施態様のブロック図を示す。 図50は、本発明の教示による、主に、オンライン取引中に発行者の知っている 残高をカードの残高と同期させる発行者プロセスの１つの好適な実施態様のフロ ーチャートを示す。 図51は、本発明の教示による、主に、オフライン取引の清算プロセス中に発行 者の知っている残高をカードの残高と同期させる発行者プロセスの１つの好適な 実施態様のフローチャートを示す。 図52は、本発明の教示による、図50のプロセスの具現体の例のフローチャート を示す。 図53は、本発明の教示による、図51のプロセスの具現体の例のフローチャート を示す。 発明の簡単な要旨 本発明の上記のおよび他の目的に従って、いくつかの実施態様の簡単な要旨を 述べる。この要旨では、いくつかの簡略化および省略が行われるが、これは本発 明のいくつかの局面を強調および導入する目的のためであって、いかなる意味に おいても本発明を限定するものではない。本発明の概念を当業者が作成および使 用し得るに十分な好適な実施態様についての詳細な記述は後に提供する。 好ましくは数百個の裏書きを簡単なマイクロコントローラのスマートカードに 千バイトより少ないバイト数で格納するのを可能にする裏書きスキームは商業的 に興味あるものであるが、従来の技術では実現することはできない。本発明はこ のような従来技術の制約を克服する。 本発明の概念は、単一公開鍵署名内に多数の一回限り署名の階層構造を提供す る。この階層構造は、特別なツリー構造の内部「ノード」として働く、ハッシュ (hash)機能またはメッセージ消化機能としても知られる圧縮一方向機能から形成 される。ツリーの「リーブ」は一回限り署名であり、その「エッジ」は、圧縮機 能の入力および時には出力である値である。従って、ルートは、構造内の一回限 り署名のすべての最終的な圧縮を表し、この圧縮の出力がディジタル署名技術に よって署名される。 各裏書きは、この裏書きでそしてこの裏書きのみで使用される単一の一回限り 署名を含むツリーの下位セットを含む。下位セットにはまた、公開鍵署名および リーフからルートへのエッジの通路が含まれる。通路上のエッジではなく、通路 のノードに付随するすべてのエッジによって表される値が含まれる。 裏書きは、構造化と協働して、カードが各段階で比較的少数の不揮発性レジス タを使用するような順序で行われる。さらに、各裏書き間で必要な計算量も少な い量に限定される。さらに、１つのディジタル署名の最後の一回限り署名から次 のディジタル署名の最初の一回限り署名に進むためには、実質的に、同じディジ タル署名内の２つの一回限り署名間を進むのと同じ資源を必要とするだけである 。 後に詳述する特定の好適な実施態様の１つは、構築ブロックとして２アーギュ メント圧縮機能の「カスケード」を使用する。カスケードの最初の圧縮機能は、 カスケードの外側から２つの入力を受ける。カスケードのその後のすべての圧縮 は、前の圧縮から１つのアーギュメントをそしてカスケードの外側から１つのア ーギュメントを受ける。従って、カスケードの１つの圧縮の出力のみが、カスケ ードへのその後のすべての入力と共に、カスケード全体の出力の検証のために使 用され得る。 カスケードは低い、好ましくは２レベルの高さしかない階層構造に構造化され 得るが、いかなる階層構造でも使用され得る。低レベルでのカスケードは、「ス トリート」と呼ばれ、「ハウス」と呼ばれる一回限り署名から直接入力を受ける 。高レベルでのカスケードは、「タウン」と呼ばれ、低レベルでのカスケードの 出力から入力を受ける。従って、あるストリートのハウス群およびあるタウンの ストリート群には完全な順序化が形成される。 大まかに述べれば、この好適な実施態様では、裏書きはハウスからハウスへ順 番に進行するものと考えられ得る。１つのハウスが訪問されると、その一回限り 署名が裏書きに使用される。この裏書きのための「実際の」横移動に加えて、平 行に行われる２つの「予備」横移動がある。 第１の予備横移動は、次のストリートに移動してほとんどすべてのハウスを訪 問する。（現在のタウン順序に次のストリートが存在する場合はこれを横移動す る。現在のタウンにストリートがもう存在しない場合は、次のタウンの最初のス トリートを横移動する。）第１の予備横移動の目的は、ストリートのリーフエッ ジを獲得して格納し、そのストリートが訪問され最初のハウスが裏書きに使用さ れるときに準備ができている状態にするである。 第２の予備横移動は次のタウンを通して移動する。この横移動の目的は、次の タウンの、最初のストリート以外のすべてのストリートからのエッジを獲得して 格納することである。これらは、この新しいタウンが実際の横移動によって最初 に訪問され最初のストリートから裏書きが行われるとき、裏書きで必要とされる 。 不正改変不可能な装置は、多くの場合、不揮発性メモリに情報を格納する。こ の好適な実施態様は、任意の妨害が行われているときでも、不揮発性メモリにい くつかの改変が突然一緒に行われることを可能にする極小多更新を可能にする。 スマートカードチップのUV照射を含む攻撃下でも重要データの秘密性は維持され る一方で、同時に、技術的な失敗の場合には回復が可能である。 取引を構成する行為を暗号化によりリンクするセッションが導入され、構成行 為がすべて順番に、そして間に他の行為を入れずに行われることが確実にされる 。セッションはまた、取引全体のための単一のプルーフシステムを提供し、特定 の取引のための特別な初歩的な行為を行う必要をなくする。任意の妨害の下でも 、セッションは、取引が完了して暗号化プルーフが適切に交換されることを、ま たは取引は全く行われないことを確実にする。 この好適な実施態様では、不正改変不可能な装置は、たとえ端末がその動作中 にカードに一般的な追加測定セットのいずれかまたはすべてを行う場合でも、端 末との間で明瞭に通信された情報の他には、端末にいかなる情報も曝露しない。 端末に不正改変不可能な装置を必要とせずに、または十分な取引データを端末 から取得者／発行者へ伝達する必要なく、金融および他の取引の十分な清算およ び解決を可能にするいくつかの清算方法が述べられる。 EMVシステムは拡張および一般化される。端末の利益は、取引データの適切な オフライン認証を含むことによって適切に保護される。EMVシステムは一般化さ れ、幅広い範囲の様々な支払いアプリケーションの実現に必要なすべての機能を 提供する。 好適な実施態様の詳細の説明 図面および以下に述べる詳細な説明は、説明の具体性および明瞭性のために多 くの簡略化した仮定を行っている。しかし、これらは本発明の範囲を限定するも のとして取られるべきではないことは理解されよう。 図面のいくつかのラインおよび矢印はメッセージを表し、これらは、最初は保 持されるかまたは途中で遅延され、様々なパーティを通して渡され、暗号化方法 により符号化および復号化され、さもなくば他の処理が行われ、これにより、正 当性および／または秘密性および／またはエラー検出および／またはエラー回復 が提供される。従って、メッセージを転送する特定の手段または方法は本発明に とっては重要ではなく、この点に関してはいかなる技術でも用いられ得ると予想 される。 当業者であれば、Bruce Schneier 1994、"Applied Cryptography，Protocols ，Algorithms，and Source Code in C"およびこれに含まれる参考文献について は周知であろう。また、Donald E．Knuth 1981、"The art of computer program ming”part 1 "Fundamental algorithms"およびpart 2”Seminumerical algorit hms”ならびにこれらに含まれる参考文献については周知であろう。 適用されると考えられるパラメータ値についての背景が、この好適な実施態様 で行われるトレードオフのいくつかの基礎として働く。 典型的なユーザ取引は、これが受容可能なほどに速いと感知される場合は、ほ ぼ１秒より長い遅延は生じるべきではないと考えられる。当然ながら、高速道路 の料金回収、さらに大量輸送の場合でさえ、実質的にもっと速い取引を必要とし 得る。上記の第２の参考文献に示されるように、裏書き署名はこのような高速取 引に非常に適している。 RSA署名は今日では最小で64バイトである。他のディジタル署名はこの大きさ の３分の１であり得る。圧縮一方向またはハッシュ機能の出力は典型的には16バ イトである。一方向機能の入力または出力は典型的には８バイトであり得る。本 発明の現在商業的に興味のある目標として既に述べた１キロバイトの不揮発性メ モリのスマートカードは、典型的には、その不揮発性記憶領域のための様々な競 合する使用を有する。署名および裏書きに必要な他の値の格納には全体量より少 ない量しか利用できないと考えられている。これら他の値の例としては、製造お よび配送に関連する自己証明データ、発行者との通信を確実にするための暗号化 鍵、カード残高を保持するレジスタ、取引記録、発行者の公開鍵証明書、鍵有効 性データなどがある。 一方向機能を構築するのに典型的に用いられ得るブロック暗号動作は、典型的 には、様々な要因によって異なるが、スマートカードのマイクロコントローラに よって毎秒100〜400回行われ得ると考えられる。このようなブロック暗号の少な くともいくつかのアプリケーションは、ハッシュまたは圧縮機能を実現するため に必要であると予想される。読出し装置は、ブロック暗号を約２桁速く計算する ために特別な回路を使用することができる。 スマートカードと読取り装置との間のデータの伝送は、典型的には、毎秒約10 00バイトであると考えられているが、いくつかの標準的なプロトコルの下では少 なくとも４のファクターだけ速度を速めることができる。 暗号化技術に関するいくつかの一般的な概念について以下に示す。 変数に「乱数」値を割り当てることにより、少なくともあるパーティに容易に 知られてはならない値を生成する機能が行われる。多くの場合鍵と呼ばれるこの ような予測不能な量を生成するには多くの手段および方法が当該分野で知られて いる。これらのうちのいくつかは、半導体のノイズ、ボタンを押す人間に検出さ れるパターン、または恐らく擬似乱数生成器とも呼ばれる決定論的暗号化技術な どの物理的な現象に基づく。これら様々な技術は多くの場合組み合わせることが できること、および多くの場合後処理により結果が向上することは当該分野では 周知である。従って、乱数値を引き出す特定の手段または方法は本発明にとって は重要ではなく、これに関してはいかなる技術も用いられ得ると予想される。 前述のように、「圧縮」機能は、ハッシュ機能またはメッセージ消化機能とし て当該分野では周知の方法の１つの例である。このような機能はその出力より大 きい入力を受ける。出力が与えられる場合にそれを生成する入力を辿るのは、入 力のいくつかが知られている場合でも、計算上禁制であると考えられている。 本明細書において用語「パーティ」は、少なくともある情報の秘密性、通常は 少なくとも１つの鍵、に対する制御を有するエンティティを示す。複数の人々が ある１つの鍵のすべてまたは実際にはその一部を知り得ると予想され、これらの 人々が集合的に１つのパーティとして考えられ得る。他の場合では、鍵は実質的 には人々に知られておらず、ある物理的な装置内に存在するかもしれない。この 時は、装置自体またはこれを時折制御する人々がパーティとみなされ得る。 情報をパーティ間で伝送する方法または手段は、本発明にとっては重要ではな く、いかなる適切な方法によっても実現され得る。例えば、出力および入力手段 は互いに物理的に近い位置に配置され得るか、またはこれらはいかなる種類の通 信ネットワークまたは技術によってでも遠隔的に通信し得る。情報は様々な形態 、例えば暗号化方法で符号化され、復号化され、そして途中で符号化の間に伝送 され得る。同様に、情報は途中で様々な形態で様々なパーティによって格納およ び ／または保持され得る。 パーティ名、パーティの形態、およびパーティ数の選択は、明瞭化のためにお よび便宜上行われる選択の例である。当然ながら、本明細書で開示した本発明の 概念は、パーティの特定のタイプ、グループ化または数に限定されると解釈され るべきではなく、また命名のしきたりなどで他の意味を含むべきではない。 次に図39を参照して、本発明の概念のいくつかの実施態様の構成部品の相互接 続および協働の一般的な説明を行う。 署名発行パーティ3941（簡単に発行者と呼ぶ）は少なくとも１つの秘密鍵を有 する。対応する公開鍵は少なくとも被裏書人3943（これについては後により詳し く述べる）および追加の検証人3944に知らされる。 署名運送および裏書きパーティ3942（本明細書では簡単に裏書人と呼ぶ）は、 ライン3951で示すように発行者3941から署名を受け取る。被裏書人および検証人 3943（簡単に裏書人3943と呼ぶ）はライン3952で示すように裏書人3942から裏書 きを受け取る。追加の検証人3944もまた、簡略化のためにライン3953を介して被 裏書人から送られるように示されている裏書きを検証する。 明瞭化のために示してはいないが、各パーティタイプには複数の例があり得る 。例えば、それぞれが同じ発行者によって発行された署名を裏書きする多数の裏 書人がいてもよい。それぞれが複数の裏書人のうちの一人から裏書きを受け取り 得る多数の被裏書人がいてもよい。それぞれが複数の被裏書人または他のものか ら受け取る裏書きを検証し得る多数の追加の検証人がいてもよい。さらに多数の 発行人がいてもよく、彼らのうち同じ署名を発行することができるものもあれば 、できないものもある。 各署名はメッセージに関連し、その発信源は本発明の概念にとっては重要では ない。例えば、メッセージは発行者3941、裏書人3942、被裏書人3943または検証 人3944、乱数源、外部イベント、またはこれらの組み合わせからのものであり得 る。上述のパーティのいずれも、裏書きで協働する前にメッセージについて知り 得るか、もしくはパーティの一方がメッセージのすべてまたは一部を他方に供給 し得る。これについては明瞭化のために示されない。 次に図42を参照して、本発明の概念のいくつかの実施態様の構成部品の相互接 続および協働の一般的な説明を、裏書人3942について行う。 スマートカード4200または他の携帯データキャリアが裏書人3941の役割を果た し得る。これはいくつかの相互接続された構成部品よりなると考えられる。I/O インタフェース4201は、発行者3941および被裏書人3943などの外部世界とインタ フェースリンク4206を介して通信し、これは、スマートカード技術では周知のよ うに、ガルバニック接触または非接触技術であり得る。また、暗号化機能4204を 計算する特別な回路またはファームウェアがあるかもしれない。さらに、制御手 段4202は他の構成部品の動作および調整を管理する。本発明の目的にとって最も 重要なものは値を格納するレジスタ4203である。これには２つのタイプ、すなわ ち不揮発性タイプおよび一時的タイプがあると考えられる。このような構成部品 すべては共におよび／またはI/Oインタフェース4201と共に、簡略化のためにバ ス4205として示す相互接続手段を介して協働し得る。１つの実施態様は、Motoro la SC-24スマートカードチップまたは、例えばThompson Semiconductorsにより 製造されるこれに近い均等物で有り得、これらは当業界の標準的なスマートカー ドに埋め込まれ得る。 図43を参照して、本発明の概念のいくつかの実施態様の機能およびプロセスス テップについて一般的に述べる。 フローチャートボックス4301に示すように最初のステップは、発行者3941が裏 書人3942に緻密な裏書き署名を発行することである。これによりすべてのハウス およびエッジが作成される。次に、上述のようにディジタル署名がルート出力に 形成される。明瞭化のためにはっきりとは示していないが、この発行プロセスで はブラインド署名技術が用いられ得る。例えば、明瞭化のために示してはいない が、中間パーティが一回限り署名および圧縮ツリーを形成し、これをブラインド 形態で署名者に提供し、非ブラインド形態の結果を裏書人に供給し得ることは当 業者であれば容易に理解され得る。これに関連する技術もまた上記の第２の参考 文献に開示されている。 点線のボックス4302は裏書き機能を示す。１つの構成要素は、メッセージに対 応する一回限り署名を形成するボックス4321である。これは、各ディジットをメ ッセージまたは制御のその部分を符号化するのに必要なカスケード内のポイント に展開することによって行われる。これは一回限り署名技術では周知であり、図 44を参照して後に詳述する。この署名は検証のために裏書人から被裏書人3943に 与えられる。上述のように、署名を検証するために必要な少なくともエッジの転 送はボックス4322に示される。ディジタル署名もまた、ボックス4323に示される ように裏書人から被裏書人に与えられる。 点線のボックス4303は、上述の点線のボックス4302の結果として与えられる緻 密な裏書き署名に対して被裏書人が行う検証機能を表す。先ず、ボックス4331で は一回限り署名か拡張される。これは、例えば、適用される一回限り機能のほと んどのアプリケーションでの形態である。この結果は次に、上述のように、ボッ クス4322で供給されたエッジと共に用いられ、圧縮機能ノードの適用によりルー トまで横移動する。この結果、ボックス4333に示すように、ボックス4321を参照 して述べたディジタル署名をチェックするための値が得られる。圧縮ツリーのエ ッジが提供されるため、署名は「メッセージ回復」を可能にするものとして当該 分野で既知のタイプである必要はない。当然ながら、署名が検証されると被裏書 人はこれを受け入れ、そうでない場合は受け入れない。 点線のボックス4304は準備プロセスを示す。これは各裏書きの間の実質的な計 算を含み得るが、直線戻り通路によって示されるように計算を全く含まないかも しれない。ボックス4341によって示される準備の１つの局面は、ハウスを評価す ることである。これらは、例えば上述のように次のストリートまたはタウンのも のであり得る。ハウスが十分に評価されると、上述のように、結果は圧縮ノード への入力エッジとして働く。ボックス4342はエッジの圧縮および結果のレジスタ 内での節約を示す。これにより関連する入力レジスタまたはハウス出力を格納す る必要がなくなるかもしれない。また、ボックス4343に示すように、不揮発性記 憶領域が新しい値を格納するために利用可能になると、古い値は消去されるかま たは少なくとも新しい値によって上書きされる。 当業者には理解され得るように、これらの様々な準備ステップは、本発明の精 神から外れることなく様々な時に様々な順序で行われ得る。例えば、いくつかの 設定では、準備は、次の裏書きに正に必要なものを作成し得る。場合によっては 、時間があればいつでも多くの将来の裏書きのための準備を行い得る。将来の裏 書 きのためのこのような準備は、明瞭化のためにはっきりと示してはいないが、い くつかの余分のレジスタを用い、数ステップ先に計算される予定の値をレジスタ に格納することによって、準備の必要なくこのようなステップが可能になり得る 。 準備は裏書きの前、裏書きの直後、または裏書き中に、もしくは裏書人が暇な ときに行われ得る。別の可能性は、徹底的に行おうとしないならば、実質的には 署名発行直後、または準備を必要とせず点線の準備ボックス全体を通り抜け得る 場合は別の時に起こり得る。 クレジット／デビットカード取引などの上記のアプリケーションに関連して、 上述の図43に示す動作への新しい拡張について開示する。これは明瞭化のために 示されてはいないが、当業者であれば理解され得る。 オンラインおよびオフライン取引の両方について考慮する。第１のタイプのオ ンライン取引では、少なくとも裏書人にオンラインで発行されるチャレンジおよ び裏書人からオンラインで戻されるレスポンスが存在し得る。このようなチャレ ンジ−レスポンスプロトコルの概念は当該分野では周知である。裏書人は典型的 にはスマートカードであり得る。 第２のタイプのオンラインアプリケーションでは、取引は、裏書きカードを受 け取る端末からオンラインで送られる単一メッセージと、サーバからオンライン で送られ端末によって受け取られる単一の対応するレスポンスとを含み得る。こ の第２のタイプの取引では、裏書きされたメッセージはチャレンジ値を含み、こ のチャレンジ値は、好ましくは、実質的に前のオンライン取引で送られた「修飾 子」によって実質的に少なくとも影響される「チャンレンジ種」から引き出され ることは当業者には理解され得る。種は、例えは、本質的には第１のタイプのア プリケーションでチャレンジとして使用されるのと同じタイプの格納された値で あり得、この場合には、修飾子は単に格納されたチャレンジであり得る。もしく は、これは、送られる種修飾子により異なるが、暗号化法のような様々な方法で 更新される値であり得る。従って、種により、端末が、端末の内部活動へのアク セスを有する者にとっても予測不能であり得る有効なチャレンジを生成すること が可能になる。 いずれのタイプのオンライン取引でも、レスポンスはチャレンジに依存し、本 明細書で述べるように裏書きであり得る。もしくは、当該分野では周知のように 、レスポンスは従来の暗号化認証であり得、十分な裏書きが後の伝送または監査 のために端末に格納され得る。 オフライン取引では、オンライン取引と同様に予測不能なチャレンジ値が好ま しいと考えられる。時折オンラインとなる端末は、このようなオンライン時にそ のチャレンジ種を更新し、少なくともこのチャレンジ種に依存して、そのチャレ ンジ値を列を通して前進させ得る。この結果、少なくともオンライン取引を通し ては予測不能なチャレンジ値の列が得られる。 図44および図45の表記は当業者にとっては明瞭であると考えられるが、明確化 のために先ず検討を行う。いくつかのシンボルが用いられる。すなわち、丸はレ ジスタ値を表す。図44に関連して述べるハウス形状のブロックは一回限り署名を 示す。角が丸い方形は圧縮カスケードを示す。そして菱形のボックスは公開鍵デ ィジタル署名を表すために用いられる。ラインおよび矢印は、出力の入力への流 れを定義するエッジを示す。進路図に入るかまたはこれから出る矢印はそれぞれ 進路図の入力または出力を示す。 図46の表記は数および特殊シンボルの表構成である。これら意味については同 図を参照して後述する。 図44に戻って、一回限り署名構造の１つの好適な実施態様について以下に詳述 する。 ハウス形状のボックス4401は一回限り署名自体を示す。後に述べるように、こ の形状は図45では一回限り署名のアイコンとして用いられる。明瞭化および明確 化のための図示として、特定の寸法パラメータ、４つの入力および３つの内部ス テージが選択されるが、このような選択は、可能な値を限定したりこのような方 形構造の必要性を意味するようには意図されない。実施態様によっては、もっと 小さいパラメータ値およびもっと大きいパラメータ値、例えば、８×８を用い得 る。４つの入力値4471〜4474がある。各入力は一方向機能4411^*〜4414^*によって 方向付けられ、それぞれ中間値4411〜4414を生成する。次のステージでは、これ らの値4411〜4414がそれぞれ一方向機能4421^*〜4424^*への入力として用いられ、 これらの出力はそれぞれ値4421〜4424を定義する。最終ステージの一方向機 能4431^*〜4434^*は値4421〜4424を入力として受け、それぞれ値4431〜4434を生成 する。 最終ステージの一方向機能の出力は、明確化のために２入力圧縮器の階層構造 によって圧縮されるように示されているが、いかなる適切な圧縮構造を用いても よい。値4431および4432は圧縮器4451によって圧縮され、その出力は圧縮器4453 に供給される。値4433および4434は圧縮器4452によって圧縮され、その出力は圧 縮器4453の他方の入力に供給される。圧縮器4453の出力は一回限り署名の最終出 力4481として示される。 ハウスでは２つのタイプの動作が行われる。一方の動作は、入力値4471〜4474 を一方向機能チェーンを通しておよび上述の圧縮階層構造を通して受け取ること によって出力を計算し、出力値4481を生成することである。他方の動作は、上述 のボックス4321で示すように一回限り署名を形成することである。当該分野では 周知のように、署名されるメッセージはディジットセットとして受け取られ、各 ディジットに対応する一方向機能チェーンがそのディジットの値に対応する深さ まで評価される。これらの一方向機能に対応する、ディジット毎に１つの出力値 か一回限り署名である。 次に図45を参照して、緻密な裏書き署名の１つの好適な実施態様について詳細 に述べる。特定の寸法パラメータ、それぞれ４つのハウスよりなる４つのストリ ートが表記の明瞭性および明確性のために選択されているが、このような選択は 、可能なパラメータを限定するかまたはこのような規則的な構造の必要性を意味 するようには意図されない。しかし、ほぼ同じ数のストリートおよびハウスが良 好なトレードオフを提供すると考えられる。もっと大きなパラメータ値、例えば ８つのハウスよりなる８つのストリートもまた環境によっては適切な選択である と考えられる。 ２レベルアプローチが意図される使用にとっては最良であると考えられる。し かし、他の構造も本明細書で開示される本発明の概念から容易に引き出され得る 。明瞭化のためにはっきりと示してはいないが、さらに別の実施態様としては、 計算またはレジスタの要件を実質的に変更することなく、１つの圧縮を上に挿入 することによってカスケードがどのように２つに分割され得るかは当業者には理 解 され得る。これにより、例えば、転送されるエッジ数を実質的に減らすことがで きる。 図45Aの角が丸いボックスa1^**は、図45Eで再び参照される構造の一部を示し、 それぞれ出力値a11〜a14を有する４つのハウスa11^*〜a14^*のストリートと呼ばれ 得る。図44を参照して上述したように、各ハウスは一回限り署名を表す。圧縮器 b11^*は値a11およびa12から入力を受け、出力値b11を生成する。圧縮器b12^*は値b 11および値a13を入力として受け、出力b12を生成する。同様に、圧縮器a1^*は値b 12およびa14を入力として受け、図45Eを参照してさらに述べるように出力値を生 成する。 同様の方法で、図45Bの角が丸いボックスa2^**は、図45Eで再び参照される構造 の一部を示し、それぞれ出力値a21〜a24を有する４つのハウスa21^*〜a24^*のスト リートと呼ばれ得る。図44を参照して上述したように、各ハウスは一回限り署名 を表す。圧縮器b21^*は値a21およびa22から入力を受け、出力値b21を生成する。 圧縮器b22^*は値b21および値a23を入力として受け、出力b22を生成する。同様に 、圧縮器a2^*は値b22およびa24を入力として受け、図45Eを参照してさらに述べる ように出力値を生成する。 さらに同様の方法で、図45Cの角が丸いボックスa3^**は、図45Eで再び参照され る構造の一部を示し、それぞれ出力値a31〜a34を有する４つのハウスa31^*〜a34^* のストリートと呼ばれ得る。図44を参照して上述したように、各ハウスは一回限 り署名を表す。圧縮器b31^*は値a31およびa32から入力を受け、出力値b31を生成 する。圧縮器b32^*は値b31および値a33を入力として受け、出力b32を生成する。 同様に、圧縮器a3^*は値b32およびa34を入力として受け、図45Eを参照してさらに 述べるように出力値を生成する。 最終の同様のストリートに対しては、図45Dの角が丸いボックスa4^**は、図45E で再び参照される構造の一部を示し、それぞれ出力値a41〜a44を有する４つのハ ウスa41^*〜a44^*のストリートと呼ばれ得る。図44を参照して上述したように、各 ハウスは一回限り署名を表す。圧縮器b41^*は値a41およびa42から入力を受け、出 力値b41を生成する。圧縮器b42^*は値b41および値a43を入力として受け、出力b42 を生成する。同様に、圧縮器a4^*は値b42およびa44を入力として受け、図45Eを 参照してさらに述べるように出力値を生成する。 図45Eでは、４つの角が丸いボックスa1^**〜a4^**が、それぞれ対応する出力値a 1〜a4と共に、圧縮ツリーへの入力として示される。第１の圧縮器b1^*は値a1およ びa2から入力を受け、その出力は値b1である。圧縮器b2^*はこの出力b1を受け、 これを値a3と組み合わせて値b2を生成する。同様の方法で、圧縮器b3^*はこの出 力値b2および値a4を出力b3^*に変える。最後に、この出力値b3は公開鍵ディジタ ル署名生成器b4^*へのメッセージ入力として働き、緻密な裏書き署名b4を生成す る。 次に図46を参照して、図45を参照して上述した本発明の構造例の動作について 述べる。 図46に示す表の各行が１つの裏書きに対応する。表の各行には欄外に番号が付 けられている。表の各列は、裏書きの間に値を格納するために用いられる好まし くは不揮発性のレジスタ位置に対応する。キャロットシンボル「＞」は、値が最 後の行から変化しているエントリを示す。ドット「．」は、値がこの行に対応す る裏書きで使用されるハウスの出力であるエントリを示す。 最初の４列は、明瞭化のためにおよび便宜上、常にそれぞれのストリート順序 位置にあるストリートエッジ値を格納するために用いられる。ドットの印の付い たエントリから４番目までであってこれを含む行部分のみが、現在のストリート からのハウスに基づく現在および以後の裏書きのために必要である。ただし、現 在のストリートの前の裏書きからの１つの出力を除く。従って、ドットの印の付 いたエントリより前のエントリは主として利用可能であり、時には中間値を保持 するために用いられ、最終的には次のストリートに入るときに持つ必要がある値 と共に準備される。 各行の最後の４つのエントリは、現在の裏書きのために必要なタウンエッジ値 を保持するために用いられる。これらの値もまた、順番位置に常に格納される。 ストリートを横移動するとき、現在および以前に横移動したストリートに対応す る初期のタウンエッジ値はもはや格納する必要はない。これらが占領したエント リは、次のタウンに入るときに必要とされるタウンエッジ値を生成し最終的に保 持するための一時的なセルとして使用され得る。 表示の明瞭化のために、最初の行で示されるタウンは、図45の表記に直接対応 するその参照番号に小文字を含む。後の行で現れるように示されている第２のタ ウンは参照番号に大文字を含む。 行１は、第１の裏書きのための完全な値セットを示すことによって始まる。a1 1にはドットが付いているため、第１のストリートの第１のハウスが一回限り署 名に使用される。明らかなように、第１のストリートが使用されるため第１のス トリートのためのエッジ値a1は必要ない。ハイフンシンボル「−」はこのエント リに有意な値がないことを示す。 行２は、この裏書きのためにはレジスタ値の変更は必要ないことを示す。裏書 きで用いられる一回限り署名に対応する第２列以外のすべての列エントリは、は っきりと裏書人によって被裏書人に伝送される。 第３の裏書である行３は、キャロットによって示されるように２つの変更され たレジスタ値を伴う。最初の値はb11であり、これはa11およびa12の圧縮として 計算される。このような圧縮は、後にも起こるが、図43を参照して上述した「エ ッジを進める」機能／ステップ4342の例としてとられ得る。第２の値a22は次の ストリートのための予備であり、図45Bにも示すように、次のストリートの第２ のハウスから計算される。 行４は第１のストリートのための最後の裏書きである。これは、b12を得るた めにb11およびa13の圧縮を必要とする。また、値a23はハウスa23^*から計算され る。 行５は第２のストリートの最初の裏書きである。エッジ値a21が計算されるよ うに示されている。ハウスa21により裏書きが行われるため、このエッジの値を 完成するために必要な計算は少なくて済む。このように特に効率が良いのは、最 後に埋めるために最初のエントリを残しておくためである。最初のストリートの エッジ値a1がこの時点で必要とされ、b12およびa14の圧縮として容易に計算され る。レジスタ値a24は対応するハウスから計算される。裏書きはこのときは第２ のストリートに移動しており、a2はもはや必要ない。 行６では、２つのハウスA21およびA22の評価を示すが、これらを不揮発性格納 は行わない。そして得られる２つのエッジ値を圧縮して、格納されているとして 示されているB21を形成する。 行７は、a21およびa22の圧縮としてb21を形成し、結果を第１のハウス列に格 納する。第２のハウス列は第３のストリートの第２のハウスから計算されるエッ ジ値を得る。値B22は第２のタウンのための準備として計算される。先ず、第２ のタウンの第２のストリートの第３のハウスの値が計算され、これは次に上記の 行６で言及した新しいタウンの第２のストリートの第１のエッジ値と共に使用さ れ、圧縮によって値B22を形成する。 行８は、b21をa23と共に圧縮することによって第１列をb21からb22にすること によって始まる。次に、a33がそのハウスから計算される。最後にエッジA2の値 が、先ずそのハウスからのA24を計算し次にこれをB22と共に圧縮することによっ て生成される。 行９は、第１のレジスタを、第３のストリートの第１のハウスから形成される エッジで満たす。第４列は第３のストリートの第４のハウスから計算される値を 得る。最初の２つのストリートb1をスキップするために必要なエッジb1は、先ず b22およびa24を圧縮してa2を得、次にこれをa1と共に圧縮することにより形成さ れる。裏書きは現在は第４のストリートにあるため、a3はもはや必要ない。 行10は、次のタウンのための値B31のみを構築することを包含する。これは、 各ハウスからそれぞれ計算されるA31およびA32の圧縮である。 行11は、先ず、a31をa32と共に圧縮することによって第１列をa31からb31に進 ませる。次に、a42がそのハウスから計算され、第２列値に置き換わる。次のタ ウンのための準備として、B31をそのハウスから計算される値A33と共に圧縮する ことによってB32に向かって移動させる。 行12は、既に格納されているa33と共に圧縮することによって第１列でb31をb3 2に置き換えることによって始まる。また、a43がそのハウスから計算され格納さ れる。さらに、A3が格納されたB32およびそのハウスから計算されたA34から圧縮 して得られる。 行13は、最初は、第１列をハウスa41の値に設定する。また、ハウスの値a44が 代わりに置かれる。b1をb2に移動させるために、最初にa3が、共に格納されてい るb32およびa34から圧縮により得られ、次にこの結果がb1と共に圧縮される。現 在では裏書きは第４のストリートにあるため、a4は解放される。 行14は、それぞれのハウスから直接計算される２つの値A41およびA42からB41 を計算することのみを伴う。 行15は、a41を格納されているa42と共に圧縮することによって、a41をb41に更 新することによって始まる。第２列には直接計算された値A12が与えられる。B41 をB42に進めるために、値A43がそのハウスから直接計算され、次にB41と共に圧 縮される。 行16もまた、値b41を格納されているa43と共に圧縮することによって、第１列 を更新して、b42を生成する。ハウスから直接計算することによって、A13が得ら れる。B42をA4に圧縮するために、A44の値がそのハウスから直接計算される。 行17は、第２のタウンからの最初の裏書きである。値A11が裏書きを通して計 算され、第１列に格納される。また、A14がそのハウス値から計算される。 行18はレジスタの変更を必要としない。第２のタウンのためのものであること を除いては行２と同じである。従って、第１のタウンと第２のタウンとの間のプ ロセスは、第２のタウンと第３のタウンとの間で再び繰り返され得る。 概観 図１に第２の好適な実施態様の概観を示す。単一の発行者101、カード102、端 末103および取得者104が示されているが、システムは、明瞭化のために示しては いないが、複数の発行者、カード、端末および取得者を含み得る。 システムには４つのエンティティ、すなわち、発行者101、カード102、端末10 3および取得者104が存在する。発行者は、カードを発行し他の参加者に対してカ ードの正しい動作を保証する組織または組織の集合体である。他の参加者として は、例えば銀行があるがこれに限定されない。カードは、発行者が信頼する不正 改変不可能なコンピュータ装置である。これは例えばスマートカードであるがこ れに限定されない。端末はカードと通信し得る計算装置である。取得者104は端 末からデータを回収するのを助ける組織である。取得者は、発行者とは異なるエ ンティティである場合は、典型的には、発行者と密接に協力して働く。 カードが最初に作成されるときは、典型的には、発行者によってまたは発行者 に代わって初期化される。これは個人化と呼ばれ、データチャネル110、111を用 いて行われる。個人化は、例えば、暗号化鍵およびシステム構成パラメータセッ トをカードに与えることを包含するが、これに限定されない。個人化が行われる と、カードは取引を行うために用いられ得る。 取引を行う前に、カードと端末との間にデータチャネル112、113が確立される 。実行され得る取引には様々なものがある。これらの多くは、カードまたは端末 が取引中に発行者か取得者のいずれかと通信することを必要としない。このよう な取引を「オフライン」と呼ぶ。取引によっては、端末が取引中に発行者と通信 することを必要とするものがある。このような種類の取引は「オンライン」と呼 ばれる。これらの取引に対しては、端末と発行者との間の通信チャネル118、119 が使用される。取引の例としては、端末によるデータ読出し、端末によるデータ 書込み、カードから端末への支払い、カードにさらに電子マネーをリロードする ことなどを含むが、これらには限定されない。 取得者104は、１つ以上の端末から情報を回収し、場合によっては取引の清算 および解決の一部またはすべてを扱うエンティティである。この目的のために、 取得者は通信チャネル114、115を介して端末と、および通信チャネル116、117を 介して発行者と通信する。取得者の機能の例としては、端末が関与した取引につ いての情報を収集すること、端末から支払いの暗号化プルーフを収集すること、 端末のシステムパラメータを更新すること、金融取引に関する情報を発行者に渡 すこと、発行者からこれらの取引のためのお金を集めること、受け取ったお金を 各端末の所有者に配布することを含むが、これらには限定されない。 緻密な裏書き署名 緻密な裏書き署名は、「ハウス」と呼ばれる使い捨て暗号化要素を使用する。 各ハウスは、メッセージの署名または認証のために一度だけ使用される。効率化 のためにこのようなハウスのいくつかが組み合わされて「タウン」を形成する。 ハウス この好適な実施態様の「ハウス」の基本的な構成を図２に示す。ハウスは、ハ ウス起源値201と呼ばれる開始値、拡張機能セット202、反復一方向機能セット20 3、反復暗号化ハッシュ機能204、およびハウス結果値230よりなる。 ハウスは、複数の列を含む。図２にはこれらのうちの２つが明確に示されてい る。第１列は項目210、211、212、213、214、215、216よりなり、第２列は項目2 20、221、222、223、224、225、226よりなる。残りの列は208によって表され明 瞭化のために詳細は示していない。 第１列について述べると、これは、ハウス起源値201を入力として受け、列の 第１の値211を出力として生成する暗号化一方向機能210により開始される。これ は次に一方向機能チェーンへの入力として使用される。各チェーンは１つ以上の 一方向機能を含む。図２にはチェーンの２つの一方向機能のみが示され、列の残 りのステップは明瞭化のために示されず209によって表される。第１の一方向機 能212は第１の列値211を入力として受け、第２の列値213を生成し、この値は次 の一方向機能への入力となる、などと続く。チェーン214の最後の一方向機能が 最後の列値215を生成する。 反復暗号化ハッシュ機能204は、公開された開始値205および各列に１つの圧縮 機能の配列からなる。開始値205は、第１列の圧縮機能216への入力の一方である 。この圧縮機能は最終列値215を他方の入力として受け、第１中間ハッシュ値を 生成する。引き続く列のそれぞれが、前の中間ハッシュ値を一方の入力としその 列の最終列値を他方の入力として受け、次の中間ハッシュ値を生成する、216に 類似した圧縮機能により終了する。 それぞれ、210、211、212、213、209、214、215、216に対応する項目である22 0、221、222、223、209、224、225、226よりなる最終列が、第１列と同様の方法 で構築される。最終列の圧縮機能226は、最後から１つ前の中間ハッシュ値を一 方の入力とし最終行の最終列値225を他方の入力として受け、最終ハッシュ値230 を生成する。この最終ハッシュ値はハウス結果値と呼ばれる。 図９にハウスの例を示す。ハウス起源値901が値201に対応する。拡張機能セッ ト902は、暗号化一方向機能910、920、930、940、950、960、970よりなり、これ らのすべてがハウス起源値901を入力として使用し、それぞれ列903（203に対応 ）の第１値911、921、931、941、951、961、971を生成する。これらの値は、そ れぞれチェーンの第１の一方向機能912、922、932、942、952、962、972への入 力として使用され、これらはそれぞれ第２列値913、923、933、943、953、963、 973を生成する。これらは次に各チェーンの第２の一方向機能914、924、934、94 4、954、964、974のための入力値であり、これらはそれぞれ第３列値915、925、 935、945、955、965、975を生成する。これらは次に、各列チェーンの第３の一 方向機能916、926、936、946、956、966、976のための入力値として使用され、 これらはそれぞれ最終列値917、927、937、947、957、967、977を生成する。こ れらの最終列値が暗号化ハッシュ機能904（204に対応）への入力を形成する。暗 号化ハッシュ機能は、第１の圧縮機能918への入力である公開された開始値905と 共に開始される。第１の圧縮機能は値917もまた入力として受け結果として第１ 中間ハッシュ値919を生成する。第１中間ハッシュ値919および第２列の最終列値 927が、第２の圧縮機能928に入力され、第２中間ハッシュ値929を生成する。こ のチェーンは、それぞれ項目938、939、948、949、958、959、968、969、978、9 79により同じ方法で連続する。最終値979が、項目230に対応するハウス結果値で ある。 各列（910、920、930、940、950、960、970など）を開始する暗号化一方向機 能のすべてが異なり、これにより、これらの入力値が同じ場合でも異なる結果値 を生成する。後にさらに詳しく述べるように、いくつかのハウスは同じハウス起 源値を使用し得る。同じハウス起源値を使用するハウスセット内では、典型的に は、列を開始する暗号化一方向機能はすべて異なっている。さらに、これらの一 方向機能は、これらの一方向機能の出力値のすべてを与えられてもハウス起源値 を再構築することは非実用的であると考えられるようにされる。このような機能 は他のシステム、とりわけ、当該分野では周知の暗号化度の高い疑似乱数生成器 て使用される。 この好適な実施態様では、１つのハウス内では列チェーン内の一方向機能（例 えば、912、914、916、922などから976まで）はすべて異なる。さらに、同じハ ウス起源値を使用するハウスセット内では、列チェーン内の一方向機能はすべて 異なる。同じハウス起源値を使用するハウスセット内では、918、928、938など のような圧縮機能のそれぞれが異なる。当業者には明らかなように、これらの機 能を異なるようにするには多くの方法がある。例えば、機能アプリケーション毎 に増分されるカウンタに依存して異なるようにする方法か、もしくはハウスまた はハウスセット内のまさにその位置を異なる機能を区別するために用いる方法な どが含まれるが、これらに限定されない。異なる位置に異なる機能を用いること によりシステムのセキュリティが向上すると考えられる。 列の高さは列値の数であり、これはチェーン内の一方向機能の数より１つだけ 多い。 ハウス結果値230はハウス起源値201に依存する。多くの中間結果を含む場合で も、列数または各列の高さに関係なく、結果値230は、メモリの固定量のみを使 用してハウス起源値から計算され得る。これは、列のそれぞれを通して順番に計 算し、次の列を開始する前に各列の最終値に圧縮機能を行うことにより実現され る。この計算の詳細は当業者には明らかである。 タウン 後述するように、ハウス出力値は、ディジタル署名スキームを用いて署名され 、カードはその署名を格納する。格納要件を減らすためには、図３に示すように いくつかのハウスを組み合わせてタウンが形成される。 タウンは複数のハウスよりなる。図３では３つのハウスが321、322、323とし て示され、残りのハウスは明瞭化のために示されず302によって表される。タウ ンの構成ハウスのそれぞれは、ハウス起源値（図２の201に対応）を有する。311 、312、313がそれぞれ321、322、323のハウス起源値である。各ハウスはまた、 図２の230に対応するハウス結果値を有する。331、332、333がそれぞれ321、322 、323のハウス結果値である。ハウス結果値のすべては暗号化ハッシュ機能340へ の入力として使用され、これがタウン結果値341を生成する。 この好適な実施態様では、タウン内のすべてのハウスは同じ構造を有する。こ れらは同じ列数、同じ列高さなどを有する。これにより実現が最も容易になると 考えられる。 この好適な実施態様のタウンの構成について図４を参照して再帰的に述べる。 単集合タウン403は単一の構成ハウス461を有する。タウン起源値460はハウス461 のハウス起源値（図２の201に対応）として使用される。ハウス結果値（図２の2 30に対応）はタウン結果値462である。 一般的なタウン401は複数の構成タウンを有する。図ではこれらのうちの３つ が421、422、423として示され、残りは明瞭化のために示されず402によって表さ れる。構成タウンのそれぞれは一般的なタウンかまたは単集合タウンのいずれか である。タウン起源値411は、構成タウンのそれぞれのためのタウン起源値とし て使用される。一連の圧縮機能を用いて構成タウンのタウン結果値が組み合わさ れ、一般的なタウンのタウン結果値453が生成される。 第１構成タウンのタウン結果値431が圧縮機能442への第１入力であり、これは 第２タウンのタウン結果値432を第２入力として受け、第１中間値452を生成する 。この中間値は次に、次の圧縮機能への第１入力として使用され、この圧縮機能 は次の構成タウンの結果値を第２入力として受け、次の中間値を生成する。この チェーンは、圧縮機能443が前の中間値を第１入力として、最終構成タウンのタ ウン結果値433を第２入力として受け、一般的なタウンのタウン結果値453を生成 する最終構成タウンまで続く。 442および443などの圧縮機能は、圧縮機能チェーンの結果が暗号化ハッシュ小 能であるように選択される。このような反復ハッシュ機能は当該分野では周知で ある。 この好適な実施態様では、構成タウンのそれぞれで使用される再帰深さは常に 同じであり、一般的なタウンの構成タウンの数は再帰深さにのみに依存する。こ れにより最も実用的な具現体が得られると考えられる。各再帰レベルは次元と呼 ばれ、再帰レベルｎを有するタウンはｎ次元タウンと呼ばれる。例えば、構成タ ウンがすべて単集合タウンである一般的なタウンは一次元タウンである。構成タ ウンがすべて一次元タウンである一般的なタウンは二次元タウンである。これは また、タウン構成の特徴付けを容易にする。例えば、7×4×5のタウンは、それ ぞれが単一のハウスよりなる５つの構成単集合タウンをそれぞれが含む４つの構 成一次元タウンをそれぞれが含む７つの構成二次元タウンを含む三次元タウンで ある。従って、このタウンのハウスの全数は7×4×5＝140である。各復帰レベル での一般的なタウンの構成タウンの数がその次元のサイズと呼ばれる。単集合タ ウンは多くの場合無視されるため、一次元タウンは複数の構成ハウスを含むとい ってよい。この好適な実施態様では、各次元のサイズはすべて同じであるか、ま たは多くて１つだけ異なる。これにより最も効率的な具現体が得られると考えら れる。 １つの好適な3×4タウンの例を図５に示す。二次元の一般的なタウン501は、 それぞれが４つの構成ハウスを含む３つの構成一次元タウン502、503、504を含 む。タウン起源値505は、タウンのハウス560、561、562、563、530、531、532、 533、510、511、512、513のそれぞれのハウス起源値として使用される。これら のハウスはそれぞれハウス出力値564、565、566、567、534、535、536、537、51 4、415、516、517を生成する。第１の一次元タウン504のハウス結果値は、圧縮 機能568、570、572のチェーンによって組み合わされる。この圧縮機能チェーン は中間値569および571ならびにタウン504のタウン結果値573を生成する。他の一 次元タウンのハウス結果値も、538、540、542、539、541、518、520、522、519 、521によって示されるように同様の方法で組み合わされ、この結果それぞれタ ウン503、502のタウン結果値543、523が得られる。一次元タウン504、503、502 のタウン結果値573、543、523は、機能581、583および中間値582によって同様の 方法で組み合わされ、この結果タウン501のタウン結果値584が得られる。 タウン作成 タウンを含むプロセスについて述べるために、図５に示す例を用いる。これら のプロセスかどのように拡張および一般化され一般的なタウンが作成されるかは 当業者には明らかである。 タウン起源値505を選択してこれからタウン結果値584を計算することによって タウンが作成される。タウン結果値は、起源値を含む、コストは掛かるが分かり やすい計算を用いて計算される。限定されない１つの例として、タウン結果値58 4を計算する優雅な方法を図41に示す。ハウスは第１列に示される順序で計算さ れる。第２列は、第１列のハウスが計算された後メモリ内に存在する値を示す。 最終列は、両方ともメモリ内に存在する値を入力値として圧縮機能を行った後メ モリ内に存在する値を示す。圧縮機能を行った後、次の行の第１列に示されるよ うに次のハウスが計算される。一般的なタウンへの一般化は最も優れた再帰的な 記述である。403のような単集合タウンは、基本的には１つのハウスの計算を含 むだけであるため、固定メモリ量で計算され得ると考えられる。一般的なタウン 401を計算するためには、先ず再帰的にタウン421を計算し、値431を格納し、再 帰的にタウン422を計算して結果値432を得、圧縮機能442を用いて値432と431を 組み合わせて値452を得、次のタウンを再帰的に計算するなどと続く。圧縮機能 のアプリケーションを構成タウンの計算とインターリーブすることによって、各 復帰レベルは構成タウン数とは関係なく固定記憶量を使用し、これにより、タウ ン全体を計算するために必要な記憶領域はタウンの次元数に比例するだけとなる 。 タウン結果値584が計算されると、発行者は公開鍵ディジタル署名スキームを 用いてこの結果値に署名を行う。これを実現するにはいくつかの方法がある。発 行者がタウンを作成している場合は、タウン結果値でディジタル署名を計算する だけでよい。これを図10に示す。署名プロセス1002は２つの入力、すなわち署名 されるメッセージ1001およびディジタル署名を生成するために使用される秘密鍵 1004を受ける。署名プロセス1003の出力値をディジタル署名と呼ぶ。タウン結果 値584をメッセージ入力値1001として使用することにより、発行者はタウン結果 値でディジタル署名を計算することができる。これをタウン署名と呼ぶ。タウン 起源値505およびタウン署名は次にカード102に送られ、ここで不揮発性メモリに 格納される。タウン署名として署名されるメッセージには他のデータも含まれ得 ると予想される。 タウンを作成するには他のいくつかの方法もある。例えば、限定はされないが 、カードは乱数のタウン起源値505を選択し、対応するタウン結果値584を計算し 、そしてタウン結果値を、受け取るタウン結果値が有効なカードによって計算さ れたものであると発行者に確信させる暗号化認証と共に発行者に送ってもよい。 次に発行者は、タウン結果値に署名してタウン署名とし、このタウン署名をカー ドに送り返す。カードはタウン起源値505およびタウン署名を不揮発性メモリに 格納する。ブラインド署名スキームもまた使用され得る。この方法では、カード はタウン結果値584を発行者に送る前にこれをブラインド化する。ブラインドデ ィジタル署名スキームを用いると、発行者はタウン結果値の実際の値を知ること なくタウン結果値に署名をおこなうことができる。 これらの作成技術のいくつかまたはすべてを用いると、カードは、それぞれが タウン起源値505とタウン署名とからなる１つ以上のタウンを得ることができる 。カードにもっと多くのタウンを再ロードすることは、典型的には、端末がカー ドに行うことができる取り引きの１つであり得る。 ハウスの消費 ハウスを使用するプロセスを消費と呼ぶ。このプロセスでは、カードはハウス を用いてメッセージに署名または認証を行う。例えば、限定はされないが、カー ドはハウスを用いて、一定の金額を表す端末へのメッセージを作成し、端末は秘 密暗号化鍵にアクセスせずにこれの有効性を検証することができる。 基本的な消費プロセスを図30に示す。このプロセスは、コミット−チャレンジ −レスポンスプロトコルとして知られる幅広いクラスの暗号化プロトコルの１つ の例である。これらは当該分野では周知であり、様々なゼロ知識プロトコル、自 己証明プロトコル、署名スキームなどで使用されている。このようなプロトコル の例としては、Guillou-Quisquaterプロトコル、Feige-Fiat-Shamirプロトコル などがある。コミット−チャレンジ−レスポンスプロトコルは、一方のパーティ （証明者）がコミットメッセージを他方のパーティ（検証者）に送ることにより 始まる。次に検証者は証明者に返送するチャレンジを選択する。最後に証明者が 検証者にレスポンスを送る。証明者は、典型的には、コミット値、チャレンジ値 、および他の（秘密）データを用いてレスポンスを計算する。検証者は、典型的 には、コミット値およびチャレンジ値に基づいてレスポンスが正しいことを検証 し得る。これは、典型的には、前もってチャレンジ値を推測することができれば 、偽の証明者でも正しいコミットおよびレスポンスメッセージを提供することが できるケースである。従って、異なる可能なチャレンジ値の数はこの種のプロト コルの重要な局面である。異なるチャレンジ値の数が少なければ、プロトコルプ ロセスを一回実行しただけでは検証者はそれほど納得せず、検証者を十分に納得 させるためには実行を繰り返さなければならない。これは多くのゼロ知識プロト コルで用いられる。異なるチャレンジ値の数が多い場合は、チャレンジを、署名 されるメッセージおよび証明者により送られるコミット値の暗号化ハッシュとし て選択されるものとして定義することによって、プロトコルは署名スキームに変 換され得る。これにより対話の必要がなくなり、証明者が単一のメッセージ内の データのすべてを検証者に送ることが可能になる。この変換も当該分野では周知 であり、例えば、Fiat-Shamir署名スキームで用いられる。いくつかのスキーム では、可能なチャレンジ値の数が増えると計算労働量が増大するため、チャレン ジ 値の数は最小限に保つのが望ましい。次に消費プロセスについて述べる。このプ ロセスは、カードが証明者、端末が検証者であるコミット−チャレンジ−レスポ ンスプロトコルの特定の実施態様である。 図30のプロセスは、カードがコミット値をメッセージ3001で端末に送るステッ プ3000で開始される。コミット値の目的は、カードが消費で使用する予定のハウ スを固定することである。例えば、限定はされないが、コミット値はタウン署名 、タウン結果値、およびタウン内のハウスの自己証明よりなり得る。メッセージ 3001が端末によって受け取られと、端末はプロセスステップ3002の実行を開始す る。端末はコミット値を格納し、乱数チャレンジｃを選択する。ステップ3002の 最後の行為として、端末はチャレンジｃをメッセージ3003でカードに送る。端末 は様々な手段を用いて乱数チャレンジｃを生成し得る。例えば、限定はされない が、これは実乱数生成器、擬似乱数生成器などを含み得る。また、選択されるチ ャレンジを取得者または発行者が端末に送る情報に依存させ、これにより端末か らいくらかの自由度を奪うこともできる。これは攻撃者による攻撃を難しくする と考えられる。メッセージ3003がカードによって受け取られると、カードはプロ セスステップ3004の実行を開始する。このステップでは、カードは関連するレス ポンスを計算し、レスポンスをメッセージ3005で端末に送る。メッセージ3005が 端末によって受け取られると、端末はプロセスステップ3006の実行を開始する。 このステップでは、端末は、レスポンスがコミット値およびチャレンジと整合す ることを検証する。 コミット値は、このプロセスでカードによって使用される予定のハウスを固有 に識別および認証しなければならない。これは、典型的には、タウンおよびタウ ン内のハウスを識別することを含む。タウンはタウン署名により認証される。ハ ウスを適切に認証するためには、タウン内のいくつかの中間値もまた、コミット メッセージかまたはレスポンスメッセージのいずれかで端末に送らなければなら ない。例えば、図５でハウス532が使用される場合は、値536、539、537、573、5 23も端末に送らなければならない（値536は他のレスポンスデータから計算され 得るため厳密には必要ないが、好適な具現体では、この方が容易であると考えら れるため送られる）。これらの値を使用して、端末は、ハウス結果値536を有す るハウスが実際にタウン501の構成ハウスであることを検証することができる。 端末は様々な圧縮機能を適用してタウン結果値584を計算し、次に署名検証プロ セスを用いてタウン署名を検証する。署名検証プロセスを図７に示す。検証機能 712は３つの入力、署名711、メッセージ710および公開鍵714を受け、単一ビット 結果値713を生成する。結果値は、ディジタル署名が実際に公開鍵714に対してメ ッセージ710の署名であるかどうかを示す。 ハウスは認証されると使用が可能になる。１つの例として図９のハウスを用い る。カードが送るレスポンスデータは、各列に唯１つの値を含む。第１列では、 これは値911、913、915または917のうちの１つである。他のすべての列でも、４ つの列値のうちの１つがレスポンス値に含まれる。端末はこれらの列値を受け取 り、必要な一方向機能を適用して、各列の最終列値917、927、937、947、957、9 67、977を計算する。次にこれらの値に圧縮機能904が適用され、ハウス結果値97 9を生成する。端末は、この値がタウンのハウスを認証するために以前に使用さ れたハウス結果値に整合することを検証するか、またはハウス結果値を用いてタ ウンのハウスを認証する。各列でどの値を送るかを選択することでチャレンジｃ が符号化される。参照を簡単にするために各列値は関連するディジット値を有す る。最終列値のディジット値は０、最終列値の１つ前の列値のディジット値は１ などとされる。図９では、第１列値はディジット値３を有し、この実際の好適な 実施態様では列高さは８であるため、ディジット値０、１、２、３、４、５、６ 、７が使用される。列高さに２の累乗を使用することによって、実際のデータを 列ディジット値に符号化／復号化することが容易になる。従って、チャレンジｃ はディジット列に変換され、これは、レスポンスデータに含まれる列値を示す。 このようにして、カードはハウスを使用して、端末と共にコミット−チャレンジ −レスポンスプロトコルを行うことができる。このプロトコル自体により端末は 、最初に発行者によって署名された有効なタウンをカードが持っており、このよ うな有効なタウンは発行者のみによって本物のカードに与えられるいるという意 味でカードが本物であるという事実を確信すると考えられる。 図６は、ｃおよび後に詳述する拡張値を符号化するために使用される多くのデ ィジット値（ディジット）を示す。600、602、604、606、608、610、612などの 各四角部分は単一のディジットを表し、603、607および611は追加のディジット 数を表す。境界601、605および609はディジットを後に詳述する異なるフィール ドに分離する。ディジット列（部分列）は、通常は、当該分野では周知の整数を 適切な基数のディジットに符号化する標準的な符号化を用いて、整数を符号化す る。列の高さが異なる場合は、最大ディジット値はそのディジット位置にわたっ て変動する。この場合では、同様に当該分野では周知の整数の混合基数符号化が 用いられる。 端末に与えられる列値のそれぞれに対して、端末は当然ながらこれに続く列値 を計算することができる。これは対応するディジット値を下げることに対応する 。このため、予防措置が取られない限り、端末がディジットを改変することが可 能になる。これを防ぐために制御値が使用される。列（従ってディジット）下位 セットが保護された列（ディジット）として指定される。制御値は、これは整数 であると考えられるが、ある定数から保護された列のすべてのディジット値の合 計を引いたものを符号化する。制御値自体もまたいくつかの列に符号化される。 例えば、限定されないが、制御値はディジット610、611、612に符号化され得、 保護されたディジットは600、602、603、604、606、607および608により構成さ れ得る。端末は単にもっと多くの一方向機能を列チェーンに加えることにより、 １つのディジットの値を単に下げることができる。端末が保護されたディジット のいずれかの値を下げようと試みる場合、制御値が増大する。これは、制御値の 符号化ディジットの少なくとも１つが増大することを意味する。このためには、 端末が、増大する制御ディジットの列の一方向機能の１つを反転させる必要があ り、実用的ではないと考えられる。この好適な実施態様では、制御値の領域は０ 〜63に固定され、９個の保護された列が可能である。（すべての列は高さ８を有 し、従って保護されたディジットのそれぞれは最大７の値を有し、従って９個の 列により最大合計63となる。63を減算のための定数として用いることにより、ち ょうど領域０〜63が制御値に与えられ、これは基数８の２つのディジットで符号 化され得る。）最大制御ディジットが、適切な一方向機能を反転させることによ って増大させようと試みる場合の最も魅力的なディジットであると考えられる。 なぜなら、このディジットを増大させることにより、保護された列の変更に多く の柔 軟性が与えられるからである。従って、制御値の最大ディジットは、合計３つの 制御列に対して２つの異なる列に複製される。最大ディジットの二重符号化によ り、制御ディジットの１つを増大させる目的で一方向機能を反転させようと試み る攻撃に対する追加のセキュリティが提供される。さらに、制御列の数は保護さ れた列の数と共に対数関数的に多くなると考えられる。 消費プロトコルは、カードと端末との間のコミット−チャレンジ−レスポンス プロトコルを実現し、このプロトコルでは、異なるチャレンジ値の数はハウス内 の列数および各列の高さに依存する。チャレンジ値は保護された列で符号化され 、上述のように制御列が加えられる。これは署名メッセージで使用することがで きる。多くてもチャレンジ値と同じ数のメッセージしか持たない短いメッセージ にとっては、チャレンジ値の代わりにメッセージ自体を使用することができる。 しかし、ほとんどのアプリケーションは、とりわけリプレイ攻撃を防ぐために、 本明細書では実用的であると考えられるものより大きなメッセージに署名するこ とを必要とする。コミット−チャレンジ−レスポンスプロトコルを使用するこの 方法は当該分野では周知である。 もっと一般的なスキームは、チャレンジをコミットメッセージおよび署名され るメッセージのハッシュであるように選択することによって、コミット−チャレ ンジ−レスポンスプロトコルを直接署名プロトコルに変換することである。これ には約128ビット以上のチャレンジ値が必要であり、これは、43個の高さが８の 保護された列および３個の制御列、合計46列を用いて実現され得る。コミット− チャレンジ−レスポンスプロトコルを用いるこの方法は当該分野では周知である 。チャレンジを計算するために用いられるハッシュにコミットメッセージを入れ ることは、これらのハウスに基づいたシステムでは必要ないと考えられる。 コミット−チャレンジ−レスポンスプロトコルはまた、認証されるメッセージ の有効コンテンツが小さい場合にメッセージを認証するために使用され得る。有 効コンテンツとは、プレイバック攻撃などを防ぐために使用されるデータ以外の メッセージ内のデータを意味する。例えば、限定はされないが、支払システムで は、署名されるメッセージの唯一の重要な部分は支払金額である。チャレンジは ２つの部分で選択され得る。第１の部分は認証されるメッセージであり、第２の 部分は、証明者には予測不能な方法で検証者によって選択される値である。この 方法はメッセージの十分な認証を提供し、同時に検証者をプレイバック攻撃から 保護すると考えられる。コミット−チャレンジ−レスポンスプロトコルのこの使 用は、短いメッセージの署名と呼ばれ得る。典型的なアプリケーションの例とし ては支払い（すなわち、カードから端末への支払い）のケースがある。チャレン ジｃは、図６に分離子601、605および609によって示されるように、４つのディ ジット列に分割される。第１ディジット600は支払いの通貨を符号化する。ディ ジット602、603および604は支払金額を符号化する。ディジット606、607、608は 端末によって乱数が選択され、最後にディジット610、611および612は制御値を 符号化する。保護されたディジットは600、606、607および608である。典型的な 構成は、１個の通貨列、５個の金額列、７個の乱数列、および３個の制御列を有 し、これは、８個の通貨、15ビットの支払い金額の清算、および21の乱数ビット を収容する。通常のディジタル署名を用いる場合は、21の乱数ビットでは端末を プレイバック攻撃から守るのに十分ではない。しかし、コミット−チャレンジ− レスポンスプロトコルでは、および特にこの特定のコミット−チャレンジ−レス ポンスプロトコルの例では、カードは最初のメッセージで使用される予定のハウ スにコミットしなければならず、チャレンジの乱数部分の値に基づいてこれを変 更することはできないため、このような攻撃から保護される。金額ディジットは 保護されるディジットには含まれないため、端末は金額ディジットのいずれでも 任意に減らすことができる。これは単に署名で符号化された金額を減らすだけで あり、端末の利益にはならないと考えられる。 別の方法では、コミット−チャレンジ−レスポンスプロトコルを、長いメッセ ージを任意に認証するために用いられる可能チャレンジ値の小セットと共に使用 することが可能である。これは、チャレンジ値を、メッセージの暗号化ハッシュ という固有に配分された機能として選択することによって行われる。この機能で は、メッセージは相互にランダムな方法（フェア・コイン・フリップとしても知 られる）で生成される数により拡張される。このような相互にランダムな数（相 互乱数）とは、２つのパーティ間の協働プロセスで、数が実際に乱数であると両 パーティが確認するような方法で構築される数である。図30のプロセスの開始時 には、カードおよび端末の両方が署名されるメッセージｍについて知っている。 プロセスステップ3000では、カードは乱数ａを生成し、これでコミット値Ａを計 算する。例えば、限定はされないが、Ａはａおよび十分に大きいランダムビット 列をハッシュすることによって形成され得る。メッセージ3001では、カードはＡ をコミットメッセージの残りと共に端末に送る。Ａの目的は、カードが、ａを端 末に暴露せずにａの選択を固定したことを端末に示すことである。このようなビ ット関与スキームは当該分野では周知である。端末は次にプロセスステップ3002 で乱数ｂを選択し、メッセージ3003でｂをカードに送る。ステップ3004では、カ ードは相互乱数ｄをａおよびｂの関数として計算する。例えば、限定はされない が、ｄはａおよびｂの排他的ORとして計算され得る。次に実際のチャレンジ値ｃ が、先ずｄと連結されたメッセージｍの暗号化ハッシュを計算し、次にハッシュ 値を均一に可能チャレンジ値セットにマップする機能を適用することによって計 算される。例えば、限定はされないが、チャレンジ値ｃは実際のハッシュ値の最 小ビットとして選択され得る。次に値ｃはハウスの保護されたディジットに符号 化され、制御ディジットが追加され、カードはこれらのディジットに関連したレ スポンスデータをメッセージ3005で端末に送る。カードはまた、値ａとメッセー ジ3005のコミット値Ａを検証するのに必要な情報とを含む。これにより、端末が ｄを従ってｃを再構築することが可能になり、また値ａおよびＡが互いに一貫し ていることをチェックすることによって、ａが実際にカードによって関与される メッセージ3001内の値であることを端末が検証することが可能になる。コミット −チャレンジ−レスポンスプロトコルのこの使用は、任意に長いメッセージの認 証と呼ばれ得る。メッセージｍはプロセスの開始時に両パーティによって知られ る必要はないが、端末へのメッセージ3001に含まれ得る。メッセージの一部はま たステップ3002で端末によって選択され、ステップ3004でカードに伝達されると 考えられる。この場合には、カードは、メッセージのその一部を受け入れるかま たは固定値に置き換えるかの選択を有する。この認証方法によって端末へのメッ セージの認証が提供されると考えられる。端末を騙すのに成功する確率は、ほぼ １を可能チャレンジ値の数で割ったものであると考えられる。 緻密な裏書き署名は高程度の柔軟性を提供すると考えられる。大きなハウスを 用いると、カードはいかなるメッセージでも署名することができる。もっと効率 的でもっと小さなハウスを用いると、カードは小さなメッセージに署名すること ができるか、または任意に長いメッセージを認証することができる。 ハウスを使用して端末への任意に長いメッセージを認証するときは、カードは 同時に、発行者が使用するためのそのメッセージの秘密鍵認証を送ることができ る（発行者が元々カードを作成したのだから、カードと発行者とは秘密鍵を共有 していると仮定する）。先ず秘密鍵認証がメッセージに添付され、次にこれら２ つの組み合わせが、ハウスを使用する端末に対して認証される。これは、端末に とっては公開鍵署名の利点を提供し、発行者にとっては秘密鍵署名の速度および 格納上の利点を提供すると考えられる。すなわち、端末はハウスおよびすべての 関連データを廃棄して、メッセージと秘密鍵認証のみを格納することができる。 タウン再計算 消費プロセス中に、カードはタウンのいくつかの中間値を端末に送らなければ ならない。計算を節約するためにこれらの値は予備計算される。１つの例として 図５のタウンを用いる。予備計算ステップは図40に示す。図40に示す予備計算ス ケジュールは、最適な予備計算スケジュールより多くの記憶領域をカードに必要 とするという意味で次善ではあるが、このスケジュールが最も容易な具現体を生 成すると考えられる。 図40はどのステップにおいてもメモリに格納される値を示す。第１列は、消費 されているタウンのハウスの番号を含む。第２列は、現在のタウン（Ａと呼ぶ） で予備計算される値セットを含む。第３列は、次のタウン（Ｂと呼ぶ）で予備計 算される値セットを含む。次のタウンとは、すべての構成ハウスが使用されたと いう意味で現在のタウンが消費された後使用される予定のタウンである。明瞭化 のために、図40では次のタウンに関連するすべての項目は斜体で示されている。 第４列は、タウン内の第１列に示されるハウスを認証するのに必要な値セットを 含み、最終列は、メモリに格納されている値の数を含む。 図40の第１行は、ハウス560が消費されているとき値523、543、564、565、566 、567が消費プロセスで使用されていることを示す。（上述のように、この好適 な実施態様では現在のハウスのハウス結果値が使用される。これは機能的な観点 か らは必要ないが、これにより実現が最も容易になると考えられる。）値534は（ ハウス530のハウス結果値を計算することによって）計算され格納される。 図40の第２行は、次のハウス561が消費されるときの状況を示す。前のステッ プと同じ値が使用され、もう１つの値、すなわち値535が予備計算される。第３ 行でハウス562が消費されるときは、値564および565はもはや消費プロセスには 必要なく、圧縮機能を用いて値569に組み合わされる。これにより格納スペース が節約され、次の値536を予備計算するために用いられる。次の行は、ハウス563 が消費されているときのこのプロセスの反復を示す。値569および566は組み合わ されて値571となり、余った格納スペースは値537を計算するために用いられる。 ハウス530を消費するときは、値571および567は組み合わされて値573となり、値 543はもはや必要ないため既に予備計算されている値534、535、536および537に 置換され、これらが消費プロセスで用いられる。このステップで値514が予備計 算される。これはまた、次のタウンのための予備計算を開始するポイントでもあ る。現在のタウン(A)のすべてのハウスが消費されると、次のタウン(B)の第１の ハウスのための消費プロセスに必要なＢの中間値が必要である。この時点で、タ ウンＢの計算543の最初のステップであるタウンＢのハウス530を計算することに よって、タウンＢの値534を予備計算する。ハウス531を消費するときは、消費の ために同じ値セットが使用され、値515が予備計算され、タウンＢではハウス値5 35が予備計算され、既に格納されている値534と組み合わされて値539が生成され る。タウンＢの値539のみが格納される。表に示すようにこのプロセスが続けら れる。ハウス533を消費するときは、値523、541、537および573が使用される。 値514、515、516および517はタウンＡで予備計算されている。タウンＢでは値53 7が計算され、タウンＢで既に予備計算されている値541と組み合わされ結果値54 3が格納される。次のハウス510が消費されているときは、タウンＡの値573、541 および537はもはや必要ない。これらは適切な圧縮機能を用いて値582へと組み合 わされる。タウンＡで既に予備計算されている値514、515、516および517がここ で使用される。２つの新しい値すなわち514および564がタウンＢで予備計算され る。次の行ではハウス511、512および513のための消費状況が示される。消費の ために使用される最初の値514、515、516および517は順番に組み合わされ、最後 のハウス513の消費のための値521および517が得られる。タウンＢの予備計算は 、565、566および567を予備計算すること、および中間値519および521と共に複 数のステップで値523を予備計算することを含む。最後のハウス513が消費された 後、次のタウンに切り替える。タウンＢと呼ばれていたものがこれでタウンＡと なる。タウンＡの消費中にタウンＢで予備計算された値は正に、表の次の行によ って示されるようにタウンＢの最初のハウス560の消費に対して必要な値である 。当然ながら、古いタウンＡの残りの値521、517および582はもはや必要ないた め廃棄される。タウンのすべてのハウスが消費されるとタウン起源値およびタウ ン署名はもはや使用されないため、これらもまた廃棄される。 この予備計算の方法は、タウンの各次元のサイズの合計に比例する格納スペー スを必要とすると考えられる。さらに、予備計算は、多数のタウンが用いられる 場合は最大で次元数と同じ数のハウスを、そして単一のタウンが用いられる場合 はそれより１つ少ない数のハウスを計算することを含むと考えられる。図40では 、各ステップで多くて２つのハウスが予備計算され、これらのうち少なくとも１ つはタウンＢのハウスである。タウンＡが第２のタウンが必要ないほどに十分に 多くのハウスを含む場合は、次のタウンの予備計算を行う必要はない。これによ りさらに必要な予備計算が減ると考えられる。カードに追加のタウンをロードす ることは可能であると考えられる。これらは予備計算を行わない（例えばタウン Ｂの次のタウン）か、または（部分）予備計算を行う（例えば、既に存在するタ ウンＡに正しい予備計算を行うタウンＢを加える）か、もしくは現在のタウンお よび予備計算を廃棄して正しい予備計算を行う新しいタウンに置換してもよい。 これらの拡張は当業者には明らかである。 上述の予備計算は当然ながらカード自体によって行われ得る。もしくは、端末 が予備計算を管理し得る。タウンのハウス結果値は秘密ではないため、カードは 要請によりこれらを計算して結果を端末に送ることができる。改良例としては、 カードはハウス結果値を計算せず各列の最終値のみを計算し、これらの列値を端 末に送り、端末がこれらを組み合わせてハウス値を得ることがある。端末は予備 計算を管理し、カードのメモリ内の必要な値の読み出し、書き込み、および削除 を行うことができる。例えば、限定はされないが、ハウス562（図40、第３行参 照）を消費するとき、端末はカードにハウス結果値536を計算するように頼むこ とができる。カードはこれを予備計算された値としてそれ自体に格納するか、ま たはこれを端末に送り、端末はこれを予備計算された値としてカードに送り返す 。端末はさらに、カードのメモリに格納されている値564および565を読み出し、 カードのメモリのこれらの値を削除し、値564および565から値569を計算し、そ して値569を予備計算された値としてカードに書き込む。同様の方法ですべての 他の予備計算行為が端末によって管理され得る。端末はそれ自体でこれらの行為 すべてを行うか、または予備計算を行い管理する不正改変不可能な装置を含み得 る。この予備計算管理システムはカードの実現を簡素化すると考えられる。予備 計算を行うか管理するときに端末が起こすエラーはセキュリティの脆弱化にはつ ながらず、せいぜいタウン内のハウスの適切な認証が失敗し得、これにより修復 が行われるまでは緻密な裏書き署名スキームが非効率となる。端末は、カードの 予備計算状態が一貫していないことを検出すると、カードを修復してこれを予備 計算に関しては一貫した状態にすると考えられる。 安全データ記憶 図12は、この好適な実施態様のカードの不揮発性メモリおよび揮発性メモリの 基本的なレイアウトを示す。 揮発性メモリ1240は、後に詳述するVNIUと呼ばれる変数1241を保持する。フィ ールド1242は、安全データ記憶の一部ではない揮発性メモリ変数を保持する。明 瞭化のためにこれらは示されていない。 不揮発性メモリ1200は3つの領域に分割される。領域1201は不揮発性グローバ ル変数を格納するために用いられる。領域1203は、当該分野では既知のように他 のアプリケーションまたは目的のために空けられている。領域1201は1230として より詳細に示されている。点線は拡張を表す。フィールド1231、1232、1233、12 34、1235および1236はそれぞれNIU、COM、NDONE、NBROK、CLCOMおよびCLCANと呼 ばれる包括的不揮発性変数であり。これらについては後に詳述する。部分1237は 、安全データ記憶システムの一部ではない包括的不揮発性変数である。NDONE変 数はセッションプルーフで用いられる。これについては後に詳述する。 領域1202は1210としてより詳細に示される。点線は拡張を表す。この領域は フレームスロットと呼ばれる複数の固定サイズのより小さな領域に分割される。 すべてのフレームスロットは同じサイズおよび同じ内部構造を有する。フレーム スロットの１つ1211は1220として拡張して示される。各フレームスロットは４つ のフィールドよりなり、各フィールドは１つの変数を格納し得る。フィールド12 21はタグフィールドと呼ばれ「タグ」という変数を保持する。フィールド1222は アクセスフィールドと呼ばれ「アクセス」という変数を保持する。フィールド12 23はデータフィールドと呼ばれ「データ」という変数を保持する。最後に、フィ ールド1224はチェックサムフィールドと呼ばれ、他の３つのフィールドに対する チェックサムとして働く(チェックサムと呼ばれる)値を保持する。他の３つのフ ィールドからチェックサムを計算する機能は多くの方法で選択され得る。例えば 、限定はされないが、二進法数として符号化されるとき他の３つのフィールドに 現れるゼロビットの数として選択され得る。４つの値、タグ、アクセス、データ およびチェックサムはまとめて「フレーム」と呼ばれる。 タグ機能は通常のコンピュータのファイル名に似ている。これはフレームを参 照する固有の名前として使用される。すべてのフレームスロットは同じサイズで あるため、フレームはフレームスロットのいずれにも適合する。フレームスロッ ト内のデータの解釈は、タグフィールドの値にのみ依存し、フレームが現れる不 揮発性メモリの位置には依存しない。特定のフレームについての情報が必要なと きはいつでも、不揮発性メモリは、タグフィールドに適切なタグ値を有するフレ ームスロットを探す。このフレームスロットの他のフィールドはこのフィールド の他のデータを含む。タフフィールドのゼロ値は、フレームスロットは有効なフ レームデータを含まず、従って空であることを示すために使用される。このよう に、フレームスロットは、フレームが不揮発性メモリ内に格納される実際の位置 である。フレームはフレームスロットのどこかに格納されている値セットであり 、これはそのタグ値によって識別される。 アクセスフィールドは、フレームのデータがアクセスされ得る前に満たすべき 条件に関するデータを格納するために用いられる。これは、多くのオペレーティ ングシステムのファイルに関連するアクセス権に対応する。データフィールドは アプリケーションのためのデータを含む。このデータの解釈およびフォーマット はアプリケーションにより異なる。 この好適な実施態様では、タグフィールドは２バイト長、アクセスフィールド は１バイト長、データフィールドは16バイト長、チェックサムフィールドは１バ イト長である。 不揮発性メモリのためのモデル 信頼性があり安全な動作のために、カードは、典型的には、信頼性があり安全 な不揮発性メモリシステムを必要とする。典型的なスマートカードはデータの不 揮発性格納のためにEEPROM技術を用いる。この技術および他の多くの不揮発性格 納技術では本来的にデータの書込みは即時ではない。EEPROMメモリには２つの基 本的なプロセス、書込みおよび消去がある。消去では、ビットブロックはデフォ ルト位置にクリアされる。これは一般性を失うことなく二進法の０で表され得る （いくつかの具現体では消去されたビットは１として読み出される）。消去のた めのブロックサイズは具現体に依存し、実際には１であり得るが、典型的な最小 ブロックサイズは８または32ビットである。これは、個々のビットを消去するの は可能ではなく、ビットブロックとしてのみ消去され得ることが多いことを意味 する。 書込みもまたブロックで行われるが、通常は個々のビットを（ここでの表現で は）１に設定することは可能である。典型的な具現体では、データをメモリブロ ックに書込むときは、０値で書込まれるビットは影響は受けないが、１値で書込 まれるビットは１に設定される。 書込みおよび消去プロセスは共に時間がかかり、典型的には約２〜３ミリ秒必 要とする。何らかの理由で動作がこの時間内に中断される場合は、通常は結果は 特定されない。EEPROMメモリにUV光を照射すると、照射されるビットは部分的な または完全な消去と同様の効果を与えると考えられる。 典型的なEEPROMメモリの機能的なモデルを図11に示す。この図は、EEPROMメモ リの単一ビットのステート図を示す。各ビットは３つの可能なステート1100、11 01、1102を有する。ステート1100は０ステートと呼ばれるものである。このステ ートでは、ビットは安定したゼロ値を有し、常にゼロとして読み出される。１ス テートと呼ばれるステート1101では、ビットは安定した１値を有し、常に１とし て読み出される。ステート1102では、ビットは中間ステートにあり、？ステート と呼ばれる。このステートでは、ビット値は定義されず、読出し動作の結果は定 義されない。ほとんどの具現体は、特定の読出しを試みるとゼロかまたは１値の いずれかが返されるが、ここでは、どの値が返されるかを予測することは不可能 であると仮定する。返される値は、温度、印加電圧などのカードの外的な要因を 含む他の要因にも依存し得るため、読出しの試みによって返される値についてど のような仮定も行わない。 図11にはステート転移も示す。１を０ステート1100のビットに書き込もうとす る書込み動作の開始時に、０ステート1100のビットはステート転移1110を介して ？ステート1102に転移される。このビットは書込み動作の間？ステートにとどま る。このビットに１を書き込もうとする書込み動作の終了時に？ステート1102の ビットは転移1111を介して１ステート1101に転移される。１ステート1101のビッ トを含むビットブロックの消去動作の開始時に、１ステート1101のビットは転移 1112を介して？ステート1102に転移される。このビットを含むビットブロックの 消去動作の終了時に？ステート1102のビットは転移1113を介して０ステート1100 に転移される。書込みまたは消去動作が何らかの理由で妨害される場合は、転移 1111および1113は行われず、ビットは？ステート1102にとどまる。 UV放射の影響下では、１ステート1101のビットもまた1112を介して？ステート 1102に、そして？ステート1102から1113を介して０ステート1100に転移され得る 。 当業者には明らかなように、このモデルは、幅広い範囲の不揮発性メモリ技術 に適用するかまたは適用され得る。 破壊モード この好適な実施態様では、カードは2つの基本的なモード、「破壊」モードお よび「非破壊」モードを有する。このモードはNBROK変数1234によって示される 。これは、メモリ内の他の変数に影響を与えずに消去され得るようにビットブロ ック全体を占領する不揮発性メモリ内の単一ビット変数である。通常の環境下で は、カードは「非破壊」モードにあり、NBROK変数1234は１の値を含む。カード の個人化を行っている間に、この変数は１値に設定される。NBROK変数1234がゼ ロの ときの「破壊」モードについては後に詳述する。 多更新 変数CLCOM(1235)およびCLCAN(1236)はそれぞれビットアレイよりなり、不揮発 性メモリのフレームスロット毎に１ビットである。デフォルト状態では、すべて のビットは０である。変数NIU(1231)およびCOM(1232)は共に、個別に書込みおよ び消去が行われるようにビットブロック全体を占領する単一ビット変数である。 VNIU(1241)変数は揮発性メモリ内の単一ビット変数である。 図18は、この好適な実施態様のフレームを見つけるプロセスを示す。開始1800 では、変数ｔは不揮発性記憶領域で見つけるべきフレームのタグ値を含む。先ず 、ステップ1801では、2つの新しい変数が初期化される。見つかったフレーム数 を示すカウンタnr_foundは０に初期化され、すべてのフレームスロットインデッ クスを通読するインデックスカウンタidxは最初のフレームのインデックス値に 初期化される。次は、項目1802、1803、1804、1805よりなるループであり、ｔに 等しいタグ値を有するフレームスロットを検索する。このとき、CLCOM変数の関 連するビットは０である。先ず、ステップ1802で、インデックスidxを有するフ レームスロットが検査されタグフィールドが値ｔを含むかどうか、および変数CL COMのフレームスロットに関連するビットが０かどうかが調べられる。これに該 当しないときは、プロセスは項目1804に進む。これに該当するときは、フレーム スロットが見つかったことになり、プロセスは項目1803に進む。ステップ1803で は、カウンタnr_foundが１つ増分し、idxの現行値がstore_idxと呼ばれる変数に 割り当てられる。この後、プロセスはステップ1804に進む。ステップ1804は、ス テップ1802によって検査されたフレームが最後のフレームかどうかをチェックす る。これに該当するときは、プロセスはステップ1810に進む。さもなくば、ステ ップ1805に進む。ステップ1805では、idx変数が１つ増分して次のインデックス 値に進み、プロセスはステップ1802に進む。これまでのプロセスの結果として、 変数nr_foundは、不揮発性メモリ内の、タグ値がｔに等しくCLCOM変数の表示ビ ットがゼロであるフレームスロットの数を含んでいる。nr_found変数がゼロより 大きい場合は、store_idx変数は見つかったフレームスロットのうちの１つのイ ンデックスを含んでいる。 ステップ1810、1811、1820、1830、1840は前のループの結果に基づいてどちら の行為を行うべきかを決定する。ステップ1810では、カウンタnr_foundがゼロ値 かどうかチェックされる。nr_foundがゼロの場合は、プロセスはステップ1820に 進み、ここで、戻り値を設定してフレームが見つからなかったことを示す。ステ ップ1810でnr_foundがゼロではないと決定される場合は、プロセスはステップ18 11に進み、ここで、nr_foundが１より大きく、ｔがゼロではないかどうかチェッ クされる。これに該当する場合は、プロセスはステップ1840に進み、ここでNBRO K変数を消去して０にし「破壊」モードに入り、適切な「破壊」モード処理のた めのリセットプロセスにジャンプする。ステップ1811で条件が偽のときは、プロ セスはステップ1830に進み、ここで戻り値を設定してフレームが見つかったこと を示す。フレームを見つけるプロセスは、ステップ1820かまたはステップ1830の 後に生じるステップ1850で終了する。 この好適な実施態様のフレームを読出すプロセスを図19に示す。開始1900では 、変数ｔは読み出される予定のフレームを含む。最初のステップ1901は、（図18 に示すような）フレームを見つけるプロセスを実行してタグｔを有するフレーム を検索する。次に、ステップ1902はフレームが見つかったかどうか決定する。フ レームが見つからなかった場合は、プロセスは1910に進み、ここで戻り値を設定 して、フレームが見つからなかったことを示す。ステップ1902がフレームが見つ かったと決定する場合は、プロセスはステップ1903に進む。このステップは、フ レームスロットからのデータを取り出し、ステップ1901の「フレームを見つける 」プロセスによって設定された変数store_idxを用いて適切なフレームスロット の位置をつきとめる。次にチェックサムフィールドが正しい値を持っているかど うかをチェックする。これに該当しない場合は、プロセスは1930に進み、ここで NBROK変数を消去して０にし、「破壊」モードに入り、適切な「破壊」モード処 理のためのリセットプロセスにジャンプする。ステップ1903が正しいチェックサ ム値を見つける場合は、プロセスはステップ1920に進み、ここで戻り値をフレー ムデータに設定し、フレームが見つかったことを示す。フレームを読み出すプロ セスは、ステップ1910または1920のいずれかの後に生じるステップ1940で終了す る。 図13は、この好適な実施態様の更新シーケンスを開始するプロセスを示す。こ のプロセスの開始1300では別の更新が既に進行中のこともある。この場合には、 両方の更新が組み合わされて単一の多更新が行われる。ステップ1301では、変数 VNIUが検査される。これが１に等しくない場合は、別の更新が既に進行中である ため、新しい更新は初期化の必要はない。プロセスはステップ1310に進む。ステ ップ1301が、変数VNIUが１の値を有すると見出す場合は、ステップ1302に進む。 ステップ1302はNIUおよびVNIUの両方をゼロに設定する。この後、プロセスはス テップ1310に進む。ステップ1310はプロセスを終了させる。 図14は、この実施態様のフレームスロット内のフレームを削除するプロセスを 示す。開始1400では、変数ｉは、削除される予定のフレームが存在するフレーム スロットのスロットインデックス番号を含む。最初の行為1401は、図13に示すよ うな「更新を開始する」プロセスを実行して、更新が進行中であることを確実に することである。次のステップ1402では、CLCOM変数の‘ｉ番目のビットが１に 設定される。この後、プロセスはステップ1410で終了する。 図15は、この好適な実施態様のフレームにデータを書き込むプロセスを示す。 開始1500では、変数ｔは書き込まれる予定のフレームのタグ値を含み、変数「ア クセス」は書き込まれる予定のフレームのためのアクセス制御コードを含み、変 数「データ」は書き込まれる予定のフレームのためのデータを含む。最初のステ ップ1501は、図13に示す「更新を開始する」プロセスを実行する。次のステップ 1502は、図18に示す「フレームを見つける」プロセスを実行して、同じタグ値を 持つ現存するフレームの位置をつきとめる。次のステップ1503は「フレームを見 つける」プロセスの戻り値を検査して、フレームが見つかったかどうかを決定す る。これに該当しない場合は、プロセスはステップ1506に進む。ステップ1503が 、フレームが見つかったと決定する場合は、プロセスはステップ1505に進む。ス テップ1505は、ステップ1502で見つかったフレームを含むフレームスロットのた めの「フレームを削除する」プロセスを実行する。見つかったフレームスロット のインデックス値は、「フレームを見つける」プロセスによって変数store_idx に格納されており、ここで「フレームを削除する」プロセスへの入力として用い られ、フレームスロットが削除されるべきであることを示す。ステップ1505の後 、プロセスはステップ1506に進む。ステップ1506は図18の「フレームを見つける 」 プロセスよりなり、タグフィールド値がゼロのフレームスロットを検索する。次 のステップ1507はステップ1506の結果を検査し、このようなフレームが見つかっ たかどうかを決定する。フレームスロットが見つからない場合は、プロセスはス テップ1520に進み、ここで図8の取消プロセスにジャンプする。これについては 後に詳述する。ステップ1507が、フレームスロットが見つかったと決定する場合 は、プロセスはステップ1508に進む。ステップ1508では、ステップ1506によって 見つけられたフレームスロットに対応するビットがCLCAN変数に設定される。ス テップ1506によって見つけられたフレームのインデックス番号は'store_idx'変 数に格納されており、これがここで適切なビットを設定するために用いられる。 次のステップ1509は、ステップ1506によって見つけられたフレームスロットに新 しいデータを書き込む。タグフィールド、アクセスフィールド、およびデータフ ィールドにはそれぞれ't'変数、「アクセス」変数、および「データ」変数の値 が書き込まれる。フレームスロットのチェックサムフィールドには適切なチェッ クサム値が書き込まれる。次のステップ1552はプロセスを終了させる。 図17は、この好適な実施態様の「コミット」プロセスを示す。プロセスはステ ップ1700で開始されステップ1701に進み、ここでVNIU変数が１に等しいかどうか を決定する。これに該当する場合は、プロセスはステップ1730に進む。ステップ 1701がVNIUがゼロに等しいと見出す場合は、プロセスはステップ1710に進む。ス テップ1710では、最初の行為はCOM変数を１に設定することである。次にCLCAN変 数が消去され０になる。次に、１に等しいCLCOM変数の各ビットに対して、この ビットに関連するフレームスロットがクリアされる。フレームスロットをクリア することは、タグフィールドを消去して０値にすることである。続いて、CLCOM 変数を消去して０にし、この後COM変数を０にリセットする。プロセスはステッ プ1721に進み、ここでNIU変数を１に設定する。次のステップ1722はVNIU変数を １に設定し、プロセスはステップ1730に進む。ステップ1730はコミットプロセス を終了させる。 図８は、この好適な実施態様の「取消」プロセスを示す。プロセスはステップ 1750で開始される。次のステップ1751は、VNIU変数が１に等しいかどうかを決定 する。これに該当するときは、プロセスはステップ1770に進む。ステップ1751が 、 VNIUが１に等しくないと決定する場合は、プロセスはステップ1751に進む。ステ ップ1751では、最初の行為はCOM変数を消去して０にすることである。次にCLCOM 変数が消去され０になる。次に、１に等しいCLCAN変数の各ビットに対して、こ のビットに関連するフレームスロットがクリアされる。フレームスロットをクリ アすることは、タグフィールドを消去して０値にすることである。ステップ1751 の最後の行為はCLCAN変数を消去して０にすることである。ステップ1751の後、 ステップ1761でNIU変数は１にセットされる。次のステップは1762であり、ここ でVNIU変数は１に設定される。プロセスは次にステップ1770に進む。ステップ17 70で「取消」プロセスは終了する。 図16は、この好適な実施態様の「リセット」プロセスを示す。プロセスはステ ップ1600で開始される。次のステップ1601はNBROK変数を検査して、その値が１ に等しいかどうかを決定する。これに該当しない場合は、プロセスはステップ16 10に進み、ここでNBROK変数が消去され０になる。ステップ1610の後、次のステ ップは1611であり、ここでは不揮発性メモリのすべての公開データが端末に送ら れる。ステップ1611の後、プロセスは再びステップ1611に戻り無限ループに入る 。ステップ1601がNBROKが１に等しいと決定する場合は、プロセスはステップ160 2に進む。ステップ1602はNIU変数を検査して、これが１に等しいかどうか決定す る。これに該当する場合は、プロセスはステップ1641に進む。ステップ1602が、 NIUは１に等しくないと見出す場合は、プロセスはステップ1603に進む。ステッ プ1603はCOM変数を検査して、これが１に等しいかどうか決定する。これに該当 するときは、プロセスはステップ1630に進む。これに該当しないときは、プロセ スはステップ1620に進む。ステップ1620では、最初の行為はCOM変数を消去して ０にすることである。次に、CLCOM変数を消去して０にする。この後、CLCAN変数 の表示ビットが１であるすべてのフレームスロットがクリアされる。フレームス ロットをクリアすることは、タグフィールドを消去して０値にすることである。 この後、CLCAN変数を消去して０にし、プロセスはステップ1640に進む。ステッ プ1630では、最初の行為はCOM変数を１に設定することである。次に、CLCAN変数 を消去して０にし、この後、CLCOM変数の表示ビットが１であるすべてのフレー ムスロットがクリアされる。次に、CLCOM変数を消去して０にし、最後にCOM変数 を消去して０にする。プロセスはステップ1640に進む。ステップ1640では変数NT Uは１に設定され、プロセスはステップ1641に進む。ステップ1641では、変数VNI Uは１に設定される。この後、プロセスはステップ1650で終了する。「リセット 」プロセスは、コミットが進行中でない場合は「取消」プロセスとして機能し、 コミットが進行中の場合は「コミット」プロセスとして機能する。 「コミット」、「取消」および「リセット」プロセスはまとめて、カウンタを 保持し、「コミット」プロセスが何回完了したか、および「取消」プロセスが何 回完了したかを示す。これらのカウンタはフレームに格納され、各「コミット」 または「取消」プロセス（「リセット」プロセスの「コミット」および「取消」 部分を含む）後に更新される。これらのカウンタおよびその更新の詳細は明瞭化 のために示されてはいない。カウンタは固有のチャレンジを生成するために使用 される。 この好適な実施態様では、「リセット」プロセスは何らかの妨害があった後に 実行される。例えば、限定はされないが、カードがパワーアップされるとき、ま たはカードのリセット後などである。多更新は、典型的には、順序は関係なく一 連の「フレームを読み出す」、「フレームを削除する」および「フレームを書き 込む」プロセスよりなる。多更新は、通常は、「コミット」プロセスまたは「取 消」プロセスにより終了する。多更新中にカードが妨害されると、妨害後の「リ セット」プロセスにより回復される。 図８、図13、図14、図15、図16、図17、図18および図19に示すプロセスはまと めて、以下の機能を提供する。すなわち、フレームはいつでも「フレームを読み 出す」プロセスを用いて読み出すことができる。戻されるデータは常にそのタグ 値により最後に書き込まれたデータである。最初の「フレームを削除する」また は「フレームを書き込む」プロセスは多更新を開始させる。「フレームを削除す る」プロセスの後、削除されたフレームは「フレームを読み出す」プロセスを用 いて読み出すことはできない。「フレームを書き込む」プロセスの後、「フレー ムを読み出す」プロセスによって戻されるデータはそのタグ値により最後に書き 込まれたデータである。「取消」プロセスが実行される場合は、多更新で行われ たすべての改変は破棄される。「フレームを読み出す」プロセスは多更新の開始 前と同じ情報を戻す。多更新が妨害されると、各妨害の後に実行される「リセッ ト」プロセスは、妨害前に「取消」プロセスが与えたと考えられる効果と同じ効 果を与える。すなわち、記憶システム内のデータへのすべての改変は破棄される 。多更新が「コミット」プロセスによって終了される場合は、すべての改変は保 持され、改変を破棄することは可能ではない。「コミット」プロセス後に「リセ ット」プロセスが実行される場合は、改変はすべて保持される。図11に示すよう な不揮発性メモリモデルを仮定すると、上記のプロセス中の任意の瞬間にカード が（恐らく繰り返して）妨害される場合は、効果は、多更新の終了時の「コミッ ト」プロセスの効果か、または多更新の終了時の「取消」プロセスの効果のいず れかであると考えられる。さらに、「コミット」プロセスがまだ開始されていな い場合は、効果は常に「取消」プロセスの効果である。これにより、通常データ ベースの極小更新と呼ばれるものが提供される。すべてが変更されるか、変更は 全く行われないかのいずれかである。この特性は任意の妨害の下でも保持される 。 図11に示すようなUV消去の効果は以下の効果に限定されると考えられる。すな わち、フレームは消去され得る。およびいかなる多更新においても１つのフレー ムの更新は防ぐことができる。これは、極小更新特性はUV消去の下では失われる ことを意味する。しかし、実用的なUV消去により、カードが「破壊」モードに入 る確率が高くなる。さらに、UV消去は新しいフレームを作成するためまたはフレ ームのデータを改変するために用いられることは決してないと考えられる。 セッション この好適な実施態様で実現されるセッションの基本構造を図24に示す。セッシ ョンは「セッションを開始＆プルーフ鍵」プロセス2401により開始される。次に １つ以上の「コマンド＆データ交換」プロセス2402が続き、この後セッションは 「セッションにコミット＆セッションを終了」プロセス2403で終了する。カード および端末の両方がセッションに関与する。後に詳述するように、これらの参加 者のそれぞれがセッションステートを保持する。カードおよび端末に保持される セッションステートはセッションを通じて同一であるべきである。後に詳述する ように、両方のセッションステートは、反復暗号化ハッシュ機能を実現するよう な方法で選択されたチェーン化機能を用いて更新される。セッションの目的は、 いくつかの独立した行為をこれらが単一の分割不能な行為として作用するように まとめて連結することである。独立した行為はいかなるタイプの行為でもよく、 セッション自体であってもよい。典型的には、独立した行為は、フレームを読み 出すかまたは書き込むなどのかなり単純な行為であり得るが、アプリケーション によってはかなり複雑な独立した行為を必要とするものもあると考えられる。 この好適な実施態様で実現される「セッションを開始＆プルーフ鍵」プロセス を図25に示す。このプロセスは、ステップ2501および2505を実行する端末103、 およびステップ2503および2507を実行するカード102を含む。プロセスはステッ プ2501て開始される。端末はセッションで使用される鍵を選択し、端末チャレン ジ値を選ぶ。ステップ2501の最後の行為として、端末は端末チャレンジ値および 鍵の選択をメッセージ2502でカードに送る。メッセージ2502を受け取ると、カー ドはプロセスステップ2503を開始する。ステップ2503の最初の行為はカードチャ レンジを選択することである。次にセッションステートが既知の値に初期化され 、チェーンを開始する。次に、ステップ2501で端末によって選択されメッセージ 2502に示されたすべての鍵がチェーン化される。後に詳述するように、チェーン 化は、チェーン化機能を用いて他のデータ（この場合には鍵）に基づいてセッシ ョンステートを更新することを含む。次の行為は端末チャレンジそして次にカー ドチャレンジをチェーン化することである。ステップ2503の最後の行為としてカ ードはメッセージ2504でカードチャレンジを端末に送る。メッセージ2504を受け 取ると、端末はプロセスステップ2505の実行を開始する。ステップ2505では、最 初の行為は、セッションステートをカードによって使用されるのと同じ開始値に 初期化してセッションステートを初期化することである。次に、ステップ2501で 選択されたすべての鍵がチェーン化され、端末チャレンジがチェーン化され、そ してカードチャレンジがチェーン化される。この結果、ステップ2503の完了時に は端末のセッションステートはカードのセッションステートと同じ値を有する。 ステップ2505の次の行為は、端末が実際に適切な鍵をチェーン化したという証明 として機能する認証コードを暗号化することである。ステップ2505の最後の行為 は、端末がメッセージ2506でプルーフをカードに送ることである。メッセージ25 06を受け取ると、カードはプロセスのステップ2507の実行を開始する。カードは 端末 から送られたプルーフを復号化し、現在のセッションステートに対してこれを検 証する。この検証が失敗するとプロセスは中断される。検証が成功すると、カー ドはステート指示子「セッション内」を設定し、プロセスは終了する。カードは 、このプロセス中にチェーン化された鍵についての情報を保持して、この情報を このセッションでの異なるフレームへのアクセス権を決定するために使用するこ とができる。端末およびカードチャレンジ値は典型的には時間により変動し、例 えば、限定はされないが、乱数生成器を用いて選択され得る。この好適な実施態 様では、カードチャレンジは「取消」カウンタおよび「コミット」カウンタより なる。 上述の鍵はカードのフレームに格納される。鍵を含む各フレームは２つに等分 される。第１の半部は通常は多様化番号を含み、第２の半部は秘密鍵データを含 む。端末かフレームのアクセスフィールドによって特定化されるアクセスを有す る場合は、フレームは標準的な「フレームを読み出す」プロセスを用いて読み出 され得る。鍵を含むフレームが読み出されるときは、秘密鍵を含む部分はゼロに 置き換えられ、秘密鍵データが読み出されるのを防ぐ。いくつかのアプリケーシ ョンでは鍵は多様化される。カードによって使用される（そして鍵フレームの第 ２の半部に格納された）秘密鍵は、マスター鍵とフレームの第１の半部に格納さ れた多様化番号との関数である。マスター鍵へのアクセスを有する端末は、先ず 鍵フレームを読み出すことによって多様化番号を読み出し、カードによって使用 される秘密鍵を計算し、これによりこの鍵を用いてセッションを開始することが できる。多様化番号へのアクセスは、鍵フレームのアクセスフィールドを適切な 値に設定することによって別の鍵によって保護され得る。 この好適な実施態様で実現される「コマンド＆データ交換」プロセスを図２６ に示す。各「コマンド＆データ交換」プロセスは初歩的な機能、例えば、限定は されないが、フレームを読み出すことおよびフレームに書き込むことよりなる。 プロセスの最初のステップ2601は端末によって実行される。最初の行為は端末が コマンドを選択することである。ステップ2601の最後の行為は、端末がコマンド データをメッセージ2602でカードに送ることである。メッセージ2602を受け取る と、カードはプロセスステップ2603の実行を開始する。このステップの最初の行 為は、カードがこれがセッション内であるかどうかをチェックすることである。 セッション内ではない場合は、プロセスは中断され、さもなくばプロセスは次の 行為を続けて行う。メッセージ2602で受け取られたコマンドデータはチェーン化 （従ってセッションステートを更新）され、コマンドが実行される。コマンドの 実行にはいくつかの行為、例えば、限定はされないが、図19、図14および図15に 示すように、フレームの読出し、削除および書込みが含まれ得る。カードから端 末へのレスポンスデータが次にチェーン化される。ステップ2603の最後の行為と して、カードはレスポンスデータをメッセージ2604で端末に送る。メッセージ26 04を受け取ると、端末はプロセスステップ2605の実行を開始する。最初の行為は 、最初にカードに送られたコマンドデータをチェーン化することである。次の行 為はカードのレスポンスデータをチェーン化することである。これでプロセスは 終了する。コマンドデータおよびレスポンスデータはまた、その時、現行であっ たセッションステートを鍵として用いて暗号化されるが、これについては明瞭化 のために示されていない。コマンドがフレームへのアクセスを含む場合は、カー ドは、その操作のために必要な鍵がこのセッションの「セッションを開始＆プル ーフ鍵」プロセスで使用されたかどうかを検証する。例えば、端末がフレームを 読み出す場合、カードは、セッションステートを作成するために使われた鍵によ りフレームの「アクセス」フィールドを用いてフレームに読出しアクセスするの が可能になることを確実にする。フレームの書込みおよび削除についても同様の 検証が行われる。 この好適な実施態様で実現される「セッションにコミット＆セッションを終了 」プロセスを図27に示す。このプロセスの最初のステップ2701では、端末はこの プロセスのためのコマンドコードをチェーン化する。次に現在のセッションステ ートを用いてプルーフを暗号化する。ステップ2701の最後の行為として、端末は プルーフをメッセージ2702でカードに送る。メッセージ2702を受け取ると、カー ドはプロセスステップ2703の実行を開始する。カードはまたこのプロセスのため のコマンドコードをチェーン化し、メッセージ2702でカードによって送られたプ ルーフを復号化する。プルーフが無効である場合はプロセスは中断され、さもな くば続行する。カードは次にコミットカウンタを増分し、セッションステート を用いて第２のプルーフを暗号化する。場合によっては、カードはまた公開プル ーフ「プルーフＰ」を作成し、これらのプルーフを不揮発性メモリに格納する。ス テップ2703の最後の行為は、カードがセッションにコミットする準備ができてい ることを示すメッセージ2704を端末に送ることである。メッセージ2704を受け取 ると、カードはプロセスステップ2705の実行を開始する。このステップの唯１つ の行為は、カードがセッションにコミットすべきであるということを示すメッセ ージ2706を端末がカードに送ることである。メッセージ2706を受け取ると、カー ドはプロセスステップ2707の実行を開始する。最初の行為はCOM変数を１に設定 することである。これは実際には、「コミット」プロセスを示す図17のステップ 2710の最初の行為である。他のすべての行為は図17で既に説明したので明瞭化の ために示していない。同時にNDONE変数が１に設定される。これは、このセッシ ョンのプルーフは端末に成功裏に送られていないことを示す。NDONE変数およびC OM変数の設定は極小であるべきである。これは、COM変数が１の場合に「コミッ ト」プロセスおよび「リセット」プロセスでNDONE変数を設定することによって 実現される。COM変数がゼロの場合は、NDONEビットは「取消」プロセスおよび「 リセット」プロセス中にゼロに設定される。カードは次に第２のプルーフおよび 場合によっては公開プルーフをメッセージ2708で端末に送る。この後、カードは 図17の「コミット」プロセスを完了する。メッセージ2708を受け取ると、端末は プロセスステップ2709の実行を開始する。これは、第2のプルーフおよび場合に よっては公開プルーフを復号化することを含む。これらのプルーフが満足のいく ものである場合は、端末はメッセージ2710をカードに送る。メッセージ2710を受 け取ると、カードはプロセスステップ2711の実行を開始する。すなわち、NDONE ビットを０にクリアする。当業者には明らかなように、NDONEビットはまたフレ ームに格納され得、これはセッション中いつでも更新される。これにより、NDON EおよびCOM変数を同時に設定するという課題が自動的に解決される。 このプロセスは、フレームの書込みまたは削除が行われたセッションに対して のみ関連する。上述のように、フレームシステムの更新は最初の書込みまたは削 除で開始される。「セッションにコミット＆セッションを終了」プロセスは、図 17の「コミット」プロセスを実行し次に更新を終了させるための通常の方法である 。 NDONEが１であるがきり、端末はカードに、両方ともカードによって保持され たままである第２のプルーフおよび場合によっては公開プルーフを再送付するよ うに頼むことができる。これを図32に示す。プロセスはステップ3200で開始され る。このステップでは、端末は「プルーフを得る」コマンドをメッセージ3201でカ ードに送る。メッセージ3201を受け取ると、カードはプロセスステップ3202の実 行を開始する。NDONEビットが依然として１であり従ってプルーフが依然として 利用可能な場合は、カードはプルーフをメッセージ3203で端末に送る。NDONEビ ットがゼロの場合はプルーフは送られない。端末はメッセージ3203を受け取ると 、プロセスステップ3204の実行を開始する。このステップでは、端末はプルーフ を検証し、「完了」コマンドをメッセージ3205でカードに送る。メッセージ3205を 受け取ると、カードはプロセスステップ3206の実行を開始する。このステップで は、カードはNDONEビットをゼロに設定する。これは、端末はもはやプルーフを 読み出すことはできないことを意味する。 ステップ2705ならびにメッセージ2704および2706により端末がカードを、実際 にはコミットしないが正にコミットの縁までもたらすことが可能になると考えら れる。この時点で端末がカードをリセットすれば、COM変数はまだ設定されてい ないので、すべてのフレームはセッション前の値に戻ると考えられる。追加のス テップ2705により、端末からカードへの最後のメッセージとメッセージ2708での プルーフの送付との間の時間量が減少すると考えられる。ステップ2707でのCOM ビットの設定の結果、すべてのフレームが新しい値に更新されまたプルーフを送 るのが可能になる。 カードと端末の両方で維持されるセッションステートはセッションにおけるす べての行為を連結するために用いられる。図20はその基本的な概念を示す。端末 が図26の「コマンド＆データ交換」プロセスで特定のフレームをカードから読み出 すことを望むとする。カードの行為は項目2000として示し、端末の行為は項目20 20として示す。カードは現在のセッションステート2011を受け、フレームから読 み出されたデータ2013を機能2010への入力とする。この機能は、現在のセッショ ンステート2011をデータ2013を組み合わせ新しいセッションステート2012を生成 する。同じ2つの入力はまた異なる方法で組み合わされて暗号化データ2014を生 成し、カードはこれを端末に送る。端末は同様のプロセスを行う。すなわち、端 末の現在のセッションステート2031およびカードから受け取ったばかりの暗号化 データ2033が機能2030への入力として用いられる。この機能は新しいセッション ステート2032および復号化データ2034の両方を生成する。これらの機能は、現在 のセッションステート2011および2031が同一であれば２つの新しいセッションス テート2012および2032は同一であり、また復号化データ2034は最初のデータ入力 2013と同一であるように選択される。端末がデータをカードに送るとき、役割が 反対の同じシステムが使用される。セッションステートの更新とは上記に言及し たチェーン化である。機能2010および2030は、これらがこれらを通過するデータ に反復暗号化ハッシュ機能を実現しセッションステートがハッシュ出力であるよ うに選択される。 図20には２つの機能2010および2030がある。カードは送り人でも受取人でもあ り得るため、両方の機能を装備する必要がある。これを簡略化するために、この 好適な実施態様では図21の解決策を用いる。カードは機能2110を装備し、端末は ボックス2130を装備する。現在のセッションステートはこの場合も機能への入力 2111および2131として用いられ、新しいセッションステート2112および2132を出 力として生成する。カードがデータを端末に送ることを望むときはカードはデー タ入力値2113を用いる。機能2110はセッションステートを更新し、セッションス テートに依存してデータを暗号化し、暗号化されたデータを2114として出力する 。この値は端末に送られ、端末はこれを機能2130への入力2133として用いる。機 能はセッションステートを更新しデータを復号化して出力値2134を提供する。機 能2130および2110は、現在のセッションステート2111および2131が同一であれば 出力データ2134は入力データ2113に等しく、新しいセッションステート2112およ び2132もまた同一であるように働く。端末がデータをカードに送ることを望む場 合は、端末はデータを入力2133とし現在のセッションステートを入力2131として 用いる。機能2130はまた、新しいセッションステートである出力値2132、および 暗号化データである出力値2134の２つの出力値を有する。端末は暗号かデータを カードに送り、カードはこれを機能2110への入力2113として用いる(この機能は 現在のセッションステートを入力2111として受ける)。機能2110は2つの出力、新 し いセッションステート2112および復号化データ2114を生成する。機能2110および 2130は、この場合も、現在のセッションステート2111および2131が同一であれば データ出力2114はデータ入力2133に等しく、新しいセッションステート2112およ び2132もまた同一であるように働く。従って、同じ機能が送り人と受取人の両方 で使用される。 この好適な実施態様の機能2110の構成を図22に示す。項目2200が機能2110に対 応する。これは２つの入力、現在のセッションステート2201とデータ入力2202と を受け、２つの結果値、新しいセッションステート2204とデータ出力2203とを生 成する。セッションステート2201は、ksbと記された暗号化一方向機能2210への 入力として使用され、暗号化／復号化値2211を生成する。これは、機能2212によ ってデータ入力2202と共に排他的OR計算され、データ出力値2203を生成する。次 にデータ出力値2203および現在のセッションステート2201がチェーン化機能2213 への入力として用いられ、新しいセッションステート2204を出力として生成する 。この好適な実施態様では、一方向機能2210とチェーン化機能2213とは、この機 能がセッション内で計算されるときはいつでも異なる機能である。 この好適な実施態様の機能2130の構成を図23に示す。項目2300が機能2130に対 応する。これは２つの入力、現在のセッションステート2301とデータ入力2302と を受け、２つの結果値、新しいセッションステート2304とデータ出力2303とを生 成する。現在のセッションステート2301は、ksbと記された暗号化一方向機能231 0への入力として使用され、暗号化／復号化値2311を生成する。これは、機能231 2によってデータ入力2302と共に排他的OR計算され、データ出力2303を生成する 。現在のセッションステート2301およびデータ入力2302がチェーン化機能2313へ の入力として用いられ、新しいセッションステート2304を出力として生成する。 機能2300および2200を構成する構築ブロックは機能性において同一である。 このセッションシステムは以下の機能性を提供すると考えられる。すなわち、 端末は、端末がアクセスを有する鍵のすべてよりなる鍵セットによってのみセッ ションを開始することができる。端末がこれらの鍵へのアクセスを有しない場合 は、ステップ2507の検証は高い確率で失敗する。使用中の鍵の適当な部分セット のみへのアクセスを有する敵が盗聴を行おうとする場合、この敵はカードと端末 との間で交換されている実際のデータを読み出すことはできない。これらのデー タはすべてセッションステートを用いて暗号化されているからである。上述の攻 撃者が、使用される鍵のすべてへのアクセスを持たないでセッションステートを 再構成することは実行不可能であると考えられる。攻撃者がセッションに一定の コマンドを加えようとすると、カードおよび端末のセッションステートはもはや 同じではなくなる。この結果高い確率でステップ2703のプルーフは失敗し、取り 引きは中断される。これにより進行中の多更新は自動的に取り消される。セッシ ョンシステムはすべての行為を連結し、カード内のいずれかのデータが改変され る場合は、これは端末によって選択されるコマンドのみによって行われ、コマン ドが順番に実行されることを確実にする。端末は依然としてステップ2705で、セ ッションを完了してすべての更新にコミットするか、もしくはセッションおよび これにより関連する多更新を中断するかどうかを選択することができる。カード がセッション中のいずれかの時点で妨害される場合は、関連する多更新は終了し ておらず、この結果カードは元のステートに戻る。ステップ2707でCOM変数を１ に設定した後カードが、例えば不注意なパワーダウンによって妨害される場合で も、端末は依然として第２のプルーフ(図27では「プルーフ2」)および場合によっ ては公開プルーフを回復することができる。COM変数が設定される前にカードが 妨害される場合は、プルーフをカードから取り出すことはできない。これは、カ ードの任意の妨害の下でも多更新は行われ端末はプルーフを読み出すことができ るか、もしくは多更新は取り消され端末はプルーフを獲得しないかのいずれかで あることを意味する。 カードは過去の取引についてのデータを格納することができると予想される。 この情報は後に多くの目的のために、例えば、限定はされないが、会計および試 験のため、または恐らく完了した取引の効果を逆転させるために使用され得る。 秘密鍵デビット／再デビット フレームの読出しおよび書込みとは別に、この好適な実施態様はまたデビット ／再デビットプロセスをサポートする。これは支払い用プリペードカードの実現 を容易にする。これにより、フレームに格納される残高レジスタ(残高と呼ばれ ることもある)を、このフレームに書き込むために使用される鍵とは異なるアク セス鍵を用いて特定の金額だけ減らす(デビットする)ことが可能である。再デビ ットプロセスにより、端末がレジスタでデビットまた再デビットプロセスを行っ た最後のものである場合に限り、端末はそのレジスタの前の値を減らすことがで きる。このレジスタはいくつかの簡単な認証コードによって保護されている。再 デビットプロセス中に端末は、その残高レジスタの前のデビット／再デビットプ ロセス中に使用されたセッションステートを送らなければならない。デビット／ 再デビットプロセスは通常はデビットが行われたことの証明としてセッションプ ルーフを使用するので、通常のアレンジメントとして、端末はこのプロセスに必 要な鍵を有する不正改変装置を持つ。これにより、このようにしてデビットされ た合計金額を追跡し、また端末がカードとの再デビットプロセスを実行するのを 可能にする一時的な鍵が安全に格納される。再デビット機能の典型的なアプリケ ーションとしてはコーヒー販売機がある。利用者が必要な飲料を選択すると、端 末はその飲料の金額分をカードからデビットし機械を始動させる。機械が（例え ば機能不全のため）飲料を提供するのに失敗したら、端末は０減分でデビットコ マンドを行って、カードの所有者に金額分を効果的に返金する。デビットおよび 再デビットプロセスは異なるアクセス鍵を必要としフレーム書込みプロセスが必 要であるため、コーヒー販売機の端末は、端末がカードの値を増やすのを可能に するような鍵へのアクセスを持つ必要はない。このプロセスの詳細は示されない が、当業者には明らかである。 一定のタイミング 本発明のシステムにおけるカードのような不正改変不可能な計算装置の主たる 用途は、一定のデータを秘密に保ち且ついくつかのプロセスを安全に実行するこ とである。機能がいくつかのプロセスを安全に実行することだけである場合でも 、外部世界がカードが実際にプロセスを行い結果が本物であることを知る唯一の 方法は、カードがプロセスの結果を認証することである。これは、通常は、暗号 化認証システムを用いて行われ、これは秘密鍵情報の格納および使用を必要とす る。ほとんどの設計では、秘密鍵がカードによって秘密に保たれ外部に送られな いことを確実にするために適切な注意が払われている。しかし、ほとんどの設計 は、 カードとインタフェース装置(端末)との間の通信レベルで行われる。 このセクションのために、端末が何らかの手段によってカードから追加の情報 を引き出そうとしていると仮定する。標準的な通信とは別に、端末は、コマンド とそのレスポンスとの間の時間、またはカードが各瞬時に引き出す電源電流など のいくつかの他の事柄を測定することができる。このような測定は、カードの内 部動作についてもっと多くの情報を暴露する可能性を持つ。 スマートカードの少なくとも１つの実際の具現体はこれらの問題を抱えている と考えられる。問題のカードはチップ上に特別なコプロセッサを備え、カードが RSA署名を行うのを可能にしている。端末は電源電流を時間およびスマートカー ドチップを取り巻く電磁界の関数として測定することによって、コプロセッサが 使用されているときを決定することができると考えられる。RSAアルゴリズムは 秘密の指数を有する累乗法を含む。この具現体では、累乗法は当該分野では周知 の二乗および乗算アルゴリズムを用いて行われる。このアルゴリズムは、多数の 二乗化とこれらを挟むもっと少ない数の乗算とを含む。コプロセッサの作動時間 を測定することにより、端末は次のステップが乗算であるか二乗化であるかを推 論することができる。この知識により、RSA署名を作成するときカードによって 使用された実際の秘密鍵を容易に回復することができる。 公開鍵アルゴリズムは一般には、秘密鍵アルゴリズムよりこの種の攻撃を受け やすいと考えられるが、多くの秘密鍵に基づくシステムもこのような攻撃を被っ ている。例えば、スマートカードのPIN検証ルーチンが各ディジットを連続して 比較し、不一致が見つかると直ちに比較を中断する場合、検証コマンドの開始と 「PINが不正確」レスポンスとの間の時間によって、ディジットの内のどれが間 違っているかが明らかとなる。これにより、４ディジット十進法のPINに対して 、攻撃中に正しいPINが見つかるまでに行う必要のある試みの平均回数が5000か ら40より少ない数に減ると考えられる。同様の攻撃が一定の秘密鍵に基づく具現 体に対しても働くと考えられる。明白な解決策は、端末に追加の情報を暴露し得 るすべてのプロセスが、固定時間量内で実行されるのを確実にすることである。 これは、適切に時間設定された遅延ループを適切な位置に挿入することによって 実現され得る。 多くの現在のスマートカードの具現体は、レスポンスのタイミング差によって カード上のファイルまたはディレクトリの存在を暴露すると考えられる。端末が このようなファイルまたはディレクトリへのアクセスを持たない場合でも、レス ポンスのタイミングは、ファイルまたはディレクトリが存在するかどうかまたは 存在しないかどうかに依存して異なる。さらに、端末が関連するスマートカード アプリケーションへのアクセスを持たない場合でも、いくつかのスマートカード の具現体はファイルおよび／またはディレクトリの存在を端末に暴露する。スマ ートカードがそのID番号を端末に暴露するのは標準的な慣行であると考えられる 。端末はこの情報を用いてスマートカードの所有者のプライバシに侵入し得ると 考えられる。 少なくとも１つの特定のスマートカードチップにとって、電源電流を時間の関 数として詳細に測定することによってどの命令が実行されているかを決定するの は可能であると考えられるため、たとえ両方のブランチにかかる時間が同じであ っても、端末はIFステートメントのどちら側が実行されたかを決定することがで きる。暗号化技術では通常行われるように、カードで使用される実際のコードが 攻撃者に知られていると仮定する。セキュリティが鍵材料の秘密性にのみ依存す べきであって、鍵に適用されるプロセスの秘密性に依存すべきではないというこ とは、暗号化およびセキュリティシステムのよく確立された原則である。 この好適な実施態様では、カードはこれらの攻撃の下で追加の情報を暴露しな いように注意する。これらの攻撃に対するセキュリティを確実にするために、カ ードは単一の実行通路を使用する。これは、端末にまだ知られておらず端末から のアクセスを持たない情報を含むプロセスに対しては、同じ命令列が常に使用さ れることを意味する。例えば、図９のようなハウスの計算では、アーキテクチャ ー（列数および各列の高さ）は端末にとって秘密ではないが、実際の値は秘密で ある。一定のアーキテクチャーにとって、カードは常に同じ命令列を使用して、 ハウス起源値901からハウス起源値901とは関係のないハウス結果値979を計算す る。 これをどのように実現するかを示す例を図31に示す。ステップ3100、3101、31 02および3103よりなる最初のプロセスは典型的な条件付き実行シーケンスを示す 。 3100で開始して、第１のステップ3101は一定の条件condを検証する。この条件が 偽の場合はプロセスはステップ3103に進み、さもなくばステップ3102に進む。ス テップ3102では、カウンタcntが増分され、２つの変数save1およびsave2にそれ ぞれ値ｘおよびｙが割り当てられる。ステップ3102の後、プロセスはステップ31 03に進み、ここでプロセスは終了する。ステップ3110、3111、3112よりなる第２ のプロセスは、条件付き実行構成を使用しない機能的に等価のプロセスを示す。 プロセスがステップ3110で開始された後、ステップ3111の最初の行為は、条件co ndを、条件が偽の場合は０であり条件が真の場合は１である整数値に変換するこ とである。条件をこのような整数値に変換する標準的な技術が存在し、一定の高 レベル言語の具現体で幅広く使用されている。ステップ3111では値condがこの値 を表すために用いられる。カウンタの増分はここでは加算に置き換えられる。つ まり、値condがカウンタに加えられる。これは、contが１に等しい場合のみカウ ンタを増分するのと同じ効果を有する。条件が偽の場合は、condは０であり、動 作は何の効果も持たない。条件が真の場合は、condは１の値を持ち、加算はcnt の値にちょうど１を加える。行為save1=ｘはもっと複雑な行為save=cond*x+(1-c ond)*save1に変換される。条件が偽の場合は、condは０に等しく、従ってcond*x もまたゼロに等しい。同時に（1-cond）は１に等しく、従って(1-cond)*save1は save1に等しい。両方の式の合計はsave1に等しく、このためこの割り当ては何の 効果も持たない。これは当然ながら最初のプロセスのこの行為を飛ばすことに等 しい。条件が真の場合は、condは１に等しく、（1-cond）は０に等しい。従って この割り当ての右側はｘに等しい値を有する。これは当然ながら、条件が真の場 合にのみ実行される最初のプロセスの行為save1=ｘと等価である。第３の行為は 別の等式を示す。変数save2はインデックス０および１を有する配列に置き換え られる。ｙの値はsave2[cond]に割り当てられる。これは、条件が真の場合はｙ はsave2[1]に割り当てられ、条件が偽の場合はｙはsave2[0]に割り当てられるこ とを意味する。元のsave2変数が新しいsave2[1]に入れられsave2[0]がプロセス 後、破棄される場合は、save2[1]は変数save2がそれぞれのプロセスの後、持っ たのと同じ値を持ち、等価の開始ステートをとる。ステップ3111のこれらの新し い行為は、条件condが真の場合のみ実行 されるステップ3102の行為と機能的に等価であると呼ばれる。プロセスはステッ プ3112で終了する。 もっと詳細な例として、上述した「フレームを見つける」プロセスを示す図18 について述べる。この好適な実施態様では、これは固定実行通路を用いるプロセ スの１つである。ステップ1802、1803、1804および1805よりなるループは固定回 数、すなわち各フレームスロットに対して一回実行される。フレームスロット数 は秘密ではないため、特別な注意を払う必要はない。しかし、ステップ1802およ び1803による条件付き実行により、フレームが見つかったかどうかおよびメモリ のどこで見つかったかが暴露され得る。このデータはいつでも端末にとって利用 可能であるとは限らない。従って、ステップ1802および1803は、図31に示す方法 を用いて単一実行通路で実現される。ステップ1810、1811、1820および1830もま た単一実行通路を用いて実現される。これは、ステップ1820および1830の行為を 、2つの条件の値に依存する単一の行為シーケンスに書き直すことを含む。これ は図31に示す方法の簡単な一般化であり、当業者には明らかである。ステップ18 40への飛び越しは単一実行通路内では行われない。これは「破壊」モードに入り、 これは基本的には以降の正常な処理を妨げる。カードが「破壊」モードに入ったと いうことは端末には全く明らかであるため、この事実を端末に隠す必要はないと 考えられる。 この好適な実施態様では、単一実行通路はすべてのプロセスに用いられるが、 他の実行通路であればさもなくば端末が知り得ない情報を端末に暴露するかもし れない。これが上記の攻撃に対する最良のセキュリティを提供すると考えられる 。明らかに、単一実行通路であるからといって、同じデータがいつでも行為に使 用されるとは限らない。秘密鍵を用いるいかなる具現体も、実行通路およびプロ セスで使用されているデータの両方を決定し得る攻撃者から保護されることは不 可能であると考えられる。 EMV この好適な実施態様はEMVシステムの具現体を含む。当業者であれば、先に言 及したEMVシステムの仕様書について周知であると考えられる。この好適な実施 態様はEMVシステムを実現し、いくつかの改良、とりわけカードによって端末に 送られるデータのダイナミックオフライン認証を組み込んでいる。 この好適な実施態様を図28に示す。プロセスはステップ2800で端末で開始され る。この後ステップ2801が続き、ここでは端末はカードにアプリケーションデー タを要求する。この要求はメッセージ2802へと符号化される。メッセージ2802を 受け取ると、カードはプロセスステップ2803の実行を開始する。ステップ2803で は、カードは要求されたアプリケーションデータをメッセージ2804で端末に送る 。EMVシステムおよびこの好適な実施態様では、このアプリケーションデータの 送付は実際には連続したいくつかの要求を用いて実現されるが、明瞭化のために これらは示されない。メッセージ2804を受け取ると端末はプロセスステップ2805 の実行を開始する。ステップ2805、2807、2808、2809、2811、2812、2814、2816 および2817の実行は、取引がオンラインで行われるときのみ行われる。オフライ ンの場合にはこれらのステップは省略される（詳細についてはEMV仕様書を参照 ）。端末は認証要求を構築しこれを発行者または発行者の代理にメッセージ2806 で送る。メッセージ2806を受け取ると、発行者はステップ2807の実行を開始する 。ここでは発行者は認証要求を処理する。次のステップ2808は、端末のための有 効スクリプトの作成よりなる。この後、ステップ2809で認証レスポンスおよびス クリプトの両方がメッセージ2810で端末に送られる。メッセージ2810を受け取る と端末はステップ2811の処理を開始する。ステップ2811では、端末は発行者から 受け取ったスクリプトを処理する。これは、スクリプトに含まれるコマンドおよ びデータをカードに送りレスポンスを待つことを含む。EMV仕様書では、スクリ プトはステップ2812、2814および2815の外部認証の前または後で実行され得る。 図28には両方の可能性を示す。簡単な拡張により２つのスクリプトを使用するこ とが可能になる。この好適な実施態様は、典型的には、ステップ2811のスクリプ トを実行する。ステップ2811の後、ステップ2812で端末は認証コードをメッセー ジ2813でカードに送る。カードはステップ2814でコードを検証し、検証結果をメ ッセージ2815で端末に送る。メッセージ2815を受け取ると、端末はプロセスステ ップ2816を実行する。ここでは端末はレスポンスを検証する。次のステップ2817 では再びカードと共にスクリプトを実行する(ステップ2811についての記述を参 照)。これまで述べたすべての行為はEMV仕様書を具体化したものである。ステッ プ281 8では、端末はカードの支払いプルーフを要求する。端末はこれをメッセージ281 9で送る。メッセージ2819を受け取ると、カードはステップ2820を実行する。こ こでは、カードは適切な支払いプルーフを計算し結果をメッセージ2821で端末に 送る。メッセージ2821を受け取ると、端末はプロセスステップ2822の実行を開始 する。ここでは端末は支払いプルーフを検証する。この後プロセスはステップ28 23で終了する。 上述のステップのほとんどはEMV仕様書に特定された行為に直接対応する。こ の好適な実施態様はダイナミックな認証をEMV仕様書に追加する。EMVシステムに は、オフラインの場合にカードおよびカードが送るメッセージの正当性を端末に 確信させるための装備はない。ステップ2820の支払いのプルーフ(EMVではTCと呼 ぶ)は秘密鍵プルーフに基づいており、端末にTCを検証させることは意図されな いと考えられる。従って、オフラインの場合には、当該分野では周知のように、 EMVでは端末はリプレイ攻撃を受けやすい。この好適な実施態様は、これを修正 するために緻密な裏書き署名を用いる。ステップ2820では、支払いに第２の要素 が加えられる。TCは依然として送られるが、これに加えてカードは、先に述べた ように任意に長いメッセージを認証し得る変形の緻密な裏書き署名を用いた取引 中に端末に送ったすべてのデータを認証する。メッセージ2821が伝送中に失われ る場合は、端末はカードに、図32に示すようにセッションのプルーフを再伝送す るのと同じ方法でデータを再伝送するように頼むことができる。端末は緻密な裏 書き署名を検証し、これによりカードによって送られたデータの正当性およびこ れによりTCの正確性を確信することができると考えられる。 発行者が作成するスクリプトは、様々な機能を安全に行うために用いられ得る 。典型的なアプリケーションは一定の形態の残高を増やすことである。スクリプ トは端末がカードに送るコマンドセットである。これらは、先に述べたようにセ ッションを構成するように発行者によって選択される。残高を増やすためのカー ドと発行者との間の直接のセッションは、端末と発行者との間に２つより多いメ ッセージを含む。開始セッションプロセス単独で、カードと発行者との間に（お よび従って端末と発行者との間）に２つのメッセージを必要とする。古い制限値 は読み出され、次に新しい制限値が書き込まれなければならないため、もっと多 く のメッセージが必要である。金融取引認証のための現在のほとんどのネットワー クは２メッセージ認証の上に構築されており、さらにメッセージを加えることは 複雑化につながる。この好適な実施態様はセッションを異なる方法で用い、現在 のセッションを使用しまた端末と発行者との間に２つのメッセージしか使用せず に増加を行うことができる。先に述べたように、カードチャレンジはいくつかの カウンタよりなる。これらのカウンタ値はメッセージ2804および2806で送られる データに含まれる。発行者はこの時点で、セッション中のカードの行為をシミュ レートするのに十分な情報を有する。特に発行者はカードが使用するカードチャ レンジについて知っている。これにより発行者はセッションを成功裏に完了させ るために必要なすべてのメッセージを生成することができる。特別な「残高に金 額を追加する」機能の代わりに、この好適な実施態様は標準的なフレームの読出 しおよび書込み機能を用いる。この結果、残高の現在の値もまたメッセージ2804 および2806に含まれる。発行者はスクリプトに「フレームを読み出す」機能を含む 。発行者は既に答えを知っているが、先に述べたように答えはまたチェーン化さ れてセッションステートになる。スクリプトの実行前に残高が異なる値に変更さ れる場合は、カードのチェーンステートが異なる。この結果「セッションにコミ ット＆セッションを終了」プロセスでのプルーフが失敗する。限定されない1つの 例としては、完全なスクリプトは、「セッションを開始＆プルーフ鍵」コマンド、 残高の「フレーム読出し」、残高の「フレーム書込み」、および「セッションにコ ミット＆セッションを終了」コマンドよりなる。端末がスクリプトを許可しない のを防ぐために、メッセージ2813で送られる認証コードはスクリプトのデータに 依存する。これにより、端末がスクリプトを実行しない場合は認証は失敗する。 当業者には明らかなように、認証コードは、スクリプトがステップ2817で実行さ れる予定であることをカードに通知するために使用され得る。 スクリプトを行うプロセスを図33にさらに詳しく示す。プロセスはステップ33 00で端末で開始され、ステップ3301に続く。ここでは端末はインデックス変数ｎ をゼロに設定する。次のステップ3302は、スクリプトにｎ番目のコマンドが存在 するかどうかをチェックする。ｎ番目のコマンドが存在しない場合は、プロセス はステップ3309に進む。ｎ番目のコマンドが存在する場合は、プロセスは3303に 進む。ステップ3303では、端末はスクリプトのｎ番目のコマンドおよびその関連 データをメッセージ3304で端末に送る。メッセージ3304を受け取ると、カードは ステップ3305の処理を開始する。ここではカードはコマンドに関連する行為を行 い、レスポンスをメッセージ3306で端末に送る。メッセージ3306を受け取ると、 端末はステップ3307の処理を開始する。ここでは端末はレスポンスをチェックし てエラーコードを調べる。カードがエラーを報告した場合は、プロセスはステッ プ3310に進む。カードがエラーを報告しなかった場合は、プロセスはステップ33 08に進み、ここで端末はｎ変数を１つだけ増分する。プロセスは次にステップ33 02に進む。ステップ3309では、端末はスクリプトプロセスが成功裏に完了したこ とを知らせる。ステップ3310では、端末はスクリプトプロセスの失敗を知らせる 。いずれの場合もプロセスはステップ3311に進みプロセスは終了する。 EMV仕様書は、オンライン取引のための、カードが行う非特定の「リスク管理」 、端末が行う特定の「リスク管理」、および発行者が行う非特定の認証プロセス を含む。この好適な実施態様は、クレジットカード取引、プリペードデビットカ ード取引、ATMカード取引などを実現するために用いられ得る一般的な構造を用 いる。カードは、このアプリケーションを用いてまだ使うことができる金額を表 す残高を保持する。支払いが成功する場合は、カードは支払いの金額によってこ の残高を減らす。カードは、カードの残高を超える金額に対するオフライン支払 いを拒絶し、オンライン取引を要求する。カードの残高を増やすためには、発行 者はスクリプトに残高を増やす適切なコマンドを送り得る。この好適な実施態様 では、カードは成功裏に完了した取引に対してのみATC（アプリケーション取引 カウンタ）を増やす。 この好適な実施態様では、カードがARQCを発行してオンライン取引を要求する と、カードはオンライン取引が成功裏に完了するまではオフライン取引を行わな い。 この好適な実施態様では、発行者はオンライン要求、およびオフライン支払い に関する端末から(恐らく取得者を介して)受け取るすべての支払いデータのデー タベースを保持する。いずれのオフラインまたはオンライン支払いに対しても、 発行者に届くデータにはカードのATC値が含まれる。オンライン取引に対しては 、 カードの残高が発行者に送られるデータに含まれる。異なる取引に関する情報は 、非年代順で発行者に届く。カードは成功した取引に対してのみATCを増やすの で、発行者は「前の」取引をあと何回期待できるかを正確に知る。詳しくは、いか なるオンライン取引においても、発行者はカードの現在のATCを知り、従って前 のオンライン取引以来カードがオフライン取引を何回行ったかを知る。発行者は またカードの現在の残高を知り、従って前のオンライン取引以来のオフライン取 引の合計金額を決定することができる。これにより、発行者がオンライン取引に 対して必要な決定を行うのに十分な情報およびカードの残高を増やすための可能 なスクリプトが得られると考えられる。 カードと発行者との間の対話を図47に示す。これはカード4700、端末4704およ び発行者4706を示す。カードは残高(CB)4701、暗号文カウンタ(ATC)4702および いくつかのカードカウンタ4703を有する。この好適な実施態様では、２つのカウ ンタが存在する。一方は各「コミット」プロセスに対して増分され、他方は各「 コミット」または「取消」プロセスの間に増分される。これらのカウンタはセッ ション中のカードチャレンジとして使用される。カードと端末とは通信チャネル 4720を通して通信する。端末と発行者とは通信チャネル4721を通して通信する。 取引の間、端末は典型的には発行者に単一のメッセージを送り、発行者は単一の メッセージで返答する。発行者は3つのデータベース、すなわち、カードベース4 708、イベントベース4709および端末ベース4710を使用し、通信チャネル4722を 用いてこれらのデータベースと通信する。端末ベースは各端末に関連するデータ を含むが、明瞭化のために示されてはいない。図48はカードベースのレコードの データフィールドを示す。第１フィールド4800は基本口座番号(PAN)および連続 番号を含む。これはカードの固有の自己証明であり、基本口座番号は通常はクレ ジットカード番号または銀行口座番号に対応し、連続番号は同じPANを使用する いくつかのカード、例えば、限定はされないが、同じ口座の２つのクレジットカ ードを区別する。次のフィールド4801はカードの状態および構成についての情報 を含む。これは明瞭化のために詳細には示されない。フィールド4802には、カー ドの最も高い既知のATCが格納される。フィールド4803には最後に完了したオン ライン取引のATC値、すなわち発行者が対応するTCを受け取ったATC値が格納され る。フィールド4804には、発行者は受け取った最後のARQCのためのATCを格納す る。フィールド4805には、発行者は既知のカード残高KCBを維持する。これはカ ードの現在の残高の発行者による最良の概算である。最後のフィールド4806は設 定金額SAを含む。これは、発行者が次のオンライン取引でカードの残高に加えよ うと計画する金額である。図49はイベントベースのレコードのフィールドを示す 。各レコードが１つのイベントを表す。最初のフィールド4900はPANおよび連続 番号を含む。これはカードを固有に識別する。フィールド4901はイベントのATC を含み、フィールド4902はイベントの状態を含み、フィールド4903はイベントの 金額を含み、フィールド4904はイベントのためのカードカウンタ値を含み、フィ ールド4905はイベント中のカードの残高を含み、最後にフィールド4906はイベン トのための設定置を含む。 図50は、オンライン取引中の発行者の処理の包括的な概観を示す。最初のステ ップ5000では、発行者は端末データおよびカードデータを含む取引のための認証 要求を受け取る。端末データは典型的には端末IDを含む。カードデータは典型的 にはPANおよび連続番号、取引金額、カードカウンタの現在の値、カード残高、 現在のATCなどを含む。次のステップ5001では、発行者は受け取ったデータの有 効性の初歩的なチェックを行う。ステップ5002では、発行者は、実際のカード残 高CBに基づいて既知の残高KCBを更新する。ステップ5004では、発行者はカード のための清算金額をチェックし、これをスクリプト金額に加える。ステップ5005 では、発行者は取引を受け入れるかどうかを決定し、最後にステップ5006では、 発行者は取引のための認証を、残高の必要な調整を行うためのオプションのスク リプトとともに端末に送る。図51は、発行者が端末からオフライン取引に関する 取引データを受け取るときの発行者の処理の包括的な概観を示す。最初のステッ プ5100では、発行者は取引データを受け取る。これは典型的には端末の識別子、 カードデータ、金額、および取引暗号文を含む。次のステップ5101では、発行者 は端末およびカードデータの有効性をチェックする。ステップ5102では、発行者 は取引の有効性をチェックする。とりわけ暗号文が正確であることをチェックす る。最後のステップ5103では、発行者は、取引と共に与えられるカード残高に基 づいて既知のカード残高KCBを更新する。 図52は、図52Aと図52Bとして示される２つの部分に分かれている。図50におい てより概略的に示す、オンライン取引中の発行者による処理をより詳細に示す。 この処理のいくつかのステップは、簡潔化のために示さない。第１のステップ52 00は、処理の開始である。この時点において、発行者は、すでに、カードID、端 末ID、ATC、ARQC、金額、カードカウンタ、カード残高CBなどを含む認証要求を 受け取っている。次のステップ5201において、発行者は、「スクリプト額」と呼 ばれる変数をゼロに設定し、「テンプkcb」と呼ばれる変数を、与えられたカー ド残高CBに設定する。「スクリプト額」変数は、スクリプトが生成される対象と なる額を含み、「テンプkcb」は、発行者により格納されたKCBを更新するために 用いられる。発行者は、問題となっているカードの記録をカードベースでチェッ クし、また問題となっている端末の記録を端末ベースでチェックする。発行者は 、ARQC暗号化記号が有効であること、端末が有効であること、カードの期限が切 れていないこと、およびカードがまだブロックされていないことを検証する。次 のステップ5202において、発行者は、HATC（知られている最も高いatc）が、現 行のATCより低いかどうかをチェックする。低くなければ、参照符号5250および5 212により示すように、処理はステップ5213に続く。この場合、カードのATCは、 そのカードの知られている最も高いATCよりも低く、従って、カードのATCは減少 されなければならない。うまく機能しているカードは、ATCを減少させることは ないため、これは、カードにより試みられた詐欺である「カード詐欺検出」とし て分類される。「カード詐欺検出」とは実際、カードの不正改変不可能性が破ら れたに違いないこと、カードが故障したに違いないこと、またはシステム内の何 か他のものが誤っていることを意味する。ステップ5202の状況が本当である場合 、処理はステップ5203に続く。ステップ5203において、発行者が、ATCは前回の 認証要求のATCと等価であるかどうかをチェックする。等価であれば、処理はス テップ5204に続く。等価でなければ、処理はステップ5214に続く。ATCがLAATCと 等価であれば、前回の取引はうまく完了していない。なぜなら、もしうまく完了 していればATCは増加していたはずだからである。従って、同一のATC値を有する 第２の認証要求を得るということは、前回の取引が完了しなかったことを示唆す る。しかし、スクリプトが実行されたが取引は完了しなかったということはあり 得る。 好適な実施形態中の全てのスクリプトがカード残高を改変するため、発行者はス クリプトが行われたかどうかを検出することができる。残高を改変しないスクリ プトに対しては、この機能に対して何らかの他の値が用いられることが予想され る。好適な実施形態において、オンライン取引が失敗に終わった後、カードがオ フライン取引を行うことはない。従って、オフライン取引は、失敗したオンライ ン取引と次のオンライン取引との間には起こり得ない。ステップ5204において、 発行者は、イベントベースに記録されたイベントをチェックすることにより、前 回の認証要求中にスクリプトが発行されたかどうかをチェックする。スクリプト が発行されておらず従ってCBの更新も未だなされていない場合、処理はステップ 5205に続く。それ以外の場合、処理はステップ5206に続く。ステップ5205におい て、発行者は、前回の認証要求に対してイベントベースに記録された残高が、現 在のカード残高と同一であるかどうかをチェックする。同一でなければ、処理は （5210および5212を介して）ステップ5213に続く。それ以外の場合、処理は（52 11および5222を介して）ステップ5223に続く。ステップ5206において、発行者は 、CBが前回の認証要求中にイベントベースに記録された残高と等価であるかどう かをチェックする。等価であれば、処理は5208に続く。それ以外の場合、処理は ステップ5207に続く。ステップ5207において、発行者は、カード残高が、前回の 認証要求に対して記録された残高と、上記認証処理中に発行されたスクリプトの 更新額との総額であるかどうかをチェックする。総額でなければ、カード残高は 説明できない様式で変化したことになり、処理は（5210および5212を介して）ス テップ5213に続く。それ以外の場合、処理はステップ5209に続く。ステップ5208 において、発行者は、前回のオンライン取引のスクリプトが完了しなかったこと を知っており、スクリプトの更新額を「スクリプト額」変数に追加する。次のス テップ5209において、発行者は、前回のオンライン取引のスクリプトに関する情 報を「完了した」または「未完了」のいずれかとして含むイベントベース内の記 録をマークする。そうすると、スクリプトは、もはや未完了ではない。ステップ 5209の後、処理は（5211および5222を介して）ステップ5223に続く。ステップ52 13において、処理は停止し、エラーを検出している。ステップ5214において、発 行者は、前回の認証要求atcLAATCが-1と等価であるかどうかをチェックする。等 価 であれば、処理はステップ5219に続く。それ以外の場合、処理は5215に続く。値 -1は、前回の認証要求が成功した取引の一部であったことを示すために用いられ る。ステップ5215において、発行者は、CBを更新するための未完了のスクリプト がまだあるかどうかを、イベントベースでチェックする。未完了のスクリプトが あれば、処理はステップ5217に続く。それ以外の場合、処理はステップ5216に続 き、そこで、「テンプkcb」変数が、前回の認証要求中の残高に設定される。ス テップ5217において、「テンプkcb」変数は、前回の認証要求中の残高と、未完 了のスクリプトの更新額との総額に設定される。次のステップ5218において、問 題となっているスクリプトは、「完了した」とマークされ、それにより「未完了 」リストから除去される。ステップ5217および5218において、未完了のスクリプ トがあった。現在、新しいATCが発行者により見られ、従って、前回の取引はう まく完了した。ステップ5219の開始時において、「テンプkcb」変数はカードの 現在の残高の上限であり、ステップ5219において、発行者は、カードの残高CBが 「テンプkcb」より大きいかどうかをチェックする。大きければ、処理は（5220 および5212を介して）ステップ5213に続く。それ以外の場合、処理は（5221およ び5222を介して）ステップ5223に続く。ステップ5223において、発行者は、合意 額が正であるかどうかをチェックする。正でなければ、処理はステップ5225に続 く。それ以外の場合、処理はステップ5224に続き、そこで、合意額が「スクリプ ト額」変数に追加され、その後処理がステップ5225に続く。ステップ5225におい て、発行者はまず、取引額が、最高でも、現在のカード残高BCと「スクリプト額 」変数との総額であることを検証する。総額でなければ、カード残高は不十分で あり、発行者は取引の認証を与えない。次に、発行者は、スクリプト額がゼロか どうかをチェックする。ゼロでなければ、処理はステップ5227に続く。それ以外 の場合、処理はステップ5226に続き、そこで、発行者は、入手可能なデータを用 いてカード用のスクリプトを作成し、必要不可欠なスクリプト情報をイベントベ ースに追加し、そして、カードベースの合意額をゼロに設定する。その後、処理 はステップ5227に続く。ステップ5227において、発行者は、LAATCが-1と等価で ないかどうかということと、ATCがLAATCよりも大きいかどうかということとをチ ェックする。そうでなければ、処理はステップ5229に続く。それ以外の場合、 処理はステップ5228に続き、そこで、LOATC値がLAATCに設定され、その後、処理 はステップ5229に続く。ステップ5229において、発行者は、この取引に関する必 要不可欠な情報を含むイベントベースに、記録を追加する。次のステップ5230に おいて、発行者は、LAATC値をATCに更新し、HATCをATC-1に更新し、KCB値をCBに 更新する。その後、処理はステップ5231で終了する。処理の後、発行者は、端末 に、認証暗号化記号、オプショナルなスクリプトなどを含むレスポンスを送信す る。 図53は、図51においてより概略的に示した、発行者がオフライン取引の取引デ ータを受け取ったときの発行者の処理を、より詳細に示す。処理の開始前に、発 行者は、典型的にはカードPANとシーケンス番号、額、端末ID、ATC、カード残高 などを含む取引データを受け取る。発行者は、そのカードに関連する記録をカー ドベースから検索する。発行者は、様々なIDの有効性を検証し、取引暗号化記号 TCが有効であるかどうかをチェックする。発行者は、PAN／シーケンス番号／ATC の組み合わせをイベントベースでチェックすることにより、この取引番号が以前 にあったかどうかをチェックする。ステップ5300で処理が開始する。次のステッ プ5301において、発行者は、ATCが、発行者がカード用に有するHATCよりも大き いかどうかをチェックする。大きくなければ、処理はステップ5303に続く。それ 以外の場合、処理は5302に続き、そこでHATC値がATC値に設定され、その後、処 理はステップ5303に続く。これらのステップは、HATC値が、有効なTCが受け取ら れる対象である最大のATC値として維持されることを保証する。ステップ5303に おいて、発行者は、LAATCが-1と等価であるかどうかということと、ATCがLAATC 以上であるかどうかということとをチェックする。そうでなければ、処理はステ ップ5309に続く。それ以外の場合、処理はステップ5304に続く。ステップ5304に おいて、発行者は、LOATCをLAATCに設定し、且つLAATCを-1に設定する。このこ とは、LOATC値を維持するために役立つ。LOATC値は、発行者がオンライン取引が そのカードで成功したということを知っている対象である前回のATC値として定 義される。次のステップ5305において、発行者は、前回のオンライン取引中にス クリプトが発行されたかどうかを、イベントベースをチェックすることによりチ ェックする。発行されていれば、処理はステップ5307に続く。それ以外の場合、 処理はステップ5306に続く。ステップ5306において、発行者は、発行者が前回の 認証要求中に受け取ったKCB値をカード残高に設定し、処理はステップ5309に続 く。これは、現在のカード残高の上限である。ステップ5307において、発行者は 、KCB値を、前回の認証要求中のカード残高と、上記要求のスクリプトにおいて 用いられる更新値の額との総額に設定する。これも、現在のカード残高の上限で ある。次のステップ5308において、発行者は、スクリプトに関連するイベント記 録を「完了した」とマークする。ステップ5309において、発行者は、ATCがLOATC 以上であるかどうかをチェックする。そうであれば、ステップ5310において取引 額かKBC値から減算される。このプロセスは、ステップ5311で終了する。 図52および図53に示すプロセスは、カード残高を維持し、カードが意図される よりも高い残高を獲得しないことを保証し、そしてカードの残高を増加しようと する如何なる試みも完了しないことを保証する安全な方法を実行する。 図52および図53に示すプロセスは、好適な実施形態において実行されるように 、かなりカードに特異的である。当業者には自明であるように、発行者のアクシ ョンの正確な順序およびタイプは、様々な実行詳細に依存して変わり得る。 クレジットカードアプリケーションにおいて、残高はOTB(Open to Buy)である 。これは、取引が拒絶される前に、ユーザがクレジットカードに課すことができ る金額である。ほとんどの現行のクレジットカードは、このようなOTB限界（ク レジット限界と呼ばれることもある）を有すると考えられている。カードにOTB を維持させることは、OTBを越える危険なく、オフライン取引がなされることを 可能にすると考えられている。このような状況において、OTBは増加されるべき である。このような状況の典型的な例は、ユーザが未払いのクレジットカード請 求に対する支払いをしたときである。支払われた額は、OTBに追加され得る。入 手可能な通信リンクがないために、典型的には、このことはカードに直接通信さ れない。カードは、オンライン取引が起こるまで、古いOTB値を用い続ける。オ ンライン取引を行う、可能性のある理由は、カードのOTBが使い果たされること であると考えられている。上記取引中、発行者は、スクリプトをカード送信して 、OBTを新しい値に増加させて更なるオフライン取引が起こることを許可する。 好適な実施形態は、取引の小さな部分がオンラインにある状態で、セキュリティ を 侵犯することなく、このように用いられ得ると考えられている。クレジットカー ドはまた、EMVシステムを用いない、従来のクレジットカード取引を行うために 用いられ得る。この結果、OTBはカードが認識することなく減少されることがあ り得る。発行者は、カードのOTBを減少させるためにスクリプトを用いることが できると考えられている。当業者にとって自明であるように、発行者はまた、ク レジットカードの「本当の」OTBを分割して、その一部をオフライン取引に用い ながら、他方で他の部分を発行者側で保管し、従来のクレジットカード取引に用 いることができる。発行者は、スクリプトを用いて、このような設定において、 発行者側に残っているOTBに応じて、カードのOTBを増加または減少させ、それに より２つのOTBのうちの一方が他方よりも多く使い果たされた場合に備えて２つ のOTBのバランスをとる。 予納型引き落としアプリケーションの場合、残高は、カードに格納される金額 を表す。この額は支払いの間、典型的には減少する。この場合も、残高が使い果 たされるまで、カードは任意の回数のオフライン取引を行うことができる。オン ライン取引において、発行者は、スクリプトを用いて残高を増加することができ る。予納型のアプリケーションにおいて、このことは、ユーザが、カードに入れ た追加の金額を発行者に支払うことを必要とする。このことは、例えば、銀行口 座からの引き落とし（現行のATMにおける現金の引き出しに類似）を一体化する ことにより達成され得るが、これには限られない。オンライン取引の間、カード はすでに認証されている。EMV仕様はすでに、PINコードのエントリなどのカード 保持者検証手続きを含むことを許可している。カードの認証およびPINコードの エントリは、ATMにおける現行の現金引き出しと同一の機能性を供給し、カード 保持者の銀行口座から引き落とされる予納型引き落としにおいて用いられる可能 性がある。カードの残高は振り込まれる。好適な実施形態において、カードは、 取引中にPINを必要とするオプションを有する。その場合、カードは、有効なPIN なしに取引を完了せず、カードにより強制的に絶対必要とされるPINは、EMV仕様 には含まれない。当業者にとって自明であるように、カードにより強制的に絶対 必要とされる検証はまた、他のいずれのカード保持者の検証方法にも適用され得 る。 オンライン引き落としアプリケーションにおいて、残高自体は、本当に必要で はない。残高は、それに非常に大きな値を与える手段のなかの様々な手段により 無効にされ得る。上記のカードの認証およびカード保持者の検証は、オンライン 取引において、直接カード保持者の銀行口座からの引き落としを行うために用い られ得る。オンライン取引はまた同時に、端末所有者の銀行口座に振り込む。 当業者にとって、単一のカードがいくつかのEMVコンパチブルなアプリケーシ ョンを含み得、従ってこれらのアプリケーションに用いられ得ることは自明であ る。 カード命令 好適な実施形態において、カードはスマートカードであり、ISO7816標準プロ トコルを用いて端末と通信する。このプロトコルにおいて、端末は、一連のコマ ンドをカードに送信する。すべてのコマンドは、端末からカードに送られるコマ ンドヘッダと、端末からカードへの何らかのオプショナルなデータ伝送と、カー ドから端末への何らかのオプショナルなデータ伝送と、さらにカードから端末に 送られる結果コードとから構成される。コマンドが用いられることが意図される シークエンスを図29に示す。カードは、他のいずれのシークエンスをも許可しな い。いずれかの時点において、端末はステップ2900で開始し得、矢印に従って進 み、出くわした順番にコマンドを発行する。ステップ2900の後、端末は、2901、 2920、2921または2930に続く。 ステップ2901において、端末は、図25の、協同で開始セッションプロセスを実 行する２つのコマンドのうちの１つめのコマンドを送信する。次に、ステップ29 02において、端末は、開始セッションプロセスの第２のコマンドを送信する。そ の後、端末は、「フレーム獲得」2903、「フレーム配置('put frame')」2904、 「フレーム引き落とし」2905、「フレーム再引き落とし」2906、「フレーム廃棄 」2907、および「公開引き落とし」2908のセットからの１以上のコマンドを送信 する。コマンドのこのシークエンスの後、端末は、セッションを終了させる「コ ミット」コマンドを送信し、上記の「コミット」プロセスを実行する。セッショ ンの後、端末は、再び開始し、「プルーフ獲得」コマンド2920を発することによ り前回のセッションからのプルーフを得、プルーフがうまく読まれたときに 「実行済み」コマンド2921を発する。上記したコマンドは、基本的カード機能を 実行する。 EMVの実行は、ほとんど別々で、上記のEMV仕様に準拠している。EMVは、ステ ップ2930で始まり、そこで、端末が「ファイル選択」コマンドを送信する。「フ ァイル選択」コマンドは、何回でも繰り返される。新しい取引を開始するために 、端末はステップ2931に続く。再び前回の取引のプルーフを得るために、端末は ステップ2930の後、「前回のAC獲得」コマンド2940を発する。ステップ2931にお いて、端末は、「アプリケーション１管理」コマンドを発し、その後「ファイル 獲得」コマンド2932および「データ獲得」コマンド2933のいずれかを１回以上実 行するループに入る。このループの後、端末は、「検証」コマンド2934を１回以 上送信する。（検証コマンドの実行は、このような状況においてオプショナルで あるが、これは簡潔化のためここには示していない。）次のステップは、端末が 「AC1生成」コマンドを送信することである。オフライン取引の場合、端末はス テップ2939に続き、オンラインの場合、端末は、ステップ2936に続き、そこで、 スクリプトからの一連のコマンドをカードに送る。2936に現れるコマンドは、点 線で示すフレーム2910に現れるものと同一であり、簡潔化のため詳細には示さな い。ステップ2936の実行は、オプショナルである。次のコマンドは、「外部認証 」2937であり、その後、端末はステップ2938で「AC2生成」コマンドを送る。コ マンド2937および2938はオプショナルである。最後に、端末は、「アプリケーシ ョン２管理」コマンドを送信する。 オフライン取引の場合、図28と図29との相関は以下のようである。ステップ29 30および2931は、管理用であり、図28には示さない。ステップ2801および2803は 、コマンド2932および2933を用いて実行される。コマンド2934は、簡潔化のため 図28には示さない。オフライン取引の場合、ステップ2805〜2817は実行されない 。ステップ2818および2820は、コマンド2935に対応し、端末が発する次のコマン ドは、簡潔化のため図28には示さない2939である。 オンライン取引の場合、図28と図29との相関は以下のようである。ステップ29 30および2931は管理用であり、簡潔化のため図28には示さない。コマンド2932、 2933、および2935は、協同してステップ2801および2803を実行する。コマンド29 34は、簡潔化のため図28には示さない。ステップ2811のスクリプトは、コマンド 2936に対応し、コマンド2936は、基本的に任意のセッションを含む。外部認証コ マンド2937は、ステップ2812、2814、および2816に対応する。ステップ2817は、 図29に示すコマンドセットにはサポートされない。ステップ2818および2820はコ マンド2938により実行され、コマンド2939は簡潔化のため図28には含まれない。 図34、図35、図36、図37および図38は、全てのコマンドの詳細なステップを示 す。全てのコマンドは、３つのステップから構成される。ここでは、「セッショ ン１開始」コマンドを例として用いる。第１のステップ3400は、端末により実行 される。端末は、メッセージ3401をカードに送る。上記カードは、いずれのコマ ンドが実行されているのか、およびいずれが何らかの他のデータを含み得るのか をカードに知らせるコマンドコードを含む。カードは、メッセージ3401を受け取 ると、第２のステップ3402の実行を開始する。これは、メッセージ3403を端末に 送り返すカードを含む。このメッセージは、何らかのオプショナルデータと結果 コードとから構成される。メッセージ3403が端末により受け取られると、端末は 第３のステップ3404の実行を開始する。第３のステップにおいては、前回のメッ セージのコンテンツの分析以外はいずれのアクションも行われない。各コマンド は、単一のAPDUに対応するが、ISO7816標準に記載された２つのT=0コマンドとし て実行され得る。同一のストラクチャが各コマンドに関して繰り返される。同一 のストラクチャは、全てのコマンド、すなわち、（3410、3411、3412、3413、34 14）、（3420、3421、3422、3423、3424）、（3430、3431、3432、3433、3434） 、（3500、3501、3502、3503、3504）、（3510、3511、3512、3513、3514）、（ 3520、3521、3522、3523、3524）、（3530、3531、3532、3533、3534）、（3600 、3601、3602、3603、3604）、（3610、3611、3612、3613、3614）、（3620、36 21、3622、3623、3624）、（3630、3631、3632、3633、3634）、（3700、3701、 3702、3703、3704）、（3710、3711、3712、3713、3714）、（3720、3721、3722 、3723、3724）、（3730、3731、3732、3733、3734）、（3800、3801、3802、38 03、3804）、（3810、3811、3812、3813、3814）、（3820、3821、3822、3823、 3824）、（3830、3831、3832、3833、3824）、および（3930、3931、3932、3933 、3934）に各々対応する事項（3400、3401、3402、3403、3404）に関して繰り返 される。 これらのコマンドのいずれもを、各々の第１のステップの参照符号で呼ぶ。 「セッション１開始」コマンド3400において、端末は、いずれの鍵がセッショ ンにおいて用いられるかを示すビットマスクと端末チャレンジとを送信する。こ れは、図25のステップ2501に対応する。カードは、ステップ2503に対応して、カ ードチャレンジを送り返す。「セッション２開始」コマンド3410において、端末 は、ステップ2505に対応して、鍵を知っていることのプルーフをカードに送る。 カードは、レスポンスコードによってのみ応答する。「フレーム獲得」コマンド 3420において、端末は、読まれるべきフレームのタグフィールドをカードに送り 、カードは、（暗号化された）カードデータとこのデータの認証（プルーフ）と で応答する。「フレーム配置('put frame')」コマンド3430において、端末は、 タグ、アクセスフィールド値、データおよび認証プルーフをカードに送る。カー ドは、レスポンスコードを送る。「フレーム廃棄」コマンド3500において、端末 は、除去すべきフレームのタグとカードの認証プルーフを送る。カードは、レス ポンスコードで応答する。「フレーム引き落とし」コマンド3510において、端末 は、引き落とすべき残高の識別子と引き落とし額とを送る。カードは、示された 残高から与えられた額を減算し、レスポンスコードを送る。「フレーム再引き落 とし」コマンド3520において、端末は、再引き落としをすべき残高の識別子と、 再引き落とし額と、再引き落とし鍵とを送る。カードは、レスポンスコードで応 答する。「公開引き落とし」コマンド3530において、端末は、残高インジケータ と、支払い額と、ランダムチャレンジとをカードに送る。カードは、レスポンス コードで応答する。「コミット」コマンド3600において、端末は、セッションプ ルーフをカードに送り、カードは、レスポンスコードで応答する。「実行済み」 コマンド3610において、追加のコマンドのやりとりはない。「プルーフ獲得」コ マンド3620において、端末は、コマンドヘッダのみをカードに送る。カードは、 セッションプルーフと、必要に応じて公開プルーフとで応答する。「ファイル選 択」コマンド3630において、端末は、AIDまたはRIDをカードに送り、カードは、 FCIで応答する。「アプリケーション１管理」コマンド3700において、端末は、 「INIT」コードをカードに送り、カードは、レスポンスコードで応答する。「ア プリケーション２管理」コマンド3710において、端末は、「EXIT」コードをカー ドに 送り、カードは、レスポンスコードで応答する。「データ獲得」コマンド3720に おいて、端末は、データオブジェクトタグをカードに送り、カードは、データオ ブジェクトで応答する。「ファイル獲得」コマンド3730において、端末は、ファ イル番号と記録番号とをカードに送り、カードは、要求された記録で応答する。 「AC1生成」コマンド3800において、端末は、要求されたACタイプとTDOL値とを カードに送り、カードは、ACタイプと、ACと、ATCとで応答する。「AC2生成」コ マンド3810において、端末は、要求されたACタイプを送り、カードは、ACタイプ と、ACと、ATCとで応答する。「外部認証」コマンド3820において、端末は、認 証プルーフをカードに送り、カードは、レスポンスコードで応答する。「検証」 コマンド3830において、端末は、CVMメソッドとCVMデータとをカードに送り、カ ードは、レスポンスコードで応答する。「前回のAC獲得」コマンド3930において 、端末は、コマンドコードのみをカードに送り、カードは、ACタイプと、ACと、 ATCとで応答する。 クリアリングメソッド カードと端末との間の取引が一旦完了すると、異なる取引からの情報が収集さ れて組み合わせられるクリアリングプロセスがあり得る。上記プロセスを記載す るためにここで用いるクリアリングの例は、金融支払いのクリアリングである。 端末に対する支払いを行うために、カードが用いられる。クリアリングシステム の一例は、端末が支払いに関する全ての取引情報を取得者／発行者に送信し、取 得者／発行者は、額を追加し且つ端末の口座に総額を振り込むというものである 。取得者104の役割は、いくつかの端末から情報を収集して、端末に、受け取っ た支払いに対して「本当の」お金で返済することである。発行者がお金を供給し て取得者がそれを受け取ると、発行者と取得者との間に何らかの種類の合意がな されたことになる。典型的には、発行者と取得者とは同一の組織の一部分である か、または近接して協同的に働く組織である。異なる状況において用いられ得る いくつかの異なるクリアリングメソッドを説明する。 フルデータ：最も簡単なクリアリングメソッドのうちの１つは、端末が、カー ドとの支払い取引からの全ての関連するデータを保持することである。クリアリ ングの間、端末は、全てのデータを取得者に送り、取得者は、全ての取引証明を 検証して端末に振り込む。これにより、取得者は、全ての取引をフルに扱う代わ りに、全ての取引詳細に対するアクセスを得る。 SAMをトランケートする：端末はまた、安全なアプリケーションモジュール(SA M)を備え得る。これは、取得者によって作成された不正改変不可能なデバイスで ある。SAMの機能は、取引データを検証して全ての受け取られた支払いの値を総 計することである。その後取引データは、破棄される。このプロセスは、通常、 トランケーションと呼ばれる。クリアリングプロセスの間、SAMは、取得者に受 け取った総額を知らせ、暗号化記号を用いて取得者に対するこのような趣旨のメ ッセージに署名する。 いくつかの個々の支払いでSAMをトランケートする：端末は、ここでもSAMを備 え得る。SAMをトランケートする場合同様、SAMは、取引データを検証して総額を 記録する。しかし、全ての取引データが破棄されるわけではなく、一部の取引の 一部の又は全部の取引データは保持される。クリアリングプロセスの間、このデ ータは、取得者にも送られる。いずれの取引データが保持されるかを選択する選 択プロセスは、端末により、SAMにより、またはその組み合わせにより様々な方 法で行われ得る。 スケルトン取引でSAMをトランケートする：端末内のSAMは、全ての取引を検証 するために用いられる。各取引に関して、スケルトン取引情報のみが端末により 保持される。これは、典型的には、金額、日付、時刻、カードのID（入手可能で あれば）などを含む。スケルトンデータは、クリアリングプロセス中に取得者に 送られる。SAMは、取得者に送られたスケルトンデータが正しいものであること を（ディジタル署名スキームを用いて署名することにより）保証し、必要であれ ば、取引の総額を記録して取得者に別途送金する。 統計的チェックによるスケルトン取引：この解決法において、端末は、全ての 取引に関する全ての取引データを保持する。クリアリングプロセスの間、端末は まず、全ての取引に関するスケルトン情報を送る。これは、典型的には、金額と 、取引データの残りを独自に固定する何らかの情報、例えば、取引データの残り に関する暗号化記号ハッシュなどとを含む。その後、取得者は、いくつかの取引 に関する完全な取引データを望み、それを端末が取得者に送信する。その後、取 得 者はこれらの取引を検証する。 統計的チェックによるバイナリハッシュツリー：このメソッドは、端末が全て の取引データを保持するという点で上記のものと似ている。全ての取引に関する スケルトン情報を送信することに代えて、端末は、固定された量のデータのみを 取得者に送り、取得者は、その後、適切に扱われていることを検査する取引のサ ブセットを選択し得る。端末は、バイナリツリーを構築する。バイナリツリーに おいて、各ノードは、２つの値、すなわち、金額とハッシュとを含む。各取引に ついて１つのリーフがあり、これは取引額と取引データのハッシュとを含む。各 非リーフノードの額は、サブノードの額の総計である。各非リーフノードのハッ シュ値は、サブノードの全てのデータの暗号化記号ハッシュである。端末は、取 得者に、取引の回数（これもツリーの構造を決定する）を送信し、さらに、ツリ ーのルートの額とハッシュ値とを送信する。その後、取得者は、取引のサブセッ トを選択し、選択したものを端末に送る。端末は、選択された取引の取引データ と、さらにいくつかのノードにおける額とハッシュ値とを送ることにより応答す る。いずれのノードを送るべきかという選択は、取得者による選択に依存する。 選択されたノードは、選択された取引のリーフを含まない最大のサブツリーのル ートにあるものである。換言すると、ハッシュがいずれの選択された取引にも依 存しないがペアレントノードも選択された取引に依存しないノードである。これ らの値を与えられて、取得者は、選択された取引を検証し、バイナリツリーのう ちの、ルートからいずれかの選択された取引への通路上にある部分を検証する。 クリアリングメソッドのうちのいくつかにおいて、発行者は、起こった全ての 取引を記録することができる。カードは不正取引改変不可能であるが、不正取引 防止可能ではない。本発明が防止しようとすることは、カードを「破壊」し、カ ードから全ての秘密の情報を抽出し、多くの複製カードを作成することである。 上記カードの複製はクローニングとも呼ばれる。各取引が、カードがシークエン スにおいて用いる独自の番号を有する場合、発行者は、クローンされたカードが 古い取引番号を再使用するか、または順序が異なる番号を用いたときに、クロー ニングを検出することができる。取引番号が全て発行者に送信される限り、この ことにより詐欺の検出が可能になる。詐欺が一旦検出されると、発行者は、クロ ーンされたカードをブラックリストに載せることができる。 カードが一般的なディジタル署名スキーム、または秘密鍵ベースの認証システ ムを用いる場合、データ内の取引カウンタが認証されることを含むことは容易で ある。現在構築及び／又は提案されているほとんどのシステムは、実際にこのよ うな取引カウンタを有している。上記に開示したコンパクトな裏書署名は、固有 の番号システムを有していないが、これは追加することができる。タウンにおけ る複数のハウスはすでに番号を有しており、常に同一の順序で用いられる。発行 者は、カードに与える各タウンにシークエンス番号を追加して、このシークエン ス番号をタウンの署名に含めることができる。（このようにして、タウンの署名 は、シークエンス番号とタウンの結果値に関する署名となる。） フルデータクリアリングシステムは、SAMを必要としないが、大量のデータが 端末から取得者に伝送されるという結果を引き起こし得る。これは、用いられる 通信システムによっては高価になり得る。 SAMベースのシステムは全て、それ自体高価な装置であるSAMを必要とする。複 数の発行者を有する環境において、全ての発行者が同一のSAMを信頼しなければ ならないか、または各端末が各発行者についてSAMを必要とするかである。 最後に述べた２つのクリアリングシステムは、SAMを必要としないが、端末に ほとんどのトランケーションをさせる。端末が取得者／発行者に対して詐欺行為 を行おうと試みた場合、端末は、統計的チェックによって捕獲される可能性があ る。チェックの量と取得者により用いられる選択メソッドとによって、取得者に 捕獲される前に端末によってうまく詐取される予想額が固定され得る。例えば、 端末が各取引に関するスケルトンデータを取得者に送った場合、取得者は、完全 な検討を行うべき取引を選択するために以下のアルゴリズムを用いることができ る。しかし、以下のアルゴリズムを用いることができる場合は、上記に限られな い。取引額が100ドル以上であれば、その取引は選択される。取引額ｘが100ドル 未満であれば、その取引が選択される可能性はx%である。従って、５ドルの取引 が選択される可能性は5%である。この選択メソッドを用いると、取得者によって 検出される前に端末によってうまく詐取される予想額は、100ドルであることが 取得者に対して保証されると考えられている。 当業者にとって自明であるように、ここに開示した本発明の概念を実現する多 くの本質的に均等な方法がある。ここで選択的に述べた特定の方法は、発明の開 示を簡潔にするためだけのものであり、時々は任意のものである。例えば、いく つかの例を挙げると、多くの１回限り署名ストラクチャ、圧縮ストラクチャ、階 層ストラクチャ、可能性のあるパラメータ値などがある。 本明細書で開示した本発明の概念およびプロトコルの一部分が、好適な実施形 態を完全に必要とすることなく、どのように利点を得るように用いられ得るかも 、当業者には自明である。このことは、本発明の概念のいくつかの使用において 、複数のパーティが組み合わされる例、実際のメッセージの代わりに簡単な認証 が用いられ得る例、装置が様々なハードウェア形態およびメモリタイプを含む例 などのいくつかの例を鑑みると、より完全に理解され得る。 当業者にとっては、ある改変および置換が明らかである。例えば、実施例とし て用いたRSAシステムの代わりに最も実際的な自己認証ディジタル署名技術が適 用され得ること、圧縮機能は２つより多いインプットを取り得ること、圧縮機能 の階層はいずれかの他のツリー状形態をも取り得ること、そして、あるタイプの アクセスをより均一に配布する登録再使用パターンが、ある技術にとっては好適 であることなどが明らかである。 本発明のこれらの記載を実施例として提供したが、様々な改変、別の構造、お よび均等物が、本発明の思想および範囲から逸脱することなく用いられ得ること は、当業者にとって明らかである。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｈ０４Ｌ 9/32 Ｇ０６Ｆ 15/21 ３４０Ｚ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，Ｍ Ｗ，ＭＸ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＩ，ＳＫ，ＴＪ，ＴＴ，ＵＡ，ＵＳ， ＵＺ，ＶＮ (72)発明者 ヴァン デル ホーク，ジェルト オランダ国 アムステルダム ビーピー エヌエル−1054，エルステ コンスタンチ ン ホイゲンスストラット 17−２

Claims (1)

1. 【特許請求の範囲】 １．メッセージの、公開鍵による認証を行う方法であって、 署名パーティにより、秘密鍵を作成する工程と、 該署名パーティの該秘密鍵に対応する公開鍵を、少なくとも受け取りパーティ によって検証可能にする工程と、 １セットの１回限り署名を作成する工程と、 該１回限り署名の圧縮階層を形成する工程と、 該公開鍵で検証可能な公開鍵ディジタル署名を該圧縮階層上に形成する工程と 、 裏書機構により、該圧縮階層のエッジを格納する工程と、 少なくとも１つの該１回限り署名で署名し且つ格納されたエッジ値を供給する ことにより裏書きする工程と、 該１回限り署名および該供給されたエッジ値、並びに該圧縮値上の該ディジタ ル署名を検証する工程と、 該裏書機構が実質的に全エッジより少ないエッジを格納し且つ各裏書き動作の 前に実質的に全エッジより少ないエッジを演算する(compute)ことにより、上記 を達成する工程と、 を含む方法。 ２．圧縮機能のカスケードストラクチャを用いる、請求項１に記載の方法。 ３．将来の裏書き動作が実質的により少ない演算を要するように、将来の裏書き 動作に対して準備する、請求項１に記載の方法。 ４．前記１回限り署名が、一方向機能のチェーン内における異なる一方向機能を 用いて構成される、請求項１に記載の方法。 ５．前記準備が、少なくとも部分的に、前記裏書機構とは異なるパーティによっ て行われる、請求項３に記載の方法。 ６．メッセージの、公開鍵による認証を行う装置であって、 署名パーティにより、秘密鍵を作成する手段と、 該署名パーティの該秘密鍵に対応する公開鍵を、少なくとも受け取りパーティ によって検証可能にする手段と、 １セットの１回限り署名を作成する手段と、 該１回限り署名の圧縮階層を形成する手段と、 該公開鍵で検証可能な公開鍵ディジタル署名を該圧縮階層上に形成する手段と 、 裏書機構により該圧縮階層のエッジを格納する手段と、 裏書きする手段であって、該１回限り署名のうちの１つで署名する手段と格納 されたエッジ値を供給する手段とを含む手段と、 該１回限り署名と供給された圧縮階層値とを検証し、且つ該圧縮値上の該ディ ジタル署名を検証する手段と、 該裏書機構が実質的に全エッジより少ないエッジを格納し且つ各裏書き動作の 前に実質的に全エッジより少ないエッジを演算することにより、上記を達成する 手段と、 を含む装置。 ７．圧縮機能のカスケードストラクチャを形成する手段を含む、請求項６に記載 の装置。 ８．将来の裏書き動作が実質的により少ない演算を要するように、将来の裏書き 動作に対して準備する、請求項６に記載の装置。 ９．金融取引を行う方法であって、 少なくとも１つの次の取引に対して用いられる端末によってチャレンジシード を維持する工程と、 オンラインサーバによりチャレンジシード・モディファイアを該端末に発行す る工程と、 少なくとも該モディファイアに応答する該端末によって該チャレンジシードを 改変する工程と、 チャレンジ値が少なくとも実質的に該チャレンジシードに依存する、次の取引 に用いる該チャレンジ値を開発する工程と、 該チャレンジを、該端末のシークレットに関与する者にさえも予測不可能にす るように、上記を達成する工程と、 を含む方法。 10．金融取引を行う装置であって、 少なくとも１つの次の取引に対して用いられる端末によってチャレンジシード を維持する手段と、 オンラインサーバによりチャレンジシード・モディファイアを該端末に発行す る手段と、 少なくとも該モディファイアに応答する該端末によって該チャレンジシードを 改変する手段と、 チャレンジ値が少なくとも実質的に該チャレンジシードに依存する、次の取引 に用いる該チャレンジ値を開発する手段と、 該チャレンジを、該端末のシークレットに関与する者にさえも予測不可能にす るように、上記を達成する手段と、 を含む装置。 11．メッセージの、公開鍵による認証を行う方法であって、 署名パーティにより、秘密鍵を作成する工程と、 該秘密鍵に対応する公開鍵を、少なくとも受け取りパーティによって検証可能 にする工程と、 該署名パーティによって、コミット−チャレンジ−レスポンスプロトコルのコ ミット値を生成する工程と、 該コミット値を該受け取りパーティに送信する工程と、 該署名パーティと該受け取りパーティとによって、互いにランダムな値を形成 する工程と、 該コミット−チャレンジ−レスポンスプロトコルのチャレンジ値を、認証すべ きメッセージと該互いにランダムな値とを連結するハッシュ値として選択する工 程と、 該署名パーティにより、該コミット−チャレンジ−レスポンスプロトコルのレ スポンス値を生成する工程と、 該レスポンス値を該受け取りパーティに送信する工程と、 該受け取りパーティにより、該レスポンス値を検証する工程と、 を含む方法。 12．前記コミット−チャレンジ−レスポンスプロトコルが、コンパクトな裏書き 動作署名プロトコルから構成される、請求項11に記載の方法。 13．メッセージの、公開鍵による認証を行う装置であって、 署名パーティにより、秘密鍵を作成する手段と、 該秘密鍵に対応する公開鍵を、少なくとも受け取りパーティによって検証可能 にする手段と、 該署名パーティによって、コミット−チャレンジ−レスポンスプロトコルのコ ミット値を生成する手段と、 該コミット値を該受け取りパーティに送信する手段と、 該署名パーティと該受け取りパーティとによって、互いにランダムな値を形成 する手段と、 該コミット−チャレンジ−レスポンスプロトコルのチャレンジ値を、認証すべ きメッセージと該互いにランダムな値とを連結するハッシュ値として選択する手 段と、 該署名パーティにより、該コミット−チャレンジ−レスポンスプロトコルのレ スポンス値を生成する手段と、 該レスポンス値を該受け取りパーティに送信する手段と、 該受け取りパーティにより、該レスポンス値を検証する手段と、 を含む装置。 14．不揮発性メモリ内にデータを格納する方法であって、 コミット値を論理０に初期化する工程と、 作成すべき改変の１以上の記述を格納する工程と、 該コミット値を論理０に設定する工程と、 該記述により特定された改変を行う工程と、 該コミット値を論理０に設定する工程と、 上記の工程中における割り込みを検出し、検出後に、 a)該コミット値を検査し、 b)該コミット値が論理１である場合に該改変を行い、 c)該コミット値を論理０に設定する工程と、 を含む方法。 15．割り込み後であって且つ前記改変が行われる前に、前記コミット値を論理１ に設定する手段を含む、請求項14に記載の方法。 16．使用中の値を論理０に初期化する工程と、 前記コミット値が論理１に設定される前に、該使用中の値を論理１に設定する 工程と、 該コミット値が論理０に設定された後に、該使用中の値を論理０に設定する工 程と、 該コミット値を論理０に設定して、その後、該使用中の値が論理１を含むこと が判明し且つ該コミット値が割り込み後に論理０を含むことが判明した場合に、 該使用中の値を論理０に設定する工程と、 を含む方法。 17．異なる改変に対しては異なるコミット値が用いられる、請求項14または16に 記載の方法。 18．前記改変が、与えられたメモリ位置のセットのうちの１つに対する標準のア クションにより構成される、請求項14または16に記載の方法。 19．前記標準のアクションが、前記位置を固定値に設定することから構成される 、請求項18に記載の方法。 20．改変記述用の前記保持(retention)手段が、改変する可能性のある位置の各 々に対して単一のビットから構成される、請求項18に記載の方法。 21．作成すべき１以上の復帰(reversion)記述を格納する工程と、 前記コミット値が割り込み後に論理０を含むことが判明した場合に、該復帰記 述により特定される復帰を行う工程と、 を含む、請求項14または16に記載の方法。 22．前記復帰の各々が、与えられたメモリ位置のセットのうちの１つに対する標 準のアクションにより構成される、請求項21に記載の方法。 23．前記標準のアクションが、前記位置を固定値に設定することから構成される 、請求項22に記載の方法。 24．復帰記述用の前記保持手段が、復帰する可能性のある位置の各々に対して単 一のビットから構成される、請求項22に記載の方法。 25．不揮発性メモリ内にデータを格納する装置であって、 １ビットのコミット値を保持する手段と、 作成すべき１以上の改変の記述を保持する手段と、 カード寿命の予め定められた期間中に該コミット値が論理０であることを保証 する、初期化手段と、 該第２の保持手段内に、作成すべき１以上の改変記述を格納する手段と、 該コミット値を論理０に設定する手段と、 該記述によって特定される改変を行う手段と、 該コミット値を論理０に設定する手段と、 通常の処理およびトリガリング中に割り込みを検出する手段と、 を含む装置であって、 該検出する手段は、 a)該コミット値を検査する手段と、 b)該コミット値が論理１である場合に該改変を行う手段と、 c)該コミット値を論理０に設定する手段とを含む装置。 26．不揮発性メモリを有する演算装置内のメモリエラーを処理する方法であって 、 モード値を第１のモードを示すように初期化する工程と、 該メモリの誤状態の発生を検出する工程と、 該誤状態が検出されると、該モード値を第２のモードを示すように設定する工 程と、 該演算装置によって実行される処理のうちの少なくとも１つにおいて該モード 値を検査する工程と、 該モード値の値に依存して該処理の挙動を改変する工程と、 を含む方法。 27．前記処理の挙動を改変する工程は、前記処理の通常の実行を前記第１の状態 に制限する工程を含む、請求項26に記載の方法。 28．前記処理の挙動を改変する工程は、アプリケーションデータの回復を許可す る前記第２のモードにおいて処理を可能にする工程を含む、請求項26に記載の方 法。 29．前記処理が、非シークレットであるデータに対するアクセスを制限する、請 求項28に記載の方法。 30．前記データのシークレット性が、前記メモリ内の個々のビットが論理「１」 状態から論理「０」状態に変化する場合、シークレット性のレベルを上昇させる コーディングにより決定される、請求項29に記載の方法。 31．前記誤状態の検出が、実質的に高い可能性でメモリエラーを検出するために データのコーディングを用いる、請求項26に記載の方法。 32．不揮発性メモリを有する演算装置内のメモリエラーを処理する装置であって 、 モード値を第１のモードを示すように初期化する手段と、 該メモリの誤状態の発生を検出する手段と、 該誤状態が検出されると、該モード値を第２のモードを示すように設定する手 段と、 該演算装置によって実行される処理のうちの少なくとも１つにおいて該モード 値を検査する手段と、 該モード値の値に依存して該処理の挙動を改変する手段と、 を含む装置。 33．端末とカードとの間の複数の独立したアクションを通信させ且つ連結する方 法であって、 通信の開始前に、該カードにおける第１のハッシュ状態を、既知の値に初期化 する工程と、 通信の開始前に、該端末における第２のハッシュ状態を、既知の値に初期化す る工程と、 該第１のハッシュ状態と、入力としての独立したアクションに関連するデータ とを実質的に取り、且つ該第１のハッシュ状態用の新しい値を出力として生み出 す機能を用いて、該第１のハッシュ状態を更新する工程と、 該第２のハッシュ状態と、入力としての独立したアクションに関連するデータ とを実質的に取り、且つ該第２のハッシュ状態用の新しい値を出力として生み出 す機能を用いて、該第２のハッシュ状態を更新する工程と、 該端末と該カードとの間で通信されたデータの少なくとも一部分を、該ハッシ ュ状態依存にする工程と、 を含む方法。 34．初期の独立したアクションが、少なくとも１つのシークレット鍵を用いて前 記ハッシュ状態を更新する、請求項33に記載の方法。 35．初期の独立したアクションが、前記鍵を所有する前記端末によるプルーフを 含む、請求項34に記載の方法。 36．前記独立したアクションが、前記ハッシュ状態に基づいて、前記カードと前 記端末との間で通信されたデータの暗号化秘匿性コーディングを含む、請求項33 、34、または35に記載の方法。 37．前記秘匿性コーディングが、データ通信の双方向において、前記カードにお けるものと同一のコーディング機能を用いる、請求項36に記載の方法。 38．前記秘匿性コーディングが、データ通信の双方向において、前記端末におけ るものと同一のコーディング機能を用いる、請求項36に記載の方法。 39．前記独立したアクションが、暫定的な変化を永久的なものにする最終的な独 立したアクションが行われるまで、前記カードの状態への暫定的な変化のみを行 う、請求項33、34、または35に記載の方法。 40．割り込みが検出されると、前記暫定的変化を破棄する、請求項39に記載の方 法。 41．前記最終的なアクションが、前記第２のハッシュ状態における前記カードの 、前記端末による第１の暗号化認証を行い、それにより前記暫定的変化を永久的 なものにするプロセスを開始することとを含む、請求項39に記載の方法。 42．前記最終的な独立したアクションが、前記第１のハッシュ状態における前記 端末の、前記カードによる第２の暗号化認証を行い、それにより前記暫定的変化 が永久的なものになったことを示すことを含む、請求項39に記載の方法。 43．前記カードが前記第２の暗号化認証を前記端末に再送信する前記最終的な独 立したアクションの後、該端末の要求によって、再送信プロセスが実行される、 請求項42に記載の方法。 44．前記最終的な独立したアクション中に、前記カード内の実行済み(done)値を 論理０に初期化する工程と、 前記再送信プロセス中に該実行済み値を検査する工程と、 該実行済み値が論理０である場合にのみ、前記第２の暗号化認証を再送信する 工程と、 該実行済み値を論理１に設定するという要求を前記端末により前記カードに送 信する工程と、 該要求を受け取ると、該実行済み値を論理１に設定する工程と、 を含む請求項43に記載の方法。 45．前記最終的な独立したアクションが、前記第１の暗号化認証を検証した後で あるが前記暫定的変化が永久的なものになる直前に、前記カードが前記端末の信 号を待つための条件を含む、請求項41に記載の方法。 46．前記独立したアクションのためのデータが、発行者により生成されて前記端 末に送信され、該端末が該発行者により供給されたデータに基づいて該カードに 関する該アクションを実行する、請求項41に記載の方法。 47．端末とカードとの間の複数の独立したアクションを通信させ且つ連結する装 置であって、 該カードにおける第１のハッシュ状態を保持する手段と、 該端末における第２のハッシュ状態を保持する手段と、 通信の開始前に、該カードにおける該第１のハッシュ状態を既知の値に初期化 する手段と、 通信の開始前に、該端末における該第２のハッシュ状態を既知の値に初期化す る手段と、 該第１のハッシュ状態と入力としての独立したアクションに関連するデータと を実質的に取り、且つ該第１のハッシュ状態用の新しい値を出力として生み出す 機能を用いて、該第１のハッシュ状態を更新する手段と、 該第２のハッシュ状態と、入力としての独立したアクションに関連するデータ とを実質的に取り、且つ該第２のハッシュ状態用の新しい値を出力として生み出 す機能を用いて、該第２のハッシュ状態を更新する手段と、 該端末と該カードとの間で通信されたデータの少なくとも一部分を、該ハッシ ュ状態依存にする手段と、 を含む装置。 48．端末と通信中のカードによる演算を行う方法であって、 該端末によって、第１のメッセージを送信する工程と、 該カードによって、該第１のメッセージを受信する工程と、 該第１のメッセージ内で受け取られたデータと該カードのメモリ内に格納され たデータとに基づいて、該カードによる演算を行う工程と、 該カードによって、第２のメッセージを送信する工程と、 該端末によって、該第２のメッセージを受信する工程と、 該第１のメッセージと該第２のメッセージとの間の遅延を誘導する工程であっ て、該遅延の期間が、該遅延前に該カードによって受信された該メッセージの内 容と該遅延前に該カードによって送信された該メッセージの内容とによって構成 される公的な情報と、該端末による適切な要求を与えられた該カードが次の通信 において該端末に送信するデータとによってのみ決定される工程と、 を含む方法。 49．前記遅延が、前記演算の可能性のある実行通路の各々において十分な遅延を 追加することにより一定にされる、請求項48に記載の方法。 50．前記演算が、各々が既知の固定された遅延を誘導するアクションのシークエ ンスにより実行され、該シークエンスが前記公的な情報によってのみ決定される 、請求項48に記載の方法。 51．前記アクションのシークエンスが、条件に応じて実行される１以上のアクシ ョンを含む１セットのアクションと機能的に等価であるアクションにより構成さ れる、請求項50に記載の方法。 52．前記命令のシークエンスが、条件に応じた格納動作の条件の関数として演算 される値を有するアドレスを用いて該格納動作を実行することにより、条件に応 じてなされる格納動作を実行する、請求項50に記載の方法。 53．端末と通信中のカードによる演算を行う装置であって、 該端末によって、第１のメッセージを送信する手段と、 該カードによって、該第１のメッセージを受信する手段と、 該第１のメッセージ内で受け取られたデータと該カードのメモリ内に格納され たデータとに基づいて、該カードによる演算を行う手段と、 該カードによって、第２のメッセージを送信する手段と、 該端末によって、該第２のメッセージを受信する手段と、 該第１のメッセージと該第２のメッセージとの間の遅延を誘導する手段であっ て、該遅延の期間が、該遅延前に該カードによって受信された該メッセージの内 容と該遅延前に該カードによって送信された該メッセージの内容とによって構成 される公的な情報と、該端末による適切な要求を与えられた該カードが次の通信 において該端末に送信するデータとによってのみ決定される手段と、 を含む装置。 54．１セットの命令を変換する方法であって、 該１セットの命令を検査する工程と、 該セットにおいて用いられる条件を決定する工程と、 該セットに、該条件を値に変換する命令を追加する工程と、 該セット内に含まれる表現を、命令の、条件に応じた実行の代わりに、該値を 用いて、等価な形態に書き換える工程と、 を含む方法。 55．１セットの命令を変換する装置であって、 該１セットの命令を格納する保持手段と、 該１セットの命令を検査する手段と、 該セットにおいて用いられる条件を決定する手段と、 該セットに、該条件を値に変換する命令を追加する手段と、 該セット内に含まれる表現を、命令の、条件に応じた実行の代わりに、該値を 用いて、等価な形態に書き換える手段と、 を含む装置。 56．取得者によって、端末からの１以上の取引に関連する取引情報を収集する方 法であって、 該取引情報のサイズに比較して実質的に小さいサイズを有する、該取引情報か らの第１の値を、該端末によって演算する工程と、 該端末によって、取引回数の指示と、取引の適用可能な総数と、該第１の値と を含む該第１のメッセージを、該取得者に送信する工程と、 該取得者によって、該第１のメッセージを受信する工程と、 将来の演算のために、該取得者によって、該第１のメッセージからのデータを 実質的に格納する工程と、 該取引のセットからのランダムな選択を行う工程と、 第２のメッセージ内の該ランダムな選択を該端末に送信する工程と、 該端末によって、該第２のメッセージを受信する工程と、 該端末によって、第３のメッセージのなかで実質的に、該選択内における取引 のための取引情報を、該取得者に送信する工程と、 を含む方法。 57．前記第１のメッセージが、全ての取引に関するスケルトン取引情報を含む、 請求項56に記載の方法。 58．前記第１のメッセージが、実質的に全ての取引の完全な取引データに関する 暗号化ハッシュ値を含み、前記第３のメッセージが、前記取得者によって該ハッ シュ値が検証されることを許可するデータを含む、請求項56に記載の方法。 59．前記暗号化ハッシュ値が、ツリーストラクチャを用いて演算される、請求項 58に記載の方法。 60．取得者によって、端末からの１以上の取引に関連する取引情報を収集する装 置であって、 該取引情報のサイズに比較して実質的に小さいサイズを有する、該取引情報か らの第１の値を、該端末によって演算する手段と、 該端末によって、取引回数の指示と、取引の適用可能な総数と、該第１の値と を含む該第１のメッセージを、該取得者に送信する手段と、 該取得者によって、該第１のメッセージを受信する手段と、 将来の演算のために、該取得者によって、該第１のメッセージからのデータを 実質的に格納する保持手段と、 該取引のセットからのランダムな選択を行う手段と、 第２のメッセージ内の該ランダムな選択を該端末に送信する手段と、 該端末によって、該第２のメッセージを受信する手段と、 該端末によって、第３のメッセージのなかで実質的に、該選択内における取引 のための取引情報を、該取得者に送信する手段と、 を含む装置。 61．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う方法であって、 典型的には異なる取引に対しては異なる可変取引データを生成する工程と、 少なくとも該可変取引データの一部に依存する値を有するメッセージブロック を構築する工程と、 該メッセージブロック上の公開鍵暗号化に基づいて、認証を該カードにより生 成する工程と、 該認証をメッセージ内において該端末に送信する工程と、 該端末によって、該メッセージを受信する工程と、 該端末によって、該認証を検証する工程と、 を含む方法。 62．前記メッセージブロックが、取引証明TCを含む、請求項61に記載の方法。 63．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う装置であって、 典型的には異なる取引に対しては異なる可変取引データを生成する手段と、 少なくとも該可変取引データの一部に依存する値を有するメッセージブロック を構築する手段と、 該メッセージブロック上の公開鍵暗号化に基づいて、認証を該カードにより生 成する手段と、 該認証をメッセージ内において該端末に送信する手段と、 該端末によって、該メッセージを受信する手段と、 該端末によって、該認証を検証する手段と、 を含む装置。 64．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う方法であって、 全ての金融取引アプリケーションに関して、該カード内に残高を維持する工程 と、 各取引の額だけ該残高を減少させる工程と、 該取引の額が該残高を越える場合にはオフライン取引を拒絶する工程と、 を含む方法。 65．前記発行者が、前記カードに格納された前記残高を改変するためにEMVのス クリプト特徴を用いる、請求項64に記載の方法。 66．前記発行者によって、前記カードに関する情報を格納する工程と、 該カードによって行われるオンライン取引に関する情報を、該発行機間によっ て格納する工程と、 オンライン取引中に該発行者により発行された第１のスクリプトを実行するこ とができなかったことを、該発行者により検出する工程と、 該第１のスクリプトのアクションを実質的に含む第２のスクリプトを作成する 工程と、 該第２のスクリプトを該端末に送信する工程と、 該端末によって、該カードを用いて該スクリプトを実行する工程と、 を含む、請求項65に記載の方法。 67．ある期間の後に、該カードによってなされたがクリアリングのために前記発 行者には提示されていないオフライン取引を、該発行者により検出する工程と、 該オフライン取引の総額を推定する工程と、 スクリプトを用いて、前記残高に該総額を実質的に追加する工程と、 を含む、請求項66に記載の方法。 68．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う装置であって、 該カード内に残高を維持する保持手段と、 各取引の額だけ該残高を減少させる手段と、 該取引の額が該残高を越える場合にはオフライン取引を拒絶する手段と、 を含む装置。 69．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う方法であって、 うまく完了した取引に対してのみ、取引カウントATCをインクリメントする工 程を含む方法。 70．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う装置であって、 うまく完了した取引に対してのみ、取引カウントATCをインクリメントする手 段を含む装置。 71．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う方法であって、 固定された期間内にオフライン取引を許可するのかオンライン取引を必要とす るのかを該カードによって決定する工程と、 固定された期間内の該決定を格納する工程と、 を含む方法。 72．実質的にEMV仕様に応じて、カード、端末、および発行者を用いて金融取引 を行う装置であって、 固定された期間内にオフライン取引を許可するのかオンライン取引を必要とす るのかを該カードによって決定する手段と、 固定された期間内の該決定を格納する手段と、 を含む装置。