JP7559178B2 - Blockchain-based network authentication system and authentication method using the same - Google Patents

Description

The present invention relates to a network authentication system that uses blockchain and an authentication method using the same.

With the increased use of cloud services and teleworking, devices move between environmental boundaries inside and outside the corporate firewall, meaning that no safe space is left in a company's IT environment.

In fact, in August 2020, it was announced that corporate PIN numbers leaked during teleworking for 900 companies worldwide (38 in Japan) were listed on crime websites, and according to the Information-Technology Promotion Agency (IPA)'s "Top 10 Information Security Threats 2021," in addition to external cyber attacks, information leaks due to internal fraud are ranked highly as threats to companies.

In light of the already ongoing trend in Europe and the US of making security measures mandatory for business partners, the review of in-house systems to comply with supply chain management, the General Data Protection Regulation, and other regulations has become an urgent task for not only large companies but also small and medium-sized enterprises, and strict authentication is required when accessing business systems.

On the other hand, measures are also required to prevent the threat of phishing scams, where network endpoints (a general term for various Internet access destinations) such as when accessing a company's business website during telework or when conducting electronic transactions over a network, are fake sites set up by criminals.

In other words, there is a need for new mutual authentication cybersecurity that also takes into account authentication of the legitimacy of network endpoints.

As shown in FIG. 2, in the conventional authentication process, a user accesses the in-house system 200 via an app S400 for remote access S401, receives an authentication request S402 from the in-house system 200, inputs their own "ID and password" S403, logs in S404, searches the in-house system's ID management database 410, and compares the input ID and password S407. If the result is OK, the user is allowed to start work S408, and can begin working S409.

Patent Publication 2020-190868 Patent Publication No. 2019-8753

Currently, most security solutions available for accessing in-house business systems or conducting electronic transactions over a network rely on IDs and passwords for personal authentication (Patent Documents 1 and 2).

However, with the recent increase in computer speeds, the need for increasingly complex IDs and passwords has called into question the effectiveness of IDs and passwords as a security measure.

Furthermore, authentication using IDs and passwords is in a state of collapse, as it requires the hassle of remembering IDs and passwords, can lead to human error due to forgetting them, and can even lead to eavesdropping and misuse by third parties, making people constantly aware of the threat of "hacking" and "spoofing."

On the other hand, conventional IC cards used as ID cards, financial cards, and transportation cards are offline terminals that require high confidentiality and secrecy of the internal data, and are robust information terminals against tampering or leakage of internal data through external attacks. However, IC cards with fingerprint authentication are adjusted so that they function as IC cards only when matched with the owner's registered fingerprint information on the card, eliminating the worries about "skimming" and "spoofing," and are an effective security measure.

However, even when accessing a network endpoint using the aforementioned fingerprint authentication IC card, since the same ID and password must be repeatedly entered, this is not a complete security measure against threats such as eavesdropping.

What's more, there is no check on the legitimacy or authenticity of network endpoints, making it impossible to prevent crimes such as "phishing scams" in which users are lured to fake endpoints and have their IDs and passwords stolen.

The present invention has been made in consideration of the above problems, and aims to provide a complete cybersecurity measure that does not require the input of an ID and password when accessing a network endpoint, guarantees the legitimacy of personal authentication to the destination, and realizes mutual authentication that guarantees the authenticity of the destination endpoint.

The present invention relates to an authentication system that performs identity authentication of a user when accessing Internet end points such as various services and business systems on a network by fingerprint authentication using an IC card with fingerprint authentication (Secure Finger ID card) (SFID), and at the same time, as background authentication processing, a blockchain network is installed that manages and stores the most recent access history of the user as a transaction (Tx), an authentication agent (Authentication Provider Interface) (API) is implemented at the entrance of the endpoint, and access to the business system is controlled by comparing the SFID and the most recent access history recorded in the blockchain on the API.
We propose an authentication system and an authentication method using this system, in which a common key used for encryption and decryption to enable secure data transmission and reception between the SFID and API is recorded in the memory inside the SFID and in a personal information database connected to the API, and when a transaction (Tx) in which a user's access history is written is distributed from the API to multiple nodes in multiple blockchain networks, a private key of a public key encryption method required to authenticate the source of the transaction (Tx) and to verify that no data has been tampered with on the distribution path is recorded in the memory inside the SFID, and its paired public key is recorded in a personal information database connected to the authentication agent, and new users are registered and SFIDs are issued, thereby verifying the legitimacy of the user's access rights and the authenticity of the endpoint between the SFID and the API through mutual authentication.

In this invention, the SFID replaces an ID and password and serves the role of authenticating a user's access rights to business systems. The SFID is issued to the individual with information not even known to him/her, such as a unique encryption key linked to the individual, as well as data that identifies the individual, such as the individual's name or employee code, pre-recorded and stored inside the SFID. The individual then receives, either in person or remotely, instructions on the operation method required to accurately register a fingerprint on the SFID card, and performs fingerprint registration.

After an SFID card is issued without a fingerprint registered, the event of completing the registration of the individual's fingerprint is recorded as the "user registration date" in the user's record in the "personal information database" installed in the company's internal system, and at the same time, recorded data (equivalent to one transaction) that serves as the starting point of the blockchain is generated as the first "access history." Thereafter, the user's access to the business system is verified by comparing the "access history" recorded in the blockchain with the "authentication history information" recorded in the SFID.

In other words, in this invention, an SFID card is issued to verify the identity of a legitimate user, and a blockchain network records and manages the user's access history to a network endpoint as a "transaction (Tx)." An API that mediates the connection between the SFID IC card and the blockchain network is deployed at the endpoint, and the API encrypts, decrypts, collects, distributes, and verifies the user's access history information to the endpoint, authenticating and controlling access from the network for remote work, etc. by the user.

Furthermore, in this invention, the latest access history information is updated each time the user accesses and is authenticated, and is kept secret in the SFID and blockchain network, and is collected and distributed in response to requests from the API, and verification is performed, thereby providing a new cybersecurity infrastructure that realizes mutual authentication of the authenticity of users and endpoints.

In this invention, an authentication infrastructure (Finger Identity as a Service authentication infrastructure) (hereinafter referred to as FIDaaS authentication infrastructure) is formed using the user's own fingerprint authentication and endpoint access history using SFID, API, and blockchain technology, which makes it possible to mutually authenticate the legitimacy of the user and the authenticity of the network access site.

In addition, according to the present invention, the above authentication is performed without the need to enter a password when accessing a network endpoint, which eliminates the hassle of users having to remember their IDs and passwords, the risk of human error due to forgetting them, and even the risk of "hacking" or "spoofing" due to wiretapping, making it possible to protect against not only external cyber attacks but also information leaks due to internal fraud.

In addition, in this invention, among multiple business systems, particularly important business systems, for example, core systems that would have a serious impact on business if subjected to a cyber attack, can be isolated from the other business systems as independent endpoints, and an API can be set up for authentication.

In addition, according to the present invention, in order to improve work efficiency, it is possible to realize a service form called single sign-on, in which multiple related business systems are grouped together, and an authentication agent is provided at the endpoint of this group as a portal, allowing authentication to be performed collectively and only once for the multiple business systems in the group.

This invention allows the authenticity of the user and the endpoint to be mutually authenticated, making it possible to realize a strict authentication infrastructure in cyberspace.

Furthermore, according to the present invention, the blockchain transaction, which is protected by authenticating the authenticity of the user and managing strict access history, meets the functional requirements of a fully signed timestamp. This makes it possible to provide high-value-added customization, such as adding and storing document information such as contracts related to the business to the data record of the transaction. For example, if the business application that connects to and controls this FIDaaS authentication platform is a materials management system within an internal system, by leaving evidence of the contract related to the purchase and sale as a record in the transaction, it becomes possible to store the purchase and sale order data safely without worrying about tampering or deletion.

Furthermore, in this invention, the authenticity of the user is authenticated by the SFID, and the access history written in the SFID cannot be rewritten and is compared with the contents written in the blockchain transaction, which does not allow for loss, so the authenticity of the business system site is authenticated, and the authenticity of the user and the authenticity of the business system site can be mutually authenticated, making strict authentication possible.

FIG. 1 is a diagram for explaining a schematic configuration of an FIDaaS authentication infrastructure according to the present invention. FIG. 1 is a diagram for explaining a sequence of a conventional authentication process according to the present invention. FIG. 1 is a diagram for explaining the sequence of an authentication process in the FIDaaS authentication infrastructure according to the present invention. A diagram explaining the mutual authentication method between the SFID card and the API according to the SCP01 of this invention. A diagram for explaining the mechanism of the FIDaaS authentication infrastructure according to the present invention and the correlation of each data. FIG. 1 shows the data structure of the blockchain of the FIDaaS authentication infrastructure according to the present invention.

The following describes a preferred embodiment for implementing cyber-physical security in which the identity of a user is authenticated using fingerprint authentication of the SFID when accessing Internet endpoints such as various web services and business system sites on the network according to the present invention, and at the same time, a blockchain network is deployed that manages and stores the user's access history as transactions, an authentication agent (API) is implemented in front of the endpoint, and access rights to business systems are checked by comparing the SFID with the most recent access history recorded in the blockchain.

Figure 1 shows a schematic diagram of one example of the configuration of a FIDaaS authentication infrastructure.

As shown in Figure 1, when a user accesses an Internet endpoint such as a business system, the user is authenticated by fingerprint authentication using a fingerprint authentication IC card (SFID), and at the same time, as a background authentication process, a blockchain network is installed that manages and stores the user's most recent access history as a transaction, an authentication agent (API) is implemented at the entrance to the endpoint, a personal information database is connected to the authentication agent (API), and the SFID and the most recent access history recorded in the blockchain are compared and verified on the API to control access to the business system. In this authentication system, the SFID records a common key with the API, a private key for the public key encryption method used in the blockchain network, and the first half of the hash ID of the blockchain transaction including the user's most recent access history and the access history, and the personal information database records the common key, a public key that combines the private key, and the second half of the transaction hash ID. (See Figure 5)

The following describes an embodiment of the FIDaaS authentication infrastructure with reference to the figures, taking as an example a case where a user 100 (e.g., a selected few employees or an employee of a business partner) who holds an SFID 110 as an identification card (e.g., an employee ID card) accesses a business system (e.g., a manufacturing system 204 in an in-house system 200) prepared as a work environment for the above authentication system.

The authentication procedure in the FIDaaS authentication infrastructure, which adopts a method different from conventional authentication processes, is shown in Figure 3, which shows the authentication process between API220, which is authentication agent software provided for security against external access, and SFID110 held by user 100 who is attempting to perform work remotely, with the manufacturing system 204 in Figure 1 as the endpoint.

In the authentication process, in step 1, communication with the outside world is permitted by fingerprint authentication of the fingerprint authentication IC card, on which the access history to the business system is written, expressed as a hash value, and the authentication agent is accessed. In step 2, the authentication agent obtains a common key from a personal information database, and uses this common key to mutually authenticate the authenticity of the fingerprint authentication IC card and the authentication agent, while also generating a temporary session key to ensure security during communication.
In step 3, the secret key and the access history recorded in the fingerprint authentication IC card are encrypted with the session key and sent to the authentication agent, and the data is transferred by restoring the data on the authentication agent side.
In step 4, the authentication agent obtains the transaction record from the blockchain using a transaction hash that is a combination of the first half (1/2) of the access history hash value received from the fingerprint authentication IC card and the second half (2/2) of the access history hash value obtained from the personal information database, and confirms that the hash value of the access history recorded in this record matches the hash value of the access history in step 3.
In step 5, the authentication agent broadcasts the transaction to the blockchain as a new access history indicating that the user's access rights are valid, and obtains a new access history hash value using the transaction hash value confirmed after consensus is reached among other nodes.
In step 6, a new access history including the first half of the newly acquired transaction hash value is sent to the SFID for authentication purposes the next time the user accesses the system. Within the SFID, the access history is updated and then the API is notified that storage is complete. The API verifies this and updates the remaining half of the transaction hash value of the most recent access history in the personal information database record. After that, the user is allowed to operate remotely. Each step is explained in detail below.

Step 1
User 100 in Figure 3 starts application software for performing remote operations on manufacturing system 204 (S150), and performs fingerprint authentication using the fingerprint sensor mounted on SFID 110 described in "STEP 1" (S10), thereby enabling communication with the outside world of the card and sending and receiving data stored in SFID 110, and accessing the API by, for example, sending an employee code (contained in 262 of personal information database 260 or personal information 112 recorded in memory 111 in SFID 110 in Figure 5).

Step 2
"STEP 2" S11 in FIG. 3 shows processing for authenticating the mutual authenticity of the SFID 110 and API 220 and for ensuring security in the subsequent mutual data communication.

SFID110 is issued with a "shared key K0 (113 recorded in memory 111 in SFID110 in FIG. 5)" pre-recorded along with the personal information of user 100. This SFID110 and API220, which reads the shared key K0265 from the personal information database 260, verify each other's authenticity based on this shared key, and ensure security in communications by using a "session key KS" that is generated each time communication is carried out and is used only once.

Explanation of SCPAs a mutual authentication method based on a common key, there is an authentication scheme based on SCP (Secure Channel Protocol) 01 defined by "globalplatform.org", the global standardization organization for IC card security management systems. Below, we will explain the use of this scheme as an example.

An example of this authentication method is shown in Figure 4. SFID110 and API220 each possess a common key K0 S501, and when authentication begins, each generates 16B (byte) random numbers Rapi and Rsfid, encrypts them, for example, with the common key K0, and sends them to the other party S502. The random numbers received from each party are divided into 4B units, rearranged according to the arrangement rules in S503, and calculate a test ciphertext CRM. This CRM is encrypted with the common key K0 to create a session key KS S504. The random numbers Rapi and Rsfid are encrypted using this KS as the encryption key to calculate ciphertext Capi and Csfid, which are then transmitted to each other and decrypted to confirm that the original random numbers have been restored. This method verifies the authenticity of each party, and at the same time, enables SFID110 and API220 to safely send and receive data using this session key KS.

Step 3
In "STEP3" S12 in Fig. 3, {TSi, TxHi(1/2)} 116, 117, which represent the access history recorded in memory 111 in SFID in Fig. 5, and secret key KB 114 are encrypted with session key KS (each communication data is represented by X. See 10 in Fig. 5), sent to API 220, and data is securely transmitted and received by restoring it on the API side. The following formulas (1) and (2) show an example of the processing of TSi.
(Example) SFID: Xi = E (TSi, KS) ... (1)
API: TSi = E -1(X i , KS) ... (2)
Here, the subscript “i” denotes the most recent “i-th” access of the user 100 to the API 220 of the manufacturing system 204 .

In the above formulas (1) and (2), the symbol E is used to mean the function "ciphertext = E (plaintext, encryption key)" and the symbol E -1 is used to mean the inverse function of E "plaintext = E -1 (ciphertext, encryption key)."

Step 4
3, the transaction record Txi13 in FIG. 5 is obtained from the block chain database 351 using the transaction hash TxHi12 generated by concatenating TxHi(1/2) 117 received from the SFID with TxHi(2/2) 266 recorded in the personal information database 260, and the hash value H(TSi) of the previous access history of the relevant user 100, i.e., employee code 122, and the relevant SFID 110 is extracted and compared with the result of calculating the hash value of the data TSi received in "STEP 3" S12. In other words, if the two match, it is verified that the legitimate holder of the SFID 110, identified by fingerprint authentication, has the right to access the manufacturing system 204, whose authenticity has been authenticated.

Here, the symbol H(X) represents a hash function that takes data X as an argument, and the resulting value is nothing other than the "hash value."

Specific examples of the above-mentioned "generating by concatenating TxHi(1/2) 117 with TxHi(2/2) 266 recorded in the personal information database 260" are shown in the following formulas (3), (4), (5), and (6).

TxHi = TxHi(1/2) + TxHi(2/2) ...(3)
TxHi(1/2) = “6b88c87243aa29yfhhtdfh1d4rws2jb1” ・・・(4)
TxHi(2/2) = “2b67gg32hhjrvud3343421987wev4f32” ・・・(5)
TxHi = “6b88c87243aa29yfhhtdfh1d4rws2jb12b67gg32hhjrvud3343421987wev4f32” ・・・(6)

For example, this means combining 32B of data each in (4) and (5) to generate 64B of TxHi12 data as in (6).

Step 5
In "STEP 5" S222 in FIG. 3, as a result of the verification in "STEP 4" S221 described in [0039] above, it is recognized that the user 100 has a valid access right and is permitted to work remotely, but this fact must be recorded as an access history that will be required for verification the next time the user 100 accesses. For this purpose, a transaction Txi+1 (see 15 in FIG. 5) containing a hash value of the access history TSi+1 corresponding to the current time is distributed to the blockchain network 300 shown in FIG. 1 with a digital signature obtained by encrypting the hash value using the private key KB by public key cryptography. This is also called "broadcast" to multiple blockchain nodes (corresponding to 351 to 353 in FIG. 1).

The blockchain node that receives transaction Txi+115 decrypts the received digital signature using the public key PKB (employee code 262 in personal information database 260 in Figure 5) that corresponds to the private key KB, and verifies that it matches the hash value of TxHi+1, thereby authenticating that the transaction was sent by a person who holds the private key that pairs with the public key, and verifies that no data was tampered with on the transmission path based on the match of the hash values.

Description of the Blockchain Network As shown in Figure 1, data in the blockchain network 300 is recorded in synchronization with multiple nodes 351 to 353 that make up the distributed network. As shown in Figure 6, the data structure that makes up the blockchain is a unit of data transmission and reception called "transaction Tx13," and its hash value is added as a "transaction hash ID, TxH12." Multiple transactions Tx13 that occurred during a certain period are collected (in the example of Figure 6, D1 to ID8 are shown as eight Tx), encrypted according to the blockchain protocol, and organized into block units 310 (similarly 320, 330, and 340). The nodes verify the validity of the blocks and accumulate the records in a chain. In the example of Figure 6, the hash value 311 of the "j+1"th block 310 contains the hash value 312 generated from the "j"th information, which is why it is a chain structure. This chain structure makes it difficult to tamper with or delete transaction data. At the same time, since data is recorded synchronously across multiple nodes, it also serves the function of backing up data.

In addition, a value called a nonce is added as a parameter to the calculation of the hash value of each block, and by adjusting this value, a hash value that meets the specified conditions is found. By verifying that the result of the hash value can be reproduced by calculations on other nodes, the validity of the block is deemed to have been agreed upon, and a new TxHi+1 is determined.

In other words, as mentioned above, only after the validity of transaction Txi+1 (15 in Figure 5) is confirmed by other nodes will it be stored in the blockchain database as one of the eight transactions in block 310 in Figure 6, and TxHi+1 (see 14 in Figure 5) can be searched again.

In contrast to the conventional method in which the accumulation of blocks is permitted (for example, in the case of the blockchain of the virtual currency Bitcoin), in the case of a private blockchain, it is possible to adopt a method that relaxes the restrictions on hash values and allows for the fast and easy discovery of parameters (nonces) that meet the conditions.

Step 6
In "STEP 6" S13 of Figure 3, the access history {TSi+1, TxHi+1 (1/2)} 115 including the first half (1/2) of the newly confirmed TxHi+1 is sent to the SFID for authentication purposes at the next access, and within the SFID, the access history 115 is updated and then the API is notified of the completion of storage. The API confirms this and updates the remaining half 266 of the transaction hash value of the most recent access history in the record of the personal information database 260, after which remote work is permitted and user 100 begins work on the manufacturing system 204 S151.

What should be particularly noted about this invention is that in the authentication process sequence shown in FIG. 3, the fingerprint authentication in "STEP 1" S10 is the only action that the user 100 must actually perform, and the process from then on, when permission to start remote work S151 is issued and work begins, is automatically carried out between the SFID, API, and the blockchain network in the background, unbeknownst to the user. In other words, not only is the burden of inputting an ID and password, which was a burden for the user 100, eliminated, but so is the burden of remembering them, forgetting them, operating errors, and worries about eavesdropping.

In the first embodiment described with reference to FIG. 1, we have described a form in which only important business systems among in-house systems, such as a core system that would have a serious impact on business if subjected to a cyber attack (e.g., the "manufacturing system" 204 in FIG. 1), are separated from other business systems and managed by the authentication infrastructure of this invention.

In this case, SFID (fingerprint identification IC card) 110 is issued, distributed, and used only by employees who are selected to access a specific system.

Different from the above, in order to improve work efficiency in in-house systems, multiple related business systems can be grouped together, a single unified access point as a portal for the group is defined, and a single API (authentication agent) is implemented, thereby configuring and providing a single sign-on (SSO) function within the group. For example, the personnel system 201, accounting system 202, and materials system 203 in FIG. 1 use a common API 210 to manage access authentication. In other words, a user 100 is permitted to use three different services, which would previously have been managed with separate IDs and passwords, across the board with a single fingerprint authentication using the SFID card.

In summary, the present invention provides an authentication system at an endpoint that provides complete security measures and performs strict authentication when accessing a network such as a business system.

100 A user of this FIDaaS authentication platform who is a user of a business application that remotely accesses a manufacturing system within an internal system. 110 SFID card (fingerprint authentication IC card) held by the user.
111 Memory in SFID card 112 General personal information such as the user's name and contact details, recorded in the memory in the SFID 113 Common key data for securely communicating data between the SFID card and the API of the business system, recorded in the memory in the SFID 114 Private key data required for the public key cryptography used in the FIDaaS authentication infrastructure of the present invention, recorded in the memory in the SFID. This is paired with the public key used for the employee code.
115: Most recent access history of the holder of this SFID accessing a business system, recorded in the memory of the SFID. 116: Most recent access time data of the holder of this SFID accessing a business system, recorded in the memory of the SFID. 117: The first half of the transaction hash ID of a transaction which describes the most recent access history to a business system recorded in the blockchain database, recorded in the memory of the SFID. 120: Finger used to perform fingerprint matching. 200: Entire internal system including multiple business systems which allow remote access. 201: Within the internal system, a human resources system which allows remote access. 202: Within the internal system, an accounting system which allows remote access. 203: Within the internal system, a materials system which allows remote access. 204: Within the internal system, a manufacturing system which allows remote access. 205: Within the internal system, an R&D system which allows remote access. 206: Within the internal system, a system management task which allows remote access.
210 Authentication agent software (API: Authentication Provider Interface) that treats the personnel system, accounting system, and materials system as a single joint access point and controls access to the company's internal systems.
220 is an authentication agent software (API) that controls access to a manufacturing system among the in-house systems. 230 is an authentication agent software (API) that controls access to an R&D system among the in-house systems, which is mentioned as an example in the description of the embodiment of the present invention.
240 Authentication agent software (API) that controls access to system administration tasks within an internal system.
260 A database that records and manages the personal information of all users who access the internal system. 261 Within the "Personal Information Database", a record of general personal data such as the user's name, contact information, etc. 262 Within the "Personal Information Database", a record that records the employee code, using as the employee code a public key that pairs with a private key concealed in the SFID necessary for the public key cryptography used in the FIDaaS authentication infrastructure of the present invention. 263, 267 Spare data record of the "Personal Information Database". 264 Within the "Personal Information Database", a data record of the time when fingerprint registration on the user's SFID card was completed or the time when access rights to the business system were registered for the user. 265 Within the "Personal Information Database", a data record that records a common key for securely communicating data between the user's SFID card and the business system's API.
266 A data record in which the latter half of the transaction hash ID of a transaction that describes the most recent access history to a business system recorded in the blockchain database is recorded in the "personal information database". 300 Blockchain network 310 The "J+1"th block in the blockchain database, which corresponds to one of the nodes. Blocks are stored in ascending order starting from the lowest number.
311 Hash value representing the “J+1”th block in the blockchain database 312 Hash value representing the “J”th block in the blockchain database 313, 314 A hash tree (Merkle tree) consisting of eight transaction data that make up the “J+1”th block in the blockchain database and its root are shown.
320 The “J”th block in the blockchain database.
340 A block in which access history is recorded starting from the “time of new user registration” or the “time of fingerprint registration completion on the SFID card” in the blockchain database.
350 A cloud in which blockchain nodes 351, 352, and 352 are arranged
S400 to S409 show the respective processing steps of a flowchart of a conventional authentication process for remote access.
410 ID management database used in conventional authentication process for remote access
S150 As an example of an embodiment of the present invention, application software for remotely accessing the API of a manufacturing system
S151 As an example of an embodiment of the present invention, this means a process of obtaining API authentication and starting remote work to the manufacturing system.
S10 to S13 As an example of an embodiment of the present invention, each processing step of a process for verifying user access rights and mutual authentication of endpoints between the SFID and API, which are required when performing remote work in a manufacturing system, is shown below.
S221 to S222 As an example of an embodiment of the present invention, the process of reading and writing data required for mutual authentication of user access rights and endpoints required when performing remote work in a manufacturing system between the API and the blockchain database is shown.
S500 to S505 show each processing step in the flowchart of the mutual authentication process between the SFID card and API, based on the authentication scheme SCP01 defined by the Global Standardization Organization for IC card security management systems.
10 Encrypted data sent from the SFID to the API using a session key that is recalculated for each authentication based on the authentication scheme SCP01. 11 Encrypted data sent from the API to the SFID using a session key that is recalculated for each authentication based on the authentication scheme SCP01. 12 Transaction hash ID of the transaction that contains the most recent access history to the business system recorded in the blockchain database.
13 Transaction record 122 containing the most recent access history to the business system recorded in the blockchain database Employee code indicating the user included in the transaction data containing the most recent access history to the business system. Public key 123 paired with a private key concealed in the SFID required for the public key cryptography method used in the FIDaaS authentication infrastructure of the present invention Most recent access time data 124 to the business system included in the transaction data containing the most recent access history to the business system Spare record 125 included in the transaction data containing the most recent access history to the business system Spare record 14 used for customization included in the transaction data containing the most recent access history to the business system Transaction hash ID of a transaction record containing access history data immediately after access rights to the business system have been authenticated
15. Transaction records that contain access history data immediately after access rights to business systems have been authenticated

Claims (3)

In an authentication system, a user is authenticated by fingerprint authentication using an IC card with fingerprint authentication when accessing an Internet end point, and at the same time, as a background authentication process, a blockchain network is installed that manages and stores the user's most recent access history as a transaction, an authentication agent is installed at the entrance of the endpoint, and the most recent access history recorded in the IC card with fingerprint authentication and the blockchain are collated on the authentication agent to control access to services and business systems. A common key used for encryption and decryption to enable secure data transmission and reception between the IC card with fingerprint authentication and the authentication agent is stored inside the IC card with fingerprint authentication. and a personal information database connected to the authentication agent, and when a transaction in which a user's access history is written is distributed from the authentication agent to a plurality of nodes of a plurality of block chain networks, a private key of a public key encryption method required for authenticating the source of the transaction and verifying that no data has been tampered with on the transmission path of the distribution is recorded in a memory inside the IC card with fingerprint authentication, and a public key that pairs with the private key is recorded in a personal information database connected to the authentication agent, and new users are registered and IC cards with fingerprint authentication are issued, and mutual authentication of the validity of the user's access rights and the authenticity of the endpoint is verified between the IC card with fingerprint authentication and the authentication agent,
In step 1, the fingerprint authentication of the IC card is used to allow communication with the outside world and access the authentication agent.
In step 2, the authentication agent obtains a common key from the personal information database, and uses this common key to mutually authenticate the authenticity of the fingerprint authentication IC card and the authentication agent, while also generating a temporary session key to ensure security during communication.
In step 3, the private key and the access history recorded in the fingerprint authentication IC card are encrypted with the session key and sent to the authentication agent, and the data is transferred by restoring the data on the authentication agent side.
In step 4, the authentication agent obtains a transaction record from the blockchain using a transaction hash obtained by combining one half (1/2) of the access history hash value received from the fingerprint authentication IC card and the other half (2/2) of the access history hash value obtained from the personal information database, and confirms that the hash value of the access history recorded in this record matches the hash value of the access history in step 3.
In step 5, the authentication agent distributes the transaction to the blockchain as a new access history indicating that the user's access rights have been recognized as valid, and obtains a new access history hash value using the transaction hash value determined after consensus is reached among the other nodes.
In step 6, a new access history including half of the newly acquired transaction hash value is sent to the IC card with fingerprint authentication for authentication purposes at the next access, and after the access history is updated in the IC card with fingerprint authentication, the authentication agent is notified of the completion of storage, and the authentication agent verifies this and updates the remaining half of the transaction hash value of the most recent access history in the record of the personal information database, after which the user is permitted to work remotely and the user can begin working on the service or business system 204. The authentication method according to claim 1, characterized in that it is also possible to realize a method in which, among multiple business systems, only particularly important business systems are separated from the other business systems and made into endpoints, and an authentication agent is installed at the entrance to the business systems to control authentication, or a method in which multiple related business systems are grouped together to improve work efficiency, and this group is treated as one endpoint, and an authentication agent is installed to collectively authenticate the business systems in the group. The authentication method described in claim 1, characterized in that it enables a highly secure signed timestamp function to be realized by adding and storing document information of a contract related to a business to the data record of a blockchain transaction protected by authentication of the authenticity of the user and strict management of access history.

Images