ケイパビリティと認証について

※2007年12月の改定にあわせた内容に修正しました。
ケイパビリティと開発者証明書についてまとめておきます。少々長いですが、今後、Symbian v9以降の端末を使用する上では避けては通れない情報だと思います。なお本内容は書籍や自分の体験、伝聞を元に編集しました。間違いが見つかりましたらご指摘頂けると助かりますm(_ _)m。

ケイパビリティとは

Symbian v9以降から導入された「ケイパビリティ」には20種類のカテゴリがあります。これらのカテゴリにはそれぞれ数個ずつAPIが登録されています(ただしSymbian上の全てのAPIがいずれかのカテゴリに属している訳ではないことに注意)。そしてこのケイパビリティを持ったAPIをアプリケーション上で使用する場合には、そのケイパビリティに対しての認証(使用許可)が必要になります。そしてケイパビリティが必要なアプリケーション(SIS)は認証されていないとインストール出来ない仕組みになっています。

ここで一つ注意したいのが、ケイパビリティを必要とするAPIを1つも使用しないアプリケーションは認証が不要ということです。つまりアプリケーションにとっては何が何でもケイパビリティと認証が必要という訳ではないということです。ケイパビリティは基本的にはセキュリティに対してクリティカルな影響を及ぼす機能を持ったAPIに割り振られています。ですのでこれらのAPIを使わなくても簡単なゲームやツールを作ることは可能です。しかし、認証なしアプリケーションの場合はインストール時に「これらは認証されていないアプリケーションですがインストールしても良いですか?」といった旨の警告文が必ず出るようになっています。これを表示させないようにするには認証が必要です(そこまでする必要は無いと思いますが…)。

認証とは

先ほどから出てくる「認証」についてですが、これが「Symbian Signed」や「開発者証明書」と呼ばれているものになります。

「Symbian Signed」はテストハウスが行うテストによってアプリケーションの安全性が(ある程度)確認され、作者の身元が確認されたものに付与されます。対象となるアプリケーション(SIS)に「Symbian Signed」を付与すると、どのデバイスにもインストールすることが可能になります。基本的にはEpocwareやPsilocといった各ソフトベンダーで販売しているシェアウェアがこれに該当します。

ただしそれにはテストハウスにテスト(有償)を依頼する時に法人格が必要になりますので、個人では取得する事が出来ません。そこでSymbian Signedでは「フリーウェアとして公開することを条件」に無料でテストを受け、Symbian Signedが取得できる制度を用意しています(詳細はこちらを見てください)。

「開発者証明書(Dev Cert)」は3年という期限が付きますがこれを付与したアプリケーション(SIS)は実機にインストールすることが可能になります。これを使用すればケイパビリティが必要なアプリケーションをテストハウス提出前に実機にインストールしてテストを行うことができるようになります。ちなみにこれは個人でも簡単に取得することができます(取得方法は「開発者証明書の取得方法と付与方法」を参照)。なお、個人で取得した場合は20種類のケイパビリティ中、13種類(06年10月30日までは10種類でした)までしか許可が下りません(残りの7種類については後述)。さらに1つの開発者証明書に対して1台のデバイス(IMEIによって管理)しか許可が下りません。

Restricted System CapabilitiesとDevice Manufacturer Capabilitiesとは

20種類のケイパビリティの中でも特別なのが4種類の「Restricted System Capabilities」と3種類の「Device Manufacturer Capabilities」です。これらはシステムフォルダ(C:/sys/など)や全てのファイル、DRM保護(デジタル著作権管理)されたコンテンツへのアクセスが自由に出来るようになります。またデバイス上に搭載されたハードウェア(カメラ等)や通信機能に対するローレベルなアクセスも可能になります。これらはその危険性の高さから使用するためにPublisher ID(後述)が必要になります。またDevice Manufacturer Capabilitiesにおいてはそれらを使用するデバイスのメーカーに利用許可を申請する必要があります。

つまりP990iやM600i等で使用したい場合はSony Ericsson、E61やE70で使用したい場合はNokiaにそれぞれ申請する必要があります。その使用に関してもSony Ericssonが公開している承認基準には「ソニエリから見て評判の良いISV(Independent Software Vendor:独立系ソフトウェア会社)であること。さらに高品質なアプリを開発でき、万が一の時は責任が負える会社であること」といった旨が記載されていいますので、仮にアプリケーションが作成できたとしても品質及び企業としての信頼が無ければSymbian Signedを取得するのは難しいかもしれません。それだけDevice Manufacturer Capabilitiesで保護されたAPIはクリティカルなものが含まれているとも言えます。

しかしDevice Manufacturer Capabilitiesで定義されている「TCB」「AllFiles」「DRM」はEComプラグインや万人向けの共有DLLの認証で必要になるくらいで、個人が作成する一般的なアプリケーションではほとんど使用する機会がないので特に心配する必要はありません。(特にTCBはどのアプリケーションベンダー・デベロッパーにも許可される事はありません。)

Publisher IDとは

Restricted System CapabilitiesとDevice Manufacturer Capabilitiesを使用するためには「Publisher ID」というものが必要になります(具体的にはOpen Signed - OfflineやExpress Signed、Certified Signedで必要)。これはTC TrustCenterVeriSignから取得できるSymbianに対する身分証明書です。ただし取得手続きには会社の登記簿が必要なので個人では取得する事が出来ません。またこれはSymbian専用のコンテンツなので、他の認証には使用できないので注意が必要です。取得コストとしてTC TrustCenterは200USD、VeriSignは250USDが必要です。また有効期限は1年間となっているので、期限が過ぎたら再度取得しなおす必要があります。

なお、Symbian SignedはTC TrustCenterのPublisher IDを取得する事を強く推奨しており、Express SignedではTC TrustCenterのものしか受け付けないので新しく取得する場合はこちらから取得した方がよいです。

以下はそれぞれのPublisher IDの取得申請フォームです。

DLLとケイパビリティの関係について

余談ですがここでDLLとケイパビリティの関係の一例としてM-FEPの例を挙げておきます。まずM-FEPではDevice Manufacturer Capabilitiesに属しているAPIは一切使用していません。にも関わらず必要なのは、まずは、「M-FEPがDLL」であり「DLLはその呼ばれる先(EXE:実行形式ファイル)よりも多いケイパビリティが必要」というルール(他にもデータケイジングやEXEの実行場所の限定といったルールが存在します。これらに興味がある方は「Symbian OS プラットフォームセキュリティ」や「Symbian OS Internals リアルタイムカーネルプログラミング」といった関係書籍を参考にして下さい)が存在するからです。さらにM-FEPのFEPという性格上、どのアプリからも呼ばれる可能性があり、そのアプリではどのケイパビリティが必要なのかが解りません。その為にFEPでは「All-Tcb(Tcb以外の全てのケイパビリティ)(Tcbは最も重要なフォルダにアクセスする為のケイパビリティで、サードパーティ製アプリに許可される事は無いとされています。さらに標準アプリでTcbを持ち、FEPを使用するようなアプリケーションは無いことからTcbを除外)」が必要ということになります。さらにこれらの理由により「13種類のケイパビリティを許可した開発者証明書」ではM-FEPが標準PIMアプリケーションやWeb、MIDPで動作できないのです。

国内キャリア端末ではなぜインストールできないアプリが存在するのか

デバイスと各認証レベルの関係についてですが、先ほど「Device Manufacturer Capabilitiesは各デバイスメーカーに任されている」と書きましたが、「デバイスにインストールできる認証のレベル」もデバイスメーカー(や端末を販売するキャリア)に任されています。つまりデバイス毎にインストール可能な認証レベルが設定されているとことです。基本的にSIMアンロック状態で販売されているデバイスは制限が無く、SIMロック状態で販売されているデバイスは各キャリアのポリシーによって例えば「Dev Cert認証SISはインストール不可」や「Symbian Signed認証SISのみインストール可能」といった制限が掛けられる傾向にあります。この辺の話しが国内キャリアから販売されたデバイスのインストール制限に繋がっていきます。

最後に

自分は最初、Symbian v9からのセキュリティモデルを見たときは「これでは開発者(特に日曜プログラマ)の自由を奪ってしまう。Symbianの今後は大丈夫だろうか?」と心配していました。ただ、色々と調べていくうちにこれは理にかなった方法であるなと納得できるようになりました。

例えばスマートデバイスは通信機能を備えている上に個人情報も保有しています。単純に考えて、「電話帳のデータを通信網を利用して配信する」とか「特定のメアドに対して指定した内容のメールを送信する」といったアプリケーションが広まったらそれは大変な脅威になると思われます。そういった危険性から守る為にはやはり使用できるAPIに制限を設け、認証という形で管理する仕組みは必要になります(「もし改竄されたらどうするか?」という話もありますが、今のSymbianにはその危険性から守る仕組みも存在します。しかしここでは割愛します)。

確かにPalmやザウルス等と比べると気軽には手を出しにくくなったかもしれませんが、これも時代の流れという物なのかも知れません。しかし、だからといって国内キャリアのように完全にクローズドにする訳ではなく(セキュリティを維持するという点では最適な方法だと思うので否定はしません。あとSymbianデバイスという括りでクローズにすることは不可能ですし)、「Freeware」ような入り口をSymbianは用意していますし、SymbianSigned内のルールや仕組みも改定されたりしています。この辺りにSymbian側のユーザーに対する歩み寄りを感じます。(Freewareは廃止されました)SymbianあってのSymbianユーザーですし、SyumbianユーザーあってのSymbianです。デバイスの繁栄にはメーカーとユーザーの相互理解が必要不可欠ではないかと思う今日この頃です。

おまけ

参考までにケイパビリティのリストを載せておきます。ケイパビリティは全部で20種類で、そのうち3種類は「Device Manufacturer Capabilities」と呼ばれ、認証にはSymbian Singed以外に端末メーカーの許可が必要です。また別の4種類は「Restricted System Capabilities」と呼ばれ、認証にはPublisher IDが必要になります。残りの13個は特に申請も無く開発者証明書が取得できます。

  • Device Manufacturer Capabilities(認証には端末メーカーの許可が必要)
    • [Tcb]:「\sys」「\resource」への書き込みに必要
    • [AllFiles]:「\sys」の読み取りと「\private内の他のアプリのフォルダ」の読み書きに必要
    • [Drm]:著作権保護されたコンテンツへのアクセスに必要
  • Restricted System Capabilities(認証にはPublisher IDが必要)
    • [CommDD]:ネットワーク機能への低レベルなアクセス
    • [DiskAdmin]:ファイルシステムへの低レベルなアクセス
    • [MultimediaDD]:マルチメディア機能への低レベルなアクセス
    • [NetworkControl]:ネットワーク機能への低レベルなアクセス
  • System Capabilities
    • [WriteDeviceData]:特定のデバイス情報の書き込み
    • [TrustedUI]:該当APIなし
    • [ReadDeviceData]:特定のデバイス情報の読み取り
    • [ProtServ]:端末内のサーバーアクセス関係
    • [SwEvent]:キーやペンイベント関係
    • [SurroundingsDD]:該当APIなし
    • [PowerMgmt]:電源管理関係
  • User Capabilities
    • [LocalServices]:Bluetoothや赤外線通信関係
    • [Location]:現在位置に関する情報
    • [NetworkServices]:無線LANやデータ通信等の通信関係
    • [ReadUserData]:特定のユーザー情報の読み取り
    • [UserEnvironment]:カメラやオーディオへの高レベルなアクセス
    • [WriteUserData]:特定のユーザー情報の書き込み

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS   最終更新のRSS
Last-modified: 2014-02-16 (日) 09:59:24 (1137d)