WO2020091525A1 - 생체 인증을 이용한 결제 방법 및 그 전자 장치 - Google Patents

생체 인증을 이용한 결제 방법 및 그 전자 장치 Download PDF

Info

Publication number
WO2020091525A1
WO2020091525A1 PCT/KR2019/014750 KR2019014750W WO2020091525A1 WO 2020091525 A1 WO2020091525 A1 WO 2020091525A1 KR 2019014750 W KR2019014750 W KR 2019014750W WO 2020091525 A1 WO2020091525 A1 WO 2020091525A1
Authority
WO
WIPO (PCT)
Prior art keywords
biometric authentication
biometric
password
server
payment
Prior art date
Application number
PCT/KR2019/014750
Other languages
English (en)
French (fr)
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
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to US17/290,579 priority Critical patent/US20220005046A1/en
Publication of WO2020091525A1 publication Critical patent/WO2020091525A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code
    • G07F7/1091—Use of an encrypted form of the PIN

Definitions

  • Various embodiments of the present invention relate to a payment method using biometric authentication and its electronic device.
  • User authentication is required for online or offline payments. User authentication using a user ID and password has been used as a method for user authentication, and a method of authenticating a user using biometric information has also been proposed.
  • An example of the user authentication using the existing biometric information may include the Fast Identity Online (FIDO) standard, and the FIDO standard clearly registers, authenticates, and unregisters the procedure explicitly, according to the FIDO standard When an error such as a non-registration status or an authentication failure occurs through the FIDO client and the FIDO server, the procedures for separately registering biometric information and performing authentication are sequentially performed.
  • FIDO Fast Identity Online
  • Various embodiments of the present invention provide an electronic device and a payment method using biometric authentication that enables an authentication issuing server to perform biometric authentication directly and efficiently and simultaneously perform registration and authentication.
  • an electronic device includes a communication module configured to provide communication with a server, a processor operatively connected to the communication module, and a memory operatively connected to the processor and configured to store biometric information.
  • the memory includes, when executed, the processor authenticates biometric authentication parameters and passwords for biometric authentication to register biometric authentication information for biometric authentication verification and password authentication passwords at the server upon initial use registration.
  • biometric authentication parameters and passwords for biometric authentication to register biometric authentication information for biometric authentication verification and password authentication passwords at the server upon initial use registration.
  • a server includes a communication module configured to provide communication with an electronic device, a processor operatively connected to the communication module, and a memory operatively connected to the processor and configured to store biometric authentication information.
  • the memory includes, at execution time, when the processor is registered for the first time, the processor receives parameters for verification of biometric authentication and an encrypted password for verification of password authentication, and decrypts the encrypted password. Parameters for storing the password in the memory, verifying biometric authentication based on the parameters for verifying the biometric authentication, storing the acquired biometric authentication information in the memory, and verifying the biometric authentication received at the time of payment using biometric authentication And biometric authentication based on the stored biometric authentication information.
  • an operation method of an electronic device includes parameters and passwords for biometric authentication verification in order to register biometric authentication information for biometric authentication verification and password authentication password registration at the server upon initial use registration Generating an encrypted password for authentication verification and transmitting it to the server, performing user authentication using at least one of the biometric authentication or the password authentication at the time of payment, and for biometric authentication information registered in the server When a change is necessary, it may include an operation of registering new biometric authentication information to the server while performing payment.
  • a method of operating a server includes receiving parameters for verification of biometric authentication and an encrypted password for verifying password authentication from an electronic device upon initial use registration, decrypting the encrypted password And storing the password in the memory, verifying biometric authentication based on the parameters for verifying the biometric authentication, and storing the acquired biometric authentication information in the memory, and for verifying the received biometric authentication at the time of payment. And at least one of verifying a biometric authentication based on the parameter and the stored biometric authentication information, and verifying password authentication by comparing the password obtained from the received encrypted password and the password stored in the memory.
  • New registration required for biometric authentication information A case, it is possible to include an operation that stores new biometric authentication information registered while performing a payment using the biometric authentication in the memory.
  • the method and the electronic device allow the authentication issuing server to directly and efficiently perform biometric authentication, thereby eliminating the problem of simultaneous service unavailable and system complexity due to the common use of the biometric authentication server, Maintenance and security can be improved, and the cost of paying the usage fee can be eliminated.
  • the method and the electronic device may simultaneously register and authenticate to solve a time delay problem due to separate progress and increase user usability.
  • FIG. 1 is a block diagram of an electronic device in a network environment according to various embodiments.
  • FIG. 2 is a block diagram illustrating a program according to various embodiments.
  • FIG. 3 is a block diagram illustrating a general execution environment and a secure execution environment operated in an electronic device according to various embodiments of the present disclosure.
  • FIG. 4 is a system configuration diagram for a payment method using biometric authentication according to various embodiments.
  • FIG. 5 is a flowchart illustrating a procedure for registering user authentication information according to various embodiments.
  • FIG. 6 is a flowchart illustrating a procedure for performing online payment according to various embodiments.
  • FIG. 7 is a flowchart illustrating a procedure for deleting payment related information and user authentication information according to various embodiments.
  • FIG. 8 is a flowchart illustrating a recovery procedure through password authentication according to verification failure by biometric authentication according to various embodiments.
  • FIG. 9 is a flowchart illustrating an operation of registering payment information and user authentication information of an electronic device according to various embodiments of the present disclosure.
  • FIG. 10 is a flowchart illustrating a biometric authentication operation of an electronic device according to various embodiments of the present disclosure.
  • FIG. 11 is a flowchart illustrating a password authentication operation of an electronic device according to various embodiments of the present disclosure.
  • FIG. 12 is a flowchart illustrating a payment operation of an electronic device according to various embodiments of the present disclosure.
  • FIG. 13 is a flowchart illustrating an operation of registering payment information and user authentication information of the issuer server according to various embodiments.
  • FIG. 14 is a flowchart illustrating an operation at the time of payment of the issuer server according to various embodiments.
  • 15 is a flowchart illustrating an operation upon payment of a publisher server after biometric authentication information is initialized by a recovery procedure according to various embodiments.
  • 16 is a flowchart illustrating a biometric authentication verification operation of the issuer server according to various embodiments.
  • 17 is a flowchart briefly illustrating an operation for user authentication of an electronic device according to various embodiments of the present disclosure.
  • FIG. 18 is a flowchart illustrating an authentication procedure at the time of payment according to a state of storing biometric authentication information of an electronic device and a state of registering biometric authentication information of an issuer server according to various embodiments.
  • 19A to 19F are diagrams illustrating an embodiment displayed on a display device when a biometric authentication verification fails during a payment according to FIG. 14 according to various embodiments and a recovery procedure through password authentication is performed.
  • the electronic device 101 communicates with the electronic device 102 through the first network 198 (eg, a short-range wireless communication network), or the second network 199. It may communicate with the electronic device 104 or the server 108 through (eg, a remote wireless communication network). According to an embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • the first network 198 eg, a short-range wireless communication network
  • the server 108 e.g, a remote wireless communication network
  • the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • the electronic device 101 includes a processor 120, a memory 130, an input device 150, an audio output device 155, a display device 160, an audio module 170, a sensor module ( 176), interface 177, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196, or antenna module 197 ).
  • at least one of the components may be omitted or at least one other component may be added to the electronic device 101.
  • some of these components may be implemented as one integrated circuit.
  • the sensor module 176 eg, a fingerprint sensor, an iris sensor, or an illuminance sensor
  • the display device 160 eg, a display.
  • the processor 120 executes software (eg, the program 140) to execute at least one other component (eg, hardware or software component) of the electronic device 101 connected to the processor 120. It can be controlled and can perform various data processing or operations. According to one embodiment, as at least part of data processing or computation, the processor 120 may receive instructions or data received from other components (eg, the sensor module 176 or the communication module 190) in the volatile memory 132. Loaded into, process instructions or data stored in volatile memory 132, and store result data in non-volatile memory 134.
  • software eg, the program 140
  • the processor 120 may receive instructions or data received from other components (eg, the sensor module 176 or the communication module 190) in the volatile memory 132. Loaded into, process instructions or data stored in volatile memory 132, and store result data in non-volatile memory 134.
  • the processor 120 includes a main processor 121 (eg, a central processing unit or an application processor), and an auxiliary processor 123 (eg, a graphics processing unit, an image signal processor) that can be operated independently or together. , A sensor hub processor, or a communication processor). Additionally or alternatively, the coprocessor 123 may be set to use lower power than the main processor 121, or to be specialized for a specified function. The coprocessor 123 may be implemented separately from the main processor 121 or as part of it.
  • a main processor 121 eg, a central processing unit or an application processor
  • an auxiliary processor 123 eg, a graphics processing unit, an image signal processor
  • the coprocessor 123 may be set to use lower power than the main processor 121, or to be specialized for a specified function.
  • the coprocessor 123 may be implemented separately from the main processor 121 or as part of it.
  • the coprocessor 123 may replace, for example, the main processor 121 while the main processor 121 is in an inactive (eg, sleep) state, or the main processor 121 may be active (eg, execute an application) ) With the main processor 121 while in the state, at least one of the components of the electronic device 101 (for example, the display device 160, the sensor module 176, or the communication module 190) It can control at least some of the functions or states associated with.
  • the coprocessor 123 eg, image signal processor or communication processor
  • may be implemented as part of other functionally relevant components eg, camera module 180 or communication module 190). have.
  • the memory 130 may store various data used by at least one component of the electronic device 101 (eg, the processor 120 or the sensor module 176).
  • the data may include, for example, software (eg, the program 140) and input data or output data for commands related thereto.
  • the memory 130 may include a volatile memory 132 or a non-volatile memory 134.
  • the program 140 may be stored as software in the memory 130, and may include, for example, an operating system 142, middleware 144, or an application 146.
  • the input device 150 may receive commands or data to be used for components (eg, the processor 120) of the electronic device 101 from outside (eg, a user) of the electronic device 101.
  • the input device 150 may include, for example, a microphone, mouse, keyboard, or digital pen (eg, a stylus pen).
  • the audio output device 155 may output an audio signal to the outside of the electronic device 101.
  • the audio output device 155 may include, for example, a speaker or a receiver.
  • the speaker can be used for general purposes such as multimedia playback or recording playback, and the receiver can be used to receive an incoming call.
  • the receiver may be implemented separately from, or as part of, the speaker.
  • the display device 160 may visually provide information to the outside of the electronic device 101 (eg, a user).
  • the display device 160 may include, for example, a display, a hologram device, or a projector and a control circuit for controlling the device.
  • the display device 160 may include a touch circuitry configured to sense a touch, or a sensor circuit (eg, a pressure sensor) configured to measure the intensity of the force generated by the touch. .
  • the audio module 170 may convert sound into an electrical signal, or vice versa. According to an embodiment, the audio module 170 acquires sound through the input device 150 or an external electronic device (eg, directly or wirelessly connected to the sound output device 155 or the electronic device 101) Sound may be output through the electronic device 102) (eg, a speaker or headphones).
  • an external electronic device eg, directly or wirelessly connected to the sound output device 155 or the electronic device 101
  • Sound may be output through the electronic device 102 (eg, a speaker or headphones).
  • the sensor module 176 detects an operating state (eg, power or temperature) of the electronic device 101 or an external environmental state (eg, a user state), and generates an electrical signal or data value corresponding to the detected state can do.
  • the sensor module 176 may include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biological sensor, It may include a temperature sensor, a humidity sensor, or an illuminance sensor.
  • the interface 177 may support at least one designated protocol that can be used for the electronic device 101 to directly or wirelessly connect to an external electronic device (eg, the electronic device 102).
  • the interface 177 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.
  • HDMI high definition multimedia interface
  • USB universal serial bus
  • SD card interface Secure Digital Card interface
  • audio interface audio interface
  • connection terminal 178 may include a connector through which the electronic device 101 can be physically connected to an external electronic device (eg, the electronic device 102).
  • the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).
  • the haptic module 179 may convert electrical signals into mechanical stimuli (eg, vibration or movement) or electrical stimuli that the user can perceive through tactile or motor sensations.
  • the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.
  • the camera module 180 may capture still images and videos. According to an embodiment, the camera module 180 may include at least one lens, image sensors, image signal processors, or flashes.
  • the power management module 188 may manage power supplied to the electronic device 101.
  • the power management module 188 may be implemented, for example, as at least part of a power management integrated circuit (PMIC).
  • PMIC power management integrated circuit
  • the battery 189 may supply power to at least one component of the electronic device 101.
  • the battery 189 may include, for example, a non-rechargeable primary cell, a rechargeable secondary cell, or a fuel cell.
  • the communication module 190 is a direct (eg, wired) communication channel or a wireless communication channel between the electronic device 101 and an external electronic device (eg, the electronic device 102, the electronic device 104, or the server 108). It can support establishing and performing communication through the established communication channel.
  • the communication module 190 operates independently of the processor 120 (eg, an application processor) and may include at least one communication processor supporting direct (eg, wired) communication or wireless communication.
  • the communication module 190 may include a wireless communication module 192 (eg, a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (eg : Local area network (LAN) communication module, or power line communication module.
  • a wireless communication module 192 eg, a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module
  • GNSS global navigation satellite system
  • LAN Local area network
  • Corresponding communication module among these communication modules includes a first network 198 (for example, a short-range communication network such as Bluetooth, WiFi direct, or infrared data association (IrDA)) or a second network 199 (for example, a cellular network, the Internet, or It may communicate with the external electronic device 104 through a computer network (eg, a telecommunication network such as LAN or WAN).
  • a computer network eg, a telecommunication network
  • the wireless communication module 192 uses a subscriber information (eg, an international mobile subscriber identifier (IMSI)) stored in the subscriber identification module 196 in a communication network such as the first network 198 or the second network 199.
  • IMSI international mobile subscriber identifier
  • the antenna module 197 may transmit a signal or power to the outside (eg, an external electronic device) or receive it from the outside.
  • the antenna module 197 may be formed of a conductor or a conductive pattern according to one embodiment, and according to an embodiment, may further include other components (eg, RFIC) in addition to the conductor or conductive pattern.
  • the antenna module 197 may include at least one antenna, from which at least suitable for a communication scheme used in a communication network such as the first network 198 or the second network 199 One antenna may be selected, for example, by the communication module 190.
  • the signal or power may be transmitted or received between the communication module 190 and an external electronic device through at least one selected antenna.
  • peripheral devices for example, a bus, a general purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)
  • GPIO general purpose input and output
  • SPI serial peripheral interface
  • MIPI mobile industry processor interface
  • the command or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199.
  • Each of the external electronic devices 102 and 104 may be the same or a different type of device from the electronic device 101.
  • all or some of the operations performed on the electronic device 101 may be performed on at least one external device among the external electronic devices 102, 104, or 108.
  • the electronic device 101 executes the function or service itself. Instead or additionally, it is possible to request at least one external electronic device to perform at least a part of the function or the service.
  • At least one external electronic device that has received the request may execute at least a part of the requested function or service, or an additional function or service related to the request, and deliver the result of the execution to the electronic device 101.
  • the electronic device 101 may process the result, as it is or additionally, and provide it as at least a part of the response to the request.
  • cloud computing, distributed computing, or client-server computing technology can be used.
  • the program 140 may include an operating system 142, middleware 144, or an application 146 executable in the operating system 142 for controlling one or more resources of the electronic device 101. It can contain.
  • the operating system 142 may include, for example, Android TM , iOS TM , Windows TM , Symbian TM , Tizen TM , or Bada TM .
  • At least some of the programs 140 may be preloaded on the electronic device 101 at the time of manufacture, for example, or when used by a user, an external electronic device (eg, the electronic device 102 or 104), or a server ( 108)).
  • the operating system 142 may control management (eg, allocation or retrieval) of one or more system resources (eg, process, memory, or power) of the electronic device 101.
  • the operating system 142 may additionally or alternatively include other hardware devices of the electronic device 101, such as the input device 150, the sound output device 155, the display device 160, and the audio module 170. , Sensor module 176, interface 177, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196, or One or more driver programs for driving the antenna module 197 may be included.
  • the middleware 144 may provide various functions to the application 146 so that functions or information provided from one or more resources of the electronic device 101 can be used by the application 146.
  • the middleware 144 includes, for example, an application manager 201, a window manager 203, a multimedia manager 205, a resource manager 207, a power manager 209, a database manager 211, and a package manager 213. ), A connectivity manager 215, a notification manager 217, a location manager 219, a graphics manager 221, a security manager 223, a call manager 225, or a speech recognition manager 227. You can.
  • the application manager 201 may manage the life cycle of the application 146, for example.
  • the window manager 203 may manage, for example, one or more GUI resources used in the screen.
  • the multimedia manager 205 for example, identifies one or more formats necessary for the reproduction of media files, and encodes or decodes the corresponding media file among the media files using a codec corresponding to the selected corresponding format among them. Can be done.
  • the resource manager 207 may manage, for example, source code of the application 146 or memory space of the memory 130.
  • the power manager 209 for example, manages the capacity, temperature, or power of the battery 189, and uses the information to determine or provide related information necessary for the operation of the electronic device 101. . According to an embodiment, the power manager 209 may interoperate with a basic input / output system (BIOS) (not shown) of the electronic device 101.
  • BIOS basic input / output system
  • the database manager 211 may create, search, or change a database to be used by the application 146, for example.
  • the package manager 213 may manage, for example, installation or update of an application distributed in the form of a package file.
  • the connectivity manager 215 may manage, for example, a wireless connection or direct connection between the electronic device 101 and an external electronic device.
  • the notification manager 217 may provide a function for notifying the user of the occurrence of a designated event (eg, an incoming call, message, or alarm), for example.
  • the location manager 219 may manage location information of the electronic device 101, for example.
  • the graphic manager 221 may manage, for example, one or more graphic effects to be provided to the user, or a user interface related thereto.
  • the security manager 223 may provide system security or user authentication, for example.
  • the telephony manager 225 may manage, for example, a voice call function or a video call function provided by the electronic device 101.
  • the voice recognition manager 227 may transmit, for example, a user's voice data to the server 108 and a command corresponding to a function to be performed in the electronic device 101 based at least in part on the voice data, Alternatively, the text data converted based at least in part on the voice data may be received from the server 108.
  • the middleware 244 may dynamically delete some of the existing components or add new components.
  • at least a part of the middleware 144 may be included as a part of the operating system 142, or may be implemented as software separate from the operating system 142.
  • Applications 146 include, for example, home 251, dialer 253, SMS / MMS 255, instant message (IM) 257, browser 259, camera 261, alarm 263 , Contact 265, Speech Recognition (267), Email (269), Calendar (271), Media Player (273), Album (275), Watch (277), Health (279) (e.g. exercise or blood sugar) Biometric information), or environmental information 281 (eg, air pressure, humidity, or temperature information measurement) applications.
  • the application 146 may further include an information exchange application (not shown) capable of supporting information exchange between the electronic device 101 and an external electronic device.
  • the information exchange application may include, for example, a notification relay application configured to deliver information (eg, a call, message, or alarm) designated to an external electronic device, or a device management application configured to manage an external electronic device. have.
  • the notification relay application may, for example, transmit notification information corresponding to a specified event (eg, receiving mail) generated by another application (eg, email application 269) of the electronic device 101 to the external electronic device. You can. Additionally or alternatively, the notification relay application may receive notification information from an external electronic device and provide it to a user of the electronic device 101.
  • the device management application may be, for example, an external electronic device that communicates with the electronic device 101 or some components thereof (for example, the display device 160 or the camera module 180) power (for example, turn-on or turn). -Off) or a function (eg, brightness, resolution, or focus of the display device 160 or the camera module 180).
  • the device management application may additionally or alternatively support installation, deletion, or update of an application operating on an external electronic device.
  • FIG. 3 is a block diagram 300 illustrating a general execution environment and a secure execution environment operated in an electronic device (eg, the electronic device 101) according to various embodiments.
  • the electronic device may operate an execution environment having a plurality of security levels to enhance security.
  • the plurality of execution environments may include, for example, a rich execution environment (REE) 310 and a trusted execution environment (TEE) 320.
  • the REE can be, for example, a first execution environment having a first security level.
  • the TEE may be, for example, a second execution environment having a second security level different (eg, higher) from the first security level.
  • the electronic device 101 may include a third execution environment having a third security level, but is not limited thereto.
  • the TEE 320 may store data requiring a relatively high security level in a secure environment and perform related operations.
  • the TEE 320 may operate on an application processor of an electronic device and operate based on a reliable hardware structure determined in the manufacturing process of the electronic device.
  • the TEE 320 may operate in a secure area by dividing an application processor or memory into a general area and a secure area.
  • the TEE 320 may set software or hardware requiring security to operate only in the security area.
  • the electronic device may operate a secure execution environment through physical change of hardware or logical change of software.
  • the TEE 320 may be referred to as an embedded secure element (ESE), secure element, or trust zone.
  • ESE embedded secure element
  • the TEE 320 may be separated from each other through the REE 310 and hardware constraints, and may be operated separately in software on the same hardware.
  • At least one application eg, payment, contact, e-mail, browser, etc.
  • an API eg, TEE functional API or TEE client API
  • the at least one application may transmit a message from a communication agent (REE communication agent) in a normal execution environment to a communication agent (TEE communication agent) in a secure execution environment using the API.
  • the message may be implemented to be delivered only to the TEE 320 in hardware.
  • the communication agent in the secure execution environment may receive the message and transmit it to a secure application (TA) associated with the message (eg, DRM, secure payment module, or secure biometric information module).
  • TA secure application
  • the security application may perform the operation related to the message, and may transmit the result of the operation to the communication agent in the general execution environment through the communication agent in the secure execution environment.
  • the communication agent in the general execution environment may deliver the result to at least one application operating in the general execution environment.
  • the electronic device 101 may include various components shown in FIG. 1, but in FIG. 4, only components necessary for simplicity of description are shown.
  • the server 410 may be included in the server 108 shown in FIG. 1, and the server 410 and the electronic device 101 communicate with each other using the first network 198 and / or the second network 199. can do.
  • the electronic device 101 may include a payment app 420, a biometric module 431, and an authentication module 433 to execute payment.
  • the payment app 420 may operate in the REE 310, and the biometric module 431 and the authentication module 433 may operate in the TEE 320.
  • the payment app 420, the biometric module 431, and the authentication module 433 may operate on one or more processors (for example, the processor 120 of FIG. 1), depending on the security environment operating method of the electronic device 101. It may operate on the same processor, or may operate on different processors.
  • the payment app 420 may be one of the applications 146 illustrated in FIG. 1 or FIG. 2, and may be executed when a user tries to make a payment.
  • the payment app 420 may include a password controller (PW) controller 421, a simple bio auth controller (SBA) controller 423, a biometric interface 425, and an authentication interface 425. Can be.
  • PW password controller
  • SBA simple bio auth controller
  • the PW controller 421 may register with an issuer such as a credit card company, a bank, or a micro payment agency, and receive a password to be used for authentication from a user and deliver it to the issuer server 450.
  • password registration by the PW controller 421 is performed at the time of initial use registration, and password authentication by the PW controller 421 performs biometric authentication at the time of payment or failure of biometric authentication performed when the payment information is deleted. Instead, it may be used when performing user authentication or resetting biometric authentication information.
  • the password may include a personal identification number (PIN), a number, a pattern, a combination of alphabet / number, and a combination of alphabet / number / symbol.
  • the SBA controller 423 performs an integrated control function related to biometric authentication, stores biometric verification original values received from the issuer server 450, and biometrics with the biometric module 431 and the authentication module 433
  • the authentication flow may be controlled to generate parameters for final biometric authentication verification, and the generated parameters may be delivered to the issuer server 450.
  • the SBA controller 423 may request and receive a randomly generated object reference value for data verification and security between the authentication module 433 and the biometric module 431 to the authentication module 433.
  • the SBA controller 423 transmits the object reference value to the biometric module 431 and encrypts the secure object (encrypted so that the object reference value can be decoded only by the authentication module 433 according to the biometric authentication result from the biometric module 431) secure object).
  • the SBA controller 423 refers to the 'original data' (which may be referred to as a final challenge) including the secure object, the original value of biometric verification, and the app signature hash value for verifying forgery of the app as an authentication module 433. It can transmit and receive three authentication parameters from the authentication module 433.
  • the three authentication parameters are the 'signed original data' (also referred to as a final challenge signed) in which the original data is signed with a biometric signature private key (e.g., cbioPRV), and the original data is issued by the issuer server 450.
  • a biometric signature private key e.g., cbioPRV
  • the SBA controller 423 may transmit the generated three parameters to the issuer server 450 to request user authentication using biometric authentication.
  • the biometric interface 425 may transmit or receive a message according to an interface defined for transmitting a message or signal between the biometric module 431 and the payment app 420 in the TEE 320.
  • the authentication interface 425 may transmit or receive a message according to an interface defined for transmission of a message or signal between the authentication module 433 and the payment app 420 in the TEE 320.
  • the biometric interface 425 and the authentication interface 427 may be APIs allowed to access the TEE 320.
  • the biometric module 431 is a module that operates in the TEE 320 and encrypts and generates a result of biometric authentication in the electronic device 101 and transmits it to the payment app 420.
  • the biometric module 431 may perform biometric authentication based on unique information that can be obtained from the user's biometric information, and may perform biometric authentication based on fingerprints, irises, and the like.
  • the biometric module 431 may acquire biometric information from a user at the time of initial registration or when biometric information needs to be stored, and store the biometric information in a memory in the TEE 320.
  • the biometric module 431 may compare the stored biometric information with the biometric information input by the user and determine that biometric authentication has been performed. If not, biometric authentication may be performed. It can be judged that it was not. The determination as to whether the biometric information is already stored may be based on the information indicating the biometric authentication information storage state.
  • the biometric module 431 may generate a secure object that encrypts the object reference value received from the SBA controller 423 based on the biometric authentication result. According to various embodiments, the biometric module 431 may generate a secure object that encrypts the object reference value only when it is determined that biometric authentication has been performed.
  • the biometric module 431 may transmit the generated security object to the SBA controller 423.
  • the authentication module 433 is a module that operates in the TEE 320, and checks the result value of the biometric authentication generated by the biometric module 431 and sends the final result of biometric authentication to the publisher server 450. It is a module for signing values.
  • the authentication module 433 may generate and transmit an object reference value at the request of the SBA controller 423, and decrypt the secure object generated by the biometric module 431 received through the SBA controller 423 to become biometric authentication. Can judge.
  • the authentication module 433 may generate a private key (eg, cbioPRV) and a public key (eg, cbioPUK) pair for biometric authentication if there is no previously generated key pair, and the key pair is SBA controller 423 Three parameters for biometric authentication verification can be generated by applying to the original data received from.
  • a private key eg, cbioPRV
  • a public key eg, cbioPUK
  • the server 410 may include a payment server 440 and at least one issuer server 450.
  • the payment server 440 performs a function of transmitting data between the payment app 420 and the at least one issuer server 450 by acting as a gateway in relation to the biometric flow
  • the at least one issuer server ( 450) may store a public key issued by the user and perform a function provided to the payment app 420.
  • the at least one issuer server 450 generates, stores, and controls the biometric verification original value (nonce) for each user, and stores and manages the public key for verifying the signature generated by the payment app 420 for each user.
  • the user may authenticate the user by verifying the final biometric authentication result received from 420).
  • the issuer server 450 may randomly generate original biometric verification values.
  • Each of the at least one issuer server 450 is a communication module for communicating with other electronic devices (eg, the electronic device 101, the payment server 450), and a memory and payment for storing biometric authentication information required for verification. It may include a simple bio auth server (SBA server) 451 that operates in response to the app 420.
  • SBA server simple bio auth server
  • the electronic device includes a communication module configured to provide communication with a server, a processor operatively connected to the communication module, and a memory operatively connected to the processor and configured to store biometric information
  • the memory when executed, is configured for biometric authentication verification and password authentication verification for the processor to register biometric authentication information for biometric authentication verification and password for password authentication to the server upon initial use registration.
  • the encrypted password is generated and transmitted to the server, and at the time of payment, at least one of the biometric authentication or the password authentication is used for user authentication, and if a change to the biometric authentication information registered in the server is required, payment is made. Registering new biometric authentication information to the server during execution You can save the instructions that you want.
  • the memory stores information indicating a biometric authentication information storage state, and the instructions request that the processor requests a biometric verification original value from the server at the time of payment, and in response to the request. , Receiving, from the server, information indicating the original biometric verification value and biometric authentication information registration status, and biometric authentication and / or based on information indicating the received biometric authentication information registration status and the biometric authentication information storage status Alternatively, user authentication may be performed using password authentication.
  • the instructions are used when the processor indicates that the information indicating the biometric authentication information registration state received from the server at the time of payment is the registered state and the information indicating the biometric authentication information storage state is the stored state.
  • User authentication is performed using authentication, and when the information indicating the biometric authentication information registration state received from the server is unregistered and the information indicating the biometric authentication information storage state is unstored, user authentication is performed using biometric authentication. If the information indicating the biometric authentication information registration state received from the server is unregistered and the information indicating the biometric authentication information storage state is stored, user authentication is performed using password authentication.
  • Biometric authentication information storage phase Converts the information indicating the unstored state, and when the information indicating the biometric authentication information registration state received from the server is registered and the information indicating the biometric authentication information storage state is unstored, authenticates the user using password authentication After performing the user authentication, it is possible to request the server to convert information indicating the biometric authentication information registration status into an unregistered status.
  • the instructions, the processor transmits a parameter for verification of biometric authentication to the server at the time of payment, receives a biometric verification result from the server, and the received verification result fails verification If it is, the encrypted password for password authentication verification is transmitted to the server, the password verification result is received from the server, and when the verification result is successful, the information indicating the biometric authentication information storage state is converted into an unstored state. And, it is possible to request the server to convert the information indicating the biometric authentication information registration status to an unregistered status.
  • the instructions, the processor generates an object reference value at the time of payment, generates a secure object that encrypts the object reference value based on a biometric authentication result, and generates the biometric verification original. It is possible to generate original data including a hash value indicating a value, the secure object, and an app used for payment, and generate a parameter for the biometric verification based on the original data.
  • the instructions generate and store a biometric authentication private key / public key pair during biometric authentication when the processor indicates that the information indicating the biometric authentication information storage state at the time of payment is not stored.
  • the parameters for verifying the biometric authentication include 'signed original data', which signed the original data with the biometric authentication private key, 'encrypted original data', which encrypted the original data with a public key provided by the server, and the It may include a biometric authentication public key.
  • the server includes a communication module configured to provide communication with the electronic device, a processor operatively connected to the communication module, and a memory operatively connected to the processor and configured to store biometric authentication information.
  • the memory upon execution, the processor receives parameters for biometric authentication verification and an encrypted password from an electronic device upon initial use registration, decrypts the encrypted password for password authentication verification, and recalls the password.
  • the biometric authentication is verified based on the parameters for the biometric authentication, and the obtained biometric authentication information is stored in the memory, and the parameters for the biometric authentication verification received at the time of payment using the biometric authentication and the stored Biometric authentication is verified based on the biometric authentication information.
  • Password verification is performed by comparing the password obtained from the encrypted password received at the time of payment using word authentication and the password stored in the memory, and if new registration of the biometric authentication information is required, payment using biometric authentication is performed. Instructions to store the new biometric authentication information registered in the memory can be stored in the memory.
  • the memory stores information indicating a biometric authentication information registration status
  • the instructions receive, by the processor, a request for an original biometric verification value from the electronic device at the time of payment, and the request.
  • the electronic device may transmit an original value of biometric verification and information indicating the registration status of the biometric authentication information.
  • the instructions receives a parameter for verification of biometric authentication from the electronic device at the time of payment, and biometric authentication based on the parameter for verification of the biometric authentication and the stored biometric authentication information And transmits the biometric verification result to the electronic device, receives the encrypted password from the electronic device when the biometric verification result is verification failure, and a password obtained from the received encrypted password and The password stored in the memory is compared to verify password authentication, the password verification result is transmitted to the electronic device, and if the password verification result is successful, the biometric authentication information registration status is not registered from the electronic device. State. Receiving a request, and may transfer information representative of the biometric information registration state to the unregistered state.
  • the instructions, the processor receives a parameter for verification of biometric authentication from the electronic device at the time of payment, verifies biometric authentication based on the parameter for verification of the biometric authentication, and the verification If the result is successful, the biometric authentication information obtained from the parameters for the biometric authentication verification may be stored and registered in the memory, and the verification result may be transmitted to the electronic device.
  • the parameter for verifying the biometric authentication is' signed original data ', which signed the original data with the biometric authentication private key generated by the electronic device, and encrypted the original data with a public key generated by the server.' Encrypted original data 'and a biometric authentication public key generated by the electronic device.
  • the instructions, the processor checks the validity of the parameter for the biometric authentication verification, decrypts the encrypted original data with the private key of the server to obtain the original data, and the decrypted Using a hash value indicating an app used for payment included in the original data, check whether the app used for payment is justified, and whether the original biometric verification value and the original biometric verification value included in the decrypted original data are the same. It is determined, and after issuing the original biometric verification value, it is determined whether a certain time has elapsed, and the stored biometric authentication information and the biometric authentication public key included in the parameter for the biometric verification are checked, and the signed By verifying the signature of the original data, the biometric verification can be performed .
  • FIG. 5 is a flowchart 500 illustrating a procedure for registering user authentication information according to various embodiments.
  • the issuer server 450 generates its own public key / private key and then delivers the public key (eg, sPUK) to the payment server 440.
  • the public key may be delivered offline, and when there are multiple publisher servers 450, the payment server 440 may receive a public key corresponding to each publisher server 450.
  • the payment app 420 provides payment-related information and user information including a card to be used or a phone number for micro-payment, and checks whether the user is a legitimate user.
  • the payment app 420 requests the public key of the issuer server 450 to the payment server 440.
  • the payment server 440 corresponds to information to be registered among the stored public keys.
  • the public key of the issuer server 450 may be delivered to the payment app 420.
  • biometric authentication information and password may be registered in the issuer server 450 by performing a biometric authentication process 550 and a password authentication process 560 after confirming the user in operation 502. have.
  • the payment app 420 requests the original biometric verification value from the issuer server 450, and in operation 506, the payment server 440 sends the request to the issuer server 450.
  • the issuer server 450 randomly generates the original biometric verification value, and the payment server 440 registers the generated biometric verification original value and the registration status parameter indicating the biometric authentication information registration status for biometric verification verification.
  • the payment server 440 may deliver the received biometric verification original value and the registration status parameter to the payment app 420.
  • the biometric authentication information may be a biometric authentication public key (eg, cbioPUK) received by the issuer server 450 from the payment app 420.
  • the registration status parameter may have a value corresponding to 'true' or a value corresponding to 'false', and in the case of 'true', it indicates that the biometric authentication information is registered, and in the case of 'false' Indicates that the biometric authentication information is not registered.
  • the registration status parameter may have a value of 'false'.
  • the payment app 420 requests the object reference value from the authentication module 433, and in operation 510, the authentication module 433 generates the object reference value by the payment app 420, Can deliver.
  • the payment app 420 transfers the object reference value received from the authentication module 433 to the biometric module 431, and in operation 512, the biometric module 431 pays for a response indicating that the object reference value has been received. It can be delivered to the app 420.
  • the payment app 420 requests a secure object from the biometric module 431, and in operation 514, the biometric module 431 obtains and stores biometric information from the user, and then payment application 420 In this way, an encrypted security object can be delivered so that only the authentication module 433 can decrypt the object reference value.
  • the payment app 420 may transmit information for generating a biometric authentication parameter to the authentication module 433.
  • the transmitted information includes the security object received from the authentication module 433, the original data including the biometric verification original value received from the issuer server 450, and the app signature hash value for verifying forgery of the app, and the publisher server 450. It may contain a public key.
  • the app signature hash value may be an app ID (identification) that enables the app to be recognized.
  • the authentication module 433 may generate a biometric private key / public key pair when there is no previously generated biometric private key / public key pair.
  • a biometric private key eg cbioPRV
  • a public key eg cbioPUK
  • the authentication module 433 may verify whether biometric registration or authentication has been performed by verifying whether the object reference value extracted by decrypting the secure object is the same as the object reference value delivered to the payment app 420 in operation 510.
  • the authentication module 433 is the first parameter that signed the original data with the biometric authentication private key, 'signed original data', and the public key provided by the issuer server 450 (eg : sPUK) encrypted second data, 'encrypted original data', and in operation 516, the first parameter, the second parameter, and the biometric authentication public key to be used by the issuer server 450 for biometric authentication (eg : cbioPUK) may be transmitted to the payment app 420 as parameters for verification of biometric authentication.
  • the payment app 420 is a secure keypad for allowing a user to input a password on a display device (eg, the display device 160 of FIG. 1).
  • the location is changed each time a number is input to the payment server 440, and a numeric filter key capable of providing security for data to be transmitted is requested.
  • the payment server 440 is requested.
  • a security keypad may be displayed by receiving the numeric filter key.
  • the payment app 420 receives a password from the user, and requests encryption by passing the issuer server public key (eg, sPUK) and the received password to the authentication module 433.
  • the payment app 420 may receive an encrypted text from the authentication module 433.
  • the payment app 420 may transmit the encrypted text received from the authentication module 433 to the payment server 440.
  • the payment server 440 passes the ciphertext to the issuer server 450, and in operation 525, a response indicating that the password is registered is received from the issuer server 450, and in operation 526, the registration response is a payment app.
  • Password registration may be completed by passing to 420.
  • the payment app 420 pays for a payment method additional request including the biometric authentication parameters obtained in the biometric authentication procedures of operations 505 to 516. It can be delivered to the server 440.
  • the payment server 440 may deliver the received request to the issuer server 450.
  • the issuer server 450 verifies the signature using the received biometric authentication parameter, and stores a biometric public key (eg, cbioPUK), which is one of the received biometric authentication parameters. If a response error of the issuer server 450 occurs during the process of verifying the signature by biometric authentication, the registration process may be performed again from the beginning.
  • a biometric public key eg, cbioPUK
  • the issuer server 450 transmits a user ID (eg, user account, device ID, and registration number for each user for payment) to the payment server 440 to recognize the registered user. ) Stores the user ID and transmits a response indicating that registration is completed in operation 531 to the payment app 420, thereby completing registration of new payment information and user authentication information.
  • a user ID eg, user account, device ID, and registration number for each user for payment
  • FIG. 6 is a flow chart 600 illustrating a procedure for performing online payment according to various embodiments.
  • online payment may request payment using the biometric authentication process 650 or the password authentication process 660, or If the verification for authentication fails after an attempt to pay through the biometric authentication process 650, payment may be requested by the password authentication process 660.
  • the publisher payment app 660 popped up in the online store requests the payment code from the issuer server 450, and in operation 602, receives the payment code from the issuer server 450. Can be.
  • the issuer payment app 660 may request payment while delivering payment information including payment code, product information, product price, and the like to the payment app 420.
  • the payment app 420 verifies whether payment information is registered through the payment app 420 by communicating with the issuer server 450. If it is not registered, you can proceed with the registration through a separate procedure.
  • the payment method by biometric authentication is registered according to the procedure shown in FIG. 5 when registered, the user authentication is first performed using biometric authentication, and then payment can be performed using password authentication according to the following conditions. have. However, when the user selects password authentication, payment using password authentication may be performed without biometric authentication.
  • the payment app 420 requests the original biometric verification value from the issuer server 450, and in operation 606, the payment server 440 sends the request to the issuer server 450.
  • the issuer server 450 generates the original biometric verification value, and pays a parameter (hereinafter, the registration status parameter) indicating the registration status of the generated biometric verification original value and biometric authentication information for biometric verification verification. It is delivered to the server 440, and in operation 608, the payment server 440 delivers the received biometric verification original value and registration status parameter to the payment app 420.
  • the payment app 420 may have a different procedure for performing the registration status parameter value and the biometric authentication information stored in the electronic device 101 on which the payment app 420 is executed.
  • the biometric authentication information is stored in the electronic device 101 and the registration status parameter value indicates 'false', or the biometric authentication information is not stored in the electronic device 101 and the registration status parameter value is true.
  • the registration status of the biometric authentication information is different between the electronic device 101 and the issuer server 450, payment is performed through user authentication using password authentication, and the value of the registration status parameter is' false' after payment is completed.
  • the electronic device 101 may perform payment according to the procedure described below in FIG. 6.
  • the electronic device 101 registers the biometric authentication information during the procedure while performing payment according to the procedure described below with reference to FIG. 6. You can do it. According to this, there is an advantage in that user convenience can be promoted by simultaneously performing payment and registering biometric authentication information.
  • the payment app 420 determines that the biometric authentication information storage state and the biometric authentication information registration state of the electronic device 101 and the issuer server 450 match, in operation 609, the payment app 420 Requests the object reference value to the authentication module 433, and in operation 610, the authentication module 433 may generate and transmit the object reference value to the payment app 420.
  • the payment app 420 transmits the object reference value received from the authentication module 433 to the biometric module 431, and in operation 612, the biometric module 431 pays for a response indicating that the object reference value has been received. It can be delivered to the app 420.
  • the payment app 420 requests a secure object from the biometric module 431, and in operation 614, the biometric module 431 acquires and stores biometric information when the biometric authentication information is not stored.
  • the biometric authentication is performed by comparing the stored biometric information with the biometric information obtained from the user, and according to the result, the object reference value is authenticated by the payment app 420 to the authentication module 433 Encrypted security objects can be delivered for decryption only.
  • the payment app 420 may transmit information for generating a biometric authentication parameter to the authentication module 433.
  • the transmitted information includes the security object received from the authentication module 433, the original data including the biometric verification original value received from the issuer server 450, and the app signature hash value for verifying forgery of the app, and the publisher server 450. It may contain a public key.
  • the authentication module 433 generates a biometric authentication private key / public key pair when the biometric authentication information is not stored, that is, if there is no previously generated biometric authentication private key / public key pair. Can be. When the biometric authentication information is stored, a new biometric authentication private key / public key pair is not generated, and the previously stored private key / public key can be used as it is.
  • the authentication module 433 may verify whether biometric authentication has been performed by verifying whether the object reference value extracted by decrypting the secure object is the same as the object reference value delivered to the payment app 420 in operation 610.
  • the authentication module 433 is the first parameter that signed the original data with the biometric authentication private key, 'signed original data', and the public key provided by the issuer server 450 (eg : sPUK) to generate the encrypted second parameter 'encrypted original data' and in operation 616, the first parameter, the second parameter, and the biometric authentication public key to be used for biometric authentication by the issuer server 450 (eg : cbioPUK) may be transmitted to the payment app 420 as parameters for verification of biometric authentication.
  • the issuer server 450 eg : sPUK
  • the payment app 420 may request payment while passing the biometric authentication parameters obtained in the biometric authentication procedures of operations 605 to 616 to the payment server 440.
  • the payment server 440 may deliver the received request to the issuer server 450.
  • the issuer server 450 verifies the signature using the received biometric authentication parameter. If the issuer server 450 fails to verify the signature by biometric authentication, it may perform payment and initialization of biometric authentication information by performing a recovery procedure using password authentication as shown in FIG. 8 described below.
  • a final payment may be performed by passing a response indicating success to the payment app 420 through the payment server 440.
  • the biometric authentication information may be additionally stored, and the registration status parameter value may be changed to 'true' to make the biometric authentication information registration status.
  • the biometric authentication information may be a biometric public key (eg, cbioPUK) delivered by the payment app 420.
  • the issuer server 450 responds that the signature verification by biometric authentication has failed, or the biometric authentication information registration status of the issuer server 450 and the payment app 420 is If different, or if the user selects to proceed with payment using password authentication, payment through password authentication may be performed.
  • the payment app 420 displays a keypad on a display device (eg, the display device 160 of FIG. 1), and in operation 618, a number filter to the payment server 440 The key is requested, and in operation 619, the numeric filter key is received from the payment server 440.
  • the payment app 420 may receive a password from the user, and in operation 621, the authentication module 433 may transmit the issuer server public key (eg, sPUK) and the input password to request encryption. In operation 622, the payment app 420 may receive an encrypted text from the authentication module 433.
  • the issuer server public key eg, sPUK
  • the payment app 420 may request payment while delivering the received cryptogram to the payment server 440.
  • the payment server 440 may deliver the received request to the issuer server 450.
  • the issuer server 450 may authenticate the user using the received encrypted text. If the issuer server 450 fails the authentication based on the ciphertext, payment does not proceed, and the password authentication procedure may be performed again. When the issuer server 450 successfully authenticates based on the ciphertext, payment proceeds, and the biometric that changes the biometric authentication information storage / registration state of the electronic device 101 and the issuer server 450 to an unsaved / unregistered state after payment is completed. Initialization of authentication information can be performed.
  • FIG. 7 is a flowchart 700 illustrating a procedure for deleting payment related information and user authentication information according to various embodiments.
  • the procedure for deleting payment information and user authentication information is performed by user authentication using the biometric authentication process 750 or the password authentication process 760 or after user authentication through the biometric authentication process 750.
  • user authentication may be performed by the password authentication process 760.
  • the payment app 420 may receive a request to delete payment information from a user.
  • all related information including payment information and user authentication information may be deleted.
  • the payment app 420 requests the original verification value from the publisher server 450, and in operation 703, the payment server 440 sends the request to the publisher server 450.
  • the issuer server 450 generates the biometric verification original value
  • the payment server 440 displays the generated biometric verification original value and the registration status parameter indicating whether a biometric authentication public key exists for user authentication.
  • the payment server 440 may transfer the received biometric verification original value and registration status parameter to the payment app 420.
  • the payment app 420 is in a state in which biometric authentication information is stored in the electronic device 101 in which the payment status 420 and the registration status parameter value are executed Depending on the procedure to be performed may be different.
  • the biometric authentication information is stored in the electronic device 101 and the registration status parameter value indicates 'false', or the biometric authentication information is not stored in the electronic device 101 and the registration status parameter value is true. If the registration status of the biometric authentication information is different between the electronic device 101 and the issuer server 450, payment information may be deleted through user authentication using password authentication.
  • the electronic device 101 may proceed to delete payment information according to the procedure described below with reference to FIG. According to an embodiment, even when the biometric authentication information is not stored and the registration status parameter value is 'false', the electronic device 101 may proceed to delete payment information according to the procedure described below with reference to FIG. 7.
  • the payment app 420 determines that the biometric authentication information registration status of the electronic device 101 and the issuer server 450 match (regardless of whether they are registered or unregistered), in operation 706, payment is made.
  • the app 420 requests the object reference value from the authentication module 433, and in operation 707, the authentication module 433 may generate and transmit the object reference value to the payment app 420.
  • the payment app 420 transmits the object reference value received from the authentication module 433 to the biometric module 431, and in operation 709, the biometric module 431 pays for a response indicating that the object reference value has been received. It can be delivered to the app 420.
  • the payment app 420 requests a security object from the biometric module 431, and in operation 711, the biometric module 431 acquires and stores biometric information when the biometric authentication information is not stored.
  • the biometric authentication is performed by comparing the stored biometric information with the biometric information obtained from the user, and according to the result, the object reference value is authenticated by the payment app 420 to the authentication module 433 ) Can only pass the encrypted security object so that it can be decrypted.
  • the payment app 420 may transmit information for generating a biometric authentication parameter to the authentication module 433.
  • the transmitted information includes the security object received from the authentication module 433, the original data including the biometric verification original value received from the issuer server 450, and the app signature hash value for verifying forgery of the app, and the publisher server 450. It may contain a public key.
  • the app signature hash value may be an app ID (identification) that enables the app to be recognized.
  • the authentication module 433 generates a biometric authentication private key / public key pair when the biometric authentication information is not stored, that is, if there is no previously generated biometric authentication private key / public key pair. Can be. When the biometric authentication information is registered, a new biometric authentication private key / public key pair is not generated, and the previously stored private key / public key can be used as it is.
  • the authentication module 433 may verify whether biometric authentication has been performed by verifying whether the object reference value extracted by decrypting the secure object is the same as the object reference value delivered to the payment app 420 in operation 707.
  • the authentication module 433 is the first parameter that signed the original data with the biometric authentication private key, 'signed original data', and the public key provided by the issuer server 450 (eg : sPUK) encrypted second parameter, 'encrypted original data', and in operation 713, the first parameter, the second parameter, and the biometric authentication public key to be used for biometric authentication verification by the issuer server 450 (eg : cbioPUK) may be transmitted to the payment app 420 as parameters for verification of biometric authentication.
  • the issuer server 450 eg : sPUK
  • the payment app 420 may request deletion of payment information while transferring the biometric authentication parameters obtained in the biometric authentication procedures of operations 702 to 713 to the payment server 440.
  • the payment server 440 may transmit the received request to the issuer server 450.
  • the issuer server 450 verifies the signature using the received biometric authentication parameter. If the issuer server 450 fails to verify the signature by biometric authentication, it may perform payment and initialization of biometric authentication information by performing a recovery procedure using password authentication as shown in FIG. 8 described below.
  • biometric authentication information When the issuer server 450 successfully authenticates the signature by biometric authentication, if the registration status parameter value indicates 'false' and the biometric authentication information is not registered, the biometric authentication information is stored, and the registration status parameter value is changed to 'true'. It can be made into the biometric authentication information registration state. In operation 723, biometric authentication information may be deleted.
  • the biometric authentication information may include a biometric authentication public key (eg, cbioPUK), and the registration status parameter value may be set to 'false'.
  • the issuer server 450 transmits a response indicating that authentication is successful to the payment server 440 in operation 724, and in operation 725, the payment server 450 receives the authentication success response You can delete payment information.
  • the payment server 450 transmits an authentication success response to the payment app 420, and in operation 727, the payment app 420 requests the payment module 433 to delete payment information in response to the authentication success. ).
  • the payment module 433 may delete payment related information including the biometric authentication private key (eg, cbioPRV) and public key (eg, cbioPUK), and in operation 729, the payment module 433 may be successfully deleted.
  • the response can be delivered to the payment app 420.
  • the payment app 420 may delete payment related information and delete a public key (eg, sPUK) of the relevant issuer server 450.
  • the issuer server 450 responds that the signature verification by biometric authentication has failed, or the biometric authentication information registration status of the issuer server 450 and the payment app 420 is If it is different or the user selects to proceed with the deletion of payment information using password authentication, payment information deletion through password authentication may be performed.
  • the payment app 420 displays a keypad on a display device (eg, the display device 160 of FIG. 1), and in operation 715, to the payment server 440 The numeric filter key is requested, and in operation 716, the numeric filter key is received from the payment server 440.
  • the payment app 420 receives the password from the user, and in operation 718, the authentication server 433 requests the encryption while passing the issuer server public key (eg, sPUK) and the received password. In operation 719, the payment app 420 may receive an encrypted text from the authentication module 433.
  • the issuer server public key eg, sPUK
  • the payment app 420 may request the deletion of payment information while transmitting the received encrypted text to the payment server 440.
  • the payment server 440 may transmit the received request to the issuer server 450.
  • the issuer server 450 may authenticate the user using the received encrypted text. If the issuer server 450 fails the authentication based on the ciphertext, payment does not proceed, and the password authentication procedure may be performed again. When the issuer server 450 successfully authenticates based on the ciphertext, deletion of payment related information may be performed according to operations 723 to 730.
  • biometric authentication information when the registration status of the biometric authentication information is different between the payment app 420 and the issuer server 450, or when verification by biometric authentication fails during payment using biometric authentication, password authentication is used.
  • Payment is performed through user authentication, and after payment is completed, the registration status parameter value is set to 'false', and biometric authentication of the payment app 420 is set to an unstored state through password authentication that matches both states. Recovery procedures can be performed.
  • FIG. 8 is a flowchart 800 illustrating a recovery procedure through password authentication according to verification failure by biometric authentication according to various embodiments.
  • the payment app 420 may receive a payment request from the internet store payment app 860.
  • the payment app 420 requests the original biometric verification value from the issuer server 450, and in operation 803, the payment server 440 sends the request to the issuer server 450.
  • the issuer server 450 generates the biometric verification original value
  • the payment server 440 displays the generated biometric verification original value and the registration status parameter indicating whether a biometric authentication public key exists for user authentication.
  • the payment server 440 may deliver the received biometric verification original value and registration status parameter to the payment app 420.
  • the payment app 420 may perform biometric authentication.
  • the payment app 420 may generate biometric authentication parameters by performing biometric authentication according to the procedure according to operations 509 to 516 of FIG. 5 or operations 609 to 616 of FIG. 6 or operations 706 to 713 of FIG. 7. have.
  • the payment app 420 may request payment while passing the biometric authentication parameter generated in the biometric authentication procedure to the payment server 440.
  • the payment server 440 may deliver the received request to the issuer server 450.
  • the issuer server 450 may verify the signature using the received biometric authentication parameter, and the signature verification may fail. If the signature verification fails, a recovery procedure using password authentication may be performed to initialize payment and biometric authentication information.
  • the issuer server 450 when the issuer server 450 fails to verify the signature by biometric authentication, in operation 810 and operation 811, the issuer server 450 receives a response indicating that the signature verification has failed.
  • the payment server 440 may be delivered to the payment app 420.
  • the payment app 420 that receives a response indicating that the verification of the signature by biometric authentication has failed may proceed with payment through password authentication.
  • the payment app 420 may perform password authentication.
  • the password authentication may be performed according to operation 517 to operation 522 of FIG. 5, operation 617 to operation 622 of FIG. 6, or operation 714 to operation 719 of FIG. 7, and an encrypted text encrypted with a password may be generated.
  • the payment app 420 may request payment while passing the cryptogram to the payment server 440.
  • the payment server 440 may deliver the received request to the issuer server 450.
  • the issuer server 450 authenticates the user using the received ciphertext, and if the password authentication is successful, the payment may be successfully completed.
  • the issuer server 450 may transmit a response indicating successful payment to the payment server 440, and the payment server 440 may transmit a successful response to the payment to the payment app 420.
  • the payment app 420 changes its biometric authentication information storage state to an unstored state, and in operation 818, the biometric authentication information registration state of the issuer server 450 is set to the payment server 440.
  • the change request can be delivered in an unregistered state.
  • the request to change the biometric authentication information registration state to the unregistered state may be a request to delete the biometric authentication public key of the payment app 420 registered in the issuer server 450.
  • the payment server 440 may transmit the change request to the issuer server 450.
  • the issuer server 450 receiving the change request deletes the biometric authentication public key corresponding to the payment app 420, and corresponds to a 'false' registration status parameter indicating whether the biometric authentication public key is registered. Can be changed to the desired value.
  • the issuer server 450 transmits a response indicating that the change is completed to the payment server 440, and in operation 822, the payment server 440 can deliver the change completion response to the payment app 420.
  • the payment app 420 receiving the change completion response may transmit a response indicating that payment is completed to the payment app 860 of the Internet store in operation 823.
  • FIG. 9 is a flowchart 900 illustrating an operation of registering payment information and user authentication information of the electronic device 101 according to various embodiments.
  • the operating subject is an electronic device (eg, the electronic device 101 of FIG. 1) or a component of the electronic device 101 (eg, the processor 120 of FIG. 1, 4) It can be understood as the payment app 420, the biometric module 431 and / or the authentication module 433).
  • the electronic device 101 may identify a legitimate user for payment information such as a small payment for a card or a phone number to be used.
  • the electronic device 101 transmits payment-related information such as card information and micro-payment information to the issuer server 450 through the payment server 440 and user information, and confirms by receiving an approval response from the issuer server 450. have.
  • the electronic device 101 may obtain a public key (eg, sPUK) of the issuer server 450.
  • the public key of the issuer server 450 may be transferred from the issuer server 450 to the payment server 440.
  • the issuer server 450 may deliver the payment to the payment server 440 offline.
  • the electronic device 101 requests the public key of the issuer server 450 to the payment server 440 when registering payment information and user authentication information, and stores and receives the public key of the issuer server 450 received and delivered (for example: Memory 130 of FIG. 1).
  • the public key of the issuer server 450 can be used to encrypt the message delivered to the issuer server 450.
  • the electronic device 101 may perform biometric authentication.
  • the electronic device 101 may store parameters indicating the storage state of the biometric authentication information, and the electronic device 101 may also register a registration state parameter indicating the registration state of the biometric authentication information related to itself from the issuer server 450.
  • Upon receiving it is possible to determine whether biometric authentication information related to the user is registered in the issuer server.
  • the storage status of the biometric authentication information of the electronic device 101 and the registration status of the biometric authentication information of the issuer server 450 are unstored / unregistered (corresponding to the parameter having a value corresponding to 'false'). Can be.
  • the electronic device 101 may generate a parameter for verifying biometric authentication to be delivered to the issuer server 450 through a biometric authentication process.
  • the parameters for verifying biometric authentication are the first parameter that signed the original data with the biometric authentication private key (eg, cbioPRV), 'signed original data', and the public key provided by the issuer server 450 (eg, sPUK) ), And the second parameter, 'encrypted original data', and the third parameter, a biometric authentication public key (eg, cbioPUK).
  • the original data may include a biometric verification original value received from the issuer server 450, a secure object encrypting the object reference value generated by the biometric module 431, and an app signature hash value for verifying forgery of the app.
  • the electronic device 101 may be configured according to the operation 505 to 516 of FIG. 5, the operation 605 to 616 of FIG. 6, or the operation 703 to 713 of FIG. 7, or the operation of FIG. 10 to be described later.
  • Biometric authentication may be performed according to a procedure.
  • the electronic device 101 may perform password authentication.
  • the electronic device 101 may register a password to be used for user authentication at the time of payment with the issuer server 450.
  • the electronic device 101 may receive a password to be registered from a user through password authentication, and may encrypt the received password using a public key (eg, sPUK) of the issuer server 450.
  • a public key eg, sPUK
  • the electronic device 101 is performed according to the operations 517 to 522 of FIG. 5, or the operations 617 to 622 of FIG. 6, or the operations 714 to 719 of FIG. 7, or the operation of FIG. 11. It is possible to create a ciphertext with the password encrypted.
  • the electronic device 101 may register a password by transmitting the cipher text generated through password authentication to the issuer server 450.
  • the electronic device 101 may transmit the biometric authentication parameter generated in operation 905 to the issuer server 450 to store the biometric authentication information in the issuer server 450.
  • the biometric authentication information may be a biometric authentication shared key (eg, cbioPUK) of the electronic device 101.
  • the issuer server 450 may receive parameters for verifying biometric authentication, perform authentication using the received parameters, and store biometric authentication information of the received electronic device 101 when authentication is successful.
  • the electronic device 101 may register biometric authentication information by performing operations 905 to 911 again if a response to successful registration of the biometric authentication information from the issuer server 450 is not received within a predetermined time. . If the electronic device 101 receives the successful response of the registration of the biometric authentication information from the issuer server 450 within a predetermined time, the electronic device 101 may determine that the payment information registration and the user authentication information are normally registered and end the registration operation.
  • FIG. 10 is a flowchart 1000 illustrating a biometric authentication operation of the electronic device 101 according to various embodiments.
  • the flowchart 1000 illustrated in FIG. 10 is an embodiment of operation 905 of FIG. 9, and the subject of operation is an electronic device (for example, the electronic device 101 of FIG. 1) or a component of the electronic device 101 (for example: It can be understood as the processor 120 of FIG. 1, the payment app 420 of FIG. 4, the biometric module 431, and / or the authentication module 433).
  • the electronic device 101 requests the original biometric verification value from the issuer server 450 to obtain the original biometric verification value and biometric authentication information from the issuer server 450 (biometric authentication public key). Registration status can be obtained. The original biometric verification value and the information indicating the biometric authentication information registration status may be received from the issuer server 450 to the electronic device 101 through the payment server 440.
  • the authentication module 433 of the electronic device 101 may generate an object reference value and transmit it to the biometric module 431.
  • the object reference value may be generated in the authentication module 433 under the control of the payment app 420 and transmitted to the bio module 431 through the payment app 420.
  • the biometric module 431 of the electronic device 101 performs biometric authentication and may generate a security object based on the result.
  • the biometric module 431 may determine that the biometric information is authenticated when the previously stored biometric information and the biometric information input by the user match, and if not, determine that the biometric information authentication has failed. have.
  • the biometric module 431 may request the user to input biometric information again or switch the authentication method to password authentication.
  • the biometric module 431 When it is determined that the biometric information is authenticated, the biometric module 431 generates an encrypted secure object so that only the authentication module 433 can decrypt the object reference value received through the payment app 420 and transmits it to the payment app 420. Can be.
  • the electronic device 101 may generate a parameter to be delivered to the issuer server 450 for biometric authentication.
  • the payment app 420 of the electronic device 101 is biometrically authenticated to check the security object received from the biometric module 431, the original verification value of the biometric received from the issuer server 450, and app forgery verification.
  • the authentication module 431 For generating the original data including the app signature hash value, the authentication module 431 itself generates a biometric authentication private key (eg cbioPRV) and a biometric public key (eg cbioPUK), and also a biometric authentication private key It is possible to generate 'signed original data', which signed the original data (e.g., cbioPRV), and 'encrypted original data', which encrypted the original data with a public key (eg, sPUK) provided by the issuer server 450. .
  • the biometric authentication private key and public key are not generated every time, but are generated and stored only when the biometric authentication information storage state of the electronic device 101 is not stored, and then the stored biometric authentication private key and public key can be used.
  • Parameters to be passed to the issuer server 450 for biometric authentication may include 'signed original data', 'encrypted original data', and a biometric authentication public key.
  • FIG. 11 is a flowchart 1100 illustrating a password authentication operation of the electronic device 101 according to various embodiments.
  • the flowchart 1100 illustrated in FIG. 11 is an embodiment of operation 907 of FIG. 9, and the operation subject is an electronic device (for example, the electronic device 101 of FIG. 1) or a component of the electronic device 101 (for example: It can be understood as a payment app (420 and / or authentication module 433) of Figure 4).
  • the electronic device 101 may display a keypad on a display device (eg, the display device 160 of FIG. 1) to allow a user to input a password.
  • a display device eg, the display device 160 of FIG. 1
  • the electronic device 101 may obtain a key filter from the issuer server 450.
  • the key filter can be modified by the key filter even if the user enters the same number so that the same signal does not go to the issuer server 450.
  • the electronic device 101 may obtain a password according to a user input.
  • the authentication module 433 of the electronic device 101 may generate a ciphertext that encrypts the password input by the user with the public key of the issuer server.
  • the generated ciphertext may be transmitted to the issuer server 450 according to the operation 909, and the password may be registered.
  • an operation subject is an electronic device (eg, the electronic device 101 of FIG. 1) or a component of the electronic device 101 (eg, the processor 120 of FIG. 1, FIG. 4) It can be understood as the payment app 420, the biometric module 431 and / or the authentication module 433).
  • the payment app 420 of the electronic device 101 may receive a payment request.
  • the electronic device 101 may perform biometric authentication in operation 1203 to generate parameters for verifying the biometric authentication transmitted to the issuer server 450.
  • the electronic device 101 may perform biometric authentication according to the flowchart shown in FIG. 10.
  • the electronic device 101 may transmit a parameter for verifying biometric authentication to the issuer server 450 to request biometric authentication, and in operation 1207, from the issuer server 450 After receiving the verification result, it is possible to determine whether the verification was successful. If verification is successful according to an embodiment, payment may be completed and terminated. If it is determined that the verification has failed according to an embodiment, in operation 1209, the electronic device 101 may switch to password authentication according to the flowchart of FIG. 11 and receive a password from a user to generate a password-encrypted ciphertext.
  • the electronic device 101 may verify the password by passing the ciphertext to the issuer server 450.
  • the issuer server 450 compares the password of the electronic device 101 stored with the password received by the ciphertext, and if it matches, determines that the password has been verified, and if not, determines that the password has not been verified and determines the result. It can be delivered to the electronic device 101. If the password is not verified from the verification result received from the issuer server 450, the electronic device 101 performs password authentication again to receive password verification, and if the password is verified, initializes biometric authentication information in operation 1213. In addition, payment may be approved. However, only biometric authentication information may be initialized without payment approval, and biometric authentication information may be added while attempting a new payment.
  • the electronic device 101 converts the biometric authentication information storage state stored in its own memory (eg, the memory 130 of FIG. 1) into 'false' in order to initialize the biometric authentication information. And, it may send a request message to initialize the biometric authentication information to the issuer server 450.
  • the issuer server 450 may receive this request message and convert the registration status parameter indicating the biometric authentication information registration status to a value corresponding to 'false'.
  • FIG. 13 is a flowchart 1300 illustrating an operation of registering payment information and user authentication information of the issuer server 450 according to various embodiments.
  • the subject of operation of the flowchart 1300 illustrated in FIG. 13 is understood as an issuer server (eg, the issuer server 450 in FIG. 4) or a component of the issuer server 450 (eg, the SBA server 451 in FIG. 4). Can be.
  • the issuer server 450 in operation 1301, the issuer server 450 generates the original biometric verification value generated according to a request from the electronic device 101 for registration of user authentication information, and the corresponding biometric data of the electronic device 101.
  • the authentication information registration status can be transmitted.
  • the biometric authentication information registration status may be represented by a registration status parameter, and the registration status parameter may have a value corresponding to 'true' or a value corresponding to 'false'. It may indicate that the biometric authentication information is in the registered state, and in the case of 'false', the biometric authentication information may be in the unregistered state.
  • the registration status parameter In the case of initial registration, the registration status parameter may have a value corresponding to 'false'.
  • the issuer server 450 receives an encrypted text from the electronic device 101 including a password encrypted with its public key (eg, sPUK), and in operation 1305, Using a private key (eg sPRV), a password can be obtained and stored from the ciphertext.
  • a password encrypted with its public key (eg, sPUK)
  • sPRV private key
  • the issuer server 450 receives a parameter for verifying biometric authentication from the electronic device 101.
  • the parameters for the verification of the biometric authentication are provided by the issuer server 450, the 'signed original data', which is the first parameter for signing the original data with the biometric authentication private key (for example, cbioPRV) of the electronic device 101. It may include a second parameter, 'encrypted original data', which is encrypted with a public key (eg, sPUK), and a third parameter, a biometric authentication public key (eg, cbioPUK).
  • the original data may include a biometric verification original value received from the issuer server 450, a secure object encrypting the object reference value generated by the biometric module 431, and an app signature hash value for verifying forgery of the app.
  • the issuer server 450 verifies biometric authentication using the received parameter.
  • biometric authentication information may be registered in operation 1311.
  • the biometric authentication information may be a corresponding biometric authentication public key (eg, cbioPUK) of the electronic device 101.
  • a registration operation may be completed.
  • FIG. 14 is a flowchart 1400 illustrating an operation at the time of payment of the issuer server 450 according to various embodiments.
  • the subject of operation of the flowchart 1400 illustrated in FIG. 14 is understood as an issuer server (eg, the issuer server 450 in FIG. 4) or a component of the issuer server 450 (eg, the SBA server 451 in FIG. 4). Can be.
  • the issuer server 450 registers the original biometric verification value generated according to the request from the electronic device 101 and corresponding biometric authentication information of the electronic device 101 in order to proceed with payment.
  • Status can be transmitted.
  • the biometric authentication information registration status may be represented by a registration status parameter, and the registration status parameter may have a value corresponding to 'true' or a value corresponding to 'false'. It may indicate that the biometric authentication information is in the registered state, and in the case of 'false', the biometric authentication information may be in the unregistered state.
  • the registration status parameter may have a value corresponding to 'true'.
  • the issuer server 450 may receive a parameter for verifying biometric authentication from the electronic device 101.
  • the parameters for the verification of the biometric authentication are provided by the issuer server 450, the 'signed original data', which is the first parameter for signing the original data with the biometric authentication private key (for example, cbioPRV) of the electronic device 101. It may include a second parameter, 'encrypted original data', which is encrypted with a public key (eg, sPUK), and a third parameter, a biometric authentication public key (eg, cbioPUK).
  • the original data may include a biometric verification original value received from the issuer server 450, a secure object encrypting the object reference value generated by the biometric module 431, and an app signature hash value for verifying forgery of the app.
  • the issuer server 450 verifies biometric authentication using the received parameter.
  • the issuer server 450 decrypts the 'encrypted original data' with its own private key for verifying the biometric authentication, verifies the app hash value and the original biometric verification value, and stores the biometric public key received as the third parameter.
  • the biometric authentication may be verified by verifying whether the electronic device 101 is the same as the corresponding biometric authentication public key and verifying the signature of the 'signed original data' using the biometric public key.
  • the issuer server 450 transfers the result of the biometric verification from the electronic device 101 to the electronic device 101, and when the biometric verification is successful, approves and completes the payment, If the biometric authentication verification fails, it is possible to wait for the reception of the encrypted password from the electronic device 101.
  • the issuer server 450 receives the encrypted password from the electronic device 101 when the biometric authentication fails, and in operation 1411, the issuer server 450 receives the encrypted password.
  • the password can be decrypted by using the private key of, and the password can be verified by comparing it with the password corresponding to the stored electronic device 101.
  • payment may be transferred to the electronic device 101 to complete the payment.
  • a request message for initializing biometric authentication information is received from the electronic device 101, and a registration status parameter indicating the biometric authentication information registration status corresponds to 'false' corresponding to an unregistered status. It is possible to change the value and delete the corresponding biometric authentication public key (eg, cbioPUK) of the electronic device 101 that was stored.
  • a biometric authentication public key eg, cbioPUK
  • the electronic device 101 and the issuer server 450 store the biometric authentication information according to the recovery procedure through password authentication according to operations 1409 to 1413. / You can initialize the registered state to the unsaved / unregistered state.
  • the method presented in the present invention when the biometric authentication fails while the use registration and the password are registered and the biometric authentication information storage / registration state of the electronic device 101 and the issuer server 450 is initialized to the unstored / unregistered state According to, payment can be performed while registering biometric authentication information to the issuer server 450.
  • FIG. 15 is a flowchart 1500 illustrating an operation at the time of payment of the issuer server 450 after the biometric authentication information is initialized by the recovery procedure according to various embodiments.
  • the operation subject of the flowchart 1500 illustrated in FIG. 15 is understood as an issuer server (eg, the issuer server 450 in FIG. 4) or a component of the issuer server 450 (eg, the SBA server 451 in FIG. 4). Can be.
  • the issuer server 450 registers the original biometric verification value generated according to the request from the electronic device 101 and corresponding biometric authentication information of the electronic device 101 in order to proceed with payment. Status can be transmitted.
  • the biometric authentication information registration status may be represented by a registration status parameter, and in this embodiment, the registration status parameter may have a value corresponding to 'false' in which the biometric authentication information registration status is not registered.
  • the biometric authentication information may be a biometric public key transmitted from the electronic device 101 to the issuer server 450.
  • the issuer server 450 may receive parameters for verifying biometric authentication from the electronic device 101.
  • the parameters for the verification of the biometric authentication are provided by the issuer server 450, the 'signed original data', which is the first parameter for signing the original data with the biometric authentication private key (for example, cbioPRV) of the electronic device 101. It may include a second parameter, 'encrypted original data', which is encrypted with a public key (eg, sPUK), and a third parameter, a biometric authentication public key (eg, cbioPUK).
  • the original data may include a biometric verification original value received from the issuer server 450, a secure object encrypting the object reference value generated by the biometric module 431, and an app signature hash value for verifying forgery of the app.
  • the issuer server 450 verifies biometric authentication using the received parameter.
  • the issuer server 450 decrypts the 'encrypted original data' with its own private key for verification of biometric authentication, verifies the app hash value and the original biometric verification value, and uses the biometric authentication public key received as the third parameter.
  • ' Biometric authentication can be verified by verifying the signature of the 'signed original data'.
  • payment may be approved and biometric authentication information may be registered while payment is completed.
  • FIG. 16 is a flow chart 1600 illustrating a biometric authentication verification operation of the issuer server 450 according to various embodiments.
  • the operation subject of the flowchart 1600 illustrated in FIG. 16 is understood as an issuer server (eg, the issuer server 450 in FIG. 4) or a component of the issuer server 450 (eg, the SBA server 451 in FIG. 4). Can be.
  • the issuer server 450 may check the validity of a parameter for verification of biometric authentication received from the electronic device 101.
  • the validity of the parameter can be verified by verifying the type field or length defined in the standard in the parameter for verifying biometric authentication. If the validity is not confirmed, it may be determined that the biometric verification has failed.
  • the issuer server 450 may obtain 'original data' by decoding 'encrypted original data' with its own private key. If the original data acquisition fails, it may be determined that the biometric verification has failed.
  • the issuer server 450 may verify whether the app signature hash value included in the original data corresponds to a legitimate app. If verification fails, it may be determined that verification of the biometric authentication has failed.
  • the issuer server 450 includes the biometric verification original value and the original data transmitted to the electronic device 101 at the request of the electronic device 101 at the start of payment. It is possible to compare the original verification value to determine whether it is consistent, and to verify whether a predetermined time has passed since the original verification of the biological verification was issued. If the original biometric verification value included in the original data and the original biometric verification value issued to the electronic device 101 do not match or a certain time has passed since the original biometric verification value is issued, it may be determined that the biometric verification verification has failed.
  • the issuer server 450 determines whether the biometric public key received from the electronic device 101 is the same as the corresponding biometric public key of the previously registered electronic device 101. can do. If the registration status parameter has a value corresponding to 'false' in which the biometric authentication information is not registered, it may not be determined whether the operation 1609 is the same. If the registration status parameter has a value corresponding to 'True', and the biometric authentication public key received from the electronic device 101 is not the same as the corresponding biometric authentication public key of the previously registered electronic device 101, biometric authentication verification It can be judged as failed.
  • the issuer server 450 may verify the signature of the 'signed original data' with the biometric public key received from the electronic device 101 or a pre-registered biometric public key. have.
  • the signature can be verified by comparing the original data obtained from the 'signed original data' and the original data obtained from the 'encrypted original data' using the biometric authentication public key.
  • the issuer server 450 may determine that the biometric verification has failed, and if the signature verification succeeds, it may determine that the biometric verification has succeeded.
  • 17 is a flowchart 1700 briefly illustrating an operation for user authentication of the electronic device 101 according to various embodiments.
  • the electronic device 101 may determine whether it is the first use registration. The determination may be made according to a user's input or may be determined based on information stored in the electronic device 101.
  • the electronic device 101 in the case of the first registration, the electronic device 101 generates a parameter for verifying biometric authentication in operation 1703, and in operation 1705, encrypts the password input by the user for use as user authentication. Passwords can be generated.
  • the electronic device 101 transmits the encrypted password to the issuer server 450 in operation 1707 to register the user authentication through biometric authentication and password authentication to the issuer server 450, and performs verification for biometric authentication in operation 1709.
  • the parameters can be sent to the issuer server 450.
  • the issuer server 450 may store password and biometric authentication information for user authentication based on the encrypted password and parameters for biometric authentication verification.
  • the electronic device 101 may perform user authentication for payment using biometric authentication or password authentication in operation 1711.
  • biometric authentication or password authentication
  • new biometric authentication information may be registered in the issuer server 450 together while performing payment.
  • FIG. 18 is a flowchart 1800 illustrating an authentication procedure at the time of payment according to a state of storing biometric authentication information of the electronic device 101 and a state of registering a biometric authentication information of the issuer server 450 according to various embodiments.
  • the flowchart 1800 illustrated in FIG. 18 is an embodiment of operation 1711 of FIG. 17, and the operation subject is an electronic device (for example, the electronic device 101 of FIG. 1) or a component of the electronic device 101 (for example: It can be understood as the processor 120 of FIG. 1, the payment app 420 of FIG. 4, the biometric module 431, and / or the authentication module 433).
  • the biometric authentication information storage state of the electronic device 101 and the biometric authentication information registration state of the issuer server 450 may have four states, and user authentication according to this state of the electronic device 101. For this, it is possible to decide whether to use biometric authentication or password authentication.
  • the electronic device 101 101 uses biometric authentication for payment, and in operation 1805, if verification by the issuer server 450 is successful, payment is approved and the biometric authentication information storage state and the biometric authentication information registration state of the issuer server 450 Can be converted into a stored / registered state.
  • the issuer server 450 may register the biometric authentication public key received from the electronic device 101 as biometric authentication information for biometric authentication verification.
  • the electronic device 101 uses password authentication for payment, and in operation 1815, if verification by the issuer server 450 is successful, payment is approved and the biometric authentication information storage state and the biometric authentication information registration state of the issuer server 450 Is initialized to the unsaved / unregistered state, and the new biometric authentication information may be stored in the issuer server 450 when the payment by the above-described operations 1803 to 1807 is performed at the next payment.
  • the electronic device 101 101 uses password authentication for payment, and in operation 1825, if verification by the issuer server 450 is successful, payment is approved and the biometric authentication information storage state and the biometric authentication information registration state of the issuer server 450 are Initialized to the unsaved / unregistered state, and the new biometric authentication information may be stored in the issuer server 450 when the payment by the above operations 1803 to 1807 is performed at the next payment.
  • the electronic device 101 101 uses biometric authentication for payment, and in operation 1835, if verification by the issuer server 450 fails, in operation 1837, switch to password authentication, and in operation 1839, verification by the issuer server 450 If this is successful, the payment is approved and the biometric authentication information storage state and the biometric authentication information registration state of the issuer server 450 are initialized to the unstored / unregistered state, and the payment by the above operations 1803 to 1807 is performed at the next payment.
  • the new biometric authentication information can be stored in the issuer server 450.
  • the verification by the issuer server 450 is successful, the payment is approved and the biometric authentication information storage state and the biometric authentication information registration state of the issuer server 450 remain in the stored / registered state.
  • 19A to 19F are diagrams illustrating an embodiment displayed on a display device when a biometric authentication verification fails during a payment according to FIG. 14 according to various embodiments and a recovery procedure through password authentication is performed.
  • FIG. 19A shows an example of a payment app 860 of an internet store, and in the payment app 860 of an internet store, a user can select to use the payment app 420 (eg, Samsung Pay) presented in the present invention. have. Then, the payment app 420 of the electronic device 101 attempts biometric authentication payment, and FIG. 19B indicates that biometric authentication payment is being attempted. Upon receiving the result of the failure of the biometric authentication verification from the issuer server 450, the electronic device 101 indicates that the biometric data cannot be authenticated, as shown in FIG. 19C, and attempts to make a payment using a password. I can tell you. When the user selects the password authentication attempt, the electronic device 101 switches to the password authentication payment and shows a keypad on the screen to enter the password as shown in FIG.
  • the payment app 420 eg, Samsung Pay
  • the electronic device 101 encrypts the password input by the user and transmits it to the issuer server 450, and upon receiving the result of authentication success from the issuer server 450, displays the authentication success as shown in FIG. As shown in 19f, a final mobile phone payment may be made and completed.
  • the electronic device 101 and the issuer server 450 store biometric authentication information, respectively, although not shown on the screen. / You can change the registration status to unsaved / unregistered status.
  • biometric authentication information storage / registration state of the electronic device 101 and the issuer server 450 is not stored / unregistered, biometric authentication information may also be registered at the time of the next biometric authentication payment, so a separate registration is required. It is much simpler and more usable than the existing method.
  • a method of operating an electronic device performs biometric authentication to register biometric authentication information for verification of biometric authentication and password for password authentication at the server upon initial use registration.
  • the operation of performing user authentication using at least one of the biometric authentication and the password authentication at the time of payment is an operation of requesting an original value of biometric verification from the server, in response to the request, Biometric authentication based on the operation of receiving the biometric verification original value and the information indicating the biometric authentication information registration status, and the information indicating the received biometric authentication information registration status and the biometric authentication information storage status stored in the memory. And / or determining to perform user authentication using password authentication.
  • the operation of determining to perform user authentication based on the biometric authentication information registration state of the server and the biometric authentication information storage state stored in the memory includes information indicating the biometric authentication information registration state received from the server. Determining that user authentication is performed using biometric authentication when the information indicating the state of registration and the state of storing the biometric authentication information is stored, the information indicating the state of biometric authentication information received from the server is unregistered and the biometric Determining that user authentication is performed using biometric authentication when the information indicating the authentication information storage state is unstored, the information indicating the biometric authentication information registration state received from the server is unregistered and the biometric authentication information storage state Information indicating In the case of the stored state, when the operation of determining to perform user authentication using password authentication and the information indicating the biometric authentication information registration state received from the server are registered and the information indicating the biometric authentication information storage state is unstored And determining to perform user authentication using password authentication.
  • the biometric authentication information storage state is not displayed after the user authentication is completed. Further comprising the step of converting to a storage state, when the information indicating the biometric authentication information registration state received from the server is in the registered state and the information indicating the biometric authentication information storage state is in the unstored state, after the user authentication is completed, to the server , Requesting to convert the biometric authentication information registration status to an unregistered status.
  • the operation of performing user authentication using at least one of the biometric authentication and the password authentication at the time of payment includes transmitting a parameter for biometric authentication verification to the server, and a biometric from the server Receiving an authentication verification result, when the received verification result is verification failure, transmitting an encrypted password for password authentication verification to the server, receiving a password verification result from the server, and receiving the verification result
  • the method may further include converting information indicating the biometric authentication information storage state into an unstored state, and requesting the server to convert information indicating the biometric authentication information registration state into an unregistered state.
  • a method of operating a server includes receiving a parameter for verifying biometric authentication and an encrypted password for verifying password authentication from an electronic device upon initial use registration, Decoding the encrypted password and storing the password in a memory, verifying biometric authentication based on the parameters for verifying the biometric authentication, and storing the obtained biometric authentication information in the memory, and receiving at the time of payment At least one of verifying biometric authentication based on a parameter for biometric authentication verification and the stored biometric authentication information, and verifying password authentication by comparing a password obtained from a received encrypted password and a password stored in the memory Including the operation of and new for the biometric authentication information If necessary, it may include an operation that stores new biometric authentication information registered while performing a payment using the biometric authentication in the memory.
  • the method may include receiving a request for the original biometric verification value from the electronic device upon payment, in response to the request, to the electronic device, the original biometric verification value and the biometric authentication information. Transmitting information indicating a registration status, receiving a parameter for verifying biometric authentication from the electronic device, verifying biometric authentication based on the parameter for verifying biometric authentication and the stored biometric authentication information, biometric authentication Transmitting a verification result to the electronic device, when the biometric verification result is verification failure, receiving an encrypted password from the electronic device, a password obtained from the received encrypted password, and a password stored in the memory Operation to verify password authentication by comparing, password Transmitting an authentication result to the electronic device, receiving the request to convert information indicating the biometric authentication information registration state from the electronic device into an unregistered state, if the verification result is successful verification, and in response to the request And converting information indicating the biometric authentication information registration status into an unregistered status.
  • the operation of storing the new biometric authentication information registered in the memory while performing payment using biometric authentication may be performed to verify biometric authentication from the electronic device.
  • the operation of verifying the biometric authentication is an operation of verifying the validity of a parameter for verifying the biometric authentication, and decrypting the encrypted original data included in the parameter for verifying the biometric authentication with the private key of the server
  • An operation of acquiring original data, an operation of checking whether a legitimate payment app is used by using a hash value included in the decrypted original data, and a biometric verification original value and the biometric verification included in the decrypted original data Checking whether the original value is the same, checking whether a certain time has elapsed since issuing the original biometric verification value, the stored biometric authentication information and the biometric public key included in the parameters for the biometric verification are the same. And verify the signature of the signed original data. May include an action.
  • the electronic device may be various types of devices.
  • the electronic device may include, for example, a portable communication device (eg, a smart phone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance device.
  • a portable communication device eg, a smart phone
  • a computer device e.g., a smart phone
  • a portable multimedia device e.g., a portable medical device
  • a camera e.g., a portable medical device
  • a camera e.g., a portable medical device
  • a camera e.g., a portable medical device
  • a wearable device e.g., a smart bracelet
  • a home appliance device e.g., a home appliance
  • any (eg first) component is referred to as a “coupled” or “connected” to another (eg second) component, with or without the term “functionally” or “communically”
  • any component can be connected directly to another component (eg, by wire), wirelessly, or through a third component.
  • module may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic blocks, components, or circuits.
  • the module may be an integrally configured component or a minimum unit of components or a part thereof performing one or more functions.
  • the module may be implemented in the form of an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • Various embodiments of the present document may include at least one stored in a storage medium (eg, internal memory 136 or external memory 138) readable by a machine (eg, electronic device 101). It may be implemented as software including instructions (eg, program 140).
  • a processor eg, processor 120
  • the at least one instruction may include code generated by a compiler or code executable by an interpreter.
  • the storage medium readable by the device may be provided in the form of a non-transitory storage medium.
  • 'non-transitory' only means that the storage medium is a tangible device, and does not include a signal (eg, electromagnetic waves). It does not distinguish between temporary storage cases.
  • a method according to various embodiments disclosed in this document may be provided as being included in a computer program product.
  • Computer program products are commodities that can be traded between sellers and buyers.
  • the computer program product is distributed in the form of a device-readable storage medium (e.g. CD-ROM (compact disc read only memory)), or through an application store (e.g. Play StoreTM ) or two user devices ( For example, it can be distributed directly between smartphones) and online (eg, downloaded or uploaded).
  • a portion of the computer program product may be stored at least temporarily in a storage medium readable by a device such as a memory of a manufacturer's server, an application store's server, or a relay server, or may be temporarily generated.
  • each component (eg, module or program) of the described components may include a singular or plural entities.
  • at least one of the above-described corresponding components or operations may be omitted, or at least one other component or operations may be added.
  • a plurality of components eg, modules or programs
  • the integrated component may perform at least one function of each component of the plurality of components the same or similar to that performed by the corresponding component among the plurality of components prior to integration.
  • operations performed by a module, program, or other component are executed sequentially, in parallel, repeatedly, or heuristically, or at least one of the operations is executed in a different order. , May be omitted, or at least one other action may be added.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

본 발명의 다양한 실시 예들은, 생체 인증을 이용한 결제 방법 및 그 전자 장치에 관한 것, 전자 장치는 서버와 통신을 제공하도록 구성된 통신 모듈, 상기 통신 모듈과 작동적으로 연결된 프로세서 및 상기 프로세서와 작동적으로 연결되고, 생체 정보를 저장하도록 구성된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하고, 결제 시에 사용자 인증을 위해 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하고, 상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 상기 서버에 등록하도록 하는 인스트럭션들을 저장할 수 있다.

Description

생체 인증을 이용한 결제 방법 및 그 전자 장치
본 발명의 다양한 실시예들은 생체 인증을 이용한 결제 방법 및 그 전자 장치에 관한 것이다.
온라인 또는 오프라인 결제를 위한 사용자 인증이 많이 요구되고 있다. 사용자 인증을 위한 방법으로 사용자 ID와 패스워드(password)를 이용한 사용자 인증이 많이 사용되어져 왔으며, 생체 정보를 이용하여 사용자를 인증하는 방법도 제시되어져 왔다.
기존의 생체 정보를 이용한 사용자 인증의 일 실시예로는 FIDO(Fast Identity Online) 표준을 들 수 있으며, FIDO 표준은 명확하게 등록, 인증, 등록 해제의 절차가 명시적으로 존재하여, FIDO 표준에 따르면 FIDO 클라이언트(client) 및 FIDO 서버(server)를 통한 생체 정보 미등록 상태 또는 인증 실패와 같은 에러 발생시, 별도로 생체 정보를 다시 등록하고, 이후 인증을 수행하는 절차가 순차적으로 진행된다.
종래의 FIDO(Fast Identity Online) 표준을 따르면, 사용자 인증을 위한 생체 정보의 재등록 및 이상 발생 시에 대해 새로운 등록 후에 인증을 하여야 하기 때문에 상당한 시간이 소요되는 등의 사용성 측면에서 불편함이 존재하였다.
본 발명의 다양한 실시예들은 인증 발행 서버가 직접 생체인증을 효율적이고 간편하게 수행하고, 등록과 인증을 동시시에 수행할 수 있는 생체 인증을 이용한 결제 방법 및 그 전자 장치를 제공한다.
본 발명의 다양한 실시예들에 따르면, 전자 장치는 서버와 통신을 제공하도록 구성된 통신 모듈, 상기 통신 모듈과 작동적으로 연결된 프로세서 및 상기 프로세서와 작동적으로 연결되고, 생체 정보를 저장하도록 구성된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하고, 결제 시에 사용자 인증을 위해 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하고, 상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 상기 서버에 등록하도록 하는 인스트럭션들을 저장할 수 있다.
본 발명의 다양한 실시예들에 따르면, 서버는 전자 장치와 통신을 제공하도록 구성된 통신 모듈, 상기 통신 모듈과 작동적으로 연결된 프로세서 및 상기 프로세서와 작동적으로 연결되고, 생체 인증 정보를 저장하도록 구성된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 최초 사용 등록 시에 전자 장치로부터 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 수신하고, 상기 암호화된 패스워드를 복호화하여 패스워드를 상기 메모리에 저장하고, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하고, 생체 인증을 이용한 결제 시에 수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하고, 패스워드 인증을 이용한 결제 시에 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하고, 상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하도록 하는 인스트럭션들을 저장할 수 있다.
본 발명의 다양한 실시예들에 따르면, 전자 장치의 동작 방법은 최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하는 동작, 결제 시에 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작 및 상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 서버에 등록하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 서버의 동작 방법은 최초 사용 등록 시에, 전자 장치로부터 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 수신하는 동작, 상기 암호화된 패스워드를 복호화하여 패스워드를 메모리에 저장하는 동작, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함하고 결제 시에, 수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하는 동작 및 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하는 동작 중 적어도 하나의 동작을 포함하고 상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함할 수 있다.
다양한 실시예들에 따른 방법 및 그 전자 장치는 인증 발행 서버가 직접 생체 인증을 효율적이고 간편하게 수행하도록 할 수 있도록 함으로써, 생체 인증 서버의 공용화로 인한 동시 서비스 불가 문제점 및 시스템 복잡도를 제거할 수 있으며, 유지보수성 및 보안성을 높일 수 있고, 사용료 지불에 따른 비용도 제거할 수 있다.
다양한 실시예들에 따른 방법 및 그 전자 장치는 등록 및 인증을 동시에 수행하여 별도 진행에 따른 시간 지연 문제를 해소하고 사용자의 사용성을 높일 수 있다.
도 1은 다양한 실시예들에 따른 네트워크 환경 내의 전자 장치의 블록도를 도시한다.
도 2은 다양한 실시예에 따른 프로그램을 예시하는 블록도이다.
도 3은, 다양한 실시예에 따른, 전자 장치에서 운용되는 일반 실행 환경과 보안 실행 환경을 도시하는 블록도이다.
도 4는 다양한 실시예들에 따른, 생체 인증을 이용한 결제 방법을 위한 시스템 구성도이다.
도 5는 다양한 실시예들에 따른 사용자 인증 정보를 등록하는 절차를 도시한 흐름도이다.
도 6은 다양한 실시예들에 따른 온라인 결제를 진행하는 절차를 도시한 흐름도이다.
도 7은 다양한 실시예들에 따른 결제 관련 정보 및 사용자 인증 정보를 삭제하는 절차를 도시한 흐름도이다.
도 8은 다양한 실시예들에 따른 생체 인증에 의한 검증 실패에 따른 패스워드 인증을 통한 복구 절차를 도시한 흐름도이다.
도 9는 다양한 실시예들에 따른, 전자 장치의 결제 정보 및 사용자 인증 정보 등록 동작을 도시한 흐름도이다.
도 10은 다양한 실시예들에 따른 전자 장치의 생체 인증 동작을 도시한 흐름도이다.
도 11은 다양한 실시예들에 따른 전자 장치의 패스워드 인증 동작을 도시한 흐름도이다.
도 12는 다양한 실시예들에 따른, 전자 장치의 결제 동작을 도시한 흐름도이다.
도 13은 다양한 실시예들에 따른, 발행사 서버의 결제 정보 및 사용자 인증 정보 등록 동작을 도시한 흐름도이다.
도 14는 다양한 실시예들에 따른, 발행사 서버의 결제시의 동작을 도시한 흐름도이다.
도 15는 다양한 실시예들에 따른, 복구 절차에 의하여 생체 인증 정보가 초기화된 이후의 발행사 서버의 결제시의 동작을 도시한 흐름도이다.
도 16은 다양한 실시예들에 따른, 발행사 서버의 생체 인증 검증 동작을 도시한 흐름도이다.
도 17은 다양한 실시예들에 따른 전자 장치의 사용자 인증을 위한 동작을 간략하게 도시한 흐름도이다.
도 18은 다양한 실시예들에 따른 전자 장치의 생체 인증 정보 저장 상태 및 발행자 서버의 생체 인증 정보 등록 상태에 따른 결제 시의 인증 절차를 도시한 흐름도이다.
도 19a 내지 19f는 다양한 실시예들에 따른 도 14에 따른 결제 시에 생체 인증 검증이 실패하여 패스워드 인증을 통한 복구 절차를 진행하는 경우의 표시장치에 표시되는 일 실시예를 도시한 도면이다.
이하 다양한 실시예들이 첨부된 도면을 참고하여 상세히 설명된다.
도 1은 다양한 실시예들에 따른 네트워크 환경(100) 내의 전자 장치(101)의 블록도이다. 도 1을 참고하면, 네트워크 환경(100)에서 전자 장치(101)는 제1 네트워크(198)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(102)와 통신하거나, 또는 제2 네트워크(199)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(104) 또는 서버(108)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 서버(108)를 통하여 전자 장치(104)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 프로세서(120), 메모리(130), 입력 장치(150), 음향 출력 장치(155), 표시 장치(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 포함할 수 있다. 일 실시예에서는, 전자 장치(101)에는, 이 구성요소들 중 적어도 하나(예: 표시 장치(160) 또는 카메라 모듈(180))가 생략되거나, 적어도 하나의 다른 구성 요소가 추가될 수 있다. 일 실시예에서는, 이 구성요소들 중 일부들은 하나의 통합된 회로로 구현될 수 있다. 예를 들면, 센서 모듈(176)(예: 지문 센서, 홍채 센서, 또는 조도 센서)은 표시 장치(160)(예: 디스플레이)에 임베디드(embedded) 된 채 구현될 수 있다
프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램(140))를 실행하여 프로세서(120)에 연결된 전자 장치(101)의 적어도 하나의 다른 구성요소(예: 하드웨어 또는 소프트웨어 구성요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일 실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성요소(예: 센서 모듈(176) 또는 통신 모듈(190))로부터 수신된 명령 또는 데이터를 휘발성 메모리(132)에 로드하고, 휘발성 메모리(132)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비휘발성 메모리(134)에 저장할 수 있다. 일 실시예에 따르면, 프로세서(120)는 메인 프로세서(121)(예: 중앙 처리 장치 또는 어플리케이션 프로세서), 및 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(123)(예: 그래픽 처리 장치, 이미지 시그널 프로세서, 센서 허브 프로세서, 또는 통신 프로세서)를 포함할 수 있다. 추가적으로 또는 대체적으로, 보조 프로세서(123)는 메인 프로세서(121)보다 저전력을 사용하거나, 또는 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(123)는 메인 프로세서(121)와 별개로, 또는 그 일부로서 구현될 수 있다.
보조 프로세서(123)는, 예를 들면, 메인 프로세서(121)가 인액티브(예: 슬립) 상태에 있는 동안 메인 프로세서(121)를 대신하여, 또는 메인 프로세서(121)가 액티브(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(121)와 함께, 전자 장치(101)의 구성요소들 중 적어도 하나의 구성요소(예: 표시 장치(160), 센서 모듈(176), 또는 통신 모듈(190))와 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 이미지 시그널 프로세서 또는 통신 프로세서)는 기능적으로 관련 있는 다른 구성 요소(예: 카메라 모듈(180) 또는 통신 모듈(190))의 일부로서 구현될 수 있다.
메모리(130)는, 전자 장치(101)의 적어도 하나의 구성요소(예: 프로세서(120) 또는 센서 모듈(176))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(140)) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리(130)는, 휘발성 메모리(132) 또는 비휘발성 메모리(134)를 포함할 수 있다.
프로그램(140)은 메모리(130)에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(142), 미들웨어(144) 또는 어플리케이션(146)을 포함할 수 있다.
입력 장치(150)는, 전자 장치(101)의 구성요소(예: 프로세서(120))에 사용될 명령 또는 데이터를 전자 장치(101)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 장치(150)는, 예를 들면, 마이크, 마우스, 키보드 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.
음향 출력 장치(155)는 음향 신호를 전자 장치(101)의 외부로 출력할 수 있다. 음향 출력 장치(155)는, 예를 들면, 스피커 또는 리시버를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있고, 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일 실시예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.
표시 장치(160)는 전자 장치(101)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 표시 장치(160)는, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일 실시예에 따르면, 표시 장치(160)는 터치를 감지하도록 설정된 터치 회로(touch circuitry), 또는 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 센서 회로(예: 압력 센서)를 포함할 수 있다.
오디오 모듈(170)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일 실시예에 따르면, 오디오 모듈(170)은, 입력 장치(150) 를 통해 소리를 획득하거나, 음향 출력 장치(155), 또는 전자 장치(101)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(102))(예: 스피커 또는 헤드폰))를 통해 소리를 출력할 수 있다.
센서 모듈(176)은 전자 장치(101)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일 실시예에 따르면, 센서 모듈(176)은, 예를 들면, 제스처 센서, 자이로 센서, 기압 센서, 마그네틱 센서, 가속도 센서, 그립 센서, 근접 센서, 컬러 센서, IR(infrared) 센서, 생체 센서, 온도 센서, 습도 센서, 또는 조도 센서를 포함할 수 있다.
인터페이스(177)는 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 적어도 하나의 지정된 프로토콜들을 지원할 수 있다. 일 실시예에 따르면, 인터페이스(177)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD 카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.
연결 단자(178)는, 그를 통해서 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일 실시예에 따르면, 연결 단자(178)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.
햅틱 모듈(179)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일 실시예에 따르면, 햅틱 모듈(179)은, 예를 들면, 모터, 압전 소자, 또는 전기 자극 장치를 포함할 수 있다.
카메라 모듈(180)은 정지 영상 및 동영상을 촬영할 수 있다. 일 실시예에 따르면, 카메라 모듈(180)은 적어도 하나의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.
전력 관리 모듈(188)은 전자 장치(101)에 공급되는 전력을 관리할 수 있다. 일 실시예에 따르면, 전력 관리 모듈(188)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.
배터리(189)는 전자 장치(101)의 적어도 하나의 구성 요소에 전력을 공급할 수 있다. 일 실시예에 따르면, 배터리(189)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지를 포함할 수 있다.
통신 모듈(190)은 전자 장치(101)와 외부 전자 장치(예: 전자 장치(102), 전자 장치(104), 또는 서버(108))간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은 프로세서(120)(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 적어도 하나의 통신 프로세서를 포함할 수 있다. 일 실시예에 따르면, 통신 모듈(190)은 무선 통신 모듈(192)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(194)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제1 네트워크(198)(예: 블루투스, WiFi direct 또는 IrDA(infrared data association) 같은 근거리 통신 네트워크) 또는 제2 네트워크(199)(예: 셀룰러 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN)와 같은 원거리 통신 네트워크)를 통하여 외부 전자 장치(104)와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성 요소(예: 단일 칩)으로 통합되거나, 또는 서로 별도의 복수의 구성 요소들(예: 복수 칩들)로 구현될 수 있다. 무선 통신 모듈(192)은 가입자 식별 모듈(196)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI))를 이용하여 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크 내에서 전자 장치(101)를 확인 및 인증할 수 있다.
안테나 모듈(197)은 신호 또는 전력을 외부(예: 외부 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 안테나 모듈(197)은, 일 실시예에 따르면, 도전체 또는 도전성 패턴으로 형성될 수 있고, 일 실시예에 따르면, 도전체 또는 도전성 패턴 이외에 추가적으로 다른 부품(예: RFIC)을 더 포함할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 적어도 하나의 안테나들을 포함할 수 있고, 이로부터, 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(190)에 의하여 선택될 수 있다. 신호 또는 전력은 선택된 적어도 하나의 안테나를 통하여 통신 모듈(190)과 외부 전자 장치 간에 송신되거나 수신될 수 있다.
상술한 구성요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))을 통해 서로 연결되고 신호(예: 명령 또는 데이터)를 상호간에 교환할 수 있다.
일 실시예에 따르면, 명령 또는 데이터는 제2 네트워크(199)에 연결된 서버(108)를 통해서 전자 장치(101)와 외부의 전자 장치(104)간에 송신 또는 수신될 수 있다. 외부 전자 장치(102, 104) 각각은 전자 장치(101)와 동일한 또는 다른 종류의 장치일 수 있다. 일 실시예에 따르면, 전자 장치(101)에서 실행되는 동작들의 전부 또는 일부는 외부 전자 장치들(102, 104, 또는 108) 중 적어도 하나의 외부 장치들에서 실행될 수 있다. 예를 들면, 전자 장치(101)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 외부 장치로부터의 요청에 반응하여 수행해야 할 경우에, 전자 장치(101)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 적어도 하나의 외부 전자 장치들에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 요청을 수신한 적어도 하나의 외부 전자 장치들은 요청된 기능 또는 서비스의 적어도 일부, 또는 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 결과를, 그대로 또는 추가적으로 처리하여, 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅, 분산 컴퓨팅, 또는 클라이언트-서버 컴퓨팅 기술이 이용될 수 있다.
도 2은 다양한 실시예에 따른 프로그램(140)을 예시하는 블록도(200)이다. 일실시예에 따르면, 프로그램(140)은 전자 장치(101)의 하나 이상의 리소스들을 제어하기 위한 운영 체제(142), 미들웨어(144), 또는 상기 운영 체제(142)에서 실행 가능한 어플리케이션(146)을 포함할 수 있다. 운영 체제(142)는, 예를 들면, AndroidTM, iOSTM, WindowsTM, SymbianTM, TizenTM, 또는 BadaTM를 포함할 수 있다. 프로그램(140) 중 적어도 일부 프로그램은, 예를 들면, 제조 시에 전자 장치(101)에 프리로드되거나, 또는 사용자에 의해 사용 시 외부 전자 장치(예: 전자 장치(102 또는 104), 또는 서버(108))로부터 다운로드되거나 갱신될 수 있다.
운영 체제(142)는 전자 장치(101)의 하나 이상의 시스템 리소스들(예: 프로세스, 메모리, 또는 전원)의 관리(예: 할당 또는 회수)를 제어할 수 있다. 운영 체제(142)는, 추가적으로 또는 대체적으로, 전자 장치(101)의 다른 하드웨어 디바이스, 예를 들면, 입력 장치(150), 음향 출력 장치(155), 표시 장치(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 구동하기 위한 하나 이상의 드라이버 프로그램들을 포함할 수 있다.
미들웨어(144)는 전자 장치(101)의 하나 이상의 리소스들로부터 제공되는 기능 또는 정보가 어플리케이션(146)에 의해 사용될 수 있도록 다양한 기능들을 어플리케이션(146)으로 제공할 수 있다. 미들웨어(144)는, 예를 들면, 어플리케이션 매니저(201), 윈도우 매니저(203), 멀티미디어 매니저(205), 리소스 매니저(207), 파워 매니저(209), 데이터베이스 매니저(211), 패키지 매니저(213), 커넥티비티 매니저(215), 노티피케이션 매니저(217), 로케이션 매니저(219), 그래픽 매니저(221), 시큐리티 매니저(223), 통화 매니저(225), 또는 음성 인식 매니저(227)를 포함할 수 있다.
어플리케이션 매니저(201)는, 예를 들면, 어플리케이션(146)의 생명 주기를 관리할 수 있다. 윈도우 매니저(203)는, 예를 들면, 화면에서 사용되는 하나 이상의 GUI 자원들을 관리할 수 있다. 멀티미디어 매니저(205)는, 예를 들면, 미디어 파일들의 재생에 필요한 하나 이상의 포맷들을 파악하고, 그 중 선택된 해당하는 포맷에 맞는 코덱을 이용하여 상기 미디어 파일들 중 해당하는 미디어 파일의 인코딩 또는 디코딩을 수행할 수 있다. 리소스 매니저(207)는, 예를 들면, 어플리케이션(146)의 소스 코드 또는 메모리(130)의 메모리의 공간을 관리할 수 있다. 파워 매니저(209)는, 예를 들면, 배터리(189)의 용량, 온도 또는 전원을 관리하고, 이 중 해당 정보를 이용하여 전자 장치(101)의 동작에 필요한 관련 정보를 결정 또는 제공할 수 있다. 일실시예에 따르면, 파워 매니저(209)는 전자 장치(101)의 바이오스(BIOS: basic input/output system)(미도시)와 연동할 수 있다.
데이터베이스 매니저(211)는, 예를 들면, 어플리케이션(146)에 의해 사용될 데이터베이스를 생성, 검색, 또는 변경할 수 있다. 패키지 매니저(213)는, 예를 들면, 패키지 파일의 형태로 배포되는 어플리케이션의 설치 또는 갱신을 관리할 수 있다. 커넥티비티 매니저(215)는, 예를 들면, 전자 장치(101)와 외부 전자 장치 간의 무선 연결 또는 직접 연결을 관리할 수 있다. 노티피케이션 매니저(217)는, 예를 들면, 지정된 이벤트(예: 착신 통화, 메시지, 또는 알람)의 발생을 사용자에게 알리기 위한 기능을 제공할 수 있다. 로케이션 매니저(219)는, 예를 들면, 전자 장치(101)의 위치 정보를 관리할 수 있다. 그래픽 매니저(221)는, 예를 들면, 사용자에게 제공될 하나 이상의 그래픽 효과들 또는 이와 관련된 사용자 인터페이스를 관리할 수 있다.
시큐리티 매니저(223)는, 예를 들면, 시스템 보안 또는 사용자 인증을 제공할 수 있다. 통화(telephony) 매니저(225)는, 예를 들면, 전자 장치(101)에 의해 제공되는 음성 통화 기능 또는 영상 통화 기능을 관리할 수 있다. 음성 인식 매니저(227)는, 예를 들면, 사용자의 음성 데이터를 서버(108)로 전송하고, 그 음성 데이터에 적어도 일부 기반하여 전자 장치(101)에서 수행될 기능에 대응하는 명령어(command), 또는 그 음성 데이터에 적어도 일부 기반하여 변환된 문자 데이터를 서버(108)로부터 수신할 수 있다. 일 실시예에 따르면, 미들웨어(244)는 동적으로 기존의 구성요소를 일부 삭제하거나 새로운 구성요소들을 추가할 수 있다. 일 실시예에 따르면, 미들웨어(144)의 적어도 일부는 운영 체제(142)의 일부로 포함되거나, 또는 운영 체제(142)와는 다른 별도의 소프트웨어로 구현될 수 있다.
어플리케이션(146)은, 예를 들면, 홈(251), 다이얼러(253), SMS/MMS(255), IM(instant message)(257), 브라우저(259), 카메라(261), 알람(263), 컨택트(265), 음성 인식(267), 이메일(269), 달력(271), 미디어 플레이어(273), 앨범(275), 와치(277), 헬스(279)(예: 운동량 또는 혈당과 같은 생체 정보를 측정), 또는 환경 정보(281)(예: 기압, 습도, 또는 온도 정보 측정) 어플리케이션을 포함할 수 있다. 일실시예에 따르면, 어플리케이션(146)은 전자 장치(101)와 외부 전자 장치 사이의 정보 교환을 지원할 수 있는 정보 교환 어플리케이션(미도시)을 더 포함할 수 있다. 정보 교환 어플리케이션은, 예를 들면, 외부 전자 장치로 지정된 정보 (예: 통화, 메시지, 또는 알람)를 전달하도록 설정된 노티피케이션 릴레이 어플리케이션, 또는 외부 전자 장치를 관리하도록 설정된 장치 관리 어플리케이션을 포함할 수 있다. 노티피케이션 릴레이 어플리케이션은, 예를 들면, 전자 장치(101)의 다른 어플리케이션(예: 이메일 어플리케이션(269))에서 발생된 지정된 이벤트(예: 메일 수신)에 대응하는 알림 정보를 외부 전자 장치로 전달할 수 있다. 추가적으로 또는 대체적으로, 노티피케이션 릴레이 어플리케이션은 외부 전자 장치로부터 알림 정보를 수신하여 전자 장치(101)의 사용자에게 제공할 수 있다.
장치 관리 어플리케이션은, 예를 들면, 전자 장치(101)와 통신하는 외부 전자 장치 또는 그 일부 구성 요소(예: 표시 장치(160) 또는 카메라 모듈(180))의 전원(예: 턴-온 또는 턴-오프) 또는 기능(예: 표시 장치(160) 또는 카메라 모듈(180)의 밝기, 해상도, 또는 포커스)을 제어할 수 있다. 장치 관리 어플리케이션은, 추가적으로 또는 대체적으로, 외부 전자 장치에서 동작하는 어플리케이션의 설치, 삭제, 또는 갱신을 지원할 수 있다.
도 3은, 다양한 실시예에 따른, 전자 장치(예: 전자 장치(101))에서 운용되는 일반 실행 환경과 보안 실행 환경을 도시하는 블록도(300)이다. 다양한 실시예에 따르면, 전자 장치는 보안 강화를 위해 복수의 보안 레벨을 가진 실행 환경을 운용할 수 있다. 복수의 실행 환경은, 예를 들면, REE(rich execution environment)(310) 및 TEE(trusted execution environment)(320)를 포함할 수 있다. REE는, 예를 들면, 제1 보안 레벨을 가지는 제1 실행 환경일 수 있다. TEE는, 예를 들면, 제1 보안 레벨과 다른(예: 높은) 제2 보안 레벨을 가지는 제2 실행 환경일 수 있다. 한 실시예에 따르면, 전자 장치(101)는 제3 보안 레벨을 가지는 제3 실행 환경을 포함할 수 있으며, 이에 한정하는 것은 아니다.
TEE(320)는 상대적으로 높은 보안 레벨이 요구되는 데이터를 안전한 환경 내에서 저장하고 관련 동작을 수행할 수 있다. TEE(320)는 전자 장치의 어플리케이션 프로세서 상에서 동작하고, 전자 장치의 제조 과정에서 결정된 신뢰할 수 있는 하드웨어 구조에 기반하여 동작할 수 있다. TEE(320)는 어플리케이션 프로세서 또는 메모리를 일반 영역과 보안 영역으로 구분하여 보안 영역에서 동작할 수 있다. TEE(320)는 보안이 필요한 소프트웨어나 하드웨어를 보안 영역에서만 동작하게 하도록 설정할 수 있다. 전자 장치는 하드웨어의 물리적 변경 또는 소프트웨어의 논리적 변경을 통하여 보안 실행 환경을 운용할 수 있다. TEE(320)는 임베디드 보안 요소(embedded secure element; ESE), 보안 요소(secure element) 또는 트러스트 존(trust zone)이라 지칭될 수 있다.
TEE(320)는 REE(310)와 하드웨어적인 제약을 통하여 서로 분리될 수 있고, 동일한 하드웨어에서 소프트웨어적으로 분리되어 동작할 수 있다. REE(310)에서 동작하는 적어도 하나의 어플리케이션(예: 결제, 컨택트, 이메일, 또는 브라우저 등)은 TEE(320)에 접근이 허용된 API(예: TEE functional API 또는 TEE client API)를 이용할 수 있다. 상기 적어도 하나의 어플리케이션은 상기 API를 이용하여 일반 실행 환경의 통신 에이전트(REE communication agent)에서 보안 실행 환경의 통신 에이전트)(TEE communication agent)로 메시지를 전달할 수 있다. 상기 메시지는 하드웨어적으로 TEE(320)에만 전달될 수 있도록 구현될 수 있다. 보안 실행 환경의 통신 에이전트는 상기 메시지를 수신하여 상기 메시지와 관련된 보안 어플리케이션(trusted application(TA))(예: DRM, 보안 결제 모듈, 또는 보안 생체 정보 모듈 등)에 전달할 수 있다. 보안 어플리케이션은 상기 메시지에 관련된 동작을 수행할 수 있으며, 동작에 대한 결과를 보안 실행 환경의 통신 에이전트를 통하여 일반 실행 환경의 통신 에이전트에 전달할 수 있다. 상기 일반 실행 환경의 통신 에이전트는 일반 실행 환경에서 운용 중인 적어도 하나의 어플리케이션에 상기 결과를 전달할 수 있다.
도 4는 다양한 실시예들에 따른, 생체 인증을 이용한 결제 방법을 위한 시스템 구성도(300)이다. 전자 장치(101)는, 도 1에 도시된 다양한 구성을 포함할 수 있으나, 도 4에서는, 설명의 간략화를 위하여, 필요한 구성만을 도시한다. 서버(410)는 도 1에 도시된 서버(108)에 포함될 수 있으며, 서버(410) 및 전자 장치(101)는 제1 네트워크(198) 및/또는 제2 네트워크(199)를 이용하여 서로 통신할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 결제를 실행하기 위하여 결제 앱(420), 생체 모듈(431) 및 인증 모듈(433)을 포함할 수 있다. 결제 앱(420)은 REE(310)에서 동작할 수 있으며, 생체 모듈(431) 및 인증 모듈(433)은 TEE(320)에서 동작할 수 있다. 결제 앱(420), 생체 모듈(431) 및 인증 모듈(433)은 하나 이상의 프로세서(예: 도 1의 프로세서(120))에서 동작할 수 있으며, 전자 장치(101)의 보안환경 운용 방식에 따라 동일한 프로세서에서 동작할 수도 있으며, 서로 다른 프로세서에서 동작할 수도 있다.
다양한 실시예들에 따르면, 결재 앱(420)은 도 1 또는 도 2에 도시된 어플리케이션(146) 중의 하나일 수 있으며, 사용자가 결제를 시도하고자 할 때 실행될 수 있다.
다양한 실시예들에 따르면, 결제 앱(420)은 PW 제어기 (password controller) (421), SBA 제어기 (simple bio auth controller) (423), 생체 인터페이스(425), 및 인증 인터페이스(425)를 포함할 수 있다.
PW 제어기(421)는 신용카드사, 은행, 소액 결제 대행사와 같은 발행사에 등록하고 인증에 사용할 비밀 번호를 사용자로부터 입력 받아 발행사 서버(450)에 전달할 수 있다. 또한, PW 제어기(421)에 의한 패스워드(password) 등록은 최초 사용 등록 시에 행해지며, PW 제어기(421)에 의한 패스워드 인증은 결제 시 또는 결제 정보 삭제 시 수행되는 생체 인증의 실패 시 생체 인증을 대신하여 사용자 인증을 수행하거나 생체 인증 정보를 리셋(reset)하는 경우에 사용될 수 있다. 여기서 패스워드는 PIN(personal identification number), 숫자, 패턴, 영문자/숫자의 조합, 영문자/숫자/기호의 조합을 포함할 수 있다.
SBA 제어기(423)는 생체 인증과 관련된 통합 제어 기능을 수행하여, 발행사 서버(450)로부터 수신한 생체 검증 원본값(nonce)을 저장하고, 생체 모듈(431) 및 인증 모듈(433)과의 생체 인증 흐름을 제어하여 최종 생체 인증 검증을 위한 파라미터를 생성하고, 발행사 서버(450)로 생성된 파라미터를 전달할 수 있다. SBA 제어기(423)는 인증 모듈(433)에 인증 모듈(433)과 생체 모듈(431) 사이의 데이터 검증 및 보안을 위하여 무작위로 생성한 오브젝트(object) 기준값을 요청하여 전달받을 수 있다. SBA 제어기(423)는 오브젝트 기준값을 생체 모듈(431)로 전달하고, 생체 모듈(431)로부터 생체 인증 결과에 따라 오브젝트 기준값을 인증 모듈(433)에서만 복호화(decoding)할 수 있도록 암호화한 보안 객체(secure object)를 수신할 수 있다. SBA 제어기(423)는 보안 객체, 생체 검증 원본값 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함하는 '원본 데이터' (파이널챌린지(final challenge)로 칭할 수도 있다)를 인증 모듈(433)로 전달하고, 인증 모듈(433)로부터 3개의 인증 파라미터들을 수신할 수 있다. 3개의 인증 파라미터는 원본 데이터를 생체 서명 개인키(예: cbioPRV)로 서명한 '서명된 원본 데이터' (파이널챌린지사인드(final challenge signed)로 칭할 수도 있다), 원본데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 '암호화된 원본 데이터' (파이널챌린지인크립티드 (final challenge encrypted)로 칭할 수도 있다) 및 발행사 서버(450)에서 생체 인증 검증용으로 사용할 생체 인증 공개키(예: cbioPUK)를 포함할 수 있다. SBA 제어기(423)는 생성된 3개의 파라미터를 발행사 서버(450)로 전달하여 생체 인증을 이용한 사용자 인증을 요청할 수 있다.
생체 인터페이스(425)는 TEE(320)에 있는 생체 모듈(431)과 결제 앱(420) 간의 메시지 또는 신호 전송을 위하여 정의된 인터페이스(interface)에 따라 메시지를 전달하거나 수신할 수 있다. 인증 인터페이스(425)는 TEE(320)에 있는 인증 모듈(433)과 결제 앱(420)간의 메시지 또는 신호 전송을 위하여 정의된 인터페이스에 따라 메시지를 전달하거나 수신할 수 있다. 생체 인터페이스(425) 및 인증 인터페이스(427)는 TEE(320)에 접근이 허용된 API일 수 있다.
다양한 실시예들에 따르면, 생체 모듈(431)은 TEE(320)에서 동작하는 모듈로서 전자 장치(101)내 생체 인증의 결과를 암호화하여 생성하고, 결재 앱(420)으로 전달하는 모듈이다. 생체 모듈(431)은 사용자의 생체 정보로부터 획득할 수 있는 독특한 정보를 바탕으로 생체 인증을 수행할 수 있는데, 지문, 홍채 등을 바탕으로 생체 인증을 수행할 수 있다. 생체 모듈(431)은 최초 등록 시 또는 생체 정보의 저장이 필요한 경우에는 사용자로부터 생체 정보를 획득하여 TEE(320) 내의 메모리에 저장할 수 있다. 생체 정보가 이미 저장되어 있는 경우에, 생체 모듈(431)은 저장된 생체 정보와 사용자가 입력한 생체 정보를 비교하여 동일하다고 판단하는 경우 생체 인증이 되었다고 판단할 수 있고, 동일하지 않은 경우 생체 인증이 되지 않았다고 판단할 수 있다. 생체 정보가 이미 저장되어 있는 지에 대한 판단은 생체 인증 정보 저장 상태를 나타내는 정보를 기초로 할 수 있다. 생체 모듈(431)은 생체 인증 결과를 바탕으로 SBA 제어기(423)로부터 전달받은 오브젝트 기준값을 암호화한 보안 객체를 생성할 수 있다. 다양한 실시예에 따르면, 생체 모듈(431)은 생체 인증이 되었다고 판단하는 경우에만 오브젝트 기준값을 암호화한 보안 객체를 생성할 수 있다. 생체 모듈(431)은 생성한 보안 객체를 SBA 제어기(423)로 전달할 수 있다.
다양한 실시예들에 따르면, 인증 모듈(433)은 TEE(320)에서 동작하는 모듈로서, 생체 모듈(431)이 생성한 생체 인증의 결과값을 확인하여 발행사 서버(450)로 전달할 생체 인증 최종 결과값을 서명하는 모듈이다. 인증 모듈(433)은 SBA 제어기(423)의 요청에 따라 오브젝트 기준값을 생성하여 전달할 수 있고, SBA 제어기(423)를 통해 수신한 생체 모듈(431)에서 생성한 보안 객체를 복호화 하여 생체 인증이 되었는 지를 판단할 수 있다. 인증 모듈(433)은 만약 기존에 생성되었던 키쌍이 없는 경우, 생체 인증을 위한 개인키(예: cbioPRV), 공개키(예: cbioPUK) 쌍을 생성할 수 있고, 이 키쌍을 SBA 제어기(423)로부터 전달받은 원본 데이터에 적용하여 생체 인증 검증을 위한 3개의 파라미터를 생성할 수 있다.
다양한 실시예들에 따르면 서버(410)는 결제 서버(440) 및 적어도 하나의 발행사 서버(450)를 포함할 수 있다. 결제 서버(440)는 생체 인증 흐름과 관련하여 게이트웨이(gateway) 역할을 수행하여 결제 앱(420)과 적어도 하나의 발행사 서버(450) 사이의 데이터 전송하는 기능을 수행하고, 적어도 하나의 발행사 서버(450)가 발행한 공개키를 저장하였다가 결재 앱(420)에 제공하는 기능을 수행할 수 있다. 적어도 하나의 발행사 서버(450)는 생체 검증 원본값(nonce)을 사용자별로 생성, 보관, 제어하고, 결재 앱(420)에서 생성한 서명 검증용 공개키를 사용자 별로 저장, 관리하며, 결제 앱(420)으로부터 전달받은 최종 생체 인증 결과값을 검증하여 사용자를 인증할 수 있다. 여기서, 발행사 서버(450)는 생체 검증 원본값을 무작위로 생성할 수 있다. 적어도 하나의 발행사 서버(450) 각각은 타 전자 장치(예: 전자 장치(101), 결제 서버(450))와 통신을 수행하기 위한 통신 모듈 및 검증에 필요한 생체 인증 정보를 저장하기 위한 메모리 및 결제 앱(420)에 대응하여 동작하는 SBA 서버(simple bio auth server) (451)를 포함할 수 있다.
다양한 실시예들에 따르면, 전자 장치는 서버와 통신을 제공하도록 구성된 통신 모듈, 상기 통신 모듈과 작동적으로 연결된 프로세서 및 상기 프로세서와 작동적으로 연결되고, 생체 정보를 저장하도록 구성된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하고, 결제 시에 사용자 인증을 위해 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하고, 상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 상기 서버에 등록하도록 하는 인스트럭션들을 저장할 수 있다.
다양한 실시예들에 따르면, 상기 메모리는 생체 인증 정보 저장 상태를 나타내는 정보를 저장하고, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 서버로 생체 검증 원본값을 요청하고, 상기 요청에 대한 응답으로, 상기 서버로부터, 생체 검증 원본값 및 생체 인증 정보 등록 상태를 나타내는 정보를 수신하고, 상기 수신한 생체 인증 정보 등록 상태를 나타내는 정보 및 상기 생체 인증 정보 저장 상태를 나타내는 정보를 기초로 생체 인증 및/또는 패스워드 인증을 이용하여 사용자 인증을 수행할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하고, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하고, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하고, 사용자 인증 완료 후에 상기 생체 인증 정보 저장 상태를 나타내는 정보를 미저장 상태로 변환하고, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하고, 상기 사용자 인증을 수행 완료 후에 상기 서버로, 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 요청하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 서버로 생체 인증 검증을 위한 파라미터를 전송하고, 상기 서버로부터 생체 인증 검증 결과를 수신하고, 상기 수신한 검증 결과가 검증 실패인 경우 패스워드 인증 검증을 위한 암호화된 패스워드를 상기 서버로 전송하고, 상기 서버로부터 패스워드 검증 결과를 수신하고, 상기 검증 결과가 검증 성공인 경우 상기 생체 인증 정보 저장 상태를 나타내는 정보를 미저장 상태로 변환하고, 상기 서버로 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 요청하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 오브젝트 기준값을 생성하고, 생체 인증 결과에 기반하여 상기 오브젝트 기준값을 암호화한 보안 객체(secure object)를 생성하고, 상기 생체 검증 원본값, 상기 보안 객체 및 결제에 사용하는 앱을 나타내는 해쉬값을 포함하는 원본 데이터를 생성하고, 상기 원본 데이터를 기초로 상기 생체 인증 검증을 위한 파라미터를 생성하도록 할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우, 생체 인증 수행 중에 생체 인증 개인키/공개키 쌍을 생성하여 저장하도록 하고, 상기 생체 인증 검증을 위한 파라미터는 상기 생체 인증 개인키로 상기 원본 데이터를 서명한 '서명된 원본 데이터', 상기 원본 데이터를 상기 서버에서 제공한 공개키로 암호화한 '암호화된 원본 데이터' 및 상기 생체 인증 공개키를 포함할 수 있다.
다양한 실시예들에 따르면, 서버는 전자 장치와 통신을 제공하도록 구성된 통신 모듈, 상기 통신 모듈과 작동적으로 연결된 프로세서 및 상기 프로세서와 작동적으로 연결되고, 생체 인증 정보를 저장하도록 구성된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 최초 사용 등록 시에 전자 장치로부터 생체 인증 검증을 위한 파라미터 및 암호화된 패스워드를 수신하고, 상기 패스워드 인증 검증을 위한 암호화된 패스워드를 복호화하여 패스워드를 상기 메모리에 저장하고, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하고, 생체 인증을 이용한 결제 시에 수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하고, 패스워드 인증을 이용한 결제 시에 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하고, 상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하도록 하는 인스트럭션들을 저장할 수 있다.
다양한 실시예들에 따르면, 상기 메모리는 생체 인증 정보 등록 상태를 나타내는 정보를 저장하고, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 전자 장치로부터 생체 검증 원본값에 대한 요청을 수신하고, 상기 요청에 대한 응답으로, 상기 전자 장치로, 생체 검증 원본값 및 상기 생체 인증 정보 등록 상태를 나타내는 정보를 전송할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하고, 상기 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하고, 상기 생체 인증 검증 결과를 상기 전자 장치로 전송하고, 상기 생체 인증 검증 결과가 검증 실패인 경우 상기 암호화된 패스워드를 상기 전자 장치로부터 수신하고, 상기 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하고, 상기 패스워드 검증 결과를 상기 전자 장치로 전송하고, 상기 패스워드 검증 결과가 검증 성공인 경우 상기 전자 장치로부터 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 하는 요청을 수신하고, 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 결제 시에 상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하고, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고, 상기 검증 결과 성공인 경우, 상기 생체 인증 검증을 위한 파라미터로부터 획득한 생체 인증 정보를 상기 메모리에 저장하여 등록하고, 상기 전자 장치로 상기 검증 결과를 전송할 수 있다.
다양한 실시예들에 따르면, 상기 생체 인증 검증을 위한 파라미터는 상기 전자 장치가 생성한 생체 인증 개인키로 원본 데이터를 서명한 '서명된 원본 데이터', 상기 원본 데이터를 서버에서 생성한 공개키로 암호화한 '암호화된 원본 데이터' 및 상기 전자 장치가 생성한 생체 인증 공개키를 포함할 수 있다.
다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서가, 상기 생체 인증 검증을 위한 파라미터의 유효성을 확인하고, 상기 암호화된 원본 데이터를 상기 서버의 개인키로 복호화 하여 원본 데이터를 획득하고, 상기 복호된 원본 데이터에 포함되어 있는 결제에 사용하는 앱을 나타내는 해쉬값을 이용하여 결제에 사용한 앱이 정당한지를 확인하고, 상기 복호된 원본 데이터에 포함되어 있는 생체 검증 원본값과 상기 생체 검증 원본값이 동일한 지 판단하고, 상기 생체 검증 원본값을 발행한 이후 일정 시간이 지났는 지를 판단하고, 상기 저장된 생체 인증 정보 및 상기 생체 인증 검증을 위한 파라미터에 포함된 상기 생체 인증 공개키가 동일한 지 확인하고, 상기 서명된 원본 데이터의 서명을 검증하여, 상기 생체 인증 검증을 수행할 수 있다.
상술한 구성을 바탕으로 이하에서는 사용자 등록, 결제, 삭제에 대한 동작에 대하여 설명한다.
도 5는 다양한 실시예들에 따른 사용자 인증 정보를 등록하는 절차를 도시한 흐름도(500)이다.
도 5를 참조하면, 동작 501에서, 발행사 서버(450)는 자신의 공개키/개인키를 생성 후 공개키(예: sPUK)를 결제 서버(440)로 전달한다. 공개키는 오프라인으로 전달될 수 있으며, 발행사 서버(450)가 복수 개인 경우, 각각의 발행사 서버(450)에 대응하는 공개키를 결제 서버(440)가 전달받을 수 있다.
일 실시예에 따르면, 동작 502에서, 결제 앱(420)은 사용하고자 하는 카드 또는 소액 결제를 위한 전화번호를 포함하는 결제 관련 정보 및 사용자 정보를 제공하고, 해당 사용자가 정당한 사용자인지 확인할 수 있다. 동작 503에서 결제 앱(420)은 발행사 서버(450)의 공개키를 결제 서버(440)로 요청한다, 동작 504에서, 결제 서버(440)는 저장하고 있던 공개키 중에서 등록하고자 하는 정보에 대응하는 발행사 서버(450)의 공개키를 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 최초 등록 시에는 동작 502에서 사용자 확인을 한 뒤에 생체 인증 과정(550)과 패스워드 인증 과정(560)을 수행하여 발행사 서버(450)에 생체 인증 정보 및 패스워드를 등록할 수 있다.
다양한 실시예들에 따르면, 동작 505에서, 결제 앱(420)은 발행사 서버(450)로 생체 검증 원본값을 요청하고, 동작 506에서, 결제 서버(440)는 이 요청을 발행사 서버(450)로 전달하며, 동작 507에서, 발행사 서버(450)는 무작위로 생체 검증 원본값을 생성하고, 생성한 생체 검증 원본값 및 생체 인증 검증을 위한 생체 인증 정보 등록 상태를 나타내는 등록 상태 파라미터를 결제 서버(440)로 전달하고, 동작 508에서, 결제 서버(440)는 전달받은 생체 검증 원본값 및 등록 상태 파라미터를 결제 앱(420)으로 전달할 수 있다. 생체 인증 정보는 발행사 서버(450)가 결제 앱(420)으로부터 수신한 생체 인증 공개키(예: cbioPUK)일 수 있다. 등록 상태 파라미터는 '참(true)'에 대응하는 값 또는 '거짓(false)'에 대응하는 값을 가질 수 있으며, '참'인 경우에는 생체 인증 정보가 등록 상태임을 나타내고, '거짓'인 경우에는 생체 인증 정보가 미등록 상태임을 나타낸다. 최초 등록의 경우, 아직 생체 인증 공개키가 등록되지 아니하였으므로 등록 상태 파라미터는 '거짓'의 값을 가질 수 있다.
다양한 실시예들에 따르면, 동작 509에서, 결제 앱(420)은 인증 모듈(433)에 오브젝트 기준값을 요청하고, 동작 510에서, 인증 모듈(433)은 결제 앱(420)으로 오브젝트 기준값을 생성하여 전달할 수 있다. 동작 511에서, 결제 앱(420)은 인증 모듈(433)로부터 전달받은 오브젝트 기준값을 생체 모듈(431)로 전달하고, 동작 512에서, 생체 모듈(431)은 오브젝트 기준값을 수신했음을 알려주는 응답을 결제 앱(420)으로 전달할 수 있다. 또한, 동작 513에서, 결제 앱(420)은 생체 모듈(431)에 보안 객체를 요청하고, 동작 514에서, 생체 모듈(431)은 사용자로부터 생체 정보를 획득하여 저장한 뒤, 결제 앱(420)으로 오브젝트 기준값을 인증 모듈(433)만이 복호화 할 수 있도록 암호화한 보안 객체를 전달할 수 있다.
다양한 실시예들에 따르면, 생체 인증을 위하여 동작 515에서, 결제 앱(420)은 인증 모듈(433)로 생체 인증 파라미터를 생성하기 위한 정보를 전달할 수 있다. 전달되는 정보는 인증 모듈(433)로부터 수신한 보안 객체, 발행사 서버(450)로부터 전달받은 생체 검증 원본값 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함하는 원본 데이터 및 발행사 서버(450)의 공개키를 포함할 수 있다. 앱 서명 해쉬값은 앱을 인식할 수 있도록 하는 앱 ID(identification)일 수 있다.
다양한 실시예들에 따르면, 인증 모듈(433)은 이전에 생성되어 있던 생체 인증 개인키/공개키 쌍이 없는 경우 생체 인증 개인키/공개키 쌍을 생성할 수 있다. 초기 등록의 경우, 생체 인증 개인키(예: cbioPRV)/공개키(예: cbioPUK) 쌍이 없으므로 새로운 생체 인증 개인키/공개키 쌍을 생성할 수 있다. 인증 모듈(433)은 보안 객체를 복호화 하여 추출한 오브젝트 기준값이 동작 510에서 결제 앱(420)으로 전달한 오브젝트 기준값과 동일한 지를 검증하여 생체 등록 또는 인증이 되었는 지를 확인할 수 있다. 오브젝트 기준값의 검증을 완료한 후, 인증 모듈(433)은 생체 인증 개인키로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터'를 생성하고 동작 516에서, 상기 제1 파라미터, 제2 파라미터 및 발행사 서버(450)에서 생체 인증 검증용으로 사용할 생체 인증 공개키(예: cbioPUK)를 제3 파라미터로 한 3개의 파라미터를 생체 인증 검증을 위한 파라미터로 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 패스워드(password) 인증을 위하여, 동작 517에서, 결제 앱(420)은 표시 장치(예: 도 1의 표시 장치(160))에 사용자가 패스워드를 입력하도록 하기 위한 보안 키패드를 표시하되, 동작 518에서, 결제 서버(440)로 매 숫자 입력 시마다 위치가 변경되어 전송하는 데이터에 대한 보안을 제공할 수 있는 숫자필터 키를 요청하고, 동작 519에서, 결제 서버(440)로부터 숫자필터 키를 수신하여 이를 기초로 보안 키패드를 표시할 수 있다. 동작 520에서, 결제 앱(420)은 사용자로부터 패스워드를 입력 받고, 인증 모듈(433)로 발행사 서버 공개키(예: sPUK)와 입력받은 패스워드를 전달하면서 암호화를 요청한다. 동작 521에서, 결제 앱(420)은 인증 모듈(433)로부터 암호문을 수신할 수 있다.
다양한 실시예들에 따르면, 패스워드 등록을 위하여 동작 523에서, 결제 앱(420)은 인증 모듈(433)로부터 받은 암호문을 결제 서버(440)로 전달할 수 있다. 동작 524에서, 결제 서버(440)는 암호문을 발행사 서버(450)로 전달하고, 동작 525에서, 패스워드가 등록되었음을 나타내는 응답을 발행사 서버(450)로부터 수신하고, 동작 526에서, 등록 응답을 결제 앱(420)으로 전달하여 패스워드 등록을 완료할 수 있다.
다양한 실시예들에 따르면, 생체 인증을 통한 결제 방법을 추가하기 위하여, 동작 527에서 결제 앱(420)은 동작 505 내지 516의 생체 인증 절차에서 획득한 생체 인증 파라미터를 포함하는 결제 방법 추가 요청을 결제 서버(440)로 전달할 수 있다. 동작 528에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 529에서, 발행사 서버(450)는 전달받은 생체 인증 파라미터를 이용하여 서명을 검증하고, 전달받은 생체 인증 파라미터 중의 하나인 생체 인증 공개키(예: cbioPUK)를 저장한다. 만약 생체 인증에 의한 서명 검증 진행과정에서 발행사 서버(450)의 응답 오류가 발생할 경우에는 처음부터 다시 등록 과정을 수행할 수 있다. 이후 동작 530에서, 발행사 서버(450)는 등록된 사용자를 인식하기 위한 사용자 ID(예: 사용자 계정, device ID, 결제를 위한 사용자별 등록 번호)를 결제 서버(440)로 전달한다 결제 서버(440)는 사용자 ID를 저장하고, 동작 531에서 등록이 완료되었음을 나타내는 응답을 결제 앱(420)으로 전달함으로써 새로운 결제 정보 및 사용자 인증 정보의 등록을 완료할 수 있다.
도 5에 도시된 절차에 따라 결제 정보 및 사용자 인증 정보를 등록한 이후 온라인 결제를 진행하는 절차에 대하여 설명한다.
도 6은 다양한 실시예들에 따른 온라인 결제를 진행하는 절차를 도시한 흐름도(600)이다.
다양한 실시예들에 따르면, 최초 사용 등록에 의하여 사용자 확인을 위한 생체 인증 정보 및 패스워드가 등록된 이후 온라인 결제는 생체 인증 과정(650) 또는 패스워드 인증 과정(660)을 이용하여 결제를 요청할 수 있거나 또는 생체 인증 과정(650)을 통한 결제 시도 후, 인증에 대한 검증이 실패한 경우에는 패스워드 인증 과정(660)에 의해 결제를 요청할 수 있다.
다양한 실시예들에 따르면, 동작 601에서, 온라인 상점에서 팝업한 발행사 결제 앱(660)은 발행사 서버(450)로 결제 코드를 요청하고, 동작 602에서, 결제 코드를 발행사 서버(450)로부터 수신할 수 있다. 동작 603에서, 발행사 결제 앱(660)은 결제 코드, 상품 정보, 상품 가격 등을 포함하는 결제 정보를 결제 앱(420)으로 전달하면서 결제를 요청할 수 있다. 동작 604에서, 결제 앱(420)은 결제 앱(420)을 통해 결제 정보의 등록 여부를 발행사 서버(450)와 통신하여 검증한다. 만약 등록되어 있지 않았다면 별도의 절차를 통해 등록을 진행할 수 있다. 등록이 되어 있는 경우에는 도 5에 도시된 절차에 따라 생체 인증에 의한 결제 방법이 등록된 경우에는 생체 인증을 이용하여 사용자 인증을 먼저 진행하고, 이후 조건에 따라 패스워드 인증을 이용하여 결제를 진행할 수 있다. 다만 사용자가 패스워드 인증을 선택하는 경우에는 생체 인증없이 패스워드 인증을 이용한 결제가 수행될 수도 있다.
다양한 실시예들에 따르면, 동작 605에서, 결제 앱(420)은 발행사 서버(450)로 생체 검증 원본값을 요청하고, 동작 606에서, 결제 서버(440)는 이 요청을 발행사 서버(450)로 전달하며, 동작 607에서, 발행사 서버(450)는 생체 검증 원본값을 생성하고, 생성한 생체 검증 원본값 및 생체 인증 검증을 위한 생체 인증 정보의 등록 상태를 나타내는 파라미터(이하 등록 상태 파라미터)를 결제 서버(440)로 전달하고, 동작 608에서, 결제 서버(440)는 전달받은 생체 검증 원본값 및 등록 상태 파라미터를 결제 앱(420)으로 전달한다.
다양한 실시예들에 따르면, 결제 앱(420)은 등록 상태 파라미터 값과 결제 앱(420)이 실행되는 전자 장치(101)에 생체 인증 정보가 저장된 상태에 따라 수행하는 절차가 다를 수 있다. 일 실시예로 전자 장치(101)에 생체 인증 정보가 저장된 상태이고 등록 상태 파라미터 값이 '거짓'을 나타내거나, 전자 장치(101)에 생체 인증 정보가 미 저장된 상태이고 등록 상태 파라미터 값이 '참'을 나타내어 전자 장치(101)와 발행사 서버(450)간에 생체 인증 정보의 등록 상태가 상이한 경우에는 패스워드 인증을 이용한 사용자 인증을 통해 결제를 진행하고, 결제가 완료된 후 등록 상태 파라미터 값을 '거짓'으로 설정하고, 전자 장치(101)의 생체 인증 정보의 저장 상태를 미 저장 상태로 설정하여 양쪽의 상태를 일치시키는 패스워드 인증을 통한 복구 절차를 수행할 수 있다.
일 실시예로 전자 장치(101)는 생체 인증 정보가 저장 상태이고 등록 상태 파라미터 값은 '참'인 정상적인 상태의 경우 도 6의 후술하는 절차에 따라 결제를 진행할 수 있다. 일 실시예로 전자 장치(101)는 생체 인증 정보가 미 저장 상태이고 등록 상태 파라미터 값도 '거짓'인 경우 도 6에 따라 후술하는 절차에 따라 결제를 진행하면서, 그 절차 중에 생체 인증 정보를 등록하도록 할 수 있다. 이에 의하면, 결제 진행과 생체 인증 정보 등록을 동시에 진행함으로써 사용자 편의를 도모할 수 있는 장점이 있다.
다양한 실시예들에 따르면, 결제 앱(420)이 전자 장치(101)와 발행사 서버(450)의 생체 인증 정보 저장 상태와 생체 인증 정보 등록 상태가 일치한다고 판단하면 동작 609에서, 결제 앱(420)은 인증 모듈(433)에 오브젝트 기준값을 요청하고, 동작 610에서, 인증 모듈(433)은 결제 앱(420)으로 오브젝트 기준값을 생성하여 전달할 수 있다. 동작 611에서, 결제 앱(420)은 인증 모듈(433)로부터 전달받은 오브젝트 기준값을 생체 모듈(431)로 전달하고, 동작 612에서, 생체 모듈(431)은 오브젝트 기준값을 수신했음을 알려주는 응답을 결제 앱(420)으로 전달할 수 있다. 또한, 동작 613에서, 결제 앱(420)은 생체 모듈(431)에 보안 객체를 요청하고, 동작 614에서, 생체 모듈(431)은 생체 인증 정보가 미저장 상태인 경우에는 생체 정보를 획득하여 저장하고, 생체 인증 정보가 저장 상태인 경우에는 저장되어 있는 생체 정보와 사용자로부터 획득한 생체 정보를 비교하여 생체 인증을 수행하고 그 결과에 따라, 결제 앱(420)으로 오브젝트 기준값을 인증 모듈(433)만이 복호화 할 수 있도록 암호화한 보안 객체를 전달할 수 있다.
다양한 실시예들에 따르면, 생체 인증을 위하여 동작 615에서, 결제 앱(420)은 인증 모듈(433)로 생체 인증 파라미터를 생성하기 위한 정보를 전달할 수 있다. 전달되는 정보는 인증 모듈(433)로부터 수신한 보안 객체, 발행사 서버(450)로부터 전달받은 생체 검증 원본값 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함하는 원본 데이터 및 발행사 서버(450)의 공개키를 포함할 수 있다.
다양한 실시예들에 따르면, 인증 모듈(433)은 생체 인증 정보가 미저장 상태인 경우, 즉 이전에 생성되어 있던 생체 인증 개인키/공개키 쌍이 없는 경우 생체 인증 개인키/공개키 쌍을 생성할 수 있다. 생체 인증 정보가 저장된 상태인 경우에는 새로운 생체 인증 개인키/공개키 쌍을 생성하지 않고, 기존에 저장되어 있던 개인키/공개키를 그대로 사용할 수 있다. 인증 모듈(433)은 보안 객체를 복호화 하여 추출한 오브젝트 기준값이 동작 610에서 결제 앱(420)으로 전달한 오브젝트 기준값과 동일한 지를 검증하여 생체 인증이 되었는 지를 확인할 수 있다. 오브젝트 기준값의 검증을 완료한 후, 인증 모듈(433)은 생체 인증 개인키로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터'를 생성하고 동작 616에서, 상기 제1 파라미터, 제2 파라미터 및 발행사 서버(450)에서 생체 인증 검증용으로 사용할 생체 인증 공개키(예: cbioPUK)를 제3 파라미터로 한 3개의 파라미터를 생체 인증 검증을 위한 파라미터로 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 동작 623에서 결제 앱(420)은 동작 605 내지 616의 생체 인증 절차에서 획득한 생체 인증 파라미터를 결제 서버(440)로 전달하면서 결제를 요청할 수 있다. 동작 624에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 625에서, 발행사 서버(450)는 전달받은 생체 인증 파라미터를 이용하여 서명을 검증한다. 만약 발행사 서버(450)가 생체 인증에 의한 서명 검증이 실패한 경우, 후술한 도 8에 도시된 것과 같은 패스워드 인증을 이용한 복구 절차를 수행하여 결제 및 생체 인증 정보에 대한 초기화를 수행할 수 있다. 발행사 서버(450)가 생체 인증에 의한 서명 검증이 성공한 경우에는 동작 626 및 동작 627에서, 성공했음을 나타내는 응답을 결제 서버(440)를 거쳐 결제 앱(420)으로 전달함으로써 최종 결제를 진행할 수 있다. 또한, 등록 상태 파라미터 값이 '거짓'으로 생체 인증 정보 미등록 상태를 나타내면 추가적으로 생체 인증 정보를 저장하고, 등록 상태 파라미터 값을 '참'으로 변경하여 생체 인증 정보 등록 상태로 만들 수 있다. 여기서 생체 인증 정보는 결제 앱(420)에서 전달한 생체 인증 공개키(예: cbioPUK)일 수 있다.
다양한 실시예들에 따르면, 동작 626 및 동작 627에서 생체 인증에 의한 서명 검증이 실패한 것으로 발행사 서버(450)가 응답하거나, 또는 발행사 서버(450) 및 결제 앱(420)의 생체 인증 정보 등록 상태가 상이하거나, 또는 사용자가 패스워드 인증을 이용한 결제를 진행하는 것으로 선택하는 경우에는 패스워드 인증을 통한 결제가 수행될 수 있다. 패스워드 인증을 통한 결제를 위하여, 동작 617에서, 결제 앱(420)은 표시 장치(예: 도 1의 표시 장치(160))에 키패드를 표시하고, 동작 618에서, 결제 서버(440)로 숫자필터 키를 요청하고, 동작 619에서, 결제 서버(440)로부터 숫자필터 키를 수신한다. 동작 620에서, 결제 앱(420)은 사용자로부터 패스워드를 입력 받고, 동작 621에서, 인증 모듈(433)로 발행사 서버 공개키(예: sPUK)와 입력받은 패스워드를 전달하면서 암호화를 요청할 수 있다. 동작 622에서, 결제 앱(420)은 인증 모듈(433)로부터 암호문을 수신할 수 있다.
다양한 실시예들에 따르면, 동작 623에서 결제 앱(420)은 수신한 암호문을 결제 서버(440)로 전달하면서 결제를 요청할 수 있다. 동작 624에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 625에서, 발행사 서버(450)는 전달받은 암호문을 이용하여 사용자 인증을 할 수 있다. 만약 발행사 서버(450)가 암호문을 기초로 한 인증이 실패한 경우, 결제가 진행되지 아니하며, 패스워드 인증 절차를 다시 수행할 수 있다. 발행사 서버(450)가 암호문에 기초한 인증이 성공한 경우 결제가 진행되고, 결제 완료 후 전자 장치(101) 및 발행사 서버(450)의 생체 인증 정보 저장/등록 상태를 미저장/미등록 상태로 변경하는 생체 인증 정보에 대한 초기화를 수행할 수 있다.
도 7은 다양한 실시예들에 따른 결제 관련 정보 및 사용자 인증 정보를 삭제하는 절차를 도시한 흐름도(700)이다.
다양한 실시예들에 따르면, 결제 정보 및 사용자 인증 정보를 삭제하는 절차는 생체 인증 과정(750) 또는 패스워드 인증 과정(760)을 이용하여 사용자 인증을 하거나 또는 생체 인증 과정(750)을 통한 사용자 인증 후, 인증에 대한 검증이 실패한 경우에 패스워드 인증 과정(760)에 의한 사용자 인증을 수행할 수 있다.
도 7을 참조하면, 동작 701에서, 결제 앱(420)은 사용자로부터 결제 정보 삭제 요청을 수신할 수 있다. 결제 정보 삭제 요청 시 결제 정보 및 사용자 인증 정보를 포함하는 관련 정보가 모두 삭제될 수 있다.
다양한 실시예들에 따르면, 동작 702에서, 결제 앱(420)은 발행사 서버(450)로 생체 검증 원본값을 요청하고, 동작 703에서, 결제 서버(440)는 이 요청을 발행사 서버(450)로 전달하며, 동작 704에서, 발행사 서버(450)는 생체 검증 원본값을 생성하고, 생성한 생체 검증 원본값 및 사용자 인증을 위한 생체 인증 공개키의 존재 여부를 나타내는 등록 상태 파라미터를 결제 서버(440)로 전달하고, 동작 705에서, 결제 서버(440)는 전달받은 생체 검증 원본값 및 등록 상태 파라미터를 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 상술한 결제 시와 마찬가지로 결제 정보 삭제 시에도 결제 앱(420)은 등록 상태 파라미터 값과 결제 앱(420)이 실행되는 전자 장치(101)에 생체 인증 정보가 저장된 상태에 따라 수행하는 절차가 다를 수 있다. 일 실시예로 전자 장치(101)에 생체 인증 정보가 저장된 상태이고 등록 상태 파라미터 값이 '거짓'을 나타내거나, 전자 장치(101)에 생체 인증 정보가 미 저장된 상태이고 등록 상태 파라미터 값이 '참'을 나타내어 전자 장치(101)와 발행사 서버(450)간에 생체 인증 정보의 등록 상태가 상이한 경우에는 패스워드 인증을 이용한 사용자 인증을 통해 결제 정보 삭제를 진행할 수 있다.
일 실시예로 전자 장치(101)는 생체 인증 정보가 저장 상태이고 등록 상태 파라미터 값은 '참'인 정상적인 상태의 경우 도 7의 후술하는 절차에 따라 결제 정보 삭제를 진행할 수 있다. 일 실시예로 전자 장치(101)는 생체 인증 정보가 미 저장 상태이고 등록 상태 파라미터 값도 '거짓'인 경우에도 도 7에 따라 후술하는 절차에 따라 결제 정보 삭제를 진행할 수 있다.
다양한 실시예들에 따르면, 결제 앱(420)이 전자 장치(101)와 발행사 서버(450)의 생체 인증 정보 등록 상태가 일치한다고 판단하면(등록 상태이든 미등록 상태이든 상관없이) 동작 706에서, 결제 앱(420)은 인증 모듈(433)에 오브젝트 기준값을 요청하고, 동작 707에서, 인증 모듈(433)은 결제 앱(420)으로 오브젝트 기준값을 생성하여 전달할 수 있다. 동작 708에서, 결제 앱(420)은 인증 모듈(433)로부터 전달받은 오브젝트 기준값을 생체 모듈(431)로 전달하고, 동작 709에서, 생체 모듈(431)은 오브젝트 기준값을 수신했음을 알려주는 응답을 결제 앱(420)으로 전달할 수 있다. 또한, 동작 710에서, 결제 앱(420)은 생체 모듈(431)에 보안 객체를 요청하고, 동작 711에서, 생체 모듈(431)은 생체 인증 정보가 미저장 상태인 경우에는 생체 정보를 획득하여 저장하고, 생체 인증 정보가 저장 상태인 경우에는 저장되어 있는 생체 정보와 사용자로부터 획득한 생체 정보를 비교하여 생체 인증을 수행하고 그 결과에 따라,, 결제 앱(420)으로 오브젝트 기준값을 인증 모듈(433)만이 복호화 할 수 있도록 암호화한 보안 객체를 전달할 수 있다.
다양한 실시예들에 따르면, 생체 인증을 위하여 동작 712에서, 결제 앱(420)은 인증 모듈(433)로 생체 인증 파라미터를 생성하기 위한 정보를 전달할 수 있다. 전달되는 정보는 인증 모듈(433)로부터 수신한 보안 객체, 발행사 서버(450)로부터 전달받은 생체 검증 원본값 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함하는 원본 데이터 및 발행사 서버(450)의 공개키를 포함할 수 있다. 앱 서명 해쉬값은 앱을 인식할 수 있도록 하는 앱 ID(identification)일 수 있다.
다양한 실시예들에 따르면, 인증 모듈(433)은 생체 인증 정보가 미저장 상태인 경우, 즉 이전에 생성되어 있던 생체 인증 개인키/공개키 쌍이 없는 경우 생체 인증 개인키/공개키 쌍을 생성할 수 있다. 생체 인증 정보가 등록된 상태인 경우에는 새로운 생체 인증 개인키/공개키 쌍을 생성하지 않고, 기존에 저장되어 있던 개인키/공개키를 그대로 사용할 수 있다. 인증 모듈(433)은 보안 객체를 복호화 하여 추출한 오브젝트 기준값이 동작 707에서 결제 앱(420)으로 전달한 오브젝트 기준값과 동일한 지를 검증하여 생체 인증이 되었는 지를 확인할 수 있다. 오브젝트 기준값의 검증을 완료한 후, 인증 모듈(433)은 생체 인증 개인키로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터'를 생성하고 동작 713에서, 상기 제1 파라미터, 제2 파라미터 및 발행사 서버(450)에서 생체 인증 검증용으로 사용할 생체 인증 공개키(예: cbioPUK)를 제3 파라미터로 한 3개의 파라미터를 생체 인증 검증을 위한 파라미터로 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 동작 720에서 결제 앱(420)은 동작 702 내지 713의 생체 인증 절차에서 획득한 생체 인증 파라미터를 결제 서버(440)로 전달하면서 결제 정보 삭제를 요청할 수 있다. 동작 721에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 722에서, 발행사 서버(450)는 전달받은 생체 인증 파라미터를 이용하여 서명을 검증한다. 만약 발행사 서버(450)가 생체 인증에 의한 서명 검증이 실패한 경우, 후술한 도 8에 도시된 것과 같은 패스워드 인증을 이용한 복구 절차를 수행하여 결제 및 생체 인증 정보에 대한 초기화를 수행할 수 있다. 발행사 서버(450)가 생체 인증에 의한 서명 검증이 성공한 경우에는 등록 상태 파라미터 값이 '거짓'으로 생체 인증 정보 미등록 상태를 나타내면 생체 인증 정보를 저장하고, 등록 상태 파라미터 값을 '참'으로 변경하여 생체 인증 정보 등록 상태로 만들 수 있다. 그리고 동작 723에서 생체 인증 정보를 삭제할 수 있다. 생체 인증 정보는 생체 인증 공개키(예: cbioPUK)를 포함할 수 있으며, 등록 상태 파라미터 값은 '거짓'으로 설정될 수 있다.
다양한 실시예들에 따르면, 발행사 서버(450)는 동작 724에서, 인증이 성공하였음을 나타내는 응답을 결제 서버(440)로 전달하고, 동작 725에서, 결제 서버(450)는 인증 성공 응답을 전달받고 결제 정보를 삭제할 수 있다. 동작 726에서, 결제 서버(450)는 인증 성공 응답을 결제 앱(420)로 전달하고, 동작 727에서, 결제 앱(420)은 인증 성공에 대한 응답으로 결제 정보를 삭제하라는 요청을 결제 모듈(433)로 전달할 수 있다. 동작 728에서, 결제 모듈(433)은 생체 인증 개인키(예: cbioPRV) 및 공개키(예: cbioPUK)를 포함하는 결제 관련 정보를 삭제할 수 있고, 동작 729에서, 결제 모듈(433)은 삭제 성공이라는 응답을 결제 앱(420)으로 전달할 수 있다. 동작 730에서, 결제 앱(420)은 결제 관련 정보를 삭제하고, 관련 발행사 서버(450)의 공개키(예: sPUK)를 삭제할 수 있다.
다양한 실시예들에 따르면, 동작 724 및 동작 726에서 생체 인증에 의한 서명 검증이 실패한 것으로 발행사 서버(450)가 응답하거나, 또는 발행사 서버(450) 및 결제 앱(420)의 생체 인증 정보 등록 상태가 상이하거나, 또는 사용자가 패스워드 인증을 이용한 결제 정보 삭제를 진행하는 것으로 선택하는 경우에는 패스워드 인증을 통한 결제 정보 삭제가 수행될 수 있다. 패스워드 인증을 통한 결제 정보 삭제를 위하여, 동작 714에서, 결제 앱(420)은 표시 장치(예: 도 1의 표시 장치(160))에 키패드를 표시하고, 동작 715에서, 결제 서버(440)로 숫자필터 키를 요청하고, 동작 716에서, 결제 서버(440)로부터 숫자필터 키를 수신한다. 동작 717에서, 결제 앱(420)은 사용자로부터 패스워드를 입력 받고, 동작 718에서, 인증 모듈(433)로 발행사 서버 공개키(예: sPUK)와 입력받은 패스워드를 전달하면서 암호화를 요청한다. 동작 719에서, 결제 앱(420)은 인증 모듈(433)로부터 암호문을 수신할 수 있다.
다양한 실시예들에 따르면, 동작 720에서 결제 앱(420)은 수신한 암호문을 결제 서버(440)로 전달하면서 결제 정보 삭제를 요청할 수 있다. 동작 721에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 722에서, 발행사 서버(450)는 전달받은 암호문을 이용하여 사용자 인증을 할 수 있다. 만약 발행사 서버(450)가 암호문을 기초로 한 인증이 실패한 경우, 결제가 진행되지 아니하며, 패스워드 인증 절차를 다시 수행할 수 있다. 발행사 서버(450)가 암호문에 기초한 인증이 성공한 경우 결제 관련 정보 삭제가 동작 723 내지 동작 730에 따라 진행될 수 있다.
다양한 실시예들에 따르면, 결제 앱(420)과 발행사 서버(450)간에 생체 인증 정보의 등록 상태가 상이한 경우, 또는 생체 인증을 이용한 결제 시에 생체 인증에 의한 검증이 실패한 경우에는 패스워드 인증을 이용한 사용자 인증을 통해 결제를 진행하고, 결제가 완료된 후 등록 상태 파라미터 값을 '거짓'으로 설정하고, 결제 앱(420)의 생체 인증을 미저장 상태로 설정하여 양쪽의 상태를 일치시키는 패스워드 인증을 통한 복구 절차를 수행할 수 있다.
도 8은 다양한 실시예들에 따른 생체 인증에 의한 검증 실패에 따른 패스워드 인증을 통한 복구 절차를 도시한 흐름도(800)이다.
도 8을 참조하면, 동작 801에서, 결제 앱(420)은 인터넷 상점 결제 앱(860)으로부터 결제 요청을 수신할 수 있다.
다양한 실시예들에 따르면, 동작 802에서, 결제 앱(420)은 발행사 서버(450)로 생체 검증 원본값을 요청하고, 동작 803에서, 결제 서버(440)는 이 요청을 발행사 서버(450)로 전달하며, 동작 804에서, 발행사 서버(450)는 생체 검증 원본값을 생성하고, 생성한 생체 검증 원본값 및 사용자 인증을 위한 생체 인증 공개키의 존재 여부를 나타내는 등록 상태 파라미터를 결제 서버(440)로 전달하고, 동작 805에서, 결제 서버(440)는 전달받은 생체 검증 원본값 및 등록 상태 파라미터를 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 동작 806에서 결제 앱(420)은 생체 인증을 진행할 수 있다. 결제 앱(420)은 도 5의 동작 509 내지 동작 516, 또는 도 6의 동작 609 내지 616, 또는 도 7의 동작 706 내지 동작 713에 따른 절차에 따라 생체 인증을 진행하여 생체 인증 파라미터를 생성할 수 있다.
다양한 실시예들에 따르면, 동작 807에서 결제 앱(420)은 생체 인증 절차에서 생성한 생체 인증 파라미터를 결제 서버(440)로 전달하면서 결제를 요청할 수 있다. 동작 808에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 809에서, 발행사 서버(450)는 전달받은 생체 인증 파라미터를 이용하여 서명을 검증하는데 서명 검증이 실패할 수 있다. 서명 검증이 실패하는 경우 패스워드 인증을 이용한 복구 절차를 수행하여 결제 및 생체 인증 정보에 대한 초기화를 수행할 수 있다.
다양한 실시예들에 따르면, 발행사 서버(450)가 생체 인증에 의한 서명 검증에 실패한 경우, 동작 810 및 동작 811에서, 발행사 서버(450)는 서명 검증에 실패하였음을 나타내는 응답을 결제 서버(440)로 전달하고, 결제 서버(440)는 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 생체 인증에 의한 서명 검증에 실패하였음을 나타내는 응답을 수신한 결제 앱(420)은 패스워드 인증을 통한 결제를 진행할 수 있다. 동작 812에서, 결제 앱(420)은 패스워드 인증을 수행할 수 있다. 패스워드 인증은 도 5의 동작 517 내지 동작 522, 또는 도 6의 동작 617 내지 동작 622, 또는 도 7의 동작 714 내지 동작 719에 따라 수행되고 패스워드를 암호화한 암호문을 생성할 수 있다.
다양한 실시예들에 따르면, 동작 813에서 결제 앱(420)은 암호문을 결제 서버(440)로 전달하면서 결제를 요청할 수 있다. 동작 814에서, 결제 서버(440)는 수신한 요청을 발행사 서버(450)로 전달할 수 있다. 동작 815에서, 발행사 서버(450)는 전달받은 암호문을 이용하여 사용자 인증을 하여 패스워드 인증에 성공하면 결제를 성공적으로 완료할 수 있다. 동작 816 및 동작 817에서, 발행사 서버(450)는 결제 성공이라는 응답을 결제 서버(440)로 전달하고, 결제 서버(440)는 결제 성공 응답을 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 결제 앱(420)은 자신의 생체 인증 정보 저장 상태를 미저장 상태로 변경하고, 동작 818에서, 결제 서버(440)로 발행사 서버(450)의 생체 인증 정보 등록 상태를 미등록 상태로 변경 요청을 전달할 수 있다. 생체 인증 정보 등록 상태를 미등록 상태로 변경 요청하는 것은 발행사 서버(450)에 등록되어 있는 결제 앱(420)의 생체 인증 공개키 삭제 요청일 수 있다. 동작 819에서, 결제 서버(440)는 상기 변경 요청을 발행사 서버(450)로 전달할 수 있다. 동작 820에서, 이 변경 요청을 전달받은 발행사 서버(450)는 결제 앱(420)에 대응하는 생체 인증 공개키를 삭제하고, 생체 인증 공개키의 등록 여부를 나타내는 등록 상태 파라미터를 '거짓'에 해당하는 값으로 변경할 수 있다. 동작 821에서, 발행사 서버(450)는 변경을 완료하였음을 나타내는 응답을 결제 서버(440)로 전달하고, 동작 822에서, 결제 서버(440)는 결제 앱(420)으로 변경 완료 응답을 전달할 수 있다. 변경 완료 응답을 수신한 결제 앱(420)은 동작 823에서, 인터넷 상점의 결제 앱(860)으로 결제가 완료되었음을 나타내는 응답을 전달할 수 있다.
이상에서 전체 시스템 관점에서 생체 인증을 이용한 결제 방법에 대하여 설명하였다. 이하에서는 전자 장치(101)의 관점에서 생체 인증을 이용한 결제 방법에 대하여 설명한다.
도 9는 다양한 실시예들에 따른, 전자 장치(101)의 결제 정보 및 사용자 인증 정보 등록 동작을 도시한 흐름도(900)이다. 도 9에 예시된 흐름도(900)의, 동작 주체는 전자 장치(예: 도 1의 전자 장치(101)) 또는 전자 장치(101)의 구성요소(예: 도 1의 프로세서(120), 도 4의 결제 앱(420), 생체 모듈(431) 및/또는 인증 모듈(433))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 901에서, 전자 장치(101)는 사용할 카드 또는 전화번호 소액 결제 등 결제 정보에 대한 정당한 사용자를 확인할 수 있다. 전자 장치(101)는 결제 서버(440)를 통해 발행사 서버(450)로 카드 정보, 소액 결제 정보 등의 결제 관련 정보 및 사용자 정보를 전달하고, 발행사 서버(450)로부터 승인 응답을 받음으로써 확인할 수 있다.
다양한 실시예들에 따르면, 동작 903에서, 전자 장치(101)는 발행사 서버(450)의 공개키(예: sPUK)를 획득할 수 있다. 발행사 서버(450)의 공개키는 발행사 서버(450)로부터 결제 서버(440)로 전달될 수 있다. 일 실시예에 따르면, 보안을 위하여 오프라인으로 발행사 서버(450)가 결제 서버(440)로 전달할 수 있다. 전자 장치(101)는 결제 정보 및 사용자 인증 정보 등록 시에 결제 서버(440)로 발행사 서버(450)의 공개키를 요청하여 전달받고 전달받은 발생사 서버(450)의 공개키를 메모리(예: 도 1의 메모리(130))에 저장할 수 있다. 발행사 서버(450)의 공개키는 발행사 서버(450)로 전달되는 메시지를 암호화하는데 사용할 수 있다.
다양한 실시예들에 따르면, 동작 905에서, 전자 장치(101)는 생체 인증을 수행할 수 있다. 전자 장치(101)는 생체 인증 정보의 저장 상태를 나타내는 파라미터를 저장하고 있을 수 있으며, 또한 전자 장치(101)는 발행사 서버(450)로부터 자신과 관련된 생체 인증 정보의 등록 상태를 나타내는 등록 상태 파라미터를 전달받아 발행사 서버에 자신과 관련된 생체 인증 정보가 등록되어 있는 지를 판단할 수 있다. 최초 등록 시 전자 장치(101)의 생체 인증 정보의 저장 상태 및 발행사 서버(450)의 생체 인증 정보의 등록 상태는 미저장/미등록 상태(파라미터가 '거짓'에 해당하는 값을 가짐에 대응)일 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 생체 인증 과정을 통해 발행사 서버(450)로 전달할 생체 인증 검증을 위한 파라미터를 생성할 수 있다. 생체 인증 검증을 위한 파라미터는 생체 인증 개인키(예: cbioPRV)로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터' 및 제3 파라미터인 생체 인증 공개키(예: cbioPUK)를 포함할 수 있다. 여기서 원본 데이터는 발행사 서버(450)로부터 수신한 생체 검증 원본값, 생체 모듈(431)에서 생성한 오브젝트 기준값을 암호화한 보안 객체 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 도 5의 동작 505 내지 동작 516, 또는 도 6의 동작 605 내지 616, 또는 도 7의 동작 703 내지 동작 713, 또는 후술할 도10의 동작에 따른 절차에 따라 생체 인증을 수행할 수 있다.
다양한 실시예들에 따르면, 동작 907에서, 전자 장치(101)는 패스워드 인증을 수행할 수 있다. 전자 장치(101)는 결제 시에 사용자 인증으로 사용할 패스워드를 발행사 서버(450)에 등록할 수 있다. 전자 장치(101)는 패스워드 인증을 통해 등록할 패스워드를 사용자로부터 입력받을 수 있고, 입력받은 패스워드를 발행사 서버(450)의 공개키(예: sPUK)를 이용하여 암호화할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 도 5의 동작 517 내지 동작 522, 또는 도 6의 동작 617 내지 동작 622, 또는 도 7의 동작 714 내지 동작 719, 또는 도 11의 동작에 따라 수행되고 패스워드를 암호화한 암호문을 생성할 수 있다.
다양한 실시예들에 따르면, 동작 909에서, 전자 장치(101)은 패스워드 인증을 통해 생성한 암호문을 발행사 서버(450)로 전달하여 패스워드를 등록할 수 있다.
다양한 실시예들에 따르면, 동작 911에서, 전자 장치(101)는 동작 905에서 생성한 생체 인증 검증을 위한 파라미터를 발행사 서버(450)로 전달하여 생체 인증 정보를 발행사 서버(450)에 저장할 수 있다. 생체 인증 정보는 전자 장치(101)의 생체 인증 공유키(예: cbioPUK)일 수 있다. 발행사 서버(450)는 생체 인증 검증을 위한 파라미터를 수신하고, 수신한 파라미터를 이용하여 인증을 수행하고 인증이 성공하는 경우 수신한 전자 장치(101)의 생체 인증 정보를 저장할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 발행사 서버(450)로부터 생체 인증 정보의 등록 성공 응답을 일정 시간 내에 수신하지 못하면 동작 905 내지 동작 911를 다시 수행하여 생체 인증 정보를 등록할 수 있다. 전자 장치(101)는 발행사 서버(450)로부터 생체 인증 정보의 등록 성공 응답을 일정 시간 내에 수신하면 정상적으로 결제 정보 등록 및 사용자 인증 정보가 등록되었다고 판단하고 등록 동작을 종료할 수 있다.
도 10은 다양한 실시예들에 따른 전자 장치(101)의 생체 인증 동작을 도시한 흐름도(1000)이다. 도 10에 예시된 흐름도(1000)는 도 9의 동작 905의 일 실시예로서, 동작 주체는 전자 장치(예: 도 1의 전자 장치(101)) 또는 전자 장치(101)의 구성요소(예: 도 1의 프로세서(120), 도 4의 결제 앱(420), 생체 모듈(431) 및/또는 인증 모듈(433)))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1001에서, 전자 장치(101)는 발행사 서버(450)로 생체 검증 원본값을 요청하여 발행사 서버(450)로부터 생체 검증 원본값 및 생체 인증 정보(생체 인증 공개키) 등록 상태를 획득할 수 있다. 생체 검증 원본값 및 생체 인증 정보 등록 상태를 나타내는 정보는 발행사 서버(450)로부터 결제 서버(440)를 통해 전자 장치(101)로 수신될 수 있다.
다양한 실시예들에 따르면, 동작 1003에서, 전자 장치(101)의 인증 모듈(433)은 오브젝트 기준값을 생성하고, 생체 모듈(431)로 전달할 수 있다. 이때 오브젝트 기준값은 결제 앱(420)의 제어에 의하여 인증 모듈(433)에서 생성되고, 결제 앱(420)을 거쳐 생체 모듈(431)로 전달될 수 있다.
다양한 실시예들에 따르면, 동작 1005에서, 전자 장치(101)의 생체 모듈(431)은 생체 인증을 수행하고, 그 결과를 바탕으로 보안 객체를 생성할 수 있다. 일 실시예에 따르면 생체 모듈(431)은 기존에 저장되어 있던 생체 정보와 사용자가 입력한 생체 정보가 일치하는 경우 생체 정보가 인증되었다고 판단하고, 일치되지 아니한 경우 생체 정보 인증이 실패하였다고 판단할 수 있다. 생체 모듈(431)은 생체 정보 인증이 실패하였다고 판단하는 경우 사용자에게 생체 정보 입력을 다시 요청하거나 인증 방식을 패스워드 인증으로 전환하도록 할 수 있다. 생체 모듈(431)은 생체 정보가 인증되었다고 판단한 경우, 결제 앱(420)을 통해 수신한 오브젝트 기준값을 인증 모듈(433)만이 복호화 할 수 있도록 암호화된 보안 객체를 생성하여 결제 앱(420)으로 전달할 수 있다.
다양한 실시예들에 따르면, 동작 1007에서, 전자 장치(101)는 생체 인증을 위해 발행사 서버(450)로 전달할 파라미터를 생성할 수 있다. 일 실시예에 따르면, 전자 장치(101)의 결제 앱(420)은 생체 인증이 되어 생체 모듈(431)로부터 전달받은 보안 객체, 발행사 서버(450)로부터 전달받은 생체 검증 원본값 및 앱 위변조 확인을 위한 앱 서명 해쉬값을 포함하는 원본 데이터를 생성하고, 인증 모듈(431)은 자체적으로 생체 인증 개인키(예: cbioPRV) 및 생체 인증 공개키(예: cbioPUK)를 생성하고, 또한 생체 인증 개인키(예: cbioPRV)로 원본 데이터를 서명한 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 '암호화된 원본 데이터'를 생성할 수 있다. 생체 인증 개인키 및 공개키는 매번 생성되는 것이 아니라 전자 장치(101)의 생체 인증 정보 저장 상태가 미저장 상태인 경우에만 생성하여 저장하고, 이후에는 저장된 생체 인증 개인키 및 공개키를 사용할 수 있다. 생체 인증을 위해 발행사 서버(450)로 전달할 파라미터는 '서명된 원본 데이터', '암호화된 원본 데이터' 및 생체 인증 공개키를 포함할 수 있다.
도 11은 다양한 실시예들에 따른 전자 장치(101)의 패스워드 인증 동작을 도시한 흐름도(1100)이다. 도 11에 예시된 흐름도(1100)는 도 9의 동작 907의 일 실시예로서, 동작 주체는 전자 장치(예: 도 1의 전자 장치(101)) 또는 전자 장치(101)의 구성요소(예: 도 4의 결제 앱(420) 및/또는 인증 모듈(433)))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1101에서, 전자 장치(101)는 표시 장치(예: 도 1의 표시 장치(160))에 키패드를 표시하여 사용자가 패스워드를 입력하도록 할 수 있다.
다양한 실시예들에 따르면, 동작 1103에서, 전자 장치(101)는 발행사 서버(450)로부터 키필터를 획득할 수 있다. 키필터는 사용자가 동일한 번호를 입력하더라도 키필터에 의하여 수정되어 발행사 서버(450)로 동일한 신호가 가지 않도록 하여 줄 수 있다.
다양한 실시예들에 따르면, 동작 1105에서, 전자 장치(101)는 사용자의 입력에 따라 패스워드를 획득할 수 있다.
다양한 실시예들에 따르면, 동작 1107에서, 전자 장치(101)의 인증 모듈(433)은 사용자가 입력한 패스워드를 발행자 서버의 공개키로 암호화한 암호문을 생성할 수 있다. 생성된 암호문은 상기 동작 909에 따라 발행사 서버(450)로 전달되어 패스워드가 등록될 수 있다.
도 12는 다양한 실시예들에 따른, 전자 장치(101)의 결제 동작을 도시한 흐름도(1200)이다. 도 12에 예시된 흐름도(700)의, 동작 주체는 전자 장치(예: 도 1의 전자 장치(101)) 또는 전자 장치(101)의 구성요소(예: 도 1의 프로세서(120), 도 4의 결제 앱(420), 생체 모듈(431) 및/또는 인증 모듈(433))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1201에서, 전자 장치(101)의 결제 앱(420)은 결제 요청을 수신할 수 있다. 결제 요청을 수신하면 전자 장치(101)는 동작 1203에서 생체 인증을 수행하여 발행사 서버(450)로 전달한 생체 인증 검증을 위한 파라미터를 생성할 수 있다. 전자 장치(101)는 도 10에 도시된 흐름도에 따라 생체 인증을 수행할 수 있다.
다양한 실시예들에 따르면, 동작 1205에서, 전자 장치(101)는 생체 인증 검증을 위한 파라미터를 발행사 서버(450)로 전달하여 생체 인증 검증을 요청할 수 있고, 동작 1207에서, 발행사 서버(450)로부터 검증 결과를 전달받아 검증 성공 여부를 판단할 수 있다. 일 실시예에 따라 검증이 성공하면 결제를 완료하고 종료할 수 있다. 일 실시예에 따라 검증이 실패한 것으로 판단되면, 동작 1209에서, 전자 장치(101)는 도 11의 흐름도에 따른 패스워드 인증으로 전환하여 사용자로부터 패스워드를 입력받아 패스워드를 암호화한 암호문을 생성할 수 있다.
다양한 실시예들에 따르면, 동작 1211에서, 전자 장치(101)는 암호문을 발행사 서버(450)로 전달하여 패스워드를 검증할 수 있다. 발행사 서버(450)는 저장되어 있는 전자 장치(101)의 패스워드와 암호문으로 전달받은 패스워드를 비교하여 일치하는 경우 패스워드가 검증되었다고 판단하고, 일치하지 않는 경우에는 패스워드가 검증되지 않았다고 판단하여 그 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 발행사 서버(450)로부터 전달받은 검증 결과로부터 패스워드가 검증되지 않은 경우에는 다시 패스워드 인증을 수행하여 패스워드 검증을 받고, 패스워드가 검증된 경우에는 동작 1213에서 생체 인증 정보를 초기화 할 수 있으며, 추가로 결제의 승인까지 가능할 수 있다. 다만, 결제의 승인 없이 생체 인증 정보만을 초기화 하고, 새로운 결제를 시도하면서 동시에 생체 인증 정보를 추가할 수도 있다.
다양한 실시예들에 따르면, 동작 1213에서, 전자 장치(101)는 생체 인증 정보를 초기화하기 위하여 자체 메모리(예: 도 1의 메모리(130))에 저장된 생체 인증 정보 저장 상태를 '거짓'으로 변환하고, 발행사 서버(450)로 생체 인증 정보를 초기화하라는 요청 메시지를 전송할 수 있다. 발행사 서버(450)는 이 요청 메시지를 수신하고 생체 인증 정보 등록 상태를 나타내는 등록 상태 파라미터를 '거짓'에 해당하는 값으로 변환할 수 있다.
도 13은 다양한 실시예들에 따른, 발행사 서버(450)의 결제 정보 및 사용자 인증 정보 등록 동작을 도시한 흐름도(1300)이다. 도 13에 예시된 흐름도(1300)의 동작 주체는 발행사 서버(예: 도 4의 발행사 서버(450)) 또는 발행사 서버(450)의 구성요소(예: 도 4의 SBA 서버(451))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1301에서, 발행사 서버(450)는 사용자 인증 정보의 등록을 위해, 전자 장치(101)로부터의 요청에 따라 생성한 생체 검증 원본값 및 전자 장치(101)의 해당 생체 인증 정보 등록 상태를 전송할 수 있다. 생체 인증 정보 등록 상태는 등록 상태 파라미터로 나타낼 수 있으며, 등록 상태 파라미터는 '참(true)'에 대응하는 값 또는 '거짓(false)'에 대응하는 값을 가질 수 있으며, '참'인 경우에는 생체 인증 정보가 등록 상태임을 나타내고, '거짓'인 경우에는 생체 인증 정보가 미등록 상태임을 나타낼 수 있다. 최초 등록인 경우 등록 상태 파라미터는 '거짓'에 해당하는 값을 가질 수 있다.
다양한 실시예들에 따르면, 동작 1303에서, 발행사 서버(450)는 전자 장치(101)로부터 자신의 공개키(예: sPUK)로 암호화된 패스워드를 포함하는 암호문을 수신하고, 동작 1305에서, 자신의 개인키(예: sPRV)를 이용하여 암호문으로부터 패스워드를 획득하고 저장할 수 있다.
다양한 실시예들에 따르면, 동작 1307에서, 발행사 서버(450)는 전자 장치(101)로부터 생체 인증 검증을 위한 파라미터를 전달받는다. 생체 인증 검증을 위한 파라미터는 전자 장치(101)의 생체 인증 개인키(예: cbioPRV)로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터' 및 제3 파라미터인 생체 인증 공개키(예: cbioPUK)를 포함할 수 있다. 여기서 원본 데이터는 발행사 서버(450)로부터 수신한 생체 검증 원본값, 생체 모듈(431)에서 생성한 오브젝트 기준값을 암호화한 보안 객체 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함할 수 있다.
다양한 실시예들에 따르면, 동작 1309에서, 발행사 서버(450)는 전달받은 파라미터를 이용하여 생체 인증을 검증한다. 생체 인증이 검증되는 경우, 동작 1311에서 생체 인증 정보를 등록할 수 있다. 생체 인증 정보는 전자 장치(101)의 해당 생체 인증 공개키(예: cbioPUK)일 수 있다. 생체 인증 정보의 등록이 완료되면 등록 동작이 완료될 수 있다.
도 14는 다양한 실시예들에 따른, 발행사 서버(450)의 결제시의 동작을 도시한 흐름도(1400)이다. 도 14에 예시된 흐름도(1400)의 동작 주체는 발행사 서버(예: 도 4의 발행사 서버(450)) 또는 발행사 서버(450)의 구성요소(예: 도 4의 SBA 서버(451))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1401에서, 발행사 서버(450)는 결제 진행을 위해, 전자 장치(101)로부터의 요청에 따라 생성한 생체 검증 원본값 및 전자 장치(101)의 해당 생체 인증 정보 등록 상태를 전송할 수 있다. 생체 인증 정보 등록 상태는 등록 상태 파라미터로 나타낼 수 있으며, 등록 상태 파라미터는 '참(true)'에 대응하는 값 또는 '거짓(false)'에 대응하는 값을 가질 수 있으며, '참'인 경우에는 생체 인증 정보가 등록 상태임을 나타내고, '거짓'인 경우에는 생체 인증 정보가 미등록 상태임을 나타낼 수 있다. 생체 인증 정보의 등록이 완료된 정상적인 상태인 경우 등록 상태 파라미터는 '참'에 대응하는 값을 가질 수 있다.
다양한 실시예들에 따르면, 동작 1403에서, 발행사 서버(450)는 전자 장치(101)로부터 생체 인증 검증을 위한 파라미터를 전달받을 수 있다. 생체 인증 검증을 위한 파라미터는 전자 장치(101)의 생체 인증 개인키(예: cbioPRV)로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터' 및 제3 파라미터인 생체 인증 공개키(예: cbioPUK)를 포함할 수 있다. 여기서 원본 데이터는 발행사 서버(450)로부터 수신한 생체 검증 원본값, 생체 모듈(431)에서 생성한 오브젝트 기준값을 암호화한 보안 객체 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함할 수 있다.
다양한 실시예들에 따르면, 동작 1405에서, 발행사 서버(450)는 전달받은 파라미터를 이용하여 생체 인증을 검증한다. 발행사 서버(450)는 생체 인증 검증을 위해 '암호화된 원본 데이터'를 자신의 개인키로 복호화 하여 앱 해쉬값 및 생체 검증 원본값을 검증하고, 제3 파라미터로 수신한 생체 인증 공개키를 저장하고 있는 전자 장치(101)의 해당 생체 인증 공개키와 비교하여 동일 여부를 확인하고, 생체 인증 공개키를 이용하여 '서명된 원본 데이터'의 서명을 검증함으로써 생체 인증을 검증할 수 있다.
다양한 실시예들에 따르면, 동작 1407에서, 발행사 서버(450)는 전자 장치(101)로부터 생체 인증 검증 결과를 전자 장치(101)로 전달하고, 생체 인증 검증이 성공하면 결제를 승인하여 완료하고, 생체 인증 검증이 실패하면, 전자 장치(101)로부터 암호화된 패스워드 수신을 대기할 수 있다.
다양한 실시예들에 따르면, 동작 1409에서 발행사 서버(450)는 생체 인증 검증 실패 시에 전자 장치(101)로부터 암호화된 패스워드를 수신하고, 동작 1411에서, 수신한 암호화된 패스워드를 발행사 서버(450)의 개인키를 이용하여 복호화하여 패스워드를 획득하고 저장되어 있던 전자 장치(101)에 대응하는 패스워드와 비교하여 패스워드를 검증할 수 있다. 패스워드 검증이 완료되면 결제 승인을 전자 장치(101)로 전달하여 결제를 완료할 수 있다.
다양한 실시예들에 따르면, 동작 1413에서 전자 장치(101)로부터 생체 인증 정보를 초기화하라는 요청 메시지를 수신하고, 생체 인증 정보 등록 상태를 나타내는 등록 상태 파라미터를 미등록 상태에 해당하는 '거짓'에 해당하는 값으로 변경하고 저장하고 있던 전자 장치(101)의 해당 생체 인증 공개키(예: cbioPUK)를 삭제할 수 있다.
다양한 실시예들에 따르면, 상술한 것처럼 결제 중에 생체 인증 검증이 실패하면, 동작 1409 내지 동작 1413에 따른 패스워드 인증을 통한 복구 절차에 따라 전자 장치(101) 및 발행사 서버(450)는 생체 인증 정보 저장/등록 상태를 미저장/미등록 상태로 초기화할 수 있다. 사용 등록 및 패스워드가 등록된 상태에서 생체 인증이 실패하여 전자 장치(101) 및 발행사 서버(450)의 생체 인증 정보 저장/등록 상태를 미저장/미등록 상태로 초기화된 경우, 본 발명에서 제시하는 방법에 따르면, 생체 인증 정보를 발행사 서버(450)에 등록하면서 결제를 진행할 수 있다.
도 15는 다양한 실시예들에 따른, 복구 절차에 의하여 생체 인증 정보가 초기화된 이후의 발행사 서버(450)의 결제시의 동작을 도시한 흐름도(1500)이다. 도 15에 예시된 흐름도(1500)의 동작 주체는 발행사 서버(예: 도 4의 발행사 서버(450)) 또는 발행사 서버(450)의 구성요소(예: 도 4의 SBA 서버(451))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1501에서, 발행사 서버(450)는 결제 진행을 위해, 전자 장치(101)로부터의 요청에 따라 생성한 생체 검증 원본값 및 전자 장치(101)의 해당 생체 인증 정보 등록 상태를 전송할 수 있다. 생체 인증 정보 등록 상태는 등록 상태 파라미터로 나타낼 수 있으며, 본 일 실시예의 경우 등록 상태 파라미터는 생체 인증 정보 등록 상태가 미등록 상태인 '거짓'에 해당하는 값을 가질 수 있다. 여기서 생체 인증 정보는 전자 장치(101)가 발행사 서버(450)로 전달한 생체 인증 공개키일 수 있다.
다양한 실시예들에 따르면, 동작 1503에서, 발행사 서버(450)는 전자 장치(101)로부터 생체 인증 검증을 위한 파라미터를 전달받을 수 있다. 생체 인증 검증을 위한 파라미터는 전자 장치(101)의 생체 인증 개인키(예: cbioPRV)로 원본 데이터를 서명한 제1 파라미터인 '서명된 원본 데이터', 원본 데이터를 발행사 서버(450)에서 제공한 공개키(예: sPUK)로 암호화한 제2 파라미터인 '암호화된 원본 데이터' 및 제3 파라미터인 생체 인증 공개키(예: cbioPUK)를 포함할 수 있다. 여기서 원본 데이터는 발행사 서버(450)로부터 수신한 생체 검증 원본값, 생체 모듈(431)에서 생성한 오브젝트 기준값을 암호화한 보안 객체 및 앱의 위변조 확인을 위한 앱 서명 해쉬값을 포함할 수 있다.
다양한 실시예들에 따르면, 동작 1505에서, 발행사 서버(450)는 전달받은 파라미터를 이용하여 생체 인증을 검증한다. 발행사 서버(450)는 생체 인증 검증을 위해 '암호화된 원본 데이터'를 자신의 개인키로 복호화 하여 앱 해쉬값 및 생체 검증 원본값을 검증하고, 제3 파라미터로 수신한 생체 인증 공개키를 이용하여 '서명된 원본 데이터'의 서명을 검증함으로써 생체 인증을 검증할 수 있다. 생체 인증이 검증된 경우에는 동작 1507에서 결제를 승인하여 결제를 완료하면서 생체 인증 정보를 등록할 수 있다.
도 16은 다양한 실시예들에 따른, 발행사 서버(450)의 생체 인증 검증 동작을 도시한 흐름도(1600)이다. 도 16에 예시된 흐름도(1600)의 동작 주체는 발행사 서버(예: 도 4의 발행사 서버(450)) 또는 발행사 서버(450)의 구성요소(예: 도 4의 SBA 서버(451))로 이해될 수 있다.
다양한 실시예들에 따르면, 동작 1601에서, 발행사 서버(450)는 전자 장치(101)로부터 수신한 생체 인증 검증을 위한 파라미터의 유효성을 확인할 수 있다. 파라미터의 유효성은 생체 인증 검증을 위한 파라미터에서 표준상 정의된 타입(type) 필드 또는 길이를 검증하여 유효성을 확인할 수 있다. 유효성이 확인되지 않으면 생체 인증 검증에 실패한 것으로 판단할 수 있다.
다양한 실시예들에 따르면, 동작 1603에서 발행사 서버(450)는 자신의 개인키로 '암호화된 원본 데이터'를 복호하여 '원본 데이터'를 획득할 수 있다. 원본 데이터 획득에 실패하면 생체 인증 검증에 실패한 것으로 판단할 수 있다.
다양한 실시예들에 따르면, 동작 1605에서, 발행사 서버(450)는 원본 데이터에 포함되어 있는 앱 서명 해쉬값이 정당한 앱에 대응하는 값인지 검증할 수 있다. 검증에 실패하면 생체 인증 검증에 실패한 것으로 판단할 수 있다.
다양한 실시예들에 따르면, 동작 1607에서, 발행사 서버(450)는 결제 시작 시에 전자 장치(101)의 요청에 의하 전자 장치(101)로 전송한 생체 검증 원본값과 원본 데이터에 포함되어 있는 생체 검증 원본값을 비교하여 일치하는 지 판단하고, 그리고 생체 검증 원본값 발행이후 미리 정해진 일정 시간이 지났는 지를 검증할 수 있다. 원본 데이터에 포함되어 있는 생체 검증 원본값과 전자 장치(101)로 발행한 생체 검증 원본값이 일치하지 않거나 또는 생체 검증 원본값 발행이후 일정 시간이 지났다면 생체 인증 검증에 실패한 것으로 판단할 수 있다.
다양한 실시예들에 따르면, 동작 1609에서, 발행사 서버(450)는 전자 장치(101)로부터 수신한 생체 인증 공개키가 이전에 등록되어 있던 전자 장치(101)의 해당 생체 인증 공개키와 동일한 지를 판단할 수 있다. 만약 등록 상태 파라미터가 생체 인증 정보가 미등록 상태인 '거짓'에 해당하는 값을 가진다면 동작 1609의 동일 여부 판단을 하지 않을 수 있다. 등록 상태 파라미터가 '참'에 해당하는 값을 가지고, 전자 장치(101)로부터 수신한 생체 인증 공개키가 이전에 등록되어 있던 전자 장치(101)의 해당 생체 인증 공개키와 동일하지 않다면 생체 인증 검증에 실패한 것으로 판단할 수 있다.
다양한 실시예들에 따르면, 동작 1611에서, 발행사 서버(450)는 전자 장치(101)로부터 수신한 생체 인증 공개키 또는 미리 등록되어 있던 생체 인증 공개키로 '서명된 원본 데이터'의 서명을 검증할 수 있다. 서명은 생체 인증 공개키를 이용하여 '서명된 원본 데이터'로부터 원본 데이터를 획득하고, 이 원본 데이터와 상술 '암호화된 원본 데이터'로부터 획득한 원본 데이터를 서로 비교하여 검증할 수 있다. 발행사 서버(450)는 서명 검증에 실패하면 생체 인증 검증에 실패한 것으로 판단하고, 서명 검증에 성공하면 생체 인증 검증에 성공한 것으로 판단할 수 있다.
상술 설명한 내용을 정리하면 다음과 같을 수 있다.
도 17은 다양한 실시예들에 따른 전자 장치(101)의 사용자 인증을 위한 동작을 간략하게 도시한 흐름도(1700)이다.
도 17을 참조하면, 전자 장치(101)는 동작 1701에서, 최초 사용 등록인 지를 판단할 수 있다. 이러한 판단은 사용자의 입력에 따라 판단할 수 있으며 또는 전자 장치(101) 내에 저장되어 있는 정보를 바탕으로 판단할 수도 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 최초 등록인 경우에는 동작 1703에서 생체 인증 검증을 위한 파라미터를 생성하고, 동작 1705에서, 사용자 인증으로 사용하기 위해 사용자가 입력한 패스워드를 암호화한 암호화된 패스워드를 생성할 수 있다. 전자 장치(101)는 발행사 서버(450)에 생체 인증 및 패스워드 인증을 통한 사용자 인증을 등록하기 위하여 동작 1707에서, 암호화된 패스워드를 발행사 서버(450)로 전송하고, 동작 1709에서 생체 인증 검증을 위한 파라미터를 발행사 서버(450)로 전송할 수 있다. 발행사 서버(450)는 암호화된 패스워드 및 생체 인증 검증을 위한 파라미터를 기초로 사용자 인증을 위한 패스워드 및 생체 인증 정보를 저장할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 최초 등록이 완료된 후에는 동작 1711에서, 생체 인증 또는 패스워드 인증을 이용하여 결제를 위한 사용자 인증을 수행할 수 있다. 특히 발행사 서버(450)에 등록된 생체 인증 정보에 대한 변경이 필요한 경우에는 동작 1711에서 결제를 수행하는 중에 함께 새로운 생체 인증 정보를 발행사 서버(450)에 등록할 수 있다.
도 18은 다양한 실시예들에 따른 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태에 따른 결제 시의 인증 절차를 도시한 흐름도(1800)이다. 도 18에 예시된 흐름도(1800)는 도 17의 동작 1711의 일 실시예로서, 동작 주체는 전자 장치(예: 도 1의 전자 장치(101)) 또는 전자 장치(101)의 구성요소(예: 도 1의 프로세서(120), 도 4의 결제 앱(420), 생체 모듈(431) 및/또는 인증 모듈(433)))로 이해될 수 있다.
도 18을 참조하면, 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 4가지의 상태를 가질 수 있으며 전자 장치(101)의 이 상태에 따라 사용자 인증을 위하여 생체 인증을 사용할 것인지 패스워드 인증을 사용할 것인지를 결정할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태가 미저장/미등록 상태이면, 동작 1803에서, 전자 장치(101)는 결제를 위하여 생체 인증을 이용하고, 동작 1805에서, 발행자 서버(450)에 의한 검증이 성공하면, 결제는 승인되고 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 저장/등록 상태로 변환될 수 있다. 이때 발행자 서버(450)는 생체 인증 검증을 위해 전자 장치(101)로부터 수신한 생체 인증 공개키를 생체 인증 정보로 등록할 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태가 미저장/등록 상태이면, 동작 1813에서, 전자 장치(101)는 결제를 위하여 패스워드 인증을 이용하고, 동작 1815에서, 발행자 서버(450)에 의한 검증이 성공하면, 결제는 승인되고 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 미저장/미등록 상태로 초기화되고, 다음 번 결제시에 상술한 동작 1803 내지 1807에 의한 결제가 진행될 때 새로운 생체 인증 정보가 발행자 서버(450)에 저장될 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태가 저장/미등록 상태이면, 동작 1823에서, 전자 장치(101)는 결제를 위하여 패스워드 인증을 이용하고, 동작 1825에서, 발행자 서버(450)에 의한 검증이 성공하면, 결제는 승인되고 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 미저장/미등록 상태로 초기화되고, 다음 번 결제시에 상술한 동작 1803 내지 1807에 의한 결제가 진행될 때 새로운 생체 인증 정보가 발행자 서버(450)에 저장될 수 있다.
다양한 실시예들에 따르면, 전자 장치(101)는 전자 장치(101)의 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태가 저장/등록 상태이면, 동작 1833에서, 전자 장치(101)는 결제를 위하여 생체 인증을 이용하고, 동작 1835에서, 발행자 서버(450)에 의한 검증이 실패하면, 동작 1837에서, 패스워드 인증으로 전환하고, 동작 1839에서, 발행자 서버(450)에 의한 검증이 성공하면, 결제는 승인되고 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 미저장/미등록 상태로 초기화되고, 다음 번 결제시에 상술한 동작 1803 내지 1807에 의한 결제가 진행될 때 새로운 생체 인증 정보가 발행자 서버(450)에 저장될 수 있다. 다만 동작 1835에서, 발행자 서버(450)에 의한 검증이 성공한다면, 결제는 승인되고 생체 인증 정보 저장 상태 및 발행자 서버(450)의 생체 인증 정보 등록 상태는 저장/등록 상태로 그대로 있게 된다.
도 19a 내지 19f는 다양한 실시예들에 따른 도 14에 따른 결제 시에 생체 인증 검증이 실패하여 패스워드 인증을 통한 복구 절차를 진행하는 경우의 표시장치에 표시되는 일 실시예를 도시한 도면이다.
도 19a는 인터넷 상점의 결제 앱(860)의 일 예를 도시한 것으로 인터넷 상점의 결제 앱(860)에서 사용자가 본원 발명에서 제시하는 결제 앱(420) (예: 삼성페이)을 사용할 것을 선택할 수 있다. 그러면 전자 장치(101)의 결제 앱(420)은 생체 인증 결제를 시도하고, 도 19b는 생체 인증 결제를 시도하고 있는 것을 표시한다. 발행자 서버(450)로부터 생체 인증 검증에 실패하였다는 결과를 수신하면, 전자 장치(101)는 도 19c에 도시된 바처럼 생체 데이터를 인증할 수 없음을 표시하고, 패스워드를 이용한 결제를 시도할 것을 알려줄 수 있다. 사용자가 패스워드 인증 시도를 선택하면, 전자 장치(101)는 패스워드 인증 결제로 전환하고 도 19d에 도시된 바처럼 패스워드를 입력할 수 있는 키패드를 화면에 도시한다. 전자 장치(101)는 사용자가 입력한 패스워드를 암호화하여 발행자 서버(450)로 전송하고, 발행자 서버(450)로부터 인증 성공이라는 결과를 수신하면 도 19e에 도시된 바와 같이 인증 성공을 표시하고, 도 19f에 도시된 바와 같이 최종 휴대폰 결제를 진행하여 완료할 수 있다.
상술한 일 실시예에서와 같이 생체 인증 결제를 시도하여 실패하고, 패스워드 인증 결제에 성공한 경우 비록 화면상에는 도시되지 않지만 전자 장치(101) 및 발행자 서버(450)는 각각이 설정하고 있던 생체 인증 정보 저장/등록 상태를 미저장/미등록 상태로 변경할 수 있다.
그리고 전자 장치(101) 및 발행자 서버(450)의 생체 인증 정보 저장/등록 상태가 미저장/미등록 상태인 경우에는 다음 생체 인증 결제 시도 시에 생체 인증 정보도 등록될 수 있기 때문에 별도의 등록을 요구하는 기존의 방식보다 훨씬 간편하고 사용성을 높일 수 있다.
다양한 실시예들에 따르면, 전자 장치(예: 전자 장치(101))의 동작 방법은 최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하는 동작, 결제 시에 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작 및 상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 서버에 등록하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 결제 시에 상기 생체 인증 및 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작은 상기 서버로 생체 검증 원본값을 요청하는 동작, 상기 요청에 대한 응답으로, 상기 서버로부터, 생체 검증 원본값 및 생체 인증 정보 등록 상태를 나타내는 정보를 수신하는 동작 및 상기 수신한 생체 인증 정보 등록 상태를 나타내는 정보 및 메모리에 저장된 생체 인증 정보 저장 상태를 나타내는 정보를 기초로 생체 인증 및/또는 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 서버의 생체 인증 정보 등록 상태 및 메모리에 저장된 생체 인증 정보 저장 상태를 기초로 사용자 인증을 수행하도록 결정하는 동작은 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작 및 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 사용자 인증 완료 후에 상기 생체 인증 정보 저장 상태를 미저장 상태로 변환하는 동작을 더 포함하고, 상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 사용자 인증 완료 후에 상기 서버로, 상기 생체 인증 정보 등록 상태를 미등록 상태로 변환하도록 요청하는 동작을 더 포함할 수 있다.
다양한 실시예들에 따르면, 상기 결제 시에 상기 생체 인증 및 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작은, 상기 서버로 생체 인증 검증을 위한 파라미터를 전송하는 동작, 상기 서버로부터 생체 인증 검증 결과를 수신하는 동작, 상기 수신한 검증 결과가 검증 실패인 경우 패스워드 인증 검증을 위한 암호화된 패스워드를 상기 서버로 전송하는 동작, 상기 서버로부터 패스워드 검증 결과를 수신하는 동작, 상기 수신한 검증 결과가 검증 성공인 경우 상기 생체 인증 정보 저장 상태를 나타내는 정보를 미저장 상태로 변환하고, 상기 서버로 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 요청하는 동작을 더 포함할 수 있다.
다양한 실시예들에 따르면, 서버(예: 발행사 서버(450))의 동작 방법은 최초 사용 등록 시에, 전자 장치로부터 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 수신하는 동작, 상기 암호화된 패스워드를 복호하여 패스워드를 메모리에 저장하는 동작, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함하고 결제 시에, 수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하는 동작 및 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하는 동작 중 적어도 하나의 동작을 포함하고 상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 방법은 결제 시에 상기 전자 장치로부터 생체 검증 원본값에 대한 요청을 수신하는 동작, 상기 요청에 대한 응답으로, 상기 전자 장치로, 생체 검증 원본값 및 상기 생체 인증 정보 등록 상태를 나타내는 정보를 전송하는 동작, 상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하는 동작, 상기 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하는 동작, 생체 인증 검증 결과를 상기 전자 장치로 전송하는 동작, 상기 생체 인증 검증 결과가 검증 실패인 경우, 암호화된 패스워드를 상기 전자 장치로부터 수신하는 동작, 상기 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하는 동작, 패스워드 검증 결과를 상기 전자 장치로 전송하는 동작, 상기 검증 결과가 검증 성공인 경우, 상기 전자 장치로부터 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 하는 요청을 수신하는 동작 및 상기 요청에 따라, 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하는 동작은 상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하는 동작, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하는 동작 및 상기 검증 결과가 성공인 경우, 상기 생체 인증 검증을 위한 파라미터로부터 획득한 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함할 수 있다.
다양한 실시예들에 따르면, 상기 생체 인증을 검증하는 동작은 상기 생체 인증 검증을 위한 파라미터의 유효성을 확인하는 동작, 상기 생체 인증 검증을 위한 파라미터에 포함된 암호화된 원본 데이터를 상기 서버의 개인키로 복호화하여 원본 데이터를 획득하는 동작, 상기 복호된 원본 데이터에 포함되어 있는 해쉬값을 이용하여 정당한 결제 앱이 사용되었는 지를 확인하는 동작, 상기 복호된 원본 데이터에 포함되어 있는 생체 검증 원본값과 상기 생체 검증 원본값이 동일한 지 확인하는 동작, 상기 생체 검증 원본값을 발행한 이후 일정 시간이 지났는 지를 확인하는 동작, 상기 저장된 생체 인증 정보 및 상기 생체 인증 검증을 위한 파라미터에 포함된 상기 생체 인증 공개키가 동일한 지 확인하는 동작 및 상기 서명된 원본 데이터의 서명을 검증하는 동작을 포함할 수 있다.
본 문서에 개시된 다양한 실시예들에 따른 전자 장치는 다양한 형태의 장치가 될 수 있다. 전자 장치는, 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치는 전술한 기기들에 한정되지 않는다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나",“A 또는 B 중 적어도 하나”, "A, B 또는 C", "A, B 및 C 중 적어도 하나” 및 “A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제1) 구성요소가 다른(예: 제2) 구성요소에, “기능적으로” 또는 “통신적으로”라는 용어와 함께 또는 이런 용어 없이, “커플드” 또는 “커넥티드”라고 언급된 경우, 그것은 어떤 구성요소가 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시예들은 기기(machine)(예: 전자 장치(101)) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(136) 또는 외장 메모리(138))에 저장된 적어도 하나의 명령어들을 포함하는 소프트웨어(예: 프로그램(140))로서 구현될 수 있다. 예를 들면, 기기(예: 전자 장치(101))의 프로세서(예: 프로세서(120))는, 저장 매체로부터 저장된 적어도 하나의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 적어도 하나의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일 실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: CD-ROM(compact disc read only memory))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두개의 사용자 장치들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 적어도 하나의 구성요소들 또는 동작들이 생략되거나, 또는 적어도 하나의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 복수의 구성요소들 각각의 구성요소의 적어도 하나의 기능들을 통합 이전에 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱(heuristic)하게 실행되거나, 동작들 중 적어도 하나가 다른 순서로 실행되거나, 생략되거나, 또는 적어도 하나의 다른 동작들이 추가될 수 있다.

Claims (15)

  1. 전자 장치에 있어서,
    서버와 통신을 제공하도록 구성된 통신 모듈;
    상기 통신 모듈과 작동적으로 연결된 프로세서; 및
    상기 프로세서와 작동적으로 연결되고, 생체 정보를 저장하도록 구성된 메모리를 포함하고,
    상기 메모리는, 실행 시에, 상기 프로세서가,
    최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하고,
    결제 시에 사용자 인증을 위해 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하고,
    상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 상기 서버에 등록하도록 하는 인스트럭션들을 저장하는, 전자 장치.
  2. 제1항에 있어서,
    상기 메모리는 생체 인증 정보 저장 상태를 나타내는 정보를 저장하고,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 서버로 생체 검증 원본값을 요청하고,
    상기 요청에 대한 응답으로, 상기 서버로부터, 상기 생체 검증 원본값 및 상기 생체 인증 정보 등록 상태를 나타내는 정보를 수신하고,
    상기 수신한 생체 인증 정보 등록 상태를 나타내는 정보 및 상기 생체 인증 정보 저장 상태를 나타내는 정보를 기초로 생체 인증 및/또는 패스워드 인증을 이용하여 사용자 인증을 수행하는, 전자 장치.
  3. 제2항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하고,
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하고,
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하고, 상기 사용자 인증을 수행 완료 후에 상기 생체 인증 정보 저장 상태를 미저장 상태로 변환하고,
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하고, 상기 사용자 인증을 수행 완료 후에 상기 서버로, 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 요청하도록 하는, 전자 장치.
  4. 제2항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 서버로 생체 인증 검증을 위한 파라미터를 전송하고,
    상기 서버로부터 생체 인증 검증 결과를 수신하고,
    상기 수신한 검증 결과가 검증 실패인 경우 패스워드 인증 검증을 위한 암호화된 패스워드를 상기 서버로 전송하고,
    상기 서버로부터 패스워드 검증 결과를 수신하고,
    상기 수신한 검증 결과가 검증 성공인 경우 상기 생체 인증 정보 저장 상태를 나타내는 정보를 미저장 상태로 변환하고, 상기 서버로 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 요청하도록 하는, 전자 장치.
  5. 제2항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    오브젝트 기준값을 생성하고,
    상기 오브젝트 기준값을 암호화한 보안 객체(secure object)를 생성하고,
    상기 생체 검증 원본값, 상기 보안 객체 및 결제에 사용하는 앱을 나타내는 해쉬값을 포함하는 원본 데이터를 생성하고,
    상기 원본 데이터를 기초로 상기 생체 인증 검증을 위한 파라미터를 생성하도록 하는, 전자 장치.
  6. 서버에 있어서,
    전자 장치와 통신을 제공하도록 구성된 통신 모듈;
    상기 통신 모듈과 작동적으로 연결된 프로세서; 및
    상기 프로세서와 작동적으로 연결되고, 생체 인증 정보를 저장하도록 구성된 메모리를 포함하고,
    상기 메모리는, 실행 시에, 상기 프로세서가,
    최초 사용 등록 시에 상기 전자 장치로부터 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 수신하고, 상기 암호화된 패스워드를 복호화하여 패스워드를 상기 메모리에 저장하고, 상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하고,
    상기 생체 인증을 이용한 결제 시에, 수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하고,
    상기 패스워드 인증을 이용한 결제 시에, 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하고,
    상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하도록 하는 인스트럭션들을 저장하는, 서버.
  7. 제6항에 있어서,
    상기 메모리는 생체 인증 정보 등록 상태를 나타내는 정보를 저장하고,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 전자 장치로부터 생체 검증 원본값에 대한 요청을 수신하고,
    상기 요청에 대한 응답으로, 상기 전자 장치로, 상기 생체 검증 원본값 및 상기 생체 인증 정보 등록 상태를 나타내는 정보를 전송하는, 서버.
  8. 제7항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하고,
    상기 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하고,
    상기 생체 인증 검증 결과를 상기 전자 장치로 전송하고,
    상기 생체 인증 검증 결과가 검증 실패인 경우 상기 암호화된 패스워드를 상기 전자 장치로부터 수신하고,
    상기 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하고,
    상기 패스워드 검증 결과를 상기 전자 장치로 전송하고,
    상기 패스워드 검증 결과가 검증 성공인 경우 상기 전자 장치로부터 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 하는 요청을 수신하고,
    상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하는, 서버.
  9. 제7항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가, 결제 시에
    상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하고,
    상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고,
    상기 검증 결과 성공인 경우, 상기 생체 인증 검증을 위한 파라미터로부터 획득한 생체 인증 정보를 상기 메모리에 저장하여 등록하고,
    상기 전자 장치로 상기 검증 결과를 전송하는, 서버.
  10. 제7항에 있어서,
    상기 인스트럭션들은, 상기 프로세서가,
    상기 생체 인증 검증을 위한 파라미터의 유효성을 확인하고,
    상기 암호화된 원본 데이터를 상기 서버의 개인키로 복호화하여 원본 데이터를 획득하고,
    상기 복호된 원본 데이터에 포함되어 있는 결제에 사용하는 앱을 나타내는 해쉬값을 이용하여 결제에 사용한 앱이 정당한지를 확인하고,
    상기 복호된 원본 데이터에 포함되어 있는 생체 검증 원본값과 상기 생체 검증 원본값이 동일한 지 판단하고,
    상기 생체 검증 원본값을 발행한 이후 일정 시간이 지났는 지를 판단하고,
    상기 저장된 생체 인증 정보 및 상기 생체 인증 검증을 위한 파라미터에 포함된 상기 생체 인증 공개키가 동일한 지 확인하고,
    상기 서명된 원본 데이터의 서명을 검증하여, 상기 생체 인증 검증을 수행하는, 서버.
  11. 전자 장치의 동작 방법에 있어서,
    최초 사용 등록 시에 생체 인증 검증을 위한 생체 인증 정보 및 패스워드 인증을 위한 패스워드를 상기 서버에 등록하기 위해 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 생성하여 상기 서버로 전송하는 동작;
    결제 시에 상기 생체 인증 또는 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작; 및
    상기 서버에 등록된 생체 인증 정보에 대한 변경이 필요한 경우, 결제를 수행하는 중에 새로운 생체 인증 정보를 서버에 등록하는 동작을 포함하는, 방법.
  12. 제11항에 있어서,
    상기 결제 시에 상기 생체 인증 및 상기 패스워드 인증 중 적어도 하나를 이용하여 사용자 인증을 수행하는 동작은,
    상기 서버로 생체 검증 원본값을 요청하는 동작;
    상기 요청에 대한 응답으로, 상기 서버로부터, 생체 검증 원본값 및 생체 인증 정보 등록 상태를 나타내는 정보를 수신하는 동작; 및
    상기 수신한 생체 인증 정보 등록 상태를 나타내는 정보 및 메모리에 저장된 생체 인증 정보 저장 상태를 나타내는 정보를 기초로 생체 인증 및/또는 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작을 포함하는, 방법.
  13. 제12항에 있어서,
    상기 서버의 생체 인증 정보 등록 상태 및 메모리에 저장된 생체 인증 정보 저장 상태를 기초로 사용자 인증을 수행하도록 결정하는 동작은,
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작;
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 생체 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작;
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 미등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작; 및
    상기 서버로부터 수신한 생체 인증 정보 등록 상태를 나타내는 정보가 등록 상태이고 상기 생체 인증 정보 저장 상태를 나타내는 정보가 미저장 상태인 경우 패스워드 인증을 이용하여 사용자 인증을 수행하도록 결정하는 동작을 포함하는, 방법.
  14. 서버의 동작 방법에 있어서,
    최초 사용 등록 시에,
    전자 장치로부터 생체 인증 검증을 위한 파라미터 및 패스워드 인증 검증을 위한 암호화된 패스워드를 수신하는 동작;
    상기 암호화된 패스워드를 복호화하여 패스워드를 메모리에 저장하는 동작; 및
    상기 생체 인증 검증을 위한 파라미터를 기초로 생체 인증을 검증하고 획득한 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함하고,
    결제 시에,
    수신한 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하는 동작 및 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하는 동작 중 적어도 하나의 동작을 포함하고,
    상기 생체 인증 정보에 대한 새로운 등록이 필요한 경우, 생체 인증을 이용한 결제를 수행하는 중에 등록한 새로운 생체 인증 정보를 상기 메모리에 저장하는 동작을 포함하는, 방법.
  15. 제14항에 있어서, 결제 시에
    상기 전자 장치로부터 생체 검증 원본값에 대한 요청을 수신하는 동작;
    상기 요청에 대한 응답으로, 상기 전자 장치로, 생체 검증 원본값 및 상기 생체 인증 정보 등록 상태를 나타내는 정보를 전송하는 동작;
    상기 전자 장치로부터 생체 인증 검증을 위한 파라미터를 수신하는 동작;
    상기 생체 인증 검증을 위한 파라미터 및 상기 저장된 생체 인증 정보를 기초로 생체 인증을 검증하는 동작;
    생체 인증 검증 결과를 상기 전자 장치로 전송하는 동작;
    상기 생체 인증 검증 결과가 검증 실패인 경우,
    암호화된 패스워드를 상기 전자 장치로부터 수신하는 동작;
    상기 수신한 암호화된 패스워드로부터 획득한 패스워드 및 상기 메모리에 저장된 패스워드를 비교하여 패스워드 인증을 검증하는 동작;
    패스워드 검증 결과를 상기 전자 장치로 전송하는 동작,
    상기 검증 결과가 검증 성공인 경우,
    상기 전자 장치로부터 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하도록 하는 요청을 수신하는 동작; 및
    상기 요청에 따라, 상기 생체 인증 정보 등록 상태를 나타내는 정보를 미등록 상태로 변환하는 동작을 포함하는, 방법.
PCT/KR2019/014750 2018-11-02 2019-11-01 생체 인증을 이용한 결제 방법 및 그 전자 장치 WO2020091525A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/290,579 US20220005046A1 (en) 2018-11-02 2019-11-01 Payment method using biometric authentication and electronic device therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020180133898A KR102616421B1 (ko) 2018-11-02 2018-11-02 생체 인증을 이용한 결제 방법 및 그 전자 장치
KR10-2018-0133898 2018-11-02

Publications (1)

Publication Number Publication Date
WO2020091525A1 true WO2020091525A1 (ko) 2020-05-07

Family

ID=70464325

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/014750 WO2020091525A1 (ko) 2018-11-02 2019-11-01 생체 인증을 이용한 결제 방법 및 그 전자 장치

Country Status (3)

Country Link
US (1) US20220005046A1 (ko)
KR (1) KR102616421B1 (ko)
WO (1) WO2020091525A1 (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9022286B2 (en) 2013-03-15 2015-05-05 Virtual Electric, Inc. Multi-functional credit card type portable electronic device
US11593467B2 (en) * 2019-11-19 2023-02-28 Red Hat, Inc. Systems and methods for biometric authorization using a main screen and a visual indicator
CN111401901B (zh) * 2020-03-23 2021-06-04 腾讯科技（深圳）有限公司 生物支付设备的认证方法、装置、计算机设备和存储介质
JP7351873B2 (ja) * 2021-06-18 2023-09-27 ヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム
CN115001817B (zh) * 2022-06-01 2023-09-26 支付宝(杭州)信息技术有限公司 一种离线的身份识别方法、装置及设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003050783A (ja) * 2001-05-30 2003-02-21 Fujitsu Ltd 複合認証システム
JP2007052598A (ja) * 2005-08-17 2007-03-01 Oki Electric Ind Co Ltd 自動取引システム
WO2015066330A1 (en) * 2013-11-04 2015-05-07 Qualcomm Incorporated User authentication biometrics in mobile devices
KR20170019822A (ko) * 2015-08-12 2017-02-22 삼성전자주식회사 인증 처리 방법 및 이를 지원하는 전자 장치
KR101773074B1 (ko) * 2016-04-19 2017-08-31 주식회사 코인플러그 거래를 지원하기 위한 방법 및 이를 사용한 인증 지원 서버

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105745669A (zh) * 2013-11-04 2016-07-06 高通股份有限公司 移动装置中的用户验证生物计量技术
KR102422372B1 (ko) * 2014-08-29 2022-07-19 삼성전자 주식회사 생체 정보와 상황 정보를 이용한 인증 방법 및 장치
JP6682816B2 (ja) * 2015-11-16 2020-04-15 富士通株式会社 秘匿情報記憶方法、情報処理端末、及び秘匿情報記憶プログラム
KR20180013524A (ko) * 2016-07-29 2018-02-07 삼성전자주식회사 전자 장치 및 전자 장치의 생체 정보 인증 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003050783A (ja) * 2001-05-30 2003-02-21 Fujitsu Ltd 複合認証システム
JP2007052598A (ja) * 2005-08-17 2007-03-01 Oki Electric Ind Co Ltd 自動取引システム
WO2015066330A1 (en) * 2013-11-04 2015-05-07 Qualcomm Incorporated User authentication biometrics in mobile devices
KR20170019822A (ko) * 2015-08-12 2017-02-22 삼성전자주식회사 인증 처리 방법 및 이를 지원하는 전자 장치
KR101773074B1 (ko) * 2016-04-19 2017-08-31 주식회사 코인플러그 거래를 지원하기 위한 방법 및 이를 사용한 인증 지원 서버

Also Published As

Publication number Publication date
KR20200050813A (ko) 2020-05-12
US20220005046A1 (en) 2022-01-06
KR102616421B1 (ko) 2023-12-21

Similar Documents

Publication Publication Date Title
WO2020091525A1 (ko) 생체 인증을 이용한 결제 방법 및 그 전자 장치
WO2021071157A1 (en) Electronic device and method for managing blockchain address using the same
WO2020171538A1 (en) Electronic device and method for providing digital signature service of block chain using the same
WO2021010766A1 (ko) 블록 체인을 이용한 전자 인증 장치 및 그 방법
WO2018097662A1 (en) Method and apparatus for managing program of electronic device
WO2015093734A1 (ko) 빠른 응답 코드를 이용한 인증 시스템 및 방법
WO2019172641A1 (en) Electronic device and method for managing electronic key thereof
WO2016129838A1 (en) Electronic device and method for processing secure information
WO2015174696A1 (ko) 공인인증을 위한 보안 토큰 및 그 구동 방법
WO2021075867A1 (ko) 블록체인 기반 시스템을 위한 키의 저장 및 복구 방법과 그 장치
WO2021040325A1 (en) Electronic device providing blockchain account information and method of operating the same
WO2022010088A1 (ko) 모바일 결제를 지원하는 전자 장치, 그 동작 방법 및 저장 매체
WO2019054779A1 (ko) 메시지를 처리하기 위한 전자 장치 및 그의 동작 방법
WO2020184987A1 (en) Electronic device including secure integrated circuit
WO2015126037A1 (ko) 일회용 랜덤키를 이용한 본인 확인 및 도용 방지 시스템 및 방법
WO2022060149A1 (ko) 탈중앙화 네트워크를 이용하여 권리를 관리하는 전자 장치 및 이의 동작 방법
WO2021015568A1 (en) Electronic device and method for protecting personal information using secure switch
WO2021060745A1 (en) Electronic device for updating firmware by using security integrated circuit and operation method thereof
WO2021210918A1 (en) Electronic device for sending cryptocurrency to blockchain account and method for operating the same
WO2020235933A1 (en) System and method for payment authentication
WO2020209596A1 (en) Electronic device and method for sharing medical information by electronic device
WO2019177408A1 (ko) 온라인 인증을 이용하여 오프라인 결제를 수행하는 시스템 및 전자 장치
WO2020149555A1 (ko) 암호화될 데이터의 정보량에 기반하여 암호화에 사용될 키를 선택하는 전자 장치 및 전자 장치의 동작 방법
WO2021049681A1 (ko) 클라우드 서버를 기초로 인증을 수행하는 전자 장치 및 그 제어 방법
WO2022146026A1 (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: 19878908

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19878908

Country of ref document: EP

Kind code of ref document: A1