WO2016126052A2 - 인증 방법 및 시스템 - Google Patents

인증 방법 및 시스템 Download PDF

Info

Publication number
WO2016126052A2
WO2016126052A2 PCT/KR2016/000951 KR2016000951W WO2016126052A2 WO 2016126052 A2 WO2016126052 A2 WO 2016126052A2 KR 2016000951 W KR2016000951 W KR 2016000951W WO 2016126052 A2 WO2016126052 A2 WO 2016126052A2
Authority
WO
WIPO (PCT)
Prior art keywords
otp
user
server
authentication
verification
Prior art date
Application number
PCT/KR2016/000951
Other languages
English (en)
French (fr)
Other versions
WO2016126052A3 (ko
Inventor
우종현
Original Assignee
(주)이스톰
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020150018752A external-priority patent/KR101570317B1/ko
Application filed by (주)이스톰 filed Critical (주)이스톰
Priority to US15/540,035 priority Critical patent/US10298400B2/en
Publication of WO2016126052A2 publication Critical patent/WO2016126052A2/ko
Publication of WO2016126052A3 publication Critical patent/WO2016126052A3/ko
Priority to US16/377,242 priority patent/US10574463B2/en
Priority to US16/748,765 priority patent/US11876908B2/en
Priority to US18/512,061 priority patent/US20240089110A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0872—Generation of secret information including derivation or calculation of cryptographic keys or passwords using geo-location information, e.g. location data, time, relative position or proximity to other entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos

Definitions

  • the present invention relates to an authentication system, and more particularly, to an authentication method and system using one time password (OTP).
  • OTP one time password
  • OTP One Time Password
  • a one-time password has been spreading as a method of authentication in financial transactions or where confidentiality is required.
  • OTP is divided into a hardware-based dongle method and a software app method of a user terminal according to a driving method.
  • the hardware dongle method has a high security effect, but it is inconvenient to carry and cost.
  • the software method has a low security effect but a low cost.
  • the present invention is to provide an authentication method and system with enhanced security as an authentication method and system using one time password (OTP).
  • OTP one time password
  • an authentication method and system with enhanced security are provided.
  • a computer implemented method for performing mutual authentication between an online service server and a service user
  • the OTP generator generates an OTP for checking the same condition as the server verification OTP for authenticity of the online service server, and uses the same generation key as the OTP generation key used to generate the OTP for server verification.
  • the calculation conditions may be different from those used to generate the server verification OTP, or may be generated by using a generation key different from the OTP generation key used to generate the server verification OTP. Generating a user OTP having a value paired with the server verification OTP by applying the same operation condition as the condition; And
  • a computer-implemented method for mutual authentication includes authenticating the service user by comparing a match.
  • a computer implemented method for performing mutual authentication between an online service server and a service user
  • the authentication server generates a corresponding verification value in response to the additional verification value transmitted from the simple authenticator as verification of the online service server through the simple authentication number and the verification authentication number is completed; And comparing the additional verification value with the corresponding verification value to perform authentication for the corresponding service user.
  • a computer implemented method for authenticating a service user connected to an online service server According to a third embodiment of the present invention, there is provided a computer implemented method for authenticating a service user connected to an online service server.
  • the authentication server generates the verification OTP for authentication of the service user by using the access terminal connection information, and compares the match between the generated verification OTP and the user OTP delivered from the online service server.
  • a user authentication method is provided that includes performing authentication for a service user.
  • the fourth embodiment of the present invention as a computer implemented method for verifying a driving environment in which a one time password (OTP) app is driven, wherein the OTP app is installed on a mobile device and is installed on the OTP.
  • Software-based OTP generator to generate a
  • the authentication server provides a method for verifying the driving environment of the OTP app comprising the step of transmitting the OTP generation condition value to the OTP app.
  • a computer-implemented method for an One Time Password (OTP) application executed in a user terminal wherein a network connection state of the user terminal is received when a driving request for the OTP application is received. Confirming; And controlling the OTP application to be executed when the network connection is in an inactive state according to a result of checking the network connection state.
  • OTP One Time Password
  • a computer implemented method for an One Time Password (OTP) application executed in a user terminal comprising: checking a network connection state of the user terminal while the OTP application is running; And controlling, when the network connection is established, at least one of driving the OTP application and performing a function according to the driving, according to a result of checking the network connection state.
  • OTP One Time Password
  • FIG. 1 and 8 show a view related to the first embodiment of the present invention.
  • FIG. 1 is a view for explaining a method and system for mutual authentication between an online service server and a service user according to an embodiment of the present invention.
  • FIG. 2 is a block diagram of one embodiment of an OTP authentication server implementing a mutual authentication method in accordance with an embodiment of the present invention.
  • FIG. 3 is a block diagram of one embodiment of an OTP generator implementing a mutual authentication method in accordance with an embodiment of the present invention.
  • FIG 4 is an example of an OTP posting screen displayed on an online service site by an online service server.
  • FIG. 5 illustrates an example of a screen in which a confirmation OTP and a user OTP generated by an OTP generator are displayed through a screen of a mobile device.
  • FIG. 6 illustrates an example of a screen in which a user OTP is displayed through a screen of a mobile device in a time OTP generation method while the OTP for confirmation is driven by a challenge & response generation method by the OTP generator.
  • FIG. 7 is a view for explaining a mutual authentication method using OTP according to another embodiment of the present invention.
  • FIG. 8 is an example of screen display on a mobile device according to FIG.
  • FIG. 9 is a view for explaining a method and system for mutual authentication between an online service server and a service user according to an embodiment of the present invention.
  • FIG. 10 is a block diagram of one embodiment of an authentication server implementing a mutual authentication method according to an embodiment of the present invention.
  • FIG. 11 is a block diagram of one embodiment of a simple authenticator implementing a mutual authentication method according to an embodiment of the present invention.
  • 12 is an example related to a screen in which a simple authentication number is posted on an online service site operated by an online service server.
  • 13 is an example associated with a screen on which the verification authentication number generated by the simple authenticator is displayed.
  • FIG. 14 is a view for explaining a processing method when a connection attempt by a hacker in the authentication process according to the mutual authentication method of FIG.
  • FIG. 15 is a diagram illustrating a processing result posted on an online service site operated by an online service server when a hacker attempts to connect as shown in FIG.
  • 16 and 17 are exemplary implementations of a mutual authentication method according to an embodiment of the present invention when a user accesses an online service server through a mobile device.
  • FIG. 18 is a view for explaining a user authentication method and authentication system according to an embodiment of the present invention.
  • 19 is a block diagram of one embodiment of an online service server associated with a user authentication method in accordance with an embodiment of the present invention.
  • FIG. 20 is a block diagram of one embodiment of an OTP authentication server implementing a user authentication method in accordance with an embodiment of the present invention.
  • 21 is a block diagram of one embodiment of an OTP generator implementing a user authentication method in accordance with an embodiment of the present invention.
  • FIG. 22 is a view illustrating a method for verifying a driving environment of an OTP app and an authentication system using the same according to an embodiment of the present invention.
  • 23 and 24 are block diagrams of an embodiment of an OTP app and an OTP authentication server for implementing a method for verifying a driving environment of an OTP app according to an embodiment of the present invention.
  • 25 and 31 are views related to the fifth embodiment of the present invention.
  • FIG. 25 illustrates a functional block of a transaction interworking OTP application as an embodiment of the present invention.
  • 26 is a schematic flowchart of a method for driving an OTP application according to an embodiment of the present invention.
  • 27 to 31 are diagrams illustrating execution screens of a transaction interlocking OTP application according to one embodiment of the present invention.
  • one component when one component is referred to as “connected” or “connected” with another component, the one component may be directly connected or directly connected to the other component, but in particular It is to be understood that, unless there is an opposite substrate, it may be connected or connected via another component in the middle.
  • unit that processes at least one function or operation, which means that it may be implemented by one or more pieces of hardware or software or a combination of hardware and software.
  • This embodiment relates to a mutual authentication method and system using OTP. More specifically, mutual authentication using OTP enables mutual verification between the service provider and the service user by providing user authentication information after verifying whether the server providing the online service is a server by a true service provider. It relates to a method and a system.
  • OTP Time Password
  • a pharming attack allows a user to recognize a website operated by a hacker as the correct site, thereby identifying the user's account information (for example, username and password) and the OTP value entered by the user in the OTP input window. It is an attack where a hacker intercepts user's money or information by using hijacked account information and OTP value.
  • the conventional technology allows a user to upload a personal image to a service server to indicate that the site is a normal site, or change the color in the address bar using SSL (Secure Socket Layer) to indicate that the site is normal. This was used.
  • the method of registering a personalized image is not easy to use because the user does not voluntarily register the image of the individual, and the use of the address bar color change service is different from browser to browser and is not easy to recognize, which causes user confusion. There are many cases. Therefore, there is a need for an improved method and technology that allows a user to naturally verify a service server while also authenticating the user.
  • the server verification OTP is displayed together on the user authentication OTP posting screen, so that the service is provided by the true service principal before the user inputs the OTP value for user authentication.
  • the OTP generator will be described based on the software OTP generator installed in the form of an application program on the user's own mobile device, but is not necessarily limited thereto.
  • the OTP generator may be a hardware OTP generator with a communication function.
  • embodiments of the present invention will be described assuming the former case for convenience and concentration of description.
  • a description will be given on the assumption that a client terminal, which is an access terminal accessing an online service server, and an OTP generator are physically separately configured with reference to FIG. 1, but the OTP generator may be implemented integrally with the client terminal.
  • the mobile device shown in FIG. 1 will be omitted. It is also apparent that the client terminal itself may be a mobile device.
  • FIG. 1 is a view for explaining a method and system for mutual authentication between an online service server and a service user according to an embodiment of the present invention.
  • 2 is a block diagram of an embodiment of an OTP authentication server implementing a mutual authentication method according to an embodiment of the present invention
  • FIG. 3 is an OTP generator implementing a mutual authentication method according to an embodiment of the present invention.
  • FIG. 4 is an example of an OTP posting screen displayed on an online service site by an online service server
  • FIG. 5 is an example of a screen on which a confirmation OTP and a user OTP generated by an OTP generator are displayed on a screen of a mobile device. .
  • FIG. 6 illustrates an example of a screen in which a user OTP is displayed through a screen of a mobile device in a time OTP generation method while the confirmation OTP is driven by a challenge & response generation method by the OTP generator.
  • a mutual authentication method and an authentication system according to an embodiment of the present invention will be described in detail with reference to FIGS. 2 to 6 with reference to FIG. 1.
  • step S1 of FIG. 1 when a user wants to use an online service by an online service site provided by the online service server 130, the service user requests an access to the online service server 130.
  • the online service to be used is an online banking service
  • the user may access a specific online service server that provides the online banking service (that is, a specific bank server that provides an online banking service).
  • the connection to the online service server 130 may be by a mobile connection through a mobile device 110 (for example, a smartphone, etc.) owned by the user, but in FIG. 1, the user owned mobile device ( The case of connecting via a client terminal 100 (for example, a company PC, etc.) separate from 110 is illustrated.
  • the online service server 130 may request a service user who wants to use the online service to input user account information.
  • the user account information refers to identification information of the corresponding user previously stored (registered) in the online service server 130 through a user registration procedure (or a service subscription procedure).
  • a user ID and a password may be used as the user account information.
  • the information can identify the user using the online service, a variety of information (for example, the user's e-mail address, telephone number, certificate password on the certificate based on the PKI (Public Key Infrastructure)) in addition to the user account information Etc.) may be used alternatively.
  • PKI Public Key Infrastructure
  • the service user in response to a request for inputting user account information, the service user inputs user account information into a corresponding online service site.
  • the online service server 130 checks whether an account matching the user account information input from the user exists.
  • the account DB 140 as shown in FIG. 1 may be utilized to confirm such account information.
  • the account DB 140 stores account information about users (ie, members) who can receive the online service through the online service server 130.
  • FIG. 1 illustrates the case where the account DB 140 is provided separately from the online service server 130, the account DB 140 may be integrated with the online service server 130.
  • the account DB 140 may be implemented integrated with the OTP authentication server 150.
  • the online service server 130 when the input user account information matches the user account stored in the account DB 140, the online service server 130 generates the OTP for server verification by the OTP authentication server 150. Ask.
  • the server verification OTP is used for the purpose of allowing the user to determine whether the online service site to which the user is currently connected is provided by a true online service provider.
  • this step (ie, step S5) is shown to be executed immediately after the previous user account verification procedure (ie, step S4) is completed, but may of course be different.
  • the request for generating the server verification OTP according to this step may be executed only when the user selects the OTP authentication method as the authentication means after the user account verification procedure is completed.
  • FIG. 1 illustrates the case where the online service server 130 makes a request for generating a server verification OTP to the OTP authentication server 150
  • the online service server 130 may be different.
  • the service user side may request the generation of the server verification OTP to the OTP authentication server 150.
  • a more detailed implementation manner may be described as follows.
  • the user transmits an OTP generation request for server verification to the OTP authentication server 150 through the OTP generator 120 installed in the mobile device 110 of the user. Method may be used.
  • the server verification OTP generation request will be described with reference to FIG. 1 shown as being transmitted from the online service server 130 to the OTP authentication server 150.
  • the request for generating the server verification OTP as described above is received (received) through the communication interface unit 151 of the OTP authentication server 150.
  • the OTP authentication server 150 in response to a request for generating the server verification OTP from the online service server 130, the OTP authentication server 150 generates the server verification OTP. At this time, the generation of the server verification OTP may be performed by the server verification OTP generation unit 153 of the OTP authentication server 150.
  • the server verification OTP generation unit 153 of the OTP authentication server 150 may be performed by the server verification OTP generation unit 153 of the OTP authentication server 150.
  • a fixed key pre-registered corresponding to user account information of a service user may be used as an OTP generation key to be used as a seed value for OTP generation.
  • the fixed key corresponding to the user account information may be used by pre-registering any one or at least two combinations of various user identification information such as the above-described user ID, password, user's email address, phone number, certificate password, and the like. Can be.
  • the fixed key corresponding to the user account information may be a phone number, a product serial number, a USIM card number, a MAC address, or the like of a mobile device owned by the user (for example, a smartphone). Any one or at least two combinations of identifiers may be pre-registered and used.
  • the fixed key corresponding to the user account information may be a private key that the user directly selects and registers when the user registers with the OTP authentication service or is assigned at the time of registering the OTP authentication service.
  • the OTP generation key to be used as a seed value for OTP generation may be a pre-registered fixed key corresponding to identification information of the true online service server to which the user wants to access.
  • the server IP address (which may be all or part of the IP address) of the online service server may be used as the OTP generation key.
  • a dynamic allocation key dynamically allocated when a user accesses the online service server may be used.
  • connection information of a service user accessing the online service server may be used.
  • the connection information of the connection terminal may include session information (for example, session ID) or socket information (for example, socket) that the online service server allocates to the service user when the service user is connected.
  • Handles (such as a socket handle) may be used.
  • the session ID is a value assigned by the server to manage continuous data transmission and reception between the server and the access terminal
  • the socket handle information is a socket for managing data, a unit for transmitting and receiving data through the network between the server and the access terminal. Any connection unique value assigned by the server itself.
  • Such session ID or socket handle information is dynamically assigned as well as a value assigned by the server itself. Therefore, the session ID or the socket handle information is advantageously secured when used as an OTP generation key because it is difficult to be stolen by a hacker from outside the server.
  • a mobile IP address (which may be all or part of an IP address) dynamically allocated by a mobile communication company may be used for a mobile device owned by a service user. For example, assuming that a service user accesses the online service server through his mobile device, the mobile IP address dynamically allocated by the mobile carrier may be used as the OTP generation key.
  • the mutual authentication method between the online service server and the service user according to an embodiment of the present invention is characterized in that the server verification OTP and the user OTP are generated to be paired with each other. Therefore, the OTP generation key can be used in various alternative ways as long as the two OTP values can be paired with each other.
  • the server verification OTP may be generated by using a specific operation condition while using the aforementioned OTP generation key.
  • the calculation conditions to be applied will be described together in step S10 to be described later. Through this, it will be clearly understood that the server verification OTP and the user OTP are generated as the value of the paired relationship with each other.
  • the OTP authentication server 150 has a corresponding OTP generation condition through the communication interface unit 151. To be transmitted to the OTP generator 120 installed in.
  • step S7 the transmission of the OTP generation condition of step S7 is illustrated as being performed through the push server 160.
  • the transmission of the OTP generation condition in step S7 is not necessarily the same, and may be transmitted directly from the OTP authentication server 150 to the OTP generator 120.
  • FIG. 1 illustrates a case of transmitting an OTP generation condition through a push message
  • transmission of the OTP generation condition may be based on a socket transmission method.
  • the OTP authentication server 150 transmits the OTP generation condition to the push server 160, and the push server 160 transmits the OTP generation condition through a push message. May be sent to the OTP generator 120.
  • the push message may be a message service provided for each app in a specific mobile operating system.
  • the transmission of the OTP generation condition does not necessarily need to be based on a push message, and may be based on various commercially available messaging services such as SMS and MMS, or by a specific communication protocol.
  • the push server 160 described above may be replaced by its functionality as a general communication server.
  • FIG. 1 illustrates the case where the OTP generation condition is directly transmitted to the OTP generator 120, it is not necessarily the same.
  • the OTP generation condition is transmitted to the mobile device 110 through a push message, and the OTP generator 120 may read the OTP generation condition and receive (acquire) the OTP generation condition.
  • the reception of the OTP generating condition may be made by the OTP generating condition receiving unit 121 of the OTP generator 120.
  • the OTP generation condition transmitted to the OTP generator 120 may be OTP calculation condition and / or OTP generation key information.
  • OTP generation key information may be OTP calculation condition and / or OTP generation key information.
  • the OTP authentication server 150 transmits the server verification OTP generated through the previous step S6 to the online service server 130 through the communication interface unit 151.
  • step S7 and step S8 may be performed at the same time, or may be performed in different ways. The same applies to the steps S9 and S10 described later.
  • the online service server 130 posts the delivered server verification OTP on the OTP post screen of the online service site, and the user OTP through the same screen. Ask for input.
  • An example of this is shown in FIG. 4.
  • the OTP posting screen 10 includes an OTP input window 10B for requesting input of a user OTP at the bottom adjacent to an OTP display window 10A where an OTP for server verification is posted (expressed) at the top, And a confirmation button 10C.
  • the OTP display window 10A in which the OTP for server verification is posted and the OTP input window 10B in which the user OTP is input are different from each other in color, form, etc. to enable immediate cognitive distinction by the service user. ) Can be expressed within.
  • the OTP display window 10A gives an orange shading effect in the display window
  • the OTP input window 10B gives a yellow shading effect in the display window, so that the OTP display window 10A and the OTP input window 10B can be visually distinguished. Can be.
  • step S10 the display window (see 20A of FIG. 5) and the user OTP of the confirmation OTP (OTP corresponding to the server verification OTP) to be displayed on the screen of the user's mobile device.
  • the display window (see 20B of FIG. 5) may also be displayed by applying the same effect as the cognitive discrimination effect applied to the OTP display window 10A and the OTP input window 10B displayed in the OTP posting screen 10.
  • the service user can intuitively understand the use of the server verification OTP and the user OTP without any difficulty. That is, the service user can intuitively find the display window (see 20A in FIG. 5) on the mobile device screen to which the same cognitive discrimination effect is applied as the OTP display window 10A in the OTP posting screen 10, and post to each display window. By confirming the coincidence between the number (that is, server verification OTP and verification OTP value), it is possible to immediately determine the authenticity of the online service server.
  • the service user can intuitively find the display window (see 20B in FIG. 5) on the mobile device screen to which the same cognitive discrimination effect is applied as the OTP input window 10B in the OTP posting screen 10. In the case of FIG. 5, a number (ie, a user OTP value) posted in 20B may be intuitively input to the OTP input window 10B in the OTP posting screen 10.
  • the OTP generator 120 generates the confirmation OTP through the confirmation OTP generator 123 and the user OTP generator 125. Create a user OTP.
  • the OTP for confirmation corresponds to the server verification OTP generated by the OTP authentication server 150 and posted on the OTP posting screen (see reference numeral 10 in FIG. 3) on the online service site of the online service server 130. , OTP value generated by the OTP generator 120. Therefore, when the verification OTP and the server verification OTP posted on the OTP posting screen 10 coincide, the service user can determine that the online service server is the true service server (that is, the authenticity of the service server).
  • the generation of the confirmation OTP and the user OTP may be in the following manner.
  • the confirmation OTP and the user OTP generated by the OTP generator 120 have a pairing value. This can be realized by using the same OTP generation key value during the OTP generation process, but generating the OTP by applying different operation conditions.
  • this will be described in detail.
  • the verification OTP uses the aforementioned various OTP generation keys as seed values, but generates a challenge & response generation method, and the user OTP (or corresponding OTP) is generated.
  • the same OTP generation key as the seed value but generating by the time OTP generation method, different operation conditions can be applied to each other.
  • FIG. 6 An example of this is shown in FIG. 6. Referring to (a) and (b) of FIG. 6, the confirmation OTP (refer to the service OTP of FIG. 6) displayed on the user's mobile device screen is generated in a challenge and response manner so that the same value is used regardless of time change. However, since the user OTP is generated by the time OTP method, it can be confirmed that the value is changed after the effective time elapses.
  • the challenge and response method is a method of generating an OTP using the number of attempts as an operation condition. Accordingly, the OTP may be generated as an encrypted value according to a specific hash function by multiplying the determined specific OTP generation key by the number of attempts, which is an operation condition.
  • the time OTP method is a method of generating the OTP using the generation time as an operation condition. Accordingly, the OTP may be generated as an encrypted value according to a specific hash function by multiplying the determined specific OTP generation key by the generation time which is an operation condition.
  • the OTP authentication server 150 is an OTP generation condition used when generating the OTP for server verification through the previous step S7.
  • the OTP authentication server 150 uses the OTP generator (the number of attempts as the operation condition according to the challenge and response method). 120).
  • the OTP generation key used to generate the OTP for server verification does not necessarily need to be transmitted to the OTP generator 120.
  • the fixed key described above through step S6 is utilized as the OTP generation key, the fixed key may be configured to be stored in advance in a key storage unit (not shown) of the OTP generator 120 and may be directly used. In this case, only step S7 may be transmitted.
  • a dynamic allocation key eg, session ID, etc.
  • the OTP generation key may be transmitted to the OTP generator 120 through step S7 together with the operation condition.
  • the confirmation OTP generation unit 123 of the OTP generator 120 may generate the confirmation OTP having the same value as the server verification OTP generated by the OTP authentication server 150 based on the received OTP generation condition. Can be.
  • the user OTP generation unit 125 of the OTP generator 120 may generate a user OTP using the same generation key as the OTP generation key used to generate the confirmation OTP, but using the generation time as an operation condition.
  • the generation time to be used as an operation condition of the user OTP generation may be transmitted from the OTP authentication server 150 to the OTP generator 120 through the previous step S7. Accordingly, the confirmation OTP and the user OTP generated by the OTP generator 120 may be generated based on the same OTP generation key but paired according to different operation conditions.
  • the case where the identification OTP and the user OTP are generated by the same OTP generation key but under different operation conditions has a pairing value with each other.
  • the confirmation OTP and the user OTP may be generated as values that are paired with each other by applying the same operation condition using different OTP generation keys.
  • it will be described with respect to the former case.
  • the confirmation OTP and the user OTP generated according to the above-described scheme may be displayed on the screen of the mobile device 110 by the OTP display unit 127 of the OTP generator 120.
  • An example of the display of the screen is illustrated in FIG. 5.
  • the confirmation OTP is displayed on the screen of the mobile device through the display window 20A, and the user OTP is displayed side by side on the same screen through the display window 20B (that is, visually paired with each other. To be expressed).
  • the service user compares the server verification OTP posted on the OTP display window 10A of the OTP posting screen shown in FIG. 4 and the confirmation OTP posted on the left display window 20A of FIG. Thus, the authenticity of the site can be determined.
  • the service user may input the user OTP value posted in the right display window 20B of FIG. 5 into the OTP input window 10B of the OTP posting screen of FIG. 4 (see step S11 of FIG. 1).
  • the OTP authentication server 150 posts an OTP for a user OTP input valid time (for example, 60 seconds) or until a user OTP input is made according to an attempt to access the online service server 130 by a service user.
  • the OTP value for server verification posted on the OTP display window 10A of the screen can be maintained as it is. That is, before the user OTP input validity time elapses or before the user OTP input is made, a subordinated connection using the same account information as the user account information of the service user is retried (for example, by a true user). Even if an additional connection by a hacker is attempted after the connection), the OTP authentication server 150 may maintain the existing OTP value without generating a new server verification OTP. According to this, it is possible to prevent illegal user authentication and information deprivation by the hackers due to subordinated access.
  • the case where the verification OTP (or the server verification OTP) and the user OTP (or the corresponding OTP) are generated in different operation conditions by using a challenge and response method and a time OTP method, respectively, has a value that is paired with each other.
  • the foregoing description is only an example and may be generated as a value that is paired with each other by another method.
  • the OTP generation key and the OTP generation method may be the same, but may have values paired with each other by applying different mode identifiers as operation conditions.
  • Both of the session IDs (that is, the OTP for verification and the user OTP, or the server verification OTP and the corresponding OTP) are used as the OTP generation key, and both are generated by the time OTP method.
  • the OTP generation key as the seed value of the OTP generation is the same, but by applying one or more different operation conditions, within the limit to be generated as a value that is mutually paired, there can be more various modifications in addition, All of these will be encompassed in the embodiments of the present invention.
  • the OTP input window is displayed on the OTP posting screen, and the method of directly inputting the user OTP to the OTP input window is described.
  • this is not necessarily the case.
  • only OTP for server verification may be posted on the OTP post screen, and an OTP input window for user OTP input may not be separately posted.
  • the user OTP is not directly input by the service user, but may be substituted for input through a specific gesture.
  • the user simply selects the user OTP expressed through the touch screen of the mobile device, and touches the screen upwards. By taking various gestures, such as, the user OTP may be automatically input.
  • the online service server 130 may request confirmation of the user OTP value input to the OTP authentication server 150 (that is, request for user authentication) (see FIG. 1). See step S12].
  • the corresponding OTP generating unit 155 of the OTP authentication server 150 applies the same conditions as the user OTP generated by the OTP generator 120 in step S10.
  • Create The authentication processing unit 157 of the OTP authentication server 150 may perform user authentication on the corresponding service user by comparing the generated OTP with the input user OTP.
  • the authentication result is notified to the online service server 130 (see step S14 of FIG. 1), and if authentication is normally performed, the online service server 130 may start the corresponding service to the corresponding service user [FIG. 1]. See step S15].
  • FIG. 7 is a diagram for explaining a mutual authentication method using OTP according to another embodiment of the present invention
  • FIG. 8 is an example of displaying a screen on a mobile device according to FIG. 7.
  • FIG. 7 is a mutual authentication method according to an embodiment of the present invention in proceeding with a payment service using a payment app 120A installed in a mobile device owned by a user when the online service server, which is a service verification target, is specialized as a payment server 130A.
  • the verification module 120B performs essentially the same or similar function as the OTP generator 120 of FIG. 1 described above.
  • the verification module 120B may be implemented as a separate app, but may also be implemented together in the payment app 120A as a part of the payment app 120A. Accordingly, in this example, the payment app 120A and the verification module 120B are implemented as one application program (see AA in FIG. 7) to the user-owned mobile device (see 110 in FIG. 1). Assume it is installed.
  • the payment app 120A may extract the user serial from the verification module 120B according to step S2 of FIG. 7, and request the server verification OTP to the payment server 130A according to step S3 of FIG. 7. .
  • the user serial may be a user unique value used when the payment app 120A and the verification module 120B are registered with the OTP authentication server 150A as one app. This user serial may be transmitted to the payment server 130A together with the OTP request for server verification. This will be described below with reference to this.
  • the payment server 130A forwards it to the OTP authentication server [see step S4 of FIG. 7], and accordingly, the OTP authentication server 150A generates the OTP for server verification. (See step S5 of FIG. 7).
  • the private key may use a predetermined key value stored corresponding to the corresponding user identified by the user serial, and in some cases, the user serial value may be used as it is.
  • the OTP authentication server 150A uses the IP address of the payment server 130A from the payment server 130A and the session ID assigned for communication connection with the payment app 130A to generate the OTP for server verification. I need to get it.
  • the IP address and session ID of the payment server 130A may be transferred from the payment server 130A to the OTP authentication server 150A through step S4 of FIG. 7.
  • the OTP authentication server 150A may transmit the OTP generation condition used to generate the OTP for server verification to the verification module 120B (see step S6 of FIG. 7).
  • the method of transmitting the OTP generation condition from the OTP authentication server 150A to the verification module 130B is essentially the same as in step S7 of FIG. 1, which will be omitted. That is, although the push server 160 and the like of FIG. 1 are not directly illustrated in FIG. 7, this step may be based on the same method as in step S7 of FIG. 1.
  • the OTP authentication server 150A delivers the server verification OTP generated in accordance with step S5 of FIG. 7 to the payment server 130A (see step S7 in FIG. 7), and the payment server 130A is used for server verification.
  • the OTP may be sent to the payment app 120A (see step S8 of FIG. 7).
  • the payment app 120A may transmit the received server verification OTP to the verification module 120B (see step S9 of FIG. 7).
  • the server verification OTP generated by the OTP authentication server 150A does not necessarily need to be delivered to the verification module 120B through the steps S7, S8, and S9.
  • the server verification OTP may be transmitted together during the transmission of the OTP generation condition according to step S6. In the present specification, for convenience and concentration of description, the description will be made based on the case of the former method.
  • the verification module 120B generates the verification OTP corresponding to the server verification OTP by referring to the OTP generation condition received through the previous step S6, and the server verification OTP received by the step S9 and the verification generated by itself.
  • Server verification can be performed by comparing the agreement between the OTPs for each server (see step S10 of FIG. 7).
  • the verification module 120B may generate a user OTP according to a predetermined method (see step S11 of FIG. 7), and deliver the generated user OTP to the payment app 120A. (See step S12 in FIG. 7). At this time, the delivered user OTP may be transmitted from the payment app 120A to the payment server 130A (see step S13 of FIG. 7), and then again to the OTP authentication server 150A (see step S14 of FIG. 7). .
  • various methods described above with reference to FIGS. 1 to 6 may also be applied to the method of generating a user OTP in the verification module 120B.
  • the private key and session ID used as the seed value of the OTP for server verification are used as the seed value of the user OTP generation, but the private IP address of the mobile device where the verification module 120B is installed is added as the seed value.
  • the user OTP is generated by applying the time OTP method. That is, in this example, the user OTP and the server verification OTP utilize the private key and the session ID as the same generation keys, but in the process of generating the server verification OTP, the OTP is generated using the challenge and response method using the server IP address as an additional seed value.
  • the OTP may be generated as a time OTP method using the mobile IP address as an additional cis value, and thus the OTP may be generated as a paired value.
  • the mutual authentication method there is no restriction that a user OTP and a server verification OTP are paired with each other according to a system implementation method.
  • the OTP authentication server 150A When a user OTP verification request is received according to step S14 of FIG. 7, the OTP authentication server 150A generates a corresponding OTP corresponding to the received user OTP under the same creation condition as in step S11 of FIG. 7, and receives the received user OTP. And user authentication are performed by comparing the corresponding OTP with a corresponding OTP generated (see step S15 of FIG. 7). At this time, the user authentication result is transmitted to the payment server 130A [see step S16 of FIG. 7]. If the user accessing the service is determined to be a legitimate user according to the authentication result, the payment server 130A proceeds with the corresponding service [ See step S17 of FIG. 7]. A payment app screen displayed through a screen of a mobile device owned by a user in a state where user authentication is completed is illustrated in FIG. 8B.
  • FIGS. 8A and 8B it can be seen that the screen display method is different from those of FIGS. 5 and 6 described above.
  • the server verification OTP and the user OTP are not displayed through the service site screen and the app screen. That is, according to the embodiment of FIG. 7, the server verification OTP and the user OTP are used only for mutual authentication performed internally without being exposed to the user. Therefore, after the user inputs a PIN number according to step S1 of FIG. 7 (see FIG. 8A), a series of processes of steps S2 to S16 of FIG. 7 are processed internally by the system, and the series of processes According to the mutual authentication is completed, the service start screen of Figure 8 (b) will be immediately displayed on the app screen.
  • the user after verifying the server verification OTP presented by the server through the screen for inputting the OTP value for user authentication, the user inputs the OTP value for user authentication, thereby verifying the verification of the service providing server.
  • User authentication can be performed at the same time.
  • the present embodiment relates to an authentication method and system, and more particularly, to a method and system for mutual authentication between an online service server and a client.
  • the conventional additional authentication means requires a user to input a one-time password generated between the online service and the authentication medium or input a separate biometric information.
  • a user if you need to re-enter a four- to six-digit temporary password with your mobile phone, it is difficult to know the number that is confirmed on the mobile phone screen, and it is also complicated to enter.
  • Another simple authentication method is a mobile push when a user enters an ID and password into an online service with a connection control app installed to determine whether to approve access to a user's designated mobile phone in advance to minimize user input.
  • the hacker's site is a pharmed hacker's site
  • the hacker sends the username and password entered by the hacker back to the actual online service. When you come back, you will be misunderstood as your connection and you will have to approve the connection.
  • the user misunderstands the final connection that arrives at his smartphone as his own It can also be approved.
  • the user when performing two-factor authentication (that is, mutual authentication based on service authentication and user authentication) for the safe use of the online service, the user is determined whether the user is a correct service without inputting a separate one-time password or biometric information. It provides a method and system for simple authentication to ensure that the connection can proceed conveniently after checking.
  • the simple authenticator will be described based on the case of a software-type authentication device installed in the form of an application program on a mobile device owned by a user, but is not necessarily limited thereto.
  • the simple authenticator may be a hardware authentication device with a communication function.
  • embodiments of the present invention will be described assuming the former case for convenience and concentration of description.
  • a client terminal which is an access terminal accessing an online service server, and a simple authenticator are physically separately configured with reference to FIG. 9, but the simple authenticator may be implemented integrally with the client terminal.
  • the mobile device shown in FIG. 9 will be omitted. It is also apparent that the client terminal itself may be a mobile device.
  • FIG. 9 is a view for explaining a method and system for mutual authentication between an online service server and a service user according to an embodiment of the present invention.
  • 10 is a block diagram of an embodiment of an authentication server implementing a mutual authentication method according to an embodiment of the present invention
  • FIG. 11 is a simple authenticator implementing a mutual authentication method according to an embodiment of the present invention.
  • a method and a system for mutual authentication according to an embodiment of the present invention will be described with reference to FIGS. 10 and 11 with reference to FIG. 9.
  • FIG. 12 is an example related to a screen on which a simple authentication number is posted on an online service site operated by an online service server
  • FIG. 13 is an example related to a screen on which a verification authentication number generated by a simple authenticator is displayed.
  • FIG. 14 is a view illustrating a processing method when a connection attempt is made by a hacker in the authentication process according to the mutual authentication method of FIG. 9, and
  • FIG. 15 is an online service operated by an online service server when an attempt is made by a hacker as shown in FIG. 14. It is a figure which illustrates the processing result posted to a service site.
  • 16 and 17 are exemplary implementations of a mutual authentication method according to an embodiment of the present invention when a user accesses an online service server through a mobile device.
  • step S1 of FIG. 9 when a user wants to use an online service by an online service site provided by the online service server 230, the service user requests an access to the online service server 230.
  • the online service to be used is an online banking service
  • the user may access a specific online service server that provides the online banking service (that is, a specific bank server that provides an online banking service).
  • the connection to the online service server 230 may be by a mobile connection through a mobile device 210 (for example, a smartphone, etc.) owned by the user.
  • a mobile device 210 for example, a smartphone, etc.
  • FIG. 9 the user owned mobile device ( An example of connecting via a separate client terminal 200 (for example, a company PC) from 210 is illustrated.
  • the online service server 230 may request a service user who wants to use the online service to input user account information.
  • the user account information refers to identification information of the corresponding user previously stored (registered) in the online service server 230 through a user registration procedure (or a service subscription procedure).
  • a user ID and a password may be used as the user account information.
  • the information can identify the user using the online service, a variety of information (for example, the user's e-mail address, telephone number, certificate password on the certificate based on the PKI (Public Key Infrastructure)) in addition to the user account information Etc.) may be used alternatively.
  • PKI Public Key Infrastructure
  • the service user in response to a request for inputting user account information, the service user inputs user account information into a corresponding online service site.
  • the online service server 230 checks whether an account matching the user account information input from the user exists.
  • the account DB 240 as shown in FIG. 9 may be used to confirm such account information.
  • the account DB 240 stores account information regarding users (ie, members) who can receive the online service through the corresponding online service server 230.
  • the account DB 240 is provided separately from the online service server 230, but the account DB 240 may be integrated with the online service server 230.
  • the account DB 240 may be implemented integrated with the authentication server 250.
  • the online service server 230 requests the authentication server 250 to generate a simple authentication number.
  • the simple authentication number is used for the purpose of allowing the user to determine whether the online service site to which the user is currently connected is provided by a true online service provider.
  • step S5 of FIG. 9 when the online service server 230 makes a request for generating a simple authentication number to the authentication server 250, the online service server 230 together with the user account information of the corresponding service user is authenticated 250. ) Can be sent.
  • the online service server 230 may transmit a simple authentication number generation request including the user ID of the corresponding user as user account information to the authorization server 250.
  • the online service server 230 may further transmit the client connection environment information to the authentication server 250 through step S5 of FIG. 9 (or through a separate step).
  • the client connection environment information collectively refers to information that can directly or indirectly indicate a connection environment of a connection terminal of a corresponding service user connected to the online service server 230.
  • the client connection environment information may vary depending on the service server.
  • various Server Variables can extract the value of the connected client terminal.
  • IP address HTTP_X_FORWARDED_FOR
  • current IP address REMOTE_ADDR
  • client browser HTTP_USER_AGENT
  • client language HTTP_ACCEPT_LANGUAGE
  • variables of the service server that provides services to the client terminal (server host name, server IP, session ID, Session maximum validity time, etc.).
  • the connecting client is a client program instead of a standard web browser
  • various system variables Mac Address, HDD UUID, etc.
  • OS operating system
  • the request for generating the simple authentication number as described above is received (received) through the communication interface unit 251 of the authentication server 250, and the user account information and / or the client connection environment information transmitted together are included in the simple authentication number. It can be used as a seed for generation.
  • the authentication server 250 in response to a request for generating a simple authentication number from the online service server 230, the authentication server 250 generates a simple authentication number. At this time, the generation of the simple authentication number may be performed by the simple authentication number generation unit 253 of the authentication server 250.
  • the simple authentication number can be generated by using the client connection environment information transmitted from the online service server 230, which has been described above.
  • the client connection environment information is used or replaced with the client connection environment information.
  • a seed key for generating a simple authentication number may be a pre-registered fixed key corresponding to user account information of a service user.
  • the fixed key corresponding to the user account information may be used by pre-registering any one or at least 10 combinations of various user identification information such as the above-described user ID, password, user's email address, phone number, certificate password, and the like. Can be.
  • the fixed key corresponding to the user account information may be a phone number, a product serial number, a USIM card number, a MAC address, or the like of a mobile device owned by the user (for example, a smartphone). Any one or at least ten combinations of identifiers may be pre-registered and used.
  • the private key corresponding to the user account information may use a private key that the user directly selects and registers when registering to the simple authentication service or is assigned at the time of simple authentication service registration.
  • a dynamic allocation key dynamically allocated when a user accesses a corresponding online service server may be used.
  • connection information of a service user accessing the online service server may be used.
  • the connection information of the connection terminal may include session information (for example, session ID) or socket information (for example, socket) that the online service server allocates to the service user when the service user is connected.
  • Handles (such as a socket handle) may be used.
  • the session ID is a value assigned by the server to manage continuous data transmission and reception between the server and the access terminal
  • the socket handle information is a socket for managing data, a unit for transmitting and receiving data through the network between the server and the access terminal. Any connection unique value assigned by the server itself.
  • Such session ID or socket handle information is dynamically assigned as well as a value assigned by the server itself. Therefore, the session ID or the socket handle information is difficult to be stolen by a hacker from outside the server.
  • a mobile IP address (which may be all or part of an IP address) dynamically allocated by a mobile carrier may be used for a mobile device owned by a service user. For example, assuming that a service user accesses an online service server through his mobile device, a mobile IP address dynamically allocated by a mobile carrier may be used as a seed value.
  • a random value generated by the authentication server 250 may be used as a seed value for generating a simple authentication number.
  • the simple authentication number generation unit 253 of the authentication server 250 uses at least one of the seed values as described above, using the time or the number of attempts (that is, the number of attempts to issue the simple authentication number) as an operation condition. You can create a simple authentication number.
  • the simple authentication number generation unit 253 may generate a value obtained by encrypting a value obtained by multiplying the at least one seed value by a time or the number of attempts according to a specific hash function. Accordingly, the simple authentication number can be generated as a value having a one-time.
  • the time OTP method is a method of generating the OTP using the generation time as an operation condition. Accordingly, the OTP may be generated as an encrypted value according to a specific hash function by multiplying the determined specific OTP generation key by the generation time which is an operation condition.
  • the authentication server 250 transmits the simple authentication number generated through the previous step S6 to the online service server 230 through the communication interface 251.
  • the delivered simple authentication number is posted for the user to check through the screen of the online service site operated by the online service server 230 according to step S9 of FIG. 9.
  • An example of this is shown in FIG. 12. Referring to FIG. 12, it can be seen that a simple authentication number (see reference numeral 30A of FIG. 12) is posted through an authentication number posting screen on the right side of an online banking site. After the simple authentication number is posted on the screen, the approval wait state may be maintained until confirmation from the user is completed (see step S10 of FIG. 9).
  • the authentication server 250 is configured to generate a simple authentication number through the communication interface unit 251 to the simple authenticator 220 installed in the mobile device 110 owned by the service user. To be transmitted.
  • the simple authentication number generation condition of step S8 is illustrated as being performed through the push server 260, but is not necessarily the same, and is directly transmitted from the authentication server 250 to the simple authenticator 220. Of course it can be.
  • FIG. 9 illustrates a case of transmitting a condition for generating a simple authentication number through a push message
  • transmission of the condition for generating a simple authentication number may be based on a transmission method using socket data communication.
  • the authentication server 250 transmits the generation condition to the push server 260, and the push server 260 performs the simple authentication number through a push message.
  • the generation condition may be transmitted to the simple authenticator 220.
  • the push message may be a message service provided for each app in a specific mobile operating system.
  • the transmission of the condition for generating the simple authentication number is not necessarily based on the push message, and may be by various commercial messaging services such as SMS and MMS, or by a specific communication protocol.
  • the above-described push server 260 may be replaced as a general communication server.
  • the condition for generating the simple authentication number has been described based on a case in which the simple authentication number is directly transmitted to the simple authenticator 220.
  • the simple authentication number generation condition is transmitted to the mobile device 210 through a push message and the like, and the simple authenticator 220 may read (receive) the simple authentication number generation condition by reading it. . Receiving such a simple authentication number generation conditions may be made by the communication interface unit 221 of the simple authenticator 220.
  • the above-mentioned simple authentication number generation condition to be transmitted through step S8 of FIG. 9 may be all of a seed value and an operation condition used to generate the simple authentication number in step S6 of FIG. 9, but may be a part thereof.
  • the authentication server 250 and the simple authenticator 220 stores in advance some of the seed values and calculation conditions used for generating the simple authentication number, and commonly used them, such pre-archive This is because the condition does not need to be transmitted separately.
  • the simple authenticator 220 may generate a verification authentication number for verifying the simple authentication number displayed through the online service site screen of the online service server 230 using the generated generation condition [FIG. 9, step S11.
  • the generation of the verification authentication number may be performed by the verification authentication number generation unit 223 of the simple authenticator 220.
  • the verification authentication number generated as described above may be displayed through the app screen of the mobile device 210 through the authentication number display unit 227 of the simple authenticator 220.
  • the verification authentication number see reference numeral 30B of FIG. 13
  • FIG. 13 an example in which the verification authentication number (see reference numeral 30B of FIG. 13) is expressed through the app screen is illustrated in FIG. 13.
  • Steps S7 to S11 described above are not necessarily limited to the order shown in FIG. 9, and may be different from each other or simultaneously.
  • the user compares the verification authentication number displayed in this way with the simple authentication number displayed through the online service site screen, so that the corresponding online service server is a true service. Determine the server (that is, the authenticity of the service server).
  • the user selects an approval button on the app screen shown in FIG. 13 to confirm the approval of the corresponding service (that is, the online service server is a true service server). Verification completion processing) (see step S12 in FIG. 9).
  • an approval button for performing an approval process for a corresponding service is provided at a lower end of a verification authentication number displayed on an app screen.
  • the approval or cancellation process for the service may be based on a specific gesture of the user. For example, if the user takes a touch gesture to push the app screen of the mobile device upwards, the user may approve it, and if the user takes a touch gesture to push down the mobile device, the user may approve the touch screen.
  • the additional verification value generator 225 of the simple authenticator 220 when the approval of the service is made, the additional verification value generator 225 of the simple authenticator 220 generates the additional verification value, and the authentication server 250 through the communication interface 221. (See step S12 and step S13 in Fig. 9).
  • the additional verification value is used as the purpose for user authentication. That is, in the embodiment of the present invention, after verifying the authenticity of the service through simple verification of the authentication number, a method of confirming whether the user who wants to use the service through the additional verification value is a legitimate user is used. .
  • the additional verification value for the user authentication is automatically generated by the simple authenticator 220 at the same time the approval process through the verification of the preceding simple authentication number is completed and immediately authenticated Is passed to the server 250. This eliminates the inconvenience of the user having to enter the user authentication value directly into the online service server in the user authentication process.
  • the additional verification value may be generated in various ways. Since the method of generating the additional verification value will not be essentially different from the methods of generating the simple authentication number described above, a detailed description thereof will be omitted. Of course, the generation of the additional verification value does not have to follow the method of generating the simple authentication number described above, and may be generated according to a predetermined condition defined by the system. The generation method will be similarly applied to generation of verification verification values (that is, verification values generated corresponding to the additional verification values) in the authentication server 250 to be described later. Therefore, when information not stored in the authentication server 250 is utilized in the process of generating the additional verification value, the corresponding information also needs to be transmitted to the authentication server 250 through step S13 of FIG. 9.
  • step S13 the transmission of the additional verification value according to step S13 is shown in Fig. 9 via the push server 260, it does not necessarily need to be, and may be transmitted directly to the authentication server 250 by any means. Do.
  • the verification verification value generation unit 255 of the authentication server 250 generates verification verification value for verifying the transmitted additional verification value, and the authentication processing unit 257 of the authentication server 250 is generated.
  • the user authentication may be performed for the corresponding service user by comparing the confirmation value between the verification verification value and the transmitted additional verification value (see step S14 of FIG. 9).
  • the authentication result is notified to the online service server 230 (see step S15 of FIG. 9), and if authentication is normally performed, the online service server 230 may start the corresponding service to the corresponding service user [FIG. 9. See step S16].
  • the user authentication number input process may be omitted, so that the entire authentication procedure Has the effect of being concise and convenient.
  • step S12 of FIG. 9 the simple authenticator 220 may notify the disapproval of approval through step S13 of FIG. 9.
  • the authentication server 250 since the authentication server 250 generates a simple authentication number according to an attempt to access an online service server by a service user, a verification valid time (for example, 60 seconds) or until the service verification by the user is completed, the generated simple authentication number can be kept as it is. This will be described with reference to FIG. 14 as follows.
  • the authentication server 250 maintains the simple authentication number generated according to the prior access or the simple authentication according to the subordinate access until the verification valid time of the simple authentication number or until the verification on the online service server is completed. New generation of numbers can be prohibited.
  • Such a subordinate accessor may display a screen (refer to reference numeral 30C of FIG. 15) indicating that duplicate access is not possible through the screen of the online service site as shown in FIG. 15. According to this, it is possible to prevent illegal user authentication and information deprivation by the hackers due to subordinated access.
  • the simple authentication number and the verification authentication number may be expressed through the screen of the mobile device as shown in FIGS. 16 and 17.
  • FIGS. 16 and 17 an app screen by the simple authenticator 220 is displayed on the top 40A of the screen of the mobile device, and the site screen provided by the online service server 230 is the bottom screen 40B of the mobile device. It is expressed in.
  • the simple authentication number 40C is displayed on the screen portion 40B.
  • the verification authentication number 40D generated by the simple authenticator 220 is displayed on the upper end portion 40A of the screen.
  • the app screen by the simple authenticator and the site screen by the online service server may be separated and displayed in different screen areas.
  • 16 and 17 illustrate an example in which an app screen is displayed in a form of being floated on the top of a site screen (that is, a screen of a layered type).
  • various methods may be applied to the screen division method. Of course.
  • the user after the user enters the ID and password into the online service, if the simple authentication number provided by the service for the additional authentication and the simple authentication number provided by the mobile simple authenticator are the same, the user approves access to the service. Eliminate unnecessary re-entry of user authentication number.
  • the user who has the simple authenticator may know that the user has requested access permission by someone other than the user. Security management of passwords is also possible.
  • the present embodiment relates to a user authentication method and system, and more particularly, to an authentication method and system for authenticating a user by using one time password (OTP) generated by using connection information of an access terminal.
  • OTP one time password
  • the hacker attacks the screen scraping software that allows a hacker to read the screen remotely from the OTP value generated by the smart phone by a normal user, or smart from a distance. If you read the phone screen and input it first on the hacker's terminal, you can browse the information of the system or intercept important transactions such as transfer of funds.
  • the conventional security technology cannot prevent the screen from being read by the human eye or the barcode reader, so if the screen generated by the OPT generator app is stolen by a hacker within the OTP input validity time, there is a problem that cannot be prevented. .
  • the prior art related to the OTP and the session is to use the OTP value for authenticating the session accessed by the user terminal, not the technical structure for authenticating different OTP value for each connected terminal.
  • the present embodiment provides a method and system for generating an OTP using connection information of an access terminal accessing a corresponding service in order to safely use an information service such as online banking, and making the OTP valid only in a connected access terminal.
  • the OTP generator will be described based on the software OTP generator installed in the form of an application program on the user's own mobile device, but is not necessarily limited thereto.
  • the OTP generator may be a hardware OTP generator with a communication function.
  • embodiments of the present invention will be described assuming the former case for convenience and concentration of description.
  • a description will be given on the assumption that a client terminal, which is an access terminal accessing an online service server, and an OTP generator are physically separately configured with reference to FIG. 18.
  • the OTP generator may be integrally implemented with the client terminal.
  • the mobile device shown in FIG. 18 will be omitted.
  • the client terminal itself may be a mobile device.
  • FIG. 18 is a view for explaining a user authentication method and authentication system according to an embodiment of the present invention.
  • 19 is a block diagram of an embodiment of an online service server related to a user authentication method according to an embodiment of the present invention
  • FIG. 20 is an embodiment of an OTP authentication server implementing a user authentication method according to an embodiment of the present invention.
  • 21 is a block diagram of an example, and FIG. 21 is a block diagram of an embodiment of an OTP generator implementing a user authentication method according to an embodiment of the present invention.
  • step S1 of FIG. 18 when a user wants to use an online service by an online service site provided by the online service server 330, the service user requests an access to the online service server 330.
  • the online service to be used is an online banking service
  • the user may access a specific online service server that provides the online banking service (that is, a specific bank server that provides an online banking service).
  • the connection to the online service server 330 may be by a mobile connection through a mobile device 310 (for example, a smartphone, etc.) owned by the user, but in FIG. 18, the user owned mobile device ( The case of connecting via a client terminal 300 (for example, a company PC, etc.) separate from 310 is illustrated.
  • the online service server 330 may request a service user who wants to use the online service to input user account information.
  • the user account information refers to identification information of the corresponding user previously stored (registered) in the online service server 330 through a user registration procedure (or a service subscription procedure).
  • a user ID and a password may be used as the user account information.
  • the information can identify the user using the online service, a variety of information (for example, the user's e-mail address, telephone number, certificate password on the certificate based on the PKI (Public Key Infrastructure)) in addition to the user account information Etc.) may be used alternatively.
  • PKI Public Key Infrastructure
  • the service user in response to a request for inputting user account information, the service user inputs user account information into a corresponding online service site.
  • the online service server 330 checks whether an account matching the user account information input from the user exists.
  • the account DB 340 as shown in FIG. 18 may be utilized to confirm such account information.
  • the account DB 340 stores account information regarding users (ie, members) who can receive the online service through the online service server 330.
  • the account DB 340 is provided separately from the online service server 330, but the account DB3140 may be integrated with the online service server 330.
  • the account DB 340 may be implemented integrated with the OTP authentication server 350.
  • the user account information checking procedure of step S4 of FIG. 18 may be executed after the user account information is transmitted to the OTP authentication server 350 according to step S5 of FIG. 18 to be described later.
  • an embodiment of the present invention will be described with reference to FIG. 18.
  • the online service server 330 may transmit the OTP authentication server 350 through the communication interface 331. ) Can transmit connection terminal connection information and user account information.
  • the connection information may be server-to-terminal connection information generated and managed by the online service server 330 to manage continuous data transmission and reception between them.
  • connection terminal connection information for example, session information (for example, session ID) or socket data allocated to the service user's connection terminal by the online service server when the service user is connected. Socket information (eg, socket handle information) in communication may be used. Such connection terminal connection information may be allocated by the connection information setting unit 333 of the online service server 330.
  • the session ID is a value assigned by the server to manage continuous data transmission and reception between the server and the access terminal
  • the socket handle information is a socket for managing data, a unit for transmitting and receiving data through the network between the server and the access terminal. Any connection unique value assigned by the server itself.
  • This session ID or socket handle information is dynamically assigned as well as assigned by the server itself, and is difficult to be stolen by hackers from outside the server. Therefore, when this is used as a seed value of OTP generation in the future, a security effect is advantageous. There is.
  • the user account information to be transmitted from the online service server 330 to the OTP authentication server 350 may be any one or part of the various user account information described above.
  • the online service server 330 may transmit only the ID of the service user as the user account information to the OTP authentication server 350.
  • the user account information is to be identified in the OTP authentication server 350 to identify the target (in FIG. 18, the mobile device 310 or OTP generator 320 owned by the service user) to transmit the access terminal connection information in the future. It is transmitted to the OTP authentication server 350 as a purpose. Therefore, the user account information to be transmitted according to this step may be variously modified as long as it can achieve its purpose.
  • this step (ie, step S5) is shown to be executed immediately after the previous user account verification procedure (ie, step S4) is completed, but may be different. For example, this step may be executed only when the user selects the OTP authentication method as the authentication means after the user account verification procedure is completed.
  • connection terminal connection information and the user account information transmitted as described above are received (received) through the communication interface unit 351 of the OTP authentication server 350.
  • the online service server 330 displays a user OTP input window through a screen of the online service site. You can ask the user to enter your OTP.
  • step S5 and step S6 of FIG. 18 may be executed at the same time, or may be executed in a different order from the order shown in FIG. 18.
  • step S6 of FIG. 18 and step S7 to be described later may also be executed at the same time, or may be executed in a different order from the order shown in FIG. 18.
  • the OTP authentication server 350 owns the service user connection information through the communication interface unit 351. To be transmitted to the OTP generator 320 installed in the mobile device 310.
  • step S7 of FIG. 18 the transmission of the connection information of the access terminal is illustrated as being performed through the push server 360.
  • the transmission terminal connection information is not necessarily the same, and may be transmitted directly from the OTP authentication server 350 to the OTP generator 320. Of course you can.
  • connection terminal connection information When the connection terminal connection information is transmitted through the push server 360, the OTP authentication server 350 transmits the connection terminal connection information to the push server 360, and the push server 360 accesses the connection terminal through a push message.
  • the connection information may be transmitted to the OTP generator 320.
  • the push message may be a message service provided for each app in a specific mobile operating system.
  • the transmission of the connection information of the access terminal does not necessarily need to be based on a push message, and may be by various commercial messaging services such as SMS and MMS, and a specific communication protocol (for example, socket data communication, etc.). ) Is also acceptable.
  • the push server 360 described above may be replaced by a general communication server.
  • FIG. 18 illustrates the case in which the access terminal connection information is directly transmitted to the OTP generator 320, this need not be the case.
  • the access terminal connection information is transmitted to the mobile device 310 through a push message and the like, and the OTP generator 320 can read (receive) the access terminal connection information.
  • the connection terminal connection information may be received by the connection terminal connection information receiver 321 of the OTP generator 320.
  • the OTP authentication server 350 is installed on the mobile device based on the user account information received from the online service server 330 The device value of the device 310 or the App push ID of the OTP generator 320 may be checked, and the access terminal connection information may be transmitted to the OTP generator 320 based on the confirmed device value or the app push ID.
  • the OTP authentication server 350 may transmit the access terminal connection information to the OTP generator 320 as a response to the request of the OTP generator 320. For example, when input of the user OTP is requested according to step S6 of FIG. 18, the service user who has recognized the request of the user OTP requests the transmission of the connection terminal connection information to the OTP authentication server 350 through the OTP generator 320. Accordingly, the OTP authentication server 350 may transmit the access terminal connection information to the OTP generator 320 as a response.
  • the OTP authentication server 350 may perform the OTP generator 320 based on the received user account information. Check the app push ID of the request, and transmits the connection information of the access terminal assigned to the mobile device 310, which is the access terminal on the online service server 330 based on the confirmed app push ID, according to the request.
  • the received connection terminal connection information may be transmitted to the OTP generator 320. That is, in this case, only the user account information is first transmitted in step S5 of FIG. 18, and the access terminal connection information is later transmitted according to the request of the OTP authentication server 350.
  • the OTP generator 320 when the access terminal connection information is transmitted to the OTP generator 320, the OTP generator 320 generates a user OTP in accordance with step S8 of FIG. In this case, the user OTP is generated using the transmitted connection terminal connection information, which may be executed by the user OTP generator 325 of the OTP generator 320.
  • the transmitted connection terminal connection information which may be executed by the user OTP generator 325 of the OTP generator 320.
  • the OTP generating unit 325 may generate the user OTP by using the received connection terminal connection information as a seed value and applying a specific operation condition (for example, the number of attempts, time, etc.). More specifically, the OTP generation unit 325 may generate a user OTP by encrypting a value obtained by multiplying the received connection terminal connection information by the above-described specific operation condition according to a specific hash function.
  • a specific operation condition for example, the number of attempts, time, etc.
  • the OTP generating unit 325 may generate a user OTP by adding another specific key value as a seed value in addition to the access terminal connection information.
  • the other specific key value may be a pre-registered private key corresponding to the user account information of the service user.
  • the private key corresponding to the user account information may be used by pre-registering any one or at least 19 combinations of various user identification information such as the above-described user ID, password, user's email address, phone number, certificate password, and the like. Can be.
  • the private key corresponding to the user account information may include a phone number, a product serial number, a USIM card number, a MAC address, and the like of a user-owned mobile device (for example, a smartphone). Any one or at least 19 combinations of identifiers may be pre-registered and used.
  • the private key corresponding to the user account information may be a private key that the user selects and registers when the user registers with the OTP authentication service or is assigned at the time of registering the OTP authentication service.
  • the above-described private key used for generating the user OTP may be stored in the key storage unit 323 of the OTP generator 320 in advance.
  • the private key stored in the key storage unit 323 of the OTP generator 320 may be stored in the key storage unit 353 of the OTP authentication server 350 to be identically used to generate OTPs. .
  • more various values may be additionally used or replaced as a seed value for OTP generation.
  • the above description focuses on the case where the OTP is generated by using the key value stored in the OTP generator 320, it is not necessary to use the stored key value.
  • a key value or a specific operation condition to be additionally used for generating the OTP may be transmitted to the OTP generator 320.
  • a method of transmitting a key value or an operation condition additionally used for generating the OTP by the OTP generator 320 to the OTP authentication server 350 may be used.
  • the OTP display unit 327 of the OTP generator 320 expresses the generated user OTP through the screen of the mobile device 310.
  • the authentication request unit 335 of the online service server 330 transfers the user OTP input by the service user through the communication interface unit 331 to the OTP authentication server ( 350) (see step S10 of FIG. 18), a verification of the input user OTP may be requested.
  • the input of the user OTP by the service user may be made through a user OTP input window posted on the online service site screen provided by the online service server 330.
  • the user OTP may not be entered directly by the service user, but may substitute input through a specific gesture.
  • the user may automatically input the user OTP by performing various gestures such as a simple touch selection of the user OTP expressed through the touch screen of the mobile device, a touch gesture that pushes the screen upward. It may be implemented.
  • the verification OTP generation unit 355 of the OTP authentication server 350 generates the verification OTP corresponding to the input user OTP (see step S11 of FIG. 18).
  • the generation method of the verification OTP is essentially the same as the user OTP generation method described above, redundant description thereof will be omitted.
  • the generation of the verification OTP according to step S11 of FIG. 18 does not necessarily need to be executed after step S11 of FIG. 18, and may be executed at any time after step S5 of FIG. 18 according to a system implementation scheme.
  • the authentication processing unit 357 of the OTP authentication server 350 compares the match between the delivered user OTP and the self-generated verification OTP, thereby performing user authentication for the corresponding service user. To perform. At this time, the authentication result is notified (transmitted) to the online service server 330 through the communication interface unit 351 (see step S12 in Fig. 18).
  • the service processing unit 337 of the online service server 330 may start the corresponding service to the corresponding service user when authentication is normally performed with reference to the notified authentication result (see step S13 of FIG. 18).
  • an OTP generation method and system for generating an OTP using connection information of an access terminal accessing the service and making the OTP valid only in a connected access terminal is provided. Accordingly, even if the OTP value is leaked by the hacker, the authentication is effective only for connecting to the server by the corresponding access terminal.
  • This embodiment relates to a method for verifying a driving environment of an OTP app and an authentication system using the same. More specifically, the present invention relates to a method and system for preventing OTP generation and authentication through the duplicated app even if the software-based OTP app is copied from the first registered mobile device to another device.
  • the hardware dongle method has a high security effect, but it is inconvenient to carry and cost, and the software method is economical and portable, but the software itself can be duplicated, so it is weak in security.
  • mobile apps can be duplicated from the first installed device to another device, and various technologies have appeared to prevent this.
  • the unique value UID (Unique Device Identifier), Phone Number, Push ID, etc.
  • the app is started.
  • the device's unique value at the time of registering the OTP app is converted into a hash value and stored, and the device compares the stored hash value with the unique value hashed in real time every time the OTP app is run. There is also a way to check whether it is the first device installed (i.e., the same device as the app was registered).
  • the former method has a problem in that the OTP app can be duplicated and run even by a simple method of newly generating an app after removing a conditional part of decompiling the app to confirm the unique value.
  • the latter method of the above-described method if the hacker is running the app after randomly changing (reconfigured) the unique value of the owned smart device to the original device where the app was installed, the app is normally There is a problem that is driven.
  • the app forgery prevention technology even if the application forgery prevention technology is mobilized additionally, if the value for the environment in which the app is running, not forgery of the app itself, the app is considered to be a normal smart device to operate.
  • the forgery detection method recognizes a common binary area of the app, there is a limit in that it cannot detect a data area having a unique value for each user such as authentication software even if it is tampered with.
  • the present embodiment checks whether the software-based OTP app is run on the first-installed and registered smart device, and then generates an OTP value so that the normal OTP value is not generated even if the OTP app is replicated by a hacker. And to provide a system.
  • FIG. 22 is a view illustrating a method for verifying a driving environment of an OTP app and an authentication system using the same according to an embodiment of the present invention
  • FIGS. 23 and 24 illustrate a driving environment of an OTP app according to an embodiment of the present invention.
  • the OTP app App refers to a software type OTP generator installed in the form of an application program on a user's own mobile device (see 410 in FIG. 22).
  • embodiments of the present invention to be described below can be applied to various online services utilizing OTP as an authentication means regardless of service type.
  • the following description will focus on the case where the OTP is used for user authentication, but if the OTP is used for authentication of a specific purpose, the present invention may be applied without particular limitation.
  • a user accesses a specific online service server (see 430 in FIG. 22) that provides a corresponding service for using an online banking service. It is assumed that OTP authentication is selected as the user authentication means.
  • OTP authentication is selected as an authentication means for using the online service provided by the online service server 430 as described above, the user has an OTP app 420 installed in his own mobile device for input of a user OTP value, which is an authentication value. ) Will be driven.
  • the OTP app 420 executes a series of procedures for verifying the app driving environment. That is, the OTP app according to the embodiment of the present invention does not immediately generate an OTP according to the driving of the app, but performs a procedure for verifying the driving environment in which the corresponding app is running before generating the OTP, and verifies the app driving environment normally. You can only generate OTP values when you are done.
  • a series of procedures for verifying the app driving environment will be described with reference to steps S2 to S7 of FIG. 22.
  • the driving environment verification unit 423 of the OTP app 420 transfers the app push ID and basic registration information to the OTP authentication server 450 through the communication interface 421. send.
  • An App Push ID is typically a unique value (e.g., Push) assigned per app installed for sending and receiving data via a push messaging service with a particular mobile operating system (e.g., Google or Apple's mobile operating system). Token, etc.). Therefore, even if the same app is installed, if the installed device is different, the app push ID is also different.
  • the app push ID transmitted to the OTP authentication server 450 through this step is a push ID for the app registered when the user first subscribes to the OTP authentication service by the OTP authentication server 450.
  • the app push ID is stored in the OTP app 420 may be delivered to the OTP authentication server 450 through this step.
  • an app push ID value is obtained from an operation server of the corresponding mobile operating system (ie, Google or Apple's management server).
  • a method of receiving and transferring the received information to the OTP authentication server 450 may be used. In the latter method, the app push ID value must be obtained every time, so even if the OTP app is copied by the hacker, the app push ID cannot be obtained through the hacker's device. Therefore, the latter scheme may be more secure than the former scheme (how the app push ID is stored in the app itself).
  • the basic registration information is information registered when the user first subscribes to the OTP authentication service, and information (for example, user identification information or the OTP authentication service that the user can identify valid users who subscribed to the OTP authentication service). Additional input information entered when signing up for, etc.), OTP app information (for example, app serial number, OTP identification, OTP app password, etc.) registered when the OTP app was registered with the authentication server, and the mobile device with the OTP app installed. Any one or a combination of information (eg, UDID, USIM card number, MAC address, etc.) may be used.
  • the above-described app push ID and basic registration information are also stored in the information registration unit 453 of the OTP authentication server 450 and used for verifying the driving environment of the OTP app in the future.
  • the driving environment verification unit 423 of the OTP app 420 may display the driving environment verification standby screen on the app screen (see step S3 of FIG. 22). ].
  • the driving environment verification standby screen is displayed on the screen of the mobile device to inform the user that the application driving environment is verified until the push message according to step S6 of FIG. 22 to be described later is transmitted from the OTP authentication server 450. It means the screen displayed on.
  • the OTP authentication server 450 is the information registration unit 453. Check whether the app push ID and basic registration information stored in) match with the received app push ID and basic registration information.
  • the environment in which the OTP app is running did not differ from the one registered at the time of signing up for the OTP authentication service (i.e., the mobile device running the OTP app is the same as the original device). do. In other words, you can see that the OTP app is not copied and stolen to other devices.
  • the OTP authentication server 450 may further perform a second verification process according to step S5 of FIG. 22.
  • the second verification process according to step S5 of FIG. 22 may be omitted according to a system implementation method, but this will be described below.
  • the OTP authentication server 450 corresponds to an IP address of an access mobile device (that is, a device on which the OTP app 420 is installed) within a range of a carrier IP address registered in advance in the information register 453.
  • the pre-registered carrier IP address range indicates an IP address range allocated by a mobile service provider providing a mobile communication service when the mobile device subscribed to the mobile communication service intends to perform IP communication.
  • step S5 of FIG. 22 is a process for further verifying the position range where the corresponding device is used beyond the device verification of the previous step (step S4).
  • the OTP app 420 may check the network settings when the app is running, so that the app does not run in a short-range communication mode such as WiFi, and manages the app to be run only in a mobile communication network such as 3G or LTE.
  • the check of the network setting may be performed by the communication network checking unit 420 of the OTP app 420.
  • the OTP authentication server 450 based on the app push ID received through step S2 of FIG. 22, the OTP generation condition value is OTP app 420 (See step S6 in Fig. 22).
  • step S6 of FIG. 22 may be performed by the following method.
  • the OTP authentication server 450 allows the OTP generation condition value to be transmitted to the mobile device 410 on which the corresponding OTP app 420 is installed through a push server (not shown).
  • the OTP app 420 may read the push message transmitted to the mobile device 410 to check the OTP generation condition value.
  • the mobile device of the true user is not the hacker's device through step S6 of FIG. OTP creation condition value is delivered. Therefore, the hacker's device cannot receive the OTP generation condition value and thus cannot generate the OTP value for authentication.
  • the OTP generating unit 427 of the OTP app 420 When the OTP generating condition value is transmitted through the previous step, the OTP generating unit 427 of the OTP app 420 generates the OTP using the received OTP generating condition value, and the OTP displaying unit 429 of the OTP app 420. ) Can display the generated OTP on the screen (see step S7 of FIG. 22).
  • the OTP generation condition value transmitted to the OTP app 420 may be a value assigned or stored by the OTP generation condition setting unit 455 of the OTP authentication server 450.
  • it may be a variable value that changes every time, such as a time value, a random value, an OTP issuance frequency, etc. of the OTP authentication server 450, the maximum time that the OTP generator 427 can operate, or the OTP app 420
  • the value may be a value transmitted to the OTP authentication server 450 or a value associated with it (the property value stored in the server), or a combination thereof.
  • the OTP generator 427 generates an OTP value by using the operator when generating the OTP when the variable value is received as the received OTP generation condition value, or when the fixed value is received, is equal to the value referenced by the app. You can generate OTP values.
  • some of the generation condition values used for generating the OTP by the OTP generator 427 may use the values previously stored in the OTP app.
  • the online service server 430 transmits the OTP input by the user to the OTP authentication server 450 (see step S19 of FIG. 22), thereby inputting the OTP. You can request verification of the value.
  • input of the OTP value by the service user may be made through an OTP input window posted on the online service site screen provided by the online service server 430.
  • the OTP value may not be directly input by the service user but may be substituted for the input through a specific gesture.
  • a user may perform various inputs such as a simple touch selection of an OTP expressed through a touch screen of a mobile device, a touch gesture of pushing the screen upward, and the automatic input of the OTP. It may be.
  • the verification authentication processing unit 457 of the OTP authentication server 450 generates a verification OTP corresponding to the input OTP, and compares the matching between the delivered OTP and the self-generated verification OTP, thereby providing the corresponding service.
  • Authentication is performed for the user (see step S10 of FIG. 22).
  • the authentication result may be notified (transmitted) to the online service server 430 through the communication interface 451.
  • the online service server 430 may start the corresponding service to the corresponding service user when authentication is normally performed with reference to the notified authentication result.
  • step S6 of FIG. 22 You can't.
  • the OTP app 420 may forcibly terminate the app or display a message on the screen to guide the termination. Can be.
  • the OTP authentication server 450 is not allowed to authenticate with the online service server 430. Notification can be sent.
  • the OTP authentication server 450 may transmit a warning message for alerting the true user to the duplication of the OTP app by the other person or the other person based on the stored push ID.
  • the OTP authentication server 450 when the push ID and the basic registration information according to step S2 of FIG. 22 is not received, when the OTP value is transmitted according to step S9 of FIG. 22, the online service server 430. Disapproval notification can be sent. This is because it is an abnormal authentication request received without undergoing an app driving environment verification process according to an embodiment of the present invention.
  • a normal OTP value is generated only in a smart device that is initially installed and registered, so that a software type OTP app having the same level of security as a hardware OTP dongle can be implemented.
  • the present embodiment relates to a method for preventing theft by a third party when running a software-based One Time Password (OTP) application in a user terminal. More specifically, the present invention relates to a method of checking whether a network is deactivated when running an OTP application and executing the OTP application when deactivated.
  • OTP One Time Password
  • a memory hacking attack is a hacking attack that sends a transaction account information to another account even when a normal user enters a transaction account, remittance amount, and OTP token value in an online transaction medium. .
  • Transaction interworking OTP technology is a technology for generating an OTP token value by receiving additional transaction information (transaction account, remittance amount) to the conventional OTP technology that generates the OTP token value by calculating the time or number of attempts to the individual OTP unique value. Therefore, even if a memory hacking attack occurs in the transaction terminal, the transaction cannot be made unless the remittance account and the remittance amount match the transaction linkage OTP.
  • interlocked OTP is composed of hardware-based OTP, which is more secure than economical and portable software. This is because an attack on a user terminal can attack the operating environment itself rather than simply phishing an app. Representatively, when a user runs an app on a user terminal, it is also possible to transmit an input value or an output result value or the screen itself to the outside, and an external hacker takes control of the user terminal through a remote control technology to remotely drive the user. It seems that even possible.
  • This embodiment is to provide a computer-implemented method for an OTP application that can prevent the risk of hacking in the process of running a software-based OTP application.
  • the present embodiment is to provide a computer-implemented method for the OTP application that prevents the OTP token value is leaked through the hacking software when the transaction-linked OTP application is installed or running in the user terminal.
  • FIG. 25 is a diagram illustrating functional blocks of a transaction interlocking OTP application according to one embodiment of the present invention
  • FIG. 26 is a schematic flowchart of a method of driving an OTP application according to an embodiment of the present invention.
  • 27 to 31 are diagrams illustrating execution screens of a transaction linkage OTP application according to an embodiment of the present invention.
  • a transaction interlocking OTP application 500 (hereinafter, abbreviated as "transaction interlocking OTP app") is a corresponding application program.
  • the network confirmation unit 510, the transaction information storage unit 520, the OTP generation unit 530, the graphical user interface (GUI) screen display unit 540, and the controller 550 may be included in order to perform a function.
  • GUI graphical user interface
  • the network confirmation unit 510 checks the network connection state of the user terminal when the transaction interworking OTP app is initially started, so that the transaction interworking OTP app can be started when the network connection is in an inactive state. Therefore, when the request for driving the transaction interlocking OTP app is received according to the user's selection as in step S210 of FIG. 26, the network checking unit 510 checks whether the network connection of the user terminal is in an inactive state [FIG. 26. See step S220].
  • the network deactivation state may be set when all network devices (for example, 3G, LTE, WiFi, Bluetooth, NFC, etc.) mounted in the user terminal are in an inactive state, but the IP (Internet Protocol) for network connection. It may also be set to the case where only a network that needs to be assigned an address is in an inactive state.
  • IP Internet Protocol
  • the network confirmation unit 510 checks whether or not a network to which the IP address is assigned exists in the user terminal, If the assigned network does not exist, it may be determined that the network is in a deactivated state. That is, in the latter case, even if the network of the short-range wireless communication method such as Bluetooth, NFC, etc. that can communicate with the outside without an IP address is activated, if the network requiring the IP address assignment is inactive, the step of FIG. It will be determined as the network deactivation state in S220.
  • the network identification unit 510 may determine that the network connection is in a deactivated state when the address system assigned to the network device is a loopback address.
  • a loopback address may be 127.0.0.1 for an IP address assigned to a network device, and may be :: 1 or 0: 0: 0: 0: 0: 0: 0: 1 for an IPv6 address.
  • the matters regarding how to define the network deactivation state may be different according to the environment setting of the application.
  • the controller 550 controls whether the transaction-linked OTP app is driven or / or whether the function is executed according to the app driving according to the confirmation result of the network confirmation unit 510.
  • the controller 550 controls the transaction interworking OTP app to be normally driven (executed).
  • the GUI screen display unit 540 displays a GUI screen for generating a transaction interworking OTP as shown in the example screens of FIGS. 27 to 31 to be described later. The control of the operation, or through this control the operation of the OTP generating unit 530 to generate a transaction interlocking OTP.
  • step S220 of FIG. 26 confirms that the network connection is not inactivated (that is, when the network is connected)
  • the controller 550 restricts the operation of the transaction interworking OTP app (that is, App execution can be disabled) (see step S240 of FIG. 26).
  • the controller 550 may control to display a pop-up (that is, a pop-up (see FIG. 27) for inducing a network connection to be inactivated) through the GUI screen (FIG. 26).
  • the controller 550 may allow the transaction interworking OTP app to be executed.
  • the network confirmation unit 510 may check whether the network connection is restored again every second or every specified period while the transaction interworking OTP app is running (see step S250 of FIG. 26). Accordingly, when the network connection is resumed, the controller 550 may limit the operation of the transaction interworking OTP app or limit the performance of the function according to the app driving (see step S260 of FIG. 26).
  • limiting the operation of the transaction interworking OTP app may be used, such as the display of a guide popup for switching the network connection state back to an inactive state, a method of automatically forcibly terminating the network connection state, and the like. have.
  • the control unit 550 of the interlocking OTP app may control to switch directly to the airplane mode or the network deactivation mode, and for this purpose, the interlocking OTP app may have the network control unit below. have.
  • limiting the execution of a function according to the operation of the transaction interlocking OTP app means that the initialization of the data of the transaction interlocking OTP app, the limitation of the data processing (operation) according to the app driving, the initialization of the app screen, etc. This may be the case.
  • the initializing value may be transaction information input or selected by the user, an OTP token value generated by the OTP generating unit 530, or all data currently generated or newly stored according to the operation of the OTP app. have.
  • the controller 550 when it is determined that the network connection is maintained in an inactive state as a result of the periodic check through the network checker 510, the controller 550 is a GUI screen (FIG. 27 to FIG. 31) expressed through the transaction interlocking OTP app. Input the transaction information, store the data about the transaction information through the transaction information storage unit 520, generate the transaction-linked OTP through the OTP generation unit 530, and display the app screen through the GUI screen display unit 540 And the like can be controlled.
  • the transaction information selected by the user may be used to generate the transaction linkage OTP through the transaction linkage OTP app.
  • a trading bank ie, a financial institution
  • a deposit account information, and a transaction amount is used for generating a transaction-linked OTP is not limited thereto. That is, at least one of various transaction information such as a bank, an account holder, a transaction amount, a deposit account number, an assigned transaction number, and a transaction condition may be used to generate a transaction-linked OTP.
  • the input item or selection item of such transaction information may be variously modified according to an app implementation method.
  • the transaction information which has been input once according to the implementation method, may be encrypted and stored and recycled according to the user's selection if necessary.
  • nickname can be set and used to easily call and use transaction information in the future.
  • the input or reused transaction information may be converted into a hash value and transferred to the OTP generator 530.
  • the OTP generation unit 530 is a component in charge of the OTP generation algorithm for transaction interworking.
  • the OTP generation key receives a transaction information selected on an OTP intrinsic key value and an OTP variable value (time or / and number of attempts).
  • the display may be transmitted to the screen display unit 540.
  • the GUI screen display unit 540 displays the OTP token details generated by the OTP generator 530 to the user (see FIG. 30).
  • the GUI screen display unit 540 may additionally provide an 'OTP app termination' or 'OTP app termination and network restart' button (see FIG. 31).
  • the network checker 510 controls the network to be executed immediately before the app termination and the controller 550 to terminate the app. It may be. In this case, the controller 550 may further transmit the transaction information input or selected by the user to another server immediately after the network is resumed, immediately after the app is terminated.
  • the transaction information related to the deposit and withdrawal from the bank is used to generate the transaction linked OTP
  • the transaction information to be used to generate the transaction linked OTP may vary according to the characteristics of the trading institution.
  • securities firms can be composed of buy item code, purchase quantity, purchase amount, etc.In the case of shopping mall, they can be composed of product code, order quantity, order amount, etc. It may consist of a trading institution, a transaction number, and a transaction amount.
  • code information identified by the user may be used to generate the transaction-linked OTP.
  • code information for identifying the user displayed through the OTP app screen for example, numbers, letters, shapes, shapes shown through the image displayed in the form of the rotary password selection key of the safe) Matching user identification code
  • the code information for identifying the user displayed through the OTP app screen may be used to generate a transactional linkage OTP.
  • the network check unit 510 is the current plane mode value and WiFi setting value Check if it is connected and deactivate the network. If your operating system doesn't support switching between Airplane or WiFi mode, stop the app from running and instruct the user to turn off the network and connect.
  • the GUI screen display unit 540 is driven to receive a trading institution, a trading account, a trading amount, a trading condition, and the like from the user.
  • the trading subject alias may be stored as needed, and the user may not need to enter a trading institution or trading account unnecessarily.
  • the input value may be encrypted or transformed into a hash value and transmitted to a third external verification server which is specified in advance when the network is resumed, and the app may be terminated.
  • the OTP generation unit 530 generates an OTP token value by using transaction information and the like in variable information (time or number) in the OTP unique value. The generated OTP token value is displayed on the GUI screen display unit 540.
  • control unit 550 configures the screen display setting time, and if the specified screen display setting time has elapsed since the transaction linked OTP is displayed on the screen, at least one of driving or performing a function according to the operation of the transaction linked OTP app. Can be controlled to be limited. Alternatively, the control unit 550 may disable the operation of the transaction interlocking OTP app, and present a selection button on the OTP display screen to induce the network connection with the OTP termination, so that the user transmits the OTP to the trading medium. You can provide an environment for input.
  • the OTP token value is not leaked by the third party for a valid time.
  • the third party cannot know what transaction information has been entered or selected by the user while the network is inactive.
  • Method and apparatus according to an embodiment of the present invention may be implemented in the form of program instructions that can be executed by various computer means may be recorded on a computer readable medium.
  • Computer-readable media may include, alone or in combination with the program instructions, data files, data structures, and the like.
  • the program instructions recorded on the computer readable medium may be those specially designed and constructed for the present invention, or may be known and available to those skilled in the computer software arts.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks.
  • Hardware devices specially configured to store and execute program instructions such as magneto-optical media and ROM, RAM, flash memory and the like.
  • Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

Abstract

인증 서버가, 서버 검증용 OTP 생성 요청에 따라 서버 검증용 OTP를 생성하는 단계; OTP 생성기가, 상기 온라인 서비스 서버의 진위 확인을 위해 상기 서버 검증용 OTP와 동일 조건의 확인용 OTP를 생성하고, 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 동일한 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과는 다른 연산 조건을 적용하여 상기 서버 검증용 OTP 생성에 사용된 연산 조건과 동일 연산 조건을 적용함으로써 상기 서버 검증용 OTP와 페어링되는 값을 갖는 사용자 OTP를 생성하는 단계; 및 상기 인증 서버가, 상기 사용자 OTP와 동일 조건의 대응 OTP를 생성하고, 상기 생성된 대응 OTP와 상기 사용자 OTP 간의 일치 여부를 비교함으로써 상기 서비스 사용자에 대한 인증을 수행하는 단계를 포함하는 상호 인증을 위한 컴퓨터 구현 방법이 제공된다.

Description

인증 방법 및 시스템
본 발명은 인증 시스템에 관한 것으로서, 보다 구체적으로는 OTP(One Time Password) 등을 이용한 인증 방법 및 시스템에 관한 것이다.
최근 금융거래나 기밀이 필요한 곳에서 그 인증 방식으로서 일회용 비밀번호인 OTP(One Time Password)의 사용이 확산되고 있다. 전통적으로 OTP는 구동인 방식에 따라서 하드웨어 기반의 동글 방식과 사용자 단말의 소프트웨어 앱 방식으로 나누어진다. 하드웨어 동글 방식은 보안의 효과는 높으나 휴대의 불편성과 비용이 발생한다는 특징이 있고, 소프트웨어 방식은 보안 효과는 다소 떨어지나 비용이 저렴하다는 장점이 있다.
따라서 전술한 하드웨어 동글 방식의 장점과 소프트웨어 앱 방식의 장점을 모두 갖추면서도, 헤커에 의해 점점 고도화되는 정보 탈취의 위험을 극복할 수 있는 신규의 인증 방법 및 인증 시스템이 요구된다.
본 발명은 OTP(One Time Password) 등을 이용하는 인증 방법 및 시스템으로서 보안성이 강화된 인증 방법 및 시스템을 제공하고자 한다.
본 발명의 일 측면에 따르면, 보안성이 강화된 인증 방법 및 시스템이 제공된다.
본 발명의 제1 실시예에 의할 때, 온라인 서비스 서버와 서비스 사용자 간의 상호 인증을 수행하는 컴퓨터 구현 방법(computer implemented method)으로서,
(a) 인증 서버가, 서버 검증용 OTP 생성 요청에 따라 서버 검증용 OTP를 생성하는 단계;
(b) OTP 생성기가, 상기 온라인 서비스 서버의 진위 확인을 위해 상기 서버 검증용 OTP와 동일 조건의 확인용 OTP를 생성하고, 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 동일한 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과는 다른 연산 조건을 적용하거나 또는 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 다른 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과 동일 연산 조건을 적용함으로써 상기 서버 검증용 OTP와 페어링되는 값을 갖는 사용자 OTP를 생성하는 단계; 및
(c) 상기 온라인 서비스 서버로부터 상기 사용자 OTP를 포함하는 사용자 인증 요청이 수신된 경우, 상기 인증 서버가, 상기 사용자 OTP와 동일 조건의 대응 OTP를 생성하고, 상기 생성된 대응 OTP와 상기 사용자 OTP 간의 일치 여부를 비교함으로써 상기 서비스 사용자에 대한 인증을 수행하는 단계를 포함하는 상호 인증을 위한 컴퓨터 구현 방법이 제공된다.
본 발명의 제2 실시예에 의할 때, 온라인 서비스 서버와 서비스 사용자 간의 상호 인증을 수행하는 컴퓨터 구현 방법(computer implemented method)으로서,
(a) 인증 서버가, 상기 온라인 서버로부터 상기 온라인 서버에 접속하는 서비스 사용자의 사용자 계정 정보를 포함하는 간편 인증번호 생성 요청이 수신됨에 따라 간편 인증번호를 생성하는 단계;
(b) 상기 인증 서버가, 상기 간편 인증번호의 생성에 사용된 생성 조건을 상기 사용자 계정 정보에 상응하는 사용자의 간편 인증기로 전송하는 단계;
(c) 상기 간편 인증기가, 상기 간편 인증번호의 생성 조건을 이용하여 상기 간편 인증번호에 대응되는 검증용 인증번호를 생성하는 단계; 및
(d) 상기 인증 서버가, 상기 간편 인증번호 및 상기 검증용 인증번호를 통한 상기 온라인 서비스 서버에 관한 검증이 완료됨에 따라 상기 간편 인증기로부터 전달되는 추가 검증값에 대응하여 대응 검증값을 생성하고, 상기 추가 검증값과 상기 대응 검증값 간의 일치 여부를 비교함으로써 해당 서비스 사용자에 대한 인증을 수행하는 단계를 포함하는 상호 인증을 위한 컴퓨터 구현 방법이 제공된다.
본 발명의 제3 실시예에 의할 때, 온라인 서비스 서버에 접속한 서비스 사용자를 인증하기 위한 컴퓨터 구현 방법(computer implemented method)으로서,
인증 서버가, 상기 온라인 서비스 서버에 접속한 상기 서비스 사용자의 접속단말 연결정보를 상기 온라인 서비스 서버로부터 수신하는 단계-여기서, 상기 접속단말 연결정보는 상기 온라인 서비스 서버와 상기 서비스 사용자의 접속단말 간의 연속적인 데이터 송수신을 관리하기 위해 상기 온라인 서비스 서버에 의해 생성 관리되는 서버-단말 간 연결정보(connecting information)임-;
상기 인증 서버로부터 상기 접속단말 연결정보가 수신된 경우, 상기 서비스 사용자의 OTP 생성기가, 상기 접속단말 연결정보를 이용하여 사용자 OTP를 생성하는 단계; 및
상기 인증 서버가, 상기 접속단말 연결정보를 이용하여 상기 서비스 사용자의 인증을 위한 검증용 OTP를 생성하고, 상기 생성된 검증용 OTP와 상기 온라인 서비스 서버로부터 전달된 사용자 OTP 간의 일치 여부를 비교함으로써 상기 서비스 사용자에 대한 인증을 수행하는 단계를 포함하는 사용자 인증 방법이 제공된다.
본 발명의 제4 실시예에 의할 때, OTP(one time password) 앱이 구동되는 구동 환경을 검증하기 위한 컴퓨터 구현 방법(computer implemented method)으로서-여기서, 상기 OTP 앱은 모바일 기기에 설치되어 OTP를 생성하는 소프트웨어 방식의 OTP 생성기임-,
(a) 인증 서버가, 상기 OTP 앱이 구동됨에 따라 상기 OTP 앱으로부터 상기 OTP 앱의 푸시 아이디(Push ID) 및 기본등록정보를 수신하는 단계;
(b) 상기 인증 서버가, 상기 수신된 푸시 아이디 및 기본등록정보와 사전 보관된 푸시 아이디 및 기본등록정보 간의 일치 여부를 확인하는 단계;
(c) 상기 (b) 단계에서 확인한 정보가 일치하는 경우, 상기 인증 서버가, OTP 앱으로 OTP 생성조건 값을 전송하는 단계를 포함하는 OTP 앱의 구동 환경 검증 방법이 제공된다.
본 발명의 제5 실시예에 의할 때, 사용자 단말에서 실행되는 OTP(One Time Password) 애플리케이션에 관한 컴퓨터 구현 방법으로서, 상기 OTP 애플리케이션에 대한 구동 요청이 수신된 경우, 상기 사용자 단말의 네트워크 연결 상태를 확인하는 단계; 및 상기 네트워크 연결 상태의 확인 결과에 따라, 상기 네트워크 연결이 비활성화 상태일 때 상기 OTP 애플리케이션이 구동되도록 제어하는 단계를 포함하는, 컴퓨터 구현 방법이 제공된다.
또한, 사용자 단말에서 실행되는 OTP(One Time Password) 애플리케이션에 관한 컴퓨터 구현 방법으로서, 상기 OTP 애플리케이션이 구동 중인 상태에서, 상기 사용자 단말의 네트워크 연결 상태를 확인하는 단계; 및 상기 네트워크 연결 상태의 확인 결과에 따라, 상기 네트워크 연결이 된 경우, 상기 OTP 애플리케이션의 구동 및 상기 구동에 따른 기능 수행 중 적어도 하나가 제한되도록 제어하는 단계를 포함하는, 컴퓨터 구현 방법이 제공된다.
본 발명의 실시예에 의하면, OTP 등을 이용하여 보안성이 한층 강화된 인증 방법 및 시스템을 제공할 수 있는 효과가 있다.
본 발명의 제1 실시예와 관련된 도면들이 도 1 내지 도 8에 도시된다.
도 1은 본 발명의 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법 및 시스템을 설명하기 위한 도면.
도 2는 본 발명의 실시예예 따른 상호 인증 방법을 구현하는 OTP 인증 서버에 관한 일 실시예의 블록도.
도 3은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 OTP 생성기에 관한 일 실시예의 블록도.
도 4는 온라인 서비스 서버에 의해 온라인 서비스 사이트에 표출되는 OTP 게시 화면 예시.
도 5는 OTP 생성기에 의해 생성된 확인용 OTP와 사용자 OTP가 모바일 기기의 화면을 통해 표출되는 화면 예시.
도 6는 OTP 생성기에 의해 확인용 OTP는 챌린지 앤드 리스폰스(Challenge & Response) 생성 방식으로 구동하면서, 사용자 OTP는 타임 OTP 생성 방식으로 모바일 기기의 화면을 통해 표출되는 화면 예시.
도 7은 본 발명의 다른 실시예에 따른 OTP를 이용한 상호 인증 방법을 설명하기 위한 도면.
도 8은 도 7에 의할 때의 모바일 기기 상의 화면 표출 예시.
본 발명의 제2 실시예와 관련된 도면들이 도 9 내지 도 17에 도시된다.
도 9는 본 발명의 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법 및 시스템을 설명하기 위한 도면.
도 10은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 인증 서버에 관한 일 실시예의 블록도.
도 11은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 간편 인증기에 관한 일 실시예의 블록도.
도 12는 온라인 서비스 서버에 의해 운영되는 온라인 서비스 사이트에 간편 인증번호가 게시되는 화면과 관련된 예시.
도 13은 간편 인증기에 의해 생성된 검증용 인증번호가 표출되는 화면과 관련된 예시.
도 14는 도 1의 상호 인증 방법에 따른 인증 과정에서 해커에 의한 접속 시도시 처리 방법을 설명하기 위한 도면.
도 15는 도 14과 같은 해커에 의한 접속 시도시의 온라인 서비스 서버에 의해 운영되는 온라인 서비스 사이트에 게시되는 처리 결과를 예시한 도면.
도 16 및 도 17은 사용자의 모바일 기기를 통해 온라인 서비스 서버에 접속하였을 때의 본 발명의 실시예에 따른 상호 인증 방법의 구현 예시.
본 발명의 제3 실시예와 관련된 도면들이 도 18 내지 도 21에 도시된다.
도 18은 본 발명의 실시예에 따른 사용자 인증 방법 및 인증 시스템을 설명하기 위한 도면.
도 19는 본 발명의 실시예예 따른 사용자 인증 방법과 관련된 온라인 서비스 서버의 일 실시예의 블록도.
도 20은 본 발명의 실시예에 다른 사용자 인증 방법을 구현하는 OTP 인증 서버에 관한 일 실시예의 블록도.
도 21은 본 발명의 실시예에 따른 사용자 인증 방법을 구현하는 OTP 생성기에 관한 일 실시예의 블록도.
본 발명의 제4 실시예와 관련된 도면들이 도 22 내지 도 24에 도시된다.
도 22는 본 발명의 실시예에 따른 OTP 앱의 구동 환경 검증 방법 및 이를 이용한 인증 시스템을 설명하기 위한 도면.
도 23 및 도 24는 본 발명의 실시예에 따른 OTP 앱의 구동 환경 검증 방법을 구현하기 위한, OTP 앱과 OTP 인증 서버에 관한 일 실시예의 블록도.
본 발명의 제5 실시예와 관련된 도면들이 도 25 내지 도 31에 도시된다.
도 25는 본 발명의 일 실시예로서, 거래연동 OTP 애플리케이션의 기능 블록을 도시한 도면.
도 26은 본 발명의 실시예에 따른 OTP 애플리케이션 구동 방법에 관한 개략적인 흐름도.
도 27 내지 도 31은 본 발명의 일 실시예로서, 거래연동 OTP 애플리케이션의 실행 화면들을 예시한 도면.
본 발명은 다양한 변환을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변환, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
본 발명을 설명함에 있어서, 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 본 명세서의 설명 과정에서 이용되는 숫자(예를 들어, 제1, 제2 등)는 하나의 구성요소를 다른 구성요소와 구분하기 위한 식별기호에 불과하다.
또한, 명세서 전체에서, 일 구성요소가 다른 구성요소와 "연결된다" 거나 "접속된다" 등으로 언급된 때에는, 상기 일 구성요소가 상기 다른 구성요소와 직접 연결되거나 또는 직접 접속될 수도 있지만, 특별히 반대되는 기재가 존재하지 않는 이상, 중간에 또 다른 구성요소를 매개하여 연결되거나 또는 접속될 수도 있다고 이해되어야 할 것이다.
또한, 명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서에 기재된 "부", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하나 이상의 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 조합으로 구현될 수 있음을 의미한다.
[제1 실시예 - 상호 인증 방법 및 시스템 #1] (Dual OTP)
본 실시예는 OTP를 이용한 상호 인증 방법 및 시스템에 관한 것이다. 보다 구체적으로는 온라인 서비스를 제공하는 서버가 진정한 서비스 제공 주체에 의한 서버인지 여부를 검증한 이후에 사용자 인증 정보를 제공하는 방식으로 서비스 제공자와 서비스 사용자 간의 상호 검증이 가능하도록 한 OTP를 이용한 상호 인증 방법 및 시스템에 관한 것이다.
최근 전자금융서비스나 IoT(Internet of Things) 시설물 제어서비스 등에 있어서 사용자 인증을 보강하기 위하여 OTP(One Time Password)가 도입되고 있다. 그러나 현재 OTP 기술은 서비스 사용자가 정당한 사용자인지 여부를 검증하는데 활용될 뿐, 사용자가 접속하는 온라인 서비스 자체가 위변조 되거나 해커에 의해서 운영되는 파밍 서버가 아님을 검증하는데 활용되고 있지는 않다.
파밍 공격(pharming attack)은 사용자로 하여금 해커가 운영하는 웹사이트를 올바른 사이트로 인지하게 함으로써, 사용자의 계정 정보(예를 들어, 아이디와 패스워드), OTP 입력창에 사용자가 입력한 OTP 값 등을 탈취하고, 탈취한 계정 정보와 OTP 값을 이용하여 해커가 사용자의 돈이나 정보 등을 가로채는 공격이다.
따라서 위와 같은 파밍 공격을 막으려면, 사용자가 접속한 서버가 위변조되지 않은 서버임을 검중할 필요가 있다. 이러한 서비스 서버 검증을 위해, 종래 기술에서는 사용자 스스로 서비스 서버에 개인 이미지를 업로드하게 하여 정상적인 사이트임을 표시하게 하거나, SSL(Secure Socket Layer)을 이용하여 주소창에 색상을 변경하게 함으로써 정상적인 사이트임을 표시하는 방식이 이용되었다.
그러나 개인화 이미지를 등록하는 방법은 사용자가 자발적으로 개인의 이미지를 등록하지 않는 경우가 많아 사용성이 크게 떨어지고 있으며, 주소창 색상 변경 서비스는 브라우저 마다 표기가 상이하고 또한 인지하기가 쉽지 않아 사용자가 혼동을 일으키는 경우가 많다. 따라서 사용자가 서비스 서버를 자연스럽게 검증하면서도 이와 함께 사용자 인증을 할 수 있는 개선된 방법과 기술이 필요하다.
본 실시예는 안전한 온라인 서비스를 제공하기 위하여, 서버 검증용 OTP를 사용자 인증 OTP 게시 화면에 함께 표시함으로써, 사용자가 사용자 인증용 OTP 값을 입력하기 전에 해당 서비스가 진정한 서비스 주체에 의해 제공되는 서비스임을 먼저 확인한 후, 사용자 인증용 OTP 값을 입력할 수 있도록 하는 방법 및 시스템을 제공하고자 한다.
이하의 설명에서, OTP 생성기는 사용자 소유의 모바일 기기에 애플리케이션 프로그램의 형태로 설치된 소프트웨어 OTP 생성기를 중심으로 설명하지만, 반드시 이에 한정되는 것은 아님은 물론이다. 예를 들어, OTP 생성기는 통신 기능을 갖춘 하드웨어 OTP 생성 장치일 수도 있다. 다만, 이하에서는 설명의 편의 및 집중을 위해 전자의 케이스를 가정하여 본 발명의 실시예를 설명하기로 한다.
또한, 이하에서는 도 1을 기준으로 온라인 서비스 서버에 접속하는 접속단말인 클라이언트 단말과 OTP 생성기가 물리적으로 별개로 구성된 경우를 가정하여 설명하지만, OTP 생성기는 클라이언트 단말과 일체적으로 구현될 수도 있다. 후자의 경우라면 도 1에 도시된 모바일 기기는 생략될 것이다. 또한, 클라이언트 단말 자체가 모바일 기기일 수도 있음은 자명하다.
도 1은 본 발명의 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법 및 시스템을 설명하기 위한 도면이다. 여기서, 도 2는 본 발명의 실시예예 따른 상호 인증 방법을 구현하는 OTP 인증 서버에 관한 일 실시예의 블록도이고, 도 3은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 OTP 생성기에 관한 일 실시예의 블록도이다. 또한 여기서, 도 4는 온라인 서비스 서버에 의해 온라인 서비스 사이트에 표출되는 OTP 게시 화면 예시이고, 도 5는 OTP 생성기에 의해 생성된 확인용 OTP와 사용자 OTP가 모바일 기기의 화면을 통해 표출되는 화면 예시이다. 또한, 도 6는 OTP 생성기에 의해 확인용 OTP는 챌린지 앤드 리스폰스(Challenge & Response) 생성 방식으로 구동하면서, 사용자 OTP는 타임 OTP 생성 방식으로 모바일 기기의 화면을 통해 표출되는 화면 예시이다. 이하, 도 1을 중심으로 도 2 내지 도 6을 함께 참조하여 본 발명의 실시예에 따른 상호 인증 방법 및 인증 시스템에 관하여 상세히 설명한다.
도 1의 단계 S1을 참조하면, 온라인 서비스 서버(130)가 제공하는 온라인 서비스 사이트에 의한 온라인 서비스를 이용하고자 하는 경우, 서비스 사용자는 온라인 서비스 서버(130)에 접속 요청을 한다.
예를 들어, 이용하고자 하는 온라인 서비스가 온라인 뱅킹 서비스인 경우, 사용자는 해당 온라인 뱅킹 서비스를 제공하는 특정 온라인 서비스 서버(즉, 온라인 뱅킹 서비스를 제공하는 특정 은행 서버)에 접속할 수 있다. 온라인 서비스 서버(130)로의 접속은 사용자 자신이 소유하는 모바일 기기(110)(예를 들어, 스마트폰 등)를 통한 모바일 접속에 의할 수 있음은 물론이나, 도 1에서는 사용자 소유의 모바일 기기(110)와는 별개의 클라이언트 단말(100)(예를 들어, 회사 PC 등)을 통해서 접속하는 경우를 예시하였다.
도 1의 단계 S2를 참조하면, 온라인 서비스 서버(130)로의 접속 요청에 따라, 온라인 서비스 서버(130)는 온라인 서비스를 이용하고자 하는 서비스 사용자에게 사용자 계정 정보의 입력을 요청할 수 있다. 여기서, 사용자 계정 정보는, 사용자 등록 절차(또는 서비스 가입 절차)를 통해서 해당 온라인 서비스 서버(130)에 미리 저장(등록)되어 있는 해당 사용자의 식별 정보를 의미한다. 통상적으로, 사용자 계정 정보로는 사용자 ID(Identifier)와 패스워드(password)가 활용될 수 있다. 다만, 해당 온라인 서비스를 이용하는 사용자를 식별할 수 있는 정보라면, 상기 사용자 계정 정보로서 이외에도 다양한 정보(예를 들어, 해당 사용자의 이메일 주소, 전화번호, PKI(Public Key Infrastructure) 기반의 인증서 상의 인증서 암호 등)가 대체 활용될 수 있음은 물론이다.
도 1의 단계 S3을 참조하면, 사용자 계정 정보의 입력 요청에 따라, 서비스 사용자는 사용자 계정 정보를 해당 온라인 서비스 사이트에 입력한다. 도 1의 단계 S4를 참조하면, 서비스 사용자로부터 사용자 계정 정보가 입력되면, 온라인 서비스 서버(130)는 사용자로부터 입력된 사용자 계정 정보와 일치하는 계정이 존재하는지를 확인한다. 이러한 계정 정보의 확인에는 도 1에 도시된 바와 같은 계정 DB(140)가 활용될 수 있다. 계정 DB(140)에는 해당 온라인 서비스 서버(130)를 통한 온라인 서비스를 제공받을 수 있는 사용자들(즉, 회원들)에 관한 계정 정보들이 보관된다. 도 1에서는 계정 DB(140)가 온라인 서비스 서버(130)와 별개로 구비되는 경우를 예시하였지만, 계정 DB(140)는 온라인 서비스 서버(130)와 통합되어 구현될 수도 있음은 물론이다. 또한, 시스템 구현 방식에 따라, 계정 DB(140)는 OTP 인증 서버(150)와 통합되어 구현될 수도 있을 것이다.
도 1의 단계 S5를 참조하면, 입력된 사용자 계정 정보가 계정 DB(140)에 보관된 사용자 계정과 일치하는 경우, 온라인 서비스 서버(130)는 OTP 인증 서버(150)로 서버 검증용 OTP의 생성을 요청한다. 여기서, 서버 검증용 OTP는 사용자가 현재 접속한 온라인 서비스 사이트가 진정한 온라인 서비스 제공자에 의해 제공된 것인지 여부를 사용자가 판별할 수 있도록 하기 위한 용도로서 활용된다.
도 1에서는 본 단계(즉, 단계 S5)가 앞선 사용자 계정 확인 절차(즉, 단계 S4)가 완료된 이후 바로 실행되는 것으로 도시되고 있지만, 이와 상이할 수도 있음은 물론이다. 예를 들어, 본 단계에 의한 서버 검증용 OTP의 생성 요청은, 사용자 계정 확인 절차가 완료된 이후에 사용자가 인증 수단으로서 OTP 인증 방식을 선택한 경우에 한하여 실행될 수도 있을 것이다.
또한, 도 1에서는 온라인 서비스 서버(130)가 OTP 인증 서버(150)로 서버 검증용 OTP의 생성 요청을 하는 경우를 예시하였지만, 이와 상이할 수도 있다. 예를 들어, 사용자 계정 확인이 완료되면, 서비스 사용자 측에서 OTP 인증 서버(150)로 서버 검증용 OTP의 생성 요청을 할 수도 있다. 이에 관한 보다 구체적인 구현 방식을 설명하면 아래와 같을 수 있다. 사용자 계정 확인이 완료되어 온라인 서비스 사이트에 서비스 접속이 이루어지면, 사용자는 자신의 모바일 기기(110)에 설치된 OTP 생성기(120)를 통해서 OTP 인증 서버(150)로 서버 검증용 OTP 생성 요청을 전송하는 방식이 이용될 수 있을 것이다. 다만 이하에서는 설명의 편의 및 집중을 위해, 서버 검증용 OTP 생성 요청은 온라인 서비스 서버(130)로부터 OTP 인증 서버(150)로 전송되는 것으로 도시된 도 1을 기준으로 설명하기로 한다.
상술한 바와 같은 서버 검증용 OTP의 생성 요청은 OTP 인증 서버(150)의 통신 인터페이스부(151)를 통해 접수(수신)된다.
도 1의 단계 S6을 참조하면, 온라인 서비스 서버(130)로부터의 서버 검증용 OTP의 생성 요청에 따라, OTP 인증 서버(150)는 서버 검증용 OTP를 생성한다. 이때, 서버 검증용 OTP의 생성은 OTP 인증 서버(150)의 서버 검증용 OTP 생성부(153)에 의해 수행될 수 있다. 이하, 서버 검증용 OTP의 생성 방법에 관한 다양한 실시예를 상세히 설명한다.
본 발명의 일 실시예에서, OTP 생성을 위한 시드 값으로서 활용될 OTP 생성키로는 서비스 사용자의 사용자 계정 정보에 대응하여 사전 등록된 고정키가 이용될 수 있다.
일 예로, 사용자 계정 정보에 대응하는 고정키는, 전술한 사용자 ID, 패스워드, 사용자의 이메일 주소, 전화번호, 인증서 암호 등과 같은 다양한 사용자 식별 정보 중 어느 하나 또는 적어도 2개의 조합이 사전 등록되어 이용될 수 있다. 다른 예로, 사용자 계정 정보에 대응하는 고정키는, 사용자 소유의 모바일 기기(예를 들어, 스마트폰 등)의 폰 번호, 제품 일련번호, 유심(USIM) 카드번호, 맥 어드레스(MAC address) 등과 같은 식별자 중 어느 하나 또는 적어도 2개의 조합이 사전 등록되어 이용될 수도 있다. 또 다른 예로, 사용자 계정 정보에 대응하는 고정키는, 사용자가 OTP 인증 서비스에 등록할 때에 자신이 직접 선택하여 등록한 또는 OTP 인증 서비스 등록시에 부여된 개인키가 이용될 수도 있다.
본 발명의 다른 실시예에서, OTP 생성을 위한 시드 값으로서 활용될 OTP 생성키로는 사용자가 접속하고자 하는 진정한 온라인 서비스 서버의 식별 정보에 대응하여 사전 등록된 고정키가 이용될 수도 있다. 일 예로, 해당 온라인 서비스 서버의 서버 IP 주소(해당 IP 주소 전체 또는 일부분일 수 있음)가 OTP 생성키로서 이용될 수 있을 것이다.
본 발명의 또 다른 실시예에서, OTP 생성을 위한 시드 값으로서 활용될 OTP 생성키로는 사용자가 해당 온라인 서비스 서버에 접속하는 시점에 동적으로 할당되는 동적 할당키가 이용될 수 있다.
일 예로, 상기 OTP 생성키로서 활용될 동적 할당키로는, 해당 온라인 서비스 서버로 접속하는 서비스 사용자의 접속단말 연결정보가 이용될 수 있다. 이때, 접속단말 연결정보로는 서비스 사용자의 접속시 해당 온라인 서비스 서버에서 서비스 사용자의 접속단말에 할당하는 세션 정보(예를 들어, 세션 ID(Session ID) 등) 또는 소켓 정보(예를 들어, 소켓 핸들(Socket handle) 등)가 이용될 수 있다.
여기서, 세션 ID는 서버와 접속단말 간의 연속적인 데이터 송수신을 관리하기 위해 해당 서버에 의해 부여되는 값이고, 소켓 핸들 정보는 서버와 접속단말 간에 네트워크를 통해 데이터를 송수신하는 단위인 소켓을 관리하기 위해 해당 서버가 자체적으로 할당한 임의의 연결 고유값이다. 이러한 세션 ID 또는 소켓 핸들 정보는 동적으로 할당됨은 물론 해당 서버에 의해 자체적으로 부여되는 값으로서, 서버 외부에서 해커에 의해 탈취되기 어렵기 때문에, 이를 OTP 생성키로서 이용하는 경우 보안 상 유리한 효과가 있다.
다른 예로, 상기 OTP 생성키로서 활용될 동적 할당키로는, 서비스 사용자 소유의 모바일 기기에 이동통신사가 동적으로 할당한 모바일 IP 주소(IP 주소 전체 또는 일부분일 수 있음)가 이용될 수도 있다. 예를 들어, 서비스 사용자가 자신의 모바일 기기를 통해서 해당 온라인 서비스 서버로 접속하는 경우를 가정하면, 이때 이동통신사에 의해 동적으로 할당된 모바일 IP 주소를 OTP 생성키로 이용할 수 있을 것이다.
또한, 이상에서 설명한 OTP 생성키에 관한 실시예들 이외에도, 더욱 다양한 값들이 OTP 생성을 위한 시드 값으로서 활용될 수 있다. 후술할 바이지만, 본 발명의 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법에서는, 서버 검증용 OTP와 사용자 OTP가 서로 페어링(pairing)되는 값으로 생성되는 것을 일 특징으로 한다. 따라서, 위 2개의 OTP 값이 서로 페어링될 수 있는 한도 내에서 OTP 생성키는 다양한 대체 사용이 가능하다.
본 발명의 실시예에서, 서버 검증용 OTP는, 전술한 OTP 생성키를 이용하되 특정 연산 조건을 적용하여 생성할 수 있다. 이때, 적용되는 연산 조건에 관해서는 이후 후술할 단계 S10에서 함께 설명하기로 한다. 이를 통해서 서버 검증용 OTP와 사용자 OTP가 서로 페어링되는 관계의 값으로 생성됨을 보다 명확히 이해할 수 있을 것이다.
도 1의 단계 S7을 참조하면, 앞선 단계를 통해 서버 검증용 OTP가 생성되면, OTP 인증 서버(150)는 통신 인터페이스부(151)를 통해서 해당 OTP 생성 조건이 서비스 사용자 소유의 모바일 기기(110)에 설치된 OTP 생성기(120)로 전송되도록 한다.
도 1에서 단계 S7의 OTP 생성 조건의 전송은 푸시 서버(160)를 통해서 수행되는 것으로 예시하고 있지만, 반드시 이와 같을 필요는 없으며, OTP 인증 서버(150)에서 직접 OTP 생성기(120)로 전송될 수도 있음은 물론이다. 또한, 도 1에서는 푸시 메시지를 통해서 OTP 생성 조건을 전송하는 케이스를 중심으로 도시하였지만, OTP 생성 조건의 전송은 소켓 전송 방식에 의할 수도 있다.
푸시 서버(160)를 통해 OTP 생성 조건을 전송하는 경우, OTP 인증 서버(150)는 OTP 생성 조건을 푸시 서버(160)로 전달하고, 이때 푸시 서버(160)는 푸시 메시지를 통해서 OTP 생성 조건을 OTP 생성기(120)로 전송할 수 있다. 여기서, 푸시 메시지는 특정 모바일 운영체제에서 앱(App) 별로 제공하는 메시지 서비스일 수 있다. 다만, OTP 생성 조건의 전송을 반드시 푸시 메시지에 의할 필요는 없음은 자명하며, SMS, MMS 등의 상용의 다양한 메시징 서비스에 의할 수도 있고, 특정 통신 프로토콜에 의하여도 무방하다. OTP 생성 조건의 전송을 푸시 메시지에 의하지 않는 다른 예시적 케이스들에서, 전술한 푸시 서버(160)는 일반적인 통신 서버로서 그 기능이 대체될 수 있다.
또한 도 1에서는 OTP 생성 조건이 OTP 생성기(120)로 직접 전송되는 케이스를 중심으로 설명하였지만, 반드시 이와 같을 필요는 없다. 예를 들어, OTP 생성 조건은 푸시 메시지 등을 통해서 모바일 기기(110)로 전송되고, OTP 생성기(120)가 이를 읽어들여 OTP 생성 조건을 수신(취득)할 수 있음은 자명하다. 이러한 OTP 생성 조건의 수신은 OTP 생성기(120)의 OTP 생성조건 수신부(121)에 의해 이루어질 수 있다.
여기서, OTP 생성기(120)로 전송되는 OTP 생성 조건은 OTP 연산 조건 또는/및 OTP 생성키 정보일 수 있다. 다만, 단계 S7을 통해서 전송되는 OTP 생성 조건이 구체적으로 어떤 정보들인지에 관해서는 이하 후술할 단계 S10에서 상세히 설명하기로 한다.
또한, 도 1의 단계 S8을 참조하면, OTP 인증 서버(150)는 통신 인터페이스부(151)를 통해서 앞선 단계 S6을 통해서 생성된 서버 검증용 OTP를 온라인 서비스 서버(130)로 전달한다.
전술한 단계 S7 및 단계 S8은, 도 1에 도시된 예시에서와는 달리, 동시에 이루어질 수도 있으며, 선후를 달리하여 이루어져도 무방하다. 이는 후술할 단계 S9 및 단계 S10의 경우에도 마찬가지이다.
도 1의 단계 S9를 참조하면, 서버 검증용 OTP의 전달에 따라, 온라인 서비스 서버(130)는 전달된 서버 검증용 OTP를 온라인 서비스 사이트의 OTP 게시 화면 상에 게시하고, 동일 화면을 통해서 사용자 OTP 입력을 요청한다. 이에 관한 예시가 도 4에 도시되고 있다.
도 4를 참조할 때, OTP 게시 화면(10)은 상단에 서버 검증용 OTP가 게시(표출)되는 OTP 표시창(10A)과 인접한 그 하단에 사용자 OTP의 입력을 요청하는 OTP 입력창(10B), 그리고 확인 버튼(10C)을 포함하고 있다. 이때, 서버 검증용 OTP가 게시되는 OTP 표시창(10A)와 사용자 OTP가 입력될 OTP 입력창(10B)는 서비스 사용자에 의한 즉각적인 인지적 구별이 가능하도록 색상, 형태 등을 달리하여 OTP 게시 화면(10) 내에 표출될 수 있다. 일 예로, OTP 표시창(10A)은 표시창 내에 주황색 음영 효과를 주고, OTP 입력창(10B)는 표시창 내에 노랑색 음영 효과를 줌으로써, OTP 표시창(10A)과 OTP 입력창(10B)이 시각적으로 구별되도록 할 수 있다.
이와 관련하여, 단계 S10을 통해서도 후술할 바이지만, 사용자의 모바일 기기의 화면을 통해 표출될 확인용 OTP(상기 서버 검증용 OTP에 대응되는 OTP임)의 표시창(도 5의 20A 참조)와 사용자 OTP의 표시창(도 5의 20B 참조)도 상기 OTP 게시 화면(10) 내에 표출된 OTP 표시창(10A) 및 OTP 입력창(10B)에 적용된 인지적 구별 효과와 동일한 효과를 적용하여 표출시킬 수 있다.
이에 의할 때, 서비스 사용자는 서버 검증용 OTP 및 사용자 OTP의 용도 구분을 별다른 어려움이 없이 직관적으로 이해할 수 있게 된다. 즉, 서비스 사용자는, OTP 게시 화면(10) 내의 OTP 표시창(10A)과 동일 인지적 구별 효과가 적용된 모바일 기기 화면 상의 표시창(도 5의 경우 20A 참조)을 직관적으로 찾을 수 있고, 각 표시창에 게시된 숫자(즉, 서버 검증용 OTP와 확인용 OTP 값) 간의 일치 여부를 확인함으로써, 해당 온라인 서비스 서버의 진위 여부를 즉각적으로 판별할 수 있다. 또한, 서비스 사용자는, OTP 게시 화면(10) 내의 OTP 입력창(10B)과 동일 인지적 구별 효과가 적용된 모바일 기기 화면 상의 표시창(도 5의 경우 20B 참조)을 직관적으로 찾을 수 있고, 해당 표시창(도 5의 경우 20B 참조)에 게시된 숫자(즉, 사용자 OTP 값)를 OTP 게시 화면(10) 내의 OTP 입력창(10B)에 직관적으로 입력할 수 있다.
도 1의 단계 S10을 참조하면, 앞선 단계 S7의 OTP 생성 조건의 전송에 따라, OTP 생성기(120)는, 확인용 OTP 생성부(123)를 통해서 확인용 OTP를 생성하고 사용자 OTP 생성부(125)를 통해서 사용자 OTP를 생성한다.
여기서, 확인용 OTP는, OTP 인증 서버(150)에 의해 생성되어 온라인 서비스 서버(130)의 온라인 서비스 사이트 상의 OTP 게시 화면(도 3의 도면번호 10 참조)에 게시된 서버 검증용 OTP에 대응하여, OTP 생성기(120)에서 생성하는 OTP 값이다. 따라서, 확인용 OTP와 OTP 게시 화면(10)에 게시된 서버 검증용 OTP가 일치하는 경우, 서비스 사용자는 해당 온라인 서비스 서버가 진정한 서비스 서버임(즉, 서비스 서버의 진위)을 판별해낼 수 있다.
본 발명의 실시예에서, OTP 생성기(120)에서, 확인용 OTP 및 사용자 OTP의 생성은 다음과 방식에 의할 수 있다. 기본적으로, OTP 생성기(120)에서 생성되는 확인용 OTP와 사용자 OTP는 상호간 페어링(pairing)되는 값을 갖는다. 이는 OTP 생성 과정에서 상호간 동일한 OTP 생성키 값을 이용하되, 서로 다른 연산 조건을 적용하여 OTP를 생성함으로써 실현될 수 있다. 이는 OTP 인증 서버(150)에서의 서버 검증용 OTP와 대응 OTP(이는 위의 사용자 OTP에 대응되는 개념의 OTP 값임)의 생성에도 동일하게 적용된다. 이하, 이에 대하여 구체적으로 설명하면 아래와 같다.
일 실시예에서, 확인용 OTP(혹은 서버 검증용 OTP)는 전술한 다양한 OTP 생성키를 시드 값으로 이용하되 챌린지 앤드 리스폰스(Challenge & Response) 생성 방식으로 생성하고, 사용자 OTP(혹은 대응 OTP)는 위와 동일한 OTP 생성키를 시드 값으로 이용하되 타임 OTP 생성 방식으로 생성함으로써, 상호간 서로 다른 연산 조건을 적용할 수 있다. 이에 관한 예시가 도 6에 도시되어 있다. 도 6의 (a) 및 (b)를 참조하면, 사용자의 모바일 기기 화면에 표출되는 확인용 OTP(도 6의 서비스 OTP 참조)는 챌린지 앤드 리스폰스 방식으로 생성되므로 시간의 변화와 무관하게 동일 값을 갖지만, 사용자 OTP는 타임 OTP 방식으로 생성되므로 유효시간 경과 후에는 그 값이 변경되고 있음을 확인할 수 있다.
여기서, 챌린지 앤드 리스폰스 방식은 연산 조건으로서 시도 횟수를 이용하여 OTP를 생성하는 방식이다. 이에 의할 때, OTP는 결정된 특정 OTP 생성키에 연산 조건인 시도 횟수를 곱한 값을 특정 해시 함수(hash function)에 따라 암호화한 값으로 생성될 수 있다. 또한 여기서, 타임 OTP 방식은 연산 조건으로서 생성 시간을 이용하여 OTP를 생성하는 방식이다. 이에 의할 때, OTP는 결정된 특정 OTP 생성키에 연산 조건인 생성 시간을 곱한 값을 특정 해시 함수에 따라 암호화한 값으로 생성될 수 있다.
전술한 예시에 의할 때, OTP 인증 서버(150)는 앞선 단계 S7을 통해서 서버 검증용 OTP를 생성하였을 때 이용한 OTP 생성 조건으로서, 챌린지 앤드 리스폰스 방식에 따른 연산 조건인 시도 횟수 정보를 OTP 생성기(120)로 전송할 수 있다. 다만 이때, 서버 검증용 OTP를 생성하는데 사용한 OTP 생성키는 OTP 생성기(120)로 반드시 전송될 필요는 없다. OTP 생성키로서 앞서 단계 S6을 통해서 설명한 고정키가 활용된 경우라면, OTP 생성기(120)의 키 보관부(미도시)에 해당 고정키가 미리 보관되도록 구성하고 이를 직접 이용할 수도 있는 바, 이와 같은 경우에는 연산 조건만을 단계 S7을 전송해줘도 무방하기 때문이다. 반면에, OTP 생성키로서 동적 할당키(예를 들어, 세션 ID 등)가 활용된 경우라면, 연산 조건과 함께 OTP 생성키도 단계 S7을 통해서 OTP 생성기(120)로 전송할 수 있다.
이에 따라, OTP 생성기(120)의 확인용 OTP 생성부(123)는 전달받은 OTP 생성 조건에 기초하여, OTP 인증 서버(150)에서 생성한 서버 검증용 OTP와 동일한 값의 확인용 OTP를 생성할 수 있다.
또한, OTP 생성기(120)의 사용자 OTP 생성부(125)는 확인용 OTP의 생성에 사용한 OTP 생성키와 동일한 생성키를 이용하되, 생성 시간을 연산 조건으로 하여 사용자 OTP를 생성할 수 있다. 이때, 사용자 OTP 생성의 연산 조건으로서 이용할 생성 시간은 앞선 단계 S7을 통해서 OTP 인증 서버(150)로부터 OTP 생성기(120)로 전송될 수 있다. 이에 따라, OTP 생성기(120)에 의해 생성된 확인용 OTP와 사용자 OTP는 동일 OTP 생성키에 기반하되, 서로 다른 연산 조건에 따라 페어링되는 값으로 생성될 수 있다.
이상에서는 확인용 OTP와 사용자 OTP가 동일 OTP 생성키에 의하되 서로 다른 연산 조건에 따라 각각 생성됨으로써 상호간 페어링되는 값을 갖게 되는 경우를 중심으로 설명하였다. 다만, 본 발명의 다른 실시예에 의할 때, 확인용 OTP와 사용자 OTP는 서로 다른 OTP 생성키에 의하되 동일한 연산 조건이 적용됨으로써, 상호간 페어링되는 값으로 생성될 수도 있음은 물론이다. 다만, 이하에서는 설명의 편의 및 집중을 위해, 전자의 케이스를 중심으로 설명하기로 한다.
상술한 방식에 따라 생성된 확인용 OTP와 사용자 OTP는 OTP 생성기(120)의 OTP 표출부(127)에 의해서 모바일 기기(110)의 화면을 통해 표출될 수 있다. 이에 대한 화면 표출 예시가 도 5를 통해 도시되고 있다. 도 5에서 확인용 OTP는 도면부호 20A의 표시창을 통해서 모바일 기기의 화면 상에 표출되고, 사용자 OTP는 도면부호 20B의 표시창을 통해서 동일 화면 상에 나란히 표출(즉, 시각적으로 서로 페어링되는 관계로 보이도록 표출)되고 있다.
이에 따라, 서비스 사용자는 온라인 서비스 사이트를 통해 표출되는 도 4와 같은 OTP 게시 화면의 OTP 표시창(10A)에 게시된 서버 검증용 OTP와 도 5의 좌측 표시창(20A)에 게시된 확인용 OTP를 비교하여, 해당 사이트의 진위 여부를 판별할 수 있다. 또한 서비스 사용자는 도 4의 OTP 게시 화면의 OTP 입력창(10B)에 도 5의 우측 표시창(20B)에 게시된 사용자 OTP 값을 입력할 수 있다[도 1의 단계 S11 참조].
이때, OTP 인증 서버(150)는, 서비스 사용자에 의한 온라인 서비스 서버(130)로의 접속 시도에 따른 사용자 OTP 입력 유효시간(예를 들어, 60초) 동안 또는 사용자 OTP 입력이 이루어지기 전까지, OTP 게시 화면의 OTP 표시창(10A)에 게시된 서버 검증용 OTP 값이 그대로 유지할 수 있다. 즉, 사용자 OTP 입력 유효시간이 경과되기 전 또는 사용자 OTP 입력이 이루어지기 전에, 해당 서비스 사용자의 사용자 계정 정보와 동일한 계정 정보를 이용한 후순위의 접속이 재시도된 경우(예를 들어, 진정한 사용자에 의한 접속 이후에 해커에 의한 추가 접속이 시도된 경우)라도, OTP 인증 서버(150)는 새로운 서버 검증용 OTP의 생성을 하지 않고 기존의 OTP 값을 그대로 유지할 수 있다. 이에 의하면, 해커에 의한 후순위 접속에 따른 불법적인 사용자 인증 및 이에 의한 정보 탈취를 방지할 수 있다.
이상에서는 확인용 OTP(혹은 서버 검증용 OTP)와 사용자 OTP(혹은 대응 OTP)가 각각 챌린지 앤드 리스폰스 방식과 타임 OTP 방식으로 서로 다른 연산 조건에서 생성되어 상호간 페어링되는 값을 갖게 되는 경우를 위주로 설명하였다. 다만, 앞선 설명은 일 예시에 불과하며, 이와 다른 방식에 의해 상호간 페어링되는 값으로 생성될 수도 있다.
예를 들어, OTP 생성키 및 OTP 생성 방식을 모두 동일하게 하되, 연산 조건으로서 서로 다른 모드 구별자를 적용함으로써 상호간 페어링되는 값을 갖도록 할 수도 있다. 이에 대하여 보다 구제척 예를 들어 설명하면, 양자 모두(즉, 확인용 OTP와 사용자 OTP, 또는 서버 검증용 OTP와 대응 OTP) 세션 ID를 OTP 생성키로 하고, 양자 모두 타임 OTP 방식에 의해 생성하되, 어느 하나는 모드 구별자로서 1을, 다른 하나는 모드 구별자로서 2를 더 추가하여 OTP를 생성함으로써 상호간 페어링되는 값을 갖도록 할 수도 있다.
즉, OTP 생성의 시드 값으로서의 OTP 생성키는 동일하게 하되, 그 연산 조건을 1가지 이상 상이하게 적용함으로써, 상호간 페어링되는 값으로 생성되게 하는 한도 내에서, 이외에도 더욱 다양한 변형례들이 존재할 수 있으며, 이는 모두 본 발명의 실시예에 포괄될 것이다.
이상에서는 OTP 게시 화면에 OTP 입력창이 표출되며, 또한 OTP 입력창에 사용자 OTP를 서비스 사용자가 직접 입력하는 방식을 중심으로 설명하였지만, 반드시 이와 같을 필요는 없으며 동일 효과를 달성하는 다양한 방식으로의 변형이 가능함은 물론이다. 예를 들어, OTP 게시 화면에는 서버 검증용 OTP만을 게시하고, 사용자 OTP 입력을 위한 OTP 입력창은 별도로 게시하지 않을 수도 있다. 또한, 사용자 OTP는 서비스 사용자에 의해 직접 입력되지 않고, 특정 제스처를 통해서 입력에 갈음할 수도 있다. 예를 들어, 확인용 OTP를 통해 서버 검증용 OTP의 진위가 확인되었을 때, 사용자가 모바일 기기의 터치 스크린을 통해 표출된 사용자 OTP를 단순 터치 선택하는 행위, 해당 화면을 위쪽 방향으로 밀어올리는 터치 제스처 등의 다양한 제스처를 취함으로써, 사용자 OTP의 자동 입력이 이루어지도록 구현될 수도 있다.
단계 S11을 통해 사용자 OTP 값이 입력된 경우, 온라인 서비스 서버(130)는 OTP 인증 서버(150)로 입력된 사용자 OTP 값의 확인을 요청(즉, 사용자 인증을 요청)할 수 있다[도 1의 단계 S12 참조].
이에 따라, 도 1의 단계 S13을 참조하면, OTP 인증 서버(150)의 대응 OTP 생성부(155)는, 앞선 단계 S10에서 OTP 생성기(120)에서 생성된 사용자 OTP와 동일 조건을 적용하여 대응 OTP를 생성한다. 그리고 OTP 인증 서버(150)의 인증 처리부(157)는 생성된 대응 OTP와 입력된 사용자 OTP 간의 일치 여부를 비교함으로써, 해당 서비스 사용자에 대한 사용자 인증을 수행할 수 있다. 이때, 인증 결과는 온라인 서비스 서버(130)로 통보되며[도 1의 단계 S14 참조], 인증이 정상적으로 이루어진 경우 온라인 서비스 서버(130)는 해당 서비스 사용자에게 해당 서비스를 개시할 수 있다[도 1의 단계 S15 참조].
이상에서는 일 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법에 대하여 설명하였다. 이하에서는 본 발명의 다른 실시예에 따른 상호 인증 방법에 대하여 도 7 및 도 8을 참조하여 설명하기로 한다. 여기서, 도 7은 본 발명의 다른 실시예에 따른 OTP를 이용한 상호 인증 방법을 설명하기 위한 도면이고, 도 8은 도 7에 의할 때의 모바일 기기 상의 화면 표출 예시이다. 도 7 및 도 8을 참조한 본 발명의 다른 실시예에 따른 상호 인증 방법을 설명하는 과정에서 앞서 도 1 ~ 도 6을 참조하여 설명한 상호 인증 방법에서와 중복될 수 있는 내용에 관해서는 그 상세한 설명은 생략하기로 한다.
도 7은 서비스 검증 대상인 온라인 서비스 서버를 결제 서버(130A)로서 특화시켰을 때 사용자 소유의 모바일 기기에 설치된 결제 앱(120A)을 이용하여 결제 서비스를 진행함에 있어서 본 발명의 실시예에 따른 상호 인증 방법이 적용되는 케이스를 도시한 것이다. 여기서, 검증 모듈(120B)은 앞서 설명한 도 1의 OTP 생성기(120)와 본질적으로 동일 또는 유사한 기능은 수행하게 된다. 검증 모듈(120B)은 별도의 앱으로 구현될 수도 있지만, 결제 앱(120A)의 일부 기능으로서 결제 앱(120A) 내에 함께 구현될 수도 있음은 물론이다. 이에 따라, 본 예에서, 결제 앱(120A)과 검증 모듈(120B)은 하나의 애플리케이션 프로그램으로 구현(도 7의 도면부호 AA 참조)되어 사용자 소유의 모바일 기기(도 1의 도면부호 110 참조)에 설치된 것으로 가정한다.
도 7의 단계 S1에서와 같이 결제 앱(120A)이 구동됨에 따라 사용자에 의한 PIN(personal identification number) 입력 및 이에 관한 검증(즉, 입력된 PIN 번호의 검증)이 완료되면(도 8의 (a) 참조), 결제 앱(120A)은 도 7의 단계 S2에 따라 검증 모듈(120B)로부터 사용자 시리얼을 추출하고, 도 7의 단계 S3에 따라 결제 서버(130A)로 서버 검증용 OTP를 요청할 수 있다.
이때, 사용자 시리얼은 결제 앱(120A)과 검증 모듈(120B)이 하나의 앱으로서 OTP 인증 서버(150A)에 등록될 때 사용된 사용자 고유값일 수 있다. 이러한 사용자 시리얼은 상기 서버 검증용 OTP 요청시 함께 결제 서버(130A)로 전송될 수 있다. 이하 이를 기준하여 설명하기로 한다.
사용자 시리얼과 함께 서버 검증용 OTP 요청이 수신되면, 결제 서버(130A)는 이를 OTP 인증 서버로 전달하고[도 7의 단계 S4 참조], 이에 따라 OTP 인증 서버(150A)는 서버 검증용 OTP를 생성한다[도 7의 단계 S5 참조].
OTP 인증 서버(150A)를 통한 서버 검증용 OTP의 생성 방법으로는 앞서 도 1 ~ 도 6을 통해 설명한 바와 같이 다양한 방법이 이용될 수 있다. 다만, 본 예에서는 서버 검증용 OTP 생성의 시드값으로서 개인키, 결제 서버의 IP 주소, 결제 서버에서 자체 생성한 세션 ID가 이용되고, 챌린지 앤드 리스폰스 방식으로 서버 검증용 OTP가 생성되는 것으로 가정하기로 한다. 이때, 상기 개인키는 사용자 시리얼에 의해 확인된 해당 사용자에 상응하여 보관된 소정의 키 값이 이용될 수 있고, 경우에 따라서는 상기 사용자 시리얼 값이 그대로 이용될 수도 있다. 이러한 경우, OTP 인증 서버(150A)는 서버 검증용 OTP의 생성을 위해서, 결제 서버(130A)로부터 결제 서버(130A)의 IP 주소, 결제 앱(130A)과의 통신 접속을 위해 할당된 세션 ID를 받아올 필요가 있다. 일 실시예에서, 상기 결제 서버(130A)의 IP 주소, 세션 ID는 도 7의 단계 S4를 통해서 결제 서버(130A)로부터 OTP 인증 서버(150A)로 전달될 수 있다.
OTP 인증 서버(150A)는 서버 검증용 OTP 생성에 사용된 OTP 생성 조건을 검증 모듈(120B)로 전송할 수 있다[도 7의 단계 S6 참조]. 이때, OTP 인증 서버(150A)로부터 검증 모듈(130B)로의 OTP 생성 조건의 전송 방법은 앞서 설명한 도 1의 단계 S7에서와 본질적으로 동일하므로 이에 대한 중복되는 설명은 생략하기로 한다. 즉, 도 7에서는 도 1의 푸시 서버(160) 등을 직접 도시하지는 않았지만, 본 단계는 앞선 도 1의 단계 S7에서와 동일한 방식에 의할 수 있다.
또한 OTP 인증 서버(150A)는 도 7의 단계 S5에 따라 생성된 서버 검증용 OTP를 결제 서버(130A)로 전달하며[도 7의 단계 S7 참조], 결제 서버(130A)는 전달받은 서버 검증용 OTP를 결제 앱(120A)으로 전송할 수 있다[도 7의 단계 S8 참조]. 이 경우, 결제 앱(120A)은 수신한 서버 검증용 OTP를 검증 모듈(120B)로 전달할 수 있다[도 7의 단계 S9 참조]. 다만, OTP 인증 서버(150A)에 의해 생성된 서버 검증용 OTP는 반드시 상기 단계 S7, S8, S9를 통해서 검증 모듈(120B)로 전달될 필요는 없다. 예를 들어, 단계 S6에 따른 OTP 생성 조건의 전송 과정에서 서버 검증용 OTP가 함께 전송될 수도 있을 것이다. 다만 본 명세서에서는 설명의 편의 및 집중을 위해 전자의 방식에 의하는 경우를 중심으로 설명하기로 한다.
이에 따라 검증 모듈(120B)은 앞선 단계 S6을 통해서 수신한 OTP 생성 조건을 참조하여 서버 검증용 OTP에 대응되는 확인용 OTP를 생성하고, 단계 S9를 통해 수신한 서버 검증용 OTP와 자체 생성한 확인용 OTP 간의 일치 여부를 비교함으로써 서버 검증을 수행할 수 있다[도 7의 단계 S10 참조].
상술한 단계를 통해, 서버 검증이 완료되면, 검증 모듈(120B)은 사전 지정된 방식에 따라 사용자 OTP를 생성하고[도 7의 단계 S11 참조], 생성된 사용자 OTP를 결제 앱(120A)으로 전달할 수 있다[도 7의 단계 S12 참조]. 이때, 전달된 사용자 OTP는 결제 앱(120A)으로부터 결제 서버(130A)로 전송되고[도 7의 단계 S13 참조], 다시 OTP 인증 서버(150A)로 전송될 수 있다[도 7의 단계 S14 참조].
여기서, 검증 모듈(120B)에서의 사용자 OTP의 생성 방법 역시 앞서 도 1 ~ 도 6을 통해 설명한 다양한 방식들이 적용될 수 있다. 다만, 본 예에서는 사용자 OTP 생성의 시드값으로서 앞서 서버 검증용 OTP의 시드값으로 사용하였던 개인키와 세션 ID를 그대로 사용하되, 검증 모듈(120B)이 설치된 모바일 기기의 사설 IP 주소를 추가 시드값으로 하여, 타임 OTP 방식을 적용하여 사용자 OTP를 생성하는 것으로 가정하기로 한다. 즉, 본 예에서는, 사용자 OTP와 서버 검증용 OTP는 개인키와 세션 ID를 동일 생성키로 활용하되, 서버 검증용 OTP 생성 과정에서는 서버 IP 주소를 추가 시드값으로 하여 챌린지 앤드 리스폰스 방식으로 OTP를 생성하고, 사용자 OTP 생성 과정에서는 모바일 IP 주소를 추가 시스값으로 하여 타임 OTP 방식으로 OTP를 생성함으로써, 상호 간 페어링되는 값으로 OTP가 생성될 수 있다. 다만, 본 발명의 다른 실시예에 따른 상호 인증 방법에서는 시스템 구현 방식에 따라서 반드시 사용자 OTP와 서버 검증용 OTP가 페어링되는 값으로 구현되어야 할 제한 사항이 있는 것은 아니다.
도 7의 단계 S14에 따라 사용자 OTP 검증 요청이 수신되면, OTP 인증 서버(150A)는 수신된 사용자 OTP에 대응되는 대응 OTP를 도 7의 단계 S11에서와 동일 생성 조건으로 생성하고, 수신된 사용자 OTP와 자체 생성한 대응 OTP 간의 일치 여부를 비교함으로써, 사용자 인증을 수행한다[도 7의 단계 S15 참조]. 이때의 사용자 인증 결과는 결제 서버(130A)로 전송되며[도 7의 단계 S16 참조], 인증 결과에 따라 서비스 접속한 사용자가 정당한 사용자로 판별된 경우 결제 서버(130A)는 해당 서비스를 진행한다[도 7의 단계 S17 참조]. 사용자 인증이 완료된 상태에서 사용자 소유의 모바일 기기의 화면을 통해 표출되는 결제 앱 화면이 도 8의 (b)에 예시되고 있다.
도 8의 (a) 및 (b)를 참조할 때, 앞서 설명한 도 5 및 도 6에서와 화면 표출 방식이 상이함을 확인할 수 있다. 도 8을 참조할 때, 도 7에 따른 본 발명의 다른 실시예의 상호 인증 방법에서는 도 5 및 도 6에서와는 달리 서버 검증용 OTP와 사용자 OTP가 서비스 사이트 화면 및 앱 화면을 통해서 화면 표출되지 않고 있다. 즉, 도 7의 실시예에 의할 때, 서버 검증용 OTP와 사용자 OTP는 사용자에게 노출되지 않고 시스템 내부적으로 수행되는 상호 인증에만 이용된다. 따라서 도 7의 단계 S1에 따라 사용자가 PIN 번호를 입력하는 과정(도 8의 (a) 참조) 이후, 도 7의 단계 S2 ~ 단계 S16의 일련의 과정은 시스템 내부적으로 처리되며, 그 일련의 과정에 따라 상호 인증이 완료되면 도 8의 (b)의 서비스 개시 화면이 바로 앱 화면에 표출되게 되는 것이다.
본 실시예에 의하면, 사용자 인증을 위해서 OTP 값을 입력하는 화면을 통해서 서버가 제시한 서버 검증용 OTP를 검증한 후, 사용자가 사용자 인증용 OTP 값을 입력하게 함으로써, 서비스 제공 서버에 대한 검증과 사용자 인증을 동시에 수행할 수 있는 효과가 있다.
[제2 실시예 - 상호 인증 방법 및 시스템 #2] (Dual Check)
본 실시예는 인증 방법 및 시스템에 관한 것으로서, 보다 구체적으로는 온라인 서비스 서버와 클라이언트 간의 상호 인증 방법 및 시스템에 관한 것이다.
편리한 전자 금융 서비스나 중요한 온라인 서비스를 안전하게 활용하고자 할 때 온라인 서비스에서 사용되는 아이디와 암호 이외에 별도의 인증 방법을 구성하여 사용자 인증에 대한 안전성을 높이고 있다. 대표적으로 OTP 동글, SMS를 통한 일회용 비밀번호, ARS를 통한 일회용 비밀번호, 모바일 앱(Mobile App) 기반 본인 생체인증 등을 활용하여 아이디 패스워드 도용에 따른 본인 인증을 강화하고 있다.
그러나 종래 추가 인증 수단들은 온라인 서비스와 인증 매체 간에 발생한 일회용 비밀번호를 사용자가 직접 입력하게 하거나, 별도의 생체 정보를 입력하는 등과 같이 사용자의 번잡한 입력을 요구하게 된다. 특히 모바일 폰으로 4~6자리의 임시 비밀번호를 재입력해야 되면, 모바일 폰 화면을 통해 확인되는 번호를 숙지하기도 어려울 뿐만 아니라 입력하기도 번잡하다.
이러한 임시 비밀번호의 입력을 없애기 위해서 사용자가 서비스에 아이디와 패스워드로 로그 온하면 푸시 정보를 모바일 폰에 보내고, 사용자가 본인 확인 인증 앱을 구동하면 본인의 생체정보(지문, 얼굴, 홍채 등)를 모바일 앱에 입력하도록 함으로써, 본인이 맞으면 자동으로 온라인 서비스를 로그인 해주는 서비스가 있는데, 이 역시 생체정보를 입력하기 위한 번잡함이 발생한다.
또 다른 간편 인증 방식으로는 사용자의 입력을 최소화 시키고자 사전에 사용자의 지정된 모바일 폰에 접속 승인 여부를 결정하는 접속 제어 앱을 설치한 상태에서, 사용자가 온라인 서비스에 아이디와 패스워드를 입력하면 모바일 푸시 메시지로 사용자 접속을 알려주고, 사용자가 접속 승인 앱을 구동하면 온라인 서비스의 접속 여부를 승인하거나 거절하는 접속 확인 방식도 있었다. 그러나 이 방식은 사용자가 접속한 서비스가 파밍(pharming)된 해커의 사이트인 경우, 사용자가 입력한 아이디와 패스워드를 해커가 역이용하여 실제 온라인 서비스에 전송하면 사용자는 자신의 모바일 폰에 접속 확인 요청이 왔을 때 본인의 접속으로 오해하고 해당 접속을 승인해주게 되는 문제가 발생하게 된다. 뿐만 아니라 사용자의 아이디와 패스워드를 알고 있는 해커가 실제 사용자가 접속하자 마자, 해당 사용자의 아이디와 패스워드로 접속을 하게 되면 사용자는 자신의 스마트폰에 도착한 최종 접속 내용을 자신의 것으로 오해하고 해당 접속을 승인하게 해줄 수도 있다.
따라서 사용자가 임시 비밀번호를 재입력하는 번잡함이 없으면서도, 해당 사이트가 정상인지 인지를 판단할 수도 있고, 자신의 접속인지 아닌지 까지 확인할 수 있는 개선된 방법과 기술이 필요하다.
본 실시예는 온라인 서비스의 안전한 사용을 위해 2팩트 인증(즉, 서비스 인증 및 사용자 인증에 따른 상호 간 인증)을 수행할 때, 별도의 일회용 암호나 생체 정보를 입력하지 않고도 올바른 서비스인지에 대해서 사용자가 확인한 후 편리하게 접속이 진행될 수 있도록 하는 간편 인증을 위한 방법 및 시스템을 제공한다.
이하의 설명에서, 간편 인증기는 사용자 소유의 모바일 기기에 애플리케이션 프로그램의 형태로 설치된 소프트웨어 방식의 인증 장치인 경우를 중심으로 설명하지만, 반드시 이에 한정되는 것은 아님은 물론이다. 예를 들어, 간편 인증기는 통신 기능을 갖춘 하드웨어 인증 디바이스일 수도 있다. 다만, 이하에서는 설명의 편의 및 집중을 위해 전자의 케이스를 가정하여 본 발명의 실시예를 설명하기로 한다.
또한, 이하에서는 도 9를 기준으로 온라인 서비스 서버에 접속하는 접속단말인 클라이언트 단말과 간편 인증기가 물리적으로 별개로 구성된 경우를 가정하여 설명하지만, 간편 인증기는 클라이언트 단말과 일체적으로 구현될 수도 있다. 후자의 경우라면 도 9에 도시된 모바일 기기는 생략될 것이다. 또한, 클라이언트 단말 자체가 모바일 기기일 수도 있음은 자명하다.
도 9는 본 발명의 실시예에 따른 온라인 서비스 서버와 서비스 사용자 간의 상호 인증 방법 및 시스템을 설명하기 위한 도면이다. 또한, 도 10은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 인증 서버에 관한 일 실시예의 블록도이고, 도 11은 본 발명의 실시예에 따른 상호 인증 방법을 구현하는 간편 인증기에 관한 일 실시예의 블록도이다. 이하, 도 9를 중심으로 도 10 및 도 11을 참조하여, 본 발명의 실시예에 따른 상호 인증 방법 및 시스템을 설명한다.
또한, 본 발명의 실시예의 설명 과정에서, 도 12 ~ 도 17를 함께 참조한다. 여기서, 도 12는 온라인 서비스 서버에 의해 운영되는 온라인 서비스 사이트에 간편 인증번호가 게시되는 화면과 관련된 예시이고, 도 13은 간편 인증기에 의해 생성된 검증용 인증번호가 표출되는 화면과 관련된 예시이며, 도 14는 도 9의 상호 인증 방법에 따른 인증 과정에서 해커에 의한 접속 시도시 처리 방법을 설명하기 위한 도면이고, 도 15는 도 14과 같은 해커에 의한 접속 시도시의 온라인 서비스 서버에 의해 운영되는 온라인 서비스 사이트에 게시되는 처리 결과를 예시한 도면이다. 또한 도 16 및 도 17은 사용자의 모바일 기기를 통해 온라인 서비스 서버에 접속하였을 때의 본 발명의 실시예에 따른 상호 인증 방법의 구현 예시이다.
도 9의 단계 S1을 참조하면, 온라인 서비스 서버(230)가 제공하는 온라인 서비스 사이트에 의한 온라인 서비스를 이용하고자 하는 경우, 서비스 사용자는 온라인 서비스 서버(230)에 접속 요청을 한다.
예를 들어, 이용하고자 하는 온라인 서비스가 온라인 뱅킹 서비스인 경우, 사용자는 해당 온라인 뱅킹 서비스를 제공하는 특정 온라인 서비스 서버(즉, 온라인 뱅킹 서비스를 제공하는 특정 은행 서버)에 접속할 수 있다. 온라인 서비스 서버(230)로의 접속은 사용자 자신이 소유하는 모바일 기기(210)(예를 들어, 스마트폰 등)를 통한 모바일 접속에 의할 수 있음은 물론이나, 도 9에서는 사용자 소유의 모바일 기기(210)와는 별개의 클라이언트 단말(200)(예를 들어, 회사 PC 등)을 통해서 접속하는 경우를 예시하였다.
도 9의 단계 S2를 참조하면, 온라인 서비스 서버(230)로의 접속 요청에 따라, 온라인 서비스 서버(230)는 온라인 서비스를 이용하고자 하는 서비스 사용자에게 사용자 계정 정보의 입력을 요청할 수 있다. 여기서, 사용자 계정 정보는, 사용자 등록 절차(또는 서비스 가입 절차)를 통해서 해당 온라인 서비스 서버(230)에 미리 저장(등록)되어 있는 해당 사용자의 식별 정보를 의미한다. 통상적으로, 사용자 계정 정보로는 사용자 ID(Identifier)와 패스워드(password)가 활용될 수 있다. 다만, 해당 온라인 서비스를 이용하는 사용자를 식별할 수 있는 정보라면, 상기 사용자 계정 정보로서 이외에도 다양한 정보(예를 들어, 해당 사용자의 이메일 주소, 전화번호, PKI(Public Key Infrastructure) 기반의 인증서 상의 인증서 암호 등)가 대체 활용될 수 있음은 물론이다.
도 9의 단계 S3을 참조하면, 사용자 계정 정보의 입력 요청에 따라, 서비스 사용자는 사용자 계정 정보를 해당 온라인 서비스 사이트에 입력한다. 도 9의 단계 S4를 참조하면, 서비스 사용자로부터 사용자 계정 정보가 입력되면, 온라인 서비스 서버(230)는 사용자로부터 입력된 사용자 계정 정보와 일치하는 계정이 존재하는지를 확인한다. 이러한 계정 정보의 확인에는 도 9에 도시된 바와 같은 계정 DB(240)가 활용될 수 있다. 계정 DB(240)에는 해당 온라인 서비스 서버(230)를 통한 온라인 서비스를 제공받을 수 있는 사용자들(즉, 회원들)에 관한 계정 정보들이 보관된다. 도 9에서는 계정 DB(240)가 온라인 서비스 서버(230)와 별개로 구비되는 경우를 예시하였지만, 계정 DB(240)는 온라인 서비스 서버(230)와 통합되어 구현될 수도 있음은 물론이다. 또한, 시스템 구현 방식에 따라, 계정 DB(240)는 인증 서버(250)와 통합되어 구현될 수도 있을 것이다.
도 9의 단계 S5를 참조하면, 입력된 사용자 계정 정보가 계정 DB(240)에 보관된 사용자 계정과 일치하는 경우, 온라인 서비스 서버(230)는 인증 서버(250)로 간편 인증번호의 생성을 요청한다. 여기서, 간편 인증번호는 사용자가 현재 접속한 온라인 서비스 사이트가 진정한 온라인 서비스 제공자에 의해 제공된 것인지 여부를 사용자가 판별할 수 있도록 하기 위한 용도로서 활용된다.
도 9의 단계 S5에서, 온라인 서비스 서버(230)가 인증 서버(250)로 간편 인증번호의 생성 요청을 할 때, 온라인 서비스 서버(230)는 해당 서비스 사용자의 사용자 계정 정보를 함께 인증 서버(250)로 전송할 수 있다. 예를 들어, 온라인 서비스 서버(230)는 사용자 계정 정보로서 해당 사용자의 사용자 ID를 포함하는 간편 인증번호 생성 요청을 인정 서버(250)로 전송할 수 있다.
또한 일 실시예에 의할 때, 온라인 서비스 서버(230)는 도 9의 단계 S5를 통해서(혹은 별개의 단계를 통해서) 클라이언트 접속환경정보를 인증 서버(250)로 추가 전송할 수도 있다. 여기서, 클라이언트 접속환경정보란, 온라인 서비스 서버(230)에 접속한 해당 서비스 사용자의 접속단말에 관한 접속환경을 직접 또는 간접적으로 나타낼 수 있는 정보를 통칭한다. 이러한 클라이언트 접속환경정보는 서비스 서버에 따라 다양할 수 있다.
예를 들어, 표준 웹 서버를 예로 들면 접속한 클라이언트 단말기의 값을 추출할 수 있는 다양한 서버 변수(Server Variables; 호스트 네임(REMOTE_HOST), 쿠키 정보(HTTP_COOKIE), 이전 URL(HTTP_PEFERER), 한 단계 앞의 IP 주소(HTTP_X_FORWARDED_FOR), 현재 IP 주소(REMOTE_ADDR), 클라이언트 브라우져(HTTP_USER_AGENT), 클라이언트 언어(HTTP_ACCEPT_LANGUAGE))이거나, 클라이언트 단말에 서비스를 제공하는 서비스 서버의 변수(서버 호스트명, 서버 IP, 세션 아이디값, 세션 최대 유효시간 등)로 구성될 수 있다. 다른 예로, 접속하는 클라이언트가 표준 웹 브라우저가 아니라 자체 클라이언트 프로그램인 경우 운영체제(OS)가 허용하는 범위 내에서 클라이언트 단말기의 다양한 시스템 변수(Mac Address, HDD UUID 등)를 클라이언트 접속환경정보로서 이용할 수 있을 것이다.
상술한 바와 같은 간편 인증번호의 생성 요청은 인증 서버(250)의 통신 인터페이스부(251)를 통해 접수(수신)되며, 함께 전송된 사용자 계정 정보 또는/및 클라이언트 접속환경정보는 상기 간편 인증번호의 생성에 시드값으로서 활용될 수 있다.
도 9의 단계 S6을 참조하면, 온라인 서비스 서버(230)로부터의 간편 인증번호 생성 요청에 따라, 인증 서버(250)는 간편 인증번호를 생성한다. 이때, 간편 인증번호의 생성은 인증 서버(250)의 간편 인증번호 생성부(253)에 의해 수행될 수 있다.
이때, 간편 인증번호는 온라인 서비스 서버(230)로부터 전달된 클라이언트 접속환경정보를 이용하여 생성할 수 있음은 앞서 설명하였는 바, 이하에서는 이러한 클라이언트 접속환경정보를 대체하여 활용되거나 또는 클라이언트 접속환경정보와 함께 상기 간편 인증번호 생성을 위한 추가 시드값으로서 활용될 수 있는 기타 실시예들에 대하여 상세히 설명하기로 한다.
본 발명의 일 실시예에서, 간편 인증번호의 생성을 위한 시드 값으로는 서비스 사용자의 사용자 계정 정보에 대응하여 사전 등록된 고정키가 이용될 수 있다.
일 예로, 사용자 계정 정보에 대응하는 고정키는, 전술한 사용자 ID, 패스워드, 사용자의 이메일 주소, 전화번호, 인증서 암호 등과 같은 다양한 사용자 식별 정보 중 어느 하나 또는 적어도 10개의 조합이 사전 등록되어 이용될 수 있다. 다른 예로, 사용자 계정 정보에 대응하는 고정키는, 사용자 소유의 모바일 기기(예를 들어, 스마트폰 등)의 폰 번호, 제품 일련번호, 유심(USIM) 카드번호, 맥 어드레스(MAC address) 등과 같은 식별자 중 어느 하나 또는 적어도 10개의 조합이 사전 등록되어 이용될 수도 있다. 또 다른 예로, 사용자 계정 정보에 대응하는 고정키는, 사용자가 간편 인증 서비스에 등록할 때에 자신이 직접 선택하여 등록한 또는 간편 인증 서비스 등록시에 부여된 개인키가 이용될 수도 있다.
본 발명의 다른 실시예에서, 인증번호 생성을 위한 시드 값으로는 사용자가 해당 온라인 서비스 서버에 접속하는 시점에 동적으로 할당되는 동적 할당키가 이용될 수 있다.
일 예로, 상기 동적 할당키로는, 해당 온라인 서비스 서버로 접속하는 서비스 사용자의 접속단말 연결정보가 이용될 수 있다. 이때, 접속단말 연결정보로는 서비스 사용자의 접속시 해당 온라인 서비스 서버에서 서비스 사용자의 접속단말에 할당하는 세션 정보(예를 들어, 세션 ID(Session ID) 등) 또는 소켓 정보(예를 들어, 소켓 핸들(Socket handle) 등)가 이용될 수 있다.
여기서, 세션 ID는 서버와 접속단말 간의 연속적인 데이터 송수신을 관리하기 위해 해당 서버에 의해 부여되는 값이고, 소켓 핸들 정보는 서버와 접속단말 간에 네트워크를 통해 데이터를 송수신하는 단위인 소켓을 관리하기 위해 해당 서버가 자체적으로 할당한 임의의 연결 고유값이다. 이러한 세션 ID 또는 소켓 핸들 정보는 동적으로 할당됨은 물론 해당 서버에 의해 자체적으로 부여되는 값으로서, 서버 외부에서 해커에 의해 탈취되기 어렵기 때문에, 이를 이용하는 경우 보안 상 유리한 효과가 있다.
다른 예로, 상기 동적 할당키로는, 서비스 사용자 소유의 모바일 기기에 이동통신사가 동적으로 할당한 모바일 IP 주소(IP 주소 전체 또는 일부분일 수 있음)가 이용될 수도 있다. 예를 들어, 서비스 사용자가 자신의 모바일 기기를 통해서 해당 온라인 서비스 서버로 접속하는 경우를 가정하면, 이때 이동통신사에 의해 동적으로 할당된 모바일 IP 주소를 시드값으로 이용할 수 있을 것이다.
또한 이상에서는 시드값으로서 특정 값이 이용되는 경우를 중심으로 설명하였지만, 간편 인증번호 생성을 위한 시드값으로는 인증 서버(250)에서 자체적으로 랜덤하게 생성하는 랜덤값이 이용될 수도 있음은 물론이다.
이에 따라, 인증 서버(250)의 간편 인증번호 생성부(253)는 상술한 바와 같은 적어도 하나의 시드값들을 이용하되, 시간 또는 시도 횟수(즉, 간편 인증번호 발급 시도 횟수)를 연산 조건으로 하여 간편 인증번호를 생성할 수 있다. 예를 들어, 간편 인증번호 생성부(253)는 상술한 적어도 하나의 시드값에 시간 또는 시도횟수를 곱한 값을 특정 해시 함수(hash function)에 따라 암호화한 값으로 생성될 수 있다. 이에 따라 간편 인증번호는 일회성을 갖는 값으로 생성될 수 있다.
또한 여기서, 타임 OTP 방식은 연산 조건으로서 생성 시간을 이용하여 OTP를 생성하는 방식이다. 이에 의할 때, OTP는 결정된 특정 OTP 생성키에 연산 조건인 생성 시간을 곱한 값을 특정 해시 함수에 따라 암호화한 값으로 생성될 수 있다.
상술한 바와 같이, 간편 인증번호가 생성되면, 인증 서버(250)는 통신 인터페이스부(251)를 통해서 앞선 단계 S6을 통해서 생성된 간편 인증번호를 온라인 서비스 서버(230)로 전달한다. 전달된 간편 인증번호는 도 9의 단계 S9에 따라 온라인 서비스 서버(230)에 의해 운영되는 온라인 서비스 사이트의 화면을 통해 사용자가 확인할 수 있도록 게시된다. 이에 관한 일 예가 도 12에 도시되고 있다. 도 12를 참조하면, 온라인 뱅킹 사이트의 우측의 인증번호 게시 화면을 통해서 간편 인증번호(도 12의 도면부호 30A 참조)가 게시되고 있음을 확인할 수 있다. 간편 인증번호가 화면 상에 게시된 이후, 사용자로부터의 확인이 완료되기 전까지는 승인 대기 상태가 지속될 수 있다[도 9의 단계 S10 참조].
또한, 도 9의 단계 S8을 참조하면, 인증 서버(250)는 통신 인터페이스부(251)를 통해서 간편 인증번호의 생성 조건이 서비스 사용자 소유의 모바일 기기(110)에 설치된 간편 인증기(220)로 전송되도록 한다.
도 9에서 단계 S8의 간편 인증번호 생성 조건의 전송은 푸시 서버(260)를 통해서 수행되는 것으로 예시하고 있지만, 반드시 이와 같을 필요는 없으며, 인증 서버(250)에서 직접 간편 인증기(220)로 전송될 수도 있음은 물론이다. 또한, 도 9에서는 푸시 메시지를 통해서 간편 인증번호의 생성 조건을 전송하는 케이스를 중심으로 도시하였지만, 간편 인증번호 생성 조건의 전송은 소켓 데이터 통신에 의한 전송 방식에 의할 수도 있다.
푸시 서버(260)를 통해 간편 인증번호 생성 조건을 전송하는 경우, 인증 서버(250)는 그 생성 조건을 푸시 서버(260)로 전달하고, 이때 푸시 서버(260)는 푸시 메시지를 통해서 간편 인증번호 생성 조건을 간편 인증기(220)로 전송할 수 있다. 여기서, 푸시 메시지는 특정 모바일 운영체제에서 앱(App) 별로 제공하는 메시지 서비스일 수 있다. 다만, 간편 인증번호 생성 조건의 전송을 반드시 푸시 메시지에 의할 필요는 없음은 자명하며, SMS, MMS 등의 상용의 다양한 메시징 서비스에 의할 수도 있고, 특정 통신 프로토콜에 의하여도 무방하다. 간편 인증번호 생성 조건의 전송을 푸시 메시지에 의하지 않는 다른 예시적 케이스들에서, 전술한 푸시 서버(260)는 일반적인 통신 서버로서 그 기능이 대체될 수 있다.
또한 도 9에서는 간편 인증번호 생성 조건이 간편 인증기(220)로 직접 전송되는 케이스를 중심으로 설명하였지만, 반드시 이와 같을 필요는 없다. 예를 들어, 간편 인증번호 생성 조건은 푸시 메시지 등을 통해서 모바일 기기(210)로 전송되고, 간편 인증기(220)가 이를 읽어들여 간편 인증번호 생성 조건을 수신(취득)할 수 있음은 자명하다. 이러한 간편 인증번호 생성 조건의 수신은 간편 인증기(220)의 통신 인터페이스부(221)에 의해 이루어질 수 있다.
상술한 도 9의 단계 S8을 통해 전송될 간편 인증번호 생성 조건은, 도 9의 단계 S6에서 간편 인증번호의 생성에 활용된 시드값 및 연산 조건 전부일 수도 있지만, 그 일부 일 수도 있다. 예를 들어, 인증 서버(250)와 간편 인증기(220)가 각각 간편 인증번호 생성에 활용되는 시드값 및 연산 조건 중 일부를 사전에 보관하고 이를 공통적으로 사용하는 경우라면, 그와 같이 사전 보관된 조건은 별도로 전송해줄 필요가 없기 때문이다.
이에 따라, 간편 인증기(220)는 수신한 생성 조건을 이용하여 온라인 서비스 서버(230)의 온라인 서비스 사이트 화면을 통해 표출된 간편 인증번호의 검증을 위한 검증용 인증번호를 생성할 수 있다[도 9의 단계 S11 참조]. 이와 같은 검증용 인증번호의 생성은 간편 인증기(220)의 검증용 인증번호 생성부(223)에 의해 수행될 수 있다.
이와 같이 생성된 검증용 인증번호는 간편 인증기(220)의 인증번호 표출부(227)을 통해서 모바일 기기(210)의 앱 화면을 통해 표시될 수 있다. 이때, 앱 화면을 통해 검증용 인증번호(도 13의 도면부호 30B 참조)가 표출된 예가 도 13에 도시되고 있다.
이상에서 전술한 단계 S7 ~ 단계 S11은, 반드시 도 9에 도시된 순서에 한정될 필요는 없으며, 서로 선후를 달리하거나 동시에 이루어질 수도 있다.
상술한 과정을 통해서 앱 화면을 통해서 검증용 인증번호가 표출되면, 사용자는 이와 같이 표출된 검증용 인증번호와 온라인 서비스 사이트 화면을 통해 표출된 간편 인증번호 간을 비교함으로써 해당 온라인 서비스 서버가 진정한 서비스 서버임(즉, 서비스 서버의 진위)을 판별해낼 수 있다.
비교 결과, 간편 인증번호와 검증용 인증번호가 일치하는 경우, 사용자는 도 13에 도시된 앱 화면 상의 승인 버튼을 선택함으로써, 해당 서비스에 관한 승인 처리(즉, 해당 온라인 서비스 서버가 진정한 서비스 서버임을 검증 완료 처리)를 할 수 있다[도 9의 단계 S12 참조].
도 13에서는 앱 화면에 표출된 검증용 인증번호의 하단에 해당 서비스에 대한 승인 처리를 할 수 있는 승인 버튼이 구비된 경우를 예시하였지만, 이 외에도 다양한 변형이 가능함은 물론이다. 예를 들어, 해당 서비스에 대한 승인 또는 취소 처리는 사용자의 특정 제스처에 의할 수도 있다. 예를 들어, 사용자가 모바일 기기의 앱 화면을 위쪽 방향으로 밀어올리는 터치 제스처를 취하면 승인 처리되고, 아래쪽 방향으로 밀어 내리는 터치 제스처를 취하면 취소 처리되도록 구현될 수도 있는 것이다.
상술한 바와 같이, 해당 서비스에 관한 승인이 이루어지는 경우, 간편 인증기(220)의 추가 검증값 생성부(225)는 추가 검증값을 생성하고, 이를 통신 인터페이스부(221)를 통해서 인증 서버(250)로 전송한다[도 9의 단계 S12 및 단계 S13 참조].
여기서, 추가 검증값은 사용자 인증을 위한 용도로서 사용된다. 즉, 본 발명의 실시예에서는 간편 인증번호의 검증을 통해서 해당 서비스의 진위 여부를 먼저 확인한 이후에, 추가 검증값을 통해서 해당 서비스를 이용하고자 하는 사용자가 정당한 사용자인지 여부를 확인하는 방식이 이용된다. 특이한 점은, 본 발명의 실시예에 의할 때, 사용자 인증을 위한 추가 검증값은 앞선 간편 인증번호의 검증을 통한 승인 처리가 완료됨과 동시에 간편 인증기(220)에 의해 자동으로 생성되어 곧바로 인증 서버(250)로 전달된다는 점이다. 이에 의하면, 사용자 인증 과정에서 사용자가 그 사용자 인증값을 온라인 서비스 서버로 직접 입력해야 하는 불편함을 없앨 수 있다.
이때, 추가 검증값은 다양한 방법으로 생성될 수 있다. 추가 검증값의 생성 방법은 앞서 설명한 간편 인증번호의 생성 방식들과 본질적으로 상이하지 않을 것이므로, 이에 관한 구체적인 설명은 생략하기로 한다. 물론, 추가 검증값의 생성은 앞서 설명한 간편 인증번호의 생성 방식을 따를 필요는 없으며, 시스템에서 정의하는 사전 지정된 조건에 따라 생성하여도 무방하다. 그 생성 방식은 후술할 인증 서버(250)에서의 확인용 검증값(즉, 위 추가 검증값에 대응되게 생성된 검증값)의 생성에도 동일하게 적용될 것이다. 따라서, 추가 검증값의 생성 과정에서 인증 서버(250)에 보관되지 않은 정보가 활용된 경우, 해당 정보도 도 9의 단계 S13을 통해서 인증 서버(250)로 전달될 필요는 있다.
또한 도 9에서는 단계 S13에 따른 추가 검증값의 전송이 푸시 서버(260)를 경유하여 이루어지는 것으로 도시되고 있지만, 반드시 이에 의할 필요는 없으며, 인증 서버(250)로 직접 전송되는 방식에 의해도 무방하다.
이에 따라, 인증 서버(250)의 확인용 검증값 생성부(255)는 전송된 추가 검증값을 검증하기 위한 확인용 검증값을 생성하고, 인증 서버(250)의 인증 처리부(257)는 생성된 확인용 검증값과 전송된 추가 검증값 간의 일치 여부를 비교함으로써 해당 서비스 사용자에 대한 사용자 인증을 수행할 수 있다[도 9의 단계 S14 참조]. 이때, 인증 결과는 온라인 서비스 서버(230)로 통보되며[도 9의 단계 S15 참조], 인증이 정상적으로 이루어진 경우 온라인 서비스 서버(230)는 해당 서비스 사용자에게 해당 서비스를 개시할 수 있다[도 9의 단계 S16 참조].
상술한 바에 따르는 본 발명의 실시예에 의하면, 서비스 사용자는 간편 인증번호를 통한 서비스 검증만을 하면 되고 이후의 사용자 인증 과정은 자동으로 수행되므로, 사용자 인증번호 입력 과정이 생략될 수 있어, 전체 인증 절차가 간결하고 편리해지는 효과가 있다.
이상에서는 도 9의 단계 S12를 통해 해당 서비스가 정상 승인되는 경우를 중심으로 설명하였다. 그러나 만일 도 9의 단계 S12를 통해 해당 서비스가 사용자에 의해 승인 불허되는 경우, 간편 인증기(220)는 도 9의 단계 S13을 통해 승인 불허 통지를 할 수 있다.
또한 본 발명의 실시예에 의하면, 인증 서버(250)는 서비스 사용자에 의한 온라인 서비스 서버로의 접속 시도에 따라 간편 인증번호가 생성된 이후, 그 간편 인증번호에 관한 검증 유효시간(예를 들어, 60초) 동안 또는 사용자에 의한 서비스 검증이 완료되기 전까지, 그 생성된 간편 인증번호를 그대로 유지할 수 있다. 이에 관하여 도 14을 참조하여 설명하면 다음과 같다.
도 14을 참조하면, 정상적인 사용자에 의한 서비스 접속에 따라 간편 인증번호가 생성된 이후, 해당 사용자의 사용자 계정 정보를 탈취한 해커에 의한 후순위 접속이 이루어진 경우[도 14의 단계 S21 참조], 온라인 서비스 서버(230)에 의한 간편 인증번호의 생성 요청이 추가 접수되더라도[도 14의 단계 S22 참조], 인증 서버(250)는 인증번호의 재생성을 금지하고 있다[도 14의 단계 S23 참조].
이와 같이, 인증 서버(250)는 간편 인증번호의 검증 유효시간 동안 또는 상기 온라인 서비스 서버에 관한 검증이 완료되기 전까지는 선순위 접속에 따라 생성된 간편 인증번호를 그대로 유지하거나 또는 후순위 접속에 따른 간편 인증번호의 신규 생성을 금지할 수 있다. 이와 같은 후순위 접속자에 대해서는 도 15과 같이 온라인 서비스 사이트의 화면을 통해서 중복 접속이 불가함을 안내하는 화면(도 15의 도면부호 30C 참조)이 표출될 수 있다. 이에 의하면, 해커에 의한 후순위 접속에 따른 불법적인 사용자 인증 및 이에 의한 정보 탈취를 방지할 수 있다.
이상에서는 사용자가 자신 소유의 모바일 기기와 별개의 클라이언트 단말을 통해서 온라인 서비스 서버에 접속한 케이스를 중심으로 설명하였다. 그러나 간편 인증기가 설치된 모바일 기기를 이용해서 직접 온라인 서비스 서버에 접속할 수도 있음은 앞서도 설명한 바이다. 이러한 경우, 간편 인증번호와 검증용 인증번호는 도 16 및 도 17에 도시된 바와 같이 모바일 기기의 화면을 통해 표출될 수 있다. 도 16을 참조하면, 간편 인증기(220)에 의한 앱 화면이 모바일 기기의 화면 상단부(40A)에 표출되고, 온라인 서비스 서버(230)에 의해 제공되는 사이트 화면이 모바일 기기의 화면 하단부(40B)에 표출되고 있다. 그리고 그 화면 화단부(40B)에는 간편 인증번호(40C)가 표출되고 있다. 또한, 도 17를 참조하면, 그 화면 상단부(40A)에 간편 인증기(220)에 의해 생성되는 검증용 인증번호(40D)가 표출되고 있다. 이와 같이 간편 인증기가 설치된 모바일 기기를 이용하여 직접 온라인 서비스 서버에 접속하는 경우에는, 간편 인증기에 의한 앱 화면과 온라인 서비스 서버에 의한 사이트 화면이 서로 다른 화면 영역에 분리되어 표출될 수 있다. 이러한 예로서, 특히 도 16 및 도 17에는 앱 화면이 사이트 화면 상부에 띄워진 형태로 표출(즉, layered type의 화면 표출)되는 경우를 도시하고 있지만, 화면 분할 방식은 이 외에도 다양한 방식이 적용될 수 있음은 물론이다.
본 실시예에 의하면, 사용자가 온라인 서비스에 아이디와 패스워드를 입력한 이후 추가 인증을 위해서 서비스에서 제공하는 간편 인증번호와 모바일 간편 인증기가 제공하는 간편 인증번호가 같은 경우 사용자의 서비스 접속을 승인함으로써, 사용자의 불필요한 인증번호 재입력을 없앨 수 있다.
또한 본 실시예에 의하면, 타인이 사용자의 아이디와 패스워드로 온라인 서비스에 접근을 시도하면 간편 인증기를 갖고 있는 사용자는 본인이 아닌 타인에 의해서 접속 허가 요청이 있었다는 상황을 숙지할 수 있어, 사용자 아이디와 패스워드에 대한 보안 관리까지 가능하게 된다.
[제3 실시예 - 접속단말 연결정보를 이용하는 사용자 인증 방법 및 시스템]
본 실시예는 사용자 인증 방법 및 시스템에 관한 것으로서, 보다 구체적으로는 접속단말의 연결정보를 이용하여 생성된 OTP(one time password)를 활용하여 사용자를 인증하는 인증 방법 및 시스템에 관한 것이다.
온라인 뱅킹이나 메일 서비스와 같이 중요 정보서비스를 보호하기 위하여 스마트폰 기반의 OTP 앱이 보편화되고 있으나, 스마트폰 화면에 생성된 OTP 값을 탈취하기 위한 공격 수준이 고도화되고 있다.
스마트폰에서 생성되는 OTP 앱의 보안성이 아무리 뛰어나다 하더라도, 정상적인 사용자가 자신의 스마트폰으로 생성한 OTP 값을 해커가 원격에서 화면을 읽어가는 화면 스크래핑(screen scraping) 소프트웨어로 공격을 하거나, 멀리서 스마트폰 화면을 읽고 먼저 해커의 단말기에서 입력하여 사용한다면 해당 시스템의 정보를 열람하거나, 자금 이체와 같은 중요 거래를 가로챌 수 있다.
또한 OTP 기술을 응용하여 생성되고 있는 다양한 전자화폐 유형의 바코드 시스템도 화면에 띄워질 때 해커에게 탈취되어 제한 시간 이내에 도용되는 경우 정상적인 인증체계에 대한 심각한 문제를 야기할 수 있다.
특히 종래 보안 기술은 화면을 사람이 육안으로 읽거나 바코드 인식기가 읽는 것을 막을 수는 없기 때문에, OPT 생성기 앱이 만들어낸 화면이 OTP 입력유효시간 이내에 해커에 의해서 도용당한다면 이를 막을 수 없는 문제가 있었다.
또한 OTP와 세션과의 관련된 종래 선행기술들을 살펴보면 사용자 단말기가 접속한 세션을 인증하기 위해서 OTP 값을 이용하는 것이지, 접속한 단말기 별로 상이한 OTP값을 인증하는 기술 구조가 아니다.
따라서 언제 어디서든 사용자가 안전하게 모바일 OTP 앱을 이용하여 온라인 서비스를 사용할 수 있도록 하는 개선된 인증보안 기술이 필요하다.
본 실시예는 온라인 뱅킹 등과 같은 정보 서비스를 안전하게 사용하기 위하여, 해당 서비스에 접속하는 접속단말의 연결정보를 이용하여 OTP를 생성하고 연결된 접속단말에서만 해당 OTP가 유효하도록 하는 방법 및 시스템을 제공한다.
이하의 설명에서, OTP 생성기는 사용자 소유의 모바일 기기에 애플리케이션 프로그램의 형태로 설치된 소프트웨어 OTP 생성기를 중심으로 설명하지만, 반드시 이에 한정되는 것은 아님은 물론이다. 예를 들어, OTP 생성기는 통신 기능을 갖춘 하드웨어 OTP 생성 장치일 수도 있다. 다만, 이하에서는 설명의 편의 및 집중을 위해 전자의 케이스를 가정하여 본 발명의 실시예를 설명하기로 한다.
또한, 이하에서는 도 18을 기준으로 온라인 서비스 서버에 접속하는 접속단말인 클라이언트 단말과 OTP 생성기가 물리적으로 별개로 구성된 경우를 가정하여 설명하지만, OTP 생성기는 클라이언트 단말과 일체적으로 구현될 수도 있다. 후자의 경우라면 도 18에 도시된 모바일 기기는 생략될 것이다. 또한, 클라이언트 단말 자체가 모바일 기기일 수도 있음은 자명하다.
도 18은 본 발명의 실시예에 따른 사용자 인증 방법 및 인증 시스템을 설명하기 위한 도면이다. 또한, 도 19는 본 발명의 실시예예 따른 사용자 인증 방법과 관련된 온라인 서비스 서버의 일 실시예의 블록도이고, 도 20은 본 발명의 실시예에 다른 사용자 인증 방법을 구현하는 OTP 인증 서버에 관한 일 실시예의 블록도이며, 도 21은 본 발명의 실시예에 따른 사용자 인증 방법을 구현하는 OTP 생성기에 관한 일 실시예의 블록도이다. 이하, 도 18을 중심으로 도 19 내지 도 21을 함께 참조하여 본 발명의 실시예에 따른 사용자 인증 방법 및 인증 시스템에 관하여 상세히 설명한다.
도 18의 단계 S1을 참조하면, 온라인 서비스 서버(330)가 제공하는 온라인 서비스 사이트에 의한 온라인 서비스를 이용하고자 하는 경우, 서비스 사용자는 온라인 서비스 서버(330)에 접속 요청을 한다.
예를 들어, 이용하고자 하는 온라인 서비스가 온라인 뱅킹 서비스인 경우, 사용자는 해당 온라인 뱅킹 서비스를 제공하는 특정 온라인 서비스 서버(즉, 온라인 뱅킹 서비스를 제공하는 특정 은행 서버)에 접속할 수 있다. 온라인 서비스 서버(330)로의 접속은 사용자 자신이 소유하는 모바일 기기(310)(예를 들어, 스마트폰 등)를 통한 모바일 접속에 의할 수 있음은 물론이나, 도 18에서는 사용자 소유의 모바일 기기(310)와는 별개의 클라이언트 단말(300)(예를 들어, 회사 PC 등)을 통해서 접속하는 경우를 예시하였다.
도 18의 단계 S2를 참조하면, 온라인 서비스 서버(330)로의 접속 요청에 따라, 온라인 서비스 서버(330)는 온라인 서비스를 이용하고자 하는 서비스 사용자에게 사용자 계정 정보의 입력을 요청할 수 있다. 여기서, 사용자 계정 정보는, 사용자 등록 절차(또는 서비스 가입 절차)를 통해서 해당 온라인 서비스 서버(330)에 미리 저장(등록)되어 있는 해당 사용자의 식별 정보를 의미한다. 통상적으로, 사용자 계정 정보로는 사용자 ID(Identifier)와 패스워드(password)가 활용될 수 있다. 다만, 해당 온라인 서비스를 이용하는 사용자를 식별할 수 있는 정보라면, 상기 사용자 계정 정보로서 이외에도 다양한 정보(예를 들어, 해당 사용자의 이메일 주소, 전화번호, PKI(Public Key Infrastructure) 기반의 인증서 상의 인증서 암호 등)가 대체 활용될 수 있음은 물론이다.
도 18의 단계 S3을 참조하면, 사용자 계정 정보의 입력 요청에 따라, 서비스 사용자는 사용자 계정 정보를 해당 온라인 서비스 사이트에 입력한다. 도 18의 단계 S4를 참조하면, 서비스 사용자로부터 사용자 계정 정보가 입력되면, 온라인 서비스 서버(330)는 사용자로부터 입력된 사용자 계정 정보와 일치하는 계정이 존재하는지를 확인한다. 이러한 계정 정보의 확인에는 도 18에 도시된 바와 같은 계정 DB(340)가 활용될 수 있다. 계정 DB(340)에는 해당 온라인 서비스 서버(330)를 통한 온라인 서비스를 제공받을 수 있는 사용자들(즉, 회원들)에 관한 계정 정보들이 보관된다. 도 18에서는 계정 DB(340)가 온라인 서비스 서버(330)와 별개로 구비되는 경우를 예시하였지만, 계정 DB3140)는 온라인 서비스 서버(330)와 통합되어 구현될 수도 있음은 물론이다.
또한, 시스템 구현 방식에 따라, 계정 DB(340)는 OTP 인증 서버(350)와 통합되어 구현될 수도 있을 것이다. 이와 같은 경우, 도 18의 단계 S4의 사용자 계정 정보 확인 절차는 후술할 도 18의 단계 S5에 따라 사용자 계정 정보가 OTP 인증 서버(350)로 전송된 이후에 실행될 수도 있을 것이다. 다만, 본 명세서에서는 설명의 집중을 위해, 도 18을 기준으로 본 발명의 실시예를 설명하기로 한다.
도 18의 단계 S5를 참조하면, 입력된 사용자 계정 정보가 계정 DB(340)에 보관된 사용자 계정과 일치하는 경우, 온라인 서비스 서버(330)는 통신 인터페이스부(331)를 통해서 OTP 인증 서버(350)로 접속단말 연결정보 및 사용자 계정 정보를 전송할 수 있다.
여기서, 온라인 서비스 서버(330)로부터 OTP 인증 서버(350)로 전송되는 상기 접속단말 연결정보는, 서비스 사용자가 접속단말(도 18에서는 클라이언트 단말(300)임)을 이용하여 온라인 서비스 서버(330)에 접속하였을 때, 양자 간의 연속적인 데이터 송수신을 관리하기 위해 온라인 서비스 서버(330)에 의해 생성 관리되는 서버-단말 간 연결정보(connecting information)일 수 있다.
이에 의할 때, 접속단말 연결정보로는 예를 들어 서비스 사용자의 접속시 해당 온라인 서비스 서버에서 서비스 사용자의 접속단말에 할당하는 세션 정보(예를 들어, 세션 ID(Session ID) 등) 또는 소켓 데이터 통신에서의 소켓 정보(예를 들어, 소켓 핸들(socket handle) 정보)가 이용될 수 있다. 이와 같은 접속단말 연결정보는 온라인 서비스 서버(330)의 연결정보 설정부(333)에 의해 할당될 수 있다.
여기서, 세션 ID는 서버와 접속단말 간의 연속적인 데이터 송수신을 관리하기 위해 해당 서버에 의해 부여되는 값이고, 소켓 핸들 정보는 서버와 접속단말 간에 네트워크를 통해 데이터를 송수신하는 단위인 소켓을 관리하기 위해 해당 서버가 자체적으로 할당한 임의의 연결 고유값이다. 이러한 세션 ID 또는 소켓 핸들 정보는 동적으로 할당됨은 물론 해당 서버에 의해 자체적으로 부여되는 값으로서, 서버 외부에서 해커에 의해 탈취되기 어렵기 때문에, 이를 향후 OTP 생성의 시드값으로서 이용하는 경우 보안 상 유리한 효과가 있다.
또한, 온라인 서비스 서버(330)로부터 OTP 인증 서버(350)로 전송될 상기 사용자 계정 정보는, 앞서 설명한 다양한 사용자 계정 정보 중 어느 하나 또는 그 일부 일 수 있다. 예를 들어, 도 18의 단계 S5에서, 온라인 서비스 서버(330)는 사용자 계정 정보로서 서비스 사용자의 ID 만을 OTP 인증 서버(350)로 전송할 수도 있다. 이때, 사용자 계정 정보는 향후 접속단말 연결정보를 전송해줄 대상(도 18에서는 서비스 사용자 소유의 모바일 기기(310) 또는 OTP 생성기(320)임)을 OTP 인증 서버(350)에서 식별할 수 있도록 하기 위한 용도로서 OTP 인증 서버(350)로 전송되는 것이다. 따라서 본 단계에 따라 전송될 사용자 계정 정보는 그 목적을 달성할 수 있는 한도 내에서 다양한 변형이 가능하다.
도 18에서는 본 단계(즉, 단계 S5)가 앞선 사용자 계정 확인 절차(즉, 단계 S4)가 완료된 이후 바로 실행되는 것으로 도시되고 있지만, 이와 상이할 수도 있음은 물론이다. 예를 들어, 본 단계는 사용자 계정 확인 절차가 완료된 이후 사용자가 인증 수단으로서 OTP 인증 방식을 선택한 경우에 한하여 실행될 수도 있을 것이다.
상술한 바와 같이 전송된 접속단말 연결정보 및 사용자 계정 정보는 OTP 인증 서버(350)의 통신 인터페이스부(351)를 통해 접수(수신)된다.
또한, 도 18의 단계 S4에 따라 사용자 계정 정보 확인 절차가 정상적으로 완료되면, 단계 S6에 따라 온라인 서비스 서버(330)는 온라인 서비스 사이트의 화면을 통해 사용자 OTP 입력창을 표출하는 등의 방식으로 서비스 사용자에게 사용자 OTP의 입력을 요청할 수 있다.
이때, 도 18의 단계 S5 및 단계 S6은 동시에 실행될 수 있으며, 도 18에 도시된 순서와 달리 그 선후를 달리하여 실행될 수도 있다. 이와 유사하게 도 18의 단계 S6과 후술할 단계 S7 또한 동시에 실행될 수 있으며, 도 18에 도시된 순서와 달리 그 선후를 달리하여 실행될 수도 있다.
또한, 본 발명의 실시예에 따라, 접속단말 연결정보가 수신된 경우, 도 18의 단계 S7에 따라 OTP 인증 서버(350)는 통신 인터페이스부(351)를 통해서 해당 접속단말 연결정보가 서비스 사용자 소유의 모바일 기기(310)에 설치된 OTP 생성기(320)로 전송되도록 한다.
도 18의 단계 S7에서 접속단말 연결정보의 전송은 푸시 서버(360)를 통해서 수행되는 것으로 예시하고 있지만, 반드시 이와 같을 필요는 없으며, OTP 인증 서버(350)에서 직접 OTP 생성기(320)로 전송될 수도 있음은 물론이다.
푸시 서버(360)를 통해 접속단말 연결정보를 전송하는 경우, OTP 인증 서버(350)는 접속단말 연결정보를 푸시 서버(360)로 전달하고, 이때 푸시 서버(360)는 푸시 메시지를 통해서 접속단말 연결정보를 OTP 생성기(320)로 전송할 수 있다. 여기서, 푸시 메시지는 특정 모바일 운영체제에서 앱(App) 별로 제공하는 메시지 서비스일 수 있다. 다만, 접속단말 연결정보의 전송을 반드시 푸시 메시지에 의할 필요는 없음은 자명하며, SMS, MMS 등의 상용의 다양한 메시징 서비스에 의할 수도 있고, 특정 통신 프로토콜(예를 들어, 소켓 데이터 통신 등)에 의하여도 무방하다. 접속단말 연결정보의 전송을 푸시 메시지에 의하지 않는 다른 예시적 케이스들에서, 전술한 푸시 서버(360)는 일반적인 통신 서버로서 그 기능이 대체될 수 있다.
또한 도 18에서는 접속단말 연결정보가 OTP 생성기(320)로 직접 전송되는 케이스를 중심으로 설명하였지만, 반드시 이와 같을 필요는 없다. 예를 들어, 접속단말 연결정보는 푸시 메시지 등을 통해서 모바일 기기(310)로 전송되고, OTP 생성기(320)가 이를 읽어들여 접속단말 연결정보를 수신(취득)할 수 있음은 자명하다. 이러한 접속단말 연결정보의 수신은 OTP 생성기(320)의 접속단말 연결정보 수신부(321)에 의해 이루어질 수 있다.
상술한 바와 같은 접속단말 연결정보의 OTP 생성기(320)로의 전송을 위해, OTP 인증 서버(350)는 온라인 서비스 서버(330)로부터 수신한 사용자 계정 정보에 기초하여 OTP 생성기(320)가 설치된 모바일 기기(310)의 기기값 또는 OTP 생성기(320)의 앱(App) 푸시 아이디를 확인하고, 확인된 기기값 또는 앱 푸시 아이디에 근거하여 상기 접속단말 연결정보를 OTP 생성기(320)로 전송할 수 있다.
다른 예로, OTP 인증 서버(350)는 OTP 생성기(320)의 요청에 대한 응답으로서 접속단말 연결정보를 OTP 생성기(320)로 전송할 수도 있다. 예를 들어, 도 18의 단계 S6에 따라 사용자 OTP의 입력이 요청되면, 이를 인지한 서비스 사용자는 OTP 생성기(320)를 통해서 OTP 인증 서버(350)로 접속단말 연결정보의 전송을 요청하고, 이에 따라 OTP 인증 서버(350)는 그 응답으로서 접속단말 연결정보를 OTP 생성기(320)로 전송할 수 있다.
또 다른 예로, 도 18의 예시에서와는 달리, 접속단말이 OTP 생성기(320)가 설치된 모바일 기기(310) 자체인 경우, OTP 인증 서버(350)는 수신된 사용자 계정 정보에 기초하여 OTP 생성기(320)의 앱 푸시 아이디를 확인하고, 그 확인된 앱 푸시 아이디에 근거하여 온라인 서비스 서버(330)에 접속단말인 모바일 기기(310)에 할당된 접속단말 연결정보의 전송을 요청하며, 그 전송 요청에 따라 수신된 접속단말 연결정보를 OTP 생성기(320)로 전송해줄 수도 있을 것이다. 즉, 이러한 케이스에서는, 도 18의 단계 S5에서는 사용자 계정 정보만이 먼저 전송되고, 접속단말 연결정보는 OTP 인증 서버(350)의 요청에 따라 나중에 전송되는 방식으로 시스템이 구현될 것이다.
상술한 다양한 방식에 따라, OTP 생성기(320)로 접속단말 연결정보가 전송되면, OTP 생성기(320)는 도 18의 단계 S8에 따라 사용자 OTP를 생성한다. 이때, 사용자 OTP는 전송된 접속단말 연결정보를 이용하여 생성되며, 이는 OTP 생성기(320)의 사용자 OTP 생성부(325)에 의해 실행될 수 있다. 이하, 접속단말 연결정보를 용한 사용자 OTP 생성 방법에 대한 다양한 실시예를 상세히 설명한다.
일 실시예에서, OTP 생성부(325)는 수신된 접속단말 연결정보를 시드값으로 하되 특정 연산조건(예를 들어, 시도횟수, 시간 등)을 적용하여 사용자 OTP를 생성할 수 있다. 보다 구체적으로는 OTP 생성부(325)는 수신된 접속단말 연결정보에 상술한 특정 연산조건을 곱한 값을 특정 해시 함수(hash function)에 따라 암호화한 값으로 사용자 OTP를 생성할 수 있다.
다른 실시예에서, OTP 생성부(325)는 접속단말 연결정보 이외에도 다른 특정 키값을 시드값으로서 더 추가하여 사용자 OTP를 생성할 수 있다. 이때, 상기 다른 특정 키값으로는 서비스 사용자의 사용자 계정 정보에 대응하여 사전 등록된 개인키가 이용될 수 있다.
일 예로, 사용자 계정 정보에 대응하는 개인키는, 전술한 사용자 ID, 패스워드, 사용자의 이메일 주소, 전화번호, 인증서 암호 등과 같은 다양한 사용자 식별 정보 중 어느 하나 또는 적어도 19개의 조합이 사전 등록되어 이용될 수 있다. 다른 예로, 사용자 계정 정보에 대응하는 개인키는, 사용자 소유의 모바일 기기(예를 들어, 스마트폰 등)의 폰 번호, 제품 일련번호, 유심(USIM) 카드번호, 맥 어드레스(MAC address) 등과 같은 식별자 중 어느 하나 또는 적어도 19개의 조합이 사전 등록되어 이용될 수도 있다. 또 다른 예로, 사용자 계정 정보에 대응하는 개인키는, 사용자가 OTP 인증 서비스에 등록할 때에 자신이 직접 선택하여 등록한 또는 OTP 인증 서비스 등록시에 부여된 개인키가 이용될 수도 있다.
사용자 OTP 생성에 이용되는 상술한 개인키는 OTP 생성기(320)의 키 보관부(323)에 미리 저장되어 있을 수 있다. 이때, OTP 생성기(320)의 키 보관부(323)에 저장되는 개인키는 OTP 인증 서버(350)의 키 보관부(353)에도 동일하게 저장됨으로써, 상호 간 OTP 생성에 동일하게 이용될 수 있다.
이상에서 설명한 실시예들 이외에도, 더욱 다양한 값들이 OTP 생성을 위한 시드값으로서 추가 활용되거나 대체 활용될 수 있음은 물론이다. 또한 이상에서는 OTP 생성기(320)에서 보관된 키 값을 활용하여 OTP를 생성하는 경우를 중심으로 설명하였지만, 반드시 보관된 키 값을 이용할 필요는 없다. 예를 들어, 도 18의 단계 S7을 통해 접속단말 연결정보를 전송할 때, OTP 생성에 추가 활용될 키 값 또는 특정 연산 조건이 함께 OTP 생성기(320)로 전송될 수도 있다. 또는 OTP 생성기(320)에서 OTP 생성에 추가 활용한 키 값 또는 연산 조건을 OTP 인증 서버(350)로 전송해주는 방식이 이용될 수도 있다.
상술한 단계에 따라 사용자 OTP가 생성되면, OTP 생성기(320)의 OTP 표출부(327)는 모바일 기기(310)의 화면을 통해서 그 생성된 사용자 OTP를 표출한다.
이후, 도 18의 단계 S9를 통해 사용자 OTP가 입력되면, 온라인 서비스 서버(330)의 인증 요청부(335)는 통신 인터페이스부(331)를 통해서 서비스 사용자에 의해 입력된 사용자 OTP를 OTP 인증 서버(350)로 전달함으로써[도 18의 단계 S10 참조], 입력된 사용자 OTP의 검증을 요청할 수 있다.
이때, 서비스 사용자에 의한 사용자 OTP의 입력은, 온라인 서비스 서버(330)에 의해 제공되는 온라인 서비스 사이트 화면에 게시된 사용자 OTP 입력창을 통해서 이루어질 수 있다. 물론 이외에도 다양한 방식으로의 변형이 가능하다. 예를 들어, 사용자 OTP는 서비스 사용자에 의해 직접 입력되지 않고, 특정 제스처를 통해서 입력에 갈음할 수도 있다. 예를 들어, 사용자가 모바일 기기의 터치 스크린을 통해 표출된 사용자 OTP를 단순 터치 선택하는 행위, 해당 화면을 위쪽 방향으로 밀어올리는 터치 제스처 등의 다양한 제스처를 취함으로써, 사용자 OTP의 자동 입력이 이루어지도록 구현될 수도 있다.
이에 따라, OTP 인증 서버(350)의 검증용 OTP 생성부(355)는 입력된 사용자 OTP에 대응하는 검증용 OTP를 생성한다[도 18의 단계 S11 참조]. 이때, 검증용 OTP의 생성 방식은 앞서 설명한 사용자 OTP 생성 방식과 본질적으로 동일하므로, 이에 관한 중복되는 설명은 생략하기로 한다. 여기서, 도 18의 단계 S11에 따른 검증용 OTP 생성은 반드시 도 18의 단계 S11 이후에 실행될 필요는 없으며, 시스템 구현 방식에 따라서 도 18의 단계 S5 이후의 임의의 시점에 실행되어도 무방하다.
상술한 바와 같이 검증용 OTP가 생성되면, OTP 인증 서버(350)의 인증 처리부(357)는 전달된 사용자 OTP와 자체 생성된 검증용 OTP 간의 일치 여부를 비교함으로써, 해당 서비스 사용자에 대한 사용자 인증을 수행한다. 이때, 그 인증 결과는 통신 인터페이스부(351)를 통해서 온라인 서비스 서버(330)로 통보(전송)된다[도 18의 단계 S12 참조].
이에 따라, 온라인 서비스 서버(330)의 서비스 처리부(337)는, 통보된 인증 결과를 참조하여 인증이 정상적으로 이루어진 경우 해당 서비스 사용자에게 해당 서비스를 개시할 수 있다[도 18의 단계 S13 참조].
본 실시예에 의하면, 온라인 뱅킹 등과 같은 정보 서비스를 안전하게 사용하기 위하여, 해당 서비스에 접속하는 접속단말의 연결정보를 이용하여 OTP를 생성하고 연결된 접속단말에서만 해당 OTP가 유효하도록 하는 OTP 생성 방법 및 시스템이 제공된다. 이에 따라, OTP 값이 해커에 의해 유출되더라도 해당 접속단말에 의한 서버 접속에 한하여 인증이 이루어지게 되는 효과가 있다.
[제4 실시예 - OTP 앱의 구동 환경 검증 방법 및 그 인증 시스템]
본 실시예는 OTP 앱의 구동 환경 검증 방법 및 이를 이용한 인증 시스템에 관한 것이다. 보다 구체적으로는 소프트웨어 방식의 OTP 앱이 최초 등록된 모바일 기기에서 다른 기기로 복제되더라도 복제된 앱에 의한 OTP 생성 및 이를 통한 인증이 이루어지지 않도록 하기 위한 방법 및 시스템에 관한 것이다.
일반적으로, 하드웨어 동글 방식은 보안의 효과는 높으나 휴대의 불편성과 비용이 발생하고, 소프트웨어 방식은 경제성과 휴대성은 좋으나 소프트웨어 자체가 복제될 수 있어 보안에 약하다.
특히 모바일 앱은 최초 설치된 기기에서 다른 기기로 복제가 가능하여 이를 막기 위한 다양한 기술들이 등장하였다. 일 예로, 스마트 기기에 OTP 앱을 설치한 이후 사용자 등록 과정에서 최초 설치한 스마트 기기의 고유값(UDID(Unique Device Identifier), Phone Number, Push ID 등)을 서버에 보관하고, 앱이 구동될 때마다 스마트 기기의 고유값을 서버에 전송하여 보관된 고유값과 일치하면 구동하게 하는 방식이 존재한다. 다른 예로, OTP 앱 등록 당시 기기의 고유값을 해시값(hash value)으로 변환하여 보관하고 있다가, OTP 앱의 구동 시점마다 실시간 해시화한 고유값과 보관된 해시값을 비교함으로써, 해당 기기가 최초 설치된 기기인지(즉, 앱 등록 당시의 기기와 동일한 기기인지) 여부를 확인하는 방식도 존재한다.
그러나 상술한 방식들 중 전자의 방식은, 앱을 디컴파일하여 고유값을 확인하는 조건 부분을 제거한 후, 앱을 새롭게 생성하는 간단한 방법으로도 OTP 앱이 복제되어 구동될 수 있다는 문제점이 있다. 또한 상술한 방식들 중 후자의 방식은, 해커가 자신 소유의 스마트 기기의 고유값을 앱이 설치되어 있던 원래 기기의 고유값으로 임의로 변경(재구성)한 후 앱을 작동하게 되면, 해당 앱이 정상적으로 구동되는 문제점이 있다.
또한, 위 방식들 이외에, 앱 위변조 방지 기술을 추가로 동원한다 하더라도, 앱 자체의 위변조가 아닌 앱이 구동되는 환경에 대한 값을 변조하게 되면 앱은 정상적인 스마트 기기로 간주하고 작동하게 된다. 또한 앱 위변조 감지 방법들은 앱의 공통된 바이너리 영역을 인식하기 때문에, 인증 소프트웨어와 같이 사용자마다 고유값이 있는 데이터 영역은 변조가 되더라도 이를 감지할 수 없는 한계가 있다.
따라서 OTP 앱이 최초 설치 및 등록된 스마트 기기에서만 정상적으로 구동될 수도록 있도록 구동 환경을 검증할 수 있는 방법과 기술이 필요하다.
본 실시예는 소프트웨어 방식의 OTP 앱이 최초 설치 및 등록된 스마트 기기에서 구동된 것이 맞는지를 확인한 후 OTP 값을 생성하게 하여, 해커에 의해서 OTP 앱이 복제된다하더라도 정상적인 OTP값이 생성되지 못하도록 하는 방법 및 시스템을 제공하고자 한다.
이하, 도 22를 중심으로 도 23 및 도 24를 함께 참조하여 본 발명의 실시예를 상세히 설명한다. 여기서, 도 22는 본 발명의 실시예에 따른 OTP 앱의 구동 환경 검증 방법 및 이를 이용한 인증 시스템을 설명하기 위한 도면이고, 도 23 및 도 24는 본 발명의 실시예에 따른 OTP 앱의 구동 환경 검증 방법을 구현하기 위한, OTP 앱과 OTP 인증 서버에 관한 일 실시예의 블록도이다.
이하의 설명에서, OTP 앱(App)은 사용자 소유의 모바일 기기(도 22의 도면부호410 참조)에 애플리케이션 프로그램의 형태로 설치된 소프트웨어 방식의 OTP 생성기를 의미한다. 또한, 이하 설명될 본 발명의 실시예는 서비스 종류를 불문하고 OTP를 인증 수단으로서 활용하는 다양한 온라인 서비스에 적용될 수 있음은 물론이다. 또한 이하에서 OTP는 사용자 인증에 활용되는 경우를 중심으로 설명하겠지만, 특정 목적의 인증을 위해 OTP가 활용되는 경우라면 특별한 제한 없이 본 발명이 적용될 수 있을 것임은 물론이다. 다만, 이하 본 발명의 실시예를 설명함에 있어서, 설명의 편의 및 집중을 위해, 사용자가 온라인 뱅킹 서비스를 이용하기 위해 해당 서비스를 제공하는 특정 온라인 서비스 서버(도 22의 도면부호 430 참조)에 접속하고, 사용자 인증 수단으로서 OTP 인증을 선택한 경우를 가정하기로 한다.
위와 같이 온라인 서비스 서버(430)에 의해서 제공되는 온라인 서비스를 이용하기 위한 인증 수단으로서 OTP 인증이 선택된 경우, 사용자는 인증 값인 사용자 OTP 값의 입력을 위해, 자신 소유의 모바일 기기에 설치된 OTP 앱(420)을 구동시키게 된다.
이에 따라, 도 22의 단계 S1과 같이 앱이 구동되면, 본 발명의 실시예에 따른 OTP 앱(420)은 앱 구동 환경을 검증하기 위한 일련의 절차를 실행한다. 즉, 본 발명의 실시예에 따른 OTP 앱은 앱 구동에 따라 OTP를 바로 생성하는 것이 아니라, OTP 생성 전에 해당 앱이 구동되고 있는 구동 환경을 검증하는 절차를 수행하고, 앱 구동 환경의 검증이 정상적으로 완료된 경우에만 OTP 값을 생성할 수 있다. 이하, 이러한 앱 구동 환경 검증을 위한 일련의 절차에 대하여 도 22의 단계 S2 ~ 단계 S7을 참조하여 설명한다.
도 22의 단계 S2를 참조하면, OTP 앱(420)의 구동 환경 검증부(423)는 통신 인터페이스부(421)을 통해서 앱 푸시 아이디(Push ID) 및 기본등록정보를 OTP 인증 서버(450)로 전송한다.
앱 푸시 아이디는 일반적으로 특정 모바일 운영체제(예를 들어, 구글 또는 애플사의 모바일 운영체제)에서 앱과의 푸시 메시징 서비스를 통한 데이터 송수신을 위해 설치된 앱(App) 별로 할당되는 고유값(예를 들어, Push Token 등)을 의미한다. 따라서 동일 앱이 설치되더라도 설치되는 기기가 상이해지면 앱 푸시 아이디도 상이해진다. 본 단계를 통해 OTP 인증 서버(450)로 전송되는 앱 푸시 아이디는, 사용자가 OTP 인증 서버(450)에 의한 OTP 인증 서비스에 최초 가입할 당시에 등록한 해당 앱에 관한 푸시 아이디이다.
일 실시예에서, 앱 푸시 아이디는 OTP 앱(420)에 보관되고 있다가 본 단계를 통해 OTP 인증 서버(450)로 전달될 수 있다. 또는 다른 실시예에 의할 때, 앱 구동 환경 검증이 필요할 때마다(즉, OTP 앱을 구동시킬 때마다) 해당 모바일 운영체제의 운용 서버(즉, 구글 또는 애플사의 관리 서버)로부터 앱 푸시 아이디 값을 받아와서 이를 OTP 인증 서버(450)로 전달하는 방식이 이용될 수도 있다. 후자의 방식에 의할 때에는 매번 앱 푸시 아이디 값을 받아와야 하므로, 해커에 의해 OTP 앱이 복제된다고 하더라도 정상적인 기기가 아닌 해커의 기기를 통해서는 앱 푸시 아이디를 받아올 수 없다. 따라서, 후자의 방식의 경우 전자의 방식(앱 푸시 아이디가 앱 자체에 보관되는 방식)에 비해 보안성이 더 높아질 수 있다.
또한, 상기 기본등록정보는, 사용자가 OTP 인증 서비스에 최초 가입할 당시에 등록한 정보로서, 해당 OTP 인증 서비스에 가입한 정당한 사용자를 확인할 수 있는 정보(예를 들어, 사용자 식별 정보 또는 사용자가 OTP 인증 서비스에 가입시 추가로 입력한 추가 입력 정보 등), OTP 앱을 인증 서버에 등록할 당시에 등록한 OTP 앱 정보(예를 들어, 앱 일련번호, OTP 식별정보, OTP 앱 암호 등), OTP 앱이 설치된 모바일 기기 정보(예를 들어, UDID, 유심(USIM) 카드번호, 맥 어드레스(MAC address) 등) 중 어느 하나 또는 이들의 조합이 이용될 수 있다.
상술한 앱 푸시 아이디 및 기본등록정보는 OTP 인증 서버(450)의 정보 등록부(453)에도 보관되어, 향후 OTP 앱의 구동 환경 검증에 활용된다. 본 발명의 실시예에 따른 앱 구동 환경 검증이 완료되기 전까지, OTP 앱(420)의 구동 환경 검증부(423)는 앱 화면에 구동 환경 검증 대기화면을 표출할 수 있다[도 22의 단계 S3 참조]. 여기서, 구동 환경 검증 대기화면이란, OTP 인증 서버(450)로부터 후술할 도 22의 단계 S6에 따른 푸시 메시지가 전송되기 전까지 앱 구동 환경을 검증하고 있다는 상황을 사용자에게 안내하기 위해 모바일 기기의 화면 상에 표출되는 화면을 의미한다.
도 22의 단계 S2에 따라 앱 푸시 아이디 및 기본등록정보가 OTP 인증 서버(450)의 통신 인터페이스부(451)를 통해 수신되면, 도 22의 단계 S4에서 OTP 인증 서버(450)는 정보 등록부(453)에 보관된 앱 푸시 아이디 및 기본등록정보와 수신된 앱 푸시 아이디 및 기본등록정보 간의 일치 여부를 확인한다.
확인 결과, 일치되는 경우, OTP 앱이 구동되는 환경이 OTP 인증 서비스에 가입할 당시에 등록한 것과 달라지지 않았음(즉, 해당 OTP 앱이 구동되는 모바일 기기가 최초 등록한 기기와 동일함)을 확인할 수 있게 된다. 다시 말해서, OTP 앱이 다른 기기로 복제되어 도용되는 것이 아님을 확인할 수 있다.
도 22의 단계 S4의 확인 결과, 정보 간 일치가 확인되면, OTP 인증 서버(450)는 도 22의 단계 S5에 따라 2차 검증 과정을 추가로 수행할 수 있다. 물론, 도 22의 단계 S5에 따른 2차 검증 과정은 시스템 구현 방식에 따라 생략될 수도 있지만, 이하 이에 대해 설명하면 다음과 같다.
도 22의 단계 S5를 참조하면, OTP 인증 서버(450)는 접속 모바일 기기(즉, OTP 앱(420)이 설치된 기기)의 IP 주소가 정보 등록부(453)에 사전 등록된 통신사 IP 주소 범위 내에 해당하는지를 확인한다. 여기서, 사전 등록된 통신사 IP 주소 범위란, 이동통신서비스를 제공하는 통신사업자가 자사 이동통신서비스에 가입한 모바일 기기가 IP 통신을 하고자 할 때에 할당하는 IP 주소 범위를 나타낸다.
만일 OTP 인증 서버(450)로 앱 푸시 아이디와 기본등록정보를 전송한 모바일 기기의 IP 주소가 최초 등록된 모바일 기기와 관련된 이동통신서비스사업자에 의해 할당되는 IP 주소 범위 내에 존재하지 않는 경우라면, 기기의 사용 위치가 서로 상이하므로 기기 정보를 탈취한 타인(해커 등)에 의한 부정한 목적의 접속일 가능성이 높다. 따라서 이러한 경우 보안 상 인증을 불허할 필요가 있다. 이와 같이 도 22의 단계 S5는 앞선 단계(단계 S4)의 기기 검증을 넘어서 해당 기기가 사용되는 위치 범위를 추가로 검증하기 위한 과정이다.
위와 관련하여, OTP 앱(420)은 앱이 구동될 때 네트워크 설정을 점검하여 WiFi 등 근거리 통신 모드에서 앱이 구동되지 않고, 3G나 LTE 등 이동통신망에서만 앱이 구동되도록 관리할 수 있다. 이러한 네트워크 설정의 점검은 OTP 앱(420)의 통신망 확인부(420)에 의해 수행될 수 있다.
상술한 바와 같은 확인 과정을 거친 결과, 정보 간 불일치가 없는 경우라면, OTP 인증 서버(450)는 도 22의 단계 S2를 통해 수신되었던 앱 푸시 아이디에 기반하여 OTP 생성조건 값이 OTP 앱(420)으로 전송되도록 한다[도 22의 단계 S6 참조].
도 22에서는 OTP 생성조건 값의 전송을 앱 푸시 아이디에 기반하여 푸시 메시지를 통해 수행하는 경우를 중심으로 설명하였다. 다만 이에 한정되는 것은 아니며, 소켓 데이터 통신 등 다양한 전송 프로토콜 또는 다양한 메시지 전송 방식이 활용될 수 있음은 자명하다.
만일 앱 푸시 아이디에 기반하여 푸시 메시지를 통해서 OTP 생성조건 값을 전송하는 경우라면 다음과 같은 방식에 의해 도 22의 단계 S6이 수행될 것이다. 먼저, OTP 인증 서버(450)는 푸시 서버(미도시)를 통해서 OTP 생성조건 값이 해당 OTP 앱(420)이 설치된 모바일 기기(410)로 전송되도록 한다. 이 경우, OTP 앱(420)은 모바일 기기(410)로 전송된 푸시 메시지를 읽어들여 OTP 생성조건 값을 확인할 수 있다.
상술한 경우, 해커에 의해서 OTP 앱이 복제되어 정상적인 푸시 아이디와 기본등록정보가 OTP 인증 서버(450)로 수신된다고 하더라도, 도 22의 단계 S6을 통해서는 해커의 기기가 아닌 진정한 사용자의 모바일 기기로 OTP 생성조건 값이 전달된다. 따라서, 해커의 기기에서는 OTP 생성조건 값을 전달 받을 수 없어 인증용 OTP 값을 생성할 수 없게 된다.
앞선 단계를 통해 OTP 생성조건 값이 전달되면, OTP 앱(420)의 OTP 생성부(427)는 수신된 OTP 생성조건 값을 이용하여 OTP를 생성하고, OTP 앱(420)의 OTP 표출부(429)는 생성된 OTP를 화면 상에 표출할 수 있다[도 22의 단계 S7 참조].
여기서, OTP 앱(420)으로 전송되는 OTP 생성조건 값은, OTP 인증 서버(450)의 OTP 생성조건 설정부(455)에 의해 할당 또는 보관된 값일 수 있다. 예를 들어, OTP 인증 서버(450)의 시간 값, 랜덤 값, OTP 발급빈도 등과 같은 매번 변하는 가변 값일 수도 있고, OTP 생성부(427)가 작동할 수 있는 최대 시간이거나, OTP 앱(420)이 OTP 인증 서버(450)에 전송했던 값 또는 이와 연관된 값(서버에서 보관하고 있는 등록정보 값), 또는 이들을 조합한 값일 수 있다.
이때, OTP 생성부(427)는 수신한 OTP 생성조건 값으로서 가변값을 수신한 경우 OTP 생성시 연산자로 활용하여 OTP 값을 생성하거나, 고정값을 수신한 경우 앱에서 참조한 값과 비교하여 동일한 경우 OTP 값을 생성할 수 있다. 여기서, OTP 생성부(427)에서 OTP 생성에 사용하는 생성조건 값 중 일부는 OTP 앱에 사전 저장된 값을 그대로 이용할 수도 있을 것이다.
이후, 도 22의 단계 S8를 통해 OTP 값이 입력되면, 온라인 서비스 서버(430)는 사용자에 의해 입력된 OTP를 OTP 인증 서버(450)로 전달함으로써[도 22의 단계 S19 참조], 입력된 OTP 값의 검증을 요청할 수 있다.
이때, 서비스 사용자에 의한 OTP 값의 입력은, 온라인 서비스 서버(430)에 의해 제공되는 온라인 서비스 사이트 화면에 게시된 OTP 입력창을 통해서 이루어질 수 있다. 물론 이외에도 다양한 방식으로의 변형이 가능하다. 예를 들어, OTP 값은 서비스 사용자에 의해 직접 입력되지 않고, 특정 제스처를 통해서 입력에 갈음할 수도 있다. 예를 들어, 사용자가 모바일 기기의 터치 스크린을 통해 표출된 OTP를 단순 터치 선택하는 행위, 해당 화면을 위쪽 방향으로 밀어올리는 터치 제스처 등의 다양한 제스처를 취함으로써, OTP의 자동 입력이 이루어지도록 구현될 수도 있다.
이에 따라, OTP 인증 서버(450)의 검증용 인증 처리부(457)는 입력된 OTP에 대응하는 검증용 OTP를 생성하고, 전달된 OTP와 자체 생성된 검증용 OTP 간의 일치 여부를 비교함으로써, 해당 서비스 사용자에 대한 인증을 수행한다[도 22의 단계 S10 참조]. 이때, 그 인증 결과는 통신 인터페이스부(451)를 통해서 온라인 서비스 서버(430)로 통보(전송)될 수 있다. 이에 따라, 온라인 서비스 서버(430)는, 통보된 인증 결과를 참조하여 인증이 정상적으로 이루어진 경우 해당 서비스 사용자에게 해당 서비스를 개시할 수 있다.
이상에서는 앱 구동 환경 검증 결과, 정상 구동 환경인 것으로 판명된 경우를 중심으로 설명하였다. 위와 반대로 앱 구동 환경 검증 결과, 비정상 구동 환경인 것으로 판명되는 경우에는 아래와 같은 처리가 이루어질 수 있다. 이하, 이에 대한 다양한 예시들을 설명한다.
일 실시예에 의할 때, 상술한 도 22의 단계 S4, 단계 S5의 확인 결과, 어느 한 단계라도 정보 간 불일치가 발생한 경우라면, OTP 인증 서버(450)는 상술한 도 22의 단계 S6을 수행하지 않을 수 있다. 이 경우, OTP 앱(420)은 도 22의 단계 S2 이후 사전 지정된 시간 이내에 도 22의 단계 S6에 따른 메시지가 도착되지 않는 경우, 앱을 강제로 종료하거나 종료를 안내하는 메시지를 화면 상에 표출할 수 있다.
다른 실시예에 의할 때, 상술한 도 22의 단계 S4, 단계 S5의 확인 결과, 어느 한 단계라도 정보 간 불일치가 발생한 경우, OTP 인증 서버(450)는, 온라인 서비스 서버(430)로 인증 불허 통지를 전송할 수 있다. 이 경우, OTP 인증 서버(450)는, 보관된 푸시 아이디에 근거하여 진정한 사용자에게 상기 인증 불허와 관련된 안내 메시지 또는 타인에 의한 OTP 앱의 복제를 경고하는 경고 메시지를 전송할 수 있다.
또한, OTP 인증 서버(450)는, 도 22의 단계 S2에 따른 푸시 아이디 및 기본등록정보가 수신되지 않은 상태에서, 도 22의 단계 S9에 따라 OTP 값이 전달된 경우, 온라인 서비스 서버(430)로 인증 불허 통지를 전송할 수 있다. 이는 본 발명의 실시예에 따른 앱 구동 환경 검증 과정을 거치지 않은 상태에서 수신된 비정상적인 인증 요청이기 때문이다.
본 실시예에 의하면, 해커에 의해서 앱 자체의 공격이 아닌 앱이 구동되는 환경에 대한 정보를 변조하는 우회 공격이 시도된다고 하더라도 정상적인 OTP값이 생성될 수 없게 된다.
따라서 본 실시예에 의하면, 최초 설치 및 등록된 스마트 기기에서만 정상적인 OTP값이 생성되도록 함으로써, 하드웨어 OTP 동글과 동일 수준의 보안성을 갖는 소프트웨어 방식의 OTP 앱을 구현할 수 있게 된다.
[제5 실시예 - OTP 앱 구동 방법] (네트워크 비활성화)
본 실시예는 사용자 단말에서 소프트웨어 방식의 OTP(One Time Password) 애플리케이션을 구동할 때, 제3자에 의해서 도용되지 못하도록 하는 방법에 관한 것이다. 보다 구체적으로는, OTP 애플리케이션을 구동할 때 네트워크가 비활성화되어 있는지 확인하고, 비활성화되어 있는 경우 OTP 애플리케이션을 실행하는 방법에 관한 것이다.
OTP를 이용한 금융거래가 안전하다고 생각하여 왔으나, 최근 인터넷 뱅킹 해킹사고를 살펴보면, 사용자가 거래단말기에서 정상적인 거래를 하더라도 거래 계좌를 변조하는 메모리 해킹 공격이 발생하고 있다.
메모리 해킹 공격이란 정상적인 사용자가 온라인 거래매체에서 거래계좌, 송금액, OTP 토큰값을 입력했다 하더라도, 거래 단말기에서 거래서버로 데이터가 보내질때, 거래계좌 정보를 다른 계좌로 변조하여 보내는 해킹 공격을 의미한다.
이를 막기 위해서 해외에서는 이미 OTP 생성 알고리즘에 거래 계좌와 거래 금액을 입력받아서 OTP 토큰값을 생성하는 거래연동 OTP가 금융권에 적용되었다. 거래연동 OTP 기술은 개인별 OTP 고유값에 시간이나, 시도횟수를 연산하여 OTP 토큰값을 생성하는 종래 OTP 기술에 거래정보(거래 계좌, 송금 금액)를 추가적으로 입력받아서 OTP 토큰 값을 생성하는 기술이다. 따라서 거래 단말기에 메모리 해킹 공격이 발생한다 하더라도 거래연동 OTP에 맞는 송금 계좌와 송금 금액이 아니라면 거래가 이루어질 수 없게 된다.
그러나 거래연동 OTP는 경제성과 휴대성이 뛰어난 소프트웨어 방식 보다는 보안성이 높은 하드웨어 기반의 OTP로 구성되고 있다. 이는 사용자 단말에 대한 공격이 앱을 단순히 피싱하는 수준이 아닌 운영환경 자체를 공격하는 것까지 가능하기 때문이다. 대표적으로는 사용자가 사용자 단말에서 앱을 구동하면 입력값 또는 출력된 결과값이나 화면 자체를 외부로 전송하는 것도 가능하고, 원격 제어 기술을 통해서 외부 해커가 사용자의 사용자 단말을 장악하여 원격 구동하는 것까지도 가능한 것으로 나타나고 있다.
따라서 소프트웨어 방식의 거래연동 OTP가 안전하게 사용자 단말에서 구동되면서도 거래 자체를 보호할 수 있는 새로운 대안이 필요하다.
본 실시예는 소프트웨어 방식의 OTP 애플리케이션의 구동 과정에서의 해킹 위험을 방지할 수 있는 OTP 애플리케이션에 관한 컴퓨터 구현 방법을 제공하고자 한다.
또한 본 실시예는 사용자 단말에서 거래연동 OTP 애플리케이션이 설치되어 있거나 구동 중에 있을 때, 해킹 소프트웨어를 통해서 OTP 토큰값을 유출하지 못하도록 하는 OTP 애플리케이션에 관한 컴퓨터 구현 방법을 제공하고자 한다.
도 25는 본 발명의 일 실시예로서, 거래연동 OTP 애플리케이션의 기능 블록을 도시한 도면이고, 도 26은 본 발명의 실시예에 따른 OTP 애플리케이션 구동 방법에 관한 개략적인 흐름도이다. 그리고 도 27 내지 도 31은 본 발명의 일 실시예로서, 거래연동 OTP 애플리케이션의 실행 화면들을 예시한 도면이다.
본 명세서의 첨부된 도면을 통해서는 거래연동 OTP(즉, 금융거래의 보안을 위해 사용되는 OTP)를 생성하는 OTP 애플리케이션의 케이스를 가정하여 도시 및 설명할 것이나, 본 발명의 실시예에 따른 OTP 애플리케이션 구동 방법은 이외의 다양한 OTP 생성 애플리케이션에도 동일 또는 유사하게 적용될 수 있음을 당업자라면 용이하게 이해할 수 있을 것이다. 따라서 본 명세서에서는 설명의 편의 및 집중을 위해 거래연동 OTP 애플리케이션의 케이스를 중심으로 설명하기로 한다.
도 25를 참조하면, 본 발명의 실시예에 따라 사용자 단말에 설치되는 OTP 애플리케이션의 일 예로서, 거래연동 OTP 애플리케이션(500)(이하, "거래연동 OTP 앱"이라 약칭함)은 해당 애플리케이션 프로그램의 기능 수행을 위해 네트워크 확인부(510), 거래정보 저장부(520), OTP 생성부(530), GUI(Graphic User Interface) 화면 표시부(540), 제어부(550)를 포함할 수 있다. 이하, 도 25의 각 구성부의 기능에 관하여 도 26의 순서도, 도 27 내지 도 31의 예시 화면을 함께 참조하여 설명하기로 한다.
네트워크 확인부(510)는, 네트워크 연결이 비활성화 상태에 있을 때에 거래연동 OTP 앱이 구동될 수 있도록, 거래연동 OTP 앱이 최초 구동될 때 사용자 단말의 네트워크 연결 상태를 확인하는 역할을 수행한다. 따라서 도 26의 단계 S210에서와 같이 사용자의 선택에 따라 거래연동 OTP 앱의 구동 요청이 수신된 경우, 네트워크 확인부(510)는 사용자 단말의 네트워크 연결이 비활성화 상태에 있는지 여부를 확인한다[도 26의 단계 S220 참조].
여기서, 네트워크 비활성화 상태란, 사용자 단말에 탑재된 모든 네트워크 디바이스(일 예로, 3G, LTE, WiFi, Bluetooth, NFC 등)가 비활성화 상태에 있는 경우로 설정될 수도 있지만, 네트워크 연결을 위해 IP(Internet Protocol) 주소의 할당이 필요한 네트워크만이 비활성화 상태에 있는 경우로 설정될 수도 있다.
위 설명의 후자의 케이스에서, 네트워크 확인부(510)는 사용자에 의한 거래연동 OTP 앱의 구동 요청이 수신된 경우, 사용자 단말에 IP 주소가 할당된 네트워크가 존재하는지 여부를 확인하고, IP 주소가 할당된 네트워크가 부존재하는 경우 네트워크 비활성화 상태에 있는 것으로 판단할 수 있다. 즉, 위 후자의 케이스에서, IP 주소의 할당 없이도 외부와 통신 가능한 Bluetooth, NFC 등의 근거리 무선 통신 방식의 네트워크가 활성화되어 있는 상태라도, IP 주소 할당이 필요한 네트워크는 비활성화된 상태라면 도 26의 단계 S220에서의 네트워크 비활성화 상태로 판단하게 될 것이다.
다른 예로, 네트워크 확인부(510)는 네트워크 상태 값을 인지하는 방법에 있어서, 네트워크 디바이스에 할당된 주소 체계가 루프백(loopback) 주소인 경우, 네트워크 연결이 비활성화된 상태인 것으로 판단할 수도 있다. 이러한 루푸백 주소는, 네트워크 디바이스에 할당된 IP 주소인 경우127.0.0.1이며, IPv6주소인 경우 ::1 또는 0:0:0:0:0:0:0:0:1 등일 수 있다.
상술한 바와 같이, 본 발명의 실시예에 따른 OTP 애플리케이션 구동 방법을 적용함에 있어서, 네트워크 비활성화 상태를 어떻게 정의할지에 관한 사항은 애플리케이션의 환경 설정에 따라 상이해질 수 있다.
제어부(550)는 네트워크 확인부(510)의 확인 결과에 따라 거래연동 OTP 앱의 구동 여부 또는/및 앱 구동에 따른 기능 실행 여부를 제어한다. 우선, 도 26의 단계 S220의 확인 결과, 네트워크 비활성화 상태에 있는 것으로 확인된 경우, 제어부(550)는 거래연동 OTP 앱이 정상 구동(실행)되도록 제어한다. 예를 들어, 제어부(550)는, 네트워크 비활성화 상태에 있는 것으로 확인된 경우, 후술할 도 27 내지 도 31의 예시 화면에서와 같이 거래연동 OTP 생성을 위한 GUI 화면이 표출되도록 GUI 화면 표시부(540)의 동작을 제어하거나, 이를 통해 거래연동 OTP가 생성되도록 OTP 생성부(530)의 동작을 제어할 수 있다.
위와 반대로, 도 26의 단계 S220의 확인 결과, 네트워크 연결이 비활성화되지 않은 상태로 확인된 경우(즉, 네트워크가 연결된 상태인 경우), 제어부(550)는 거래연동 OTP 앱의 구동을 제한(즉, 앱 실행을 불허)할 수 있다[도 26의 단계 S240 참조]. 이 경우, 제어부(550)는 GUI 화면을 통해서 네트워크 비활성화를 안내하는 팝업(즉, 네트워크 연결을 비활성화 상태로 전환되도록 유도하는 팝업(도 27 참조))이 표출되도록 제어할 수 있다[도 26의 단계 S244 참조]. 이에 따라 사용자가 도 26의 단계 S248에서와 같은 네트워크 차단을 실행한 경우, 제어부(550)는 비로소 거래연동 OTP 앱이 실행되도록 할 수 있다.
또한 네트워크 확인부(510)는 거래연동 OTP 앱이 구동되는 동안에도 매초 또는 지정한 주기 마다 네트워크 연결이 다시 회복되었는지를 확인할 수 있다[도 26의 단계 S250 참조]. 이에 따라, 네트워크 연결이 재개된 경우, 제어부(550)는 거래연동 OTP 앱의 구동을 제한하거나 또는 앱 구동에 따른 기능 수행을 제한할 수 있다[도 26의 단계 S260 참조].
도 26의 단계 S260에서, 거래연동 OTP 앱의 구동을 제한한다고 함은, 네트워크 연결 상태를 다시 비활성화 상태로 전환시키기 위한 안내 팝업의 표출, 네트워크 연결 상태를 자동으로 강제 종료시키는 방식 등이 이용될 수 있다. 사용자 단말에 설치된 운영체제(Operating System)에 따라 네트워크 연결을 자동으로 비활성화하거나 재연결시킬 수 있도록 허용하는 운영체제도 존재한다. 따라서 이러한 케이스에서는 거래연동 OTP 앱의 제어부(550)는 직접 에어플레인 모드(Airplane Mode)로 전환하거나 네트워크 비활성화 모드로 전환되도록 제어할 수 있으며, 이를 위해 거래연동 OTP 앱은 네트워크 제어부를 하위에 둘 수도 있다.
또한 도 26의 단계 S260에서, 거래연동 OTP 앱의 구동에 따른 기능 실행을 제한한다고 함은, 거래연동 OTP 앱의 데이터 초기화, 앱 구동에 따른 데이터 처리(연산)의 제한, 앱 화면의 초기화 등이 여기에 해당될 수 있다. 이때, 초기화 시키는 값은 사용자가 입력 또는 선택하였던 거래정보와, OTP 생성부(530)에서 생성된 OTP 토큰값 등이 될 수 있으며, 또는 OTP 앱의 구동에 따라 현재 생성 또는 새롭게 저장된 모든 데이터일 수도 있다.
위와 달리, 네트워크 확인부(510)를 통한 주기적인 확인 결과, 네트워크 연결이 비활성화 상태로 지속되는 것으로 판단되는 경우, 제어부(550)는 거래연동 OTP 앱을 통해 표출되는 GUI 화면(도 27 내지 도 31 참조)을 통해 거래정보의 입력, 거래정보 저장부(520)를 통한 거래정보에 관한 데이터 저장, OTP 생성부(530)를 통한 거래연동 OTP의 생성, GUI 화면 표시부(540)를 통한 앱 화면 표출 등이 가능하도록 제어할 수 있다.
본 발명의 실시예에서, 거래연동 OTP 앱을 통한 거래연동 OTP의 생성에는 사용자에 의해 선택된 거래정보가 이용될 수 있다. 도 27 내지 도 30을 참조할 때, 거래연동 OTP의 생성에는 거래은행(즉, 금융기관), 입금 계좌정보, 거래 금액이 활용되는 경우를 예시하였지만, 이에 한정되는 것은 아님은 물론이다. 즉, 거래연동 OTP의 생성에는 거래은행, 예금주 명, 거래 금액, 입금 계좌번호, 부여된 거래번호, 거래 조건 등의 다양한 거래정보 중 적어도 하나가 활용될 수 있다. 이러한 거래정보의 입력항목 또는 선택항목은 앱 구현 방식에 따라 다양하게 변형될 수 있다.
또한 이때, 구현방식에 따라서 한번 입력 받았던 거래정보는 암호화하여 저장하였다가 필요시 사용자의 선택에 따라서 재활용할 수 있다. 자주 쓰는 거래정보를 저장할 때 닉네임을 설정하여 향후 손쉽게 거래정보를 호출하여 사용할 수 도 있다. 뿐만 아니라 구현 방식에 따라서 입력되거나 재사용된 거래정보를 해쉬값으로 변환하여 OTP 생성부(530)에 전달할 수 도 있다.
OTP 생성부(530)는 거래연동 OTP 생성 알고리즘을 담당하는 구성부로서, OTP 고유키 값, OTP 가변값(시간 또는/및 시도횟수)에 선택된 거래정보를 받아서 거래연동 OTP 토큰값을 생성하여 GUI 화면 표시부(540)에 전달할 수 있다.
GUI 화면 표시부(540)은 OTP 생성부(530)에서 생성된 OTP 토큰 내역을 사용자에게 표시한다[도 30 참조]. 구현 방식에 따라서는 추가적으로 GUI 화면 표시부(540) 화면에 OTP 토큰값 이외에도 'OTP 앱 종료' 또는 'OTP 앱 종료 및 네트워크 재개' 버튼을 제공할 수 있다[도 31 참조].
거래연동 OTP 앱이 직접 네트워크의 비활성화/활성화를 제어할 수 있게 허용된 운영체제의 경우, 네트워크 확인부(510)를 통해서 앱 종료 직전 네트워크를 구동하고 제어부(550)가 앱을 종료할 수 있도록 제어할 수도 있다. 이 경우, 제어부(550)는 네트워크가 재개되고 난 뒤 앱을 종료하기 직전 사용자가 입력하거나 선택한 거래정보를 다른 서버에 추가로 전송되도록 할 수도 있다.
이상에서는 거래연동 OTP 생성에 은행에서의 입출금과 관련된 거래정보가 이용되는 경우를 주로 설명하였지만, 거래연동 OTP 생성에 이용될 거래정보는, 거래 기관의 성격에 맞추어서 달라질 수 있다. 예를 들어 증권사의 경우 매수종목코드, 매수수량, 매수금액 등으로 구성될 수 있으며, 쇼핑몰의 경우 상품코드, 주문수량, 주문금액 등으로 구성될 수 있으며, 채권이나 전자화폐의 경우도 거래상대방의 거래기관, 거래번호, 거래금액 등으로 구성될 수 있을 것이다.
또한 이상에서는 거래연동 OTP 생성에 거래정보가 이용되는 경우만을 주로 설명하였지만, 거래연동 OTP 생성에는 사용자 별로 구분 식별되는 코드정보가 이용될 수도 있다. 예를 들어, 거래정보와 무관하게, OTP 앱 화면을 통해 표출되는 사용자 식별을 위한 코드정보(일 예로, 금고의 회전식 비밀번호 선택키 형태로 표출되는 이미지를 통해 보여지는 숫자, 문자, 도형, 형상에 매칭되는 사용자 식별코드)가 거래연동 OTP 생성에 이용될 수도 있을 것이다.
또한 이상에서는 네트워크 연결 상태의 확인 결과에 따라서 거래연동 OTP 앱의 구동 또는 구동에 따른 기능 실행을 제한하거나 허용하는 경우만을 주로 설명하였지만, 다른 추가 제한도 더 존재할 수 있다. 예를 들어, 거래연동 OTP 앱이 구동 중인 상태에서, 해당 앱의 화면이 포어그라운드(Foreground) 상태에서 백그라운드(Background) 상태로 전환되는지 여부를 확인하고, 백그라운드 상태로 전환되는 경우 OTP 앱 구동 또는 구동에 따른 기능 실행이 제한되도록 하는 추가 제한 사항도 더 존재할 수 있을 것이다.
이상에서는 사용자 단말에서 거래연동 OTP 앱의 구동 방법과 관련된 구성부들의 각 역할에 대하여 설명하였는 바, 이하에서는 본 발명의 내용이 보다 명확히 이해될 수 있도록, 실제 구현의 일 예에 관하여 설명하기로 한다.
먼저, 사용자 단말의 운영체제가 앱에서 에어플레인 모드(비행기 탑승 모드) 설정이나 WiFi 설정 변경을 지원하는 경우, 거래연동 OTP 앱이 구동되면 네트워크 확인부(510)는 현재 에어플레인 모드 값과 WiFi 설정 값을 확인하여 연결되어 있다면 네트워크를 비활성화시킨다. 만약 운영체제가 앱에서 에어플레인 모드 또는 WiFi 모드 전환을 지원하지 않는다면 앱 구동을 중단하고 사용자에게 네트워크 설정을 해제하고 접속할 것을 안내한다.
네트워크가 비활성화된 상태가 확인되면 GUI 화면 표시부(540)가 구동되어 거래기관, 거래계좌, 거래금액, 거래조건 등을 사용자로부터 입력 받는다. 자주 쓰는 거래주체에 대한 정보를 보관하기 위해서 필요에 따라서는 거래주체 별칭을 저장하도록 하고, 사용자가 불필요하게 거래기관, 거래계좌를 입력하지 않도록 할 수 있다. 이때 구현방법에 따라서 입력된 값을 암호화하거나 해쉬값으로 변형하여 네트워크가 재개되는 시점에 미리 지정한 제3의 외부 검증서버에 전송하고 앱을 종료할 수도 있다. OTP 생성부(530)는 OTP고유값에 가변정보(시간 또는 횟수)에 거래정보 등을 이용하여 OTP 토큰값을 생성한다. 생성된 OTP 토큰값은 GUI 화면 표시부(540)에 표시된다.
이 경우, 제어부(550)는 화면 표출 설정 시간을 구성하여, 거래연동 OTP가 화면에 표출된 이후 지정된 화면 표출 설정 시간이 경과한 경우, 거래연동 OTP 앱의 구동 또는 구동에 따른 기능 수행 중 적어도 하나가 제한되도록 제어할 수 있다. 또는 제어부(550)는 거래연동 OTP 앱이 계속 구동되는 것을 비활성화할 수 있고, OTP 표시 화면에 사용자에게 OTP 종료와 함께 네트워크 연결을 유도할 수 있는 선택버튼을 제시하여, 사용자가 OTP를 거래 매체에 입력하도록 환경을 제공할 수 있다.
본 실시예에 의하면, 사용자 단말에서 OTP 앱을 구동한다 하더라도 OTP 토큰값이 유효한 시간 동안 제3자에 의해서 유출되지 않는다.
또한 본 실시예에 의하면, 네트워크가 비활성화되는 동안에 어떤 거래 정보가 사용자에 의해서 입력되거나 선택되었는지 제3자가 알 수 없다.
또한 본 실시예에 의하면, 종래의 숫자 입력 버튼만 갖추고 있는 하드웨어기반의 거래연동 OTP 동글과 대비할 때, 사용자 단말의 편리한 입력 구조로 인하여 거래연동 OTP 활성화가 가능하며, 상시 휴대하는 사용자 단말의 장점과 소프트웨어 타입의 경제성까지 갖출 수 있게 된다.
본 발명의 실시예에 따른 방법 및 장치는 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다.
컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media) 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상에서는 본 발명의 실시예를 참조하여 설명하였지만, 해당 기술 분야에서 통상의 지식을 가진 자라면 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 쉽게 이해할 수 있을 것이다.

Claims (11)

  1. 온라인 서비스 서버와 서비스 사용자 간의 상호 인증을 수행하는 컴퓨터 구현 방법(computer implemented method)으로서,
    (a) 인증 서버가, 서버 검증용 OTP 생성 요청에 따라 서버 검증용 OTP를 생성하는 단계;
    (b) OTP 생성기가, 상기 온라인 서비스 서버의 진위 확인을 위해 상기 서버 검증용 OTP와 동일 조건의 확인용 OTP를 생성하고, 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 동일한 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과는 다른 연산 조건을 적용하거나 또는 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 다른 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과 동일한 연산 조건을 적용함으로써 상기 서버 검증용 OTP와 페어링되는 값을 갖는 사용자 OTP를 생성하는 단계; 및
    (c) 상기 온라인 서비스 서버로부터 상기 사용자 OTP를 포함하는 사용자 인증 요청이 수신된 경우, 상기 인증 서버가, 상기 사용자 OTP와 동일 조건의 대응 OTP를 생성하고, 상기 생성된 대응 OTP와 상기 사용자 OTP 간의 일치 여부를 비교함으로써 상기 서비스 사용자에 대한 인증을 수행하는 단계
    를 포함하는 상호 인증을 위한 컴퓨터 구현 방법.
  2. 제1항에 있어서,
    상기 (b) 단계 이전에,
    상기 인증 서버가, 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키 및 연산 조건이 푸시 메시지 또는 소켓 전송을 통해서 상기 서비스 사용자의 모바일 기기에 설치된 상기 OTP 생성기로 전송되도록 하는 단계
    를 더 포함하는 상호 인증을 위한 컴퓨터 구현 방법.
  3. 제1항에 있어서,
    상기 서버 검증용 OTP 생성 요청은, 상기 서비스 사용자가 상기 온라인 서비스 서버가 제공하는 온라인 사이트에 입력한 사용자 계정 정보가 사전 등록된 해당 사용자의 계정 정보와 일치하는 경우, 상기 온라인 서비스 서버로부터 상기 인증 서버로 전송되는, 상호 인증을 위한 컴퓨터 구현 방법.
  4. 제1항에 있어서,
    상기 서버 검증용 OTP 생성에 사용되는 상기 OTP 생성키로는, 상기 서비스 사용자의 사용자 계정 정보에 대응하여 사전 등록된 고정키, 진정한 온라인 서비스 서버의 식별 정보에 대응하는 사전 등록된 고정키, 상기 서비스 사용자가 상기 온라인 서비스 서버에 접속하는 시점에 동적으로 할당되는 동적 할당키 중 어느 하나가 이용되는 것을 특징으로 하는, 상호 인증을 위한 컴퓨터 구현 방법.
  5. 제4항에 있어서,
    상기 동적 할당키로는, 상기 온라인 서비스 서버로 접속하는 상기 서비스 사용자의 접속단말 연결정보가 이용되고,
    상기 접속단말 연결정보는, 상기 서비스 사용자의 접속시 상기 온라인 서비스 서버에 의해 할당되는 세션 ID(Session ID) 또는 소켓 핸들(socket handle) 정보인 것을 특징으로 하는, 상호 인증을 위한 컴퓨터 구현 방법.
  6. 제1항에 있어서,
    상기 서버 검증용 OTP는, 상기 OTP 생성키를 시드값으로 이용하되 챌린지 앤드 리스폰스(Challenge & Response) 생성 방식에 기반한 제1 연산 조건으로서 시도 횟수를 연산 조건으로 하여 생성하고,
    상기 사용자 OTP는, 상기 OTP 생성키와 동일 생성키를 시드값으로 이용하되 타임 OTP 생성 방식에 기반한 제2 연산 조건으로서 시간을 연산 조건으로 하여 생성하는 것을 특징으로 하는, 상호 인증을 위한 컴퓨터 구현 방법.
  7. 제6항에 있어서,
    상기 서비스 사용자에 의한 상기 온라인 서비스 서버로의 접속 시도에 따른 사용자 OTP 입력 유효시간이 경과되기 전 또는 사용자 OTP 입력이 이루어지기 전에, 상기 서비스 사용자의 사용자 계정 정보와 동일한 계정 정보를 이용한 후순위의 접속이 재시도된 경우,
    상기 인증 서버는, 상기 사용자 OTP 입력 유효시간 동안 또는 상기 사용자 OTP 입력이 이루어지기 전까지, 선순위 접속에 따라 생성된 서버 검증용 OTP를 그대로 유지하거나 또는 후순위 접속에 따른 서버 검증용 OTP의 신규 생성을 금지하는 것을 특징으로 하는, 상호 인증을 위한 컴퓨터 구현 방법.
  8. 제1항에 있어서,
    상기 서버 검증용 OTP와 상기 사용자 OTP는, 동일 생성키 및 동일 생성 방식에 의하되 모드 구별자를 달리한 서로 다른 연산 조건에 의해 생성됨으로써 상호 간에 페이링되는 값으로 생성되는, 상호 인증을 위한 컴퓨터 구현 방법.
  9. 제1항에 있어서,
    상기 인증 서버가, 상기 생성된 서버 검증용 OTP가 상기 온라인 서비스 서버에 의해 제공되는 OTP 게시 화면을 통해 게시되도록 상기 서버 검증용 OTP를 상기 온라인 서비스 서버로 전송하는 단계를 더 포함하고,
    상기 OTP 게시 화면에는 상기 서버 검증용 OTP를 게시하는 OTP 표시창과 사용자 OTP의 입력을 위한 OTP 입력창이 함께 표출되고,
    상기 (b) 단계에서, 상기 사용자 OTP는 상기 OTP 생성기가 설치된 모바일 기기를 통한 동일 화면 상에서 상기 확인용 OTP와 페어링되어 표출되는, 상호 인증을 위한 컴퓨터 구현 방법.
  10. 제9항에 있어서,
    상기 OTP 표시창과 상기 OTP 입력창은 인지적 구별이 가능하도록 상기 OTP 게시 화면 내에 표출되되,
    상기 모바일 기기의 동일 화면을 통해 표출되는 상기 확인용 OTP와 상기 사용자 OTP는, 상기 OTP 표시창과 상기 OTP 입력창에 적용된 것과 동일한 인지적 구별 효과가 적용되어 상기 모바일 기기의 화면 상에 표출되는, 상호 인증을 위한 컴퓨터 구현 방법.
  11. 온라인 서비스 서버와 서비스 사용자 간의 상호 인증을 수행하는 인증 시스템으로서,
    서버 검증용 OTP 생성 요청에 따라 서버 검증용 OTP를 생성하고, 상기 온라인 서비스 서버로부터 사용자 OTP를 포함하는 사용자 인증 요청이 수신된 경우 상기 사용자 OTP와 동일 조건의 대응 OTP를 생성하고 상기 생성된 대응 OTP와 상기 사용자 OTP 간의 일치 여부를 비교하여 상기 서비스 사용자에 대한 인증을 수행하는, 인증 서버; 및
    상기 온라인 서비스 서버의 진위 확인을 위해 상기 서버 검증용 OTP와 동일 조건의 확인용 OTP를 생성하고, 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 동일한 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과는 다른 연산 조건을 적용하거나 또는 상기 서버 검증용 OTP 생성에 사용된 OTP 생성키와 다른 생성키를 이용하되 상기 서버 검증용 OTP 생성에 사용된 연산 조건과 동일한 연산 조건을 적용함으로써 상기 서버 검증용 OTP와 페어링되는 값을 갖는 사용자 OTP를 생성하는, OTP 생성기
    를 포함하는 상호 인증을 위한 인증 시스템.
PCT/KR2016/000951 2015-02-06 2016-01-28 인증 방법 및 시스템 WO2016126052A2 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/540,035 US10298400B2 (en) 2015-02-06 2016-01-28 Authentication method and system
US16/377,242 US10574463B2 (en) 2015-02-06 2019-04-07 Authentication method and system
US16/748,765 US11876908B2 (en) 2015-02-06 2020-01-21 Authentication method and system
US18/512,061 US20240089110A1 (en) 2015-02-06 2023-11-17 Authentication method and system

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
KR1020150018752A KR101570317B1 (ko) 2015-02-06 2015-02-06 Otp 애플리케이션 구동 방법
KR10-2015-0018752 2015-02-06
KR20150062552 2015-05-04
KR10-2015-0062552 2015-05-04
KR20150074949 2015-05-28
KR10-2015-0074949 2015-05-28
KR20150129976 2015-09-14
KR10-2015-0129976 2015-09-14
KR10-2015-0187986 2015-12-28
KR20150187986 2015-12-28

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/540,035 A-371-Of-International US10298400B2 (en) 2015-02-06 2016-01-28 Authentication method and system
US16/377,242 Continuation US10574463B2 (en) 2015-02-06 2019-04-07 Authentication method and system

Publications (2)

Publication Number Publication Date
WO2016126052A2 true WO2016126052A2 (ko) 2016-08-11
WO2016126052A3 WO2016126052A3 (ko) 2016-11-10

Family

ID=56564851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/000951 WO2016126052A2 (ko) 2015-02-06 2016-01-28 인증 방법 및 시스템

Country Status (2)

Country Link
US (4) US10298400B2 (ko)
WO (1) WO2016126052A2 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018160039A1 (ko) * 2017-03-03 2018-09-07 주식회사 와임 분할 기능을 이용한 자동 인증 처리 방법 및 시스템
WO2019021152A1 (en) * 2017-07-27 2019-01-31 Adari Swarna Kumari REAL-TIME CREATION OF A BANK ACCOUNT AND DISTRIBUTION OF A HOST KIT FOR THE BANK ACCOUNT VIA A BANKING AUTOMATIC WINDOW
WO2021010778A1 (ko) * 2019-06-14 2021-01-21 우순조 고유 정보를 이용한 실시간 문자열 변조/복조 장치 및 방법

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9858401B2 (en) * 2011-08-09 2018-01-02 Biogy, Inc. Securing transactions against cyberattacks
WO2016134657A1 (zh) * 2015-02-27 2016-09-01 飞天诚信科技股份有限公司 一种推送认证的系统和设备的工作方法
US10911452B2 (en) * 2016-11-22 2021-02-02 Synergex Group (corp.) Systems, methods, and media for determining access privileges
US10484177B2 (en) 2017-07-10 2019-11-19 Dell Products, Lp Method and apparatus for generation of a time-based one-time password for session encryption of sensor data gathered in low-performance and IOT environments
US11063916B1 (en) * 2017-08-01 2021-07-13 Amazon Technologies, Inc. Facility control service
US20190306153A1 (en) * 2018-03-27 2019-10-03 Ca, Inc. Adaptive risk-based password syncronization
US10984093B2 (en) * 2018-04-30 2021-04-20 Western Digital Technologies, Inc. Memory and controller mutual secure channel association
CN109120597B (zh) * 2018-07-18 2020-09-01 阿里巴巴集团控股有限公司 身份校验、登录方法、装置及计算机设备
US11245526B2 (en) * 2019-12-05 2022-02-08 Identité, Inc. Full-duplex password-less authentication
JP7322732B2 (ja) * 2020-02-03 2023-08-08 トヨタ自動車株式会社 認証システム
WO2021229749A1 (ja) * 2020-05-14 2021-11-18 甲賀電子株式会社 Ｉｐ通信における認証方法および認証システム

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491752A (en) * 1993-03-18 1996-02-13 Digital Equipment Corporation, Patent Law Group System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens
US6360254B1 (en) * 1998-09-15 2002-03-19 Amazon.Com Holdings, Inc. System and method for providing secure URL-based access to private resources
US7437550B2 (en) * 1999-12-02 2008-10-14 Ponoi Corp. System for providing session-based network privacy, private, persistent storage, and discretionary access control for sharing private data
US7409543B1 (en) * 2000-03-30 2008-08-05 Digitalpersona, Inc. Method and apparatus for using a third party authentication server
US7526798B2 (en) * 2002-10-31 2009-04-28 International Business Machines Corporation System and method for credential delegation using identity assertion
US20040103325A1 (en) * 2002-11-27 2004-05-27 Priebatsch Mark Herbert Authenticated remote PIN unblock
BRPI0417326B1 (pt) * 2003-12-23 2019-03-06 Wachovia Corporation Sistema de autenticação para aplicativos de computadores em rede
US8185961B2 (en) * 2005-03-10 2012-05-22 Nippon Telegraph And Telephone Corporation Network system, method for controlling access to storage device, management server, storage device, log-in control method, network boot system, and method of accessing individual storage unit
US7904946B1 (en) * 2005-12-09 2011-03-08 Citicorp Development Center, Inc. Methods and systems for secure user authentication
US9768963B2 (en) * 2005-12-09 2017-09-19 Citicorp Credit Services, Inc. (Usa) Methods and systems for secure user authentication
JP3939736B1 (ja) * 2006-03-27 2007-07-04 株式会社シー・エス・イー ユーザ認証システム、およびその方法
KR100847999B1 (ko) * 2006-06-30 2008-07-23 포스데이타 주식회사 네트워크 기반의 ｄｖｒ 시스템에 있어서 ｄｖｒ 서버 및모니터링 대상 단말 접근 제어 방법
KR100786551B1 (ko) * 2006-09-15 2007-12-21 이니텍(주) 복수 개의 방식에 의한 일회용 비밀번호의 사용자 등록,인증 방법 및 그러한 방법을 수행하는 프로그램이 기록된컴퓨터 판독 가능 기록 매체
US8539559B2 (en) * 2006-11-27 2013-09-17 Futurewei Technologies, Inc. System for using an authorization token to separate authentication and authorization services
WO2008105602A1 (en) * 2007-02-28 2008-09-04 Mininfo Co., Ltd. User authentication method and system using graphic otp
NO332479B1 (no) * 2009-03-02 2012-09-24 Encap As Fremgangsmåte og dataprogram for verifikasjon av engangspassord mellom tjener og mobil anordning med bruk av flere kanaler
KR101625222B1 (ko) * 2009-06-18 2016-06-13 주식회사 비즈모델라인 씨드 조합 방식의 오티피 운영 방법
US8843757B2 (en) * 2009-11-12 2014-09-23 Ca, Inc. One time PIN generation
CN102713922B (zh) * 2010-01-12 2015-11-25 维萨国际服务协会 用于对验证令牌的任何时候确认的方法
US8627088B2 (en) * 2010-02-10 2014-01-07 Authernative, Inc. System and method for in- and out-of-band multi-factor server-to-user authentication
KR101028882B1 (ko) 2010-09-14 2011-04-12 김종승 휴대단말기를 이용한 ｏｔｐ 방식의 사용자인증 시스템 및 방법
SG189120A1 (en) * 2010-10-05 2013-05-31 Cse Co Ltd System and method for two-factor user authentication
US20130139222A1 (en) * 2011-11-29 2013-05-30 Rawllin International Inc. Authentication of mobile device
US9118662B2 (en) * 2011-12-27 2015-08-25 Intel Corporation Method and system for distributed off-line logon using one-time passwords
US9367678B2 (en) * 2012-02-29 2016-06-14 Red Hat, Inc. Password authentication
KR101409754B1 (ko) * 2012-03-12 2014-06-19 에스케이플래닛 주식회사 오프라인 거래 결제 시스템, 이를 위한 방법 및 장치
KR101513694B1 (ko) 2013-02-26 2015-04-22 (주)이스톰 Otp 인증 시스템 및 방법
US9143492B2 (en) * 2013-03-15 2015-09-22 Fortinet, Inc. Soft token system
KR20130060249A (ko) * 2013-05-20 2013-06-07 장부권 비밀번호 관리 시스템 및 관리 방법
US20140365780A1 (en) * 2013-06-07 2014-12-11 Safa Movassaghi System and methods for one-time password generation on a mobile computing device
US9332008B2 (en) * 2014-03-28 2016-05-03 Netiq Corporation Time-based one time password (TOTP) for network authentication

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018160039A1 (ko) * 2017-03-03 2018-09-07 주식회사 와임 분할 기능을 이용한 자동 인증 처리 방법 및 시스템
US11240230B2 (en) 2017-03-03 2022-02-01 Waem Co., Ltd. Automatic authentication processing method and system using dividing function
WO2019021152A1 (en) * 2017-07-27 2019-01-31 Adari Swarna Kumari REAL-TIME CREATION OF A BANK ACCOUNT AND DISTRIBUTION OF A HOST KIT FOR THE BANK ACCOUNT VIA A BANKING AUTOMATIC WINDOW
WO2021010778A1 (ko) * 2019-06-14 2021-01-21 우순조 고유 정보를 이용한 실시간 문자열 변조/복조 장치 및 방법

Also Published As

Publication number Publication date
US20200162258A1 (en) 2020-05-21
US20240089110A1 (en) 2024-03-14
US11876908B2 (en) 2024-01-16
US20190238336A1 (en) 2019-08-01
US10298400B2 (en) 2019-05-21
WO2016126052A3 (ko) 2016-11-10
US10574463B2 (en) 2020-02-25
US20180270067A1 (en) 2018-09-20

Similar Documents

Publication Publication Date Title
WO2016126052A2 (ko) 인증 방법 및 시스템
WO2021060857A1 (ko) 원격 실행 코드 기반 노드의 제어 플로우 관리 시스템 및 그에 관한 방법
WO2011149214A2 (ko) 오티피를 생성하기 위해 홍채정보를 이용한 쓰리-팩터 사용자 인증방식과 무선통신단말기의 오티피 인증모듈을 이용한 안전한 상호인증시스템
WO2019231252A1 (en) Electronic device for authenticating user and operating method thereof
WO2016167536A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2016178548A1 (ko) 프로파일 제공 방법 및 장치
EP3284274A1 (en) Method and apparatus for managing a profile of a terminal in a wireless communication system
WO2018082482A1 (zh) 一种网络共享方法、接入网络方法及系统
WO2017099342A1 (ko) 임시 계정 정보를 제공하는 방법, 장치 및 시스템
WO2016003200A1 (en) Method and apparatus for installing profile for euicc
WO2015137745A1 (en) System and method of encrypting folder in device
WO2017054481A1 (zh) 一种信息验证和处理方法、装置、以及信息处理系统
WO2011079753A1 (zh) 认证方法、认证交易系统和认证装置
WO2020197221A1 (ko) 통신 방법 및 통신 디바이스
WO2019001110A1 (zh) 权限认证方法、系统、设备及计算机可读存储介质
WO2017035695A1 (zh) 信息传输方法及移动设备
WO2020171672A1 (en) Method for interoperating between bundle download process and esim profile download process by ssp terminal
WO2017084337A1 (zh) 一种身份验证方法、装置和系统
WO2018034491A1 (en) A primary device, an accessory device, and methods for processing operations on the primary device and the accessory device
WO2019132555A1 (ko) 이모지가 포함된 메시지를 송수신하는 전자 장치 및 그 전자 장치를 제어하는 방법
WO2023106759A1 (ko) Qr코드 스캔·셀픽형 웹중개제어로 이루어진 하이브리드식 사진인화키오스크형 오프라인 이지 결제장치 및 방법
WO2019035491A1 (ko) 사용자 인증방법 및 장치
WO2020105892A1 (ko) 디바이스가 디지털 키를 공유하는 방법
WO2017188497A1 (ko) 무결성 및 보안성이 강화된 사용자 인증방법
WO2019194428A1 (ko) 외부 전자 장치의 키를 공유하는 전자 장치 및 전자 장치의 동작 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16746793

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 15540035

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16746793

Country of ref document: EP

Kind code of ref document: A2