X.509 PKI を用いた信頼された MIDlet スイート

証明された MIDlet スイートは、MIDlet スイートの署名者を認証することにより信頼され、そして保護ドメインが割り当てられます。 保護ドメインによって許容され、付与されたパーミッションによって保護された機能を MIDlet スイートは実行することができます。 ここで定義された機構は、デバイスが署名者について確認し、MIDlet スイートを信頼することができるように X.509 公開鍵基盤に基づく MIDlet スイートの署名と認証を可能にします。

この仕様の実装が、PKI を使用して署名された MIDlet スイートを信頼された MIDlet スイートであると認めるなら、以下の書式と処理に従って、それらの署名について確認しなければなりません。

MIDlet スイートは JAR に署名をすることによって保護されます。 署名と証明書は属性としてアプリケーション・ディスクリプタに追加します。 デバイスは署名について確認するためにそれらを使用します。 デバイスは、ルート証明書領域をデバイスの保護ドメインに使用することで認証を実施します。 処理と書式の詳細は以下の通りです。

参照

MIDP 2.0 デバイスが、転送とセキュリティに標準の Internet、ワイヤレスのプロトコル、および技術を使用することで動作すると想定します。 Internet コンテンツの保証のために、既に存在している公開鍵暗号のための Internet 標準をベースとするメカニズム:

用語の定義

用語信頼された MIDlet スイートパーミッション、および保護ドメインは、MIDP アプリケーションのためのセキュリティによって定義されます。

以下に追加の用語を定義します:

用語定義
保護ドメイン・ルート証明書デバイスがダウンロードした MIDlet スイートの検査と承認をする際に、暗黙のうちに信頼する保護ドメインに関連した証明書。

MIDlet スイートへの署名

セキュリティ・モデルには、MIDlet スイート、証明者、および公開鍵証明書が関わります。 どのような公開鍵方式の認証においても、他の証明書について確認をするために使用する、1セットのルート証明書に基づきます。 ゼロかそれ以上のルート証明書がデバイスには存在する必要があるでしょう。 さらに、ルート証明書は SIM(WIM) カード・ USIM モジュールなどのリムーバブル・メディアで存在するかもしれません。 実装は X.509 証明書と対応するアルゴリズムをサポートしなければなりません。デバイスは追加の署名メカニズムと証明書フォーマットをサポートすることができます。

MIDlet スイートの署名者は、配布、サポート、および使用に関する請求に責任を持つ開発者あるいは何らかの存在であるかもしれません。 署名者はデバイス上の保護ドメイン・ルート証明書の1つによって有効になる公開鍵証明書を必要とします。 公開鍵は、MIDlet スイート上の署名について確かめるために使用します。 アプリケーション・ディスクリプタが、RSA X.509 証明書を含むものとして公開鍵を提供します。

JAR マニフェストの中で定義された属性は、署名で保護されます。 アプリケーション・ディスクリプタの中で定義された属性は保証されません。 属性がマニフェストに現れると、それはアプリケーション・ディスクリプタからの異なる値によって上書きされてはなりません。 信頼された MIDlet スイートに関しては、アプリケーション・ディスクリプタの値はマニフェストにおける対応する属性の値と一致しなければなりません。 そうでなければ、MIDlet スイートをインストールしてはなりません。 定義が1つなら、MIDlet.getAppProperty メソッドはマニフェストからの属性値を返さなければなりません。 そうでなければ、(もしあれば)アプリケーション・ディスクリプタからの値を返します。

属性値が等しいという要求仕様は MIDP 1.0 と異なっており、署名のされたアプリケーションの使用において、これらの手続きで確かめなければならないことに注意が必要です。 信頼されていないアプリケーション・ディスクリプタに関しては、マニフェスト属性よりもアプリケーション・ディスクリプタ属性を優先的に取り扱う MIDP 1.0 の規則に従わなければなりません。

署名証明書の作成

  1. 署名者は、デバイスにおける認証ポリシーを意識し、適切な認証局にコンタクトする必要があります。 例えば、署名者はその識別名(DN)と公開鍵(通常、パッケージ内の証明書が要求する)を認証局に送る必要があるかもしれません。
  2. CA は RSA X.509(バージョン3)証明書を作成し、それを証明者に返します。
  3. 複数の CA を使用するなら、アプリケーション・ディスクリプタの全ての署名者証明書が同じ公開鍵を含まなければなりません。

アプリケーション・ディスクリプタへの証明書の挿入

  1. 証明書パスは証明者証明書とルート証明書を省略することを除く全ての必要な証明書を含みます。 ルート証明書はデバイスに存在するでしょう。
  2. パスの各証明書は、以下のようにアプリケーション・ディスクリプタにエンコード(Base64 を使用し、改行を除きます)して挿入します:
    MIDlet-Certificate-<n>-<m>: <Base64 エンコードした証明書>

    <n>:= ディスクリプタの中の最初の証明パスが 1 と等しい値、または追加の証明パスは前の数から 1 加算した数です。 これは証明書に対応するルート証明書がデバイスに存在するかを確認するためにテストする順序を定義します。 下記の MIDlet スイートの認証セクションを参照してください。

    <m>:= 証明パスにおける証明者の証明書に 1、またはその後の中間証明書は前の数よりも 1 大きな数です。

JAR の RSA SHA-1 署名の作成

  1. PKCS #1 バージョン 2.0 標準規格 [RFC2437] の EMSA-PKCS1-v1_5 エンコード手法によって、JAR の署名は署名者秘密鍵で作成します。
  2. 署名は Base64 でエンコードし、ただ一つの MIDletJar-RSA-SHA1 属性に改行を省いて書式化し、アプリケーション・ディスクリプタに挿入します。
    MIDlet-Jar-RSA-SHA1: <Base64 でエンコードした JAR 署名>

MIDlet スイートの署名者が保護ドメイン・ルート証明書の所有者にとって、保護ドメインの利害関係者の資産と可能性を保護することに責任があり、それに署名する前に、MIDlet スイートに対してそのためのチェックする際に適切な注意を発揮しなければならないことに注意すべきです。 信頼する関係(場合によっては法的な協定によって結ぶ)がある場合は、保護ドメイン・ルート証明書の所有者はサード・パーティおよびいくつかの状況(MIDlet の作者)による、MIDlet スイートに対する代理による署名を実施することができます

MIDlet スイートの認証

MIDlet スイートをダウンロードするとき、デバイスは認証が必要となるか否かをチェックしなければなりません。 属性 MIDlet-Jar-RSA-SHA1 がアプリケーション・ディスクリプタに存在するなら、以下のように、署名者証明書と JAR 署名について確認することによって、JAR を認証しなければなりません。

アプリケーション・ディスクリプタに MIDlet-Jar-RSA-SHA1 属性がなければ、信頼されていない MIDlet スイートとされて認証を行いませんが、インストールおよび呼び出しはできます。

署名者証明書の確認

証明パスはアプリケーション・ディスクリプタからの証明者証明書と他の証明書に必要とされるが含まれていないルート証明書から成ります。

  1. 署名者証明書のためにアプリケーション・ディスクリプタの属性 MIDlet-Certificate-1-<m><m>1 から始まり、その名前を持つ属性がなくなるまで 1 ずつ増加します)から証明パスを得ます。 それぞれの属性の値は Base64 でエンコードされた証明書であり、必要に応じてデコードおよび解析を行います。
  2. 保護ドメインの保護ドメイン・ルート証明書の権威情報源を使用し、RFC2459 で説明されている基本的なパス確認処理を使用して証明パスが正当であることを確認します。 最初の署名者からルートまでの連鎖が正当であると確認し、保護ドメイン・ルート証明書を含む保護ドメインへの MIDlet スイートの割り当ておよび手続きを行います。
  3. MIDlet-Certificate-<n>-<m><n>1 以上の属性が存在していて、MIDlet-Certificate-<1>-<m>の証明書について確認した後に証明パスを証明できないなら、<n>の前の値に 1 を加算し、ステップ1と2を実行します。

表1 - 証明者証明書の検証を完了するまでの動作。

結果動作
<n>パスを有効にすることを試みました。 証明書のための発行人の公開鍵をまったく発見することができないか、または証明パスのいずれも有効確認できません。 認証は失敗し、JAR のインストールは許容されません。
証明および正当であると確認された1つ以上の完全な証明書パスがあります。 実装は、確認が最初に成功した証明と許可に使用する証明書パスを使用して、署名の検証を続けます。
1つの完全な証明書パスだけが、証明および正当であると確認できました。 実装は署名の検証を継続します。

MIDlet スイートの JAR の確認

  1. 検証済み署名者証明書(前述)から公開鍵を取得します。
  2. アプリケーション・ディスクリプタから MIDlet-Jar-RSA-SHA1 属性を取得します。
  3. 属性の値から Base64 のデコードを行い、PKCS #1 署名 [RFC2437] を得ます。
  4. 署名について確認するために、署名者の JAR の公開鍵、署名、および SHA-1 ダイジェストを使用します。 署名検証に失敗するなら、アプリケーション・ディスクリプタと MIDlet スイートを拒絶します。 実装は、失敗した JAR のインストールを拒否しなければならず、また MIDlet スイートから MIDlet が呼び出されることを許容してはなりません。

証明書について確認し、署名について確認し、そして JAR について確認するステップが、そのときに一度全て成功すると、MIDlet スイートの内容は完全であることが確認されており、署名者の身元も確認されています。 インストール時に、この処理を実行しなければなりません。

MIDlet スイートの出所の検証結果の概要

前述の MIDlet スイートの証明者の身元の証明で説明されているように、デジタル署名の確認を実行するステップが不可欠です。 検証の結果は認証に対する直接の影響を持ちます。 以下の表2に、署名検証の主導でインストール時に認証をさらに使用する状態をまとめます。

表2 - MIDlet スイートの出所の検証の概要

初期状態検証結果
JAD が提供されない JAR をダウンロードしました。 認証を実行できませんが、JAR はインストールすることもできます。 MIDlet スイートは信頼されていないとして扱います。
JAR が提供されますが JAR は署名がありません。 認証を実行できませんが、JAR はインストールすることもできます。 MIDlet スイートは信頼されていないとして扱います。
JAR は署名されているのですが、ルート証明書の連鎖を確認する鍵の保管庫にルート証明書の提供がありません。 認証を実行できないため、JAR のインストールは許容できません。
JAR は署名されており、パスの証明書は期限切れです。 認証を完了できないため、JAR のインストールは許容できません。
JAR は署名されており、期限切れ以外の理由で拒絶される証明書です。 JAD を拒絶し、JAR のインストールは許容できません。
JAR は署名されており、証明パスは検証に成功したものの、署名の検証には失敗しました。 JAD を拒絶し、JAR のインストールは許容できません。
JAR は署名されており、証明書パスは検証に成功し、署名の検証にも成功しました。 JAR のインストールは許容されます。

認証と認証結果のキャッシュ

認証と認証処理の実装は、JAR、アプリケーション・ディスクリプタ、および認証情報から検証に関連する情報を計算するとき、その後の使用のために結果をキャッシュとして保存または転送することがあります。このキャッシュされた情報はみだりに変更されることができないようにしなければならず、また別の方法による危険からも保護されることを確実にしなければなりません。そして、この認証情報を使用します。

MIDlet スイートを認証し、認可するために使用する MIDlet スイートとセキュリティ情報が危険に晒されないようにすることは不可欠です。例えば、MIDlet スイートのリムーバブル・メディアへの保存や他のアクセスの使用によって破壊されるかもしれません。

分割 VM 実装におけるセキュリティ

分割 VM(CLDC 5.4.6)を使用する環境で、JAR を使用するセキュリティ機構を実装することが可能ですが、これはデバイス・フォーマットに JAR を変換することを前提としています。JAR は MIDlet のセマンティクスを忠実に維持している限り、ネットワークに登録します。 変換が一度行われると、アプリケーションのデバイス・フォーマットは改ざん耐性を保証し、認可されたパーミッションを維持しなければなりません。 この種のネットワーク・セキュリティ基盤が既に存在していて、それがこの仕様(そして、JSR に基づく仕様の全てを見通す)による全ての保護に要求される形式をサポートしているなら、MIDlet スイート・セキュリティを受け入れた実装が、デバイス・フォーマットによる認証とパーミッションに基づき、デバイス上において実際に実行する内容として MIDlet 由来のこれらの実装フォーマットを使用することができます。 MIDlet スイートのデバイス・フォーマット・バージョンを認証して認可する詳細は、実装に特有でありこの仕様によってカバーしません。

信頼された MIDlet スイートのための MIDP X.509 証明書プロファイル

保証されている信頼された MIDlet スイートは HTTPS と同じような証明書プロファイルをベースに使用します。プロファイルは RFC2459 Internet X.509 公開鍵暗号基盤と CRL プロファイル [RFC2459] をベースとする WAP 証明書プロファイル、WAP-211-WAPCer-20010522-A {WAPCert] に基づきます。 詳細は javax.microedition.pki のパッケージ・ドキュメントを参照してください。

OTA のための証明書処理

デバイスはキーの用法拡張が提供されるとき、拡張子が digitalSignature ビットをセットしていることを確認しなければなりません。 デバイスはキーの用法拡張を認めなければなりません。そして提供されるときには、拡張子が id-kp-codeSigning オブジェクト識別子を含むことを確認しなければなりません(RFC2459 セクション 4.2.1.13 を参照)。

アプリケーション・ディスクリプタはディスクリプタ証明書の連鎖に自己発行のルート証明書を含むべきではありません。 しかしながら、MIDP デバイスは連鎖において、いかなる他の証明書をも扱い、X.509 v3 自己発行 CA 証明書の中の連鎖における連鎖を明確に拒絶することはありません。

証明書の期限切れと取り消し

アプリケーション・ディスクリプタから提供された証明書の期限切れと取り消しは認可手続きを行う中(特に証明書パスの検証において)でチェックします。 そのような情報は証明書自体から取得可能なため、証明書の期限切れはデバイスにおいてローカルにチェックします。 証明書の期限切れの検証は、証明書パス検証の本来的で義務的な部分です。

証明書の取り消しはより複雑なチェックです。要求をサーバーに送る必要があり、その結果受信した応答に基づいて決定を行います。 適切な手段がデバイスに実装されているなら、証明書の取り消しを行うことができます。 そのような機構は、MIDP 実装の一部ではなく、またこのため MIDP 2.0 セキュリティ・フレームワークの一部ではありません。

証明書の取り消しをデバイスで実装するなら、それはオンライン証明書ステータス・プロトコル(OCSP)[RFC2560] をサポートすべきです。 他の証明書の取り消しプロトコルをサポートするなら、これら他のプロトコルのサポートによって証明書の取り消しが示されるかもしれません。 この場合、OCSP プロトコルよって受け取った結果に関わらず、証明書の取り消しとみなすことが許されます。

MIDlet スイートの署名の例

保護ドメイン・ルート証明書とそれらの関連署名処理を構造化する多くの手法があります。 これらの例は、この仕様による概念のいくつかを例証することを前提としたもので、MIDlet PKI 署名を使用する方法を制限するものではありません。 異なる粒度による取り消し(証明書の取り消しをデバイスが対応して提供する場合に)を MIDlet に行うことを許容する例を示します。

例 1 - 開発者は署名証明書を所有している場合

これは JAD に(署名者の自己同一性を通して)MIDlet スイートの素性をエンコードします。 証明書が取り消されると、全てのユーザーのためのあらゆるデバイス上の全ての開発者によって署名された MIDlet が、その配下の実行許可を取り消すでしょう。

  1. 開発者は MIDlet ネットワーク・アプリケーションを作成します。
  2. 開発者は JAR マニフェストにパーミッションをエンコードし、最終的な MIDlet JAR を作成します。
  3. 開発者は署名証明書で非公開−公開鍵ペアを作成し、1つ以上の保護ドメイン・ルート証明書で証明書に署名します。
  4. 開発者の証明書は、MIDlet JAR に署名して関連する JAD エントリを作成するために使用します。
  5. MIDlet JAR は適切に配置された JAR と共に配布され、適切な保護ドメイン・ルート証明書と共に MIDP 2.0 適合デバイスで実行することができます。

例 - 保護ドメインの利害関係者が署名証明書を所有している場合

これは JAD に(MIDlet スイート開発者ではない)署名者の素性をエンコードします。 証明書が取り消されると、この特定の証明書がある全ての書名付き MIDlet の実行許可を取り消すでしょう。

  1. 開発者は MIDlet ネットワーク・アプリケーションを作成します。
  2. 開発者は JAR マニフェストに許可をエンコードし、最終的な MIDlet JAR を作成します。
  3. 保護ドメイン利害関係者の署名証明書(必ずしもルート証明書であるというわけではない)は、MIDlet JAR に署名して関連する JAD エントリを作成するために使用します。
  4. MIDlet JAR は適切に配置された JAR と共に配布され、適切な保護ドメイン・ルート証明書と共に MIDP 2.0 適合デバイスで実行することができます。