AU2019360160A1 - Authentication system - Google Patents

Authentication system Download PDF

Info

Publication number
AU2019360160A1
AU2019360160A1 AU2019360160A AU2019360160A AU2019360160A1 AU 2019360160 A1 AU2019360160 A1 AU 2019360160A1 AU 2019360160 A AU2019360160 A AU 2019360160A AU 2019360160 A AU2019360160 A AU 2019360160A AU 2019360160 A1 AU2019360160 A1 AU 2019360160A1
Authority
AU
Australia
Prior art keywords
user
server
card
private key
password
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
AU2019360160A
Inventor
Simon Brown
Steven Engel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lockbox Technologies Pty Ltd
Original Assignee
Lockbox Tech Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2018903954A external-priority patent/AU2018903954A0/en
Application filed by Lockbox Tech Pty Ltd filed Critical Lockbox Tech Pty Ltd
Publication of AU2019360160A1 publication Critical patent/AU2019360160A1/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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
    • 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/44—Program or device authentication
    • 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/602—Providing cryptographic facilities or services
    • 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
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • 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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • 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
    • 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
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2131—Lost password, e.g. recovery of lost or forgotten passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]

Abstract

A method, apparatus and systems are disclosed to control user access to digital items. Also disclosed is method, apparatus and systems which ensure secure storage and transmission of digital items within a system. Also disclosed is a password recovery methodology and apparatus.

Description

Authentication System
TECHNICAL FIELD
[0001] The present invention relates to an authentication system and more particularly to a document storage and access system for digital items and more particularly but not
exclusively such systems where it is desired to control user access to the digital items and to ensure secure storage and transmission of the digital items within the system.
BACKGROUND
[0002] A problem with centralized server systems which orchestrate access to documents is that they have a major security vulnerability if they store user passwords (or values derived from them) or the documents to which they orchestrate access. This is a major reason why servers are a target for hackers. Approaches to this issue include the following:
[0003] Enterprise digital rights management (e.g. Microsoft Office Rights Management) - however the systems do not have a storage platform which ensures that unprotected files cannot be uploaded. The systems do have a characteristic that
protected data cannot be disclosed unless the user has been expressly authorised to see it.
[0004] Zero knowledge storage (e.g. SpiderOak) . However, the systems provide only limited support for file sharing between users, and do not support partial item sharing (e.g. with or without annotation) and user delegation.
[0005] End to end messaging (e.g. Open Whisper Systems' Signal) systems. However, the systems do not have long-term storage model (rather than messaging) and typically cannot revoke a user's access once granted. They do not support user impersonation, nor support sharing outside of a closed system.
[0006] It is an object of the present invention to address or at least ameliorate some of the above disadvantages or provide a useful alternative.
NOTES
[0007] The term "comprising" (and grammatical variations thereof) is used in this specification in the inclusive sense of "having" or "including", and not in the exclusive sense of "consisting only of".
[0008] The above discussion of the prior art in the
Background of the invention, is not an admission that any information discussed therein is citable prior art or part of the common general knowledge of persons skilled in the art in any country.
SUMMARY OF INVENTION DEFINI TIONS
[0009] a "derivative" is a mathematical operation applied to a digital item so as to deterministically calculate a new result from the digital item. Examples include a hash of the digital item (including an iteratively repeated hash) or encryption of the digital item.
[0010] A "password" is a digital item associated with a user ID. Most usually the user ID is also a digital item such that the digital item is one digital item of a digital item hair which the proof of possession is required to effect authentication of the user ID on a digital device such that there is a level of trust that a login session on the digital device has been affected by was sponsored by that user
represented by the user ID.
[0011] According to one broad form of the invention there is provided with a system for secure access control and transmission of digital items; the system including at least one server and at least one client device; the server including at least one server processor in communication with a server memory; the server memory storing code for execution by the server processor; the at least one client device including at least one device processor in communication with a device memory; the device memory storing code for execution by the device processor; the system further including a recovery card having its own set of recovery card credentials; the apparatus utilised to effect password replacement for a user using the at least one client device to communicate with the at least one server;
a user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key; the device authenticated with the server using a device set of credentials including a device ID and device password and device private key and device public key;
the system reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a recovery card password, a recovery card private key and a recovery card public key;
the system associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
[0012] According to another broad form of the invention there is provided a system for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server; the system including at least one server and at least one client device; the server including at least one server processor in communication with a server memory; the server memory storing code for execution by the server processor; the at least one client device including at least one device processor in communication with a device memory; the device memory storing code for execution by the device processor; the user having at least for a given user login: a user ID, a user password, a user private key and a user public key;
the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivative of the user private key of the user against the user ID;
the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge; the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative;
if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
[0013] According to another broad form of the invention there is provided a system for secure access control and transmission of digital items in a client server environment wherein at least one server communicates with a plurality of participating user entities by means of participating digital devices in the form of digital communications devices in order to provide secure access control and transmission services for digital items created by, originated by or brought into the environment by ones of the plurality of participating user entities;
the server and the device executing steps whereby:
for each participating user entity participating in the environment ;
each participating user entity is authenticated as between the entity and the at least one server for that user entity in a participating user entity authentication step;
each participating digital device used by the participating user entity is authenticated as between the digital device and the at least one server for that user entity in a participating digital device authentication step;
and wherein each participating user entity has a participating user entity encryption key;
the steps further including:
a sending (source) user entity enabling secure access for a receiving (target) user entity of the plurality of user entities to a designated (unencrypted) digital item which is recorded as under the custody of the sending (source) user entity;
said sending (source) user entity encrypting the designated digital item or the user entity encrypting a key by which the designated digital item has been encrypted so as to produce an encrypted designated digital item or an encrypted digital item key preparatory to the sending user entity enabling secure access to the designated digital item by the receiving (target) user;
said sending (source) user entity utilising a sending (source) user entity digital device which has been authenticated as between the server and the sending (source) user entity thereby to enable the designated receiving (target) user entity to decrypt the designated digital item;
said sending user entity having a sending user entity encryption key;
said designated receiving user entity having a designated receiving user entity encryption key;
access to the designated digital item effected by the sending user entity encrypting the designated digital item so as to produce the encrypted designated digital item by utilising the designated receiving user entity encryption key to encrypt the designated digital item or access to the designated digital item effected by the sending user entity encrypting the document key of the designated digital item so as to produce the encrypted document key of the designated digital item by utilising the designated receiving user entity encryption key to encrypt the document key of the designated digital item.
[0014] Accordingly in another broad form of the invention there is provided a password recovery method utilising a recovery card, said method comprising:
in a first card generation step
executed on an off-line device;
for each card the off-line device generates a card private key and
a card password and
a card ID and
a card public key (derived from the card private key) ;
the off-line device then encrypts the card private key using the card password so as to generate an encrypted card private key;
the off-line device then embosses and/or prints on the card so as to be readable by a user the card ID and the card password; the system administrator may then upload to an online server (platform)
the card ID and
the encrypted card private key and
the card public key;
in a second user setup step the user utilises a device which has been authenticated to the online server; the user previously registered to the server whereby the server has a user record for the user comprising user ID; user public key; encrypted user private key;
the user indicates that they wish to register a card,
supplying the card ID from the card;
the device having the user ID, user password, user public key and user private key;
the device then transmits the card ID to the online server in order to receive the card public key for that card identified by that card ID from the server:
the device then encrypts the user private key against the card public key to generate a card encrypted user private key;
the device uploads the card encrypted user private key to the online server where it is referenced against a user record on the online server;
thereby to enable a (third) user password reset step before the user;
said reset step comprising
the user loads to the device the recovery card password and (associated with) the card ID;
the device receives from the online server the encrypted user private key and the encrypted card private key
the device decrypts the encrypted card private key by using the recovery card password provided to the device by the user so as to obtain a recovered card private key;
the device decrypts the card encrypted user private key by using the recovered card private key in order to thereby obtain a recovered user private key;
the device encrypts the recovered user private key against a new user password provided to the device by the user as part of the password reset step;
thereby to produce a new encrypted user private key;
the device uploads the new encrypted user private key to the online server whereby the new encrypted private key replaces the encrypted private key previously associated with their user record corresponding to their user ID.
[0015] In a further broad form of the invention there is provided in a client server system a method of password replacement for a user using a device to communicate with the server;
the user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key; the device authenticated with the server using a device a set of credentials including a device ID and device password and device private key and device public key; the method reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a recovery card password, a recovery card private key and a recovery card public key;
the method comprising associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
[0016] In yet a further broad form of the invention there is provided a method of secure access control and transmission of digital items in a client server environment wherein at least one server communicates with a plurality of
participating user entities by means of participating digital devices in the form of digital communications devices in order to provide secure access control and transmission services for digital items created by, originated by or brought into the environment by ones of the plurality of participating user entities ;
said method comprising:
for each participating user entity participating in the environment ;
authenticating the each participating user entity as between the entity and the at least one server for that user entity in a participating user entity authentication step;
authenticating each participating digital device used by the participating user entity as between the digital device and the at least one server for that user entity in a
participating digital device authentication step;
and wherein each participating user entity has a participating user entity encryption key;
said method comprising:
a sending (source) user entity enabling secure access for a receiving (target) user entity of the plurality of user entities to a designated (unencrypted) digital item which is recorded as under the custody of the sending (source) user entity;
said sending (source) user entity encrypting the designated digital item or the user entity encrypting a key by which the designated digital item has been encrypted so as to produce an encrypted designated digital item or an encrypted digital item key preparatory to the sending user entity enabling secure access to the designated digital item by the receiving
(target) user;
said sending (source) user entity utilising a sending (source) user entity digital device which has been authenticated as between the server and the sending (source) user entity thereby to enable the designated receiving (target) user entity to decrypt the designated digital item;
said sending user entity having a sending user entity
encryption key;
said designated receiving user entity having a designated receiving user entity encryption key;
access to the designated digital item effected by the sending user entity encrypting the designated digital item so as to produce the encrypted designated digital item by utilising the designated receiving user entity encryption key to encrypt the designated digital item or access to the designated digital item effected by the sending user entity encrypting the document key of the designated digital item so as to produce the encrypted document key of the designated digital item by utilising the designated receiving user entity encryption key to encrypt the document key of the designated digital item.
[0017] Preferably said sending user entity receives said designated receiving user entity encryption key from said at least one server.
[0018] Preferably the steps of encryption or decryption are executed on the participating digital devices.
[0019] Preferably each digital device is authenticated by the system before it can be used within the system.
[0020] Preferably parameters associated with each user entity are stored on the server preparatory to each user entity participating in the system.
[0021] Preferably parameters associated with each digital item are stored on the server preparatory to each user entity participating in the system.
[0022] Preferably the digital item is stored on the server in encrypted form. [0023] Preferably the digital item is stored on the server in encrypted form by reference to a document key.
[0024] In yet a further broad form of the invention there is provided a method of secure access control and transmission of digital items in a client server environment incorporating a first underlying methodology wherein servers forming part of the system never have enough information to decrypt the user entity content.
[0025] Preferably there is incorporated a second underlying methodology wherein all user entity content to which a user may have access is encrypted (directly or transitively) against their private key.
[0026] Preferably the servers forming the part of the system never see this key in an unencrypted form.
[0027] Preferably the servers store the key encrypted using a key derived from the user's password.
[0028] Preferably the servers forming part of the system never see the user's password (or any keys derived from it) .
[0029] Preferably the user's password is never sent to the servers, even in encrypted form.
[0030] Preferably the user's password is verified at the client device level by using the derivative of the user' s password to decrypt the user key.
[0031] Preferably systems implementing the method rely on an infrastructure which includes cryptographic keys.
[0032] Preferably cryptographic keys are associated with the various elements making up the systems.
[0033] Preferably cryptographic keys are associated with: Each entity or user participating in the system;
Each digital device used to participate in the system;
Each digital item stored or transmitted within the system. [0034] Preferably the cryptographic keys are utilised to encrypt and decrypt each digital item (typically a document) stored or transmitted within the system, and to determine which users may decrypt a digital item.
[0035] Preferably the method is further applied to a method for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server;
the user having at least for a given user login: a user ID, a user password, a user private key and a user public key;
the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivative of the user private key of the user against the user ID;
the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge;
the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative; if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
[0036] Preferably the comparison operation compares the user password supplied during the login attempt with the user password used to encrypt the user private key to generate the value stored on the server. [0037] Preferably the derivative of the user private key is an encryption of the private key encrypted against a value derived from the user password.
[0038] In yet a further broad form of the invention there is provided a method of secure access control and transmission of digital items in a client server environment as claimed in any previous claim further incorporating a password recovery method utilising a recovery card, said password recovery method comprising
in a first card generation step
executed on an off-line device;
for each card the off-line device generates a card private key and
a card password and
a card ID and
a card public key (derived from the card private key) ;
the off-line device then encrypts the card private key using the card password so as to generate an encrypted card private key;
the off-line device then embosses and/or prints on the card so as to be readable by a user the card ID and the card password; the system administrator may then upload to an online server (platform)
the card ID and
the encrypted card private key and
the card public key;
in a second user setup step the user utilises a device which has been authenticated to the online server;
the user previously registered to the server whereby the server has a user record for the user comprising user ID; user public key; encrypted user private key;
the user indicates that they wish to register a card,
supplying the card ID from the card;
the device having the user ID, user password, user public key and user private key;
the device then transmits the card ID to the online server in order to receive the card public key for that card identified by that card ID from the server:
the device then encrypts the user private key against the card public key to generate a card encrypted user private key; the device uploads the card encrypted user private key to the online server where it is referenced against a user record on the online server;
thereby to enable a (third) user password reset step before the user;
said reset step comprising
the user loads to the device the recovery card password and (associated with) the card ID;
the device receives from the online server the encrypted user private key and the encrypted card private key
the device decrypts the encrypted card private key by using the recovery card password provided to the device by the user so as to obtain a recovered card private key;
the device decrypts the card encrypted user private key by using the recovered card private key in order to thereby obtain a recovered user private key;
the device encrypts the recovered user private key against a new user password provided to the device by the user as part of the password reset step;
thereby to produce a new encrypted user private key;
the device uploads the new encrypted user private key to the online server whereby the new encrypted private key replaces the encrypted private key previously associated with their user record corresponding to their user ID.
[0039] In yet a further broad form of the invention there is provided a method of secure access control and transmission of digital items in a client server environment;
the method further including a method of password replacement for a user using a device to communicate with the server;
the user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key;
the device authenticated with the server using a device a set of credentials including a device ID and device password and device private key and device public key;
the method reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a recovery card password, a recovery card private key and a recovery card public key;
the method comprising associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
[0040] In yet a further broad form of the invention there is provided a client server environment operating according to the method as described above.
[0041] In yet a further broad form of the invention there is provided method for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server;
the user having at least for a given user login: a user ID, a user password, a user private key and a user public key;
the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivative of the user private key of the user against the user ID;
the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge;
the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative; if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
[0042] Preferably, the comparison operation compares the user password supplied during the login attempt with the user password used to encrypt the user private key to generate the value stored on the server.
[0043] Preferably, the derivative of the user private key is an encryption of the private key encrypted against a value derived from the user password.
[0044] In yet a further broad form of the invention there is provided a client server environment operating according to the method of any previous claim.
[0045] In yet a further broad form of the invention there is provided a device operating according to the method as described above.
[0046] In yet a further broad form of the invention there is provided a digital item secured according to the method as described above.
[0047] In yet a further broad form of the invention there is provided media containing code which when executed by a processor performs the method as described above.
[0048] In yet a further broad form of the invention there is provided a recovery card marked with indicia and operable according to the method as described above.
BRIEF DESCRIPTION OF DRAWINGS
[0049] Embodiments of the present invention will now be described with reference to the accompanying drawings wherein:
[0050] Figure 1A is a block schematic diagram of an initial authentication procedure for authenticating a user entity in order that the client entity may participate in the system of the present invention.
[0051] Figure IB is a block schematic diagram of an initial authentication procedure for authenticating a client device in order that the client device may participate in the system of the present invention.
[0052] Figure 2 is a logic flowchart of a preferred method of authenticating the client device of figure IB. [0053] Figure 3A is a block schematic diagram of a first part of a recovery card procedure and system according to an embodiment of the present invention
[0054] Figure 3B is a block schematic diagram of a second part of a recovery card procedure and system according to an embodiment of the present invention,
[0055] Figure 4 is a block schematic diagram of a third part of a recovery card procedure and system according to an embodiment of the present invention,
[0056] Figure 5A is a flowchart of a recovery card
generation procedure according to an embodiment of the present invention,
[0057] Figure 5B is a flowchart of the setup procedure for associating a card with a user record in accordance with an embodiment of the present invention,
[0058] Figure 5C is a flowchart of a reset procedure for re-encrypting a user key against a new password in accordance with an embodiment of the present invention.
[0059] Figure 6 is a block schematic diagram of a user entity password authentication according to an embodiment of the present invention and without server knowledge of user entity password or derivative thereof.
[0060] Figure 7 is a block schematic diagram of a user password reset procedure according to an embodiment of the present invention.
[0061] Figure 8A is a logic flowchart of a set up procedure for the password reset procedure of figure 4.
[0062] Figure 8B is a logic flowchart of the password reset procedure of figure 7.
[0063] Figure 9A is a block schematic diagram of an
embodiment of an access and security control infrastructure within which embodiments of the present invention operate. [0064] Figure 9B is a block schematic diagram of an
embodiment of the access and security control infrastructure within which embodiments of the present invention operate.
[0065] Figure 10 is a logic flowchart of a preferred method of operation of the access and security control infrastructure of figure 9B .
[0066] Figure 11 is a system architecture block diagram of an example system to which the password recovery system of figures 3, 4, 5 and the user authentication system of figures 6,7,8 and access and security control infrastructure of the figures 9 and 10 may be applied.
DESCRIPTION OF EMBODIMENTS
Security Principles
[0067] A first underlying methodology is that servers forming part of the system never have enough information to decrypt the user entity content.
[0068] A second underlying methodology is that all user entity content to which a user may have access is encrypted (directly or transitively) against their private key. The servers forming the part of the system never see this key in an unencrypted form. In particular forms the servers store the key encrypted using a key derived from the user's password.
[0069] A third underlying methodology is that the servers forming part of the system never see the user's password (or any keys derived from it) . More generally the user's password is never sent to the servers, even in encrypted form. Again, more generally the user's password is verified at the client device level by using the derivative of the user' s password to decrypt the user key.
Cryptographic Keys
[0070] Systems implementing aspects of embodiments of the present invention rely on an infrastructure which includes cryptographic keys. More specifically, cryptographic keys are associated with the various elements making up the systems. Keys are associated with:
Each entity or user participating in the system;
Each digital device used to participate in the system; Each digital item stored or transmitted within the system.
[0071] These keys are utilised to encrypt and decrypt each digital item (typically a document) stored or transmitted within the system, and to determine which users may decrypt a digital item.
User and device authentication process
[0072] Figure 1A is a block schematic diagram of an initial authentication procedure for authenticating a user entity in order that the client entity may participate in the system of the present invention.
[0073] Figure IB is a block schematic diagram of an initial authentication procedure for authenticating a client device in order that the client device may participate in the system of the present invention.
[0074] Figure 2 is a logic flowchart of a preferred method of authenticating the client device of figure IB.
[0075] The above described infrastructure forms the basis for a document storage and access control system in accordance with embodiments of the invention as will be described
immediately below.
Password recovery using pseudonymous cryptographic keys.
[0076] Figure 3A is a block schematic diagram of a first part of a password recovery card procedure and system
according to an embodiment of the present invention
[0077] Figure 3B is a block schematic diagram of a second part of a recovery card procedure and system according to an embodiment of the present invention,
[0078] Figure 4 is a block schematic diagram of a third part of a recovery card procedure and system according to an embodiment of the present invention,
[0079] Figure 5A is a flowchart of a recovery card
generation procedure according to an embodiment of the present invention, [0080] Figure 5B is a flowchart of the setup procedure for associating a card with a user record in accordance with an embodiment of the present invention,
[0081] Figure 5C is a flowchart of a reset procedure for re-encrypting a user key against a new password in accordance with an embodiment of the present invention
[0082] Stated in summary form: This is the recovery card mechanism.
[0083] Password recovery is complex because you want to make it convenient for users to regain access if they forget their password, but without reducing the overall security of the scheme.
[0084] At the same time, it's important that we can't reset passwords ourselves, as that would undo our zero-knowledge promise, as if we can reset a customer password, we can then grant ourselves access.
[0085] We have therefore devised a password recovery system using pseudonymous cryptographic keys to ensure that a user can reset their password, but that our servers cannot.
[0086] In order to recover the user's password three pieces of information are required:
(1) The recovery card password, printed on the card; and
(2) The recovery card private key, encrypted against the recovery card password; and
(3) The user's private key, encrypted against the recovery card private key.
[0087] During normal operation, no one entity has all three pieces of information:
The recovery card generation system has the card
password and card private key, but not the user's private key. (Note that this system must be permanently isolated from any network in order to protect the security of the scheme.)
The Lockbox platform has the card private key
(encrypted, per 2) and the user's private key (encrypted, per 3), but not the recovery card password. The user has the recovery card password, but not the other two pieces of information.
[0088] Thus, if any one of those entities is compromised alone (e.g. if the recovery card is lost), the attacker cannot reset the customer password. Instead, a trusted device must be used to recover items (2) and (3) from the Lockbox Platform, and then the user provides (1) . This then provides access to the user's private key (using 1 to decrypt 2, and 2 to decrypt 3), allowing the device to set a new password by re-encrypting and uploading the user's private key to the Platform.
[0089] We have further enhanced the security of the scheme by making the recovery cards pseudonymous rather than
customised for a user; bulk distribution of generated cards to a customer for then distribution to their users makes it impractical for Lockbox staff to manipulate which recovery card is associated with a given user if the secrecy of the recovery card generation system was compromised.
[0090] The above described security card process and related password recovery system of embodiments of the present invention in relation to figures 3, 4, 5 may be utilised to advantage in combination with the user/password authentication system and the digital item access control systems referred to and described below:
User entity password authentication without server knowledge of password or derivative but allowing password reset
[0091] Figure 6 is a block schematic diagram of a user entity password authentication according to an embodiment of the present invention and without server knowledge of user entity password or derivative thereof.
[0092] Figure 7 is a block schematic diagram of a user password reset procedure according to an embodiment of the present invention.
[0093] Figure 8A is a logic flowchart of a set up procedure for the password reset procedure of figure 7.
[0094] Figure 8B is a logic flowchart of the password reset procedure of figure 7. [0095] The methodology reflected in figures 6,7,8A, 8B may be summarised as follows:
[0096] Legacy password authentication schemes work by storing the user's password in the server. When the user attempts to login, the server compares the supplied password to the stored one, and permit login on a match.
[0097] Modern password authentication schemes do not store the user' s password, but instead store something derived from the password that can't easily be turned back into the
password (e.g. a cryptographic hash of the password) . The server then uses the same operation to compute the derivative of the supplied password and compares the output to the stored value. While this is very strong, it still involves the storage of something derived from the password on the server which represents a vulnerability.
[0098] Our scheme does not store passwords or derivatives on the server. Instead, we use cryptographic keys to
authenticate the user. When the user account is created, the user's device creates a public-private cryptographic key. A copy of the private key is encrypted against a value derived from the user's password (a hash of it computed using the PBKDF#2 scheme), and uploaded to our server. The device also generates and stores a public and private key, stores the private key on itself and sends the public key to the server.
[0099] When the user logs into their account, the server requires either a device public key or a strong authentication event, before sending the encrypted user private key to the device. The user then supplies their password to the device and the device derives the value and uses that to decrypt the key. If that operation succeeds, the user has proven they know the correct password; the device then proves possession of the private key to the server, completing the login event.
[00100] We support password reset by allowing the (target) user to specify which other (source) users may reset their password. We then store a copy of the target user's private key encrypted against the source user's public key. This allows the source user to decrypt the user's private key and re-encrypt it against a new password, allowing the target user to login with that new password. Note that the trusted device or strong authentication requirement means that the source user cannot simply login as the target user unless they also have access to a trusted device and/or the target user's strong authentication mechanism.
[00101] The above described process with reference to figures 6,7,8 in relation to user authentication may be utilised to advantage in combination with a digital item access control system as to be described below.
Digital item access control system
[00102] The above described infrastructure forms the basis for the access control and transmission system in accordance with embodiments of the present invention. The system seeks to control access to digital items circulated within the system. The system also seeks to secure the items during transmission and storage. An item will typically be a document. However, the item may be any block of digital data in respect of which it is desired to control access and also to secure the item during transmission to provide the access and also during storage prior to and after transmission.
[00103] The concepts which underlie the access and control system include:
1. Zero knowledge storage concept:
[00104] The platform which orchestrates the storage and transmission of digital items at no stage has an unencrypted form of the digital item stored on it.
[00105] More particularly in preferred forms the platform never receives or stores private keys or keys used to encrypt items. In preferred forms the platform may store public keys - but in this instance only to facilitate encryption elsewhere in the system.
[00106] Also, in preferred forms encryption of digital items or keys is never done on the platform.
2. The 'push' concept in access controls:
[00107] The owner entity of a document or a digital item (or user entity with access rights to the document or digital item) has to 'push' (which is to say grant access or instigate transmission) to any other target entity or user which is seeking access to that document or digital item.
[00108] In preferred forms access involves receiving a key of the target entity or user which is then used by the owner entity to encrypt the document or digital item following which the thus encrypted document or digital item is stored within the platform and possibly transmitted to a device under the control of the target entity or user.
[00109] Transmission of the encrypted document or digital item may be by way of the platform.
[00110] In preferred forms the platform is implemented on a server. More preferably the server is a web-enabled server.
[00111] In no instance does the platform act as a target entity or user entity.
[00112] That is to say, the platform (most usually
implemented as a server) is not relied on to enforce the access controls to digital items. In preferred forms
cryptography enforces the access controls.
[00113] In preferred forms the steps of encryption and decryption in respect of cryptography are executed on digital devices .
[00114] In preferred forms each digital device is
authenticated by the system before it can be used within the system.
[00115] Figure 9A is a block schematic diagram of a first embodiment of the access and security control infrastructure within which embodiments of the present invention operate.
[00116] With reference to figure 9A there is disclosed a first preferred embodiment of a secure access control and transmission system 10.
[00117] More particularly, the system 10 comprises a digital environment in this instance in the form of a client server environment made up of at least one server 11 and at least a first client digital device 12 and a second client digital device 13.
[00118] The server 11 includes a memory 14 in communication with a processor 15 and in communication with a communication module 16.
[00119] First client digital device 12 includes a memory 17 in communication with a processor 18 and in communication with a communication module 19.
[00120] Second client digital device 13 includes a memory 20 in communication with a processor 21 and in communication with a communication module 22.
[00121] In preferred forms communication of data within this digital environment is by way of a packet switched network wherein each data packet 23 comprises an address portion 24 and a data portion 25.
[00122] In use if a second user in the form of target user 26 is to receive access to a first digital document 27 (the first digital document being under the control of a first user in the form of a source user 28) then a key [in this instance U2-KPub] associated with the target user 26 is caused by the second client digital device 13 (in its capacity as the target user client device) to be transmitted in this instance from server 11 to first client digital device 12 (in its capacity as the source user client device) . This key is used to encrypt the first digital document 27 following which the encrypted first digital document 27A is caused to be made available to the target user client device 13 in this instance via the digital environment including server 11.
[00123] Target user 26 may then cause the target user client device 13 to decrypt the encrypted first digital document 27A in order to obtain the first digital document 27 [in this instance using target user 2 private key U2-KPVT under the RSA encryption system] .
[00124] Figure 9B is a block schematic diagram of a second embodiment of the access and security control infrastructure within which embodiments of the present invention operate. [00125] In this instance access to the document is controlled by controlling access to a document key by which the document is encrypted.
[00126] Figure 10 is a logic flowchart of a preferred method of operation of the access and security control infrastructure of figure 9B .
[00127] In one form and more particularly with reference to figure 10 the steps in the above described process of figure 9B are :
[00128] The source user 28 decides to provide access to the first digital document 27 to the target user 26.
[00129] Source user 28 selects the first digital document 27 and clicks 'grant access' on the source user client device 12.
[00130] Source user client device 12 retrieves file metadata of the first digital document 27 and a key [in this instance public key U2-Kpub] associated with the target user 26 from the server 11.
[00131] Source user client device 12 decrypts the document key of the first digital document 27 using a private key [in this instance Ul-KpvT] associated with the source user 28.
[00132] Source user client device 12 then encrypts the document key of the first digital document 27 using the key U2-KPub associated with the target user 26 to generate a re encrypted document key for first digital document 27.
[00133] Source user client device 12 adds the user ID of the target user and the re-encrypted document key for the first digital document 27 into a data packet which is transmitted to the server and saved referenced against the first digital document 27 within the digital item (file) list.
[00134] The target user entity 26 may then cause the target user client device 13 to decrypt first digital document 27 by unencrypting the re-encrypted document key by use of the target user's private key U2-KpVT. [00135] By thereby having been granted access to first digital document 27 of source user 28 and as now reflected in the metadata stored on the server 11 the target user now has the capability to make the first digital document 27 available to other users within the environment utilising the same procedure .
Example 1
[00136] Figure 11 is a system architecture block diagram of an example system to which the password recovery system of figure is 3, 4, 5 and user authentication of figures 6, 7, 8 and access and security control infrastructure of the figures 9 and 10 may be applied.
[00137] Cryptographic enforcement of access controls with zero knowledge storage.
[00138] Cryptographic enforcement of access controls means that each user has an encryption key, and documents are
(transitively) encrypted against them. Users grant access to a document for other users by encrypting it against the other user's key, making it possible for the target user to decrypt it. That means that if the server isn't relied on to enforce the access controls to documents, as the cryptography enforces it instead.
[00139] Zero knowledge storage means that our servers store documents and supply them to users but cannot see inside the documents because they are encrypted. This is because the documents are encrypted (above) and our server is not granted access .
[00140] In preferred forms the keys are generated as summarised in the below table:
[00141] Device public and private keys (Kdevice) are
generated and stored on the device.
[00142] A user's public key, but not the private key
(Kuser) , is stored on the device.
[00143] When a device first authenticates it downloads and caches the user private key (in encrypted form) from the platform. This key is kept in RAM and never stored on the device .
[00144] For each user, the platform stores:
RSA (Kplatform, (AES (PBKDF#2 (users-password) , Kuser))
RSA (Kplatform, (AES (PBKDF#2 (users-password) , Kuser- sensitive) ) .
[00145] When the platform has authenticated a device and wants to send it the user's key, note that it returns:
RSA(Kdevice, (AES (PBKDF#2 (users-password) , Kuser))
New device for an existing user (e.g. adding a second iPad or replacement device)
[00146] If an existing user attempts to log into the
platform (termed 'Athena' in figure 5) on a new device (i.e.
We already know they have been logging in on other device (s)) the authentication is halted and the user is notified that the administrators must approve the device, unless; a) If the user has registered on another device of a specific type, then we send a push notification to that device with a generated authentication code or;
b) If a mobile phone number is on file for the user, a
secondary authentication code is generated and sent via SMS for
validation of the new device else;
c) If no phone number is available, all of the admins
associated with the user are notified and any of them can approve the login. Once approved a push notification is sent to the device advising the user they can login.
Keys on the Device
[00147] Kdevice public and private keys are generated and stored on the device.
[00148] Kuser' s public key, but not the private key, is stored on the device.
[00149] When a device first authenticates it downloads and caches Kuser (in encrypted form) from the platform. This key is kept in RAM and never stored on the device.
New user , new device
[00150] A user within an Athena organisation that has the 'user admin' permission creates a new user account, specifying username. They will also be required to enter the user's email and mobile number.
[00151] The Athena platform generates an initial password for the user, format will be "word-word-word-word" where word is a three to six-character common word in English, e.g.
"seeks-world-hop-strung" .
[00152] The Athena platform creates an entry in the newUsers table, with the AthenaOrganisationID, username,
PBKDF#2 (password) for the user, as well as the contact details if provided. The platform returns [AthenaOrganisationID, username, initial-password] to the portal, which returns them to the admin user.
[00153] The admin user provides these three attributes to the end user, along with information on how to download the Athena app . The portal will create a generated PDF that has the end user's username, initial password,
AthenaOrganisationID and detailed app installation and
download instructions. The content of the email will also include links to the appropriate app store download location. The email is, by default, emailed directly to the new user.
The email can be disabled by the admin user. If the admin user elects to disable the welcome email, the document is available for download or resend at any time.
[00154] The end user downloads the Athena app. On first run, it prompts the user for an Athena organisation ID, their username and their initial password. If it's a new device, it hasn't yet generated or registered a device ID.
[00155] The device generates a 2048-bit RSA key Kdevice, a 2048-bit RSA key Kuser, and a 256-bit AES key Kuser-sensitive . It also generates a UUID, device ID.
[00156] The device sends a request to the Athena platform via / Register, containing device ID.
[00157] The platform confirms that the proposed device ID is unique. If so, it returns the Kplatform public key to the device. The device then prompts the user to set a new
password, according to the current password complexity policy. It generates a new 256 bit AES key called KUserTransport, and then calculates
a. AES (KUserTransport, (AES (PBKDF#2 (users-password) , Kuser)) b. AES (KUserTransport, (AES (PBKDF#2 (users-password) ,
Kusersensitive ) )
c. RSA (KPlatform, KUserTransport) 9. The device then sends a user registration request to the platform, signed by the device key, containing:
a. devicelD;
b. (AthenaOrganisationID, username, RSA (Kplatform, initial- password) )
c. RSASign (Kdevice, (AES (KUserTransport, (AES (PBKDF#2 (new- password) , Kuser) ) , AES (KUserTransport, (AES (PBKDF#2 (new- password) , Kusersensitive)), RSA (KPlatform, UserTransport) ) .
[00158] The platform decrypts that blob, calculates
PBKDF#2 ( initial-password) , and verifies whether there is a row in newUsers that matches those details. (If not, return error message and fail out.) If so, it creates new records in the AthenaUsers table to reflect the user account, the
AthenaDevices table to reflect the device, and the
AthenaUsersDevices table to reflect that that device is associated with that user. It then returns a success message to the device.
[00159] The platform verifies the device key signature, and then stores the two encrypted passwords (still encrypted against Kplatform) and the encrypted KUserTransport in the user table.
[00160] The platform notifies the user by email and/or SMS that a new device has been registered to their Athena account, and to report immediately to their organisation' s
administrator if they don't recognise the activity. Depending on the Athena organisation's preferences, a notification to the user admin may also be required. All new device additions are logged and are reported to administrators at next login according to the alert preference set for the admin account.
New user on an exi sting device (e . g . adding a second board)
[00161] Essentially, the flow above, but initiated from the '+' tile on the Athena home page.
[00162] Flow therefore after step 5 (user admin sends password to user) jumps immediately to step 10 in section 3.7 ("The device then sends devicelD and (AthenaOrganisationID, username, RSA (Kplatform, password))").
[00163] For the web interface, a browser is a device, and subject to device registration on login. That means 2FA at login, and it then generates a Kdevice to use to receive and access the data. For the sake of user experience, we can save Kdevice in the local browser (local storage, rather than a cookie, preferably) so that the same user using the same browser doesn't need to go through the registration flow more than once in a blue moon. Each time the session times out, they'll need to re-enter their password. Not sure yet how often 2FA might be required, but less often than that.
[00164] Those Kdevice registrations for web browsers should probably timeout in the backend (30 days after last used?), to avoid the table blowing out if someone uses lots of different browsers. (That "expiring, temporary shadow user" feature we were talking about for international travel would also be useful for users' needing emergency access from an untrusted device, e.g. in a hotel business centre.)
New device for an existing user (e.g. adding a second
iPad or replacement device)
[00165] If an existing user attempts to log into Athena on a new device (i.e. We already know they have been logging in on other device (s)) the authentication is halted and the user is notified that the administrators must approve the device, unless ;
a) If the user has registered on another device (iPhone or Windows 10), then we send a push notification to that device with a generated authentication code or;
b) If a mobile phone number is on file for the user (we will strongly recommend that it is), a secondary authentication code is generated and sent via SMS for validation of the new device else;
c) If no phone number is available, all of the admins
associated with the user are notified and any of them can approve the login, once approved a push notification is sent to the device advising the user they can login.
[00166] This secondary validation of new devices is the default but can be disabled by admin. We will maintain a list of device hashes for each approved device.
Normal Authentication Flow - online
[00167] When a user on a device logs into Athena from a device that has a Kdevice:
1. The device submits its Athena UUID and the user's UUID to the login API .
2. The platform verifies that that device is associated with that user and, if so, generates a 256-bit random number called a nonce, and sends RSA (Kdevice, nonce) to the device.
3. The device decrypts the nonce, and returns SA (Kplatform, nonce) .
4. If the platform decrypts the same nonce as it sent to that device, the platform retrieves the encrypted user key from its data store and its associated AES key KUserTransport which has been encrypted by KPlatform, unwraps the outer RSA encryption on KUserTransport using Kplatform and re-encrypts it against KDevice. It then sends: a. AES (KUserTransport, AES (PBKDF#2 (user-password) ,
Kuser) )
b. AES (KUserTransport, AES (PBKDF#2 (user-password) , Kuser- sensitive
c. RSA(KDevice, KUserTransport)
5. The device decrypts KUserTransport using KDevice, then decrypts the outer AES layer using this decrypted key on the other properties.
6. The device prompts the user for their password, calculates PBKDF#2 (userpassword) , and then uses this to decrypt Kuser and Kuser-sensitive .
7. The device uses the recovered Kuser private key to create RSA (Kplatform, RSASign (Kuser, nonce)), and sends it to the platform.
8. The platform verifies the signature on the nonce using the user's public key, verifies that the nonce was the one sent to the device, and verifies that that device is associated with that user's account. If all those checks pass, the server creates a random session token (1024-bit random number?), creates an entry in the session table with that session token
, user UUID, device UUID, and other appropriate metadata (e.g. session start timestamp, session expiry timestamp) . It then returns session token to the device.
9. All requests from that device to any authenticated API endpoint include the session token. When each request is received, the platform checks that the session token is in the session table and has not expired; if so, it retrieves the session context. The platform also validates that the session token has access to the specified API, which may not be true even if the session token is valid.
[00168] We don't need to prompt for a username on login. The only times we need it is when we are adding a new device to a user or adding a new board/company association for an existing user. For the next version, I might suggest moving the offline verification code generation process 3.10 section. That way, every time we verify the password online, we create a new copy of the offline verification code, which should reduce the chance for a password mismatch around changes, but it
potentially adds some complexity/time to the online login process, so we might want to throttle it to just once a day. Normal Authentication Flow - offline
[00169] If the user attempts to use Athena when there is no internet connection the following is the flow. This will only work if they have authenticated at least once (they won't have any data if they haven't anyway) .
[00170] A nonce is generated on the device and used to securely store (keychain or equivalent) RSA(KDevice, nonce), AES (PBKDF#2 (user-password) , nonce) . This is stored only once and is created during the first successful online
authentication .
[00171] The nonce should only be used for offline
authentication (and nothing else) and must be regenerated every time the password changes.
Unsuccessful Authentication Flow
[00172] If there is an unsuccessful login attempt the Athena app will allow two subsequent attempts (i.e. 3 failed logins' in succession) and then delay subsequent login attempts by five minutes. If there is a second set of three failed
logins' , Athena will delete all app data (revert to an initial application state) .
[00173] All of the above actions are immediately logged and reported back to the Athena server. Each customer (secretariat or administrator) will be independently notified of the event via their selected notification method (email, SMS or PNS) .
User Information Recorded
[00174] For each user added to the system by a board
administrator we will require the following to be captured:
• First and Last name
• Email address
• Mobile phone number
• And, if a company employee a unique employee number.
User Password Reset
[00175] Should a user forget their password there will be a password reset mechanism.
[00176] On the login screen for the iOS and Win 10 apps to initiate password reset. This reset function will require the use of a plastic identity card with a serial number and an authentication code printed on the rear. This card will be sent by the customer (secretariat) to each Athena user on initial registration by the administrators (along with some spares) . The codes are for one use only. The customer, on receipt of their card(s) and while still remembering their password, registers the card(s) with their account through the app (details in 0 below) .
[00177] The process will be that the user taps on the reset password button and they are prompted to either scan the
QRCode (via the camera on the device) or enter the
authentication code.
[00178] Once the authentication code has been entered, immediate entry of a new password (of appropriate strength) will then be required. All admins will be alerted
[00179] of the password change according to the alert preferences set.
[00180] If a user has lost their card any of the admins associated with the can request a new card be sent to the user .
[00181] All other admins associated with the user will be alerted of the password change according to the alert
preferences set for that account.
[00182] When a card with an authentication code is used a notification is provided to Lockbox administration staff to assign and send a new card to the user.
Card generation process :
[00183] The system generates tuples of (card serial number, card password, card private RSA key, card public RSA key) . It exports card printing records of the form [ (card serial number, card password) ] .
[00184] It exports card upload records of the form [(card serial number, KCard-public, PKCS#8 (card-password, KCard) ) ] , which are uploaded to the platform. The card private keys are protected using a PKCS#8 format, with the private key
encrypted against the card-password using aesl28CBC scheme. Both the public key and private key are exported in PEM format . [00185] The platform then stores: card-serial-number:
(KCard-public, PKCS#8 ( cardpassword, Kcard) ) <-- that is, if someone has the card serial and password, they can access the private key. Else nobody can, not even the platform.
[00186] Card registration process: When a user receives a card, they can add it to their account. This is part of the initial registration flow for the user. When a user adds a card, it prompts just for the card serial number, entered twice for certainty, or via QR code. The app then asks the Athena platform for the card-public-key (Kcard-public)
associated with that card serial number. It also calculates new AES key called Ktransport and KCardWrap. The app then uses this to calculate: card-serial-number: ( RSA (KPlatform,
Ktransport), RSA(KCard, KCardWrap), AES (Ktransport,
AES (KCardWrap, (Kuser, Kuser-sensitive ) ) ) It then sends that to the platform.
[00187] The platform will then unwrap Ktransport, unwrap the data encrypted by these AES keys.
[00188] The platform then:
(i) confirms that that card is not issued to any other user .
(ii) updates the card record to reflect that the card has been issued to that user.
(iii) updates the user record in Lockbox to reflect the card's access by appending the data above.
The resulting Lockbox user record looks like: user-id:
(RSA (KPlatform, KUserTransport) ,
AES (KUserTransport (AES (PBKDF2 (password) , Kuser) ) ) ,
AES (KUserTransport (AES (PBKDF2 (password) , Kuser-sensitive) ) ) , [impersonator-user-id: RSA (KUser-impersonator, KUserTransport- impersonator ) , AES (KUserTransport, AES (KUserTransport- impersonator, Kuser)))], #users allowed to impersonate/reset [card-serial-number: RSA(KCard, KCardWrap),
AES (KUserTransport, AES (KCardWrap, (Kuser, Kuser-sensitive) ) ) ]
) and the Lockbox card record looks like: card-serial- number: ( KCard-public, PKCS#8 (card-password, KCard), [user- id]
[00189] Note that if the person is an Athena user, the Athena platform will also store: person-id: ([board-id: user- id] , [card-serial-number] ) This allows the Athena platform to automatically register a new board membership (and therefore a new Kuser) with the same card for password recovery.
[00190] Password recovery process with a card:
1. User chooses "Lost password".
2. User selects "I have my registered card".
3. App prompts for the card serial number and password (or QR code) .
4. App requests the encrypted card private key from the platform, supplying both its user-id and device-id.
5. Platform verifies that the both the user and the device are known, current and associated with each other. It then
retrieves three elements from the user record: RSA (KPlatform, KUserTransport) , RSA(KCard, KCardWrap) , AES (KUserTransport, AES (KCardWrap, (Kuser, Kuser-sensitive ) ) )
6. From the card record, the platform retrieves: PKCS#8 (card- password, KCard)
7. The platform then generates a new 256 bit AES key we will call Ktransport. It uses KPlatform to decrypt KUserTransport, and then uses KUserTransport to decrypt the last element above before re-encrypting it against Ktransport. It then returns to the device: RSA(KDevice, Ktransport), AES (Ktransport,
PKCS#8 (card-password, KCard)), RSA(KCard, KCardWrap),
AES (KCardWrap, (Kuser, Kuser-sensitive) ) ) ) ,
8. The app uses Kdevice to decrypt the payload, and then the card password to decrypt KCard, and then the card private key to decrypt Kuser.
9. The app prompts the user for a new password.
10. The app calculates a new 256 bit AES key KUserTransport and then calculates RSASign (KCard, ( user-id, card-serial- number, AES (KUserTransport ( PBKDF2 (password, Kuser))),
AES (KUserTransport (PBKDF2 (password, Kuser-sensitive) ) ) ) ,
RSA (KPlatform, KUserTransport) ), and sends that back to the platform, to update the user record.
11. The platform will verify that the card is associated with that user, verify the signature using KCard-Public, and update the user record.
12. The platform confirms the user record was updated. [For Athena, if the user has multiple memberships and therefore multiple Kuser records, the app repeats steps 4-12 for each of those Kuser' s with the same card key.] 13. The app tells the platform that the card has been used to recover everything required, and that the card should be invalidated .
14. The platform marks the card as used. Whilst the card has been marked as used it is still available for use for a 14-day period from that time. Once the 14 days has expired the card is marked as terminated and can no longer be used. When a card is used an automatic process is initiated to send a new card to the user.
15. The app notifies the user that they should immediately request a new card from one of their secretariats and register it in the app immediately once it arrives.
[00191] Password recovery process without a card:
User chooses "Lost password" .
User selects "I do not have a card or I have lost my card". Athena app prompts user to confirm that all annotations and any other "eyes only" content will be lost in the password reset; encourages user to look for their card and/or remember their password if they can. User confirms "I understand".
App sends a "password reset" request to Athena platform, which does a 2FA of the user to confirm it's not an attacker
attempting to reset the user's password. Then confirms request to the app, with a temporary session token (or equivalent) .
App then prompts user for a new password and calculates
PBKDF#2 (newpassword) .
App then does: i. for each board that the user is a member of, retrieve the secretariat generic user's Kuser's public key (which we'll call, for this piece, Ksecretariat) ; ii.
calculate RSA (Ksecretariat, PBKDF#2 (new-password) ) for each Ksecretariat; iii. sends the list of [(board-id),
RSA (Ksecretariat, PBKDF#2 (newpassword) ) ] to the platform, authenticated with the session token .
The platform then notifies each secretariat that a password change is required for that user. As each secretariat approves the change, their app uses their Kuser to decrypt the
Ksecretariat for the board and the Kuser for the target user. It uses these to decrypt the PBKDF#2 (new-password) , and reencrypt the Kuser for the target user to generate
RSA (Kplatform, AES (PBKDF#2 (new-password) , Kuser)) for the target user, and then lodge this as the new platform copy of the Kuser for the target user. [00192] As this happens for each board the user is a member of, their documents will become available again as they regain access to their Kuser records using their new password.
[00193] Broadly this means that if you have your password, you can register a new card. If you have a registered card, you can reset your password. If you have neither, you lose some super-sensitive data (annotations, notes and backups), and you have to have the secretariats you're associated with approve the reset. If you're only a member of one board, that's one reset approval. If you're a member of a dozen, then each approves it. That's necessary so that a secretariat at one board can't reset a user's credential and then see all of the other boards' content that that user has access to.
INDUSTRIAL APPLICABILI TY
[00194] Embodiments of the present invention operate to provide controlled and secure access to and transmission of digital items (which may be in the form of documents) as between entities or users of a system.

Claims (37)

1. A password recovery method utilising a recovery card, said method comprising
in a first card generation step
executed on an off-line device;
for each card the off-line device generates a card private key and
a card password and
a card ID and
a card public key (derived from the card private key) ;
the off-line device then encrypts the card private key using the card password so as to generate an encrypted card private key;
the off-line device then embosses and/or prints on the card so as to be readable by a user the card ID and the card password; the system administrator may then upload to an online server (platform)
the card ID and
the encrypted card private key and
the card public key;
in a second user setup step the user utilises a device which has been authenticated to the online server;
the user previously registered to the server whereby the server has a user record for the user comprising user ID; user public key; encrypted user private key;
the user indicates that they wish to register a card,
supplying the card ID from the card;
the device having the user ID, user password, user public key and user private key;
the device then transmits the card ID to the online server in order to receive the card public key for that card identified by that card ID from the server:
the device then encrypts the user private key against the card public key to generate a card encrypted user private key;
the device uploads the card encrypted user private key to the online server where it is referenced against a user record on the online server;
thereby to enable a (third) user password reset step before the user;
said reset step comprising
the user loads to the device the recovery card password and (associated with) the card ID; the device receives from the online server the encrypted user private key and the encrypted card private key
the device decrypts the encrypted card private key by using the recovery card password provided to the device by the user so as to obtain a recovered card private key;
the device decrypts the card encrypted user private key by using the recovered card private key in order to thereby obtain a recovered user private key;
the device encrypts the recovered user private key against a new user password provided to the device by the user as part of the password reset step;
thereby to produce a new encrypted user private key;
the device uploads the new encrypted user private key to the online server whereby the new encrypted private key replaces the encrypted private key previously associated with their user record corresponding to their user ID.
2. In a client server system a method of password
replacement for a user using a device to communicate with the server;
the user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key;
the device authenticated with the server using a device set of credentials including a device ID and device password and device private key and device public key;
the method reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a
recovery card password, a recovery card private key and a recovery card public key;
the method comprising associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
3. A method of secure access control and transmission of digital items in a client server environment wherein at least one server communicates with a plurality of participating user entities by means of participating digital devices in the form of digital communications devices in order to provide secure access control and transmission services for digital items created by, originated by or brought into the environment by ones of the plurality of participating user entities; said method comprising:
for each participating user entity participating in the environment ;
authenticating the each participating user entity as between the entity and the at least one server for that user entity in a participating user entity authentication step;
authenticating each participating digital device used by the participating user entity as between the digital device and the at least one server for that user entity in a
participating digital device authentication step;
and wherein each participating user entity has a participating user entity encryption key;
said method comprising:
a sending (source) user entity enabling secure access for a receiving (target) user entity of the plurality of user entities to a designated (unencrypted) digital item which is recorded as under the custody of the sending (source) user entity;
said sending (source) user entity encrypting the designated digital item or the user entity encrypting a key by which the designated digital item has been encrypted so as to produce an encrypted designated digital item or an encrypted digital item key preparatory to the sending user entity enabling secure access to the designated digital item by the receiving
(target) user;
said sending (source) user entity utilising a sending (source) user entity digital device which has been authenticated as between the server and the sending (source) user entity thereby to enable the designated receiving (target) user entity to decrypt the designated digital item;
said sending user entity having a sending user entity
encryption key;
said designated receiving user entity having a designated receiving user entity encryption key;
access to the designated digital item effected by the sending user entity encrypting the designated digital item so as to produce the encrypted designated digital item by utilising the designated receiving user entity encryption key to encrypt the designated digital item or access to the designated digital item effected by the sending user entity encrypting the document key of the designated digital item so as to produce the encrypted document key of the designated digital item by utilising the designated receiving user entity encryption key to encrypt the document key of the designated digital item.
4. The method of claim 3 wherein said sending user entity receives said designated receiving user entity encryption key from said at least one server.
5. The method of claim 3 or 4 wherein the steps of
encryption or decryption are executed on the participating digital devices.
6. The method of claim 3 or 4 or 5 wherein each digital device is authenticated by the system before it can be used within the system.
7. The method of any one of previous claims 3 to 6 wherein parameters associated with each user entity are stored on the server preparatory to each user entity participating in the system.
8. The method of any one of claims 3 to 7 wherein parameters associated with each digital item are stored on the server preparatory to each user entity participating in the system.
9. The method of any one of claims 3 to 8 wherein the digital item is stored on the server in encrypted form.
10. The method of any one of claims 3 to 9 wherein the digital item is stored on the server in encrypted form by reference to a document key.
11. A method of secure access control and transmission of digital items in a client server environment incorporating a first underlying methodology wherein servers forming part of the system never have enough information to decrypt the user entity content.
12. The method of claim 11 incorporating a second underlying methodology wherein all user entity content to which a user may have access is encrypted (directly or transitively) against their private key.
13. The method of claim 11 or 12 wherein the servers forming the part of the system never see this key in an unencrypted form.
14. The method of any one of claims 11 to 13 wherein the servers store the key encrypted using a key derived from the user's password.
15. The method of any one of claims 11 to 14 wherein the servers forming part of the system never see the user' s password (or any keys derived from it) .
16. The method of claim 15 wherein the user's password is never sent to the servers, even in encrypted form.
17. The method of any one of claims 11 to 16 wherein the user's password is verified at the client device level by using the derivative of the user' s password to decrypt the user key.
18. The method of any one of claims 11 to 17 wherein systems implementing the method rely on an infrastructure which includes cryptographic keys.
19. The method of claim 18 wherein cryptographic keys are associated with the various elements making up the systems.
20. The method of any one of claims 11 to 19 wherein
cryptographic keys are associated with:
each entity or user participating in the system;
each digital device used to participate in the system;
each digital item stored or transmitted within the system.
21. The method of any one of claims 11 to 20 wherein the cryptographic keys are utilised to encrypt and decrypt each digital item (typically a document) stored or transmitted within the system, and to determine which users may decrypt a digital item.
22. The method of any one of claims 1 to 21 further applied to a method for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server;
the user having at least for a given user login: a user ID, a user password, a user private key and a user public key; the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivati ve of the user private key of the user against the user ID;
the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge;
the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative; if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
23. The method of claim 22 wherein the comparison operation compares the user password supplied during the login attempt with the user password used to encrypt the user private key to generate the value stored on the server.
24. The method of claim 22 or 23 wherein the derivative of the user private key is an encryption of the private key encrypted against a value derived from the user password.
25. A method of secure access control and transmission of digital items in a client server environment as claimed in any previous claim further incorporating a password recovery method utilising a recovery card, said password recovery method comprising
in a first card generation step
executed on an off-line device; for each card the off-line device generates a card private key and
a card password and
a card ID and
a card public key (derived from the card private key) ;
the off-line device then encrypts the card private key using the card password so as to generate an encrypted card private key;
the off-line device then embosses and/or prints on the card so as to be readable by a user the card ID and the card password; the system administrator may then upload to an online server (platform)
the card ID and
the encrypted card private key and
the card public key;
in a second user setup step the user utilises a device which has been authenticated to the online server;
the user previously registered to the server whereby the server has a user record for the user comprising user ID; user public key; encrypted user private key;
the user indicates that they wish to register a card,
supplying the card ID from the card;
the device having the user ID, user password, user public key and user private key;
the device then transmits the card ID to the online server in order to receive the card public key for that card identified by that card ID from the server:
the device then encrypts the user private key against the card public key to generate a card encrypted user private key;
the device uploads the card encrypted user private key to the online server where it is referenced against a user record on the online server;
thereby to enable a (third) user password reset step before the user;
said reset step comprising
the user loads to the device the recovery card password and (associated with) the card ID;
the device receives from the online server the encrypted user private key and the encrypted card private key
the device decrypts the encrypted card private key by using the recovery card password provided to the device by the user so as to obtain a recovered card private key; the device decrypts the card encrypted user private key by using the recovered card private key in order to thereby obtain a recovered user private key;
the device encrypts the recovered user private key against a new user password provided to the device by the user as part of the password reset step;
thereby to produce a new encrypted user private key;
the device uploads the new encrypted user private key to the online server whereby the new encrypted private key replaces the encrypted private key previously associated with their user record corresponding to their user ID.
26. A method of secure access control and transmission of digital items in a client server environment;
the method further including a method of password replacement for a user using a device to communicate with the server;
the user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key;
the device authenticated with the server using a device a set of credentials including a device ID and device password and device private key and device public key;
the method reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a recovery card password, a recovery card private key and a recovery card public key;
the method comprising associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
27. A method for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server;
the user having at least for a given user login: a user ID, a user password, a user private key and a user public key;
the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivative of the user private key of the user against the user ID; the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge;
the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative; if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
28. The method of claim 27 wherein the comparison operation compares the user password supplied during the login attempt with the user password used to encrypt the user private key to generate the value stored on the server.
29. The method of claim 27 or 28 wherein the derivative of the user private key is an encryption of the private key encrypted against a value derived from the user password.
30. A client server environment operating according to the method of any previous claim.
31. A device operating according to the method of any previous claim.
32. A digital item secured according to the method of any previous claim.
33. Media containing code which when executed by a processor performs the method of any previous claim.
34. A recovery card marked with indicia and operable according to the method of any previous claim.
35. A system for secure access control and transmission of digital items; the system including at least one server and at least one client device; the server including at least one server processor in communication with a server memory; the server memory storing code for execution by the server
processor; the at least one client device including at least one device processor in communication with a device memory; the device memory storing code for execution by the device processor; the system further including a recovery card having its own set of recovery card credentials; the apparatus utilised to effect password replacement for a user using the at least one client device to communicate with the at least one server;
a user authenticated with the server using a user set of credentials including a user ID and user password and user private key and user public key;
the device authenticated with the server using a device set of credentials including a device ID and device password and device private key and device public key;
the system reliant on creation of a recovery card having its own set of credentials including a recovery card ID, a
recovery card password, a recovery card private key and a recovery card public key;
the system associating a selected recovery card with the user on the server whereby subsequently the user may utilise the device and selected ones of the recovery card credentials to replace selected ones of the user credentials on the server.
36. A system for authentication of a user login request in order to permit an authenticated user session between the user and a server on a device of the user in a client/server system where the device and user are previously jointly authenticated with respect to the server; the system including at least one server and at least one client device; the server including at least one server processor in communication with a server memory; the server memory storing code for execution by the server processor; the at least one client device including at least one device processor in communication with a device memory; the device memory storing code for execution by the device processor; the user having at least for a given user login: a user ID, a user password, a user private key and a user public key;
the device having at least a device ID, a device public key and a device private key;
the server in a user enrolment event for the user storing the public key of the user and a derivative of the user private key of the user against the user ID;
the server in a device enrolment event for the device storing the device public key against the device ID;
said method comprising authenticating login of the user in a login event by the user to the server by the following steps: provided the server has enrolled the user login;
provided the server has enrolled the device;
the device signals to the server commencement of the login event by the user;
the server supplies to the device the derivative of the user private key stored against the user ID and a randomly created authentication challenge;
the device performs a comparison operation to determine if the password of the user is the same as the password used to create the derivative to encrypt the user private key, and thereby decrypts the user private key from the derivative; if the comparison operation is positive the device signals to the server that the user login request has been authenticated by providing a cryptographic response to the authentication challenge which requires possession of the user private key, whereupon the server treats the login event as successful such that the user ID is now authenticated for the user session on the server using the device.
37. A system for secure access control and transmission of digital items in a client server environment wherein at least one server communicates with a plurality of participating user entities by means of participating digital devices in the form of digital communications devices in order to provide secure access control and transmission services for digital items created by, originated by or brought into the environment by ones of the plurality of participating user entities;
the server and the device executing steps whereby:
for each participating user entity participating in the environment ; each participating user entity is authenticated as between the entity and the at least one server for that user entity in a participating user entity authentication step;
each participating digital device used by the participating user entity is authenticated as between the digital device and the at least one server for that user entity in a
participating digital device authentication step;
and wherein each participating user entity has a participating user entity encryption key;
the steps further including:
a sending (source) user entity enabling secure access for a receiving (target) user entity of the plurality of user entities to a designated (unencrypted) digital item which is recorded as under the custody of the sending (source) user entity;
said sending (source) user entity encrypting the designated digital item or the user entity encrypting a key by which the designated digital item has been encrypted so as to produce an encrypted designated digital item or an encrypted digital item key preparatory to the sending user entity enabling secure access to the designated digital item by the receiving
(target) user;
said sending (source) user entity utilising a sending (source) user entity digital device which has been authenticated as between the server and the sending (source) user entity thereby to enable the designated receiving (target) user entity to decrypt the designated digital item;
said sending user entity having a sending user entity
encryption key;
said designated receiving user entity having a designated receiving user entity encryption key;
access to the designated digital item effected by the sending user entity encrypting the designated digital item so as to produce the encrypted designated digital item by utilising the designated receiving user entity encryption key to encrypt the designated digital item or access to the designated digital item effected by the sending user entity encrypting the document key of the designated digital item so as to produce the encrypted document key of the designated digital item by utilising the designated receiving user entity encryption key to encrypt the document key of the designated digital item.
AU2019360160A 2018-10-18 2019-10-18 Authentication system Pending AU2019360160A1 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
AU2018903954A AU2018903954A0 (en) 2018-10-18 Password recovery using pseudonymous cryptographic keys
AU2018903951A AU2018903951A0 (en) 2018-10-18 Cryptographic Enforcement of Access Controls with Zero Knowledge Storage
AU2018903951 2018-10-18
AU2018903954 2018-10-18
AU2018903952 2018-10-18
AU2018903952A AU2018903952A0 (en) 2018-10-18 Password authentication without server knowledge of password or derivative but allowing password reset
PCT/AU2019/051138 WO2020077415A1 (en) 2018-10-18 2019-10-18 Authentication system

Publications (1)

Publication Number Publication Date
AU2019360160A1 true AU2019360160A1 (en) 2021-05-27

Family

ID=70282860

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2019360160A Pending AU2019360160A1 (en) 2018-10-18 2019-10-18 Authentication system

Country Status (3)

Country Link
EP (1) EP3867780A4 (en)
AU (1) AU2019360160A1 (en)
WO (1) WO2020077415A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114900338A (en) * 2022-04-20 2022-08-12 岚图汽车科技有限公司 Encryption and decryption method, device, equipment and medium

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113630241B (en) * 2020-05-09 2023-04-07 杭州海康威视数字技术股份有限公司 Password recovery method and system, cloud server and electronic equipment

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060075228A1 (en) * 2004-06-22 2006-04-06 Black Alistair D Method and apparatus for recognition and real time protection from view of sensitive terms in documents
WO2012144909A1 (en) * 2011-04-19 2012-10-26 Invenia As Method for secure storing of a data file via a computer communication network
US20130159699A1 (en) * 2011-12-16 2013-06-20 F-Secure Corporation Password Recovery Service
US9521001B2 (en) * 2014-04-28 2016-12-13 Adobe Systems Incorporated Privacy preserving electronic document signature service
US10805071B2 (en) * 2014-10-13 2020-10-13 Invenia As Method and system for protecting and sharing digital data between users in a network
WO2017023385A2 (en) * 2015-07-07 2017-02-09 Private Machines Inc. Secure searchable and shareable remote storage system and method
CN106685645B (en) * 2016-11-14 2019-05-28 郑州信大捷安信息技术股份有限公司 A kind of cipher key backup for safety chip business cipher key and restoration methods and system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114900338A (en) * 2022-04-20 2022-08-12 岚图汽车科技有限公司 Encryption and decryption method, device, equipment and medium
CN114900338B (en) * 2022-04-20 2023-07-21 岚图汽车科技有限公司 Encryption and decryption method, device, equipment and medium

Also Published As

Publication number Publication date
EP3867780A1 (en) 2021-08-25
EP3867780A4 (en) 2022-11-09
WO2020077415A1 (en) 2020-04-23

Similar Documents

Publication Publication Date Title
US11297064B2 (en) Blockchain authentication via hard/soft token verification
CA3076532C (en) Leveraging flexible distributed tokens in an access control system
US11770261B2 (en) Digital credentials for user device authentication
US9330245B2 (en) Cloud-based data backup and sync with secure local storage of access keys
CN106104562B (en) System and method for securely storing and recovering confidential data
US8392702B2 (en) Token-based management system for PKI personalization process
US20160065571A1 (en) System and methods for secure file sharing and access management
CN106537403B (en) System for accessing data from multiple devices
US5491752A (en) System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens
US8775794B2 (en) System and method for end to end encryption
US11347882B2 (en) Methods and systems for secure data sharing with granular access control
AU2013243769A1 (en) Secure authentication in a multi-party system
US11361101B2 (en) Multi-party authentication and authorization
US20230038949A1 (en) Electronic signature system and tamper-resistant device
WO2020077415A1 (en) Authentication system
WO2016033208A1 (en) System and methods for secure file sharing and access management
US8842827B2 (en) Mobile phone aided operations system and method
GB2585010A (en) Cryptocurrency key management
US11797392B2 (en) Backup and recovery of private information on edge devices onto surrogate edge devices
US20240135013A1 (en) Method and system for activating a pcb analysis utilizing manufacturing capability data
KR100842014B1 (en) Accessing protected data on network storage from multiple devices
NZ761966B2 (en) Leveraging flexible distributed tokens in an access control system
WO2018007832A1 (en) System for secure electronic message transmission
He et al. UFLE: a user‐friendly location‐free encryption system for mobile users
KR20070116293A (en) Method and system of controlling access to data