System and method for secure deposit and recovery of secret data

FIELD

The present disclosure relates generally to cryptographic systems and methods to allow for secure deposit and recovery of secret data. More particularly, the disclosure relates to cryptographic systems and methods that use encryption to provide data security and access control on distributed data across communication networks such as the internet.

BACKGROUND

With the increasing use of the internet, more and more users and businesses turn to web-based services for email, file storage, data sharing, social networking and other applications. These web-based services all involve storing and exchanging large amount of sensitive data over the internet. They largely rely on the service providers to protect their data, which we refer to as the trusted-third party model.

The trusted-third party model relies on the good faith and competency of web service providers to protect the users' data. Users have to trust the service providers to properly protect their data with good intention and the users' essentially lose control over who can access their data. The users' data are not only vulnerable to external and insider attacks, but they are also subject to high risks and potential abuses. Furthermore, these service providers have different access control approaches driven by different needs or technologies. Therefore the access controls of the end users' data in different environments are highly fragmented.

The alternative to the trusted third party model is the use of end-to-end encryption model. This model shifts the responsibility of data security and access back to the end user but also the liability of securely protecting the encryption key from loss or theft. If a user loses an encryption key then the secured data will no longer be available. Similarly, if the encryption key is compromised or stolen then the data may no longer be secure.

Shifting the key management responsibility to the users causes many usability issues, such as exchanging encryption keys and securely and reliably storing encryption keys. Some approaches try to resolve these issues by combining the end-to-end encryption model and the trusted-third party model by having a the user trust a third party to manage and secure their encryption keys used in an end-to-end encryption model. These combined approaches still suffer from the same issues as the trusted-third party model as the users' secured data may be accessed by the trusted third party or by compromising the security of the trusted third party.

In typical database systems such as relational database management systems (RDBMS), there are access control systems in place to selectively authorize access to data objects based on a user account or role or group in terms of access privileges. Such an access control system typically functions as a part of a closed system. It depends on the metadata to decide who can access what data. For distributed data residing in separated systems, such conventional access control system cannot function. With the internet increasingly being used as both information storage and transfer media, user data are typically distributed across multiple different and independent web sites or services. Therefore such a conventional access control system cannot function. Moreover, such a conventional access control system depends on database administrators to manage, such as granting or revoking, the access rights. From an end user perspective, such an approach is essentially the same as trusting a 3rd party, which has no assurance of data confidentiality.

Cryptography systems have intrinsic access control properties in a distributed setting such as the internet. Anyone who can access a cipher doesn't necessarily mean that he/she can access the original data of the cipher. Only the intended users who possess the keys that can decrypt a cipher can access the data. Among many cryptography systems, client-based end-to-end cryptography systems, such as PGP and SMIME, offer strong data security assurance for end users.

However, many issues prevent these systems from being used as common access control tools for average users to govern their sensitive data distributed all over the internet. First, these systems are not sufficient for access control. Because once the data are encrypted and distributed such as after a PGP or SMIME email being sent, it's difficult to grant additional access or revoke an existing access. Second, the key managements of such systems are enormously hard for most average users. Third, the fact that users have to exchange public key certificates before exchanging any data further deter users from adopting them. Furthermore, once the private key is lost, the data protected by the private key cannot be recovered. This is a big risk for users who consider adopting the systems. Especially, with the increasing use of mobile devices among users, losing a mobile device is an event with high probability. Losing a mobile device with its stored secret key, such as a private PGP key, is a major risk for a user of such end-to-end cryptography systems.

Various systems have been proposed to address some of the issues. To prevent the loss of a private key, a common solution is to allow a user to encrypt a private key with a passphrase then store the encrypted private key in systems accessible over the internet. As long as users have access to the systems, the users can retrieve the private key ciphers and decrypt them by inputting the passphrases. However, users of such systems have to shoulder the burden of remembering the passphrases. Losing the passphrases results in losing the encrypted private keys. They are vulnerable to either losing the private keys when forgetting complex passphrases or vulnerable to being attacked when using simple passphrases even in the case of using password-based key derivation function (KDF). In addition, it is a one-factor authentication because knowing the passphrase can get the private key to decrypt the data. More importantly, data protected by a user passphrase is vulnerable to systematic insider attacks by the server.

A system described in US 2013/0198508 A1 allows a local device to recover an encrypted key that is encrypted by a key, L, related to two “public” keys, one of which D is stored in the local device. This is useful when a user cannot recall the password for a password-encrypted version of the encrypted key. However, when the local device is lost and the stored “public” key D is also lost, L cannot be recovered. Thus the encrypted key cannot be recovered.

Some systems, such as Symantec PGP products or a system described in US 2013/0080765 A1, require extra secrecies for recovery purpose. For example, multiple personal questions and answers known to a user are used to create a recovery key. However, because recovery is not a frequent event, answers to these questions could be very hard to remember. In fact, these systems force a user to remember more secrecy.

Some systems distribute recovery secrecy to multiple systems such as different sites in parts so that in the case of recovery the segments of data are retrieved from these sites and combined together to recover the data. For example, a system described in U.S. Pat. No. 8,572,757 B1 stores a recovery key in one site and the encrypted data in another site. These systems are cryptographically unsafe because it requires a user to turn over the secrecy to a trusted 3rd party. Such systems are vulnerable to large scale systematic collusion attacks.

SUMMARY

According to a first aspect, a social-based cryptographic system is provided for secure deposit of a secret data associated with a user account, the system comprises a user device, a recovery server, and a recovery peer. The user device has a memory for storing instructions and a processor for executing the instructions to derive an encryption key based on a secret provided to the user device to generate a derived encryption key, encrypt the secret data using the derived encryption key to generate a once-encrypted secret data, designate a recovery peer and obtaining a recovery-peer key associated with the recovery peer, and encrypting the once-encrypted secret data using the recovery-peer key to generate a twice-encrypted secret data. The recovery server stores the twice-encrypted secret data and associates the twice-encrypted secret data with the user account and the recovery peer. The recovery peer device associated with the recovery peer, the recovery peer device having a memory for storing instructions and a processor for executing the instructions to: generate the recovery-peer key and provide the recovery-peer key to the user device. In some aspects of the social-based cryptographic system the secret data associated with the user account can be securely recovered, the recovery peer device having further instructions to obtain the twice-encrypted secret data, decrypt the twice-encrypted secret data using the recovery-peer key to recover the once-encrypted secret data, and transmit the once-encrypted secret data to the user device; and the user device having further instructions to derive the encryption key based on a secret provided to the user device to generate the derived encryption key at the user device, and decrypt the once-encrypted secret data using the derived key to recover the secret data.

According to a second aspect, a method for depositing a secret data of a user account in a cryptographic system to allow for secure recovery of the secret data is provided. The method comprises deriving an encryption key based on a secret provided to a user device to generate a derived encryption key at the user device; designating a recovery peer and obtaining a recovery-peer key associated with the recovery peer; encrypting the secret data using the derived encryption key and the recovery-peer key to generate an encrypted secret data; and storing the encrypted secret data at a location remote from the user device. In some embodiments encrypting the secret data can comprise encrypting the secret data using the derived encryption key to generate a once-encrypted secret data, and encrypting the once-encrypted secret data using the recovery-peer key to generate a twice-encrypted secret data. In a further aspect of the method for securely depositing secret data the secret can be a password and deriving the derived encryption key can use a password-based key derivation algorithm at the user device. The password-based key derivation algorithm can use any one of a salt, an iteration count, and a combination thereof obtained from the recovery server. In a further aspect of the method for securely depositing secret data can include obtaining a symmetric key from the recovery server associated with the user account, and the derived encryption key can be comprised of the symmetric key and a key derived from a password-based key derivation algorithm using a password. The derived encryption key can be comprised of the XOR operation of the symmetric key and the key derived from a password-based key derivation algorithm using the password.

In a further aspect of the method for securely depositing secret data, the recovery-peer key can be a public key corresponding to a public/private key pair associated with the recovery peer or a symmetric key shared with the recovery peer. The recovery-peer key can be obtained from the recovery server. In a further aspect the recovery peer and the user account can have mutually consented to provide secure recovery to one or each other. In a further aspect of the method for securely depositing secret data, the location remote from the user device can be the recovery peer or the recovery server. The recovery server can associate the encrypted secret data with the user account and the recovery peer.

In yet a further aspect of the method for securely depositing secret data, the twice-encrypted secret data can be cryptographically signing with an identity key associated with the user account. In yet another aspect the secret data can be a private key corresponding to a public/private key pair associated with the user account.

According to a third aspect, a method for securely recovering a secret data of a user account in a cryptographic system that has been securely deposited is provided. The method for securely recovering a secret data comprises obtaining an encrypted secret data at a recovery peer device, the encrypted secret data encrypted using a derived encryption key based on a secret and a recovery-peer key of a recovery peer device; deriving an encryption key based on a secret provided to the user device to generate the derived encryption key at the user device; decrypting the encrypted secret data using the recovery-peer key and the derived encryption at the user device to recover the secret data.

In some aspects of method for securely recovering the secret data, the step of decrypting the secret data can comprise decrypting the encrypted secret data by the recovery peer device using the recovery-peer key to generate a once-encrypted secret data; receiving the once-encrypted secret data from the recovery peer device at a user device associated with the user account; and decrypting the once-encrypted secret data using the derived key to recover the secret data. The secret can be a password and deriving the derived encryption key uses a password-based key derivation algorithm at the user device. The user device can obtain a salt, an iteration count, or a combination thereof, from the recovery server that can be used as an input to the password-based key derivation algorithm. In some aspects, a symmetric key associated with the user account can be obtained from the recovery server, and the derived encryption key can be comprised of the symmetric key and a key derived from a password-based key derivation algorithm using a password. The derived encryption key can also be comprised of the XOR operation of the symmetric key and the key derived from a password-based key derivation algorithm using the password. An authentication token can be provided to the recovery server from the user device to verify that the user account is associated with the user device, the authentication token can be generated from a password using the password-based key derivation algorithm at the user device

In some further aspects of method for securely recovering the secret data, the method can further comprise receiving a request for secret data recovery from a user device at a recovery server; and identifying a recovery peer. The method can also include transmitting the twice-encrypted secret data to the recovery peer from the recovery server.

In still other aspects of method for securely recovering the secret data, the recovery-peer key can be a private key stored on the recovery peer device corresponding to a public/private key pair of the recovery device. The method can also comprise receiving a confirmation associated with the user account through an out-of-band communication that the user account is requesting recovery of the secret data. The out-of-band communication can include a cryptographic hash, such as fingerprint, associated with a communication channel, or a public/private key pair that is used to secure the communication channel, used by the user device to request secure recovering of the secret data. In some aspects the secret data can be a private key corresponding to a public/private key pair associated with the user account, such as to identify the user account.

According to a fourth aspect, a method of securely recovering a user account without a password using peer-based authentication of ownership of the user account is provided. The method comprises generating a random value at a user device associated with the user account and cryptographically signing the random value with a user private key associated with the user account to generate a first signature; designating a recovery peer and obtaining a recovery key associated with the recovery peer; encrypting the first signature with the recovery key associated with the recovery peer to generate an encrypted first signature; storing the random value and the encrypted first signature at a recovery server; retrieving the encrypted first signature from the recovery server at recovery peer device of the recovery peer; decrypting the encrypted first signature using the recovery key at a recovery peer device of the recovery peer to generate decrypted first signature; providing the decrypted first signature to the recovery server; and verifying the decrypted first signature using a user public key corresponding to the user private key and the random value at the recovery server. In some aspects of the method, the recovery key can be a public key and decrypting the encrypted first signature can use a recovery private key corresponding to the public key. In other aspects the recovery key can be a symmetric key. In yet a further aspect, the method can further comprise requesting the recovery peer authenticate ownership of the user account through an out-of-band communication to prevent a man-in-the-middle attack.

In yet another aspect of the method of securely recovering a user account, the method can further comprise generating a new-identity public key and a new-identity private key; associating the new-identity public key with the user account by cryptographically signing the new-identity public key with the recovery public key at the recovery peer device to generate a second signature; and verifying that the second signature belongs to the recovery peer.

According to a fifth aspect, a method of decoupling a password from secret data secured with the password is provided. The method comprises encrypting the secret data with a server key stored at a recovery server; and permitting access to the server key by a user device by authenticated access using the password.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the various embodiments described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings which show at least one exemplary embodiment, and in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a social network-based cryptographic system for providing encryption-based access control and secure recovery of secret data;

<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart diagram of a method for enforcing access control in the social network-based cryptographic system of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart diagram of a method for depositing secret data to allow for secure recovery using a recovery peer;

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart diagram of a method for securely recovering secret data using a recovery peer device;

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart diagram of a method for securely recovering a shared secret between a user and a recovery peer;

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart diagram of a method for securely sharing data between peers;

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart diagram of a method for setting up a peer-based account recovery; and

<figref idref="DRAWINGS">FIG. 8</figref> is a flowchart diagram of a method for a peer-based authentication and account recovery.

DESCRIPTION OF VARIOUS EMBODIMENTS

It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementations of various embodiments described herein.

Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a block diagram illustrates an exemplary environment <b>100</b> having a first client device <b>105</b> of User <b>1</b>, a second client device <b>110</b> of User <b>2</b> coupled to a data communication network <b>102</b>, such as the internet, for example, with a server computer <b>115</b> and a service <b>120</b>.

Client devices <b>105</b> and <b>110</b>, server computer <b>115</b> and service <b>120</b> are computing devices that include a computer processor and a memory for storing data and software instructions for execution by the processor. These computing devices also include a network interface, wired or wireless, to allow communication using data communication network <b>102</b>. Devices <b>105</b> and <b>110</b> can be a mobile phone, a tablet, a wearable device, a computer or any other kind of computing device.

User <b>1</b> device <b>105</b> is a client device User <b>1</b> can register a user account using an identifier and an authentication token, such as a passphrase, for example, with server <b>115</b>. The identifier can be a unique and arbitrary string or any other unique identifier, such as an email address, for example. Although embodiments below are described using a passphrase, other authentication tokens may be used similarly. The term “user account” is used generically to associate a user of the system and can include physical persons or devices as users. For example, an autonomous device or device in the Internet-of-Things can also have a user account with server <b>115</b>.

Once the user account is created, the client device generates a private/public key pair of private key K₁<b>125</b> and public key k₁<b>130</b> as master keys. In some embodiments, keys <b>125</b> and <b>130</b> can be generated based on Elliptic Curve Cryptography (ECC) or any other asymmetric systems including but not limited to, RSA, EIGamal, Diffie-Hellman, Paillier, NTRU and McEliece. User <b>1</b> device <b>105</b> further generates a server key S₁<b>160</b>. User <b>1</b> device <b>105</b> can then deposit public key k₁<b>130</b>, and clear-text server key S₁<b>160</b> into User <b>1</b> account stored on server <b>115</b>, preferably via a secure communication mechanism, such as SSL/TLS, for example, or any other means of secure communication. In some embodiments, server key S₁<b>160</b> can be generated at server computer <b>115</b> associated with User <b>1</b> account. In these embodiments, server key S₁<b>160</b> is transferred to device <b>105</b> via secure communication. It is understood that User <b>1</b> is authenticated before accessing server key S₁<b>160</b>. In some embodiments, server key S₁<b>160</b> can be encrypted by a key derived from the authentication token and stored locally in device <b>105</b>, in addition to a copy of the server key S₁<b>160</b> being stored in the server computer <b>115</b>. User <b>1</b> is required to present the passphrase to decrypt the local server key S₁<b>160</b> or login to User <b>1</b>'s account on server <b>115</b> to retrieve server key S₁<b>160</b>.

User <b>1</b> Device <b>105</b> encrypts master private key <b>125</b> with server key <b>160</b> via a symmetric encryption algorithm. Device <b>105</b> outputs cipher K_1S1<b>190</b> and stores cipher K_1S1<b>190</b> locally on device <b>105</b> along with public key k₁<b>130</b>. This provides a method of decoupling a password from secret data that is secured with the password by encrypting the secret data with a server key stored at the recovery sever and permitting access to the server key by a user device by authenticated access using the password. The secret data can be a private key stored on the device that is encrypted with the server key.

The decoupling of the login passphrase and the master private key stored in device <b>105</b> during normal operations allows resetting passphrase and recovering master private key become two separate operations, which allows each of the operations to be carried out freely and independently. With this decoupling, when losing the User <b>1</b> Device <b>105</b> that stores the master private key, a login passphrase could help recover the master private key; when resetting a login passphrase, it would not affect the local encrypted master private key. Those skilled in the art will appreciate that this lowers the probability of losing both login passphrase and a device storing the master private key at the same time. Equally important, this decoupling ensures a user is authenticated by two factors in order to access data. One is the login passphrase, which a user knows. The other is the master private key in the device, which a user has.

In a preferred embodiment, the symmetric algorithm can be AES-256 in CTR mode, where server key size is 256 bits in length. Any other symmetric encryption algorithms including block ciphers and stream ciphers such as Blowfish, DES, Triple DES, Serpent, Twofish, IDEA, RC2, RC5, and any key sizes can be used. In some embodiments, device <b>105</b> can additionally output and store another cipher locally by encrypting master private key <b>125</b> with a derived key based on User <b>1</b> account passphrase.

User <b>1</b>'s account passphrase can be enhanced by a password-based key derivation function such as PBKDF2, bcrypt or scrypt. In a preferred embodiment, PBKDF2, salt a₁and a sufficiently large iteration count can be used to derive a strong passphrase, which is stored in server <b>115</b> for authentication purpose. Salt a₁can be generated by the client device process during key generation.

In some embodiments, User <b>1</b>'s account identifier can be signed by User <b>1</b>'s master private key <b>130</b>. The signature can then be deposited into User <b>1</b>'s account on server <b>115</b>.

In the case that User <b>2</b> registers a user account in server <b>115</b> with a device <b>110</b>, master private key K₂<b>135</b> is generated, encrypted with generated random server key S₂, and stored locally in device <b>110</b> along with generated master pubic key k₂<b>140</b>. Public key <b>140</b>, generated random salts a₂and b₂and server key S₂can all be deposited in registered User <b>2</b> account in server <b>115</b> via a secure communication channel. It's to be understood that User <b>2</b> could be a secondary account of a same physical user.

In a preferred embodiment, User <b>1</b> can look up User <b>2</b> with necessary contact information or identifier, such as User <b>2</b>'s email address, and initiate a request of exchanging encrypted data with User <b>2</b>. If User <b>2</b> accepts and authorizes the request, User <b>1</b> and <b>2</b> are allowed to exchange both master public keys k₁<b>130</b> and k₂<b>140</b> with each device. Otherwise, User <b>1</b> and <b>2</b> will not be allowed to have each other's public keys. In some embodiments, User <b>1</b> and <b>2</b> can verify associated fingerprints of the public keys or digital signatures signed by each other's master private key when exchanging public keys.

While a user authorized handshake may or may not be used for exchanging public keys, those skilled in the art will appreciate that this helps a recipient easily differentiate the trust level of incoming encrypted data. More importantly, it could also reduce the probability of any unintended or malicious encrypted data being decrypted by a recipient's client device.

In the case that User <b>1</b> needs to send data D, such as a private email, for example, to User <b>2</b> via service <b>120</b>, such as a webmail provider, for example, User <b>1</b> device <b>105</b> can initiate a process <b>200</b> illustrated in <figref idref="DRAWINGS">FIG. 2</figref>. At step <b>205</b>, device <b>105</b> will generate a session key S, then at step <b>210</b> encrypt the data D with the session key S (preferably using AES-256 in CTR mode) and output cipher Ds <b>155</b>. In some embodiments, device <b>105</b> can first compress data D, then encrypt the compressed data D and output cipher Ds <b>115</b>. In some embodiments, the session key can be a random key. In other embodiments, the session key can be generated based on data D. For example, session key S could be a hash value of a file when data D is a file and service <b>120</b> is a cloud storage service. Data D authenticity and integrity checking and non-repudiation may or may not add to cipher Ds <b>155</b>. In some embodiments, device <b>105</b> can generate a digital signature for data D using User <b>1</b>'s master private key and associates to cipher <b>155</b>.

Device <b>105</b> can also generate an index I <b>165</b> associated to cipher <b>155</b>. In some embodiments, the index can be inserted into cipher <b>155</b>. In other embodiments, the index can be derived from cipher <b>155</b>. At step <b>215</b>, device <b>105</b> will encrypt the session key S with its own public key k₁and at step <b>220</b> deposit output cipher Ski <b>175</b> and index I <b>165</b> into the account in server <b>115</b> associated with User <b>1</b>. At step <b>225</b>, User <b>1</b> Device <b>105</b> can also retrieve User <b>2</b>'s public key k₂according to User <b>2</b>'s identifier, such as an email address, and at step <b>230</b> encrypt the session key S with User <b>2</b>'s public key k₂. At step <b>235</b> device <b>105</b> deposits the output cipher S_k2<b>185</b> and the associated index I <b>165</b> into User <b>2</b>'s account at server <b>115</b>. Finally, at step <b>240</b>, User <b>1</b> Device <b>105</b> sends Ds to service <b>120</b>.

In a preferred embodiment, device <b>105</b> can store a copy of server key encrypted by a key derived from User <b>1</b>'s account passphrase. During normal operation, when User <b>1</b> logs into server <b>115</b> by using an account identifier and a passphrase, User <b>1</b> Device <b>105</b> can derive a key based on the input passphrase and obtain server key S₁. With server key S₁, device <b>105</b> can decrypts cipher K_1S1to obtain master private key K₁and store it in the device memory for normal operation.

User <b>2</b> device <b>110</b> can receive or retrieve cipher D_s<b>185</b> from service <b>120</b>, such as an email from a webmail provider, for example. Device <b>110</b> will also retrieve cipher S_k2<b>180</b> from server <b>115</b>, decrypt cipher <b>180</b> with User <b>2</b> private key K₂and obtain session key S <b>145</b> locally at User Device <b>2</b>. Finally with session key S <b>145</b>, it decrypts cipher D_s<b>155</b> and obtains data D <b>150</b> locally. In some embodiments, device <b>110</b> can further uncompress the obtained data after decryption to obtain data D <b>150</b>. In some embodiments, User <b>2</b> device <b>110</b> can also validate the digital signature of data D using User <b>1</b>'s master public key.

If User <b>1</b> needs to revoke User <b>2</b>'s access to cipher <b>155</b>, after sending out the private email, or cipher Ds <b>155</b> to service <b>120</b>, User <b>1</b> can look up and remove cipher S_k2<b>180</b> from User <b>2</b>'s account stored on server <b>115</b>.

In the case that User <b>2</b> has not yet registered an account in the server <b>115</b>. User <b>1</b> can still first exchange data with User <b>2</b> before any public key exchange takes place, then at a later time grant additional access right to User <b>2</b>, after User <b>2</b> registers an account in server <b>115</b> and performs the public key exchange. In this case, User <b>1</b> can first carry out steps <b>205</b>, <b>210</b>, <b>215</b>, <b>220</b> and <b>240</b>. Later, once User <b>2</b> has registered an account and a user-authorized handshake took place, User can <b>1</b> can perform the process illustrated in <figref idref="DRAWINGS">FIG. 6</figref> to grant the access right to User <b>2</b>. At step <b>605</b>, device <b>105</b> retrieves cipher Ski <b>175</b>, at step <b>610</b>, obtains session key S <b>145</b> by decrypting cipher <b>175</b> with key K₁<b>125</b>, after obtaining public key k₂<b>140</b> at step <b>615</b>, encrypts session key <b>145</b> with public key <b>140</b>, outputs cipher S_k2<b>180</b> locally at step <b>620</b>. Finally device <b>105</b> deposits cipher <b>180</b> into User <b>2</b>'s account in server <b>115</b> at step <b>625</b>.

It is understood that data D is not limited to be email. It could be any type of files, text and media based on applications. Service <b>120</b> is not limited to be a web mail provider. It could a cloud storage service, a social network service, a messaging service or any type of services that temporarily or permanently store and access to cipher <b>155</b>. Service <b>120</b> could be any destination service or intermediate service. Service <b>120</b> might or might not have its own access control mechanism. It should also be understood that service <b>120</b> not only can reside in the internet, but also can reside with server computer in the same network including, but not limited to, LAN, VLAN, wireless network, WAN and any combination of them.

It should also be understood that it's easy to grant additional access rights to additional users to access cipher D_s<b>155</b>. In the case of User <b>1</b> sharing a file, or data D <b>150</b>, via a cloud storage service, or service <b>120</b>, after User <b>1</b> initially granting access right to User <b>2</b> according to block diagram <b>200</b>, User <b>1</b> can still grant an additional access right to an extra user. Device <b>105</b> can first retrieve cipher <b>175</b> and the associated index I <b>165</b>, decrypt cipher <b>175</b> with private key <b>125</b> to obtain session key S <b>145</b>, then encrypt session key S <b>145</b> with the public key of the extra user and deposits output cipher and the index <b>165</b> into the extra user's account in the server.

In the case User <b>1</b> needs to recover the master private key when the local master private key is lost, for example by losing device <b>105</b>, User <b>1</b> can pick one or more users with whom User <b>1</b> has completed handshakes and store the master private key securely in the server computer. In a preferred embodiment, at the same time, User <b>1</b> might additionally enable account recovery by storing a secret signature in the server computer for supporting authentication factor “the peer you know”, whose details are described in process <b>700</b> and <b>800</b>.

Next reference will be made to <figref idref="DRAWINGS">FIG. 3</figref> which illustrates a method for depositing secret data to allow for secure recovery using a recovery peer. The secret data in this example refers to the private key <b>125</b> of User <b>1</b> but any other type of secret data, such as passwords or a file, for example, can be recovered using this method. The server <b>115</b> is also referred to as the recovery server as it assists with the secret data recovery.

Illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, process <b>300</b> is a process for storing secret digital data securely using recovery peers. At step <b>305</b>, User <b>1</b> pick User <b>2</b> as a recovery peer and obtains a recovery-peer key from User <b>2</b>. In this example, User <b>2</b>'s public key k₂corresponding to User's <b>2</b> private key K₂. User <b>1</b> also derives an encryption key based on a secret provided to the user device to generate a derived encryption key. A passphrase P<b>1</b> can be input by User <b>1</b> as the secret for deriving a key P′₁. Such a passphrase can be an arbitrary string with sufficient security strength. In a preferred embodiment, such a passphrase can be identical to the passphrase of User <b>1</b> account. At step <b>310</b>, a key P′₁is derived from P₁using a password-based key derivation function, such as function PBKDF2 with salt b₁and a sufficiently large iteration count c₁. At step <b>315</b>, another key L₁can be further derived from derived key P′₁by combining with server key S₁. In this manner the derived encryption key is a combination of a secret of the user (e.g. the passphrase) and a shared secret with the recovery server <b>115</b>. In a preferred embodiment, the combining operation can be an XOR operation. At step <b>320</b>, device <b>105</b> encrypts the secret data, or the master private key K₁<b>125</b>, with derived key L₁and outputs cipher K_1L1. At step <b>325</b>, device <b>105</b> further encrypts cipher K_1L1with the recovery-peer key, (e.g. public key k₂) and outputs cipher K_1L1k2locally. Finally, at step <b>330</b>, device <b>105</b> stores cipher K_1L1k2at a location remote from User Device <b>105</b>, such as in recovery server <b>115</b> or another internet-accessible server.

The encryption of the secret data can be done in any number of reversible ways using the recovery-peer key and the derived encryption key, such as by changing the order to application of the keys or combining the keys to encrypt the secret data. In some embodiments, the secret data, K₁, can be first encrypted with a derived key from a passphrase, then encrypted with server key S₁before being encrypted with User <b>2</b>'s public key k₂. In other embodiments, K₁can be first encrypted with server key S₁, then encrypted with a derived key from a passphrase before being encrypted with User <b>2</b>'s public key k₂. It is to be understood that the re-encryption is not limited to using User <b>2</b>'s public key. In some embodiments, the re-encryption is done using User <b>2</b>'s symmetric key accessible by User <b>1</b>. In these embodiments, User <b>1</b>'s device can use a symmetric key to encrypt K_1L1then transfer and store the symmetric key in User <b>2</b>'s device via secure communication means. In these embodiments, the derived encryption key, L₁, can be generated by combining P′₁, S₁and the shared symmetric key of User <b>2</b>. K_1L1is generated by encrypting with L₁and stored in server. In other embodiments, User <b>1</b>'s device can use a shared symmetric key associated with the public keys of User <b>1</b> and User <b>2</b> to obtain K_1L1, for example, based on Elliptic Curve Integrated Encryption Scheme (ECIES).

In the case of losing master private key <b>125</b> and cipher <b>190</b> (or registering a new User Device associated with the user account stored at the recovery server), after User <b>1</b> has logged in into his account by providing the passphrase, and optionally verifying with one or more additional authentication factors, device <b>105</b> can initiate a master private key recovery process illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. At step <b>405</b>, device <b>105</b> generates a pair of private key T₁and public key t₁, then at step <b>410</b> sends public key t₁to server.

At step <b>415</b>, server <b>115</b> receives t₁and signals User <b>2</b> device <b>110</b> to help recover private key for User <b>1</b>.

At step <b>420</b>, device <b>110</b> receives public key t₁and cipher K_1L1k2<b>185</b>. The cipher K_1L1k2<b>185</b> is provided as an example of encrypted secret data that can be decrypted to recover the secret data using a derived encryption key (derived from a secret of the user and a shared secret with the server) and a recovery-peer key.

In a preferred embodiment, upon receiving public key t₁and the recovery request, User <b>1</b> and User <b>2</b> carry out a public key verification on t₁, via an out-of-band communication, at the same time allow User <b>2</b> to authenticate User <b>1</b> is the person who issues t₁. An out-of-band communication can refer to any communication between User <b>1</b> and User <b>2</b> that verifies the identity of the other user to ensure that it is the User that is making the request. This can include digital communication, such as e-mail, SMS text messages, and non-digital communication such as in person communication or phone calls.

Any approach of verifying a public key during exchange known in the art can be used, for example, verifying the fingerprint of a public key or a digital signature. The fingerprint can be provided by an SMS message, for example, from User <b>1</b> to User <b>2</b>. Such verification can detect a potential man-in-the-middle attack. At step <b>425</b>, device <b>110</b> decrypts K_1L1k2with the recovery-peer key of User <b>2</b> (e.g. private key K₂) and obtains cipher K_1L1. In some embodiments, device <b>110</b> can obtains cipher K_1L1by using a symmetric key. At step <b>430</b>, device <b>110</b> encrypts cipher K_1L1with public key t₁and output cipher K_1L1t1. At step <b>435</b>, device <b>110</b> sends cipher K_1L1t1to recovery server <b>115</b>.

At step <b>440</b>, recovery server <b>115</b> receives cipher K_1L1t1and notifies device <b>105</b>.

At step <b>445</b>, device <b>105</b> receives cipher K_1L1t1, and at step <b>450</b> decrypts it with private key T₁and obtains cipher K_1L1. Next, device <b>105</b> derives an encryption key based on a secret provided to User Device <b>1</b> (e.g. a passphrase or biometric) and a shared secret with the recovery server <b>115</b>. At step <b>455</b>, device <b>105</b> derives key P′₁from passphrase P₁using the same password-based key derivation function with the same parameters as used in step <b>310</b> to deposit the secret data for secure recovery. In a preferred embodiment, passphrase P₁can be read from the memory location where P₁is stored after being input by User <b>1</b> during log in. In other embodiments, passphrase P₁can be being input by User <b>1</b> explicitly. At step <b>460</b>, device <b>105</b> further derives key L₁by combining P′₁and retrieved server key S₁. The combining operation is identical to the one at step <b>315</b>. Once key L₁is recovered, at step <b>465</b>, device <b>105</b> decrypts cipher K_1L1with key L₁and obtains master private key K₁. Finally, at step <b>470</b>, device <b>105</b> can destroy private key T₁and public t₁.

It's to be understood that the recovered digital data could be any digital data other than the master private key K₁. It could be also any types of files including, but not limited to, documents, images, binaries, hard drive images and backup files. In some embodiments, the master private key K₁can be encrypted with more than one recovery peers' public keys.

In a case of User <b>1</b> not being able to remember account passphrase as well as losing master private key <b>125</b> in device <b>105</b>, access to the data shared by peers can remain recoverable. After User <b>1</b> completed an authentication with one or more factors, for example, at least one of them is the factor described in process <b>700</b> and <b>800</b>. User <b>1</b> can re-login into User <b>1</b>'s account at server <b>115</b> and initiate a restore data access process illustrated in <figref idref="DRAWINGS">FIG. 5</figref> to recover a shared secret (e.g. cipher D_s<b>155</b>) between User <b>1</b> and User <b>2</b>.

At step <b>505</b>, device <b>105</b> generates a new pair of master private key N₁and master public key n₁. At step <b>510</b>, device <b>105</b> stores public key n₁to server <b>115</b>.

At step <b>515</b>, server <b>115</b> receives public key n₁and signal of restoring data access. Server <b>115</b> identifies all users with whom User <b>1</b> share data and signal found users, User <b>2</b> in this example.

At step <b>520</b>, User <b>2</b> device <b>110</b> receives a signal from server <b>115</b> and retrieves new public key n₁. At step <b>525</b>, device <b>110</b> retrieves cipher, S_k2, whose key is shared secrecy with public key k₁and k₂. At step <b>530</b>, for each retrieved cipher, S_k2, device <b>110</b> decrypts S_k2with master private key K₂and obtain session key S. At step <b>535</b>, for each obtained session key S, device <b>110</b> encrypts S with new public key n₁and outputs cipher S_n1. At step <b>540</b>, device <b>110</b> stores cipher S_n1in server <b>115</b>.

At step <b>545</b>, server <b>115</b> receives and store cipher S_n1and signals User <b>1</b> that the recovery process by User <b>2</b> is completed.

At step <b>550</b> device <b>105</b> receives signal of completion and ready to access recovered data with new master private key N₁.

In the case that User <b>1</b> cannot remember the account passphrase, a passphrase reset can be initiated. User <b>1</b> should first be authenticated with one or more factors. In some embodiments, User <b>1</b> can be authenticated with two factors by verifying an email and verifying a text message. It's to be understood that the authentication mechanism could be any approach known in the art. Once User <b>1</b> is authenticated, device <b>105</b> can retrieve server key S₁from server <b>115</b> and decrypt cipher K_1S1to obtain K₁. Device <b>105</b> thus can replace the local encrypted copy of server key S₁cipher K_1S1by encrypting S_K1with the new passphrase, in a preferred embodiment, as well as replace cipher K_1L1k2by initiating the peer-based recovery illustrated in block diagram <b>300</b>, using the new passphrase. It is to be understood that the passphrase for authentication could be a separate passphrase for encrypting secrecies and they could be a single passphrase. It is also understood that a user account could be authenticated with different authentication tokens, such as smart cards, one-time passwords, images, biometrics as well as a passphrase could be a sequence of bits derived from such mechanisms.

Those skilled in the art will appreciate that the present disclosure significantly strengthens data security and recoverability of online data for a user and the usability of cryptography systems, by using social peers. Intuitively, a group of users can better defend attacks than an individual. By helping each other, a user can keep online data safe by only using a passphrase. This allows social groups more than just for sharing but also for better protection, recovery and usability, thus becomes a social security network. It maintains strong data security assurance on a secrecy stored in the server based on the strength of cryptographic elements. It first resists insider attacks from the server using a multi-layer encryption. It also resists attacks by a recovery peer by wrapping the secrecy with a generated key. A vicious recovery peer has to try login interactively to brute force the passphrase in order to get the server key. Such attempts are not sufficient and can be detected easily by the server. In the case of a recovery peer colluding with the server together, the secrecy is still protected by the strength of a user passphrase and the key derivation functions. The requirement of collusion with an individual prevents large-scale attacks especially when the server is comprised. Because a recovery peer is likely a trusted person of the user, it is less likely for a collusion to take place. In addition, the availability of both passphrase reset and recovery solution allows a user to pick a stronger passphrase, as the user knows that the account and data are recoverable in the case of losing a passphrase.

In the case that User <b>1</b> account and User <b>2</b> account are two different accounts of a same physical user, using User <b>2</b> account as a recovery peer also offers significant security benefits. A brute force attack on User <b>2</b>'s account can not directly comprise the security of User <b>1</b> account. In some embodiments, a physical user can use two separated accounts, each of which acts as the other's recovery peer. Such a setup can give the same physical user additional recovery means without weakening the strong security assurance.

Those skilled in the art will appreciate that with the combination of features of passphrase reset, key recovery and shared data recovery, the present disclosure significantly reduces the task for a user to manage secrecy without comprising data security assurance. When losing account passphrase, the master private key can be recovered. When losing a device or the storage of the master private key, the master private key can be recovered, without the need of keeping extra secrecy. Even when both passphrase and device with master private key are lost, shared data can still be recovered, which minimizes the lost of data. In addition, to access a user's data, an attacker needs two factors—the passphrase that a user knows and the master private key that a user has. This significantly strengthens the security of user data.

Those skilled in the art will also appreciate that the present disclosure allows multiple client devices to communicate securely without being online at the same time, by storing communication data in an intermediate storage service when client devices are offline. It can enhance the data security for many services including messaging services.

In some environments such as an enterprise environment, it's typically required to access data for audit, virus scan, monitor, or sometimes being recovered by an employer when an employee leaves an organization. In this case, one or more additional access for trusted authorities are optionally granted to targeted encrypted data by automatically adding encrypted session keys associate with the authority account. In some embodiments, such an automatic-granted access could be carried out in a form of attaching the encrypted session key to the targeted encrypted data, i.e. key escrow. In other embodiments, the key escrow can be in a compatible format of PGP, SMIME or other standards. Those skilled in the art will appreciate that such hybrid form of access control it is easy to perform inline data scanning without compromising the flexibility of managing access control with end users. In a preferred embodiment, those user accounts and communications subjected to authority access are differentiated using indicators on the user interface presented on a graphic display of client devices, for example, different colors, fonts or graphical symbols, such that communication peers are aware of what data can be accessed by a 3rd party. Being transparent will greatly improve privacy protection. By knowing what communications are secure and what are not, users can determine what data should be exchanged under each scenario.

In the case that a second device is to share the same user account with a first device, the master private key stored in the first device is transferred to the second device securely. In a preferred embodiment, the second device generates a pair of temporary private/public keys to facilitate the transfer on top of other secure communication means such as SSL/TLS with server computer. In some embodiments, the first device and the second device can communicate directly with each other. Once the master private key of the user account is received, the master private key will be used to access the data of the user account. In a preferred embodiment, any additional device to use the same user account will require an authorization from an existing device and a notification is sent to all devices of the user account. In addition, any password reset, key recovery and data recovery will trigger a notification to all devices of the user account. Those skilled in art will appreciate that these authorization and notification can significantly improve the security of an user account by allowing the account user be aware of critical changes of the account.

It's understood that the present disclose can be modified for variations. In other embodiments, session key S can be a private key whose public key is used to encrypt other data. In other embodiments, the master private key could be encrypted with a symmetric key. In these embodiments, the encrypted master private key can be stored in the server computer.

When a user forgot the login passphrase as well as losing the master private key, the user loses the account. In order to recover the account, the user must re-authenticate himself/herself against the server to prove that he/she is the person he/she claimed to be. For security reasons, a multi-factor authentication process is required for the server, for example, usually verifying against an email address or text messaging against a mobile number. However, these are not secure factors. To authenticate a user more reliably, in the preferred embodiment, the present disclosure uses a factor of “the peer you know” to perform peer-based authentication to authenticate a user.

Illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, a method is illustrated of setting up the authentication factor by using a recovery peer for the purpose of recovering account.

At step <b>705</b>, User <b>1</b> picks User <b>2</b> as a recovery peer and obtains User <b>2</b>'s public key k₂.

At step <b>710</b>, User <b>1</b>'s device freshly generates a random value R locally and at step <b>715</b>, User <b>1</b>'s device signs R with User <b>1</b>'s master private key K₁<b>125</b> and produces a signature of Sig.

At step <b>720</b>, User <b>1</b>'s device encrypts Sig with k₂<b>140</b> and outputs encrypted signature Sig_k2. It's to be understood that User <b>1</b>'s device may also encrypt Sig with a shared symmetric key associated with User <b>1</b>'s and User <b>2</b>'s public keys k₁and k₂, for example, based on ECIES. In some embodiment, User <b>1</b>'s device may encrypt Sig with a symmetric key of User <b>2</b>, which is accessible to User <b>1</b>.

At step <b>725</b>, User <b>1</b>'s device sends and stores the random value R and the encrypted signature Sig_k2in the server computer <b>115</b>.

At step <b>730</b>, User <b>1</b>'s device deletes the random value R, the signature Sig of R and the encrypted signature Sig_k2locally.

Because the random value R is freshly generated locally, the signature Sig produced by K₁is a secret only known to User <b>1</b> device. By deleting the signature Sig, there is no one but User <b>1</b> and User <b>2</b> can produce signature Sig again. For server computer <b>115</b>, even though it has the random value R the server does not have the master key K₁, and therefore cannot produce Sig. Instead, it can verify Sig with the stored public key k₁. When User <b>1</b> loses the master private key K₁, User <b>1</b> can no longer produce Sig to prove to be the owner of the account. Therefore, User <b>1</b> has to ask User <b>2</b> to reproduce Sig and associate with User <b>1</b> back to the account associated with Sig.

In a preferred embodiment, process <b>700</b> and process <b>300</b> can be used in conjunction such that when User <b>1</b> picks a recovery peer, both process <b>700</b> and <b>300</b> are carried out at the same time. In this embodiment, a user performs a single check to pick a recovery peer. The user can obtain the functionalities of recovering both master private key and account at the same time.

It's understood that User <b>1</b> may pick more than one account recovery peer and the account recovery policy may require more than one such peer-based authentication.

<figref idref="DRAWINGS">FIG. 8</figref> illustrates process <b>800</b> to perform authentication against the server with the factor of “the peer you know” which allows User <b>1</b> to recover his/her account, after process <b>700</b> has been carried out. In the case of User <b>1</b> losing the account because of forgetting password and losing the master private key, in a preferred embodiment, User <b>1</b> may carry out a first authentication using some factor known in the art such as an email associated with the account previously stored in the server computer. An additional authentication then is carried out using the factor “the peer you know” described in the process <b>800</b>.

At step <b>805</b>, User <b>1</b> device generates a new pair of private key N₁and public key n₁locally.

At step <b>810</b>, User <b>1</b> device sends n₁to server computer and requests to authenticate against the lost User <b>1</b> account as well as k₁associated to this account in order to recover this account.

At step <b>815</b>, once receiving n₁and the account recovery request, server computer associates n₁with Sig_k2and allows both to be retrieved by User <b>2</b>.

At step <b>820</b>, User <b>1</b> initiates an out-of-band exchange with User <b>2</b> to request User <b>2</b> to help authenticate User <b>1</b> against the server computer. In a preferred embodiment, such an out-of-band exchange could be in a form of in-person meeting, live phone/video conversation or some secure communication such that User <b>2</b> can authenticate User <b>1</b> with high probability. It is to be understood that having User <b>1</b> to initiate an exchange with User <b>2</b> is also important for improving security, because User <b>1</b> must remember that User <b>2</b> has been chosen as an account recovery peer previously and that User <b>2</b>'s out-of-band contact information.

At step <b>825</b>, after User <b>2</b> successfully authenticated User <b>1</b>, User <b>2</b> operates User <b>2</b> device to retrieve Sig_k2and n₁from server computer.

At step <b>830</b>, User <b>2</b> device obtains Sig by decrypting Sig_k2with K₂.

At step <b>835</b>, User <b>2</b> device obtains Sig<b>2</b> by signing n₁with K₂. By signing n₁with K₂, User <b>2</b> provides a proof of authentication that User <b>1</b> associates with n₁and Sig. In some embodiments, User <b>2</b> device may obtain Sig<b>2</b> by signing n₁and Sig together. It's to be understood that when exchanging n₁, a verification of n₁may be performed using any approach known in the art to verify a public key, such as verifying a fingerprint of the public key or a signature, via an out-of-band channel. Such measure is to detect man-in-the-middle attack.

At step <b>840</b>, User <b>2</b> device sends Sig and Sig<b>2</b> to server computer.

At step <b>845</b>, after receiving Sig and Sig<b>2</b>, the server computer may verify Sig using the previously stored R and k₁; as well as verify Sig<b>2</b> by using n₁and k₂.

At step <b>850</b>, if both verifications are successful, server computer now has a proof with high confidence that n₁is from User <b>1</b> because User <b>2</b> released Sig only after authenticating User <b>1</b> and verifying n₁and that n₁is associated with User <b>1</b>. Thus server computer now authenticates User <b>1</b> and associates n₁with User <b>1</b> account.

At step <b>855</b>, User <b>1</b> device receives the signal that User <b>1</b> has been authenticated successfully.

It's to be understood that process <b>800</b> and process <b>500</b> can also be used in conjunction. In a preferred embodiment, after successfully authenticated, User <b>1</b> device might use the N₁and n₁as the new master key pair. In this case, step <b>505</b> in process <b>500</b> can be skipped.

In a preferred embodiment, when User <b>1</b> loses the master private key and request private key recovery, process <b>800</b> is not necessary because in process <b>400</b>, the public key verification between User <b>1</b> and User <b>2</b> when exchanging each other's public key allows User <b>2</b> authenticate User <b>1</b> at the same time.

In a preferred embodiment, after successful multi-factor authentication, including at least one peer-based authentication, a user can recover his/her lost account. It's obvious to those skilled in the art that such a “the peer you know” authentication factor may be used as sole authentication factor or in conjunction with other authentication factors. It's to be understood that once used, the relevancy of a previous Sig generated by the original master private key is reduced because User <b>1</b> has a new pair of master private and public key. In a preferred embodiment, User <b>1</b> may be recommended to pick recovery peers again.

Those skilled in the art will appreciate that the present disclosure makes use of the human authentication and cryptographic property to allow a user to recover his/her account, which has previously established recovery relationship with a peer. Human based authentication is a highly reliable way to authenticate a person in particular in a context of social relationship. If a user chooses familiar and trusted people, such as friends, as recovery peers, the likelihood of an attacker taking over his/her account can be significantly reduced. Using such a peer-based authentication factor, or using social groups by helping and authenticating each other, thus can protect user account better and improve user account security in a network environment. In addition, by allowing a user to choose peers to recover their own accounts, there is no need to depend on centralized user account management. Thus such a social-based security network can be quite self-sufficient.

While the exemplary embodiments have been described herein, it is to be understood that the invention is not limited to the disclosed embodiments. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims, and scope of the claims is to be accorded an interpretation that encompasses all such modifications and equivalent structures and functions.