WO2011047717A1

WO2011047717A1 - Method for securing and retrieving a data file

Info

Publication number: WO2011047717A1
Application number: PCT/EP2009/063775
Authority: WO
Inventors: Jennifer Kate Schofield
Original assignee: Jennifer Kate Schofield
Priority date: 2009-10-21
Filing date: 2009-10-21
Publication date: 2011-04-28

Abstract

Method for securing and retrieving a data file stored on a computer comprising the steps of providing a first and a second key, each comprising a data storage unit with a securing/ retrieving program and an encryption key and comprising means for connecting said key to said computer. The method further comprises the steps of connecting the first key with the computer via said means for connecting; causing said data file to be encrypted by said securing/ retrieving program with said encryption key and storing it as an encrypted data file on said computer; removing said first key from the computer; connecting said second key with a computer where said encrypted data file resides via said means for connecting; causing said encrypted data file to be decrypted by said securing/ retrieving program using said encryption key; and removing said second key from the computer.

Description

Method for securing and retrieving a data file

FIELD OF THE INVENTION

[0001] The present invention relates to a method for securing and retrieving a data file, in particular a data file stored on a computer.

BACKGROUND OF THE INVENTION

[0002] There are numerous software and hardware encryption solutions available today but they suffer from several disadvantages.

[0003] It is often necessary to install software on a computer. This is frequently not allowed (for example in the workplace, hotel or internet cafe). Software installation may require the assistance of a 'system administrator' and commonly requires a tedious 'reboot' of the computer before the software can be used . A further problem is that one may desire to encrypt and decrypt a data file on different computers, at home and at work for example. [0004] Cryptography is a highly specialized, mathematically based area and it is difficult for a non-specialist to assess how secure their data is. For example, encrypting something twice or encrypting compressed data can actually reduce overall security which is not intuitive. Choosing passwords and passphrases that contain numbers to replace letters such as "O", "L" and "E" is often assumed to make them unguessable whereas it only marginally increases the time needed to guess them.

[0005] Technology becomes obsolete very quickly. Descriptions of encryption software contain phrases such as "there is no currently known decryption technique" and "decryption without knowledge of the key is impractical using today's computers". Both knowledge and technology advance at an increased rate and encryption techniques considered to be highly secure a few years ago are now regarded as being unusable.

Furthermore, computers themselves become obsolete quickly. The encryption software may no longer be available or may not be compatible when a new computer is purchased .

[0006] Some of the existing solutions store encrypted data on

removable storage. This may be done using software on the computer or hardware within the removable storage. The problem with this is that the data on the removable storage, which is presumably very important, tends not to be backed up. If the removable storage is lost then the data is lost.

[0007] Existing solutions use so-called stream encryption. A relatively short secret key is used to generate a sequence of pseudo-random numbers that are then used to encrypt the data. The encrypted data is secure because the key is a secret and the values of the resulting pseudo-random numbers cannot be predicted . In practice, due to the continuous explosive growth in computing power and advances in the mathematics of cryptography, there has been a constant stream of new, 'unbreakable' standards that have each fallen only to be replaced by a new 'unbreakable' standard.

[0008] The objective of the present invention is thus to provide a method for securing and retrieving a data file stored on a computer which : is easy to use, but at the same time does not compromise on the security of the encrypted data;

- can be employed without the need to install any piece of software on said computer;

can be used on any computer storing data files; allows the encrypted data file to be freely transferred, backed-up, etc, without any risk of compromising its encrypted contents.

[0009] An objective of further embodiment of the present invention is that the encrypted data file is guaranteed to be unbreakable, i.e. the encrypted data file resulting from the method should be mathematically proven to be impossible to be decrypted without the corresponding key.

[0010] An objective of an even further embodiment of the present invention is that the encrypted data file is guaranteed against manipulations and that any attempt to alter the encrypted data file is detected during decryption.

SUMMARY OF THE INVENTION

[0011] The above identified objectives of the present invention are solved by a method for securing and retrieving a data file stored on a computer comprising the steps:

a) providing a first and a second key, each comprising :

a data storage unit with a securing/ retrieving program and an encryption key;

means for connecting the key to said computer;

b) connecting the first key with the computer via said means for

connecting;

c) causing said data file to be encrypted by said securing/ retrieving

program with said encryption key and storing it as an encrypted data file on said computer;

d) removing said first key from the computer;

e) connecting said second key with a computer where said encrypted data file resides via said means for connecting;

f) causing said encrypted data file to be decrypted by said securing/

retrieving program using said encryption key; and

g) removing said second key from the computer [0012] Thus, according to the first embodiment of the present invention, the possession of a physical entity, the key, is the only requirement for encryption and decryption of the data file. This ensures that the method is easy to use since the need to keeping a physical key on one's person or locked away and not leaving it unattended, comes naturally. Since the securing/ retrieving program is stored on the data storage unit on the key itself, there is no need to install any piece of software on the computer where the data file to be secured is stored. Furthermore, since the key is stored on a physical device, the key, and does not need to be transmitted over a communication channel, there is no need to compromise on the key-size. This greatly increases the possibilities as far as encryption is concerned which yields a much safer encryption.

[0013] The fact that the data file is not moved to a new location by the securing method ensures that back-up procedures established for the computer where the data file is stored can continue backing up the data file, this time as encrypted, without the risk of disclosing their contents, or even knowledge that the data file backed up is an encrypted data file. Thus, the encryption of the data file is completely transparent for the back-up

procedures which are not rendered useless by relocation of the data file onto a removable storage as is the case with numerous prior art securing methods.

[0014] The objective of the further embodiment of the present

invention, i.e. that the encrypted data file be guaranteed to be unbreakable, is solved by a method for securing and retrieving a data file stored on a computer, wherein the data file is being encrypted respectively decrypted with a "one time pad" encryption scheme using a portion of the encryption key, stored on the first and/or second key, said portion having the same length as said data file, wherein for each encryption a new portion is being used . In the preferred embodiment of the present invention, measures are taken to ensure that the same portion of the key is never reused. Furthermore, it is ensured that the key itself is uniquely and perfectly randomly generated for each pair of first, respectively second key. [0015] The objective of the even further embodiment of the present invention, i.e. that the encrypted data file is guaranteed against manipulations and that any attempt to alter the encrypted data file is detected during decryption, is solved by a method for securing and retrieving a data file characterized in that a digest of the data file is computed and stored in order to ensure that the data file can not be tampered with.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Further characteristics and advantages of the invention will in the following be described in detail by means of the description and by making reference to the drawings. Which show :

Fig. 1A Renaming of an encrypted data file by the securing/ retrieval program;

Fig. IB Renaming of an encrypted data file by the user in order to

disguise its nature;

Fig. 1C Restoration of the original file name of an encrypted data file the securing/ retrieval program;

Fig. 2A Securing/ retrieving program interface after the key is connected with the computer; Fig. 2B Sequence depicting the usage of the securing/ retrieving program interface for encrypting and opening for editing of a data file;

Fig. 2C Sequence depicting the editing of an encrypted data file followed by closing it, leaving only the encrypted data file on the

computer; Fig. 2D Renamed encrypted data file, being disguised as an audio file.

DESCRIPTION OF PREFERRED EMBODIMENTS

[0017] Certain terms will be used in this patent application, the formulation of which should not be interpreted to be limited by the specific term chosen, but as to relate to the general concept behind the specific term. [0018] In the context of the present application, computer shall refer to any kind of computing device which is capable to carry out a simple set of instructions, such as PCs, PDAs, mobile phones, game consoles, terminals, etc. [0019] The preferred embodiment of the present invention uses a pair of keys for all securing and retrieving operations. These keys, i.e. the first key and second key, are provided always as a pair.

[0020] Each key comprises a data storage unit with a securing/ retrieving program and an encryption key; and means for connecting the key with a computer.

[0021] In its preferred embodiment, the data storage unit is a nonvolatile memory, like a flash memory unit. In this embodiment, the key itself is a removable storage device, also known as a "flash drive". The key as provided with said means for connecting can thus be a "USB flash drive" wherein the USB connector is a suitable and currently almost universally compatible means for connecting of the key with most commercially available computers. For special applications though, specialized connectors may be employed as connection means. Wired or wireless remote connections are also adaptable for this purpose. [0022] Furthermore, any storage medium like a hard drive disk or even write-once media, like CD-R, DVD-R or BD-R may act as the data storage unit. This ensures that the key is easily adaptable to various uses, and depending on particular needs, providing suitable storage capacity. In these embodiments, the means for connecting of the key may be the corresponding connectors of the hard drive, SSD or the like or the drives suitable for reading the storage media .

[0023] The securing/ retrieving program is provided to carry out the encryption/ decryption of the data file stored on the computer after the key is connected to said computer. The securing/ retrieving program may be configured in various ways to achieve its task without departing from the general concept of the present invention. The step of "causing said data file to be encrypted by said securing/ retrieving program with said encryption key and storing it as an encrypted data file on said computer" can be initiated in various ways. In the preferred embodiment of the present invention, this step is initiated by "dragging" the data file onto an icon that appears when connecting the key with the computer. The securing/ retrieving program then performs the necessary steps to encrypt the data file. The sequence of steps carried out during encryption depends on the encryption scheme used. The sequence corresponding to a particularly preferred encryption scheme of the present invention will be described in detail in later paragraphs. These steps may include opening the data file for editing, closing the data file, applying some auxiliary maintenance procedures, and encrypting the data file using the encryption key found on one of the keys. As a last step, the data file is stored on the computer as an encrypted data file, preferably in the exact same location where the data file was stored before encryption.

[0024] After encryption is complete, the key may be removed from the computer, making the decryption of the encrypted data file impossible without the possession of at least one of the pair of keys.

[0025] When decryption of the encrypted data file is desired, the second key from the pair of keys needs to be connected to the computer. After the second key has been connected, the decryption process may be initiated. Similarly to the encryption process, in the preferred embodiment of the present invention, the decryption process is started by dragging the encrypted data file onto the icon that appears upon connecting the key with the computer. The securing/ retrieving program recognizes that the data file dragged onto the icon is an encrypted data file and initiates the decryption sequence. The sequence of steps carried out during decryption depends on the encryption scheme used . The sequence corresponding to a particularly preferred encryption scheme of the present invention will be described in detail in later paragraphs.

[0026] Depending on particular implementation/ settings, the decryption of the encrypted data file may be followed, after editing/ viewing and closing, by a subsequent encryption and storage of the data file on the computer in its encrypted form. Alternatively, the decryption may be followed by storage of the data file on the computer in its decrypted form. [0027] The second key may be then removed from the computer and the procedure may be repeated.

[0028] In a particular embodiment of the present invention, the encryption keys on the first and second keys are identical, thus the first key and second key are interchangeable. This embodiment has several benefits, such as easy replacement or the mere possibility of decryption in case of the loss of a key. The interchangeable nature of the keys has to be addressed when it comes to security to keep track of encryption/ decryption of data files with one or the other of the pair of keys. This embodiment has multiple uses, such as a diary/ testament intended for posthumous publication is encrypted using one of the keys. The encrypted data file is stored in a well known place, on a public file server perhaps. The other key is deposited with a bank or lawyer to be made available on death or on a specific date. The data file can be continuously updated until the publication date without involving the lawyer or bank. In any case the security of the data file lies with the

possession of the key.

[0029] The data storage unit of the keys may further comprise a flag which identifies a portion of the key used for encryption. In case of keys with identical encryption keys, provision of different flags for each key ensures that, while both keys may be used to decrypt data files encrypted with any of the keys, the same portion of the encryption key is only used by one of the keys, thus ensuring the unique usage of the encryption key by multiple keys. In case of a single pair of keys with identical encryption keys, the first key and second key are provided with flags A and B. Since the encryption keys are identical, they can each decrypt data files encrypted by the other, but the first key will use only the fist half of the encryption key, identified by A, the second key only the second half portion of the of the encryption key, identified by B, for encryption.

[0030] In a further embodiment of the present invention, the pair of keys contains different encryption keys. In this embodiment, the encryption of the data file with the first key may be followed by a successive encryption with the second key. The resulting "double-encrypted" data file can be fully decrypted again only by the possession of both keys. It is to be noted that this measure is not taken for making the encryption itself stronger, this is not necessary, but to accommodate different usage scenarios. The encrypted data file may be stored at any given location or even a public server and the keys can be given to two different people. It is thereby ensured that they have to be in agreement in order to decrypt the data file. This method may be useful for cases where a document has to be deposited in a manner that it can't be accessed or altered without the consent of both parties.

[0031] It is to be noted that the concepts presented herein may be extended for more than a pair of keys, i.e. more than two keys are provided with identical/ different encryption keys and any/ all keys are required for encryption/ decryption of a data file.

[0032] In all embodiments of the present invention, all data, required to decrypt a data file encrypted according to the claimed method, is embedded into the data file during encryption. This embedded data includes filetype, extension, file headers, data identifying the encryption key or portion of the encryption key used for encryption, or metadata associated with the data file, etc. Furthermore, in a particularly advantageous embodiment of the present invention, a digest of the data file is computed and stored to ensure that the data file can not be modified after encryption. Preferably, this digest is computed before encryption and added to the data file, thus allowing said digest to be encrypted together with the data file. All these measures ensure that the contents of the data file may not be altered even with the knowledge of the unencrypted original contents, since an appropriate digest algorithm ensures that even the smallest change in the data file renders the digest to be invalid .

[0033] In a particular embodiment, while being encrypted, the name of and/or metadata related to said data file is/are being changed in order to conceal the nature of the data file, the original name/ metadata being recoverable only by decryption of the encrypted data file using the first and/or second key used for encryption.

[0034] The fact that the method according to the present invention may be used without the need to install any kind of software, and that all the information needed to decrypt the encrypted data file is embedded in the encrypted data file itself, allows the encrypted data file to be freely

transferred after encryption and be decrypted on any computer where the file has been transferred to. This feature provides a great portability to the encrypted data file.

[0035] In a further advantageous embodiment of the present invention, said data storage unit can be written only once for storing said securing/ retrieving program and encryption key, thus preventing any further

modifications intended to compromise said securing/ retrieving program and/or encryption key. The securing/ retrieving program and the encryption key is written onto this data storage unit by the manufacturer of the keys and any change of either the securing/ retrieving program or the encryption key is prevented. This additional level of security ensures that one can not manipulate a key by substituting the encryption key known to an attacker and distributing the compromised key. In a further embodiment, instead of being write-once, the data storage unit is protected against alterations or even access by other means, such as a PIN code or other known measures. As a further addition, the key may comprise a further data storage unit which is not write protected for storing additional data required by said securing/ retrieving program. Said additional data being encryption key usage data, said flags for identifying portions of the key used for encryption or other maintenance data of the securing/ retrieving program. It is to be noted that the data storage unit and the further data storage unit may be comprised within the same physical storage device being spilt into multiple logical partitions or the like, enabling the definition of a write-once partition for storing the securing/ retrieving program and the encryption key and the definition of a further partition for additional data .

[0036] In usage scenarios where multiple keys are used to encrypt/ decrypt the same data file, there is a need to keep track of the portions of the encryption key used for encrypting the data file. This is done by storing so- called key usage data . In order to ensure complete independence of the encrypted data file, the key usage data is embedded into the encrypted data file. Thus, during decryption, the securing/ retrieving program will be able to read this key usage data and identify the portion of the key used for encryption and needed now for decryption. Since the encryption key is perfectly random and unique, the presence of the key usage data does not compromise the integrity of the securing method. The key usage data may be a sequence index or a small portion of the encryption key uniquely identifying the portion of the key used for encryption.

MOST PREFERRED EMBODIMENT [0037] In the following paragraphs, the detailed implementation of the preferred method of the present invention is described. According to this embodiment, the securing/ retrieving program and the key are provided on a "USB flash drive" and requires no installation. In its basic form, it does not use passwords or PINs and relies entirely on the user being in possession of a physical key, the USB flash drive. Although this can itself be inconvenient and increase the likelihood of the secret data being revealed, it has the overriding advantage that a non-expert can assess the risk and behave accordingly. People are used to dealing with physical keys for houses, offices etc. The need to keeping a physical key on your person or locked away and not leaving it unattended where it can be copied, comes naturally. The method is very straight-forward and, if used correctly, resistant to attack over prolonged time periods. Because the key is stored on a physical device there is no need to compromise on the key-size. Since the key is not overused , the encrypted data is inherently safe, independent of future developments in cryptography or computers. If the key is lost then a spare key can be used . There is nothing to connect the lost key with the encrypted data so the data is still secure. The encrypted data file can be left on a centrally managed computer which gets regularly backed up. The encrypted data file may also be 'stored' using an online service.

- PREFERRED ENCRYPTION SCHEME

[0038] Existing solutions use so-called stream encryption. A relatively short secret key is used to generate a sequence of pseudo-random numbers that are then used to encrypt the data. The encrypted data is secure because the key is secret and the values of the resulting pseudo-random numbers cannot be predicted . In practice, due to the continuous explosive growth in computing power and advances in the mathematics of cryptography, there has been a constant stream of new, 'unbreakable' standards that have each fallen only to be replaced by a new 'unbreakable' standard.

[0039] The preferred embodiment of the present invention uses the only encryption scheme that is guaranteed to be unbreakable, i.e. the so-called 'one time pad' which is also known as 'perfect encryption'. This scheme uses a very long truly random key (as long as the data to be encrypted) which is never reused . Because there is no mathematical relationship between the key and the data, it is impossible to spot patterns and break the encryption. The 'one time pad' is usually dismissed as being impractical because of:

a) The difficulty of generating large amounts of truly random data for the key;

b) The difficulty of securely distributing the long keys, especially when the purpose of the encryption is to communicate securely via untrusted

communication channels, such as the internet; and

c) The existence of more convenient sufficiently secure alternatives.

To address a), the key according to the present invention will come

preinstalled with a large encryption key generated from a physical source such as ambient noise. Since the present invention is primarily concerned with securing data rather than transmitting it, item b) does not apply. The time dependent nature of c) has already been described, what is secure today probably will not be secure tomorrow.

- ENCRYPTING A DATA FILE [0040] Encrypted data files are made up of 2 or more 1KB blocks and have the following layout. The entire file is encrypted with the one-time-pad : 4 bytes

512 bytes

4 bytes

256 bytes

64 bytes

184 bytes

1024 bytes

1024 or fewer bytes

Zero to 1023 bytes size

The following sequence is carried out for encrypting a data file :

1. Setting the version to a constant number.

2. Filling "key specifier" and "reserved" in the area with zeroes.

3. Setting the unencrypted file size in the header.

4. Setting original file name in the header.

5. Setting the digest derived from a key block and the entire unencrypted data in the header.

6. Copying of the data to be encrypted into the subsequent blocks using as many blocks as are necessary. The final block may be incomplete if the size of the data is not divisible by 1024. In this case the unused part of the block is filled with zeroes.

7. Appending a "dross" area filled with zeroes which has a random size of zero to 1023 bytes.

8. Encrypting the entire file with the one-time-pad by applying a logical XOR between each byte of the file and corresponding byte of the key.

8.1 First the header is encrypted with one key block;

8.2 A key block to be included in the digest is saved; and

8.3 As many key blocks as are necessary to encrypt the remainder of the file are used . It is to be noted that the steps above are a 'logical' description of the operation of the securing/ retrieving program. In practice the securing/ retrieving program builds the blocks in sequence, encrypts them, and writes them to the disk in a single pass. This avoids writing unencrypted data to the disk.

The purpose of the various fields is described below:

This is to allow the file format to be changed . The securing/ retrieving program can check the 'version' field to determine how it has to interpret the remainder of the header.

These 64 bytes are initially zero so, after encryption, they contain 64 bytes of raw key. This is used by the securing/ retrieving program during decryption to find which part of the key was used for encryption.

The size of encrypted data is rounded up to the next 1024 byte boundary. The original size has to be kept to be able to correctly decrypt the file. The user can also append additional 'junk' data to the file to further disguise it.

The user may change the name and type of the encrypted data file to disguise it. The original name has to be kept so that the file can be opened and so that the user is sure that they have decrypted the correct file.

The decrypt operation checks that the decrypted result has the same digest as the original content. This guards against the file being accidentally or deliberately corrupted or shortened.

This is a random amount of random data (from the key) to hide the true file size. Without this, the encrypted files would always be a multiple of 1024 bytes which would make them more recognizable. The size rounding and dross are needed for the following reason. If, for example, an encrypted file that was known to contain the word "YES" became shorter by one byte after an update then someone may deduce that "YES" had been changed to "NO".

[0041] The format of the encrypted data files described in the previous section means that they exhibit the following properties:

They contain random data . If the encryption key is truly random then the encrypted data file will also be truly random. The header is unrecognizable after encryption. There is no technical way to determine that the file was produced by the securing/ retrieving program.

If someone assumes for non-technical reasons that the encrypted file was created by the securing/ retrieving program then there is no way to determine which key was used to encrypt the file other than by trying various keys and examining the results.

The size of the encrypted data file is somewhat random. Large input will create large encrypted files and small input will create small encrypted files but it is not possible to deduce the exact size of the original from the size of the encrypted file. The file format allows any amount of "junk" (or misleadingly recognizable data) to be appended to the file so that the size can be disguised fully. The securing/ retrieving program always appends zero to 1023 bytes of random data however. - The digest ensures that the decrypt operation can tell if the encrypted data file has be tampered with or corrupted during transmission or storage. Without the digest, one-time-pad encrypted files can easily be manipulated by an attacker if they know the original contents:

Example :

Plain text: 'Β' 'ΙΓ Ύ' ' '

Random key: 72 5D Fl 6B 24

Encrypted : 30 08 A8 48 15

[0042] If the attacker has the plain contents and the encrypted contents then they can easily deduce that portion of the key and alter the encrypted text:

Modified : 30 08 A8 48 16

Decrypted : 'Β' 'ΙΓ Ύ' ' ' '2' [0043] Without the digest, the person decrypting the file would be oblivious to the fact that the data had been modified. Because of the digest, the securing/ retrieving program can reject files that have been deliberately modified or corrupted during transmission. Note that the securing/ retrieving program creates the digest from a block of key data that was not used to encrypt the file plus all the unencrypted data . This technique ensures that even an attacker with an unencrypted file and an encrypted version of the same file cannot recreate a valid digest because the attacker does not have the key block that was used for digest creation.

- DECRYPTING A DATA FILE

[0044] The first step of the decryption process is to find which part of the encryption key was used to encrypt the data file. This is done using the 64 byte 'key selector' in the file header. The key selector contains raw key data. In principle the securing/ retrieving program only needs to read the key file in blocks and compare the 64 bytes key selector field of every block with the key selector from the encrypted data file. In practice, it is too time-consuming to read, say, 2GB of key data from, say, a USB memory stick. To increase the speed of this search, an additional file called the "index" file, as described in later paragraphs, is used. This allows the correct encryption key block to be found extremely rapidly or to quickly determine that the data file was not encrypted using this key. [0045] Once the start of the encryption key has been found, the header of the data file can be decrypted . The next key block is included in the digest of the data and the next series of encryption key blocks are used to decrypt the data. The decrypted data is written to a data file while calculating the digest of the contents. The calculated digest is compared against the value in the header to make sure that the exact original content has been recreated .

[0046] Finally, the data file's name and size are set to their original values using the fields in the header.

- FILES USED DURING ENCRYPTION AND DECRYPTION

[0047] There are four main files that are used during encryption and decryption : 1. The encryption key file which contains a large amount (typically gigabytes) of random data . The first block of the encryption key file is not used. This allows even a "WAV" file containing random noise, for example, to be used as a key file. The WAV file header is smaller than one key block. 2. The status file which keeps track of how much of the key has been used. It contains a single integer which is the block number of the last used block in the key file. If this file does not exist then the securing/ retrieving program creates it.

3. OPTIONAL: Encryption key flag . If it contains "A" then the securing/ retrieving program only uses the first half of the key file for encrypting data files but can use the whole encryption key file when decrypting. If it contains "B" then the securing/ retrieving program uses only the second half of the encryption key for encrypting documents but can use the whole key file when decrypting . This mechanism allows two keys to be created that can decode each other's files but will never use the same part of key for encryption. When two people are exchanging messages using a pair of keys, it is important that the one-time-pad is never reused because this would greatly weaken the security, especially if messages contain "publicly known" data (JPEG picture files and MS-Word document s always starts with the same sequence of values for example).

4. The index file which allows a given portion to be found quickly in the encryption key. If this file does not already exist then the securing/ retrieving program creates it. The index file has the format shown below:

INDEX FILE(4 bytes per

KEY FILE (1024 bytes per entry)

entry)

Key block 0 (unused)

Key block 1

Index of key block N-l

Key block M

Index of key block M

Index of key block 1

Key block N-l

The index file is created by the securing/ retrieving program as follows:

It gets the size of the encryption key and converts this to 1024 bytes blocks. The result is "N" blocks. - An index file filled with 3*N zeroes is created. Each record is a four byte integer so the index file is relatively small (about one hundredth of the size of the encryption key file).

The key file is sequentially read and the first four bytes of the key specifier of each key block are taken. This is considered as an integer "K" and "I" = K modulo 3*N is calculated .

If index file entry "I" contains zero then the securing/ retrieving program stores the index of the current key block in it.

If index file entry "I" does not contain zero then it is already in use and the securing/ retrieving program tries entry "1 + 1", "1+2" etc until it finds a free entry. If it reaches the end of the file before finding a free entry then it goes back to the start of the file. Because the index file has 3*N entries and the key data is very random, entry "I" will almost always be free and it is not normally necessary to go to "1 + 1" or further.

The securing/ retrieving program uses the index file to find the key start point as follows: It gets X = the first four bytes of the key specifier from the encrypted file.

It calculates Y = X modulo 3*N.

It gets V = the integer in entry Ύ" from the index file. - If "V" is zero then the file is either not encrypted or encrypted with a different key and the process ends.

If it is non-zero then the securing/ retrieving program gets key block "V" from the key file.

It compares the entire key specifier from the encrypted file with the key specifier in key block "V".

If the two are equal then the start of the key has been found and the process is finished .

If they are not equal then the securing/ retrieving program moves to index record Y+ l, Y+2 etc. but a zero index file record terminates the search and means that the file is not encrypted or encrypted with a different key.

- CREATION OF THE ENCRYPTION KEYS [0048] The method according to the present invention requires a large file containing random data that should ideally be generated from a physical source to be used as the encryption key. The following sources have been tried successfully:

1. Recording the audio output of a VHF radio that is not tuned to any station. This approach is somewhat easier to implement and does not require any special hardware.

2. Recording the video output of a PC analog TV-tuner that is not tuned to any station. This approach creates the required random data hundreds of times more quickly because of the higher bandwidth of the video signal . [0049] In both cases the result should be "whitened" before use. This is because the signal, although unpredictable, is not equally likely to contain a "0" or "1" at any given bit position. The securing/ retrieving program also has a "whiten" program that reads an audio or video file and uses the Von

Neumann whitening algorithm for example to process the data.

- DIGEST

[0050] The preferred embodiment of the present invention uses the public domain Whirlpool algorithm to calculate data digests for the following purposes: 1. To ensure that the encrypted data file is not tampered with. The encrypted data file contains a digest of a key block and the original content.

2. To quickly check if a file was changed by the editing program. The securing/ retrieving program calculates a digest of the 'new' and 'old' data files and compares them. If the digest has not changed then no changes to the data file have been made and there is no need to re-encrypt it. This ensures that the encryption key is not wasted when the user is simply opening an encrypted data file for viewing only.

[0051] The Whirlpool digest algorithm has no known security flaws but it should be noted that the whole data file, including the header containing the digests, are encrypted with the one-time-pad . Thus the encryption does not depend on the strength or weakness of the Whirlpool digest.

SPECIFIC IMPLEMENTATION OF THE SECURING/ RETRIEVING PROGRAM INTERFACE [0052] In the following section, a specific implementation of the securing program interface is described .

[0053] The program is not a desktop application in the classical sense, in that it does not have a main window, menus, options etc. It is intended to be started by "dragging" a data file onto the executable. This starts an instance of the program which runs in the background until the selected operation is complete. However, if an error occurs then the securing/ retrieving program displays a 'pop up' window with an "OK" button to notify the user of the error. When the program has completed the requested action, it quietly exits. The program has three modes of operation. The mode is dependent on the first character of the executable file name so by renaming the program file one can select a different mode of operation. These modes allow different user interfaces to be evaluated . The modes are shown in the table below:

[0054] The executable files "open.exe", "encrypt.exe" and "decrypt.exe" are mutually compatible and can be used in combination. For example, "open" could be used as the main, convenient interface with "encrypt" and "decrypt" being supplied in an 'Advanced' folder. The main problem with the explicit "encrypt" and "decrypt" operations could be that the users could forget to encrypt a file again after they had edited it. With the "open" program this very important step is carried out automatically when the user closes the window that is being used to edit the file.

[0055] The securing/ retrieving program can also be called from the command line which is useful for scripting and testing . In this case the executable name is ignored . For the 'open', 'encrypt' and 'decrypt' functions, the command line syntax is as follows: open -o <file-name> open -e <file-name>

open -d <file-name>

- FILE NAME OF THE ENCRYPTED DATA FILE

[0056] By default, the securing/ retrieving program renames files when it encrypts them. It appends„ (encrypted)" to the file name which also changes the icon that is displayed as illustrated in Figure 1A. This naming scheme helps the user keep track of encrypted data files. The user can, however, change the name and type of the data file to disguise it, as shown on Figure IB. The encrypted data file now looks like a 'music' (mp3) file. The encrypted data file invisibly contains the original name and type so that the securing/ retrieving program is able to "open" it with the correct program (a text editor in this case) and the original data file name will be displayed in the text editor's title bar. If the file is dropped onto the "decrypt" program then the original name is restored as shown on Figure 1C.

- ERASING DATA FILES

[0057] When the securing/ retrieving program needs to delete data files, for example the original unencrypted source file, it does the following :

It overwrites every block of the data file with a block of randomly generated data. This is repeated three times. It 'flushes' the file system after every 'write' to ensure the random data is really written to the disk.

It renames the file to a long, randomly generated name. This is also repeated three times.

It deletes the file.

This procedure greatly reduces the probability that someone can 'revive' the original unencrypted data file or its name using low level disk repair tools. Despite this, for optimal security, the user should ideally work as follows: 1. Create an empty file using e.g . Text editor. 2. Drop the empty file onto the "open" program. The securing/ retrieving program starts the text editor.

3. Enter the desired text into the text editor, save and close. The securing/ retrieving program encrypts the data file.

4. Drop the encrypted data file onto the "open" program when more text has to be added.

This procedure ensures that the unencrypted text is never written to the main disk of the computer. - DETECTING THAT THE USER HAS FINISHED EDITING A FILE ON WINDOWS

[0058] The securing/ retrieving program needs to start an editing program such as a text editor or spreadsheet editor and then wait for the user to finish editing before encrypting the data file again (if it has changed). The securing/ retrieving program does this by waiting for the editing program to exit. There is a problem if the editing program was already running, however. In this case, when an encrypted data file is dropped onto "open" then a new instance of the editing program will open a new window for the unencrypted data file. The user closes the window after editing the document but the editing program continues to run because of the first window running the other instance of the editing program was already open. The securing/ retrieving program will be notified immediately that the editing program has exited in these circumstances even though it is still running . The securing/ retrieving program gets around this problem by periodically scanning all the running programs on the computer and getting the text from their title bars. It uses this to find out which window is being used to edit the unencrypted document. When this window no longer exists then the securing/ retrieving program knows to re-encrypt the file.

USAGE SCENRARIO OF THE SPECIFIC IMPLEMENTATION OF THE SECURING/ RETRIEVING PROGRAM INTERFACE

[0059] On inserting the key, i.e. USB flash drive in this preferred embodiment, a new disk will automatically appear. Opening this disk displays a window similar to the one shown on Figure 2A. [0060] There is an icon onto which one can 'drag and drop' data files. When a file is dropped onto the padlock icon, the data file is 'opened' using the program that was used to create it. For example, a text document will be opened with a text editor, a spreadsheet in a spreadsheet editor, etc. If the file was originally encrypted then it is first decrypted before opening . When the application is closed then the file is re-encrypted . The net result is that one only has to drag a file onto the padlock item to make it safe, to make changes and keep those changes safe. This sequence is shown on Figure 2B.

[0061] One may then edit the document and close it again as shown on figure 2C. The file gets a new name with "(encrypted)" appended to it. One can simply drag this file to the padlock icon again to make more changes. One can also change the name of the encrypted file to make it look like something else, like an audio file for example, as shown on figure 2D. Even though the name and type has changed, the securing/ retrieving program knows the original name.

[0062] In a further embodiment of the present invention, a usage meter is provided to indicate how much of the encryption key remains to be used.

[0063] As an optional component, an integrated editor is provided, the use of it being more secure than using other text editors which store temporary backup copies of the edited document in obscure locations thus compromising security.

[0064] It will be understood that many variations could be adopted based on the specific structure hereinbefore described without departing from the scope of the invention as defined in the following claims. INDUSTRIAL APPLICATIONS

[0065] Securing/ retrieving program provides a simple to use,

unbreakable encryption for various amounts of sensitive data . It uses plain simple one-time-pad encryption with no complicated enhancements' that could jeopardize security. [0066] The securing/ retrieving program and the encryption key are delivered on two keys, USB flash drives. The contents of these two keys are different to all other keys. The purchaser will be recommended to keep one key in a safe place and keep the other key on their person, perhaps on a key chain. The keys are immediately ready for use.

[0067] After a while, the encryption key will be exhausted and the user can either buy a new one or start using the 'spare' key. When the 'spare key' is exhausted then there is no option other than to buy a new key.

[0068] A further service provided within the concept of the present invention is to offer a registration service for duplicate keys so that the purchaser could later obtain replacement keys. As an alternative solution, a duplicate key on a DVD-ROM - a copy of the key could be provided on a DVD- ROM to be stored in a safe place.

- SECURE MAIL

[0069] Instead of keeping the second key in a safe place it could be given to a trusted friend. The user can then communicate in complete privacy with that friend by encrypting messages before sending them as attachments to an email. The fist key (A) and second key (B) are made in such a way that they can each decrypt each other's messages but A will never use the same key as B when encrypting a message and vice-versa.

- POSTHUMOUS PUBLICATION [0070] A diary intended for posthumous publication is encrypted using the first key. The encrypted data file is stored in a well known place, on a public file server for example. The second key is deposited with a bank or lawyer to be made available on death or on a specific date. The data file can be continuously updated until the publication date without involving the lawyer or bank.

- DOUBLE ENCRYPTION WITH DIFFERENT KEYS

[0071] Many encryption techniques are weakened if data is encrypted twice but this is not the case with the method of the present invention. A data file (perhaps containing the PIN of a bank account containing emergency funds) can be encrypted twice in succession with two different keys. The data file and one of the keys can be given to two different people. They have to be in agreement that a situation warrants access to the emergency funds in order to decrypt the data file containing the PIN code.

Claims

Claims:

1. Method for securing and retrieving a data file stored on a computer

comprising the steps:

a) providing a first and a second key, each comprising :

a data storage unit with a securing/ retrieving program and an encryption key;

means for connecting said key to said computer;

b) connecting the first key with the computer via said means for

connecting;

c) causing the data file to be encrypted by said securing/ retrieving

program with the encryption key and storing it as an encrypted data file on said computer;

d) removing the first key from the computer;

e) connecting the second key with a computer where said encrypted data file resides via the means for connecting;

f) causing said encrypted data file to be decrypted by said securing/

retrieving program using said encryption key; and

g) removing the second key from the computer.

2. Method for securing and retrieving a data file according to claim 1,

characterized in that the encryption keys on said first respectively second keys are identical, thus the first respectively second keys being interchangeable.

3. Method for securing and retrieving a data file according to claim 2,

characterized in that the data storage unit of the fist key and second key comprise a first flag and a second flag, identifying different portions of the encryption key to be used for encryption by said first respectively second key.

4. Method for securing and retrieving a data file according to claim 1,

characterized in that said first respectively second keys comprise a first respectively a second encryption key which are different and said method further comprises the steps: after step d) : connecting said second key with a computer where said encrypted data file resides and causing said encrypted data file to be encrypted again by said securing/ retrieving program with the second encryption key and storing it as an encrypted data file on said computer;

after step g) connecting said first key with a computer where said encrypted data file resides and causing said encrypted data file, still encrypted with the first key, to be decrypted by said securing/ retrieving program using the first encryption key; followed by removal of said first key from the computer.

Method for securing and retrieving a data file according to any of the previous claims,

characterized in that it further comprises the step:

- before step e) said encrypted data file is transferred to a computer different from said computer used for encryption.

characterized in that said data file is being encrypted respectively decrypted with a "one time pad" encryption scheme using a portion of the encryption key, stored on the first and/or second key, said portion having the same length as said data file, wherein for each encryption a new portion is being used.

Method for securing and retrieving a data file according to claim,

characterized in that key usage data, identifying portions of the encryption key used for encryption, is embedded in said encrypted data file.

characterized in that the encryption key stored in said first, respectively second key is uniquely and perfectly randomly generated fo each pair of first, respectively second key.

Method for securing and retrieving a data file according to claim 8, characterized in that the encryption key is generated from

unpredictable environmental variables.

characterized in that all data required to decrypt said encrypted data file is embedded in said encrypted data file during encryption.

characterized in that while being encrypted, the name of and/or metadata related to said data file is/are being changed in order to conceal the nature of the data file, the original name/ metadata being recoverable only by decryption of the encrypted data file using the first and/or second key used for encryption.

characterized in that said data storage unit can be written only once for storing said securing/ retrieving program and encryption key, thus preventing any further modifications intended to compromise said securing/ retrieving program and/or encryption key.

Method for securing and retrieving a data file according to claim 12, characterized in that said key comprises a further data storage unit fo storing additional data required by said securing/ retrieving program.

14. Method for securing and retrieving a data file according to one of the previous claims, characterized in that a digest of the data file is computed and in order to ensure that the data file can not be tampered with.

Method for securing and retrieving a data file according to claim 14, characterized in that, said digest is computed before encryption of the data file and added to said data file, thus allowing said digest to be encrypted as well.