LU103094B1 - INNOVATIVE SERVER-BASED METHOD FOR MANAGING SECRET DATA - Google Patents

Abstract

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 high user-friendliness when using the secret data. The method does not require a master password and includes two-factor authentication.

Description

INNOVATIVE SERVER-BASED METHOD FOR MANAGING SECRET INFORMATION LU103094

DATA

TECHNICAL FIELD

The present invention relates to a computer-implemented method for a secure

Management of secret data on a server and the secure use of secret

Data using various application clients. The user retains the data through cryptographic

Encryption of the secret data and the authorization of all application clients using an authenticator client ensures full control over the secret data available on the server at all times, while at the same time making the use of the secret data highly user-friendly. The process 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 inventive

procedure.

STATE OF THE ART

The use of usernames and passwords is a widely used method of

Authentication of a user when attempting to access a

Web application or computer-implemented application. A password is set by the user at least during initialization and must be kept secret. If the

If a potential attacker displays, intercepts or retrieves a password in unencrypted form, can guess it or calculate it, 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 is growing,

Attempt to secure users with passwords. This results in a conflict of objectives between IT security and user-friendliness. If all accesses are secured by the same

Password protected, this results in a single point of failure and a high level of severity of the

Problem if this password is broken. If passwords are too simple and easy to remember, they can be guessed. If they are too short, there are opportunities to

Brute-force methods to guess the password. If a user stores his passwords centrally and unencrypted for increased user-friendliness, an attacker can

Compromise directory.

Classic password managers try to solve the problems of user-friendliness by

master password. All password data is stored centrally and access white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application granted using the master password. Such systems nevertheless reveal clear disadvantages LU103094 in IT security. The master password as a single point of failure is a lucrative attack vector for attackers. With offline password managers, it can be broken by brute force

Methods can be determined if the master password is not long and strong enough.

Studies reveal that users are often unable to generate and remember a sufficiently long and strong password without revealing it in plain text as a reminder. Key logging or other malware can also

Master password is spied on or the user is tricked by phishing or similar methods to

be instructed to enter their master password in the wrong place.

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 done via a second method, for example confirming a login by entering an SMS code in addition to the

Password. In this case, factors that a user remembers (e.g. password) can be combined 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 fraudulent authentication.

An alternative way of using and storing passwords is to use cloud-based, centralized password management solutions, such as those offered by Google or

Apple for the browsers of clients. This provides access to the

Passwords are secured, for example, by the existing account with the respective provider. This results in user-friendly functions such as synchronization in all

Client devices on which a user is logged in. Furthermore, the server-based

Storing passwords relatively simple Brute-force attacks by controlling the

Prevent the frequency of login attempts.

Nevertheless, such solutions are based on access to the respective

User account and therefore 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 locally, for example on a security chip. A central access management system that white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Password sharing or individual management of individual devices of a user account LU103094 and their access rights are generally not possible.

Another possibility for using and storing passwords is 'Single-Sign-

On” (SSO) procedure. SSO procedure offers a user the possibility of easy

Access to all services and applications of his authorization through one-time

Authentication. SSO procedures are widely offered as a software-as-a-service (SaaS) model. Such password managers as described above can be seen as an example of a local SSO system, where a local client, with which a user authenticates, automatically fills in all access data. In addition, SSO procedures are common that use a single portal, which in turn

Login for other services and applications, or ticketing systems that operate within a trusted circle of services or applications

Evidence of a user’s authentication is transmitted and thus used in all services and

applications a registration is carried out.

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 every web application, for example, is supported by the SSO procedure.

In particular, SSO procedures with high user-friendliness through 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 needs to 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 to be protected can be expanded by a user. This could essentially include any type of data, 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 methods are suitable for this purpose. Such methods are not only aimed at encrypting data, but also serve to

Ensuring the integrity and origin of data. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

For example, a method for ensuring the integrity of data LU103094 is known from the state of the art, in which a so-called hash value (also known as a hash or

A hash function is used for this. Such a hash function is used, for example, by the Secure

Hash Algorithm (SHA) is provided. 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 256 bits, for example. 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 calculates the hash value of the data and sends this hash value to the receiver.

The recipient can verify the authenticity and genuineness of the data, provided that the hash value itself is genuine and reliable.

However, the hash method has the disadvantage that the method is completely out of

This is enforced 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 during communication between A and B and communicate which certificates they expect. This can prevent an attacker E from manipulating the communication. This process is called certificate

Pinning.

A certificate is a data set that confirms the characteristics of a person or a device and whose origin and integrity can be verified cryptographically. Certificates based on asymmetric cryptographic methods, also known as public-key or public-private-key methods, are widely used. They are used, among other things, for digital signatures. With asymmetric cryptographic methods, a holder 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

The recipient can use a mutual cryptographic function to reconstruct 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, can clearly determine the authorship of the owner and the

Ensure the integrity of the message. By sending a certificate to a

For example, a device can authenticate itself against a web application or server by verifying ownership of the private key, white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application which in turn was issued to the device LU103094 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 using the public key of an asymmetric key pair using cryptographic algorithms.

Actor in the system. The secret key is only known by 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 corresponding secret key, i.e. only by the corresponding actor.

In the alternative symmetric encryption, data is encrypted with a single cryptographic key. It can only be encrypted using the same

The advantage of symmetric encryption is that

The fact 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

At the same time, it must be ensured that only this

Parties have knowledge of this key. This gives rise to the problem of the 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 have special requirements. Not only must the secret key be able to decrypt the message encrypted using the public key. It must also not be possible 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 exist, such as the SHA described above. Mathematically, it has not been proven that these one-way functions in asymmetric encryption methods cannot be reversed by an attacker with sufficiently high computing power, i.e. that a private key cannot be derived from the public key. In theory, a 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 white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application Cryptographic systems and functions, such as Curve25519 for LU103094 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, which is kept up to date in various versions. TLS includes methods for the creation and use of symmetric and asymmetric cryptographic keys, for creating digital signatures, for

Key exchange over insecure channels and for authentication.

Below, some concrete approaches from the state of the art are described,

Procedures for secure and user-friendly management of confidential data, in the

Rule related to password data.

From US10893045B2 a method is known in which only certain terminal devices of the

Access to data, including on a server, is permitted by creating a session on the server using a unique ID of the terminal device. In addition, a

Authenticator can be used to allow or deny access from end devices by authenticating the user with a second factor. However, the server does not store any explicit password data, but rather any data, and the

Access to the data is done using a master password. The

The encryption method of the server-side data is controlled by any device. This makes the process suitable as a secure

Data storage, but no password manager without a master password.

From US9590959B2 a method is also known 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 can implicitly

Procedure as authentication for a server-based password manager with additional

Functions are understood. However, there is no 2FA or a more specific

Encryption technology of potential password data stored in the database revealed.

From US8589442B2 a single sign-on system is known, which is based on a decentralized

principle works. 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 process does not use white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

2FA for individual registrations. US10341334B2, on the other hand, discloses a single- LU103094

Sign-on solution in a portal variant, where a user logs in using a

master password to log in once on several associated websites. The associated

Logins and passwords are stored on a web server, encrypted using the master password. 2FA is not revealed here either.

From US8904180B2 a method and system is known 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-party service. The

Server then provides the key material, encrypted with the one-time key, 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 revealed, which would also be implicitly conceivable with a smartphone as a second factor. However, the

Patent does not contain any methods for controlled authentication of other, trustworthy

Clients. Furthermore, the encryption of the access data on the server is not

Client or an additional device. Instead, the access data is either encrypted with an additional master key on the server, or stored as a “key-

Bag” on the client, so that the server only provides authentication. This eliminates either the advantage of protecting the access data against attacks on the

Having the server in your own hands, or the advantages of storing on the server.

From US20080031447A1 a method for the secure storage of passwords and user names of websites on a server is known. The invention discloses an encrypted storage, whereby the decryption of the data is only possible by

key material of a client is possible, so that the data on the server is not vulnerable. However, the procedure does not reveal 2FA and expects a master

User's password.

US20220209955A1 discloses a method for enabling secure

Login process also under offline conditions, whereby a server provides various services, such as the regular changing of passwords and the authentication of users for

The invention discloses two variants of storing

Password data: online and offline. In the online version it is revealed that a

Client must authenticate using an additional device as a second factor, but it is not clearly disclosed that the password data on the server is verified by a white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Client-controlled key material is permanently encrypted and thus cannot be attacked LU103094. The second factor or authenticator is also not in the

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

In US9727715B2 a method is disclosed which also includes a server and a

Application for password management. Password data is encrypted with an asymmetric key associated with a client, stored on the server and can be accessed when visiting the associated website. The private

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

From US10491588B2 a method is known in which a server for the

Password management acts as an authenticator to establish the connection between a device and a secure password database. The process also includes the automatic filling of password forms on the device by a web application.

However, the server as an interface must always have a connection from the

Server to the device as well as the secure password database, which ensures

Disadvantages of local and cloud-based storage are combined. In addition, a

Master password required.

EP2332114B1 and US9948648B1 disclose methods for automatically filling out and

Generating password data in web applications. However, the procedures do not specify secure control and storage of the password data.

From EP3420677B1 a method is also known in which a password-free

Pairing of two client devices is carried out by communication via a server. In this process, 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 paired. The exchange of

Information about asymmetric encryption is provided by scanning QR codes white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application from one client to the other client simplified. Sharing of login data such as LU103094

Passwords between clients are disclosed, but no server-based

Password manager, or primary control of password data by a client.

TASK

It is therefore the object of the present invention to provide a method for secure storage,

Use and management of secret data such as passwords. The user should not have to accept any loss of time or security by remembering and entering secret data, especially as a single point of failure. Instead, a user-friendliness similar to an SSO solution should be provided. However, the user should be able to use the secret data for any

Web application and on each of the devices used in a simple, efficient and cost-effective manner. The security and integrity of all secret data on servers exposed on the Internet should be ensured and controlled via the user's devices. Sharing secret data within a team is also a desired feature of the process.

SOLUTION

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

Further advantageous developments and further developments result 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 for 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 them, which has an advantage in terms of the user-friendliness of the invention. On the server, all secret data is stored exclusively in encrypted form, 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 different devices, as long as the user allows this using the

Authenticator clients are authorized. All communication between the user's devices takes place via encrypted channels. By using a white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Mobile phone with access protection as authenticator client, the procedure is inherently protected by 2FA LU103094, whereby the authenticator client simultaneously transmits the secret data and

Permissions of other devices can be easily managed.

DETAILED DESCRIPTION

The invention is described in detail below. The present

Invention is explained in more detail without limiting the invention to these descriptions.

Where the term "may" is used in this application, it 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 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 process described below. The push authenticator is a system of cryptographic

Keys of the authenticator client, which in combination allow the inventive method 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 encryption key pair consisting of a private encryption key and a public encryption key. For the generation and storage of asymmetric cryptographic keys, a key designated for the creation and storage of cryptographic keys is preferred.

Key element is used. The preferred authenticator client is a modern

Smartphones are used, where such key elements are standard equipment for their biometric functions, among other things. Such key elements are white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application advantageously designed to be particularly resilient against cyberattacks and physical LU103094

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 in a second sub-step of S01) on a

Server. By possessing the private login key, a client can authenticate itself against the server. In this process, the login key can be seen as a login to an account for the method according to the invention, however, this is not dependent on knowledge of a master password, but on the possession of a device, the authenticator client. For such an authentication process, the

Creating a signature used for a message that is associated with the contact of the

Clients with the server using the private 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 preferred for the authentication process. The public

The server can use encryption keys to encrypt data so that only the owner of the private encryption 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 described in a first

Substep of S02) is authorized 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 is carried out. A preferred embodiment of the encrypted

Transfer will be described later in the description.

In a second sub-step of S02), the application client uses the private

Login key to authenticate against the server in the manner already described.

In a third sub-step of S02), a

Session created by the authenticated application client using the public

Session key of a session key pair generated by the application client is stored on the server. This public session key can be used to encrypt data that only this application client can access using its private session key white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Access. Creating a session requires that the application client has a LU103094

Computer program product which is designed to generate an asymmetric cryptographic session key pair. A computer program product which, among other things, offers this functionality is a part of this invention and is described in the further course of the description. In a preferred variant, a

Software functionality for generating cryptographic keys on the

Application client is provided by an application client extension described below. 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 to connect multiple application clients using the

Authenticator clients. In a preferred embodiment of the method, all coupled clients or their sessions are displayed on the authenticator client in list form. In a particularly preferred embodiment, the method is designed for an option of

Authenticator clients are set up 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

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 time at the latest when no session exists. In a particularly preferred

In this version, the status of the session is determined by the application client directly at the

Start of the application client extension. In another particularly preferred variant, the time interval can be set and is also made dependent on the security requirements on the application client. 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 the deletion of the session. In a still preferred embodiment, white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Authenticator clients each have a session on the server, so that advantageously several LU103094

authenticator client of a user, but also by another

authenticator client.

In step S03), the initialized authenticator client and the coupled

Application client for storing or retrieving secret data by the

Application client to or from a safe located on the server. A

Vault is a data packet on the server's storage medium that is associated with an account and is cryptographically encrypted as described below. In a preferred embodiment, the vault contains an ordered list of submissions 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 one account, which can be encrypted differently.

Secret data in the vault 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 defined by the user, such as free text for secret

Notes or image data can be saved.

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 case that multiple push authenticators have access to the

This encryption has the advantage 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

This encryption is done in a second sub-step of S03) using the public encryption key of the push authenticator, so that only one client has access to the symmetric key and thus the safe, which is in

is in possession of the private encryption key.

In a third sub-step of S03), the storage and retrieval of secret data from the vault is authorized by the application client, namely by the

Authenticator client, which contains the private encryption key for white ip | Patent & Legal in encrypted form

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application provides the application client so that it can retrieve the private encryption key LU103094 and decrypt the safe. Preferably, this encrypted provision of the private encryption key is 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 retrieved by the

Authenticator client is encrypted using the public session key and sent via the

Server is sent to the application client, whereby only the application client can

can decrypt the broadcast. In another variant, the private

Encryption key together with the private login key in step S02) to the

Application client. In a preferred embodiment of the two

Transmission variants, the private encryption key cannot be

Application client stored in persistent storage so that the

Authenticator client must confirm each individual save or retrieval and the private

Encryption key cannot be stolen in the event of a physical attack on the application client while it is switched off. Other preferred

Explanations for authorizing storage and retrieval by providing the

encryption key by the authenticator client result from further described preferred features of the invention.

This configuration allows the authenticator client to control the authentication process, particularly in

Step S02) the authorized clients and in step S03) any access to the secret

Data. Another advantage here is that it is possible to attempt to retrieve secret data from

Application client, the authenticator client is used as a second factor. In a preferred

In this variant, the activated use of a

The device's protection function is required, for example through a biometric

Authentication. This advantageously makes 2FA protection completely through the possession of a

device by the user (authenticator client) and a query of a secret of the

User (e.g. biometric authentication). This authentication of the user at the

An authenticator client is standard nowadays, especially when using a modern smartphone, and is recommended regardless of the method used to manage confidential data. In this respect, this measure is advantageous and should not 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 for

Authorizing steps S02) and S03). white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

In a special embodiment, an authenticator client is used simultaneously as an application client LU103094. In this case, the computer program products used in their

Execution of the characteristics of the procedure on the authenticator client or the

Application client, installed and executed separately. For example, the features of the procedure that belong to the authenticator client are executed in a mobile app and the features of the procedure that belong to the application client are executed in a web application that is called up via the browser. In this case, the version in which the use of the push authenticator within the mobile app requires a protective function of the smartphone when opening the mobile app is particularly preferred, so that 2FA is advantageous when using the

device is secured.

In a preferred embodiment of the method according to the invention, at least one profile is used as an indirection level on 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 gain access to the account. Instead, a profile encrypts the symmetric

Key of at least one safe with a public profile key of a

Authenticator client created asymmetric profile key pair. The profile and thus in particular the private profile key is then validated on the server side by the public

Encryption key of the associated push authenticator. A profile includes 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 by the public encryption key of the associated push authenticator. Due to this configuration of encryptions, the term

Profile is declared as an indirection level, which means that the profile in the

Encryption process of a safe as an additional layer between a push

authenticator and a safe. The profile is thus protected by this push

Authenticator and thus controlled by the authenticator client.

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

In this version of a profile, several profiles are encrypted with the same public encryption key of a push authenticator, so that a push authenticator

Access to multiple profiles. A profile can also be accessed through the public white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Encryption keys of several push authenticators are encrypted simultaneously, LU103094 so that these several push authenticators are required simultaneously to gain access to the profile. This variant is preferred only for particularly sensitive secret

Data is used for which a high level of security applies or for whose management the

consent of several users is required.

In a further preferred approach, following the introduction of profiles,

In this variant, the symmetric key of a safe is encrypted by one or more different public profile keys or public encryption keys from multiple profiles or push authenticators. The symmetric key can

Keys can be encrypted using the public keys of multiple profiles, multiple push authenticators, or both profiles and push authenticators.

A symmetric key can be created using the public keys of multiple profiles or

Push authenticators are encrypted simultaneously, so that these multiple profiles or push authenticators are required to gain access to the symmetric key. This variant is preferably used only for particularly sensitive secret data for which a high level of security applies or for whose management the

consent of several users is required. Alternatively, multiple copies of the same symmetric key can be created using the public keys of several profiles or push

Authenticators are encrypted, so that advantageous these multiple profiles or push

Authenticators gain access to the symmetric key independently of each other.

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 keys of a push authenticator have several different ones, for different

can encrypt symmetric keys belonging to safes.

These possible implementation variants can, for example, but not preferably, allow a single push authenticator and two profiles to have 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, variant, a push authenticator can, for example, provide direct

Access to the symmetric key of a vault, and to a profile, where the

profile still has access to three additional vaults. This would mean that a push authenticator

Access to a total of 4 safes. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Profiles are advantageous as an indirection layer for push authenticators because they provide flexibility for LU103094 access permissions to secret data. Access to a

Tresor is no longer necessarily tied to a user and their (initial) authenticator client. Instead, a user can share access to a Tresor via a profile with other push authenticators on other users' authenticator clients.

To share access to a vault via a profile, a sharing

Authenticator client in a preferred version 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 read the only

Profiles thus offer a solution for secure, fully encrypted

Account sharing, whereby access to the secret data, but not access to the

Account is shared via the push authenticator itself. This function is particularly advantageous in small teams with specialized tasks in the work environment.

In a preferred embodiment of the method according to the invention, a

Safe has 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 with 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 according to the use of the inventive

Procedure 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 sensitive data area contains the associated passwords and other secret data such as

Answers to security questions are stored. 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 is stored.

Through access or lack of access to the private high security key or the private profile high security key, access to a white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application second area with more sensitive data. The high-security key pair LU103094 or the profile high-security key pair each belongs to a push authenticator or profile and is accordingly assigned to a push

Authenticator or profile associated key pairs on the corresponding

Authenticator client is generated 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 are not stored on a client’s persistent storage. A persistent storage 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 retrieved again. To ensure that access to these keys is not lost in this version, at least the authenticator client that is using the

If the user has generated the high-security key pair or the profile high-security key pair, this generation must be reproducible. The preferred method for this is to generate it from a random starting value that is stored. Such a starting value is described in more detail later in the description.

Due to 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 this access always starts from generating the random seed value or retrieving the private (profile) high security keys from

Authenticator client is dependent. This means that the authenticator client can

Access to the sensitive data area is controlled not only when connecting application clients, but at any time.

In a still preferred variant, the login key pair of a

Authenticator clients cannot be stored on permanent storage, so no

Application client can permanently log on to the server. This is advantageous for

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 vault, a coupled

Application client can be placed in an open or closed state, which allows or denies this application client access to the private

This ensures that access to this

Application clients can be controlled to the sensitive data area, whereby a white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Application client in the open state receives access, while an application client in the LU103094 closed state only receives access to the metadata area. This regulation or the setting in the open or closed state is carried out by the authenticator client. In a particularly preferred embodiment, the setting in 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 already 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 encrypted session key of the application client.

High Security Key or Profile High Security Key in a session of the

Application clients on the server. If such an encrypted

High security key, so only the application client that has the private

session key can decrypt this high-security key and use it to access the vault. 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 place an application client in an open state can increase the efficiency of retrieving and storing secret data for a particularly trusted device. The ability to place an application client in a closed state means that any 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, in contrast to 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. This is advantageous in that the application client cannot use any secret data from the sensitive data area for the

Web applications, but at least via a stored URL of the

Web application or a stored user name detects that secret data for the web application is present in the sensitive data area in the vault.

In a further preferred embodiment of the method according to the invention, the integrity of the public encryption keys stored on the server,

High security keys, profile keys, profile high security keys and

Session key is secured by a signing process. The signing process uses white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application a private identification key of an identification key pair of the push-link associated with the LU103094 respective public key stored on the server.

authenticator or profile. The public identification key is stored on the server. During the signing process, the private

A signature is created between the 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 was created by 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. However, if it is no longer correct, 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 are login key pair,

Identification key pair, coding key pair and high security key pair are derived from a random authenticator seed. Furthermore, the key pairs belonging to a profile, identification key pair, profile key pair and

Profile high security key pair is also derived from a random authenticator seed. This derivation is particularly preferably done using collision-free cryptographic one-way functions.

Deriving the key pairs has the advantage that a push authenticator and all its keys can be derived from a single random seed value.

Authorizing other devices by transmitting multiple private keys to them, the random authenticator or profile seed can be transmitted once instead. Other preferred properties of keys, for example,

High security and login keys are not permanently stored on a

Application client may be stored, the keys are given priority after the

Derive. Each random authenticator or profile seed, which key

Derived data which may not be stored permanently on an application client may itself not be stored permanently on an application client.

In a particularly preferred embodiment, the random starting values for push

Authenticators and profiles on an authenticator client on the key element of the

Authenticator clients are stored, preferably encrypted and protected from attacks.

This variant has the consequence that instead of the encrypted transmission of private keys in the method according to the invention, the random white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Authenticator or profile seed value is transmitted encrypted. In particular, LU103094 is used to authorize the pairing of an application client.

Authenticator seed transmitted encrypted instead of the private login key.

In addition, when authorizing storage or retrieval of secret data by the application client, the random authenticator seed or random authenticator key is used instead of the private encryption and high-security keys or profile and high-security profile keys.

Profile start value is transferred. In a particularly preferred embodiment, the

Placing an application client in an open or closed state controlled by adding the random authenticator or profile seed encrypted with the application client's public session key to a session instead of the high-security private keys contained in these random seeds.

In a particularly preferred embodiment, a profile is generated not from one but from two random profile start values, whereby a random

Profile seed the profile key pair and from another random

Profile high security seed the identification key pair and the

Profile high security key pair can be generated. 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 divide between open and closed states, in that in the case of the closed state, the (not permanently storable) random profile high security seed value is not used in the session for

is made available and therefore 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, encryption 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 seed value. Furthermore, the

Key pairs Identification key pair, profile key pair and

Profile security key pair in addition to the random profile seed and

Profile high security seed value derived from a random profile salt value. Salt value and

Profile salts are stored unencrypted on the server. Deriving

Keys from random seed values combined with random salt values has the advantage that an attacker cannot find out private keys by using different

Starting values are tested systematically using so-called rainbow tables and if the result of a key is the same, the starting value can be derived. Salt values thus advantageously increase cryptographic security. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

In a further preferred embodiment of the method LU103094 according to the invention, the method comprises a recovery function which allows a new

Authenticator client and any push authenticator or profile of the initial

To use the secret data encrypted by the authenticator client 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 using 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,

Initializing the push authenticator on the initial authenticator client also creates another backup authenticator, which encrypts a copy of the same secret data as 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 protected by additional security measures. By way of example, but not as a limitation, iOS and Android offer for their mobile

Applications encrypted cloud backups that 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. For this backup code, an additional backup authenticator is created when it is retrieved for the first time and the secret data of the

User's data is encrypted with this backup authenticator. An authenticator start value is derived from the backup code using a hash function, preferably with the help of 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. For security against spying, manipulation and loss of the backup code, this

The user is responsible for implementing the recovery function.

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 in all safes encrypted by the respective backup authenticator of the initial authenticator client is combined into a single transfer. The safe(s) are then encrypted using one or preferably two new symmetric keys. These symmetric

Keys are replaced by new public encryption keys and preferably new

High security public keys of a newly initialized push authenticator encrypted on the new authenticator client. All keys of the initial authenticator client, white ip | Patent & Legal

HEYL-0002-P-LU 03/29/2023 Luxembourg patent application including the backup authenticator used will be deleted so that all safes LU103094 are advantageously re-encrypted and long-term attacks on the secret data via the recovery function are prevented from this point on at the latest. Preferably, new recovery functions are 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 is used to store metadata of the secret

To store and retrieve data from a safe to which the session of this application client is assigned. This makes it possible, in particular, to use the application client extension to identify websites that are called up in the browser as known websites for which secret data is already available.

In a particularly preferred embodiment, the

Application client extension overlays, especially for the forms for logging in to popular websites. The overlays are particularly advantageous in place of the original

Forms are displayed by adapting the source code of the website accordingly.

This allows a user to immediately recognize that secret data has already been stored using the method according to the invention and to retrieve it accordingly.

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 a website after a successful login attempt. In another variant, the

Application client extension Overlays also for forms that require the user to enter, in particular but not exclusively, address, payment and

Request credit card information. In another variant, the

Application client extension overlays if the user or another user has left a secret note for a specific URL and asks to display it. This makes it advantageous to securely store and share notes specifically for certain web applications.

In a particularly preferred embodiment, the

Application extension the recognition of known websites for which secret data is available, the generation and display of overlays as well as the automatic filling of forms, in particular forms for login, with all the data available in the current state of the

application clients available secret data, automatically. The user only has white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application still has the task of LU103094

To confirm the storage or retrieval of secret data using the authenticator client, whereby the application client extension also generates and displays 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 on the device used as the authenticator client in this embodiment.

Smartphone. In a particularly preferred variant, the

Authenticator client installs a mobile application as already described, which is described in this

In the case of a required authorization, 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 fingerprint or face identification, is requested. This advantageously achieves 2F A using an authentication that is intuitive and familiar to the user. The

Smartphone is also a particularly simple and intuitive way 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 comprises a session token, which is stored on the server alongside the public session key. The existing session token advantageously allows the client to send requests to the server. Removing the session token in this embodiment allows

To control sessions of application clients, but also authenticator clients, by rejecting their requests to the server by removing the session token. A

Client whose request to the server is rejected deletes in a particularly preferred

Execution of its stored keys. The session token is therefore a particularly simple way for an authenticator client to exercise control over client sessions.

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 entry includes any form of data capture by the authenticator client, in particular but not limited to physical typing by the user or white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Capturing image, radio or sound information. The authenticator client encrypts its private login key or preferably its random authenticator seed with this public exchange key and sends the encrypted result to the

Application client that uses the private login key or preferably the random

Authenticator seed value can be decrypted with the private exchange key. Encryption ensures the security of the transmission. The encrypted private login key or random authenticator seed value is preferably sent using the server as a proxy, i.e. in the forwarding function.

The integrity of the sent encrypted private

login key or random authenticator seed using a signature of the

Authenticator client, preferably by means of its identification key. The application client can authenticate the client as sender and the

Integrity of the sent encrypted private login key or random

authenticator seed when the server provides the application client with the public

Identification key is also sent along.

In a particularly preferred embodiment, the exchange key pair is used only once, so that no spam, malicious code or faulty

Information can be sent to the application client using the same encryption at all times. It is particularly preferred that the exchange key pair is 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 in a generated and displayed by the application client

Exchange QR code, 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 is provided which implements the method according to the invention on a

authenticator client used by the smartphone, the operating system of the

Smartphones are registered as processors of at least one specific type of QR code used for linking application clients. This means that this mobile application is automatically started when such a QR code is captured by any camera application on the smartphone. This in turn increases the time efficiency of the process and thus the user-friendliness.

In general, embodiments of the present invention may be implemented as a program,

Firmware, computer program or computer program product with a program code white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application or be implemented as data, whereby the program code or data is effective to carry out one of the methods LU103094 when the program is based on a

The program code, the computer program product or the data can, for example, also be stored on a machine-readable medium or

The program code or data can be stored as

source code, machine code or bytecode, 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), 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 extensively described method, 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 vaults. In a preferred embodiment, the computing unit is a CPU (central processing unit), which is versatile for operations, but is not adapted to particularly specialized computing operations. In a preferred embodiment, the

Server also contains an application-specific integrated circuit (ASIC) for efficient encryption, for verifying 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 instructions which are used in the

Execution by a computing unit on an authenticator client causes the authenticator client to execute the method according to the invention. This particularly concerns the

Process steps and features that are carried out on the authenticator. These include in particular, but not limited to, the following process steps and features: * The generation or derivation of all asymmetric key pairs on a

Authenticator client, * Creating and sending as well as receiving and evaluating requests to or from the server white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application e Accessing interfaces for using the camera, protection element, protection function LU103094 and memory of the authenticator client e Storing private keys and values e 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), asking the user to verify via the smartphone's protection function as an authenticator client.

The present invention comprises, in addition to the extensively described method, the

Server and a computer program product A also a computer program product B.

This includes instructions that, when executed by a processing unit on a

Application client causes it to carry out the method according to the invention.

This particularly concerns the process steps and features that are carried out on the authenticator. These include in particular, but not limited to, the following:

Process steps and features: * Generating or deriving all asymmetric key pairs on a

Application client, * Creating and sending as well as receiving and evaluating requests to or from the server * Accessing interfaces for using the protection element and memory of the

Application clients e Storage of private keys and metadata of secret data e Access to interface for local communication with an associated

Application client extension e The provision of at least one user interface which provides functions for

Retrieving session status, creating and displaying a public

Exchange key for coupling with a server and authenticator client (especially via QR code), detecting the recognition status of a

Web application and creating and displaying overlays, displaying a

Authorization prompt for the authenticator client, auto-fill of secret data, storing of 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 white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Application clients a web application, while the application client extension as LU103094

Browser Addin is running. In this preferred implementation, pairing is performed including displaying the public exchange key pair and features such as a

Retrieval of the status of the application client in the web application. The browser

Addin, on the other hand, takes over all functions and steps of the procedure regarding the

Storing metadata of secret data, creating and displaying

Overlays, filling out forms and storing and retrieving secret

data to and from the server.

The present invention comprises, in addition to the extensively described method, the

Server and the computer program products A and B also 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 concerns

Specifically, the procedural steps and characteristics that are performed on the server.

This includes, in particular but not limited to, the following process 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

Proxy for forwarding communication between clients, e Accessing memory and special ASICs for encryption, verifying signatures and certificates or executing hash functions, e 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,

The present invention comprises, in addition to the extensively described method, the

Server and the computer program products A, B and C also a system which consists of the

combination of the computer program products A, B and C and the server. This

System is capable of fully executing the present inventive method. This requires the use of suitable authenticator clients or application clients that have already been specified but are not covered by the present invention and that are set up to at least

computer program products A or B. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Further advantages, features and possible applications of the present invention LU103094 will become apparent from the following description of embodiments and the

Drawings. The elements mentioned in the claims and in the description may

Features may be essential to the invention individually or in any combination.

It should also 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 that there is no contradiction, whereby a separate description of various possible combinations is omitted in order to avoid unnecessary repetition. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

EXAMPLES OF IMPLEMENTATION LU103094

The above-described properties, features and advantages of this invention as well as the

The way in which these are achieved will become clearer and more clearly understandable in the

Context 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 limiting the invention to this

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 limited 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 coloured boxes and provided with a key symbol. All keys or values that are highlighted in light grey are secret keys or values that are only available on the respective device to which they belong. Keys or values that are highlighted in white

Values are also secret, but are stored on the server, but only in encrypted form. Keys or values highlighted in dark grey 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 stores or retrieves secret data on a

Application client (1.3), here a laptop. In the preferred embodiment shown here, this function is implemented via overlays (1.4.2) by the

Application Client Extension (1.4.1) provided in this preferred

Execution as a browser add-in. Different forms (1.4.3) of different web applications can be

Application client extension (1.4.1) is automatically recognized and the inventive overlay (1.4.2) is displayed. If the

If the user enters 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 white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application. An authenticator client (1.2) communicates via a server (1.1) with LU103094 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, represented by the solid arrows, in this preferred version via channels with encryption according to 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.

Only between application client (1.3) and its

Application Client Extension (1.4.1) enables local, unencrypted communication on the same device, e.g. between the

device storage and the browser add-in.

Fig. 3: A comparison of the different keys that a push authenticator (1.5) and a profile (1.7) have. A profile (1.7) has, in contrast to the

Push Authenticator (1.5) does not have a login key pair consisting of a public (2.1.2) and a private (2.1.3) login key to authenticate itself against the server. Both Profile (1.7) and 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), which are stored on the server, are authenticated using the private

Identification key (2.2.3) are signed, whereby by means of the

signing process (2.2.4) the integrity of the signed public keys can be ensured. 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

Key for encrypting vaults belonging to the profile or push authenticator. The encryption key pair (2.3.2 and 2.3.3) and

However, the high-security key pair (2.4.2 and 2.4.3) of the push authenticator (1.5) also serves to protect any key of this

Push Authenticator assigned profile (1.7) in order to gain access to this profile. In the illustrated version white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application, any keys of the profile or push authenticator from LU103094 are the random profile seed (4.2.1) and the random

Profile high security seed (4.2.2), or the random

Authenticator seed value (4.1) is derived. There are both

Profile seed (4.2.1) and profile high security seed (4.2.2) to obtain from a profile the profile key pair (2.5.2 and 2.5.3) and the

To be able to retrieve the profile and security key pair (2.6.2 and 2.6.3) individually, e.g. depending on whether the profile is in open or closed

In this version, all keys are stored in the

Push authenticator (1.5) or the profile (1.7) is additionally 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 by means of a profile (1.7), whereby it should be noted that such an encryption variant in a variant without

Profile can also be done directly by a push authenticator. The public (2.2.2, 2.5.2, 2.6.2) and private (2.2.3, 2.5.3, 2.6.3)

Keys are composed of at least one random profile seed (4.2.1), one random profile security seed (4.2.2) and one random

Profile salt (4.4) is generated. The public keys (2.2.2, 2.5.2, 2.6.2) are stored on the server, with the public

Profile security key (2.6.2) is used to create the symmetric

High security key (3.2) and the public

Profile key (2.5.2) is used to at least determine the symmetrical

Key (3.1) to encrypt. In a preferred variant, the public profile key (2.5.2) additionally encrypts both symmetric

Keys (3.1, 3.2) are encrypted. The symmetric keys can 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) by encryption by a push authenticator (1.5) and a second, in this

Backup authenticator variant (1.6). In the profile at the bottom left, as in Fig.4, a random profile start value (4.2.1), a random profile security start value (4.2.2) and a random

Profile salt value (4.4) generates key pairs associated with the profile, where white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application these can be used as in Fig.4 to encrypt a server-side safe LU103094. While the random profile salt (4.4) is publicly available 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) encrypted by at least the public high security key (2.4.2) of the push authenticator (1.5) are stored on the server. This means that only this push authenticator (1.5) can gain access to this profile by decrypting the random seeds (4.2.1 and 4.2.2) of the profile.

In addition, in this version a backup authenticator (1.6) is set up, with which the random starting 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 replaced by transmitting the random

Authenticator seed value (4.1) and the random salt value (4.3) are created on 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 associated with 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 only one public (2.8.2) and one private (2.8.3)

Exchange key to obtain keys or

To be able to receive encrypted start values. In the 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 a 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 a

Application client all keys described in particular in Fig. 3.

However, the open state can control whether a 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) has access to its white ip | Patent & Legal

HEYL-0002-P-LU 03/29/2023 Luxembourg patent application has a private identification key and a high security profile key. This LU103094 allows or prohibits access to sensitive data within the secret data accordingly 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

Key. In this version, a push authenticator accesses the safe (3.3.1) directly, unlike in the equally possible

Variant in Fig.4, in which a profile is used as an indirection plane for the

Push authenticator accesses the vault (3.3.1). 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 the symmetric

Key (3.1) to encrypt and decrypt in order to gain access to the safe encrypted by this symmetric key (3.1). In this preferred embodiment, however, the safe is

Metadata area (3.3.5) and a sensitive data area (3.3.3), whereby the sensitive data area (3.3.3) is 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 needs the

High security key pair (2.4.1) consisting of a private (2.4.3) and a public (2.4.2) high security key for encrypting and decrypting the symmetric high security key (3.2). The private

The 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 top left shows a web application, here for example

Github.com, their standard form (1.4.3) for login. Therefore white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application, the application client and the application client extension (1.4.1) LU103094 must be coupled with an authenticator client by scanning the QR code (2.8.4) displayed by the application client extension (1.4.1) by the authenticator client in this preferred embodiment. This QR code (2.8.4) contains a public exchange key (2.8.2), which allows login keys or random start values to be encrypted and securely exchanged between the authenticator client and the application client and the coupling of the application client to be carried out. In the coupled state, the application extension (1.4.1) recognizes the familiar form (1.4.3) for login and automatically displays a

Overlay (1.4.2) for logging in with the method according to the invention instead of the form, see illustration in the middle at the top of Fig.8. If the user initializes the login, the overlay (1.4.2) in the middle of the illustration below shows that the user has access to the secret data of this

Web application should be authorized using the authenticator client — this applies at least in the case that the application client is not set to open state, because then it could also access the sensitive secret data without

Retrieve 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 that can be made by

Application of the description of the invention, within the scope of

patent application. white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

LIST OF REFERENCE SYMBOLS LU103094 (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 white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

(2.6.1) Profile high security key pair LU103094 (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) Exchange 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) Vault (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) Transfer (4.1) Random authenticator seed (4.2.1) Random profile seed (4.2.2) Random profile high security seed (4.3) Random salt (4.4) Random profile salt white ip | Patent & Legal

HEYL-0002-P-LU 29.03.2023 Luxembourg patent application

Claims (22)

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: S01) initializing at least one push authenticator (1.5) on an initial authenticator client (1.2), comprising 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 encoding key pair (2.3.1) from a private encoding 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), S02) coupling at least one application client (1.3) to the server (1.1), comprising 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) by means of 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), S03) storing or retrieving 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 white ip | Patent & Legal HEYL-0002-P-LU 29.03.2023 Luxembourg patent application Encrypting the safe (3.3.1) when saving and decrypting the safe LU103094 (3.3.1) upon retrieval, wherein 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) to decrypt the symmetric key (3.1). 2. The method according to claim 1, wherein 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). 3. Method according to claim 1 or 2, 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 several profiles (1.7) or push authenticators (1.5) is encrypted. 4. Method according to one of claims 1 to 3, 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). 5. The method according to claim 4, 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 storage of clients, i.e. authenticator clients (1.2) or application clients (1.3). white ip | Patent & Legal HEYL-0002-P-LU 29.03.2023 Luxembourg patent application 6. Method according to one of claims 4 to 5, wherein a coupled application client (1.3) is placed in a closed state in which this application client (1.3) does not have access to the private high-security key (2.4.3). 7. Method according to one of claims 4 to 6, wherein a coupled application client (1.3) is placed in an open state in which the application client (1.3) gains access to the private high-security key (2.4.3). 8. Method according to one of claims 1 to 7, wherein the integrity of the data stored on the server (1.1) stored public encryption key (2.3.2), high security key (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). 9. Method according to one of claims 1 to 8, 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) from at least one random authenticator start value (4.1) or profile start value (4.2.1, 4.2.2). 10. The method according to claim 9, wherein for deriving 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). 11. The method according to any one of claims 1 to 10, 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). 12. Method according to one of claims 1 to 11, 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 overlays (1.4.2) for stored secret data (3.3.2) on Internet pages. white ip | Patent & Legal HEYL-0002-P-LU 29.03.2023 Luxembourg patent application 13. The method according to claim 12, wherein the application extension (1.4.1) automatically recognizes various LU103094 forms (1.4.3) of a website and can fill them out if desired. 14. The method according to any one of claims 1 to 13, 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). 15. The method according to any one of claims 1 to 14, 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). 16. Method according to one of claims 1 to 15, wherein the coupling of the application client in step S02) is carried out by entering a (1.3) created and issued public exchange key (2.8.2) of an exchange key pair (2.8.1) is initialized in 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). 17. The method according to claim 16, 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). 18. 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 17 in a network, and at least one storage medium for storing at least computer programs, keys, values, sessions and safes. 19. Computer program product A, comprising commands which, when executed by an authenticator client, cause the authenticator client to carry out the method according to the invention. white ip | Patent & Legal HEYL-0002-P-LU 29.03.2023 Luxembourg patent application 20. Computer program product B, comprising instructions which, when executed by LU103094, cause an application client to carry out the method according to the invention. 21. Computer program product C, comprising instructions which, when executed by a server, cause the server to carry out the method according to the invention. 22. System comprising a server (1.1) according to claim 18, a computer program product A according to claim 19, a computer program product B according to claim 20 and a computer program product C according to claim 21. white ip | Patent & Legal HEYL-0002-P-LU 29.03.2023 Luxembourg patent application