JPH11506560A - スマートカードにコマンドを安全に入れる方法 - Google Patents

Abstract

(57)【要約】 本発明はスマートカード（ＳＣ）にコマンド（ＣＯＭ）を安全に入れて認証する方法に関するものである。特にアプリケーション・プロバイダ（ＡＰ）によって特定アプリケーション・コマンドが入れられる場合、すなわち、カード発行者（ＣＩ）に関してオフ・ラインの場合、そのコマンドが有効であることを確かめなければならない。本発明は確認コードによってコマンド（ＣＯＭ）の保護を含む方法を提供する。これらのコード（ＭＡＣ１，ＭＡＣ２）は２つの異なるキーを使って発生させられる。１つのキー（Ｋ１）はカード発行者（ＣＩ）が保存し、もう１つのキー（Ｋ２）は信託された第三者（ＴＴＰ）が保存する。さらに、一組のキー（Ｋ３^*）から１つのキーを使って発生させられる確認コード（ＭＡＣ３）が個々のアプリケーション（たとえばＡＰ１，ＡＰ２）に対してコマンドを選択的に認証するために使われる。

Description

【発明の詳細な説明】 スマートカードにコマンドを安全に入れる方法 〔発明の背景〕 本発明はスマートカードにコマンドを入れる（ｌｏａｄ）方法に関するもので ある。さらに詳しくは、本発明はスマートカードに特定コマンドをオフラインで 入れる方法に関するものである。 現代の支払いシステムでは、電子支払い媒体の使用がますます重要になってき ている。メモリーカードやスマートカード（一般にＩＣカードと呼ばれている） のような電子支払い媒体は、その応用が拡張しているという評価を得ている。多 くの国々で電子カードは公衆電話等に用いられている。先進カードは他の機能に 加え、電子「財布」を含むことができる。そのような先進支払い媒体はメモリー に加え、適切なプログラムを行うことのできるプロセッサを含んでいる。 ここで、スマートカードあるいはカードという用語は、プロセッサおよびメモ リーからなる集積回路を少なくとも１つ持っている電子支払い媒体を表すために 用いられることに留意すべきである。いわゆるスマートカードの実際の形状がど んなであるかは重要でない。 スマートカードのプロセッサ上で行われるプログラムは、カードから提供され るサービス、すなわち、カードにあるソフトに依存してスマートカードの機能お よび関連するデータ構造（たとえば、財布・ユーザＩＤ・ロイヤルティプログラ ム）を決定する。時が経つにつれ、新機能を加えたり既存機能を改良したりする ために、カードのプログラムを更新する必要がしばしば生ずる。このため、カー ドは他のプログラムを置き換える新しいプログラムを受け入れる必要がある。し かし、その際、新たに入れたプログラムが有効に働くということを確認しなけれ ばならない。 プログラムの確認はカード発行者とカードとの間で安全なデータ交換プロトコ ルを使うことによって、比較的容易に達成され得る。しかし、アプリケーション ・プロバイダのような他の関係者は、カード発行者を経由してこれをする必要な しに、カードに新しいアプリケーション（したがって、新しいコマンド）を入れ ることができることを望む。 〔発明の要約〕 本発明の目的は、上記および他の問題点を克服し、スマートカードにコマンド を安全に入れて作動させる方法を提供することにある。さらに本発明の目的は、 コマンドの統合性を保証しながら、アプリケーション・プロバイダによって特定 アプリケーション・コマンドをスマートカードに入れる方法を提供することにあ る。 これらおよび他の目的は、 第２の当事者（ｔｈｅ ｓｅｃｏｎｄ ｐａｒｔｙ）が第１キーを用いてコマ ンドの第１確認コードを発生させ、 第三者（ａ ｔｈｉｒｄ ｐａｒｔｙ）が第２キーを用いてコマンドの第２確 認コードを発生させ、 コードと共にコマンドをカードに移し、 それぞれ第１・第２キーを用いて第１・第２確認コードを再発生させることに より、カードがコマンドを認証し（ｖａlｉｄａｔｅ）、および 該再発生されたコードを移されたコードと比較するステップからなる、 第１の当事者（ａ ｆｉｒｓｔ ｐａｒｔｙ）によってコマンドを安全にスマ ートカードに入れる方法によって達成され、カードは第２の当事者によって発行 される。 本発明の方法において、コマンドの確認は２人の異なる、好ましくは独立した （相手に依存しない）当事者、すなわち通常はカード発行者である第２の当事者 と、通常は中央銀行のような信用ある独立の第三者に確認コードを発生させるこ とにより、安全保護される。ひとたび双方の確認コードが発生させられると、確 認コードによってこれが気づかれることなしには、コマンドを変更するのは実質 的に不可能である。アプリケーション・プロバイダである第１の当事者は、当事 者と第２の当事者がともにコマンドを「認証した」という証拠をもっている。第 三者はコマンドのコピーを保存するのが好ましい。 本発明の方法は単一のコマンドおよび一組のコマンドの双方に対し、適用され ることが理解されるであろう。 カードに移すことと次の認証は、認証が失敗したときくり返されることが好ま しく、認証が成功するまで入れられているコマンドの使用が阻止される。これに より、無効コマンドすなわち送信エラーや操作をされたコマンドがカードで実行 されるのが防がれる。 有利なことに、認証が予め決められた回数、好ましくは１０回未満、失敗すれ ば、入れられているコマンドは永久に実行できない。これは相手のキーを変える ことによってなされる。こうして、働かなくなったコマンドの際限のない再ロー ド（ｒｅｌｏａｄｉｎｇ）が終了する。 入れられたコマンドは特定アプリケーション・コマンド、すなわちカードのア プリケーションに直接作用するコマンドである。このようなコマンドはしばしば 、カードのアプリケーションを操作させる機械語インストラクションである。本 発明の方法を使って、そのようなコマンドの使用が制御されるので、アプリケー ションの統合性が保証される。 第１・第２確認コードは、ＡＮＳＩ（米国規格協会）×９．１９規格に従って 発生させられたメッセージ確認コードであることが好ましい。 有利なことに、第１・第２キーを含まない追加確認コードが相手から発生させ られる。これにより、そのような方法に影響を与えることなく、当事者に認証チ ェックをさせられる。 〔図面の簡単な説明〕 図１は本発明の方法に使われるスマートカードの斜視図である。 図２は図１のスマートカードの集積回路のブロック図である。 図３は本発明の方法におけるデータ交換の説明図である。 図４はスマートカードのデータ構造の説明図である。 図５は本発明の方法に使われるフラグ・レジスタの説明図である。 図６は本発明の方法の実施例を示すフローチャートである。 〔実施例〕 図１に、集積回路を内蔵した基板２からなるスマートカードあるいはＩＣカー ド１を例示する。集積回路はカード・リーダのようなものと接続するための端子 ３を有している。なお、本発明はまた、いわゆる非接触スマートカードにも適用 できる。 図２に、プロセッサ１１、メモリ１２、および入出力回路１３からなる集積回 路１０を例示する。メモリは一時的なデータ保存のための揮発性（ＲＡＭ）メモ リ部と、永久的もしくは半永久的なデータ保存のための不揮発性（ＲＯＭ）メモ リ部からなっている。後者はＥＥＰＲＯＭタイプのメモリが好ましい。不揮発性 部の保存データは、プログラミング・データ（インストラクション、プログラム ）および支払いデータ、すなわち金銭処理に関するデータの双方を有している。 別個のメモリ（図示せず）がプロセッサ１１のインストラクション・セットを保 存するために用いられる。入出力回路１３は図１の端子３のような（図２には示 していない）端子を通して外部デバイスと通信できる。集積回路１０は図１のカ ード内に含まれている。 本発明の方法の実施例を図３に例示する。たとえばアプリケーション・プロバ イダＡＰのような当事者（ａ ｆｉｒｓｔ ｐａｒｔｙ）が、その顧客にカード 機能を提供する。スマートカードＳＣが相手（ａ ｓｅｃｏｎｄ ｐａｒｔｙ） 、すなわちカード発行者ＣＩから発行される。本発明によれば、信託された第三 者ＴＴＰが後述するようにコマンドの認証に関与する。 一組のコマンドＣＯＭがアプリケーション・プロバイダＡＰからの指図により 、カード発行者ＣＩあるいは外部ソースによって発生させられている。一組のコ マンドＣＯＭは１つまたは２以上のコマンドからなる。すなわち、ここに説明し ている方法は、個々のコマンド、あるいは複数コマンドの組に対して適用される 。以下の説明において、本発明の方法を説明するための便宜上、複数の組コマン ドでなく単一コマンドを用いて行う。コマンドは特定アプリケーション・コマン ド（ＡＳＣ）あるいは汎用コマンド（ＧＰＣ）である。 図３に示すように、アプリケーション・プロバイダＡＰが確認のため、コマン ドＣＯＭをカード発行者ＣＩに与える。そのコマンドＣＯＭに基づく確認コード ＭＡＣ１が第１キーＫ１を使ってカード発行者ＣＩから発生させられる。コード ＭＡＣ１に加え、キー（少なくともキーＫ１）の使用を伴わない付加的な（第４ ）確認コードＭＡＣ４を、コマンドの組がオプションとして受けることもある。 このコードＭＡＣ４は、他の確認コード内で使われるキーとは無関係に、コマン ドの付加検証をするために使われる。コードＭＡＣ４の計算は第１確認コードＭ ＡＣ１を伴う。その場合、次のように書かれる。 ＭＡＣ４＝Ｆ_K1（ＣＯＭ，ＭＡＣ１） ここでＦは、それによってコードを決定するための関数を表している。コードＭ ＡＣ１とＭＡＣ４は、アプリケーション・プロバイダＡＰに送られ、そこで一時 保存される。 本発明によれば、コマンドＣＯＭは信託された第三者ＴＴＰにも送られる。第 三者は第２キーＫ２を使ってコマンドＣＯＭの第２確認コードＭＡＣ２を発生さ せる。コードＭＡＣ２はアプリケーション・プロバイダＡＰに送られる。 この第三者は、たとえば中央銀行、あるいはカード発行者とサービス・プロバ イダから指名された機関である。 アプリケーション・プロバイダＡＰは第３キーＫ３^*を使って第３確認コード ＭＡＣ３を発生させる。キーＫ３^*は一組のキー（* で表わしている）からなり 、各個々のキーは個々のカード・アプリケーションや個々のカード・ファイルに 対応している。一組のキーＫ３−１，Ｋ３−２，…からなるキーＫ３^*は、コマ ンドをカードの特定アプリケーションやファイルに選択的に入れるために使われ る。これは図４、図５を用いて後述する。第３キーＫ３^*はアプリケーション間 で変わり得るので、第３確認コードＭＡＣ３も変わり得る。すなわち、コードＭ ＡＣ３は特定アプリケーション確認コードである。コードＭＡＣ３はコマンドＣ ＯＭと第１・第２確認コードの双方に基づいているので、二重確認を与える。そ の場合、次のように書かれる。 ＭＡＣ３＝Ｆ_K3（ＣＯＭ，ＭＡＣ１，ＭＡＣ２） ここでＦは、それによってコードを決定する関数を表している。 確認コードＭＡＣ１とＭＡＣ２は、ＭＡＣ３とＭＡＣ４と同様に、暗号を含む メッセージ確認技術を使って発生させられることが好ましい。そのような技術は たとえばＡＮＳＩ ×９．１９規格に開示されている。この技術そのものは本発 明にとって本質的なものではない。付加確認コードも暗号（たとえばパブリック ・キー）を使って、あるいはいわゆるハッシュ（ｈａｓｈ）関数を使って発生さ せられる。 確認コードＭＡＣ１とＭＡＣ２の双方は、オプションの確認コードＭＡＣ３と ＭＡＣ４同様に、コマンドに付属し、あるいは他の仕方でコマンドに伴う。図３ で、コマンドとそれに伴う確認コードは ＣＯＭ，ＭＡＣ１，ＭＡＣ２〔，ＭＡＣ３，ＭＡＣ４〕 と表されている。ここで〔 〕内はオプションのコードを示している。コマンド とそれに伴うコードが送られる実際の順序はもちろん異なる。 スマートカードＳＣがコマンドを受け取るとすぐ、予めカード内に保存されて あるキーＫ１とＫ２を使って、カードが確認コードＭＡＣ１とＭＡＣ２を再び発 生する。再び発生させられたコードＭＡＣ１’とＭＡＣ２’は、受け取られたコ ードＭＡＣ１およびＭＡＣ２と比較される。もしこれらのコードが同一なら、コ マンドの認証は成功し、コマンドは作動する。この作動はあるフラグをセット（ あるいはリセット）することによりなされる。もし認証が失敗すれば、すなわち それらのコードが同一でなければ、コマンドの再送信の要求が出される。再送信 カウンタが再送信の数を追跡し、予め決められた数（たとえば５）を越えると再 送信を禁止する。 こうしてカードは、好ましくは、カードに入れられたコマンドが活性化される までは使用され得ないようにアレンジされる。すなわち、カードに入れられたコ マンドは認証の結果としてリリースされるまで、ブロックされる。これにより、 無効のコマンドがカードによって実行されることが防がれる。図４に、本発明の 好ましい実施例からなる、図１のスマートカードのようなカード上のデータ構造 を示す。データ構造は図２のメモリ１２のようなメモリ内に実際に保存されてい る。 いわゆるマスター・ファイルＭＦは、他のファイルに対するレファランスを有 している。図４に、いくつかのいわゆるアプリケーション・ファイル（ＡＰ１， ＡＰ２，ＡＰ３）が示されている。各ＡＰ１，ＡＰ２，…は１以上のサブファイ ル、たとえばプログラム・ファイルおよびデータ・ファイルからなる。 図４に示すように、各アプリケーション（ファイル）はそれぞれ対応するキー （Ｋ３−１，Ｋ３−２，Ｋ３−３）を有している。これらのキーＫ３−ｉは、図 ３の一組のキーＫ３^*のＫ３−ｉ（ｉはｉ番目のアプリケーションを示す）に対 応している。上に説明したように、カードは１以上のキー（たとえばＫ１，Ｋ２ ）を使ってコマンドの確認コード（たとえばＭＡＣ１，ＭＡＣ２）を再発生し、 その再発生したコードを受け取られたコードと比較して受け取られたコードを検 証することができる。すなわち、もし受け取られたコードと再発生したコードが 一致しなければ、対応するコマンドはカードに入れられない、あるいは少なくと も実行を阻止される。同様に、一組のキーＫ３^*のキーがコマンドを個々のアプ リケーションに選択的に入れるために使われ、ターゲット・アプリケーション（ たとえばＡＰ２）が対応するキー（たとえばＫ３−２）で示される。あるコマン ドが１以上のアプリケーションに入れられなければならない場合には、キーＫ３^* はワイルドカードを含む。 図４に示すように、マスター・ファイルＭＦはフラグ・レジスタＦＲを有する 。図５に、フラグ・レジスタＦＲがさらに詳細に示されている。フラグ・レジス タＦＲは、たとえば各１ビットの複数のフラグＦ−１，Ｆ−２，…からなってい る。各フラグはカードのプロセッサ（図２の１１）のコマンドに対応している。 プロセッサとそのソフトウエアは、対応するフラグがセットされていればコマン ドの実行が禁止されるようにアレンジされている。メモリ・ロケーションを更新 するＵＰＤＡＴＥコマンドは、たとえばＦ−３がセットされていれば実行される 。こうして、（特定アプリケーション）コマンドの承認されていない、あるいは 不注意の実行に対し、付加的な保護がなされる。 フラグ・レジスタは適当なコマンド、たとえばＳＥＴ−ＦＬＡＧ−ｉ（ｉはフ ラグ番号）によって制御され得る。関係しているコマンドが特定アプリケーショ ン・コマンドなら、すべてのフラグが最初にセットされることが好ましく、こう して特定アプリケーション・コマンドの実行が防がれる。コマンドの確認が検証 され、コマンドの実行が許可されるなら、フラグはコマンドを認証するコマンド （たとえば、ＶＡＬＩＤＡＴＥ）によってリセットされる。フラグ・レジスタＦ Ｒはマスター・ファイルＭＦ以外のファイルにも存在でき、１以上のフラグ・レ ジスタが１つのカード内に収納され得る。 図６に、本発明の方法の１実施例からなるフロー・チャートを示す。ステップ １００で処理が開始される。これは１以上のコマンドを発生させ、コマンドをア プリケーション・プロバイダＡＰに与えることを含んでいる。アプリケーション ・プロバイダＡＰは次にそのコマンドをカード発行者ＣＩと第三者ＴＴＰに送る 。 ステップ１０１で、カード発行者ＣＩは第１キーＫ１を使って、コマンドＣＯ Ｍの第１確認コードＭＡＣ１を発生させる。コードＭＡＣ１はアプリケーション ・プロバイダＡＰに送られる。コマンドはステップ１０１でカード発行者ＣＩに 送られており、あるいはそれ以前に、たとえばステップ１００で送られている。 同様にステップ１０２で、第三者ＴＴＰはキーＫ２を使ってコマンドＣＯＭの 第２確認コードＭＡＣ２を発生させる。コードＭＡＣ２はアプリケーション・プ ロバイダＡＰに送られる。コマンドはステップ１０２で第三者に送られており、 あるいはそれ以前に、たとえばステップ１００で送られている。 ステップ１０３で、アプリケーション・プロバイダＡＰは確認コードＭＡＣ１ およびＭＡＣ２と一緒にコマンドＣＯＭをスマートカードＳＣに送る。ステップ １０４で、スマートカードＳＣはそれぞれキーＫ１およびＫ２を使って、コマン ドＣＯＭの確認コードＭＡＣ１’およびＭＡＣ２’を発生させることにより、コ ードＭＡＣ１およびＭＡＣ２を再び発生させる。ステップ１０５で、コードＭＡ Ｃ１’が受け取られたコードＭＡＣ１と比較される。これらのコードが等しけれ ば、ステップ１０６に移り、そうでなければ処理がＥｘｉｔに出される。 処理がＥｘｉｔに出されると、カードが受け取ったコマンドＣＯＭは、そのコ マンドを消去するか、あるいはフラグ・レジスタにフラグをセットすることによ り、禁止される。コマンドＣＯＭとそれに伴う確認コードの再送信が要求される 。好ましくは、再送信の数がモニターされ、試行回数が予め決められた数、たと えば３か５を越えると、再送信が終了させられる。 ステップ１０６で、コードＭＡＣ２’は受け取られたコードＭＡＣ２と比較さ れる。これらのコードが等しければステップ１０７に移り、そうでなければ処理 はＥｘｉｔに出される。 ステップ１０７で、スマートカードＳＣはたとえばフラグ・レジスタＦＲで対 応するフラグをリセットすることによりコマンドＣＯＭを可能にする。コマンド ＣＯＭが呼び出されて実行される。ステップ１０８で処理が終了する。 図６には、好ましい実施例の必須のステップのみ示した。第３・第４確認コー ドＭＡＣ３・ＭＡＣ４を決定して評価するような付加的なステップは、簡単化の ため省略した。上記実施例は例示のためにのみ示され、本発明の範囲から逸脱す ることなく、多くの変形と追加が可能であることを当業者は理解するであろう。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｋ 19/073 Ｇ０６Ｋ 19/00 Ｐ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＵ，ＢＧ ，ＢＲ，ＣＡ，ＣＮ，ＣＺ，ＥＥ，ＨＵ，ＩＬ，ＪＰ， ＫＲ，ＬＴ，ＬＶ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，Ｓ Ｇ，ＳＩ，ＳＫ，ＴＲ

Claims (1)

1. 【特許請求の範囲】 １．第１の当事者（ＡＰ）によってスマートカード（ＳＣ）にコマンド（ＣＯＭ ）を入れ、第２の当事者（ＣＩ）によって該カード（ＳＣ）が発行される方法で あって、第２の当事者（ＣＩ）が第１キー（Ｋ１）を用いてコマンドの第１確認 コード（ＭＡＣ１）を発生させ、第三者（ＴＴＰ）が第２キー（Ｋ２）を用いて コマンド（ＣＯＭ）の第２確認コード（ＭＡＣ２）を発生させ、コマンド（ＣＯ Ｍ）をコード（ＭＡＣ１，ＭＡＣ２）と共にスマートカード（ＳＣ）に送り、該 カード（ＳＣ）がそれぞれ第１キー（Ｋ１）および第２キー（Ｋ２）を用いて第 １確認コード（ＭＡＣ１）および第２確認コード（ＭＡＣ２）を再び発生させる ことによりコマンド（ＣＯＭ）を認証し、再び発生させられたコード（ＭＡＣ１ ’，ＭＡＣ２’）を送られたコード（ＭＡＣ１，ＭＡＣ２）と比較するステップ からなることを特徴とするスマートカード（ＳＣ）にコマンド（ＣＯＭ）を安全 に入れる方法。 ２．認証が失敗したとき、カード（ＳＣ）に送ることとそれに続く認証をくり返 し、認証が成功するまで入れられたコマンド（ＣＯＭ）の使用を阻止する請求項 １の方法。 ３．認証が予め決められた回数（Ｎ）−好ましくは、１０回未満−失敗した場合 に、入れられたコマンド（ＣＯＭ）を永久に使用不能にする請求項２の方法。 ４．コマンドを使用不能にすることが、カード内に保存されている第２の当事者 （ＣＩ）のキー（Ｋ１）を変えることにより、カード（１）によって実行される 請求項３の方法。 ５．コマンド（ＣＯＭ）が特定アプリケーション・コマンド（ＡＳＣ）である請 求項１〜４のいずれか１項の方法。 ６．第１確認コード（ＭＡＣ１）および／または第２確認コード（ＭＡＣ２）が ＡＮＳＩ ×９．１９規格によって発生させられるメッセージ確認コードである 請求項１〜５のいずれか１項の方法。 ７．カードがいくつかのアプリケーション（たとえばＡＰ１，ＡＰ２）を有し、 各アプリケーションが第３確認コード（ＭＡＣ３）を備えたコマンドを認証する ため個々の第３キー（たとえばＫ３−２）を備え、第３確認コードが個々の第３ キー（Ｋ３−２）を使って発生させられる請求項１〜６のいずれか１項の方法。 ８．第２の当事者（ＣＩ）がコマンド（ＣＯＭ）の第４確認コード（ＭＡＣ４） を発生させ、該第４コード（ＭＡＣ４）は第１キー（Ｋ１）あるいは第２キー（ Ｋ２）を含んでいない請求項１〜７のいずれか１項の方法。 ９．カードかフラグ・レジスタ（ＦＲ）を有し、各フラグ（Ｆ−１，Ｆ−２，… ）がプロセッサ（１１）のコマンドに対応し、該フラグ（たとえばＦ−２）かセ ットされている場合には、コマンドの実行が禁止される請求項１〜８のいずれか １項の方法。 10．基板（２）と、プロセッサ（１１）およびキー（たとえばＫ１，Ｋ２）を含 むメモリ（１２）とを有する集積回路（１０）とからなるカード（１）であって 、集積回路（１０）が少なくとも２つのキー（たとえばＫ１，Ｋ２）を使って、 受け取ったコマンド（ＣＯＭ）の確認コード（ＭＡＣ１，ＭＡＣ２）を再び発生 させ、再び発生させられた確認コード（ＭＡＣ１’，ＭＡＣ２’）を受け取った 確認コード（ＭＡＣ１，ＭＡＣ２）と比較するようにアレンジされていることを 特徴とするカード（１）。 11．メモリ（１２）が個々のアプリケーション（たとえばＡＰ１，ＡＰ２）を有 するデータ構造からなり、各アプリケーションが確認コードを再び発生させ、そ の確認コードに関連するコマンドを選択的に入れるための個々のキー（たとえば Ｋ３−１，Ｋ３−２）を含む請求項１０のカード。 12．メモリ（１２）がフラグ・レジスタ（ＦＲ）からなり、各フラグ（Ｆ−１， Ｆ−２，…）がプロセッサ（１１）のコマンドに対応し、そのフラグ（たとえば Ｆ−２）がセットされていればコマンドの実行を禁止する請求項１０または１１ のカード。