TrustedAPIDに関する推察

たまたまTrustedAPIDについて調べる機会があったので情報として記載します。

まずTrustedAPIDとは、iアプリ(Doja)のJarファイルではなく、JAMファイル(MIDPでいうJADファイル)の中の一要素のことで、ドコモの公認アプリ(iアプリDX)と勝手アプリを見分けるために使用され、それによってアプリに制限を設ける仕組みに使われる。

もともとiアプリMIDPと同じCLDCのKVM(キロバイトオーダーのJavaVM)で動く形態をとっているが、プロファイルの部分が完全なドコモ独自仕様なので、MIDPの証明書による信頼ドメイン分割とは異なり、このあたりの仕様は公開されていない。

わかっていることはこのTrustedAPIDに有効な11桁の数字を設定すれば、『ダウンロード元以外との通信』『電話帳等の内部データへのアクセス』『GPSBluetooth等のネイティブ機能へのアクセス』等が可能なiアプリDXとして、iアプリを配布できるということ。

ちなみにこのTrustedAPIDは「iMenu」中の「メニューリスト」でコンテンツを提供している(ドコモの審査を通過した)コンテンツプロバイダに付与されるものらしく、ドコモショップでその申請方法を聞いたところ、企画書等を用意してからドコモのホームページ(作ろうiモードコンテンツ〜NTT Docomo IP 申込〜)で申し込むと、後日担当者から連絡が入るという流れで進める必要があるとの事。

と、前起きが長くなりましたが今回はそのTrustedAPIDを使ったiアプリ機能制限(iアプリDXであるかないかを見分ける仕組み)の実現方法に関する推察です。

まずは実験。

サイトAからダウンロードできるiアプリDXを用意。このiアプリDXは「Jarファイル」「有効なTrustedAPIDが記載されたJAMファイル(以下、JAMファイル)」「ダウンロード用HTMLファイル(以下、HTMLファイル)」から構成されているものとします。

通常のiアプリダウンロード

この時JAMファイルの「PackageURL」にはホスト名を含む「http://サイトA/…/Jarファイル」という絶対パスでJarファイルを指定しています。また、HTMLファイルからは同一フォルダ内のJAMファイルを相対パスで指定しています。

  1. 携帯電話から「http://サイトA/…/HTMLファイル」にアクセス
  2. ダウンロードボタンからサイトAのJAMファイルにアクセス
  3. 「http://サイトA/…/Jarファイル」をiアプリとしてダウンロード・インストール

【結果】
iアプリDXである旨が表示され、正常にダウンロード完了

実験1

通常のiアプリダウンロードの状態から、JAMファイルとHTMLファイルだけサイトBに移します。

つまり携帯電話は一旦サイトB上のJAMファイルにアクセスした後に、その中で指定されたサイトA上のJarファイルをダウンロードするような状態にします。

  1. 携帯電話から「http://サイトB/…/HTMLファイル」にアクセス
  2. ダウンロードボタンからサイトBのJAMファイルにアクセス
  3. 「http://サイトA/…/Jarファイル」をiアプリとしてダウンロード・インストール

【結果】
iアプリDXである旨が表示され、正常にダウンロード完了

実験2

「通常のiアプリダウンロード」で使用したJarファイル・JAMファイル・HTMLファイルのすべてをサイトBに移します。その際、JAMファイルの「PackageURL」は「http://サイトB/…/Jarファイル」と書き換えます。

  1. 携帯電話から「http://サイトB/…/HTMLファイル」にアクセス
  2. ダウンロードボタンからサイトBのJAMファイルにアクセス
  3. 「http://サイトB/…/Jarファイル」をiアプリとしてダウンロード・インストール

【結果】
「ソフトに誤りがあるため、ダウンロードできません」と表示され、ダウンロードできず

実験3

「通常のiアプリダウンロード」で使用したJarファイル・JAMファイル・HTMLファイルのすべてをサイトBに移します。その際、JAMファイルの「PackageURL」はホスト名を含まない「Jarファイル」の相対パスに書き換えます。

  1. 携帯電話から「http://サイトB/…/HTMLファイル」にアクセス
  2. ダウンロードボタンからサイトBのJAMファイルにアクセス
  3. サイトB上で相対パスとして指定された「Jarファイル」をiアプリとしてダウンロード・インストール

【結果】
「ソフトに誤りがあるため、ダウンロードできません」と表示され、ダウンロードできず

考察

上記「実験1」「実験2」からTrustedAPIDはJarファイルのダウンロード元のホスト名と関連付いていると考えられる。

ただ、ホスト名ではなくIPアドレスと関連付いている、もしくはダウンロードURL全体と関連付いているとも考えられるが、前者はDNSラウンドロビンに影響を及ぼすという点、後者はダウンロードURL変更のたびにTrustedAIPDの再設定が必要になるという管理工数の点から可能性は低いと思われる。

ポート番号についても「ダウンロードURL全体と関連付いている」と同様である。

次に携帯電話からTrustedAPIDとホスト名の関連付けを確認する方法については、通常のiアプリダウンロードの際にプログレスバーが二度進むのに対し、「実験2」「実験3」では一度目の完了(おそらくJAMファイルのダウンロード)の後に二度目の少し進んだところ(端末の表示からおそらくここでも通信が発生していると思われる)でエラーとなることから、ドコモ内にTrustedAIPDとホスト名の関連付けデータが存在し、JAMファイルにTrustedAPIDの記載がある場合は携帯電話からドコモへそのデータの有効性の確認をしているものと思われる。

ただしここでも、一方向の不可逆(ハッシュ)関数等を用いたTrustedAPIDとホスト名の関連付けを確認する手段が携帯電話自身に備わっているとも考えられるが、これでは「実験2」「実験3」でのプログレスバーの進み方が説明できないため、その可能性は低いと思われる。

推察(結論)

TrustedAPIDはJarファイルのダウンロード元のホスト名と関連付いており、その情報はドコモ内で管理され、必要毎に携帯端末から参照される仕組みになっている。

また、iアプリのダウンロード時のJAMファイルにTrustedAPIDの記載がある場合は、それらの仕組みを使って携帯電話がそのTrustedAPIDを有効と判断した場合のみ、iアプリiアプリDXとしてインストールする。

ので、TrustedAPIDが必要な時(iアプリDXを作りたい場合)は、ドコモへの申請が必要である。