JP3741357B2 - Data storage method and system, and data storage processing recording medium - Google Patents

Description

【００５９】
平均計算回数は、各アクセス位置とアクセス長の組について「数２」に示す式で求めた値の平均値である。なお、「数１」、「数２」の中で使用している記号の意味は図２２に示す通りである。また、「Ｌ％Ｒ」とは、「Ｌ／Ｒの余り」のことである。
【００６０】
【数２】

【００６１】
次に、上のようにして求めた平均再暗号化処理長と平均計算回数、および暗号化処理速度、復号化処理速度、レコード用暗号鍵の生成にかかる時間、初期化データの生成にかかる時間から、「数１」、「数２」の計算に用いた仮レコード長を使った時の平均書き込みオーバヘッド時間は「数３」に示す式を用いて得ることができる。
【００６２】
【数３】

【００６３】
ここで、「数３」中の（平均再暗号化処理長）／（復号化速度）は、ファイルから読み込んだ再暗号化処理が必要な部分を復号化するのにかかる時間の平均である。また、（平均再暗号化処理長）／（暗号化速度）は、再暗号化処理が必要な部分を暗号化するのにかかる時間の平均である。また、｛ … ｝×（平均計算回数）は、レコードごとに用意するレコード鍵と初期化データを計算するのにかかる時間の平均である。これら３つの式の和を求めると、書き込みオーバヘッド時間の平均になる。
【００６４】
このようにしてそれぞれの仮レコード長について求めた平均書き込みオーバヘッド時間のうち、その最少値を与える仮レコード長を選ぶ（ステップ２１０４）。これが書き込み時のオーバヘッドを最少にするレコード長である。最後に、アプリケーションプログラムと選んだレコード長を組にしてレコードサイズ記憶部１２４に書き込む（ステップ２１０５）。
【００６５】
以上のように本実施形態においては、端末１０１のアプリケーションプログラム１０６からオペレーティングシステム１０８へ発行する記憶装置１１１へのデータ読み込み・書き出し要求を横取りし、書き出し要求の際にはデータを暗号化するための暗号鍵をネットワーク１２２で接続している鍵管理サーバ１１２から取り寄せ、この暗号鍵でデータを暗号化して記憶装置１１１に保存し、また、読み込み要求の際には記憶装置１１１から暗号化データを読み出し、この暗号化データを復号するための鍵を鍵管理サーバ１１２から取り寄せ、この暗号鍵で暗号化データを復号して取り出した元のデータをアプリケーションプログラム１０６に渡すようにしたため、暗号化や復号化の指示をユーザが明示的に行うことなしに記憶装置１１１に保存するデータを自動的に暗号化し、読み出す時には自動的に復号することができ、煩わしい操作をユーザに強いることがないという効果が得られる。また、記憶装置１１１に保存するデータを自動的に保存するので、ユーザがデータの暗号化を忘れるという問題も起きない。
【００６６】
また、鍵管理サーバ１１１２に対して暗号鍵を送ってもらう要求を出す前に、アプリケーションプログラム１０６を操作しているユーザに対してそのユーザを識別するための情報を入力させ、この情報の正しさをユーザが操作している端末１０１で確認した後にユーザの鍵を鍵管理サーバ１１２から取り寄せる、あるいはユーザが入力した識別情報を鍵管理サーバ１１２に送り、鍵管理サーバ１１２で受け取った識別情報の正しさを確認した後にそのユーザの暗号鍵を送り返すようにしているため、暗号化した機密データを保存してある携帯用の端末が盗まれたとしても、解読される危険性はこれらのデータが同一の記憶装置に保存されている場合に比べて小さくなり、データの機密性をさらに高めることができる。例えば、携帯用端末に暗号化データを保存しておき、社内でそのデータにアクセスしたい時は社内ＬＡＮに接続し、社外からは社内ネットワークへリモートアクセスして利用するようにしておけば、この携帯端末を不正に入手したユーザは、ユーザの識別情報を類推するだけでなく、リモートアクセス時のユーザ認証作業も行う必要があるので安全性がより高くなる。また、社内では携帯用端末を鍵管理サーバと同じネットワークに接続して重要データの編集や閲覧が可能なように構成でき、社外では鍵管理サーバが存在しないので、そのデータにアクセスできなくさせるように構成することができ、セキュリティを高めることができる。
【００６７】
さらに、アプリケーションプログラム１０６からオペレーティングシステム１０８へのデータ読み出し・書き込み要求を横取りするための仕組みは、オペレーティングシステム１０８が提供している場合には、既存のアプリケーションプログラムやオペレーティングシステムを書き換える必要がなく、しかも新たにハードウェアを置き換える必要もなく、最小限のコストでデータのセキュリティを高めることが可能である。
さらに、ＩＣカードにユーザ固有の暗号鍵を記録しておいて各ユーザ自身で暗号鍵を管理させる方法も考えられるが、ＩＣカード自体の紛失によりデータの復号が不可能になったり、ＩＣカードの読み書き機構を端末１０１に付加しておく必要があるので、コスト面で不利となる。しかし、本実施形態のように暗号鍵を鍵管理サーバ１１２から取り寄せるようにすることにより、ＩＣカードの読み書き機構を備えていない端末であっても利用することができるという利点がある。
【００６８】
なお、本実施形態では、ファイルの暗号化に際し、ユーザ鍵をそのまま使わずにファイル暗号鍵をその都度生成しているが、ユーザ鍵でファイル自体を直接に暗号化してもよい。
また、ファイルを保存あるいは読み出すたびにユーザに対してユーザ名とパスワードを入力させているが、これらの情報を端末１０１のメモリに一時的に保存しておいて、次回のファイル保存、読み出しの際にはこの一時保存してあるユーザ名とパスワードを使って鍵管理要求を生成するように構成することにより、ユーザの入力操作をさらに簡略化することができる。
さらに、取り寄せたユーザ鍵自体をメモリ上に一時保存し後で再利用する構成にすることにより、端末１０１と鍵管理サーバ１１２間の通信を行わずに済み、通信のオーバヘッドを省いて処理スピードを速めることができ、ネットワーク１２２のトラフィックを減らすこともできる。
【００６９】
また、予めユーザがファイル保存の際には自動的に暗号化して欲しいファイルやディレクトリを指定するように構成することで、指定したファイルあるいは指定したディレクトリ以下にあるファイルだけに対して、暗号化や復号化を行うことができる。これにより、暗号化して保存する場所としてフロッピーディスクのような記憶媒体を表わすディレクトリも指定できるので、重要な情報をコピーされて持ち出されることを防ぐこともできる。
【００７０】
さらに、端末１０１および鍵管理サーバ１１２において実施形態で説明したような機能を実現する各機能部分は、具体的には同等機能を実現する処理プログラムで構成されるものであり、これらの処理プログラムはＣＤＲＯＭなどの記憶媒体に格納して、あるいはインタネット等の通信媒体を通じて利用者に提供することができるものである。
【００７１】
また、本実施形態では、レコードごとに暗号鍵と初期化データを計算していたが、読み書き時の速度を高速化するためにファイル暗号鍵とファイル初期化データをそのまま使ってもよい。この場合、本実施形態に比べて暗号化ファイルの安全性が少し失われることになる。また、レコード長の計算方法も変える必要がある。
【００７２】
レコード長を決めるためにアプリケーションのアクセス長だけでなく、オペレーティングシステムによるファイルアクセスへのキャッシュの単位や、記憶装置上でのデータの記録単位（例えばセクタ長）を使うこともできる。
また、レコード長を求める時に、読み書きのアクセス記録の両方を使って平均書き込み時間を求めたが、厳密に読み書きを区別して計算してもよい。このためには、アクセス情報記憶部に読み書きを区別する欄を設ければよい。
また、レコード長はアプリケーションプログラム用のレコード長が求まっていない時だけでなく、例えば一週間に一回というように定期的に計算してもよい。
【００７３】
また、レコード長を求めた結果、その値がそれまで使っていたレコード長と異なる値になった場合、既存のファイルを暗号化し直せばよい。
また、暗号化ファイルにレコード長を記憶しておく領域を設けておくことで、そのファイルを暗号化する際のレコード長を保存して置くことができる。このようにすれば、アプリケーションプログラムに最適なレコード長が変わった時に、既存の暗号化ファイルを新しいレコード長の値を使って簡単に暗号化し直すことが可能である。
【００７４】
【発明の効果】
以上のように本発明によれば、暗号化や復号化の指示をユーザが明示的に行うことなしに記憶装置に保存するデータを自動的に暗号化し、読み出す時には自動的に復号することができ、煩わしい操作をユーザに強いることがないという効果が得られる。また、記憶装置に保存するデータを自動的に保存するので、ユーザがデータの暗号化を忘れるという問題も起きない。
【００７５】
また、自動的に暗号化・復号化する際に問題となる、データ上書き時の再暗号化処理や初期化データ生成処理のオーバヘッドも最小化できるので、このような最適化を行なわない場合に比べてデータ上書き処理を高速化できる。
【図面の簡単な説明】
【図１】本発明を適用したコンピュータシステムの実施形態を示すシステム構成図である。
【図２】ユーザに配布する鍵情報レコードの構成図である。
【図３】ユーザ配布情報作成手順を示すフローチャートである。
【図４】認証トークンの構成図である。
【図５】ファイル暗号化手順を示すフローチャートである。
【図６】端末と鍵管理サーバとの間で送受されるメッセージのフォーマット構成図である。
【図７】ユーザ鍵要求メッセージデータ部に含まれる元の内容を示す図である。
【図８】ユーザ鍵要求メッセージの構成図である。
【図９】ユーザ鍵返答メッセージデータ部に含まれる元の内容（ユーザ鍵あり）を示す図である。
【図１０】ユーザ鍵返答メッセージデータ部に含まれる元の内容（ユーザ鍵なし）を示す図である。
【図１１】記憶装置に記憶される暗号化ファイルの構成図である。
【図１２】ファイル復号化手順を示すフローチャートである。
【図１３】鍵管理アプリケーションの処理手順を示すフローチャートである。
【図１４】暗号化の詳細手順を示すフローチャートである。
【図１５】アプリケーションプログラムからの書き込み要求の構成図である。
【図１６】レコードサイズ記憶部を表す図である。
【図１７】アクセス情報記憶部を表す図である。
【図１８】書き込み要求の実行によってファイル上に上書きされる範囲と再暗号化処理の必要となる範囲を表す図である。
【図１９】復号化の詳細手順を示すフローチャートである。
【図２０】アプリケーションプログラムからの読み込み要求の構成図である。
【図２１】レコード長を求める手順を示すフローチャートである。
【図２２】計算式に使われている記号の説明図である。
【符号の説明】
１０１…端末、１０２…ユーザ入力部、１０３…パスワード暗号鍵生成部、１０４…ファイル暗号鍵生成部、１０５…暗号化・復号化部、１０６…アプリケーション、１０７…ファイルアクセスフック部、１０８…オペレーティングシステム、１０９…記憶装置用インタフェース、１１０…通信用インタフェース、１１１…記憶装置、１１２…鍵管理サーバ、１１３…鍵管理アプリケーション、１１４…ユーザ入力部、１１５…パスワード暗号鍵生成部、１１６…ユーザ鍵生成部、１１７…暗号化・復号化部、１１８…オペレーティングシステム、１１９…通信用インタフェース、１２０…記憶装置用インタフェース、１２１…鍵データベース、１２２…ネットワーク、１２３…ユーザ、１２４…レコードサイズ記憶部、１２５…アクセス情報記憶部。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to data for writing and storing data processed by the application program in the storage device in a computer system comprising a computer that executes processing according to the application program and a storage device connected to the computer. The present invention relates to a storage method and system, and a data storage processing recording medium.
[0002]
[Prior art]
Conventionally, in a computer system provided with a storage device such as a magnetic disk device, data processed by an application program operating inside the computer is stored in the storage device as it is.
For this reason, the data stored on the storage device can be seen or rewritten from the computer used to create the data, or from the computer on the network if this storage device is connected to the network. There was a risk of secret leaks and data alterations.
[0003]
Therefore, the operating system that manages the storage device is provided with an access control function that determines which user can read or rewrite the data stored in the storage device, and the right of access. There is a mechanism that does not allow access from users who do not have access.
However, since the storage device can be directly accessed without using the operating system, the access control function cannot completely prevent the data from being seen or altered.
Therefore, measures have been taken to prevent such fraud by encrypting the data stored in the storage device or attaching an electronic signature for detecting that the data has been altered.
[0004]
By the way, when data is encrypted or decrypted, the data is divided into 8-bit or 64-bit basic units and then encrypted and decrypted. However, since the basic unit with the same content is encrypted into the same ciphertext as it is, it becomes a clue to decrypt the ciphertext. Therefore, when encrypting the basic unit at a certain position in the data, the encryption is performed after performing some processing (for example, exclusive OR) using the already encrypted basic unit at the previous position. Turn into. When such a basic unit chain process is performed, the clues for decoding can be eliminated. When encrypting the basic unit at the beginning of the data, chain processing is performed using separately prepared initialization data. The above cipher chaining process is described in, for example, “Cryptography and Data Security” (D.E.R. Denning, translated by Tadahiro Uenono et al., Published by Bafukan).
[0005]
[Problems to be solved by the invention]
However, when data is encrypted and stored, the data is temporarily stored on the storage device, or encryption is performed by the user explicitly specifying the data stored in the storage device. Similarly, when decrypting encrypted data, the user explicitly designates decryption and decrypts the original data.
For this reason, there is a problem that the user has to instruct data encryption / decryption one by one, and the operation is troublesome. In particular, when performing operations such as once decrypting encrypted data, modifying it, and then re-encrypting it, the re-encryption operation may be forgotten, and the re-encryption operation is forgotten In some cases, there is a problem that it is not possible to counter the snooping or modification of data in the storage device. Therefore, when data encryption / decryption is necessary, there is a need for a mechanism that can perform encryption / decryption without a direct instruction from the user.
[0006]
The present invention has been made to solve these problems, and a first object of the present invention is to make a request to write data from an application program without direct instruction of encryption / decryption by a user. If there is, the data is automatically encrypted and stored in the storage device, and if there is a data read request, the encrypted data stored in the storage device is automatically decrypted and passed to the application program. Accordingly, it is an object of the present invention to provide a data storage method and system, and a storage medium for storage processing, which can prevent the data in the storage device from being seen or altered without a troublesome operation by the user.
[0007]
Further, in the case of automatically encrypting / decrypting in response to a write request or read request from the application program as described above, the following problems arise.
The application program reads and writes data from an arbitrary position in the file. If the encryption basic unit is chained when performing the automatic encryption method, when data is overwritten at a certain position in the file, all the basic encryption units after that position are re-encrypted. This is necessary, and the time until the overwriting process ends is increased.
[0008]
In order to reduce the portion that requires such re-encryption processing, a method is considered in which a file is divided into records having a fixed length larger than the basic encryption unit, and the initialization data is prepared for each record. In this method, when data is overwritten at a certain position in the file, the re-encryption process is performed only up to the end of the overwritten record. By doing in this way, the part which needs re-encryption can be limited.
[0009]
However, by dividing the file into records of a certain length, the re-encryption process when data is overwritten can be reduced, but it is not easy to determine how much record length is good.
[0010]
If the record length is long, the length of the re-encryption process required when the application program overwrites the data becomes large.
If the record length is short, the application program often accesses across multiple records when reading and writing data, increasing the number of times to prepare the initialization data for each record, which increases the processing time and overhead. turn into.
[0011]
Further, since the unit length for reading and writing differs for each application program, the optimum record length for one application program is not necessarily optimum for another application program.
[0012]
The present invention has been made to solve the above-mentioned problems. The second object of the present invention is to record the length of reading and writing and the position to start reading and writing for each application program. , Data storage method and system capable of shortening processing time when data is overwritten by obtaining a record size that minimizes overhead time consisting of re-encryption processing when overwriting and preparation of initialization data It is to provide a recording medium for processing.
[0013]
[Means for Solving the Problems]
In order to achieve the above object, according to the data storage method of the present invention, in response to a data write request from an application program, the file hook means intercepts the write request, and the operating system stores the data to be written as the storage target. Before writing to the device, it is encrypted by the preset record length unit with the encryption key stored in the internal memory of the computer and written to the storage device,
In response to a read request from the application program, the read request is intercepted by the file hook means, and before the read data is transferred to the application program, the encrypted data from the storage device is transferred to the operating system. After reading in record units, decrypt the encrypted data with the encryption key stored in the internal memory in preset record length units and transfer the decrypted data to the application program that made the read request It is characterized by doing.
[0014]
In addition, when a user saves a file in advance, the file or directory that the user wants to automatically encrypt is specified, so that only the specified file or files under the specified directory are encrypted or decrypted. It is characterized by this.
[0015]
Also, when the operating system receives a data read / write request from an application program, it records the location and data length of the data in the file, takes a sufficient number of records, and then re-reads each application program. The record length that minimizes the overhead of the encryption process and the initialization data process is calculated, and the record length obtained by the calculation is used for the subsequent encryption / decryption.
[0016]
By such means, the data stored in the storage device can be automatically encrypted without the user explicitly giving instructions for encryption and decryption, and can be automatically decrypted when read out. The user is not forced. Further, since the data stored in the storage device is automatically stored, there is no problem that the user forgets to encrypt the data.
In addition, since a directory representing a storage medium such as a floppy disk can be designated as a place to be encrypted and saved, it is possible to prevent important information from being copied out.
[0017]
In addition, since the length of re-encryption in one overwrite request and the record length that minimizes the overhead of the initialization data generation process can be obtained for each application program, the processing time when data is overwritten Can be accelerated for each application program.
In addition, if the operating system provides a mechanism for intercepting data read / write requests from the application to the operating system, there is no need to rewrite existing application programs or operating systems, and new hardware It is possible to increase the security of data at a minimum cost without having to replace.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, it demonstrates in detail based on embodiment of this invention.
FIG. 1 is a system configuration diagram showing an embodiment of the present invention.
In the present embodiment, data created by an application program running on a terminal by a user is encrypted with his / her key obtained from a key management server (key management computer) and stored in a storage device connected to the terminal. In this case, the encrypted data read from the storage device is decrypted with its own key obtained from the key management server, and the plaintext data is passed to the application.
[0019]
The system shown in FIG. 1 is roughly divided into a terminal 101 operated by a user 123, a storage device 111 connected to the terminal 101, and a key management server (key management computer) that manages keys for data encryption. ) 112, a key database 121 storing a key for encryption, and a network 122 connecting the terminal 101 and the key management server 112.
The terminal 101 is composed of a stationary or portable computer, and includes a user input unit 102, a password encryption key generation unit 103, a file encryption key generation unit 104, an encryption key / decryption unit. 105, an application program 106, a file access hook unit 107, an operating system 108, a storage device interface 109, a communication interface 110, a record size storage unit 124, and an access information storage unit 125. A user 123 is created by the application program 106 The data file can be saved in the storage device 111 or read out.
The user input unit 102 is for causing the user 123 to input a user name and password according to an instruction from the file access hook unit 107. The password encryption key generation unit 103 is for generating an encryption key from the password input by the user 123. The password encryption key encrypts the authentication information of the user 123 and the encryption key used for the entire system and saves it in the storage device 111. The file encryption key generation unit 104 randomly generates an encryption key used for encrypting a file stored in the storage device 111. The encryption / decryption unit 105 actually encrypts / decrypts a file. An application program 106 for the user 123 to create a data file is software such as a word processor or a spreadsheet.
[0020]
The file access hook unit 107 manages overall file encryption / decryption processing in the terminal 101 such as processing of intercepting a file access request from the application program 106 to the storage device 111 and obtaining a user key from the key management server 112. Is. The operating system 108 operating on the terminal 101 manages the storage device interface 109, the communication interface 110, the record size storage unit 124, and the access information storage unit 125 to access the storage device 111 and the network 122. Is provided to the application program 106 and the file access hook unit 107.
[0021]
The record size storage unit 124 is used to store the record size when encrypting / decrypting each application program.
[0022]
The access information storage unit 125 is for storing a plurality of read / write start positions and read / write data lengths in a file for each application program, and records for encryption / decryption. Used to calculate size.
The storage device 111 stores not only the file created by the user 123 but also an authentication token used for confirmation when the user 123 inputs a password and a system key used by the system to encrypt data. is there.
[0023]
On the other hand, the key management server 112 includes a key management application program 113, a user input unit 114, a password encryption key generation unit 115, a user key generation unit 116, an encryption / decryption unit 117, an operating system 118, a communication interface 119, and a storage. A device interface 120 is provided, and the user 123 of the terminal 101 generates information for using the system and manages user keys.
The key management application program 113 manages the entire cryptographic processing in the key management server 112, such as generation of information distributed to the user 123 and processing of a user key request message from the terminal 101. The user input unit 114 is for causing the user 123 to input a user name and a password according to an instruction from the key management application program 113 when the user 123 first generates a user key. The password encryption key generation unit 115 is for generating an encryption key from the password input by the user 123. The user key generation unit 116 is for generating an encryption key for the user 123 at random. The encryption / decryption unit 117 encrypts information to be distributed to the user 123, and encrypts or decrypts an electronic message exchanged when the user 123 requests a user key.
The operating system 118 operating on the key management server 112 manages the communication interface 119 and the storage device interface 120, and the environment such as communication using the network 122 and access to the key database 121 is changed to the key management application program 113. To provide.
The key database 121 stores a system key for encrypting communication data exchanged between the terminal 101 and the key management server 112 using the network 122, and a key information record of the user 123. This key information record 2 includes a user name 201 and a user key 202, as shown in FIG.
[0024]
(Create user distribution information)
FIG. 3 is a flowchart showing a procedure for creating on the key management server 112 data to be distributed to the user 123 in order to use this system.
First, the user name and password are input from the user input unit 114 (step 301).
Next, the password encryption key generation unit 115 adds a process to the password of the user 123 to generate a password encryption key. As a processing method, for example, a one-way function such as the MD5 algorithm is used (step 302).
Subsequently, the user key generation unit 116 randomly generates a user key (step 303).
A key information record as shown in FIG. 2 is created from the user key and user name obtained here and stored in the key database 121 (step 304). FIG. 2 is an example of the key information record of the user A whose user name is “A”.
Next, an authentication token for verifying the correctness of the password input by the user 123 is created (step 305). Since it is dangerous for security to save the password entered by the user as it is, it is stored using encryption processing. For example, in UNIX, “all 0” data is encrypted and stored using the password of the user 123 as a key, and when the user 123 inputs the password later, the same processing is performed to perform authentication.
[0025]
In the present embodiment, 6-byte data of all “0” is encrypted with a password encryption key to generate an authentication token as shown in FIG. In FIG. 4, 401 is a user name (here, user A) indicating the owner of the authentication token, and 402 is a data value after the encryption processing is performed.
Subsequently, the system key used for encrypting data flowing on the network 122 in this system is also encrypted with the password encryption key (step 306). By using the password encryption key, only the person who knows the password of the user 123 can obtain the correct system key.
The system key is created at the key management server 112 at the start of system operation.
Finally, the authentication token and the encrypted system key are copied to a floppy disk or the like and passed to the user 123 (step 307). The user 123 uses the received information by copying it to the storage device 111 connected to the terminal 101 operated by the user 123.
[0026]
(File encryption)
FIG. 5 is a flowchart showing a procedure when the data created on the terminal 101 by the user 123 (here, user A) is encrypted and stored in the storage device 111.
This procedure starts when the user A tries to save data created by the application program 106 in the storage device 111.
First, when the application program 106 issues a file save request to the operating system 108, the file access hook unit 107 receives the file save request before the operating system 108 processes the request (step 501).
Subsequently, in order to encrypt and save the file requested to be saved, the user key is obtained from the management server 112 as follows.
First, the user A is requested to input the user name and password of the user A who has operated the application program 106 from the user input unit 102 (step 502). Next, a password encryption key generation unit 103 generates a password encryption key from the input password (step 503).
[0027]
In order to confirm whether the input password is correct, the terminal 101 performs the same processing as the generation of the authentication token in the management server 112 and verifies whether or not it matches the authentication token read from the storage device 111 (step 504). If they do not match, the user name and password are repeatedly input. If they match, go to the next step.
[0028]
Next, the encrypted system key is read from the storage device 111, and the system key is decrypted using the password encryption key (steps 505 and 506).
Note that the authentication token and the encryption system key read from the storage device 111 have been generated by the key management server 112 in advance.
[0029]
Next, a message is exchanged with the key management server 112 to obtain a user key. Note that the format of messages exchanged between the terminal 101 and the key management server 112 is as shown in FIG. In FIG. 6, reference numeral 601 denotes a header part for distinguishing messages. If “0”, it indicates a user key request message for requesting a user key from the terminal 101 to the key management server 112. ”Is a user key response message indicating that the response is from the key management server 112. Reference numeral 602 denotes a data body included in the message, and the content differs depending on the type of message. Reference numeral 603 denotes an electronic signature of the header part 601 and the data part 602 using the system key.
In order to obtain the user key from the key management server 112, the terminal 101 creates a user key request message (step 507). Information sent from the terminal 101 to the key management server 112 is a user name and challenge data. The challenge data is an integer that is randomly selected each time a user key request message is created. The challenge data is determined to include response data that has been subjected to predetermined processing (for example, adding 1) in the user key response message. Thus, the user can confirm that the received response message is a response to the request message issued immediately before.
First, data consisting of a user name 701 and challenge data 702 as shown in FIG. 7 is formed and encrypted with a system key. Next, as shown in FIG. 8, an electronic signature 803 of data including a value “0” indicating that the message is a user key request message in the header portion 801 and information obtained by encrypting the user name and challenge data in the data portion 802. A user key request message composed of The generated user key request message is sent to the key management server 112, and a response message is sent back.
[0030]
Thereafter, the key management server 112 processes the user key request message, creates a user key response message, and sends it back to the terminal 101 (step 508). Details of this procedure will be described later with reference to FIG.
When the terminal 101 receives the returned user key response message (step 509), the terminal 101 first checks the electronic signature included in the response message for alteration during transfer (step 510). If it is determined that the message has been altered, the application program 106 that issued the file save command is notified of the failure of the save and the process is terminated (step 521). If there is no modification, go to the next step.
Since the data part of the user key response message is encrypted with the system key, it is decrypted with the system key (step 511).
[0031]
By the way, there are two types of user key response messages, one containing a user key and one not containing a user key because some error has occurred in the key management server 112, and the contents of the data part of the response message are different. The contents of the data part before being encrypted are as shown in FIG. 9 or FIG.
FIG. 9 shows the contents when the user key is returned, and includes a user name 901, response data 902, a value “0” 903 indicating that the user key is included, and a user key 904.
FIG. 10 shows the contents when the user key is not returned due to some error, and includes a user name 1001, response data 1002, and a value “1” 1003 indicating that some kind of error has occurred. Here, 1003 may include any value other than “0” to indicate a specific type of error.
The response data included in the user key response message is obtained by adding “1” to the value of the challenge data included in the user key request message.
After decrypting the data part of the user key response message, the terminal 101 checks for the presence of the user key (step 512). If the user key is not included, the file cannot be encrypted and saved, so the application program 106 is notified of the failure to save (step 521), and the process ends. If the user key is included, the process proceeds to the procedure for actually encrypting the file.
[0032]
Here, if writing to a new file, a file encryption key and file initialization data are randomly generated (step 519). Then, after encrypting the file encryption key with the user key, the encrypted file encryption key and file initialization data are stored as the header of the new file (step 520), and the process proceeds to the next procedure. The file encryption key is used to generate an encryption key prepared for each record obtained by dividing the file. The file initialization data is used to generate initialization data for each record.
[0033]
If writing to an existing file, the encrypted file encryption key and file initialization data are read from the header of the file to be written (step 514). Then, the encrypted file encryption key is decrypted with the user key to obtain a file encryption key (step 515).
Next, the data requested to be written is encrypted (step 516). Details of the encryption procedure will be described with reference to FIG.
[0034]
The encrypted data obtained as described above is written at a position in the encrypted file corresponding to the write request of the application program 106. The encrypted file encryption key is 1101, the file initialization data is 1102, the encrypted file body is 1103, and the signature generated using the user key is 1104 as shown in FIG. An encrypted file 1100 is created and stored in the storage device 111. Therefore, the storage device 111 stores the encrypted file main body 1103 obtained by encrypting the file generated by the application program 106 with the data 1101, the file initialization data 1102, and the signature 1104 encrypted with the file encryption key. Will be.
Finally, the end of saving is notified to the application program 106 that issued the file saving request (step 518), and this procedure ends.
[0035]
(Decrypt file)
FIG. 12 is a flowchart showing a procedure when the user A reads out the encrypted data stored in the storage device 111 by the application program 106 operating on the terminal 101.
This procedure starts when user A attempts to read data previously encrypted and stored in the storage device 111 into the application program 106. When the application program 106 issues a file read request to the operating system 108, the file read request file access hook unit 107 receives it before the operating system 108 processes the request (step 1201).
The file access hook unit 107 instructs the operating system 108 to read the file specified by the read request, and reads the encrypted file from the storage device 111 via the storage device interface 109 (step 1202). .
[0036]
Next, in order to decrypt the read file, user authentication is performed in the same procedure as when the file is encrypted, and the user key is obtained from the key management server 112. Steps 1203 to 1213 corresponding to the procedure for obtaining the user key are exactly the same as steps 502 to 512 in FIG.
At this time, when the modification of the user key reply message from the key management server 112 is detected (step 1211) or the user key cannot be obtained (step 1213), the read file is decrypted. Therefore, the application program 106 is notified of the read failure (step 1219), and this procedure is terminated (step 1218). Only when the user key can be obtained, the encrypted file is decrypted as follows.
Here, the file to be read has a format as shown in FIG. 11. 1101 is a file encryption key encrypted with a user key, 1102 is file initialization data, 1103 is an encrypted file body, and 1104 is these This is an electronic signature using user keys of three pieces of data 1101 to 1103.
[0037]
In FIG. 12, if the user key is included, the signature 1104 is checked to see if the encrypted file has been altered (step 1214). If it is found that the file has been altered, the application program 106 is notified of the failure to read the file (step 1219), and this procedure is terminated.
If not modified, first, the encrypted file encryption key 1101 and file initialization data 1102 are read from the encrypted file (step 1215).
[0038]
Next, by using the user key obtained from the key management server 112, the encrypted file encryption key 1101 is decrypted to obtain the original file encryption key (step 1216).
Subsequently, the encrypted data corresponding to the request of the application program 106 is read from the encrypted file body 1103 and decrypted using the file encryption key obtained by decryption (step 1217). Details of the decoding procedure will be described with reference to FIG.
Finally, the decrypted data is transferred to the application program 106 (step 1218), and this procedure is terminated.
[0039]
(Key management application program processing)
FIG. 13 is a flowchart illustrating a procedure when the key management application program 113 operating on the key management server 112 processes a user A user key request from the terminal 101.
This procedure starts upon receiving a user key request message from the file access hook unit 107.
The user key request message received by the key management application program 113 has a format configuration as shown in FIG.
When receiving the user key request message from the terminal 101 (step 1301), the key management application program 113 first reads a system key stored in the key database 121 in order to check whether the message has been altered (step 1302). ) The electronic signature in the request message is confirmed (step 1303). If there is a modification, the operation of retrieving the user key described below from the key database 121 is not performed.
[0040]
In order to retrieve the user key from the key database 121, first, the encryption / decryption unit 117 decrypts the user key request message with the system key, and retrieves the user name 701 and challenge data 702 as shown in FIG. 7 (step 1304). ).
Next, the key information record including the user name obtained here is extracted from the key database 121. If a key information record as shown in FIG. 2 is found, the user key 202 is extracted (step 1305).
[0041]
As described above, after the modification inspection of the user key request message and the extraction of the user key are finished, a user key response message to be returned to the terminal 101 is created (step 1306). Here, the response data included in the response message is a value obtained by adding “1” to the challenge data included in the request message, but the content included in the data portion of the response message depending on whether or not the user key has been obtained. Changes. When the user key is obtained, the data including the user name 901, the response data 902, the value “0” 903 indicating that the user key is included, and the user key 904 are encrypted / decrypted as shown in FIG. What is encrypted using the system key on the conversion unit 117 is included in the data part of the user key response message.
If the user key could not be obtained, as shown in FIG. 10, the data consisting of the user name 1001, response data 1002, and the value “1” indicating that the user key is not included is encrypted / decrypted. What is encrypted on the part 117 using the system key is included in the data part of the user key response message.
In the signature part of the user key reply message, a signature created by using a system key with data consisting of a header part having a value “1” indicating that it is a user key reply message and the data part created as described above Include.
The user key response message created as described above is sent to the terminal 101 (step 1307), and this procedure ends.
[0042]
(Detailed encryption procedure)
FIG. 14 is a flowchart showing a detailed procedure for encrypting data requested to be written from the application program 106. This procedure starts when a file encryption key, file initialization data, and write request data are prepared.
[0043]
FIG. 15 shows a write request from the application. 1501 is a write start position, 1502 is the length of write data, and 1503 is write data. In the write request shown in FIG. 15, 1503 write data is requested to be written between positions 1800 to 2799 in the file.
In FIG. 14, first, the record length corresponding to the application program that has made the write request is read from the record size storage unit (step 1401).
As shown in FIG. 16, the record size storage unit 124 stores a record size 1602 for each of various application programs 1601 such as a spreadsheet program and a word processor program. If the corresponding record length is not recorded, the default length recorded at the end of the record size storage unit 124 is read. Here, it is assumed that “512” is read as the length corresponding to the application program that made the write request.
[0044]
If the record length is not recorded in the record size storage unit 124, the write request position 1501 in the file and the length 1502 of the write data included in the write request from the application program are set for this application program. The access information is stored in the access information storage unit 125 (step 1403).
[0045]
As shown in FIG. 17, the access information storage unit 125 records the start position 1701 and the length of write data 1702 for each application program each time there is a write / read request, and can store a plurality of them. . FIG. 17 shows a state where the write request of FIG. 15 is stored in the access information storage unit 125. The data recorded here is used to obtain the record length for encryption after a certain time.
[0046]
Next, the start position of the write request is divided by the record length, and the quotient is set as a record index value indicating the record number in the file (step 1404). If writing is performed across multiple records, the calculation is performed for all records. When the record index is obtained from the write request shown in FIG. 15, the quotient obtained by dividing the write start position “1800” by the record length “512” is 3, and the quotient obtained by dividing the write end position 2799 by 512 is 5. The index values are “3”, “4”, and “5”.
[0047]
Subsequently, the record encryption key for the record of the write destination is calculated using the index value of the record and the file encryption key (step 1405). If it is necessary to make a write request from the beginning of the record, initialization data for the record is obtained from the file initialization data and the record index value. As these calculation methods, for example, a method of concatenating two pieces of data and performing a calculation by a hash function is conceivable. In the case of the write request in FIG. 15, since it is a write request from the middle of record 3 to the middle of record 5, the calculation of the record encryption key of “record 3” and the record encryption keys of “record 4” and “5” Calculate initialization data.
[0048]
Next, it is checked whether the data to be written is an overwrite of the data already stored in the file (step 1406). If the data is not overwritten, the write data is copied to the encryption buffer and the process proceeds to the encryption step (step 1411).
If overwriting, the part necessary for the cipher chaining process and the part necessary for re-encryption are read from the file into the encryption buffer at the write start position (step 1407). The part required for the cipher chaining process is the ciphertext used in the chaining process when encrypting data at the write start position, and is the ciphertext immediately before the write start position. It depends on the method. If the write start position is at the beginning of the record, the record initialization data is used as a part necessary for the encryption chain process, so there is no need to read the part immediately before the write start position from the file. If the length required for the cipher chaining process in this embodiment is “8”, the part necessary for the cipher chaining process in the write request in FIG. 15 is the cipher from the position “1792” to “1799” in the file. It is a sentence. The portion that needs to be re-encrypted is a portion that needs to redo the cipher chaining process by overwriting data, and is from immediately after the write end position to the end of the record that includes this write end position. The portion of the write request in FIG. 15 that requires re-encryption is from “2800” immediately after the write end position in the file to the last position “3071” of “record 5” including this write end position. FIG. 18 shows a part necessary for the cipher chaining process and a part necessary for re-encryption in the file.
[0049]
Subsequently, the portion on the encryption buffer that needs to be re-encrypted is decrypted using the corresponding record encryption key (step 1408). In the write request of FIG. 15, decryption is performed using the record encryption key of “record 5”. Then, the write request data is connected to the decrypted data for re-encryption and written on the encryption buffer (step 1409).
[0050]
Finally, when the data to be encrypted is prepared on the encryption buffer, encrypt it using the encryption key for the record corresponding to the data, the data necessary for the encryption chain processing read from the file, and the initialization data. (Step 1410) This procedure is terminated.
[0051]
(Detailed decryption procedure)
FIG. 19 is a flowchart showing a detailed procedure for reading and decoding data requested to be read from the application program. This procedure starts when the file encryption key and file initialization data are prepared.
FIG. 20 shows a read request from the application. 2001 is a read start position, and 2002 is the length of read data.
[0052]
In FIG. 19, first, as with the write request, the record length corresponding to the application program that has made the read request is read from the record size storage unit (step 1901). If there is no corresponding record length, a default value is read (step 1902), and the read start position 2001 and its length 2002 are recorded in the access information storage unit 125 for this application program (step 1903). The calculation of the record index and the calculation of the encryption key for the record and the initialization data are performed in the same manner as the case of the write request (steps 1904 and 1905).
[0053]
Subsequently, the record corresponding to the read request is read from the file, decrypted using the record encryption key and the initialization data (step 1906), and this procedure ends.
[0054]
(Record length calculation)
FIG. 21 is a flowchart showing a detailed procedure for calculating the record length. This procedure starts when access information recorded in the access information storage unit 125 exceeds a certain number (for example, 100) in an application program.
Here, the record length is assumed to be a power of 2. This is because there are many examples in which the number of powers of 2 is used for the file access unit of the application program and the operating system and the physical recording unit on the storage device in order to simplify processing.
Before starting this procedure, the encryption speed, the decryption speed, the time required to generate a record encryption key, and the time required to generate initialization data are obtained.
[0055]
In FIG. 21, first, an average value of access lengths recorded in the access information storage unit 125 is obtained (step 2102). Here, it is assumed that “140” bytes are obtained as the average access length. Next, the smallest power of 2 that exceeds the average access length is obtained (step 2102). In this example, “256”.
[0056]
Subsequently, the following procedure is performed assuming that the record length is a power of 1, 2, 4,..., 2, and the average write overhead time in each case is obtained (step 2103). The upper limit of the temporary record length is the smallest power of 2 that exceeds the average access length obtained in the previous procedure. In this example, “256”.
[0057]
The calculation performed for each temporary record length is as follows.
First, the average length required for re-encryption processing at the time of writing, and the average number of calculation of the record encryption key and initialization data for each access are obtained. The length required for the re-encryption process is a portion as shown in FIG. The average re-encryption processing length is an average value of values obtained by the expression shown in “Equation 1” for each access length.
[0058]
[Expression 1]

[0059]
The average number of times of calculation is an average value of values obtained by the expression shown in “Expression 2” for each set of access position and access length. The meanings of symbols used in “Equation 1” and “Equation 2” are as shown in FIG. “L% R” means “the remainder of L / R”.
[0060]
[Expression 2]

[0061]
Next, the average re-encryption processing length and average number of calculations obtained as described above, the encryption processing speed, the decryption processing speed, the time taken to generate the record encryption key, and the time taken to generate the initialization data Thus, the average write overhead time when the temporary record length used in the calculation of “Equation 1” and “Equation 2” is used can be obtained using the equation shown in “Equation 3”.
[0062]
[Equation 3]

[0063]
Here, (average re-encryption processing length) / (decryption speed) in “Equation 3” is an average of the time taken to decrypt the portion that needs to be re-encrypted read from the file. Further, (average re-encryption processing length) / (encryption speed) is an average of time taken to encrypt a portion that requires re-encryption processing. {...} × (average number of calculations) is the average of the time taken to calculate the record key and initialization data prepared for each record. Finding the sum of these three equations gives the average write overhead time.
[0064]
Thus, the temporary record length giving the minimum value is selected from the average write overhead time obtained for each temporary record length (step 2104). This is the record length that minimizes the overhead during writing. Finally, the application program and the selected record length are paired and written to the record size storage unit 124 (step 2105).
[0065]
As described above, in the present embodiment, a data read / write request to the storage device 111 issued from the application program 106 of the terminal 101 to the operating system 108 is intercepted, and the data is encrypted at the time of the write request. Obtain an encryption key from the key management server 112 connected via the network 122, encrypt the data with this encryption key, save it in the storage device 111, and read out the encrypted data from the storage device 111 when a read request is made. Since the key for decrypting the encrypted data is obtained from the key management server 112 and the original data obtained by decrypting the encrypted data with this encryption key is passed to the application program 106, the encryption or decryption is performed. Is stored in the storage device 111 without the user's explicit instruction. Automatically encrypts data to be automatically able to decode, the effect is obtained that does not impose troublesome operation to the user when reading. Further, since the data to be stored in the storage device 111 is automatically stored, there is no problem that the user forgets to encrypt the data.
[0066]
Also, before issuing a request to the key management server 1112 to send the encryption key, the user operating the application program 106 is input information for identifying the user, and the correctness of this information is confirmed. The user's key is obtained from the key management server 112 after confirming with the terminal 101 operated by the user, or the identification information input by the user is sent to the key management server 112 and the identification information received by the key management server 112 is corrected. Since the user's encryption key is sent back after confirmation, the risk of decryption is the same even if the portable terminal storing the encrypted confidential data is stolen. Compared with the case where the data is stored in the storage device, the confidentiality of the data can be further increased. For example, if you store encrypted data in a portable terminal and want to access the data internally, connect to the internal LAN, and from outside the company, remotely access the internal network for use. A user who has illegally obtained a terminal not only infers user identification information but also needs to perform user authentication work at the time of remote access. In addition, it can be configured to connect a portable terminal to the same network as the key management server in the company so that important data can be edited and viewed, and since there is no key management server outside the company, the data cannot be accessed. The security can be increased.
[0067]
In addition, the mechanism for intercepting data read / write requests from the application program 106 to the operating system 108 does not need to rewrite existing application programs or operating systems when the operating system 108 provides them. There is no need to replace hardware, and data security can be increased at a minimum cost.
Furthermore, a method of recording a user-specific encryption key on the IC card and managing the encryption key by each user is conceivable. However, data loss becomes impossible due to loss of the IC card itself, Since it is necessary to add a read / write mechanism to the terminal 101, it is disadvantageous in terms of cost. However, by obtaining an encryption key from the key management server 112 as in the present embodiment, there is an advantage that even a terminal that does not have an IC card read / write mechanism can be used.
[0068]
In this embodiment, when encrypting a file, the file encryption key is generated each time without using the user key as it is, but the file itself may be directly encrypted with the user key.
Each time a file is saved or read, the user is prompted to enter a user name and password. However, these pieces of information are temporarily saved in the memory of the terminal 101, and the next time the file is saved and read. In this case, the user input operation can be further simplified by configuring such that the key management request is generated using the temporarily stored user name and password.
Further, by arranging the obtained user key itself in the memory and reusing it later, it is not necessary to perform communication between the terminal 101 and the key management server 112, and the processing speed is reduced by omitting the communication overhead. It can speed up and reduce traffic on the network 122.
[0069]
In addition, when the user saves the file in advance, it is configured to automatically specify the file or directory that the user wants to encrypt, so that only the specified file or files under the specified directory can be encrypted or Decryption can be performed. As a result, a directory representing a storage medium such as a floppy disk can be designated as a place to be encrypted and saved, so that important information can be prevented from being copied out.
[0070]
Furthermore, each functional part that realizes the functions described in the embodiment in the terminal 101 and the key management server 112 is specifically configured by a processing program that realizes an equivalent function. It can be stored in a storage medium such as a CDROM or provided to a user through a communication medium such as the Internet.
[0071]
In this embodiment, the encryption key and the initialization data are calculated for each record. However, the file encryption key and the file initialization data may be used as they are in order to increase the reading / writing speed. In this case, the security of the encrypted file is slightly lost compared to the present embodiment. It is also necessary to change the method for calculating the record length.
[0072]
In order to determine the record length, not only the access length of the application but also a cache unit for file access by the operating system and a data recording unit (for example, sector length) on the storage device can be used.
Further, when the record length is obtained, the average write time is obtained by using both the read / write access records, but it may be calculated by strictly distinguishing the read / write. For this purpose, a column for distinguishing between reading and writing may be provided in the access information storage unit.
The record length may be calculated not only when the record length for the application program is not found, but also periodically, for example, once a week.
[0073]
Further, as a result of obtaining the record length, if the value is different from the record length used so far, the existing file may be re-encrypted.
Further, by providing an area for storing the record length in the encrypted file, the record length when the file is encrypted can be stored and stored. In this way, when the optimum record length for the application program changes, it is possible to easily re-encrypt the existing encrypted file using the new record length value.
[0074]
【The invention's effect】
As described above, according to the present invention, the data stored in the storage device can be automatically encrypted without being explicitly instructed by the user to be encrypted, and can be automatically decrypted when read. As a result, it is possible to obtain an effect that the user is not forced to perform troublesome operations. Further, since the data stored in the storage device is automatically stored, there is no problem that the user forgets to encrypt the data.
[0075]
In addition, the overhead of re-encryption processing and initialization data generation processing when data is overwritten, which is a problem when automatically encrypting and decrypting, can be minimized, compared to the case where such optimization is not performed. Can speed up data overwrite processing.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram showing an embodiment of a computer system to which the present invention is applied.
FIG. 2 is a configuration diagram of a key information record distributed to a user.
FIG. 3 is a flowchart showing a user distribution information creation procedure;
FIG. 4 is a configuration diagram of an authentication token.
FIG. 5 is a flowchart showing a file encryption procedure.
FIG. 6 is a format configuration diagram of a message transmitted and received between a terminal and a key management server.
FIG. 7 is a diagram showing original contents included in a user key request message data part.
FIG. 8 is a configuration diagram of a user key request message.
FIG. 9 is a diagram showing original contents (with a user key) included in a user key response message data part.
FIG. 10 is a diagram showing original contents (no user key) included in a user key response message data part.
FIG. 11 is a configuration diagram of an encrypted file stored in a storage device.
FIG. 12 is a flowchart showing a file decoding procedure.
FIG. 13 is a flowchart illustrating a processing procedure of a key management application.
FIG. 14 is a flowchart showing a detailed procedure of encryption.
FIG. 15 is a configuration diagram of a write request from an application program.
FIG. 16 is a diagram illustrating a record size storage unit.
FIG. 17 is a diagram illustrating an access information storage unit.
FIG. 18 is a diagram illustrating a range overwritten on a file by execution of a write request and a range that requires re-encryption processing.
FIG. 19 is a flowchart showing a detailed procedure of decoding.
FIG. 20 is a configuration diagram of a read request from an application program.
FIG. 21 is a flowchart showing a procedure for obtaining a record length.
FIG. 22 is an explanatory diagram of symbols used in the calculation formula.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 101 ... Terminal, 102 ... User input part, 103 ... Password encryption key generation part, 104 ... File encryption key generation part, 105 ... Encryption / decryption part, 106 ... Application, 107 ... File access hook part, 108 ... Operating system , 109 ... interface for storage device, 110 ... interface for communication, 111 ... storage device, 112 ... key management server, 113 ... key management application, 114 ... user input unit, 115 ... password encryption key generation unit, 116 ... user key generation , 117 ... Encryption / decryption part, 118 ... Operating system, 119 ... Communication interface, 120 ... Storage device interface, 121 ... Key database, 122 ... Network, 123 ... User, 124 ... Record size storage part, 125 ... access information Storage unit.

Claims (9)

A storage device, and a file hook means for intercepting a data read / write request from the application program to the storage device, and a computer for executing processing according to the application program, and processing the data processed by the application program In a method for storing data to be written and stored in the storage device,
In response to a data write request from the application program, the write request is intercepted by the file hook means, and the operating system stores the data to be written in the internal memory of the computer before writing to the storage device. Encrypted in record length units set in advance with an encryption key and written to the storage device,
In response to a read request from the application program, the read request is intercepted by the file hook means, and before the read data is transferred to the application program, the encrypted data from the storage device is transferred to the operating system. After reading in record units, decrypt the encrypted data with the encryption key stored in the internal memory in preset record length units and transfer the decrypted data to the application program that made the read request A data storage method characterized by: 2. The data storage apparatus according to claim 1, wherein only data in a file designated in advance by a user or only data of all files in a designated directory is encrypted or decrypted in the storage device. The data storage method described. 3. The data storage method according to claim 2, wherein the record length unit is set for each application program. Record the access information at the time of file access by the application program, set a temporary record length exceeding the average access length calculated based on the access information, calculate the overhead time for each temporary record length, and the calculation result is The data storage method according to claim 2, wherein the record length is the smallest. 3. The data storage method according to claim 2, wherein the record length is set as a cache unit when a file is accessed by an operating system. 3. The data storage method according to claim 2, wherein the record length is a data recording unit in a storage device. The data storage method according to any one of claims 2 to 6, wherein the encryption key is obtained from a key management computer during authentication of a user who operates the computer. The encryption key is a first encryption key acquired from a key management computer at the time of authentication of a user who operates the computer. When the data to be stored is encrypted, a second encryption key generated inside the computer by the first encryption key is used. An encrypted encryption key obtained by encrypting the data to be written with the first encryption key, and creating the encrypted data body by encrypting the data to be written with the first encryption key. And write to the storage device,
3. When decrypting, the encrypted encryption key is decrypted with a first encryption key, and the encrypted data body is decrypted with a second encryption key obtained by the decryption. The data storage method according to claim 6. Data storage processing program for writing and storing data processed by the application program in the storage device in a computer system including a computer that executes processing according to the application program and a storage device connected to the computer A recording medium on which
A file hook process that intercepts a data read / write request to the storage device issued from the application program to the operating system of the computer;
In response to a data write request from the application program, the write request is intercepted by the file hook means, and the operating system stores the data to be written in the internal memory of the computer before writing to the storage device. A first process of encrypting in a record length unit set in advance with an encryption key and writing to the storage device;
In response to a read request from the application program, the read request is intercepted by the file hook means, and before the read data is transferred to the application program, the encrypted data from the storage device is transferred to the operating system. After reading in record units, decrypt the encrypted data with the encryption key stored in the internal memory in preset record length units and transfer the decrypted data to the application program that made the read request A second process to
A data storage processing recording medium on which is recorded a data storage processing program.

Images