Secure Data File Structure and Method for Dissemination Thereof

Abstract

A datafile structure comprises a plurality of individual files, each of those individual files being encrypted using different encryption keys. The individual encrypted files are arranged in sequence

Description

The present invention relates to data security, and, more particularly, methods, systems and associated datafiles for storing multiple files together in a secure manner for transmission and allowing recipients access thereto. Background of the Invention There are numerous scenarios in which it is required to provide multiple files as a bundle or collection on the understanding that a subset of the files might be needed by one or more recipient. An example of such a scenario is when an individual is required to submit proof of identity documents to an intermediary. The identity documents may for example include a plurality of documents to provide photographic ID, a plurality of documents to provide proof of address, documents to prove financial standing and / or one or more documents to prove marital status, employment history or the like. However, different end recipients may only require some documents but not others for their own individual purposes. In such a scenario, the individual must send the whole bundle of documents to the intermediary and is then reliant on the security measures and correct handling of the documents by the intermediary in order to ensure that only the relevant, essential documents are securely shared with the relevant recipients. This is clearly disadvantageous to the individual, who loses control of their own personal information and who may share additional documents with the intermediary than are strictly necessary for any individual intended purpose. Whilst there exist conventional encryption techniques for protecting the individual documents or the whole bundle of documents collectively, such techniques are not ideal. In the case of individual document encryption, there exists the problem of an intermediary or individual repeatedly having to check which documents are required for a specific end user and then sending those individual documents and corresponding keys to allow access thereto. This causes an administrative burden and the potential for errors. If an entire, singular bundle of documents is maintained and sent to any end user, this is administratively simple but repeatedly sends additional documents to end users that are not needed by them, thereby proliferating the unwanted dissemination of the individual’s personal details. The above scenario of an individual’s personal details and associated proof of identity is just one example. There exist a wide variety of other scenarios in which it is desirable to collect a bundle of documents / files for transmission to recipients even though different recipients will only require access to some of those documents for their own individual purposes. It is the aim of the present invention to eliminate or mitigate one or more of the above-mentioned problems. It may be considered an additional or alternative aim of the invention to provide a method / system and / or associated file structure by which files can be collated and transmitted securely to different recipients who may require access to only some of those files, without unnecessary dissemination of their contents. Summary of the Invention According to a second aspect of the invention, there is provided a datafile structure as recited in appended claim 1. Optional features are defined in dependent claims 2-12, which may be applied to any of the aspects defined herein. The invention may be used in a system for encrypting a datafile, comprising: a user device arranged to generate a public / private key pair for encryption of a plurality of individual files; a file security management server arranged to receive the plurality of individual files and to generate a singular datafile structure according to the first or second aspect. The file security management server may log the public keys in a key store. The file security management server may log the singular datafile structure or an identifier thereof in a data store. The file security management server may encrypt the single datafile, including the individual encrypted files and EOF identifiers thereof. The single datafile may comprise a file expiry identifier. There may be provided a system for decrypting or opening the datafile structure of the first aspect, said system comprising the user device and file security management server of the third aspect and a recipient device for receiving the single datafile, wherein the recipient device receives the single datafile and the user device receives the public keys for the individual encrypted files, wherein the recipient device receives individual decrypted files from the single datafile based upon the public keys provided. According to a further aspect of the invention, there is provided a method of encrypting a datafile as recited in claim 13. There may be provided a method for decrypting or opening a datafile 5 corresponding with the further aspect. According to another aspect, there is provided a data carrier comprising machine readable instruction for control of one or more processor to create a datafile structure as recited in appended claim 17. Any of the optional or essential features defined in relation to any one aspect of the invention above may be applied to any further aspect, wherever practicable. Those optional feature combinations have not been explicitly repeated only for conciseness. 15 Detailed Description of Embodiments Workable embodiments of the invention are described in further detail below, by way of example only, with reference to the accompanying drawings, of which: Figure 1 shows a schematic overview of a system for securing files in accordance with an example of the invention; Figure 2 shows a schematic a schematic overview of a system for sharing the secured files; Figure 3 shows a table of example data used to create the secure files; Figure 4 shows a schematic of a secure file structure; Figure 5 shows the overall secure file structure with its accompanying data Figure 1 shows a user device 10, using which a user can transmit a plurality of sensitive files 12. The user device 10 may be a conventional computing device such as a desktop / laptop PC, a server, a smartphone, tablet or other conventional computing device. The files 12 may be stored on the device 10, e.g. in a nonvolatile memory device thereof, or else may be accessible to the user device 10 for the purpose of transmitting them to, or allowing access to them by, a server 14. For example, the sensitive files 12 could be stored in a cloud storage facility and the user device 10 could send the files form the cloud storage facility or allow the server access to the storage facility to retrieve or modify / process the files. Users may be in communication with server 14 over a conventional communication network. The server 14 is a server of a central file security management system, which comprises the server 14 and an associated certificate store 16 and a cryptographic key store 18. The store 16 or 18 may comprise suitable non-volatile data storage devices, e.g. including databases for storage and retrieval of the associated data / files by the server 14. The data stores 16, 18 are securely maintained, e.g. with the central file security management system being behind a firewall. The server 14 and data stores may or may not be provided on a local area network. In some embodiments, the certificate store 16 is a temporary store and is used only when creating the certificate as will be described below. That is to say the certificate store may be short-term memory and the overall system may avoid the need for the user’s sensitive files to be held remotely of their device 10. Instead, the server 14 in some embodiments may maintain a log of the issued certificates, rather than holding the certificates themselves. The sensitive files 12 in this example are files containing the personal information of the user in possession of the device 10. The sensitive files may comprise identification files for the user. The sensitive files may comprise any or any combination of the user’s passport, driving license, proof of address (such as bills or the like), bank account / statement, birth certificate and / or marriage certificate. The files may comprise document and / or image files, e.g. comprising images of any of the relevant documents. The files could comprise other file formats containing data representative of the information contained in any of the aforementioned documents. In other examples, the sensitive files could comprise information other than personal information, e.g. potentially any collection of sensitive files could be considered where the files are to be amassed / collected to provide a file repository that can be accessed by others. The specific number of files collated by the user for the purpose of the present invention can vary, e.g. being potentially between two and, say, one hundred files. The precise number is not of particular consequence for the operation of the invention. However, it is envisaged that the number of files will result in a file size that is suitable for transmission by conventional email or other file communication means. The number may for example be between two and fifty files. In various examples, the number may be less than or equal to forty, thirty, twenty or ten individual files. The system of the invention is primarily intended for collections of files that are collated manually by a user, i.e. rather than larger numbers of files amassed by a computer programme. In the system of Figure 1, there is shown the certificate generation steps for operation of the system. The user sends the files 12 and associated public keys to sever 14. Server 14 generates a certificate and puts it into the certificate store 16. Server 14 also saves the associated public keys with tags for each of the files 12 in the key store 18. The specific steps of this process may comprise: 1. User Side (e.g. using an application running on the user device 10) a. Depending on the number of documents / files 12, multiple public and private key pairs are generated (i.e. with a different key pair for each of the files). These keys are called partial keys and are generated using RSA encryption algorithm in this example. b. User sends the files / documents and public keys to the server 14. c. The public and private key pairs are also saved locally at the user device 10. 2. Server side. a. Upon receipt of the documents / files 12 from the user device 10, server 14 verifies each file is valid then encrypts it using the provided public keys for each received / validated file. Each file is thus encrypted separately. b. Once the files are encrypted, server 14 combines them together in a single file with added separation of each file to represent the end of each file (described in further below). With each combined file there is provided expiry data for the file (e.g. a datetime) and a hash to verify the combined file’s integrity. c. The combined file is encrypted using a symmetric key. d. The symmetric key is sent back to the user device 10 (e.g. for safe keeping) and the encrypted, combined file 12A can remain at the server, e.g. stored at the central file security management system, and / or be sent back to the user. The combined file 12A at this point is referred to as a certificate, i.e. comprising the encrypted individual files 1-n and the associated data comprising the file separation data and expiry data, all of which is encrypted as a single certificate. Turning now to Figure 2, there is shown the use of the system to allow sharing of the combined files, e.g. the certificate, with a recipient so the recipient can access individual files within the certificate according to their needs, e.g. being allowed to access a single file, a subset of the files, or all the files depending on the permissions given by the user. The recipient device 20 may be any of the aforementioned device types in respect of the user. The process of disseminating the files 12 may be initiated by the user device 10 (i.e. in the knowledge that access to certain files will be required by a certain recipient) or else by the recipient device 20. 3. Providing Recipient Access to Files. a. When a recipient requires access to some documents, they send a request to server 14 from the recipient device 20. This may be done using a specific application on the recipient device 20 or else using a general-purpose communication application. The request will identify the user and the relevant documents needed for that user. b. Server 14 verifies that the recipient’s request is legitimate and shares the whole (unlocked) certificate 12Afrom the certificate store 16 and relevant public keys from the key store 18 (i.e. with tags). Additionally or alternatively, the server 14 may notify the user device 10 of the relevant certificate and / or keys to be shared with the recipient, e.g. so the user can validate the request and / or send the keys and / or certificate from the user device 10 to the recipient. c. Upon receipt of the certificate 12A and keys, the recipient device 20 separates relevant documents and their hash using provided end of file (EOF) data with the help of public keys. d. The recipient device 20 then sends only relevant encrypted documents / files from the received certificate and their associated public keys to user. e. The user device 10 matches the public key(s) with using its locally saved key pairs, decrypts the document, and sends it back to the recipient device 20. f. The recipient 20 verifies each decrypted document / file against the provided verification hash locally. Using the above process, a user can send a bundle of documents / files to a central management server, i.e. requiring the user to collate the bundle of documents only once, whilst allowing permission to a variety of recipients to access certain different documents from the collated bundle. This can all be done securely, safe in the knowledge that recipients cannot get access to files other than those for which permission has been given by the end user, even though the entire certificate can be sent to the recipient. Also, the process provides an audit trail of which files / documents were sent to which recipients, which can be logged at the user device 10 and / or server 14. Various recipients can thus be provided with the documents they need for their own different or similar purposes using the system and procedures described herein. Whilst specific steps are described above as part of the overall process for providing recipient access to certain files, it will be appreciated that those steps could be modified as desired when using the certificate described above, i.e. whereby the user or server 14 could perform different steps, depending on the level of security needed between the user device 10, the server 14 and the recipient 20. The systems and procedures are underpinned by the combined file format (i.e. the certificate) as described herein, further details of which are described below. The RSA encryption used herein involves a public key and a private key. The public key can be known by everyone and is used for encrypting messages. The intention is that messages encrypted with the public key can only be decrypted in a reasonable amount of time by using the private key. The public key is represented by the integers n and e, and the private key is separate (although n is also used dunng the decryption process, so it might be considered to be a part of the private key also). However, the private key is kept secret. • The keys for the RSA algorithm are generated in the following way: • Two large prime numbers p and q are chosen at random, be similar in magnitude, but differ in length. • Compute n = pq. n is used as the modulus for both the public and private keys. Its length, usually expressed in bits, is the key length. • n is released as part of the public key. • Compute A(n), where / \ is Carmichael's totient function. Since n = pq, A(n) = lcm(Z(p), / (q)), and since p and q are prime, A(p) = (p(p) = p - 1, and likewise A(q) = q - 1. Hence A(n) = lcm(p - 1, q - 1). The Icm may be calculated through the Euclidean algorithm, since lcm(a, b) = |ab| / |gcd(a7b). A(n) is kept secret. • Choose an integer e such that 1 <e <A(n) and gcd(e, A(n)) = 1; that is, e and A(n) are coprime, e having a short bit-length and small Hamming weight results in more efficient encryption - the most commonly chosen value for e is 216 + 1 = 65537. The smallest (and fastest) possible value for e is 3, but such a small value for e has been shown to be less secure in some settings, e is released as part of the public key. • Determine the private key ‘d’ as an integer, where d = e-1 (mod A(n)); that is, d is the modular multiplicative inverse of e modulo A(n). This means: solve for d the equation de = 1 (mod A(n))\ c / can be computed efficiently by using the extended Euclidean algorithm, since, thanks to e and A(n) being coprime, said equation is a form of Bezout's identity, where d is one of the coefficients. The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the private (or decryption) exponent d, which must be kept secret, p, q, and A(n) must also be kept secret because they can be used to calculate d. In fact, they can all be discarded after d has been computed. The RSA key generation process is described above because it relates to how the end of file (EOF) identifier for each file in the certificate 12A is generated. Whilst the current method uses RSA, it will be appreciated to the skilled reader that similar techniques could be used to generate EOF identifiers for other key generation (and encryption) methods, particularly where a public and private key pair are generated. Adding End of File: To generate the EOF, we first take the n value from each public key (e, n) and assign it to the relevant file like the example below. Passport: 391 Driving license: 899 Then we generate a random prime number, p, and multiply it with the number ‘n’ that was assigned to each file. This calculation, and the resulting end-of-file identifier is shown in Figure 3. Whilst only two files are shown, it will be appreciated that this process is repeated for every file that makes up the certificate. We place the n*p identifier at the end of each encrypted file to keep track of the different files inside the certificate, i.e. identifying them by their EOF. This mechanism also helps prevent files from repeating as system will try to overwrite the file between same place again. To find the EOF we can simply find these numbers and divide them by the public key to identify. In this way, the public key is being reused and there is not extra information required to find and identify any document / file within the string of files that make up the certificate 12A. The EOF is a numerical identifier or marker that can therefore be identified by a computer processing the collection of files 12A to determine which individual file within the string of files precedes the EOF. Other, similar ways of generating an EOF could be envisaged, which could be alphanumerical and can derive from a component used to generate the public key during the encryption process. Once the recipient has the public key, they have the means to identify the individual files they need access to from the collection of encrypted files. This file identification can be verified by the user device 10 and / or server 14 as necessary. However, the contents of the individual file can only be accessed with the private key. Public key can thus be used to encrypt and point out the location of a specific file to a recipient in a way that avoids using the metadata of the file itself. The use of the server 14 as a central file security management system for controlling the process of key management and secure certificate storage on behalf of the end user is beneficial for ensuring the integrity of the whole process. However in other embodiments, e.g. where the end user is an organisation, it is possible that the role of the central fie security management system could be performed by the end user. For example, the users could be employees of the organisation that operates the server 14 and could be located on a common local area network. Using the described approach, there is provided a system where the files mentioned above are kept in one place in the form a certificate. This certificate has an expiry date within it and the whole certificate is signed (e.g. by the central file security management system) to protect the integrity of the data enclosed. After signing the certificate can be given back to the end user so that information (i.e. the files or certificate) need not be saved on any of the server side by the central file security management system. When a potential recipient needs specific documents, they will request the certificate from the user directly and ask for the access key from the central file security management system. The server 14 will provide a partial key to the recipient so that they can only access the information that is specifically required by them. The partial key is therefore just issued in respect of the individual files needed by the recipient, e.g. as one or a subset of the total files contained in the certificate, and the recipient cannot access the contents of those files until only those specific files are decrypted using the relevant private keys. The systems and methods described wherein allow secure dissemination of a 5 collection of files / documents, where various different recipients may require access to different individual documents from said collection. The recipients can only access the specific files for which they are given permission by a user of the system 10

Claims

1. A datafile structure comprising;a plurality of individual files, each of those individual files being encrypted using different encryption keys, the individual encrypted files being arranged in sequence in the datafile structure;an end of file (EOF) identifier at the end of each encrypted file in the sequence, such that an EOF identifier is present between the end of each file in the sequence and the start of the next file; wherein,the EOF identifier for the individual file comprises an element used in the encryption key for said file,said sequence of individual encrypted files and EOF identifiers being provided as a single datafile for transmission over a network.

2. A datafile structure according to claim 1, wherein the plurality of individual files are encrypted using a public and private key pair and the EOF identifier comprises an element of the public key.

3. A datafile structure according to claim 1 or 2, wherein the EOF identifier element comprises an alphanumeric element or string.

4. A datafile structure according to claim 3 wherein the EOF identifier element comprises the modulus n of an RSA key.

5. A datafile structure according to any preceding claim, wherein the element is a first element and the EOF identifier comprises a second element.

6. A datafile structure according to claim 5, wherein the second element comprises a random alphanumeric element.

7. A datafile structure according to claim 5 or 6, wherein the second element comprises a prime number.

8. A datafile structure according to any preceding claim, wherein the single datafile is encrypted.

9. A datafile structure according to any preceding claim, comprising a file expiry indicator.

10. A datafile structure according to claim 9, wherein the file expiry indicator comprises a datetime indicator identifying when the plurality of files or individual files thereof will cease to be accessible.

11. A datafile structure according to claim 9 or 10, wherein the single datafile comprising the EOF indicators and the file expiry indicator are collectively encrypted.

12. A datafile structure according to any preceding claim wherein the single datafile is provided as a certificate.

13. A method of creating a datafile structure for secure dissemination, the method comprising:encrypting a plurality of individual files separately using different encryption keys;arranging the individual encrypted files in sequence;providing an EOF identifier at the end of each encrypted file in the sequence, such that an EOF identifier is present between the end of each file in the sequence and the start of the next file; wherein,the EOF identifier for each respective individual file comprises an element used in the encryption key for said file;providing the sequence of individual encrypted files and EOF identifiers as a single datafile.

14. A method of creating a datafile structure according to claim 13, wherein the EOF identifiers for each encrypted file are different.

15. A method according to claim 13, further comprising accessing individual files within the single datafile using a user device, a file security management server and a recipient device for receiving the single datafile, wherein the recipient device receives the single datafile and the user device receives the public keys for the individual encrypted files from the file security management server, wherein the recipient device receives specific individual decrypted files from the single datafile in dependence upon the public keys received by the user device.

16. A method according to claim 13, further comprising accessing individual files within the single datafile by a recipient, the recipient transmitting a request for one or more individual file and receiving in reply to said request one or more public key associated with the respective one or more individual encrypted file within the single datafile, wherein said public keys are used to indicate the one or more EOF identifier for said one or more individual encrypted file, said one or more individual file being decrypted for access by the recipient.

17. A data carrier comprising machine readable instructions for one or more computer processor to create a datafile structure suitable for secure transmission to recipients by:encrypting a plurality of individual files separately using different encryption keys;arranging the individual encrypted files in sequence;providing an EOF identifier at the end of each encrypted file in the sequence, such that an EOF identifier is present between the end of each file in the sequence and the start of the next encrypted file; wherein,the EOF identifier for each respective individual file comprises an element used in the encryption key for said file;providing the sequence of individual encrypted files and EOF identifiers as a single datafile.

Images