JP5190800B2 - プログラムの実行制御システム、実行制御方法、実行制御用コンピュータプログラム - Google Patents

Description

本発明は、プログラムの実行制御システム、実行制御方法、及び実行制御用コンピュータプログラムに関し、特に、携帯端末などの情報通信端末に格納されているシステム及びデータを保護しながらアプリケーションプログラム等の実行を可能とする実行制御システム、実行制御方法、及び実行制御用プログラムに関する。

携帯端末などの情報通信端末が、有線または無線のネットワークを介して外部からアプリケーションプログラムやデバイスドライバ或いはライブラリなどを取り込む場合、取り込んだプログラムの悪意ある動作等から、情報通信端末内に保持してあるデータに不正にアクセスされたり、端末のシステムの安定した動作が阻害されたりする虞がある。そのため、プログラムなどの配布元を確認したり、プログラムが配信途中で改竄されていないかどうかを検証したり、プログラムが通信端末のシステム及び資源へアクセスする際に制限をする実行制御技術が必要である。この種の実効制御技術は、通信端末に外部メモリカードを装着してアプリケーションプログラムなどを取り込む場合にも必要となる。
従来のアプリケーションプログラムの実行制御手法について簡単に説明する。
文献１には、Ｌｉｎｕｘ（登録商標）のセキュリティを強化するＳＥＬｉｎｕｘ（Ｓｅｃｕｒｉｔｙ−ＥｎｈａｎｃｅｄＬｉｎｕｘ）についての説明がある。このＳＥＬｉｎｕｘを通信端末やコンピュータ端末に導入すると、ＳＥＬｉｎｕｘモジュールがＬｉｎｕｘカーネルに組み込まれ、セキュリティ・ポリシー・ファイル（設定ファイル）とＳＥＬｉｎｕｘ拡張コマンドが追加される。セキュリティ管理者は、ＳＥＬｉｎｕｘ拡張コマンドを実行してセキュリティ・ポリシー・ファイルを参照し或いはその内容を変更してＳＥＬｉｎｕｘの管理作業を行なうようにしている。
文献２には、ＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）上で動作するクラスファイル（ＣＰＵアーキテクチャ非依存の中間コード）のセキュリティを強化するＪａｖａセキュリティについての説明がある。このＪａｖａセキュリティをもつＪＶＭを導入した通信端末やコンピュータ端末では、クラスファイル実行時のセキュリティポリシが設定可能である。複数のクラスファイルをまとめた、証明書付のＪＡＲファイルをＪＶＭにロードする際にセキュリティポリシが適用され、セキュリティを確保している。
文献３に記載されている実行制御システムによれば、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を高レベルＡＰＩと低レベルＡＰＩとで構成し、信頼判断手段と安全度評価手段とを備えている。高レベルＡＰＩは自分を呼び出したアプリケーションプログラムが証明書をもっているか否かを判断し、証明書を持っていて、その証明書が正しい場合は、低レベルＡＰＩを呼び出して要求した機能を実行する。この低レベルＡＰＩを呼び出す許可に際しては、証明書内のコード作成者情報と許可する機能との対応を記したテーブルが用いられる。或いは、証明書自身に許可する機能そのものを記す場合もある。一方、証明書がない場合、或いはその証明書が正しくない場合には、要求された機能を実行する際の安全度評価を行なっている。機能を実行しても安全だと評価された場合、低レベルＡＰＩの呼び出しを行う。
文献４に記載されている実行制御システムによれば、認証モジュールに設けたＴＲＭ（Ｔａｍｐｅｒ Ｒｅｓｉｓｔａｎｔ Ｍｏｄｕｌｅ）部は、アプリケーションプログラムの認証のための情報を耐タンパ領域に保持する。この情報を用いて、端末ダウンロード部にダウンロードされたアプリケーションプログラムの認証を行い、アプリケーションプログラムの出所の確認や改竄の有無の検証を行う。認証済みのアプリケーションプログラムに対してのみ、端末のローカルリソースの利用を許可することにより、不正なアプリケーションプログラムによるローカルリソースの利用を防止できる。
文献５に記載の実行制御システムによれば、アプリケーションプログラムの起動を検知し、起動されたアプリケーションプログラムからのリソース利用要求を一時保留し、起動されたアプリケーションプログラムが正規のものであるか否かを検証する。検証の結果が正規のプログラムと判断された場合にのみ一時保留した処理要求を許可するようにしている。
文献６は、ネットワーク等を介して信頼性のないソースから入手したソフトウエアを安全に実行するための制御システムを開示している。この文献６によれば、署名入り内容から署名部分を抽出し、抽出した署名に基づいて、内容に関連した信認証明と内容を使用するためのリソース要件とを抽出する。更に、信認証明を使用して署名入り内容の信頼性と完全性を確認し、この信頼性と完全性の何れかに疑いがある場合には補正動作をするようにしている。
文献７は、通信網を介してコンテンツ提供者からソフトウエアを購入する際、購入の度にコンテンツ提供者に対して事前の手続を不要とするコンテンツ提供手法を開示している。即ち、ソフトウエア毎に「コンテンツ提供を受けるためのアクセス条件」を予め定めておき、利用者がソフトウエアの記録媒体を購入した後、コンテンツ提供を受けるためにコンテンツ提供者（コンテンツサーバ）に最初にアクセスしたとき、購入したソフトウエアに予め付与されているソフト種別と最初のアクセス時に提示した識別ＩＤとから、上述のアクセス条件に合致するかを判定し、合致している場合にのみコンテンツ提供を行うようにしている。
文献１ 「ＳＥＬｉｎｕｘ徹底ガイド」（中村雄一、水上友宏、上野修一著、日経ＢＰ社、２００４年３月、２４頁〜４１頁及び８７頁〜８９頁）
文献２ 「Ｊａｖａ２プラットフォームセキュリティ」（リー・ゴーン＝著、島田秋雄＋波多浩昭＋川上貴＝訳、株式会社ピアソン・エデュケーション、４１頁〜４８頁）（Ｊａｖａは登録商標）
文献３ 特開２００２−３５１５６３号公報
文献４ 特開２００３−２２３２３５号公報
文献５ 特開２００３−１０８２５３号公報
文献６ 特開平１０−９１４２７号公報
文献７ 特開２００２−４１３６６号公報
文献１では、アプリケーションプログラムを新たに追加する場合、追加しようとするアプリケーションプログラムに応じてセキュリティポリシデータベースを更新する必要がある。しかしながら、セキュリティ設定に過不足や漏れがないことを保証する正しいセキュリティポリシデータベースの構築は難易度が高いのが通常であり、セキュリティ設定管理を厳格に行う装置ではアプリケーションプログラムを新たに追加することが困難であり、したがって、セキュリティポリシデータベースの更新後も所定のセキュリティを保持することが非常に難しいという問題がある。
文献２は、ＣＰＵアーキテクチャ非依存のＪＶＭ上でのセキュリティ確保を目的とした技術である。ＪＶＭは通信端末やコンピュータ端末上のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上に搭載され、ＯＳから見れば１つのアプリケーションである。よって、ＪＶＭ上のセキュリティ通信端末やコンピュータ端末上で動作するすべてのプログラムのセキュリティを確保できない。例えば、ＪＶＭ上で動作するクラスファイルは、ＯＳのシステムコールなどを呼び出すネイティブメソッド呼び出し機能を備えているが、そのネイティブメソッドを呼び出すと、ＪＶＭ上のセキュリティの適用範囲外となる。また、クラスファイルは、ＪＡＲ（ＪａｖａＡｒｃｈｉｖｅ）ファイルとしてＪＶＭに配布される。このＪＡＲファイルは、複数クラスファイルを含み、それらクラスファイルの素性を証明する証明書を含んでもよい。しかし、ＪＡＲファイルを展開しもクラスファイルに証明書は添付されないので、展開されたクラスファイルの各々を他の場所に移動させると、その素性に応じたセキュリティは確保されない。
文献３によるセキュリティ強化では、高レベルＡＰＩが実行しているアプリケーションプログラムと同一空間に存在するため、信頼性判断手段及び安全度評価手段とアクセスを許可する機能との対応を記したテーブルの情報、或いは、コード作成者と許可する機能との対応を記したテーブルの情報が詐称される虞がある。
文献４による実行制御では、個々のアプリケーションプログラムについてアプリケーションプログラムが利用するリソース情報が必要であり、限られたリソース（メモリ）しか持たない携帯電話などでは、リソース確保のために端末の製造コストが上がる虞があり、或いは、製造コストを上げないようにすればリソース不足となる問題がある。
文献５による実効制御では、アプリケーションプログラムの改竄検知のためのハッシュ値を管理するモジュールが存在しているので管理が大変であり、業務アプリケーションプログラムと同一プロセス空間でフィルタモジュールが稼動するために詐称されやすいという問題がある。
文献６に記載された制御システムを、例えば、携帯電話のような機器に応用する場合、携帯電話の製造者或いは機種ごとに使用制限をしたい機能／リソースが異なることがある。携帯電話のようにメモリが限られている端末機器においては、内容ごとにリソース要件を異ならせると、内容の数が多くなるとメモリ消費に問題がでる可能性がある。
文献７に記載のアクセス制御では、コンテンツ提供を受けようとする際には必ずコンテンツサーバと通信を行う必要があり、従って、通信が不可能な場合にはコンテンツの提供を受けることができないという問題がある。
本発明の目的は、厳密にセキュリティ設定管理がなされている装置であっても、セキュリティポリシデータベースを更新することなくプログラムの追加を行うことができるプログラムの実行制御手法を提供することにある。
本発明の他の目的は、セキュリティの考慮がなされていないプログラムを実行しても安全なプログラムの実行制御手法を提供することにある。
本発明の更に他の目的は、端末内のセキュリティを確保する仕組みが容易に詐称されないプログラムの実行制御手法を提供することである。
本発明の更に他の目的は、プログラムの実行にあたり、必要最低限のリソース（メモリ）のみでセキュリティ確保が可能なプログラムの実行制御手法を提供することである。
本発明の更に他の目的は、プログラムを実行するシステム内のリソースへのアクセス許可をプログラムの製作者が決定するのではなく、携帯端末に格納してあるシステムが許可することを可能とするプログラムの実行制御手法を提供することである。

請求項１に記載の発明は、コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照し、プログラムが利用できる機能を制限するプログラムの実行制御システ
ムであって、プログラムに関連付けられたセキュリティドメインを決定する第１の手段と、決定したセキュリティドメインとセキュリティポリシデータとに基づいてセキュリティドメインで規定されている制限内でのみそのプログラムを正常に動作させる第２の手段とを有することを特徴とするプログラムの実行制御システムである。
請求項２に記載の発明は、第１及び第２の手段の一部あるいはすべてをＯＳ内の手段として有することを特徴とする請求項１に記載のプログラムの実行制御システムである。
請求項３に記載の発明は、コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照し、プログラムが利用できる機能を制限するプログラムの実行制御システムであって、プログラムに関連付けられたセキュリティドメインを決定する第１の手段と、決定したセキュリティドメインの情報をセキュリティポリシデータで規定されている複数の機能アクセス種別の何れかに関連付けてアクセス制御を設定する第２の手段とを有することを特徴とするプログラムの実行制御システムである。
請求項４に記載の発明は、前記第１及び第２の手段の一部あるいはすべてをＯＳ内の手段として有することを特徴とする請求項３に記載のプログラムの実行制御システムである。
請求項５に記載の発明は、プログラムにデジタル署名又はデジタル証明書が添付されているかどうかを検証する検証手段を更に有することを特徴とする請求項３または請求項４に記載のプログラムの実行制御システムである。
請求項６に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティドメインを取得することにより行なわれる請求項５に記載のプログラムの実行制御システムである。
請求項７に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されている証明書或いは署名を検証することにより行なわれる請求項５に記載のプログラムの実行制御システムである。
請求項８に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティポリシデータ内で使用される識別子を取得することにより行なわれる請求項５に記載のプログラムの実行制御システムである。
請求項９に記載の発明は、複数のプログラムからなるパッケージに添付されたセキュリティドメイン情報を取出す機能と、取出したセキュリティドメイン情報を前記パッケージに含まれる複数のプログラムの夫々に添付する機能を有する手段を更に有することを特徴とする請求項３に記載のプログラムの実行制御システムである。
請求項１０に記載の発明は、前記パッケージにデジタル署名又はデジタル証明書が添付されているかどうかを検証する手段を更に有することを特徴とする請求項９に記載のプログラムの実行制御システムである。
請求項１１に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティドメインを取得することにより行なわれる請求項１０に記載のプログラムの実行制御システムである。
請求項１２に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されている証明書或いは署名を検証することにより行なわれる請求項１０に記載のプログラムの実行制御システムである。
請求項１３に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティポリシデータ内で使用される識別子を取得することにより行なわれる請求項１０に記載のプログラムの実行制御システムである。
請求項１４に記載の発明は、コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照し、プログラムが利用できる機能を制限するプログラムの実行制御方法であって、プログラムに関連付けられたセキュリティドメインを決定する第１の工程と、決定したセキュリティドメインとセキュリティポリシデータとに基づいてセキュリティドメインで規定されている制限内でのみそのプログラムを正常に動作させる第２の工程とを有することを特徴とするプログラムの実行制御方法である。
請求項１５に記載の発明は、前記第１及び第２の工程の一部あるいはすべてをＯＳ内で実施される工程として有することを特徴とする請求項１４に記載のプログラムの実行制御システムである。
請求項１６に記載の発明は、コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照し、プログラムが利用できる機能を制限するプログラムの実行制御方法であって、プログラムに関連付けられたセキュリティドメインを決定する第１の工程と、決定したセキュリティドメインの情報をセキュリティポリシデータで規定されている複数の機能アクセス種別の何れかに関連付ける第２の工程とを有することを特徴とするプログラムの実行制御方法である。
請求項１７に記載の発明は、前記第１及び第２の工程の一部あるいはすべてをＯＳ内で実施される工程として有することを特徴とする請求項１６に記載のプログラムの実行制御システムである。
請求項１８に記載の発明は、プログラムにデジタル署名又はデジタル証明書が添付されているかどうかを検証する工程を更に有することを特徴とする請求項１６または請求項１７に記載のプログラムの実行制御方法である。
請求項１９に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティドメインを取得することにより行なわれる請求項１８に記載のプログラムの実行制御方法である。
請求項２０に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されている証明書或いは署名を検証することにより行なわれる請求項１８に記載のプログラムの実行制御方法である。
請求項２１に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティポリシデータ内で使用される識別子を取得することにより行なわれる請求項１８に記載のプログラムの実行制御方法である。
請求項２２に記載の発明は、複数のプログラムからなるパッケージに添付されたセキュリティドメイン情報を取出す工程と、取出したセキュリティドメイン情報を前記パッケージに含まれる複数のプログラムの夫々に添付する工程とを更に有することを特徴とする請求項１６に記載のプログラムの実行制御方法である。
請求項２３に記載の発明は、前記パッケージにデジタル署名又はデジタル証明書が添付されているかどうかを検証する工程を更に有することを特徴とする請求項２２に記載のプログラムの実行制御方法。
請求項２４に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティドメインを取得することにより行なわれる請求項２３に記載のプログラムの実行制御方法である。
請求項２５に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されている証明書或いは署名を検証することにより行なわれる請求項２３に記載のプログラムの実行制御方法である。
請求項２６に記載の発明は、セキュリティドメインの決定は、プログラムに予め付加されているセキュリティポリシデータ内で使用される識別子を取得することにより行なわれる請求項２３に記載のプログラムの実行制御方法である。
請求項２７に記載の発明は、請求項１４乃至２６のいずれかに記載のプログラムの実行制御方法を実現するためのコンピュータプログラムである。
請求項２８に記載の発明は、請求項１乃至１３のいずれかに記載の実行制御システム上で動作するプログラムに対してその実行制御システム上でセキュリティドメインを決定する際に必要な情報を添付する手段を有することを特徴とするプログラム配信サーバである。
請求項２９に記載の発明は、請求項９乃至１３のいずれかに記載の実行制御システム上で動作するプログラムを複数含むパッケージに対し、その実行制御システム上でセキュリティドメインを決定する際に必要な情報を添付する手段を有することを特徴とするプログラム配信サーバである。
請求項３０に記載の発明は、請求項１４乃至２１のいずれかに記載の実行制御方法により動作するプログラムに対し、その実行制御方法によってセキュリティドメインを決定する際に必要な情報を添付する工程を有することを特徴とするプログラム配信方法である。
請求項３１に記載の発明は、請求項２２乃至２６のいずれかに記載の実行制御方法により動作するプログラムを複数含むパッケージに対し、その実行制御方法によってセキュリティドメインを決定する際に必要な情報を添付する工程を有することを特徴とするプログラム配信方法である。
請求項３２に記載の発明は、請求項３０または３２に記載のプログラム配信方法を実現するためのコンピュータプログラムである。
第１に、プログラムを情報通信端末に追加する際に、端末内に予め用意されているセキュリティポリシデータベースを更新する必要がないため、セキュリティポリデータベースの複雑な再構築の作業が不要となる効果がある。その理由は、追加しようとするプログラムに添付されているセキュリティドメイン情報に基づいてセキュリティポリシデータベース内のアクセス制御ルールを決定し、そのルールをプログラムに関連付けるためである。
第２に、セキュリティが考慮されていないプログラムを実行したとしても、情報通信端末内で不正な動作やアクセスなどを排除できるという効果がある。その理由は、プログラムを実行する際にその実行可能ファイルにセキュリティドメイン情報を添付するためである。その結果、プログラムを実行する場合、そのセキュリティドメイン情報により得られるプログラムの素性に基づいて端末内部の複数の機能毎にアクセスを制御できる。また、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）レベルで「機能アクセスの制御手段」を実現しているので、ＯＳ自体に備わっている既存のシステムコールインタフェースによりプログラムを動作させることができる。従って、プログラム自体に改造を加える必要がないという効果もある。さらに、本発明をＯＳ上で実施するようにすれば、ＯＳレベルでセキュリティを確保するので、そのＯＳを搭載した機器上のすべてのプログラムに対してセキュリティを確保できるという効果もある。
第３に、プログラム実行時のアドレス空間（プロセス）外でセキュリティを確保しているので、容易に詐称されないという効果がある。その理由は、セキュリティ確保を目的とした「機能アクセスの制御手段」を、上述のように、ＯＳレベルで実現しているためである。
第４に、プログラムを実行するにあたり、必要最低限のリソースのみで安全に実行できる効果がある。その理由は、プログラム毎に異なるアクセス制御などを行なうのではなく、セキュリティドメイン情報ごとの制御情報を予め端末内に保持しておき、プログラムにはセキュリティドメイン情報のみ添付し、そのプログラムを通信端末上で実行する際には、そのセキュリティドメイン情報に対応する制御情報を適用してアクセス制御などを実現しているためである。このため、端末内の制御情報は、セキュリティドメイン情報の数だけ予め用意しておくだけでよい。
第５に、通信端末内のセキュリティを確保するにあたり、いかなるプログラムについても、端末自身がそのプログラムの素性により適切なアクセス制御を実施することができるという効果がある。その理由は、プログラムの製作者が、そのプログラムが使用しようとするリソース情報をプログラムに添付するのではなく、所属するセキュリティドメイン情報をプログラムに添付し、そのプログラムを端末上で実行する際には、そのセキュリティドメイン情報に対応する制御情報を適用してアクセス制御を実現しているためである。さらに、そのセキュリティドメイン情報は、改竄されてないことを保証するためデジタル署名またはデジタル証明書を使用している。

図１は、第１の実施の形態を説明するためのブロック図
図２は、第１の実施の形態を説明するためのプログラム配信サーバのブロック図
図３は、第１の実施の形態で使用されるセキュリティポリシデータベースの内容例を示す図
図４は、第１の実施の形態で使用されるアプリケーションプログラムなどのファイル構造を簡単に示す図
図５は、第１の実施の形態で使用されるセキュリティドメイン種別とセキュリティＩＤとの関係を示す図
図６は、第１の実施の形態の動作を説明するためのフローチャート
図７は、第２の実施の形態を説明するためのブロック図
図８は、第２の実施の形態を説明するためのプログラム配信サーバのブロック図
図９は、第２の実施の形態の動作を説明するためのフローチャート
図１０は、第３の実施の形態を説明するためのブロック図
図１１は、第４の実施の形態を説明するためのブロック図
図１２は、第４の実施の形態の動作を説明するためのフローチャート
図１３は、第５の実施の形態を説明するためのブロック図
図１４は、第６の実施の形態を説明するためのプログラム配信サーバのブロック図
図１５は、第６の実施の形態を説明するためのブロック図
図１６は、第７の実施の形態を説明するためのブロック図
図１７は、本発明に係る実施例を説明するためのセキュリティポリシデータベースの内容例を示す図
１０：携帯端末、１２：プログラム配信サーバ、１０１、２０１：ＣＰＵ、１０２、２０２：ＲＡＭ、１０３、２０３：ＲＯＭ、１０４、２０４：ＨＤＤ、１０５、２０５：外部メモリ、１０６、２０６：出力装置、１０７、２０７：入力装置、１０８、２０８：通信装置、１０９：アプリケーション取得手段、１１０：ユーザデータ、１１１：ライブラリ、１１２：アプリケーションプログラム、１１３：デバイスドライバ、１１４：ＯＳ処理手段、１１５：実行制御処理手段、１１６：ドメイン情報取出／添付手段、１１６ｂ：ドメイン情報取出／ＩＤ添付手段、１１７：署名検証／添付手段、１１５１：制御手段、１１８、１１５２：セキュリティドメイン情報取得手段、１１５２ｂ：セキュリティＩＤ取得手段、１１５３：検証手段、１１９、１１５４：アクセス制御設定手段、１１５５：アクセス制御手段、１１５６：セキュリティポリシデータベース、２０９：ドメイン埋め込み手段、２１０：証明書あるいは署名添付手段、２１１：パッケージ作成手段、２１２：ドメイン情報セキュリティＩＤ変換手段

本明細書で説明する実施の形態では、移動体通信などに使用される携帯端末を例に挙げて説明する。しかし、本発明は、携帯端末への応用に限定されるものではなく、アプリケーションプログラムなどを外部から取り込んで使用する種々の情報関連機器に応用可能である。
本発明に係る第１の実施の形態を図１〜図６を参照して説明する。
第１の実施の形態は、図１に示すように、大きく分けて、携帯端末１０とプログラム配信サーバ１２とから構成され、これらは有線或いは無線ネットワークを介して接続している。
携帯端末１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０３、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４、外部メモリ１０５、出力装置１０６、入力装置１０７、通信装置１０８、プログラム取得手段１０９、ユーザデータ１１０、ライブラリ１１１、アプリケーションプログラム１１２、デバイスドライバ１１３、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）処理手段１１４、実行制御処理手段１１５などを備えている。
実行制御処理手段１１５は、制御手段１１５１、セキュリティドメイン情報取得手段１１５２、検証手段１１５３、アクセス制御設定手段１１５４、アクセス制御手段１１５５、セキュリティポリシデータベース１１５６等から構成されている。
図１に示すように、携帯端末１０のユーザ空間では、プログラム取得手段１０９、ユーザデータ１１０、ライブラリ１１１、アプリケーションプログラム１１２が動作し、一方、携帯端末１０のカーネル空間では、ＯＳ処理手段１１４、デバイスドライバ１１３、実行制御処理手段１１５が動作する。
ユーザデータ１１０、ライブラリ１１１、アプリケーションプログラム１１２は、実際には、夫々、携帯端末１０に取り込まれたユーザデータ、ライブラリ、アプリケーションプログラムを指すが、本明細書では説明を簡単にするため、携帯端末１０に取り込まれる前のユーザデータ、ライブラリ、アプリケーションプログラムについても、夫々、参照番号１１０、１１１、１１２を付す場合がある。
また、アプリケーションプログラム１１２は、ＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）上で動作する中間コードではなく、ＣＰＵ１０１が直接解釈可能な実行コードを含んでいる。
上述の手段及び装置の動作について説明する。
ＣＰＵ１０１は、携帯端末１０内の手段及び装置の制御、プログラムの実行の制御、演算処理などに使用される。ＲＡＭ１０２は、携帯端末１０内の手段及び装置を制御するプログラムの実行時に一時的に使用される記憶領域である。なお、ＲＡＭ１０２は実行コードそのものを一時的に記憶する場合もある。ＲＯＭ１０３は、読出しのみが可能な記憶装置であり、上述の手段及び装置を制御するプログラムの実行コード及びデータなどを記憶し、記憶されている実行コードおよびデータは携帯端末１０の電源ＯＦＦによっても消滅しない。
ＨＤＤ１０４は、ＲＡＭ１０２に比べて読書きの速度は遅いが、記憶容量が大きいという特徴があり、携帯端末１０の電源をＯＦＦにしても記憶されている実行コードおよびデータは消滅しない。外部メモリ１０５は、携帯端末１０に着脱可能な読書き可能な記憶装置であり、アプリケーションプログラム１１２、ライブラリ１１１、ユーザデータ１１０、およびデバイスドライバ１１３などの実行コードやデータ等を記憶させることができ、携帯端末１０に装着することにより、携帯端末１０に、プログラム、実行コード、データなどを追加することができる。
出力装置１０６は、携帯端末１０が処理した結果をディスプレイに表示したり、音声で出力する装置である。入力装置１０７は、例えば、キー（ボタン）を備え、携帯端末１０に新たな処理の実行を指示するために使用される。
通信装置１０８は、携帯端末１０の外部と通信し、アプリケーションプログラム１１２、ライブラリ１１１、ユーザデータ１１０、デバイスドライバ１１３などのデータや実行コードを携帯端末１０に取り込む際に使用される。即ち、プログラム取得手段１０９は、通信装置１０８を介して、プログラム配信サーバ１２からアプリケーションプログラム等を携帯端末１０内に取得する。尚、上述したように、着脱可能な外部メモリ１０５からもアプリケーションプログラム等を取得可能である。
ＯＳ処理手段１１４は、ＯＳ（例えばＨＤＤ１０４に格納されている）を用いて処理を行う手段であり、アプリケーションプログラム１１２が呼び出すシステムコールの処理を行うと共に、このシステムコール処理中に制御手段１１５１を呼び出す。
制御手段１１５１は、実行制御処理手段１１５の他の構成手段１１５２〜１１５５を制御してアプリケーションプログラム１１２の実行制御を行う。尚、アプリケーションプログラム１１２と同様に、ライブラリ１１１の実行制御も行なう場合もあるが、説明を簡単にするため、アプリケーションプログラム１１２の実行制御を中心にして説明する。
セキュリティドメイン情報取得手段１１５２は、アプリケーションプログラム１１２に関連付けられたセキュリティドメイン情報を取得し、検証手段１１５３は、アプリケーションプログラム１１２に添付されたデジタル署名（又はデジタル証明書）の検証処理を行う。アクセス制御設定手段１１５４は、セキュリティドメイン情報取得手段１１５２が取得したセキュリティドメイン情報に基づいて「取得したアプリケーションプログラム」に適応されるセキュリティポリシを決定し、決定したセキュリティポリシをアプリケーションプログラム１１２に設定する。アクセス制御手段１１５５は、アプリケーションプログラム１１２が携帯端末１０の機能にアクセスする際のアクセス制限を行うものであり、アクセス制御についてのセキュリティポリシは、セキュリティポリシデータベース１１５６に保持されている。尚、図１に示したＨＤＤ１０４は必須の装置ではなく、更に、図１では表示装置、電源等の本発明の実施に直接関係のない装置の図示を省略している。
図２にプログラム配信サーバ１２の構成の一例を示す。プログラム配信サーバ１２は、少なくとも、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、外部メモリ２０５、出力装置２０６、入力装置２０７、通信装置２０８、ドメイン埋込手段２０９、証明書或いは署名添付手段２１０から構成されている。図２の装置或いは手段２０１〜２０８の機能は、図１の携帯端末１０の１０１〜１０８と同じなので説明を省略する。
ドメイン埋込手段２０９は、ＨＤＤ２０４などに格納されている送信予定のアプリケーションプログラムにセキュリティドメイン情報を埋め込む機能を有する。一方、証明書或いは署名添付手段２１０は、セキュリティドメイン情報が埋め込まれたアプリケーションプログラムについて、携帯端末１０上での改竄チェックを容易にするためにハッシュ関数などを用いてハッシュ値を求めてその値を含んだ署名或いは証明書を添付する。
次に、第１の実施の形態の動作を、図１〜図６を参照して詳細に説明する。
まず、プログラム配信サーバ１２が携帯端末１０に配布するアプリケーションプログラムを準備するまでの動作を説明する。アプリケーションプログラムを通信装置２０８或いは外部メモリ２０５からプログラム配信サーバ１２の内部に入力し、例えばＨＤＤ２０４等に格納する。このとき、アプリケーションプログラムが所属するセキュリティドメイン情報も入力する。ドメイン埋込手段２０９は、入力されたアプリケーションプログラムにドメイン情報を添付し、次いで、証明書或いは署名添付手段２１０がセキュリティドメイン情報が埋め込まれたアプリケーションプログラムのハッシュ値を求め、その値を含んだ署名或いは証明書を添付する。その後、アプリケーションプログラムは、通信装置２０８を介して携帯端末１０に送信されるか、或いは、脱着可能な外部メモリ２０５に格納される。
尚、アプリケーションプログラムファイルにドメインを埋め込む機能はプログラム配信サーバ１２ではなく他のサーバで実現し、ドメインを埋め込んだファイルをプログラム配信サーバ１２に置くようにしてもよい。つまり、プログラム配信サーバ１２で上述のすべての処理を行うのでなく、いくつかのサーバで処理を分担するようにしてもよい。
図３は、図１のセキュリティポリシデータベース１１５６の構成例を簡単に示す図である。
携帯端末１０に格納されているアプリケーションプログラム１１２は、図３に示す複数のセキュリティＩＤのいずれかに関連付けられ、そのセキュリティＩＤで一意に識別されるアクセス制御ルール（セキュリティコンテキスト）により許可された機能（例えばＡ〜Ｅの全部又は一部）にアクセス可能である。ここでいう機能とは、後述する本実施の形態のように本発明が携帯端末に応用される場合には、図１７に示すように、「電話をかける」、「通話料金制御」、「サウンド機能」、「通信する」、「画面を使う」等の機能を指す。
図３を参照すると、例えば、アプリケーションプログラム１１２がセキュリティＩＤの３に関連付けられた場合、そのアプリケーションプログラム１１２は、機能Ｃと機能Ｅのみにアクセス可能であり、機能Ａ、機能Ｂ、機能Ｄについてはアクセス禁止であることを示している。
図４は、図１のアプリケーションプログラム１１２、ライブラリ１１１、およびデバイスドライバ１１３夫々のファイルのデータ構成例を簡単に示した図であり、図示の例では、実行コード、セキュリティドメイン情報、デジタル署名から成る。
図４に示すファイルのデータ構成例がアプリケーションプログラム１１２のものとすると、図４に示すように、このアプリケーションプログラム１１２は、実行コード、セキュリティドメイン情報、デジタル署名で構成されていてもよいし、実行コード及びセキュリティドメイン情報のみで構成されていてもよいし、或いは、実行コードだけであってもよい。ライブラリ１１１及びデバイスドライバ１１３の夫々についても同様である。
実行コードは、ＣＰＵ１０１によって実行される命令コードであり、セキュリティドメイン情報は、アプリケーションプログラムの所属するセキュリティドメイン情報である。デジタル署名は、実行コードとセュリティドメイン情報とをデジタル署名したものであり、このデジタル署名は暗号化されていてもよい。このデジタル署名を添付することで、ネットワークを介した配信途上でのアプリケーションプログラム等のファイル改竄を検出することが可能である。デジタル署名自体は公知であり、アプリケーションプログラム配布者が、例えば、ＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）等のハッシュ関数を用いてハッシュ値を生成して署名データを作成する手法が広く使われている。
なお、ファイル内での実行コード、セキュリティドメイン情報、デジタル署名の配列順番は図４に限定されないことは勿論であり、要は、これらの実行コード、セキュリティドメイン情報およびデジタル署名が取り込んだアプリケーションプログラム等に含まれていればよい。なお、デジタル署名の代わりにデジタル証明書が添付されていても良く、この場合、このデジタル証明書の中にセキュリティドメイン情報が含まれていても良い。デジタル証明書の形式としては、例えばＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）Ｘ．５０９で規定された形式が広く利用されている。デジタル証明書によってそこに記載されたセキュリティドメイン情報は信頼できる公的認証機関によって保証されていることになる。
アプリケーションプログラム１１２が、図４に示すように、デジタル署名を含む場合には、このデジタル署名が正しく検証されれば、配布者、実行コード、実行コードが所属するセキュリティドメイン情報は正しく承認されているとしてよいので、携帯端末１０（図
１）上で安全に実行可能である。デジタル署名の代わりにデジタル証明書が添付されている場合も同様である。しかしながら、図１に示す携帯端末１０では、実行コードのみの場合（図４においてセキュリティドメイン情報及びデジタル署名を含まない場合）のように信頼できない（信頼性に疑問のある）アプリケーションプログラムであっても実行させることは可能である。
図５は、アプリケーションプログラム１１２に含まれるセキュリティドメイン情報の種別と、セキュリティポリシデータベース１１５６内のアクセス制御ルールを決めるセキュリティＩＤ（図３参照）との関連を示す図である。図４に示すデータは、図１のアクセス制御設定手段１１５４に保持されている。なお、図５に示す例では、アプリケーションプログラムがセキュリティドメイン情報を含まないで実行コードのみを有する場合には、セキュリティドメイン情報種別は「信頼できないベンダ」に分類されてセキュリティＩＤは４となる。
以下、本実施の形態の動作を、アプリケーションプログラムを例にとって、図６のフローチャートを用いて説明する。
図６のフローチャートで説明する動作の前提として、信頼できるアプリケーションプログラムの作成者又は配布者は、送信しようとするアプリケーションプログラムにセキュリティドメイン情報とデジタル署名（或いはデジタル証明書）を添付し、そのアプリケーションプログラムをプログラム配信サーバ１２（図１及び図２）に置くものとする。或いは、上述の作成者又は配布者は、アプリケーションプログラムをプログラム配信サーバ１２に置く代わりに、そのアプリケーションプログラムを外部メモリ１０５（例えばＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カードなど）に記録してもよい。
ステップＳ６００において、携帯端末１０は、プログラム配信サーバ１２に置かれたアプリケーションプログラムを、アプリケーション取得手段１０９により携帯端末１０内部に取り込む（或いは、外部メモリ１０５を携帯端末１０に装着して記録されているアプリケーションプログラムを携帯端末１０に取り込む場合もある）。
上述の場合は、携帯端末１０に配信されるアプリケーションプログラムは、セキュリティドメイン情報及びデジタル署名を含んでいるが、これに限らず、セキュリティドメイン情報及びデジタル署名を含まない「信頼できないアプリケーションプログラム」も上述と同様に携帯端末１０に取り込まれる場合もある。
なお、ライブラリおよびデバイスドライバについても、上述のアプリケーションプログラムの場合と同様に携帯端末１０に取り込まれる（図１では取り込まれたライブラリおよびデバイスドライバを夫々１１１及び１１３で示している）。
携帯端末１０が取り込んだアプリケーションプログラム（図１において１１２で示す）を起動する場合、ＯＳ処理手段１１４に起動を依頼する（ステップＳ６０２）。
続いて、ステップＳ６０４において、取り込んだアプリケーションプログラム１１２からセキュリティドメイン情報が取り出せたかどうかの判断を行う。セキュリティドメイン情報を取り出すためには、ＯＳ処理手段１１４がアプリケーションプログラム１１２の起動を処理する途中で制御手段１１５１を呼び出し、この制御処理手段１１５１によりドメイン情報取得手段１１５２が呼び出される。ドメイン情報取得手段１１５２は、アプリケーションプログラム１１２を構成するファイル（図４参照）を解析し、アプリケーションプログラム１１２にセキュリティドメイン情報が存在すればそれを取り出す。
セキュリティドメイン情報が取り出せない場合にはステップＳ６０６に進み、このステップにおいて、そのアプリケーションプログラム１１２は信頼できないと判断し、アクセス制御設定手段１１５４を呼び出す。この場合、アクセス制御設定手段１１５４は、セキュリティドメイン種別を「信頼できないベンダ」と判断してセキュリティＩＤを４とし、ステップＳ６０８に進む。一方、ステップＳ６０４において、セキュリティドメイン情報が取り出せた場合には直接ステップＳ６０８に行く。
ステップＳ６０８において、検証手段１１５３はアプリケーションプログラム１１２からデジタル署名（又はデジタル証明書）を取り出し、デジタル署名（又はデジタル証明書）が正しいものであるかどうかを検証する。なお、デジタル署名（又はデジタル証明書）が存在しない場合にはステップＳ６１０に進む。
デジタル署名が添付されていた場合は、署名された秘密鍵と対をなす公開鍵（予め携帯端末１０の内部に格納されている）により署名検証を行う。また、このデジタル署名が暗号化されていれば復号を行った後に署名検証を行う。署名時に使用された秘密鍵がセキュリティドメイン情報ごとに異なる場合は、署名検証に使用する公開鍵もセキュリティドメイン情報ごとに異なることになる。一方、デジタル署名の代わりにデジタル証明書が添付されていた場合はデジタル証明書の検証を行う。検証の結果、デジタル署名（又はデジタル証明書）が正しいものであればステップＳ６１０に進む。
ステップＳ６０８において、デジタル署名（又はデジタル証明書）が正しくないと判断された場合には、取り込んだアプリケーションプログラム１１２は改竄されている可能性があるので、アプリケーション１１２の起動処理を中止する（ステップＳ６０９）。
ステップＳ６１０において、セキュリティＩＤが未だ決定されていないと判断された場合にはステップＳ６１２に進み、セキュリティＩＤが既に決定されていれば（即ちステップＳ６０６での処理が行なわれていれば）ステップＳ６１４に進む。ステップＳ６１２では、アクセス制御設定手段１１５４を呼び出してアクセス制御設定を行う。この場合、セキュリティドメイン情報があるので、そのセキュリティドメイン情報からセキュリティドメイン情報種別を判断し、図５に示した表を参照して、そのセキュリティドメイン情報種別に対応するセキュリティＩＤを決定する。
ステップＳ６１４において、アプリケーションプログラムのプロセスとセキュリティＩＤとを関連付ける。即ち、アプリケーションプログラム１１２は、携帯端末１０上ではプロセスとして動作し、そのプロセスに対して決定したセキュリティＩＤを関連付ける。例えば、プロセスを管理するプロセス管理データがＯＳ内に存在していれば、このプロセス管理データにセキュリティＩＤを格納することで関連付けを行うことができる。
実現方法としてはプロセス管理データにセキュリティＩＤを直接設定してもよいし、アプリケーションプログラム１１２の実行コードがプロセスにマッピングされる前であれば、アプリケーションプログラム１１２に関するアクセス制御手段１１５５が管理するセキュリティ情報に、実行コードがマッピングされた際に、そのプロセスの管理データに該当するセキュリティＩＤを格納するようにアプリケーション１１２に関するセキュリティ情報を書き換えておいてもよい。この場合、セキュリティ情報には、該当するセキュリティＩＤそのものではなく、該当するセキュリティＩＤを導くための仮ＩＤが設定されてもよい。
即ち、図５で示されるテーブルのセキュリティＩＤの部分が仮ＩＤとなり、仮ＩＤとセキュリティＩＤとの関連付けを示すテーブルを、セキュリティポリシデータベース１１５６に設定しておく。アプリケーションプログラム１１２のプロセスが生成されると、仮ＩＤから該当するセキュリティＩＤが決定され、そのセキュリティＩＤをプロセスの管理デ
ータに格納する。なお、仮ＩＤからセキュリティＩＤを決定するための情報は、必要であればセキュリティポリシデータベース１１５６にあらかじめ設定しておく。ＳＥＬｉｎｕｘを代表としたよく知られたアクセス制御を可能とするアクセス制御手段１１５５は、プロセス起動時、実行コードがプロセスにマッピングされる際にセキュリティＩＤをプロセスの管理データに設定しており、既存技術として存在している。
或いは、制御手段１１５１にプロセスＩＤとセキュリティＩＤを関連付けるデータを作成して保存しておいてもよい。更に、アプリケーションプログラム１１２であるファイルを一意に識別可能なファイルＩＤ、或いはファイルパスとセキュリティＩＤを関連付けるデータを作成して保存しておいてもよい。
アプリケーションプログラム１１２に基づいて携帯端末１０で生成されるプロセスとセキュリティＩＤとを関連付けることでアクセス制御設定処理は完了する。その後、アプリケーションプログラム１１２の起動が続行されて携帯端末上でプロセスとして実行される（ステップＳ６１６）。
図６は、アプリケーションプログラム１１２にセキュリティドメイン情報がデジタル署名（又はデジタル証明書）とは別に添付されていた場合の動作を説明するフローチャートである。もし、デジタル署名の代わりにデジタル証明書が添付されており、セキュリティドメイン情報がデジタル証明書の中に含まれている場合は、ステップＳ６０４でのセキュリティドメイン情報取得についての判断を、ステップＳ６０８のデジタル証明書の検証の後に行うようにすればよい。
アプリケーションプログラム１１２から生成されたプロセスは、実行コードに従った処理を行う。実行コードによる携帯端末１０内の各種資源へのアクセスはＯＳを介して行われる。つまり、図１に即して言えば、実行コードは、ＯＳ処理手段１１４を経由して各種資源にアクセスする。この際、ＯＳ処理手段１１４は、制御手段１１５１を呼び出し、更に、アクセス制御手段１１５５を呼び出す。これらの呼び出しの際にプロセスＩＤ或いはプロセスの実行コードを示すアプリケーションプログラムであるファイルのＩＤとセキュリティＩＤを関連付けたデータ（テーブル）が存在すれば、制御手段１１５１は、呼び出したプロセスのプロセスＩＤとそれに関連付けられたセキュリティＩＤとを獲得し、アクセス制御手段１１５５を呼び出す。
或いは、上述したように、プロセス管理データにセキュリティＩＤが存在すれば、アクセス制御手段１１５５は、そのプロセス自身のプロセス管理データからそのセキュリティＩＤを獲得する。プロセスに関するセキュリティＩＤが判明すると、アクセス制御手段１１５５は、セキュリティポリシデータベース１１５６を参照し、そのプロセスがアクセスしようとしている機能について、アクセス制御ルールがアクセスを許可しているか或いは禁止しているかを判断する。アクセス制御手段１１５５は、アクセスが許可されていれば許可を示すデータを、制御手段１１５１を経由してＯＳ処理手段１１４に渡し、そのプロセスはアクセスしようとしていた機能にアクセスする。一方、アクセスが禁止されていれば、アクセス制御手段１１５５は、禁止を示すデータを、制御手段１１５１を経由してＯＳ処理手段１１４に渡し、ＯＳ処理手段１１４は、そのプロセスに対してエラーを戻す。
図３に示したセキュリティデータベースを用いて具体例を挙げれば、アプリケーションプログラム１１２の或るプロセスのセキュリティＩＤが３と判断されれば、そのプロセスは機能Ａ，Ｂ，及びＤに対してアクセス禁止となる。
上述した第１の実施の形態の効果について説明する。
本実施の形態によれば、携帯端末１０に取り込んだアプリケーションプログラム１１２
に添付されているセキュリティドメイン情報から、アプリケーションプログラム１１２が携帯端末１０の複数の機能夫々について利用可能かどうかを決定するセキュリティＩＤを求めることができる。即ち、アプリケーションプログラム１１２から取り出したセキュリティドメイン情報に基づいてセキュリティポリシデータベース１１５６を参照し、このデータベースに予め格納してあるセキュリティＩＤ（アクセス制御ルール）を一意に求めることができる。セキュリティポリシデータベース１１５６は参照されるだけなので、セキュリティポリシデータベース１１５６を更新することなくアプリケーションプログラム１１２を追加し且つ実行することができる。従って、長時間を要する複雑なセキュリティポリシデータベースの再構築作業を行わずに済むという効果があり、更に、データデータの更新が不要なので、データ更新による誤ったセキュリティポリシデータの混入という危険を避けることができる。
更に、本実施の形態によれば、携帯端末１０は外部からアプリケーションプログラム１１２を安全に取り込むことができる。その理由は、セキュリティドメイン情報およびデジタル署名またはデジタル証明書がアプリケーションプログラム１１２となるファイルごとに添付されており、かつ、そのファイルをアプリケーションとして起動する際にセキュリティドメイン情報およびデジタル署名またはデジタル証明書による改竄チェックが実施されるからである。
したがって、携帯端末１０上のアプリケーションプログラム１１２が外部の想定外のサーバと通信して、悪意あるアプリケーションプログラムを受信し、携帯端末１０上に格納したとしても、アプリケーション起動時にＯＳレベルでデジタル署名あるいはデジタル証明書の検証を実施するので安全は確保される。
更にまた、本実施の形態によれば、アプリケーションプログラム１１２が携帯端末１０に取得された後に、アプリケーションプログラム１１２が携帯端末上で第三者によって改竄された場合もその改竄を検知することができる。その理由は、セキュリティドメイン情報およびデジタル署名（またはデジタル証明書）がアプリケーションプログラム１１２となるファイルごとに添付されており、且つ、そのファイルがアプリケーションとして起動する毎にセキュリティドメイン情報およびデジタル署名（またはデジタル証明書）を用いて改竄チェックが実施されるからである。
更にまた、本実施の形態によれば、あるアプリケーションプログラム１１２から別のアプリケーションプログラムを、セキュリティを意識することなく安全に起動させることができる。その理由は、ドメイン情報取得手段、検証手段、アクセス制御設定手段、アクセス制御手段がＯＳ機能の一部として存在し、アプリケーション起動時に必ず呼び出されるＯＳ処理手段（システムコール）からそれらすべての手段が呼び出され、起動されるアプリケーションプログラムの配布者に応じた実行環境を作成するからである。
次に本発明に係る第２の実施の形態を図７〜図９を参照して説明する。
図７及び図８に第２の実施の形態の構成例を示す。図７に示した構成例は、図１に示した第１の実施の形態の構成例にドメイン情報取出／添付手段１１６と署名検証／添付手段１１７とを追加したものであり、その他の部分は図１の構成と同様である。第２の実施の形態では、第１の実施の形態と異なり、複数のアプリケーションプログラムから成るアプリケーションパッケージを外部から取り込んでいる。
ドメイン情報取出／添付手段１１６は、アプリケーションパッケージからセキュリティドメイン情報を取り出す機能の他に、アプリケーションパッケージを複数のアプリケーションプログラムに展開して夫々にセキュリティドメイン情報を添付する機能を有する。
アプリケーションパッケージにはアプリケーションパッケージ毎にセキュリティドメイン情報とデジタル署名（又はデジタル証明書）とが添付されているが、アプリケーションパッケージに含まれる複数のアプリケーションプログラムの夫々には、セキュリティドメイン情報及びデジタル署名（又はデジタル証明書）の両方或いは一方が添付されていない場合がある。このアプリケーションパッケージには、アプリケーションプログラムの他にユーザデータ及び／又はライブラリ、ドライバが含まれていてもよい。ライブラリとドライバには、アプリケーションプログラムの場合と同様にセキュリティドメイン情報とデジタル署名（又はデジタル証明書）が添付されてもよい。
署名検証／添付手段１１７は、アプリケーションパッケージに添付されているデジタル署名或いはデジタル証明書を検証する機能の他に、パッケージを展開して取り出したアプリケーションプログラムの夫々にデジタル署名を添付する（埋め込む）機能を持つ。
アプリケーションパッケージは、アプリケーションプログラムの作成者又は配布者によりプログラム配信サーバ１２に置かれ、携帯端末１０のアプリケーションプログラム取得手段１０９により取り込まれる（ダウンロードされる）。或いは、第１の実施の形態で説明したように、アプリケーションパッケージを記憶させた外部メモリ１０５（例えばＳＤカードなど）を携帯端末１０に装着し、アプリケーションプログラム取得手段１０９により携帯端末１０に取り込むことも可能である。
図７に示したプログラム配信サーバ１２の機能の構成の一例を図８に示す。
図８を第１の実施の形態で説明した図２と比較すると、図８には、パッケージ作成手段２１１が追加されている。このパッケージ作成手段２１１は、複数のアプリケーションプログラムを１つのパッケージとしてまとめる機能を有する。ドメイン埋込手段２０９は、第１の実施の形態と異なり、アプリケーションパッケージにセキュリティドメイン情報を添付する機能を有する。しかし、ドメイン埋込手段２０９は、この機能のほかに、アプリケーションパッケージを構成するアプリケーションプログラムの夫々にもセキュリティドメイン情報を添付する機能を有するようにしてもよい。一方、証明書或いは署名添付手段２１０は、アプリケーションパッケージにデジタル署名（又はデジタル証明書）を添付する機能を有する。しかし、上述の場合と同じように、この証明書或いは署名添付手段２１０は、アプリケーションパッケージを構成するアプリケーションプログラムの夫々にもデジタル署名（又はデジタル証明書）を添付する機能を有するようにしてもよい。
プログラム配信サーバ１２に、複数のアプリケーションプログラム含むアプリケーションパッケージとセキュリティドメイン情報が入力された場合にはパッケージ作成手段２１１は使用されず、ドメイン埋込手段２０９および証明書或いは署名添付手段２１０が、セキュリティドメイン情報およびデジタル署名（又はデジタル証明書）を添付したアプリケーションパッケージを作成する。
プログラム配信サーバ１２に、複数のアプリケーションプログラムとセキュリティドメイン情報が入力された場合、必要であればドメイン埋込手段２０９でアプリケーションプログラムにセキュリティドメイン情報を埋め込み、必要であればそのアプリケーションプログラムに証明書あるいは署名添付手段２１０によりデジタル署名（又はデジタル証明書）を添付する。
なお、アプリケーションプログラムには必ずしもセキュリティドメイン情報、デジタル署名（又はデジタル証明書）を添付されなくてもよく、その場合は、アプリケーションプログラムに関して、プログラム配信サーバ１２では何も処理しない。次に複数のアプリケーションプログラムを含むアプリケーションパッケージをパッケージ作成手段２１１で作成する。そのアプリケーションパッケージにもセキュリティドメイン情報をドメイン埋め込み手段２０９で添付する。そして、証明書あるいは署名添付手段２１０によりデジタル署名（又はデジタル証明書）を添付する。もし、デジタル証明書内にセキュリティドメイ
ン情報も含む場合は、ドメイン埋め込み手段２０９がアプリケーションパッケージにセキュリティドメイン情報を添付する必要はない。
なお、上述したドメインを埋め込む機能、証明書あるいは署名を添付する機能はプログラム配信サーバ１２ではなく他のサーバで実現し、ドメインおよび証明書或いは署名を埋め込んだアプリケーションプログラムおよびアプリケーションパッケージをプログラム配信サーバ１２に置くようにしてもよい。つまり、プログラム配信サーバｌ２で上述のすべての処理を行うのでなく複数のサーバで処理を分担するようにしてもよい。
図９は、図７及び図８に示した第２の実施の形態において、携帯端末１０に取り込んだアプリケーションパッケージに含まれるアプリケーションプログラムの起動準備が完了するまでの処理を説明するためのフローチャートである。このフローチャートでの動作の前に、携帯端末１０のプログラム取得手段１０９は、プログラムパッケージを取り込んでいるものとする。
ステップＳ９００において、プログラム取得手段１０９は、ドメイン情報取出／添付手段１１６を呼び出し、この手段１１６においてアプリケーションパッケージに添付されているセキュリティドメイン情報を取り出す処理が行なわれる。ステップＳ９０２において、ドメイン情報取出／添付手段１１６はセキュリティドメイン情報が取り出せたかどうかの判定を行ない、判定結果を呼出元のプログラム取得手段１０９に通知する。セキュリティドメイン情報が取り出されていればステップＳ９０４に進む。取り出されていなければ、ステップＳ９０６において、プログラム取得手段１０９は、ドメイン情報取出／添付手段１１６を呼び出してパッケージを展開し、展開された複数のアプリケーションプログラムを取得してフローを終了する。
ステップＳ９０４において、プログラム取得手段１０９は、署名検証／添付手段１１７を呼び出し、この手段１１７においてアプリケーションパッケージにデジタル署名又はデジタル証明書が添付されているかの検証が行なわれ、署名検証／添付手段１１７はその検証結果をプログラム取得手段１０９に通知する。尚、デジタル署名又はデジタル証明書が暗号化されていれば復号を行なう。
次のステップＳ９０８に示すように、デジタル署名又はデジタル証明書が添付されていなければ図９のフローを終了し、デジタル署名又はデジタル証明書が添付されていればステップＳ９１０に進む。このステップＳ９１０において、プログラム取得手段１０９は、ドメイン情報取出／添付手段１１６を呼び出し、この手段１１６によりパッケージを展開して複数のアプリケーションプログラムを取り出す。
ステップＳ９１２において、プログラム取得手段１０９は、ドメイン情報取出／添付手段１１６を呼び出し、夫々のアプリケーションプログラムにセキュリティドメイン情報を添付する。
最後に、ステップＳ９１４において、プログラム取得手段１０９は、署名検証／添付手段１１７を呼び出し、セキュリティドメイン情報が添付されたアプリケーションプログラムをデジタル署名する（デジタル署名を添付する）。この場合、携帯端末１０内で秘密鍵と公開鍵とを作成しておき、秘密鍵を使用してデジタル署名を行い、アプリケーションプログラムの起動時に署名検証するために公開鍵を検証手段１１５３に通知しておく。本ステップＳ９１４では、デジタル署名の代わりにデジタル証明書を添付してもよい。
アプリケーションパッケージ内にライブラリ及びデバイスドライバがあれば、これらについても上述の処理が施される。
複数のアプリケーションプログラムの夫々（図７において１１２で示す）を起動する際の動作は第１の実施の形態と同様である。
図９のフローチャートでは、外部から取り込んだアプリケーションパッケージにデジタル署名又はデジタル証明書とは別にセキュリティドメイン情報が添付されている場合を説明したが、セキュリティドメイン情報がデジタル証明書に含まれている場合は、ステップＳ９０２とステップＳ９０８の順番を逆にする必要がある。
第２の実施の形態によれば、複数のアプリケーションプログラムをアプリケーションパッケージとして配布することが可能である。したがって、携帯端末１０は一度に複数のアプリケーションパッケージを取り込むことができるのでデータ通信量を削減できるという効果がある。また、アプリケーションパッケージ展開後の個々のアプリケーションプログラムには、アプリケーションパッケージに添付されていたセキュリティドメイン情報を添付するため、アプリケーションプログラム（ステップＳ９０８或いはＳ９１４を経たアプリケーションプログラムを図７では参照番号１１２で示す）の起動時の素性確認が容易である。更に、デジタル署名されるため、携帯端末１０内においてアプリケーションパッケージ展開された後のアプリケーションプログラムが改竄された場合でも容易にその改竄が検知できる。
アプリケーションパッケージの形態として、アプリケーションパッケージおよびそれに含まれるアプリケーションプログラムの両方にセキュリティドメイン情報と署名あるいは証明書が添付されていることも考えられる。その場合、図９のステップＳ９１２をスキップするか、或いは、アプリケーションパッケージに添付されていたセキュリティドメイン情報でアプリケーションプログラムのセキュリティドメイン情報を上書きすることで対応可能である。
第３の実施の形態について図１０を参照して説明する。
上述したように、第１及び第２の実施の形態では、プログラムに付加されているセキュリティドメイン情報を記述したデータを取り出し、取り出したデータに基づいてセキュリティドメインを決定或いは判別している。
これに対し、第３の実施の形態では、携帯端末１０に取り込まれるプログラムには、ドメイン情報の代わりに、デジタル証明書或いはデジタル署名が付加されている。第３の実施の形態によれば、プログラムからこの証明書或いは署名を取得し（取り出し）、取得した証明書或いは署名を検証し、検証に成功した証明書或いは公開鍵の種別によってドメインを決定するようにしている。
即ち、図１０に即して説明すれば、プログラムに付加されている証明書或いは署名は、「証明書或いは署名取得手段」１１５２ｂにおいて取得され（取り出され）、検証手段１１５３ｂにおいて、携帯端末内に保持され且つ複数のドメインの夫々に関連付けられたルート証明書（親証明書）又は公開鍵を順次使用してドメインの検証が行なわれる。検証が成功（正常終了）したときに使用されたルート証明書（親証明書）又は公開鍵に関連付けられているドメインが、検証対象となったプログラムのセキュリティドメインと決定される。
第３の実施の形態の変形例として、上述の第２の実施の形態と同様、パッケージに証明書或いは署名を付加するようにしてもよい。この変形例の動作は、上述の第２及び第３の実施の形態の説明から容易に理解できるので詳細な説明は省略する。
上述した第１乃至第３の実施の形態では、セキュリティドメインに応じて携帯端末内の資源へのプログラムのアクセス制限を行っている。しかし、本発明は、セキュリティドメインに応じた様々な制限（例えば、使用可能な資源の制限）を取り込んだプログラムに課すようにすることも可能である。即ち、プログラムに関連したセキュリティドメインを決定した後に、そのドメインで規定されている制限内でのみ、そのプログラムを正常に動作させるようにすることも可能である。
第４の実施の形態を図１１及び図１２を参照して説明する。
上述した第１〜第３の実施の形態では、カーネル空間（ＯＳ）においてセキュリティドメイン情報をアプリケーションプログラムから取り出し、取り出したセキュリティドメイン情報に対応するセキュリティＩＤを設定している。
これに対し、第４の実施の形態では、図１１に示すように、図１においてカーネル空間に設けていたセキュリティドメイン情報取得手段１１５２及びアクセス制御設定手段１１５４をユーザ空間に移し、ユーザ空間において、夫々、セキュリティドメイン情報取得手段１１８及びアクセス制御設定手段１１９として動作させている。即ち、セキュリティドメイン情報取得手段１１８は、ユーザ空間において、第１の実施の形態の図１のセキュリティドメイン取得手段１１５２と同様に機能し、アクセス制御設定手段１１９は、ユーザ空間において、第１の実施の形態の図１のアクセス制御手段設定手段１１５４と同様に機能する。
図１１のアクセス制御手段１１５５は、ユーザ空間からアプリケーションプログラム１１２のセキュリティＩＤ設定に関する操作を可能とする機能を有している。このアクセス制御手段１１５５へのユーザ空間からのアクセスは、アクセス制御設定手段１１９からのみとなるアクセス制御をセキュリティポリシデータベース１１５６に予め設定しておく。
以下、本実施の形態の動作を、アプリケーションプログラムを例にとって、図１２のフローチャートを用いて説明する。
図１２のフローチャートを用いて説明する動作の前提として、信頼できるアプリケーションプログラムの作成者又は配布者は、送信しようとするアプリケーションプログラムにセキュリティドメイン情報とデジタル署名（或いはデジタル証明書）を添付し、そのアプリケーションプログラムをプログラム配信サーバ１２（図１１）に置くものとする。或いは、上述の作成者又は配布者は、アプリケーションプログラムをプログラム配信サーバ１２に置く代わりに、そのアプリケーションプログラムを外部メモリ１０５（例えばＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カードなど）に記録してもよい。
ステップＳ１２００において、携帯端末１０は、プログラム配信サーバ１２に置かれたアプリケーションプログラムを、アプリケーション取得手段１０９により携帯端末１０の内部に取り込む（或いは、外部メモリ１０５を携帯端末１０に装着して記録されているアプリケーションプログラムを携帯端末１０に取り込む）。
上述の場合は、携帯端末１０に配信されるアプリケーションプログラムは、セキュリティドメイン情報及びデジタル署名を含んでいるが、これに限らず、セキュリティドメイン情報及びデジタル署名を含まない「信頼できないアプリケーションプログラム」も上述と同様に携帯端末１０に取り込まれる場合もある。
なお、ライブラリおよびデバイスドライバも、上述のアプリケーションプログラムの場合と同様に携帯端末１０に取り込むことができる（図１１では取り込まれたライブラリおよびデバイスドライバを夫々１１１及び１１３で示している）。
携帯端末１０が取り込んだアプリケーションプログラム（図１１において１１２で示す）を起動する場合、先ず、ステップＳ１２０２において、取り込んだアプリケーションプログラム１１２からセキュリティドメイン情報が取り出せたかどうかの判断を行う。セキュリティドメイン情報を取り出すためには、セキュリティドメイン情報取得手段１１８が呼び出される。セキュリティドメイン情報取得手段１１８は、アプリケーションプログラム１１２を構成するファイル（例えば図４参照）を解析し、アプリケーションプログラム１１２にセキュリティドメイン情報が存在すればそれを取り出す。
セキュリティドメイン情報が取り出せない場合にはステップＳ１２０４に進み、このステップにおいて、そのアプリケーションプログラム１１２は信頼できないと判断され、アクセス制御設定手段１１９を呼び出す。この場合、アクセス制御設定手段１１９は、セキュリティドメイン種別を「信頼できないベンダ」と判断してセキュリティＩＤを４とし、ステップＳ１２０８に進む。一方、ステップＳ１２０２において、セキュリティドメイン情報が取り出せた場合には直接ステップＳ１２０６に進む。
ステップＳ１２０６では、アクセス制御設定手段１１９を呼び出してセキュリティドメイン情報からセキュリティドメイン情報種別を判断し、例えば図５に示した表を参照して、そのセキュリティドメイン情報種別に対応するセキュリティＩＤを決定する。
ステップＳ１２０８において、アプリケーションプログラム１１２とセキュリティＩＤとを関連付ける。即ち、アプリケーションプログラム１１２は、携帯端末１０上ではプロセスとして動作し、そのプロセスに対して決定したセキュリティＩＤを関連付ける。本ステップでは、まだプロセスとして生成されていないので、プロセス生成時に関連付け可能となる設定を行う。例えば、アプリケーションプログラム１１２に関するアクセス制御手段１１５５が管理するセキュリティ情報に、アプリケーションプログラム１１２の実行コードがメモリにマッピング（ロード）された際に、そのプロセスの管理データに該当するセキュリティＩＤを格納するようにアプリケーション１１２に関するセキュリティ情報を書き換えておいてもよい。
この場合、セキュリティ情報には、該当するセキュリティＩＤそのものではなく、該当するセキュリティＩＤを導くための仮ＩＤが設定されてもよい。この場合、図５で示したテーブルのセキュリティＩＤの部分が仮ＩＤとなり、仮ＩＤとセキュリティＩＤとの関連付けを示すテーブルは、セキュリティポリシーデータベース１１５６に設定しておくことになる。
アプリケーションプログラム１１２のプロセスが生成されると、仮ＩＤから該当するセキュリティＩＤが決定され、そのセキュリティＩＤをプロセスの管理データに格納する。なお、仮ＩＤからセキュリティＩＤを決定するための情報は、必要であればセキュリティポリシデータベース１１５６にあらかじめ設定しておく必要がある。ＳＥＬｉｎｕｘを代表とする周知のアクセス制御を可能とするアクセス制御手段１１５５は、プロセス起動時、実行コードがプロセスにマッピングされる際にセキュリティＩＤをプロセスの管理データに設定しており、既存技術として存在している。
ステップＳ１２１０において、アプリケーションプログラム１１２を起動する場合、ＯＳ処理手段１１４にアプリケーションプログラム１１２の起動を依頼する。
ステップＳ１２１２において、検証手段１１５３はアプリケーションプログラム１１２からデジタル署名（又はデジタル証明書）を取り出し、デジタル署名（又はデジタル証明書）が正しいものであるかどうかを検証する。なお、デジタル署名（又はデジタル証明書）が存在しない場合にはステップＳ１２１４に進む。
デジタル署名が添付されていた場合は、署名された秘密鍵と対をなす公開鍵（予め携帯端末１０の内部に格納されている）により署名検証を行う。また、このデジタル署名が暗号化されていれば復号を行った後に署名検証を行う。署名時に使用された秘密鍵がセキュリティドメイン情報ごとに異なる場合は、署名検証に使用する公開鍵もセキュリティドメイン情報ごとに異なることになる。一方、デジタル署名の代わりにデジタル証明書が添付されていた場合はデジタル証明書の検証を行う。検証の結果、デジタル署名（又はデジタル証明書）が正しいものであればステップＳ１２１４に進む。
ステップＳ１２１２において、デジタル署名（又はデジタル証明書）が正しくないと判断された場合には、取り込んだアプリケーションプログラム１１２は改竄されている可能性があるので、アプリケーション１１２の起動処理を中止する（ステップＳ１２１６）。
最後に、アプリケーションプログラム１１２の起動処理が完了し、携帯端末１０上でプロセスとして実行される（ステップＳ１２１４）。
なお、ステップＳ１２０２からステップＳ１２０８の処理を行わないで、ステップＳ１２１０からアプリケーションプログラム１１２の起動処理をした場合、図５に示す「信頼できないべンダ」で実行されるように、生成されるプロセスのデフォルトのセキュリティＩＤが４となるように予めセキュリティポリシデータベース１１５６に設定しておく。
また、プログラム配信サーバ１２から獲得しない（即ち、予め携帯端末１０に存在する）アプリケーションプログラムに関しても該当するセキュリティＩＤが割り当てられるように、セキュリティＩＤを予めセキュリティポリシデータベース１１５６に設定しておく。
上述したように、図１２は、アプリケーションプログラム１１２にセキュリティドメイン情報がデジタル署名（又はデジタル証明書）とは別に添付されている場合のフローチャートである。もし、デジタル署名の代わりにデジタル証明書が添付されており、セキュリティドメイン情報がデジタル証明書の中に含まれている場合は、ステップＳ１２０２でのセキュリティドメイン情報取得についての判断の前に、ステップＳ１２１２のデジタル証明書の検証と同様な処理を追加し、そのデジタル証明書検証後にセキュリティドメイン情報を取り出せばよい。この場合、図１１の検証手段１１５３に証明書検証を依頼するか、検証手段１１５３と同じ機能をユーザ空間に用意することで可能である。
アプリケーションプログラム１１２から生成されたプロセスは、実行コードに従った処理を行うが、その時のアクセス制御は上述した第１、第２及び第３の実施の形態と同じである。
上述した第４の実施の形態の構成および動作は、第１の実施の形態の構成および動作に対応させたものであるが、第３の実施の形態で示した「セキュリティドメイン情報が添付されていないアプリケーションプログラム」についても、同じ構成および動作で実現可能である。
第５の実施の形態を図１３を参照して説明する。
第５の実施の形態は、第４の実施の形態（図１１）のユーザ空間にドメイン情報取出／添付手段１１６と署名検証／添付手段１１７とを追加したものである。このドメイン情報取出／添付手段１１６および署名検証／添付手段１１７は、第２の実施の形態で説明したものと同一である。図１３のドメイン情報取出／添付手段１１６および署名検証／添付手段１１７以外の構成は、第４の実施の形態（図１１）と同じである。
第５の形態を用いてソフトウェアパッケージを展開する動作は、第２の実施の形態のステップＳ９００〜Ｓ９１４（図９）と同じである。また、第５の形態のアプリケーションプログラム１１２を起動する動作は、第４の実施の形態で説明したステップＳ１２００〜Ｓ１２１６（図１２）と同じである。
なお、上述した第５の形態の構成および動作は、第２の実施の形態に対応させたものであるが、第３の実施の形態で示した「セキュリティドメイン情報を添付されていないアプリケーションプログラム」についても同じ構成および動作で実現可能である。
第６の実施の形態について図１４および図１５を参照して説明する。
第１から第５までの実施の形態では、アプリケーションプログラムおよびアプリケーションパッケージの両方またはいずれかにセキュリティドメイン情報を埋め込んでいた。第６の実施の形態では、セキュリティドメイン情報を埋め込む代わりに、セキュリティＩＤを埋め込む。
図１４は、第１の実施の形態のプログラム配信サーバ１２（図２）にセキュリティＩＤを埋め込む機能を追加したプログラム配信サーバ（同じ参照番号１２で示す）の構成図である。第６の実施の形態を示す図１４を、第１の実施の形態のプログラム配信サーバ１２の構成を示す図２と比較すると、図１４では図２に示したドメイン埋め込み手段２０９が削除され、新たにセキュリティＩＤ埋め込み手段２１１とドメイン情報セキュリティＩＤ変換手段２１２とが追加されている。
セキュリティＩＤ埋め込み手段２１１は、セキュリティＩＤをアプリケーションプログラムに埋め込む機能を有している。ドメイン情報セキュリティＩＤ変換手段２１２は、図５に示すテーブルを保持しており、プログラム配信サーバ１２に入力されるセキュリティドメイン情報をセキュリティＩＤに変換する機能を有している。なお、プログラム配信サーバ１２への入力がドメイン情報ではなく、セキュリティＩＤの場合、ドメイン情報セキュリティＩＤ変換手段２１２は何もしない。
図１４のその他の機能については、第１の実施の形態と同じ機能である。図１４に関連する携帯端末の構成例を図１５に示す。図１５を、第１の実施の形態を示した図１と比較すると、図１のセキュリティドメイン情報取得手段１１５２が、セキュリティＩＤ取得手段１１５２ｃとなり、第６の実施の形態では、セキュリティドメイン情報を取得するのではなく、セキュリティＩＤを取得するようになっている。また、図５に示すテーブルは、図１５の携帯端末１０では不要である。
アプリケーションプログラムにセキュリティドメイン情報ではなくセキュリティＩＤを埋め込んだ場合の携帯端末１０の動作と、第１の実施の形態の動作（図５）との相違について述べる。図６のステップＳ６０４およびＳ６０６のセキュリティドメイン取り出しについては、第６の実施の形態では、セキュリティＩＤが取り出されることになる。更に、図６のステップＳ６１２における「セキュリティドメイン種別を判定してセキュリティＩＤを決定する処理」は不要となる。
第６の実施の形態では、第１の実施の形態にセキュリティドメイン情報の代わりにセキュリティＩＤを埋め込む手法を説明したが、この手法は、第２から第５までの実施の形態にも適応可能である。
第７の実施の形態について図１６を参照して説明する。
第１から第５までの実施の形態では、アプリケーションプログラムおよびアプリケーションパッケージの両方または何れかにセキュリティドメイン情報を埋め込み、一方、第６の実施の形態では、アプリケーションプログラムおよびアプリケーションパッケージの両方または何れかにセキュリティドメイン情報の代わりにセキュリティＩＤを埋め込むようにしていた。
第７の実施の形態では、第２の実施の形態で示した、アプリケーションパッケージまたはその中に含まれるアプリケーションプログラムにはセキュリティドメイン情報を埋め込み、アプリケーションパッケージを展開する際にアプリケーションプログラムに、セキュリティＩＤを埋め込んでいる。
図１６は、第２の実施の形態にアプリケーションパッケージを展開する際にアプリケーションプログラムに、セキュリティＩＤを埋め込む仕組みを追加した構成を示す図である。
図１６を、第２の実施の形態に係る図７と比較すると、図１６では、図７のドメイン情報取出／添付手段１１６がドメイン情報取得／ＩＤ添付手段１１６ｂとなっている。
ドメイン情報取出／ＩＤ添付手段１１６ｂは、セキュリティドメイン情報を取得後、セキュリティＩＤをアプリケーションプログラム１１２に添付する。また、この処理を行うため、図５に示すテーブルはドメイン情報取出／ＩＤ添付手段１１６ｂが管理するようにする。或いは、図５に示すテーブルをドメイン情報取出／ＩＤ添付手段１１６ｂから参照可能な場所に置くようにしてもよい。
アプリケーションプログラムにセキュリティドメイン情報ではなくセキュリティＩＤを埋め込む第７の実施の形態による携帯端末１０上の動作を、第２の実施の形態によるアプリケーションパッケージの展開動作（図９のフローチャート）と対比して説明すると、第７の実施の形態によれば、ステップＳ９１２では、ドメイン情報取出／ＩＤ添付手段１１６ｂがアプリケーションパッケージに添付されていたセキュリティドメイン情報をもとにして図５に示したテーブルからセキュリティＩＤを求め、アプリケーションプログラム１１２の夫々にそのセキュリティＩＤを埋め込む。更に、ステップＳ９１４では、セキュリティＩＤを埋め込まれたアプリケーションプログラム１１２をデジタル署名する。
第６の実施の形態のアプリケーションプログラムを実行する動作は、第２の実施の形態と同じである。

実施例を用いて更に本発明を説明する。
図１のアプリケーションプログラム１１２に添付されたセキュリティドメイン情報を用いて、セキュリティポリシデータベース１１５６に格納されているアクセス制御ルールがアプリケーションプログラム１１２にどのように適用されるかを具体的に説明する。
図１７は、本発明の実施例に用いるセキュリティポリシデータベース１１５６の具体的な構成の一例を示す図であり、移動体通信システムの携帯端末に適用した場合のセキュリティポリシデータを示している。
セキュリティポリシデータベース１１５６には、アクセス制御ルールとして、Ｏｐｅｒａｔｏｒ、Ｍａｎｕｆａｃｔｕｒｅｒ、Ｔｒｕｓｔｅｄ、Ｕｎｔｒｕｓｔｅｄの各コンテキスト毎に各機能の利用について可否が設定されている。
例えば、セキュリティＩＤが１のＯｐｅｒａｔｏｒコンテキストで動作するアプリケーションプログラムは、「電話をかける」、「通話料金制御」、「サウンド機能」、「通信する」、「画面を使う」の機能の利用が可能である。
一方、セキュリティＩＤが２のＭａｎｕｆａｃｔｕｒｅｒコンテキストで動作するアプリケーションプログラムは、「電話をかける」、「サウンド機能」、「画面を使う」の機能の利用が可能であり、「通話料金制御」及び「通信する」の機能は利用不可である。
更に、セキュリティＩＤが３のＴｒｕｓｔｅｄコンテキストで動作するアプリケーションプログラムは、「サウンド機能」及び「画面を使う」夫々の機能は利用できるが、「電話をかける」、「通話料金制御」、「通信する」の機能は利用できない。
更に、セキュリティＩＤが４のＵｎｔｒｕｓｔｅｄコンテキストで動作するアプリケーションプログラムは、「画面を使う」機能のみの利用が可能であり、「電話をかける」、「サウンド機能」、「通話料金制御」、「通信する」の機能については利用できない。
このように、本実施例を移動体通信システムの携帯端末に適用し、セキュリティポリシデータベース１１５６に上記のようなセキュリティポリシデータを設定することで、非公認（例えば上述のＵｎｔｒｕｓｔｅｄコンテキストの場合）のアプリケーションプログラムによる不正動作（例えば、特定の電話番号への通話、特定サイトへのアクセス等）を禁止することができる。
以上、本発明を移動体通信等に使用される携帯端末に応用した場合について説明したが、これに限らず、外部からアプリケーションプログラムを取り込んで使用する種々の移動及び固定の情報関連機器に応用可能である。

Claims (15)

1. コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照することにより、プログラムが利用できる機能を制限するプログラムの実行制御システムであって、
   前記プログラムに関連付けられたセキュリティドメイン情報を取得するセキュリティドメイン情報取得手段と、
   前記セキュリティドメイン情報に基づいて前記セキュリティドメイン情報の種別を判断し、前記セキュリティポリシデータを参照して当該セキュリティドメイン情報種別に対応するセキュリティＩＤを決定し、前記プログラムのプロセスと前記セキュリティＩＤを関連付けるアクセス制御設定手段と、
   前記セキュリティＩＤに対応付けられているアクセス制御ルールに基づいて、前記プログラムが利用できる機能を制限するアクセス制御手段とを備え、
   前記セキュリティドメイン情報取得手段、前記アクセス制御設定手段、前記アクセス制御手段の一部あるいはすべてをＯＳ内の手段として有する
   ことを特徴とするプログラムの実行制御システム。
2. 前記プログラムにデジタル署名又はデジタル証明書が添付されているかどうかを検証する検証手段を備えることを特徴とする請求項１に記載のプログラムの実行制御システム。
3. 前記前記プログラムにデジタル署名又はデジタル証明書が添付されていない場合、前記プログラムの起動処理を終了することを特徴とする請求項２に記載のプログラムの実行制御システム。
4. 前記前記プログラムにデジタル署名又はデジタル証明書が添付されている場合、前記検証手段が、前記デジタル署名又はデジタル証明書が正しいか否かを検証し、
   前記デジタル署名又はデジタル証明書が正しくない場合、前記プログラムの起動処理を終了することを特徴とする請求項２又は請求項３に記載のプログラムの実行制御システム。
5. 複数のプログラムからなるパッケージに添付されたセキュリティドメイン情報を取出す機能と、前記パッケージを展開して取り出された複数のプログラムの夫々に、前記取出したセキュリティドメイン情報を添付する機能とを有するドメイン情報取出添付手段を備えることを特徴とする請求項１から請求項４の何れか１項に記載のプログラムの実行制御システム。
6. 前記パッケージにデジタル署名又はデジタル証明書が添付されているかどうかを検証する機能と、前記ドメイン情報取出添付手段により前記セキュリティドメイン情報が添付されたプログラムにデジタル署名を添付する機能とを有する署名検証添付手段を備えることを特徴とする請求項５に記載のプログラムの実行制御システム。
7. 前記ドメイン情報取出添付手段が、
   前記パッケージにデジタル署名又はデジタル証明書が添付されてた場合に、前記パッケージを展開して取り出された複数のプログラムの夫々に、前記取出したセキュリティドメイン情報を添付する
   ことを特徴とする請求項６に記載のプログラムの実行制御システム。
8. コンピュータ上で動作するプログラム毎にセキュリティポリシデータを参照することにより、プログラムが利用できる機能を制限するプログラムの実行制御方法であって、
   前記プログラムに関連付けられた前記セキュリティドメイン情報を取得するセキュリティドメイン情報取得ステップと、
   前記セキュリティドメイン情報に基づいて前記セキュリティドメイン情報の種別を判断し、前記セキュリティポリシデータを参照して当該セキュリティドメイン情報種別に対応するセキュリティＩＤを決定し、前記プログラムのプロセスと前記セキュリティＩＤを関連付けるアクセス制御設定ステップと、
   前記セキュリティＩＤに対応付けられているアクセス制御ルールに基づいて、前記プログラムが利用できる機能を制限するアクセス制御ステップとを有し、
   前記セキュリティドメイン情報取得ステップ、前記アクセス制御設定ステップ、前記アクセス制御ステップの一部あるいはすべてがＯＳ内で実施されることを特徴とするプログラムの実行制御方法。
9. 前記プログラムにデジタル署名又はデジタル証明書が添付されているかどうかを検証する検証ステップを有することを特徴とする請求項８に記載のプログラムの実行制御方法。
10. 前記前記プログラムにデジタル署名又はデジタル証明書が添付されていない場合、前記プログラムの起動処理を終了することを特徴とする請求項９に記載のプログラムの実行制御方法。
11. 前記前記プログラムにデジタル署名又はデジタル証明書が添付されている場合、前記検証ステップで、前記デジタル署名又はデジタル証明書が正しいか否かを検証し、
    前記デジタル署名又はデジタル証明書が正しくない場合、前記プログラムの起動処理を終了することを特徴とする請求項９又は請求項１０に記載のプログラムの実行制御方法。
12. 複数のプログラムからなるパッケージに添付されたセキュリティドメイン情報を取出すステップと、前記パッケージを展開して取り出された複数のプログラムの夫々に、前記取出したセキュリティドメイン情報を添付するステップとを含むドメイン情報取出添付ステップを有することを特徴とする請求項８から請求項１１の何れか１項に記載のプログラムの実行制御方法。
13. 前記パッケージにデジタル署名又はデジタル証明書が添付されているかどうかを検証するステップと、前記ドメイン情報取出添付ステップにおいて前記セキュリティドメイン情報が添付されたプログラムにデジタル署名を添付するステップとを含む署名検証添付ステップを有することを特徴とする請求項１２に記載のプログラムの実行制御方法。
14. 前記ドメイン情報取出添付ステップで、
    前記パッケージにデジタル署名又はデジタル証明書が添付されてた場合に、前記パッケージを展開して取り出された複数のプログラムの夫々に、前記取出したセキュリティドメイン情報を添付する
    ことを特徴とする請求項１３に記載のプログラムの実行制御方法。
15. 請求項８乃至１４のいずれかに記載のプログラムの実行制御方法を実現するためのコンピュータプログラム。

Images