1

ここのJavaCard 2.2 API ドキュメントに記載されているように、このアプレットを選択したSELECT APDU コマンドを、ファイルまたは内部アプレットの状態選択に関連する可能性のある他のすべてのSELECT APDU コマンドから区別するためにselectingApplet()アプレット メソッドによって使用されるメソッドであり、 true を返します。このアプレットが選択されている場合。process()

私の質問は、なぜこの方法が必要なのですか? さらに一般的なこと:選択したアプレットが SELECT アプレット コマンドを受信する必要があるのはなぜですか? SELECTアプレット APDU を知る必要がある唯一のエンティティは JCREだと思います。

以下のシナリオを提案します：

  1. JCREがCADから APDU コマンドを受信
  2. SELECT APDU コマンドかどうかを確認します。
  3. SELECT APDU コマンドでない場合は、受信した APDU をprocess()選択したアプレットのメソッドに送信します。選択されたアプレットはそれを解釈して実行します（スイッチと if 式を使用し、selectingApplet()メソッドを使用する必要はありません）
  4. SELECT APDU コマンドの場合は、コマンドのデータ フィールドの長さをチェックして、それがSELECTファイルであるか、またはSELECT アプレットであるかを確認します。
  5. SELECT Fileコマンドの場合、JCREはprocess()選択されたアプレットのメソッドに再度送信します。ただし、SELECT アプレットコマンドの場合、JCREdeselet()は現在選択されているアプレットのメソッドを呼び出してselect()から、新しく要求されたアプレットのメソッドを呼び出します。を受信した後True、それを選択して次の APDU コマンドを待機します (さらに、この新しく選択されたアプレットのメソッドに前のSELECT-AppletAPDU コマンドを送信する必要はありません)。process()

上記の実装の何が問題になっていますか? JC 2.2 の現在の実装の利点は何ですか (すべての受信 APDU をprocess()現在選択されているアプレットのメソッドに送信し、異なるSELECTコマンドをselectingApplet()区別します)

現在の実装は脆弱性を提供していると思います! プログラマがアプレットを、そのprocess()メソッドが受信したすべてのAPDUをEEPROMに書き込むように実装すると、カードにインストールされている他のアプレットの AID を取得できます。これは正しいですか？

4

2 に答える 2

3

あなたの最後の点について：いいえ。
APDU は別のアプレットの有効な AID であるため、JCRE はその事実を認識し、それを現在のアプレットに転送せず、現在のアプレットを deseclect し、AID によって参照される別のアプレットを選択して を呼び出しますselectingApplet()。メソッドは、この現在のAPDUだけで選択されたことをアプレットが認識する唯一の方法です
。 たとえば、一部のファイル ポインタをリセットしたり、Securemessaging やその他の認証ステータスをリセットしたりするために使用できます。selectingApplet()

編集：私はデフォルトのアプレットテンプレートを参照していました。それは次のようになります：

process(){
if(selectingApplet()){
return;
}

したがって、実際にはメソッドはブール値を返すだけであり、実際には通常のプロセスメソッドが呼び出されますが、すぐに終了/終了します。

一方、select()メソッドは、最初に選択されたときに呼び出されるアプレットによって上書きされる可能性があります。選択が事前に呼び出され、アプレットの選択を拒否できるため、より強力であることを除いて、それらの間に大きな違いはありません（私が知っていることです）（インターアプレット通信に役立つ可能性があります）

于 2014-11-08T22:35:12.417 に答える