JP2008537240A - 埋め込みシステム、特にスマートカードにロードされる疑似コードの検証方法 - Google Patents

Abstract

本発明は、特にチップカードなどの携帯用電子装置にロードされるバイトコード（疑似コード）タイプのインタープリタ型言語のアプリケーションの検証と、少なくとも１つのプロセッサ（２）と、ＲＡＭ（５）とを備える携帯用電子装置にロードされる、バーチャルマシン（４２）で解釈可能なアプリケーション（３１）の検証方法に関する。アプリケーションを装置にロードした後で検証する前に、プロセッサ（２）で実行される処理によりアプリケーションのコードのチェックを実行することからなる検証方法であって、サブプログラムの起動時に、ＲＡＭ（５）に実検証コンテキスト（２００ないし２０３）をバックアップするステップと、サブプログラム用の新検証コンテキスト（２０６ないし２０９）を作成および起動するステップと、以前にバックアップされた検証コンテキスト（２００ないし２０３）を復旧するステップとを含むことを特徴とする。

Description

本発明は、埋め込みシステムのコードの一貫性を検証する方法に関する。
本発明は、これに限らないが、より詳しくは、スマートカードにロードされるバイトコード（疑似コード）タイプのインタープリタ型言語のアプリケーションの分野に関する。

‘埋め込みシステム’は、広義で使用され、特に、あらゆる携帯用電子装置、例えば処理およびストレージリソースが比較的制限されるスマートカード（チップカード）のために設計されたシステムを示す。

同様に、‘インタープリタ型言語’は、複数ラインのコードの実行がコード解釈を可能にする補助手段を必要とする、コンパイルされていない言語である。このような言語の一例は、スマートカードのアプリケーションソリューションにおいて非常に広範囲に使用されているＪａｖａ（登録商標）言語である。Ｊａｖａアプリケーションまたは‘アプレット’は、関連Ｊａｖａバーチャルマシン（ＪＶＭ）により解釈される。また、前記バーチャルマシンに相当するものを実装するハードウェアソリューションも存在しているが、その例が専用チップである。‘バーチャルマシン’は、以下において関連インタープリタ型言語の解釈を可能にするソフトウェアタイプの補助手段と、ハードウェアタイプの補助手段とを示す。

疑似コード（バイトコード）、これに限らないが、例えばＪａｖａ、の検証は、Ｊａｖａプラットフォームのセキュリティにおいて重要な要素である。このような検証は、特に、バーチャルマシン、即ちスタック（スタッキングおよびアンスタッキングアクセスを有するメモリ）とレジスタ（索引アクセスを有するメモリレジスタ）とを有するマシンで解釈されるバイトコードプログラムが完全であり（完全性検証）、それが例えばコードの変数のタイプのような特性に従うということを確認することにある。これらの検証作業は、比較的複雑で、リソースを消費する（ランダムアクセスメモリ（ＲＡＭ）の高消費、および長い処理時間）。

スマートカードの開発で、Ｊａｖａソリューションはこのようなスマートカードに組み込まれた。スマートカードの寿命期間中に、新しいアプリケーション、例えばＪａｖａアプレット、が使われるためにカードにロードされる。このようなアプレットは、損傷されるか、または不良になる可能性があり、無許可メモリゾーンを呼び出してバーチャルマシンの故障の原因となる。スマートカードの外観、およびカードに対するプログラムの集積で、このような検証は、利用可能リソースの不足の観点から、全ての埋め込みシステムにおいて極めて複雑になった。

バイトコードタイプのプログラムは他のプログラム、またはサブプログラムを頻繁に呼び出す。呼び出しプログラムと同じ実行コンテキストを共有するプログラムと、特定専用実行コンテキストを有する他の方法のプログラムとは、区別できる。本発明は、特に呼び出しプログラムと同じ実行コンテキストを有するプログラムまたはサブプログラムに対する呼び出しに関する。‘サブプログラム’は、以下において、同じ実行コンテキストを共有するコードの他の部分から、前記コードの一部分が呼び出されたプログラムであるか、または呼び出されたサブプログラム（前記呼び出しプログラムと共通しているコードラインのセット）であるかにかかわらず、到達できる前記コードの一部分を定義するのに使われる。このような呼び出しは、‘Ｇｏｔｏ’または‘ｉｆ’タイプの機能で、またはマクロに対する呼び出し中に行うことができる。

注意すべきことは、一例としてＪａｖａ言語で、サブルーチンまたはサブプログラムを実行させる一対の命令、すなわち、サブルーチンへのジャンプ（Ｊｕｍｐ ｔｏ Ｓｕｂｒｏｕｔｉｎｅ、ＪＳＲ）と、サブルーチンからの復帰（Ｒｅｔｕｒｎ ｆｒｏｍ Ｓｕｂｒｏｕｔｉｎｅ、ＲＥＴ）とが存在するということである。図１は、サブプログラム（Ｂ７乃至ＲＥＴ）を有するコードの一例を、前記サブプログラム（第４行：ＪＳＲ Ｂ７）に対する呼び出しと共に提案している。サブプログラムの終了時にＲＥＴ命令が実行されると、バーチャルマシンは、サブプログラムを呼び出したＪＳＲの次に続いてバイトコードを実行する。ＪＳＲ呼び出し情報を格納するために、情報タイプのいかなるインスタンスもなしに、そのアドレスがバーチャルマシンのスタックに記録される。それは、実行流れによって決まるスタック内の数値である。このような記録の問題は、標準検証器がタイプに基づいて動作し、数値を適切に利用していないということである。したがって、どのコード部分がサブプログラムを呼び出しているのかを静的に判断することができない。

このような検証アルゴリズムは、バイトコード毎に単一化アルゴリズムを適用し、そのアルゴリズムの原理は、以下の通りである：バイトコードで、同じ変数が（例えば、サブプログラムに対する２つの異なるジャンプからの）２つの異なるタイプに収斂される収斂位置で、変数は、前記２つのタイプに共通している第１アンセスタのタイプを取る（共通アンセスタのコンセプトは、Ｊａｖａタイプのオブジェクト指向言語の継承原理に起因する）。そして、タイプ不適合が発生した場合は、‘ＴＯＰ’と呼ばれるタイプが変数に割り当てられる。それから、バイトコードのモデリング中に、バイトコードによって予想されるタイプが受取バイトコードに適合しないと、コードは拒絶される。

サブプログラムで、同一サブプログラムに対する２つの異なる呼び出しは、変数が同一のタイプを有しない場合であっても、実行可能である。したがって、タイプの問題がなくても（２つの異なるコンテキストがあるので、バーチャルマシンによるコード実行中に２つのタイプは介入できない）、検証エラー（不適合タイプ）が起こる可能性がある。

Ｊａｖａカードにおいて疑似コード検証は、違法操作がバイトコードにより使用される要素のタイプに行われないということを確実にする。２つの特性が検証される：バイトコード毎に、スタックの高さは、実行パスに関係なく常に同じである。バイトコード毎に、実行パスに関係なくバイトコードに適合した、変数（レジスタ）、及びスタック段階のタイプが存在する。

この目的のためには、全ての可能な実行パスが静的に調査される。これは、バイトコードの抽象的な実行である。
バイトコードの列毎において、完全性検証は、多くの情報が格納されることを必要とする。ただジャンプターゲットのために、この格納を遂行することが十分であることが明らかになった。さらに、アルゴリズムは、命令ポインタまたは‘プログラムカウンタ’（現在の検証位置でのコード列上のポインタ）のような付加情報、ワークリスト（その後に検証されるコード列のリスト）、および現在フレーム（装置のＲＡＭに記録される、調べられる位置でのレジスタのタイプ及びスタックのタイプのセット）を格納する必要がある。

オフカード処理中にバイトコードが最初に検証される、ＳＵＮ ＭＩＣＲＯＳＹＳＴＥＭＳ（登録商標）ソリューションのような外部検証ソリューションが知られている。一旦確認されると、それはスマートカードにロードされる。このようなソリューションにおける欠点は、バイトコード検証とカードへのロードとの間に、コード不良の可能性があるという事実である。したがって、それらのソリューションは、カードにロードされて実行される初期コードと最終コードとの間で完全性を保証しない。

安全な環境でオフカードで検証が行われる、またプログラムに対する署名を可能にする、ＳＵＮ ＭＩＣＲＯＳＹＳＴＥＭＳ（登録商標）検証器も知られている。カードは、単にプログラムを受け取り次第署名を検証しなければならない。
カードを媒介とするソリューションには、特に、過度なＲＡＭの占有のような欠点がある。

証明つきコードによる検証も知られている。証明つきコードは、オフカードで計算され、プログラムがカードに送信されると、プログラムに付加される。その案は、タイプ情報をコードに挿入することである。その結果、カード上での検証は非常に容易になり、ＲＡＭは非常に少ない容量だけを必要とする。

そのソリューションにおける欠点は、オフカード前処理：証明の計算を必要とすることと、送信されて格納されるデータ（バイトコードおよび証明）のサイズが大きいこと、つまり送信時間が長く通過域の消費が増大することである。

フランス特許第２，８１５，４３４号で保護されるトラスティドロジック（登録商標）検証器もまた知られている。バーチャルマシンにより使用されるレジスタは、単形分割され、すなわち、各レジスタは１つの可変タイプを有する。したがって、ＲＡＭの必要性が減少する。このソリューションの欠点は、方法が２つの要求された追加特性を検証するようその方法を修正するためにオフカードでの計算を必要とすることである。

特定の埋め込みバイトコード検証が実行不可能であることを示す文献がある。特に、「Ｊａｖａバイトコード検証：アルゴリズムおよび形式化」（ｈｔｔｐ：／／ｐａｕｉｌｌａｃ．ｉｎｒｉａ．ｆｒ／〜ｘｌｅｒｏｙ／ｐｕｂｌｉ／ｂｙｔｅｃｏｄｅ−ｖｅｒｉｆｉｃａｔｉｏｎ−ＪＡＲ．ｐｄｆ）は、多変性の従来検証アルゴリズムがＪａｖａカードのような低処理能力の装置では実行できないことを示している。
仏国特許第２，８１５，４３４号

本発明の目的は、処理中に消費されるＲＡＭを制限する埋め込みシステムのコードの一貫性を検証する方法を提案することで、従来技術の欠点を改善することである。本発明は、さらに、例えば、スマートカードのような携帯用電子装置外部でのいかなる前処理も、またはアプリケーションのコードにいかなる要素追加も必要としない。本発明のもう１つの目的は、検証段階中に、ＲＡＭの管理を最適化することである。

本発明は、より少なくＲＡＭを消費するために、現在フレームの特別な管理でコンテキスト（多変性）によってバイトコード検証を行う。サブプログラム検証中に方法検証状況がくるように規定が作られる。この目的のために、（特に、ジャンプターゲットにおけるスタックフレーム、現在フレーム、およびワークリストを含む）現在データの状態をバックアップすることでコンテキストが変更される。サブプログラムの終了時に、サブプログラムの現在コンテキストの現在フレームが先行コンテキストのバイトコード（例えば、ＪＳＲ）の呼び出しの後続に対応するフレームと一体化する。それから先行コンテキストが復旧される。

この目的は、インタリーブできるサブプログラムの呼び出し、例えばＪＳＲ／ＲＥＴを管理することを可能にすることである。

さらに、本発明は、バックアップが示すスタックフレーム（例えば、変更コンテキストに格納されるジャンプターゲットでの現在フレーム）の辞書を長い間に確立することで、ジャンプターゲットでのフレームバックアップの間のメモリ消費を最適化する。通常の使用時は、これらのジャンプに対する呼び出しを管理するために多数の追加的、および時々は重複した情報項目を格納しなければならない。このような多くの情報は、大部分の携帯用電子装置の既存メモリサイズには適合しない。辞書の利点は、メモリにバックアップされる不必要な数の同一スタックフレームを増加しないことであり、したがって、バイトコードとコンパイラの特性による良好な圧縮比を得ることができる。辞書の利点は、消費されたメモリの制限されたリソースを有する携帯用電子装置へのはめ込みを可能にすること、大きいＲＡＭリソースを有する装置のためにより小さいＲＡＭリソースを有する携帯用電子装置の使用を可能にすること、及び、このようにして費用を節減することである。

本発明は、ＲＡＭの適切な管理で既存のソリューションの能力を高めるために既存ソリューションに容易に結合される。

その結果、最も一般的な意味で、本発明は、少なくともプロセッサと、ランダムアクセスメモリまたは‘ＲＡＭ’とを備える携帯用電子装置にロードされる、バーチャルマシンで解釈可能なアプリケーションの検証方法であって、一旦前記アプリケーションが前記装置にロードされて検証される前に前記プロセッサで実行される処理で前記アプリケーションのコードをチェックするように動作する前記検証方法において、サブプログラムの呼び出し中に、前記ＲＡＭに現在検証コンテキストをバックアップするバックアップステップと、サブプログラム専用の新検証コンテキストを作成および起動する作成および起動ステップと、サブプログラムの終了時、以前にバックアップされた検証コンテキストを復旧する復旧ステップと、を含んでいることを特徴とする検証方法を提供する。

１つの実施において、前記作成および起動ステップにおいて例えば現在フレームだけで前記新検証コンテキストは初期化される。
特定の実施において、前記方法は、前記サブプログラムに対する呼び出しが検出された時、呼び出されたサブプログラムのコードの即時チェックの実行をさらに備えている。
より詳しくは、前記方法はコード区画のための従来のステップを含んでいない。
１つの実施において、前記方法は、電源以外に、前記装置外部のリソースの使用を含んでいない。

１つの実施において、前記コンテキストはアプリケーションコードのツリー構造探索を可能にするワークリストを備えている。前記方法は、前記アプリケーションの一列のコードのチェック中、前記ワークリストを前記コード列の可能な後続で更新する更新ステップをさらに備えている。
特に、前記コンテキストは命令ポインタと現在フレームとを備えている。
１つの実施において、全部または一部の同一フレームが１つのアドレス下で辞書と呼ばれる前記ＲＡＭのあるゾーンにバックアップされる。
特定の実施において、同一フレームは１つのアドレス下でバックアップされ、バックアップされるフレームを含む辞書が作成される。

より詳しく言うと、前記ＲＡＭにバックアップされる新フレームそれぞれに対して、全部または一部の前記新フレームが前記辞書に存在しているか否かが検証され、存在する場合、関連ポインタ（ｐｒｔ１）が使用され、存在しない場合、前記辞書への記録が行われ、その新しい記録に関連するポインタ（ｐｔｒ２）が使用される。

ある実施において、前記辞書は、前記フレームの同質部に対応するセクションに分けられる。特に、前記辞書の同質部のうちの１つはレジスタに対応する。変形として、前記辞書の同質部のうちの１つはスタックに対応する。他の変形として、前記辞書の同質部のうちの１つはバイトコードタイプで可変しないレジスタに対応する。

さらに、本発明は、スマートカードと、この検証方法を実行するための、少なくともＪａｖａバーチャルマシンおよび一貫性が検証されるべきである解釈可能なＪａｖａ言語のＪａｖａアプレットを備えるＪａｖａカードと、を提供する。
本発明は、下記の発明の実施に関する説明により容易に理解することができ、添付の図面を参考にする。

一例としての下記の実施態様で、ＪＳＲ命令により呼び出されるＪａｖａサブルーチンは、単に一般に呼び出されることが可能で本発明に関連するサブプログラムの一例である。

図２を参照して、カードモジュール１は、例えばフラッシュタイプの不揮発性メモリ３を制御するマイクロプロセッサ２と、ＲＯＭ４と、ＲＡＭ５とを備える。
前記ＲＯＭ４は、バイトコード検証器コンピュータプログラム４１と、バイトコード実行を可能にするバーチャルマシン４２とを格納する。‘バーチャルマシン’は、バイトコードの実行中に、スタック５１およびレジスタ５２を前記ＲＡＭ５で管理するマシンを意味する。前記スタック５１は、データが積み重なる、また引き出されるトップアクセスメモリである。前記レジスタ５２は、索引アクセスまたはフリーアクセスを有するメモリレジスタである：レジスタのいかなる情報もアクセス可能である。

検証されるプログラムまたはアプリケーション３１は、前記不揮発性メモリ３にファイル形式で格納される。このプログラムは、疑似コードまたはバイトコードの形式であり、本発明は前記バーチャルマシン４２に関連してその完全性を検証することを提案する。

ファイル３１は、前記バーチャルマシン４２によりロードされるファイルである変換アプレット（ＣＡＰ）ファイルである。このファイルは、バイトコード検証が方法毎に発生する場合にＪａｖａ意味で複数の方法を含むことができる。検証される方法Ｍ１で方法Ｍ２が呼び出されると、検証器はＭ２がすでに検証されたか、または後で検証されるか考えて、次のバイトコードへ進む。

図１は、方法Ｍのバイトコードの一例を示す。このバイトコードは、第４行のサブルーチンへのジャンプ（ＪＳＲ）と、第１１行の復帰（ＲＥＴ）とを含む。ＪＳＲにより呼び出されたサブルーチンは、Ｂ７からＲＥＴまで拡張する。

図３を参照すると、バイトコード検証器は、１００で方法Ｍの検証を開始する。１０２で第１のバイトコードＢ１が取られる。１０４で検証される従来のバイトコードであるので、完全性基準（タイプ）の検証が１０６でレジスタと現在フレームのスタックとの比較によりバイトコード上で行われ、前記現在フレームはバイトコードの関数（タイプの変更、新しい変数等）として更新される。現在フレームは、調べられる位置でのバーチャルマシンのレジスタおよびスタックのタイプ・セットである。それが第１のバイトコードであるので、図４に示すように現在フレームデータ２００をメモリに格納することができる。追加データ、例えばワークリスト２０２が、さらにメモリにバックアップされる。ワークリストは、検証される次のバイトコードのリストを備え、前記リストは、処理される次のバイトコードが第２行のバイトコードであることを示すために‘第２行’に置かれる。ワークリストは、コードのツリー構造探索を可能にし、各コード列が有することができる複数の後者を考慮することでこの経路の全ての場合をカバーできるようにする。コード列の‘複数の後者’は、前記列から到達できる他のコード列を示す。現在フレームのデータ項目と、追加データ項目（例えば、ジャンプターゲットでスタックフレームのワークリスト２０２、辞書２０３、およびリスト２０１）とのセットは、現在コンテキストを構成する。

それから、更新されるＲＡＭでバイトコードＢ２およびＢ３に対する検証がコンテキストデータで再生され、特にワークリストは連続的に‘第３行’に進み、その後‘第４行’に進む。

１０８で検証器がＪＳＲと第４行で出会うと、ワークリストは‘第５行’で更新される。次に、ＪＳＲのアドレス、または例えば‘第４行’のような命令ポインタのアドレスが、フレームのスタックに格納される。このアドレスは、ジャンプが起こった場所の‘格納’を可能にする。その後、検証器は１１０で現在コンテキストをＲＡＭ５にバックアップする。図５は、コンテキストのバックアップ実行を示す。とりわけ、現在フレームのポインタｐ１、追加データ（ワークリスト等）のポインタｐ２ないしｐ４、およびコンテキスト終端ポインタｐ５がメモリ２０４に格納される。‘スタックフレーム’または‘フレーム’は、ジャンプターゲットで、即ち前記フレームがバックアップされる時に現在フレームに対応する。バックアップされたコンテキストは、データ項目のセットと方法検証に有用なＲＡＭデータ項目の構造２０４とで構成されている：特にワークリスト２０２、スタックフレーム２００がそうである。

それから新検証コンテキストが１１２で作成および起動される。図６に示されているように、新フレーム２０６と追加データ項目２０７ないし２０９が対応ポインタｐ’１ないしｐ’５でＲＡＭの残余空間内で作成される。この作成中、新フレーム２０６は、サブルーチンジャンプ時に現在スタックフレーム２００に同じく初期化される。その時、レジスタとスタックは従来のコンテキストに適合するが、新コンテキスト内である。

検証アルゴリズムはそれから再開可能で、サブルーチンの開始時にワークリストが‘第７行’に置かれる。
その後、検証アルゴリズムは、バイトコードＢ７、Ｂ８およびＢ９に適用され、メモリのコンテキストデータが更新される。
検証器が第１０行のバイトコードＲＥＴと出会うと、対応ＪＳＲの後者で単一化が確立され、検証される次の要素が現在コンテキストのワークリストで探される。ワークリストが空いている時、バイトコード検証ソリューションに遍在するサブルーチン画定問題は、この例では、一般検証アルゴリズムにより当然に取扱われる：サブルーチンのエンドを示す、新コンテキストのワークリストは、空いている。
それからサブルーチンは終わり、図７に示すように、先行コンテキストが１１４で復旧される。

最後に、検証されるいかなるバイトコードもない時に方法Ｍの検証が１１６で終了する。
方法Ｍで、ある方法が呼び出される場合には、現在タイプが呼び出された方法のタイプと合致するか確認するために前記方法のパラメータの検証を行う。この方法の検証は、前述の通り方法Ｍとは独立に行われる。

本発明の実施において、スタックフレームの辞書が用いられる。スタックフレームはゆっくり変わる場合が多く、それらの多数が同じコンテンツを有する。

図８を参照すると、コードはサブプログラムに対する呼び出しを３つ含む。
Ｂ２でサブプログラム呼び出し中に、現在フレームをＲＡＭ５の‘辞書’と呼ばれる部分にバックアップすることができる。ＲＡＭ５に現在コンテキストをバックアップする場合、現在フレームを指すポインタｐｔｒ１を使用する。
Ｂ６でサブプログラム呼び出し中に、現在フレームをバックアップするためにジャンプ時の現在フレームと同じ辞書のスタックフレームと関連するポインタｐｔｒ１を使用する。
このようなスタックフレームが辞書５３に存在しない時は、新しいエントリｐｔｒ２が辞書で作成される（サブプログラム呼び出しＢｔの場合）。

一実施例で、サブプログラムが取り出されるにつれて、辞書で（即ち、関連ポインタがいかなるコンテキストバックアップにも使用されない時の）未使用スタックフレームが空けられる。

任意に、セーブされたＲＡＭ空間の圧縮および容量を最適化するために頻発する部分スタックフレームエントリで辞書を構築することができる。一例として、辞書でレジスタとスタックとを分離するか、またはレジスタをいくつかのセットに分離することが可能で、特に‘バイトコードタイプ’で可変しないレジスタ（パラメータと共にＪａｖａソースの方法の初めに示される、前記方法の実行中にタイプを変更しない全体変数）が前記方法の各コンテキストが指すセットを構成することができる。

辞書がスタックフレームに限定されないことと、辞書は前記バックアップの大きさを減らすためにコンテンツバックアップ中に使用されるいかなるタイプのエントリも含むことができることが理解される。

サブプログラムを含んでいるバイトコードの一例を示す。 本発明の実行のためのＪａｖａカードアーキテクチャの一例を示す。 本発明の検証方法を示す。 本発明の検証方法の実施においてＲＡＭがどのように変化するかを示す。 本発明の検証方法の実施においてＲＡＭがどのように変化するかを示す。 本発明の検証方法の実施においてＲＡＭがどのように変化するかを示す。 本発明の検証方法の実施においてＲＡＭがどのように変化するかを示す。 ＲＡＭの管理を最適化するための辞書の使用を示す。

Claims (16)

1. 少なくとも１つのプロセッサ（２）と、ランダムアクセスメモリすなわち‘ＲＡＭ’（５）とを備える携帯用電子装置（１）にロードされる、バーチャルマシン（４２）で解釈可能なアプリケーション（３１）の検証方法であって、一旦前記アプリケーションが前記装置にロードされて検証される前に前記プロセッサ（２）で実行される処理で前記アプリケーションのコードをチェックするように動作する前記検証方法において、
   −サブプログラムの呼び出し中に、前記ＲＡＭ（５）に現在検証コンテキスト（２００ないし２０３）をバックアップするバックアップステップと、
   −サブプログラム専用の新検証コンテキスト（２０６ないし２０９）を作成および起動する作成および起動ステップと、
   −サブプログラムの終了時、以前にバックアップされた検証コンテキスト（２００ないし２０３）を復旧する復旧ステップと、
   を含んでいることを特徴とする検証方法。
2. 前記作成および起動ステップ中、前記新検証コンテキスト（２０６ないし２０９）が初期化されることを特徴とする請求項１記載の検証方法。
3. 前記サブプログラムの呼び出しが検出された時、呼び出されたサブプログラムのコードの即時チェックの実行をさらに備えていることを特徴とする請求項１記載の検証方法。
4. コード区画のための従来のステップを含んでいないことを特徴とする請求項１記載の検証方法。
5. 電源以外に、前記装置外部のリソースの使用を含んでいないことを特徴とする請求項１記載の検証方法。
6. 前記コンテキストはアプリケーションコード（３１）のツリー構造探索を可能にするワークリスト（２０２）を備えていることを特徴とする請求項１記載の検証方法。
7. 前記アプリケーションの一列のコードのチェック中、前記ワークリスト（２０２）を前記コード列の有力な後者で更新する更新ステップをさらに備えていることを特徴とする請求項１乃至６のいずれかに記載の検証方法。
8. 前記コンテキストは命令ポインタと現在フレームとを備えていることを特徴とする請求項１記載の検証方法。
9. 全部または一部の同一フレームが１つのアドレス下で辞書（５３）と呼ばれる前記ＲＡＭ（５）のあるゾーンにバックアップされることを特徴とする請求項１記載の方法。
10. 前記ＲＡＭ（５）にバックアップされる新フレームのそれぞれに対して、全部または一部の前記新フレームが前記辞書（５３）に存在しているか否かが検証され、存在する場合、関連ポインタ（ｐｒｔ１）が使用され、存在しない場合、前記辞書（５３）への記録が行われ、その新しい記録に関連するポインタ（ｐｔｒ２）が使用されることを特徴とする請求項１乃至９のいずれかに記載の方法。
11. 前記辞書（５３）は、前記フレームの同質部に対応するセクションに分けられることを特徴とする請求項９記載の方法。
12. 前記辞書（５３）の同質部のうちの１つはレジスタ（５２）に対応することを特徴とする請求項１１記載の検証方法。
13. 前記辞書（５３）の同質部のうちの１つはスタック（５１）に対応することを特徴とする請求項１１記載の検証方法。
14. 前記辞書（５３）の同質部のうちの１つはバイトコードタイプで可変しないレジスタ（５２）に対応することを特徴とする請求項１１記載の検証方法。
15. 少なくともＲＡＭ（５）と、請求項１乃至１４の何れかに記載の方法を実行するためのプロセッサ（２）とを備えるスマートカード。
16. ＲＡＭ（５）と、プロセッサ（２）と、Ｊａｖａ（登録商標）バーチャルマシン（４２）と、前記バーチャルマシンで解釈可能なコードの一貫性が検証されるべきである少なくとも１つのＪａｖａアプレット（３１）とを備え、請求項１乃至１４の何れかに記載の方法を実行するスマートカードタイプのＪａｖａカード。

Images