WO2018107248A1

WO2018107248A1 - System of secure client side data storage

Info

Publication number: WO2018107248A1
Application number: PCT/AU2017/051409
Authority: WO
Inventors: Ric B. Richardson
Original assignee: Haventec Pty Ltd
Priority date: 2016-12-16
Filing date: 2017-12-18
Publication date: 2018-06-21

Abstract

A method of long-term securing and reuse of locally accessible data at a second location remote from a first location; said method comprising issuing a request from the second location to the first location to receive a data batch; the data batch encrypted at the second location to form an encrypted data batch; the encrypted data batch having associated therewith a decryption key for recovery of the data batch from the encrypted data batch; calculating an identity characteriser of the data comprising the encrypted data batch; storing the key and the identity characteriser at the first location; transmitting the data batch to the second location for immediate use at the second location; transmitting the encrypted data batch to the second location for storage at the second location for subsequent reuse of the data batch at the second location; deleting the data batch after use at the second location; in the event of need to reuse the data batch at the second location sending a request to the first location for the key for decryption of the encrypted data batch; the key being sent from the first location to the second location for decryption of the encrypted data batch subject to a proving condition.

Description

System of secure client side Data Storage

Invented by Ric Richardson

[0001] The present invention relates to a system of secure data storage and more particularly although not exclusively to a system which permits access and re- access to securely stored data without the need to re^¬ transmit the data in its entirety in the event that the data undergoes a change.

Background

[0002] The use of web browsers and web enabled apps on smart phones for the sharing of information is well known in the art. Typically a user will visit web sites or other information stores and view the data locally as it is cached in the browser' s temporary storage area to enable quick access if the user wishes to view the information in a subsequent session. In time this data is typically dumped from the cache to allow the storage space to be used for other temporarily stored data.

[0003] A more recent technology called Local Storage was introduced in the HTML 5 specification and allow data to be stored on a long-term basis if needed but typically this data is not secured and is not encrypted.

[0004] While suitable for limited applications, the storage of unencrypted data is not suitable for high security applications such as the local storage of financial and transaction information for a users banking activity. [0005] Typically this means that high security information such as transaction and accounting data needs to be downloaded in each session that the user is connected to the banks network and then deleted to ensure that the data is not compromised by others who may have access to the users client device.

[0006] This process means that often secure data such as banking and accounting data is slow to access and is a large consumer of network traffic in that it often needs to be re-downloaded multiple times for viewing by the user even if the data has not changed or has changed little since the last time the user connected.

[0007] A system that allows data to be downloaded and stored locally in a secure way would enable data to be more efficiently managed. It would also allow a much faster user experience and allow more data processing be done at the client rather than being dependant on network services .

[0008] Embodiments of the disclosed invention are designed to address these issues or at least provide a useful alternative.

Brief description of invention

[0009] Accordingly in one broad form there is provided a method of identification and reuse subject to

satisfaction of a condition of locally accessible data at a second location remote from a first location; said method comprising issuing a request from the second location to the first location to receive a data batch; the data batch encrypted at the second location to form an encrypted data batch; the encrypted data batch having associated therewith a decryption key for recovery of the data batch from the encrypted data batch; calculating an identity characteriser of the data comprising the encrypted data batch; storing the key and the identity characteriser at the first location; transmitting the data batch to the second location for immediate use at the second location; transmitting the encrypted data batch to the second location for storage at the second location for subsequent reuse of the data batch at the second location; deleting the data batch after use at the second location; in the event of need to reuse the data batch at the second location sending a request to the first location for the key for decryption of the encrypted data batch; the key being sent from the first location to the second location for decryption of the encrypted data batch subject to a proving condition. 10] Accordingly in a further broad form there is provided a method of long-term securing and reuse of locally accessible data at a second location remote from a first location;

said method comprising issuing a request from the second location to the first location to receive a data batch;

the data batch encrypted at the second location to form an encrypted data batch; the encrypted data batch having associated therewith a decryption key for recovery of the data batch from the encrypted data batch;

calculating an identity characteriser of the data comprising the encrypted data batch;

storing the key and the identity characteriser at the first location;

transmitting the data batch to the second location for immediate use at the second location;

transmitting the encrypted data batch to the second location for storage at the second location for subsequent reuse of the data batch at the second location;

deleting the data batch after use at the second location;

in the event of need to reuse the data batch at the second location sending a request to the first location for the key for decryption of the encrypted data batch;

the key being sent from the first location to the second location for decryption of the encrypted data batch subject to a proving condition. 11] In yet a further broad form of an invention there is provided a method of improving security of data held in storage; said method comprising encrypting data at a first location to form encrypted data which can be decrypted by means of a key;

storing the encrypted data at a second location separate from the first location.

[0012] Preferably the proving condition comprises

comparison of an identity characteriser of the data comprising the data batch stored at the second location with an identity characteriser of the data comprising the data batch calculated for the data batch at the time the data batch was encrypted at the first location to form the encrypted data batch pursuant to the request from the second location to the first location to receive the data batch.

[0013] Preferably the key is associated with a user

account .

[0014] Preferably the identity characteriser is

associated with a user account.

[0015] Preferably the identity characteriser comprises a checksum.

[0016] Preferably the identity characteriser is

generated by action on the unencrypted data.

[0017] Preferably the identity characteriser is

generated by action on the encrypted data. [0018] Preferably the second location receives the data batch from the first location.

[0019] Preferably the second location receives the data batch from the second location.

[0020] Preferably the second location receives the data batch from a third location.

[0021] Preferably the encrypted data held at the second location is decrypted by sending the data to a

decryption location separate from the second location.

[0022] Preferably the decryption location is the first location .

[0023] Preferably the decryption location is a third

location separate from the first location and separate from the second location.

[0024] Preferably the method further includes, on

request, transmitting the key to the decryption location thereby to allow decryption of the encrypted data .

[0025] Preferably the decrypted data is made available for use at the decryption location.

[0026] Preferably the decrypted data is made available for use at the second location separate from the first location . [0027] Preferably the decrypted data is deleted within a predetermined period after use.

[0028] Preferably the predetermined period is less than one minute .

[0029] Preferably the predetermined period is less than one hour .

[0030] Preferably the method further includes

calculating an identity characteriser of the encrypted data .

[0031] Preferably the method further includes

transmitting the identity characteriser to the second location .

[0032] Preferably prior to seeking access to the

encrypted data at the second location the identity characteriser stored at the second location is compared with the identity characteriser calculated when encrypting the data to form the encrypted data and if they match then the key is sent to the second location .

[0033] Preferably the key, once sent to the second

location, is then used to decrypt the encrypted data stored at the second location in order to recover the data for use at the second location.

[0034] In yet a further broad form there is provided a storage medium containing code which, when executed on a platform, effects the method described above. [0035] In yet a further broad form there is provided an apparatus incorporating a processor and memory, the memory loaded with the code of the storage medium described above.

[0036] Accordingly in a further broad form of the invention there is provide a method of long-term securing and reuse of locally accessible data at a second location remote from a first location;

said method comprising issuing a request from the second location to the first location to receive a data batch located at the second location;

the data patch encrypted at the second location to form an encrypted data patch; the encrypted data batch having associated therewith a decryption key for recovery of the data batch from the encrypted data batch;

calculating a checksum of the data comprising the encrypted data batch;

storing the key and the checksum at the second location; transmitting the data batch to the second location for immediate use at the second location;

transmitting the encrypted data batch to the second location for storage at the second location for

subsequent reuse of the data batch at the second

location;

deleting the data batch after use at the second location; in the event of need to reuse the data batch at the second location sending a request to the first location for the key for decryption of the encrypted data batch; the key being sent from the second location to the first location for decryption of the encrypted data batch subject to a proving condition.

[0037] Preferably the proving condition comprises comparison of a checksum of the encrypted data batch stored at the second location with a checksum of the encrypted data batch calculated for the data batch at the time the data batch was encrypted at the first location to form the encrypted data batch pursuant to the request from the second location to the first location to receive the data batch located at the second location.

[0038] Preferably the key is associated with a user

account .

[0039] Preferably the checksum is associated with a user account .

[0040] Accordingly in a further broad form of the invention there is provided a method of improving security of data held in storage;

said method comprising encrypting data at a first location to form encrypted data which can be decrypted by means of a key;

[0041] Preferably the encrypted data held at the second location is decrypted by sending the data to a decryption location separate from the second location. [0042] Preferably in one form the decryption location is the first location.

[0043] In another form the decryption location is a third location separate from the first location and separate from the second location.

[0044] Preferably the method further includes, on request, transmitting the key to the decryption location thereby to allow decryption of the encrypted data.

[0045] In a preferred form the decrypted data is made available for use at the decryption location.

[0046] In an alternative preferred form the decrypted data is made available for use at the second location separate from the first location.

[0047] In a preferred form the decrypted data is deleted within a predetermined period after use.

[0048] Preferably the predetermined period is less than one minute .

[0049] Preferably the predetermined period is less than one hour.

[0050] Preferably the method further includes

calculating a checksum of the encrypted data.

[0051] Preferably the method further includes

transmitting the checksum to the second location. [0052] More preferably, prior to seeking access to the encrypted data at the second location the checksum stored at the second location is compared with the checksum calculated when encrypting the data to form the encrypted data and if they match then the key is sent to the second location .

[0053] Preferably the key, once sent to the second location, is then used to decrypt the encrypted data stored at the second location in order to recover the data for use at the second location.

Drawing

[0054] Figure 1 illustrates main components of an

example embodiment of the system and methodology of a preferred form of the present invention.

[0055] Figure 2 is a logic diagram of an example control process of the example embodiment of figure 1.

[0056] Figure 3A,B,C,D,E comprised block diagrams of a further embodiment of the present invention.

Description and Operation

[0057] Figure 1 disclosed the main components of the example embodiment. The example embodiment discloses the invention in the context of an online banking account where transaction information is accessed by the user for reviewing of transaction activity and other information such as bank balance.

[0058] A users device such as a personal computer 10 typically connects to a bank network 11 by means of a public network such as the Internet 12. The users device 10 may have an application such as a browser 13, which is used to access information on the bank network 11.

[0059] Typically a user would connect to the bank network 11 to access information such as transaction data 20 related to their bank account 19. While some data from the transaction data 20 could be accessed for a single session, any data that could be accessed multiple times on the client application 13 could be transferred for local storage 14 on the client device and made available for ongoing use and access over time. However that data must be encrypted so that it remains secure while in use on the client.

[0060] To ensure the data is secure, each batch of data that is added to the transaction data store 20 could be encrypted as a batch of data 21. Each batch 21 could have a encryption key 23 24 that is used to secure the data. The secure encrypted batch of data can then be downloaded to the client and stored 15 17 in an encrypted form in the applications Local Storage 14.

[0061] Each batch of data 21 could also be given a calculated checksum 22 25 that is stored with the users account 19.

[0062] When a user wants to access account information that is already stored locally on the users device 10, the application 13 can check that the data is available, even though it would be encrypted, by comparing the checksums 16 18 of the batch data that is available locally, and then the key 23 24 that relates to the selected check summed data 15 17 can be supplied to the client so that the data can be decrypted, viewed and used by the user during a secure session on the client without the need to re-download the data 20 from the network 11 an additional time.

[0063] Ideally, the decrypted data would be deleted from memory after use in the secure session to ensure that other users of the client device do not have access to the secure data in it's unencrypted state. In practise the encryption method that could be used would be AES 256 bit which is fast and should deliver considerable user speed and reduced network traffic advantages.

[0064] Figure 2 shows an example control process of the example embodiment. Initially a user 40 may request secure data 42 from a banking networks and server system 41. Before automatically retrieving the data from the server the application on the client side checks to see if the requested data is available locally 43. If no then the data is requested from the server 44 and sent as normal data to allow the user to start using the

information 45. At the end of the session the data is deleted from client device memory 46.

[0065] The reason that a non-batch encrypted copy of data is sent is so that the user can start using the data immediately on the client device.

[0066] The data requested by the user 44 is also

encrypted 47 using an encryption key generated on the server 47. The encrypted data is then communicated to the client and stored for future reference 48. In addition a check sum 48 is done of the encrypted batch of data 47 and is stored on the client device for future reference 49. Both the encryption key 50 and the checksum of the batch of data 51 are stored with the users account information for future compare and decryption of the data on the client side device 40.

[0067] If the application 42 requests data that is already available locally 43 then the checksum of the requested encrypted data 52 is compared with the checksum for the batch as stored on the network system 41. If the checksums match 54 then the key to decrypt the data 55 is given to the client device 56 and the data is decrypted for use in the current session 56. To ensure security the decrypted data is not stored but rather is deleted t the end of the session 57.

[0068] If there is more recent data 53 relevant to the clients request 43 then the new batch of data 58 is encrypted 59 and check summed 61 and the new batch of encrypted data is stored on the client device 60 along with the related checksum 62. Also the checksum 61 and the related encryption key 64 are stored 64 63 with the user account.

Alternative Eitibodiments

[0069] The example embodiment uses a scenario where the secure data relates to bank transactions and data. An alternative embodiment could include any type of secure data where it is advantageous to have a secure local version of the data for local viewing, use and

processing . [0070] The example embodiment teaches that a non batch encrypted version of the requested data is sent before a batch encrypted is sent to the client device. This technique is designed to allow the user to commence using the data immediately without having them wait for the batch data to be encrypted and check summed. An

alternative embodiment may have all data batch encrypted before sending the other client device resulting in the advantage that only one set of data is communicated between client and server.

[0071] The example embodiment uses a technique called check summing to verify that the client side stored data and the data originally encrypted by the server are identical . An alternative embodiment could use any method of verification including but not limited to MD5 checking or similar.

[0072] The example embodiment shows a client device connecting to a server on a secure network. An

alternative embodiment could be used in any device to device, device to server, or server to server

communication .

[0073] The example embodiment shows the client using a web browser application using HTML 5 local storage for the storage of secure data. An alternative embodiment could use any web or network enabled application and any form of local storage available to that application including but not limited to cloud applications or remote access use of the related applications. [0074] The example embodiment shows the server doing the encryption of data and only decryption occurring on the client side device. One of the reasons this is because the generation of encryption keys is typically a

processor intensive process. An alternative embodiment could see the encryption of data for storage and the generation of checksums both completed on the client side by the client device rather than on the server.

[0075] In a particularly preferred form of the invention the encrypted data and the key for the encrypted data may not be in the same place or on the same device.

Further Example Embodiment

[0076] Applicant has described a storage system which relies on maintaining an encrypted version of data at a location separate from the key needed to decrypt the data. The storage system is described in international patent application PCT/AU2017/000002 the description, drawings of which are incorporated herein in their entirety .

[0077] The methodology of the present application can be used with advantage to the storage system of

PCT/AU2017/000002 as will now be described in this further example of embodiment with reference to figs 3A,B,C,D,E.

[0078] Figures 3A, B, C illustrate in diagrammatic form one form of topology and execution of an example embodiment disclosed in PCT/AU2017/000002. [0079] In this instance, with reference to figure 3Ά, a storage system 80 relies on a server 81 in

communication with client device 82 in this instance over network 83. In this particular instance network 83 includes the internet which itself comprises an interconnected network of computers adapted for transmission of packet data 84 to destinations identified in header 85. In many circumstances client device 82 will be in electronic communication with network 83 by way of initial link 86 which may comprise a mobile telephone network or other radio communication network such as wifi or the like.

Unsecured Window Period

[0080] In this instance, client device 82 includes a client device memory 87 and client devicse processor 88 whereby code 89 stored in memory can be executed by processor 88. In this instance the code 89 includes an application adapted to receive commands 90 and data 91 from server 81. In this instance the commands 90 and data 91 permit creation of form fields Fl - F7 in a form structure 92. In preferred forms the form structure 92 is determined on server 81 and forms part of the commands 90 and data 91 transmitted to client device 82 during the unsecured window period. Each form field can receive respective data Dl - D7 which may be received from the server 81 as data 91 or may be inserted by a local user of the client device 82. The form structure 92 and data 91 is presented in unsecured form during an unsecured window period of storage system 80. During this period the data Dl - D7 is transmitted from client device 82 to server 81. Server 81, typically located at a location physically remote from client device 82, received data Dl - D7 over either a secured or unsecured data channel and saves data Dl - D7 in server memory 93 referenced against an entity account 94.

Secure Window Period

[0081] With reference to figure 4B a secured window

period commences when server 81 encrypts data Dl - D7 with reference to at least one key 95 so as to form encrypted data 96 which is then transmitted by server 81 to client device 82 which is to say the client device 82 which formulated data Dl - D7 and from which the data was transmitted to server 81 referenced against entity account 94. In one form an entity account may be owned by the client device 82 itself. In another form the entity account may be owned by a user of the code 89 executed on the client device 82 from which the data Dl - D7 originated.

[0082] In either case the server 81 references the data both before encryption and after encryption against the entity account 94.

[0083] In a preferred form the server 81 is a web

server. In an alternative preferred form the server may serve application functionality in the form of an API or the like for execution as code 89 on client device 82.

[0084] Once the data Dl - D7 has been encrypted and

transmitted to client device 82 the server 81 deletes all instances of data Dl - D7 from its storage - whether in an encrypted or unencrypted form leaving the only key 95 stored against the entity account 94.

[0085] During this secured window period the client

device 82 stores the encrypted data 96 locally in client device memory 87. It is to be noted that the key 95 is not provided to the client device 82.

Subsequent Use of Data Dl - D7

[0086] With reference to figure 4C in sessions

comprising execution of code 89 as subsequent sessions to an initial session on client device 82 an unsecured window session is initiated during a subsequent unsecured window period during which execution of code 89 causes transmission of encrypted data 96 to server 81 where upon, following authentication of entity account 94 corresponding key 95 is utilised to decrypt data Dl - D7 and transmit it over either a secured or unsecured channel from server 81 to client device 82. In a preferred form the data Dl - D7 will repopulate the form structure 92 on the client device 82. This data may then be used for various functionality on the client device 82. The data Dl - D7 may be amended during the subsequent session during the subsequent unsecured window period. When a user of the client device 82 or the client device itself terminates the subsequent unsecured window period the data Dl - D7 is transmitted to server 81 as described with reference to figure 3A and a subsequent secured window period is initiated as described with reference to figure 3B. [0087] In a preferred form a user of client device 82 may be given the option as to whether to invoke the procedure described above.

[0088] With reference to figs 3D,E the methodology of the present invention in a preferred form is applied as follows :

[0089] With reference to fig 3D where like components are numbered as for figs 3A, B, C, checksums CI to Cn are maintained for data associated with respective user accounts Δ1 through to An. In one form the checksums comprise a checksum of the data before encryption. In an alternative form the checksums comprise checksums of the data after encryption.

[0090] As before respective keys Kl through to Kn are also stored for each respective user account.

[0091] With reference to figure 3D the situation

illustrated where checksum CSl has been generated for data Dl, 2, 3, 4, 5, 6, 7 for storage on client device 82. Correspondingly checksum CI has been generated for user account Al in respective of data Dl, 2, 3, 4, 5, 6, 7.

[0092] With reference to figure 3E when the user client requests data and that data is available locally (for example, from previous operations as per fig 3A,B,C) then a comparison operation is performed comparing checksum CSl with checksum CI in respect of account Al . If they match (indicating that the data has not been changed since the last access by the user client) then key Kl is transmitted from server 81 to client device 82 for use to decrypt the encrypted data D1-D7 already stored on the client device 82 thereby to reconstruct the unencrypted data 92 for local use during the unsecured window period.

[0093] A checksum has been used as a mechanism to

indicate whether data has been changed. Other algorisms can be used to create an indicator which is

characteristic of the data content 01,2,3,4,5,6,7 sufficient to be usable to indicate whether data content has changed to a sufficient level of certainty.

[0094] It will be observed that the data for use may arise from server 81. In alternative forms it may arise initial on the client device 82. In yet alternative forms it may arise at a third location separate from either the server 81 or the client device 82. In this instance the data will need to be stored in a server environment rendering it at least accessible to server 81 for the purpose of execution of embodiments of the present invention.

[0095] It will be further observed that with this

arrangement there is no need to send the encrypted data D1-D7 between the server and the client device thereby saving on data transmission costs and time.

Industrial Applicabili y

[0096] Embodiments of the present invention can be

applied in environments where it is desired to keep data secure. Scenarios can include use of credit card information or user name and password data or other sensitive data.

Claims

CLAIMS:

1. A method of long-term securing and reuse of locally accessible data at a second

location remote from a first location;

calculating an identity characteriser of the data comprising the encrypted data batch; storing the key and the identity characteriser at the first location;

deleting the data batch after use at the second location;

the key being sent from the first location to the second location for decryption of the encrypted data batch subject to a proving condition.

2. The method of claim 1 wherein the proving condition comprises comparison of an identity characteriser of the data comprising the data batch stored at the second location with an identity characteriser of the data comprising the data batch calculated for the data batch at the time the data batch was encrypted at the first location to form the encrypted data batch pursuant to the request from the second location to the first location to receive the data batch.

3. The method of claim 1 or 2 wherein the key is associated with a user account.

4. The method of claim 1 or 2 or 3 wherein the identity characteriser is associated with a user account.

5. The method of any previous claim wherein the identity characterise!- comprises a checksum.

6. The method of any previous claim wherein the identity characteriser is generated by action on the unencrypted data.

7. The method of any previous claim wherein the identity characteriser is generated by action on the encrypted data.

8. The method of any previous claim wherein the second location receives the data batch from the first location.

9. The method of any previous claim wherein the second location receives the data batch from the second location.

10. The method of any previous claim wherein the second location receives the data batch from a third location.

11. A method of improving security of data held in storage;

12. The method of claim 11 wherein the encrypted data held at the second location is decrypted by sending the data to a decryption location separate from the second location.

13. The method of claim 12 wherein the decryption location is the first location.

14. The method of claim 12 wherein the decryption location is a third location separate from the first location and separate from the second location.

15. The method of any one of claims 11 to 14 wherein the method further includes, on request, transmitting the key to the decryption location thereby to allow decryption of the encrypted data.

16. The method of any one of claims 11 to 15 wherein the decrypted data is made

available for use at the decryption location.

17. The method of any one of claims 11 to 15 wherein the decrypted data is made

available for use at the second location separate from the first location.

18. The method of any previous claim wherein the decrypted data is deleted within a predetermined period after use.

19. The method of claim 18 wherein the predetermined period is less than one minute.

20. The method of claim 18 wherein the predetermined period is less than one hour.

21. The method of any one of claims 11 to 20 wherein the method further includes

calculating an identity characteriser of the encrypted data.

22. The method of claim 21 wherein the method further includes transmitting the identity characteriser to the second location.

23.. The method of any previous claim wherein prior to seeking access to the encrypted data at the second location the identity characteriser stored at the second location is compared with the identity characteriser calculated when encrypting the data to form the encrypted data and if they match then the key is sent to the second location.

24. The method of claim 23 wherein the key, once sent to the second location, is then used to decrypt the encrypted data stored at the second location in order to recover the data for use at the second location.

25. A storage medium containing code which, when executed on a platform, effects the method of any one of claims 1 to 24.

26. An apparatus incorporating a processor and memory, the memory loaded with the code of the storage medium of claim 25.