JP6612322B2 - データ処理方法およびデータ処理装置 - Google Patents

Description

本発明の実施形態は、通信分野に関し、詳細には、データ処理方法およびデータ処理装置に関する。

情報技術の発展と共に、個人情報のセキュリティが人々の大きな関心事となっている。ユーザは（ノートブックコンピュータ、スマートフォン、タブレットコンピュータといった）様々なインテリジェント端末を用いて個人データ操作を行う場合がある。例えばユーザは、電子メール、モバイルバンク、ソーシャルネットワークといったアプリケーションプログラムの操作を行う場合があり、使い勝手がいいように、ユーザは普通、ログインパスワードといったプライバシデータをインテリジェント端末に保存している。

しかし、現在のインテリジェント端末によるプライバシデータの保護においてはいくつかの脅威も存在する。例えば、プライバシデータは平文形式で携帯電話機に直接保存されており、これによりプライバシデータの漏洩が生じやすい。先行技術ではユーザのプライバシデータに対して暗号化が行われるが、暗号化されたプライバシデータの鍵はバージョン互換性があり、ユーザ移行の容易なプログラムでコード化されており、攻撃者によって容易に獲得される可能性がある。その結果、ユーザのプライバシデータに大きなリスクが生じることになる。

したがって、現在のインテリジェント端末においてはデータセキュリティを強化することが急務である。

本発明の実施形態は、攻撃者によるデータの盗み取りを有効に防止して、データセキュリティを向上させることができるデータ処理方法およびデータ処理装置を提供する。

第1の態様によれば、データ処理方法が提供され、本方法は、
信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップであって、第1のネットワーク・データ・パケットは第1の識別子を含む、ステップと、
信頼されている実行ドメインで、第1の識別子に対応する第1のデータを取得するステップであって、第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、ステップと、
信頼されている実行ドメインで、第1のデータおよび第1のネットワーク・データ・パケットに従って第2のネットワーク・データ・パケットを生成するステップと、
信頼されている実行ドメインで、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて第2のネットワーク・データ・パケットの暗号化を行い、暗号化された第2のネットワーク・データ・パケットを取得するステップと、
暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するステップと、
を含む。

第1の態様に関連して、第1の態様の第1の可能な実施態様において、本方法は、
ターゲットサーバによって送信された、第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するステップと、
信頼されている実行ドメインで、第1のセッション鍵を用いて、暗号化された第3のネットワーク・データ・パケットを復号するステップと、
復号された第3のネットワーク・データ・パケットが第1のデータを含むと判定される場合に、第3のネットワーク・データ・パケット、および第1のデータに対応する第1の識別子に従って第4のネットワーク・データ・パケットを生成するステップであって、第4のネットワーク・データ・パケットは第1のデータを含まない、ステップと、
第4のネットワーク・データ・パケットを信頼されていない実行ドメインで動作するターゲットアプリケーションへ送るステップと、
をさらに含む。

第1の態様または第1の態様の第1の可能な実施態様に関連して、第1の態様の第2の可能な実施態様において、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップよりも前に、本方法は、
信頼されている実行ドメインで、ターゲットサーバとのセキュア・ソケット・レイヤ（SSL）接続を確立し、第1のセッション鍵を決定するステップであって、第1のセッション鍵は、ターゲットサーバの第1の証明書に関する、信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、第1の証明書はターゲットサーバの識別を証明するために用いられる、ステップ、
をさらに含む。

第1の態様の第2の可能な実施態様に関連して、第1の態様の第3の可能な実施態様において、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップよりも前に、本方法は、
信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するステップであって、第2の証明書は第1の証明書と同じ汎用名を有し、第2のルート証明書は信頼されている実行ドメインと信頼されていない実行ドメインとで事前に記憶されている、ステップと、
第2の証明書および第2のルート証明書に従って、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2のセッション鍵を決定するステップであって、第2のセッション鍵は信頼されている実行ドメインと信頼されていない実行ドメインとの間のセッション鍵である、ステップと、
をさらに含み、
信頼されている実行ドメインで、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップは、
第2のセッション鍵を用いて暗号化されている第1のネットワーク・データ・パケットを取得するステップと、
信頼されている実行ドメインで、第2のセッション鍵を用いて、暗号化された第1のネットワーク・データ・パケットを復号するステップと、
を含む。

第1の態様の第3の可能な実施態様に関連して、第1の態様の第4の可能な実施態様において、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2の証明書および第2のルート証明書に従って第2のセッション鍵を決定するステップは、
信頼されている実行ドメインで生成された第2の証明書を取得するステップと、
信頼されていない実行ドメインで、第2のルート証明書に従って第2の証明書を検証するステップと、
検証に成功した場合に第2のセッション鍵を生成し、第2の証明書の公開鍵を用いて第2のセッション鍵を暗号化するステップと、
信頼されている実行ドメインで、第2の証明書の秘密鍵を用いて、暗号化された第2のセッション鍵を復号し、第2のセッション鍵を獲得するステップと、
を含む。

第1の態様および第1の態様の第1から第4の可能な実施態様の任意の1つの可能な実施態様に関連して、第1の態様の第5の可能な実施態様において、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するステップは、
共用メモリを用いて信頼されていない実行ドメインへ暗号化された第2のネットワーク・データ・パケットを渡すステップと、
信頼されていない実行ドメインで、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するステップと、
を含む。

第2の態様によれば、データ処理装置が提供され、本装置は、
信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するように構成された第1の取得モジュールであって、第1のネットワーク・データ・パケットは第1の識別子を含む、第1の取得モジュールと、
信頼されている実行ドメインで、第1の取得モジュールによって取得された第1のネットワーク・データ・パケット内の第1の識別子に対応する第1のデータを取得するように構成された第2の取得モジュールであって、第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、第2の取得モジュールと、
信頼されている実行ドメインで、第1のネットワーク・データ・パケット、および第2の取得モジュールによって取得された第1のデータに従って第2のネットワーク・データ・パケットを生成するように構成された第1の生成モジュールと、
信頼されている実行ドメインで、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて、第1の生成モジュールによって生成された第2のネットワーク・データ・パケットの暗号化を行い、暗号化された第2のネットワーク・データ・パケットを取得するように構成された暗号化モジュールと、
暗号化モジュールによって取得された暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成された第1の送信モジュールと、
を含む。

第2の態様に関連して、第2の態様の第1の可能な実施態様において、本装置は、
ターゲットサーバによって送信された、第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するように構成された受信モジュールと、
信頼されている実行ドメインで、第1のセッション鍵を用いて、受信モジュールによって受信された暗号化された第3のネットワーク・データ・パケットを復号し、復号された第3のネットワーク・データ・パケットが第1のデータを含むと判定される場合に、第3のネットワーク・データ・パケット、および第1のデータに対応する第1の識別子に従って第4のネットワーク・データ・パケットを生成するように構成された処理モジュールであって、第4のネットワーク・データ・パケットは第1のデータを含まない、処理モジュールと、
処理モジュールによって生成された第4のネットワーク・データ・パケットを信頼されていない実行ドメインで動作するターゲットアプリケーションへ送るように構成された第2の送信モジュールと、
をさらに含む。

第2の態様または第2の態様の第1の可能な実施態様に関連して、第2の態様の第2の可能な実施態様において、本装置は、
第1の取得モジュールが信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、信頼されている実行ドメインで、ターゲットサーバとのセキュア・ソケット・レイヤ（SSL）接続を確立し、第1のセッション鍵を決定するように構成された第1の確立モジュールであって、第1のセッション鍵は、ターゲットサーバの第1の証明書に関する、信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、第1の証明書はターゲットサーバの識別を証明するために用いられる、第1の確立モジュール、
をさらに含む。

第2の態様の第2の可能な実施態様に関連して、第2の態様の第3の可能な実施態様において、本装置は、
第1の取得モジュールが信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するように構成された第2の生成モジュールであって、第2の証明書は第1の証明書と同じ汎用名を有し、第2のルート証明書は信頼されている実行ドメインと信頼されていない実行ドメインとで事前に記憶されている、第2の生成モジュールと、
第2のルート証明書、および第2の生成モジュールによって生成された第2の証明書に従って、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2のセッション鍵を決定するように構成された第2の確立モジュールであって、第2のセッション鍵は信頼されている実行ドメインと信頼されていない実行ドメインとの間のセッション鍵である、第2の確立モジュールと、
さらに含み、
第1の取得モジュールは、
第2のセッション鍵を用いて暗号化されている第1のネットワーク・データ・パケットを取得するように構成された第1の取得部と、
信頼されている実行ドメインで、第2のセッション鍵を用いて、第1の取得部によって取得された暗号化された第1のネットワーク・データ・パケットを復号するように構成された復号部と、
を含む。

第2の態様の第3の可能な実施態様に関連して、第2の態様の第4の可能な実施態様において、第2の確立モジュールは、
信頼されている実行ドメインで生成された第2の証明書を取得するように構成された第2の取得部と、
信頼されていない実行ドメインで、第2のルート証明書に従って、第2の取得部によって取得された第2の証明書を検証し、検証に成功した場合に第2のセッション鍵を生成し、第2の証明書の公開鍵を用いて第2のセッション鍵を暗号化するように構成された処理部と、
信頼されている実行ドメインで、第2の証明書の秘密鍵を用いて、処理部によって暗号化された第2のセッション鍵を復号し、第2のセッション鍵を獲得するように構成された復号部と、
を含む。

第2の態様および第2の態様の第1から第4の可能な実施態様の任意の1つの可能な実施態様に関連して、第2の態様の第5の可能な実施態様において、第1の送信モジュールは、
共用メモリを用いて信頼されていない実行ドメインへ暗号化された第2のネットワーク・データ・パケットを渡すように構成された受渡し部と、
信頼されていない実行ドメインで、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成された送信部と、
を含む。

以上の技術的解決策に基づき、本発明の実施形態によるデータ処理方法およびデータ処理装置では、データが信頼されている実行ドメインで記憶されており、そのため、データを使用するプロセスにおいて、平文形式のデータが信頼されていない実行ドメインで表示されることが有効に防止され、攻撃者によるデータの盗み取りを有効に防止することができ、それによってデータセキュリティが向上する。

本発明の実施形態における技術的解決策をより明確に説明するために、以下で、これらの実施形態を説明するために必要な添付の図面について簡単に述べる。当然ながら、以下の説明における添付の図面は単に本発明のいくつかの実施形態を示すにすぎず、当業者は、これら添付の図面から難なく他の図面をさらに導出することができる。

本発明の一実施形態によるデータ処理方法の適用シナリオの概略図である。 本発明の一実施形態によるデータ処理方法の概略的流れ図である。 本発明の一実施形態によるデータ処理方法の別の概略的流れ図である。 本発明の一実施形態によるデータ処理方法の別の概略的流れ図である。 本発明の一実施形態によるデータ処理装置の概略的ブロック図である。 本発明の別の実施形態によるデータ処理装置の概略的ブロック図である。

以下で、本発明の実施形態における添付の図面に関連して、本発明の実施形態における技術的解決策を明確に説明する。当然ながら、説明される実施形態は、本発明の実施形態の全部ではなく、一部であるにすぎない。本発明の実施形態に基づいて当業者によって難なく得られる他のすべての実施形態は、本発明の保護範囲内に含まれるものとする。

本発明の技術的解決策は、モバイル通信用グローバルシステム（Global System of Mobile communication、略称「GSM（登録商標）」）、符号分割多元接続（Code Division Multiple Access、略称「CDMA」）システム、広帯域符号分割多元接続（Wideband Code Division Multiple Access、略称「WCDMA（登録商標）」）システム、汎用パケット無線サービス（General Packet Radio Service、略称「GPRS」）システム、ロング・ターム・エボルーション（Long Term Evolution、略称「LTE」）システム、周波数分割複信（Frequency Division Duplex、略称「FDD」）システム、時分割複信（Time Division Duplex、略称「TDD」）システム、ユニバーサル移動電話システム（Universal Mobile Telecommunication System、略称「UMTS」）といった様々な通信システムに適用できることを理解すべきである。

本発明の各実施形態において、端末は、ユーザ機器（User Equipment、略称「UE」）、移動局（Mobile Station、略称「MS」）、移動端末（Mobile Terminal）などと呼ばれる場合もあることをさらに理解すべきである。端末は、無線アクセスネットワーク（Radio Access Network、略称「RAN」）を用いて1つ以上のコアネットワークとの通信を行うことができる。例えば、端末は、携帯電話機（あるいは、「セルラ」電話機またはセルフォンとも呼ばれる）、移動端末を有するコンピュータなどとすることができる。例えば、端末はさらに、無線アクセスネットワークと音声および／またはデータをやりとりする、携帯型モバイル装置、ポケットサイズのモバイル装置、ハンドヘルド型モバイル装置、コンピュータ内蔵型モバイル装置、または車載式モバイル装置とすることもできる。表現しやすいように、本発明の実施形態では端末が携帯電話機であることを説明例として用いているが、本発明の実施形態はそれだけに限定されない。

本発明の実施形態を理解しやすいように、本発明の実施形態の説明で用いられうるいくつかの要素についてここでまず説明する。

1．信頼されていない実行ドメインおよび信頼されている実行ドメイン：
信頼されていない実行ドメインと信頼されている実行ドメインとは、同じプロセッサ上で動作する2つの動作環境として理解することができ、信頼されていない実行ドメインはさらに「ノーマルワールド」とも呼ばれ、例えば、アプリケーションを動作させるための環境であり、それに対応して、信頼されている実行ドメインは「セキュアワールド」とも呼ばれる。信頼されていない実行ドメインの情報またはデータは、攻撃者によって盗み取られ、または損傷される可能性があり、すなわち、信頼されていない実行ドメインの情報およびデータのセキュリティは高くはない。信頼されていない実行ドメインと比べて、信頼されている実行ドメインは情報およびデータのセキュリティを有効に保証することができ、信頼されていない実行ドメインのアプリケーション／システムプログラムはいずれも、信頼されている実行ドメインのデータおよび情報へのランダムなアクセス／変更を行うことができないため、信頼されている実行ドメインの情報またはデータは、攻撃者によって取得されることも、改ざんされることもない。加えて、端末のハードウェアとソフトウェアとは信頼されている実行ドメインのセキュリティを共同で保証する。具体的には、ARM（Advanced RISC Machine、アドバンスト縮小命令セット・コンピューティング・マシン）プロセッサに基づく端末では、ARMによって提供されるTrustZoneセキュリティ拡張技術が信頼されていない実行ドメインおよび信頼されている実行ドメインの設計に用いられうる。

2．セキュア・ソケット・レイヤ（Secure Sockets Layer、略称「SSL」）通信：
SSLは汎用の通信暗号化プロトコルであり、クライアントとサーバとの間の通信のセキュリティをセキュアに、有効に保証することができる。SSLに基づく通信は2つのステップに分けられ、第1のステップは、クライアントとサーバとの間でSSL接続を確立するために非対称暗号化方式で通信を暗号化することである。具体的な手順は以下のとおりである。クライアントはまずサーバへの接続要求を開始する。サーバはクライアントに対してサーバの識別を証明する証明書を送信することができ、証明書はサーバの何らかの情報および非対称暗号化のための公開鍵を含む。クライアントがサーバの識別に関する検証に成功した後で、クライアントは対称暗号化のためのセッション鍵を生成し、次いで、サーバの証明書内の公開鍵を用いてセッション鍵を暗号化し、暗号化されたセッション鍵をサーバへ送信する。セッション鍵は非対称的に暗号化されており、したがって、公開鍵を用いて暗号化されているセッション鍵は、サーバの秘密鍵を用いてしか復号することができない（秘密鍵はサーバのみによって保持される）。この時点で、クライアントはサーバの識別に関する検証を完了し、サーバとの折衝によりセッション鍵をセキュアに決定する。第2のステップでは、通信段階で、クライアントとサーバとの間のすべての後続の通信がセッション鍵を用いて暗号化される。

3．証明書およびルート証明書：
以上から分かるように、SSL接続を確立するプロセスにおいて、サーバは普通、クライアントが検証するためのサーバの識別を証明する証明書を提供し、すなわち、証明書はサーバの識別を証明するために用いられる文書である。一般に、証明書は少なくとも以下の3つの情報を含む。

（1）公開鍵
証明書には公開鍵が含まれており、証明書の所有者のみが公開鍵に対応する秘密鍵を有する。非対称暗号化では、公開鍵を用いて暗号化されているコンテンツを復号するには対応する秘密鍵だけしか用いることができず、逆もまた然りである（秘密鍵を用いて暗号化されているコンテンツを復号するには対応する公開鍵だけしか用いることができない）。すなわち、証明書内の公開鍵を用いて暗号化されている情報は証明書の所有者しか復号することができない。したがって、証明書内の公開鍵は、クライアントに接続するのが証明書の所有者でなければならないことを保証することができる（非証明書所有者は公開鍵に対応する秘密鍵を持たず、したがって、証明書内の公開鍵を用いてクライアントによって暗号化されている情報を復号することができず、クライアントとの通信を行うことができない）。

（2）汎用名
証明書には汎用名が含まれている。例えば、そのドメイン名がwww.google.comであるサーバでは、サーバの証明書の汎用名はwww.google.comであり、証明書の汎用名はクライアントに証明書の所有者の識別を知らせることができ、クライアントは、証明書の汎用名が、クライアントが接続しようとしているサーバのドメイン名と一致しているかどうか比較することができる。

（3）署名情報
証明書には認証局の署名情報がさらに含まれうる。署名情報は対応するルート証明書の秘密鍵を用いて認証局によって暗号化されている情報であり、対応するルート証明書はクライアントに事前にインストールされているため、クライアントは署名情報を用いて証明書の信憑性を検証する。クライアントは、信頼されているルート証明書を用いて署名されている証明書だけを信頼する。理解しやすいように、以下でルート証明書について説明する。

ルート証明書は予めクライアントによって信頼されている証明書（例えば、Microsoft Root Authority）であり、ルート証明書はクライアントに事前にインストールされている（ルート証明書には公開鍵も含まれている）。ウェブサイトの証明書に署名するときに、信頼されている認証局は信頼されている認証局のルート証明書の秘密鍵を用いて署名情報を暗号化する。その結果、署名情報は局のルート証明書の公開鍵を用いてしか復号することができなくなり、署名情報はルート証明書の公開鍵を用いて復号することができる。したがって、クライアントが証明書の信憑性を検証するときには、事前に保存されている複数のルート証明書の公開鍵が証明書内の署名情報を復号するために順次に用いられうる。証明書内の署名情報を証明書のうちのいずれか1つを用いて復号することができれば、それは証明書が信頼されている認証局によって発行されたものであること、すなわち、証明書が信頼されていることを示す。

以上から分かるように、SSLプロトコルに基づく通信プロセスにおいては、証明書およびルート証明書が2つの重要な要素であり、これらは通信セキュリティを保証するための基礎であり、鍵である。

現在は、携帯電話機のいくつかのアプリケーション（例えば、Alipay）が動作しているときには、ユーザプライバシに密接に関連するデータ（例えば、ユーザアカウントやパスワードや識別カード番号であり、以下ではこれをユーザ・プライバシ・データと呼ぶ）が、ログインや支払いといった操作を行うためにアプリケーションサーバへ送信される必要がある。先行技術では、ユーザ・プライバシ・データは一般にアプリケーションに記憶されており（信頼されていない実行ドメインで記憶されていることと等しく）、その場合、ユーザ・プライバシ・データと他の情報とが、操作を行うために（Alipayサーバといった）アプリケーションサーバへ一緒に送信される。現在は、携帯電話機とサーバとの間の通信のセキュリティを保証するために、SSLプロトコルを用いて携帯電話機とサーバとの間の通信の暗号化が行われうる。例えば、サーバはSSLプロトコルに従って携帯電話機へ証明書を送信し、いくつかのルート証明書が携帯電話機の信頼されていない実行ドメインで事前に記憶されており、その場合、携帯電話機は、ルート証明書を用いて、サーバによって提供される証明書を検証し、検証に成功した後で、サーバとの折衝によって携帯電話機内のアプリケーションによって暗号化鍵が決定され、鍵は後続の通信において暗号化に用いられる。

しかし、そうしたアーキテクチャにはいくつかの問題が存在する。第1に、ユーザ・プライバシ・データは携帯電話機の信頼されていない実行ドメインで保存されており、これにより攻撃者にユーザ・プライバシ・データを盗み取る機会が与えられる。第2に、携帯電話機は、信頼されていない実行ドメインでルート証明書を用いて、サーバによって提供される証明書を検証し、そのため、攻撃者は、携帯電話機の信頼されていない実行ドメインで悪意のあるルート証明書をインストールすることによってユーザの携帯電話機を攻撃することができる。悪意のあるルート証明書がインストールされている携帯電話機は偽造されたアプリケーションサーバを区別することができないため、携帯電話機は悪意のあるルート証明書に応じてユーザ・プライバシ・データを偽造されたアプリケーションサーバへ送信する可能性があり、これによりユーザ・プライバシ・データのセキュリティが大幅に低下する。

前述の問題を解決するために、本発明では図1に示す構造を提案する。第1に、端末（具体的には、例えば、携帯電話機）は信頼されている実行ドメインと信頼されていない実行ドメインとを含む。先行技術とは異なり、信頼されていない実行ドメインで動作するアプリケーションモジュール（例えば、Alipayといったアプリケーション）はもはやユーザ・プライバシ・データ（例えば、Alipayの支払いパスワード）を保存しておらず、ユーザ・プライバシ・データに取って代わるユーザ・プライバシ・データとの対応関係を有する識別子を保存しており、対応関係とユーザ・プライバシ・データとはどちらも信頼されている実行ドメインで記憶されている（例えば、図に示すように、プライバシデータは信頼されている実行ドメイン内部のセキュリティモジュールに記憶されている）。信頼されていない実行ドメインで動作するアプリケーションモジュールは識別子を含むネットワーク・データ・パケットを送信し、次いで、信頼されている実行ドメイン内部のセキュリティモジュールがネットワーク・データ・パケットを傍受し、ネットワーク・データ・パケット内の識別子に従って対応するユーザ・プライバシ・データを決定し、ネットワーク・データ・パケット内の識別子をユーザ・プライバシ・データで置き換え、次いで、ユーザ・プライバシ・データを含むネットワーク・データ・パケットをアプリケーションサーバへ送信する。このようにして、信頼されていない実行ドメインを攻撃する攻撃者は、たとえ攻撃者が識別子を盗み取ったとしてもユーザ・プライバシ・データを取得することができないため、ユーザ・プライバシ・データのセキュリティを有効に向上させることができる。加えて、先行技術とは異なり、アプリケーションサーバの識別を検証するために用いられるルート証明書（例えば、図1に示すSSLモジュール3のルート証明書1）はもはや信頼されていない実行ドメインでは記憶されておらず、信頼されている実行ドメインで記憶されている。このようにして、たとえ攻撃者が信頼されていない実行ドメインで悪意のあるルート証明書をインストールしたとしても、信頼されている実行ドメインのデータは攻撃者によって取得も改ざんもされえないため、信頼されている実行ドメインのSSLモジュール3は偽造されたアプリケーションサーバを識別することができる。

理解しやすいように、以下で図1に関連して、本発明の一実施形態による適用シナリオにおけるモジュールについて簡単に説明する。図1に示すように、端末は信頼されていない実行ドメインと信頼されている実行ドメインとを含み、ユーザ・プライバシ・データは信頼されている実行ドメインで記憶されている。具体的には、信頼されていない実行ドメインは、アプリケーションモジュールと、SSLモジュール1と、プロキシモジュール1と、ネットワークドライバとを含み、信頼されている実行ドメインは、セキュリティモジュールと、SSLモジュール2と、SSLモジュール3と、プロキシモジュール2とを含む。以下で各モジュールおよび各モジュールの接続関係について簡単に説明する。

信頼されていない実行ドメインの各モジュールについてまず説明する。

アプリケーションモジュール：
具体的には、例えば、Alipay、126 E-mail box、QQといった、信頼されていない実行ドメインで動作するアプリケーションについて、アプリケーションがアプリケーションサーバに関連サービスを要求するときには、（支払いパスワードやユーザの識別カード番号といった）ユーザプライバシに関連したいくつかのデータを用いる必要がある。先行技術とは異なり、本発明においては、信頼されていない実行ドメインで動作するアプリケーションはもはや用いる必要のあるユーザ・プライバシ・データを保存しておらず、（図1に示すように）ユーザ・プライバシ・データとの対応関係を有する識別子を保存しており、対応関係は信頼されている実行ドメインで事前に保存されている。加えて、識別子とユーザ・プライバシ・データとの間には内容の点での関連がない。したがって、信頼されていない実行ドメインを攻撃する攻撃者は、たとえ攻撃者が識別子を盗み取ったとしてもユーザ・プライバシ・データを取得することができない。

SSLモジュール1：
信頼されていない実行ドメインのSSLモジュール1はアプリケーションモジュールのためのSSLサービスを提供し、信頼されていない実行ドメインで記憶されているルート証明書（図1に示すルート証明書2）を用いてアプリケーションサーバの識別を検証し、SSLセッションのセキュリティを保証する。具体的には、SSLモジュール1は、SSLモジュール1とのSSLセッションを行うネットワークサーバがアプリケーション（例えばAlipay）によって指定されたネットワークサーバ（例えばAlipayサーバ）であるかどうか検証する。以下で詳細に説明する。

プロキシモジュール1：
信頼されていない実行ドメインのプロキシモジュール1はネットワーク・データ・パケットを送る役割を担う。アプリケーションモジュールからアプリケーションサーバへ送信されるネットワーク・データ・パケットについて、プロキシモジュール1はネットワーク・データ・パケットを処理のために信頼されている実行ドメインへ送ることができ、アプリケーションサーバから信頼されていない実行ドメインへ送信されるネットワーク・データ・パケットについて、プロキシモジュール1はやはりネットワーク・データ・パケットを処理のために信頼されている実行ドメインへ送ることができ、信頼されている実行ドメインからアプリケーションサーバへ送信されるネットワーク・データ・パケットについて、プロキシモジュール1はネットワーク・データ・パケットをネットワークドライバへ送り、そのためネットワークドライバがネットワーク・データ・パケットをアプリケーションサーバへ送信する。

ネットワークドライバ：
ネットワークドライバは、ネットワーク・データ・パケットをアプリケーションサーバへ送信し、またはアプリケーションサーバによって送信されたネットワーク・データ・パケットを受信する役割を担い、ネットワークドライバは具体的には、例えば、携帯電話機内のネットワークアダプタのドライバとすることができる。

以上では信頼されていない実行ドメインの各モジュールについて説明したが、以下では信頼されている実行ドメインの各モジュールについて説明する。

セキュリティモジュール：このモジュールにはユーザ・プライバシ・データが保存されており、信頼されていない実行ドメインのいかなる悪意のあるプログラム／システムもセキュリティモジュールに記憶されたユーザ・プライバシ・データを盗み取ることができない。より具体的には、このモジュールにおいて、すべてのユーザ・プライバシ・データは「ユーザ・プライバシ・データ＋識別子」のような対応関係に類似したモードで記憶されている。

SSLモジュール3：
図1に示すように、信頼されている実行ドメインのSSLモジュール3は、ネットワークサーバとのSSL接続（図1に示すSSL接続1）を確立するために用いられ、信頼されている実行ドメインで記憶されたルート証明書1はネットワークサーバの識別を検証するために用いられ、通信セキュリティを保証する（図1に示されている、折衝によって決定されるセッション鍵1）。

SSLモジュール2：
SSLモジュール2は、信頼されている実行ドメインのセキュリティモジュールが、アプリケーションサーバの代わりに、信頼されていない実行ドメインのアプリケーションモジュールとのSSL接続（図1に示すSSL接続2）を行うのを支援する役割を担う。

信頼されていない実行ドメインのアプリケーションモジュールは、やはり信頼されていない実行ドメインに位置するSSLモジュール1を用いて、アプリケーションモジュールとSSLセッションを行うネットワークサーバがアプリケーション（例えばAlipay）によって指定されたネットワークサーバ（例えばAlipayサーバ）であるかどうか検証することができる。本発明では、信頼されている実行ドメインとアプリケーションサーバとの間でSSL接続が確立される。言い換えると、セキュリティモジュールとアプリケーションサーバとの間でSSL接続が確立される。したがって、セキュリティモジュールは、アプリケーションモジュールによって指定されたアプリケーションサーバの代わりに、アプリケーションモジュールとのSSL接続を確立する必要がある。したがって、信頼されている実行ドメインで、異なるサーバのために証明書が作成される必要がある。具体的には、証明書はセキュリティモジュールのために作成され、そのためセキュリティモジュールは、アプリケーションサーバの代わりに、アプリケーションモジュールとのSSL接続を行うことができる。以下で詳細に説明する。

プロキシモジュール2：
信頼されている実行ドメインのプロキシモジュール2もネットワーク・データ・パケットを送る役割を担う。プロキシモジュール2は、セキュリティモジュールへ、信頼されていない実行ドメインのプロキシモジュール1から送られたデータパケット（このデータパケットはSSLモジュール2またはSSLモジュール3によって暗号化され、復号される）を送り、セキュリティモジュールによってアプリケーションサーバへ送信されたネットワーク・データ・パケットを処理のために信頼されていない実行ドメインのプロキシモジュール1へ送ることができる。

図1に示すネットワークドライバは信頼されていない実行ドメインに位置すること、すなわち、端末は、信頼されていない実行ドメインで、アプリケーションサーバとの直接通信を行うことを理解すべきである。例えば、信頼されている実行ドメインで処理された後で、ネットワーク・データ・パケットは、信頼されていない実行ドメインへ渡され、次いでアプリケーションサーバへ送信される必要がさらにあり、したがって、プロキシモジュール2は、セキュリティモジュールによってアプリケーションサーバへ送信されたネットワーク・データ・パケットを、処理のために信頼されていない実行ドメインのプロキシモジュール1へ送る必要がある。任意選択で、ネットワークドライバが信頼されており、セキュアである場合、ネットワークドライバは信頼されている実行ドメインで設定されてもよい。言い換えると、端末は、信頼されていない実行ドメインで、アプリケーションサーバとの直接通信を行うことができる。これに対応して、セキュリティモジュールによってアプリケーションサーバへ送信されるネットワーク・データ・パケットについて、プロキシモジュール2はネットワーク・データ・パケットを処理のために信頼されていない実行ドメインのプロキシモジュール1へ送る必要はなく、代わりに、プロキシモジュール2は、ネットワーク・データ・パケットを信頼されている実行ドメインのネットワークドライバへ直接送ることができ、ネットワークドライバはネットワーク・データ・パケットをアプリケーションサーバへ送信することができる。

共用メモリ：
図1に示すように、信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりを支援するために、これら2つの実行ドメイン間には共用メモリがある。信頼されていない実行ドメインで、信頼されている実行ドメインへ送られる必要があるデータパケットが共用メモリに記憶され、データパケットは、信頼されている実行ドメインで、共用メモリから取得され（逆もまた然りである）、すなわち、信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりは共用メモリを用いて行われる。

プロキシモジュール1およびプロキシモジュール2によるネットワーク・データ・パケットの送り、すなわち、信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりは、共用メモリを用いて行われることを理解すべきである。

実際の操作において、信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりはさらに別の手段を用いて行われてもよく、これについては本発明の本実施形態では限定されないことをさらに理解すべきである。

結論として、従来のアーキテクチャとは異なり、本発明では、信頼されていない実行ドメインのアプリケーションモジュールは単にユーザ・プライバシ・データの識別子を記憶するにすぎず、したがって、攻撃者はユーザ・プライバシ・データの識別子を盗み取ることしかできず、プライバシデータを盗み取ることはできない。加えて、識別子とプライバシデータとの間には内容の点で関連がなく、したがって、攻撃者は盗み取った識別子を用いてユーザ・プライバシ・データを逆から導出することもできない。信頼されている実行ドメインでは、信頼されているアプリケーションサーバへ送信されたネットワーク・データ・パケット内の識別子のみがユーザ・プライバシ・データで置き換えられる。ネットワーク・データ・パケットのターゲットサーバが信頼されているサーバではないことが判明した場合には、ネットワーク・データ・パケットに対する操作が行われず、そのため、攻撃者による悪意のある信頼されていないサーバを用いたユーザ・プライバシ・データの盗み取りが防止される。

図1に示すアーキテクチャまたはシナリオは、当業者が本発明の実施形態をよりよく理解するのを支援するために用いられるものであり、本発明の実施形態の範囲を限定するためのものではないことを理解すべきである。例えば、ユーザ・プライバシ・データとの対応関係を有する識別子は、識別子が信頼されていない実行ドメインで記憶されている限り、必ずしもアプリケーションモジュールに記憶されているとは限らない。同様に、ユーザ・プライバシ・データも、ユーザ・プライバシ・データが信頼されている実行ドメインで記憶されている限り、必ずしも図1に示すセキュリティモジュールに記憶されているとは限らない。加えて、当業者は、当然ながら、図1の所与の例に従って様々な均等な改変や変更を加えることができ、そうした改変や変更も本発明の実施形態の保護範囲内に含まれるものである。

図2には、本発明の一実施形態によるデータ処理方法100の概略的流れ図が示されており、方法100は、例えば、端末によって実行され、端末は信頼されていない実行ドメインおよび信頼されている実行ドメインを含み、例えば、図1に示す端末である。図2に示すように、本方法は以下のステップを含む。

S110．信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得し、第1のネットワーク・データ・パケットは第1の識別子を含む。

S120．信頼されている実行ドメインで、第1の識別子に対応する第1のデータを取得し、第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである。

S130．信頼されている実行ドメインで、第1のデータおよび第1のネットワーク・データ・パケットに従って第2のネットワーク・データ・パケットを生成する。

S140．信頼されている実行ドメインで、暗号化された第2のネットワーク・データ・パケットを取得するために、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて第2のネットワーク・データ・パケットの暗号化を行う。

S150．暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信する。

信頼されていない実行ドメインで動作するターゲットアプリケーションは第1の識別子を含む第1のネットワーク・データ・パケットを生成し、第1のネットワーク・データ・パケットはターゲットサーバにサービスを要求するための要求データパケットであると理解されうる。信頼されている実行ドメインで、第1のネットワーク・データ・パケットが取得され、第1のネットワーク・データ・パケット内の第1の識別子に対応する第1のデータが取得され、第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータであり、例えば、図1に示すユーザ・プライバシ・データである。具体的には、第1の識別子とサービスを要求するために必要な第1のデータとの間には対応関係があり、この対応関係は信頼されている実行ドメインで事前に記憶されている。信頼されている実行ドメインでは、取得された第1の識別子および事前に記憶された対応関係に従って第1のデータを取得することができ、第1のデータを含む第2のネットワーク・データ・パケットは、取得された第1のデータおよび第1のネットワーク・データ・パケットに従って信頼されている実行ドメインで決定される。任意選択で、第2のネットワーク・データ・パケットは、第1のネットワーク・データ・パケット内の第1の識別子を第1のデータで置き換えることによって決定されてもよい。信頼されている実行ドメインで、ターゲットサーバとの折衝によって決定された第1のセッション鍵（例えば、図1に示すセッション鍵1）に従って第2のネットワーク・データ・パケットに対する暗号化が行われる。第1のセッション鍵は信頼されている実行ドメインで記憶されており、信頼されていない実行ドメインでは取得することができず、したがって、信頼されていない実行ドメインで動作するシステムまたはプログラムは第1のセッション鍵を取得することができず、平文形式の第1のデータを取得することもできないことを理解すべきである。第1のデータを含む暗号化された第2のネットワーク・データ・パケットはターゲットサーバへ送信され、そのためターゲットサーバは第2のネットワーク・データ・パケットに従ってターゲットアプリケーションの要求に応答する。

したがって、本発明の本実施形態によるデータ処理方法では、データが信頼されている実行ドメインで記憶されており、そのため、データを使用するプロセスにおいて、平文形式のデータが信頼されていない実行ドメインで表示されることが有効に防止され、攻撃者によるデータの盗み取りを有効に防止することができ、それによってデータセキュリティが向上する。

本発明の本実施形態の第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータであることを理解すべきである。例えば、AlipayアプリケーションがAlipayサーバに関連サービスを要求するときには、サーバのためのユーザ名、ログインパスワードまたは支払いパスワードなどを提供する必要があり、第1のデータは具体的には、ユーザ名およびログインパスワードまたは支払いパスワードとすることができる。データが攻撃者によって盗み取られた場合、ユーザの個人所有物または私用資源が危険にさらされる可能性がきわめて高い。本発明では、第1のデータをユーザ・プライバシ・データと呼ぶ場合もあることを理解すべきである。

第1の識別子に加えて、第1のネットワーク・データ・パケットは他の要求情報、例えば、ターゲットサーバのドメイン名といった情報をさらに含むことができ、これについては本発明の本実施形態では限定されないことをさらに理解すべきである。

ステップS110では、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットが取得され、第1のネットワーク・データ・パケットは第1の識別子を含む。具体的には、第1のネットワーク・データ・パケットは共用メモリを用いて取得されうる。

任意選択で、本発明の本実施形態では、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップは、
共用メモリを用いて第1のネットワーク・データ・パケットを取得するステップ、
を含む。

具体的には、信頼されていない実行ドメインで、ターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットは共用メモリに記憶され、次いで、信頼されていない実行ドメインが信頼されている実行ドメインに切り替わり、信頼されている実行ドメインで、第1のネットワーク・データ・パケットが共用メモリから取得され、次いで、信頼されている実行ドメインで、第1のネットワーク・データ・パケットに対して後続の処理が行われる。より具体的には、図1に示すように、信頼されていない実行ドメインで、アプリケーションモジュールによって生成された、第1の識別子を含む第1のネットワーク・データ・パケットがプロキシモジュール1を用いて共用メモリに記憶され、信頼されている実行ドメインで、第1のネットワーク・データ・パケットがプロキシモジュール2を用いて共用メモリから取り出され、次いで、第1のネットワーク・データ・パケットは後続の処理のために信頼されている実行ドメインの別のモジュールへ送られる。

ステップS120で、第1の識別子に対応する第1のデータが信頼されている実行ドメインで取得される。具体的には、第1の識別子とサービスを要求するために必要な第1のデータとの間には対応関係があり、この対応関係は信頼されている実行ドメインで事前に記憶されており、信頼されている実行ドメインで、第1の識別子によって決定される第1のデータはこの対応関係および第1の識別子に従って決定されうる。

第1の識別子と第1のデータとの間には対応関係があるが、第1の識別子には内容の点で第1のデータとの関連はありえないことを理解すべきである。すなわち、信頼されていない実行ドメインを攻撃する攻撃者は、たとえ攻撃者が第1の識別子を盗み取ったとしても対応する第1のデータを導出することも取得することもできず、それによって第1のデータのセキュリティが向上する。第1の識別子は信頼されていない実行ドメインで事前に記憶されていてよい。具体的には、第1の識別子はターゲットアプリケーションに記憶されていてよい。例えば、第1の識別子は図1に示すアプリケーションモジュールに記憶されていてよい。

第1の識別子と第1のデータとの間の対応関係は任意の記憶モードで信頼されている実行ドメインにおいて記憶されていてよいことをさらに理解すべきである。例えば、対応関係は、対応する第1のデータを第1の識別子に従って信頼されている実行ドメインで取得することができる限り、「第1の識別子＋第1のデータ」モードで記憶されていてもよく、あるいは第1の識別子および第1のデータに基づいて確立されるインデックスのモードで記憶されていてもよく、これについては本発明の本実施形態では限定されない

ステップS130で、第2のネットワーク・データ・パケットが第1のデータおよび第1のネットワーク・データ・パケットに従って生成される。第2のネットワーク・データ・パケットは第1のデータを含むことを理解すべきである。

任意選択で、本発明の本実施形態では、信頼されている実行ドメインで、ステップS130の第1のデータおよび第1のネットワーク・データ・パケットに従って第2のネットワーク・データ・パケットを生成するステップは、
第2のネットワーク・データ・パケットを決定するために第1のネットワーク・データ・パケット内の第1の識別子を第1のデータで置き換えるステップ、
を含む。

本発明の本実施形態では、第2のネットワーク・データ・パケットが第1のデータを含み、ターゲットアプリケーションによって指定されるターゲットサーバにサービスを要求することができる限り、第2のネットワーク・データ・パケットは第1のデータおよび第1のネットワーク・データ・パケットに従って再生成されてもよく、これについては本発明の本実施形態では限定されないことを理解すべきである。

ステップS140で、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて第2のネットワーク・データ・パケットに対して暗号化が行われる。第1のセッション鍵は、信頼されている実行ドメインで、ターゲットサーバと通信を行うための鍵であることを理解すべきである。通信が行われる前に、信頼されている実行ドメインの暗号化復号モジュールとターゲットサーバとは第1のセッション鍵について合意しており、これについては図3に関連して以下で詳細に説明する。

第1のセッション鍵は、信頼されていない実行ドメインのシステムまたはプログラムが第1のセッション鍵を取得することができないことが保証される限り、信頼されている実行ドメインで事前に記憶されていてもよく、信頼されている実行ドメインで任意のときにサーバから取得されてもよく、これについては本発明の本実施形態では限定されないことをさらに理解すべきである。

ステップS150で、暗号化された第2のネットワーク・データ・パケットがターゲットサーバへ送信される。具体的には、暗号化された第2のネットワーク・データ・パケットは信頼されている実行ドメインでターゲットサーバへ直接送信されてもよく、または暗号化された第2のネットワーク・データ・パケットは、信頼されている実行ドメインが信頼されている実行ドメインに切り替わった後でターゲットサーバへ送信されてもよい。ターゲットサーバへデータを送信するために用いられるネットワークドライバが信頼されており、セキュアである場合、すなわち、ネットワークドライバが信頼されている実行ドメインで動作する場合には、暗号化された第2のネットワーク・データ・パケットは、信頼されている実行ドメインで、ターゲットサーバへ送信されてよく、ネットワークドライバが信頼されていない場合、すなわち、ネットワークドライバが信頼されていない実行ドメインで動作する場合には、暗号化された第2のネットワーク・データ・パケットは、信頼されていない実行ドメインで、ターゲットサーバへ送信されることを理解すべきである。

任意選択で、本発明の本実施形態では、ステップS150の暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するステップは、
共用メモリを用いて信頼されていない実行ドメインへ暗号化された第2のネットワーク・データ・パケットを渡すステップと、
信頼されていない実行ドメインで、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するステップと、
を含む。

したがって、本発明の本実施形態によるデータ処理方法では、第1のデータが信頼されている実行ドメインで記憶されており、これによりデータセキュリティを向上させることができる。加えて、第1のデータを含むネットワーク・データ・パケットがターゲットサーバへ送信されるときに、第1のデータは第1のセッション鍵を用いて暗号化され、次いで暗号化された第1のデータが送信され、これにより第1のデータのセキュリティがさらに向上する。

ステップS140で、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて第2のネットワーク・データ・パケットに対して暗号化が行われる。第1のセッション鍵は、信頼されている実行ドメインで、ターゲットサーバと通信を行うための鍵であることを理解すべきである。具体的には、第1のセッション鍵はターゲットサーバとのSSL接続を確立することによって決定されうる。

任意選択で、一実施形態では、ステップS110の信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップよりも前に、本方法は、
信頼されている実行ドメインで、ターゲットサーバとのセキュア・ソケット・レイヤSSL接続を確立し、第1のセッション鍵を決定するステップであって、第1のセッション鍵は、ターゲットサーバの第1の証明書に関する、信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、第1の証明書はターゲットサーバの識別を証明するために用いられる、ステップ、
をさらに含む。

具体的には、図3に示すように、ステップS201で、ターゲットサーバとのSSL接続を確立するよう要求するための要求データパケットが、信頼されていない実行ドメインで動作するターゲットアプリケーションを用いて生成され、ステップS202で、要求データパケットはターゲットサーバへ送信され、ステップS203で、ターゲットサーバは、要求データパケットに従って、端末に対してターゲットサーバの識別を証明することができる（第1の証明書に対応する）証明書1を送信する。具体的には、証明書1は公開鍵を含み、サーバのドメイン名が証明書1の汎用名として用いられ、証明書1の署名情報が（第1のルート証明書に対応する）ルート証明書1の秘密鍵を用いて暗号化され、ルート証明書1（具体的には、図1に示すSSLモジュール3のルート証明書1）は端末の信頼されている実行ドメインで事前に記憶されている。ステップS204で、信頼されている実行ドメインにおいて、サーバによって送信された証明書1は事前に記憶されたルート証明書1を用いて検証される。具体的には、証明書1の署名情報がルート証明書1の公開鍵を用いて復号することができると判定される場合、これは、証明書1が信頼されている証明書であること、すなわち、ターゲットサーバは信頼されていることを示し、証明書1の汎用名が、ターゲットアプリケーションがサービスを要求しようとしているサーバのドメイン名と一致すると判定される場合、ターゲットサーバは、信頼されていない実行ドメインで動作するターゲットアプリケーションによって指定されたサーバであると判定することができる。ステップS205で、ターゲットサーバの識別の検証に成功すると、（第1のセッション鍵に対応する）セッション鍵1が生成され、証明書1に含まれる公開鍵を用いてセッション鍵1に対する暗号化が行われる。ステップS206で、暗号化されたセッション鍵1はサーバへ送信され、ステップS207で、ターゲットサーバは、証明書1に含まれる公開鍵に対応する秘密鍵を用いてセッション鍵1を暗号化する。この時点で、端末とターゲットサーバとの間で（やはり図1に示すSSL接続1に対応する）SSL接続1が実施される。

本発明の本実施形態では、ターゲットサーバとのSSL接続は信頼されている実行ドメインで確立され、通信暗号化に用いられるセッション鍵1が生成されること、すなわち、端末は、信頼されている実行ドメインで動作しているときにのみターゲットサーバとの折衝によって決定されたセッション鍵1を知ることができることを理解すべきである。言い換えると、信頼されていない実行ドメインのプログラムおよびシステムはセッション鍵1を取得することができない。したがって、ステップS140で、信頼されている実行ドメインにおいて第1のセッション鍵を用いて、第1のデータを含む第2のネットワーク・データ・パケットに対して暗号化が行われた後で、暗号化された第2のネットワーク・データ・パケットは、信頼されている実行ドメインで、ターゲットサーバによってのみ復号されうる。この場合、攻撃者はユーザ・プライバシ・データを盗み取ることができず、というのは、第1に、攻撃者が信頼されている実行ドメインのいかなるデータを盗み取ることも不可能であり、すなわち、信頼されている実行ドメインで記憶されたユーザ・プライバシ・データを盗み取ることが不可能であるからであり、第2に、サーバの識別を検証するために用いられるルート証明書1は信頼されている実行ドメインで事前に記憶されており、攻撃者はルート証明書1を改ざんすることができないため、攻撃者は、サーバを偽造することによってユーザ・プライバシ・データを盗み取ることができないからである。したがって、信頼されている実行ドメインにおける、信頼されているサーバに対するセキュリティ認証のみが成功する。攻撃者によって偽造されたサーバについては、セキュリティ認証は絶対に成功せず、すなわち、偽造されたサーバとのSSL接続は失敗し、セッション鍵1を決定するための偽造されたサーバとの折衝も行われえない。その結果、攻撃者は、ルート証明書またはサーバを偽造することによって平文形式のユーザ・プライバシ・データを盗み取ることができなくなる。

したがって、本発明の本実施形態では、平文形式のユーザ・プライバシ・データ（第1のデータ）は信頼されていない実行ドメインでは表示されず、そのため、攻撃者による平文形式のユーザ・プライバシ・データの盗み取りを有効に防止することができ、それによってデータセキュリティが向上する。

ステップS202で、要求データパケットはターゲットサーバへ送信されることを理解すべきである。具体的には、信頼されていない実行ドメインで生成された要求データパケットは、共用メモリを用いてまず信頼されている実行ドメインへ渡すことができ、次いで、信頼されている実行ドメインで、ターゲットアプリケーションがサービスを要求しようとしているサーバのドメイン名が要求データパケットに従って取得され、そのため、後続のステップS204で、証明書1の汎用名がサーバのドメイン名に従って検証され、最後に、要求データパケットはターゲットサーバへ送信される。任意選択で、要求データパケットは、信頼されている実行ドメインでターゲットサーバへ送信されても、信頼されていない実行ドメインでターゲットサーバへ送信されてもよく、これについては本発明の本実施形態では限定されない。例えば、サーバへデータを送信し、またはサーバからデータを受信するために用いられるネットワークドライバが信頼されており、セキュアである場合、すなわち、ネットワークドライバが信頼されている実行ドメインで動作する場合、ステップS202で、要求データパケットは、信頼されている実行ドメインで、ターゲットサーバへ送信され、ネットワークドライバが信頼されていない場合、すなわち、ネットワークドライバが信頼されていない実行ドメインで動作する場合、ステップS202で、要求データパケットは、信頼されていない実行ドメインで、ターゲットサーバへ送信される。図3にはサーバによるデータ送信の動作が含まれており、例えば、ステップS202、ステップS203、およびステップS206はすべて信頼されている実行ドメインで行われ、またはすべて信頼されていない実行ドメインで行われることを理解すべきである。具体的実施態様は、ネットワークドライバが位置する実行ドメインに依存する。

具体的には、先行技術では、ネットワークドライバは、図1に示すように、信頼されていない実行ドメインで動作する。したがって、本発明の本実施形態では、ネットワークドライバも信頼されていない実行ドメインで動作する場合、すなわち、ネットワークドライバが、信頼されていない実行ドメインで、ターゲットサーバとの通信伝送を行う場合。具体的には、ターゲットサーバへ要求データパケットを送信する動作、ターゲットサーバによって送信された証明書1を受信する動作、暗号化されたセッション鍵1をターゲットサーバへ送信する動作、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信する動作といった動作は、信頼されていない実行ドメインで行われる。既存のアーキテクチャと比べて、本発明の本実施形態で提供される技術的解決策はデータセキュリティの向上を理由として大幅に変更されず、そのためコード変更コストが低減されうる。

したがって、本発明の本実施形態のデータ処理方法では、データが信頼されている実行ドメインで記憶されており、そのため、データを使用するプロセスにおいて、平文形式のデータが信頼されていない実行ドメインで表示されることが防止され、攻撃者によるデータの盗み取りを有効に防止することができ、それによってデータセキュリティが向上する。

図1に関連して以上で説明したように、信頼されていない実行ドメインで動作するターゲットアプリケーションも、ターゲットアプリケーションと通信を行うサーバがターゲットアプリケーションによって指定されたサーバであるかどうか検証する。本発明の本実施形態では、第1の識別子を含み、ターゲットアプリケーションによって生成される第1のネットワーク・データ・パケットはサーバへ直接送信されない。代わりに、第1のネットワーク・データ・パケットは、第1のネットワーク・データ・パケットが信頼されている実行ドメインで取得され、第1のネットワーク・データ・パケットに対して特定の処理（例えば、第1の識別子を第1のデータで置き換える処理）が行われた後でターゲットサーバへ送信される。すなわち、本発明では、信頼されていない実行ドメインのターゲットアプリケーションと直接やりとりするのは信頼されている実行ドメイン（例えば、図1に示すセキュリティモジュール）である。したがって、信頼されている実行ドメインと信頼されていない実行ドメインとの間のSSL接続の確立を実施するために信頼されている実行ドメインで証明書が作成される必要がある。図1に示すアーキテクチャを例に取ると、以下のように理解することができる。アプリケーションモジュールによって指定されたターゲットサーバは、信頼されている実行ドメインのセキュリティモジュールの代わりに、アプリケーションモジュールとのSSL接続を確立する。

任意選択で、一実施形態では、ステップS110の信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップよりも前に、本方法は、
信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するステップであって、第2の証明書は第1の証明書と同じ汎用名を有し、第2のルート証明書は信頼されている実行ドメインと信頼されていない実行ドメインとで事前に記憶されている、ステップと、
信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2の証明書および第2のルート証明書に従って第2のセッション鍵を決定するステップであって、第2のセッション鍵は信頼されている実行ドメインと信頼されていない実行ドメインとの間のセッション鍵である、ステップと、
をさらに含み、
信頼されている実行ドメインで、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップは、
第2のセッション鍵を用いて暗号化されている第1のネットワーク・データ・パケットを取得するステップと、
信頼されている実行ドメインで、第2のセッション鍵を用いて暗号化された第1のネットワーク・データ・パケットを復号するステップと、
を含む。

任意選択で、本発明の本実施形態では、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2の証明書および第2のルート証明書に従って第2のセッション鍵を決定するステップは、
信頼されている実行ドメインで生成された第2の証明書を取得するステップと、
信頼されていない実行ドメインで、第2のルート証明書に従って第2の証明書を検証するステップと、
検証に成功したときに第2のセッション鍵を生成し、第2の証明書の公開鍵を用いて第2のセッション鍵を暗号化するステップと、
信頼されている実行ドメインで、第2のセッション鍵を獲得するために、第2の証明書の秘密鍵を用いて暗号化された第2のセッション鍵を復号するステップと、
を含む。

具体的には、図3に示すように、ステップS208で、信頼されている実行ドメインにおいて、ターゲットサーバの識別の検証に成功した後で、（第2の証明書に対応する）証明書2が、信頼されていない実行ドメインで事前に記憶されている（第2のルート証明書に対応する）ルート証明書2（例えば、図1に示す信頼されていない実行ドメインにおけるSSLモジュール1のルート証明書2）を用いて作成される。すなわち、証明書2の署名情報がルート証明書2の秘密鍵を用いて暗号化される。加えて、証明書2の汎用名はターゲットサーバの証明書1（ステップS203参照）の汎用名と同じであり、証明書2も公開鍵を含み、公開鍵に対応する秘密鍵が信頼されている実行ドメインで記憶されている。ステップS209で、証明書2は共用メモリを用いて信頼されていない実行ドメインへ渡され、ステップS210で、証明書2は、信頼されていない実行ドメインにおいて、ルート証明書2を用いて検証される。具体的には、ルート証明書2の公開鍵は証明書2の署名情報を復号し、証明書2の汎用名がターゲットアプリケーションによって指定されたサーバのドメイン名であるかどうか検証するために用いられる。ステップS211で、検証に成功した後で、（本発明の本実施形態では第2のセッション鍵に対応する）（図1に示すSSLモジュール1のセッション鍵1に対応する）セッション鍵2が信頼されていない実行ドメインで生成され、証明書2の公開鍵を用いてセッション鍵2に対して暗号化が行われる。ステップS212で、暗号化されたセッション鍵2は共用メモリを用いて信頼されている実行ドメインへ渡され、ステップS213で、セッション鍵2は、証明書2に含まれる公開鍵に対応する秘密鍵を用いて信頼されている実行ドメインで復号される。この時点で、（図1に示すSSL接続2に対応する）SSL接続2が信頼されていない実行ドメインと信頼されている実行ドメインとの間で確立される。この場合、暗号化に用いられるセッション鍵2は信頼されていない実行ドメインと信頼されている実行ドメインとで知られている。図1に示すように、セッション鍵2はSSLモジュール1とSSLモジュール2の両方に記憶されている。

ステップS210で、証明書2は、信頼されていない実行ドメインで、ルート証明書2を用いて検証されることを理解すべきである。信頼されていない実行ドメインのターゲットアプリケーションについて、証明書2はターゲットアプリケーションのターゲットサーバに属する（証明書2の汎用名は、ターゲットサーバによって提供される証明書1の汎用名と一致する）。加えて、ターゲットアプリケーションにとって、証明書2は信頼されている認証局によって発行された証明書である（証明書2はルート証明書2を用いて署名されており、ルート証明書2は信頼されていない実行ドメインで事前にインストールされており、したがって、ターゲットアプリケーションにとって、ルート証明書2は信頼されている認証局によって発行されたルート証明書に属する）。したがって、ステップS210で、証明書2に関するルート証明書2を用いた検証は成功する。図1を例に取ると、これは、セキュリティモジュールの識別に関するアプリケーションモジュールによる検証が成功すること、としても理解されうる。

本発明の本実施形態では、信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりは、具体的には、例えば図3に示すステップS209およびステップS212で、共用メモリを用いて実施されうることをさらに理解すべきである。信頼されている実行ドメインと信頼されていない実行ドメインとの間のやりとりは別の方法で実施されてもよく、これについては本発明の本実施形態では限定されない。

本発明の本実施形態では、図3に示す証明書1、ルート証明書1、証明書2、およびルート証明書2は、それぞれ、第1の証明書、第1のルート証明書、第2の証明書、および第2のルート証明書に対応することをさらに理解すべきである。

したがって、本発明の本実施形態のデータ処理方法では、ターゲットサーバとのSSL接続が信頼されている実行ドメインで確立され、ターゲットサーバとセキュリティモジュールとの間で通信鍵（第1のセッション鍵）が生成される。第1のデータが通信鍵を用いて暗号化された後で、暗号化された第1のデータはターゲットサーバへ送信され、そのため、平文形式の第1のデータが信頼されていない実行ドメインで表示されることが防止され、攻撃者による第1のデータの盗み取りを有効に防止することができ、これにより送信時に第1のデータのセキュリティを有効に保証することができ、データセキュリティがさらに向上する。

ターゲットサーバによって送信されたネットワーク・データ・パケットが受信されると、ネットワーク・データ・パケットは、信頼されている実行ドメインで、受信ネットワーク・データ・パケットに対する関連処理が行われた後で、信頼されていない実行ドメインで動作するターゲットアプリケーションにも送信されうる。

任意選択で、一実施形態において、図2に示す方法100は、
ターゲットサーバによって送信された、第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するステップと、
信頼されている実行ドメインで、第1のセッション鍵を用いて暗号化された第3のネットワーク・データ・パケットを復号するステップと、
復号された第3のネットワーク・データ・パケットが第1のデータを含むと判定される場合に、第3のネットワーク・データ・パケット、および第1のデータに対応する第1の識別子に従って第4のネットワーク・データ・パケットを生成するステップであって、第4のネットワーク・データ・パケットは第1のデータを含まない、ステップと、
第4のネットワーク・データ・パケットを、信頼されていない実行ドメインで動作するターゲットアプリケーションへ送るステップと、
をさらに含む。

任意選択で、本発明の本実施形態では、第3のネットワーク・データ・パケットは、ターゲットサーバによって第2のネットワーク・データ・パケットに応答するために用いられる応答データパケットである。

具体的には、図4に示すように、ステップS301で、（第1の識別子に対応する）識別子1を含む（第1のネットワーク・データ・パケットに対応する）データパケット1がターゲットアプリケーションを用いて生成され、ステップS302で、データパケット1は共用メモリを用いて信頼されている実行ドメインへ渡され、ステップS303で、対応するユーザ・プライバシ・データが、対応関係、およびデータパケット1に含まれる識別子1に従って信頼されている実行ドメインで決定され、ステップS304で、ユーザ・プライバシ・データを含む（第2のネットワーク・データ・パケットに対応する）データパケット2が生成され、ステップS305で、（第1のセッション鍵に対応する）セッション鍵1を用いて暗号化されているデータパケット2がターゲットサーバへ送信され、ステップS306で、ターゲットサーバはセッション鍵2を用いてデータパケット2を復号し、ステップS307で、ターゲットサーバは、データパケット2に従って応答パケット、すなわち、（第3のネットワーク・データ・パケットに対応する）データパケット3を決定し、ステップS308で、ターゲットサーバは端末へ、セッション鍵を用いて暗号化されているデータパケット3を送信し、ステップS309で、データパケット3はセッション鍵1を用いて信頼されている実行ドメインで復号され、ユーザ・プライバシ・データを含まない（第4のネットワーク・データ・パケットに対応する）データパケット4がデータパケット3に従って決定され、ステップS310で、共用メモリを用いて、（第2のセッション鍵に対応する）セッション鍵2を用いて暗号化されているデータパケット4、ステップS311で、データパケット4はセッション鍵2を用いて信頼されていない実行ドメインで復号され、これによりターゲットアプリケーションはデータパケット4内のデータを用いて対応するアプリケーション動作を行う。例えば、wechatアプリケーションがwechatアプリケーションサーバの応答を受信した後で、ユーザのログイン操作を行うことができる。別の例では、AlipayアプリケーションがAlipayアプリケーションサーバの応答を受信した後で、ユーザの支払い操作、ログイン操作などを行うことができる。

ステップS309で、ユーザ・プライバシ・データを含まないデータパケット4はデータパケット3に従って信頼されている実行ドメインで決定されることを理解すべきである。具体的には、データパケット3がユーザ・プライバシ・データを含まないと判定される場合には、データパケット3はデータパケット4であると直接決定されうる。言い換えると、データパケット3は信頼されていない実行ドメインへ直接渡されうる。データパケット3がユーザ・プライバシ・データを含むと判定される場合には、データパケット4は、データパケット3内のユーザ・プライバシ・データを第1の識別子で置き換えることによって決定されうる。

任意選択で、本発明の本実施形態では、第3のネットワーク・データ・パケットが第1のデータを含まないと判定される場合には、第3のネットワーク・データ・パケットは第4のネットワーク・データ・パケットであると決定される。

したがって、本発明の本実施形態のデータ処理方法では、データが端末の信頼されている実行ドメインで記憶されており、平文形式のデータが、データを使用するプロセスにおいて、端末の信頼されていない実行ドメインで露になることが防止され、そのため、攻撃者によるデータの盗み取りを有効に防止することができ、それによって端末におけるデータのセキュリティが有効に向上する。

加えて、ユーザ・プライバシ・データがアプリケーションで（すなわち、信頼されていない実行ドメインで）記憶される先行技術と比べて、本発明の本実施形態のデータ処理方法では、ユーザ・プライバシ・データは端末の信頼されている実行ドメインで記憶され、ユーザ・プライバシ・データの識別子が信頼されていない実行ドメインで記憶され、これによりユーザ・プライバシ・データのセキュリティが向上するが、端末の性能オーバーヘッドが大きく増えることはない。加えて、サーバを検証するために用いられるルート証明書は信頼されている実行ドメインで記憶されており、これによりサーバの識別を有効に検証し、悪意のあるサーバからの攻撃が有効に防止される。

本発明の本実施形態のデータ処理方法をより理解しやすくするために、以下で、図1に示す構造に関連して、モバイルバンクおよびクレジットカード支払いを例に取って、本発明の本実施形態の具体的実施態様について簡単に説明する。

I．モバイルバンクを例に取り、すなわち、図1に示す端末は携帯電話機であり、信頼されていない実行ドメインのアプリケーションモジュールは具体的にはモバイルバンクであり、アプリケーションサーバはモバイル・バンク・サーバである。
1．SSL接続がモバイルバンクとセキュリティモジュールとの間と、セキュリティモジュールとモバイル・バンク・サーバとの間とで確立され、信頼されているSSLモジュール3はモバイル・バンク・サーバの識別を検証するために用いられる。
2．例えば、ユーザがモバイル・バンク・サーバに対するログイン操作を行うと、モバイルバンクは（アカウントおよびパスワードを含む）記憶されたユーザ・プライバシ・データの第1の識別子を読み取ることができ、第1の識別子および他の情報は、モバイル・バンク・サーバにログインサービスを要求するために用いられる第1のネットワーク・データ・パケットを生成するために用いられ、第1のネットワーク・データ・パケットはセッション鍵2を用いてSSLモジュール1によって暗号化される。
3．セキュリティモジュールは、SSLモジュール2による復号によって獲得され、プロキシモジュール1、共用メモリ、およびプロキシモジュール2によって送られた第1のネットワーク・データ・パケットを受け取り、内部の第1の識別子を（アカウントおよびパスワードを含む）ユーザ・プライバシ・データで置き換え、第2のネットワーク・データ・パケットを生成する。SSLモジュール3はセッション鍵1を用いてSSLモジュール3によって第2のネットワーク・データ・パケットに対する暗号化を行い、次いで暗号化された第2のネットワーク・データ・パケットは、プロキシモジュール2、共用メモリ、プロキシモジュール1、およびネットワークドライバを用いてモバイル・バンク・サーバへ送信される。
4．モバイル・バンク・サーバは第2のネットワーク・データ・パケットの要求を処理し、要求に応答するために用いられる第3のネットワーク・データ・パケットを決定し、セッション鍵1を用いて暗号化されている第3のネットワーク・データ・パケットを携帯電話機へ送信する。
5．第3のネットワーク・データ・パケットは信頼されている実行ドメインでSSLモジュール3によって復号される。
6．信頼されている実行ドメインで、ユーザ・プライバシ・データを含まない第4のネットワーク・データ・パケットが、セキュリティモジュール、SSLモジュール2、プロキシモジュール1、共用メモリ、およびプロキシモジュール2を用いてモバイルバンクへ送られる。

モバイルバンクを用いるプロセスにおいて、平文形式の（アカウントおよびパスワードを含む）ユーザ・プライバシ・データは信頼されていない実行ドメインに対して絶対に露になることがなく、これにより、ユーザのモバイルバンクのパスワードおよびアカウントのセキュリティを有効に保証することができる。加えて、信頼されている実行ドメインで記憶されたセキュアなルート証明書がモバイル・バンク・サーバの信憑性を検証するために用いられ、したがって、悪意をもって偽造されたモバイル・バンク・サーバを識別することができ、それによってユーザ・プライバシ・データのセキュリティがさらに向上する。

II．クレジットカード支払いを例に取り、すなわち、図1に示す端末は携帯電話機であり、信頼されていない実行ドメインのアプリケーションモジュールは具体的には、クレジット・カード・アプリケーション・モジュールであり、アプリケーションサーバはクレジット・カード・アプリケーション・サーバである。

クレジット・カード・アプリケーション・モジュールが、支払いといった操作を行うために、クレジット・カード・アプリケーション・サーバへユーザ・プライバシ・データの第1の識別子（クレジットカード番号）を送信するとき。信頼されている実行ドメインで、クレジット・カード・アプリケーション・モジュールは、第1の識別子をユーザ・プライバシ・データ（クレジットカード番号）で置き換えることができ、次いでユーザ・プライバシ・データをクレジット・カード・アプリケーション・サーバへ送信する。これにより、ユーザのクレジットカード番号のセキュリティを保護して、悪意のあるプログラムによるユーザのクレジットカード番号の盗み取りを防止することができる。具体的説明はモバイルバンクの例と同様であり、簡潔にするために、ここでは詳細を繰り返さない。

したがって、本発明の本実施形態のデータ処理方法では、ユーザ・プライバシ・データが信頼されている実行ドメインで記憶されており、そのため、ユーザ・プライバシ・データを使用するプロセスにおいて、平文形式のユーザ・プライバシ・データが信頼されていない実行ドメインで表示されるのを有効に防止することができ、攻撃者によるユーザ・プライバシ・データの盗み取りを有効に防止することができ、それによってユーザ・プライバシ・データのセキュリティが向上する。

本発明の本実施形態のデータ処理方法において阻むことのできるユーザ・プライバシ・データ攻撃の方法には、それだけに限らないが、以下が含まれる。
1．アプリケーションの脆弱性を利用してアプリケーションに記憶されたユーザ・プライバシ・データを取得する。
2．システムの脆弱性を利用してアプリケーションによって暗号化されたユーザ・プライバシ・データを取得する。性能を考慮して、アプリケーションは一般に、ユーザ・プライバシ・データの単純な暗号化のみを行い、次いでユーザ・プライバシ・データを記憶し、そうした暗号化データは容易に破られる。
3．ユーザ・プライバシ・データを獲得するために、悪意のある信頼されていない暗号化／復号モジュール（例えば、信頼されていない実行ドメインの暗号化モジュール、例えば、図1のSSLモジュール1）を利用して、アプリケーションによって送信／受信される平文形式のすべてのデータを獲得する。

本発明の本実施形態では、平文形式のユーザ・プライバシ・データは信頼されていない実行ドメインでは表示されず、したがって、上述の攻撃をユーザ・プライバシ・データに対して直接仕掛けることによってユーザ・プライバシ・データを取得することはできない。ユーザ・プライバシ・データは、信頼されている暗号化モジュール（例えば、信頼されている実行ドメインの暗号化モジュール、例えば、図1のSSLモジュール3）による暗号化の後で初めて信頼されていない実行ドメインで表示される。しかし、信頼されている暗号化プロトコル（例えばSSLプロトコル）を用いて暗号化されている情報を、現在の技術に基づいて、総当たり攻撃で破るコストは高く、そうした攻撃方法は考慮しなくてもよい。

本発明の本実施形態のデータ処理方法は、攻撃者が端末上に悪意のあるルート証明書をインストールすることによって行われる端末に対する攻撃をさらに阻むことができる。

1．攻撃者は携帯電話機に悪意のあるルート証明書をインストールする。この場合、ルート証明書は、ユーザによって送信される平文形式のすべてのデータを獲得するために、悪意のあるサーバをターゲットアプリケーションのターゲットサーバとして偽造するために用いられうる。

本発明の本実施形態では、信頼されている実行ドメインで記憶されたルート証明書がサーバの識別を検証するために用いられ、攻撃者は信頼されている実行ドメインでいかなる悪意のあるルート証明書もインストールすることができず、したがって、悪意のあるルート証明書をインストールすることによって端末内のユーザ・プライバシ・データを攻撃することができない。

2．悪意のあるルート証明書をインストールするときに、攻撃者は、信頼されていないプロキシが信頼されている実行ドメインのいかなる機能も用いないように、信頼されていないプロキシを攻撃する場合がある。

信頼されている実行ドメインが迂回される場合、攻撃者はアプリケーションによって送信されたすべての情報を盗み取る可能性がある。しかし、アプリケーションによって送信されたすべてのデータは単なる識別子にすぎず、識別子とユーザ・プライバシ・データとの間には内容の点でいかなる関連もなく、したがって、攻撃者はユーザのユーザ・プライバシ・データを取得することができない。

したがって、本発明の本実施形態のデータ処理方法では、ユーザ・プライバシ・データが端末の信頼されている実行ドメインで記憶されており、平文形式のユーザ・プライバシ・データが、ユーザ・プライバシ・データを使用するプロセスにおいて、端末の信頼されていない実行ドメインで露になることが防止され、そのため、攻撃者によるユーザ・プライバシ・データの盗み取りを有効に防止することができ、それによって端末におけるユーザ・プライバシ・データのセキュリティが有効に保護される。

本発明の本実施形態のデータ処理方法は、随時変更される必要のある非常に重要なデータ、例えば注文金額を保護するシナリオにさらに適用されうることを理解すべきである。例えば、信頼されている実行ドメインに入力表示モジュールが追加され、注文金額に関連した情報は、ユーザ・プライバシ・データの処理方法と同じ、または類似した処理方法で信頼されている実行ドメインに、より具体的には、信頼されている実行ドメインのセキュリティモジュールに保存されてよく、これにより、注文情報が改ざんされるのを有効に防止することができる。

本発明の様々な実施形態において、前述のプロセスにおける順序番号の値は実行順序を示すものではなく、各プロセスの実行順序は各プロセスの機能および内部論理によって決定され、本発明の実施形態の実施プロセスに対するいかなる限定も構成するものではないことを理解すべきである。

したがって、本発明の本実施形態のデータ処理方法では、ユーザ・プライバシ・データが信頼されている実行ドメインで記憶されており、そのため、ユーザ・プライバシ・データを使用するプロセスにおいて、平文形式のユーザ・プライバシ・データが信頼されていない実行ドメインで表示されるのを有効に防止することができ、攻撃者によるユーザ・プライバシ・データの盗み取りを有効に防止することができ、それによってユーザ・プライバシ・データのセキュリティが向上する。

以上では、図1から図4に関連して本発明の実施形態によるデータ処理方法について詳細に説明した。以下では、図5に関連して本発明の実施形態によるデータ処理装置について詳細に説明する。

図5に、本発明の一実施形態によるデータ処理装置400の概略的ブロック図を示す。図5に示すように、本装置は、
信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するように構成された第1の取得モジュール410であって、第1のネットワーク・データ・パケットは第1の識別子を含む、第1の取得モジュール410と、
信頼されている実行ドメインで、第1の取得モジュール410によって取得された第1のネットワーク・データ・パケット内の第1の識別子に対応する第1のデータを取得するように構成された第2の取得モジュール420であって、第1のデータはターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、第2の取得モジュール420と、
信頼されている実行ドメインで、第1のネットワーク・データ・パケット、および第2の取得モジュール420によって取得された第1のデータに従って第2のネットワーク・データ・パケットを生成するように構成された第1の生成モジュール430と、
暗号化された第2のネットワーク・データ・パケットを取得するために、信頼されている実行ドメインで、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて、第1の生成モジュール430によって生成された第2のネットワーク・データ・パケットの暗号化を行うように構成された暗号化モジュール440と、
暗号化モジュール440によって取得された暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成された第1の送信モジュール450と、
を含む。

したがって、本発明の本実施形態のデータ処理装置を用いれば、データは信頼されている実行ドメインで記憶されており、データ暗号化鍵も信頼されている実行ドメインで記憶されており、これによりデータセキュリティを向上させることができる。

任意選択で、一実施形態において、本装置は、
ターゲットサーバによって送信された、第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するように構成された受信モジュールと、
信頼されている実行ドメインで、第1のセッション鍵を用いて、受信モジュールによって受信された暗号化された第3のネットワーク・データ・パケットを復号し、復号された第3のネットワーク・データ・パケットが第1のデータを含むと判定される場合に、第3のネットワーク・データ・パケット、および第1のデータに対応する第1の識別子に従って第4のネットワーク・データ・パケットを生成するように構成された処理モジュールであって、第4のネットワーク・データ・パケットは第1のデータを含まない、処理モジュールと、
処理モジュールによって生成された第4のネットワーク・データ・パケットを信頼されていない実行ドメインで動作するターゲットアプリケーションへ送るように構成された第2の送信モジュールと、
をさらに含む。

任意選択で、一実施形態において、本装置は、
第1の取得モジュール410が、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、信頼されている実行ドメインで、ターゲットサーバとのセキュア・ソケット・レイヤSSL接続を確立し、第1のセッション鍵を決定するように構成された第1の確立モジュールであって、第1のセッション鍵は、ターゲットサーバの第1の証明書に関する、信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、第1の証明書はターゲットサーバの識別を証明するために用いられる、第1の確立モジュール、
をさらに含む。

任意選択で、一実施形態において、本装置は、
第1の取得モジュール410が、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するように構成された第2の生成モジュールであって、第2の証明書は第1の証明書と同じ汎用名を有し、第2のルート証明書は信頼されている実行ドメインと信頼されていない実行ドメインとで事前に記憶されている、第2の生成モジュールと、
第2のルート証明書、および第2の生成モジュールによって生成された第2の証明書に従って、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、第2のセッション鍵を決定するように構成された第2の確立モジュールであって、第2のセッション鍵は信頼されている実行ドメインと信頼されていない実行ドメインとの間のセッション鍵である、第2の確立モジュールと、
さらに含み、
第1の取得モジュール410は、
第2のセッション鍵を用いて暗号化されている第1のネットワーク・データ・パケットを取得するように構成された第1の取得部と、
信頼されている実行ドメインで、第2のセッション鍵を用いて、第1の取得部によって取得された暗号化された第1のネットワーク・データ・パケットを復号するように構成された復号部と、
を含む。

任意選択で、一実施形態において、第2の確立モジュールは、
信頼されている実行ドメインで生成された第2の証明書を取得するように構成された第2の取得部と、
信頼されていない実行ドメインで、第2のルート証明書に従って、第2の取得部によって取得された第2の証明書を検証し、検証に成功した場合に第2のセッション鍵を生成し、第2の証明書の公開鍵を用いて第2のセッション鍵を暗号化するように構成された処理部と、
第2のセッション鍵を獲得するために、信頼されている実行ドメインで、第2の証明書の秘密鍵を用いて、処理部によって暗号化された第2のセッション鍵を復号するように構成された復号部と、
を含む。

任意選択で、一実施形態において、第1の送信モジュールは、
共用メモリを用いて信頼されていない実行ドメインへ暗号化された第2のネットワーク・データ・パケットを渡すように構成された受渡し部と、
信頼されていない実行ドメインで、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成された送信部と、
を含む。

本発明の本実施形態によるデータ処理装置400は、本発明の実施形態のデータ処理方法における端末、例えば、図1に示す端末に対応しうるものであり、装置400内の各モジュールの上記その他の動作および／または機能は、それぞれ、ここでは簡潔にするためにその説明を繰り返さないが、図1から図4の方法の対応する手順を実現するために用いられることを理解すべきである。

したがって、本発明の本実施形態のデータ処理装置を用いれば、データは信頼されている実行ドメインで記憶されており、データ暗号化鍵も信頼されている実行ドメインで記憶されており、これによりデータセキュリティを向上させることができる。

図6に示すように、本発明の一実施形態はネットワークデバイス500をさらに提供し、ネットワークデバイス500は、プロセッサ510と、メモリ520と、バスシステム530と、受信機540と、送信機550とを含む。プロセッサ510、メモリ520、受信機540、および送信機550はバスシステム530を用いて接続されており、メモリ520は命令を記憶するように構成されており、プロセッサ510は、メモリ520によって記憶された命令を実行し、信号を受信するように受信機540を制御し、信号を送信するように送信機550を制御するように構成されている。プロセッサ510は、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された、第1の識別子を含む第1のネットワーク・データ・パケットを取得し、信頼されている実行ドメインで、ターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、第1の識別子に対応する第1のデータを取得し、信頼されている実行ドメインで、第1のネットワーク・データ・パケット、および第2の取得モジュールによって取得された第1のデータに従って第2のネットワーク・データ・パケットを生成し、暗号化された第2のネットワーク・データ・パケットを取得するために、信頼されている実行ドメインで、ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて、第1の生成モジュールによって生成された第2のネットワーク・データ・パケットの暗号化を行う、ように構成されており、送信機550は、暗号化モジュールによって取得された暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成されている。

したがって、本発明の本実施形態のデータ処理装置を用いれば、データは信頼されている実行ドメインで記憶されており、データ暗号化鍵も信頼されている実行ドメインで記憶されており、これによりデータセキュリティを向上させることができる。

任意選択で、一実施形態において、受信機540は、ターゲットサーバによって送信され、第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するように構成されており、プロセッサ510は、信頼されている実行ドメインで、第1のセッション鍵を用いて、受信機540によって受信された暗号化された第3のネットワーク・データ・パケットを復号し、復号された第3のネットワーク・データ・パケットが第1のデータを含むと判定される場合に、第3のネットワーク・データ・パケット、および第1のデータに対応する第1の識別子に従って第4のネットワーク・データ・パケットを生成するように構成されており、第4のネットワーク・データ・パケットは第1のデータを含まず、送信機550は、第4のネットワーク・データ・パケットを信頼されていない実行ドメインで動作するターゲットアプリケーションへ送るように構成されている。

任意選択で、一実施形態において、プロセッサ510は、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、ターゲットサーバとのセキュア・ソケット・レイヤSSL接続を確立し、第1のセッション鍵を決定するように構成されており、第1のセッション鍵は、ターゲットサーバの第1の証明書に対する、信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、第1の証明書はターゲットサーバの識別を証明するために用いられる。

任意選択で、一実施形態において、プロセッサ510は、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前に、信頼されている実行ドメインで、信頼されている実行ドメインと信頼されていない実行ドメインとで事前に記憶されている、第2のルート証明書に従って、第1の証明書と同じ汎用名を有する、第2の証明書を生成し、第2のルート証明書、および第2の生成モジュールによって生成された第2の証明書に従って、信頼されている実行ドメインと信頼されていない実行ドメインとの間でSSL接続を確立し、信頼されている実行ドメインと信頼されていない実行ドメインとの間のセッション鍵である、第2のセッション鍵を決定し、第2のセッション鍵を用いて暗号化されている第1のネットワーク・データ・パケットを取得し、信頼されている実行ドメインで、第2のセッション鍵を用いて、暗号化された第1のネットワーク・データ・パケットを復号するように構成されている。

任意選択で、一実施形態において、プロセッサ510は、信頼されている実行ドメインで生成された第2の証明書を取得し、信頼されていない実行ドメインで、第2のルート証明書に従って第2の証明書を検証し、検証に成功した場合に第2のセッション鍵を生成し、第2の証明書の公開鍵を用いて第2のセッション鍵を暗号化し、第2のセッション鍵を獲得するために、信頼されている実行ドメインで、第2の証明書の秘密鍵を用いて、処理部によって暗号化された第2のセッション鍵を復号するように構成されている。

任意選択で、一実施形態において、プロセッサ510は、共用メモリを用いて暗号化された第2のネットワーク・データ・パケットを信頼されていない実行ドメインへ渡すように構成されている。

送信機550は、信頼されていない実行ドメインで、暗号化された第2のネットワーク・データ・パケットをターゲットサーバへ送信するように構成されている。

本発明の本実施形態では、プロセッサ510は中央処理装置（Central Processing Unit、略称「CPU」）とすることもでき、あるいはプロセッサ510は別の汎用プロセッサ、ディジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールド・プログラマブル・ゲート・アレイ（FPGA）、または別のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理デバイス、ディスクリートハードウェア部品などとすることもできることを理解すべきである。汎用プロセッサはマイクロプロセッサとすることもでき、プロセッサは任意の従来のプロセッサとすることもできる。

メモリ520は、読取り専用メモリおよびランダム・アクセス・メモリを含んでいてよく、プロセッサ510のための命令およびデータを提供する。メモリ520の一部は、不揮発性ランダム・アクセス・メモリ（NVRAM）をさらに含んでいてよい。例えば、メモリ520はデバイスの種類に関する情報をさらに記憶することができる。

データバスに加えて、バスシステム530は、電源バス、制御バス、状況信号バスなどをさらに含んでいてよい。しかし、説明を明確にするために、図では様々な種類のバスがバスシステム530として記されている。

一実施プロセスにおいて、前述の方法の各ステップは、プロセッサ510においてハードウェアの集積論理回路を用いて、またはソフトウェアの形態の命令を用いて完了されうる。本発明の各実施形態に関連して開示した方法のステップは、ハードウェアプロセッサによって直接実行され、完了されてもよく、プロセッサにおいてハードウェアモジュールとソフトウェアモジュールの組み合わせを用いて実行され、完了されてもよい。ソフトウェアモジュールは、ランダム・アクセス・メモリ、フラッシュメモリ、読取り専用メモリ、プログラマブル読取り専用メモリ、電気的消去書込み可能メモリ、レジスタといった、当分野の成熟した記憶媒体に位置していてよい。記憶媒体はメモリ520に位置し、プロセッサ510はメモリ520内の情報を読み取り、プロセッサ510のハードウェアと組み合わさって前述の方法の各ステップを完了する。反復を避けるために、ここでは詳細を繰り返さない。

本発明の本実施形態によるデータ処理装置500は、本発明の実施形態のデータ処理装置400に対応するものであってもよく、本発明の一実施形態のデータ処理端末に対応するものであってもよく、装置500内のモジュールの上記その他の動作および／または機能は、それぞれ、図1から図4の方法の対応する手順を実現するために用いられ、ここでは簡潔にするためのそれらの説明を繰り返さないことをさらに理解すべきである。

したがって、本発明の本実施形態のデータ処理装置を用いれば、データは信頼されている実行ドメインで記憶されており、データ暗号化鍵も信頼されている実行ドメインで記憶されており、これによりデータセキュリティを向上させることができる。

本明細書における「および／または」という用語は、関連付けられる対象を記述するための結合関係を記述するにすぎず、3つの関係が存在しうることを表す。例えば、Aおよび／またはBは、Aのみが存在する、AとBの両方が存在する、およびBのみが存在する、という3つの場合を表すことができる。加えて、本明細書における文字「／」は一般に、関連付けられる対象間の「または」の関係を示す。

本発明の様々な実施形態において、前述のプロセスにおける順序番号の値は実行順序を示すものではなく、各プロセスの実行順序は各プロセスの機能および内部論理によって決定され、本発明の実施形態の実施プロセスに対するいかなる限定も構成するものではないことを理解すべきである。

本明細書で開示される実施形態において記述される例と組み合わせて、各ユニットおよびアルゴリズムステップを電子ハードウェアによって、またはコンピュータソフトウェアと電子ハードウェアの組み合わせによって実現することができることを、当業者は理解するであろう。各機能が果たされるのがハードウェアによってか、それともソフトウェアによってかは、技術的解決策の個々の用途および設計上の制約条件に依存する。当業者は、様々な方法を使用して個々の用途ごとに記述された機能を実現することができるが、そうした実施態様は本発明の範囲を超えるものとみなすべきではない。

説明を簡便にするために、前述のシステム、装置、およびユニットの詳細な作動プロセスについては、前述の方法実施形態における対応するプロセスを参照してよいことを当業者は明確に理解することができ、ここでは詳細を繰り返さない。

本出願で提供されるいくつかの実施形態においては、開示のシステム、装置、および方法を他のやり方で実現することもできることを理解すべきである。例えば、説明された装置実施形態は単なる例示にすぎない。例えば、ユニット分割は単なる論理的機能分割にすぎず、実際の実装に際しては他の分割とすることもできる。例えば、複数のユニットまたはコンポーネントが組み合わされ、または統合されて別のシステムになる場合もあり、ある機能が無視され、または実行されない場合もある。加えて、表示された、または論じられた相互結合または直接結合または通信接続を、いくつかのインターフェースを介して実現することもできる。装置間またはユニット間の間接結合または通信接続は、電子的形態、機械的形態、または他の形態として実現することができる。

別々の部品として記述されたユニットは物理的に分離している場合もそうでない場合もあり、ユニットとして表示された部品は、物理的ユニットである場合もそうでない場合もあり、一箇所に位置する場合もあり、複数のネットワークユニット上に分散される場合もある。ユニットの一部または全部を、各実施形態の解決策の目的を達成するための実際の必要に従って選択することもできる。

加えて、本発明の各実施形態における機能ユニットが1つの処理部へ統合される場合もあり、ユニットの各々が物理的に独立して存在する場合もあり、または2つ以上のユニットが1つのユニットへ統合される。

各機能がソフトウェア機能ユニットの形態で実現され、独立した製品として販売され、または使用される場合に、それらの機能は、コンピュータ可読記憶媒体に記憶することができる。そうした理解に基づき、本発明の技術的解決策を本質的に、または先行技術に寄与する部分を、または技術的解決策の一部を、ソフトウェア製品の形態で実現することができる。ソフトウェア製品は記憶媒体に記憶されており、（パーソナルコンピュータ、サーバ、またはネットワークデバイスとすることができる）コンピュータデバイスに、本発明の各実施形態で記述されている方法のステップの全部または一部を実行するよう命令するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、取り外し可能ハードディスク、読取り専用メモリ（ROM、Read-Only Memory）、ランダム・アクセス・メモリ（RAM、Random Access Memory）、磁気ディスク、光ディスクといった、プログラムコードを記憶することができる任意の媒体を含む。

以上の説明は、単に、本発明の具体的実施態様であるにすぎず、本発明の保護範囲を限定するためのものではない。本発明で開示される技術範囲内で当業者によって容易に考案されるいかなる変形も置換も、本発明の保護範囲内に含まれるものとする。したがって、本発明の保護範囲は、特許請求の範囲の保護範囲に従うべきものとする。

400 データ処理装置
410 第1の取得モジュール
420 第2の取得モジュール
430 第1の生成モジュール
440 暗号化モジュール
450 第1の送信モジュール
500 データ処理装置
510 プロセッサ
520 メモリ
530 バスシステム
540 受信機
550 送信機

Claims (12)

1. 信頼されている実行ドメインと信頼されていない実行ドメインとを含むデータ処理装置におけるデータ処理方法であって、
   前記信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するステップであって、前記信頼されていない実行ドメインは非セキュアな実行ドメインであり、前記第1のネットワーク・データ・パケットは第1の識別子を含む、ステップと、
   前記信頼されている実行ドメインで、前記第1の識別子を、前記第1の識別子に対応する第1のデータに置き換えるステップであって、前記信頼されている実行ドメインはセキュアな実行ドメインであり、前記第1のデータは前記ターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、ステップと、
   前記信頼されている実行ドメインで、前記第1のデータおよび前記第1のネットワーク・データ・パケットに従って第2のネットワーク・データ・パケットを生成するステップと、
   前記信頼されている実行ドメインで、前記ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて前記第2のネットワーク・データ・パケットの暗号化を行い、暗号化された第2のネットワーク・データ・パケットを取得するステップと、
   前記暗号化された第2のネットワーク・データ・パケットを前記ターゲットサーバへ送信するステップと、
   を含む方法。
2. 前記ターゲットサーバによって送信された、前記第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するステップと、
   前記信頼されている実行ドメインで、前記第1のセッション鍵を用いて、暗号化された前記第3のネットワーク・データ・パケットを復号するステップと、
   復号された前記第3のネットワーク・データ・パケットが前記第1のデータを含むと判定される場合に、前記第3のネットワーク・データ・パケット、および前記第1のデータに対応する前記第1の識別子に従って第4のネットワーク・データ・パケットを生成するステップであって、前記第4のネットワーク・データ・パケットは前記第1のデータを含まない、ステップと、
   前記第4のネットワーク・データ・パケットを前記信頼されていない実行ドメインで動作する前記ターゲットアプリケーションへ送るステップと、
   をさらに含む、請求項1に記載の方法。
3. 信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前記ステップよりも前に、
   前記信頼されている実行ドメインで、前記ターゲットサーバとのセキュア・ソケット・レイヤ（SSL）接続を確立するステップと、
   前記第1のセッション鍵を決定するステップであって、前記第1のセッション鍵は、前記ターゲットサーバの第1の証明書に関する、前記信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、前記第1の証明書は前記ターゲットサーバの識別を証明するために用いられる、ステップと、
   をさらに含む、請求項1または2に記載の方法。
4. 信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前記ステップよりも前に、
   前記信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するステップであって、前記第2の証明書は前記第1の証明書と同じ汎用名を有し、前記第2のルート証明書は前記信頼されている実行ドメインと前記信頼されていない実行ドメインとで事前に記憶されている、ステップと、
   前記第2の証明書および前記第2のルート証明書に従って、前記信頼されている実行ドメインと前記信頼されていない実行ドメインとの間で前記SSL接続を確立し、第2のセッション鍵を決定するステップであって、前記第2のセッション鍵は前記信頼されている実行ドメインと前記信頼されていない実行ドメインとの間のセッション鍵である、ステップと、
   をさらに含み、
   信頼されている実行ドメインで、信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得する前記ステップは、
   前記第2のセッション鍵を用いて暗号化されている前記第1のネットワーク・データ・パケットを取得するステップと、
   前記信頼されている実行ドメインで、前記第2のセッション鍵を用いて、暗号化された前記第1のネットワーク・データ・パケットを復号するステップと、
   を含む、請求項3に記載の方法。
5. 前記信頼されている実行ドメインと前記信頼されていない実行ドメインとの間で前記SSL接続を確立し、前記第2の証明書および前記第2のルート証明書に従って第2のセッション鍵を決定する前記ステップは、
   前記信頼されている実行ドメインで生成された前記第2の証明書を取得するステップと、
   前記信頼されていない実行ドメインで、前記第2のルート証明書に従って前記第2の証明書を検証するステップと、
   検証に成功した場合に前記第2のセッション鍵を生成するステップと、
   前記第2の証明書の公開鍵を用いて前記第2のセッション鍵を暗号化するステップと、
   前記信頼されている実行ドメインで、前記第2の証明書の秘密鍵を用いて、暗号化された前記第2のセッション鍵を復号し、前記第2のセッション鍵を獲得するステップと、
   を含む、請求項4に記載の方法。
6. 前記暗号化された第2のネットワーク・データ・パケットを前記ターゲットサーバへ送信する前記ステップは、
   共用メモリを用いて前記信頼されていない実行ドメインへ前記暗号化された第2のネットワーク・データ・パケットを渡すステップと、
   前記信頼されていない実行ドメインで、前記暗号化された第2のネットワーク・データ・パケットを前記ターゲットサーバへ送信するステップと、
   を含む、請求項1から5のいずれか一項に記載の方法。
7. 信頼されている実行ドメインと信頼されていない実行ドメインとを含むデータ処理装置であって、
   前記信頼されていない実行ドメインで動作するターゲットアプリケーションによって送信された第1のネットワーク・データ・パケットを取得するように構成された第1の取得モジュールであって、前記信頼されていない実行ドメインは非セキュアな実行ドメインであり、前記第1のネットワーク・データ・パケットは第1の識別子を含む、第1の取得モジュールと、
   前記信頼されている実行ドメインで、前記第1の取得モジュールによって取得された前記第1のネットワーク・データ・パケット内の前記第1の識別子を、前記第1の識別子に対応する第1のデータに置き換えるように構成された第2の取得モジュールであって、前記信頼されている実行ドメインはセキュアな実行ドメインであり、前記第1のデータは前記ターゲットアプリケーションがターゲットサーバにサービスを要求するために必要なデータである、第2の取得モジュールと、
   前記信頼されている実行ドメインで、前記第1のネットワーク・データ・パケット、および前記第2の取得モジュールによって置き換えられた前記第1のデータに従って第2のネットワーク・データ・パケットを生成するように構成された第1の生成モジュールと、
   前記信頼されている実行ドメインで、前記ターゲットサーバとの事前折衝によって決定された第1のセッション鍵を用いて、前記第1の生成モジュールによって生成された前記第2のネットワーク・データ・パケットの暗号化を行い、暗号化された第2のネットワーク・データ・パケットを取得するように構成された暗号化モジュールと、
   前記暗号化モジュールによって取得された前記暗号化された第2のネットワーク・データ・パケットを前記ターゲットサーバへ送信するように構成された第1の送信モジュールと、
   を含む装置。
8. 前記ターゲットサーバによって送信された、前記第1のセッション鍵を用いて暗号化されている第3のネットワーク・データ・パケットを受信するように構成された受信モジュールと、
   前記信頼されている実行ドメインで、前記第1のセッション鍵を用いて、前記受信モジュールによって受信された暗号化された前記第3のネットワーク・データ・パケットを復号し、復号された前記第3のネットワーク・データ・パケットが前記第1のデータを含むと判定される場合に、前記第3のネットワーク・データ・パケット、および前記第1のデータに対応する前記第1の識別子に従って第4のネットワーク・データ・パケットを生成するように構成された処理モジュールであって、前記第4のネットワーク・データ・パケットは前記第1のデータを含まない、処理モジュールと、
   前記処理モジュールによって生成された前記第4のネットワーク・データ・パケットを前記信頼されていない実行ドメインで動作する前記ターゲットアプリケーションへ送るように構成された第2の送信モジュールと、
   をさらに含む、請求項7に記載の装置。
9. 前記第1の取得モジュールが前記信頼されていない実行ドメインで動作する前記ターゲットアプリケーションによって送信された前記第1のネットワーク・データ・パケットを取得する前に、前記信頼されている実行ドメインで、前記ターゲットサーバとのセキュア・ソケット・レイヤ（SSL）接続を確立し、前記第1のセッション鍵を決定するように構成された第1の確立モジュールであって、前記第1のセッション鍵は、前記ターゲットサーバの第1の証明書に関する、前記信頼されている実行ドメインで事前に記憶されている第1のルート証明書を用いた検証に成功した後で生成されるセッション鍵であり、前記第1の証明書は前記ターゲットサーバの識別を証明するために用いられる、第1の確立モジュール、
   をさらに含む、請求項7または8に記載の装置。
10. 前記第1の取得モジュールが前記信頼されていない実行ドメインで動作する前記ターゲットアプリケーションによって送信された前記第1のネットワーク・データ・パケットを取得する前に、前記信頼されている実行ドメインで、第2のルート証明書に従って第2の証明書を生成するように構成された第2の生成モジュールであって、前記第2の証明書は前記第1の証明書と同じ汎用名を有し、前記第2のルート証明書は前記信頼されている実行ドメインと前記信頼されていない実行ドメインとで事前に記憶されている、第2の生成モジュールと、
    前記第2のルート証明書、および前記第2の生成モジュールによって生成された前記第2の証明書に従って、前記信頼されている実行ドメインと前記信頼されていない実行ドメインとの間で前記SSL接続を確立し、第2のセッション鍵を決定するように構成された第2の確立モジュールであって、前記第2のセッション鍵は前記信頼されている実行ドメインと前記信頼されていない実行ドメインとの間のセッション鍵である、第2の確立モジュールと、
    さらに含み、
    前記第1の取得モジュールは、
    前記第2のセッション鍵を用いて暗号化されている前記第1のネットワーク・データ・パケットを取得するように構成された第1の取得部と、
    前記信頼されている実行ドメインで、前記第2のセッション鍵を用いて、前記第1の取得部によって取得された暗号化された前記第1のネットワーク・データ・パケットを復号するように構成された復号部と、
    を含む、請求項9に記載の装置。
11. 前記第2の確立モジュールは、
    前記信頼されている実行ドメインで生成された前記第2の証明書を取得するように構成された第2の取得部と、
    前記信頼されていない実行ドメインで、前記第2のルート証明書に従って、前記第2の取得部によって取得された前記第2の証明書を検証し、検証に成功した場合に前記第2のセッション鍵を生成し、前記第2の証明書の公開鍵を用いて前記第2のセッション鍵を暗号化するように構成された処理部と、
    前記信頼されている実行ドメインで、前記第2の証明書の秘密鍵を用いて、前記処理部によって暗号化された前記第2のセッション鍵を復号し、前記第2のセッション鍵を獲得するように構成された復号部と、
    を含む、請求項10に記載の装置。
12. 前記第1の送信モジュールは、
    共用メモリを用いて前記信頼されていない実行ドメインへ前記暗号化された第2のネットワーク・データ・パケットを渡すように構成された受渡し部と、
    前記信頼されていない実行ドメインで、前記暗号化された第2のネットワーク・データ・パケットを前記ターゲットサーバへ送信するように構成された送信部と、
    を含む、請求項7から11のいずれか一項に記載の装置。

Images