JP4959473B2 - コンピュータの画面の情報を保護するシステム - Google Patents

Description

この発明は、一般的には、コンピュータのセキュリティ管理に関し、より詳しくは、コンピュータに接続された画面における出力情報を保護するための技術に関するものである。

近年、コンプライアンス強化や個人情報保護のために、コンピュータリソースに対するアクセス制御をきめ細かく行う必要性が増大している。そのために、機密情報を含んだファイルへのアクセス制御や、クリップボードやプロセス間通信を介した機密情報のフロー制御を行う様々な方法が実用化されている。

しかし、ファイルのアクセス権やクリップボードの情報の管理をするだけでは、情報の最終的な出力デバイスである画面上の情報セキュリティ管理を効果的に行うことはできない。

すなわち、画面上に出力された画像データを保護するための確実な手法がないと、折角、機密情報を含んだファイルそのもののアクセス権を設定しても、機密情報を含んだ画面上ののデータを、どのプロセスからでも自由に読み込みを許してしまうことになる。

VMWareやVirtual PCなどのコンピュータ仮想技術により、ゲストＯＳ間の画面情報の隔離を行うことは可能である。しかし、この技術では、ホストＯＳからはゲストＯＳの画面を自由に読むことを許してしまうため、ホストＯＳに悪意あるソフトウェアが潜んでいると、ゲストＯＳの画面上の機密情報が不正に持ち出される危険性を防ぎきれない。

また、ＮＳＡ（米国国家安全保障局）のSecured X Window Systemは、独立した仮想デスクトップ画面上に機密情報を表示することで、他のデスクトップ画面内のプロセスと、画面を分離することを可能ならしめる。但し、この技術では、ビデオメモリ上の画像データは保護されないので、バックグラウンドプロセスが自由に画像情報を読み取ることを許してしまう。

特開平１１−２４９９６５は、ビデオメモリに格納したビデオデータに従ってディスプレイ装置の表示画面上に表示処理を行なうコンピュータシステムにおいて、表示画面上に表示するウインドウ単位の画面情報を管理するためのウインドウ管理テーブルを設け、ウインドウ単位の画面情報の表示指示に応じてウインドウ管理テーブルを更新すると共に、当該画面情報のコピー処理のプロテクトを指示するためのコピープロテクト情報を前記ウインドウ管理テーブルに設定し、表示画面上に表示処理されたウインドウ単位の画面情報に対するコピー要求を受けたときに、ウインドウ管理テーブルを参照してコピー要求対象の画面情報に対してコピープロテクト情報が設定されている場合にはビデオメモリから画面情報に対応するビデオデータのコピー処理を禁止するようにすることを開示する。

特開２００７−３４６８５は、電子ペーパに表示する各コンテンツの機密性保持等を実現するためのシステムであって、このシステムは、利用制限記憶手段をもち、この利用制限記憶手段がコンテンツ毎の利用制限情報を保持し、表示制御手段が表示部へコンテンツの表示内容を利用制限情報に応じた態様で書き込む。そうして、利用制限情報に応じて、表示部に表示するドキュメント中の或るコンテンツを表示する又は表示しない等の態様とすることにより、コンテンツの機密性保持や同一性維持等をコンテンツの利用を制限することで実現する。また、ユーザからの確認要求に応じて、利用制限記憶手段に保持した利用制限情報を表示部２に書き込んでユーザに提示する。

特開２００７−５２６５５は、予め規定されている範囲内に立ち入る利用者に関連付けられている認証情報を取得する手段と、前記取得された認証情報が、前記ドキュメントに関連付けられている表示許可条件を満たすか否かを判断する手段と、前記認証情報が前記表示許可条件を満たさない場合に、前記ドキュメントの前記表示部への表示を制限する制限手段と、を含むドキュメント表示制御装置を開示する。

特開２００７−６５８４６は、本出願人と同一の出願人に係る発明であり、オペレーティングシステム上で第１および第２アプリケーションプログラムを含む複数のアプリケーションプログラムを並行に動作させる情報処理装置であって、第１アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、または、第１アプリケーションプログラムおよびオペレーティングシステム間で送受信されるメッセージを監視する監視部と、監視部による監視結果に基づいて、第２アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、若しくは、第２アプリケーションプログラムおよびオペレーティングシステム間のメッセージ送受信の処理を変更または禁止する制御部とを備える情報処理装置を開示する。本願発明の１つの背景技術として参考までに示す。

これらの従来技術によれば、特定の目的に対しては、有効に画面のセキュリティ保護が達成される。しかし、これらの従来技術では、最近になって、ＧＵＩ環境で採用されつつある半透明ウインドウに適切に対処できないし、表示されている文字列情報やフォントサイズなどに応じた、柔軟なセキュリティ管理も難しい。
特開平１１−２４９９６５ 特開２００７−３４６８５ 特開２００７−５２６５５ 特開２００７−６５８４６

この発明は、上記問題点を解決するためになされたものであり、表示されるウインドウの属性、描画結果などを考慮して、柔軟且つ効果的な表示情報のセキュリティ管理を実現することを可能とする技術を提供ことを目的とする。

上記目的は、マルチウインドウ・システムなどのグラフィック・ユーザ・インターフェースをもつコンピュータ・システムにおいて、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、好適には画像処理などの複雑なステップを経ないで、描画命令の論理演算パターンから判断し、それと同時に、画面やメモリ上の画像と一対一に対応するラベル付けされた領域マップを管理することで、画面に出力された画像の情報フロー制御を実施することによって、達成される。

本発明は、各プロセスによるグラフィクスデバイスへの描画命令実行を検出する描画命令実行検出部と、前記描画命令実行検出部が検出した描画命令の種別およびパラメータを解析することにより描画命令実行後の画像状態を判定する描画命令解析部と、描画命令解析部の判定結果に基づき描画領域にラベル付けを行うラベル割り当て部と、画面およびオフスクリーンバッファのラベルを管理するラベルマップ管理部と、実際に描画命令を実行する描画命令実行部と、さらに、描画命令実行検出部が画面またはオフスクリーンバッファからの画像読み込みを検出したときに、読み込み元領域のラベルに応じて読み込み元の画像を処理する画像処理制御部で構成される。

本発明によれば、先ず、各プロセス内に監視モジュールが常駐させられる。そうして、監視モジュールは、プロセスによるグラフィックスデバイスに対する描画命令を監視する。

監視モジュールは、プロセスが画像データを書き込む際に、描画プロセスの属性や描画命令の内容に応じて、描画領域に対してセキュリティラベルを割り当てる。描画領域には、画面上の可視領域のほかに、オフスクリーンバッファ上の不可視領域も含む。本発明は、ここで、描画命令種別およびパラメータを解析し、描画領域の既存画像（Destination）、描画演算の処理対象画像(Source)、パラメータで指定された画像要素(Pattern)の論理演算の結果、描画命令実行後にどの画像情報が残されるかを判定し、その結果に応じてセキュリティラベルを割り当てる。

一方、監視モジュールは、プロセスが画面上またはオフスクリーンバッファ上の画像データを読み込む際に、プロセスのセキュリティラベルと、読み込もうとする画面領域のセキュリティラベルとを比較し、読み込み命令の可否を判定する。画面領域のセキュリティラベルが、読み込みプロセスのセキュリティラベルより高い場合は、読み込み命令を失敗させるか、あるいは、領域内の画像情報が、セキュリティラベルの低いプロセスに伝わらないように、墨塗りやマスク処理した画像データを返す。

本発明により、画面上に出力された機密情報は、適切なセキュリティラベルを割り当てたプロセスしか読み出せなくなるため、悪意あるプログラムや一般プログラムは、画面上の機密情報画像を取得できない。その結果、画面スナップショットを取得されて機密情報が漏洩する危険性が避けられる。

この発明によれば、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、描画命令の論理演算パターンから判断して、アクセス制御するので、悪意あるプログラムや一般プログラムからの画面上の機密情報画像へのアクセスを効果的に禁止できるとともに、半透明ウインドウなどの場合にも、適切なセキュリティラベルを割り当てることによって、柔軟にアクセス制御を行うことができる。

以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。

図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・パス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ビデオメモリ（ＶＲＡＭ）１０８と、ハードディスク・ドライブ（ＨＤＤ）１１０と、キーボード１１２と、マウス１１４と、ディスプレイ１１６が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標） ４、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１０６は、好適には、５１２ＫＢ以上の容量をもつものである。ビデオメモリ１０８は、ディスプレイ１１６に画面出力するためのイメージを保持するために使用される。

ハードディスク・ドライブ１１０には、個々に図示しないが、オペレーティング・システム及び本発明に係る処理プログラム、及びそのワードプロセッサ、表計算プログラム、プレゼンテーション作成プログラム、データベース・プログラムなどのアプリケーション・プログラムが、予め格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃ ＯＳ（商標）などの、マルチウインドウのグラフィック・ユーザー・インターフェースをサポートし、ＣＰＵ１０４に適合する任意のものでよい。なお、以下の説明では、便宜上、オペレーティング・システムとして、Ｗｉｎｄｏｗｓ ＸＰ（商標）を使用し、ＡＰＩとしてＷｉｎ３２ ＡＰＩを使用するものとして説明する。しかし、この分野の当業者なら、Ｌｉｎｕｘ（商標）などの他のオペレーティング・システムでも、同等のＡＰＩを具備していることを理解するであろう。

ハードディスク・ドライブ１１０にはまた、後述する本発明に係るセキュリティ管理プログラムが格納されている。このセキュリティ管理プログラムは、オペレーティング・システムのグラフィックス・ライブラリの呼び出しを監視し得る機能を記述可能な、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（商標）などの任意のプログラム言語処理系で書かれている。

ディスプレイ１１６は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。

キーボード１１０及びマウス１１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ１１６に表示されたアイコン、タスクバー、ウインドウなどのグラフィック・オブジェクトを操作するために使用される。

図２は、この実施例の論理構成のブロック図である。図２において、ＶＲＡＭ１０８中には、画面表示領域１０８ａと、複数のオフスクリーン・バッファ１０８ｂ、オフスクリーン・バッファ１０８ｃ、オフスクリーン・バッファ１０８ｄ・・・が存在する。個々のオフスクリーン・バッファは、アプリケーション・プログラムによって、作成、変更またはクリアされる。但し、アプリケーション・プログラムがオフスクリーン・バッファを作成しただけでは、それは、ディスプレイ１１６（図１）の画面には反映されず、画面表示領域１０８ａにコピーされてはじめて、画面に見える状態となる。例えば、ウインドウが最小化された、あるアプリケーション・プログラムが、画像を作成する命令を実行し、その結果がオフスクリーン・バッファの変更をもたらすことがあり得る。しかし、そのようなオフスクリーン・バッファの変更は、最小化されたアプリケーション・プログラムのウインドウが復元、あるいは最大化されるまで、画面表示領域１０８ａには反映されず、すなわち、それまではユーザーに見えない。

オフスクリーン・バッファ１０８ｂ、オフスクリーン・バッファ１０８ｃ、１０８ｄ・・・は、基本的に、ＶＲＡＭ１０８中に確保されるが、ＶＲＡＭ１０８に十分な空き領域がなくなったなどの場合、主記憶１０６中に確保される。

ラベル・マップ・テーブル２１０は、本発明で利用される特徴的な構成の１つであり、好適には、ＶＲＡＭ１０８中に、CreateBitmap、CreateCompatibleBitmapなどのＡＰＩ関数を呼び出すなどして、確保される。主記憶１０６中に確保する場合は、通常のGlobalAllocのようなＡＰＩ関数を用いることができる。ラベル・マップ・テーブル２１０は、画面ラベルマップ２１０ａと、オフスクリーン・バッファ・ラベルマップ２１０ｂ、２１０ｃ、２１０ｄ・・・とからなり、それぞれ、画面表示領域１０８ａ、複数のオフスクリーン・バッファ１０８ｂ、１０８ｃ、１０８ｄ・・・に個別に対応している。しかし、オフスクリーン・バッファに格納されているのは、画面に対する描画内容であるが、オフスクリーン・バッファ・ラベルマップに格納されているのは、セキュリティ・レベルである。各々のオフスクリーン・バッファ・ラベルマップには、単一のセキュリティラベルを割り当てることができる。セキュリティラベルを割り当てるとは、この実施例では、オフスクリーン・バッファ・ラベルマップとして、CreateBitmapなどのＡＰＩ関数により割り当てられたビットマップ領域全体に、セキュリティラベル（例えば、１）を書き込むことである。本発明では、画面ラベルマップ２１０ａ上での、オフスクリーン・バッファ・ラベルマップの論理演算に基づき、アクセス制御が行われるが、その詳細は動作は、後で説明する。

図２の上方を参照すると、複数のアプリケーション・プログラム２２０ａ、２２０ｂ、２２０ｃ・・・が示されている。これらのアプリケーション・プログラムは、一般的には、ディスク１１０に保存され、キーボード１１２及びマウス１１４の操作に応答して、オペレーティング・システムの機能によって、ディスク１１０から主記憶１０６にロードされ、実行される。

本発明によれば、複数のアプリケーション・プログラム２２０ａ、２２０ｂ、２２０ｃには、１〜３のようなセキュリティ・ラベルが付与される。ここでは、その数字が多いほど、セキュリティ・ラベルが高いとする。アプリケーション・プログラム、あるいはアプリケーション・プログラムが生成するプロセスにセキュリティ・レベルを付与する技術としては、例えば、特開２００７−６５８４６に記載されている技術がある。これにより開示される技術は、オペレーティング・システム上で、アプリケーション・プログラム間で送受信されるメッセージを監視し、別途記述されているポリシーに基づき、処理の変更、禁止などを行う。なお、以下の説明では、特開２００７−６５８４６の文脈におけるセキュリティ・レベルと、ここでアプリケーション・プログラムに付与されるセキュリティ・ラベルを同一視する。

下記は、ファイル毎にセキュリティ・ラベルを設定するポリシーの例であり、<Rule RuleId="urn:rule1">が、設定されるセキュリティ・レベルを記述する。すなわち、urn:rule1以外に、"urn:rule0, "urn:rule2など複数用意しておく。また、<AttributeValue DataType="file:path"> 〜 </AttributeValue>のところで、そのセキュリティ・ラベルが適用されるアプリケーション・プログラムを記述する。
<!-- Group 1 -->
<Rule RuleId="urn:rule1">
<Description>Deny clipboad copy and print by notepad and calc</Description>
<Subjects>
<Subject>
<AttributeValue DataType="file:path">calc.exe</AttributeValue>
</Subject>
<Subject>
<AttributeValue DataType="file:path">notepad.exe</AttributeValue>
</Subject>
</Subjects>
<Resources>
<Resource DataType="clipboard" Lib="SBLCLIP">
<!-- クリップボードへのコピー禁止 -->
<AttributeValue DataType="clipboard:type">
<AnyClipboardDataType/>
</AttributeValue>
<Actions>
<Action Effect="Deny">write</Action>
</Actions>
</Resource>
...........
...........
</Rule>

同様に、アプリケーション・プログラムによって生成されるプロセス毎に、セキュリティ・レベルを設定することが可能であるが、このような機能自体、本発明の要旨ではないので、これ以上の詳しい説明は省略する。必要に応じて、特開２００７−６５８４６その他の従来技術を参照されたい。なお、上記ポリシーには明示していないが、セキュリティ・ラベルを指定していないアプリケーション・プログラムには、最低レベルのセキュリティ・ラベルを付与するのが望ましい。これによって、素性の分からないアプリケーション・プログラムが、意図しない状況でビデオ・メモリから機密情報を取得することが防止される。

さて、図２に戻って、描画命令実行機能検出部２２２は、上述のような機能を使用して、アプリケーション・プログラム２２０ａ、２２０ｂ、２２０ｃが発行する描画命令を監視する。併せて、それらのアプリケーション・プログラムがそれらの描画命令を発行したプロセスのセキュリティ・レベルを取得する。そのような典型的な描画命令として、BitBlt、及びStretchBltがある。

描画命令解析部２２４は、描画命令実行機能検出部２２２が検出した描画命令の種別やパラメータを解析し、描画命令実行の結果、どのような画像が、画面に残るかを判別する。

ラベル割り当て部２２６は、アプリケーション・プログラムまたはプロセスに割り当てられたセキュリティ・レベルを参照して、画面ラベルマップ２１０ａ上に割り当てられるラベル値を決定する。なお、この実施例の説明では、アプリケーション・プログラムのセキュリティ・レベルと、それに対応するラベルマップのラベルとを同一のものとして説明することに留意されたい。

ラベルマップ管理部２２８は、ＶＲＡＭ１０８の空き領域、または主記憶１０６などで、画面やオフスクリーンのラベルを管理する。

画像処理制御部２３０は、ラベルマップを参照しながら、読み込みの可否を判断して、マスク処理などを実施する。

描画命令実行部２３２は、描画を行う機能部であり、一つの実施例では、描画が実際に行われるように、オペレーティング・システムに、描画ＡＰＩ関数を引き渡す。

図３は、本発明が利用可能な、アプリケーション・プログラム監視の仕組みの概要を示す図である。一番下のレイヤ３０２は、グラフィックス・デバイスのハードウェアであり、その上に、グラフィックス・デバイスのハードウェアのメーカから提供される、グラフィックス・ドライバのレイヤ３０４がある。レイヤ３０４の上には、Win32グラフィックサブシステムを実現するWin32k.sysデバイス・ドライバのレイヤ３０６があり、その上に、具体的なグラフィック関係のＡＰＩ関数呼び出しを含む、GDI32.DLLのレイヤ３０８がある。そうして、GDI32.DLLと各アプリケーション・プログラムの間に、ＡＰＩ監視モジュール３１０が介在し、アプリケーション・プログラムが発行するグラフィック関係のＡＰＩ関数呼び出しを監視する。このような監視機能は、図２の描画命令実行検出部２３２が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開２００７−６５８４６で開示されているものである。

図４は、本発明が利用可能な、アプリケーション・プログラム監視の別の仕組みの概要を示す図である。図４の実施例の、図３の実施例との違いは、アプリケーション・プログラム個別のＡＰＩ監視モジュール３１０を、GDI32.DLLとアプリケーション・プログラムの間に介在させることなく、その代わりに、グラフィックス・ドライバのレイヤ３０４と、Win32k.sysデバイス・ドライバのレイヤ３０６の間に、ＤＤＩ監視ドライバのレイヤ４０２を置くことで、GDI32.DLLからグラフィックス・ドライバに送られる描画命令を、ＤＤＩ監視ドライバが監視する。このような監視機能は、図２の描画命令実行検出部２３２が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開２００２−２７８５２６で開示されているものである。

図３の監視機構の場合、ウインドウのクリッピング処理を、ＡＰＩ監視モジュール３１０が行う必要があるが、図４の監視機構の場合、ＤＤＩ監視ドライバに、クリッピング処理された可視領域情報が伝わるため、クリッピング処理する手間が省ける。

次に、図２の描画命令実行検出部２２２が利用する、描画命令監視モジュールの機能について説明する。この描画命令監視モジュールは、この実施例では、図３のＡＰＩ監視モジュール３１０または、図４のＤＤＩ監視ドライバ４０２である。

先ず、前提として、各プロセスには、適当なセキュリティ・レベルとしてのラベルが割り当られる。ここでは、ラベル値が高いほど機密性の高い情報を扱うと仮定する。そのとき、例えば特開２００７−６５８４６に記載されている方法で、管理者が事前にプロセスごとに割り当ててもよい。あるいは、本出願人に係る、２００７年５月３１日に出願の米国特許出願第１１／７５５７６９号に記載されている技法により、開いているファイルやネットワークアドレス、画面出力文字情報などのコンテキストに応じて動的に割り当ててもよい。

一方、描画命令監視モジュールは、各プロセスによって描画命令が発行されるたびに、画面上およびオフスクリーンバッファ上の描画領域に対して、描画プロセスの属性や描画命令の内容に応じたセキュリティ・ラベルの割り当てを行う。

描画命令監視モジュールは、まず、描画命令の種別およびパラメータを解析し、描画命令を以下の演算式に抽象化する。
out = OP(src, dst, pat)
ここで、OPは描画命令種別(Operation)、srcは処理対象画像(Source)、dstは描画領域既存画像(Destination)、patは演算に用いる画像要素(Pattern)を意味する。また、outは、描画命令実行後の画像を意味する。srcとdstは、画面上の可視領域(Screen)の場合もあるし、ＶＲＡＭ１０８または主記憶１０６(memory)上のオフスクリーンバッファの場合もある。

例えば、画面上の画像を別領域に移動する命令は、
OP = SourceCopy
src = Screen
dst = Screen
pat = NULL
out = src
と表現する。

特定の画面領域を黒く塗りつぶすときは、
OP = PatternCopy
src = NULL
dst = Screen
pat = Black
out = pat
と表現する。

オフスクリーンバッファから画面へのビットマップ半透明描画命令は、
OP = AlphaBlend
src = Memory
dst = Screen
pat = NULL
out = (src OR dst)
と表現する。

特定の画面領域の反転表示は、
OP = DestInvert
src = NULL
dst = Screen
pat = NULL
out = (NOT dst)
と表現する。

描画命令種別は、src, dst, patの論理演算パターンに応じて２５６種類存在する。さらに、描画を行わない命令として、オフスクリーンメモリの作成命令 CreateBitmap等も含む。描画命令監視モジュールは、このように描画命令を抽象化した上で、描画先領域の既存画像(Destination)が、描画命令によりどのように処理されるかを判定する。そうして、描画命令監視モジュールは、判定結果により、以下のように、描画先領域のセキュリティ・ラベルを決める。

描画命令実行により、描画先領域の既存画像が塗りつぶされる場合、描画命令発行元のプロセスのセキュリティ・ラベルまたはソース領域のセキュリティ・ラベルを割り当てる。この種の命令の例として、ビットブロック転送を行うBitBltがあり、下記のような引数をとる。
BOOL BitBlt(HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight,
HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nWidthはコピー先の長方形の論理単位の幅、nHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、dwRopは、ラスターオペレーションコードである。dwRop = SRCCOPYの場合、コピー元の長方形を、コピー先の長方形としてそのままコピーする処理が行われる。この場合、out = OP(src, dst, pat)の形に抽象化したとき、指定したパターンで埋める訳ではないので、pat = NULLである。また、dwRop = SRCCOPYとすることにより、画面から画面へのブロック転送であるので、OP = SourceCopyで、src = Screen、 dst = Screen、out = srcである。オフスクリーンバッファから画面に書く場合は、src = Memoryとなる。また、dstとして、オフスクリーンバッファを選ぶこともでき、その場合は、dst = Memoryとなる。

別の例として、ブラシを使って長方形領域を描画するPatBltを挙げてみると、
BOOL PatBlt(HDC hdc, int nXLeft, int nYLeft, int nWidth,
int nHeight, DWORD dwRop);
ここで、hdcはデバイスコンテキストのハンドル、nXLeftは長方形領域の左上隅の論理単位のx座標、nYLeftは長方形領域の左上隅の論理単位のy座標で、out = OP(src, dst, pat)の形に抽象化したとき、
dwRop = PATCOPYとすることにより、src = NULL、 dst = Screen、OP = PatternCopyで、out = patである。ここで、patとは、デバイスコンテキストで現在選択されているブラシによるパターンである。

描画命令実行により、描画先領域の既存画像情報がそのまま残る場合は、既存ラベルを継承する。この種の命令の例として、ラスターオペレーションコードにDSTINVERT(デスティネーション反転)を指定したBitBltがある。この場合、src = NULL、dst = Screen、pat = NULL、out = NOT (dst) となる。

描画命令実行により、既存画像と新規画像の合成結果が表示される場合は、既存ラベルと新規ラベルの高いほうを割り当てる。この種の命令の例として、ラスターオペレーションコードにMERGECOPY(コピー元とコピー先のAND演算)を指定したBitBltや、AlphaBlend(半透明描画)が挙げられる。なお、AlphaBlendは、次のとおりである。
BOOL AlphaBlend(HDC hdcDest, int nXDest, int nYDest, int nDestWidth,
int nDestHeight, HDC hdcSrc, int nXSrc, int nYSrc,
int nSrcWidth, int nSrcHeight, BLENDFUNCTION BlendFunction);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nDestWidthはコピー先の長方形の論理単位の幅、nDestHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、nSrcWidthはコピー元の長方形の論理単位の幅、nSrcHeightはコピー元の長方形の論理単位の高さ、BlendFunctionはAlphaBlendを行う関数を指定する構造体である。この場合、out = OP(src, dst, pat)の形に抽象化したとき、src = Screen、dst = Screen、pat = NULLである。また、out = (src OR dst)であるが、ここのORは、論理ＯＲ演算ではなく、BlendFunctionに基づく、AlphaBlendの結果である。オフスクリーンバッファから画面にAlphaBlendする場合は、src = Memoryとなる。
以上、いくつかの代表的な描画用ＡＰＩ関数の抽象化について説明したが、この分野の当業者であれば、他の描画用ＡＰＩ関数についても、同様の取り扱いが可能であることを理解するであろう。

図２に戻って、画面表示領域１０８ａ内で新たな描画が行われ、または、オフスクリーンバッファ１０８ｂなどが画面表示領域１０８ａ内にコピーされて、新たな描画が発生するときは、それに対応して、画面ラベルマップ２１０ａに対して、対応するセキュリティ・ラベルの領域の書き込みが行われる。ラベルマップ・テーブル２１０を主記憶１０６で管理する場合には、このコピーとして、memcpyなどの周期のコピー関数を用いることがだきる。また、ラベルマップ・テーブル２１０を、画像バッファ１０８の一部として管理する場合は、上述したBitBltを使うこともできる。

このような度重なる画面ラベルマップ２１０ａに対する書き込みで、ある領域のラベルが隣接する領域とラベルが一致した場合は、処理の便宜上、それらの領域は、統合される。これらのことは、後で、具体例に基づき説明することで、一層理解が深められるであろう。

図５は、本発明のこの実施例に係る、ラベル割り当て処理のフローチャートである。このフローチャートは、図２の描画命令実行検出部２２２が、任意のアプリケーション・プログラム２２０ａ、２２０ｂ、・・・において、描画命令を検出したときに開始される。ステップ５０２では、検出された描画命令が、上述したようにout = OP(src, dst, pat)の形式に抽象化される。

尚、out = OP(src, dst, pat)によって、outの領域を考えたとき、それが描かれる元の画面ラベルマップ２１０ａのラベルの分布によって、outはさまざまな条件の領域に分かれ得る。図５の様々な判断ステップは、そのようなoutの異なる条件の領域毎に判断と処理を行うものであることを理解されたい。

ステップ５０４では、outにおいて、実行プロセスよりも高いラベルのsrcが、描画命令実行後に残るかどうかが判断される。これは、言い換えると、描画命令が、srcの上書き、またはsrcとpatの合成、またはsrcとdstの合成、またはsrc、dst及びpatの全ての合成であり、且つsrc領域のラベルとして実行プロセスのラベルより高いものが含まれていた場合である。

ステップ５０４の判断がYesであると、ステップ５０６で、実行プロセスより高いラベルのsrc領域をマスク処理する描画命令に変換される。このことは、具体的には、実行プロセスより高いラベルのsrc領域の座標を検出して、その検出した座標範囲は、例えば、PatBltにより、黒塗りにするなどの方法をとる。この黒塗りの領域に対応する描画命令は、ラベル１のプロセスとして処理を行うようにする。これによって、outに対応するラベルマップ・テーブル領域には、ラベル１が書き込まれることになる。こうしておくことにより、再度ステップ５０２からステップ５０４の判断ステップに来たとき、その判断がyesにならないので、ステップ５０６には進まない。なお、検出した座標範囲のラベル値は、「１」にリセットする代わりに、実行プロセスと同じラベル値に設定してもよい。さらに、上記黒塗り処理は、要するに、その領域の画面情報を無意味なものにすればよいので、オリジナルの情報を隠蔽する、網掛け、白抜きなど任意の画面処理をもちいることができる。

ステップ５０４での判断がNoであると、ステップ５０８で、outがpatで上書きまたは、srcとpatの合成かどうかが判断される。もしその判断がYesなら、ステップ５１０で、outの領域に、実行プロセスのラベルを割り当てる。

ステップ５０８での判断がNoであると、ステップ５１２で、outがdstとpatの合成、または、srcとdstとpatの合成かが判断される。もしその判断がyesなら、ステップ５１４で、outにおいて、dstのラベルと、実行プロセスのラベルの高い方が割り当てる。

ステップ５１２での判断がNoであると、ステップ５１６で、outがsrcで上書きかどうかが判断される。もしその判断がYesなら、ステップ５１８で、outにsrc領域のラベルを割り当て、そうでないなら、ステップ５２０で、outにdstの領域を割り当てる。

次に、画面の図に従い、本発明の実施例の処理をより具体的に説明する。

図６は、図１に示すハードウェア構成のコンピュータの起動直後の様子を示す。以下の図面では、画面表示領域１０８ａと、それに対応する画面ラベルマップ２１０ａを並置して示す。画面ラベルマップ２１０ａとして、ＶＲＡＭ領域を使う場合、画面ラベルマップ２１０ａの領域確保には、CreateBitmapなどのＡＰＩ関数を使用することができる。画面ラベルマップ２１０ａとして、主記憶を使う場合、GlobalAllocなどのＡＰＩ関数を使用することができる。図６では、起動直後なので、画面表示領域１０８ａには、何も表示されていないとする。一方、画面ラベルマップ２１０ａには、デフォールトのセキュリティ・ラベル値として、全ビットマップに1が埋められる。このコピーには、画面ラベルマップ２１０ａがＶＲＡＭ領域を使う場合、BitBltを使用することができる。画面ラベルマップ２１０ａが主記憶１０６にある場合は、memcpyなどを使用することができる。

次に、図７に示すように、ラベル３のプロセスが、オフスクリーン・バッファに領域１０８ｂを確保し、そこにグラフを描画しようとする。これに従って、図２の描画命令実行検出部２２２が、そのラベル３のプロセスの描画命令を検出し、それに従って、描画命令解析部２２４が、ラベル割り当て部２２６に作用して、３という数字が埋められたオフスクリーン・ラベルマップ領域２１０ｂがラベルマップ・テーブル２１０に確保される。そして、画像処理制御部２３０が描画命令実行部２３２に作用し、これにより、画像命令実行検出部２２２が検出した描画命令を描画実行部２３２に引渡す。こうして、実際のグラフの描画が領域１０８ｂで行われるが、この段階では、オフスクリーン・バッファ領域１０８ｂに描かれたグラフは、まだ画面には見えない。

次に、図８に示すように、ラベル３のプロセスが、グラフが描画されたオフスクリーン・バッファ領域１０８ｂを、BitBltを使って画面表示領域１０８ａにコピーしようとする。すると、この描画命令は、描画命令実行検出部２２２により検出され、それに従って、描画命令解析部２２４が、ラベル割り当て部２２６に作用して、結果画像を計算する。その結果、実行プロセスよりも高レベルのsrcは残らないのでステップ５０４はNo、Patで上書きでもsrcとpatの合成でもないのでステップ５０８もNo、dstとpatの合成でもないのでステップ５１２もNoで、ステップ５１６で、srcで上書きかどうかの判断で初めてYesになる。従って、ステップ５１８で、srcのラベル３が割り当てられて、図８に示すように、画面ラベルマップ２１０ａに、オフスクリーン・ラベルマップ領域２１０ｂがコピーされ、領域８０２となる。これに従い、画像処理制御部２３０が描画命令実行部２３２に作用し、これにより、画像命令実行検出部２２２が検出した描画命令を描画実行部２３２に引渡す。このことは、オフスクリーン・バッファ領域１０８ｂの画面ラベルマップ２１０ａへのコピーをもたらし、そうしてコピーされた画像８０４は、ユーザーに見えるようになる。

図９では、ラベル２を割り当てられた別のプロセスが、ラベル３の領域の一部を上書きするように別のグラフ９０４を表示することを試みる。このとき、このラベル２を割り当てられたプロセスによって表示されるoutの中に、ラベル２よりもラベルが高い領域は残されないので、ステップ５０４はNoになって、ステップ５０８もステップ５１２もNoで、ステップ５１６でのsrcで上書きかどうかの判断がyesになり、ステップ５１８で、オフスクリーン・ラベルマップ領域２１０ｂにおいて、outの領域９０２でのラベル２の割り当てが行われる。このことにより、実際の画面ラベルマップ２１０ａで、画像９０４が、ラベル３の領域の一部を上書きするように表示する、ということが許可される。

図１０では、ラベル２を割り当てられたさらに別のプロセスが、既に描かれているラベル３の領域８０４の一部と、既に描かれているラベル２の領域９０４の両方を上書きするように、半透明の領域１００６を表示することを試みる。このとき、このラベル２を割り当てられたプロセスによって表示されるoutの中に、ラベル２よりもラベルが高い領域は残されないので、ステップ５０４はNoであり、patで上書きでもなく、srcとpatの合成でもないのでステップ５０８もNoであるが、ステップ５１２での、srcとdstの合成か、という判断が、領域８０４と領域１００６との重なりの部分でYesになり、その部分については、ステップ５１４が適用されて、すなわち、dst領域のラベルと、実行プロセスのラベルの高い方が割り当てられるので、領域８０４と領域１００６との重なりの部分のラベルは３となる。また、領域１００６に対応するラベルも、領域９０４に対応するラベルもともに２なので、それらは、ラベルマップ領域２１０ａではマージされて、図１０に示すようになる。

次に、図１１に示すように、ラベル２を割り当てられた、またさらに別のプロセスが、オフスクリーンバッファ上に、空白の領域１１０２を確保する。これに対応して、ラベルマップ・テーブル２１０に、ラベル２の領域１１０４が、ラベル割り当て部２２６によって確保される。

次に、図１２に示すように、空白の領域１１０２を確保したのと同一のラベル２のプロセスが、破線で示す領域１２０２領域を、領域１１０２にコピーしようと試みたとする。そのようなコピーは、BitBltのような描画命令を発行するので、描画命令実行検出部２２２により検出され、図５のフローチャートの判断が行われる。

そこで、領域１２０２の、領域１１０２へのコピーを想定してみると、典型的には図１２の画面ラペルマップ２１０ａを参照すると見て取れるように、outとなるべきラベル２の領域１１０４に、ラベル３の領域１００４が入ってくることになる。このことは、実行プロセスにより高ラベルのsrcが描画命令に残ることを意味するので、領域１００４に対応して、ステップ５０４での判断でのYesを引き起こし、それにより、ステップ５０６では、画像処理制御部２３０によって、画面ラペルマップ２１０ａのラベル３の領域１００４に対応する画像表示領域からの、オフスクリーンバッファ１１０２へのコピーが、BitBltではなく、PatBltの黒の塗りつぶしに置き換えられる。従って、図１２に示すように、オフスクリーン・バッファ１１０２にコピーされてきたときは、ラベル３の領域の見えている部分が、黒塗りでコピーされて、そこだけ見えなくなっている。これによって、ラベルが相対的に低いプロセスに、ラベルが相対的に高いプロセスの内容がコピーされるのが防げるので、セキュリティ的な保護が提供される。なお、図５のステップ５０６に関連して説明したように、黒の塗りつぶしは、ラベル１の描画プロセスに置き換えられるので、オフスクリーン・ラベルマップ１１０４は、図１２に示すように、画面ラペルマップ２１０ａの対応src領域において、ラベル３の領域を、ラベル１に書き換えた状態になる。

尚、図１０で表示した半透明の領域には、「XYZ Confidential」という文字が入っている。ウインドウへの文字の表示は、TextOutというＡＰＩ関数を使って行うことができるので、このようの文字列出力自体を、図２の描画命令実行検出部２２２は検出可能である。従って、"xxx confidential"のような特定の文字列出力を含むＡＰＩ関数を検出することに応答して、そのプロセスのラベルを１つ増やすか、あるいは、ある既定の絶対値に設定するようにしてもよい。

また、背景のにじみ処理を伴う半透明合成処理の場合は、にじみの度合いとフォントサイズのパラメータの一方または両方に基づき、可読性が低下したと判断して、そのプロセスのラベルを１つ減らしてもよい。このような検出処理を行う処理ブロックは、図２には明示的に示されていないが、にじみの度合いもフォントサイズも、適当なＡＰＩ関数で取得できるので、そのような機能を追加することは可能である。

このようなラベルの変更処理は、図２の描画命令解析部２２４の機能を拡張することによって行うことができる。

また、上記実施例では、オペレーティング・システム上で走る監視プログラムより描画命令を監視することによって、ラベルマップを操作し、以って所望の画面のセキュリティ管理機能を達成しているが、オペレーティング・システムのソースコードを作成・編集できる権限を有し、またはその立場にある場合は、本発明の機能を、オペレーティング・システムのネイティブな機能として、実装するようにしてもよい。

本発明を実施するためのコンピュータのハードウェアのブロック図である。 本発明の実施例に係るラベルマップ管理機構の機能ブロック図である。 描画監視の機能を実現するための構成の１つの例を示すブロック図である。 描画監視の機能を実現するための構成の別の例を示すブロック図である。 本発明の実施例に係るラベルマップ管理処理のフローチャートである。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。 画面領域と画面ラベルマップの対応を示す図である。

Claims (6)

1. 画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記メモリ上の画像データを画面に表示する際に、画面の情報を保護するシステムであって、
   前記画面に対応するセキュリティ・ラベル・マップ情報を、前記メモリ上にもつラベル・マップ記憶手段と、
   前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出する検出手段と、
   前記検出手段の検出に応答して、前記読取領域に対応するセキュリティ・ラベル・マップ情報を、前記ラベルマップ記憶手段上で確認し、前記アプリケーション・プログラムのセキュリティ・ラベルが、前記読取領域のセキュリティ・ラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの情報の読取動作を禁止する制御手段とを有する、
   画面情報保護システム。
2. 前記読取領域からの情報の読取動作の禁止は、該読取り情報の宛先への書込み命令を、塗りつぶしの命令に書き換えることによって行われる、請求項１に記載の画面情報保護システム。
3. 前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書込み命令に応答して、前記ラベルマップ記憶手段の対応する領域に、該セキュリティラベルの情報を書き込む手段をさらに有する、請求項１に記載の画面情報保護システム。
4. 前記ラベルマップ記憶手段は、前記メモリの、前記画面に対応しない領域に配置される、請求項１に記載の画面情報保護システム。
5. 前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項１に記載の画面情報保護システム。
6. 前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項１に記載の画面情報保護システム。

Images