セキュリティモデルを構成する3つのコンセプト：Symbian OS開発の勘所（10）（4/4 ページ）

[大久保 潤 管理工学研究所，＠IT MONOist]

データケージング ― ファイルのアイソレーション

　セキュリティに関しては、もう1つ押さえておかなければならないコンセプトがあります。それがデータケージング（data caging）です。例えばダウンロードしてきた音楽ファイルがDRMで保護されていても、解読を行うdecryptorから自由にアクセスができるようではクラックされるのも時間の問題です。携帯電話にためてあるプライベートデータがファイルとして読める場合も同様です。マルウェアに吸い上げられて、どこかにこっそり送信されてしまうことを完全に防ぐことはできません。この場合の共通の問題点は、

あるユーザーに属するファイルは、そのユーザーの権限で起動したプログラムからは等しく読み書きできてしまう

というところにあります。本当に警戒すべきなのは許可されていないプログラムがファイルを読み書きすることなのですが、古典的なユーザー権限モデルではこれをガードする方法がありません。

　そこでSymbianが導入したコンセプトがデータケージングです。アプリケーションごとにプライベートなディレクトリを用意し（籠 == cage）、その中にアプリケーション固有のデータを格納するようにします。これにより、明示的に共有をしてしないデータに対して、所有者ではないプロセスが必要なケイパビリティを持っていない場合のアクセスが抑止できます。

　このデータケージングが導入された以降、Symbian OSのファイルシステムは表4のような構成となりました。

	\sys ・ システムが使用するファイルを格納するディレクトリ ・ 読み出しにはAllFilesケイパビリティが必要 ・ すべての実行ファイルは\sys\bin以下に格納され、ここに対する書き出しはTcbケイパビリティが必要
	\private ・ プログラムごとのプライベートディレクトリが\private\<SID>という形式で格納される ※<SID>はアプリケーションのUIDと同様にSymbianから取得するセキュリティ用のユニークID ・ \private\<SID>は、同じSIDを持つプロセスから制限なくアクセスできる ・ ほかのプロセスはAllFilesケイパビリティが必要 ・ プライベートディレクトリの割り当てはインストーラが行う
	\resource ・ 読み込み専用のリソースファイルが配置される ・ 読み込みにはケイパビリティは不要だが、変更にはTcbが必要。よってインストーラのみがコンテンツを追加できる ・ 具体例 \resource\app：アプリケーション用のリソース格納ディレクトリのトップ \resource\fep：FEP用のリソース格納ディレクトリのトップ ・ プライベートディレクトリの割り当てはインストーラが行う
	\<others> ・ 読み書き自由な保護されないディレクトリ
表4　ディレクトリの構成

どうやって実現するのか ― 署名プロセスとインストーラの連携

　信頼、ケイパビリティ、データケージング、Symbian OSがセキュリティのために用意した3つのコンセプトの説明は完了しました。しかしこれらはコンセプトであり、実現にはさらに要素が必要です。インストールしようとしているプログラムが本当に信頼に足るのかを認証するプロセスと、認証されたプログラムを携帯電話に受け入れるプロセスです。前者はSymbian Signedという手続きで、後者は携帯電話上のインストーラプログラム（SWInstaller）で実現されます。

　Symbian Signedとは、開発者が作成したインストールパッケージ（.SISという拡張子が付くことからSISファイルと呼ばれます）をしかるべきキーで電子署名することです。具体的な手順は以下のとおりです。

1. 開発者はVeriSignからACS Publisher IDという開発者自身を証明するIDを取得する。
2. 開発者はACS Publisher IDを使って、作成したSISファイルに開発者認証を行う（自分が作ったSISファイルであることを保証する）。
3. 署名されたSISファイルはSymbian Signedポータルを経由して、テストハウスに送られる。テストハウスはプログラムが安定しているか、規約を守っているかを確認する包括試験と、アプリケーションが使用を希望しているケイパビリティに関してフォーカスした試験の2つを行う。
4. 問題がなければSISファイルは認証機関に渡され、ACS Publisher IDに代わって、Symbianへのチェーンを持つ別のIDで再署名される。
5. 再署名されたSISファイルは開発者の手元に戻され、出荷が可能となる。

　これらの結果、携帯電話にインストールされるSISファイルは、身元が分かった開発者が作ったものであり、かつ必要なケイパビリティだけを要求するということが保証されます。これを受けて、セキュリティの最後の扉である携帯電話上のインストーラがSISファイルのインストールを行います。

　インストーラはSISファイルが必要だと主張しているケイパビリティの検証を行います。もしSISファイルの必要とするシステムケイパビリティが証明書によって指定されていなければ、インストールを中断します。不足しているものがユーザケイパビリティであれば、ユーザーに対して許可の問い合わせを行い、インストールの継続もしくは中断の指示を仰ぎます。最終的にインストーラは\private\<SID>にアプリケーションのプライベートディレクトリを作成し、バイナリファイルを\sys\bin以下に格納します。こうしてインストールが完了したアプリケーションこそ、すべてのステークホルダーの利益を侵害しない、信頼に足るアプリケーションなのです。

※補足しておくと、ケイパビリティをまったく必要としない、またはユーザケイパビリティしか必要としないという場合は自己署名（self signed）という方法があります。makekeysというコマンドを用いて証明書を作成し、それを用いてSISファイルを署名することができます。

システムケイパビリティを必要とするアプリケーションの場合、自己署名だけでは開発の期間を乗り切ることができません。認証機関による署名が済んでいないので、実機へのインストールが拒否されるからです。これを回避するため開発者証明書（Developer Certificate）という仕掛けが用意されています。どの電話機に対して、どのケイパビリティが必要かをSymbian Signedに対して申請することにより、開発専用の証明書が入手できます。これを使ってSISファイルを署名することで、システムケイパビリティが必要なソフトウェアの開発が可能となります。

---

　今回は携帯電話でセキュアな環境を実現するためにSymbian OSが取ったデザインの概説を行いました。より興味を持たれた方は、http://www.symbiansigned.comなどをご覧いただければと思います。

　ほかの環境から引っ越してこられる際のお手伝いとなることを目的として、なぜそうなっているのか、ほかの環境とどう違うのか、という視点でSymbian OSの概要を解説してきたこの連載も、今回のセキュリティ周りをもって一応の完結となります。些少（さしょう）なりとも本連載がSymbian OSに移行してこられる方の役に立てば幸いです。（連載完）