JPH09251426A - File ciphering system and its control method, and cipher file reception system and its control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a safe cipher file reception system and its method which need only one cipher file even when plural users access the same WWW(world wide web). SOLUTION: This cipher file reception system includes a server information processor 120 which includes a shared file cipher program 21b and previously ciphers the information transmitted through a WWW to store them in a magnetic disk 5b, and a client information processor 110 which includes a shared file cipher program 21a and a communication API hook program. Then the system hooks the communication API call sent from a browser program and automatically decodes the received file data.

Description

【発明の詳細な説明】Detailed Description of the Invention

【０００１】[0001]

【発明の属する技術分野】本発明は、情報処理装置のフ
ァイルの暗号化システムおよびその制御方法ならびに通
信回線を通じて暗号ファイルを受信する際のデータ受信
制御方法に係り、特に、複数のユーザーが復号可能な暗
号ファイルを作成あるいは復号化する場合に好適な、共
用ファイル暗号システム及びその制御方法ならびにアプ
リケーションプログラムにとって透過な暗号ファイル受
信システム及びその制御方法に関する。BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file encryption system for an information processing apparatus, a control method therefor, and a data reception control method when an encrypted file is received through a communication line, and more particularly, it can be decrypted by a plurality of users. The present invention relates to a shared file encryption system and its control method suitable for creating or decrypting various encrypted files, and an encryption file reception system and its control method transparent to an application program.

【０００２】[0002]

【従来の技術】パーソナルコンピュータなどの情報処理
装置が普及するにつれて、各情報処理装置毎の磁気記憶
装置上に保管していたユーザーのプログラムファイル、
データファイルなどを一箇所の大容量磁気記憶装置に保
管し、各情報処理装置のユーザーがファイルを共用す
る、といった使い方が行われるようになってきた。一般
的には、ファイルサーバプログラムが搭載されたサーバ
情報処理装置と該サーバ情報処理装置へアクセスするた
めのクライアントプログラムが搭載された複数のクライ
アント情報処理装置をネットワークで接続し、サーバ情
報処理装置上のファイルを各クライアント情報処理装置
からアクセスし利用する。このようなファイル共用シス
テムは、従来は企業等の内部で閉じていたが、インター
ネットと呼ばれる世界的規模のネットワークの普及と共
に、このインターネットと企業内ネットワークを接続し
企業外からもアクセス可能とするケースが増大してい
る。上述のようなファイル共用システムの普及とネット
ワークの広域化は、ファイルサーバ上の共用ファイルの
セキュリティ即ち不正アクセスに対する防御の必要性を
従来にも増して高くしている。2. Description of the Related Art As information processing apparatuses such as personal computers have become widespread, user program files stored on a magnetic storage device for each information processing apparatus,
Data files and the like are stored in one large-capacity magnetic storage device, and users of each information processing device share the file. Generally, a server information processing apparatus equipped with a file server program and a plurality of client information processing apparatuses equipped with a client program for accessing the server information processing apparatus are connected via a network. Is accessed and used from each client information processing device. Conventionally, such a file sharing system has been closed inside a company or the like, but with the spread of a global network called the Internet, a case where the Internet is connected to a company network to enable access from outside the company. Is increasing. The spread of the file sharing system and the wide area of the network as described above have made the security of the shared files on the file server, that is, the need for protection against unauthorized access higher than ever.

【０００３】サーバ情報処理装置上のファイルのセキュ
リティを保つ方法としては、ファイルサーバプログラム
が具備するユーザー認証機構と、該ユーザー認証に基づ
いた、各ファイルへのアクセス権限設定／確認機構を用
いるのが一般的である。しかし、この方式ではネットワ
ーク上を流れるデータの暗号化が行われないため、盗聴
による不正アクセスが可能である。そこで、より高いセ
キュリティが必要な場合には、格納しているファイル或
いはネットワーク上を流れるファイルのデータを秘密鍵
や公開鍵を用いて暗号化するのが一般的である。これら
の暗号化方法については、「データ保護と暗号化の研
究」一松信監修、日本経済新聞社（昭５８）などで詳し
く開示されている。As a method of maintaining the security of a file on a server information processing apparatus, a user authentication mechanism provided in a file server program and an access authority setting / confirmation mechanism for each file based on the user authentication are used. General. However, in this method, data flowing on the network is not encrypted, so that unauthorized access by eavesdropping is possible. Therefore, when higher security is required, it is general to encrypt the data of the stored file or the file flowing on the network by using a secret key or a public key. These encryption methods are disclosed in detail in "Research on Data Protection and Encryption" supervised by Shin Ichimatsu and Nihon Keizai Shimbun (1983).

【０００４】また、前記インターネットにおいては、情
報発信機能を持つＷＷＷ（Ｗｏｒｌｄ−Ｗｉｄｅ Ｗｅ
ｂ）サーバを利用し、ハイパーテキストと呼ばれる形式
の文書ファイルで情報を提供するのが一般的となってい
る。前記ハイパーテキストを解釈し、グラフィカルに表
示するソフトウェアはブラウザと呼ばれ、広く普及して
いる。前記ハイパーテキストの言語仕様としては、ＨＴ
ＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐ Ｌａｎｇｕａ
ｇｅ）が一般に用いられており、この言語仕様やＨＴＭ
Ｌで記述されたファイルを表示するブラウザについて
は、「ＵＮＩＸ ＭＡＧＡＺＩＮＥ」（１９９４．１
０）ｐｐ．５２−６０などで詳しく述べられている。な
お、殆どのＨＴＭＬファイルは他のＨＴＭＬファイルや
イメージデータファイルとリンクしており、前記ブラウ
ザはＨＴＭＬファイルを受信した後で、それがリンクし
ているイメージデータファイルを受信し、該ＨＴＭＬフ
ァイルの内容と合わせて同一画面に表示する。これらＨ
ＴＭＬファイルとそれにリンクされたイメージデータフ
ァイルを総括してページと呼ぶ。Further, on the Internet, a WWW (World-Wide We) having an information transmission function is provided.
b) It is general to provide information in a document file in a format called hypertext using a server. Software for interpreting the hypertext and displaying it graphically is called a browser and is widely used. The language specifications of the hypertext include HT
ML (HyperText Markup Langua
ge) is generally used, and this language specification and HTM
For a browser that displays files described in L, see "UNIX MAGAZINE" (1994.1).
0) pp. 52-60. Note that most HTML files are linked to other HTML files and image data files, and the browser receives the HTML file and then receives the image data file to which the HTML file is linked, and the contents of the HTML file. And display it on the same screen. These H
The TML file and the image data file linked to it are collectively called a page.

【０００５】上記ＷＷＷサーバは、ＨＴＴＰ（Ｈｙｐｅ
ｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と
いう通信規約に基づいて、上記ＨＴＭＬファイルやイメ
ージデータをブラウザに送信する。この時、インターネ
ット上を流れるデータは暗号化されていないため、ＷＷ
Ｗサーバに機密情報を含むページを格納することはセキ
ュリティ上問題がある。インターネット上を流れるデー
タの暗号化手段としては、例えばＳｅｃｕｒｅＨＴＴＰ
やＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）
などが挙げられる。また、これらの技術については、
「日経コミュニケーション」日経ＢＰ社（１９９５．１
２．４ ｐ７５−８０）などに記載されている。[0005] The WWW server is HTTP (Hype).
The HTML file and the image data are transmitted to a browser based on a communication protocol called "rtext Transfer Protocol". At this time, since the data flowing on the Internet is not encrypted,
Storing a page containing confidential information in the W server has a security problem. As means for encrypting data flowing on the Internet, for example, Secure HTTP
And SSL (Secure Socket Layer)
And the like. Also, about these technologies,
"Nikkei Communication" Nikkei BP (1995.1)
2.4 pages 75-80).

【０００６】[0006]

【発明が解決しようとする課題】上述の暗号化は不正ア
クセスに対する防御ならびにデータの盗聴や改ざんに対
する防御という観点からは十分ではあるが、複数のユー
ザーが同一のファイルを安全にアクセスできるようにす
るためには、ユーザー毎に異なる鍵を用いる必要があり
鍵の管理が困難であるという課題がある。また、格納さ
れているファイルを暗号化する場合には、鍵毎に暗号化
ファイルを作成する必要があり、記憶装置の記憶容量を
多く消費してしまうという課題がある。また、通信時に
ネットワーク上のデータを暗号化する方法においては、
暗号/復号処理のためアクセス速度が低下してしまうと
いう課題もある。さらに、通信時にネットワーク上のデ
ータを暗号化する方法においては、暗号化処理のためア
クセス速度が低下してしまうという課題と、ＷＷＷサー
バが機密情報を平文ファイルで管理しているため、該平
文ファイルを管理する情報処理装置に直接アクセスする
ことで機密情報が漏れてしまうという課題とがある。Although the above-described encryption is sufficient from the viewpoint of protection against unauthorized access and wiretapping and tampering of data, it enables a plurality of users to securely access the same file. Therefore, it is necessary to use a different key for each user, and it is difficult to manage the key. In addition, when a stored file is encrypted, it is necessary to create an encrypted file for each key, and there is a problem that a large amount of storage capacity of a storage device is consumed. In addition, in the method of encrypting data on the network during communication,
There is also a problem that the access speed is reduced due to the encryption / decryption processing. Furthermore, in the method of encrypting data on the network during communication, the problem that the access speed is reduced due to the encryption process and that the WWW server manages confidential information in a plaintext file, the plaintext file There is a problem that confidential information is leaked by directly accessing the information processing device that manages the.

【０００７】また、ファイル共用システムの場合、クラ
イアント情報処理装置が必ずしも復号化ソフトウェアプ
ログラムを具備しているとは限らない。暗号化されたフ
ァイルを復号化ソフトウェアが具備されていない情報処
理装置上のアプリケーションプログラムで読み出した場
合、該情報処理装置のモニタ画面上に意味のない文字や
記号が表示されたり、該アプリケーションプログラムが
異常動作することがあるという課題がある。Further, in the case of the file sharing system, the client information processing device does not always have the decryption software program. When an encrypted file is read by an application program on an information processing device that is not equipped with decryption software, meaningless characters or symbols are displayed on the monitor screen of the information processing device, or the application program There is a problem that it may operate abnormally.

【０００８】また、格納するファイルを暗号化する方法
では、ユーザーが暗号化操作を忘れてしまい、不正なア
クセスから防御すべきファイルを平文で格納してしまう
という課題がある。Further, the method of encrypting the file to be stored has a problem that the user forgets the encryption operation and stores the file to be protected from unauthorized access in plain text.

【０００９】また、インターネット上で上記ブラウザを
具備するクライアント情報処理装置が必ずしも復号化ソ
フトウェアプログラムを具備しているとは限らない。暗
号化されたファイルを復号化ソフトウェアが具備されて
いない情報処理装置上のブラウザで読み出した場合、該
情報処理装置のモニタ画面上に意味のない文字や記号が
表示されたり、該ブラウザプログラムが異常動作するこ
とがあるという課題がある。Further, the client information processing apparatus having the above-mentioned browser on the Internet does not always have the decryption software program. When an encrypted file is read by a browser on an information processing device that does not have decryption software, meaningless characters or symbols are displayed on the monitor screen of the information processing device, or the browser program is abnormal. There is a problem that it may operate.

【００１０】そこで、本発明の目的は、複数のユーザー
が同一のファイルを利用する場合にも暗号化ファイルが
一個で済み且つ安全なファイル暗号化システムおよびそ
の制御方法を提供することにある。Therefore, it is an object of the present invention to provide a file encryption system that requires only one encrypted file even when a plurality of users use the same file, and a secure file encryption method.

【００１１】また、本発明の他の目的は、複数のユーザ
ーが同一のディレクトリ内のファイルを暗号化する場合
に、復号化を許可するユーザーをユーザー毎に設定可能
なファイル暗号化システムおよびその制御方法を提供す
ることにある。Another object of the present invention is to provide a file encryption system in which a user who permits decryption can be set for each user when a plurality of users encrypt files in the same directory. To provide a method.

【００１２】また本発明の他の目的は、復号化ソフトウ
ェアを具備していないクライアント情報処理装置におい
て暗号化されたファイルを読み出した場合にも、異常動
作することのないファイル暗号化システムおよびその制
御方法を提供することにある。Another object of the present invention is to provide a file encryption system and its control that do not operate abnormally even when an encrypted file is read in a client information processing apparatus that does not have decryption software. To provide a method.

【００１３】また、本発明の他の目的は、ユーザーが暗
号化を忘れることのないファイル暗号化システムおよび
その制御方法を提供することにある。Another object of the present invention is to provide a file encryption system and a control method therefor in which a user never forgets to encrypt.

【００１４】さらに、本発明の目的は、インターネット
上で複数のユーザーが同一のページをＷＷＷサーバから
受信する場合にも暗号ファイルが１ファイルにつき一個
で済み、且つ安全な暗号ファイル受信システム及びその
制御方法を提供することにある。Further, an object of the present invention is to provide a secure encrypted file receiving system and its control, in which only one encrypted file is required even when a plurality of users receive the same page from the WWW server on the Internet. To provide a method.

【００１５】また、本発明の他の目的は、復号化ソフト
ウェアを具備していないクライアント情報処理装置にお
いて暗号化されたファイルを読み出した場合にも、異常
動作することのない暗号ファイル受信システム及びその
制御方法を提供することにある。Another object of the present invention is to provide an encrypted file receiving system which does not operate abnormally even when an encrypted file is read out by a client information processing apparatus which does not have decryption software, and the same. It is to provide a control method.

【００１６】さらに、本発明の他の目的は、受信した暗
号ファイルの復号化処理を、ユーザーがファイル毎に明
示的に指示する必要のない暗号ファイル受信システム及
びその制御方法を提供することにある。Still another object of the present invention is to provide a cryptographic file receiving system and its control method in which the user does not need to explicitly instruct the decryption processing of the received encrypted file for each file. .

【００１７】[0017]

【課題を解決するための手段】上記目的は、少なくとも
ファイルへの入出力制御機能を持つオペレーティングシ
ステム（ＯＳ）と、前記ファイルを格納する記憶装置と
を具備する情報処理装置において、暗号化を行う対象デ
ィレクトリを予めユーザー毎に複数設定可能な暗号化デ
ィレクトリ記憶手段と、前記記憶手段の記憶データを暗
号化する手段と、前記ＯＳ上で動作するアプリケーショ
ンプログラムから前記ディレクトリ内のファイルへの書
き込みデータを暗号化する暗号化手段とを設けることに
よって達成される。The above object is to perform encryption in an information processing apparatus having at least an operating system (OS) having an input / output control function for files and a storage device for storing the files. An encrypted directory storage means capable of setting a plurality of target directories in advance for each user, a means for encrypting the storage data of the storage means, and write data to a file in the directory from an application program operating on the OS are provided. It is achieved by providing an encryption means for encrypting.

【００１８】また、上記他の目的は、少なくともファイ
ルへの入出力制御機能を持つオペレーティングシステム
（ＯＳ）と、前記ファイルを格納する記憶装置と、前記
ファイルを暗号化するファイル暗号化手段と、前記ファ
イルを復号化する復号化手段とを具備する情報処理装置
において、前記ファイル暗号化手段は、アプリケーショ
ンプログラムが解釈し処理する文法に従って記述された
平文ファイルのデータ暗号化において、前記文法におけ
る前記アプリケーションプログラム処理時に処理対象外
として無視する注釈文とするための記述子を前記暗号化
後のデータに付加し暗号ファイルとして格納し、前記フ
ァイル復号化手段は、前記暗号ファイルのデータ復号化
において、前記注釈文のための記述子によって注釈文と
されたデータ部分を復号化し、暗号化前の平文ファイル
のデータとして格納することによって達成される。Another object is to provide an operating system (OS) having at least an input / output control function for a file, a storage device for storing the file, a file encryption means for encrypting the file, and In the information processing device, comprising: a decryption unit for decrypting a file, the file encryption unit uses the application program in the grammar for data encryption of a plaintext file described according to a grammar interpreted and processed by the application program. A descriptor for making an annotation text to be ignored as a non-processing object at the time of processing is added to the encrypted data and stored as an encrypted file, and the file decryption means, in the data decryption of the encrypted file, the annotation The data part annotated by the statement descriptor Decoded, it is achieved by storing the data in unencrypted plaintext file.

【００１９】また、上記他の目的は、前記アプリケーシ
ョンプログラムから前記ＯＳに発行されるファイル操作
要求をフックするフック手段を設け、前記ファイル操作
要求発行時に自動的に暗号化あるいは復号化を行う手段
を設けることによって達成される。Another object is to provide a hook means for hooking a file operation request issued from the application program to the OS, and to automatically encrypt or decrypt the file operation request when the file operation request is issued. It is achieved by providing.

【００２０】上記目的は、少なくとも通信制御機能とフ
ァイルへの入出力制御機能を持つオペレーティングシス
テム（ＯＳ）と、前記ファイルを格納する記憶装置とを
具備する第一の情報処理装置と、該第一の情報処理装置
とはネットワークで接続され、少なくとも前記第一の情
報処理装置上の記憶装置からファイルを受信するための
通信制御機能を持つオペレーティングシステム（ＯＳ）
を具備する第二の情報処理装置から構成されるシステム
において、前記ファイルを暗号化して該暗号ファイルに
情報開示先となるユーザーのリストを添付するファイル
暗号化手段と、前記第二の情報処理装置を利用するユー
ザーが、前記記憶装置に登録された前記暗号ファイルを
受信したときに、該暗号ファイルを復号化する受信ファ
イル復号化手段と、前記ユーザーが前記ユーザーリスト
に含まれている場合には、前記受信ファイル復号化手段
を呼び出し、含まれていない場合には復号化を行わない
よう制御する復号権利判別手段とを設けることによって
達成される。The above object is to provide a first information processing apparatus having an operating system (OS) having at least a communication control function and a file input / output control function, and a storage device for storing the file, and the first information processing apparatus. Operating system (OS) having a communication control function for receiving a file from at least the storage device on the first information processing device, which is connected to the information processing device via a network.
In a system including a second information processing apparatus including: a file encryption unit that encrypts the file and attaches a list of users who are information disclosure destinations to the encrypted file; and the second information processing apparatus When a user who uses the received file receives the encrypted file registered in the storage device, a received file decryption unit that decrypts the encrypted file, and if the user is included in the user list, This is achieved by providing the above-mentioned received file decryption means, and decryption right discrimination means for controlling so as not to perform decryption if not included.

【００２１】また、上記他の目的は、少なくともファイ
ルへの入出力制御機能を持つオペレーティングシステム
（ＯＳ）と、前記ファイルを格納する記憶装置と、前記
ファイルを暗号化するファイル暗号化手段とを具備する
第一の情報処理装置において、前記ファイル暗号化手段
は、アプリケーションプログラムが解釈し処理する文法
に従って記述された平文ファイルのデータ暗号化におい
て、前記文法における前記アプリケーションプログラム
処理時に処理対象外として無視する注釈文とするための
記述子を前記暗号化後のデータに付加し暗号ファイルと
して格納し、前記受信ファイル復号化手段は、前記暗号
ファイルのデータ復号化において、前記注釈文のための
記述子によって注釈文とされたデータ部分を復号化し、
暗号化前の平文ファイルのデータとしてアプリケーショ
ンプログラムに渡すことによって達成される。Another object is to have an operating system (OS) having at least an input / output control function for a file, a storage device for storing the file, and a file encryption means for encrypting the file. In the first information processing apparatus, the file encryption means ignores the data encryption of the plaintext file described according to the grammar interpreted and processed by the application program as a non-processing target when processing the application program in the grammar. A descriptor to be an annotation text is added to the encrypted data and stored as an encrypted file, and the received file decryption means uses the descriptor for the annotation text to decrypt the encrypted file data. Decode the data part that is the annotation text,
It is achieved by passing it to the application program as the plaintext file data before encryption.

【００２２】また、上記他の目的は、前記第二の情報処
理装置において、前記アプリケーションプログラムから
前記ＯＳに発行されるデータ送受信要求をフックするフ
ック手段を設け、該フック手段により前記アプリケーシ
ョンプログラムより先に受信データをチェックし、該受
信データが前記暗号ファイルのデータであれば復号化を
行い、前記アプリケーションプログラムに渡すことによ
って達成される。Another object is to provide a hook means for hooking a data transmission / reception request issued from the application program to the OS in the second information processing apparatus, and the hook means precedes the application program. This is accomplished by checking the received data, decrypting the received data if the received data is the data of the encrypted file, and passing the decrypted data to the application program.

【００２３】[0023]

【発明の実施の形態】以下、本発明の一実施例を図を用
いて説明する。DESCRIPTION OF THE PREFERRED EMBODIMENTS One embodiment of the present invention will be described below with reference to the drawings.

【００２４】まず、全体のシステム構成を説明する。図
１は、本発明の共用ファイル暗号システムの一構成例で
ある。１１０はクライアント情報処理装置、１２０はサ
ーバ情報処理装置である。サーバ情報処理装置１２０に
は、中央処理装置（ＣＰＵ）１ｂ、メモリ２ｂ、ＬＡＮ
コントローラ３ｂ、ディスクコントローラ４ｂ、磁気デ
ィスク５ｂが具備されている。前記サーバ情報処理装置
１２０の起動時には、オペレーティングシステム（Ｏ
Ｓ）２０ｂおよびファイルサーバプログラム２５が、デ
ィスクコントローラ４ｂを介して磁気ディスク５ｂから
メモリ２ｂ上にロードされる。クライアント情報処理装
置１１０には、ＣＰＵ１ａ、メモリ２ａ、ＬＡＮコント
ローラ３ａ、ディスクコントローラ４ａ、磁気ディスク
５ａ、ＩＣカードコントローラ６がそれぞれ具備されて
いる。前記クライアント情報処理装置１１０の起動時に
は、ＯＳ２０ａ、クライアントプログラム２４、共用フ
ァイル暗号プログラム２１、ファイルＩ／Ｏフックプロ
グラム２２が、前記ディスクコントローラ４ａを介して
前記磁気ディスク５ａから前記メモリ２ａ上にロードさ
れる。また、アプリケーションプログラム２３は、前記
クライアント情報処理装置１１０のユーザー（以下、単
にユーザーと呼ぶ）の指示によって前記ディスクコント
ローラ４ａを介して前記磁気ディスク５ａから前記メモ
リ２ａ上にロードされる。前記ファイルＩ／Ｏフックプ
ログラム２２は、アプリケーションプログラム２３が前
記ＯＳ２０ａに発行するファイルＩ／Ｏ ＡＰＩをフッ
ク（横取り）し、ファイルデータの暗号化・復号化をバ
ックグラウンドで自動的に行うものである。First, the overall system configuration will be described. FIG. 1 is a configuration example of a shared file encryption system according to the present invention. 110 is a client information processing device, and 120 is a server information processing device. A central processing unit (CPU) 1b, a memory 2b, a LAN
A controller 3b, a disk controller 4b, and a magnetic disk 5b are provided. When the server information processing apparatus 120 is started, an operating system (O
S) 20b and the file server program 25 are loaded from the magnetic disk 5b to the memory 2b via the disk controller 4b. The client information processing device 110 includes a CPU 1a, a memory 2a, a LAN controller 3a, a disk controller 4a, a magnetic disk 5a, and an IC card controller 6, respectively. When the client information processing apparatus 110 is started, the OS 20a, the client program 24, the shared file encryption program 21, and the file I / O hook program 22 are loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a. You. The application program 23 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a according to an instruction from a user of the client information processing apparatus 110 (hereinafter, simply referred to as a user). The file I / O hook program 22 hooks (preempts) the file I / O API issued by the application program 23 to the OS 20a, and automatically performs encryption / decryption of file data in the background. .

【００２５】前記サーバ情報処理装置１２０と前記クラ
イアント情報処理装置１１０は、ローカルエリアネット
ワーク（ＬＡＮ）１０１を介して相互に接続されてお
り、各々のＬＡＮコントローラ３を介して通信を行う。
図１では一台のクライアント情報処理装置１１０を示し
たが、実際には、同じ構成のクライアント情報処理装置
１１０が複数前記ＬＡＮ１０１に接続されており、これ
らのクライアント情報処理装置１１０間で、前記サーバ
情報処理装置１２０の前記磁気ディスク５ｂに格納され
たファイルを共用する。ユーザーは前記共用を行うた
め、前記クライアントプログラム２４を介して前記磁気
ディスク５ｂ上の共用ファイルをアクセスする。The server information processing device 120 and the client information processing device 110 are connected to each other via a local area network (LAN) 101, and communicate with each other via each LAN controller 3.
Although FIG. 1 shows one client information processing apparatus 110, actually, a plurality of client information processing apparatuses 110 having the same configuration are connected to the LAN 101, and the client information processing apparatus 110 The file stored in the magnetic disk 5b of the information processing device 120 is shared. The user accesses a shared file on the magnetic disk 5b via the client program 24 to perform the sharing.

【００２６】また、クライアント情報処理装置１１０の
ＩＣカードコントローラ６は、ＩＣカード１３０が脱着
可能となっている。前記ＩＣカード１３０内には、ＣＰ
Ｕ１ｃ、不揮発性メモリ７、入出力インタフェース８が
具備されている。前記不揮発性メモリ７には、アクセス
制御プログラム３０、グループ暗号プログラム２８、Ｉ
Ｄ情報２９、マスタ鍵３１が書き込まれている。前記不
揮発性メモリ７の内容は、前記入出力インタフェース８
を介して外部からアクセスすることができる。ただし、
不正なアクセスから前記不揮発性メモリ７の記憶内容を
保護する為、前記ＣＰＵ１ｃによるユーザー認証制御が
必ず介在する仕組みとなっている。Further, the IC card controller 6 of the client information processing apparatus 110 has an IC card 130 detachable. In the IC card 130, a CP
A U1c, a nonvolatile memory 7, and an input / output interface 8 are provided. The nonvolatile memory 7 has an access control program 30, a group encryption program 28,
The D information 29 and the master key 31 are written. The contents of the nonvolatile memory 7 are stored in the input / output interface 8.
Can be accessed from outside via However,
In order to protect the storage contents of the nonvolatile memory 7 from unauthorized access, the user authentication control by the CPU 1c always intervenes.

【００２７】図２７は、前記共用ファイル暗号プログラ
ム２１と前記ファイルＩ／Ｏフックプログラム２２を構
成するプログラムルーチンを示す図である。前記共用フ
ァイル暗号プログラム２１は、前記ＩＣカード１３０へ
のログイン、ログアウトを行うログイン制御ルーチン１
０００、ログアウト制御ルーチン１１００、ユーザーが
ファイルの暗号化をその都度明示的に指示し暗号化する
手動ファイル暗号化ルーチン２０００、前記手動ファイ
ル暗号化をＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋ
ｕｐ Ｌａｎｇｕａｇｅ）で記述した共用ファイル向け
にアレンジしたＨＴＭＬファイル暗号化ルーチン２１０
０から構成される。前記ファイルＩ／Ｏフックプログラ
ム２２は、ファイルオープンフックルーチン１２００、
ファイルクリエイトフックルーチン１３００、ファイル
リードフックルーチン１４００、ファイルライトフック
ルーチン１５００、ファイルクローズフックルーチン１
６００、ファイルリネームフックルーチン１７００から
構成される。FIG. 27 is a diagram showing a program routine that constitutes the shared file encryption program 21 and the file I / O hook program 22. The shared file encryption program 21 includes a login control routine 1 for logging in and out of the IC card 130.
000, a logout control routine 1100, a manual file encryption routine 2000 for the user to explicitly instruct and encrypt a file each time, and an HTML (Hyper Text Mark) manual file encryption.
HTML file encryption routine 210 arranged for a shared file described in up Language)
It consists of 0. The file I / O hook program 22 includes a file open hook routine 1200,
File create hook routine 1300, file read hook routine 1400, file write hook routine 1500, file close hook routine 1
600 and a file rename hook routine 1700.

【００２８】図２は、前記ＩＤ情報２９の内容の一例を
示す図である。ここでは、カテゴリ毎の内容を示すデー
タとそのコードを１０組まで登録できるようになってい
る。実際に前記不揮発性メモリ７に記憶するのは、デー
タとコードの値だけである。FIG. 2 is a diagram showing an example of the contents of the ID information 29. Here, up to 10 sets of data indicating the contents of each category and their codes can be registered. What is actually stored in the nonvolatile memory 7 is only the data and code values.

【００２９】次に、上記グループ暗号プログラム２８の
動作について説明する。グループ暗号では、復号化を許
す相手の宛先リストを作成し、該宛先リストをハッシュ
関数に入力することによって得られるハッシュ値を、暗
号化・復号化の鍵に用いる。前記鍵をグループ鍵５１と
呼ぶ。本実施例における宛先リストは、前記ＩＤ情報２
９を条件式で連結した形で表現する。具体的には、「カ
テゴリ番号」「データコード識別子」「演算子」「デー
タ」を一組とし、カンマ（，）で区切って並べる。この
カンマは論理和の意味を持つ。演算子としては、等しい
（＝）の他、大小（＞、＜）や論理積（＾）を用いるこ
とができる。例えば、図２で示した前記ＩＤ情報２９の
定義を用いた場合、 「システム研究所の第四部の主任以上と暗号太郎」 という宛先に対する宛先リストは、 「５Ｃ＝６７６＾６Ｃ＝０４＾８Ｃ＞＝５，２Ｄ＝暗号
太郎」 となる。Next, the operation of the group encryption program 28 will be described. In the group encryption, a destination list of a partner to whom decryption is permitted is created, and a hash value obtained by inputting the destination list to a hash function is used as an encryption / decryption key. The key is called a group key 51. The destination list in the present embodiment is the ID information 2
9 is expressed in a form linked by a conditional expression. Specifically, a “category number”, a “data code identifier”, an “operator”, and a “data” are set as a set and are separated by commas (,). This comma has a logical OR meaning. As an operator, in addition to equality (=), magnitude (>, <) and logical product (＾) can be used. For example, when the definition of the ID information 29 shown in FIG. 2 is used, the destination list for the destination of “Chief or higher of the fourth part of System Research Laboratory and Taro Cryptography” is “5C = 676 ^ 6C = 04 ^ 8C > = 5, 2D = Cryptaro. ”

【００３０】図３は、前記宛先リストのハッシュ値を計
算し前記グループ鍵５１を作成する手順の一例を示す図
である。３１はマスタ鍵、４１は宛先リスト、５１はグ
ループ鍵、３２はハッシュ関数である。まず、前記ＩＤ
情報を元に作成した宛先リストのデータ長が８の倍数の
バイト数になっていない場合には不足分を空白文字で補
い更に８バイトの乱数を付加する。宛先リストが丁度８
の倍数であった場合には単に８バイトの乱数を付加す
る。８の倍数とした宛先リストを以下では単に宛先リス
ト４１と呼ぶ。このように乱数を付加することによっ
て、同じ宛先でも毎回異なるグループ鍵が生成されるの
でセキュリティを向上することができる。FIG. 3 is a diagram showing an example of a procedure for calculating the hash value of the destination list and creating the group key 51. 31 is a master key, 41 is a destination list, 51 is a group key, and 32 is a hash function. First, the ID
If the data length of the destination list created based on the information is not a multiple of 8 bytes, the shortage is supplemented with blank characters and a random number of 8 bytes is added. Address list is exactly 8
If it is a multiple of, an 8-byte random number is simply added. The destination list that is a multiple of 8 is simply referred to as a destination list 41 below. By adding a random number in this way, a different group key is generated each time even at the same destination, so that security can be improved.

【００３１】次にハッシュ関数３２の動作を簡単に説明
する。まず、前記宛先リスト４１を先頭から８バイトず
つブロック暗号方式によって暗号化し、該暗号化の結果
と初期値との排他的論理和を取り次の段のブロック暗号
の初期値として用いる。この処理を前記宛先リスト４１
の最後まで繰り返し、最後の段から出力される暗号化結
果と初期値との排他的論理和をグループ鍵５１とする。
なお、前記ブロック暗号では、８バイトのマスタ鍵３１
と８バイトの初期値を用いて入力データの暗号化を行
う。なお、データを暗号化するユーザーと復号化するユ
ーザーは、同じ値の前記マスタ鍵３１を使用する。Next, the operation of the hash function 32 will be briefly described. First, the destination list 41 is encrypted by 8 bytes at a time from the beginning by a block encryption method, and an exclusive OR of a result of the encryption and an initial value is obtained and used as an initial value of a block encryption of the next stage. This process is performed in the destination list 41.
And the exclusive OR of the encryption result output from the last stage and the initial value is used as the group key 51.
In the block cipher, an 8-byte master key 31 is used.
Then, the input data is encrypted using the initial value of 8 bytes. A user who encrypts data and a user who decrypts data use the master key 31 having the same value.

【００３２】図４は、前記ＩＣカード１３０内の前記グ
ループ暗号プログラム２８の処理内容を示すフロー図で
ある。グループ暗号プログラム２８では、上述のグルー
プ鍵生成方法を用いて前記宛先リスト４１からグループ
鍵５１を作成する。ステップ４０１では、前記ＩＣカー
ド１３０のアクセス制御プログラム３０に対するログイ
ンが完了しているかどうかを検査し、完了していなけれ
ばステップ４１１でエラーコードを設定して本プログラ
ムを終了する。前記ログインが完了している場合には、
入力された宛先リスト４１をステップ４０２で解析し、
前記ＩＤ情報２９に該当する宛先があるかどうかを検査
する。該検査の結果宛先が該当していればステップ４０
３を実行し、該当していなければステップ４１２でエラ
ーコードを設定し本プログラムを終了する。ステップ４
０３では、図３で説明した方法でグループ鍵を生成す
る。以上の処理によって、ＩＣカード１３０にログイン
済みで且つ前記宛先リストの宛先としてＩＣカード１３
０内のＩＤ情報２９に該当するものがある場合のみグル
ープ鍵を生成するように制御することができる。FIG. 4 is a flow chart showing the processing contents of the group encryption program 28 in the IC card 130. In the group encryption program 28, a group key 51 is created from the destination list 41 by using the above-described group key generation method. In step 401, it is checked whether or not the login to the access control program 30 of the IC card 130 is completed, and if it is not completed, an error code is set in step 411 and the program is terminated. If the login has been completed,
The input destination list 41 is analyzed in step 402,
It is checked whether there is a destination corresponding to the ID information 29. If the result of the inspection indicates that the destination is applicable, step 40
Step 3 is executed, and if not, an error code is set in step 412 and the program ends. Step 4
In 03, a group key is generated by the method described with reference to FIG. With the above processing, the user has already logged in to the IC card 130 and
It is possible to control to generate a group key only when there is ID information 29 in 0.

【００３３】以上説明したグループ鍵５１を用いてデー
タを暗号化することによって、前記宛先リスト４１に含
まれるＩＤ情報２９を持つ者だけが該データの復号化を
可能とすることができる。By encrypting the data using the group key 51 described above, only the person having the ID information 29 included in the destination list 41 can decrypt the data.

【００３４】次に、上述のグループ暗号をファイルの暗
号に適用した例について説明する。図５は、ファイルの
暗号化手順と暗号化後のファイルの構成を示す図であ
る。５０１は暗号化する前の平文ファイル、５０２は暗
号化後の暗号文ファイルである。６１は乱数として生成
された実行鍵、５０４は前記実行鍵６１を鍵として前記
ファイル５０１の内容を暗号化した暗号文データ、５０
５は暗号文データ５０４に付加するヘッダ、５０６から
５１１は前記ヘッダ５０５の内容であり、５０６は使用
した暗号化方式を示す文字列、５０７は前記平文ファイ
ル５０１のファイル名、５０８前記平文ファイル５０１
のファイルサイズ、５０９は前記実行鍵６１をグループ
鍵５１で暗号化した暗号化実行鍵、５１０は前記宛先リ
スト４１のサイズ、５１１は前記宛先リスト４１を前記
マスタ鍵３１で暗号化した暗号化宛先リストである。前
記暗号文ファイル５０２は、図６に示すように上記手順
と全く逆の手順で復号化することができる。上述のファ
イル暗号化においては、前記グループ鍵５１は前記実行
鍵６１を暗号化する為に用い、ファイルデータの暗号化
には前記実行鍵６１を用いた。したがって、前記宛先リ
スト４１を変更する場合には、まず前記実行鍵６１を変
更前の前記宛先リスト４１で生成した前記グループ鍵５
１で復号化し、次に変更後の前記宛先リスト４１から生
成した前記グループ鍵５１で再暗号化すればよい。これ
により、前記宛先リスト４１の変更時にも前記実行鍵６
１に比べデータ量の多いファイルデータは再暗号化が不
要とすることができ、変更処理を高速に行うことができ
る。Next, an example in which the above-mentioned group cipher is applied to the cipher of a file will be described. FIG. 5 is a diagram showing a file encryption procedure and a configuration of a file after encryption. Reference numeral 501 denotes a plaintext file before encryption, and 502 denotes an encrypted text file after encryption. 61 is an execution key generated as a random number; 504 is ciphertext data obtained by encrypting the contents of the file 501 using the execution key 61 as a key;
5 is a header to be added to the ciphertext data 504; 506 to 511 are contents of the header 505; 506 is a character string indicating the encryption method used; 507 is the file name of the plaintext file 501;
509 is an encrypted execution key obtained by encrypting the execution key 61 with the group key 51, 510 is the size of the destination list 41, and 511 is an encrypted destination obtained by encrypting the destination list 41 with the master key 31. It is a list. As shown in FIG. 6, the ciphertext file 502 can be decrypted in a procedure completely opposite to the above procedure. In the above-described file encryption, the group key 51 is used to encrypt the execution key 61, and the execution key 61 is used to encrypt file data. Therefore, when the destination list 41 is changed, first, the execution key 61 is changed to the group key 5 generated in the destination list 41 before the change.
1 and then re-encrypted with the group key 51 generated from the changed destination list 41. Thus, even when the destination list 41 is changed, the execution key 6
Re-encryption of file data having a larger amount of data than that of No. 1 can be unnecessary, and the change processing can be performed at high speed.

【００３５】次に、上記ファイルの暗号化を用いてユー
ザーが操作するファイルを自動的に暗号化・復号化する
機能について説明する。ここで用いるファイルシステム
は、最近のＯＳが具備する一般的なものであり、ツリー
状の階層構造を持つ。ツリーの節の部分はディレクトリ
と呼ばれ、各ディレクトリに存在するファイルはディレ
クトリファイルと呼ばれるファイルによって管理され
る。ファイルの物理的な格納場所は、前記クライアント
情報処理装置１１０の前記磁気ディスク５ａあるいは前
記サーバ情報処理装置１２０の前記磁気ディスク５ｂの
どちらでもよい。Next, the function of automatically encrypting / decrypting a file operated by the user by using the above-mentioned file encryption will be described. The file system used here is a general one included in a recent OS, and has a tree-like hierarchical structure. The sections of the tree are called directories, and the files in each directory are managed by files called directory files. The physical storage location of the file may be either the magnetic disk 5a of the client information processing device 110 or the magnetic disk 5b of the server information processing device 120.

【００３６】図７は、ユーザーから見た論理的なディレ
クトリの構成を示す図である。本実施例のファイルの自
動暗号化、復号化を導入していない場合は、前記論理的
なディレクトリ構成と物理的なディレクトリ構成は同一
である。図８は、ファイルの自動暗号化、復号化を導入
した後の物理的なディレクトリ構成を示す図である。ユ
ーザーがファイルの自動暗号化、復号化を行うディレク
トリには、ファイル名としてユーザー名とその末尾
に「．ｄｅｉ」を付加したファイル名で宛先リストファ
イル９０１を作成する。また、全ユーザーに共通な宛先
を設定して暗号化を行う場合には、「ｄｅｆａｕｌｔ．
ｄｅｉ」というファイル名で宛先リストファイル９０１
を作成する。このように、前記宛先リストファイル９０
１を作成しておくと、前記宛先リストファイル９０１に
記載された宛先リストを宛先としたファイルの自動暗号
化が行われ、連番とその末尾に「．ｓｓｆ」を付加した
ファイル名で格納される。例えば、図７のファイル「ｏ
ｓａｋａ．ｄｏｃ」は「０００１．ｓｓｆ」として格納
される。また前記自動暗号化が行われたディレクトリに
は、「ｆｉｌｅｉｎｆｏ．ｄｅｉ」という名称の暗号フ
ァイル情報ファイル９０２が作成される。FIG. 7 is a diagram showing a logical directory structure viewed from the user. When the automatic file encryption and decryption of the present embodiment are not introduced, the logical directory structure and the physical directory structure are the same. FIG. 8 is a diagram showing a physical directory structure after the automatic encryption and decryption of a file has been introduced. In a directory in which the user automatically encrypts and decrypts a file, a destination list file 901 is created with a user name as a file name and a file name with ".dei" added to the end thereof. When encryption is performed by setting a common destination for all users, “default.
destination list file 901 with the file name “dei”
Create In this way, the destination list file 90
When 1 is created, the files are automatically encrypted with the destination list described in the destination list file 901 as the destination, and are stored with a serial number and a file name with ".ssf" added to the end. It For example, the file "o
saka. “doc” is stored as “0001.ssf”. In addition, an encrypted file information file 902 named “fileinfo.dei” is created in the directory where the automatic encryption has been performed.

【００３７】図９は、前記宛先リストファイル９０１、
前記暗号ファイル情報ファイル９０２の内容の一例を示
す図である。各ユーザーの宛先リストファイル９０１
は、該ユーザーを宛先としたグループ暗号で暗号化して
いる。また、「ｄｅｆａｕｌｔ．ｄｅｉ」は、前記マス
タ鍵３１を用いて暗号化している。これによって、宛先
リストファイルの不正な読み出しや改竄を防止できる。
一方、暗号ファイル情報ファイル９０２には、暗号化後
のファイル名、暗号化前の平文ファイル名、暗号化前の
平文ファイルのサイズが書き込まれている。上述のファ
イル名称はあくまでも一例であり他の名称を用いてもよ
い。FIG. 9 shows the destination list file 901,
It is a figure which shows an example of the content of the said encryption file information file 902. Destination list file 901 for each user
Is encrypted by group encryption with the user as the destination. Further, “default.dei” is encrypted using the master key 31. As a result, unauthorized reading and falsification of the destination list file can be prevented.
On the other hand, in the encrypted file information file 902, the file name after encryption, the plaintext file name before encryption, and the size of the plaintext file before encryption are written. The above file names are merely examples, and other names may be used.

【００３８】以下、図８に示したような物理的構造を持
つファイルを図７に示した論理的ファイル構造として扱
うための処理プログラムの詳細を説明する。Details of the processing program for handling the file having the physical structure shown in FIG. 8 as the logical file structure shown in FIG. 7 will be described below.

【００３９】まず、共用ファイル暗号プログラム２１内
のログイン処理ルーチン１０００、ログアウト処理ルー
チン１１００について説明する。図１０は、前記ＩＣカ
ード１３０へのログイン処理ルーチン１０００の処理フ
ローを示す図である。まず、ステップ１００１でユーザ
ーがＩＤとパスワードの入力を行い、ステップ１００２
では前記ユーザーＩＤと前記パスワードを用いて前記Ｉ
Ｃカード１３０にログインを試み、ステップ１００３で
前記ログインが成功したかどうかを判定する。前記判定
の結果、失敗の場合はステップ１００９を実行し、３回
続けて失敗するまではステップ１００１以下を繰り返す
よう制御する。ログインに成功すると、ステップ１００
４でイベント待ち状態となる。イベントが到着すると、
ログアウト要求かどうかを調べ、ログアウト要求ならば
ステップ１００８でログアウト処理を行い終了する。前
記イベントがログアウト要求でなければステップ１００
６でタイマイベントかどうかを調べ、タイマイベントで
なければステップ１００４に戻る。タイマイベントであ
った場合には、ＩＣカード１３０が前記クライアント情
報処理装置１１０に接続されているかどうかを調べ、接
続されていればステップ１００４に戻り、接続されてい
ない場合は、ステップ１００８のログアウト処理を実行
し、終了する。このように、タイマイベントを用いて定
期的に前記ＩＣカード１３０の接続を調べることによっ
て前記ＩＣカード１３０を抜いた際のログアウト処理を
自動化することができる。First, the login processing routine 1000 and the logout processing routine 1100 in the shared file encryption program 21 will be described. FIG. 10 is a diagram showing a processing flow of a login processing routine 1000 for the IC card 130. First, in step 1001, the user inputs an ID and a password.
Then, using the user ID and the password,
An attempt is made to log in to the C card 130, and it is determined in step 1003 whether or not the log in has been successful. If the result of the determination is a failure, step 1009 is executed, and control is performed so that steps 1001 and subsequent steps are repeated until three consecutive failures occur. If login is successful, step 100
At 4 the event wait state is set. When the event arrives,
It is checked whether the request is a logout request. If the request is a logout request, logout processing is performed in step 1008, and the processing is terminated. If the event is not a logout request, step 100
In step 6, it is checked whether the event is a timer event. If the event is not a timer event, the process returns to step 1004. If it is a timer event, it is checked whether or not the IC card 130 is connected to the client information processing apparatus 110. If it is connected, the process returns to step 1004; And exit. As described above, the logout process when the IC card 130 is removed can be automated by checking the connection of the IC card 130 periodically using the timer event.

【００４０】図１１は、前記ＩＣカード１３０からのロ
グアウト処理ルーチン１１００の処理フローを示す図で
ある。まず、ステップ１１０１でオープン中の暗号ファ
イルがあるかどうかを調べ、あればステップ１１０２で
ユーザーにログアウトを中止するか否かを尋ねる。ログ
アウト処理を中止する場合には、本ルーチンを終了す
る。中止しない場合には、ステップ１１０３でオープン
中の暗号ファイルのクローズ処理を行い、処理を継続す
る。ステップ１１０４では、ＩＣカード１３０がクライ
アント情報処理装置１１０に接続されているかどうかを
調べ、接続されていればステップ１１０５でＩＣカード
１３０に対してログアウトコマンドを送出し処理を終了
する。接続されていなければそのまま処理を終了する。FIG. 11 is a diagram showing a processing flow of a logout processing routine 1100 from the IC card 130. First, it is checked in step 1101 whether there is an open encrypted file, and if so, in step 1102, the user is asked whether to stop logout. If the logout process is to be stopped, this routine ends. If not stopped, in step 1103, the open file is closed and the process is continued. In step 1104, it is checked whether or not the IC card 130 is connected to the client information processing apparatus 110. If connected, a logout command is sent to the IC card 130 in step 1105, and the process ends. If not, the process ends.

【００４１】次に、前記ファイルＩ／Ｏフックプログラ
ム２２内の各ルーチンの処理について説明する。まず、
ファイルのデータ入出力とその管理方法から説明する。Next, the processing of each routine in the file I / O hook program 22 will be described. First,
A description will be given from the data input / output of the file and the management method thereof.

【００４２】図１８は、本実施例のファイル暗号化・復
号化におけるデータの入出力方法を示す図である。前記
暗号文ファイル５０２の前記暗号文データ５０４は、暗
号文ブロックバッファ８２のサイズ単位で前記暗号文ブ
ロックバッファ８２との間で読み出し・書き込みが行わ
れる。前記暗号文ブロックバッファ８２のデータは復号
化し平文ブロックバッファ８１に転送される。また、前
記平文ブロックバッファ８１のデータは暗号化し前記暗
号文ブロックバッファ８２に転送される。FIG. 18 is a diagram showing a data input / output method in file encryption / decryption of this embodiment. The ciphertext data 504 of the ciphertext file 502 is read / written from / to the ciphertext block buffer 82 in units of the size of the ciphertext block buffer 82. The data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. The data in the plaintext block buffer 81 is encrypted and transferred to the ciphertext block buffer 82.

【００４３】図１９は、オープン中の暗号ファイルを管
理するためのファイルハンドルテーブル９０である。ハ
ンドル番号１９０２、オープンモード１９０３、平文フ
ァイルポインタ１９０４、暗号ファイルポインタ１９０
５、バッファポインタ１９０６、更新フラグ１９０７、
宛先リスト４１の各情報を、オープン中の各ファイル毎
にポインタ１９０１を用いてリスト構造で記憶してい
る。ここでハンドル番号１９０２は、ファイルをオープ
ンした際に前記ＯＳ２０から与えられる管理番号、オー
プンモード１９０３とは、読み出し専用、書き込み専
用、あるいは読み書き用などのモードを示す値である。
前記平文ファイルポインタ１９０４は復号化後の平文フ
ァイル５０１に対するリード・ライトを行う際の起点を
示すものであり、平文ファイル５０１の先頭からのバイ
ト数で示される。なお、平文ファイル５０１は、平文ブ
ロックバッファ８１を通して読み書きする論理的なファ
イルとして存在する。暗号ファイルポインタ１９０５
は、暗号文ファイルに対するリード・ライトを行う際の
起点を示すものであり、５０２のヘッダ５０５を含む先
頭からのバイト数で示される。前記暗号ファイルポイン
タ１９０５は、ファイルの最後のブロック部分以外では
バッファサイズ単位で増減する。バッファポインタ１９
０６は、平文ブロックバッファ８１および暗号文ブロッ
クバッファ８２に転送されているデータの先頭が前記平
文ファイル５０１のどの部分に該当するデータであるか
を示す値であり、前記平文ファイル５０１の先頭からの
バイト数が格納してある。前記バッファポインタ１９０
６はバッファサイズの単位でのみ増減する。更新フラグ
１９０７は、前記平文ブロックバッファ８１のデータ
が、ライトＩ／Ｏ操作によって更新されているが暗号文
ブロックバッファ８２への転送と暗号文ファイル５０２
への書き込みが完了していない状態を示すフラグであ
る。FIG. 19 shows a file handle table 90 for managing open encrypted files. Handle number 1902, open mode 1903, plaintext file pointer 1904, encrypted file pointer 190
5, buffer pointer 1906, update flag 1907,
The information of the destination list 41 is stored in a list structure using the pointer 1901 for each open file. Here, the handle number 1902 is a management number given from the OS 20 when the file is opened, and the open mode 1903 is a value indicating a mode such as read-only, write-only, or read / write.
The plaintext file pointer 1904 indicates a starting point when reading / writing the plaintext file 501 after decryption, and is indicated by the number of bytes from the head of the plaintext file 501. Note that the plaintext file 501 exists as a logical file that is read and written through the plaintext block buffer 81. Encrypted file pointer 1905
Indicates the starting point when reading / writing to the ciphertext file, and is indicated by the number of bytes from the beginning including the header 505 of 502. The cipher file pointer 1905 increases or decreases in buffer size units except for the last block of the file. Buffer pointer 19
06 is a value indicating which part of the plaintext file 501 corresponds to the head of the data transferred to the plaintext block buffer 81 and the ciphertext block buffer 82. The number of bytes is stored. The buffer pointer 190
6 increases or decreases only in units of buffer size. The update flag 1907 indicates that the data in the plaintext block buffer 81 has been updated by a write I / O operation, but is transferred to the ciphertext block buffer 82 and the ciphertext file 502.
This is a flag indicating a state in which writing to the memory has not been completed.

【００４４】図１２は、前記ファイルオープンフックル
ーチン１２００の処理フローを示す図である。まず、ス
テップ１２８１で、フックしたファイルのディレクトリ
に前記暗号ファイル情報ファイル９０２が存在するか否
かを調べ、存在すれば前記暗号ファイル情報ファイル９
０２の内容を参照し、フックしたファイルのファイル名
が登録されているか否かを調べる。登録されていれば、
ステップ１２８２で対応する暗号文ファイル５０２のフ
ァイル名称にファイル名称を変更する。次に、ステップ
１２０１で前記ＯＳ２０ａに対しファイルオープン要求
を発行する。該オープンが成功したかどうかをステップ
１２０２で調べ、失敗した場合は本ルーチンを終了す
る。次にステップ１２０３で、ＩＣカード１３０へのロ
グインが終了しているかどうかを調べ、ログイン済みの
場合は、ステップ１２０７に処理を移す。ログイン済み
でなかった場合には、ステップ１２０４で当該ファイル
が暗号ファイルであるかどうかを調べ、暗号ファイルで
なかった場合は本ルーチンの処理を終了する。暗号ファ
イルの場合には、ステップ１２０５で前記ログイン処理
ルーチン１０００を呼び出すことによってＩＣカード１
３０へのログイン処理を行う。ステップ１２０６では、
前記ログイン処理が成功したかどうかを調べ、成功しな
かった場合はステップ１２１５でメッセージ２ １２５
２を表示して本ルーチンを終了する。ログインに成功し
た場合は、ステップ１２０７で当該ファイルの復号権限
があるか、即ち宛先にログイン中のユーザーが含まれて
いるかどうかを判定する。前記判定は暗号ファイルの前
記ヘッダ５０５の前記暗号化宛先リスト５１１を復号化
することによって前記宛先リスト４１を取得し、該宛先
リスト４１を前記ＩＣカード１３０の前記グループ暗号
プログラム２８に入力し、グループ鍵５１が出力される
かエラーコードが出力されるかで行う。復号権限がない
場合には、ステップ１２１５でメッセージ２ １２５２
を表示して本ルーチンを終了する。復号権限がある場合
にはステップ１２０９において、当該ユーザーまたは共
通の前記宛先リストファイル９０１が当該ディレクトリ
に存在するかどうかを調べ、存在すれば暗号化対象ディ
レクトリであると判定する。暗号化対象ディレクトリで
なければステップ１２１６を実行し、フックしているフ
ァイルが暗号ファイルであるかどうかを調べ、暗号ファ
イルでなければ本ルーチンを終了する。暗号ファイルの
場合は、ステップ１２１７でメッセージ３１２５３を表
示し、処理を中断するか否かをユーザーに問い合わせ
る。上記ステップ１２０９で暗号化対象ディレクトリと
判定した場合は、ステップ１２１０でフックしているフ
ァイルが暗号ファイルかどうかを調べ、暗号ファイルで
なかった場合には、ステップ１２１１でメッセージ１
１２５１を表示し、処理を中断するか否かをユーザーに
問い合わせる。ステップ１２１０の判定で、暗号ファイ
ルであった場合には、ステップ１２１８で当該ファイル
の宛先リスト４１と当該ディレクトリの宛先リストファ
イル９０１に書かれた宛先リスト４１の宛先が同じか異
なるかを調べ、異なっていた場合には、ステップ１２１
９でメッセージ４ １２５４を表示し、処理を中断する
か否かをユーザーに問い合わせる。前記ステップ１２１
８で宛先が同じと判定した場合には、ステップ１２２０
でファイルハンドルテーブル９０への登録を行い、本ル
ーチンを終了する。また、前記ステップ１２１７、１２
１１、１２１９でのメッセージ表示に対し、ユーザーが
処理の中止を選択したかどうかはステップ１２１２で判
定し、中止の場合はステップ１２１３でファイルをクロ
ーズし、ステップ１２１４でリターンコードにオープン
エラーを設定し本ルーチンを終了する。前記ステップ１
２１２での前記判定が中止でなければ、前記ステップ１
２２０を実行し、本ルーチンを終了する。FIG. 12 is a diagram showing a processing flow of the file open hook routine 1200. First, in step 1281, it is checked whether or not the encrypted file information file 902 exists in the directory of the hooked file.
02, it is checked whether the file name of the hooked file is registered. If you are registered,
In step 1282, the file name is changed to the file name of the corresponding ciphertext file 502. Next, in step 1201, a file open request is issued to the OS 20a. It is checked in step 1202 whether or not the opening has succeeded. If the opening has failed, this routine ends. Next, in step 1203, it is determined whether or not login to the IC card 130 has been completed. If the login has been completed, the process proceeds to step 1207. If the user has not logged in, the process checks in step 1204 whether the file is an encrypted file. If not, the process of this routine ends. In the case of an encrypted file, the log-in processing routine 1000 is called in step 1205, so that the IC card 1
The server 30 performs a login process. In step 1206,
It is determined whether or not the login processing has been successful. If the login processing has not been successful, the message 2 125 is determined in step 1215.
2 is displayed and this routine ends. If the login is successful, it is determined in step 1207 whether the file has the decryption right, that is, whether the destination includes the logged-in user. The determination is made by obtaining the destination list 41 by decrypting the encrypted destination list 511 of the header 505 of the encrypted file, inputting the destination list 41 to the group encryption program 28 of the IC card 130, This is performed depending on whether the key 51 is output or an error code is output. If the user does not have the decryption authority, the message 2 1252 is output in step 1215.
Is displayed and the routine ends. If the user has the decryption right, in step 1209, it is checked whether or not the user or the common destination list file 901 exists in the directory. If it is not the encryption target directory, step 1216 is executed to check whether or not the hooked file is an encrypted file. If the file is not an encrypted file, this routine ends. In the case of an encrypted file, a message 31253 is displayed in step 1217 to inquire of the user whether or not to interrupt the process. If it is determined in step 1209 that the directory is an encryption target directory, it is checked in step 1210 whether the hooked file is an encrypted file.
1251 is displayed and an inquiry is made to the user as to whether or not to suspend the processing. If it is determined in step 1210 that the file is an encrypted file, it is checked in step 1218 whether the destination list 41 of the file and the destination of the destination list 41 written in the destination list file 901 of the directory are the same or different. If so, step 121
In step 9, message 41254 is displayed, and the user is inquired whether or not to interrupt the processing. Step 121
If it is determined in step 8 that the destinations are the same, step 1220
To register in the file handle table 90, and terminates this routine. Steps 1217 and 1217
In response to the message displayed in steps 11 and 1219, it is determined in step 1212 whether or not the user has selected to stop the processing. This routine ends. Step 1
If the determination at 212 is not aborted, the step 1
Step 220 is executed, and this routine ends.

【００４５】図１３は、ファイルクリエイトフックルー
チン１３００の処理フローを示す図である。まず、ステ
ップ１３０１で、ＩＣカード１３０へのログインが終了
しているかどうかを調べ、ログイン済みの場合はステッ
プ１３０６に処理を移す。ログイン済みでなかった場合
には、ステップ１３０２で当該ユーザーまたは共通の前
記宛先リストファイル９０１が当該ディレクトリに存在
するかどうかを調べ、存在すれば暗号化対象ディレクト
リであると判定する。暗号化対象ディレクトリでなけれ
ば、ステップ１３３１でファイルクリエィトを実行し本
ルーチンを終了する。暗号化対象ディレクトリの場合
は、ステップ１３０３でメッセージ５ １３５５を表示
し、ステップ１３０４で前記ログイン処理ルーチン１０
００を呼び出すことによって前記ＩＣカード１３０への
ログイン処理を行う。ステップ１３０５では、前記ログ
イン処理が成功したかどうかを調べ、成功しなかった場
合はステップ１３４１でメッセージ６ １３５６を表示
してファイルクリエイトを中止するか否かユーザーに問
い合わせる。ステップ１３４２でユーザーの選択を判定
し、中止の場合はステップ１３４３でクリエイトエラー
を設定し本ルーチンを終了する。中止でない場合は、ス
テップ１３２０でファイルクリエイトを実行し本ルーチ
ンを終了する。一方、ステップ１３０５でログインに成
功した場合は、ステップ１３０６で、当該ディレクトリ
に当該ユーザーまたは共通の前記宛先リストファイル９
０１が存在するかどうかを調べ、存在すれば暗号化対象
ディレクトリであると判定する。暗号化対象ディレクト
リでなければステップ１３２０でファイルクリエイトを
実行し、本ルーチンを終了する。暗号化対象ディレクト
リである場合は、ステップ１３０７でファイル名称を、
連番とその末尾に「．ｓｓｆ」を付加したファイル名に
置き換え、ステップ１３０８でファイルクリエイトを実
行する。ステップ１３０９では、前記ファイルクリエィ
トが成功したかどうかを調べ、失敗ならば本ルーチンを
終了し、成功ならばステップ１３１０以下を実行する。
ステップ１３１０では、暗号ファイルの前記ヘッダ５０
５を生成し、ステップ１３０８で作成したファイルの先
頭部分に書き込む。続くステップ１３１１では前記暗号
ファイル情報ファイル９０２への登録を行い、さらにス
テップ１３１２でファイルハンドルテーブル９０への登
録を行い本ルーチンを終了する。FIG. 13 is a diagram showing a processing flow of the file create hook routine 1300. First, in step 1301, it is determined whether or not login to the IC card 130 has been completed. If the login has been completed, the process proceeds to step 1306. If the user has not logged in, it is checked in step 1302 whether the user or the common destination list file 901 exists in the directory, and if it exists, the directory is determined to be an encryption target directory. If it is not the directory to be encrypted, file creation is executed in step 1331 and this routine ends. In the case of the directory to be encrypted, a message 51355 is displayed in step 1303, and the login processing routine 10 is executed in step 1304.
By calling 00, the login process to the IC card 130 is performed. In step 1305, it is checked whether or not the login processing is successful, and if not successful, a message 61356 is displayed in step 1341 and the user is inquired whether or not to cancel the file creation. In step 1342, the user's selection is judged, and in the case of cancellation, a create error is set in step 1343 and this routine is ended. If not, the file creation is executed in step 1320, and this routine ends. On the other hand, if the login is successful in step 1305, in step 1306, the destination list file 9 of the user or the common destination is stored in the directory.
It is checked whether or not 01 exists, and if it exists, it is determined that the directory is an encryption target directory. If the directory is not the encryption target directory, file creation is executed in step 1320, and this routine ends. If the directory is an encryption target directory, the file name is
The file is replaced with a serial number and a file name with ".ssf" added to the end, and file creation is executed in step 1308. In step 1309, it is checked whether or not the file creation has succeeded. If the file creation has failed, this routine ends. If the file creation has succeeded, steps 1310 and subsequent steps are executed.
In step 1310, the header 50 of the encrypted file
5 is generated and written at the beginning of the file created in step 1308. In the following step 1311, registration in the encrypted file information file 902 is performed, and in step 1312, registration in the file handle table 90 is performed, and this routine ends.

【００４６】図１４は、リードフックルーチン１４００
の処理フローを示す図である。まず、ステップ１４０１
でリードＩ／Ｏのパラメータに含まれるファイルハンド
ル番号が前記ファイルハンドルテーブル９０に既に登録
されているかどうかを調べ、登録されていなければ暗号
・復号対象のファイルではないのでステップ１４２１で
通常のファイルリードＩ／Ｏを実行し、本ルーチンを終
了する。ファイルハンドルテーブル９０に登録済みの場
合は、ステップ１４０２で、前記ファイルハンドルテー
ブル９０の前記オープンモード１９０３がリード可にな
っているかどうかを調べ、リード不可であれば処理が継
続できないので、ステップ１４２２でエラーコードを設
定して本ルーチンを終了する。次に、ステップ１４０３
で前記平文ファイルポインタ１９０４を取得する。ステ
ップ１４０４では、前記平文ファイルポインタ１９０４
が、前記バッファポインタ１９０６から始まるバッファ
の中を指し示しているかどうかを調べる。指し示してい
ればステップ１４１３に処理を移し、指し示していなけ
ればステップ１４０５以下を実行する。ステップ１４０
５では前記更新フラグ１９０７を参照し、前記平文ブロ
ックバッファ８１中に更新データがあるかどうかを調
べ、あればステップ１４０６で実際の暗号文ファイル５
０２のファイルポインタをＯＳへのシークコマンドによ
って前記バッファポインタ１９０６へと移動させる。ス
テップ１４０７で平文ブロックバッファ８１のデータを
暗号化し、暗号文ブロックバッファ８２に転送すると共
に、暗号文ファイル５０２に書き戻す。ステップ１４０
８では前記更新フラグ１９０７をクリアし、前記平文ブ
ロックバッファ８１中に更新データがないことを示すよ
うに設定する。ステップ１４０９で実際の暗号文ファイ
ル５０２のファイルポインタをＯＳへのシークコマンド
によって前記暗号ファイルポインタ１９０５へと移動さ
せる。ステップ１４１０では、ブロックサイズ分のデー
タを前記暗号文ファイル５０２から暗号文ブロックバッ
ファ８２へと読み出す。ステップ１４１１では、前記暗
号文ファイルポインタ１９０５、前記バッファポインタ
１９０６を更新する。ステップ１４１２では、暗号文ブ
ロックバッファ８２のデータを復号化し平文ブロックバ
ッファ８１に転送する。ステップ１４１３では、フック
したファイルリードＩ／Ｏの要求元アプリケーションプ
ログラム２３が指定した要求バッファに平文ブロックバ
ッファ８１からデータを転送する。ステップ１４１４で
は、前記転送を行ったバイト数を前記平分ファイルポイ
ンタ１９０４に加算する。ステップ１４１５では、フッ
クしたファイルリードＩ／Ｏの要求元が要求したサイズ
分のデータを前記要求バッファに転送したかどうかを調
べ、未完了ならばステップ１４１０以下を再び実行し、
完了ならば本ルーチンを終了する。FIG. 14 shows a lead hook routine 1400.
It is a figure which shows the processing flow of. First, step 1401
It is checked whether or not the file handle number included in the read I / O parameter has already been registered in the file handle table 90. If the file handle number has not been registered, it is not a file to be encrypted / decrypted. I / O is executed, and this routine ends. If the file is already registered in the file handle table 90, it is checked in step 1402 whether the open mode 1903 of the file handle table 90 is readable. If the open mode 1903 is not read, the process cannot be continued. An error code is set and this routine ends. Next, step 1403
To obtain the plaintext file pointer 1904. In step 1404, the plaintext file pointer 1904
Of the buffer starting from the buffer pointer 1906 is checked. If it is pointing, the processing is moved to step 1413, and if it is not pointing, step 1405 and subsequent steps are executed. Step 140
In 5, the update flag 1907 is referred to to check whether or not there is update data in the plaintext block buffer 81.
The file pointer No. 02 is moved to the buffer pointer 1906 by a seek command to the OS. In step 1407, the data in the plaintext block buffer 81 is encrypted, transferred to the ciphertext block buffer 82, and written back to the ciphertext file 502. Step 140
In step 8, the update flag 1907 is cleared, and a setting is made to indicate that there is no update data in the plaintext block buffer 81. In step 1409, the file pointer of the actual ciphertext file 502 is moved to the cipher file pointer 1905 by a seek command to the OS. In step 1410, data of the block size is read from the ciphertext file 502 to the ciphertext block buffer 82. In step 1411, the ciphertext file pointer 1905 and the buffer pointer 1906 are updated. In step 1412, the data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. In step 1413, the data is transferred from the plaintext block buffer 81 to the request buffer designated by the application program 23 requesting the hooked file read I / O. In step 1414, the number of transferred bytes is added to the plain file pointer 1904. At step 1415, it is checked whether or not data of the requested size has been transferred to the request buffer by the request source of the hooked file read I / O.
If completed, this routine ends.

【００４７】図１５は、ライトフックルーチン１５００
の処理フローを示す図である。まず、ステップ１５０１
でフックしたライトＩ／Ｏのパラメータに含まれるファ
イルハンドル番号が前記ファイルハンドルテーブル９０
に既に登録されているかどうかを調べ、登録されていな
ければ暗号・復号対象のファイルではないのでステップ
１５２１で通常のファイルリードＩ／Ｏを実行し、本ル
ーチンを終了する。ファイルハンドルテーブル９０に登
録済みの場合は、ステップ１５０２で、前記ファイルハ
ンドルテーブル９０の前記オープンモード１９０３が
「リードライト可」になっているかどうかを調べ、「リ
ードライト可」でなければステップ１５３１でエラーコ
ードを設定して本ルーチンを終了する。「ライト可」だ
けではなく「リードライト可」の必要があるのは、暗号
化のブロック単位よりも小さなサイズの書込に対して
は、不足分のデータをリードした上で暗号化して書き戻
すリードモディファイライト処理が必要なためである。
前記ファイルオープンフックルーチンで「ライト可」を
強制的に「リードライト可」に置き換えてファイルをオ
ープンしておいてもよい。次に、ステップ１５０３で前
記平文ファイルポインタ１９０４を取得する。ステップ
１５０４では、前記平文ファイルポインタ１９０４が、
前記バッファポインタ１９０６から始まるバッファの中
を指し示しているかどうかを調べる。指し示していれば
ステップ１５１３に処理を移し、指し示していなければ
ステップ１５０５以下を実行する。ステップ１５０５で
は前記更新フラグ１９０７を参照し、前記平文ブロック
バッファ８１中に更新データがあるかどうかを調べ、更
新データがなければステップ１５１０に処理を移し、更
新データがあればステップ１５０６で実際の暗号文ファ
イル５０２のファイルポインタをＯＳへのシークコマン
ドによって前記バッファポインタ１９０６へと移動させ
る。ステップ１５０７では、平文ブロックバッファ８１
のデータを暗号化し、暗号文ブロックバッファ８２に転
送すると共に、暗号文ファイル５０２に書き戻す。ステ
ップ１５０８では前記更新フラグ１９０７をクリアし、
前記平文ブロックバッファ８１中に更新データがないこ
とを示すように設定する。ステップ１５０９では、暗号
文ファイル５０２のファイルポインタをＯＳへのシーク
コマンドによって前記暗号ファイルポインタ１９０５が
指し示す位置へと移動させる。ステップ１５１０では、
フックしたファイルライトＩ／Ｏ要求の書込データ領域
が、現在の平文ブロックバッファ８１全体を包含するか
否かを調べる。前記調査の結果全体を包含していない場
合は、不足分を読み出しマージする必要があるので、ス
テップ１５１１で暗号文ブロックバッファ８２のサイズ
分だけ暗号文ファイル５０２をリードする。リードした
データは、前記暗号文ブロックバッファ８２に格納する
と共に、復号化し前記平文ブロックバッファ８１に格納
する。一方、前記ステップ１５１０での調査の結果、全
体を包含していれば不足分を読み出す必要がないのでス
テップ１５１８でステップ１５１１のリードサイズと同
じサイズ分だけシーク処理を行う。ステップ１５１２で
は、暗号文ファイルポインタ１９０５、バッファポイン
タ１９０６を更新する。ステップ１５１３では、平文フ
ァイルポインタ１９０４の指し示す位置から暗号文ファ
イルポインタ１９０５の指し示す位置の手前までのデー
タを、フックしたファイルＩ／Ｏ要求の書込データバッ
ファから平文ブロックバッファ８１に転送する。ステッ
プ１５１４では、平文ブロックバッファ８１の内容が更
新されたことを示す更新フラグ１９０７をセットし、ス
テップ１５１５でフックしたファイルＩ／Ｏライト要求
の全データの転送を完了したかどうかを判定し、完了し
ていなければステップ１５０６以下を完了するまで繰り
返し実行する。以上の処理によって、平文ブロックバッ
ファ８１は、先読みと先復号化キャッシュとして動作
し、且つライトバックキャッシュとして動作するので、
暗号化・復号化によるファイルＩ／Ｏ処理速度の低下を
少なく抑えることができる。FIG. 15 shows a light hook routine 1500.
It is a figure which shows the processing flow of. First, step 1501
The file handle number included in the parameter of the write I / O hooked by the above is stored in the file handle table 90.
It is checked whether or not the file has already been registered. If the file has not been registered, it is not a file to be encrypted / decrypted. Therefore, normal file read I / O is executed in step 1521, and this routine ends. If it is registered in the file handle table 90, it is checked in step 1502 whether the open mode 1903 of the file handle table 90 is set to "read / write enabled". An error code is set and this routine ends. It is necessary to have not only “write enabled” but also “read / write enabled”. For writing smaller than the encryption block unit, read the insufficient data, encrypt it and write it back. This is because a read-modify-write process is required.
The file open hook routine may forcibly replace “write permitted” with “read / write permitted” and open the file. Next, in step 1503, the plaintext file pointer 1904 is obtained. In step 1504, the plaintext file pointer 1904 is
It is checked whether or not the pointer is pointing in the buffer starting from the buffer pointer 1906. If so, the process proceeds to step 1513; otherwise, steps 1505 and subsequent steps are executed. In step 1505, the update flag 1907 is referred to, and it is checked whether or not there is update data in the plaintext block buffer 81. If there is no update data, the process proceeds to step 1510. The file pointer of the statement file 502 is moved to the buffer pointer 1906 by a seek command to the OS. In step 1507, the plaintext block buffer 81
Is transferred to the ciphertext block buffer 82 and written back to the ciphertext file 502. In step 1508, the update flag 1907 is cleared,
A setting is made to indicate that there is no update data in the plaintext block buffer 81. In step 1509, the file pointer of the ciphertext file 502 is moved to the position indicated by the cipher file pointer 1905 by a seek command to the OS. In step 1510,
It is checked whether or not the write data area of the hooked file write I / O request includes the entire current plaintext block buffer 81. If the result of the check does not include the entirety, the shortage is read and merged, so the ciphertext file 502 is read by the size of the ciphertext block buffer 82 in step 1511. The read data is stored in the ciphertext block buffer 82 and decrypted and stored in the plaintext block buffer 81. On the other hand, as a result of the check in the step 1510, if the whole is included, it is not necessary to read the shortage. Therefore, in the step 1518, the seek process is performed for the same size as the read size in the step 1511. In step 1512, the ciphertext file pointer 1905 and the buffer pointer 1906 are updated. In step 1513, the data from the position indicated by the plaintext file pointer 1904 to the position before the position indicated by the ciphertext file pointer 1905 is transferred from the hooked file I / O request write data buffer to the plaintext block buffer 81. In step 1514, an update flag 1907 indicating that the contents of the plaintext block buffer 81 has been updated is set, and it is determined whether or not transfer of all data of the file I / O write request hooked in step 1515 has been completed. If not, the process is repeatedly executed until steps 1506 and subsequent steps are completed. With the above processing, the plaintext block buffer 81 operates as a pre-read and pre-decryption cache and operates as a write-back cache.
A decrease in file I / O processing speed due to encryption / decryption can be reduced.

【００４８】図１６は、クローズフックルーチン１６０
０の処理フローを示す図である。まず、ステップ１６０
１で前記ファイルハンドルテーブル９０に、当該クロー
ズ要求のあったファイルハンドルが登録されているかど
うかを調べ、登録されていなければステップ１６０７に
処理を移行し、ファイルをクローズして終了する。前記
ファイルハンドルテーブル９０に登録済みのファイルで
あった場合には、前記ファイルハンドルテーブル９０の
更新フラグ１９０７を参照し、前記更新フラグ１９０７
がセット、即ちファイルに書き戻されていない更新デー
タが平文ブロックバッファ８１に存在するかどうかを調
べる。前記更新フラグ１９０７がセットされていた場合
には、ステップ１６０３で平文ブロックバッファ８１の
内容を暗号化し、ファイルに書き戻す処理を行う。続く
ステップ１６０４では、前記平文ブロックバッファ８１
を、全て０などのデータを書き込むことによってクリア
し、ステップ１６０５で前記平文ブロックバッファ８１
と前記暗号文ブロックバッファ８２を解放する。ステッ
プ１６０６では、前記ファイルハンドルテーブル９０か
ら当該ファイルのノードを削除し、ステップ１６０７で
ファイルクローズ要求をＯＳに発行し、本ルーチンを終
了する。FIG. 16 shows the close hook routine 160.
FIG. 7 is a diagram showing a processing flow of 0. First, step 160
In step 1, it is checked whether or not the file handle for which the close request has been made is registered in the file handle table 90. If not, the process proceeds to step 1607, the file is closed, and the process ends. If the file has been registered in the file handle table 90, the update flag 1907 of the file handle table 90 is referred to, and the update flag 1907 is referred to.
Is set, that is, whether or not update data not written back to the file exists in the plaintext block buffer 81. If the update flag 1907 has been set, a process of encrypting the contents of the plaintext block buffer 81 and writing it back to the file is performed in step 1603. In the following step 1604, the plaintext block buffer 81
Is cleared by writing data such as all 0s, and the plaintext block buffer 81
Then, the ciphertext block buffer 82 is released. In step 1606, the node of the file is deleted from the file handle table 90, a file close request is issued to the OS in step 1607, and this routine ends.

【００４９】図１７は、ファイルリネームフックルーチ
ン１７００の処理フローを示す図である。まず、ステッ
プ１７０１でリネームの対象がディレクトリファイルか
どうかを判定し、ディレクトリファイルならばステップ
１７２１でリネームを実行し、本ルーチンを終了する。
ディレクトリファイルでなければ、ステップ１７０２で
対象ファイルが暗号ファイルかどうかを判定し、暗号フ
ァイルでなければ前記ステップ１７２１でリネームを実
行し、本ルーチンを終了する。続くステップ１７０３で
は、当該ファイルの復号権限があるか、即ち前記ヘッダ
５０５の宛先リスト４１にログイン中のユーザーのＩＤ
情報２９とマッチする項目が含まれているかどうかを判
定し、復号権限がなければ、ステップ１７１１で権限が
ない旨のメッセージを表示し、ステップ１７１２でエラ
ーコードを設定し本ルーチンを終了する。復号権限があ
る場合は、ステップ１７０４で、当該ファイルのヘッダ
５０５の平文ファイル名５０７を前記アプリケーション
プログラム２３が指示した新名称に変更し、ステップ１
７０５では暗号ファイル情報ファイル９０２に記載され
た当該ファイルの平文ファイル名称を前記ステップ１７
０４と同様に新名称に変更し、本ルーチンを終了する。FIG. 17 is a diagram showing a processing flow of the file rename hook routine 1700. First, in step 1701, it is determined whether or not the target of the rename is a directory file. If the target is a directory file, the rename is executed in step 1721, and this routine ends.
If it is not a directory file, it is determined in step 1702 whether or not the target file is an encrypted file. If it is not an encrypted file, renaming is executed in step 1721 and the routine ends. In the following step 1703, it is determined whether the user has the authority to decrypt the file, that is, the ID of the user who has logged in the destination list 41 of the header 505.
It is determined whether or not an item that matches the information 29 is included. If there is no decryption right, a message indicating that there is no right is displayed in step 1711, an error code is set in step 1712, and this routine ends. If the user has the decryption right, in step 1704, the plain text file name 507 in the header 505 of the file is changed to the new name designated by the application program 23.
In step 705, the plaintext file name of the file described in the encrypted file information file 902 is entered in step 17
Similar to 04, the name is changed to a new name, and this routine ends.

【００５０】以上説明したファイルＩ／Ｏフックプログ
ラム２２の各ルーチンの処理によって、所望のディレク
トリ内のファイルの暗号化・復号化をアプリケーション
プログラム２３からは透過に実現することができる。By the processing of each routine of the file I / O hook program 22 described above, the encryption / decryption of a file in a desired directory can be realized transparently from the application program 23.

【００５１】次に、前記共用ファイル暗号プログラム２
１に含まれる手動ファイル暗号化ルーチン２０００につ
いて図２０を用いて説明する。このルーチンは、暗号化
を行う平文ファイルのファイル名称と、暗号化後の暗号
文ファイル名称と宛先リスト４１を入力として動作す
る。まず、ステップ２００１では、指定された平文ファ
イルをオープンし、ステップ２００２で仮の名称を付け
た一時ファイルを作成する。ステップ２００４では指定
された前記宛先リスト４１を前記ＩＣカード１３０のグ
ループ暗号プログラム２８に与えることによってグルー
プ鍵を生成する。前記生成には前記ＩＣカード１３０へ
のログインが必要であるが，上記の実施例と同様である
のでここでは記述を省略している。ステップ２００５で
は乱数である前記実行鍵４１を生成し、ステップ２００
６で前記ヘッダ５０５を前記一時ファイルの先頭部分に
書き込む。ステップ２００９では、平文ファイルからデ
ータを読み出し、ステップ２０１０で該データを暗号化
し、ステップ２０１１で該暗号化データを一時ファイル
に書き込む。ステップ２０１２では、前記平文ファイル
の全データの暗号化を終了したかどうかを判定し、終了
するまで前記ステップ２００９、２０１０、２０１１を
繰り返し実行するように制御する。ステップ２０１３で
は、前記平文ファイルと前記一時ファイルの両方をクロ
ーズする。ステップ２０１４では、指定された平文ファ
イル名と暗号文ファイル名が同一かどうかを判定し、同
一ならばステップ２０１５で前記平文ファイルを削除す
る。ステップ２０１６では、前記一時ファイルのファイ
ル名称を指定された暗号文ファイル名称に変更し、本プ
ログラムを終了する。Next, the shared file encryption program 2
The manual file encryption routine 2000 included in No. 1 will be described with reference to FIG. This routine operates with the file name of the plaintext file to be encrypted, the encrypted file name after encryption, and the destination list 41 as inputs. First, in step 2001, the designated plaintext file is opened, and in step 2002, a temporary file with a temporary name is created. In step 2004, a group key is generated by giving the designated destination list 41 to the group encryption program 28 of the IC card 130. The generation requires the login to the IC card 130, but since it is the same as the above embodiment, the description thereof is omitted here. In step 2005, the execution key 41, which is a random number, is generated.
In step 6, the header 505 is written to the head of the temporary file. In step 2009, data is read from the plaintext file, the data is encrypted in step 2010, and the encrypted data is written in the temporary file in step 2011. In step 2012, it is determined whether or not encryption of all the data of the plaintext file has been completed, and control is performed so that steps 2009, 2010, and 2011 are repeatedly executed until the encryption is completed. In step 2013, both the plaintext file and the temporary file are closed. In step 2014, it is determined whether or not the designated plaintext file name and the ciphertext file name are the same. In step 2016, the file name of the temporary file is changed to the specified ciphertext file name, and the program ends.

【００５２】次に、ＨＴＭＬファイルの暗号化を行う実
施例について説明する。図２２の２２０１は、平文のＨ
ＴＭＬファイルの一例である。前記ＨＴＭＬファイル
は、ＨＴＭＬブラウザで表示すると図２３に示す画面と
なる。図２４の２４０１は、暗号化したＨＴＭＬファイ
ルの一例であり、リーダ部分２４０２、前記平文のＨＴ
ＭＬファイル２２０１を暗号化した本体部分２４０３、
フッタ部分２４０４を合成したものである。リーダ部分
２４０２の最後はＨＴＭＬでのコメント文開始を示す
「＜！――」が、フッタ部分２４０４の最初はＨＴＭＬ
でのコメント文終了を示す「――＞」が設定されてお
り、前記合成によって本体部分２４０３はコメント文の
内容となる。ＨＴＭＬブラウザによる表示において、前
記コメント文の内容は表示されないので、前記の暗号化
ＨＴＭＬファイル２４０１をＨＴＭＬブラウザで表示し
た結果は、図２５に示すような画面となる。このよう
に、暗号化した結果をコメント文として埋め込むことに
よって、復号化プログラムを具備しないクライアント情
報処理装置１１０で暗号化ファイルを誤って表示した場
合にも、意味のない文字列を画面に表示することを防止
することができる。Next, an embodiment for encrypting an HTML file will be described. Reference numeral 2201 in FIG.
It is an example of a TML file. When the HTML file is displayed by an HTML browser, the screen shown in FIG. 23 is displayed. Reference numeral 2401 in FIG. 24 is an example of an encrypted HTML file, which includes a reader portion 2402 and the plaintext HT.
A main body portion 2403 that is an encrypted ML file 2201,
This is a combination of the footer portion 2404. At the end of the reader part 2402, "<!-", Which indicates the start of a comment sentence in HTML, is displayed at the beginning of the footer part 2404.
"->" Indicating the end of the comment sentence is set, and the main body portion 2403 becomes the content of the comment sentence by the synthesis. Since the content of the comment text is not displayed in the display by the HTML browser, the result of displaying the encrypted HTML file 2401 by the HTML browser is a screen as shown in FIG. By embedding the encrypted result as a comment text, a meaningless character string is displayed on the screen even if the encrypted file is erroneously displayed by the client information processing apparatus 110 having no decryption program. Can be prevented.

【００５３】図２１は、上記のＨＴＭＬファイル暗号化
を行うＨＴＭＬファイル暗号化プログラムの処理フロー
を示す図である。ステップ２１０１では、指定された平
文のＨＴＭＬファイル２２０１をオープンし、ステップ
２１０２で仮の名称を付けた一時ファイルを作成する。
ステップ２１０４では指定された前記宛先リスト４１を
前記ＩＣカード１３０のグループ暗号プログラム２８に
与えることによってグループ鍵を生成する。ステップ２
１０５ではリトライカウンタを初期化し、ステップ２１
０６では乱数である前記実行鍵４１を生成する。ステッ
プ２１０７では前記ヘッダ５０５を前記一時ファイルの
先頭部分に書き込む。ステップ２１０９では、前記リー
ダ部分２４０２を前記一時ファイルの前記ヘッダ５０５
の続きに書き込む。ステップ２１１０では、前記平文の
ＨＴＭＬファイル２２０１からデータを読み出し、ステ
ップ２１１１で該データを暗号化する。ステップ２１１
２では、暗号化後のデータの中に前記コメントの終了文
字列「――＞」がないかどうかを調べ、あればステップ
２１３１以下を実行し、なければステップ２１１３で前
記一時ファイルに前記暗号化後のデータを書き込む。ス
テップ２１１４では、前記平文のＨＴＭＬファイル２２
０１の全データの暗号化を終了したかどうかを判定し、
終了するまで前記ステップ２１１０、２１１１、２１１
２、２１１３を繰り返し実行するように制御する。ステ
ップ２１１５では、前記フッタ部分２４０４を前記一時
ファイルに書き込み、ステップ２１１６で前記平文のＨ
ＴＭＬファイル２２０１と前記一時ファイルの両方をク
ローズする。ステップ２１１７では、指定された平文の
ＨＴＭＬファイル名と暗号化後のＨＴＭＬファイル名が
同一かどうかを判定し、同一ならばステップ２１１８で
前記平文のＨＴＭＬファイル２２０１を削除する。ステ
ップ２１１９では、前記一時ファイルのファイル名称を
指定された暗号化後のＨＴＭＬファイル名称に変更し、
本プログラムを終了する。一方、前記ステップ２１１２
において、暗号化後のデータの中に前記コメントの終了
文字列「――＞」あると判定された場合は、ステップ２
１３１で前記一時ファイルに書き込んだ内容をクリアす
る。次に、ステップ２１３２で前記リトライカウンタを
カウントアップし、ステップ２１３３で前記リトライカ
ウンタが予め設定した上限値（本実施例では１０回とし
た）を越えていないかを検査し、越えていなければステ
ップ２１０６からの部分を再度実行する。この再実行で
は、前記ステップ２１０６で前回とは異なる乱数が実行
鍵６１として使われるので、前記ステップ２１１１の暗
号化で再び前記コメントの終了文字列「――＞」が現れ
る確率はかなり低い。それにも拘わらず、前記上限値を
越えてしまった場合は、ステップ２１３４で前記平文の
ＨＴＭＬファイル２２０１と前記一時ファイルの両方を
クローズする。さらにステップ２１１５で前記一時ファ
イルを削除し、ステップ２１３６でエラーメッセージを
表示し、本プログラムを終了する。なお、暗号化したデ
ータはランダムな値となるので、前記コメントの終了文
字列「――＞」が現れる確率は、一文字は１バイト（＝
８ビット）で表現されるので「（２の８乗）の３乗」分
の１、即ち１６７７７２１６分の１である。言い換えれ
ば約１６Ｍバイトのデータに一回起こる程度ということ
である。したがって、上述のように実行鍵６１を替えて
リトライする制御を組み込んでおけば、実用上全く問題
がないことが判る。また、前記コメントの終了文字列
「――＞」が前記本体部分２４０３に出現することを避
ける別の手段として、暗号化したデータを１６進表示に
よるテキスト文字列として格納することもできる。FIG. 21 is a diagram showing a processing flow of the HTML file encryption program for performing the above HTML file encryption. In step 2101, the designated plaintext HTML file 2201 is opened, and in step 2102, a temporary file with a temporary name is created.
At step 2104, the specified destination list 41 is given to the group encryption program 28 of the IC card 130 to generate a group key. Step 2
At 105, the retry counter is initialized, and step 21
At 06, the execution key 41 which is a random number is generated. In step 2107, the header 505 is written at the head of the temporary file. In step 2109, the reader portion 2402 is transferred to the header 505 of the temporary file.
Write in the continuation of. In step 2110, data is read from the plaintext HTML file 2201, and in step 2111 the data is encrypted. Step 211
In step 2, it is checked whether or not the comment end character string "->" is present in the encrypted data, and if there is, the steps from step 2131 and thereafter are executed. Write later data. In step 2114, the plain text HTML file 22
It is judged whether the encryption of all data of 01 is completed,
Until the end, the steps 2110, 2111, 211
Control is performed so that steps 2 and 2113 are repeatedly executed. In step 2115, the footer portion 2404 is written in the temporary file, and in step 2116, the plain text H
Both the TML file 2201 and the temporary file are closed. In step 2117, it is judged whether or not the designated plain text HTML file name and the encrypted HTML file name are the same, and if they are the same, the plain text HTML file 2201 is deleted in step 2118. In step 2119, the file name of the temporary file is changed to the specified encrypted HTML file name,
Exit this program. On the other hand, the step 2112
If it is determined that the end character string "->" of the comment is included in the encrypted data in step 2, step 2
At 131, the contents written in the temporary file are cleared. Next, in step 2132, the retry counter is counted up, and in step 2133, it is checked whether the retry counter exceeds the preset upper limit value (10 times in this embodiment). The portion from 2106 is executed again. In this re-execution, since the random number different from the previous time is used as the execution key 61 in the step 2106, the probability that the end character string “—>” of the comment appears again in the encryption in the step 2111 is considerably low. Nevertheless, if the upper limit is exceeded, both the plaintext HTML file 2201 and the temporary file are closed in step 2134. Further, the temporary file is deleted in step 2115, an error message is displayed in step 2136, and the program ends. Since the encrypted data has a random value, the probability that the end character string "->" of the comment will appear is that one character is 1 byte (=
Since it is represented by 8 bits, it is 1 / (the cube of (2 8)), that is, 1 / 677,216. In other words, it occurs only once for about 16 Mbytes of data. Therefore, if the control for changing the execution key 61 and retrying is incorporated as described above, there is no problem in practical use. Further, as another means for preventing the end character string “—>” of the comment from appearing in the main body portion 2403, the encrypted data can be stored as a text character string in hexadecimal display.

【００５４】この方法で作成した暗号化ＨＴＭＬファイ
ルを図２６に示す。ただし、この方法では、１バイトの
データを表現するために２文字即ち２バイトが必要であ
り、データ量が倍になってしまうという問題もある。FIG. 26 shows an encrypted HTML file created by this method. However, in this method, two characters, that is, two bytes are required to represent one-byte data, and there is a problem that the data amount is doubled.

【００５５】本実施例では、ＨＴＭＬで記述されたドキ
ュメントファイルについて述べたが、解釈時に無視され
るコメント文を記述するための書式を備えた文法であれ
ば同様に本発明を適用することができることは明らかで
ある。In the present embodiment, the document file described in HTML has been described, but the present invention can be similarly applied to any grammar having a format for describing a comment sentence that is ignored during interpretation. Is clear.

【００５６】[0056]

【実施例】以下、本発明をインターネットに用いた場合
の実施例を図を用いて説明する。まず、全体のシステム
構成を説明する。図１は、本発明の暗号ファイル受信シ
ステム及びその制御方法の一構成例である。１１０はク
ライアント情報処理装置、１２０はサーバ情報処理装置
である。DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment in which the present invention is applied to the Internet will be described below with reference to the drawings. First, the overall system configuration will be described. FIG. 1 is a configuration example of an encrypted file receiving system and a control method thereof according to the present invention. 110 is a client information processing device, and 120 is a server information processing device.

【００５７】サーバ情報処理装置１２０には、中央処理
装置（ＣＰＵ）１ｂ、メモリ２ｂ、ＬＡＮコントローラ
３ｂ、ディスクコントローラ４ｂ、磁気ディスク５ｂが
具備されている。サーバ情報処理装置１２０の起動時に
は、オペレーティングシステム（ＯＳ）２０ｂと、ＷＷ
Ｗ（Ｗｏｒｌｄ−Ｗｉｄｅ Ｗｅｂ）サーバプログラム
２６、および共用ファイル暗号プログラム２１ｂが、デ
ィスクコントローラ４ｂを介して磁気ディスク５ｂから
メモリ２ｂ上にロードされる。クライアント情報処理装
置１１０には、ＣＰＵ１ａ、メモリ２ａ、ＬＡＮコント
ローラ３ａ、ディスクコントローラ４ａ、磁気ディスク
５ａ、ＩＣカードコントローラ６がそれぞれ具備されて
いる。クライアント情報処理装置１１０の起動時には、
ＯＳ２０ａ、共用ファイル暗号プログラム２１ａ、通信
ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎ
ｔｅｒｆａｃｅ）フックプログラム２７が、前記ディス
クコントローラ４ａを介して前記磁気ディスク５ａから
前記メモリ２ａ上にロードされる。また、ブラウザプロ
グラム１９は、前記クライアント情報処理装置１１０の
ユーザー（以下単にユーザーと呼ぶ）の指示によって前
記ディスクコントローラ４ａを介して前記磁気ディスク
５ａから前記メモリ２ａ上にロードされる。前記通信Ａ
ＰＩフックプログラム２７は、ブラウザプログラム１９
が前記ＯＳ２０ａに発行する通信ＡＰＩをフック（横取
り）し、受信ファイルデータの復号化をバックグラウン
ドで自動的に行うものである。The server information processing device 120 includes a central processing unit (CPU) 1b, a memory 2b, a LAN controller 3b, a disk controller 4b, and a magnetic disk 5b. When the server information processing device 120 is started, the operating system (OS) 20b and the WW
The W (World-Wide Web) server program 26 and the shared file encryption program 21b are loaded from the magnetic disk 5b onto the memory 2b via the disk controller 4b. The client information processing device 110 includes a CPU 1a, a memory 2a, a LAN controller 3a, a disk controller 4a, a magnetic disk 5a, and an IC card controller 6, respectively. When the client information processing device 110 is started,
OS 20a, shared file encryption program 21a, communication API (Application Program In)
interface) hook program 27 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a. The browser program 19 is loaded from the magnetic disk 5a onto the memory 2a via the disk controller 4a according to an instruction from a user of the client information processing apparatus 110 (hereinafter simply referred to as a user). Communication A
The PI hook program 27 is the browser program 19
Hooks the communication API issued to the OS 20a, and automatically decrypts the received file data in the background.

【００５８】前記サーバ情報処理装置１２０と前記クラ
イアント情報処理装置１１０は、ローカルエリアネット
ワーク（ＬＡＮ）１０１を介して相互に接続されてお
り、各々のＬＡＮコントローラ３を介して通信を行う。
なお、前記サーバ情報処理装置１２０と前記クライアン
ト情報処理装置１１０は互いに遠隔地に存在し、電話回
線や専用回線を介して接続されていてもよい。The server information processing device 120 and the client information processing device 110 are connected to each other via a local area network (LAN) 101, and communicate with each other via each LAN controller 3.
The server information processing device 120 and the client information processing device 110 may be located at remote locations from each other, and may be connected via a telephone line or a dedicated line.

【００５９】図２８では一台のクライアント情報処理装
置１１０を示したが、実際には、同じ構成のクライアン
ト情報処理装置１１０が複数前記ＬＡＮ１０１に接続さ
れており、これらのクライアント情報処理装置１１０間
で、前記サーバ情報処理装置１２０の前記磁気ディスク
５ｂに格納されたＨＴＭＬファイルやイメージデータフ
ァイルを共用する。ユーザーは前記共用を行うため、前
記ブラウザプログラム１９を使用して前記磁気ディスク
５ｂ上のファイルをアクセスする。なお、前記ＨＴＭＬ
ファイルやイメージデータファイルは、前記サーバ情報
処理装置１２０上で作成して前記磁気ディスク５ｂに格
納しても良いし、クライアント情報処理装置１１０上で
作成してから磁気ディスク５ｂに格納しても良い。ま
た、クライアント情報処理装置１１０のＩＣカードコン
トローラ６は、ＩＣカード１３０が脱着可能となってい
る。前記ＩＣカード１３０内には、ＣＰＵ１ｃ、不揮発
性メモリ７、入出力インタフェース８が具備されてい
る。前記不揮発性メモリ７には、アクセス制御プログラ
ム３０、グループ暗号プログラム２８、ＩＤ情報２９、
マスタ鍵３１が書き込まれている。前記不揮発性メモリ
７の内容は、前記入出力インタフェース８を介して外部
からアクセスすることができる。ただし、不正なアクセ
スから前記不揮発性メモリ７の記憶内容を保護する為、
前記ＣＰＵ１ｃによるユーザー認証制御が必ず介在する
仕組みとなっている。In FIG. 28, one client information processing device 110 is shown, but in reality, a plurality of client information processing devices 110 having the same configuration are connected to the LAN 101, and these client information processing devices 110 are connected to each other. , HTML files and image data files stored in the magnetic disk 5b of the server information processing device 120 are shared. The user accesses the file on the magnetic disk 5b using the browser program 19 to perform the sharing. In addition, the HTML
The file or image data file may be created on the server information processing device 120 and stored on the magnetic disk 5b, or may be created on the client information processing device 110 and then stored on the magnetic disk 5b. . Further, the IC card 130 of the client information processing apparatus 110 can be attached / detached. The IC card 130 includes a CPU 1c, a non-volatile memory 7, and an input / output interface 8. The non-volatile memory 7 includes an access control program 30, a group encryption program 28, ID information 29,
The master key 31 is written. The contents of the non-volatile memory 7 can be externally accessed via the input / output interface 8. However, in order to protect the contents stored in the nonvolatile memory 7 from unauthorized access,
The user authentication control by the CPU 1c is necessarily interposed.

【００６０】図２９は、前記共用ファイル暗号プログラ
ム２１と前記通信ＡＰＩフックプログラム２７を構成す
るプログラムルーチンを示す図である。前記共用ファイ
ル暗号プログラム２１は、前記ＩＣカード１３０へのロ
グイン、ログアウトを行うログイン制御ルーチン１００
０、ログアウト制御ルーチン１１００、ユーザーがファ
イルの暗号化をその都度明示的に指示し暗号化する手動
ファイル暗号化ルーチン２０００、前記手動ファイル暗
号化をＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ
Ｌａｎｇｕａｇｅ）で記述した共用ファイル向けにア
レンジしたＨＴＭＬファイル暗号化ルーチン２１００か
ら構成される。前記通信ＡＰＩフックプログラム２７
は、ｓｅｎｄフックルーチン１８００、ｒｅｃｖフック
ルーチン１８１０、ｃｌｏｓｅ ｓｏｃｋｅｔフックル
ーチン１８２０から構成される。FIG. 29 is a diagram showing a program routine constituting the shared file encryption program 21 and the communication API hook program 27. The shared file encryption program 21 includes a login control routine 100 for logging in and out of the IC card 130.
0, a logout control routine 1100, a manual file encryption routine 2000 in which a user explicitly instructs and encrypts a file each time, and the manual file encryption is performed by HTML (Hyper Text Markup).
It is composed of an HTML file encryption routine 2100 arranged for a shared file described in the Language). The communication API hook program 27
Is composed of a send hook routine 1800, a recv hook routine 1810, and a close socket hook routine 1820.

【００６１】前記ＩＤ情報２９の内容は前記第１の実施
例における図２に示したＩＤ情報２９と同じである。こ
こでは、カテゴリ毎の内容を示すデータとそのコードを
１０組まで登録できるようになっている。実際に前記不
揮発性メモリ７に記憶するのは、データとコードの値だ
けである。The contents of the ID information 29 are the same as the ID information 29 shown in FIG. 2 in the first embodiment. Here, up to 10 sets of data indicating the contents of each category and their codes can be registered. What is actually stored in the nonvolatile memory 7 is only the data and code values.

【００６２】次に、上記グループ暗号プログラム２８の
動作は前記実施例におけるグループ暗号プログラム２８
の動作と、宛先リストのハッシュ値を計算し前記グルー
プ鍵５１を作成する手順は前記実施例における図３に示
した手順とそれぞれ同じである。前記ＩＣカード１３０
内の前記グループ暗号プログラム２８の処理内容は前記
実施例における図４に示したフロー図と同じである。以
上説明したグループ鍵５１を用いてデータを暗号化する
ことによって、前記宛先リスト４１に含まれるＩＤ情報
２９を持つ者だけが該データの復号化を可能とすること
ができる。Next, the operation of the group encryption program 28 will be described below.
And the procedure for calculating the hash value of the destination list and creating the group key 51 are the same as the procedure shown in FIG. 3 in the embodiment. The IC card 130
The processing content of the group encryption program 28 in the above is the same as the flow chart shown in FIG. 4 in the embodiment. By encrypting the data using the group key 51 described above, only the person having the ID information 29 included in the destination list 41 can decrypt the data.

【００６３】次に、上述のグループ暗号をファイルの暗
号に適用した例について説明する。図３０は、ファイル
の暗号化手順と暗号化後のファイルの構成を示す図であ
る。図５に示した例とは、暗号化後のファイル５０２の
ヘッダ５０５の内容が相違している。すなわち、５０１
は暗号化する前の平文ファイル、５０２は暗号化後の暗
号ファイルである。６１は乱数として生成された実効
鍵、５０４は前記実効鍵６１を鍵として前記ファイル５
０１の内容を暗号化した暗号文データ、５０５は暗号文
データ５０４に付加するヘッダ、５０６から５１１は前
記ヘッダ５０５の内容であり、５０６は使用した暗号化
方式を示す文字列、５０９は前記実効鍵６１をグループ
鍵５１で暗号化した暗号化実効鍵、５１１は前記宛先リ
スト４１を前記マスタ鍵３１で暗号化した暗号化宛先リ
スト、５１０は前記暗号化宛先リスト５１１のサイズで
ある。前記暗号ファイル５０２は、図３１に示すように
上記手順と全く逆の手順で復号化することができる。Next, an example in which the above-mentioned group cipher is applied to the cipher of a file will be described. FIG. 30 is a diagram showing a file encryption procedure and a file structure after encryption. The content of the header 505 of the encrypted file 502 is different from the example shown in FIG. That is, 501
Is a plaintext file before encryption, and 502 is an encrypted file after encryption. 61 is an effective key generated as a random number, and 504 is the file 5 using the effective key 61 as a key.
The ciphertext data obtained by encrypting the contents of 01, 505 is a header added to the ciphertext data 504, 506 to 511 are the contents of the header 505, 506 is a character string indicating the encryption method used, and 509 is the effective An encrypted effective key 511 obtained by encrypting the key 61 with the group key 51, an encrypted destination list 511 obtained by encrypting the destination list 41 with the master key 31, and a size 510 of the encrypted destination list 511. The cipher file 502 can be decrypted by a procedure completely opposite to the above procedure as shown in FIG.

【００６４】上述のファイル暗号化においては、前記グ
ループ鍵５１は前記実効鍵６１を暗号化する為に用い、
ファイルデータの暗号化には前記実効鍵６１を用いた。
したがって、前記宛先リスト４１を変更する場合には、
まず前記実効鍵６１を変更前の前記宛先リスト４１で生
成した前記グループ鍵５１で復号化し、次に変更後の前
記宛先リスト４１から生成した前記グループ鍵５１で再
暗号化すればよい。これにより、前記宛先リスト４１の
変更時にも前記実効鍵６１に比べデータ量の多いファイ
ルデータは再暗号化が不要とすることができ、変更処理
を高速に行うことができる。In the above file encryption, the group key 51 is used to encrypt the effective key 61,
The effective key 61 was used to encrypt the file data.
Therefore, when changing the destination list 41,
First, the effective key 61 may be decrypted by the group key 51 generated by the destination list 41 before the change, and then re-encrypted by the group key 51 generated by the destination list 41 after the change. As a result, even when the destination list 41 is changed, re-encryption of the file data having a larger data amount than the effective key 61 can be eliminated, and the change process can be performed at high speed.

【００６５】次に、共用ファイル暗号プログラム２１内
のログイン処理ルーチン１０００、ログアウト処理ルー
チン１１００について説明する。前記ＩＣカード１３０
へのログイン処理ルーチン１０００の処理フローは、図
１０に示した第１の実施例におけるログイン処理ルーチ
ン１０００と同じであり、詳細な説明は省略する。タイ
マイベントを用いて定期的に前記ＩＣカード１３０の接
続を調べることによって前記ＩＣカード１３０を抜いた
際のログアウト処理を自動化することができる。Next, the login processing routine 1000 and the logout processing routine 1100 in the shared file encryption program 21 will be described. The IC card 130
The processing flow of the login processing routine 1000 for login is the same as that of the login processing routine 1000 in the first embodiment shown in FIG. 10, and detailed description thereof will be omitted. By periodically checking the connection of the IC card 130 using a timer event, the logout process when the IC card 130 is removed can be automated.

【００６６】前記ＩＣカード１３０からのログアウト処
理ルーチン１１００の処理フローは、図１１に示した第
１の実施例におけるログアウト処理ルーチン１１００と
同じであり、詳細な説明は省略する。The processing flow of the logout processing routine 1100 from the IC card 130 is the same as that of the logout processing routine 1100 in the first embodiment shown in FIG. 11, and detailed description thereof will be omitted.

【００６７】図３２は、本実施例のファイル暗号化・復
号化におけるデータの入出力方法を示す図である。前記
暗号ファイル５０２の前記暗号文データ５０４は、暗号
文ブロックバッファ８２のサイズ単位で前記暗号文ブロ
ックバッファ８２との間で読み出し・書き込みが行われ
る。前記暗号文ブロックバッファ８２のデータは復号化
し平文ブロックバッファ８１に転送される。また、前記
平文ブロックバッファ８１のデータは暗号化し前記暗号
文ブロックバッファ８２に転送される。この入出力方法
が図１８に示した入出力方法と異なる点は、バッファ長
が１０２４ｂｙｔｅから２５６ｂｙｔｅとして示されて
いる点である。FIG. 32 is a diagram showing a data input / output method in file encryption / decryption of this embodiment. The ciphertext data 504 of the ciphertext file 502 is read / written with the ciphertext block buffer 82 in units of the size of the ciphertext block buffer 82. The data in the ciphertext block buffer 82 is decrypted and transferred to the plaintext block buffer 81. The data in the plaintext block buffer 81 is encrypted and transferred to the ciphertext block buffer 82. This input / output method is different from the input / output method shown in FIG. 18 in that the buffer length is shown from 1024 bytes to 256 bytes.

【００６８】次に、前記共用ファイル暗号プログラム２
１に含まれる手動ファイル暗号化ルーチン２０００につ
いて説明する。このルーチンは、暗号化を行う平文ファ
イルのファイル名称と、暗号化後の暗号ファイル名称と
宛先リスト４１を入力として動作する。この処理は、図
２０に示したファイル暗号化ルーチン２０００と略同じ
であり、詳細な説明を省略する。Next, the shared file encryption program 2
The manual file encryption routine 2000 included in 1 will be described. This routine operates by inputting the file name of the plaintext file to be encrypted, the encrypted file name after encryption, and the destination list 41. This process is substantially the same as the file encryption routine 2000 shown in FIG. 20, and detailed description thereof will be omitted.

【００６９】次に、ＨＴＭＬファイルの暗号化を行う実
施例について説明する。この実施例においても、平文の
ＨＴＭＬファイルおよびブラウザでの表示ならびに暗号
化したＨＴＭＬファイルなどは、実施例１の図２２〜図
２６に示した例と同じであり、その詳細な説明を省略す
る。Next, an embodiment for encrypting an HTML file will be described. Also in this embodiment, the plain text HTML file, the display on the browser, the encrypted HTML file, and the like are the same as those in the first embodiment shown in FIGS.

【００７０】上記のＨＴＭＬファイル暗号化を行うＨＴ
ＭＬファイル暗号化プログラムの処理フローは実施例１
の図２１に示した処理フローと同じであり、詳細な説明
を省略する。この方法で作成した暗号化ＨＴＭＬファイ
ルは図２６に示したものと同じである。以上の暗号化処
理を施したファイルは、情報提供者によって前記サーバ
情報処理装置の磁気ディスク５ｂに格納される。HT for performing the above HTML file encryption
The processing flow of the ML file encryption program is the first embodiment.
21 is the same as the processing flow shown in FIG. 21, and detailed description thereof will be omitted. The encrypted HTML file created by this method is the same as that shown in FIG. The file that has been subjected to the above-described encryption processing is stored in the magnetic disk 5b of the server information processing apparatus by the information provider.

【００７１】次に、前記ブラウザプログラム１９が、Ｗ
ＷＷサーバプログラム２６から前記暗号ファイルを受信
する際の通信ＡＰＩフックプログラム２７の処理につい
て説明する。まず、受信ファイルデータの入出力とその
管理方法から説明する。図３３は、本実施例における受
信ファイル復号化の際のデータ入出力を示す図である。
８３は、ブラウザプログラム１９が用意する暗号文受信
バッファであり、暗号文が含まれている。通信ＡＰＩフ
ックモジュールは、後述するｒｅｃｖフック処理の中
で、受信した前記暗号文を暗号文ブロックバッファ８２
にコピーする。このとき、暗号文ブロックバッファ８２
が満たされた場合、該暗号文の復号化処理を実行し平文
を平文ブロックバッファ８１にコピーする。さらに、平
文をブラウザ２３へ渡すために、前記平文ブロックバッ
ファ８１の中身を前記暗号文受信バッファに上書きコピ
ーする。暗号文受信バッファ８３から暗号文ブロックバ
ッファ８２へコピーした暗号文が、前記暗号文ブロック
バッファ８２を満たしていない場合は、復号化処理を行
わずに次の受信ファイルデータを待つ。以後、受信した
暗号ファイルデータの前記暗号文ブロックバッファ８２
へのコピー、前記復号化処理と平文ブロックバッファ８
１へのコピー、および暗号文受信バッファ８３への平文
コピーを、受信した暗号ファイルデータがなくなるまで
繰り返す。Next, the browser program 19
The processing of the communication API hook program 27 when receiving the encrypted file from the WW server program 26 will be described. First, input / output of received file data and a management method thereof will be described. FIG. 33 is a diagram showing data input / output at the time of decrypting a received file in the present embodiment.
Reference numeral 83 is a ciphertext reception buffer prepared by the browser program 19 and contains a ciphertext. The communication API hook module processes the received ciphertext in the ciphertext block buffer 82 in the recv hook process described later.
Copy to At this time, the ciphertext block buffer 82
If is satisfied, the decryption processing of the ciphertext is executed and the plaintext is copied to the plaintext block buffer 81. Further, in order to pass the plaintext to the browser 23, the content of the plaintext block buffer 81 is overwritten and copied to the ciphertext reception buffer. When the ciphertext copied from the ciphertext reception buffer 83 to the ciphertext block buffer 82 does not fill the ciphertext block buffer 82, the decryption processing is not performed and the next reception file data is waited for. After that, the ciphertext block buffer 82 of the received ciphertext file data
Copy to, decryption process and plaintext block buffer 8
The copy to 1 and the plaintext copy to the ciphertext reception buffer 83 are repeated until there is no received cipher file data.

【００７２】図３４は、オープン中のソケットを管理す
るためのソケット情報テーブル９１である。ソケット情
報テーブル９１は、ソケット記述子１９１２、受信フラ
グ１９１３、受信データポインタ１９１４、暗号化実効
鍵５０９、暗号化宛先リストのサイズ５１０、暗号化宛
先リスト５１１、グループ鍵５１、実効鍵６１、暗号文
ブロックバッファポインタ１９１５、平文ブロックバッ
ファポインタ１９１６の各情報を、オープン中の各ソケ
ット毎にポインタ１９０１を用いてリスト構造で記憶し
ている。ここでソケット記述子１９１２は、ソケットを
オープンした際に前記ＯＳ２０から与えられる管理番号
である。受信フラグ１９１３とは、前記ソケット記述子
１９１２を使用して暗号ファイルのデータを１度も受信
していない場合には”０”、暗号ファイルのデータを１
回以上受信した場合には”１”とするフラグである。前
記受信データポインタ１９１４は、受信したファイルデ
ータから暗号文を読み込む際の起点を示すものであり、
後述するｒｅｃｖフックルーチン１８１０が、データ受
信時に受信バッファの先頭アドレスを登録する。暗号文
ブロックバッファポインタ１９１５と平文ブロックバッ
ファポインタ１９１６は、それぞれ図３３における暗号
文ブロックバッファ８２と平文ブロックバッファ８１へ
のポインタであり、復号化処理時にバッファ間で暗号文
や平文をコピーする際の起点となるものである。また、
前記暗号化実効鍵５０９と前記暗号化宛先リストサイズ
５１０、および暗号化宛先リスト５１１は、暗号ファイ
ル受信時に前記ヘッダー５０５から読み込んで登録す
る。なお、該暗号化宛先リスト５１１は、図６に示すよ
うにマスタ鍵によって復号化される。更に、該宛先リス
ト４１からグループ鍵５１を生成し、また前記暗号化実
効鍵５０９を前記グループ鍵５１で復号化して実効鍵６
１を求め、それぞれソケット情報テーブル９１に登録す
る。FIG. 34 shows a socket information table 91 for managing open sockets. The socket information table 91 includes a socket descriptor 1912, a reception flag 1913, a reception data pointer 1914, an encrypted effective key 509, an encrypted destination list size 510, an encrypted destination list 511, a group key 51, an effective key 61, and a ciphertext. Each information of the block buffer pointer 1915 and the plaintext block buffer pointer 1916 is stored in a list structure by using the pointer 1901 for each open socket. Here, the socket descriptor 1912 is a management number given by the OS 20 when the socket is opened. The reception flag 1913 is "0" when the data of the encrypted file has never been received using the socket descriptor 1912, and the data of the encrypted file is 1
This flag is set to "1" when received more than once. The received data pointer 1914 indicates the starting point when reading a ciphertext from the received file data,
A recv hook routine 1810, which will be described later, registers the start address of the reception buffer when receiving data. The ciphertext block buffer pointer 1915 and the plaintext block buffer pointer 1916 are pointers to the ciphertext block buffer 82 and the plaintext block buffer 81 in FIG. 33, respectively, and are used when a ciphertext or a plaintext is copied between the buffers during decryption processing. It is the starting point. Also,
The encrypted effective key 509, the encrypted destination list size 510, and the encrypted destination list 511 are read from the header 505 and registered when the encrypted file is received. The encrypted destination list 511 is decrypted by the master key as shown in FIG. Further, the group key 51 is generated from the destination list 41, and the encrypted effective key 509 is decrypted by the group key 51 to obtain the effective key 6
1 is obtained and registered in the socket information table 91, respectively.

【００７３】次に、前記通信ＡＰＩフックプログラム２
７内の各ルーチンの処理について説明する。図３５は、
前記ｓｅｎｄフックルーチン１８００の処理フローを示
す図である。まず、ステップ１８０１で、ブラウザプロ
グラム１９がＷＷＷサーバプログラム２６へ送信するデ
ータ中にファイル取得用コマンドである”ＧＥＴ”が存
在するか否かを調べる。存在すればステップ１８０４で
前記ソケット情報テーブル９１を参照し、フックしたソ
ケットの記述子が登録されているか否かを調べる。登録
されていれば、ステップ１８０６で該当するソケット情
報のうち、受信フラグ１９１３を”０”にして、ステッ
プ１８０７のｓｅｎｄ処理を行う。登録されていない場
合、ステップ１８０５でソケット情報をテーブル９０に
登録する。前記ステップ１８０１で、送信データ中に前
記ファイル取得用コマンドが存在しなければ、フックし
たソケットの記述子が前記ソケット情報テーブルに登録
されているか否かをステップ１８０２で調べる。登録さ
れていれば、ステップ１８０３で該当するソケット情報
を削除する。登録されていなければ、ステップ１８０７
でｓｅｎｄ処理を実行する。次に、ステップ１８０８で
ｓｅｎｄ処理のエラーが発生し、かつステップ１８０９
で該当するソケット情報がテーブルに登録済みの場合
は、ステップ１８１０で該当するソケット情報を前記ソ
ケット情報テーブル９１から削除し、ステップ１８１１
で前記ブラウザプログラム１９にリターンする。前記ス
テップ１８０８でエラーが発生しなければ、なにもせず
にステップ１８１１で前記ブラウザプログラム１９にリ
ターンする。Next, the communication API hook program 2
The processing of each routine in 7 will be described. FIG. 35 shows
FIG. 14 is a diagram showing a processing flow of the send hook routine 1800. First, in step 1801, it is checked whether or not the file acquisition command “GET” is present in the data transmitted by the browser program 19 to the WWW server program 26. If there is, in step 1804, the socket information table 91 is referred to to check whether the descriptor of the hooked socket is registered. If registered, in step 1806, the reception flag 1913 of the corresponding socket information is set to "0", and the send process of step 1807 is performed. If not registered, the socket information is registered in the table 90 in step 1805. If the file acquisition command does not exist in the transmission data in step 1801, it is checked in step 1802 whether or not the descriptor of the hooked socket is registered in the socket information table. If registered, the corresponding socket information is deleted in step 1803. If not registered, step 1807
Executes send processing. Next, in step 1808, an error in the send process occurs, and
If the corresponding socket information is already registered in the table in step 1810, the corresponding socket information is deleted from the socket information table 91 in step 1810, and
Returns to the browser program 19. If no error occurs in step 1808, the process returns to the browser program 19 in step 1811 without doing anything.

【００７４】図３６は、ｒｅｃｖフックルーチン１８２
０の処理フローを示す図である。まず、ステップ１８２
１でブラウザプログラム１９がコールしたｒｅｃｖの処
理を行い、ステップ１８２２で前記ｒｅｃｖ処理のエラ
ーチェックを行う。このときエラーが発生した場合、ス
テップ１８３５で前記エラーを前記ブラウザプログラム
１９にリターンする。なお、エラーに関するメッセージ
は前記ブラウザプログラム１９が表示するので、ｒｅｃ
ｖフックルーチン１８１０がエラーメッセージを表示す
る必要はない。エラーなしの場合は、ステップ１８２３
でソケットの記述子が前記ソケット情報テーブル９１に
登録済みであるかどうかを調べる。ここで、ｓｅｎｄフ
ックルーチンの中でソケット情報テーブル９１に登録さ
れたソケット記述子は、ＷＷＷサーバ２６が管理するＨ
ＴＭＬファイルやイメージデータファイルの受信に使用
するソケットを指す。そこで、ソケット情報テーブル９
１に登録済みの場合はステップ１８２４で受信データの
有無をチェックする。登録されてない場合は、ステップ
１８３５で受信データをブラウザプログラム１９にリタ
ーンする。ステップ１８２４で受信データが存在しない
場合は、データの受信が完了したことを意味するので、
該当するソケット情報を前記ソケット情報テーブル９１
から削除し、ステップ１８３５で前記ブラウザプログラ
ム１９にリターンする。受信データが存在する場合は、
ステップ１８２５でｒｅｃｖフラグをチェックする。前
記ｒｅｃｖフラグが”０”であれば、前記ｓｅｎｄ処理
に対する１回目の受信データであると判断し、ステップ
１８２６で前記受信データをチェックする。ステップ１
８２７で、受信データが本発明の暗号化方式により暗号
化されたファイルである場合、ステップ１８２８でログ
イン中のユーザーが存在するかチェックする。存在しな
い場合は、ステップ１８３８でメッセージ１８３７を表
示する。存在する場合は、ステップ１８２９で宛先リス
トに、前記ログインユーザーが含まれているかを調べ
る。前記ログインユーザーが含まれている場合は、ステ
ップ１８３０で前記ｒｅｃｖフラグを”１”に設定し、
ステップ１８３２で前記受信ファイルデータを復号化す
る。一方、前記宛先リストに前記ログインユーザーが含
まれていない場合は、ステップ１８３１でメッセージ１
８３６を表示し、ステップ１８３４でソケット情報を前
記ソケット情報テーブル９１から削除してリターンす
る。一方、前記ステップ１８２７で、受信ファイルデー
タが暗号化されていない場合は、ステップ１８３４でソ
ケット情報を前記ソケット情報テーブルから削除してリ
ターンする。FIG. 36 shows the recv hook routine 182.
FIG. 7 is a diagram showing a processing flow of 0. First, step 182
In step 1, the recv process called by the browser program 19 is processed, and in step 1822, an error check of the recv process is performed. If an error occurs at this time, the error is returned to the browser program 19 in step 1835. Since a message about the error is displayed by the browser program 19, rec
The vhook routine 1810 need not display an error message. If there is no error, step 1823
To check whether the socket descriptor has already been registered in the socket information table 91. Here, the socket descriptor registered in the socket information table 91 in the send hook routine is the H descriptor managed by the WWW server 26.
Refers to the socket used to receive TML files and image data files. Therefore, the socket information table 9
If it is already registered in step 1, it is checked in step 1824 whether or not there is received data. If not registered, the received data is returned to the browser program 19 in step 1835. If the received data does not exist in step 1824, it means that the reception of the data is completed.
The corresponding socket information is stored in the socket information table 91.
, And returns to the browser program 19 in step 1835. If there is received data,
In step 1825, the recv flag is checked. If the recv flag is “0”, it is determined that the received data is the first received data for the send process, and the received data is checked in step 1826. Step 1
If the received data is a file encrypted by the encryption method of the present invention at 827, it is checked at step 1828 whether there is a logged-in user. If it does not exist, the message 1837 is displayed in step 1838. If it exists, it is checked in step 1829 whether the destination user list includes the login user. If the login user is included, the recv flag is set to “1” in step 1830,
In step 1832, the received file data is decrypted. On the other hand, if the login user is not included in the destination list, the message 1 is sent in step 1831.
836 is displayed, the socket information is deleted from the socket information table 91 in step 1834, and the process returns. On the other hand, if the received file data is not encrypted in step 1827, the socket information is deleted from the socket information table in step 1834 and the process returns.

【００７５】図３７は、ｃｌｏｓｅｓｏｃｋｅｔフック
ルーチン１８４０の処理フローを示す図である。まずス
テップ１８４１では、前記ブラウザプログラム１９がコ
ールしたｃｌｏｓｅｓｏｃｋｅｔ関数の引数に指定され
たソケット記述子が、ソケット情報テーブル９１に登録
されているかを調べる。登録されている場合は、ステッ
プ１８４２で前記ソケット記述子に対応するソケット情
報をテーブル９０から削除し、ステップ１８４３のｃｌ
ｏｓｅｓｏｃｋｅｔ処理を実行して前記ブラウザプログ
ラム１９にリターンする（ステップ１８４４）。一方、
前記ソケット情報テーブルに登録されていない場合は、
ステップ１８４３のｃｌｏｓｅｓｏｃｋｅｔ処理を実行
してリターンする。FIG. 37 is a diagram showing the processing flow of the closesocket hook routine 1840. First, in step 1841, it is checked whether or not the socket descriptor specified in the argument of the closesocket function called by the browser program 19 is registered in the socket information table 91. If registered, the socket information corresponding to the socket descriptor is deleted from the table 90 in step 1842, and cl in step 1843
It executes an ossocket process and returns to the browser program 19 (step 1844). on the other hand,
If it is not registered in the socket information table,
The process executes the closesocket process of step 1843 and returns.

【００７６】以上説明した通信ＡＰＩフックプログラム
２７の各ルーチンの処理によって、所望のページの復号
化をブラウザプログラム１９からは透過に実現すること
ができる。By the processing of each routine of the communication API hook program 27 described above, the decryption of a desired page can be realized transparently from the browser program 19.

【００７７】次に、本実施例において、実際のＷＷＷ運
用システムの一例について図３８を用いて説明する。１
４０は、代理サーバ情報処理装置であり、代理サーバプ
ログラム１８により、前記クライアント情報処理装置１
１０と前記サーバ情報処理装置１２０との間の送受信デ
ータを中継する。また、前記代理サーバプログラム１８
は、前記サーバ情報処理装置１２０が前記クライアント
情報処理装置１１０からの要求に応じて発信したＨＴＭ
Ｌファイルやイメージデータファイルを、ディスクコン
トローラ４ｃを介して磁気ディスク５ｃ内にキャッシュ
する機能を持つ。以後、前記クライアント情報処理装置
１１０からファイル転送要求を出した場合、該ファイル
が前記磁気ディスク５ｃ内にキャッシュされていれば、
前記代理サーバプログラム１８が該キャッシュファイル
を前記クライアント情報処理装置１１０へ転送する。本
実施例においては、機密情報に関するファイルは全て暗
号化されて前記サーバ情報処理装置１２０の磁気ディス
ク５ｂに格納されている。したがって、ファイル転送時
に前記磁気ディスク５ｃにキャッシュされる機密情報は
全て暗号ファイルとなる。Next, an example of an actual WWW operation system in this embodiment will be described with reference to FIG. 1
Reference numeral 40 is a proxy server information processing device, and by the proxy server program 18, the client information processing device 1
10 relays data transmitted and received between the server 10 and the server information processing apparatus 120. The proxy server program 18
Is an HTM transmitted by the server information processing apparatus 120 in response to a request from the client information processing apparatus 110.
It has a function of caching L files and image data files in the magnetic disk 5c via the disk controller 4c. Thereafter, when a file transfer request is issued from the client information processing apparatus 110, if the file is cached in the magnetic disk 5c,
The proxy server program 18 transfers the cache file to the client information processing device 110. In this embodiment, all files related to confidential information are encrypted and stored in the magnetic disk 5b of the server information processing apparatus 120. Therefore, all confidential information cached in the magnetic disk 5c at the time of file transfer becomes an encrypted file.

【００７８】[0078]

【発明の効果】以上説明したように、本発明はファイル
の暗号化において、復号化を許可するユーザーのリスト
をファイルに付加するグループ暗号用いるので、複数の
ユーザーが同一のファイル利用する場合にも暗号化ファ
イルが一個で済み且つ安全であるという効果がある。As described above, according to the present invention, when a file is encrypted, a group encryption that adds a list of users who are permitted to decrypt to the file is used. Therefore, even when a plurality of users use the same file, There is an effect that only one encrypted file is required and it is safe.

【００７９】また、暗号化の対象ディレクトリと復号を
許可するユーザーの宛先リストをユーザー毎に設定可能
であるので、複数のユーザーがディレクトリを共用し該
ディレクトリ内のファイルを異なる宛先リストを用いて
ファイル暗号化を行うことができるという効果がある。Further, since the directory to be encrypted and the destination list of users who are allowed to decrypt can be set for each user, a plurality of users share the directory and files in the directory are filed using different destination lists. There is an effect that encryption can be performed.

【００８０】また、本発明は、アプリケーションプログ
ラムが解釈し処理する文法に従って記述された平文ファ
イルのデータ暗号化において、前記文法における前記ア
プリケーションプログラム処理時に処理対象外として無
視する注釈文とするための記述子を前記暗号化後のデー
タに付加し暗号ファイルとして格納するので、本暗号化
システムに対応した復号プログラムを具備しない情報処
理装置で前記暗号化ファイルを読み出した場合にも、異
常動作することがないという効果がある。Further, according to the present invention, in data encryption of a plaintext file described in accordance with a grammar that an application program interprets and processes, a description for making an annotation sentence to be ignored as a processing target when the application program is processed in the grammar is described. Since the child is added to the encrypted data and stored as an encrypted file, abnormal operation may occur even when the encrypted file is read by an information processing device that does not have a decryption program compatible with the encryption system. There is an effect that there is no.

【００８１】また、本発明は、アプリケーションプログ
ラムからＯＳに発行されるファイル操作要求をフックす
るフック手段を設け、前記ファイル操作要求発行時に自
動的に暗号化あるいは復号化を行うので、ユーザーが暗
号化を忘れることがないという効果がある。Further, according to the present invention, the hook means for hooking the file operation request issued from the application program to the OS is provided, and the encryption or decryption is automatically performed when the file operation request is issued. It has the effect of never forgetting.

【００８２】また、本発明は、ＷＷＷサーバが予め暗号
化されたファイルを管理するので、該ＷＷＷサーバプロ
グラムを具備するサーバ情報処理装置に直接アクセスし
ても機密情報が漏れないという効果がある。また、本発
明は、ＷＷＷサーバが予め暗号化されたファイルを管理
するので、該ファイル転送時に代理サーバによってキャ
ッシュされる機密情報も暗号ファイルとなるため、代理
サーバ情報処理装置に直接アクセスしても機密情報が漏
れないという効果がある。Further, according to the present invention, since the WWW server manages the files encrypted in advance, there is an effect that confidential information is not leaked even if the server information processing apparatus having the WWW server program is directly accessed. Further, according to the present invention, since the WWW server manages a file encrypted in advance, the confidential information cached by the proxy server at the time of transferring the file is also an encrypted file, so that the proxy server information processing device is confidential even if directly accessed. The effect is that information is not leaked.

【００８３】また、本発明は、ブラウザプログラムから
通信モジュールに発行される通信ＡＰＩ呼び出しをフッ
クするフック手段を設け、前記データ受信ＡＰＩ呼び出
し時に自動的に復号化を行うので、ユーザーにとって復
号化のための操作が不要であるという効果がある。Further, according to the present invention, the hook means for hooking the communication API call issued from the browser program to the communication module is provided, and the decoding is automatically performed when the data reception API is called. The operation is unnecessary.

【図面の簡単な説明】[Brief description of drawings]

【図１】本発明の実施例における共用ファイル暗号シス
テムの一構成例を示す図。FIG. 1 is a diagram showing a configuration example of a shared file encryption system according to an embodiment of the present invention.

【図２】本発明の実施例におけるＩＤ情報２９の内容の
一例を示す図。FIG. 2 is a diagram showing an example of contents of ID information 29 in the embodiment of the present invention.

【図３】本発明の実施例において、宛先リストのハッシ
ュ値を計算し前記グループ鍵５１を作成する手順の一例
を示す図。FIG. 3 is a diagram showing an example of a procedure for calculating a hash value of a destination list and creating the group key 51 in the embodiment of the present invention.

【図４】本発明の一実施例におけるＩＣカード１３０内
の前記グループ暗号プログラム２８の処理内容を示すフ
ロー図。FIG. 4 is a flowchart showing the processing contents of the group encryption program 28 in the IC card 130 according to the embodiment of the present invention.

【図５】本発明の一実施例におけるファイルの暗号化手
順と暗号化後のファイルの構成を示す図。FIG. 5 is a diagram showing a file encryption procedure and a file structure after encryption according to an embodiment of the present invention.

【図６】本発明の一実施例におけるファイルの復号化手
順を示す図。FIG. 6 is a diagram showing a file decoding procedure according to an embodiment of the present invention.

【図７】本発明の一実施例におけるユーザーから見た論
理的なディレクトリの構成を示す図。FIG. 7 is a diagram showing a logical directory structure viewed from a user according to an embodiment of the present invention.

【図８】本発明の一実施例におけるファイルの自動暗号
化、復号化を導入した後の物理的なディレクトリ構成を
示す図。FIG. 8 is a diagram showing a physical directory structure after automatic file encryption and decryption is introduced in an embodiment of the present invention.

【図９】本発明の一実施例における宛先リストファイル
９０１、前記暗号ファイル情報ファイル９０２の内容の
一例を示す図。FIG. 9 is a diagram showing an example of the contents of a destination list file 901 and the encrypted file information file 902 according to an embodiment of the present invention.

【図１０】本発明の一実施例におけるＩＣカード１３０
へのログイン処理ルーチン１０００の処理フローを示す
図。FIG. 10 is an IC card 130 according to an embodiment of the present invention.
FIG. 10 is a diagram showing the processing flow of a login processing routine 1000 for login to the.

【図１１】本発明の一実施例におけるＩＣカード１３０
からのログアウト処理ルーチン１１００の処理フローを
示す図。FIG. 11 is an IC card 130 according to an embodiment of the present invention.
FIG. 13 is a diagram showing a processing flow of a logout processing routine 1100 from FIG.

【図１２】本発明の一実施例におけるファイルオープン
フックルーチン１２００の処理フローを示す図。FIG. 12 is a diagram showing a processing flow of a file open hook routine 1200 according to an embodiment of the present invention.

【図１３】本発明の一実施例におけるファイルクリエイ
トフックルーチン１３００の処理フローを示す図。FIG. 13 is a diagram showing a processing flow of a file create hook routine 1300 according to an embodiment of the present invention.

【図１４】本発明の一実施例におけるリードフックルー
チン１４００の処理フローを示す図。FIG. 14 is a diagram showing a processing flow of a lead hook routine 1400 according to an embodiment of the present invention.

【図１５】本発明の一実施例におけるライトフックルー
チン１５００の処理フローを示す図。FIG. 15 is a diagram showing a processing flow of a light hook routine 1500 according to an embodiment of the present invention.

【図１６】本発明の一実施例におけるクローズフックル
ーチン１６００の処理フローを示す図。FIG. 16 is a diagram showing a processing flow of a close hook routine 1600 according to an embodiment of the present invention.

【図１７】本発明の一実施例におけるファイルリネーム
フックルーチン１７００の処理フローを示す図。FIG. 17 is a diagram showing a processing flow of a file rename hook routine 1700 according to an embodiment of the present invention.

【図１８】本発明の一実施例におけるファイル暗号化・
復号化時のデータの入出力方法を示す図。FIG. 18 illustrates an example of file encryption and encryption according to an embodiment of the present invention.
The figure which shows the input-output method of the data at the time of decoding.

【図１９】本発明の一実施例におけるオープン中の暗号
ファイルを管理するためのファイルハンドルテーブル９
０の構成を示す図。FIG. 19 is a file handle table 9 for managing open encrypted files according to an embodiment of the present invention.
FIG.

【図２０】本発明の一実施例における手動ファイル暗号
化ルーチン２０００の処理フローの一例を示す図。FIG. 20 is a diagram showing an example of a processing flow of a manual file encryption routine 2000 according to an embodiment of the present invention.

【図２１】本発明の第一の実施例における第一のサーバ
情報処理装置１２０のディレクトリ構造を示す図。FIG. 21 is a diagram showing a directory structure of the first server information processing device 120 according to the first embodiment of the present invention.

【図２２】本発明の一実施例における平文のＨＴＭＬフ
ァイルの一例を示す図。FIG. 22 is a diagram showing an example of a plaintext HTML file according to an embodiment of the present invention.

【図２３】本発明の一実施例において平文のＨＴＭＬフ
ァイルをブラウザで表示した画面の例を示す図。FIG. 23 is a diagram showing an example of a screen in which a plaintext HTML file is displayed on a browser in an embodiment of the present invention.

【図２４】本発明の一実施例における暗号化したＨＴＭ
Ｌファイルの一例を示す図。FIG. 24 shows an encrypted HTM in one embodiment of the present invention.
The figure which shows an example of an L file.

【図２５】本発明の一実施例において暗号化した平文の
ＨＴＭＬファイルをブラウザで表示した画面の例を示す
図。FIG. 25 is a diagram showing an example of a screen in which a plaintext HTML file encrypted in a working example of the present invention is displayed by a browser.

【図２６】本発明の一実施例における暗号化したＨＴＭ
Ｌファイルの他の例を示す図。FIG. 26 shows an encrypted HTM in one embodiment of the present invention.
The figure which shows the other example of L file.

【図２７】本発明の第一の実施例における前記共用ファ
イル暗号プログラム２１と前記ファイルＩ／Ｏフックプ
ログラム２２を構成するプログラムルーチンを示す図。FIG. 27 is a diagram showing a program routine that constitutes the shared file encryption program 21 and the file I / O hook program 22 in the first embodiment of the present invention.

【図２８】本発明の実施例における暗号ファイル受信シ
ステムの一構成例を示す図。FIG. 28 is a diagram showing a configuration example of an encrypted file receiving system according to an embodiment of the present invention.

【図２９】本発明の実施例における前記共用ファイル暗
号プログラム２１と前記通信ＡＰＩフックプログラム２
７を構成するプログラムルーチンを示す図。FIG. 29 is the shared file encryption program 21 and the communication API hook program 2 according to the embodiment of the present invention.
The figure which shows the program routine which comprises 7.

【図３０】本発明の一実施例におけるファイルの暗号化
手順と暗号化後のファイルの構成を示す図。FIG. 30 is a diagram showing a file encryption procedure and a file structure after encryption according to an embodiment of the present invention.

【図３１】本発明の一実施例におけるファイルの復号化
手順を示す図。FIG. 31 is a diagram showing a file decoding procedure according to an embodiment of the present invention.

【図３２】本発明の一実施例におけるファイル暗号化・
復号化時のデータの入出力方法を示す図。FIG. 32 is a diagram illustrating a file encryption according to an embodiment of the present invention.
The figure which shows the input-output method of the data at the time of decoding.

【図３３】本発明の一実施例における受信ファイル復号
化時のデータの入出力方法を示す図。FIG. 33 is a diagram showing an input / output method of data at the time of decrypting a received file in one embodiment of the present invention.

【図３４】本発明の一実施例におけるオープン中のソケ
ット情報を管理するためのソケット情報テーブル９１の
構成を示す図。FIG. 34 is a diagram showing a configuration of a socket information table 91 for managing socket information during opening according to an embodiment of the present invention.

【図３５】本発明の一実施例におけるｓｅｎｄフックル
ーチン１８００の処理フローを示す図。FIG. 35 is a diagram showing a processing flow of a send hook routine 1800 according to an embodiment of the present invention.

【図３６】本発明の一実施例におけるｒｅｃｖフックル
ーチン１８２０の処理フローを示す図。FIG. 36 is a diagram showing a processing flow of a recv hook routine 1820 in the embodiment of the present invention.

【図３７】本発明の一実施例におけるｃｌｏｓｅｓｏｃ
ｋｅｔフックルーチン１８４０の処理フローを示す図。FIG. 37: closesoc in one embodiment of the present invention
The figure which shows the processing flow of the ket hook routine 1840.

【図３８】本発明の実施例において実際のＷＷＷを運用
するシステムの一構成例を示す図。FIG. 38 is a diagram showing an example of the configuration of a system that operates an actual WWW in the embodiment of the present invention.

【符号の説明】[Explanation of symbols]

１ ＣＰＵ ２ メモリ ３ ＬＡＮコントローラ ４ ディスクコントローラ ５ 磁気ディスク ６ ＩＣカードコントローラ ７ 不揮発メモリ ８ 入出力インタフェース １９ ブラウザプログラム １８ 代理サーバプログラム ２０ ＯＳ ２１ 共用ファイル暗号プログラム ２２ ファイルＩ／Ｏフックプログラム ２３ アプリケーションプログラム ２４ クライアントプログラム ２５ ファイルサーバプログラム ２６ ＷＷＷサーバプログラム ２７ 通信ＡＰＩフックプログラム ２８ グループ暗号プログラム ２９ ＩＤ情報 ３０ アクセス制御プログラム ３１ マスタ鍵 ３２ ハッシュ関数 １０１ ＬＡＮ １１０ クライアント情報処理装置 １２０ サーバ情報処理装置 １３０ ＩＣカード １４０ 代理サーバ情報処理装置 1 CPU 2 Memory 3 LAN Controller 4 Disk Controller 5 Magnetic Disk 6 IC Card Controller 7 Nonvolatile Memory 8 Input / Output Interface 19 Browser Program 18 Proxy Server Program 20 OS 21 Shared File Encryption Program 22 File I / O Hook Program 23 Application Program 24 Client Program 25 File server program 26 WWW server program 27 Communication API hook program 28 Group encryption program 29 ID information 30 Access control program 31 Master key 32 Hash function 101 LAN 110 Client information processing device 120 Server information processing device 130 IC card 140 Proxy server information Processor

───────────────────────────────────────────────────── フロントページの続き (72)発明者 梅木 久志 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 大津 豊 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 (72)発明者 森藤 元 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 清水 麻由子 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Hisashi Umeki 1099, Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Ltd. System Development Laboratory, Hitachi, Ltd. (72) Inventor, Yutaka Otsu 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa In-house company Hitachi Ltd., Software Development Headquarters (72) Inventor Hajime Morito 1099 Ozenji, Aso-ku, Kawasaki City, Kanagawa Prefecture In-house Hitachi Systems Development Laboratory (72) Inventor Mayuko Shimizu 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Hitachi, Ltd. Software Development Division

Claims (39)

【特許請求の範囲】[Claims] 【請求項１】 少なくともファイルへの入出力制御機能
を持つオペレーティングシステム（ＯＳ）と、前記ファ
イルを格納する記憶装置あるいはネットワークで接続さ
れた第二の情報処理装置上の記憶装置へのファイル格納
手段とを具備する情報処理装置からなるファイル暗号化
システムにおいて、暗号化を行う対象ディレクトリを予
め設定しファイルに記憶する暗号化ディレクトリ記憶手
段と、前記ＯＳ上で動作するアプリケーションプログラ
ムから前記ディレクトリ内のファイルへの書き込みデー
タを暗号化する暗号化手段とを設けたことを特徴とする
ファイル暗号化システム。1. An operating system (OS) having at least an input / output control function for a file, and a storage device for storing the file or a file storage means in a storage device on a second information processing device connected by a network. In a file encryption system including an information processing device including: an encrypted directory storage unit that presets a directory to be encrypted and stores the file in a file; and a file in the directory from an application program operating on the OS. A file encryption system comprising: an encryption means for encrypting write data to the file. 【請求項２】 前記暗号化ディレクトリ記憶手段は、前
記情報処理装置を利用するユーザー毎に、独立した複数
の暗号化対象ディレクトリを設定可能であることを特徴
とする請求項１記載のファイル暗号化システム。2. The file encryption according to claim 1, wherein the encryption directory storage means can set a plurality of independent encryption target directories for each user who uses the information processing apparatus. system. 【請求項３】 前記暗号化ディレクトリ記憶手段は、前
記対象ディレクトリ毎に復号可能なユーザーのリストを
記憶することを特徴とする請求項１または請求項２記載
のファイル暗号化システム。3. The file encryption system according to claim 1, wherein the encrypted directory storage means stores a list of users who can be decrypted for each target directory. 【請求項４】 前記ユーザーのリストを記憶したファイ
ルを、前記対象ディレクトリ毎に前記対象ディレクトリ
内に作成することを特徴とする請求項３記載のファイル
暗号化システム。4. The file encryption system according to claim 3, wherein a file storing a list of the users is created in the target directory for each target directory. 【請求項５】 前記暗号化手段は、当該ディレクトリに
暗号化対象ディレクトリであることを示すファイルがあ
る場合にファイルへの書き込みデータを暗号化すること
を特徴とする請求項１記載のファイル暗号化システム。5. The file encryption according to claim 1, wherein said encryption means encrypts write data to the file when the directory has a file indicating that the directory is an encryption target directory. system. 【請求項６】 前記ユーザーのリストを暗号化し記憶す
ることを特徴とする請求項３ないし請求項５のいずれか
記載のファイル暗号化システム。6. The file encryption system according to claim 3, wherein the list of users is encrypted and stored. 【請求項７】 前記アプリケーションプログラムから見
た論理的ファイル名と、前記暗号化手段によって格納さ
れる物理的ファイル名とが異なることを特徴とする請求
項１ないし請求項６のいずれか記載のファイル暗号化シ
ステム。7. The file according to claim 1, wherein a logical file name viewed from the application program and a physical file name stored by the encryption means are different. Encryption system. 【請求項８】 少なくともファイルへの入出力制御機能
を持つオペレーティングシステム（ＯＳ）と、前記ファ
イルを格納する記憶装置あるいはネットワークで接続さ
れた第二の情報処理装置上の記憶装置へのファイル格納
手段とを具備する情報処理装置からなるファイル暗号化
システムにおいて、暗号化を行う対象ディレクトリを予
め設定しファイルに記憶する暗号化ディレクトリ記憶手
段と、アプリケーションプログラムから前記ディレクト
リ内のファイルへの書き込みデータの暗号化と読み出し
データの復号化とを行う暗号復号手段とを設けたことを
特徴とするファイル暗号化システム。8. An operating system (OS) having at least a file input / output control function, and a file storage means for storing the file in a storage device or a storage device on a second information processing device connected by a network. In a file encryption system including an information processing apparatus including: an encryption directory storage unit that presets a directory to be encrypted and stores the file in a file; and encryption of write data from an application program to a file in the directory. A file encryption system comprising: an encryption / decryption means for performing encryption and decryption of read data. 【請求項９】 前記暗号復号手段は、アプリケーション
プログラムからのファイル書き込み或いは読み出しのサ
イズとは独立したサイズの平文ブロックバッファと暗号
文ブロックバッファとを具備し、暗号化および復号化の
処理は、前記ブロックバッファ上の全データを一度に処
理することによって行うことを特徴とする請求項８記載
のファイル暗号化システム。9. The encryption / decryption means comprises a plaintext block buffer and a ciphertext block buffer having a size independent of the size of writing or reading a file from an application program, and the encryption and decryption processing is performed by the above 9. The file encryption system according to claim 8, which is performed by processing all the data on the block buffer at a time. 【請求項１０】 前記暗号化手段あるいは復号化手段
は、前記アプリケーションプログラムから前記ＯＳに発
行されるファイル操作要求をフックするフック手段によ
って呼び出されることを特徴とする請求項１ないし請求
項９のいずれか記載のファイル暗号化システム。10. The method according to claim 1, wherein the encryption means or the decryption means is called by hook means for hooking a file operation request issued to the OS from the application program. Or described file encryption system. 【請求項１１】 前記暗号化手段は、復号を許可するユ
ーザーのリストの文字列をハッシュ関数によって圧縮す
ることによって作成した数値を暗号化の鍵として用いる
ことを特徴とする請求項１ないし請求項１０のいずれか
記載のファイル暗号化システム。11. The encryption means uses a numerical value created by compressing a character string of a list of users who are permitted to decrypt with a hash function as an encryption key. 10. The file encryption system according to any one of 10. 【請求項１２】 前記暗号化手段は、復号を許可するユ
ーザーのリストの文字列をハッシュ関数によって圧縮す
ることによって作成した数値で暗号化の鍵を暗号化し、
該暗号化鍵を暗号化ファイルに付加することを特徴とす
る請求項１なし請求項１０のいずれか記載のファイル暗
号化システム。12. The encryption means encrypts an encryption key with a numerical value created by compressing a character string of a list of users permitted to decrypt with a hash function,
11. The file encryption system according to claim 1, wherein the encryption key is added to an encrypted file. 【請求項１３】 少なくともファイルへの入出力制御機
能を持つオペレーティングシステム（ＯＳ）と、前記フ
ァイルを格納する記憶装置あるいはネットワークで接続
された第二の情報処理装置上の記憶装置へのファイル格
納手段と、前記ファイルを暗号化するファイル暗号化手
段とを具備する情報処理装置からなるファイル暗号化シ
ステムの制御方法において、前記ファイル暗号化手段
が、アプリケーションプログラムが解釈し処理する文法
に従って記述された平文ファイルのデータ暗号化に際
し、前記文法における前記アプリケーションプログラム
処理時に処理対象外として無視する注釈文とするための
記述子を前記暗号化後のデータに付加し格納することを
特徴とするファイル暗号化システムの制御方法。13. An operating system (OS) having at least an input / output control function for a file, and a storage device for storing the file or a file storage means in a storage device on a second information processing device connected by a network. And a file encryption system comprising an information processing device comprising a file encryption means for encrypting the file, wherein the file encryption means is a plaintext written in accordance with a grammar interpreted and processed by an application program. When encrypting the data of the file, a descriptor for adding an annotation text to the annotation data to be ignored as a processing target when processing the application program in the grammar is added to the encrypted data and stored. Control method. 【請求項１４】 前記暗号化後のデータに前記注釈文の
終了を示す記述子が存在しないような暗号化鍵を選択し
使用することを特徴とする請求項１３記載のファイル暗
号化システムの制御方法。14. The control of the file encryption system according to claim 13, wherein an encryption key is selected and used such that a descriptor indicating the end of the annotation text does not exist in the encrypted data. Method. 【請求項１５】 ファイルが暗号文のファイルであるこ
とを前記アプリケーションプログラムが表示するための
記述文を、前記暗号化後のデータを含む前記注釈文の前
あるいは後ろに付加し格納することを特徴とする請求項
１３又は請求項１４記載のファイル暗号化システムの制
御方法。15. A descriptive text for displaying by the application program that a file is a ciphertext file is added and stored before or after the annotation text including the encrypted data. The method for controlling the file encryption system according to claim 13 or 14. 【請求項１６】 少なくともファイルへの入出力制御機
能を持つオペレーティングシステム（ＯＳ）と、前記フ
ァイルを格納する記憶装置あるいはネットワークで接続
された第二の情報処理装置上の記憶装置へのファイル格
納手段と、前記記憶装置に格納されたファイルを復号化
するファイル復号化手段とを具備する情報処理装置から
なるファイル暗号化システムの制御方法において、前記
ファイル復号化手段が、アプリケーションプログラムが
解釈し処理する文法に従って記述された暗号ファイルの
データ復号化に際し、前記文法における前記アプリケー
ションプログラム処理時に処理対象外として無視する注
釈文とするための記述子によって注釈文とされたデータ
部分を復号化し、該復号化後のデータを暗号化前の平文
ファイルのデータとして格納することを特徴とするファ
イル暗号化システムの制御方法。16. An operating system (OS) having at least a file input / output control function, and a file storage means in a storage device for storing the file or a storage device on a second information processing device connected by a network. And a file decryption means for decrypting a file stored in the storage device, the method of controlling a file encryption system comprising an information processing device, wherein the file decryption means is interpreted and processed by an application program. At the time of decrypting the data of the encrypted file described according to the grammar, the data portion which is the annotation sentence is decrypted by the descriptor for the annotation sentence to be ignored as the processing target when the application program is processed in the grammar, and the decryption is performed. The data after is the plaintext file data before encryption. A method for controlling a file encryption system, which is characterized by storing as a file. 【請求項１７】 前記暗号化手段あるいは復号化手段
は、前記アプリケーションプログラムから前記ＯＳに発
行されるファイル操作要求をフックするフック手段によ
って呼び出されることを特徴とする請求項１３ないし請
求項１６のいずれか記載のファイル暗号化システムの制
御方法。17. The encryption unit or the decryption unit is called by a hook unit that hooks a file operation request issued to the OS from the application program. Or the control method of the file encryption system described above. 【請求項１８】 前記暗号化手段は、復号を許可するユ
ーザーのリストの文字列をハッシュ関数によって圧縮す
ることによって作成した数値を暗号化の鍵として用いる
ことを特徴とする請求項１３ないし請求項１７のいずれ
か記載のファイル暗号化システムの制御方法。18. The encryption means uses a numerical value created by compressing a character string of a list of users who are permitted to decrypt by a hash function as an encryption key. 18. The method for controlling the file encryption system according to any one of 17. 【請求項１９】 前記暗号化手段は、復号を許可するユ
ーザーのリストの文字列をハッシュ関数によって圧縮す
ることによって作成した数値で暗号化の鍵を暗号化し、
該暗号化鍵を暗号化ファイルに付加することを特徴とす
る請求項１３ないし請求項１７のいずれか記載のファイ
ル暗号化システムの制御方法。19. The encryption means encrypts an encryption key with a numerical value created by compressing a character string of a list of users who are allowed to decrypt with a hash function,
18. The method for controlling a file encryption system according to claim 13, wherein the encryption key is added to an encrypted file. 【請求項２０】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを格納する記憶装置とを具備する
第一の情報処理装置と、該第一の情報処理装置とはネッ
トワークで接続され、少なくとも通信制御機能を持つオ
ペレーティングシステム（ＯＳ）と、該ＯＳ上で動作
し、前記第一の情報処理装置上の記憶装置からファイル
を受信する機能を持つアプリケーションプログラムとを
具備する第二の情報処理装置によって構成された暗号フ
ァイル受信システムにおいて、前記第一の情報処理装置
が、前記ファイルを暗号化するファイル暗号化手段を有
し、前記第二の情報処理装置が、前記アプリケーション
プログラムが前記第一の情報処理装置からファイル暗号
化手段によって暗号化された前記暗号ファイルを受信す
る際に、該受信ファイルを復号化してから前記アプリケ
ーションプログラムに渡す受信ファイル復号化手段を有
することを特徴とする暗号ファイル受信システム。20. An operating system (O) having at least a communication control function and a file input / output control function.
S), a first information processing device including a storage device that stores the file, an operating system (OS) that is connected to the first information processing device via a network, and has at least a communication control function, A cryptographic file receiving system configured by a second information processing device, which includes an application program that operates on the OS and has a function of receiving a file from a storage device on the first information processing device, One information processing device has a file encryption means for encrypting the file, and the second information processing device has the application program encrypted from the first information processing device by the file encryption means. When the encrypted file is received, the received file is decrypted before the application program Cryptographic file receiving system characterized by having a reception file decoding means to pass. 【請求項２１】 受信ファイル復号化手段は、前記ファ
イル暗号化手段によって前記暗号ファイルに復号可能な
ユーザーのリストが付加されたファイルを受信して、復
号化することを特徴とする請求項２０記載の暗号ファイ
ル受信システム。21. The received file decryption means receives and decrypts a file in which the list of users who can be decrypted is added to the encrypted file by the file encryption means. Encrypted file receiving system. 【請求項２２】 前記受信ファイル復号化手段は、アプ
リケーションプログラムが前記ＯＳに発行するデータ送
受信要求をフックするフック手段によって呼び出される
ことを特徴とする請求項２０又は請求項２１記載の暗号
ファイル受信システム。22. The encrypted file receiving system according to claim 20, wherein the received file decryption means is called by hook means for hooking a data transmission / reception request issued by the application program to the OS. . 【請求項２３】 前記フック手段は、前記第二の情報処
理装置のユーザーの身元を確認するユーザー認証手段に
よって認証されたユーザーが存在する場合にのみ前記受
信ファイル復号化手段を呼び出すことを特徴とする請求
項２０ないし請求項２２のいずれか記載の暗号ファイル
受信システム。23. The hook means calls the received file decryption means only when there is a user authenticated by the user authentication means for confirming the identity of the user of the second information processing apparatus. 23. The encrypted file receiving system according to claim 20. 【請求項２４】 前記受信ファイル復号化手段は、前記
ユーザー認証手段によって認証されたユーザーが、前記
復号可能なユーザーのリストに含まれているか否かを判
別する復号権利判別手段によって復号権利があると判断
された場合にのみ呼び出されることを特徴とする請求項
２０ないし請求項２３のいずれか記載の暗号ファイル受
信システム。24. The reception file decryption unit has a decryption right by a decryption right determination unit that determines whether the user authenticated by the user authentication unit is included in the list of decryptable users. 24. The encrypted file receiving system according to claim 20, wherein the encrypted file receiving system is called only when it is determined to be. 【請求項２５】 前記暗号ファイルに、復号可能なユー
ザーのリストを暗号化して付加したファイルを受信して
復号化することを特徴とする請求項２０記載の暗号ファ
イル受信システム。25. The encrypted file receiving system according to claim 20, wherein the encrypted file is received by decrypting a file obtained by encrypting and adding a list of decryptable users. 【請求項２６】 前記第一の情報処理装置上の記憶装置
には、前記ファイル暗号化手段によって予め暗号化され
たファイルが格納されていることを特徴とする請求項２
０ないし請求項２５のいずれか記載の暗号ファイル受信
システム。26. The storage device on the first information processing device stores a file encrypted in advance by the file encryption means.
The encrypted file receiving system according to any one of claims 0 to 25. 【請求項２７】 前記フック手段は、前記アプリケーシ
ョンプログラムが、前記第一の情報処理装置へ送信した
ファイル転送要求コマンドに対する受信ファイルのみを
復号化の対象として処理することを特徴とする請求項２
０ないし請求項２５のいずれか記載の暗号ファイル受信
システム。27. The hook means processes only a received file for a file transfer request command transmitted to the first information processing apparatus by the application program, as a decoding target.
The encrypted file receiving system according to any one of claims 0 to 25. 【請求項２８】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを暗号化するファイル暗号化手段
と、前記暗号化ファイルを格納する記憶装置とを具備す
る第一の情報処理装置と、該第一の情報処理装置とはネ
ットワークで接続され、少なくとも通信制御機能を持つ
オペレーティングシステム（ＯＳ）と、該ＯＳ上で動作
し、前記第一の情報処理装置上の記憶装置から前記暗号
ファイルを受信する機能を持つアプリケーションプログ
ラムとを具備する第二の情報処理装置から構成された暗
号ファイル受信システムにおいて、前記ファイル暗号化
手段は、前記アプリケーションプログラムが解釈し処理
する文法に従って記述された平文ファイルのデータ暗号
化において、前記文法における前記アプリケーションプ
ログラム処理時に処理対象外として無視する注釈文とす
るための記述子を、前記暗号化後のデータに付加したも
のを暗号ファイルとするものであり、前記アプリケーシ
ョンプログラムが前記暗号ファイルを受信したとき、前
記記述子が付加されて注釈文となっているデータ部分の
みを取り出して復号化する受信ファイル復号化手段を設
けたことを特徴とする暗号ファイル受信システム。28. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. A second operating system (OS) having at least a communication control function, and an application program operating on the OS and having a function of receiving the encrypted file from the storage device on the first information processing apparatus In the encrypted file receiving system configured by the information processing device, the file encryption means, during data encryption of a plaintext file described according to a grammar interpreted and processed by the application program, at the time of processing the application program in the grammar. Descriptor to be an annotation sentence to be ignored as non-processing target The encrypted data is added to the encrypted file, and when the application program receives the encrypted file, only the data part in which the descriptor is added to form the comment text is extracted. An encrypted file receiving system comprising a received file decoding means for decoding. 【請求項２９】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを暗号化するファイル暗号化手段
と、前記暗号化ファイルを格納する記憶装置とを具備す
る第一の情報処理装置と、該第一の情報処理装置とはネ
ットワークで接続され、少なくとも通信制御機能を持つ
オペレーティングシステム（ＯＳ）を具備する第二の情
報処理装置と、前記ネットワークで接続され、前記第二
の情報処理装置が前記第一の情報処理装置へ送信するデ
ータや、反対に前記第二の情報処理装置が前記第一の情
報処理装置から受信するデータを中継する機能と、該受
信データをキャッシュするキャッシュ機能とを具備する
第三の情報処理装置とから構成される暗号化ファイル受
信システムにおいて、前記第二の情報処理装置が、前記
暗号ファイルの転送要求を出すと、該暗号ファイルが前
記第一の情報処理装置から前記第三の情報処理装置を経
由して前記第二の情報処理装置へ転送されると共に、該
暗号ファイルは前記キャッシュ機能によってキャッシュ
され、前記第二の情報処理装置が、再度同じ暗号ファイ
ルの転送要求を出すと、前記キャッシュ機能によりキャ
ッシュされた暗号ファイルが前記第三の情報処理装置か
ら前記第二の情報処理装置へ転送されることを特徴とす
る暗号ファイル受信システム。29. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. Data to be transmitted to the first information processing device by the second information processing device, which is connected to the second information processing device having at least an operating system (OS) having a communication control function via the network, On the contrary, the second information processing apparatus is composed of a third information processing apparatus having a function of relaying data received from the first information processing apparatus and a cache function of caching the received data. In the encrypted file receiving system, when the second information processing device issues a transfer request for the encrypted file, the encrypted file receives the first information processing. From the storage device to the second information processing device via the third information processing device, the encrypted file is cached by the cache function, and the second information processing device again stores the same encrypted file. Is transmitted, the encrypted file cached by the cache function is transferred from the third information processing device to the second information processing device. 【請求項３０】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを格納する記憶装置とを具備する
第一の情報処理装置と、該第一の情報処理装置とはネッ
トワークで接続され、少なくとも通信制御機能を持つオ
ペレーティングシステム（ＯＳ）と、該ＯＳ上で動作
し、前記第一の情報処理装置上の記憶装置からファイル
を受信する機能を持つアプリケーションプログラムとを
具備する第二の情報処理装置によって構成された暗号フ
ァイル受信システムの制御方法において、前記アプリケ
ーションプログラムが前記第一の情報処理装置から前記
暗号ファイルを受信する際に、該受信ファイルを復号化
してから前記アプリケーションプログラムに渡すように
したことを特徴とする暗号ファイル受信システムの制御
方法。30. An operating system (O) having at least a communication control function and a file input / output control function.
S), a first information processing device including a storage device that stores the file, an operating system (OS) that is connected to the first information processing device via a network, and has at least a communication control function, A control method for a cryptographic file receiving system configured by a second information processing apparatus, comprising: an application program that operates on the OS and has a function of receiving a file from a storage device on the first information processing apparatus. When the application program receives the encrypted file from the first information processing device, the received file is decrypted and then passed to the application program. . 【請求項３１】 前記ファイル暗号化手段によって、前
記暗号ファイルに復号可能なユーザーのリストが付加さ
れたファイルを受信して、復号化するようにしたことを
特徴とする請求項３０記載の暗号ファイル受信システム
の制御方法。31. The encrypted file according to claim 30, wherein the file encryption means receives and decrypts a file in which a list of decryptable users is added to the encrypted file. Receiving system control method. 【請求項３２】 前記受信ファイル復号化手段を、アプ
リケーションプログラムが前記ＯＳに発行するデータ送
受信要求をフックするフック手段によって呼び出すこと
を特徴とする請求項３０記載の暗号ファイル受信システ
ムの制御方法。32. The control method of an encrypted file receiving system according to claim 30, wherein the received file decryption means is called by hook means for hooking a data transmission / reception request issued by the application program to the OS. 【請求項３３】 前記フック手段は、前記第二の情報処
理装置のユーザーの身元を確認するユーザー認証手段に
よって認証されたユーザーが存在する場合にのみ前記受
信ファイル復号化手段を呼び出すことを特徴とする請求
項３０ないし請求項３２のいずれか記載の暗号ファイル
受信システムの制御方法。33. The hook means calls the received file decryption means only when there is a user authenticated by the user authentication means for confirming the identity of the user of the second information processing apparatus. 33. The control method of the encrypted file receiving system according to claim 30. 【請求項３４】 前記受信ファイル復号化手段を、前記
ユーザー認証手段によって認証されたユーザーが、前記
復号可能なユーザーのリストに含まれているか否かを判
別する復号権利判別手段によって復号権利があると判断
された場合にのみ呼び出すことを特徴とする請求項３０
ないし請求項３３のいずれか記載の暗号ファイル受信シ
ステムの制御方法。34. The decryption right discriminating means for discriminating whether or not the user authenticated by the user authenticating means is included in the decryptable user list has the decryption right for the received file decrypting means. 31. Calling only when it is determined that
34. The control method of the encrypted file receiving system according to claim 33. 【請求項３５】 前記暗号ファイルに、復号可能なユー
ザーのリストを暗号化して付加したファイルを受信して
復号化することを特徴とする請求項３０記載の暗号ファ
イル受信システムの制御方法。35. The control method of the encrypted file receiving system according to claim 30, wherein a file obtained by encrypting and adding a list of decryptable users to the encrypted file is received and decrypted. 【請求項３６】 前記第一の情報処理装置上の記憶装置
に、前記ファイル暗号化手段によって予め暗号化された
ファイルを格納することを特徴とする請求項３０ないし
請求項３５のいずれか記載の暗号ファイル受信システム
の制御方法。36. The storage device on the first information processing device stores a file encrypted in advance by the file encryption means. Control method of encrypted file receiving system. 【請求項３７】 前記フック手段は、前記アプリケーシ
ョンプログラムが、前記第一の情報処理装置へ送信した
ファイル転送要求コマンドに対する受信ファイルのみを
復号化の対象として処理することを特徴とする請求項３
０ないし請求項３５記載の暗号ファイル受信システムの
制御方法。37. The hook means processes only a received file for a file transfer request command transmitted to the first information processing apparatus by the application program, as a decryption target.
A control method for the encrypted file receiving system according to any one of claims 0 to 35. 【請求項３８】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを暗号化するファイル暗号化手段
と、前記暗号化ファイルを格納する記憶装置とを具備す
る第一の情報処理装置と、該第一の情報処理装置とはネ
ットワークで接続され、少なくとも通信制御機能を持つ
オペレーティングシステム（ＯＳ）と、該ＯＳ上で動作
し、前記第一の情報処理装置上の記憶装置から前記暗号
ファイルを受信する機能を持つアプリケーションプログ
ラムとを具備する第二の情報処理装置から構成された暗
号ファイル受信システムの制御方法において、前記ファ
イル暗号化手段は、前記アプリケーションプログラムが
解釈し処理する文法に従って記述された平文ファイルの
データ暗号化において、前記文法における前記アプリケ
ーションプログラム処理時に処理対象外として無視する
注釈文とするための記述子を、前記暗号化後のデータに
付加したものを暗号ファイルとし、前記アプリケーショ
ンプログラムが前記暗号ファイルを受信したとき、前記
記述子が付加されて注釈文となっているデータ部分のみ
を取り出して復号化することを特徴とする暗号ファイル
受信システムの制御方法。38. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. A second operating system (OS) having at least a communication control function, and an application program operating on the OS and having a function of receiving the encrypted file from the storage device on the first information processing apparatus In the control method of the encrypted file receiving system configured by the information processing apparatus, the file encryption means, in the data encryption of the plaintext file described according to the grammar interpreted and processed by the application program, the application in the grammar. Because it is a comment statement that is ignored as a processing target during program processing A descriptor is added to the encrypted data as an encrypted file, and when the application program receives the encrypted file, only the data part to which the descriptor is added and which is a comment text is extracted. A method for controlling an encrypted file receiving system characterized by decrypting. 【請求項３９】 少なくとも通信制御機能とファイルへ
の入出力制御機能を持つオペレーティングシステム（Ｏ
Ｓ）と、前記ファイルを暗号化するファイル暗号化手段
と、前記暗号化ファイルを格納する記憶装置とを具備す
る第一の情報処理装置と、該第一の情報処理装置とはネ
ットワークで接続され、少なくとも通信制御機能を持つ
オペレーティングシステム（ＯＳ）を具備する第二の情
報処理装置と、前記ネットワークで接続され、前記第二
の情報処理装置が前記第一の情報処理装置へ送信するデ
ータや、反対に前記第二の情報処理装置が前記第一の情
報処理装置から受信するデータを中継する機能と、該受
信データをキャッシュするキャッシュ機能とを具備する
第三の情報処理装置とから構成される暗号ファイル受信
システムの制御装置において、前記第二の情報処理装置
が前記暗号ファイルの転送要求を出すと、該暗号ファイ
ルが前記第一の情報処理装置から前記第三の情報処理装
置を経由して前記第二の情報処理装置へ転送されると共
に、該暗号ファイルは前記キャッシュ機能によってキャ
ッシュされ、前記第二の情報処理装置が、再度同じ暗号
ファイルの転送要求を出すと、前記キャッシュ機能によ
りキャッシュされた暗号ファイルを前記第三の情報処理
装置から前記第二の情報処理装置へ転送することを特徴
とする暗号ファイル受信システムの制御方法。39. An operating system (O) having at least a communication control function and a file input / output control function.
S), a file encryption means for encrypting the file, and a first information processing device having a storage device for storing the encrypted file, and the first information processing device is connected via a network. Data to be transmitted to the first information processing device by the second information processing device, which is connected to the second information processing device having at least an operating system (OS) having a communication control function via the network, On the contrary, the second information processing apparatus is composed of a third information processing apparatus having a function of relaying data received from the first information processing apparatus and a cache function of caching the received data. In the control device of the encrypted file receiving system, when the second information processing device issues a transfer request for the encrypted file, the encrypted file is transferred to the first information device. While being transferred from the processing device to the second information processing device via the third information processing device, the cipher file is cached by the cache function, and the second information processing device again uses the same encryption. A method of controlling a cryptographic file receiving system, comprising: transmitting a cryptographic file cached by the cache function from the third information processing device to the second information processing device when a file transfer request is issued.