Two-way history-based dynamic-length password authentication system

Abstract

It can prevent skimming, forged cards, and server impersonation with a high degree of success, providing a highly reliable and readily available identity verification system. [Solution] An authentication system configured such that both the IC card and the server maintain a predetermined number of usage history records, when an authentication request is made, the server encrypts the connection records from a predetermined number of past connections and transmits them to the IC card via a card reader, the IC card compares the connection records with its own stored history to verify the legitimacy of the server, and then generates a long password that changes each time within the IC card based on the fluctuating value transmitted from the server, the value relating to the user, and the pointer value based on the usage history, transmits the long password to the server to perform user authentication, and after authentication, the IC card and the server mutually compare the latest connection records and update the usage history information.

Description

Technical Field

[0001] The invention of the present disclosure relates to a two-way history verification type dynamic long password authentication system.

Background Art

[0002] Conventionally, as a technique for mutual authentication between a memory card and a terminal, an authentication method using a counter and an encryption function in the memory card has been proposed (Patent Document 1). This publication describes a method of using a secret code based on the counter value at the end of a transaction for authentication in the next transaction.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the prior art, there are problems such as difficulty in automatic recovery when a discrepancy occurs between the card-side history and the server-side history, vulnerability to brute-force attacks with only a short PIN, and difficulty in preventing server impersonation even when only the card side is authenticated. Furthermore, the central problems to be solved by the invention of the present disclosure are: (i) making it substantially impossible to establish authentication without possession of the IC card even if the ID number or PIN is leaked; (ii) making it substantially impossible to create and use a copy (counterfeit card) even if the IC card is temporarily seized; (iii) making impersonation extremely difficult against attacks such as connection to a counterfeit card reader or counterfeit server, eavesdropping, tampering, and replay of communication; and (iv) converging to a state where the counterfeit card cannot pass verification after the genuine card has logged in at least once even if server-side data is leaked and a counterfeit card is created. The invention disclosed herein aims to solve these problems simultaneously and to achieve highly reliable and readily available personal authentication. [Means for solving the problem]

[0005] To solve the above problems, for example, the configuration described in the claims is adopted. This application includes several means for solving the above problems, but to give one example, An authentication system comprising a card reader, an IC card, and a server, An authentication system configured such that both the IC card and the server maintain a predetermined number of usage history records, when an authentication request is made, the server encrypts the connection records from a predetermined number of previous connections and transmits them to the IC card via the card reader, the IC card compares the connection records with its own stored history to verify the legitimacy of the server, and further generates a long password that changes each time within the IC card based on the fluctuating value transmitted from the server, the value relating to the user, and the pointer value based on the usage history, transmits the long password to the server to perform user authentication, and after authentication, the IC card and the server mutually compare the latest connection records and update the usage history information.

[0006] An authentication system configured such that the IC card first returns a dummy ID, which is different from the genuine ID and is generated according to predetermined rules as a signal to transition to the authentication protocol of the authentication system, in response to an identification number request from the card reader; the server receives the dummy ID via the card reader and, upon detecting that the dummy ID conforms to the rules, issues an ID request command to obtain a formal identification number, and subsequent communication transitions to a procedure that follows the authentication protocol of the authentication system.

[0007] The IC card is equipped with a ring-shaped memory that holds a predetermined number of connection records, and the authentication system is configured to perform the wrapping process of the pointer value associated with the update of the usage history by bitwise operation using a predetermined bitmask value on the pointer value.

[0008] The authentication system is configured such that the IC card holds a template table containing multiple types of long password prototypes, and the reference row of the template table is selected by computationally determining it based on at least a portion of the variable value transmitted from the server, a portion of the value relating to the user, and a pointer value based on the usage history, and then mapping the result of the computation to a predetermined range and using it as a template number.

[0009] Each prototype in the template table is provided with at least one blank space, and the IC card is configured as an authentication system in which a long password element is formed by inserting a replacement string obtained by applying a predetermined substitution table or a similar mapping rule to at least a portion of the value relating to the user into the blank space.

[0010] The IC card is an authentication system configured to hold an encryption scheme table consisting of multiple schemes, and to select and apply an encryption scheme to be applied prior to enclosing the long password in an encrypted packet, using a reference number obtained by a predetermined mapping rule based on at least a portion of the variable value and at least a portion of the value relating to the user.

[0011] The authentication system is configured such that the IC card redundantly holds a usage history pointer indicating the update position of the ring-shaped memory and has an instruction bit indicating the current reference destination, the server has an abnormality monitoring bit indicating that the history update procedure is incomplete, and if an abnormal termination is detected during the authentication process, the system compares the connection record held in the IC card and the connection record held in the server at positions that are shifted by 1 from each other to determine whether recovery is possible, and if recovery is successful, the integrity of the ring-shaped memory is restored by rolling back the usage history pointer or by a recovery update that does not switch the instruction bit.

[0012] An authentication system comprising a mode that uses facial recognition, wherein in this mode, the server compares a facial image with a registered facial image, and upon matching, the server encrypts the variable value and a temporary short password independent of the PIN and transmits them to the IC card, and the IC card generates the long password based on the received variable value and the temporary short password, and transmits it to the server.

[0013] An authentication system configured such that, after the server confirms that the long password matches, the IC card encrypts and transmits the latest connection record pointed to by the working pointer, and the server compares the internal expected value with the connection record and, upon matching, synchronizes the values ​​of the usage history pointer and the anomaly monitoring bit as an update process for the ring-shaped memory. [Effects of the Invention]

[0014] According to the invention disclosed herein, the card and the server match each other's histories and combine fluctuating values ​​from the server, user-related values, and pointer values ​​based on usage history to generate a different long password each time for authentication. Therefore, (a) even if the ID or PIN is leaked individually or in combination, it becomes virtually impossible to derive the correct response without the IC card. (b) Since the card proceeds with processing on the premise of matching a predetermined number of previous records (encrypted) from the server, impersonation by a fake server / fake reader or eavesdropping / replay is difficult to achieve. (c) After authentication, the history of both the server and the card advances monotonically through normal update C or recovery update C', and if the genuine card logs in even once first, a fake card duplicated from the same state will not match in subsequent matching and cannot be used. As a result, skimming, forged cards, and server impersonation can be prevented with an extremely high probability, providing highly reliable and readily available authentication. Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0015] [Figure 1] Overall system configuration diagram [Figure 2] Block diagram of authentication main flow A (A1 to A18) [Figure 3] Block diagram of long password generation flow B (B1 to B8) [Figure 4] Block diagram of normal update flow C (C1 to C6) [Figure 5] Block diagram of recovery update flow C' (C'1 to C'4)

Mode for Carrying Out the Invention

[0016] In this embodiment, an "interactive history verification type dynamic long password authentication system" 10 (hereinafter, may be referred to as an authentication system) composed of an integrated circuit card (hereinafter, IC card) used for credit settlement, personal authentication, entrance and exit management, etc., a card reader for reading the IC card, and an authentication server connected via the card reader will be exemplified and described. FIG. 1 is an overall configuration diagram of the authentication system 10. The authentication system 10 includes a card reader 20, an IC card 30, and a server 40, and the card reader 20 and the server 40 are directly or indirectly connected via a wired or wireless network. The card reader 20 may be incorporated into a payment terminal alone, or may be attached as an external module to a general-purpose device such as a smartphone.

[0017] When the user inserts or taps (in the case of non-contact type) the IC card 30, the card reader 20 supplies power and executes a reset procedure in accordance with the international standard ISO / IEC 7816. Thereafter, the card reader 20 relays messages to and from the server 40 using an Application Protocol Data Unit (APDU) and operates as the execution entity of the authentication protocol.

[0018] The IC card 30 has an encryption operation circuit, generates a session key according to the instruction of the server 40, and encrypts subsequent communications. Note that the encryption and key sharing methods widely include known methods and are not limited to public key encryption methods. For example, a common key (symmetric key) method, a challenge - response method, a method of distributing a temporary key based on random numbers, or a method using a message authentication code (MAC) can be appropriately selected according to design requirements such as the processing ability, delay, and price of the IC card.

[0019] Inside the IC card 30, a ring - shaped memory for holding connection records of a predetermined number of past cases (128 cases in this embodiment) is provided. To ensure the consistency of history updates, the usage history pointer indicating the update position is duplicated (Spx0 or Spx1), and a 1 - bit pointer instruction bit (0 = Spx0 / 1 = Spx1) indicating which one to adopt is provided together. Also, usage history pointers indicating the update positions of the ring - shaped memory are provided in both the IC card 30 and the server 40, and an anomaly monitoring bit is provided at least in the server 40 (a corresponding flag may be provided on the card side if necessary).

[0020] "Usage history information" refers to a broad concept including connection records (such as date and time information like year, month, day, hour, minute, second, etc. and random number sequences) held in the ring - shaped memory and usage history pointers (Spx, workSpx) indicating the update positions of the connection records.

[0021] "Pointer value based on usage history" is a value indicating a reference or update position on the ring - shaped memory, which is at least one of the values of the current usage history pointer (Spx) or the working pointer (workSpx), or a predetermined operation result (including addition, subtraction, bit operations, etc.) on them.

[0022] Furthermore, the IC card 30 stores a template table and an encryption method table for generating a different long password (long password) each time from a 4 - digit personal identification number (PIN) input by the user. In this embodiment, a configuration is adopted in which a different long - digit password is generated from the 4 - digit PIN using these tables, and the password is used for authentication.

[0023] The server 40 stores the identification information of each IC card 30 and up to 128 connection histories, and sequentially performs history verification, anomaly detection, password verification, and history synchronization based on messages received via the card reader 20, and sends the results back to the card reader 20.

[0024] The card reader 20, IC card 30, and server 40 each include at least a processor, main memory (RAM), auxiliary storage (flash memory, SSD, etc.), and communication control unit. The card reader 20 also includes a display device and a buzzer to alert the user in the event of authentication failure or other issues.

[0025] In this specification, the terms "card module," "reader module," and "server module" refer to the programs (or logical function blocks) stored in the main memory of the IC card 30, card reader 20, and server 40, respectively.

[0026] The main memory stores control programs that execute the authentication main flow A, the long password generation flow B, the normal update flow C, or the recovery update flow C'. The processor executes these programs to realize the functions of system 10. Detailed processing for each flow is shown in Figures 2 to 5 below.

[0027] Authentication Main Flow A is the main process from when the IC card is inserted into the card reader until successful login, and consists of steps A1 to A18. Long Password Generation Flow B consists of steps B1 to B8, is called at step A12 in Authentication Main Flow A, and generates a long password that changes each time and sends it to the server. Normal Update Flow C consists of steps C1 to C6, and when authentication is successful, it appends the connection record to the ring-shaped memory in the card and synchronizes the usage history pointer between the card and the server. Recovery Update Flow C' consists of steps C'1 to C'4, is executed when the previous connection terminated abnormally, and resolves the inconsistency in the ring-shaped memory based on the result of comparing the connection records of "50th / 51st connections" stored on the card and the server.

[0028] According to System 10 of this disclosure, the authenticity of both the IC card and the server is guaranteed with high precision, achieving a high level of security that prevents the use of fraudulent cards and server impersonation.

[0029] Verification of the "legitimateness" of a server or IC card is synonymous with verification of its "authenticity," and includes processes to eliminate impersonation by third parties by comparing past history (for example, comparing connection records from 101 times ago).

[0030] The System 10 disclosed herein can be used as a highly secure and available authentication platform in a variety of situations, such as authentication of the user for credit card and cash card payments using personal computers and smartphones, authentication of the user for credit card and cash card payments at store POS terminals, authentication of employee and student IDs at access control terminals in offices and research facilities, user authentication when smart locks are in operation at unmanned stores, shared offices, and rental warehouses, additional authentication for high-value transactions at ATMs and kiosk terminals, verification of permission to use automatic ticket gates and rental bicycle stations in public transportation, and user authentication at IoT devices such as EV charging stations and parking gates.

[0031] For each flow, the detailed processing content will be explained according to the step numbers in the diagram. Figure 2 illustrates each step of the authentication main flow A.

[0032] In step A1, when a card is inserted into the card reader, the reader module supplies power and a reset signal, and the card module replies with an Answer to Reset (ATR). The ATR contains an identification flag indicating that the card is compatible with the authentication protocol of the authentication system. Subsequently, based on the set of ciphers unique to the genuine ID number indicated by the card module, the card module and the server module determine the encryption method according to the encryption method index specified by the server and establish a secure channel to encrypt subsequent communications. In implementations that provisionally establish a secure channel before receiving the genuine ID number, a common provisional method may be used, and then, based on the receipt of the genuine ID number, the system may switch to the ID-specific method specified by the encryption method index.

[0033] The "authentication protocol of the authentication system" refers to the authentication, verification, and update procedure, including the main authentication flow A, the long password generation flow B, the successful update flow C, or the recovery update flow C'.

[0034] In this specification, "encryption scheme index" refers to an index value used to reference and select from multiple encryption and authentication schemes (including symmetric-key schemes, public-key schemes, challenge-response schemes, MAC schemes, etc.) that are commonly implemented in the card module and server module, according to a predetermined mapping rule. Furthermore, "encryption scheme group" refers to a set of candidate schemes mentioned above that are pre-registered and linked to the genuine ID number or card type.

[0035] In step A2, when the reader module requests the card module to send an identification number, the card module first replies with a dummy ID that is longer than 13 digits (e.g., 0123456789012…), which would not be possible with the conventional method. Upon receiving this response, the reader module determines that the card is "compatible with the new method" and notifies the server module of this determination.

[0036] A "dummy ID," unlike a true ID, is an identifier used as a signal to transition to the authentication protocol of the authentication system. Dummy IDs are generated by the card module according to predetermined rules, which are commonly recognized by both the card module and the server module. The rules may be based on fixed or variable values ​​and include a condition that the number must have at least one digit exceeding a predetermined threshold L (e.g., 13). The server module detects whether the received identifier conforms to the rules and, if so, issues an ID request command to obtain a formal identification number (true ID).

[0037] In step A3, the server module recognizes "dummy ID = new system signal" and issues an ID request command to obtain the official identification number. The reader module relays this command to the card module, which then returns the genuine ID (card-specific number). The reader module encrypts the received genuine ID with a common key shared by all card readers and sends it to the server module. After that, it switches to transparent mode, which transparently relays data without recognizing the header string. At the same time, the card module copies the current usage history pointer Spx to the working pointer workSpx (work area) and stores it there, ensuring that the main data is protected even in the event of a power outage before proceeding to the next step.

[0038] The terms "new method support" and "new method signal" mentioned above are interpreted as corresponding to the authentication protocol of the authentication system and signifying a signal for transitioning to that protocol.

[0039] In step A4, the server module connects via the security channel. (i) Connection record from 101 connections ago (date and time information + random number sequence), (ii) Previous abnormal termination flag (1 bit information that transferred the abnormality monitoring bit from within the server) The data is combined into a single packet and sent to the reader module. The card module decodes the received packet and compares the obtained record from 101 previous entries with the log from 101 previous entries held in the ring-shaped memory. At the same time, the previous abnormal termination flag obtained during the decodement process is stored in the working area and used for subsequent flow branching decisions. In the matching process, the working pointer workSpx is used as a reference pointer to immediately indicate the corresponding address in the ring-shaped memory. The connection record from "a predetermined number of times prior" is explained using 101 times prior as an example in this embodiment, but is not limited to this; it refers to the record from n times prior, according to the system setting value n.

[0040] In step A5, the card module compares the record from 101 connections prior to the previous one (out of 128 records) with the record received from the server module at the same location. If both records match, authentication proceeds to the normal route (step A11). If there is a mismatch, it is assumed that there may have been an error in the previous procedure, and in step A6, the abnormal termination flag is checked to determine whether recovery is possible.

[0041] In step A6, the value of the abnormal termination flag received by the card module is determined. If the flag is 0 (previous successful termination), the record mismatch 101 times ago is judged to be impersonation by a third party, and the process proceeds to the recovery failure process (step A9) described below. On the other hand, if the flag is 1 (previous abnormal termination occurred), the process proceeds to the recovery route (step A7).

[0042] In step A7, the connection records of the "last 50 sessions" held by the server module are compared with the connection records of the "last 51 sessions" held by the card module to determine if they match. If an abnormal termination occurred in the previous session, the connection history pointers on the card and server sides will shift by one, allowing the consistency to be confirmed through this comparison.

[0043] "Recording at positions shifted by 1" refers to a process that determines consistency by comparing the (k+1)th record on the card side with the kth record on the server side (or vice versa), assuming that the usage history pointers on the card side and the server side differ by 1 due to an incomplete previous session. Comparing 50th and 51st records is one example, and generally any value of k can be taken.

[0044] In step A8, the card module determines the result of comparing the records from 50 and 51 cycles ago. If the two records do not match, the recovery is considered a failure and the process proceeds to step A9. If they do match, the recovery process continues and the process moves to step A10.

[0045] In step A9, as part of the recovery failure process, the card module sends an error code back to the reader module, which then issues a warning via a buzzer sound or display. This completes the authentication main flow A.

[0046] In step A10, the card module assumes that the previous session was interrupted and rolls back by decrementing the working pointer workSpx, which is a copy of the usage history pointer Spx, by 1. This deliberately skips the most recent area that was empty in the ring memory, restoring the past 127 connection records held by the card module and server module to a fully synchronized state. The recovery procedure does not retransmit the latest history (data from 0 sessions ago), and log consistency is ensured solely through this rollback operation, thus avoiding unnecessary communication traffic and writes. Once the card module completes the rollback, it proceeds to the normal authentication route (step A11).

[0047] In step A11, the reader module, upon receiving an authentication initiation request from the card module, prompts the user to choose between entering a four-digit PIN or using facial recognition.

[0048] If the user selects the PIN method, the reader module transmits the PIN (0000-9999) entered by the user directly to the card module, and simultaneously relays a two-digit (hexadecimal 00h-FFh) shuffled number Wx received from the server module to the card module via the secure channel. The card module immediately proceeds to the authentication process (step A12: long password generation) using the PIN and Wx as input values.

[0049] "User-related values" refer to values ​​associated with user input or user identification, and include at least the PIN (Ax1~Ax4) and the temporary short password Axx (0000h~FFFFh) sent from the server when the facial recognition method is selected.

[0050] If the user selects the facial recognition method, the reader module sends facial image data captured by the camera to the server module. The server module compares the image with the registered facial image, and if there is a mismatch, it sends a "facial recognition failed" notification back to the reader module. The reader module displays this notification and sends a disconnection signal to the card module to terminate the session. If the matching is successful, the server module encrypts a randomly generated shuffled number Wx and a four-digit temporary short password Axx (0000h~FFFFh) that is shuffled independently of the PIN and has a different value each time, and sends them to the reader module. The reader module then forwards these to the card module. The card module uses the received Wx and Axx to proceed to the long password generation process (step A12).

[0051] In this step, the system securely transmits the input information and shuffled digit Wx (and a temporary short password Axx if necessary) to the card module according to the authentication method selected by the user, and then initiates the subsequent long password generation and verification sequence.

[0052] In step A12, the card module generates a long password to send to the server module along the long password generation flow B, using the variable value Wx, PINs Ax1 to Ax4, and the current usage history pointer value workSpx. In the long password generation flow B within the card module, a long password that changes each time is generated through the processes of selecting a template row, filling in the template blanks, and applying an encryption method, then encrypted and sent to the server module.

[0053] The fluctuating value transmitted from the server refers to the shuffled number Wx (including Wx1 and Wx2) which is generated randomly each time.

[0054] In step A13, the server module decrypts or verifies the received long password and matches it. If the match is successful and its legitimacy is confirmed, it sends an approval message back to the card module. Then, it proceeds to step A15. If the match is unmatched and authentication is rejected, it sends a rejection message back and proceeds to the subsequent authentication failure processing (step A14).

[0055] In step A14, as part of the authentication failure process, the server module determines that the IC card is fake when it detects a mismatch in the long password verification, sends an alarm code to the reader module to activate a buzzer or display device, and then the authentication main flow A ends.

[0056] In step A15, immediately after successful authentication, the card module encrypts the latest connection record (including the current time and random number sequence, etc.) indicated by the working pointer workSpx and sends it to the server module.

[0057] In step A16, the server module compares the most recently received connection record with the internal expected value. If they match, it immediately proceeds to the ring memory update process (step A17). If they do not match, it determines that authentication has failed, and the server module sends an alarm code to the reader module (step A14) to terminate the session. Note that if abnormal recovery is performed by the 50th / 51st previous comparison (steps A7-A10), the value of the working pointer workSpx will be the value of the usage history pointer Spx minus 1, and the comparison is performed using the expected value that takes this correction into account.

[0058] "Cross-referencing the latest connection records" is a concept that encompasses a series of steps after successful authentication, including (i) the server side verifying the latest connection record sent from the card side (step A16), (ii) sending the latest connection record generated by the server side to the card side for the card side to import (step C1), and (iii) synchronizing the connection records and usage history pointers on both the card side and the server side through these processes.

[0059] In step A17, if a match is confirmed, the card module calls either the normal update flow C or the recovery update flow C' as a ring-shaped memory update process.

[0060] In step A18, the reader module displays "Authentication successful," and the server module hands over the session key for business processing to the higher-level application. This completes the authentication main flow A, allowing services such as payment processing and access control to be started over the secure channel.

[0061] Figure 3 illustrates each step of the long password generation flow B. Long password generation flow B is a long password generation process called in step A12 of authentication main flow A. At the start of long password generation flow B, the card module already has the following information: two-digit Wx (Wx1 and Wx2) sent from the server module, four-digit PINs Ax1 to Ax4 entered by the user, and a working pointer workSpx (current usage history pointer) held internally by the card. Furthermore, the card module has pre-stored a template table and an encryption method table (up to 256 entries each) for long password generation.

[0062] The number of entries in the template table and encryption scheme table can be designed according to the equipment resources and security requirements, and the maximum number shown is only one example. The specific numerical values ​​in the following description are illustrative, and the inventions of this disclosure are not limited to these.

[0063] In step B1, the card module sequentially imports the following into a temporary workspace: a two-digit Wx (Wx1, Wx2) sent from the server, the four-digit PIN entered by the user converted into four numerical values ​​(Ax1~Ax4), and a usage history pointer (workSpx) indicating the previous connection order. For example, with Wx = 03 (Wx1=0x00(0), Wx2=0x03(3)), and PIN "0 4 1 1", Ax1=0x00(0), Ax2=0x04(4), Ax3=0x01(1), Ax4=0x01(1) are obtained, and the usage history pointer workSpx=0x05(5) is given. The card arranges these 7 bytes <0x00, 0x03, 0x00, 0x04, 0x01, 0x01, 0x05> in a contiguous address in memory (e.g., registers R0~R6) and proceeds to the next step B2.

[0064] In step B2, the card module selects a long password generation algorithm from two methods according to an internal flag: the template method (the normal route where a template is selected from a template table, the blanks are filled in, and then encryption is performed) and the large table direct read method (a modified route where the password is obtained directly from a large complete password table without going through a template).

[0065] In step B3, if the template method is selected, the card module calculates the reference row (template number) Idx of the template table using the following formula: Idx = Wx1 × 16 + Ax1 + workSpx • Wx1: Server random number (0-15) • Ax1: A 4-bit internal representation of the first digit of the 4-digit PIN entered by the user (actual input is 0-9). • workSpx: Current usage history pointer (0-127) If Idx is 100h (256) or greater, a bitmask operation is performed. Idx = Idx AND 0xFF Perform this operation to keep the result within the range of 0 to FFh (0 to 255). As a simplified embodiment, Wx1 may be fixed to 0, in which case the following equation holds. Idx = Ax1 + workSpx For example, if the values ​​loaded in step B1 are Wx1=0x00, Ax1=0x00, workSpx=0x05, 0x00 × 16 = 0x00(0) 0x00 + 0x00 = 0x00(0) 0x00 + 0x05 = 0x05(5) Therefore, we obtain Idx = 0x05 (decimal 5).

[0066] The reference row of the template table may be determined by obtaining an index value using an operation f(...) that depends on at least some of the variable values ​​sent from the server, some of the values ​​related to the user, and some or all of the pointer values ​​based on the usage history, and then mapping it to a range corresponding to the number of records in the template table (for example, by modulo operation or bitmask mapping). The number of records in the template table is variable depending on the implementation and is not limited to 256.

[0067] Step B4 is performed only if the direct reading method for the large table is selected. The card module uses the template number Idx, which was calculated in step B3, to directly read the "completed password" with that number from the large long password table into the work area, and then proceeds to step B7.

[0068] In step B5, using the template method, the card module uses the template number Idx determined in step B3 to read the corresponding long password prototype (fixed string + 2 holes) from the template table into the work area. For example, in the row where Idx=0x05 (decimal 5) abcdefghi'01h'jklm12345'02h'6789abc This is the original code stored, where '01h' and '02h' are control codes indicating "the first hole" and "the second hole," respectively. This original code is then expanded directly into the work area.

[0069] The template prototype may have one or more fill-in-the-blank spaces, and the number, position, and length of these spaces are variable depending on the implementation. The strings inserted into the spaces may be obtained by applying a mapping rule (e.g., fixed tables, arithmetic conversions, combination rules, etc.) to at least a portion of the values ​​related to the user, not limited to substitution tables.

[0070] In step B6, the card module fills in two holes in the template. Specifically, it inserts a 3-5 character string of Ax3 converted using a predetermined substitution table into the first hole, and similarly inserts a string of Ax4 converted in the second hole. Multiple substitution tables are stored on the card in 10x10 combinations, and each digit (0-9) of the entered 4-digit PIN is mapped to a unique string on the card. This completes the "long password base". For example, if Ax3=0x01(1) is converted to “f5n” in the substitution table, and Ax4=0x01(1) is converted to “9876”, then the base form abcdefghi'01h'jklm12345'02h'6789abc f5n and 9876 are inserted into the hole positions, respectively. abcdefghif5njklm1234598766789abc This is replaced with the long password base.

[0071] In step B7, the card module takes the long password base obtained in the previous step (the one with the blanks filled in in step B6 if using the template method, or the completed password obtained in step B4 if using the direct reading of the large table) as input and performs a code conversion process based on the encryption scheme table. Specifically, it first determines the reference number of the encryption scheme table using the formula "Wx2 × 16 + Ax2" calculated from the server random number Wx2 and the second digit of the PIN Ax2, and then obtains the code conversion rule corresponding to that number (up to 256 possibilities, such as character code substitution, exclusive OR shift, and rotating Caesar). For example, from Wx2=0x03(3) and Ax2=0x04(4), we obtain 0x03×16+0x04=0x34(52), and we use No. 52 in the encryption scheme table to perform a code transformation on the element. The card module applies the acquired code conversion rules to the aforementioned base element to generate a complete long password. The combination of Wx2 and Ax2 greatly improves the diversity of passwords generated from the same base element.

[0072] The "encryption scheme table" refers to a set of rules for code conversion or encryption applied to a long password element, and may include one or more of the following: character substitution, bitwise operations, rotation shifts, exclusive OR operations, and decryption rules. The number of schemes included is variable depending on the implementation and is not limited to 256. The selection of an applicable scheme can be achieved by generating a reference number using a predetermined mapping rule (including bit concatenation, addition / subtraction, modulo, bitmask, etc.) based on at least a portion of the variable value and a portion of the value related to the user, and then referring to this table using that number.

[0073] In step B8, the card module encloses the long password obtained in the previous step in an encrypted packet and sends it directly to the server module. With this packet transmission, processing of the B-series subflow is complete, and control returns to step A13 of the main flow.

[0074] An "encrypted packet" refers to an encrypted or authenticated message transmitted or received over a secure channel based on a session key or authentication key. The rules of the encryption scheme table (code conversion and encryption) applied during the long password generation stage and the encryption / authentication protection in the communication channel may be implemented at separate layers.

[0075] In this embodiment, the ring-shaped usage history memory update process branches into two paths depending on the result of the past history comparison. Specifically, in the authentication main flow A, if the connection record from 101 sessions ago matches and normality is confirmed (the normal route from step A5 to A11 onwards), the normal update flow C is called after successful login authentication. On the other hand, in the path where the previous session terminated abnormally and recovery is achieved by matching the connection records from 50 / 51 sessions ago (via steps A7 to A10), the recovery update flow C' is called after successful authentication. Therefore, the authentication main flow A is configured to execute only one of the two paths depending on the history comparison result of the authentication phase, thereby ensuring the consistency of the ring memory.

[0076] The normal update flow C is an update process for the ring-shaped usage history memory, which is called when the connection record from 101 connections prior matches and the connection is made via the normal authentication route (step A17). At the time of the call, the card module and the server module share the latest connection record (year, month, day, hour, minute, second + random number sequence), the usage history pointer Spx (0-127), the usage history pointer indicator bit (a 1-bit flag indicating the usage history pointer currently referenced by the card module; 0 = Spx0, 1 = Spx1), and the anomaly monitoring bit (a flag indicating that the server module is in the process of updating). In this subflow, the ring-shaped memory itself, which holds 128 connection histories, has a single configuration, and the usage history pointer that indicates the update position has a dual configuration of Spx0 / Spx1. By utilizing the fact that the usage history pointer indicator bit can only take either 0 or 1, the consistency of the history update is ensured even if an anomaly such as a power outage or card removal occurs.

[0077] Figure 4 illustrates each step of the normal update flow C. In step C1, the server module first sets the anomaly monitoring bit to 1 to indicate that an update has begun. Next, the server module generates the latest connection record (year, month, day, hour, minute, second + random number sequence) on the work area, encrypts it, and sends it to the card module. The card module decrypts the received packet and incorporates the acquired connection record as its own latest connection record.

[0078] In step C2, the card module calculates the address workSpx+1 in the ring memory (if the value reaches 128, it applies the bitwise operation AND 7Fh to wrap back to 0-127) and writes the latest connection record encrypted to that address.

[0079] The number of entries M in the ring-shaped memory is variable depending on the implementation, and is preferably set to M = 2^n (n ≥ 1). In this case, pointer value wrapping can be achieved by an AND operation or the like using a bitmask (M-1) corresponding to the number of entries. For example, when M = 128, (M-1) = 0x7F is used, but generally a "predetermined bitmask value" corresponding to the number of entries is used.

[0080] In step C3, the card module copies and saves the value of workSpx+1 to Spx1 if the current pointer instruction bit is 0, or to Spx0 if the pointer instruction bit is 1, and updates the backup pointer. This configuration ensures that even if an abnormal termination occurs during the update process, at least one pointer will always retain the latest address.

[0081] In step C4, the card module inverts the usage history pointer indicator bit to switch whether Spx0 or Spx1 is referenced as the "current pointer". After the switch, the pointer value written immediately before becomes the new reference, and the pointer value before the switch is retained in non-volatile memory as a backup until the usage history pointer indicator bit is rewritten.

[0082] In step C5, the card module sends an encrypted "update complete" code to the reader module, which then forwards the code to the server module without modification.

[0083] In step C6, the server module that received the notification updates the value of its usage history pointer to Spx+1 and resets the anomaly monitoring bit to 0, thereby fully synchronizing with the card module. With this process, the normal update flow C is completed, and control is returned to step A18 (authentication success process) of the authentication main flow A.

[0084] Recovery update flow C' is a recovery update process for the ring-shaped usage history memory that is called when the previous session terminated abnormally and the recovery conditions are met by matching the connection records from 50 / 51 sessions ago in the authentication main flow A (steps A7-A10). At the time of the call, the abnormality monitoring bit on the server module side is already set to 1, indicating an "incomplete state," and there is a one-entry discrepancy between the usage history pointers of the card module and the server module. The recovery update flow C' restores consistency without switching the pointer indicator bits (Spx0 / Spx1) by writing the latest connection record back to the pointer location (workSpx) currently pointed to by the card module and sending an update completion code while keeping the pointer value unchanged. The detailed processing is explained below according to steps C'1 to C'4.

[0085] Figure 5 illustrates each step of the recovery and update flow C'. In step C'1, the server module confirms that the anomaly monitoring bit is already set to 1, and then proceeds with recovery and updating while maintaining that state. First, the server module generates the latest connection record (year, month, day, hour, minute, second + random number sequence) on the work area, encrypts it, and sends it to the card module. The card module decrypts the received packet and adopts the resulting connection record as the new latest connection record.

[0086] In step C'2, the card module calculates the address workSpx in the ring memory (if the value reaches 128, it applies the bitwise AND operation 7Fh to wrap back to 0-127) and writes the latest connection record encrypted to that address. Here, since workSpx holds the current pointer Spx itself, no pointer increment operation is performed. Also, the card module does not change the usage history pointer indicator bits (0=Spx0 / 1=Spx1). As a result, the combination of the values ​​of Spx0 and Spx1 and the pointer indicator bits retains the state from the previous session, and data integrity is maintained even if the card is removed midway through.

[0087] In step C'3, the card module sends an encrypted "update complete" code to the reader module, which then forwards the code to the server module without modification.

[0088] In step C'4, when the server module receives the update completion code, it synchronizes its own usage history pointer with the card, saves the latest connection record held in the work area to non-volatile memory, and resets the anomaly monitoring bit to 0. This completes the recovery update, and the recovery update flow C' process ends.

[0089] The authentication main flow A, long password generation flow B, normal update flow C, and recovery update flow C' described above, by coordinating their respective functions of history verification, dynamic password generation, and history update / recovery processing, constitute a robust authentication protocol that verifies the authenticity of both the card and server sides while automatically responding to abnormal conditions such as power outages or card removal. This enables the provision of a highly secure and available personal authentication platform for applications such as credit card payment terminals and access control systems.

[0090] It should be noted that the invention of this disclosure is not limited to the embodiments described above, and includes various modifications. For example, the embodiments described above are described in detail to make the invention of this disclosure easier to understand, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace parts of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add configurations from other embodiments to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations. [Explanation of Symbols]

[0091] 10. Two-way history-based dynamic-length password authentication system 20 card readers 30 IC cards 40 servers

Claims

1. An authentication system comprising a card reader, an IC card, and a server, An authentication system configured such that both the IC card and the server maintain a predetermined number of usage history records, when an authentication request is made, the server encrypts the connection records from a predetermined number of previous connections and transmits them to the IC card via the card reader, the IC card compares the connection records with its own stored history to verify the legitimacy of the server, and further generates a long password that changes each time within the IC card based on the fluctuating value transmitted from the server, the value relating to the user, and the pointer value based on the usage history, transmits the long password to the server to perform user authentication, and after authentication, the IC card and the server mutually compare the latest connection records and update the usage history information.

2. An authentication system according to claim 1, wherein the IC card first returns a dummy ID, which is different from the true ID and is generated according to predetermined rules as a signal to transition to the authentication protocol of the authentication system, in response to an identification number request from the card reader, and the server receives the dummy ID via the card reader, and when it detects that the dummy ID conforms to the rules, it issues an ID request command for obtaining a formal identification number, and the subsequent communication is configured to transition to a procedure that follows the authentication protocol of the authentication system.

3. The authentication system according to claim 1, wherein the IC card is equipped with a ring-shaped memory that holds a predetermined number of connection records, and the wrapping process of the pointer value accompanying the update of the usage history is performed by bitwise operations using a predetermined bitmask value on the pointer value.

4. The authentication system according to claim 1, wherein the IC card holds a template table storing multiple types of long password prototypes, and the reference row of the template table is selected by computationally determining it based on at least a portion of the variable value transmitted from the server, a portion of the value relating to the user, and a pointer value based on the usage history, and mapping the result of the computation to a predetermined range and using it as a template number.

5. An authentication system according to claim 4, wherein each prototype of the template table is provided with at least one blank space, and the IC card is configured to constitute a long password element by inserting a replacement string obtained by applying a predetermined substitution table or a similar mapping rule to at least a portion of the value relating to the user into the blank space.

6. The authentication system according to claim 1, wherein the IC card holds an encryption scheme table consisting of multiple schemes, and is configured to select and apply an encryption scheme to be applied prior to enclosing the long password in an encrypted packet, using a reference number obtained by a predetermined mapping rule based on at least a portion of the variable value and at least a portion of the value relating to the user.

7. An authentication system according to claim 1, wherein the IC card redundantly holds a usage history pointer indicating the update position of the ring-shaped memory and has an instruction bit indicating the current reference destination, the server has an abnormality monitoring bit indicating an incomplete state of the history update procedure, and when an abnormal termination is detected during the authentication process, the authentication system is configured to determine whether recovery is possible by comparing the connection record held in the IC card and the connection record held in the server, which are shifted by 1 from each other, and when recovery is successful, to restore the integrity of the ring-shaped memory by rolling back the usage history pointer or by a recovery update without switching the instruction bit.

8. An authentication system according to claim 1, comprising a mode for using facial recognition, wherein the server compares a facial image with a registered facial image, and when the comparison matches, the server encrypts a temporary short password independent of the variable value and PIN and transmits it to the IC card, and the IC card generates a long password based on the received variable value and the temporary short password, and transmits it to the server.

9. An authentication system according to claim 1, wherein after the server confirms that the long password matches, the IC card encrypts and transmits the latest connection record pointed to by the working pointer, and the server compares the internal expected value with the connection record and, upon matching, synchronizes the values ​​of the usage history pointer and the anomaly monitoring bit in the ring memory update process.

Images