WO2024200764A1 - Procédé basé sur serveur innovant pour la gestion de données confidentielles - Google Patents

Procédé basé sur serveur innovant pour la gestion de données confidentielles Download PDF

Info

Publication number
WO2024200764A1
WO2024200764A1 PCT/EP2024/058675 EP2024058675W WO2024200764A1 WO 2024200764 A1 WO2024200764 A1 WO 2024200764A1 EP 2024058675 W EP2024058675 W EP 2024058675W WO 2024200764 A1 WO2024200764 A1 WO 2024200764A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
authenticator
profile
client
server
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.)
Ceased
Application number
PCT/EP2024/058675
Other languages
German (de)
English (en)
Inventor
Dominik SCHÜRMANN
Vincent BREITMOSER
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.)
Heylogin GmbH
Original Assignee
Heylogin GmbH
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
Application filed by Heylogin GmbH filed Critical Heylogin GmbH
Publication of WO2024200764A1 publication Critical patent/WO2024200764A1/fr
Anticipated expiration legal-status Critical
Ceased 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/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/321—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 involving a third party or a trusted authority
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/45—Structures or tools for the administration of authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/3234—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 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • 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

Definitions

  • the present invention relates to a computer-implemented method for secure management of secret data on a server and secure use of the secret data by means of various application clients.
  • a computer-implemented method for secure management of secret data on a server and secure use of the secret data by means of various application clients By cryptographically encrypting the secret data and authorizing all application clients by means of an authenticator client, the user retains full control over his secret data available on the server at all times, while at the same time ensuring that the secret data is highly user-friendly.
  • the method does not require a master password and includes two-factor authentication.
  • the present invention also relates to a system, a server and three computer program products A, B and C for implementing the method according to the invention.
  • a password is set by the user at least when it is initialized and must be kept secret. If the password is displayed, intercepted or accessed unencrypted by a potential attacker, can be guessed or calculated, the security and integrity of the data, applications and user profile are at risk.
  • 2FA two-factor authentication
  • 2FA means that authentication must also be carried out using a second method, for example confirming a login by entering an SMS code in addition to the password. This can be beneficial for the user by combining factors that a user remembers (e.g. password) with those that a user has (mobile phone, biometric data). 2FA is generally recommended for important access and could prevent numerous security gaps caused by authentication being outsmarted.
  • An alternative way of using and storing passwords is to use cloud-based, centralized password management systems, such as those offered by Google or Apple for client browsers. Access to passwords is secured, for example, by an existing account with the respective provider. This results in user-friendly functions such as synchronization across all client devices on which a user is logged in. Furthermore, server-based storage of passwords can relatively easily prevent brute-force attacks by controlling the frequency of login attempts.
  • SSO procedures offer a user the possibility of easy access to all services and applications of their authorization through one-time authentication.
  • SSO procedures are widely offered as a software-as-a-service (SaaS) model.
  • Password managers such as those described above can be seen as an example of a local SSO system in which a local client with which a user authenticates automatically fills in all access data.
  • SSO procedures are widespread which use a single portal, which in turn handles the login for other services and applications, or ticketing systems which transmit proof of a user’s authentication within a trusted circle of services or applications, thus allowing a login to be carried out for all services and applications.
  • SSO procedures are not necessarily free of a master password.
  • Passwords are not the only data in the digital environment that must be kept secret. Credit card data, for example, is often used in online shopping. Sensitive personal data such as addresses and contact details should also be protected. In principle, the list of potentially secret data that needs to be protected can be expanded by a user. Essentially any type of data is conceivable, in particular secret notes or image data.
  • secret data such as passwords must generally be transmitted and stored in encrypted form.
  • Cryptographic processes are suitable for this. Such processes are not only aimed at encrypting data, but also serve to ensure the integrity and origin of data.
  • a method for ensuring the integrity of data is known from the state of the art, in which a so-called hash value (also called a hash or checksum) is calculated from data.
  • a so-called hash value function (hash function) is used.
  • hash function is provided, for example, by the Secure Hash Algorithm (SHA).
  • SHA Secure Hash Algorithm
  • a typical length for a hash is, for example, 256 bits.
  • a desirable property of a good cryptographic hash function is injectivity and the resulting collision resistance, which means that the hash function always maps different input data to different hashes. If the sender of the data calculates its hash value and makes this hash value available to the recipient, the recipient can verify the authenticity and genuineness of the data, provided the hash value itself is genuine and reliable.
  • the hash method has the disadvantage that the method is completely invalidated if the hash value itself is manipulated during a man-in-the-middle attack.
  • Man-in-the-middle attacks can be largely avoided if both sides exchange certificates with each other during communication between A and B and communicate which certificates they expect. This makes it impossible for an attacker E to manipulate the communication. This process is known as certificate pinning.
  • a certificate is a data set that confirms the properties of a person or a device and whose origin and integrity can be cryptographically verified. Certificates based on asymmetric cryptographic methods, also known as public-key or public-private-key methods, are widespread. They are used, among other things, for digital signatures. With asymmetric cryptographic methods, an owner has a key pair consisting of a public and a secret (or private) key. Using a unique cryptographic function, the owner calculates a certificate or signature for a specific message or its unique hash.
  • Any recipient can use a mutual cryptographic function to restore the message or its hash from the public key published by the owner and the certificate or signature and, by comparing it with the actual (unencrypted) message, ensure beyond doubt the authorship of the owner and the integrity of the message.
  • a device can, for example, authenticate itself against a web application or server by verifying ownership of the private key. which in turn was issued to the device, for example, by a trusted third party.
  • Asymmetric cryptographic methods can also be used to encrypt data so that the original data cannot be viewed in plain text by third parties.
  • the data is encrypted by an actor in the system using the public key of an asymmetric key pair and cryptographic algorithms.
  • the secret key is only known to the actor who is allowed to decrypt the data and should not be shared but stored securely.
  • the resulting encrypted data set can only be decrypted by the associated secret key, i.e. only by the corresponding actor.
  • symmetric encryption In the alternative symmetric encryption, however, data is encrypted with a single cryptographic key. It can only be decrypted using the same key.
  • the advantage of symmetric encryption is that the process is relatively simple, efficient and fast.
  • the disadvantage of symmetric encryption is that it requires that all trustworthy parties who are authorized to view the data must know the key, since both encrypting and decrypting data requires knowledge of the same key. At the same time, it must be ensured that only these parties have knowledge of this key. This gives rise to the problem of so-called key exchange via a potentially insecure digital
  • Transport Layer Security is a cryptographic protocol for securing communication in networks.
  • TLS is an example of a widely respected standard that is kept up to date in various versions.
  • TLS includes methods for creating and using symmetric and asymmetric cryptographic keys, for creating digital signatures, for exchanging keys over insecure channels and for authentication.
  • US10893045B2 discloses a method in which only certain end devices are allowed access to data, including on a server, by creating a session on the server using a unique ID of the end device.
  • An authenticator can also be used to allow or deny access from end devices by authenticating the user with a second factor.
  • the server does not store explicit password data, but rather any data, and access to the data is achieved using a master password.
  • the encryption method of the server-side data is controlled in the method by any end device. The method is therefore suitable as a secure data storage facility, but not as a password manager without a master password.
  • US9590959B2 also discloses a method in which a user's access request to a database service is authenticated by a cryptographic service. Different cryptographic methods are provided to prove the authenticity of the request or the user. This method can implicitly be understood as authentication for a server-based password manager with additional functions. However, no 2FA or a more specific encryption technique for potential password data stored in the database is disclosed.
  • a single sign-on system is known from US8589442B2, which works according to a decentralized principle. Login data of a user on one device can also be used on other devices by authenticating unique device IDs of all authorized devices with a mapping algorithm. However, this procedure does not 2FA is disclosed for individual logins.
  • US10341334B2 discloses a single sign-on solution in a portal variant, where a user logs in once to several associated websites using a master password. The associated logins and passwords are stored on a web server, encrypted using the master password. 2FA is not disclosed here either.
  • US8904180B2 discloses a method and system in which encrypted data on a device is stored separately from the key material for decrypting the data on a server. Access to the key material on the server is achieved by querying a client device by sending a signed one-time key, whereby the signature can be authenticated by the server or a third service. The server then makes the key material, encrypted with the one-time key, available to the client device.
  • a possibility for 2FA is disclosed, which would also be implicitly conceivable with a smartphone as a second factor.
  • the patent does not disclose any methods for the controlled authentication of other, trustworthy clients.
  • the encryption of the access data on the server is not controlled by the client or an additional device. Instead, the access data is either encrypted with an additional master key on the server, or as a "key bag" on the client, so that the server only provides authentication. This means that either the advantage of having the security of the access data against attacks on the server in your own hands or the advantages of storing it on the server are lost.
  • US20080031447A1 discloses a method for securely storing passwords and user names from websites on a server.
  • the invention discloses encrypted storage, whereby the data can only be decrypted using key material from a client, so that the data on the server is not vulnerable.
  • the method does not disclose 2FA and expects a master password from the user.
  • US20220209955A1 discloses a method for enabling a secure log-in process even under offline conditions, whereby a server provides various services, such as regularly changing passwords and authenticating users.
  • the invention discloses two variants of storing password data: online and offline.
  • a client In the online variant, it is disclosed that a client must authenticate itself using an additional device as a second factor, but it is not clearly disclosed that the password data on the server is stored by a
  • the key material controlled by the client is permanently encrypted and therefore cannot be attacked.
  • the second factor or authenticator is also not able to control the coupling of other clients in the sense of a password manager.
  • the keys are stored encrypted on the client, not on a server.
  • US9727715B2 discloses a method which also includes a server and an application for password management.
  • Password data is encrypted using an asymmetric key associated with a client, stored on the server and can be accessed when visiting the associated website.
  • the private key on the client is in turn encrypted using another key which is generated from an authentication mechanism so that 2FA can be achieved.
  • this second factor does not have to be an additional device and is not set up to manage the available clients in the sense of a password manager.
  • the client is the owner of the first key; multiple clients cannot be managed by a trusted second factor, for example a mobile application.
  • US10491588B2 discloses a method in which a password management server acts as an authenticator to establish the connection between a device and a secure password database.
  • the method also includes the automatic filling of password forms on the device by a web application.
  • the server as an interface always requires a connection from the server to the device as well as to the secure password database, which combines the disadvantages of local and cloud-based storage.
  • a master password is also required.
  • EP2332114B1 and US9948648B1 disclose methods for automatically filling in and generating password data in web applications. However, the methods do not specify secure control and storage of the password data.
  • EP3420677B1 also discloses a method in which a password-free connection of two client devices is carried out by communication via a server.
  • secret material for secure authentication is exchanged in an encrypted manner using asymmetric key pairs between both clients and stored on a server to confirm that the devices are connected.
  • the exchange of information via asymmetric encryption is carried out by scanning QR codes. from one client to the other client. Sharing of login data such as passwords between the clients is revealed, but no server-based password manager or primary control of password data by a client.
  • the security white paper v1.4 from heylogin GmbH describes a method that provides password-free management of secret data in a user-friendly manner.
  • Secret data can be stored securely on a server and encrypted using flexible client devices.
  • the method does not reveal any possibility of managing user-based permissions to the secret data or exchanging access, since each encryption of secret data is permanently assigned to a device.
  • secret data such as passwords
  • the user should not have to accept any loss of time or security by remembering and entering secret data, in particular as a single point of failure. Instead, user-friendliness similar to an SSO solution should be provided.
  • the user should be able to manage the secret data for any web application and on any of the devices they use easily, efficiently and inexpensively.
  • the security and integrity of all secret data on servers exposed on the Internet should be ensured and controlled via the user's devices.
  • the authorizations to access the secret data should be flexibly assigned and assigned to users and shareable between users.
  • an authenticator client controls the use of the secret data, the devices using this secret data and the underlying encryption of all secret data.
  • the secret data is stored on a server so that multiple devices can access it, which is an advantage in terms of usability of the invention.
  • All secret data is stored exclusively in encrypted form on the server, with keys that are only available on the user's devices.
  • the devices never send secret data in unencrypted form to the server, so the server is only used as a data storage and communication proxy.
  • the server allows central access to the secret data and its use with various devices, as long as the user authorizes this using the authenticator client. All communication between the user's devices takes place via encrypted channels.
  • the method is inherently protected by 2FA, whereby the secret data and authorizations of other devices can be easily managed at the same time via the authenticator client.
  • key pair implies that it is an asymmetric key pair comprising a private and a public key.
  • client includes both an authenticator client and an application client with its application client extension.
  • a push authenticator is initialized on an initial authenticator client.
  • the authenticator client can be seen as the core of the method according to the invention on the user side, since this authenticator client controls any storage and use, as well as any addition of further clients, in the method described below.
  • the push authenticator is a system of cryptographic keys of the authenticator client, which in combination allow the method according to the invention described below to be implemented on the software side, while the authenticator client describes the hardware device itself that is used for the method according to the invention.
  • the initial authenticator client is described as initial because it can be replaced, e.g. if the device is lost.
  • the first sub-step of S01) involves generating at least two asymmetric Key pairs, a login key pair consisting of a private login key and a public login key, and an encoding key pair consisting of a private encoding key and a public encoding key.
  • a key element designated for creating and storing cryptographic keys is preferably used to generate and store asymmetric cryptographic keys.
  • a modern smartphone is preferably used as the authenticator client, as such key elements are standard equipment for their biometric functions, among other things.
  • Such key elements are advantageously designed to be particularly resilient to cyberattacks and physical attacks, so that they protect the private keys particularly well.
  • Curve25519 is particularly preferred for creating the asymmetric keys, which is recommended in the TLS protocol 1.3.
  • the two public keys are stored on a server in a second sub-step of S01).
  • a client By possessing the private login key, a client can authenticate itself against the server.
  • the login key can be seen as a login to an account for the method according to the invention, but this is not dependent on knowledge of a master password, but on possession of a device, the authenticator client.
  • the server can verify that the message actually comes from a client that is in possession of the private login key.
  • a cryptographic method described in the TLS protocol is particularly preferably used for the authentication process.
  • the server can use the public coding key to encrypt data in such a way that only the owner of the private coding key has access.
  • step S02 the existing push authenticator is used to link additional clients to the server that can retrieve the secret data stored for this account. These clients are referred to below as application clients.
  • This process of coupling such an application client is authorized in a first sub-step of S02) by the authenticator client by exchanging at least its private login key in encrypted form with the application client.
  • This encrypted transmission is preferably carried out using asymmetric encryption. A preferred embodiment of the encrypted transmission is described later in the description.
  • the application client uses the private login key to authenticate itself against the server in the manner already described.
  • a session is created on the server for the application client by the authenticated application client storing the public session key of a session key pair generated by the application client on the server.
  • This public session key can be used to encrypt data to which only this application client has access using its private session key.
  • Creating a session requires that the application client comprises a computer program product that is set up to generate an asymmetric cryptographic session key pair.
  • a computer program product that offers this functionality, among other things, is part of this invention and is described later in the description.
  • a software functionality for creating cryptographic keys on the application client is provided by an application client extension described later.
  • the application client also uses a key element to securely store the private keys, in particular the private encryption key and the private session key, which it has at its disposal.
  • Step S02) can be repeated in order to link several application clients using the authenticator client.
  • all linked clients or their sessions are displayed in list form on the authenticator client.
  • the method is set up for an option for the authenticator client to control the sessions of application clients, delete the public session keys from the server and thus remove the session on the server side.
  • any contact by the application client without a session with the server is rejected by the server.
  • the application client is set up to delete any keys it possesses in the event of rejection by the server. This advantageously prevents the long-term and therefore unnecessarily risky storage of private keys on unauthorized devices.
  • the application client retrieves the status of its session from the server at regular intervals, so that the private key material is deleted from the authenticator client at this point in time at the latest if no session exists.
  • the status of the session is retrieved for the first time by the application client immediately when the application client extension is started.
  • the time interval can be set and is also made dependent on the security requirements on the application client. Is For example, if no key element is installed in the application client and the application client is connected to a potentially dangerous public network, the time interval for retrieving the session status can be set to a particularly short time, for example 1 second.
  • a client cannot see that its own session no longer exists without contacting the server, which deletes the key material. This advantageously prevents an attacker from being incentivized to delay deleting the session.
  • authenticator clients also each receive a session on the server, so that several authenticator clients of a user can be initialized, but also controlled from another authenticator client.
  • step S03 the initialized authenticator client and the coupled application client are used to store or retrieve secret data by the application client on or from a safe located on the server.
  • a safe is a data packet on the server's storage medium that is assigned to an account and, as described below, is cryptographically encrypted.
  • the safe contains an ordered list of transfers that map the chronological order of the stored secret data so that all secret data is clearly sorted and assigned.
  • several safes can exist for an account, which can be encrypted differently.
  • Secret data in the safe preferably includes login data for web applications, i.e. user names, email addresses and passwords.
  • alternative secret data can also be stored in safes according to the invention, for example payment and credit card information or addresses.
  • other data types that can be defined by the user such as free text for secret notes or image data, can also be stored.
  • the safe containing secret data is encrypted using a symmetric key.
  • this encryption advantageously means that multiple copies of the safe do not have to be encrypted for the different push authenticators. It therefore makes sense that there is always exactly one symmetric key for a safe.
  • this key Since with symmetric encryption, decryption is also done using the same symmetric key, this key must also be encrypted because it is to be stored on the server in order to ensure authorized access to the Safe.
  • This encryption takes place in a second sub-step of S03) using the public encryption key of the push authenticator, so that only a client that is in possession of the private encryption key has access to the symmetric key and thus the safe.
  • the storage and retrieval of secret data from the safe is authorized by the application client, namely by the authenticator client, which provides the private encryption key in encrypted form for the application client so that the latter can retrieve the private encryption key and decrypt the safe.
  • This encrypted provision of the private encryption key is preferably authorized by an active input on the authenticator client by a user.
  • the encrypted provision or retrieval is realized by the private encryption key being encrypted by the authenticator client using the public session key and sent to the application client via the server, whereby only the application client can decrypt this transmission.
  • the private encryption key is transmitted to the application client together with the private login key in step S02).
  • the private encryption key cannot be stored in persistent memory by the application client, so that the authenticator client must confirm each individual storage or retrieval and the private encryption key can advantageously not be stolen in the event of a physical attack on the application client while it is switched off.
  • Further preferred embodiments for authorizing storage and retrieval by providing the encryption key by the authenticator client result from further described preferred features of the invention.
  • the authenticator client controls the authorized clients through this configuration, particularly in step S02) and any access to the secret data in step S03).
  • the authenticator client is used as a second factor for an attempt to retrieve secret data from the application client.
  • the authenticator client is required to activate a protective function of the device, for example through biometric authentication.
  • biometric authentication advantageously means that the 2FA protection is completely achieved through the user owning a device (authenticator client) and querying a secret from the user (e.g. biometric authentication).
  • biometric authentication e.g. biometric authentication
  • This authentication of the user on the authenticator client is now standard in any case, especially when using a modern smartphone, and is independent of the management method. confidential data. In this respect, this measure is advantageous not to be seen as additional effort, as other 2FA methods are usually seen.
  • a smartphone is used as an authenticator client, which has a key element. Furthermore, the authenticator client preferably has options for user input to authorize steps S02) and S03).
  • an authenticator client is used simultaneously as an application client.
  • the computer program products that implement the features of the method on the authenticator client or the application client when they are executed are installed and executed separately from one another.
  • the features of the method that belong to the authenticator client are executed in a mobile app and the features of the method that belong to the application client are executed in a web application that is called up via the browser.
  • the embodiment variant in which the use of the push authenticator within the mobile app requires a protective function of the smartphone when the mobile app is opened is particularly preferred, so that 2FA is advantageously secured when the device is used.
  • the method according to the invention further comprises the use of at least one profile as an indirection level of the authenticator client, in addition to the initialized push authenticator.
  • a profile is essentially technically equivalent to a push authenticator, with the difference that a profile does not have its own login key to authenticate itself against the server.
  • a profile instead of at least one push authenticator, a profile encrypts the symmetric key of at least one safe with a public profile key of an asymmetric profile key pair created on the authenticator client.
  • the profile and thus in particular the private profile key is then encrypted on the server side in this standard embodiment using the public coding key of the associated push authenticator.
  • a profile comprises at least the profile key pair, but in the further course of the description, further keys belonging to the profile are described, which are also encrypted accordingly using the public coding key of the associated push authenticator.
  • This configuration of standard and preferred encryptions explains the concept of the profile as an indirection layer, which means that the profile acts as an additional layer between a push and authenticator and a safe.
  • the profile is therefore controlled by this push authenticator and thus by the authenticator client.
  • the profile controls access to safes encrypted with its profile key pair.
  • the technical effect is an additional encryption level with which a wide range of encryption variants can be implemented between push authenticators and safes.
  • a user is assigned a profile for each organization or context in which all accesses for this user can be collected.
  • Profiles advantageously allow authorizations to be implemented on a user-specific or otherwise flexible basis.
  • profiles allow, for example, the implementation of a superadmin profile, which can encrypt all of an organization's safes and is therefore a basic requirement for the possible allocation of administrator rights to manage secret data, but also to prevent the loss of secret data due to key loss.
  • profiles are also fundamentally advantageous in relation to the crypto agility of the invention or the organization that uses the method according to the invention.
  • crypto methods can be changed or updated step by step. This means that basic security against certain threats can be established with little effort, without, for example, having to re-encrypt each individual safe.
  • This is a flexibility advantage compared to the use of exclusively direct encryption of safes using push authenticators.
  • any key material associated with a profile is created from a random profile seed.
  • encrypting a profile e.g. by the Encryption key of the associated push authenticator that the random profile seed is encrypted.
  • each user per organization or context is assigned not only one profile for encrypting safes, but at least one additional profile that is used for the fully encrypted reception of messages and information and/or for storing preferences and settings regarding the use of the method according to the invention, for example the time until a session is automatically closed.
  • other functions can thus be implemented in the same encryption architecture in addition to storing and retrieving secret data.
  • a profile In one version of a profile, several identical copies of the profile are encrypted on the server side using the public encryption keys of several push authenticators.
  • This version gives several push authenticators, especially those of several users, access to a profile.
  • the advantage here is increased flexibility in managing and changing authenticators.
  • a profile can be encrypted using any authenticator. For example, hardware security devices can be added or removed as additional or backup authenticators. The entire set of authenticators of a user or several users can thus be flexibly rotated with regard to their profile. This is also advantageous for a more secure backup and recovery strategy, as it makes the total loss of key material less likely.
  • a profile In another variant of a profile, several profiles are encrypted with the same public encryption key of a push authenticator, so that a push authenticator has access to several profiles.
  • This version can be used to implement a push authenticator as a master device for specific applications in which extensive access should not depend on users or profiles, but on specific devices.
  • a profile is encrypted using the public encryption keys of several push authenticators at the same time, so that these several push authenticators are required at the same time to gain access to the profile.
  • This variant is preferably only used for particularly sensitive secret data for which a high level of security applies or for whose management the consent of several users is required. This can advantageously create a digital four-eyes principle for access to this profile.
  • the symmetric key of a vault is encrypted by one or more different public profile keys or public encryption keys of multiple profiles or push authenticators.
  • the symmetric key can be encrypted by the public keys of multiple profiles, multiple push authenticators, or both profiles and push authenticators.
  • a symmetric key can be encrypted by the public keys of several profiles or push authenticators at the same time, so that these several profiles or push authenticators are required to gain access to the symmetric key.
  • This variant is preferably only used for particularly sensitive secret data for which a high level of security applies or for whose management the consent of several users is required. This can advantageously create a digital four-eyes principle for access to secret data.
  • multiple copies of the same symmetric key can be encrypted using the public keys of multiple profiles or push authenticators, so that these multiple profiles or push authenticators can access the symmetric key independently of one another.
  • the access of the profiles or push authenticators to a safe can thus be established and managed independently of one another.
  • multiple vaults can be created for one account, so that conversely a public profile key of a profile or a public encryption key of a push authenticator can encrypt multiple different symmetric keys belonging to different vaults.
  • a push authenticator can have direct access to the symmetric key of a safe and to a profile, with the profile also having access to three other safes. This would give a push authenticator access to a total of 4 safes.
  • Profiles are advantageous as an indirection layer for push authenticators because they provide flexibility for access permissions to secret data. Access to a Tresor is no longer necessarily tied to a user and their (initial) authenticator client. Instead, in a preferred implementation, a user can share access to a vault via a profile with other push authenticators on other users' authenticator clients. To share access to a vault via a profile, in a preferred implementation, a sharing authenticator client encrypts this profile with the public encryption key of a push authenticator registered with the server of another, receiving authenticator client by retrieving the public encryption key from the server. The sharing authenticator client then stores the encrypted profile on the server so that the receiving authenticator client can retrieve the profile that only it can read. Profiles thus provide a solution for secure, fully encrypted account sharing, where access to the secret data, but not access to the account, is shared via the push authenticator itself. This feature is particularly beneficial in small teams with specialized tasks in the work environment.
  • two profiles are used sequentially, with at least a first profile being encrypted directly by the public profile key of the profile key pair of at least a second profile.
  • certain authorization chains can advantageously be implemented even more simply and, from a key hygiene perspective, even more cleanly.
  • a user can temporarily take over access to secret data or access data from another user without the profiles or authenticators assigned to the other user being changed. Instead, only an encryption of a profile of one user with a profile of the other user needs to be created and sent to the profile of one user.
  • a parent or guardian can temporarily take over access to a child's access data.
  • access data of an employee leaving an organization can be transferred securely and easily to a new employee.
  • the direct encryption of at least a first profile using the public profile key of the profile key pair of at least a second profile means that no further intermediate steps are introduced, such as separate safes for storing certain profiles.
  • This embodiment is less computationally and memory-intensive.
  • the advantage is that the encryption of the profiles is therefore more efficient and, from a key hygiene perspective, simpler and clearer.
  • Profile is the random profile seed of the first profile from which its key material can be generated, is encrypted directly by the profile key pair of the second profile.
  • the profile seed contains all the necessary information of the profile, so that it is advantageous not to encrypt several individual keys.
  • two profiles are used sequentially in such a way that a comprehensive authorization structure for at least one administrator of the secret data of an organization is advantageously implemented cryptographically.
  • the first profile encrypts all safes belonging to an organization and at least the second profile is managed by the push authenticators of an administrator of the organization.
  • the first profile technically takes on the function of a super administrator and can advantageously prevent unwanted loss of access to safes by automatically encrypting each safe using this profile, preferably automatically.
  • At least one, but preferably all user profiles of administrators of the organization have access to this profile. If an administrator authorization is to be revoked, the encryption of the first profile can advantageously be simply deleted with the second profile of this administrator, so that the second profile is no longer able to decrypt the first profile.
  • the administrator of the organization is able to delete all encryptions according to method step S03) of his organization, replace them with placeholders and generate new ones.
  • This embodiment allows an administrator to cancel profiles of certain users, certain push authenticators or certain encryptions (and thus access authorizations).
  • Advantageous use cases of this are the on- and offboarding of employees of an organization, the creation and cancellation of certain (administrator) authorizations, as well as the blocking and restoring of access in the event of loss or change of devices that can be used as push authenticators.
  • the administrator of the organization is able to resolve an encryption and thus the corresponding access authorization as follows.
  • the encryption of a profile or the symmetric key of a safe is deleted.
  • the profile is continued as a free profile, with placeholders being used as encryptions.
  • new encryptions are created and the keys or the profile start value are encrypted and sent to the push authenticator of the new, replaced or returning user.
  • This can advantageously be used to start a flexible and secure onboarding process. It is particularly preferable for a new push authenticator to regenerate the keys of his newly assigned profile after onboarding, so that from a data protection point of view only he, and no longer the administrator, has access to them.
  • a safe comprises a sensitive data area and a metadata area.
  • the sensitive data area is additionally encrypted within the safe using a symmetric high-security key. This means that to access this sensitive data area, both the symmetric key for decrypting the entire safe and the symmetric high-security key for decrypting the sensitive data area are required.
  • the symmetric high-security key is in turn encrypted using a public high-security key of an asymmetric high-security key pair of a push authenticator or a public profile high-security key of an asymmetric profile high-security key pair of a profile.
  • secret but not highly sensitive data such as user names and email addresses can be stored in the metadata area, while the associated passwords and other secret data such as answers to security questions are stored in the sensitive data area.
  • billing addresses could be stored in the metadata area and credit card information in the sensitive data area.
  • the high-security key pair or the profile high-security key pair each belongs to a push authenticator or profile and is generated on the corresponding authenticator client in addition to the key pairs already described that belong to a push authenticator or profile, and the respective private key is stored there.
  • the high security key pair and the profile high security key pair cannot be stored on a client's permanent memory.
  • a permanent memory is a memory that makes data available even after the power supply is switched off. This means that a client only has these keys available in a working memory, at most until the next time this client is switched off. After that, they must be re-stored. To ensure that access to these keys is not lost in this embodiment, this generation must be reproducible at least on the authenticator client that generated the high-security key pair or the profile high-security key pair. The preferred method for this is to generate them from a random starting value that is saved. Such a starting value is described in more detail later in the description.
  • the non-permanently storable version of the private high-security key or private profile high-security key ensures that an application client never has permanent access to the sensitive data area of the safe, but that this access always depends on the generation from the random start value or retrieval of the private (profile) high-security key from the authenticator client. This means that the authenticator client controls access to the sensitive data area not only when connecting application clients, but at all times.
  • the login key pair of an authenticator client cannot be stored on permanent storage, so that no application client can permanently log on to the server. This advantageously means that access to the account is also permanently controlled via the authenticator client.
  • a coupled application client can be set to an open or closed state, whereby this application client receives access or no access to the private high-security key.
  • This advantageously ensures that access of this application client to the sensitive data area can be regulated, whereby an application client in the open state receives access, while an application client in the closed state only receives access to the metadata area.
  • This regulation or setting to the open or closed state is carried out by the authenticator client.
  • setting to the open or closed state is achieved by switching a binary switch within a mobile application, whereby the mobile application displays such a binary switch for each coupled application client in a list.
  • these binary switches for setting the state are preferably displayed within the previously described list overview of all clients on the authenticator client.
  • the state is determined by the existence of the with the high-security key or profile high-security key encrypted with the public session key of the application client in an application client session on the server. If a high-security key encrypted in this way exists, only the application client that has the private session key can decrypt this high-security key and use it to access the safe.
  • the authenticator client associated with the high-security key can change the application client from the open to the closed state by removing this key from the server.
  • the ability to put an application client into an open state can increase the efficiency of retrieving and storing secret data for a particularly trustworthy device.
  • the ability to put an application client into a closed state means that every retrieval or storage of secret data can and must be authorized by the trusted authenticator client.
  • the private encryption key or private profile key unlike the equivalent high-security keys, can be stored on the application client so that the application client has at least access to the metadata area as long as it has an active session on the server.
  • the application client cannot retrieve secret data from the sensitive data area for the web applications, but can at least recognize via a stored URL of the web application or a stored user name that secret data for the web application is present in the sensitive data area in the safe.
  • the integrity of the public coding keys, high-security keys, profile keys, profile high-security keys and session keys stored on the server is ensured by a signing process.
  • a private identification key of an identification key pair of the push authenticator or profile associated with the respective public key stored on the server is used for the signing process.
  • the public identification key is stored on the server.
  • a signature is generated from the private identification key and the respective public key, which is stored on the server together with the respective public key.
  • the server or third parties can determine without a doubt that the signature comes from the owner of the private identification key, in this case from the authenticator client.
  • the integrity of the signed public keys is guaranteed. This applies as long as the public identification key on the server is also correct and unchanged. If it is the However, if this is no longer the case, this problem can again be advantageously detected by the authenticator client.
  • the key pairs belonging to a push authenticator - login key pair, identification key pair, coding key pair and high-security key pair - are derived from a random authenticator start value. Furthermore, the key pairs belonging to a profile - identification key pair, profile key pair and profile high-security key pair - are also derived from a random authenticator start value. This derivation is particularly preferably carried out using collision-free cryptographic one-way functions.
  • Deriving the key pairs has the advantage that a push authenticator and all of its keys can be derived from a single random start value.
  • the random authenticator or profile start value can be transmitted once instead.
  • Other preferred properties of keys such as that high-security and login keys may not be permanently stored on an application client for security reasons, are preferably assigned to the keys after derivation.
  • Any random authenticator or profile start value that can derive keys that may not be permanently stored on an application client may itself not be permanently stored on an application client.
  • the random start values for push authenticators and profiles on an authenticator client are stored on the key element of the authenticator client, advantageously encrypted and protected against attacks.
  • This embodiment variant results in the random authenticator or profile start value being transmitted in encrypted form instead of the encrypted transmission of private keys in the method according to the invention.
  • the random authenticator start value is transmitted in encrypted form instead of the private login key.
  • the random authenticator start value or profile start value is transmitted instead of the private coding and high-security keys or profile and profile high-security keys.
  • the setting of an application client into an open or closed state is controlled by adding the random authenticator or profile start value encrypted with the public session key of the application client to a session instead of the private high-security keys contained in these random start values.
  • a profile is not generated from one but from two random profile start values, with the profile key pair being generated from one random profile start value and the identification key pair and the profile high-security key pair being generated from another random profile high-security start value. If the symmetric key and symmetric high-security key of a safe are encrypted using a profile, this division also allows a coupled application client to be divided into open and closed states, in that in the case of the closed state the random profile high-security start value (which cannot be stored permanently) is not made available in the session and thus no sensitive data can be retrieved from the safe by the application client.
  • the key pairs belonging to a push authenticator, identification key pair, coding key pair and high-security key pair are derived from a random salt value in addition to the random authenticator start value.
  • the key pairs belonging to a profile, identification key pair, profile key pair and profile high-security key pair are derived from a random profile salt value in addition to the random profile start value and profile high-security start value.
  • the salt value and profile salt value are stored unencrypted on the server.
  • Deriving keys from random start values combined with random salt values has the advantage that an attacker cannot find out private keys by testing different start values, also systematically using so-called rainbow tables, and can derive the start value if the result of a key is the same. Salt values thus advantageously increase cryptographic security.
  • the method comprises a recovery function which allows a new authenticator client and the secret data encrypted by any push authenticator or profile of the initial authenticator client to be used without having access to the initial authenticator client, i.e. the first authenticator client used for this account.
  • Backup authenticators are used for this purpose, which are advantageously initialized on the new authenticator client by the recovery function in order to gain access to the secret data of the initial authenticator client.
  • an additional backup authenticator is created, which contains a copy of the same secret data like the push authenticator of the initial authenticator client.
  • the corresponding random authenticator start value of the backup authenticator, from which all keys of this backup authenticator can be derived, is preferably stored in an encrypted cloud that is protected by additional security measures.
  • iOS and Android offer encrypted cloud backups for their mobile applications, which are used for the backup authenticator.
  • a backup code can be retrieved by the user from the mobile application.
  • this backup code is retrieved for the first time, another backup authenticator is created and the user's secret data is encrypted with this backup authenticator.
  • An authenticator start value is particularly preferably derived from the backup code using a hash function using a backup salt value, which is stored on the server.
  • the backup salt value advantageously increases the security of this execution of the recovery function.
  • the user himself is responsible for security against spying, manipulation and loss of the backup code.
  • the secret data is combined into a single transfer in all safes encrypted by the respective backup authenticator of the initial authenticator client.
  • the safe(s) are then encrypted using one or preferably two new symmetric keys. These symmetric keys are encrypted using new public encryption keys and preferably new public high-security keys of a newly initialized push authenticator on the new authenticator client. All keys of the initial authenticator client, including the backup authenticator used, are deleted so that all safes are advantageously re-encrypted and long-term attacks on the secret data are prevented via the recovery function from this point on at the latest.
  • New recovery functions are preferably created on the new authenticator client using the backup authenticators described.
  • an application client comprises an associated application client extension that is locally connected to and on the application client.
  • the application client extension is a browser extension in a browser on the application client.
  • the application client extension serves to store metadata of the secret data of a safe to which the session of this application client is assigned. store and retrieve. This makes it particularly useful for the application client extension to identify websites that are accessed in the browser as known websites for which secret data is already available.
  • the application client extension generates overlays, in particular for the forms for logging in to well-known websites.
  • the overlays are particularly advantageously displayed instead of the original forms by adapting the source code of the website accordingly. This allows a user to immediately recognize that secret data has already been saved using the method according to the invention and to retrieve it accordingly.
  • the overlays also ask the user whether the secret data already entered should be saved in the corresponding safe, for example if there are no previously saved login data for this website after a successful login attempt on a website.
  • the application client extension also generates overlays for forms that ask the user to enter, in particular but not exclusively, address, payment and credit card information.
  • the application client extension generates overlays if the user or another user has left a secret note for a specific URL and asks whether it is displayed. This advantageously allows notes to be saved and shared securely specifically for certain web applications.
  • the application extension automatically recognizes known websites for which secret data is available, generates and displays overlays, and automatically fills out forms, particularly login forms, with all secret data available in the current state of the application client.
  • the only task left for the user is to confirm the saving or retrieval of secret data using the authenticator client when the application client is closed, with the application client extension also generating and displaying a special overlay for this task. This advantageously ensures a user experience that is as convenient as an SSO solution.
  • any authorization of the coupling of application clients as well as the storage and retrieval of secret data by an authenticator client is achieved by a swipe gesture that is carried out on the smartphone used as the authenticator client in this embodiment.
  • a mobile application as already described is installed on the authenticator client, which in this
  • the user is prompted to perform the swipe gesture using a simple graphical user interface.
  • the security function of the smartphone for example biometric authentication using a fingerprint or facial identification, is requested. This advantageously achieves 2FA using an authentication that is intuitive and familiar to the user.
  • the authorization on the smartphone is also a particularly simple and intuitive type of authorization and advantageously increases the user-friendliness of the entire process.
  • a session of a client coupled to the server includes a session token, which is stored on the server alongside the public session key.
  • the existing session token advantageously allows the client to send requests to the server.
  • removing the session token allows sessions of application clients, but also authenticator clients, to be controlled by rejecting their requests to the server by removing the session token.
  • a client whose request to the server is rejected deletes its stored keys.
  • the session token is therefore a particularly simple way of exercising control over client sessions by an authenticator client.
  • the coupling of an application client is initialized in step S01) by entering a public exchange key of an asymmetric exchange key pair generated by this application client into the authenticator client.
  • the input includes any form of data capture by the authenticator client, in particular but not limited to physical typing by the user or capture of image, radio or sound information.
  • the authenticator client encrypts its private login key or preferably its random authenticator start value with this public exchange key and sends the encrypted result to the application client, which can decrypt the private login key or preferably the random authenticator start value with the private exchange key. Encryption advantageously ensures the security of the transmission.
  • the encrypted private login key or random authenticator start value is preferably sent using the server as a proxy, i.e.
  • the integrity of the sent encrypted private login key or random authenticator seed is verified by means of a signature of the authenticator client, particularly preferably by means of its identification key.
  • the application client can determine the authenticator client as the sender and the integrity of the encrypted private login key or random authenticator seed value sent if the server also sends the public identification key to the application client.
  • the exchange key pair is only used once, so that no spam, malicious code or incorrect information can be sent to the application client using the same encryption.
  • the exchange key pair is particularly preferably renewed on a time-controlled basis, particularly preferably every 30 seconds, 60 seconds or 5 minutes.
  • the public exchange key is contained in an exchange QR code generated and displayed by the application client, which is captured visually by the authenticator client and particularly preferably by camera.
  • This embodiment advantageously allows a particularly high level of user-friendliness.
  • a mobile application that executes the method according to the invention on a smartphone used as an authenticator client is registered with the operating system of the smartphone as a processor of at least one such specific type of QR code that is used for coupling application clients. This mobile application is therefore started automatically when such a QR code is captured by any camera application on the smartphone. This in turn increases the time efficiency of the method and thus advantageously the user-friendliness.
  • embodiments of the present invention can be implemented as a program, firmware, computer program or computer program product with a program code or as data, wherein the program code or the data is effective to carry out one of the methods when the program runs on a computing unit.
  • the program code, the computer program product or the data can also be stored, for example, on a machine-readable carrier or data carrier.
  • the program code or the data can be present, among other things, as source code, machine code or byte code as well as other intermediate code.
  • CPU Central Processing Unit
  • GPU Graphics Processing Unit
  • ASIC Application-Specific Integrated Circuit
  • IC Integrated Circuit
  • SOC System on Chip
  • FPGA Field Programmable Gate Array
  • the present invention also includes the server, which has at least one computing unit for executing computer programs, network connections for exchanging data with at least all clients connected to the server in a network, and at least one storage medium for storing computer programs as well as keys, values, sessions and safes.
  • the computing unit is a CPU (central processing unit), which can be used for a variety of operations but is not adapted to particularly specialized computing operations.
  • the server also includes an application-specific integrated circuit (ASIC) for efficient encryption, for checking signatures or certificates and for executing hash functions.
  • ASIC application-specific integrated circuit
  • the present invention comprises a computer program product A.
  • This comprises commands which, when executed by a computing unit on an authenticator client, cause the authenticator client to carry out the method according to the invention.
  • This relates in particular to the method steps and features that are carried out on the authenticator. These include in particular, but not restrictively, the following method steps and features:
  • the server and a computer program product A the present invention also includes a computer program product B.
  • the computer program product B consists of up to two parts, a primary computer program product of the application client and an application client extension.
  • the primary computer program product of the application client is a web application
  • the application client extension is implemented as a browser add-in.
  • the coupling including displaying the public exchange key pair and functions such as retrieving the status of the application client, is carried out in the web application.
  • the browser add-in takes over all functions and steps of the process relating to storing metadata of secret data, creating and displaying overlays, filling out forms, and storing and retrieving secret data on and from the server.
  • the server and the computer program products A and B the present invention also includes a computer program product C.
  • This relates in particular to the method steps and features that are carried out on the server. These include in particular, but not restrictively, the following method steps and features:
  • the present invention also includes a system which consists of the combination of the computer program products A, B and C and the server.
  • This system is able to fully carry out the present inventive method.
  • the prerequisite for this is the use of suitable authenticator clients or application clients which have already been specified but are not covered by the present invention and which are set up to execute at least the computer program products A and B.
  • all cryptographic keys are shown as color boxes and provided with a key symbol. All keys or values that are shown in light gray are secret keys or values that are only available on the device to which they belong. Keys or values that are shown in white are also secret, but are available on the server, albeit only in encrypted form. Keys or values that are shown in dark gray are public keys or values and can be unencrypted on the server side.
  • Fig. 1 The operating principle of the user interface of the method according to the invention in
  • Step S03 The user saves or retrieves secret data on an application client (1.3), here a laptop.
  • this function is provided via overlays (1.4.2) by the application client extension (1.4.1), in this preferred embodiment executed as a browser add-in.
  • Different forms (1.4.3) of different web applications can be automatically recognized by the application client extension (1.4.1) and the inventive overlay (1.4.2) displayed. If the user saves or retrieves secret data, he is asked to confirm this step on his authenticator client (1.2), in this preferred embodiment a smartphone.
  • Fig. 2 The underlying architecture of the system of the parties involved in the process
  • An authenticator client (1.2) communicates via a server (1.1) with an application client (1.3) or its associated application client extension (1.4.1). Both the authenticator client (1.2) and the application client (1.3) and its application client extension (1.4.1) communicate with the server via encrypted channels, shown by the solid arrows, in this preferred embodiment via channels with encryption according to the TLS protocol.
  • the server (1.1) serves as a communication proxy between the clients; this functionality is shown with the dotted arrows. In this case, the clients communicate using end-to-end encrypted messages within the encrypted channels. Local, unencrypted communication on the same device only occurs between the application client (1.3) and its application client extension (1.4.1), e.g. between the device memory and the browser add-in.
  • Fig. 3 A comparison of the different keys that a push authenticator (1.5) and a profile (1.7) have.
  • a profile (1.7) does not have a login key pair consisting of a public (2.1.2) and a private (2.1.3) login key to independently authenticate itself against the server.
  • Both the profile (1.7) and the push authenticator (1.5) have an identification key pair consisting of a public (2.2.2) and a private (2.2.3) identification key, whereby all other described public keys of the profile (1.7) or push authenticator (1.5) that are stored on the server are signed using the private identification key (2.2.3), whereby the integrity of the signed public keys can be ensured using the signing process (2.2.4).
  • Profile (public (2.5.2) and private (2.5.3) profile key and public (2.6.2) and private (2.6.3) profile high security key) and push authenticator (public (2.3.2) and private (2.3.3) encryption key and public (2.4.2) and private (2.4.3) high security key) have differently named keys for encrypting vaults belonging to the profile or push authenticator.
  • the encryption key pair (2.3.2 and 2.3.3) and high security key pair (2.4.2 and 2.4.3) of the push authenticator (1.5) also serve to decrypt any keys of a profile (1.7) assigned to this push authenticator in order to gain access to this profile.
  • all keys of the profile or push authenticator are derived from the random profile start value (4.2.1) and the random profile high security start value (4.2.2) or the random authenticator start value (4.1). Both the profile start value (4.2.1) and the profile high security start value (4.2.2) exist in order to be able to retrieve the profile key pair (2.5.2 and 2.5.3) and the profile high security key pair (2.6.2 and 2.6.3) individually from a profile, e.g. depending on whether the profile is in the open or closed state. In this variant, all keys from the push authenticator (1.5) or the profile (1.7) are also derived from a random salt value (4.3) or a random profile salt value (4.4).
  • Fig. 4 The encryption of a safe (3.3.1) on a server (1.1), in this
  • the public (2.2.2, 2.5.2, 2.6.2) and private (2.2.3, 2.5.3, 2.6.3) keys generated on the authenticator client (1.2) and belonging to the profile are generated from at least one random profile seed value (4.2.1), one random high-security profile seed value (4.2.2) and one random profile salt value (4.4).
  • the public keys (2.2.2, 2.5.2, 2.6.2) are stored on the server, whereby the public profile high-security key (2.6.2) is used to encrypt the symmetric high-security key (3.2) and the public profile key (2.5.2) is used to encrypt at least the symmetric key (3.1).
  • both symmetric keys are also encrypted using the public profile key (2.5.2).
  • the symmetric keys can in turn be used to retrieve secret data from the safe (3.3.1), which is stored there systematically and chronologically sorted in individual transfers (3.3.7) for individual web applications.
  • Fig. 5 The access restriction to a profile (1.7) through encryption by a push authenticator (1.5) and a second, in this embodiment, backup authenticator (1.6).
  • key pairs associated with the profile are generated from a random profile start value (4.2.1), a random profile high security start value (4.2.2) and a random profile salt value (4.4), whereby These can be used to encrypt a server-side vault as shown in Fig.4.
  • the random profile salt (4.4) is stored publicly on the server
  • the random profile seed (4.2.1) is encrypted by the public encryption key (2.3.2) of a push authenticator (1.5)
  • the random profile high-security seed (4.2.2) is encrypted by at least the public high-security key
  • This backup authenticator (1.6) can be created by transferring the random authenticator seed (4.1) and the random salt value (4.3) to another authenticator client and, in the event of a loss of the initial authenticator client (1.2), generate all keys (2.1.2, 2.1.3, 2.2.2, 2.2.3, 2.3.2, 2.3.3, 2.4.2, 2.4.3) there in order to decrypt the profile (1.7) and thus gain access.
  • Fig. 6 The public and private keys available to a profile (1.7) and a push authenticator (1.5) on an application client in uncoupled, coupled but closed, and coupled and open states.
  • uncoupled state the application client generates only one public (2.8.2) and one private (2.8.3) exchange key in order to be able to receive keys or start values encrypted from an authenticator client.
  • coupled state the application client has a session (2.7.4) with a session token (2.7.5) and a public (2.7.2) and a private
  • a push or backup authenticator (1.5 or 1.6) also has a login key pair consisting of a public (2.1.2) and private (2.1.3) login key to authenticate against the server, which a profile cannot do.
  • a profile (1.7) or push/backup authenticator (1.5 / 1.6) on an application client has all the keys described in particular in Fig. 3.
  • the open state can control whether the push/backup authenticator (1.5 / 1.6) on an application client has access to its private high-security key (2.4.3), identification key
  • Fig. 7 An illustration of the access authorization to a safe (3.3.1) and the secret data contained therein through the possession and use of certain keys.
  • a push authenticator accesses the safe (3.3.1) directly, unlike in the equally possible embodiment in Fig. 4, in which a profile accesses the safe (3.3.1) as an indirection level for the push authenticator.
  • the push authenticator is in possession of the encryption key pair (2.3.1), consisting of a private (2.3.3) and a public (2.3.2) encryption key. With these keys, the push authenticator can encrypt and decrypt the symmetric key (3.1) in order to gain access to the safe encrypted by this symmetric key (3.1).
  • the safe is divided into a metadata area (3.3.5) and a sensitive data area (3.3.3), with the sensitive data area (3.3.3) additionally encrypted by a symmetric high-security key (3.2).
  • the push authenticator can only access the metadata area (3.3.5) and the metadata (3.3.6) contained therein.
  • the push authenticator requires the high-security key pair (2.4.1) consisting of a private (2.4.3) and a public (2.4.2) high-security key to encrypt and decrypt the symmetric high-security key (3.2).
  • the private high-security key (2.4.3) cannot be stored permanently by the push authenticator, but must be generated or derived using the random authenticator seed value (see Fig.6), which in turn is only possible when the push authenticator is in the open state.
  • Fig. 8 An illustration of a preferred embodiment of the
  • Application client extension (1.4.1) with its functions and the various overlays (1.4.2).
  • the method according to the invention is used here for password-based login to a web application.
  • a web application here for example Github.com, shows its standard form (1.4.3) for login. Therefore the application client and the application client extension (1.4.1) must be coupled with an authenticator client by, in this preferred embodiment, the application client extension
  • This QR code (2.8.4) contains a public exchange key
  • the application extension (1.4.1) recognizes the known form (1.4.3) for logging in and automatically displays an overlay (1.4.2) for logging in using the method according to the invention instead of the form, see the illustration in the top center of Fig.8. If the user initializes the login, the overlay (1.4.2) in the bottom center of the illustration shows that the user should authorize access to the secret data of this web application using the authenticator client - this applies at least in the case that the application client is not set to the open state, because then it could also retrieve the sensitive secret data without authorization. At the end of the process, the overlay (1.4.2) shows the successful login to the web application and is then hidden.

Landscapes

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

Abstract

La présente invention porte sur un procédé mis en œuvre par ordinateur pour la gestion sécurisée de données confidentielles sur un serveur, et l'utilisation sécurisée de données confidentielles au moyen de différents clients d'application. Grâce au chiffrement cryptographique des données confidentielles et à l'autorisation de tous les clients d'application au moyen d'un client d'authentification, l'utilisateur conserve la maîtrise totale de ses données confidentielles disponibles sur le serveur à tout moment, tandis qu'un niveau élevé de convivialité d'utilisation des données confidentielles est assuré. Le procédé ne nécessite pas de mot de passe maître et comprend une authentification à deux facteurs.
PCT/EP2024/058675 2023-03-29 2024-03-28 Procédé basé sur serveur innovant pour la gestion de données confidentielles Ceased WO2024200764A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
LU103094A LU103094B1 (de) 2023-03-29 2023-03-29 Innovatives serverbasiertes verfahren zum management geheimer daten
LULU103094 2023-03-29

Publications (1)

Publication Number Publication Date
WO2024200764A1 true WO2024200764A1 (fr) 2024-10-03

Family

ID=86226588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/058675 Ceased WO2024200764A1 (fr) 2023-03-29 2024-03-28 Procédé basé sur serveur innovant pour la gestion de données confidentielles

Country Status (2)

Country Link
LU (1) LU103094B1 (fr)
WO (1) WO2024200764A1 (fr)

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080031447A1 (en) 2006-08-04 2008-02-07 Frank Geshwind Systems and methods for aggregation of access to network products and services
US20100169368A1 (en) * 2004-12-22 2010-07-01 Neill Richard W System and associated methods for remotely enabling features
US8589442B2 (en) 2006-03-22 2013-11-19 Alibaba Group Holding Limited Intersystem single sign-on
US8904180B2 (en) 2001-03-09 2014-12-02 Ca, Inc. Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys
US9003015B2 (en) * 2010-12-21 2015-04-07 Sitecore A/S Method and a system for managing a website using profile key patterns
US9590959B2 (en) 2013-02-12 2017-03-07 Amazon Technologies, Inc. Data security service
US9727715B2 (en) 2014-09-07 2017-08-08 Michael Boodaei Authentication method and system using password as the authentication key
US9948648B1 (en) 2013-03-14 2018-04-17 Dell Software Inc. System and method for enforcing access control to publicly-accessible web applications
EP2332114B1 (fr) 2008-08-08 2018-08-22 Microsoft Technology Licensing, LLC Remplissage de formulaires à l'aide d'identités numériques, et génération automatique de mots de passe
US10341334B2 (en) 2007-06-22 2019-07-02 Google Llc Web based system that allows users to log into websites without entering username and password information
US10491588B2 (en) 2017-03-23 2019-11-26 Baldev Krishan Local and remote access apparatus and system for password storage and management
US10893045B2 (en) 2013-08-29 2021-01-12 Liberty Labs Limited System for accessing data from multiple devices
EP3420677B1 (fr) 2016-02-26 2021-08-11 CA, Inc. Système et procédé d'appariement mobile en service assisté d'une connexion informatique sans mot de passe
US20220209955A1 (en) 2020-12-20 2022-06-30 Secret Double Octopus Ltd System and method for performing a secure online and offline login process

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8904180B2 (en) 2001-03-09 2014-12-02 Ca, Inc. Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys
US20100169368A1 (en) * 2004-12-22 2010-07-01 Neill Richard W System and associated methods for remotely enabling features
US8589442B2 (en) 2006-03-22 2013-11-19 Alibaba Group Holding Limited Intersystem single sign-on
US20080031447A1 (en) 2006-08-04 2008-02-07 Frank Geshwind Systems and methods for aggregation of access to network products and services
US10341334B2 (en) 2007-06-22 2019-07-02 Google Llc Web based system that allows users to log into websites without entering username and password information
EP2332114B1 (fr) 2008-08-08 2018-08-22 Microsoft Technology Licensing, LLC Remplissage de formulaires à l'aide d'identités numériques, et génération automatique de mots de passe
US9003015B2 (en) * 2010-12-21 2015-04-07 Sitecore A/S Method and a system for managing a website using profile key patterns
US9590959B2 (en) 2013-02-12 2017-03-07 Amazon Technologies, Inc. Data security service
US9948648B1 (en) 2013-03-14 2018-04-17 Dell Software Inc. System and method for enforcing access control to publicly-accessible web applications
US10893045B2 (en) 2013-08-29 2021-01-12 Liberty Labs Limited System for accessing data from multiple devices
US9727715B2 (en) 2014-09-07 2017-08-08 Michael Boodaei Authentication method and system using password as the authentication key
EP3420677B1 (fr) 2016-02-26 2021-08-11 CA, Inc. Système et procédé d'appariement mobile en service assisté d'une connexion informatique sans mot de passe
US10491588B2 (en) 2017-03-23 2019-11-26 Baldev Krishan Local and remote access apparatus and system for password storage and management
US20220209955A1 (en) 2020-12-20 2022-06-30 Secret Double Octopus Ltd System and method for performing a secure online and offline login process

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HEYLOGIN GMBH: "heylogin White Paper", 6 April 2022 (2022-04-06), pages 1 - 16, XP093084091, Retrieved from the Internet <URL:https://web.archive.org/web/20220528040652/https://www.heylogin.com/files/heylogin-security-whitepaper-en-v1-4.pdf> [retrieved on 20230914] *

Also Published As

Publication number Publication date
LU103094B1 (de) 2024-09-30

Similar Documents

Publication Publication Date Title
US11316685B1 (en) Systems and methods for encrypted content management
EP2020797B1 (fr) Appareil et procédé de passage de jetons opaques pour le serveur client
DE60314402T2 (de) System und methode zum speichern sowie abrufen kryptographischer geheimnisse von unterschiedlichen kundenendgeräten in einem netzwerk
EP3732605B1 (fr) Dépôt et accès sûrs à des fichiers au moyen d&#39;une application web
US8059818B2 (en) Accessing protected data on network storage from multiple devices
DE102009001718B4 (de) Verfahren zur Bereitstellung von kryptografischen Schlüsselpaaren
DE112015002927B4 (de) Generierung und Verwaltung geheimer Chiffrierschlüssel auf Kennwortgrundlage
EP2289222B1 (fr) Procédé, serveur d&#39;authentification et serveur prestataire de services pour l&#39;authentification d&#39;un client
DE112008001436T5 (de) Sichere Kommunikation
EP2544117A1 (fr) Procédé et système pour partager et stocker des données personnelles sans perte de confidentialité
DE112015000213T5 (de) Passwortgestützte Berechtigungsprüfung
DE212015000047U1 (de) Sichere Anmeldung ohne Passwörter
EP2929648A1 (fr) Procédé pour établir une liaison sûre entre des clients
EP1777907B1 (fr) Méthode et dispositifs pour effectuer des opérations cryptographiques dans un réseau type client-server
CN110519222B (zh) 基于一次性非对称密钥对和密钥卡的外网接入身份认证方法和系统
DE202025101951U1 (de) System zur adaptiven Multi-Faktor-Authentifizierung mit NFC-Tags in Identitätsmanagement-Netzwerken
DE202025100477U1 (de) System für sichere IoT-Geräteauthentifizierung und Datenübertragung
DE102017006200A1 (de) Verfahren, Hardware und System zur dynamischen Datenübertragung an ein Blockchain Rechner Netzwerk zur Abspeicherung Persönlicher Daten um diese Teils wieder Blockweise als Grundlage zur End zu Endverschlüsselung verwendet werden um den Prozess der Datensammlung über das Datenübertragungsmodul weitere Daten in Echtzeit von Sensoreinheiten dynamisch aktualisiert werden. Die Blockmodule auf dem Blockchaindatenbanksystem sind unbegrenzt erweiterbar.
LU103094B1 (de) Innovatives serverbasiertes verfahren zum management geheimer daten
Beurdouche et al. RFC 9750: The Messaging Layer Security (MLS) Architecture
EP4576652A1 (fr) Système de stockage sécurisé et centralisé d&#39;une clé numérique
DE102014114432B4 (de) Verfahren, Vorrichtung und Computerprogramm zum Kontrollieren eines Zugriffsauf einen Service innerhalb eines Netzwerkes
Zhang et al. Improved CP-ABE Algorithm Based on Identity and Access Control
KR100842014B1 (ko) 다수의 장치로부터 네트워크 저장 장치상의 보호 데이터에대한 접근
EP3355548A1 (fr) Procédé et système d&#39;authentification d&#39;utilisateur

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24719998

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 24719998

Country of ref document: EP

Kind code of ref document: A1