Near-field audio-based user authentication device and method

Abstract

Disclosed are a near-field audio-based user authentication device and method. The near-field audio-based user authentication device according to an embodiment of the present invention comprises: an audio random number generation unit that generates an audio random number for near-field audio-based user authentication using a first terminal and a second terminal of a user and transmitting the audio random number to the second terminal; and an audio random number verification unit that compares an audio random number included in an authentication request message received from the first terminal and the audio random number transmitted to the second terminal to verify the authentication request message, wherein the second terminal plays back, to the first terminal, audio converted from the audio random number, and the first terminal converts the audio random number from the audio.

Description

Proximity Acoustic-Based User Authentication Device and Method

[0001] The present invention relates to proximity verification and user authentication technology, and more specifically, to proximity acoustic-based user authentication technology.

[0002] Authentication systems utilizing proximity verification play a crucial role in safeguarding digital transactions and protecting user data. Existing proximity verification methods are primarily implemented by confirming that two devices are physically close to each other using technologies such as Wi-Fi, Bluetooth, or NFC. However, these methods have limitations in environments where network-based communication is restricted due to organizational security policies or physical constraints.

[0003] For example, Wi-Fi-based proximity verification requires both devices to be connected to the same network, but this is often unusable in highly secure environments due to network isolation policies. Bluetooth-based methods can also be difficult to use due to limitations in communication range, signal interference, or compatibility issues between devices. Consequently, there is a growing demand for alternative proximity verification methods that do not rely on existing network communication channels.

[0004] Meanwhile, Korean Published Patent No. 10-2021-0114225, “Voice Authentication System and Method Using a Wearable Device,” discloses a voice authentication system configured to detect a vibration signal generated from the vocal cords of a user wearing the wearable device in accordance with the user’s speech using a vibration sensor, transmit a voice signal corresponding to the user’s speech and the vibration signal to a communication terminal, and the communication terminal compares the voice signal and the vibration signal received from the wearable device, and if the occurrence or duration times of both signals are mutually synchronized or if the magnitude change patterns of both signals over time correspond to each other, transmit the voice signal to the voice authentication server.

[0005] The present invention aims to determine whether a first terminal and a second terminal are physically close to each other using acoustic random numbers.

[0006] In addition, the present invention aims to enable authentication to be performed even in an environment where network communication (Wi-Fi or Bluetooth) cannot be used.

[0007] In addition, the present invention aims to provide a secure authentication method utilizing a Verifiable Credential (VC) of decentralized identity technology.

[0008] In addition, the present invention aims to support proximity verification authentication by utilizing various authentication information.

[0009] In addition, the present invention aims to provide an authentication method applicable not only to application authentication of a terminal but also to operating system login.

[0010] In addition, the present invention aims to provide an authentication technology that can be effectively applied even in environments with strict security policies.

[0011] A proximity acoustic-based user authentication device according to an embodiment of the present invention for achieving the above-mentioned purpose comprises an acoustic random number generation unit that generates an acoustic random number for proximity acoustic-based user authentication using a user's first terminal and a second terminal and transmits it to the second terminal, and an acoustic random number verification unit that verifies the authentication request message by comparing the acoustic random number included in the authentication request message received from the first terminal with the acoustic random number transmitted to the second terminal, wherein the second terminal plays an acoustic random number converted from the acoustic random number to the first terminal, and the first terminal converts the acoustic random number from the acoustic random number.

[0012] At this time, the acoustic random number generator can generate a session connection random number in response to a user authentication request from the first terminal and transmit it to the second terminal.

[0013] At this time, the acoustic random number generator can receive a Verifiable Presentation (VP) containing the session connection random number and the user's Verifiable Credential (VC) from the second terminal and verify it through a blockchain network.

[0014] At this time, the acoustic random number generator can generate the acoustic random number using multiple values ​​corresponding to the audible frequency and store it in a database together with the session connection random number.

[0015] At this time, the acoustic random number verification unit requests the first terminal to play a preset acoustic random number request sound to the second terminal, and the first terminal can play the acoustic random number request sound to the second terminal.

[0016] At this time, the second terminal can receive the acoustic random number request sound and record the playback completion time.

[0017] At this time, the second terminal can play sounds corresponding to a plurality of frequency values ​​converted from the acoustic random number at preset time units for each frequency value.

[0018] At this time, the first terminal can record the reception start time of receiving the sound converted from the acoustic random number.

[0019] At this time, the acoustic random number verification unit can verify whether the difference between the playback completion time and the reception start time is shorter than a preset response limit time.

[0020] At this time, if the difference between the playback completion time and the reception start time is shorter than a preset response limit time, the first terminal can convert the sound converted from the acoustic random number into an acoustic random number.

[0021] At this time, the first terminal can generate the authentication request message digitally signed with an acoustic random number converted from the sound and the private key of the first terminal.

[0022] In addition, a proximity acoustic-based user authentication method according to an embodiment of the present invention for achieving the above objective comprises, in a proximity acoustic-based user authentication method of a proximity acoustic-based user authentication device, a step of generating an acoustic random number for proximity acoustic-based user authentication using a user's first terminal and a second terminal and transmitting it to the second terminal; a step of the second terminal playing an acoustic converted from the acoustic random number to the first terminal; a step of the first terminal converting the acoustic random number from the acoustic; and verifying the authentication request message by comparing the acoustic random number included in the authentication request message received from the first terminal with the acoustic random number transmitted to the second terminal.

[0023] At this time, the step of generating the acoustic random number and transmitting it to the second terminal may generate a session connection random number in accordance with the user authentication request of the first terminal and transmit it to the second terminal.

[0024] At this time, the step of generating the acoustic random number and transmitting it to the second terminal can be verified through a blockchain network by receiving a Verifiable Presentation (VP) containing the session connection random number and the user's Verifiable Credential (VC) from the second terminal.

[0025] At this time, the step of generating the acoustic random number and transmitting it to the second terminal may generate the acoustic random number using a plurality of values ​​corresponding to the audible frequency and store it in a database together with the session connection random number.

[0026] At this time, the proximity acoustic-based user authentication method may further include the step of requesting the first terminal to play a preset acoustic random number request sound to the second terminal; and the step of the first terminal playing the acoustic random number request sound to the second terminal.

[0027] At this time, the step of playing to the second terminal may involve the second terminal receiving the acoustic random number request sound and recording the playback completion time.

[0028] At this time, the step of playing to the first terminal may allow the second terminal to play sounds corresponding to a plurality of frequency values ​​converted from the acoustic random number at preset time units for each frequency value.

[0029] At this time, the step of playing to the first terminal may record the reception start time when the first terminal receives the sound converted from the acoustic random number.

[0030] At this time, the conversion step can verify whether the difference between the playback completion time and the reception start time is shorter than a preset response limit time.

[0031] The present invention can determine whether the first terminal and the second terminal are physically close to each other using acoustic random numbers.

[0032] In addition, the present invention can perform authentication even in an environment where network communication (Wi-Fi or Bluetooth) cannot be used.

[0033] In addition, the present invention can provide a secure authentication method utilizing a Verifiable Credential (VC) of decentralized identity technology.

[0034] In addition, the present invention can support proximity verification authentication by utilizing various authentication information.

[0035] In addition, the present invention can provide an authentication method applicable not only to application authentication of a terminal but also to operating system login.

[0036] In addition, the present invention can provide an authentication technology that can be effectively applied even in environments with strict security policies.

[0037] FIG. 1 is a diagram showing a proximity acoustic-based user authentication system according to an embodiment of the present invention.

[0038] FIGS. 2 and FIGS. 3 are sequence diagrams illustrating the user registration step of a near-field acoustic-based user authentication method according to an embodiment of the present invention.

[0039] Figures 4, 5, and 7 are sequence diagrams illustrating the user authentication steps of a near-field acoustic-based user authentication method.

[0040] FIG. 6 is a graph showing the structure of the sound generated when converting an acoustic random number into sound according to an embodiment of the present invention.

[0041] FIG. 8 is a graph showing the structure of a request sound according to an embodiment of the present invention.

[0042] FIG. 9 is a graph showing the time at which the playback completion time of a requested sound is recorded according to an embodiment of the present invention.

[0043] FIG. 10 is a graph showing the structure of the received analyzed acoustics according to an embodiment of the present invention.

[0044] FIG. 11 is a graph showing the time point for recording the start time of sound reception in the converted sound according to an embodiment of the present invention.

[0045] FIG. 12 is a sequence diagram showing the processing steps when proximity authentication is successful during the user authentication steps illustrated in FIG. 4, FIG. 5, and FIG. 7.

[0046] FIG. 13 is a graph showing acoustic random number sampling of a first terminal according to an embodiment of the present invention.

[0047] FIG. 14 is a block diagram showing a proximity acoustic-based user authentication device according to an embodiment of the present invention.

[0048] FIG. 15 is a drawing showing a computer system according to an embodiment of the present invention.

[0049] The present invention will be described in detail below with reference to the accompanying drawings. Hereinafter, repetitive descriptions and detailed descriptions of known functions and configurations that may unnecessarily obscure the essence of the invention are omitted. Embodiments of the present invention are provided to more completely explain the invention to those with average knowledge in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clearer explanation.

[0050] Throughout the specification, when a part is described as "including" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components.

[0051] The present invention is capable of various modifications and may have various embodiments, and embodiments are illustrated in the drawings and described in detail.

[0052] However, this is not intended to limit the invention to specific embodiments and should be understood to include all modifications, components, or substitutions that fall within the spirit and scope of the invention.

[0053] In describing the components of the embodiments of the present invention, terms such as first, second, A, B, (a), (b), etc. may be used. These terms are used merely to distinguish the components from other components, and the essence, order, or sequence of the components is not limited by the terms.

[0054] Furthermore, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.

[0055] In the present invention, when a component is referred to as being "associated" with another component, it should be understood that it may be directly associated with or connected to the other component, or that there may be other components in between.

[0056] The terms used in this invention are used merely to describe specific embodiments and are not intended to limit the invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, terms such as "comprising" or "having" are intended to specify the existence of the features, numbers, steps, actions, components, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, or combinations thereof.

[0057] Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings. In describing the present invention, independent reference numerals are used even for identical components in the drawings to facilitate overall understanding.

[0058] FIG. 1 is a diagram showing a proximity acoustic-based user authentication system according to an embodiment of the present invention.

[0059] Referring to FIG. 1, a proximity acoustic-based user authentication system according to one embodiment of the present invention may include a first terminal (20), a second terminal (30), a database (40), a blockchain (50), and an authentication server (100).

[0060] The user (10) can use the identity verification in the second terminal (30) to log in to the app of the first terminal (20).

[0061] The first terminal (20) is a terminal with an app installed to request a login, such as a PC.

[0062] The second terminal (30) is a terminal installed with an app that stores the identity verification of the user (10), and examples of portable terminals such as smartphones may be used.

[0063] The authentication server (100) may correspond to a proximity acoustic-based user authentication device according to an embodiment of the present invention.

[0064] The authentication server (100) can register and manage authentication information of the first terminal (20) and the second terminal (30) for proximity authentication.

[0065] In FIG. 1, the authentication server (100) is depicted as two devices, one on the smartphone side and one on the PC side, but it can be used as a single device. For convenience, the present invention is described as having two devices.

[0066] Additionally, the authentication server (100) can verify authentication information submitted by the first terminal (20) and the second terminal (30).

[0067] At this time, the authentication server (100) can issue an acoustic random number to the second terminal (30) to check whether the first terminal (20) and the second terminal (30) are located close to each other.

[0068] At this time, the authentication server (100) can perform proximity acoustic-based user authentication by comparing the acoustic random number issued above with the acoustic random number received from the first terminal (20).

[0069] The database (DB) (40) can store and manage information of the first terminal (20) and the second terminal (30) for proximity verification authentication.

[0070] Additionally, the database (DB) (40) can store a session random number for connecting two sessions and information that needs to be shared between sessions, because different sessions are created within the authentication server (100) when the first terminal (20) and the second terminal (30) each connect to the authentication server (100).

[0071] Additionally, the database (DB) (40) stores acoustic random numbers generated by the authentication server (100) and can provide acoustic random numbers upon request from the authentication server (100).

[0072] The blockchain (50) can serve as a trusted distributed storage for storing the DID document of the user (10) and the identity certificate issuer, and the identity certificate validity list document.

[0073] In the present invention, 'close distance' means a distance at which the microphone of the first terminal (20), the authentication requester, can clearly recognize the sound played by the second terminal (30) that possesses identity verification, generally within 0.5m.

[0074] The sonic random number is a random number generated by the authentication server for proximity measurement. The sonic random number is transmitted to the second terminal (30), converted into sound according to a set rule and played back, and the first terminal (20) that receives this sound can restore it back into a numerical sonic random number.

[0075] Acoustic random numbers can be used to verify whether the second terminal (30) is close enough for the microphone of the first terminal (20) to recognize the sound generated by the second terminal (30). Acoustic random numbers may have a reception delay limit time as a method to avoid Man-in-the-Middle (MITM) attacks, such as reuse through recording or network relay.

[0076] Decentralized Identity (DID) technology enables individuals or organizations to manage and control their digital identities without the control of a central authority. It utilizes distributed ledger technologies, such as blockchain, to securely store and share identity information and credentials. The decentralized identity technology discussed in this document can utilize the W3C's DID core specifications.

[0077] A Decentralized Identifier (DID) is a unique identifier in a decentralized environment that does not require registration with a central authority and typically uses distributed ledger technology.

[0078] A Verifiable Credential (VC) is digital identity information designed to be easily verified by validators through the decentralized technology of blockchain. Verifiable Credentials allow validators to verify the validity of an identity through the blockchain without needing to connect directly with the issuer when verifying the identity. The Verifiable Credential technology in this document may utilize the W3C VC Data Model specification.

[0079] A Verifiable Presentation (VP) is a format used when a user submits their own identity credentials to a verifier. A user can generate a VP by selecting information from their 보유 identity credentials to submit to the verifier and digitally signing it. The verifier can verify the submitter's identity by verifying the integrity of the VP and the integrity and validity of the identity credentials information contained within the VP.

[0080] A VC validity list document is a list containing information about the validity status of VCs issued by an issuer. In an environment where decentralized identity technology is applied, this list can generally be published on a blockchain. To maintain integrity, the VC validity list document may include the issuer's digital signature on the validity list.

[0081] Referring again to FIG. 1, step (S110) allows the authentication server (100) to generate acoustic random numbers.

[0082] Step (S120) can store the acoustic random number generated by the authentication server (100) in the DB (40).

[0083] Step (S130) allows the authentication server (100) to issue an acoustic random number to the second terminal (30).

[0084] Step (S140) can convert the acoustic random number received by the second terminal (30) into sound.

[0085] Step (S150) allows the second terminal (30) to play a converted acoustic random number.

[0086] Step (S160) allows the first terminal (20) to restore the acoustically generated random number that has been played.

[0087] Step (S170) allows the first terminal (20) to submit the restored acoustic random number to the authentication server (100).

[0088] Step (S180) allows the authentication server (100) to obtain the acoustic random number stored in Step (S120) from the DB (40).

[0089] Step (S190) allows the authentication server (100) to verify by comparing the acoustic random number submitted from the first terminal (20) with the stored acoustic random number.

[0090] FIGS. 2 and FIGS. 3 are sequence diagrams illustrating the user registration step of a near-field acoustic-based user authentication method according to an embodiment of the present invention.

[0091] Referring to FIGS. 2 and FIGS. 3, it can be seen that the process of combining first and second terminal information to be used for authentication and identity verification (VC) information within the terminal and registering them with the authentication server is shown.

[0092] Step (S201) allows the user (10) to run the app of the first terminal (20).

[0093] Step (S202) allows the first terminal (20) to launch an app executed by the user (10).

[0094] Step (S203) allows the user (10) to select the 'Register Authentication Information' button of the first terminal (20) app to register the second terminal (30) to be used for proximity authentication.

[0095] Step (S204) allows the user (10) to enter the address (authServerAddr) of the authentication server (100) that handles proximity authentication into the app.

[0096] Step (S205) allows the first terminal (20) to generate a unique ID (pcID) and a public key pair (pcPubKey, pcPriKey) to be used for authentication.

[0097] Step (S206) can store the pcID, pcPubKey, pcPriKey generated by the first terminal (20) and the address (authServerAddr) of the authentication server (100) in the first terminal (20) in a secure manner.

[0098] Step (S207) allows the first terminal (20) to request a random number (pcRand) for replay attack defense from the authentication server (100).

[0099] Step (S208) allows the authentication server (100) to generate a random number (pcRand) to defend against retransmission attacks.

[0100] Step (S209) allows the authentication server (100) to store a random number generated for comparison with a random number (pcRand) sent back from the first terminal (20) in the session.

[0101] Step (S210) can send a random number (pcRand) generated by the authentication server (100) to the first terminal (20).

[0102] Step (S211) allows the first terminal (20) to generate a digital signature (pcSig) using a private key (pcPriKey) for authentication request information including pcID, pcRand, and the public key (pcPubKey) of the first terminal (20) to construct an authentication request message {pcID, pcRand, pcPubKey, pcSig}.

[0103] Step (S212) allows the first terminal (20) to transmit an authentication request message configured in the format {pcID, pcRand, pcPubKey, pcSig} to the authentication server (100).

[0104] Step (S213) allows the authentication server (100) to check whether the pcRand submitted by the first terminal (20) and the pcRand stored in the session are the same value in order to defend against retransmission attacks.

[0105] Step (S214) allows the authentication server (100) to verify the digital signature (pcSig) using the public key (pcPubKey) in the authentication request to check whether the first terminal (20) possesses a private key corresponding to the public key.

[0106] Step (S215) can generate a session connection random number (sRand) to be used as a key to connect two sessions in order to share information between the authentication server (100) on the first terminal (20) side and the authentication server (100) on the second terminal (30) side.

[0107] Step (S216) allows the authentication server (100) on the first terminal (20) side to store a session connection random number (sRand) in the session information table of the DB (40).

[0108] At this time, step (S216) allows the first terminal (20) and the second terminal (30) to share information through the authentication server (100) using the session connection random number (sRand) stored in the DB (40) by the first terminal (20).

[0109] At this time, step (S216) allows the second terminal (30) to submit the sRand to the authentication server session connected to the first terminal (20) by pushing it to the app of the second terminal (30).

[0110] At this time, in step (S216), if both authentication servers (100) share sRand in the manner described above, each authentication server (100) can periodically query (polle) the session table of the DB (40) with the sRand value to obtain information updated in the session of the other authentication server.

[0111] Step (S217) can poll the VP verification result of the second terminal (30).

[0112] At this time, step (S217) can check whether the result of verifying the VP in the session of the second terminal (30) side authentication server (100) is updated by the authentication server (100) on the first terminal (20) side periodically querying the session table of the DB with sRand as the key value.

[0113] Step (S218) allows the authentication server (100) on the first terminal (20) side to generate a QR containing a session connection random number (sRand) and an identity verification submission URL (vpURL).

[0114] Step (S219) can send the QR generated by the authentication server (100) back to the first terminal (20).

[0115] Step (S220) can display the QR received by the first terminal (20) on the screen.

[0116] Step (S221) allows the first terminal (20) to request a terminal registration result for proximity verification authentication from the authentication server (100) and wait for a response.

[0117] Step (S222) allows the user (10) to run an app that stores the identity verification to scan the QR code on the second terminal (30).

[0118] Step (S223) allows the app executed by the user (10) to be launched.

[0119] Step (S224) allows the user (10) to sequentially select the identity verification submission -> QR capture menu in the app.

[0120] Step (S225) can capture a QR image through the camera of the second terminal (30).

[0121] Step (S226) allows the second terminal (30) to obtain a session connection random number (sRand) and a VP submission URL (vpURL) value within the QR information.

[0122] Step (S227) allows the second terminal (30) to generate a verifiable presentation (VP) containing the following information.

[0123]

[0124] - Terminal pushToken (a unique token value for sending a push from the authentication server (100) to the terminal (30))

[0125] - Session connection random number (sRand)

[0126] - User Identity Verification (VC)

[0127] Step (S228) allows the second terminal (30) to submit a VP to the vpURL address of the authentication server (100) obtained from the QR.

[0128] Step (S229) allows the authentication server (100) on the second terminal (30) side to analyze the VP and obtain the DID information of the submitter (holder) and the DID information of the identity certificate (VC) issuer included in the VP.

[0129] Step (S230) allows the authentication server (100) to query the VC validity list document and the DID Document of the VP submitter and VC issuer on the blockchain (50).

[0130] Step (S231) allows the blockchain (50) to send back the VC validity list document and the issuer and owner's DID document to the second terminal (30) side authentication server (100).

[0131] Step (S232) allows the authentication server (100) on the second terminal (30) side to verify the VP by obtaining a public key from the VP submitter's DID Document and to verify the VC by obtaining a public key from the VC issuer's DID Document.

[0132] Step (S233) allows the authentication server (100) to obtain a public key from the VC issuer's DID Document retrieved from the blockchain (50) and verify the signature of the VC validity list document.

[0133] Step (S234) allows the authentication server (100) to find status information of the VC submitted by the user within the VC validity list document and check the VC validity information value to determine the validity of the VC.

[0134] Step (S235) allows the authentication server (100) to obtain the VC owner's DID (userDID) from the VC information when the VC is confirmed to be valid.

[0135] Step (S236) allows the authentication server (100) to obtain the push token of the second terminal (30) within the VP.

[0136] Step (S237) allows the authentication server (100) to obtain the ID (pcID) of the first terminal (20) within the VP.

[0137] Step (S238) allows the authentication server (100) to store the first terminal (20) ID (pcID), identity verification owner ID (userDID), and push token information of the second terminal (30) in the DB.

[0138] Step (S239) allows the authentication server (100) to obtain a session connection random number (sRand) within the VP information.

[0139] Step (S240) allows the authentication server (100) on the second terminal (30) side to find the session connection random number (sRand) value obtained within the VP in the session table of the DB and update the VP verification result (success / failure).

[0140] Step (S241) allows the authentication server (100) to respond to the VP verification result to the second terminal (30).

[0141] Step (S242) allows the second terminal (30) to receive a response from the authentication server (100) and display a registration result message.

[0142] Step (S243) allows the user (10) to check and tap the registration result message displayed on the second terminal (30).

[0143] Step (S244) allows the authentication server (100) on the first terminal (20) side to monitor the session table through polling and obtain the VP verification result when it is updated.

[0144] Step (S245) allows the authentication server (100) to check whether the VP verification result value retrieved from the session table is successful and to generate a response for the first terminal (20) accordingly.

[0145] Step (S246) allows the authentication server (100) to transmit the result of 'terminal registration for proximity verification authentication' to the first terminal (20).

[0146] Step (S247) allows the first terminal (20) to receive a response from the authentication server (100) and display a registration result message.

[0147] Step (S248) allows the user (10) to check and tap the registration result message displayed on the first terminal (20).

[0148] FIGS. 4, FIGS. 5, and FIGS. 7 are sequence diagrams illustrating the user authentication steps of a proximity acoustic-based user authentication method. FIG. 6 is a graph illustrating the structure of an acoustic generated when an acoustic random number is converted into an acoustic signal according to an embodiment of the present invention.

[0149] Referring to FIG. 4, it can be seen that the process of authenticating (logging in) to the first terminal (20) using the identity certificate stored in the second terminal (30) is shown. At this time, the first terminal (20) and the second terminal (30) must be located at a close distance where sound transmission is possible between them.

[0150] Step (S301) allows the user (10) to run the app of the first terminal (20).

[0151] Step (S302) allows the app executed by the user (10) to be launched.

[0152] Step (S303) allows the user (10) to select the 'Login' button of the first terminal (20) app for proximity authentication.

[0153] Step (S304) allows the first terminal (20) to request a random number (pcRand) for replay attack defense from the authentication server (100).

[0154] Step (S305) allows the authentication server (100) to generate a random number (pcRand) to defend against retransmission attacks.

[0155] Step (S306) allows the authentication server (100) to store a random number generated for comparison with a random number (pcRand) sent back from the first terminal (20) in the session.

[0156] Step (S307) can send a random number (pcRand) generated by the authentication server (100) to the first terminal (20).

[0157] Step (S308) allows the first terminal (20) to generate a digital signature (pcSig) using a private key (pcPriKey) for authentication request information including pcID and pcRand, thereby constructing an authentication request message {pcID, pcRand, pcSig}.

[0158] Step (S309) allows the first terminal (20) to transmit an authentication request message configured in the format {pcID, pcRand, pcSig} to the authentication server (100).

[0159] Step (S310) allows the authentication server (100) to check whether the pcRand submitted by the first terminal (20) and the pcRand stored in the session are the same value in order to defend against retransmission attacks.

[0160] Step (S311) is when the authentication server (100) obtains the pcID from the authentication request message, and then queries the DB using this value as a key to obtain the public key (pcPubKey) of the first terminal (20) corresponding to the pcID, the push token (pushToken), and the DID (userID) of the identity proof owner of the second terminal (30).

[0161] Step (S312) allows the authentication server (100) to verify the digital signature (pcSig) of the message using the public key (pcPubKey) obtained from the DB to verify whether the first terminal (20) possesses a private key corresponding to the public key.

[0162] Step (S313) can generate a session connection random number (sRand) to be used as a key to connect two sessions in order to share information between the authentication server (100) on the first terminal (20) side and the authentication server (100) on the second terminal (30) side.

[0163] Step (S314) allows the authentication server (100) on the first terminal (20) side to store a session connection random number (sRand) in the session information table of the DB.

[0164] Step (S315) allows the authentication server (100) on the first terminal (20) side to periodically query the session table of the DB with sRand as the key value to check whether the sonic random number (sonicRand) is updated in the session of the authentication server (100) on the second terminal (30) side.

[0165] Step (S316) allows the authentication server (100) to generate a push request including a session connection random number (sRand) and an identity verification submission URL (vpURL).

[0166] Step (S317) allows the authentication server (100) to send a push to the second terminal (30) using a push token.

[0167] Step (S318) allows the second terminal (30) that received the push to generate a Verifiable Presentation (VP) including a session connection random number (sRand) and a user's identity verification (VC).

[0168] Step (S319) allows the second terminal (30) to submit a VP to the vpURL address of the authentication server (100) obtained from the push information.

[0169] Referring to FIG. 5, step (S320) allows the authentication server (100) on the second terminal (30) side to analyze the VP and obtain the DID information of the submitter (holder) and the DID information of the identity certificate (VC) issuer included in the VP.

[0170] Step (S321) allows the authentication server (100) to query the VC validity list document and the DID Document of the VP submitter and VC issuer on the blockchain (50).

[0171] Step (S322) allows the blockchain (50) to send back the VC validity list document and the issuer and owner's DID document to the second terminal (30) side authentication server (100).

[0172] Step (S323) allows the authentication server (100) on the second terminal (30) side to verify the VP by obtaining a public key from the VP submitter's DID Document and to verify the VC by obtaining a public key from the VC issuer's DID Document.

[0173] Step (S324) allows the authentication server (100) to obtain a public key from the VC issuer's DID Document retrieved from the blockchain (50) and verify the signature of the VC validity list document.

[0174] Step (S325) allows the authentication server (100) to find status information of the VC submitted by the user within the VC validity list document and to determine the validity of the VC by checking the value of this VC validity information. If the VC is valid, it can be checked whether the registered user's DID (userID) matches the DID of the VC owner.

[0175] Step (S326) allows the authentication server (100) to obtain a session connection random number (sRand) within the VP information.

[0176] Step (S327) can generate sonic random numbers.

[0177] Step (S327) allows the authentication server (100) to generate a sonic random number required for proximity verification authentication.

[0178] At this time, step (S327) can generate a random number value between 20 and 20,000 because the acoustic random number is converted into an audible frequency band (20 to 20,000 Hz) at the second terminal.

[0179] However, step (S327) can generate acoustic random numbers in a narrower range between 200 and 18,000 Hz by considering the performance of the terminal's microphone, external environment, etc.

[0180] Also, step (S327) can set the minimum interval between acoustic random numbers to 100Hz so that it is less affected by noise during the transmission process.

[0181] Accordingly, step (S327) may use a method of generating an acoustic random number between 2 and 180 and then multiplying this value by 100 to convert it into an acoustic number.

[0182] Step (S327) can be set differently depending on the security policy, such as the number of acoustic random numbers generated, the method for converting them into sound, and the length of each sound converted from the acoustic random numbers.

[0183] Step (S327) may involve the authentication server (100), the first terminal (20), and the second terminal (30) sharing this policy in advance.

[0184] Step (S328) may request preparation for proximity verification authentication.

[0185] At this time, step (S328) may request the second terminal (30) to convert the acoustic random number into sound in advance by sending an acoustic random number so that the second terminal (30) can respond with sound converted from the acoustic random number as soon as the first terminal (20) sends an acoustic random number request to the second terminal (30).

[0186] Step (S329) can receive a sonic random number and convert it into sound.

[0187] At this time, step (S329) allows the second terminal (30) to receive 5 acoustic random numbers and calculate the frequency to be converted into sound by multiplying the value by 100.

[0188] At this time, step (S329) can be {300, 1400, 18000, 5700, 10000} when calculating the frequency to be converted into sound using the acoustic random number shown in FIG. 6.

[0189] At this time, step (S329) can generate a sound of a total length of 1 second by playing the five frequencies for 200ms each.

[0190] Step (S329) can be created as an audio format such as wav, mp3, etc., which can be easily played by the second terminal (30).

[0191] Step (S329) can be generated using a media API provided by the terminal's OS or development language as sound. It can be seen that using the above frequency values ​​generates sound as shown in FIG. 6.

[0192] Referring to FIG. 6, it can be seen that the structure of the sound generated when converting acoustic random numbers according to an embodiment of the present invention into sound is shown. It can be seen that five sonic random numbers from 2 to 180, {3, 14, 180, 57, 100}, are generated.

[0193] Step (S330) can guide the second terminal (30) to the user (10) to bring the second terminal (30) close to the first terminal (20) and press the confirmation button.

[0194] Step (S331) allows the user (10) to bring the second terminal (30) close to the first terminal (20) and then tap the ready button.

[0195] Step (S332) allows the second terminal (30) to turn on the microphone.

[0196] Step (S333) allows the second terminal (30) to turn on the speaker.

[0197] Step (S334) allows the second terminal (30) to reply to the authentication server (100) that the proximity verification authentication preparation is complete.

[0198] Step (S335) can display a notification message to the user (10) that the second terminal (30) is waiting for proximity verification authentication and monitor the sound received by the microphone.

[0199] Step (S336) allows the authentication server (100) on the second terminal (30) side to update the session connection random number (sRand) and acoustic random number (sonicRand) values ​​in the session table of the DB.

[0200] Step (S337) allows the authentication server (100) on the second terminal (30) side to poll whether the proximity authentication result is updated in the session table of the DB (40) at the authentication server (100) on the first terminal (20) side.

[0201] Step (S338) allows the authentication server (100) on the first terminal (20) side to obtain the sonic random number value updated in the session table from the authentication server (100) on the second terminal (30) side through polling.

[0202] Referring to FIG. 7, step (S339) allows the authentication server (100) on the side of the first terminal (20) to request the first terminal (20) to measure the distance from the second terminal (30).

[0203] Step (S340) allows the first terminal (20) to turn on the microphone.

[0204] Step (S341) allows the first terminal (20) to turn on the speaker.

[0205] Step (S342) allows the first terminal (20) to play an acoustic random number request sound of a predetermined length and frequency. The purpose of playing this sound may be to request the second terminal (30) to reply with an acoustic random number converted into sound. In FIG. 7, a method of playing a 4000Hz sound of 0.2 seconds in length three times at 0.2-second intervals may be used.

[0206] FIG. 8 is a graph showing the structure of a requested sound according to an embodiment of the present invention. FIG. 9 is a graph showing the recording point of the playback completion time of the requested sound according to an embodiment of the present invention. FIG. 10 is a graph showing the structure of a received analyzed sound according to an embodiment of the present invention. FIG. 11 is a graph showing the recording point of the sound reception start time of the converted sound according to an embodiment of the present invention.

[0207] Referring to Fig. 8, it can be seen that a 4000Hz sound with a length of 0.2 seconds is requested three times at intervals of 0.2 seconds.

[0208] Step (S343) allows the first terminal (20) to store the playback completion time (tS) in memory immediately after the acoustic random number request sound playback is completed.

[0209] Referring to Fig. 9, it can be seen that the time point (tS) for recording the completion time of the requested sound playback in the requested sound is indicated.

[0210] Step (S344) allows the first terminal (20) to turn off the speaker when the acoustic random number request sound playback is completed.

[0211] Step (S345) allows the acoustic random number request sound played from the first terminal (20) to be transmitted to the second terminal (30).

[0212] Step (S346) allows the second terminal (30) to receive a sound request for an acoustic random number of a promised length in the following way. The second terminal (30) samples the sound received through the microphone in 1ms increments, discards it if it is not the promised frequency, and continues sampling to check the pattern if it is the promised frequency.

[0213] For example, if a 4000Hz sound is played three times with a length of 200ms and a 200ms interval, sampling in 1ms increments will result in approximately 200 4000Hz patterns followed by about 200 silent patterns, followed by about 200 4000Hz patterns, then another 200 silent patterns, and finally about 200 4000Hz patterns. At this time, step (S346) can check for each sample whether it is a predefined frequency, and if a frequency that does not meet the criteria is received, it can be discarded and sampling for 1 second can be performed again from the beginning. To perform such sound sampling in a real-world usage environment, noise must be filtered to prevent malfunctions caused by noise. This function can be implemented by using a media API provided by a library of the OS or app development language.

[0214] Referring to Fig. 10, it can be seen that the process of analyzing sound received in the above manner is shown.

[0215] Step (S347) allows the second terminal (30) to receive a sonic random number request sound for a promised amount of time, and then immediately after the request sound ends, play a sonic random number converted into sound.

[0216] Step (S348) allows the acoustically generated random number played by the second terminal (30) to be transmitted to the first terminal (20).

[0217] Step (S349) allows the microphone of the first terminal (20) to receive the acoustically generated random number played by the second terminal (30). The receiving method may be sampled for a specified time using the sampling method described above, which is sampling in 1ms increments.

[0218] Step (S350) allows the first terminal (20) to record in memory the time (reception start time, tR) when an acoustic random number is detected by the microphone.

[0219] Referring to Fig. 11, it can be seen that the time point (tR) at which the sound reception started is recorded is indicated in the sound.

[0220] Step (S351) allows the microphone to be turned off when the first terminal (20) has finished receiving the acoustically generated random number.

[0221] Step (S352) allows the first terminal (20) to calculate the difference between the acoustic random number reception start time (tR) and the acoustic random number request sound playback completion time (tS) and check if it is shorter than the reference response limit time.

[0222] At this time, step (S352) may set a response limit time of 3ms or less by considering the current 5G communication and network latency and sampling interval to block relay attacks such as recording and video calls. This response limit time may be increased or decreased by considering the performance of the communication infrastructure, the sampling interval, and the processing speed of the general-purpose terminal.

[0223] Step (S353) can proceed with the authentication failure processing procedure in the following order if, in Step (S352), it is confirmed that the distance between the first terminal (20) and the second terminal (30) is not within the sound reach range when the proximity verification authentication fails.

[0224] Step (S353) can return a proximity verification authentication failure to the authentication server (100) if the negative value calculated by the first terminal (20) is longer than the standard response limit time (e.g., 3ms), considering it as fraudulent activity such as transmission via recording.

[0225] Step (S354) allows the first terminal (20) to display an authentication failure message to the user (10).

[0226] Step (S355) allows the user (10) to check the authentication failure message displayed on the first terminal (20).

[0227] Step (S356) allows the authentication server (100) on the side of the first terminal (20) to check the authentication failure message received from the first terminal (20) and then update the proximity verification authentication failure code in the session table of the DB.

[0228] Step (S357) allows the authentication server (100) connected to the second terminal (30) to poll the session table and check the result of the proximity verification authentication processing.

[0229] Step (S358) allows the authentication server (100) to generate an authentication failure response message to be sent to the second terminal (30).

[0230] Step (S359) can transmit an authentication failure response message generated by the authentication server (100) to the second terminal (30).

[0231] Step (S360) can display an authentication failure message received by the second terminal (30) from the authentication server (100) to the user (10).

[0232] Step (S361) allows the user (10) to check the authentication failure message displayed on the second terminal (30).

[0233] FIG. 12 is a sequence diagram showing the processing steps upon successful near-field authentication in the user authentication step illustrated in FIG. 4, FIG. 5 and FIG. 7. FIG. 13 is a graph showing acoustic random number sampling of a first terminal according to an embodiment of the present invention.

[0234] Step (S362) allows the proximity authentication success procedure to proceed in the following order when the proximity authentication is successful through acoustic random number transmission between the first terminal (20) and the second terminal (30) upon the success of proximity verification authentication in Step (S352) illustrated in FIG. 7.

[0235] Referring to FIG. 12, step (S362) can determine that proximity authentication can proceed normally if the - value calculated by the first terminal (20) is shorter than or equal to the reference response limit time.

[0236] Step (S363) can restore the acoustic random number recorded by the first terminal (20) through the microphone to an acoustic random number.

[0237] At this time, step (S363) can analyze the frequency through acoustic sampling and extract the original acoustic random number based on this.

[0238] At this time, step (S363) can sample acoustic random numbers 1,000 times per second at intervals of 1 ms.

[0239] At this time, if step (S363) converts 5 acoustic random numbers into acoustics in 200ms intervals as in the example, 1000 samples can be divided into 5 groups of 200 samples each in order.

[0240] At this time, step (S363) discards n start values ​​and end values ​​from 5 groups because each of the 200 acoustically random number sampling values ​​that are acoustically generated may contain the previous or subsequent acoustically random number value or noise due to measurement error. n can be appropriately determined by considering the environment. For example, if step (S363) decides to discard 5 start and end values ​​each, it may discard the 1st to 5th values ​​(start values) and the 196th to 200th values ​​(end values).

[0241] At this point, step (S363) can calculate the average of each group value that is discarded and remains. In the example, five values ​​similar to {300, 1400, 18000, 5700, 10000} are calculated.

[0242] At this time, step (S363) takes an integer obtained by dividing the average value by 100, so that noise less than 100 Hz is discarded, and thus the acoustic random number {3, 14, 180, 57, 100} of FIG. 13 can be obtained.

[0243] Referring to FIG. 13, it can be seen that acoustic random number sampling of the first terminal (20) is shown.

[0244] Step (S364) allows the first terminal (20) to generate a digital signature (pcSig) using the private key (pcPriKey) of the first terminal (20) and the ID information (pcID) of the first terminal (20), including sonic random numbers (sonicRand), e.g., {3, 14, 180, 57, 100}, and the ID information (pcID) of the first terminal (20), and to construct a proximity verification authentication request message {pcID, sonicRand, pcSig} to be transmitted to the authentication server (100).

[0245] Step (S365) allows the first terminal (20) to submit a proximity verification authentication request message to the authentication server (100).

[0246] Step (S366) allows the authentication server (100) on the side of the first terminal (20) to extract a sonic random number from the proximity verification authentication request message.

[0247] Step (S367) can verify whether there is a match by comparing the acoustic random number included in the authentication request message sent from the first terminal (20) with the acoustic random number obtained from the session table of the DB (40). Through this comparison, it can be determined whether the proximity authentication was performed successfully.

[0248] Step (S368) allows the authentication server (100) to verify the digital signature (pcSig) of the authentication request message using the public key (pcPubKey) of the first terminal (20) and confirm the integrity of the message.

[0249] Step (S369) allows the authentication server (100) to send an authentication success response to the first terminal (20) when the integrity of the proximity authentication request message is confirmed.

[0250] Step (S370) allows the first terminal (20) to display an authentication success message to the user (10).

[0251] Step (S371) allows the user (10) to confirm that the login procedure has been completed in the app of the first terminal (20).

[0252] Step (S372) allows the authentication server (100) on the first terminal (20) side to update the authentication success code in the authentication result column associated with the session connection random number (sRand) in the session table of the DB (40).

[0253] Step (S373) allows the authentication server (100) connected to the second terminal (30) to poll the session table to check if the authentication result code has been updated to success.

[0254] Step (S374) allows the authentication server (100) on the second terminal (30) side to generate an authentication success response after confirming that the authentication result code is successful.

[0255] Step (S375) allows the authentication server (100) to send an authentication success response to the second terminal (30).

[0256] Step (S376) allows the second terminal (30) to display an authentication success message to the user (10).

[0257] Step (S377) allows the user (10) to check the authentication success message displayed on the second terminal (30).

[0258] FIG. 14 is a block diagram showing a proximity acoustic-based user authentication device according to an embodiment of the present invention.

[0259] Referring to FIG. 14, a proximity acoustic-based user authentication device according to one embodiment of the present invention may include an authentication information management unit (410), an acoustic random number generation unit (420), and an acoustic random number verification unit (430). The authentication information management unit (410), the acoustic random number generation unit (420), and the acoustic random number verification unit (430) may perform the functions of the authentication server (100) described in FIG. 1 to FIG. 14.

[0260] The authentication information management unit (410) can store and manage authentication-related data of the user (10), the first terminal (20), and the second terminal (30).

[0261] The authentication information management unit (410) can generate a session connection random number (sRand) and store it in the DB (40).

[0262] The authentication information management unit (410) can set up and manage communication sessions with the first terminal (20) and the second terminal (30).

[0263] The authentication information management unit (410) can process authentication request information received from the first terminal (20) and the second terminal (30).

[0264] The authentication information management unit (410) can communicate with the blockchain (50) to retrieve information related to identity verification (VC) and DID.

[0265] The authentication information management unit (410) can verify the electronic signature associated with the ID information of the user (10) and the terminal.

[0266] The authentication information management unit (410) can determine whether authentication is successful or unsuccessful and update the session table accordingly.

[0267] The acoustic random number generator (420) can generate an acoustic random number for proximity acoustic-based user authentication using the first terminal (20) and the second terminal (30) of the user (10) and transmit it to the second terminal (30).

[0268] At this time, the acoustic random number generator (420) can generate a session connection random number in response to a user authentication request from the first terminal (20) and transmit it to the second terminal (30).

[0269] At this time, the acoustic random number generator (420) can receive a verifiable presentation (VP) containing the session connection random number and the user's identity proof (Verifiable Credential, VC) from the second terminal (30) and verify it through a blockchain network.

[0270] The acoustic random number generator (420) can generate an acoustic random number (sonicRand) required for proximity authentication.

[0271] At this time, the acoustic random number generator (420) can generate the acoustic random number using multiple values ​​corresponding to the audible frequency and store it in a database together with the session connection random number.

[0272] The acoustic random number generator (420) can transmit the generated acoustic random number to the second terminal (30) to convert it into sound.

[0273] The acoustic random number generator (420) can generate acoustic random numbers resistant to noise using a random number generation algorithm.

[0274] The acoustic random number generator (420) can store the generated acoustic random number and the session connection random number (sRand) in the DB (40).

[0275] The acoustic random number generator (420) can generate acoustic random numbers of various frequency ranges (e.g., 200 to 18,000 Hz) upon request.

[0276] The acoustic random number generator (420) can verify the validity of the acoustic random number by linking it with the authentication information management unit (410) before transmission.

[0277] At this time, the second terminal (30) can play the sound converted from the acoustic random number to the first terminal (20).

[0278] At this time, the first terminal (20) can convert an acoustic random number from the sound.

[0279] The acoustic random number verification unit (430) can verify the authentication request message by comparing the acoustic random number included in the authentication request message received from the first terminal with the acoustic random number transmitted to the second terminal.

[0280] At this time, the acoustic random number verification unit (430) requests the first terminal (20) to play a preset acoustic random number request sound to the second terminal (30), and the first terminal (20) can play the acoustic random number request sound to the second terminal (30).

[0281] At this time, the second terminal (30) can receive the acoustic random number request sound and record the playback completion time.

[0282] At this time, the second terminal (30) can play sounds corresponding to multiple frequency values ​​converted from the acoustic random number at preset time units for each frequency value.

[0283] At this time, the first terminal (20) can record the reception start time of receiving the sound converted from the acoustic random number.

[0284] At this time, the acoustic random number verification unit (430) can verify whether the difference between the playback completion time and the reception start time is shorter than the preset response limit time.

[0285] At this time, if the difference between the playback completion time and the reception start time is shorter than the preset response limit time, the first terminal (20) can convert the sound converted from the acoustic random number into an acoustic random number.

[0286] At this time, the first terminal (20) can generate the authentication request message digitally signed with the acoustic random number converted from the sound and the private key of the first terminal.

[0287] The acoustic random number verification unit (430) can compare the acoustic random number received from the first terminal (20) with the acoustic random number stored in the session to check whether they match.

[0288] The acoustic random number verification unit (430) can analyze the acoustically generated acoustic random number and restore it to the original acoustic random number (sonicRand).

[0289] The acoustic random number verification unit (430) can verify the acoustic random number within the authentication request message transmitted from the first terminal (20).

[0290] The acoustic random number verification unit (430) can determine whether the proximity authentication is successful based on the restored acoustic random number.

[0291] The acoustic random number verification unit (430) can verify the integrity by verifying the electronic signature of the authentication request message.

[0292] The acoustic random number verification unit (430) can transmit whether authentication failed or succeeded to the authentication information management unit (410).

[0293] The acoustic random number verification unit (430) can increase verification accuracy by filtering out noise and distorted acoustic data.

[0294] FIG. 15 is a drawing showing a computer system according to an embodiment of the present invention.

[0295] Referring to FIG. 15, a first terminal (20), a second terminal (30), and a proximity acoustic-based user authentication device (100) according to an embodiment of the present invention may be implemented in a computer system (1100), such as a computer-readable recording medium. As illustrated in FIG. 15, the computer system (1100) may include one or more processors (1110), memory (1130), user interface input device (1140), user interface output device (1150), and storage (1160) that communicate with each other via a bus (1120). Additionally, the computer system (1100) may further include a network interface (1170) connected to a network (1180). The processor (1110) may be a central processing unit or a semiconductor device that executes processing instructions stored in memory (1130) or storage (1160). Memory (1130) and storage (1160) may be various forms of volatile or non-volatile storage media. For example, memory may include ROM (1131) or RAM (1132).

[0296] As described above, the proximity acoustic-based user authentication device and method according to one embodiment of the present invention are not limited to the configurations and methods of the embodiments described above; rather, all or part of each embodiment may be selectively combined to allow for various modifications to be made.

Claims

An acoustic random number generator that generates an acoustic random number for proximity acoustic-based user authentication using a user's first terminal and second terminal and transmits it to the second terminal; and An acoustic random number verification unit that verifies the authentication request message by comparing the acoustic random number included in the authentication request message received from the first terminal with the acoustic random number transmitted to the second terminal; Includes, The second terminal plays the sound converted from the acoustic random number to the first terminal, and The above-mentioned first terminal is a proximity acoustic-based user authentication device characterized by converting an acoustic random number from the above-mentioned acoustic. In claim 1, The above acoustic random number generator A proximity acoustic-based user authentication device characterized by generating a session connection random number in response to a user authentication request from the first terminal and transmitting it to the second terminal. In claim 2, The above acoustic random number generator A proximity acoustic-based user authentication device characterized by receiving a Verifiable Presentation (VP) containing the session connection random number and the user's Verifiable Credential (VC) from the second terminal and verifying it through a blockchain network. In claim 3, The above acoustic random number generator A proximity acoustic-based user authentication device characterized by generating the acoustic random number using multiple values ​​corresponding to audible frequencies and storing it in a database together with the session connection random number. In claim 1, The above acoustic random number verification unit A proximity acoustic-based user authentication device characterized by requesting the first terminal to play a preset acoustic random number request sound to the second terminal, and the first terminal playing the acoustic random number request sound to the second terminal. In claim 5, The above second terminal A proximity acoustic-based user authentication device characterized by receiving the above-mentioned acoustic random number request acoustic and recording the playback completion time. In claim 6, The above second terminal A proximity acoustic-based user authentication device characterized by playing acoustics corresponding to a plurality of frequency values ​​converted from the above acoustic random number at preset time units for each frequency value. In claim 7, The above first terminal A proximity acoustic-based user authentication device characterized by recording the reception start time of receiving the acoustic converted from the above acoustic random number. In claim 8, The above acoustic random number verification unit A proximity acoustic-based user authentication device characterized by verifying whether the difference between the above-mentioned playback completion time and the above-mentioned reception start time is shorter than a preset response limit time. In claim 9, The above first terminal A proximity acoustic-based user authentication device characterized by converting the acoustic number converted from the acoustic random number into an acoustic random number when the difference between the above playback completion time and the above reception start time is shorter than a preset response limit time. In claim 10, The above first terminal A proximity acoustic-based user authentication device characterized by generating the authentication request message digitally signed with an acoustic random number converted from the above acoustic and the private key of the first terminal. In a proximity acoustic-based user authentication method of a proximity acoustic-based user authentication device, A step of generating an acoustic random number for proximity acoustic-based user authentication using the user's first terminal and second terminal and transmitting it to the second terminal; A step in which the second terminal plays the sound converted from the acoustic random number to the first terminal; The step of the first terminal converting an acoustic random number from the sound; and A step of verifying the authentication request message by comparing the acoustic random number included in the authentication request message received from the first terminal with the acoustic random number transmitted to the second terminal; A proximity acoustic-based user authentication method characterized by including In claim 12, The step of generating the above acoustic random number and transmitting it to the second terminal A proximity acoustic-based user authentication method characterized by generating a session connection random number in response to a user authentication request from the first terminal and transmitting it to the second terminal. In claim 13, The step of generating the above acoustic random number and transmitting it to the second terminal A proximity acoustic-based user authentication method characterized by receiving a Verifiable Presentation (VP) containing the session connection random number and the user's Verifiable Credential (VC) from the second terminal and verifying it through a blockchain network. In claim 14, The step of generating the above acoustic random number and transmitting it to the second terminal A proximity acoustic-based user authentication method characterized by generating the acoustic random number using a plurality of values ​​corresponding to audible frequencies and storing it in a database together with the session connection random number. In claim 12, The above proximity acoustic-based user authentication method A step of requesting the second terminal to play a preset acoustic random number request sound to the first terminal; and A proximity acoustic-based user authentication method characterized by further including the step of the first terminal playing an acoustic random number request sound to the second terminal. In claim 16, The step of playing to the second terminal above A proximity acoustic-based user authentication method characterized in that the second terminal receives the acoustic random number request acoustic and records the playback completion time. In claim 17, The step of playing to the first terminal above A proximity sound-based user authentication method characterized by the second terminal playing a sound corresponding to a plurality of frequency values ​​converted from the acoustic random number at preset time units for each frequency value. In claim 18, The step of playing to the first terminal above A proximity acoustic-based user authentication method characterized in that the first terminal records the reception start time of receiving the acoustic converted from the acoustic random number. In claim 19, The above-mentioned conversion step A proximity acoustic-based user authentication method characterized by verifying whether the difference between the playback completion time and the reception start time is shorter than a preset response limit time.

Images