U.S. patent application number 14/334193 was filed with the patent office on 2014-11-20 for secure cloud storage and synchronization systems and methods.
The applicant listed for this patent is Sara Mohanty, Subhashis Mohanty, Troy Schilling. Invention is credited to Sara Mohanty, Subhashis Mohanty, Troy Schilling.
Application Number | 20140344572 14/334193 |
Document ID | / |
Family ID | 47912578 |
Filed Date | 2014-11-20 |
United States Patent
Application |
20140344572 |
Kind Code |
A1 |
Mohanty; Subhashis ; et
al. |
November 20, 2014 |
SECURE CLOUD STORAGE AND SYNCHRONIZATION SYSTEMS AND METHODS
Abstract
A secure cloud storage and synchronization system and method is
described that provides, among other things: (1) local password
recovery, including a mechanism by which the user of the system can
recover their password without having stored it on a remote server;
(2) secure, private versioning of files, including a mechanism to
privately store a version history of files on one or more remote
servers in such a way that it is technically infeasible for anyone
other than the legitimate owner to access any component of the file
history; (3) secure, private de-duplication of files stored on one
or more remote servers that reduces storage requirements by
allowing for the storage of a single file when there are
duplicates, even across users; and (4) secure, private sharing of
files between users of the system that allows one user to share a
file on the "cloud" with another user without deciphering or
transporting the file.
Inventors: |
Mohanty; Subhashis; (San
Diego, CA) ; Mohanty; Sara; (San Diego, CA) ;
Schilling; Troy; (Salt Lake City, UT) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Mohanty; Subhashis
Mohanty; Sara
Schilling; Troy |
San Diego
San Diego
Salt Lake City |
CA
CA
UT |
US
US
US |
|
|
Family ID: |
47912578 |
Appl. No.: |
14/334193 |
Filed: |
July 17, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13621752 |
Sep 17, 2012 |
|
|
|
14334193 |
|
|
|
|
61539368 |
Sep 26, 2011 |
|
|
|
61585065 |
Jan 10, 2012 |
|
|
|
Current U.S.
Class: |
713/165 |
Current CPC
Class: |
H04L 63/0428 20130101;
G06F 21/6218 20130101; H04L 2463/062 20130101; G06F 2221/2107
20130101; H04L 67/1095 20130101; H04L 63/126 20130101 |
Class at
Publication: |
713/165 |
International
Class: |
G06F 21/62 20060101
G06F021/62; H04L 29/06 20060101 H04L029/06 |
Claims
1. A de-duplication system comprising: a first computing device and
a second computing device, both devices being adapted and
programmed to communicate data to and from each other over the
Internet, the first computing device being further adapted and
programmed such that, upon a first request: the first computing
device encrypts a first data blob using a first key, thereby
creating a first encrypted data blob; the first computing device
cryptographically hashes the first data blob, thereby creating a
first cryptographic hash of the first data blob; the first
computing device encrypts the first key, using a first root key,
thereby creating a first encrypted key; the first computing device
communicates to the second computing device: the first encrypted
data blob; the first cryptographic hash of the first data blob; and
the first encrypted key; the second computing device being further
adapted and programmed such that, after receipt of the first
encrypted data blob, the first cryptographic hash of the first data
blob, and the first encrypted key from the first device, the second
computing device will: recognize when it receives a second request
to receive a second encrypted data blob that coincides
byte-for-byte with the first encrypted data blob; deny the second
request; and provide to the second requester access to first
encrypted data blob.
2. The de-duplication system of claim 1, wherein the second
computing device is further adapted and programmed such that, when
it receives a second request to receive a second encrypted data
blob that coincides byte-for-byte with the first encrypted data
blob, the second computing device will: recognize when it receives
a second request to receive a second encrypted data blob that
coincides byte-for-byte with the first encrypted data blob by
comparing the first cryptographic hash of the first data blob to a
second cryptographic hash of the second data blob.
3. The de-duplication system of claim 1, wherein the second
computing device is further adapted and programmed such that, when
it receives a second request to receive a second encrypted data
blob that coincides byte-for-byte with the first encrypted data
blob, the second computing device will: deny the second request
when the second computing device determines that the second
requester can compute the first key with which the first encrypted
data blob is encrypted.
4. The de-duplication system of claim 1, wherein the second
computing device is further adapted and programmed such that, when
it receives a second request to receive a second encrypted data
blob that coincides byte-for-byte with the first encrypted data
blob, the second computing device will: provide to the second
requester access to the first encrypted data blob by communicating
to second requester: the first encrypted data blob; and the first
encrypted key from the first device.
5. The de-duplication system of claim 1, wherein the second
computing device cannot compute the first key with which the first
encrypted data blob is encrypted.
6. The de-duplication system of claim 1, wherein the first
computing device and the second computing device are further
adapted and programmed such that the system operates as claimed
when the first request and the second request come from different
computing devices.
7. The de-duplication system of claim 1, wherein the first
computing device and the second computing device are further
adapted and programmed such that the system operates as claimed
when the first request and the second request come from the same
computing device.
8. The de-duplication system of claim 1, wherein the first
computing device and the second computing device are further
adapted and programmed such that the system operates as claimed
when the first request and the second request come from computing
devices that both store the first root key.
9. The de-duplication system of claim 1, wherein the first
computing device and the second computing device are further
adapted and programmed such that the system operates as claimed
when the first request and the second request come from computing
devices that do not both store the first root key.
10. The de-duplication system of claim 1, wherein the second
computing device comprises a plurality of computers in the
Cloud.
11. A method of de-duplication operable on a first computing device
and a second computing device when both devices are adapted and
programmed to communicate data to and from each other over the
Internet and to perform the following respective steps, comprising
the following steps: the first computing device encrypts a first
data blob using a first key, thereby creating a first encrypted
data blob; the first computing device cryptographically hashes the
first data blob, thereby creating a first cryptographic hash of the
first data blob; the first computing device encrypts the first key,
using a first root key, thereby creating a first encrypted key; the
first computing device communicates to the second computing device:
the first encrypted data blob; the first cryptographic hash of the
first data blob; and the first encrypted key; the second computing
device, after receipt of the first encrypted data blob, the first
cryptographic hash of the first data blob, and the first encrypted
key from the first device: recognizing when it receives a second
request to receive a second encrypted data blob that coincides
byte-for-byte with the first encrypted data blob; denying the
second request; and providing to the second requester access to
first encrypted data blob.
12. The de-duplication method of claim 11, wherein the second
computing device, when it receives a second request to receive a
second encrypted data blob that coincides byte-for-byte with the
first encrypted data blob: recognizes when it receives a second
request to receive a second encrypted data blob that coincides
byte-for-byte with the first encrypted data blob by comparing the
first cryptographic hash of the first data blob to a second
cryptographic hash of the second data blob.
13. The de-duplication method of claim 11, wherein the second
computing device, when it receives a second request to receive a
second encrypted data blob that coincides byte-for-byte with the
first encrypted data blob, will: deny the second request when the
second computing device determines that the second requester can
compute the first key with which the first encrypted data blob is
encrypted.
14. The de-duplication method of claim 11, wherein the second
computing device, when it receives a second request to receive a
second encrypted data blob that coincides byte-for-byte with the
first encrypted data blob, will: provide to the second requester
access to the first encrypted data blob by communicating to second
requester: the first encrypted data blob; and the first encrypted
key from the first device.
15. The de-duplication method of claim 11, wherein the second
computing device does not compute the first key with which the
first encrypted data blob is encrypted.
16. The de-duplication method of claim 11, wherein the first
computing device and the second computing device are further
adapted and programmed such that the method operates as claimed
when the first request and the second request come from different
computing devices.
17. The de-duplication method of claim 11, wherein the first
computing device and the second computing device are further
adapted and programmed such that the method operates as claimed
when the first request and the second request come from the same
computing device.
18. The de-duplication method of claim 11, wherein the first
computing device and the second computing device are further
adapted and programmed such that the method operates as claimed
when the first request and the second request come from computing
devices that both store the first root key.
19. The de-duplication method of claim 11, wherein the first
computing device and the second computing device are further
adapted and programmed such that the method operates as claimed
when the first request and the second request come from computing
devices that do not both store the first root key.
20. A de-duplication system comprising: first computing means and
second computing means, both computing means being adapted and
programmed to communicate data to and from each other over the
Internet, the first computing device being further adapted and
programmed such that, upon a first request: the first computing
means encrypts a first data blob using a first key, thereby
creating a first encrypted data blob; the first computing means
cryptographically hashes the first data blob, thereby creating a
first cryptographic hash of the first data blob; the first
computing means encrypts the first key, using a first root key,
thereby creating a first encrypted key; the first computing means
communicates to the second computing means: the first encrypted
data blob; the first cryptographic hash of the first data blob; and
the first encrypted key; the second computing means being further
adapted and programmed such that, after receipt of the first
encrypted data blob, the first cryptographic hash of the first data
blob, and the first encrypted key from the first device, the second
computing means will: recognize when it receives a second request
to receive a second encrypted data blob that coincides
byte-for-byte with the first encrypted data blob; deny the second
request; and provide to the second requester access to first
encrypted data blob.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 13/621752 filed on Sep. 17, 2012, which is a
non-provisional of U.S. Patent Application Ser. No. 61/539368 filed
on Nov. 26, 2011, and which is a non-provisional of U.S. Patent
Application Ser. No. 61/585065 filed on Jan. 10, 2012. Each of
these applications is incorporated herein by reference.
TECHNICAL FIELD
[0002] The present invention relates to systems and methods for
secure and private cloud data storage, transfer, sharing, updating,
versioning, and synchronization among multiple devices.
BACKGROUND
[0003] Individuals now often use an ever-increasing number of
computing devices, including desktop computers at multiple
locations such as home and work, laptop computers, tablet
computers, handheld computers such as smartphones, and other
computing devices. Many of these devices are connectable with
communication networks such as the Internet. The increasing use of
different devices at different times and places has led to an
increasing need for users to access their data and digital services
from various remote computing devices. At the same time, the advent
of "cloud" computing has led users to cause their computing devices
to access data and digital services from various remote sources.
Cloud computing refers generally to applications and services
offered over the Internet. Since these services are often
connected, users can share information between multiple systems and
with other users. Non-limiting examples of cloud computing include
online backup services, social networking services, personal data
services, online applications, and hardware services, such as
redundant servers, mirrored websites, and Internet-based computer
clusters.
[0004] Accessing cloud computing from multiple computing devices
presents numerous technical issues, including providing automated
backup of a user's data from different computing devices,
synchronization of data across devices, selective sharing of data
with only certain friends and colleagues, and "versioning" of data
(i.e., the ability to undelete or roll-back to a previous version
of a document or other file no longer on one or more of the user's
devices). Moreover, there is an increasing need for any solutions
to these issues to be secure and private, so that only the user and
the user's specific designees, if any, can access the user's data.
Accordingly, it would be preferable that it be technically
infeasible for even the solution provider to access the user's
information.
SUMMARY
[0005] The present inventors have developed an integrated solution
that addresses all of these issues and more, all while strictly
maintaining the privacy of the user's data. These solutions are
alternatively referred to herein individually and collectively as
the system, method, or application. In various example embodiments
the system may allow a user to mark any file on any of his/her
devices for backup and synchronization, and mark any directory on
any of his/her devices for backup and synchronization. This may
provide backup/synchronization of all files in the marked
directory, and recursive marking of all subdirectories (and the
files contained therein) of the marked directory. Files
subsequently added to the marked directory may likewise be backed
up and synchronized in these embodiments.
[0006] Example embodiments of the system may also allow a user to
revert to a previous version of any of their synchronized files,
and/or share files with other users. Synchronized files may be
synchronized both with the files on the "cloud" and those on the
user's registered devices (storage and bandwidth resources on those
devices permitting).
[0007] Various embodiments of the system may include any or all of
the following aspects: mechanisms that encrypt user data on remote
servers; mechanisms that protect user data on user devices;
mechanisms that allow users to securely and privately share data
with other users; mechanisms that enable a user to recover his/her
password without participation from the remote servers; mechanisms
that compute, transfer and store a diff/patch specification on the
remote servers; and mechanisms that enable file de-duplication,
this is, mechanisms that enable the solution provider to store a
single version of a file common to two or more unrelated users.
[0008] Accordingly, provided herein are various systems and
methods, including but not limited to systems and methods that
provide: (1) local password recovery that provides a mechanism by
which the user of the system can recover their password without
having stored it on a remote server; (2) secure, private versioning
that provides a mechanism to privately store a version history of
files on one or more remote servers in such a way that it is
technically infeasible for anyone other than the legitimate owner
to access any component of the file history; (3) secure, private
de-duplication of files stored on one or more remote servers that
reduces storage requirements by allowing for the storage of a
single file when there are duplicates, even across users; (4)
secure, private sharing of files between users of the system that
allows one user to share a file on the "cloud" with another user
without deciphering or transporting the file.
[0009] Other aspects of the invention are disclosed herein as
discussed in the following Drawings and Detailed Description.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The invention can be better understood with reference to the
following figures. The components within the figures are not
necessarily to scale, emphasis instead being placed on clearly
illustrating example aspects of the invention. In the figures, like
reference numerals designate corresponding parts throughout the
different views. It will be understood that certain components and
details may not appear in the figures to assist in more clearly
describing the invention.
[0011] FIG. 1 is a block diagram of a system in accordance with
various example embodiments of the invention, showing example
hardware.
[0012] FIG. 2 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0013] FIG. 3 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0014] FIG. 4 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0015] FIG. 5 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0016] FIG. 6 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0017] FIG. 7A is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0018] FIG. 7B is a table and corresponding chart showing the
location of data in accordance with various example embodiments of
the invention.
[0019] FIG. 8 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0020] FIG. 9 is a flow diagram of a system in accordance with
various example embodiments of the invention.
[0021] FIG. 10 is a comparison of the flow diagrams of FIGS. 8 and
9 in accordance with various example embodiments of the
invention.
DETAILED DESCRIPTION
[0022] Following is a non-limiting written description of example
embodiments illustrating various aspects of the invention. These
examples are provided to enable a person of ordinary skill in the
art to practice the full scope of the invention without having to
engage in an undue amount of experimentation. As will be apparent
to persons skilled in the art, further modifications and
adaptations can be made without departing from the spirit and scope
of the invention, which is limited only by the claims.
[0023] Definitions
[0024] The following definitions will be used throughout this
description except where otherwise noted:
[0025] Entity Management System (EMS): The "cloud" server--or set
of servers--owned and/or operated and/or used in certain
embodiments by a service provider to store user data, provide
connectivity between user devices, and provide other data
services.
[0026] Key Derivation Function (KDF): A function that takes a
"passphrase" (an arbitrary-length byte arrays) as input, and
generates a symmetric encryption key as output. The KDF may take
other input parameters such as, for example, salt and/or an
iteration count, or any other suitable parameters.
[0027] diff: A computational algorithm that computes the difference
between two or more files. The diff of two files depends on the
order of those files. For example, diff(F.sub.1, F.sub.2) is, in a
sense, the inverse of diff(F.sub.2, F.sub.1). The output of
diff(F.sub.1, F.sub.2) is a set of instructions required to obtain
file F.sub.2 from file F.sub.1 ("file" here simply mean an array of
bytes). A diff may provide multiple types of outputs, such as patch
instructions, described below. For reasons of efficiency, the diff
of two files may depend on the type of those files.
[0028] patch: A computational algorithm for transforming one file
into another, given a set of patch instructions. Notationally,
patch(F.sub.1, P.sub.12)=F.sub.2, where P.sub.12=diff(F.sub.1,
F.sub.2). The following notation will also be used herein:
P.sub.12(F.sub.1)=patch(F.sub.1, P.sub.12).
[0029] device RSA key pair: In cryptography, RSA (which stands for
Rivest, Shamir and Adleman who first publicly described it) is a
well-known algorithm for public-key cryptography. In various
embodiments, an RSA key pair is associated to each of the user's
devices. In such embodiments, the user's devices generate their own
RSA key pairs, and the user's device transfers the public key to
EMS and securely stores the private key locally.
[0030] user RSA key pair: A single RSA key pair is associated with
each user (in addition to the RSA key pair associated with each of
the user's devices). In various embodiments, the first of the
user's devices to register itself with EMS generates the user RSA
keys.
[0031] root key: The user's "root key" is a single symmetric key
associated with a single user. It is generated by the first device
registered with the system. In various embodiments, EMS will not be
capable of computing a user's root key.
[0032] root protection key: The root protection key (different than
the "root key") is obtained from the user's password by use of a
KDF. In various embodiments, the root protection key is used to
encrypt the root key before it is stored on EMS. The root
protection key may also be used to protect sensitive user data on
the user's devices.
[0033] de-duplication (de-dup): A single user may possess two files
that are bit-for-bit identical (not including inode information).
Similarly, two users may possess files that are bit-for-bit
identical. De-dup refers to a mechanism by which such duplicate
files can be stored as a single copy of a single file to decrease
storage requirements. The present system and method implements
de-dup while stringently maintaining each user's security and
privacy.
[0034] logical file: An array of bytes representing the contents of
an actual file (not including inode information). By definition,
there is a single logical file associated with the current version
of a synchronized file, despite that there may be multiple actual
files on EMS and on one or more user devices.
[0035] Notation
[0036] If K denotes an encryption key and D denotes a blob of data,
K#D denotes encipherment of D using the encryption key K. The type
of encryption algorithm is implied by the nature of the key. If K
is a public RSA key, asymmetric RSA encryption is understood. If K
is intended as a symmetric key, the specific encryption algorithm
is not specified herein, but the Advanced Encryption Standard (AES)
with cipher block chaining is typically preferred.
[0037] Example Architecture
[0038] With reference to FIG. 1, example architecture 1000 is
shown. One or more users (not shown) may use a plurality of
computing devices 10, including by way of example and not
limitation, personal data assistants or PDA's 10-1, smart phones
10-2, desktop computers, for instance at work and home 10-3, 10-5,
tablet computers 10-4, and laptop computers 10-6. It is understood
that these are just examples of computing devices 10 and that other
types of computer devices 10 are available and will be forthcoming
in the future. Computing devices 10 are typically connectable by
wire and/or wirelessly with communication networks such as the
Internet, as represented by cloud 20. The Internet or cloud 20
comprises a vast infrastructure facilitating digital communication,
processing, storage, and other data services and features as is
known in the art. Use of computing devices 10 may cause a user's
data to be stored in the cloud 20, for instance in one or many
servers 22 or other computer systems 24. In the present system, the
EMS exists in the cloud 20 and is referred to synonymously with the
cloud 20, and comprises one or more servers 22 and/or other
computer systems 24 adapted and programmed to run the system and
Method as described herein.
[0039] Example of Key Creation
[0040] With reference to FIG. 2, an example embodiment of Key
Creation 2000 will be described. Initially at step 2200, a user
(not shown) enters a new Password P into a first device 10. At
steps 2300 and 2400, the system operating on device 10
cryptographically transforms Password P into a First Hash,
SHA-1(P), and separately into a Second Hash, SHA-2(P). First Hash
SHA-1(P) is then transferred from device 10 to EMS 20 where it is
stored for future authentication of the user. At step 2500, the
system operating on device 10 transforms Second Hash, SHA-2(P) into
Root Protection Key, Kp, using a Key Derivation Function (KDF). At
step 2600 the system operating on device 10 generates the Root Key,
K--generally a symmetric key; this is done only once per user (on
the user's first device). At step 2525, the system operating on
device 10 enciphers the Root Key (K) with the Root Protection Key,
Kp, creating the Secured Root Key, Kp#K, which is then (optionally)
transferred to and stored on EMS 20 at step 2550.
[0041] At step 2700, the system operating on device 10 uses an RSA
algorithm to generate a User RSA Key Pair; with private key denoted
V, and public key denoted L. The User Private Key, V, is enciphered
with Root Key, K, by the system operating on device 10 into a
Secured Private Key, K#V, at step 2800. The Secured Private Key,
K#V, is (optionally) transferred to and stored on EMS 20 at step
2850. The Public User Key, L, is then transferred to and stored on
EMS 20 at step 2720.
[0042] In addition to generating User Keys, V, L, the system
operating on device 10 also uses an RSA algorithm to generate
public and private device keys. At step 2730, the system operating
on device 10 uses an RSA algorithm to generate a Private Device Key
Pair; with private key denoted Vd, and public key denoted Ld. Ld is
transferred to and stored on EMS 20 at step 2750.
[0043] It is understood that additional or different steps may be
taken in other example embodiments of key creation 2000, including
use of different or additional algorithms for data transformation.
Further details regarding these steps are provided below.
[0044] User Password Storage
[0045] In various embodiments including the one shown in FIG. 2,
EMS 20 shall store (only) a cryptographic transform, i.e., "hash,"
of the user's password. In the examples herein, it will be assumed
that the SHA-1 hash of the user's password is stored on EMS 20,
though another cryptographic hash function could be used. SHA
stands for "secure hash algorithm", and SHA-1 and SHA-2 are
cryptographic hash functions published by the NIST as a U.S.
Federal Information Processing Standard. In these example
embodiments, the SHA-1 hash (and quantities derived from it) of the
user's password is the only quantity derived directly from the
user's password that EMS 20 may use for any purpose.
[0046] If it is necessary for the client application to store, or
otherwise use the user's password for privacy purposes, the use of
that password by the client applications (both the "client" and
"server" executing on the user's devices 10) is preferably only in
terms of a second cryptographic hash of the password. The hash
function used for this purpose may be independent of the first
SHA-1 hash function described above. For this purpose, the
SHA-2/256 hash (referenced below as SHA-2) of the user's password
may be used as shown in example step 2400, though another hash
function (independent from that used by EMS) could be used. With
the exception of the password recovery data discussed herein, in
these example embodiments the SHA-2 hash (and quantities derived
from it) of the user's password is the only quantity derived from
the user's password that the client applications may use for any
purpose.
[0047] Key Derivation Function
[0048] A key derivation function (KDF) may be used in various
places for generation of a symmetric key from a password or
passphrase. For example, a KDF may be used that is consistent with
PKCS 5, V2 KDF, as documented in PKCS #5 v2.0: Password-Based
Cryptography Standard, RSA Laboratories, Mar. 25, 1999. When a key
is derived using a KDF, random salt is generated. It is preferable
that the salt consists of at least 16 bytes. The KDF may also take
an iteration count as input. The purpose of this iteration count is
to increase the complexity of computing the key, which complicates
dictionary attacks. It is preferable that the iteration count be at
least 1,000.
[0049] If a blob of data should be encrypted with a key obtained
from a KDF, and if the system must store this blob for future
recovery, and if recovery should be facilitated using only the
associated password, the salt and iteration count may both be
stored in plaintext (though perhaps obfuscated) along with the
encrypted blob.
[0050] Root Key and Root Protection Key
[0051] In various example embodiments, the user's root key (an
example of which is described above with respect to step 2600) may
be: (1) randomly generated by the first user device registered by
the user; (2) of cryptographic quality; and (3) preferably at least
32 bytes long.
[0052] The user's root key is important for protecting the user's
data (along with the user's password, device private RSA key, and
user private RSA key). The root key is preferably not stored in
plaintext on EMS 20, so that it shall not be feasible for anyone
(or anything) other than the user (or the user's devices) to derive
the user's root key.
[0053] The root key may be securely stored on EMS 20 for retrieval
by only the user. This can be accomplished by using any suitable
system, including one using the following steps. An encryption key
(preferably at least 32 bytes long) is obtained using a KDF as
previously described, with the hash (for instance SHA-2) of the
user's password as input (this is the password associated with the
user's account, which is used for authentication with EMS 20). This
is the root protection key, as illustrated in step 2500.
[0054] The root key is encrypted using the above root protection
key, as shown in step 2600. AES encryption, which is well known in
the art, may be used, for example. The secured root key is
transmitted to EMS 20 for storage, as shown in steps 2525,
2550.
[0055] The root protection key (generated in step 2500) shall
typically not be used for any purpose other than that described
here, except possibly for securing sensitive data on the user's
device 10. The root protection key should not be stored in
plaintext. The root protection key should not be transferred from
the user's device 10, and should be securely deleted or zeroized
from the RAM or other memory of the device 10 as soon as possible
after it is computed. Otherwise, the various hashes and keys
generated on device 10 may be stored on device 10, unless otherwise
noted.
[0056] The only dependencies that the EMS 20 database should have
on the user's password are: (1) the encrypted root key; and (2) the
hash (SHA-1 preferred) used for the purpose of user
authentication.
[0057] After the first device 10 is registered as shown for
instance in example 2000, it shall store the root key in
application storage space, protected for access by the user. When
subsequent devices are registered, they shall obtain the user's
secured root key from EMS 20 (such as Kp#K shown in step 2550),
decipher it, and store it in application storage space, protected
for access by the user.
[0058] If and when the user changes his/her EMS password, the root
key may be encrypted with the new password, and uploaded to EMS 20
for storage, for instance as described above with respect to Key
Creation 2000.
[0059] A device 10 should usually have a local copy of the user's
root key, K. However, if a device 10 (for example, a web client or
a new device) requires the user's root key, K, the device 10 may
reverse the above process, for instance as shown in process 3000 in
FIG. 3, where: (1) the system operating on device 10 sends a
request to EMS 20 for the secured root key, Kp#K, as shown in steps
3100, 3200; (2) EMS 20 transfers the secured root key, Kp#K, from
EMS 20 to device 10, as shown in step 3300; (3) the system
operating on device 10 computes the root protection key, Kp, from
the password, as shown in step 2500; (4) the system operating on
device 10 deciphers the root key, K, using the root protection key
Kp, as shown in step 3400.
[0060] Note that a change in the user's password does not require
that any of the user's data be re-encrypted; only the user's root
key is re-encrypted upon password change as shown in method 2000.
Thus, a user password change is a simple and quick operation.
[0061] User RSA Keys
[0062] A single RSA key pair is associated with each user (in
addition to the RSA key pair associated with each of the user's
devices). The first of the user's devices 10 to register itself
with EMS 20 generates and stores the user RSA keys, as shown in
step 2700 in FIG. 2. The user public RSA key is typically stored on
the associated device 10. Likewise, the user private RSA key is
typically securely stored on the associated device 10 for future
access.
[0063] The primary purpose of the user RSA key pair is to provide a
mechanism for users to securely/privately exchange information with
one another in a manner that is device-independent. Data sharing is
discussed further later in this description.
[0064] Device RSA Keys
[0065] The device RSA keys are used for device authentication, and
to facilitate symmetric key transport between user devices 10.
Their generation and storage are illustrated in step 2730,in FIG.
2. The device public RSA key is typically stored on the associated
device 10. The device private RSA key is typically securely stored
on the associated device 10 for future access.
[0066] Password Creation and Recovery
[0067] In the examples shown herein the user must separately store
or otherwise remember her or his password, because it is not stored
on EMS 20. To avoid inoperability of the system due to lost
passwords, each of the user's devices 10 may provide a password
recovery feature. In various embodiments this is an option that may
be enabled or disabled by the user. Password recovery will
typically operate locally, because EMS 20 does not participate in
this function.
[0068] One example embodiment of a password creation and recovery
feature 4000 running on an application on device 10 is illustrated
in FIG. 4, where the client requests to create a password P at step
4200, and is then asked a number of recovery questions at step
4300, such as: "What was the name of your first pet?"; "In what
city were you born?"; "What is your mother's maiden name"; and the
like. In step 4400, the user selects, and provides answers to, at
least N.sub.MIN questions, where N.sub.MIN.apprxeq.4. In addition
to the pre-loaded questions, the application may provide an option
for the user to add an arbitrary text question (arbitrary other
than constraints such as maximum length), and the corresponding
answer. This defines N.sub.R>N.sub.MIN pair of strings: {Qi,
Ai|0<i<N.sub.R}, where the Qi are the questions and Ai are
the secret answers. If the user adds custom questions, those
questions may be stored, for instance on a fixed drive/sdcard, and
protected for secure access by the application only.
[0069] At step 4500, the application running on device 10 may then
generate the following composite string:
P.sub.R=Q.sub.1|A.sub.r|Q.sub.2|A.sub.2| . . . Q.sub.NR|A.sub.NR,
where the symbol "|" denotes concatenation. At step 4600, P.sub.R
is used as the "passphrase" input to a Key Derivation Function
(KDF), the output of which is an encryption key (the recovery key)
K.sub.R. The application then prompts the user to enter his/her
desired password, P, at step 4700. The application may require that
the user enter P twice, and verify that the two entries are
identical. The user's plaintext password, P, is then encrypted with
K.sub.R at step 4800, and the result, K.sub.R#P, is stored, for
instance on a fixed drive/sdcard at step 4900, and is protected for
secure access by the application only.
[0070] Password recovery will now be discussed. In various example
embodiments the password is recovered by reversing the process
4000. For example, on request the user may be prompted for their
secret answers provided in step 4400, then steps 4500 and 4600 may
be repeated to generate the recovery key, K.sub.R, after which step
4800 can be run in reverse to decipher the encrypted password
K.sub.R#P, yielding the plain text password, P, which is then
displayed to the user on device 10. After having recovered the
user's password, the memory in which the secret answers, recovery
passphrase, recovery key and password are stored are typically
deleted and zeroized.
[0071] Recovery of the user's password may be associated with a
verification method by which the algorithm may determine that the
recovered password is correct (or is likely correct). This may be
as simple as a check that the deciphered password consists of only
ASCII characters, though any other suitable method may be used. The
above password creation and recovery system is one example
embodiment. Other embodiments may include fewer or additional or
different steps, as appropriate.
[0072] Application Data Protection Model (Local Storage)
[0073] Proprietary data relating to the application that must be
stored on the user's device 10 (e.g., data that reveals the nature
of the applications protocols, licensing mechanisms, etc.) may be
protected using any suitable method, including but not limited to
the following steps. When relevant and possible, any file
containing such data may be owned (in the UNIX sense) by the
application. A user might in certain embodiments be able to access
application files by rooting or jailbreaking their device. In
addition to storage of proprietary application data in
application-specific storage, all such files may be encrypted using
any suitable mechanism.
[0074] User Data Protection Model (Local Storage)
[0075] Data that is owned by the user, that must be stored on the
user's device 10, and that need not be accessed outside the
application, but that is of sufficient sensitivity to be afforded
special protection, may be encrypted using the user's root key, K.
The root key, K, should be stored securely (or obfuscated) on the
device.
[0076] User Data Protection Model (Cloud Storage)
[0077] The basic model for protection of user data stored on EMS 20
is shown as process 5000 in FIG. 5, and is described below. A data
blob D may be securely stored on EMS 20 as follows. At step 5100 a
symmetric key .alpha. is generated on the user's device to encrypt
the blob D, for instance as follows: A digest h.sub.K(D) of the
blob D may be computed, where h.sub.K denotes an independent
cryptographic hash function (independent of h.sub.FP., discussed
herein). The hash (SHA-1 preferred) of the blob D is typically
computed on the user's device 10. Any other suitable cryptographic
hash function could be used. The result is a "pre-key"
.eta.=h.sub.K(D). The key .alpha. is obtained by use of a KDF
acting on the pre-key .eta.. That is, .alpha.=.alpha.
(D)=KDF(h.sub.K(D)).
[0078] At step 5200, the blob D is encrypted with the key .alpha.
(preferably using AES in CBC mode with PKCS-5 padding), and the
result is denoted .alpha.#D. Then at step 5300, the key .alpha. is
encrypted with the user's root key K (preferably using AES in CBC
mode with PKCS-5 padding), and that result is denoted
K#.alpha..
[0079] As shown in steps 5250, and 5350, .alpha.#D and (optionally)
K#.alpha. are transferred to, and stored on, EMS 20. A blob
identifier (e.g. obtained from a hash function independent of
h.sub.K) may also be transmitted to, and stored on, EMS.
[0080] Extraction of data D by the user requires knowledge of the
encryption key .alpha.. This can be obtained by downloading the
secured key K#.alpha. to the user's device 10, and then deciphering
it locally using the user's root key K. If the user's root key K is
not available on the local device 10, it can be obtained as
described previously with respect to process 3000 shown in FIG.
3.
[0081] Data Sharing
[0082] The above model accommodates data sharing as shown in
example 6000 in FIG. 6 and described below. In this non-limiting
example, Alice, using a first device 10-1, has a data blob D that
she wants to share with Bob, who is using a second device 10-2. The
data blob D is secured on EMS 20 with Alice's AES key .alpha., as
shown at 6200. As shown in step 6100, Alice's Root Key, K.sub.A, is
securely stored on Alice's device 10-1. And as shown in step 6300,
Alice's key .alpha. is securely stored on EMS 20, encrypted with
Alice's root key K.sub.A. In order for Alice to share D with Bob,
her key .alpha. must be transported to Bob on second device 10-2.
This may be done as follows:
[0083] Step 6400, Alice's device 10-1 obtains the encrypted key
K.sub.A#.alpha. from EMS 20.
[0084] Step 6500, Alice's device 10-1 deciphers .alpha. using
Alice's root key K.sub.A.
[0085] Step 6600, Bob's public user key, L.sub.B, publicly stored
on EMS 20, is communicated to Alice's device 10-1 upon request
therefrom.
[0086] Step 6700, Alice's device 10-1 RSA-encrypts .alpha. using
Bob's public user key, L.sub.B, resulting in L.sub.B#.alpha..
[0087] Step 6800, the above result, L.sub.B#.alpha., is uploaded to
EMS 20.
[0088] Step 6940, EMS documents permission for Bob to access
encrypted blob, .alpha.#D, which will be transmitted to Bob's
device upon request.
[0089] Step 6900, if Bob's device 10-2 (or any other of Bob's
devices 10) is online, L.sub.B#.alpha. may be automatically pushed
from EMS 20 to the online device 10-2.
[0090] Step 6910, L.sub.B#.alpha. is deciphered with Bob's private
user key 6905, resulting in .alpha..
[0091] Step 6920, .alpha. is encrypted with Bob's root key, K.sub.B
6907, resulting in K.sub.B#.alpha..
[0092] Step 6930, the above result, K.sub.B#.alpha., is then
(optionally) uploaded to EMS 20.
[0093] Step 6950, Bob's device, 10-2 may then compute the shared
data blob D by deciphering .alpha.#D with the encryption key
.alpha. obtained in step 6910.
[0094] If none of Bob's devices 10 is online, steps 6900-6950 would
be performed when the next of Bob's devices 10 comes online or
otherwise in digital communication with EMS 20.
[0095] De-Duplication
[0096] De-duplication refers to securely and privately storing
files (such as simply byte arrays) for several users while
minimizing duplication of files and/or byte arrays. Secure and/or
private storage means in various embodiments that the user's files
are encrypted before storage on the system, and the encryption key
is unknown to the system provider.
[0097] In various embodiments, storing files without duplication
means that when a user requests that a file be stored on the system
(such as EMS 20), if the contents of that (plaintext) file already
reside on the system (encrypted with a key unknown to the system
provider), the system does not store a duplicate.
[0098] In various embodiments, the system solves the problem as
follows. Suppose the user wishes to securely store a data blob D on
EMS 20, such as shown in FIG. 7A at step 7320. As described
previously and shown at steps 7330-7355, this data D is encrypted
with an encryption key .alpha., and the result, .alpha.#D, is
transferred to EMS 20 for storage (see also, step 5250 in FIG. 5
and step 6200 in FIG. 6, and corresponding descriptions). As
further illustrated in FIG. 7A, in order to facilitate
de-duplication or "de-dup," a second quantity is also transferred
to EMS 20, in association with the encrypted blob. This quantity is
the message digest (or "fingerprint") of D, computed using a
cryptographic hash function denoted herein as h.sub.FP. That is,
the "fingerprint" of D is h.sub.FP(D), as shown in step 7370. A
third quantity is computed and transmitted to EMS for storage in
association with .alpha.#D, as indicated in step 7350. This third
quantity is the key .alpha., noted in step 7340, itself encrypted
as shown in step 7360 with the user's root key k, identified at
step 7310.
[0099] The final element of solutions used in various embodiments
is the mechanism by which the key is determined. The key .alpha.
used to encrypt the blob may be computed as described previously,
which for convenience is restated again here with respect to data
blob D in example de-duplication system and method 7300: As shown
in step 7330, a digest h.sub.K(D) of the blob D may be computed,
where h.sub.K denotes an independent cryptographic hash function
(independent of h.sub.FP., discussed herein). The hash (SHA-1
preferred) of the blob D is typically computed on the user's device
10. Any other suitable cryptographic hash function could be used.
As noted in step 7330, the result is a "pre-key" .eta.=h.sub.K(D).
Then as shown in step 7340, the key .alpha. is obtained by use of a
KDF acting on the pre-key .eta.. That is,
.alpha.=.alpha.(D)=KDF(h.sub.K(D)).
[0100] The reasons this method enables private de-duplication is
that if a subsequent user intends to securely store a data blob on
EMS 20 that coincides, byte-for-byte, with D, then: (1) the system
can determine that the new blob is a duplicate of D, by the fact
that the fingerprint of the new blob coincides with the fingerprint
of D; (2) the user wishing to store the new blob (which coincides
with D), has the ability to compute the key with which D is
encrypted; and (3) it is not possible for EMS to compute the
encryption key .alpha.(D).
[0101] For security reasons, it is preferable in certain
embodiments that for data blobs of a size below some given
threshold, a random encryption key be generated, rather than using
the deterministic method above. In such embodiments, data blob D is
checked 7325 to see if it is sufficiently large to use
de-duplication process 7300, because short files are not eligible
for de-duplication. If step 7325 reveals that data blob D is too
short, then a random encryption key may be generated for D, rather
than applying de-duplication process 7300. Also h.sub.FP and
h.sub.K may be independent cryptographic hash functions. In certain
embodiments the has functions h.sub.FP=SHA-1 and h.sub.K=SHA-2/256
are used.
[0102] Example De-Duplication
[0103] In one example embodiment 7000 the system supports three
users, Alice, Bob and Charlie. At a certain point in time, two data
blobs D.sub.1 and D.sub.2 (e.g., files) stored on EMS 20. In this
example, access to these two blobs D.sub.1 and D.sub.2 has been
allowed and disallowed to the three users as indicated in Table 1,
shown in FIG. 7B. If the users' root keys in this example are
denoted by K.sub.A, K.sub.B and K.sub.C, respectively, chart 7200
illustrates the data that would be stored in the database of the
EMS 20.
[0104] As previously indicated, it is usually preferred in typical
embodiments that small files be ineligible for de-duplication.
Databases in the EMS 20 should include means to indicate whether
each data blob D is eligible for de-duplication. This can be
accomplished with, for example, a separate field provided in the
"blob table" (assuming a relational database). Alternatively,
ineligibility for de-duplication could be indicated with a null
fingerprint, or any other suitable means. Likewise, any suitable
database design may be used. Specific designs for databases in EMS
20 will be apparent to persons of skill in the art and are not
further described here.
[0105] Private File Versioning
[0106] In the following description the term "logical file" will be
used to denote a logical byte array. From any given file on any
user device 10, the associated logical file is simply the byte
array represented on a disk or other data storage medium. The
logical file does not contain inode information. Similarly, a
"logical file history" is conceptually a finite, ordered set of
logical files, each one (except the zeroth or first) representing
one version beyond the previous version. For purposes of
illustrating the concept, disclosed herein are two example options
for file versioning that may be used with the present system.
[0107] For clarity in the following description, encryption of data
blobs (both files and patches) sent to and from, and maintained on,
the EMS 20 is not explicitly indicated, as those steps have been
described previously. It is understood that all user files (and all
file diff/patch blobs) are typically encrypted. Note that in
principle each file or patch is a "data blob" that can be
independently de-duplicated, if desired; however, it may make sense
to only make original file versions (for method #1 below), or
current file versions (for method #2 below), eligible for
de-duplication. Both of these example methods perform all file
differentials or "diffs" on the user's device 10 (rather than on
EMS 20), enabling EMS 20 to remain ignorant of the user's file
content.
[0108] Described below are two examples of versioning. In the first
example, an original version of the logical file is stored as
F.sub.0 and patch instructions are applied to F.sub.0 to arrive at
the current version of the file, or any version prior to the
current version. In the second example, the current version of the
logical file is stored as F.sub.N and patch instruction are applied
to F.sub.N to back out changes made in various versions to arrive
at the desire version. These two examples provide the extreme cases
for versioning disclosed herein. It would be apparent to one of
skill in the art that a version of the logical file between the
original F.sub.0 and the current F.sub.N could be selected as the
starting point designated as (F.sub.N-X) and patches could be
applied to bring the starting version F.sub.N-X to more current
versions, or patches could be backed out to bring to earlier
versions.
[0109] Versioning Example Method #1
[0110] If F.sub.0 is the original version of logical file F, and
all subsequent versions are denoted F.sub.i, example versioning
method #1 8000, illustrated in FIG. 8, stores the following
(encrypted in a manner discussed below): {F.sub.0, P.sub.i,
i+1|i.gtoreq.0}. The Nth version of the logical file is obtained as
follows: F.sub.N=P.sub.N-1, N.sup..smallcircle. . . .
.sup..smallcircle. P.sub.1, 2.sup..smallcircle. P.sub.0, 1
(F.sub.0).
[0111] P.sub.m, n is used to denote the set of patch instructions
required to patch version m to version n, and also P.sub.m, n is
used to denote the function, which when applied to version m of the
logical file (byte array) will result in version n of the logical
file (again, a byte array).
[0112] In accordance with the foregoing definitions and
description, FIG. 8 illustrates example high-level operations
required to perform the following actions:
[0113] Step 8200, Commit: when a new version is committed by a
client, the local (modified) file becomes the current version. The
client downloads the original version F.sub.0, and the patches to
the kth version, and creates the kth version as follows:
F.sub.K=P.sub.k-1, k.sup..smallcircle. . . . .sup..smallcircle.
P.sub.1, 2.sup..smallcircle. P.sub.0, 1 (F.sub.0). The client then
performs whatever revision is wants to the kth version, creates a
patch and uploads the patch corresponding to the latest changes to
the EMS 20.
[0114] Step 8300, Checkout: when version k of a logical file is
checked out, the client downloads the original version F.sub.0, and
the patches to the kth version, and creates the kth version as
follows: F.sub.K=P.sub.k-1, k.sup..smallcircle. . . .
.sup..smallcircle. P.sub.1, 2.sup..smallcircle. P.sub.0, 1
(F.sub.0). This assumes that the user's device 10, or client, does
not have any version of the logical file of interest. If the user's
device 10 did have such a version, then the client could simply
download the patches from the current version to the desired
checkout version and apply those patches to the version currently
stored on the client. The client does not upload anything to the
EMS 20 during checkout.
[0115] Step 8400, Revert: if a user's device 10, or client, has
version N of a logical file, and wishes to replace it with version
k<N, the client is said to revert the file to version k. Since
the client already has a version N of the file, the client needs to
download the patches from k to N, which it inverts and applies
those inverted patches as F.sub.k=P.sub.k+1, k.sup..smallcircle. .
. . .sup..smallcircle. P.sub.N-1, N-2.sup..smallcircle. P.sub.N,
N-1 (F.sub.N). The client does not upload anything to the EMS 20
during revert.
[0116] Step 8500, Update: if a user's device 10, or client, has
version k of a logical file, and wishes to update that file to
version N>k (on EMS 20), the client is said to update from
version K to version N. Since the client already created the kth
version of the file stored, the client needs to download the
patches from k to N and applies those patches as F.sub.N=P.sub.N-1,
N.sup..smallcircle. . . . .sup..smallcircle. P.sub.k, k+1
(F.sub.k). The client does not upload anything to the EMS 20 during
update.
[0117] Versioning Example Method #2
[0118] If F.sub.N is the current version of logical file F, and all
previous versions are denoted F.sub.i, example versioning method #2
9000, illustrated in FIG. 9, stores the following (encrypted in a
manner discussed below): {F.sub.N, P.sub.i-1,
i|N-1.gtoreq.i.gtoreq.0}. In accordance with the foregoing
definitions and description, FIG. 9 illustrates example high-level
operations required to perform the following actions:
[0119] Step 9200, Commit: when a new version is committed by a
client, the local (modified) file becomes the current version. The
client downloads the current version F.sub.k from the EMS 20. The
client then performs whatever revision it wants to the kth version,
creates a patch and uploads the patch and the new version F.sub.k+1
to the EMS 20.
[0120] Step 9300, Checkout: when version k of a logical file is
checked out, version F.sub.N is downloaded from EMS 20 to the
user's device 10, along with all the patches (i.e., N-k patches) to
arrive at version F.sub.k. This assumes that the user's device 10,
or client, does not have any version of the logical file of
interest. If the user's device 10 did have such a version, then the
client could simply download the patches from the current version
to the desired checkout version and apply those patches to the
version currently stored on the client. Version k of the logical
file is obtained as follows: F.sub.k=P.sub.k+1, k.sup..smallcircle.
. . . .sup..smallcircle. P.sub.N-1, N-2.sup..smallcircle. P.sub.N,
N-1 (F.sub.N). In other words, the desired version is obtained by
applying the patches from the most current version of the logical
file F.sub.N. (note the patches here are the inverted patches from
method #1). This is different than in versioning method #1
described above because in that method the desired version is
obtained by starting with the original version and applying all the
patches until the desire version is reached. The client does not
upload anything to the EMS 20 during checkout.
[0121] Step 9400, Revert: if a user's device 10, or client, has
version N of a logical file, and wishes to replace it with version
k<N, the client is said to revert the file to version k. Since
the client already downloaded the current version F.sub.N, the
client needs to download the patches to arrive at the changes to
the kth version. Then the client can apply those patches as
F.sub.k=P.sub.k+1, k.sup..smallcircle. . . . .sup..smallcircle.
P.sub.N-1, N-2.sup..smallcircle. P.sub.N, N-1 (F.sub.N). The client
does not upload anything to the EMS 20 during revert.
[0122] Step 9500, Update: if a user's device 10, or client, has
version k of a logical file, and wishes to update that file to
version N (on EMS 20), the client is said to update from version k
to version N. Since the client already has a version of the file
stored, the client needs to download the patches to update the
changes to the Nth version, and must invert those patches. Then the
client can apply those inverted patches as F.sub.N=P.sub.N-1,
N.sup..smallcircle. . . . .sup..smallcircle. P.sub.k, k+1
(F.sub.k). The client does not upload anything to the EMS 20 during
update.
[0123] FIG. 10 provides a comparison 10000 of the corresponding
steps 8200-8500, and 9200-9500, respectively, of versioning method
#1 8000 and versioning method #2 9000. Comparison 10000 indicates
what data must be uploaded to, and downloaded from, EMS 20 for each
operation of interest. The choice on which method to use depends on
the system requirements and desired performance. For example, the
system may want to make available only five previous versions of a
particular file. This could be implemented by using method #2, and
allowing the maximum number of inverted patches to be five. And
since most users usually download the most current version of a
file, method #2 with a limit of five patches not only reduces the
amount of memory that must be allocated to each file, but also
allows the client to use the current version without wasting
resources in applying patches to arrive at the most current version
as would be required in method #1.
[0124] Of course a particular user may require prior versioning on
a regular basis, and may require those versions to be earlier than
five previous versions. In such a case, method #2 may not be
optimal for the system resources, rather method #1 might be better
or method #2 with more than five inverted patches stored.
Alternatively, a hybrid between methods #1 and #2 may be optimal
where a logical file F.sub.K is stored along with patches flanking
both in the more current version direction and the previous
direction. The system can be dynamic enough to identify the current
and historical needs of a particular user, and adapt the versioning
method to optimize the system.
[0125] Example Incorporating Privacy and De-Duplication
[0126] The above descriptions of versioning do not explicitly
indicate encryption and de-duplication. The following example
should clarify how encryption and de-duplication are accomplished,
along with versioning. For the sake of brevity, only an example of
the commit process commit is provided, and only for versioning
method #2. From this example, all other cases will be readily
apparent to a person of skill in the art.
[0127] Detailed Example of Versioning Method #2--Commit Step
9200
[0128] In this example a logical file F is at version k. F.sub.k is
stored on the user's device 10. On EMS 20, the following three
quantities are stored (in a simple database structure): (1)
h.sub.k, the fingerprint of F.sub.k as previously described, for
instance with respect to FIGS. 6 and 7; (2) .alpha..sub.k#F.sub.k,
where F.sub.k, encrypted is with symmetric key .alpha..sub.k; and
(3) K#.alpha..sub.k, the symmetric key .alpha..sub.k, encrypted
with the user's root key K. Patches to previous versions are also
securely stored on EMS 20.
[0129] On the user's device 10, the local version of the file is
modified. The modified file may be denoted by F*. With reference to
the steps and structure shown in FIG. 9, a new version (version
k+1) may be synchronized with EMS 20 as follows: [0130] 1. The
device 10 (e.g., User's Device #1 in FIG. 9) requests version k of
the file from EMS 20. This request contains a file history
identifier. This is simply an identifier that is unique across the
system; it could be a database primary key, a UUID, or the like.
The request also contains the version number requested (i.e., k) .
[0131] 2. The response from EMS 20 contains .alpha..sub.k#F.sub.k
and K#.alpha..sub.k. [0132] 3. The device 10 deciphers
.alpha..sub.k using the user's root key K. [0133] 4. The device 10
deciphers F.sub.k using .alpha..sub.k. [0134] 5. The device 10
computes the patch P.sub.k+1,k; this contains instructions required
to obtain F.sub.k from the new (modified) file F* (which is to
become F.sub.k+1). [0135] 6. The device 10 sends the patch to EMS
20: [0136] a. If the system is designed to enable de-duplication
for patches and the size of P.sub.k-1,k is above the de-duplication
threshold, the device computes the fingerprint of P.sub.k+1,k as
described in the text describing FIGS. 6 and 7. This fingerprint is
denoted h.sub.k+1,k. [0137] b. The device 10 generates the key
.alpha..sub.k+1,k used to encipher P.sub.k+1,k. If the system is
designed to enable de-duplication for patches and the size of
P.sub.k+1,k is above the de-duplication threshold, then
.alpha..sub.k+1,k (i.e., the key) is computed from the patch as
described in the text describing FIGS. 6 and 7. Otherwise,
.alpha..sub.k+1,k is generated at random. [0138] c. The device
enciphers .alpha..sub.k+1,k with the user's root key K, thereby
obtaining K#.alpha..sub.k+1,k. [0139] d. If the size of F.sub.k+1
is below the de-duplication threshold, the device computes the
fingerprint of F.sub.k+1 as described in the text describing FIGS.
6 and 7. Denote this fingerprint by h.sub.k+1. [0140] e. The device
generates the key .alpha..sub.k+1 used to encipher F.sub.k+1. If
the size of F.sub.k+1 is above the de-duplication threshold, then
.alpha..sub.k+1 is computed from F.sub.k+1 as described in the text
describing FIGS. 6 and 7. Otherwise, .alpha..sub.k+1 is generated
at random. [0141] f. The device enciphers .alpha..sub.k+1 with the
user's root key K, thereby obtaining K#.alpha..sub.k+1. [0142] g.
The device sends a commit command to EMS 20. The commit command
contains: [0143] The file history identifier [0144] The current
version (k) can be sent as a "sanity check". [0145] Indication
whether the patch is eligible for de-duplication [0146] The
fingerprint of the patch: h.sub.k+1,k (if eligible) [0147] The
encrypted patch: .alpha..sub.k+1,k#P.sub.k+1,k [0148] The encrypted
patch key: K#.alpha..sub.k+1,k [0149] Indication whether the new
file version is eligible for de-duplication [0150] The fingerprint
of the new file version: h.sub.k+1 (if eligible) [0151] The
encrypted file: .alpha..sub.k+1#F.sub.k+1 [0152] The encrypted file
key: K#.alpha..sub.k+1 [0153] 7. EMS 20 rolls the file version
number: [0154] a. EMS 20 looks up the file history using the file
history identifier [0155] b. EMS 20 ensures that the current
version is at the version (k) provided in the commit command [0156]
If the provided patch is eligible for de-duplication, EMS 20
determines whether the patch fingerprint already exists in the
database. If so, it associates the k+1.fwdarw.k patch entry with
the existing blob. Otherwise, it associates the k+1.fwdarw.k patch
entry with the relevant data provided in the commit command
(h.sub.k+1,k, .alpha..sub.k+1,k#P.sub.k+1,k). In either case, EMS
20 stores the encrypted patch key, K#.alpha..sub.k+1,k, for future
access by the user. [0157] If the newly-provided file version is
eligible for de-duplication, EMS 20 determines whether the
associated fingerprint already exists in the database. If so, it
associates the version k+1 file with the existing blob. Otherwise,
it associates the version k+1 file with the relevant data provided
in the commit command (h.sub.k+1, .alpha..sub.k+1#F.sub.k+1). In
either case, EMS 20 stores the encrypted file key,
K#.alpha..sub.k+1, for future access by the user.
[0158] The description above is provided a simple example to
illustrated the concept, and is not necessarily the preferred data
transport protocol. A preferred method may involve a sequence of
messages between the device 10 and EMS 20 such that duplicate blobs
are not transmitted to EMS 20 (to conserve bandwidth). For example,
a preferred method may involve first sending the fingerprint of the
k+1 file version to EMS 20. The response from EMS 20 would indicate
whether there is already a data blob stored in EMS 20 that
corresponds to the k+1 file version. If so, the device 10 would not
send the blob. If not, the device 10 would then send the encrypted
k+1 file version. In either case, the device 10 would send the
associated key (encrypted with the user's root key), as described
herein.
[0159] While the description above refers to particular embodiments
of the present invention, it should be readily apparent to people
of ordinary skill in the art that a number of modifications may be
made without departing from the spirit thereof. The accompanying
claims are intended to cover such modifications as would fall
within the true spirit and scope of the invention. The presently
disclosed embodiments are, therefore, to be considered in all
respects as illustrative and not restrictive, the scope of the
invention being indicated by the appended claims rather than the
foregoing description. All changes that come within the meaning of
and range of equivalency of the claims are intended to be embraced
therein. Moreover, the applicants expressly do not intend that the
following claims "and the embodiments in the specification to be
strictly coextensive." Phillips v. AHW Corp., 415 F.3d 1303, 1323
(Fed. Cir. 2005) (en banc).
* * * * *