WO2024200764A1

WO2024200764A1 - Innovative server-based method for management of confidential data

Info

Publication number: WO2024200764A1
Application number: PCT/EP2024/058675
Authority: WO
Inventors: Dominik SCHÜRMANN; Vincent BREITMOSER
Original assignee: Heylogin Gmbh
Priority date: 2023-03-29
Filing date: 2024-03-28
Publication date: 2024-10-03
Also published as: LU103094B1

Abstract

The present invention relates to a computer-implemented method for the secure management of confidential data on a server, and the secure use of confidential data by means of different application clients. Through cryptographic encryption of the confidential data and the authorisation of all application clients by means of an authenticator client, the user retains full control over their confidential data available on the server at all times, while at the same time maintaining a high level of user-friendliness of the use of the confidential data. The method does not require a master password and comprises two-factor authentication.

Description

INNOVATIVE SERVER-BASED METHOD FOR MANAGING SECRET

DATA

TECHNICAL FIELD

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. 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.

STATE OF THE ART

The use of user names and passwords is a widely used method of authenticating a user when attempting to access a web application or computer-implemented application. 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.

At the same time, the number of user accounts in various applications that users try to secure with passwords is growing. This results in a conflict of objectives between IT security and user-friendliness. If all access is secured with the same password, there is a single point of failure and a high level of severity of the problem if this password is broken. If passwords are chosen to be too simple and easy to remember, they can be guessed. If they are too short, there is a chance of guessing the password using brute force methods. If a user stores his passwords centrally and unencrypted for greater user-friendliness, an attacker can compromise this directory.

Classic password managers try to solve the problems of user-friendliness by using a master password. All password data is stored centrally and access using the master password. However, such systems reveal clear disadvantages in terms of IT security. The master password is a single point of failure and is a lucrative attack vector for attackers. With offline password managers, it can be determined using brute force methods if the master password is not long and strong enough. Studies reveal that users are often unable to generate a sufficiently long and strong password and remember it without revealing it in plain text as a reminder. The master password can also be spied on using key logging or other malware, or the user can be instructed to enter their master password in the wrong place using phishing or similar methods.

Classic password managers are also generally suboptimal in terms of user-friendliness, as they require the regular entry of the master password, which should be as strong as possible.

Classic password managers usually offer the option of two-factor authentication (2FA), but users often only trust their password. 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.

Nevertheless, such solutions are based on access to the respective user account and thus via a master password and do not necessarily require 2FA. Depending on the procedure, the encryption of the password data on the server is not always controlled by the client devices themselves. If the encryption of the server-side password data has already been carried out by a client device, there is no guarantee that the key material for decryption is stored securely locally, for example on a security chip. A central access management system that Password sharing or individual management of individual devices of a user account and their access rights are generally not possible.

Another way of using and storing passwords is through “Single Sign-On” (SSO) procedures. 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. In addition, 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.

One disadvantage of SSO procedures is the inexhaustibility of the services and applications that must be integrated into the procedure. For example, in ticketing systems, the circle of trust must be extended to as many services and applications as possible in order to achieve a high level of user-friendliness. A user cannot be sure that, for example, every web application is supported by the SSO procedure. In particular, SSO procedures that are highly user-friendly due to the integration of many services and applications are usually expensive. Sharing access data is also not usually provided for in SSO procedures. In addition, depending on the initial authentication, 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.

Regardless of the authentication and access management process, 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. For example, 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. Such a hash function is provided, for example, by the Secure Hash Algorithm (SHA). With a hash function, a data block that is not necessarily limited in size can be mapped to a data block of fixed size, the hash. 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.

However, 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. By sending a certificate to make contact, 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.

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

Communication channel for initiating an encrypted data exchange between multiple parties.

The algorithms or functions for creating cryptographic keys from, for example, a random number sequence must meet special requirements. Not only must the secret key be able to decrypt the message encrypted using the public key. It must also be impossible or virtually impossible to deduce the secret key from the public key of an asymmetric key pair. In order to meet these requirements, various cryptographic systems with various one-way functions such as the SHA described above exist. Mathematically, it has not been proven that these one-way functions cannot be reversed by an attacker with sufficiently high computing power in asymmetric encryption methods, i.e. that a private key cannot be derived from the public key. In theory, symmetric encryption such as the one-time pad offers even greater security than asymmetric encryption. A constantly evolving state of the art and the use of widely respected open source standards for the underlying Cryptographic systems and functions, such as Curve25519 for asymmetric encryption, are one approach to ensure a high level of security.

Transport Layer Security (TLS) 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.

Below, some concrete approaches from the state of the art are described to provide procedures for secure and user-friendly management of secret data, usually related to password data.

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. However, 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, on the other hand, 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. By using two-part symmetric keys to encrypt and decrypt the secret data, which is stored on a client device and additionally on the server side, a possibility for 2FA is disclosed, which would also be implicitly conceivable with a smartphone as a second factor. However, the patent does not disclose any methods for the controlled authentication of other, trustworthy clients. Furthermore, 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. However, 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. 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. In the offline version, however, 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. However, 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. In this invention, 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. However, 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. In this case, 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. However, 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.

TASK

It is therefore the object of the present invention to provide a method for the secure storage, use and management of secret data, such as passwords in particular. 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. However, 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. In addition, the authorizations to access the secret data should be flexibly assigned and assigned to users and shareable between users.

SOLUTION

The object is achieved by a method having the features of claim 1.

Further advantageous embodiments and developments emerge from the subclaims and from the description with reference to the figures.

GENERAL BENEFITS

Advantageously, 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. However, 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. By using a mobile phone with access protection as the authenticator client, 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.

DETAILED DESCRIPTION

The invention is described in detail below. The present invention is explained in more detail without restricting the invention to these descriptions. Where the term "can" is used in this application, this refers to both the technical possibility and the actual technical implementation. The singular includes the plural, unless the context clearly indicates otherwise.

In particular, the term key pair implies that it is an asymmetric key pair comprising a private and a public key. The term client includes both an authenticator client and an application client with its application client extension.

The method according to the invention is based on three basic steps (S01) to S03). In step S01), 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.

To initialize the push authenticator on the authenticator client, 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). By possessing the private login key, a client can authenticate itself against the server. In this method, 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. For such an authentication process, it is preferred to create a signature for a message that is sent when the client contacts the server, using the private login key. By checking the signature using the public login key, 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.

In 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. In a second sub-step of S02), the application client uses the private login key to authenticate itself against the server in the manner already described.

In a third sub-step of S02), 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. In a preferred variant, a software functionality for creating cryptographic keys on the application client is provided by an application client extension described later. In a particularly preferred variant, 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. In a preferred embodiment of the method, all linked clients or their sessions are displayed in list form on the authenticator client. In a particularly preferred embodiment, 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. In this variant, any contact by the application client without a session with the server is rejected by the server. In a particularly preferred variant, 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. In a further preferred variant, 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. In a particularly preferred embodiment, the status of the session is retrieved for the first time by the application client immediately when the application client extension is started. In another particularly preferred variant, 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. In another preferred variant, 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. In another preferred variant, 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.

In 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. In a preferred embodiment, 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. In principle, 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. In addition, alternative secret data can also be stored in safes according to the invention, for example payment and credit card information or addresses. In another version of the safe, other data types that can be defined by the user, such as free text for secret notes or image data, can also be stored.

In a first sub-step for the purpose of storing and retrieving secret data in step S03), the safe containing secret data is encrypted using a symmetric key. In the event that multiple push authenticators are to be granted access to the safe, 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.

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.

In a third sub-step of S03), 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. In one possible embodiment, 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. In another variant, the private encryption key is transmitted to the application client together with the private login key in step S02). In a preferred embodiment of the two transmission variants, 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.

Advantageously, the authenticator client controls the authorized clients through this configuration, particularly in step S02) and any access to the secret data in step S03). Another advantage is that the authenticator client is used as a second factor for an attempt to retrieve secret data from the application client. In a preferred embodiment, the authenticator client is required to activate a protective function of the device, for example through biometric authentication. This 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). 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.

As already described, in a preferred embodiment of the invention, 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).

In a special embodiment, an authenticator client is used simultaneously as an application client. In this case, 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. For example, 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. In this case, 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. Instead, in a standard embodiment, 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. At the same time, 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.

The wide range of encryption variants results in a number of advantages in terms of the flexibility of the entire method according to the invention. On the one hand, there is an advantage in terms of the tidiness and clarity of the encryption method, which can also be referred to as "key hygiene". Profiles allow separate keys to be created in profiles for separate contexts, for example in profiles for private use and for company use. Profiles are to be viewed completely independently of one another, since there are no dependencies between random profile start values or profile keys of profiles or between profiles and push authenticators. Thinking further and more specifically, this key hygiene advantageously allows the creation of meaningful roles and assignments within the system according to the invention.

For example, in a preferred embodiment, 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. Furthermore, 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.

The use of profiles is also fundamentally advantageous in relation to the crypto agility of the invention or the organization that uses the method according to the invention. For example, 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.

In a preferred embodiment, any key material associated with a profile is created from a random profile seed. In this preferred embodiment, encrypting a profile, e.g. by the Encryption key of the associated push authenticator that the random profile seed is encrypted.

In one embodiment, 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. Advantageously, other functions can thus be implemented in the same encryption architecture in addition to storing and retrieving secret data.

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.

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.

In another variant, 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. In a preferred embodiment variant following the introduction of profiles, 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.

In one embodiment, 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.

In an alternative, preferred embodiment, 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. Advantageously, the access of the profiles or push authenticators to a safe can thus be established and managed independently of one another.

As already described, 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.

These possible implementation variants can, for example (but not preferred), give a single push authenticator and two profiles access to a symmetric key, with two different push authenticators having access to each profile. This would give a total of 5 different push authenticators access to the associated safe. In another possible but not particularly preferred implementation variant, for example, 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.

In a preferred embodiment, 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. By implementing two sequential profiles, certain authorization chains can advantageously be implemented even more simply and, from a key hygiene perspective, even more cleanly. For example, 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. For example, a parent or guardian can temporarily take over access to a child's access data. In another application example, 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.

In a particularly preferred embodiment of the sequential insertion of two

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.

In a particularly preferred embodiment, 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.

In a particularly preferred embodiment of the sequential use of two profiles to implement an authorization structure for at least one administrator of the secret data of an organization, 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.

In a particularly preferred embodiment, 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. In the case of encryption of a profile, the profile is continued as a free profile, with placeholders being used as encryptions. When the profile is returned or handed over, 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.

In a preferred embodiment of the method according to the invention, 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.

In a preferred embodiment corresponding to the use of the method according to the invention as a password manager, 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. In an alternative application of the method according to the invention for online trading, for example, billing addresses could be stored in the metadata area and credit card information in the sensitive data area.

Through access or lack of access to the private high-security key or the private profile high-security key, access to a second area with more sensitive data can be gradually determined. 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.

In a particularly preferred embodiment, 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.

In a further preferred variant, 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.

In a preferred embodiment of the use of access control of a metadata area and a sensitive data area of the safe, 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. In a particularly preferred embodiment, 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. Furthermore, these binary switches for setting the state are preferably displayed within the previously described list overview of all clients on the authenticator client.

In a particularly preferred embodiment of the control of the open or closed state of an application 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. At the same time, 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. Advantageously, 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.

In a further preferred embodiment of the method according to the invention, 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. During the signing process, 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. Using the public identification key and the signature, 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. At the same time, 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.

In a further preferred embodiment of the method according to the invention, 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. When authorizing other devices by transmitting multiple private keys to them, 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. In a particularly preferred embodiment, 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. In particular, when authorizing the coupling of an application client, the random authenticator start value is transmitted in encrypted form instead of the private login key. In addition, when authorizing the storage or retrieval of secret data by the application client, 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. In a particularly preferred embodiment variant, 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. In a particularly preferred embodiment, 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.

In a further preferred embodiment of the method according to the invention, the key pairs belonging to a push authenticator, identification key pair, coding key pair and high-security key pair (excluding the login key pair), are derived from a random salt value in addition to the 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 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.

In a further preferred embodiment of the method according to the invention, 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.

In a particularly preferred embodiment of the recovery function, when the push authenticator is initialized on 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. As an example, but not as a limitation, iOS and Android offer encrypted cloud backups for their mobile applications, which are used for the backup authenticator.

In an alternative, particularly preferred variant, a backup code can be retrieved by the user from the mobile application. When 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. In this embodiment of the recovery function, the user himself is responsible for security against spying, manipulation and loss of the backup code.

In a particularly preferred embodiment of the recovery function, when the new authenticator client is initialized using one of the described or another recovery function, 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.

In a further preferred embodiment of the method according to the invention, an application client comprises an associated application client extension that is locally connected to and on the application client. In a particularly preferred embodiment, 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.

In a particularly preferred embodiment, 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. In another embodiment, 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. In another embodiment, 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.

In a particularly preferred embodiment, 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.

In a further preferred embodiment of the method according to the invention, 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. In a particularly preferred variant, a mobile application as already described is installed on the authenticator client, which in this In the event that authorization is required, the user is prompted to perform the swipe gesture using a simple graphical user interface. In a particularly preferred embodiment, in addition to performing the swipe gesture, 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.

In a further preferred embodiment of the method according to the invention, 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. In this embodiment, 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. In a particularly preferred embodiment, 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.

In a further preferred embodiment of the method according to the invention, 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. in the forwarding function. Particularly preferably, 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.

In a particularly preferred embodiment, 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.

In a particularly preferred embodiment of coupling an application client using an asymmetric exchange key pair, 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. In a further particularly preferred embodiment, 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.

In general, 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.

A computing unit can be represented by a processor, a computer processor (CPU = Central Processing Unit), a graphics processor (GPU = Graphics Processing Unit), a computer, a computer system, an application-specific integrated circuit (ASIC = Application-Specific Integrated Circuit), an integrated circuit (IC = Integrated Circuit), a single-chip system (SOC = System on Chip), a programmable logic element or a field-programmable gate array with a microprocessor (FPGA = Field Programmable Gate Array).

In addition to the method described in detail, 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. In a preferred embodiment, 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. In a preferred embodiment, the server also includes an application-specific integrated circuit (ASIC) for efficient encryption, for checking signatures or certificates and for executing hash functions.

In addition to the extensively described method and the server, 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:

• Generating or deriving all asymmetric key pairs on an authenticator client,

• Creating and sending as well as receiving and evaluating requests to or from the server

• Access interfaces for using the camera, protection element, protection function and memory of the authenticator client

• Storing private keys and values

• Providing a user interface that provides functions for authorizing (e.g. using a swipe gesture), listing all paired clients, changing the status and removing sessions from clients, creating and sharing a profile, entering a public exchange key to pair an application client (in particular via camera and QR code), prompting the user to verify using the smartphone's protection function as an authenticator client. In addition to the extensively described method, the server and a computer program product A, the present invention also includes a computer program product B. This includes commands which, when executed by a computing unit on an application client, cause the client to execute 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:

• Generating or deriving all asymmetric key pairs on an application client,

• Access interfaces for using the application client's protection element and memory

• Storing private keys and metadata of secret data

• Access to interface for local communication with an associated application client extension

• Providing at least one user interface that provides functions for retrieving session status, creating and displaying a public exchange key for coupling with a server and authenticator client (in particular via QR code), detecting the awareness status of a web application, creating and displaying overlays, displaying an authorization request for the authenticator client, automatically filling in secret data, storing secret data.

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. In a preferred embodiment, the primary computer program product of the application client is a web application, while the application client extension is implemented as a browser add-in. In this preferred embodiment, 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, on the other hand, 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. In addition to the extensively described method, the server and the computer program products A and B, the present invention also includes a computer program product C. This includes commands which, when executed by a computing unit on the server, cause the server 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 server. These include in particular, but not restrictively, the following method steps and features:

• Generating or deriving all symmetric keys,

• Accessing the network connections to create and send as well as receive and evaluate requests to or from the clients, in particular acting as a proxy to forward communication between clients,

• Access to memory and special ASICs for encryption, verification of signatures and certificates or execution of hash functions,

• Storing encrypted private keys, public keys and secret data in vaults, in particular generating a systematic database-like data management so that vaults, keys, values, sessions, tokens and account data are correctly assigned to each other and to the respective users and clients,

In addition to the extensively described method, the server and the computer program products A, B and C, 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.

Further advantages, features and possible applications of the present invention also emerge from the following description of embodiments and the drawings. The features mentioned in the claims and in the description can be essential to the invention individually or in any combination. In addition, it should be noted that the person skilled in the art will undoubtedly recognize that the individual features described in the above specific embodiments can be combined with one another in an appropriate manner, provided there is no contradiction, whereby a separate description of various possible combinations is omitted in order to avoid unnecessary repetition. EXAMPLES OF IMPLEMENTATION

The above-described characteristics, features and advantages of this invention, as well as the manner in which they are achieved, will be more clearly and distinctly understood in connection with the following drawings and descriptions of the basic principles and embodiments of the present invention.

The present invention is explained in more detail without restricting the invention to these drawings and descriptions. If the term "can" is used in this application, this refers to both the technical possibility and the actual technical implementation. Features shown in the individual figures and described for the respective example are not restricted to the respective individual example. The singular includes the plural, unless the context clearly indicates otherwise.

In the following drawings, 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.

Below shows:

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. In the preferred embodiment shown here, 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

Devices. The arrows represent the process-specific communication channels 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. In addition, 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. In contrast to the push authenticator (1.5), 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. In the embodiment shown 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

Variant using a profile (1.7), whereby it should be noted that such an encryption variant can also be carried out directly by a push authenticator in a variant without a profile. 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). In a preferred variant, both symmetric keys (3.1, 3.2) 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). In the profile at the bottom left, as in Fig. 4, 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. While 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) and the random profile high-security seed (4.2.2) is encrypted by at least the public high-security key

(2.4.2) of the push authenticator (1.5) is stored on the server. This means that only this push authenticator (1.5) can gain access to this profile by decrypting the random start values (4.2.1 and 4.2.2) of the profile. In addition, a backup authenticator (1.6) is set up in this version, with which the random start values (4.2.1 and 4.2.2) of the profile are stored again on the server in the same encrypted form. 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. In 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. In 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

(2.7.3) session key. 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. In addition, 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. However, 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

(2.2.3) and login key (2.1.3) or a profile (1.7) access to its private identification key and high security profile key. This allows or prohibits access to sensitive data within the secret data and can be controlled via an authenticator client.

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. In this embodiment, 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). In this preferred embodiment, however, 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). Using the symmetric key (3.1) alone, the push authenticator can only access the metadata area (3.3.5) and the metadata (3.3.6) contained therein. To access the sensitive data (3.3.4) in the sensitive data area (3.3.3), 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. In the first state at the top left, 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

(1.4.1) is scanned by the authenticator client. This QR code (2.8.4) contains a public exchange key

(2.8.2), whereby login keys or random starting values can be exchanged in an encrypted and secure manner between the authenticator client and the application client and the application client can be coupled. In the coupled state, 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.

In the different figures, parts that are equivalent in terms of their function are always provided with the same reference symbols, so that they are usually only described once.

The embodiments of the invention shown are to be understood as examples and not as restrictive. The invention can also be carried out in a different manner. Therefore, all equivalent structural changes made by applying the description of the invention are to be included in the scope of the patent application. REFERENCE SYMBOL LIST

(1.1) Server

(1.2) Authenticator client

(1.3) Application client

(1.4.1) Application client extension

(1.4.2) Overlay

(1.4.3) Form

(1.5) Push Authenticator

(1.6) Backup Authenticator

(1.7) Profile

(2.1.1) Login key pair

(2.1.2) Public login key

(2.1.3) Private login key

(2.2.1) Identification key pair

(2.2.2) Public identification key

(2.2.3) Private identification key

(2.2.4) Signing process

(2.3.1) Encryption key pair

(2.3.2) Public encryption key

(2.3.3) Private encryption key

(2.4.1) High security key pair

(2.4.2) Public high-security key

(2.4.3) Private high-security key

(2.5.1) Profile key pair

(2.5.2) Public profile key

(2.5.3) Private profile key (2.6.1) Profile high-security key pair

(2.6.2) Public profile high security key

(2.6.3) Private profile high security key

(2.7.1) Session key pair

(2.7.2) Public session key

(2.7.3) Private session key

(2.7.4) Session

(2.7.5) Session token

(2.8.1) Replacement key pair

(2.8.2) Public exchange key

(2.8.3) Private exchange key

(2.8.4) Exchange QR code

(3.1) Symmetric key

(3.2) Symmetric high-security key

(3.3.1) Safe

(3.3.2) secret data

(3.3.3) Sensitive data area

(3.3.4) Sensitive data

(3.3.5) Metadata area

(3.3.6) Metadata

(3.3.7) Handover

(4.1) Random authenticator seed

(4.2.1) Random profile starting value

(4.2.2) Random profile high security seed

(4.3) Random salt value

(4.4) Random profile salt value

Claims

PATENT CLAIMS

1. Computer-implemented procedure for secure management of secret data (3.3.2) on a server (1.1) and secure use of the secret data

(3.3.2), comprising the steps:

501) Initializing at least one push authenticator (1.5) on an initial authenticator client (1.2), comprising the

Generating at least two asymmetric key pairs belonging to the push authenticator (1.5), a login key pair (2.1.1) from a private login key (2.1.3) and a public login key (2.1.2) and an encryption key pair (2.3.1) from a private encryption key

(2.3.3) and a public encryption key (2.3.2) and

Storing the public login key (2.1.2) and the public encryption key (2.3.2) of the push authenticator (1.5) on the server (1.1),

502) coupling at least one application client (1.3) to the server (1.1), comprising the

Authorization by the authenticator client (1.2) by means of encrypted exchange of the private login key (2.1.3) from the push authenticator (1.5) with the application client (1.3),

Authenticating the application client (1.3) against the server (1.1) using the login key pair (2.1.1) and creating a session (2.7.4) for the application client (1.3) on the server (1.1) by depositing a public session key (2.7.2) of a session key pair (2.7.1) generated by the application client (1.3),

503) Storage or retrieval of secret data (3.3.2) by the application client

(1.3) to or from a safe (3.3.1) located on the server (1.1), comprising the Encrypting the vault (3.3.1) when storing it and decrypting the vault (3.3.1) when retrieving it, whereby the encryption or decryption is achieved by a symmetric key (3.1) stored on the server (1.1),

Encrypting the symmetric key (3.1) with the public encryption key (2.3.2) of the push authenticator (1.5) and

Storing or retrieving by authorizing an encrypted retrieval of the private encryption key (2.3.3) of the push authenticator (1.5) by the authenticator client (1.3) for decrypting the symmetric key (3.1), characterized in that at least one profile (1.7) is used as an indirection level in addition to the push authenticator (1.5), wherein the symmetric key (3.1) is encrypted by a public profile key (2.5.2) of a profile key pair (2.5.1) of the profile (1.7), wherein the profile (1.7) is encrypted by the public encryption key (2.3.2) of the push authenticator (1.5).

2. The method according to claim 1, wherein the symmetric key (3.1) is encrypted by one or more different public profile keys (2.5.2) or public encryption keys (2.3.2) of multiple profiles (1.7) or push authenticators (1.5).

3. Method according to one of claims 1 to 2, wherein two profiles are used sequentially so that at least a first profile (1.7) is encrypted directly by the public profile key (2.5.2) of the profile key pair (2.5.1) of at least a second profile (1.7).

4. The method according to claim 3, wherein the first profile (1.7) encrypts all vaults (3.3.1) belonging to an organization and wherein the at least second profile (1.7) is managed by the push authenticators (1.5) of an administrator of the organization.

5. The method according to claim 4, wherein the administrator of the organization is able to delete all encryptions according to method step S03) of his organization, to replace them with placeholders and to generate new ones.

6. Method according to one of claims 1 to 5, wherein the safe (3.3.1) comprises a sensitive data area (3.3.3) and a metadata area (3.3.5), wherein the sensitive data area (3.3.3) is additionally encrypted by a symmetric high-security key (3.2) stored on the server, wherein the symmetric high-security key (3.2) is encrypted by means of a public high-security key (2.4.2) of a high-security key pair (2.4.1) of a push authenticator (1.5) or a public profile high-security key

(2.6.2) of a profile high security key pair (2.6.1) of a profile (1.7).

7. The method according to claim 6, wherein the high security key pair (2.4.1), the profile high security key pair (2.6.1) and the login key pair (2.1.1) cannot be stored on a permanent memory of clients, i.e. authenticator clients (1.2) or application clients (1.3).

8. Method according to one of claims 6 to 7, wherein a coupled application client (1.3) is placed in a closed state in which this application client (1.3) does not receive access to the private high-security key (2.4.3).

9. The method according to any one of claims 6 to 8, wherein a coupled application client (1.3) is placed in an open state in which the application client (1.3) receives access to the private high-security key (2.4.3).

10. Method according to one of claims 1 to 9, wherein the integrity of the public encryption keys (2.3.2), high security keys

(2.4.2), profile key (2.5.2), profile high-security key (2.6.2) and session key (2.7.2) is ensured by a signing process (2.2.4) using a private identification key (2.2.3) of an identification key pair (2.2.1) of the associated push authenticator (1.5) or profile (1.7).

11. The method according to one of claims 1 to 10, wherein the key pairs (2.1.1, 2.2.1, 2.3.1, 2.4.1, 2.5.1, 2.6.1) of a push authenticator (1.5) or a profile (1.7) are derived from at least one random authenticator start value (4.1) or profile start value (4.2.1, 4.2.2).

12. The method according to claim 11, wherein to derive the key pairs (2.1.1, 2.2.1, 2.3.1, 2.4.1, 2.5.1, 2.6.1) of a push authenticator (1.5) or a profile (1.7), a random salt value (4.3) or profile salt value (4.4) is additionally used and stored on the server (1.1) for the push authenticator (1.5) or the profile (1.7).

13. The method according to any one of claims 1 to 12, wherein the method comprises a recovery function which enables the use of a new authenticator client (1.2) and all previous secret data (3.3.2) without the initial authenticator client (1.2).

14. Method according to one of claims 1 to 13, wherein in addition to the application client (1.3) an associated application client extension (1.4.1) is coupled, which stores and retrieves metadata (3.3.6) of the session (2.7.4) and displays overlays (1.4.2) for stored secret data (3.3.2) on Internet pages.

15. The method according to claim 14, wherein the application extension (1.4.1) automatically recognizes various forms (1.4.3) of a website and can fill them out if desired.

16. The method according to any one of claims 1 to 15, wherein the authorization of the application client (1.3) as well as the storage and retrieval of secret data (3.3.2) by the application client (1.3) are carried out by means of a simple swipe gesture on a smartphone as an authenticator client (1.2).

17. The method according to any one of claims 1 to 16, wherein a session (2.7.4) comprises a session token (2.7.5) generated by the server (1.1), which allows at least the client belonging to the session (2.7.4) to send requests to the server (1.1).

18. The method according to one of claims 1 to 17, wherein the coupling of the application client in step S02) is initialized by entering a public exchange key (2.8.2) of an exchange key pair (2.8.1) created and issued by the application client (1.3) into the authenticator client (1.2), and wherein the private login key (2.1.3) is encrypted with the public exchange key (2.8.2) during the exchange from the authenticator client (1.2) to the application client (1.3).

19. The method according to claim 18, wherein the public exchange key (2.8.2) is contained in an exchange QR code (2.8.4) generated and displayed by the application client (1.3), which is detected by the authenticator client (1.2).

20. Server (1.1), comprising at least one computing unit for executing computer programs, network connections for exchanging data at least with the clients belonging to the method according to one of claims 1 to 19 in a network, and at least one storage medium for storing at least computer programs, keys, values, sessions and safes.

21. Computer program product A, comprising instructions which, when executed by an authenticator client, cause the authenticator client to carry out the method according to one of claims 1 to 19.

22. Computer program product B, comprising instructions which, when executed by an application client, cause the application client to carry out the method according to one of claims 1 to 19.

23. Computer program product C, comprising instructions which, when executed by the server, cause the server to carry out the method according to one of claims 1 to 19.

24. System comprising a server (1.1) according to claim 20, a computer program product A according to claim 21, a computer program product B according to claim 22 and a computer program product C according to claim 23.