Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
  • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords

Definitions

• TITLE SYSTEM AND METHOD FOR SECURE DEPOSIT AND RECOVERY OF SECRET
• 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.
• 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.
• RDBMS relational database management systems
• 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.
• conventional access control system cannot function.
• user data are typically distributed across multiple different and independent web sites or services. Therefore such a conventional access control system cannot function.
• Cryptography systems have intrinsic access control properties in a distributed setting such as the internet.
• Teen 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.
• client-based end-to-end cryptography systems such as PGP and SMIME, offer strong data security assurance for end users.
• 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 US 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..
• a social-based cryptographic system 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.
• 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.
• a method for depositing a secret data of a user account in a cryptographic system to allow for secure recovery of the secret data 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.
• 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.
• 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.
• 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.
• 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.
• the recovery peer and the user account can have mutually consented to provide secure recovery to one or each other.
• 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.
• the twice-encrypted secret data can be cryptographically signing with an identity key associated with the user account.
• the secret data can be a private key corresponding to a public/private key pair associated with the user account.
• a method for securely recovering a secret data of a user account in a cryptographic system that has been securely deposited 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.
• 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.
• 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
• 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.
• 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.
• 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.
• a method of securely recovering a user account without a password using peer-based authentication of ownership of the user account 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.
• 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.
• the recovery key can be a symmetric key.
• 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.
• 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.
• a method of decoupling a password from secret data secured with the password 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.
• Figure 1 is a schematic diagram of a social network-based cryptographic system for providing encryption-based access control and secure recovery of secret data
• Figure 2 is a flowchart diagram of a method for enforcing access control in the social network-based cryptographic system of FIG. 1 ;
• Figure 3 is a flowchart diagram of a method for depositing secret data to allow for secure recovery using a recovery peer
• Figure 4 is a flowchart diagram of a method for securely recovering secret data using a recovery peer device
• Figure 5 is a flowchart diagram of a method for securely recovering a shared secret between a user and a recovery peer
• Figure 6 is a flowchart diagram of a method for securely sharing data between peers
• Figure 7 is a flowchart diagram of a method for setting up a peer-based account recovery
• Figure 8 is a flowchart diagram of a method for a peer-based authentication and account recovery.
• FIG. 1 a block diagram illustrates an exemplary environment 100 having a first client device 105 of User 1 , a second client device 110 of User 2 coupled to a data communication network 102, such as the internet, for example, with a server computer 1 15 and a service 120.
• a data communication network 102 such as the internet, for example, with a server computer 1 15 and a service 120.
• Client devices 105 and 110, server computer 1 15 and service 120 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 102.
• Devices 105 and 110 can be a mobile phone, a tablet, a wearable device, a computer or any other kind of computing device.
• User 1 device 105 is a client device
• User 1 can register a user account using an identifier and an authentication token, such as a passphrase, for example, with server 1 15.
• the identifier can be a unique and arbitrary string or any other unique identifier, such as an email address, for example.
• a passphrase an authentication token
• the term "user account' is used generically to associate a user of the system and can include physical persons or devices as users.
• an autonomous device or device in the Internet-of-Things can also have a user account with server 1 15.
• the client device Once the user account is created, the client device generates a private/public key pair of private key Ki 125 and public key ki 130 as master keys.
• keys 125 and 130 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.
• ECC Elliptic Curve Cryptography
• User 1 device 105 further generates a server key Si 160.
• User 1 device 105 can then deposit public key ki 30, and clear-text server key Si 160 into User 1 account stored on server 1 15, preferably via a secure communication mechanism, such as SSL TLS, for example, or any other means of secure communication.
• server key Si 160 can be generated at server computer 115 associated with User 1 account. In these embodiments, server key Si 160 is transferred to device 105 via secure communication.
• server key Si 160 can be encrypted by a key derived from the authentication token and stored locally in device 105, in addition to a copy of the server key Si 160 being stored in the server computer 115.
• User 1 is required to present the passphrase to decrypt the local server key Si 160 or login to User 1 's account on server 1 15 to retrieve server key Si 160.
• User 1 Device 105 encrypts master private key 125 with server key 160 via a symmetric encryption algorithm.
• Device 105 outputs cipher Kisi 190 and stores cipher Kisi 190 locally on device 105 along with public key ki 130.
• 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 105 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.
• 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.
• 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.
• 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.
• device 105 can additionally output and store another cipher locally by encrypting master private key 125 with a derived key based on User 1 account passphrase.
• User 1 's account passphrase can be enhanced by a password-based key derivation function such as PBKDF2, bcrypt or scrypt.
• PBKDF2 password-based key derivation function
• salt ai and a sufficiently large iteration count can be used to derive a strong passphrase, which is stored in server 115 for authentication purpose.
• Salt ai can be generated by the client device process during key generation.
• User 1 's account identifier can be signed by User 1 's master private key 130. The signature can then be deposited into User 1 's account on server 115.
• master private key K 2 135 is generated, encrypted with generated random server key S 2 , and stored locally in device 1 10 along with generated master pubic key k 2 140.
• Public key 140, generated random salts a 2 and b2 and server key S 2 can all be deposited in registered User 2 account in server 1 15 via a secure communication channel. It's to be understood that User 2 could be a secondary account of a same physical user.
• User 1 can look up User 2 with necessary contact information or identifier, such as User 2's email address, and initiate a request of exchanging encrypted data with User 2. If User 2 accepts and authorizes the request, User 1 and 2 are allowed to exchange both master public keys ki 130 and k 2 140 with each device. Otherwise, User 1 and 2 will not be allowed to have each other's public keys. In some embodiments, User 1 and 2 can verify associated fingerprints of the public keys or digital signatures signed by each other's master private key when exchanging public keys. [0045] 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.
• necessary contact information or identifier such as User 2's email address
• User 1 device 105 can initiate a process 200 illustrated in Figure 2.
• device 105 will generate a session key S, then at step 210 encrypt the data D with the session key S (preferably using AES-256 in CTR mode) and output cipher Ds 155.
• device 105 can first compress data D, then encrypt the compressed data D and output cipher Ds 1 15.
• the session key can be a random key. In other embodiments, the session key can be generated based on data D.
• session key S could be a hash value of a file when data D is a file and service 120 is a cloud storage service.
• Data D authenticity and integrity checking and non-repudiation may or may not add to cipher Ds 155.
• device 105 can generate a digital signature for data D using User 1 's master private key and associates to cipher 155.
• Device 105 can also generate an index I 165 associated to cipher 155.
• the index can be inserted into cipher 155.
• the index can be derived from cipher 155.
• device 105 will encrypt the session key S with its own public key ki and at step 220 deposit output cipher Ski 175 and index I 165 into the account in server 1 15 associated with User 1.
• User 1 Device 105 can also retrieve User 2's public key k2 according to User 2's identifier, such as an email address, and at step 230 encrypt the session key S with User 2's public key k2.
• device 105 deposits the output cipher Sk2 185 and the associated index I 165 into User 2's account at server 1 15.
• User 1 Device 105 sends Ds to service 120.
• device 105 can store a copy of server key encrypted by a key derived from User 1's account passphrase.
• a key derived from User 1's account passphrase During normal operation, when User 1 logs into server 1 15 by using an account identifier and a passphrase, User 1 Device 105 can derive a key based on the input passphrase and obtain server key Si. With server key Si, device 105 can decrypts cipher Kisi to obtain master private key Ki and store it in the device memory for normal operation.
• User 2 device 1 10 can receive or retrieve cipher D s 185 from service 120, such as an email from a webmail provider, for example.
• Device 110 will also retrieve cipher Sk2 180 from server 115, decrypt cipher 180 with User 2 private key K2 and obtain session key S 145 locally at User Device 2. Finally with session key S 145, it decrypts cipher D s 155 and obtains data D 150 locally.
• device 110 can further uncompress the obtained data after decryption to obtain data D 150.
• User 2 device 1 10 can also validate the digital signature of data D using User 1 's master public key.
• User 1 needs to revoke User 2's access to cipher 155, after sending out the private email, or cipher Ds 155 to service 120, User 1 can look up and remove cipher Sk2 180 from User 2's account stored on server 115.
• User 1 In the case that User 2 has not yet registered an account in the server 1 15. User 1 can still first exchange data with User 2 before any public key exchange takes place, then at a later time grant additional access right to User 2, after User 2 registers an account in server 1 15 and performs the public key exchange. In this case, User 1 can first carry out steps 205, 210, 215, 220 and 240. Later, once User 2 has registered an account and a user-authorized handshake took place, User can 1 can perform the process illustrated in Figure 6 to grant the access right to User 2.
• device 105 retrieves cipher Ski 175, at step 610, obtains session key S 145 by decrypting cipher 175 with key Ki 125, after obtaining public key k2 140 at step 615, encrypts session key 145 with public key 140, outputs cipher Sk2 180 locally at step 620. Finally device 105 deposits cipher 180 into User 2's account in server 115 at step 625.
• data D is not limited to be email. It could be any type of files, text and media based on applications.
• Service 120 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 155.
• Service 120 could be any destination service or intermediate service. Service 120 might or might not have its own access control mechanism. It should also be understood that service 120 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.
• Device 105 can first retrieve cipher 175 and the associated index I 165, decrypt cipher 175 with private key 125 to obtain session key S 145, then encrypt session key S 145 with the public key of the extra user and deposits output cipher and the index 165 into the extra user's account in the server.
• User 1 In the case User 1 needs to recover the master private key when the local master private key is lost, for example by losing device 105, User 1 can pick one or more users with whom User 1 has completed handshakes and store the master private key securely in the server computer. In a preferred embodiment, at the same time, User 1 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 700 and 800.
• FIG. 3 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 125 of User 1 but any other type of secret data, such as passwords or a file, for example, can be recovered using this method.
• the server 115 is also referred to as the recovery server as it assists with the secret data recovery.
• process 300 is a process for storing secret digital data securely using recovery peers.
• User 1 pick User 2 as a recovery peer and obtains a recovery-peer key from User 2.
• User 2's public key k2 corresponding to User's 2 private key K2.
• User 1 also derives an encryption key based on a secret provided to the user device to generate a derived encryption key.
• a passphrase P1 can be input by User 1 as the secret for deriving a key ⁇ .
• 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 1 account.
• a key ⁇ is derived from Pi using a password-based key derivation function, such as function PBKDF2 with salt bi and a sufficiently large iteration count ci.
• another key Li can be further derived from derived key ⁇ by combining with server key Si.
• 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 1 15.
• the combining operation can be an XOR operation.
• device 105 encrypts the secret data, or the master private key Ki 125, with derived key Li and outputs cipher KI LL
• device 105 further encrypts cipher Km with the recovery-peer key, (e.g. public key k ⁇ ) and outputs cipher K ik2 locally.
• device 105 stores cipher Kiu k2 at a location remote from User Device 105, such as in recovery server 115 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.
• the secret data, Ki can be first encrypted with a derived key from a passphrase, then encrypted with server key Si before being encrypted with User 2's public key k2.
• Ki can be first encrypted with server key Si , then encrypted with a derived key from a passphrase before being encrypted with User 2's public key k ⁇ . It is to be understood that the re-encryption is not limited to using User 2's public key.
• the re-encryption is done using User 2's symmetric key accessible by User 1 .
• User 1 's device can use a symmetric key to encrypt Km then transfer and store the symmetric key in User 2's device via secure communication means.
• the derived encryption key, Li can be generated by combining ⁇ , Si and the shared symmetric key of User 2.
• K i is generated by encrypting with Li and stored in server.
• User 1 's device can use a shared symmetric key associated with the public keys of User 1 and User 2 to obtain Kiu , for example, based on Elliptic Curve Integrated Encryption Scheme (ECIES).
• ECIES Elliptic Curve Integrated Encryption Scheme
• device 1 05 can initiate a master private key recovery process illustrated in Figure 4.
• step 405 device 105 generates a pair of private key Ti and public key ti, then at step 410 sends public key ti to server.
• server 1 1 5 receives ti and signals User 2 device 1 10 to help recover private key for User 1 .
• device 110 receives public key ti and cipher iuk2 1 85.
• the cipher Kiuk2 1 85 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.
• an out-of-band communication can refer to any communication between User 1 and User 2 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 1 to User 2.
• Such verification can detect a potential man-in-the-middle attack.
• device 1 10 decrypts KILIK2 with the recovery-peer key of User 2 (e.g. private key K2) and obtains cipher KI LL
• device 1 10 can obtains cipher Kiu by using a symmetric key.
• device 1 10 encrypts cipher Kiu with public key ti and output cipher Kiuti.
• device 1 10 sends cipher Kiuti to recovery server 1 15.
• recovery server 1 15 receives cipher Kiuti and notifies device 105.
• device 105 receives cipher Kiuti, and at step 450 decrypts it with private key Ti and obtains cipher KI LL
• device 105 derives an encryption key based on a secret provided to User Device 1 (e.g. a passphrase or biometric) and a shared secret with the recovery server 1 15.
• device 105 derives key ⁇ from passphrase Pi using the same password-based key derivation function with the same parameters as used in step 310 to deposit the secret data for secure recovery.
• passphrase Pi can be read from the memory location where Pi is stored after being input by User 1 during log in. In other embodiments, passphrase Pi can be being input by User 1 explicitly.
• device 105 further derives key Li by combining ⁇ and retrieved server key Si .
• the combining operation is identical to the one at step 315.
• device 105 decrypts cipher Kiu with key Li and obtains master private key Ki .
• device 105 can destroy private key Ti and public ti .
• the recovered digital data could be any digital data other than the master private key Ki . It could be also any types of files including, but not limited to, documents, images, binaries, hard drive images and backup files.
• the master private key Ki can be encrypted with more than one recovery peers' public keys.
• step 505 device 105 generates a new pair of master private key Ni and master public key .
• step 510 device 105 stores public key m to server 1 15.
• server 1 5 receives public key ni and signal of restoring data access.
• Server 1 5 identifies all users with whom User 1 share data and signal found users, User 2 in this example.
• User 2 device 1 10 receives a signal from server 1 15 and retrieves new public key ni .
• device 1 10 retrieves cipher, Sk2, whose key is shared secrecy with public key ki and k ⁇ .
• device 1 10 decrypts Sk2 with master private key K2 and obtain session key S.
• device 110 encrypts S with new public key m and outputs cipher Sni.
• device 1 10 stores cipher S n i in server 115.
• server 1 15 receives and store cipher Sm and signals User 1 that the recovery process by User 2 is completed.
• step 550 device 105 receives signal of completion and ready to access recovered data with new master private key Ni .
• a passphrase reset can be initiated.
• User 1 should first be authenticated with one or more factors.
• User 1 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.
• device 105 can retrieve server key Si from server 115 and decrypt cipher Kisi to obtain Ki.
• Device 105 thus can replace the local encrypted copy of server key Si cipher Kisi by encrypting SKI with the new passphrase, in a preferred embodiment, as well as replace cipher Ki uk2 by initiating the peer-based recovery illustrated in block diagram 300, using the new passphrase.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the key escrow can be in a compatible format of PGP, SMIME or other standards.
• 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.
• the master private key stored in the first device is transferred to the second device securely.
• 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.
• the first device and the second device can communicate directly with each other.
• the master private key will be used to access the data of the user account.
• 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.
• any password reset, key recovery and data recovery will trigger a notification to all devices of the user account.
• session key S can be a private key whose public key is used to encrypt other data.
• the master private key could be encrypted with a symmetric key.
• the encrypted master private key can be stored in the server computer.
• FIG. 7 Illustrated in Figure 7, a method is illustrated of setting up the authentication factor by using a recovery peer for the purpose of recovering account.
• step 705 User 1 picks User 2 as a recovery peer and obtains User 2's public key k2.
• User 1 's device freshly generates a random value R locally and at step 715, User 1 's device signs R with User 1's master private key Ki 125 and produces a signature of Sig.
• User 1 's device encrypts Sig with k ⁇ 140 and outputs encrypted signature Sigi ⁇ 2. It's to be understood that User 1 's device may also encrypt Sig with a shared symmetric key associated with User 1 's and User 2's public keys ki and k2, for example, based on ECIES. In some embodiment, User 1 's device may encrypt Sig with a symmetric key of User 2, which is accessible to User 1.
• User 1 's device sends and stores the random value R and the encrypted signature Sigk2 in the server computer 1 15.
• the signature Sig produced by Ki is a secret only known to User 1 device. By deleting the signature Sig, there is no one but User 1 and User 2 can produce signature Sig again.
• server computer 115 even though it has the random value R the server does not have the master key Ki, and therefore cannot produce Sig. Instead, it can verify Sig with the stored public key ki.
• User 1 loses the master private key Ki, User 1 can no longer produce Sig to prove to be the owner of the account. Therefore, User 1 has to ask User 2 to reproduce Sig and associate with User 1 back to the account associated with Sig.
• process 700 and process 300 can be used in conjunction such that when User 1 picks a recovery peer, both process 700 and 300 are carried out at the same time.
• 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.
• User 1 may pick more than one account recovery peer and the account recovery policy may require more than one such peer-based authentication.
• FIG 8 illustrates process 800 to perform authentication against the server with the factor of "the peer you know" which allows User 1 to recover his/her account, after process 700 has been carried out.
• User 1 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 800.
• User 1 device generates a new pair of private key Ni and public key ni locally.
• User 1 device sends m to server computer and requests to authenticate against the lost User 1 account as well as ki associated to this account in order to recover this account.
• server computer associates ni with Sigk2 and allows both to be retrieved by User 2.
• User 1 initiates an out-of-band exchange with User 2 to request User 2 to help authenticate User 1 against the server computer.
• 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 2 can authenticate User 1 with high probability. It is to be understood that having User 1 to initiate an exchange with User 2 is also important for improving security, because User 1 must remember that User 2 has been chosen as an account recovery peer previously and that User 2's out-of-band contact information.
• step 825 after User 2 successfully authenticated User 1 , User 2 operates User 2 device to retrieve Sigk2 and m from server computer.
• User 2 device obtains Sig by decrypting Sigk2 with K2.
• User 2 device obtains Sig2 by signing m with K2.
• By signing m with K2, User 2 provides a proof of authentication that User 1 associates with m and Sig.
• User 2 device may obtain Sig2 by signing m and Sig together. It's to be understood that when exchanging m, a verification of m 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.
• step 840 User 2 device sends Sig and Sig2 to server computer.
• the server computer may verify Sig using the previously stored R and k-i ; as well as verify Sig2 by using m and k2.
• server computer now has a proof with high confidence that m is from User 1 because User 2 released Sig only after authenticating User 1 and verifying m and that m is associated with User 1.
• server computer now authenticates User 1 and associates m with User 1 account.
• step 855 User 1 device receives the signal that User 1 has been authenticated successfully.
• process 800 and process 500 can also be used in conjunction.
• User 1 device might use the Ni and m as the new master key pair. In this case, step 505 in process 500 can be skipped.
• process 800 is not necessary because in process 400, the public key verification between User 1 and User 2 when exchanging each other's public key allows User 2 authenticate User 1 at the same time.
• 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 1 has a new pair of master private and public key. In a preferred embodiment, User 1 may be recommended to pick recovery peers again.
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computing Systems (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Storage Device Security (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (1)

Family

ID=54070724

Family Applications (1)

Country Status (4)

Cited By (7)

Families Citing this family (31)

Citations (7)

Family Cites Families (5)

• 2015
  • 2015-03-10 WO PCT/CA2015/000149 patent/WO2015135063A1/en active Application Filing
  • 2015-03-10 US US15/123,346 patent/US20170142082A1/en not_active Abandoned
  • 2015-03-10 CA CA2949847A patent/CA2949847A1/en not_active Abandoned
  • 2015-03-10 CN CN201580010720.9A patent/CN106104562B/zh active Active

Patent Citations (7)

Also Published As

Similar Documents

Legal Events