METHOD FOR CONDUCTING AN AUTHENTICATION PROCESS BY AN INDIVIDUAL SYSTEM USER

Description

Technical field

[0001] The invention describes a method for human-machine authentication that defines the individual system user as an essential system element. For the purposes of this application, authentication refers to the verification of an identity, as distinct from authentication, which refers to the verification of this identity for its authenticity. The resulting authorization, as a consequence, grants access after successful verification of identity. The invention is suitable for integration into existing systems. The security of a system is enhanced by the entry of an authentication code, which the individual system user must enter upon request from the system.The method focuses on the cognitive performance of the individual system user and demonstrates how this valuable individual human factor can be integrated into a technical authentication process to increase security. Cognitive performance, as defined in this invention, includes, for example, perception, attention, memory, learning and problem-solving abilities, adaptability, executive functions, and cognitive flexibility.

[0002] Each individual system user possesses unique cognitive abilities. These can make a significant contribution to system security during the authentication process, regardless of the complexity of the system implementation. The invention describes a method for utilizing this human potential to enhance the security of technical systems.

[0003] The invention utilizes technical elements / aids based on known cryptographic techniques and principles (see

[014] ). System users apply these ad hoc during the authentication process. No in-depth knowledge of cryptography, computer science, or mechanics is required of the individual system user. The cognitive abilities of the individual system user are inherent to the process and of central importance. They are at the heart of the authentication process. Utilizing the cognitive abilities of the individual system user is the core element for making the authentication process more secure. The individual system user has individual choices. Depending on their security needs and their own abilities, the individual system user can increase the complexity and thus the security standard. State of the art

[0004] The basic procedure is as follows: An individual system user requests access to an action protected by a technical system. The stored authentication code is entered by the individual system user and verified by the protected system. Subsequent system actions depend on the result of the verification.

[0005] During the input process, external eyes, cameras, or so-called keyloggers (hardware or software used to record the user's input on a computer keyboard) can directly intercept and unjustifiably reuse this authentication code if the public input of the authentication code corresponds 1:1 to the stored secret authentication code.

[0006] The authentication code, which is sent to a certification authority via data transmission, e.g., over the internet, can be encrypted. However, if an attacker or unauthorized third party decrypts this data, the decrypted data still contains the stored authentication code exactly as it was originally intended.

[0007] In general, there is always an increased security risk when entering / transmitting the authentication code to perform security-critical actions of a system or during a security-critical process if the authentication code and the stored, secure and secret authentication code are identical.

[0008] Similarly, there is an increased security risk if the individual system user cannot be sure that the authentication code request is being made by a legitimate system, whereby the term phishing is commonly used here for, for example, fake websites, emails or text messages as supposedly trustworthy communication partners in electronic communication.

[0009] To achieve higher system security during human-machine authentication, state-of-the-art technology typically integrates additional software and / or hardware components as an extra security layer into the authentication process. These include, among others: the carrying and administering of additional hardware components (tokens), the use of additional software (2FA, MFA) or the carrying and administering of additional lists (TAN, iTAN).

[0010] In this context, "token" refers to a hardware or software component used to identify and authenticate users, usually as part of an access control system with two-factor authentication (2FA). This serves as proof of identity for a user through a combination of two different and independent components (factors), such as a bank card and PIN at an ATM. Multi-factor authentication (MFA) verifies this access authorization using several independent characteristics (factors). The transaction authentication number (TAN) or indexed transaction authentication number (iTAN) are one-time passwords primarily used in online banking.

[0011] The sequential processing of procedures or mechanisms, in which upstream and / or downstream security levels are sequentially traversed, increases the effort required to reach the actual goal in the case of legitimate authentication. Depending on the number of security levels, an individual system user, as a legitimate system user, must therefore expend more time and energy to achieve their objective.

[0012] Additionally, the problem of the 1:1 mapping of input code and authentication code shown in [005 - 010] remains. This problem exists for each individual upstream and / or downstream link in the security chain.

[0013] In the examples presented in [005 - 011], the human being as a significant factor in the authentication process is increasingly replaced by technology. The human being increasingly only needs to transmit an output from technology element A to technology element B to reach the next security level. Extending the security chain by adding further security levels reduces the internalization (mental storage) of the secret authentication code. Furthermore, the importance of the human being in the entire security chain is increasingly neglected.

[0014] There are methods that influence the manual entry of the authentication code by changing the key layout at the moment of input. This makes it difficult for users who, for example, memorize a PIN code as a pattern on the respective input field. Examples of this include the following publications: File number Brief description CH 713 015 A2 Input device and method DE 296 13 938 U1 Code entry system for check card payment systems and ATMs DE 10 2004 002 128 A1 Device and method of coded and / or non-coded commands DE 10 2008 019 034 A1 Method and device for determining an access code DE 10 2009 020 207A1 Input terminal and PIN capture procedure DE 10 2009 012 011A1 PIN or password entry system for daily use in department stores to ensure discretion

[0015] In the technical field of cryptography, extensive techniques, procedures and standards have been available for many years to make authentication on technical systems more secure and thus make attacks on technical systems more difficult.

[0016] These include, among others: Challenge-response authentication (authentication procedure of a participant based on knowledge by means of a task (challenge) that the participant must solve (response) to prove that he knows a defined piece of information (shared secret), salt (cryptography a randomly chosen string that is attached to a given plaintext before its further processing (e.g.(Input into a hash function) is appended), Salted Challenge Response Authentication Mechanism (password-based challenge-response authentication mechanisms that allow authentication of a user to a server), Standard: ISO / IEC 9797 Message Authentication Codes [MACs] / Message Authentication Codes [MACs] (to obtain the origin of data or messages and to verify their integrity), Message Authenticator Algorithm (MAA) (cryptographic functions for calculating a Message Authentication Code (MAC)) or Standard: ISO-IEC-9798 Entity authentication / Authentication of instances (to confirm that an instance is indeed what it claims to be).

[0017] The techniques and teachings of the established machine-to-machine authentication methods described in

[014] have not been practically transferable to human-to-machine authentication due to their complexity.

[0018] Publication US 9 686 275 B2 discloses a technique for continuous user authentication through real-time fusion and correlation of multiple factors, whereby monitored data of user actions are continuously received by a computer and analyzed by a server to perform a series of modalities in order to authenticate the user.

[0019] Publication US 9,672,335 B2 discloses a method for user login to a computer that introduces an additional thought-driven user interface in which the user must respond to one or more prompts. The user's responses to these prompts are used to determine whether the user possesses the required level of cognitive function to gain access to the computer system or to continue an active login session.

[0020] Patent US 10,476,873 B2 discloses devices, systems, and methods for recognizing user identities and for passwordless user authentication, for which the task optionally involves connecting the dots on the screen. The system monitors user interactions and user-specific characteristics and subsequently relies on such user-specific characteristics as a means of user authentication.

[0021] Furthermore, publication EP 1 010 049 B1 discloses a method for providing user access to a secure application, in which at least one symbol is displayed to the user as an authentication request. The user manipulates the displayed symbol so that a code key can be generated based on these manipulations. Using this code key in conjunction with stored authentication information, the user can generate an authentication result, and user access is granted if the result supports the authentication requirements of the secure application. The following documents also represent relevant prior art: US2018 / 219859A1, US2016 / 006730A1, EP3229163A1.

[0022] Against this background, the object of the present invention is to provide a method for carrying out an authentication process by an individual system user, effectively and practically integrating fast ad hoc calculations, such as those that can be performed by machines to solve cryptographic tasks, which are required by the individual system user and thus incorporated into the authentication process. This challenge is the core of the present invention. Disclosure of the invention Advantages of the invention

[0023] The invention highlights the potential of the individual system user to increase security in authentication processes and clearly distinguishes itself from purely machine-based processes. By incorporating the cognitive capabilities of the individual system user, many current security problems in human-based authentication processes can be solved. The invention offers existing and / or new technical systems an "individual human-machine authentication method" which: 1. makes cryptographically sophisticated / established security mechanisms (see

[014] ) applicable ad hoc for individuals, 2. utilizes the individual cognitive abilities of individuals to protect system security and makes these technically implementable, 3. is scalable and can be individually tailored to the cognitive performance of the individual system user. The individual system user and / or the system administrator can thus increase the complexity according to their wishes and security needs in order to obtain a higher security level, 4. can combine individual security levels in one step and thus enables the parallel processing of a large number of security levels to accelerate the authentication process, 5. resolves the 1:1 relationship between input code and authentication code, 6.7. makes access by unauthorized attackers through spying more difficult, since authentication can be performed openly / publicly without the individual system user having to fear that a third party could exploit the spied-upon input effectively and with minimal resources, 8. distributes the physical input of the authentication code across the entire input field, which significantly hinders the derivation of inputs through pressure traces (e.g., dirt profiles, fingerprints, etc.), 9. enables mutual authentication verification (human-machine) to make phishing (see

[008] ) more difficult, 10. is open to future cryptographic security techniques, procedures, and extensions that can be flexibly integrated, 11. does not require any skills in cryptography, computer science, or mechanics from the individual system user, 12. can be easily implemented in existing security systems, 13.does not necessarily require the creation of new authentication codes, as existing authentication codes can be retained, and 13. strengthens the memory of the authentication code, as the individual system user engages intensively with the authentication code during the authentication process, thus imprinting it more deeply into long-term memory.

[0024] The following describes the procedure by which the aforementioned advantages can be achieved. Reference numerals are used that refer to the numbers used in the attached figures and to the attached list of reference numerals.

[0025] The procedure will henceforth be referred to as individual algorithm-based multi-factor authentication (abbreviated: dopeIN or dopeIN procedure) 1000 ( Fig. 1), that is, the term dopeIN replaces the term for individual algorithm-based multi-factor authentication in the following and is used synonymously.

[0026] In order for individuals to benefit from the dopeIN 1000 procedure, it is necessary to define and establish terminology to distinguish it from existing knowledge. The specific definitions of these terms will be noted directly where they are used in the text and / or prefixed with dopeIN.

[0027] Technical systems represent 1000 in the context of individual algorithm-based multi-factor authentication (dopeIN) ( Fig. 1 ) technical components (e.g., computers, microprocessors, machines, devices, components, etc.) in a larger unit (e.g., computer network, plant, building, device, machine, etc.) that interact for the purpose of "human-machine authentication" with regard to their input and output variables.

[0028] Security fragments are used for authentication verification. They can be created and / or verified as input and output variables within a single technical component in a technical system, or distributed, created, and / or verified across a network of different technical components in technical systems.

[0029] The dopeIN 1000 method revealed here distinguishes two fundamental phases: the implementation phase (2000) and the application phase (3000). The application phase (3000) presupposes an implementation phase (2000).

[0030] To provide a meaningful understanding of how to use the individual algorithm-based multi-factor authentication (dopeIN) 1000, the application phase 3000 is explained before the implementation phase 2000 and schematically illustrated in flowcharts in the appendix. Figures 1 to 4 clarifies.

[0031] The technical authentication and security systems 100 and 200 may differ during the application and implementation phases 3000 and 2000, respectively, but this is not mandatory. For clarity, the technical system is designated 100 in the context of application phase 3000 and 200 in the context of implementation phase 2000.

[0032] The technical security systems 200 serve to manage, generate and / or synchronize / exchange data of algorithms for individual algorithm-based multi-factor authentication.

[0033] The technical authentication systems 100 execute algorithms for individual algorithm-based multi-factor authentication in order to secure security-relevant actions by means of additional cognitive performance of the individual system user 101 in the event of authentication. Application phase 3000 (Fig. 3)

[0034] A technical authentication system 100, in which a person must authenticate themselves as an individual system user 101 102, uses a previously defined common secret authentication code 108 and a previously defined common secret dopeIN algorithm 107 for authentication processes for data processing 105, 106.

[0035] When a security-relevant action 102 of an individual system user 101, who uses the dopeIN procedure 1000 (hereinafter referred to as dopeIN user 101), is accessed via the system, the technical authentication system 100 belonging to the requesting dopeIN user 101 generates temporary authentication data 109 and sends an input prompt 111 to the dopeIN user 101. This temporary authentication data 109 (hereinafter referred to as dopeIN authentication or dopeIN authentication data 109) is the result of the dopeIN data processing 105, by executing the dopeIN algorithm 107 of the requesting dopeIN user 101, at the time of the request 102.

[0036] If the dopeIN user 101 is able to correctly interpret the temporary dopeIN authentication data 109, 110, then he can determine the correct input code 112 at the time of the request 102 through his cognitive performance.

[0037] If the input prompt 111 of the technical authentication system 100 appears legitimate to the dopeIN user 101, the individual system user 101 resolves the prompt 111 and transmits the result of their cognitive performance to the requesting technical authentication system 100 by means of input 103. This input data 112 of the dopeIN user 101 is hereinafter referred to as the temporary dopeIN input code 112.

[0038] The technical authentication system 100 checks the individual security fragments, the temporary dopeIN input code 112 of the dopeIN user 101 based on the generated temporary dopeIN authentication data 109, the jointly agreed secret authentication code 108 and the individually underlying dopeIN algorithm 107 of the dopeIN procedure 1000, by executing the dopeIN algorithm 107 and delivers as output a temporary result 113 of this dopeIN authentication check 106.

[0039] The temporary result 113 of the authentication check 106 can now be used to determine the further steps of the system process 114, depending on the result 113. For example, if the temporary result 113 is positive, the desired security-relevant action 102 could be executed immediately. In the case of a negative result, the dopeIN user 101 could receive a warning message, and subsequent system access by the dopeIN user 101 could be blocked.

[0040] The table below summarizes the individual steps of application phase 3000 as described in Fig. 3 shown again in summary.

[0041] dopeIN application phase: Human ⇔ Machine Person: ⇓ * performs a security-relevant action 102 on a technical authentication system 100 which has implemented the dopeIN procedure 1000 Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 105 * generates the temporary authentication data 109 * optionally displays 110 of these temporary authentication data 109 * stores 104 these temporary authentication data 109 for further dopeIN data processing * opens an input dialog and prompts for the entry of the temporary dopeIN input code 112 111 Person: ⇓ * cognitively determines, based on the previously defined dopeIN algorithm 107, the security fragment which the machine needs for subsequent dopeIN data processing 106 in order to confirm correct authentication (see

[001] ) and report it as output 113 * adds another security fragment (temporary dopeIN input code 112) to the dopeIN data processing 106 by means of input 103 Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 to validate and verify all fragments of the security-relevant system request 102 106 ⇓ * checks all individual security fragments for plausibility (107, 108, 109, 112) ⇓ * checks whether all security fragments match each other 106 ⇓ * verifies the content of all security fragments, depending on their definition 106 ⇓ * Based on dopeIN data processing 106, generates the temporary result of the dopeIN authentication check as output 113 * Depending on the temporary result 113 of the dopeIN authentication check, 106 further steps are performed 114

[0042] The following are potential application areas for the technical implementation of the dopeIN application phase: Human ⇔ Machine: Potential application areas for the dopeIN application phase: Human ⇔ Machine Example 1: Authentication at a bank transfer machine

[0043] Person: ⇓ * performs a security-relevant action 102 on a technical authentication system 100 which has implemented the dopeIN procedure 1000 → A bank customer wants to make a transfer using their debit card at a transfer machine at their bank. To do this, they insert their debit card into the transfer machine. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 105 → Using the card reader of the transfer machine, it is determined that the card is a legitimate EC card belonging to the bank customer, and a secure data exchange takes place with the bank's security server. The bank's security server executes the corresponding dopeIN algorithm 107 of the requesting bank customer (dopeIN user) 101 from 105. * generates the temporary authentication data 109 * stores 104 these temporary authentication data 109 for further dopeIN data processing → By executing the associated dopeIN algorithm 107, the temporary authentication data 109 is generated and stored on the security server. * optionally displays 110 of these temporary authentication data 109 * opens an input dialog and prompts for the entry of the temporary dopeIN input code 112 111 → The bank's security server then sends a secure data packet to the ATM, containing the temporary authentication data 109. This temporary authentication data 109 is then displayed on the ATM. Simultaneously, the customer is prompted to enter the temporary dopeIN entry code 112. Person: ⇓ * cognitively determines, based on the previously defined dopeIN algorithm 107, the security fragment which the machine uses for subsequent dopeIN data processing 106 required to confirm correct authentication (see

[001] ) and report as output 113 → The bank customer checks the plausibility of the temporary authentication data 109 displayed by the transfer machine in order to then determine the temporary dopeIN input code 112 using cognitive performance. * adds another security fragment (temporary dopeIN input code 112) to the dopeIN data processing 106 by means of input 103 → The bank customer enters the temporarily determined dopeIN entry code 112 at the transfer machine and confirms his entry. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 to validate and verify all fragments of the security-relevant system request 102 106 → By confirming the entry of the temporary dopeIN input code 112 at the transfer machine, all available security fragments of this security-relevant action are sent from the transfer machine to the bank's security server via secure data transmission. The server then executes the corresponding dopeIN algorithm 107 of the requesting bank customer (dopeIN user) 101 out of 106. ⇓ * checks all individual security fragments for plausibility (107, 108, 109, 112) ⇓ * checks whether all security fragments match each other 106 ⇓ * verifies the content of all security fragments, depending on their definition 106 * Based on dopeIN data processing 106, generates the temporary result of the dopeIN authentication check as output 113 * Depending on the temporary result 113 of the dopeIN authentication check, 106 further steps are performed 114 → Depending on the result of the security-related authentication request at a payment terminal, further predefined steps can now be taken. If the result is positive, access to all customer functions of the payment terminal may be granted. If negative, the customer may be required to authenticate again. Example 2: Purchase confirmation from an already authenticated web shop user as an individual system user 101

[0044] Person: ⇓ * performs a security-relevant action 102 on a technical authentication system 100 which has implemented the dopeIN procedure 1000 → An already authenticated webshop user wants to place a payment order for their filled online shopping cart. To do this, the webshop user confirms a corresponding prompt from the webshop in their browser. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 105 → The user data of the web shop user defined that payment transactions are additionally secured with an individual algorithm-based multi-factor authentication (dopeIN) 1000, which is why the associated dopeIN algorithm 107 of the web shop user (dopeIN user) 101 is executed on the security server of the web shop provider 105. * generates the temporary authentication data 109 * stores 104 these temporary authentication data 109 for further dopeIN data processing → By executing the associated dopeIN algorithm 107, the temporary authentication data 109 is generated and stored on the security server of the web shop provider. * optionally displays 110 of these temporary authentication data 109 * opens an input dialog and prompts for the entry of the temporary dopeIN input code 112 111 → The webshop provider's security server then sends a secure data packet containing the temporary authentication data 109 to the webshop provider's web server via secure data transmission. This temporary authentication data 109 is then displayed in the webshop user's browser. Simultaneously, the webshop user is prompted to enter the temporary dopeIN input code 112. Person: ⇓ * cognitively determines, based on the previously defined dopeIN algorithm 107, the security fragment which the machine needs for subsequent dopeIN data processing 106 in order to confirm correct authentication (see

[001] ) and report it as output 113 → The web shop user checks the plausibility of the temporary dopeIN authentication data 109 displayed by the web shop, in order to then determine the temporary dopeIN input code 112 using cognitive performance. * adds another security fragment (temporary dopeIN input code 112) to the dopeIN data processing 106 by means of input 103 → The web shop user enters the temporarily determined dopeIN input code 112 into their browser and confirms their entry. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 to validate and verify all fragments of the security-relevant system request 102 106 → By confirming the entry of the temporary dopeIN input code 112 in the webshop user's browser, all available security fragments of this security-relevant action are sent via secure data transmission from the webshop user's browser to the webshop provider's web server and from there to the webshop provider's security server. This server then executes the corresponding dopeIN algorithm 107 of the requesting webshop user (dopeIN user) 101 out of 106. ⇓ * checks all individual security fragments for plausibility (107, 108, 109, 112) ⇓ * checks whether all security fragments match each other 106 ⇓ * verifies the content of all security fragments, depending on their definition 106 ⇓ * Based on dopeIN data processing 106, generates the temporary result of the dopeIN authentication check as output 113 * Depending on the temporary result 113 of the dopeIN authentication check, 106 further steps are performed 114 → Depending on the outcome of this security-related request from the webshop user, further predefined steps can now be taken. If the result is positive, for example, the purchase of the items in the shopping cart can be confirmed. If negative, for example, the webshop customer can be blocked for the next 15 minutes, with a corresponding email notification sent to the webshop user's email address. Example 3: Access control to a security laboratory

[0045] Person: ⇓ * performs a security-relevant action 102 on a technical authentication system 100 which has implemented the dopeIN procedure 1000 → An employee of a company wants to enter a security laboratory on the company premises. To do so, he holds his company ID card, in the form of a chip card, against the corresponding reader at the secured laboratory entrance. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 105 → The correct identification of the chip card at the reader then sends a secure data packet to the company's security server via secure data transmission. This server executes the corresponding dopeIN algorithm 107 of the requesting employee (dopeIN user) 101 from 105. * generates the temporary authentication data 109 * stores 104 these temporary authentication data 109 for further dopeIN data processing → By executing the associated dopeIN algorithm 107, the temporary authentication data 109 is generated and stored on the security server. * optionally displays 110 of these temporary authentication data 109 * opens an input dialog and prompts for the entry of the temporary dopeIN input code 112 111 → The employee receives a text message to their company mobile phone containing the temporary authentication data 109 and instructions to enter their temporarily generated dopeIN entry code 112 on the keypad next to the laboratory's security door. The employee is also instructed to confirm this entry using the fingerprint scanner attached to the keypad 111. Person: ⇓ * cognitively determines, based on the previously defined dopeIN algorithm 107, the security fragment which the machine uses for subsequent dopeIN data processing 106 is required to confirm correct authentication (see

[001] ) and report it as output 113. → The employee reads and checks the delivery and content of the text message on his company mobile phone for plausibility, in order to then determine the temporary dopeIN entry code 112 using cognitive performance. * adds another security fragment (temporary dopeIN input code 112) to the dopeIN data processing 106 by means of input 103 → The employee follows the instructions of the previously named text message, enters the temporarily determined dopeIN entry code 112 on the keypad of the named security door and confirms his entry by means of the fingerprint of his left ring finger on the associated fingerprint scanner. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 to validate and verify all fragments of the security-relevant system request 102 106 → Through the correct identification of the employee's fingerprint at the fingerprint scanner, the temporary dopeIN input code 112 entered on the keypad is sent to the security server used in the company, which then executes the associated dopeIN algorithm 107 of the requesting employee (dopeIN user) 101 out of 106. ⇓ * checks all individual security fragments for plausibility (107, 108, 109, 112) ⇓ * checks whether all security fragments match each other 106 ⇓ * verifies the content of all security fragments, depending on their definition 106 ⇓ * Based on dopeIN data processing 106, generates the temporary result of the dopeIN authentication check as output 113 * Depending on the temporary result 113 of the dopeIN authentication check, 106 further steps are performed 114 → Depending on the outcome of the security-related request to open the security door to the safety laboratory, further predefined steps can now be taken. For example, if the request is successful, the security door can be opened; if unsuccessful, an alarm will sound and the security door will remain closed. Example 4: Deactivating the immobilizer of a car

[0046] Person: ⇓ * performs a security-relevant action 102 on a technical authentication system 100 which has implemented the dopeIN procedure 1000 → A car driver wants to deactivate the immobilizer in his car in order to start the engine. To do this, he presses the start button in his car. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 105 → Using the user-defined car key stored in the on-board computer and the pressed start button on the car, the on-board computer recognizes that it is a legitimate car key of the car driver and executes the associated dopeIN algorithm 107 of the requesting car driver (dopeIN user) 101 out of 105. * generates the temporary authentication data 109 * stores 104 these temporary authentication data 109 for further dopeIN data processing → By executing the associated dopeIN algorithm 107, the temporary authentication data 109 is generated and stored in the on-board computer of the car. * optionally displays 110 of these temporary authentication data 109 * opens an input dialog and prompts for the entry of the temporary dopeIN input code 112 111 → The car's on-board display then shows this temporary authentication data 109. At the same time, the car driver is asked to enter the temporary dopeIN entry code 112. Person: ⇓ * cognitively determines, based on the previously defined dopeIN algorithm 107, the security fragment which the machine needs for subsequent dopeIN data processing 106 in order to confirm correct authentication (see

[001] ) and report it as output 113 → The car driver checks the temporary authentication data 109 displayed on the on-board display in order to then determine the temporary dopeIN input code 112 using cognitive performance. * adds another security fragment (temporary dopeIN input code 112) to the dopeIN data processing 106 by means of input 103 → The car driver enters the temporarily determined dopeIN input code 112 on the car's on-board display and confirms his entry. Machine: ⇓ * executes the respective dopeIN algorithm 107 of the respective dopeIN user 101 to validate and verify all fragments of the security-relevant system request 102 106 → By confirming the entry of the temporary dopeIN entry code 112 in the on-board display, the on-board computer then executes the dopeIN algorithm 107 associated with the car key of the car driver (dopeIN user) 101 out of 106. ⇓ * checks all individual security fragments for plausibility (107, 108, 109, 112) ⇓ * checks whether all security fragments match each other 106 ⇓ * verifies the content of all security fragments, depending on their definition 106 ⇓ * Based on dopeIN data processing 106, generates the temporary result of the dopeIN authentication check as output 113 * Depending on the temporary result 113 of the dopeIN authentication check, 106 further steps are performed 114 → Depending on the result of the security-related request to deactivate the immobilizer, further predefined steps can now be taken. If the result is positive, the immobilizer can be deactivated, allowing the engine to be started in the next step. If the result is negative, an error message may be displayed on the on-board display indicating that correct authentication has not taken place.

[0047] Implementation phase 2000, as in Figure 2 shown

[0048] To use individual algorithm-based multi-factor authentication (dopeIN) 1000 between an individual system user 101 and a technical authentication system 100, technical elements / tools 115 must first be created and managed. This takes place within the implementation phase 2000.

[0049] An individual system user 101 creates an individual software- or hardware-based dopeIN algorithm 107 using their cognitive abilities, a technical security system 200, and technical elements / tools 115. The individual system user 101 does not require any background knowledge in cryptography, computer science, or mechanics.

[0050] The dopeIN algorithm 107 is the technical product or construct that defines data processing processes 105, 106 with the goal of secure "individual human-machine authentication". The dopeIN algorithm 107 is a separate security component of the individual algorithm-based multi-factor authentication (dopeIN) 1000.

[0051] Under dopeIN administration 116, an administrative unit (person and / or organization) is understood to be one that implements the dopeIN procedure 1000 into its security process and organizes the necessary personnel and technical prerequisites 2000, 3000. Procedure-related synchronization processes for exchanging non-public data, such as a system-specific "procedure for storing and using secret authentication data" 117, are extended to include the dopeIN procedure 1000 (see...). Fig. 4 ).

[0052] The dopeIN administration must consider when and to what extent dopeIN algorithms are used and who defines and manages them. The advantages and disadvantages of individual design freedom must be weighed against systematized restrictions and regulations (see...). Fig. 4 ).

[0053] Similarly, the dopeIN administration defines 116 hardware and / or software components of 100 technical authentication systems and 200 technical security systems and assigns how and where: the technical elements / tools 115 for the creation and management of dopeIN algorithms 107 are provided, dopeIN user data 104 are managed, dopeIN algorithms 107 are generated 127, dopeIN algorithms 107 are executed 105, 106, the temporary authentication data 109 are managed, the respective optional dopeIN displays 110 are shown, the respective inputs of the dopeIN input codes 103 are made, and how the respective outputs of the dopeIN data processing 105, 106, 127 are to be interpreted and managed.

[0054] The advantages and disadvantages of internal or external data processing processes and services must be weighed against each other (see...). Fig. 2 , Fig. 3 , Fig. 4 ).

[0055] The dopeIN administration 116 also decides when and how further techniques, procedures and standards (see

[009] ,

[014] ) are to be integrated in the context of the implementation of individual algorithm-based multi-factor authentication (dopeIN).

[0056] Based on a dopeIN algorithm 107, temporary authentication data 109 is generated (see dopeIN generation procedure) 105 and analyzed and verified in the subsequent verification process (see dopeIN verification procedure) 106. The dopeIN algorithm 107 fulfills at least the following security aspects: It integrates at least one jointly agreed-upon secret authentication code 108, which is known to both parties, i.e., the individual system user 101 and the technical authentication system 100. It is itself a security fragment—the authentication checks. It includes a user-defined dopeIN generation procedure 105. When executed, this procedure generates a temporary security fragment (dopeIN authentication data) 109. It includes a user-defined dopeIN verification procedure 106. This procedure performs logical checks on various input parameters (temporary authentication data 109, temporary dopeIN input code 112, and secret authentication code 108) in relation to each other and returns a temporary result of these checks as output 113.

[0057] The table below summarizes the individual steps of the 2000 implementation phase.

[0058] dopeIN implementation phase: Human ⇔ Machine Human (dopeIN Administration 116) * implements the dopeIN procedure 1000 into the security process and informs the individual system users 101 about the content and application of the individual algorithm-based multi-factor authentication (dopeIN) 1000 ( Fig. 1 , cf. Fig. 4 ) * provides or specifies the technical prerequisites for the definition and interpretation of dopeIN algorithms 107 (see Fig. 4 ) Human (dopeIN user 101) * creates, selects from 118, generates 127 or receives 118 a dopeIN algorithm 107, which * itself represents a security fragment of the dopeIN data processing operations 105, 106, 127 * includes a user-defined dopeIN generation procedure 105 which, when executed, generates a temporary security fragment (dopeIN authentication data) 109 for the pending dopeIN data processing 106 * includes a user-defined dopeIN verification procedure 106 which, when executed, performs logical verifications of different input parameters (security fragments) depending on each other and provides the result 113 of these verifications 106 as a temporary output (see Fig. 3 ) Machine: * represents the technical hardware and software 100, 200, 115 for generating, managing (creating, editing, modifying, saving and deleting) and executing security fragments of the individual algorithm-based multi-factor authentication (dopeIN) 1000. (cf. Fig. 4 )

[0059] To enable an individual system user 101 without knowledge of cryptography, computer science or mechanics to generate and manage individual security fragments of individual algorithm-based multi-factor authentication (dopeIN), further technical elements / tools are required 115. (cf. Fig. 2 )

[0060] These technical elements / aids include 115: dopeIN rule sets 120, dopeIN calculation rules 123, dopeIN phrases 124, dopeIN patterns 119, dopeIN levels of consideration 122, dopeIN assignment levels 121, dopeIN assignment patterns 126 and dopeIN[-algorithm templates] 125.

[0061] To generate 127 dopeIN algorithms 107, templates, so-called dopeIN[-algorithm templates] 125, can be used or individually created 118. These dopeIN[-algorithm templates] 125 contain the framework of a dopeIN algorithm 107, but not secret information such as authentication codes 108.

[0062] With the help of dopeIN rule sets 120, applicable dopeIN phrases 124 and dopeIN calculation rules 123 are generated. This allows both simple and very complex calculation and data processing operations 105, 106, 107 to be represented. The dopeIN user 101 selects the level of complexity according to their individual security needs and their own cognitive abilities.

[0063] The creation and use of dopeIN rule sets 120, dopeIN calculation rules 123 and dopeIN phrases 124 is the responsibility of the dopeIN user 101 and is, if necessary, aligned with the specifications of the dopeIN administration 116, which uses or implements the dopeIN procedure 1000 (see Fig. 4 ).

[0064] dopeIN calculation rules 123 control in the simplest way how calculations are to be performed by the technical authentication system 100 by executing the dopeIN algorithm 107. They also define how the individual system user 101 is to proceed.

[0065] The following are examples of different dopeIN calculation rules 123, deliberately omitting reference numbers. They range from very simple (Level 1a) to too heavy (Level 2c). The operators in the arithmetic problems consist of single-digit decimal numbers (0-9).

[0066] dopeIN calculation rules of level 1a: 1. Regardless of the operator or operand, calculations always proceed from left to right, and a result is determined for every two operands and one operator. 2. If a result is a two-digit decimal, only the units digit is used for the solution. 3. There are only two operands and one operator. 4. Only addition (+) or subtraction (-) are permitted as operators. 5. If the result of an operation is less than 0, the number 10 is added to the first operand, and the calculation continues from there.

[0067] Examples include: arithmetic problem Solution doubleN - input code Explanation of the solution 1 + 1 =? 1 + 1 = 2 2 The units digit corresponds to the solution. 6-3=? 8-3=3 3 1 + 9 =? 1 + 9 = 10 0 9 + 7 =? 9 + 7 = 16 6 2 - 3 =? 2 - 3 ⇒ 10 + 2 - 3 ⇒ 12 - 3 = 9 9 If the result is less than 0, 10 is added to the first operand. The units digit represents the solution. 0 - 6 =? 0 - 6 ⇒ 10 + 0 - 6 ⇒ 10 - 6 = 4 4

[0068] dopeIN calculation rules of level 1b: Note: All dopeIN calculation rules of level 1a apply: (1-5), in addition point 6 applies: 1. Regardless of the operator or operand, calculations always proceed from left to right, and a result is determined for every two operands and one operator. 2. If a result is a two-digit decimal, only the units digit is used for the solution. 3. There are only two operands and one operator. 4. Only addition (+) or subtraction (-) are permitted as operators. 5. If the result of an operation is less than 0, the number 10 is added to the first operand, and the calculation continues with that value. 6. Multiplication (*) and division ( / ) operators are used for integration. However, they are used as placeholders, with (*) representing addition and ( / ) representing subtraction.

[0069] Examples include: arithmetic problem Solution dopeIN entry code Explanation of the solution 1 + 9 =? 1 + 9 = 10 0 The units digit corresponds to the solution. 1 * 9 =? 1 * 9 ⇒ 1 + 9 = 10 0 (*) is interpreted as (+). The units digit corresponds to the solution. 4 / 5 =? 4 / 5 ⇒ 4 - 5 ⇒ 10 + 4 - 5 ⇒ 14 - 5 = 9 9 ( / ) is interpreted as (-). If the result is less than 0, 10 is added to the first operand. The units digit represents the solution.

[0070] dopeIN calculation rules of level 1c: Note: The dopeIN calculation rules of level 1a apply: (1-3 and 5), points 4 and 6 are changed or added: 1. Regardless of the operator or operand, calculations always proceed from left to right, and a result is determined for every two operands and one operator. 2. If a result is a two-digit decimal, only the units digit is used for the solution. 3. There are only two operands and one operator. 4. The only permitted operators are addition (+), subtraction (-), and multiplication (*). 5. If the result of an operation is less than 0, the number 10 is added to the first operand, and the calculation continues with that value. 6. Division ( / ) is used for integration. However, it serves as a placeholder for subtraction.

[0071] Examples include: Receipt Solution dopeIN entry code Explanation of the solution 3 * 9 =? 3 * 9 = 27 7 The units digit corresponds to the solution 7 * 8 =? 7 * 8 = 56 6 3 / 7 =? 3 / 7 ⇒ 3 - 7 ⇒ 10 + 3 - 7 ⇒ 13 - 7 = 6 6 ( / ) is interpreted as (-). If the result is <0, 10 is added to the first operand. The units digit corresponds to the solution.

[0072] dopeIN calculation rules of level 1d: Note: The dopeIN calculation rules of level 1c apply: (1, 3, 4, 5, 6), point 2 is changed: 1. Regardless of the operator or operand, calculations always proceed from left to right, and a result is determined for every two operands and one operator. 2. If a result is a two-digit decimal greater than 10, only the tens digit is used for the solution. 3. There are only two operands and one operator. 4. The only permitted operators are addition (+), subtraction (-), and multiplication (*). 5. If the result of an operation is less than 0, 10 is added to the first operand, and the calculation continues with that value. 6. Division ( / ) is used for integration. However, it serves as a placeholder for subtraction.

[0073] Examples include: arithmetic problem Solution dopeIN entry code Explanation of the solution 3 * 9 =? 3 * 9 = 27 2 If the result is >10, the tens digit corresponds to the solution. 7 * 8 =? 7 * 8 = 56 5 1 / 1 =? 1 / 1 ⇒ 1 - 1 = 0 0 ( / ) is interpreted as (-). If the result is <= 10, the units digit of the solution is used. 5 * 2 =? 5 * 2 = 10 0 If the result is <= 10, the units digit corresponds to the solution. 5 + 7 =? 5 + 7 = 12 1 If the result is >10, the tens digit corresponds to the solution. 8 / 9 =? 8 / 9 ⇒ 8 - 9 ⇒ 10 + 8 - 9 ⇒ 18 - 9 = 9 9 ( / ) is interpreted as (-). If the result is <0, 10 is added to the first operand. The units digit corresponds to the solution.

[0074] dopeIN calculation rules of level 1e: Note: The dopeIN calculation rules of level 1a apply: (1 and 3), points 2, 4, 5 are changed: 1. Regardless of the operator or operand, calculations always proceed from left to right, and a result is determined for every two operands and one operator. 2. If a result is a two-digit decimal, the digit sum is calculated, and the units digit of this sum is used as the result. 3. There are only two operands and one operator. 4. Only addition (+) and multiplication (*) are permitted as operators. 5. The operators for subtraction (-) and division ( / ) are integrated. However, they are used as placeholders, with (-) and ( / ) serving as placeholders for addition.

[0075] Examples include: arithmetic problem Solution dopeIN entry code Explanation of the solution 5 * 5 =? 5 * 5 = 25 ⇒ 2 + 5 = 7 7 If the result has two digits, the digit sum is calculated. The units digit corresponds to the solution. 7 * 7 =? 7 * 7 = 49 ⇒ 4 + 9 = 13 3 9 - 9 =? 9 - 9 ⇒ 9 + 9 = 18 ⇒ 1 + 8 = 9 9 (-) is interpreted as (+). If the result has two digits, the digital root is calculated. The units digit corresponds to the solution. 1 / 9 =? 1 / 9 ⇒ 1 + 9 = 10 ⇒ 1 + = 1 1 ( / ) is interpreted as (+). If the result has two digits, the digital root is calculated. The units digit corresponds to the solution.

[0076] dopeIN calculation rules of level 2a: 1. Calculations are always performed from left to right, regardless of the operator. The order of operations (multiplication and division before addition and subtraction) is disregarded. Each pair of operands and one operator forms an intermediate result until a final result can be determined. 2. If an intermediate result or final result is a two-digit decimal greater than 18, only the units digit is used for the intermediate result or final result. 3. There are multiple operands and multiple operators. 4. Only addition (+) or subtraction (-) are permitted as operators. 5. If the result of an arithmetic operation is less than 0, the number 10 is added to the first operand, and the calculation continues from there.

[0077] Examples include: arithmetic problem Solution dopeIN entry code Explanation of the solution 1 + 9 + 2 =? 1 + 9 + 2 ⇒ 10 + 2 = 12 2 The units digit corresponds to the solution. 5 - 6 + 1 =? 5 - 6 + 1 ⇒ 10 + 5 - 6 + 1 ⇒ 15 - 6 + 1 ⇒ 9 + 1 = 10 0 If the result is less than 0, 10 is added to the first operand. The units digit represents the solution. 2 - 3 + 9 =? 2 - 3 + 9 ⇒ 10 + 2 - 3 + 9 ⇒ 12 - 3 + 9 ⇒ 9 + 9 = 18 8 If the result is less than 0, 10 is added to the first operand. The units digit represents the solution. 4 - 1 + 2 - 3 =? 4 - 1 + 2 - 3 ⇒ 3 + 2 - 3 ⇒ 5-3=2 2 The units digit corresponds to the solution.

[0078] dopeIN calculation rules for level 2b: Note: All dopeIN calculation rules for level 2a apply: (1-5), in addition point 6 applies: 1. Calculations are always performed from left to right, regardless of the operator. The order of operations (multiplication and division before addition and subtraction) is disregarded. Each pair of operands and one operator forms an intermediate result until a final result can be determined. 2. If an intermediate result or final result is a two-digit decimal greater than 18, only the units digit is used for the intermediate result or final result. 3. There are multiple operands and multiple operators. 4. Only addition (+) and subtraction (-) are permitted as operators. 5. If the result of an arithmetic operation is less than 0, the number 10 is added to the first operand, and the calculation continues with this value. 6. Multiplication (*) and division ( / ) operators are used for integration. However, they are used as placeholders, with (*) representing addition and ( / ) representing subtraction.

[0079] Examples include: arithmetic problem Solution dopeIN entry code Explanation of the solution 3 * 4 * 9 + 1 / 2 =? 3 * 4 * 9 + 1 / 2 ⇒ 3 + 4 * 9+ 1 / 2 ⇒ 7 * 9 + 1 / 2 ⇒ 7 + 9 + 1 / 2 ⇒ 16 + 1 / 2 ⇒ 16 + 1 - 2 ⇒ 17 - 2 = 15 5 (*) is interpreted as (+). ( / ) is interpreted as (-). The units digit corresponds to the solution. 1 - 9 * 3 =? 1 - 9 * 3 ⇒ 10 + 1 - 9 * 3 ⇒ 11 - 9 * 3 ⇒ 2 * 3 ⇒ 2 + 3 = 5 5 (*) is interpreted as (+). The intermediate result will be <0, therefore 10 is added to the first operand. ( / ) is interpreted as (-). The units digit corresponds to the solution.

[0080] dopeIN calculation rules for level 2c: Note: The dopeIN calculation rules for level 2a apply: (1-3 and 5), points 4 and 6 are changed or added: 1. Calculations are always performed from left to right, regardless of the operator. The order of operations (multiplication and division before addition and subtraction) is disregarded. Each pair of operands and one operator forms an intermediate result until a final result can be determined. 2. If an intermediate result or final result is a two-digit decimal greater than 18, only the units digit is used for the intermediate result or final result. 3. There are multiple operands and multiple operators. 4. Only addition (+), subtraction (-), and multiplication (*) are permitted as operators. 5. If the result of an operation is less than 0, the number 10 is added to the first operand, and the calculation continues with that value. 6. Division ( / ) is used for integration. However, it serves as a placeholder for subtraction.

[0081] For example: math problem and Solution dopeIN entry code Explanation of the solution 5 / 2 * 9 - 8 9 ⇓ ( / ) is interpreted as (-). 5 - 2 * 9 - 8 ⇓ 3 * 9 = 8 ⇓ 27 - 8 ⇓ If the intermediate result is a two-digit number and >18, the units digit is used for further calculation. 7 - 8 ⇓ If the result is <0, 10 is added to the first operand. 10 + 7 - 8 ⇓ 17 - 8 = 9 The units digit corresponds to the solution.

[0082] Syntactic units are defined using dopeIN phrases 124, which receive their value assignments during dopeIN data processing 105,106 technically and cognitively 102, 103. Examples: dopeIN phrases

[0083] The table below lists examples of dopeIN phrases 124 and links them to a identifier. For better understanding, the data type is also listed, but reference numbers are deliberately omitted. Value of the dopeIN phrase mark Data type remark please A text Extra B text sharp C text m1t D text S4hn3 E text (DDMMYYYY-hh:rnm:ss) F text Dynamic assignment of system date and system time in the described format (e.g. : 25.12.2017-11:11:11)

[0084] Using dopeIN patterns 119, temporary authentication data 109 can be generated (see dopeIN generation procedure 105) and analyzed and verified in the subsequent verification process (see dopeIN verification procedure 106).

[0085] dopeIN patterns 119 are divided into several layers. The layers are named as follows: dopeIN viewing levels 122 dopeIN assignment levels 121

[0086] Only when the dopeIN user 101 knows the dopeIN pattern 119 with its levels 121, 122 during a security-relevant action 102 is he able to correctly interpret the authentication data 109.

[0087] The creation and use of dopeIN patterns 119 is the responsibility of the dopeIN user 101 and is subject, if necessary, to the specifications of the dopeIN administration 116, which uses or implements the dopeIN procedure 1000.

[0088] The dopeIN viewing levels 122 deal with the individual perspectives on the temporary authentication data 109. They focus on the selection of different decimal numbers, operators, and / or characters. Relationships between the place values ​​of the display pairs and the place values ​​of the temporary dopeIN input code 112 are defined. Examples of different dopeIN viewing levels 122 are outlined below, deliberately omitting reference numbers. Examples: dopeIN viewing levels (two-line display / four-digit assignment)

[0089] Examples of dopeIN viewing levels 122, a two-line dopeIN display of the authentication data 109, 110 and the four-digit assignment for the interpretation of a dopeIN input code to be solved 112 are shown below. The text is read from left to right and top to bottom. The small numbers 1-4 indicate the corresponding decimal place of the dopeIN input code 112. Designation of the doubleN level of consideration dopeIN ad Explanation of the assignment to the decimal place of the dopeIN input code 1 ⇒ 10 3< 2 ⇒ 10 2< 3 ⇒ 10 1< 4 ⇒ 10 0< vertical 4+ 5+ 3- 8- diagonal_A 4+ 5- 3- 8+ individual_1 -4 -3 8- 5 * individual_2 +9 -1 +8 +5 Examples: dopeIN viewing levels (four-line display / individual assignment)

[0090] The following examples show dopeIN viewing levels 122, a four-line dopeIN display 109, 110 and the individual assignment for the interpretation of a dopeIN input code to be solved 112. The text is read from left to right and from top to bottom. The small numbers 1-8 indicate the corresponding decimal place of the dopeIN input code 112. Designation of the dopeIN viewing level dopeIN ad Explanation of the assignment to the decimal place of the dopeIN input code 1 ⇒ 10 7< 2 ⇒ 10 6< 3 ⇒ 10 5< 4 ⇒ 10 4< 5 ⇒ 10 3< 6 ⇒ 10 2< 7 ⇒ 10 1< 8 ⇒ 10 0< individual_A -3 +4 6+ 5- -6 3+ +5 4- no assignment 1 ⇒ 10 3< 2 ⇒ 10 2< 3 ⇒ 10 1< 4 ⇒ 10 0< individual_B 1- 8 * * 1 * 0 no assignment 1 ⇒ 10 3< 2 ⇒ 10 2< 3 ⇒ vertical_big 9 - 5+ 9 + 5- 9 + 9+ Examples: dopeIN viewing levels (single-line display / five-digit assignment)

[0091] The following examples show dopeIN viewing levels 122 of a single-line dopeIN display of the authentication data 109, 110 and the five-digit assignment for the interpretation of a dopeIN input code to be solved 112. The text is read from left to right and top to bottom. The small numbers 1-5 indicate the corresponding decimal place of the dopeIN input code 112. Designation of the doubleN level of consideration doubleN display Explanation of the assignment to the decimal place of the dopelN input code 1 ⇒ 10 3< 2 ⇒ 10 3< 3 ⇒ 10 3< 4 ⇒ 10 1< 5 ⇒ 10 0< myView_01 8+ 1- -7 8 + 1 - 7- myView_02 8+ +1 +7 +3 73 3+

[0092] The dopeIN assignment levels 121 deal with the positioning of dopeIN rule sets 120 and dopeIN observation levels 122, which are assigned in the form of dopeIN assignment patterns 126. dopeIN phrases 124, operators, operands, intermediate results, results, and dopeIN calculation rules 123 can be assigned. Predefined dopeIN assignment patterns 126 can be used, or individual dopeIN assignment patterns 126 can be defined as the basis for the assignments.

[0093] By assigning random values ​​within dopeIN assignment patterns 126, the physical input 103 of the temporary dopeIN input code 112 is distributed across the entire input field. This significantly hinders the derivation of pressure traces (dirt profiles, fingerprints, etc.).

[0094] When designing dopeIN assignment patterns 126, the interpretation and assignment of multiple authentication codes and / or further software and / or hardware components as supplementary security levels (see

[009] ) is possible. All applied security fragments can be added to the authentication process in parallel in a single step by entering the dopeIN input code 112. This speeds up the authentication process.

[0095] For technical authentication systems 100 that only allow single-line or no representations of the authentication data 109, 110, it makes sense to define a static operator. Statically stored alternating operators or operands that follow a predefined static dopeIN assignment pattern 126 are also possible. Likewise, the use of a random operand or a random result is permissible. The interpretation and assignment of a 2FA code and / or other software and / or hardware components as supplementary security elements is also applicable (see

[009] ). Examples of static dopeIN assignment patterns Example 1:

[0096] The following table shows examples of the positioning and assignment possibilities of two operands, an operator, the result and an eight-digit authentication code 108 using a single-line authentication data display 109, 110, whereby reference numbers have been deliberately omitted in the table and description.

[0097] The following applies: Fields labeled "Result" represent the dopeIN display. Fields labeled "Operand 2" represent the dopeIN input code and are marked with dopeIN[]. The operator is defined as a static dopeIN assignment pattern, marked with (), and is: + + - - + - - +. Random values ​​are marked with {}. The authentication code is static, marked with PIN, and is 47110815. The dopeIN viewing level is "vertical". The dopeIN calculation rules of level 1a apply. Example 2:

[0098] The following table shows, by way of example, the positioning and assignment possibilities of two operands, an operator, the result and an eight-digit authentication code 108 without publication / display of the temporarily generated authentication data 109, whereby reference numbers have been deliberately omitted in the table and description.

[0099] The following applies: The operator was defined as a static dopeIN assignment pattern, marked with (), and is: + - + - + - + -. Fields labeled as Operand 2 represent the dopeIN input code and are marked with dopeIN[]. The authentication code is static, marked with PIN, and is 47110815. The result is dynamic, marked with {DDMMhhmm}, and refers to the current date and time, here 16031255. The dopeIN viewing level is vertical. The dopeIN calculation rules of level 1a apply. Example 3:

[0100] The following table shows an example of the use of an individual dopeIN phrase 124, whereby reference numbers have been deliberately omitted in the table and description.

[0101] The following applies: Random values ​​are marked with {}. Fields named dopeIN[] represent the dopeIN input code. The secret, secure authentication code is marked with CODE and is myPASSWORD. The individual dopeIN phrase is marked with ∘ !!, ∘ is SuPeR, and is inserted after the fourth character of the authentication code.

[0102] Another security factor is the use of dynamic dopeIN assignment patterns 126. Each security fragment that is dynamically integrated into the authentication process provides increased protection against unauthorized access to a security-relevant system action 102. Examples of dynamic dopeIN assignment patterns Example 1:

[0103] Example 1 shows the positioning and assignment possibilities of two operands, an operator, the result and a three-digit authentication code 108, whereby reference numbers have been deliberately omitted in the table and description.

[0104] The following applies: Fields labeled Operand 1 and Operator represent the dopeIN display. Fields labeled Operand 2 represent the dopeIN input code and are marked with dopeIN[]. Random values ​​are marked with {}. The result is static, represents the authentication code, is marked PIN, and is 449. The dopeIN viewing level is vertical. The dopeIN calculation rules of level 1a apply. Example 2:

[0105] The following table shows examples of the positioning and assignment possibilities of three operands, an operator, the result and a three-digit authentication code 108, whereby reference numbers have been deliberately omitted in the table and description.

[0106] The following applies: Fields labeled Operand 1 and 2 and Operator 1 and 2 represent the dopeIN display. Fields labeled Operand 3 represent the dopeIN input code and are marked with dopeIN[]. Random values ​​are marked with {}. The result is static, represents the authentication code, is marked with PIN, and is 333. The dopeIN viewing level labeled vertical_big applies. The dopeIN calculation rules of level 2a apply.

[0107] Individual dopeIN assignment patterns 126 offer dopeIN users 101 the greatest possible freedom in assigning dopeIN viewing levels 122, dopeIN calculation rules 123, and dopeIN phrases 124. The creativity of each individual dopeIN user 101 can thus be profitably incorporated into the individual algorithm-based multi-factor authentication (dopeIN) 1000. Examples of individual dopeIN assignment patterns Example 1:

[0108] Example 1 shows the use of dynamic operators determined on the basis of a 6-digit 2FA code (see

[009] ), where reference numbers have been deliberately omitted in the table and description.

[0109] The following is defined as an individual dopeIN assignment pattern: If the respective decimal place of the 2FA code (see

[009] ) is even, an addition follows; if it is odd, this leads to a subtraction. If the decimal number is 0, a multiplication or division is generated randomly.

[0110] The following applies: Fields labeled Operator 1 and Result represent the dopeIN display. Fields labeled Operand 2 represent the dopeIN input code and are marked with dopeIN[]. Random values ​​are marked with {}. Operand 1 is static, represents the authentication code, is labeled PIN, and is 753219. The dopeIN viewing level is vertical. The dopeIN calculation rules of level 1b apply. A unique dopeIN assignment pattern exists that fulfills the above requirement; this is marked with !!. Example 2:

[0111] In this case, the current system date (DD.MM) is dynamically assigned to the second operator, here 13.03. Reference numbers have been deliberately omitted in the table and description.

[0112] The following applies: Fields labeled "Operator 1" represent the dopeIN display. Fields labeled "Result" represent the dopeIN input code and are marked with dopeIN[]. Random values ​​are marked with {}. The operand "list static", representing the authentication code, is marked with PIN and is 0815. The dopeIN viewing level is "vertical". The dopeIN calculation rules of level 1a apply. A unique dopeIN assignment pattern exists that meets the above requirements; this is marked with !!. Example 3:

[0113] In this example, the current system time (hh:mm) is dynamically assigned to the second operator, here 16:55. Additionally, the position of the dopeIN input code 112 changes per decimal place based on a previously defined positioning identifier.

[0114] The following table shows examples of all permutations and their respective assignments that can result from using two operands and one operator, and assigns a positioning indicator to each. Reference numbers have been deliberately omitted from the table and descriptions.

[0115] The following applies: The fields Operand 1 B & C, Operator A to F, Operand 2 A & D, and Result E & F represent the dopeIN display. The fields Operand 1 D & F, Operand 2 C & E, and Result A & B represent the dopeIN input code and are labeled dopeIN[]. Random values ​​are marked with {}. The secret, secure authentication code is labeled PIN. Positioning indicator Designation: A B C D E F Operand 1 Operator Operand 2 Result PIN { + , -} {0..9} dopeIN[] {0..9} { + , -} PIN dopeIN[] {0..9} { + , -} dopeIN[] PIN dopeIN[] { + , -} {0..9} PIN PIN { + , -} dopeIN[] {0..9} dopeIN[] { + , -} PIN {0..9}

[0116] The following applies to the individual dopeIN assignment pattern: Fields labeled "Operator 1" represent the dopeIN display. The fields "Operand 1 D & D" and "Result A & A" represent the dopeIN input code. Random values ​​are marked with {}. The authentication code is static, labeled "PIN," and is 4711. The dopeIN viewing level is "vertical." The dopeIN calculation rules of level 1a apply. An individual dopeIN assignment pattern exists that fulfills the above requirements; this is marked with !!. The current time is 16:55. The operands, authentication code, and result are assigned individually for each decimal place based on the positioning indicator. Example 4:

[0117] Example 4 illustrates the positioning and assignment possibilities of two operands, an operator, the result, and an 8-digit authentication code 108 on a single-line authentication data display 109, 110. Static dopeIN assignment patterns 126 are used for the operator, and individual dopeIN assignment patterns 126 are used for the dopeIN calculation rules 123 to be applied. Reference numbers have been deliberately omitted in the table and description.

[0118] The following applies: Fields labeled "Result" represent the dopeIN display. Fields labeled "Operand 2" represent the dopeIN input code and are marked with dopeIN[]. The operator is defined as a static dopeIN assignment pattern, marked with (). It is + * - / / * * / . Random values ​​are marked with {}. Operand 2 is static, represents the authentication code, is labeled PIN, and is 47110815. The dopeIN viewing level is vertical. Each decimal place has its own individually assigned dopeIN calculation rule. Example 5:

[0119] Example 5 shows the use of an individual dopeIN phrase 124, which is dynamically adapted and added at a specific position in the secure authentication code 108. Another individual dopeIN phrase 124 is assigned using the table: Examples: dopeIN phrases (see

[041] ) and appended to the end of the authentication code 108. The temporarily generated authentication data 109 is not published / displayed. Reference numbers have been deliberately omitted from the table and description.

[0120] The following applies: • Fields named dopeIN[] represent the dopeIN input code. • The secret, secure authentication code is marked with PASSWORD and is my&&word. • The secret, individual dopeIN phrase ∘ is marked with !!, ∘ is inserted after the position of the first & character of the authentication code, ∘ is dynamic and corresponds to today's system date (DDMM), here 24.12. • Another individual dopeIN phrase will be • Using the individual table, examples: dopeIN phrases / identifiers: B assigned, here EXTra, ∘ marked with !!, ∘ and inserted at the last position of the authentication code. Fragments of dopeIN data processing Designation: Value of the fragment Fragment 1 PASSWORD my word Fragment 2 !individual dopeIN phrase! !2412! Fragment 3 Examples: Phrases / Characteristics: B! !Extra! ⇓ ⇓ dopeIN entry code dopeIN[] [my&2412&wordEXTra] Example 6:

[0121] Example 6 shows the use of a custom dopeIN phrase 124, which is dynamically adapted and added to a specific position in the secure authentication code 108. This dynamic adaptation is achieved through several data processing operations. Reference numbers have been deliberately omitted from the table and description.

[0122] The following applies: Fields labeled as Operator 1 represent the dopeIN display. Fields labeled dopeIN[] represent the dopeIN input code. Random values ​​are marked with {}. The authentication code is labeled CODE and is pa{}s{}st. Operand 1 is static, represents another authentication code, is labeled PIN, and is 1357. The secret individual dopeIN phrase ∘ is marked with !!, ∘ replaces all {} characters of the authentication code, ∘ is determined using the global dopeIN calculation rules of level 1a, ∘ is dynamic and corresponds to the system time (hhmm), here 11:55.

[0123] The dopeIN user 101 can directly influence the dopeIN display 110. This allows the dopeIN user 101 to make visual markings that indicate whether the dopeIN display 110 was generated by a legitimate technical authentication system 100.

[0124] To protect against phishing (see

[008] ), the dopeIN user 101 can define, using a dopeIN assignment pattern 126, that certain characters and / or numbers of the dopeIN display 110 appear in a specific color, background color, or font. If these individually selected identifiers are not fulfilled by the technical system 101, it is immediately apparent to the dopeIN user 101, and to be expected, that the technical authentication system 100 has been compromised.

[0125] It is up to the competence, creativity, and experience of each dopeIN user to define their own dopeIN algorithm templates and generate dopeIN algorithms from them. A multitude of permutations and variations of these security fragments exist. The description here outlines some possibilities and provides rough examples.

[0126] The use of individual algorithm-based multi-factor authentication (dopeIN) 1000 integrates additional security elements into the authentication process. Therefore, the creation and / or continuous modification of the authentication code 108 is not mandatory. This automatically increases the acceptance of individual algorithm-based multi-factor authentication (dopeIN) 1000 among individual system users 101.

[0127] Likewise, the standardized intervals for changing authentication codes 108, which may already be specified by the dopeIN administration 116, can be increased.

[0128] The use of individual algorithm-based multi-factor authentication (dopeIN) 1000 addresses and technically represents the individual security needs of the dopeIN user 101 and / or the dopeIN administration 116 as a separate security fragment 107. It can be implemented in technical authentication and security systems 100, 200 2000 and applied within technical authentication systems 100 3000. At the same time, underlying variability is ensured, allowing future cryptographic security techniques, procedures, and extensions to be flexibly integrated. The flexibility and adaptability of individual algorithm-based multi-factor authentication (dopeIN) 1000 with regard to user needs is intended to promote acceptance among broad user groups. Sources on the state of the art include:

[0129] File number Brief description CH 713 015 A2 Input device and method DE 296 13 938 U1 Code entry system for check card payment systems and ATMs DE 10 2004 002 128 A1 Device and method of coded and / or non-coded commands DE 10 2008 019 034 A1 Method and device for determining an access code DE 10 2009 020 207 A1 Input terminal and PIN capture procedure DE 10 2009 012 011A1 PIN or password entry system for daily use in department stores to ensure discretion US 9 686 275 B2 Correlating cognitive biometrics for continuous identification verification US 9 672 335 B2 Cognitive-based logon process for computing device US 10 476 873 B2 Device, system, and method of password-less user authentication and password-less detection of user identity EP 1 010 049 B1 Generalized User Identification and Authentication System

Claims

1. Method (1000) for performing an authentication process (3000) by an individual system user (101), using technical security systems (200) which comprise hardware and software and are intended to generate, manage and execute an authentication algorithm (107), formed from security fragments, of individual algorithm-based multifactor authentication, on a technical authentication system (100) requiring authentication, wherein the method comprises: (a) the implementation (2000) of security fragments using the technical security system (200) by an administrator (116) and / or a system user (101) individualizing the authentication process at least in the form of patterns (119) and / or sets of rules (120) and / or algorithm templates (125) for generating an algorithm (127) for performing the authentication process (3000) within a technical authentication system (100) requiring the authentication (102), (b) the management (2000) of the implemented security fragments by the administrator (116) and / or the individual system user (101) within the technical security system (200), (c) the generation (2000) of the authentication algorithm (107) from implemented security fragments (119 to 126) by the individual system user (101) and the linking of this authentication algorithm (107) to an authentication code (108) determined by the individual system user (101), wherein the authentication algorithm (107) with authentication code (108) is assigned to a defined technical authentication system (100) by the individual system user (101), (d) performance (3000) of the authentication process by legitimizing (102) the individual system user (101) on a technical authentication system (100) that is selected by the system user (101) and requires authentication (102), and automatically generating (105) temporary authentication data (109) by means of executing the authentication algorithm (107) on the technical authentication system (100) based on the authentication algorithm (107) stored in the technical security system (200) for this technical authentication system (100) with reference to the authentication code (108) and transmitting said data to the individual system user (101), wherein data are exchanged between the technical security system (200) managing the authentication algorithm (107) with authentication code (108) and the technical authentication system (100) requiring authentication by way of synchronization processes (117) for exchanging non-public data, (e) use of the authentication algorithm (107) in conjunction with the authentication code (108) by the individual system user (101) for the purpose of converting the temporary authentication data (109) into a temporary input code (112) for input (103) and authentication (3000) of the individual system user (101) on the technical authentication system (100), and (f) performance of an authentication check (106) of the temporary input code (112) input by the individual system user (101) by the technical security system (200), with the inclusion of the generated temporary authentication data (109), and use of the authentication code (108) generated by the individual system user (101) and the authentication algorithm (107) for generating a temporary result (113) of the authentication check (106) for triggering defined steps of the system process (114) on the basis of this temporary result (113) of the authentication check (106).

2. Method (1000) for performing an authentication process (3000) according to Claim 1, characterized in that established known cryptographic security mechanisms are integrated into the method in order to implement the security fragments and / or to automatically generate (2000) and / or execute (3000) the security fragments.

3. Method (1000) for performing an authentication process (3000) according to Claim 1 or 2, characterized in that the complexity of the authentication process (3000) with user interaction (118) is scalable and can be determined by the individual system user (101) when implementing (2000) the security fragments (107, 119 to 126) for the authentication process (102).

4. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that a plurality of security techniques are processed in a single step in a parallel manner by means of a single input (103) by the individual system user (101).

5. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that the physical input (103) of the temporary input code (112) takes place in an input field and is requested and input in a manner distributed over the entire input field during use.

6. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that existing authentication codes (108) can be integrated into the authentication process and can thus be retained.

7. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that an individual system user (101) can already recognize, during the input prompt (111) of a requesting authentication system (100), by comparing the security fragments implemented by the individual system user (101) for the input prompt (111), whether the requesting authentication system (100) has the legitimacy to create the input prompt (111).

8. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that the security fragments for the individual algorithm-based multifactor authentications (1000), depending on how the individual algorithm-based multifactor authentication (1000) is implemented by the administration (116), are generated, managed (2000) and / or executed (3000) inside and / or outside the system.

9. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that the individual system user (101) generates (118) algorithm templates (125) by means of technical elements and / or aids (115) and implements the applicable authentication algorithm (107) in the authentication process (3000) in a manner adapted to his or her cognitive abilities, wherein the patterns (119) and sets of rules (120) can be individually combined with algorithm templates (125) and these algorithm templates (125) form the basis for generating (127) the algorithms (107) of the authentication process (3000).

10. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that the individual system user (101) defines and / or selects (118) user data (104), algorithms (107), patterns (119), sets of rules (120), assignment levels (121), viewing levels (122), calculation rules (123), phrases (124), algorithm templates (125) and assignment patterns (126) for the purpose of generating (127) the algorithms (107).

11. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that the patterns (119) consist of viewing levels (122) and assignment levels (121), wherein these assignment levels (121) include assignment patterns (126) and the sets of rules (120) consist of phrases (124) and / or calculation rules (123).

12. Method (1000) for performing an authentication process (3000) according to any of the preceding claims, characterized in that an authentication algorithm (107) consists of at least one user-defined generation procedure (105) and at least one user-defined verification procedure (106).

13. Program product (115) for performing an authentication process (3000) according to the method (1000) according to any of Claims 1 to 12 for completely or partially managing and generating user data (104), algorithms (107), patterns (119), sets of rules (120), assignment levels (121), viewing levels (122), calculation rules (123), phrases (124), algorithm templates (125) and assignment patterns (126), with instructions executable by a technical security system (200) and a technical authentication system (100) and the synchronization (117) of the authentication algorithm (107) between the technical security system (200) and the authentication system (100).

14. Computer program for performing an authentication process (3000) according to the method (1000) according to any of Claims 1 to 12, wherein the computer program runs on technical data processing machines as a technical security and authentication system (100, 200).

15. Technical construction for performing an authentication process (3000) according to the method (1000) according to any of Claims 1 to 12, wherein the technical construction comprises mechanical and / or electronic locks and / or locking systems and the technical security and authentication systems (100), (200) for applying the individual algorithm-based multifactor authentication (1000) with access to the mechanical and / or electronic locks and / or locking systems.