[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2022119387A1 - Procédé, dispositif électronique et serveur permettant d'effectuer une authentification d'utilisateur - Google Patents

Procédé, dispositif électronique et serveur permettant d'effectuer une authentification d'utilisateur Download PDF

Info

Publication number
WO2022119387A1
WO2022119387A1 PCT/KR2021/018243 KR2021018243W WO2022119387A1 WO 2022119387 A1 WO2022119387 A1 WO 2022119387A1 KR 2021018243 W KR2021018243 W KR 2021018243W WO 2022119387 A1 WO2022119387 A1 WO 2022119387A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
electronic device
pin
client
secure
Prior art date
Application number
PCT/KR2021/018243
Other languages
English (en)
Inventor
Nishant ROOPALWAL
Ramanath Vishnu Pai
Venkata Kiran CHEGU
Original Assignee
Samsung Electronics Co., Ltd.
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 Samsung Electronics Co., Ltd. filed Critical Samsung Electronics Co., Ltd.
Publication of WO2022119387A1 publication Critical patent/WO2022119387A1/fr

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
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/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
    • 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

Definitions

  • the present invention relates to authentication, and more specifically related to a method, electronic device, and server for performing user authentication in the electronic device.
  • the existing payment system/method includes the TEE, a trusted boot, a secure Personal Identification Number (PIN) pad (e.g. TUIs), fingerprint scanner, and hardware-backed key store, which are some of cutting-edge security features supplied by the existing payment system/method (e.g. Samsung's mini hardware). These features are required for the existing payment system to safeguard user and payment data.
  • the existing payment system/method merely secures the user and payment data at rest, for example, the device's user PIN and payment data are safe, but not in non-TEE, TUI devices but does not offer an authentication token during each transaction attempt. Thus, it is desired to provide a useful alternative for performing user authentication in electronic devices for the execution of secure payments.
  • the principal object of the embodiments herein is to perform user authentication in electronic devices for an execution of secure payments by establishing a secure logical channel between a client (user of an electronic device) and a server.
  • the secure logical channel includes a device-specific parameter(s), an application-specific parameter(s), and a server-specific parameter(s).
  • the secure logical channel is uniquely identified through the device-specific parameter(s), the application-specific parameter(s) and the server-specific parameter(s).
  • Another object of the embodiment herein is to provide an authentication system setup and verification process through the secure logical channel where the setup process results in two dependent objects.
  • a first object i.e. client PIN secure object
  • a second object i.e. server PIN secure object
  • the user verification process depends upon verification of the secure logical channel, first object integrity check and verification, and then user PIN.
  • Another object of the embodiment herein is to provide a payment data binding and a transaction authorization with authentication system where binding is defined as payment data dependency on authentication system and binding verification is one of an authentication factor for transaction authorization along with other factors.
  • Another object of the embodiment herein is to provide a fingerprint-based transaction authorization where a fingerprint is verified and a fingerprint signature is generated at the electronic device but transaction authorization happens at the server after validation of the secure logical channel and the fingerprint signature.
  • the embodiment herein is to provide a method for performing user authentication in an electronic device.
  • the method includes receiving, by a server, a client request from the electronic device, where the client request includes a plurality of device-specific parameters and a plurality of application-specific parameters. Further, the method includes verifying, by the server, the plurality of device-specific parameters received in the client request. Further, the method includes sending, by the server, a server response to the electronic device, where the server response includes a plurality of server-specific parameters.
  • the method includes establishing, by the server, a secure logical channel between the server and the electronic device using the plurality of device-specific parameters, the plurality of application-specific parameters, and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server. Further, the method includes authenticating, by the server, the user of the electronic device using the established secure logical channel.
  • the plurality of device-specific parameters includes an application parameter (Device master identifier (Dmid)), a nonce, and a client certificate chain, where the client certificate chain includes a list of certificates and a client signature (i.e. electronic device attestation signature) generated by a device key.
  • the Dmid is a user account unique parameter. It is received from the server by logging in to an application.
  • the Dmid is an application authentication parameter (server binding parameter). Usage of the Dmid by the server is as follows identifying a pay application from a unique device and binding validation.
  • the plurality of server-specific parameters includes a server certificate chain, an Authorization Transaction Counter (ATC), a client certificate chain attestation status, a client key store status as Trusted Execution Environment (TEE) hardware-based or mechanism-based
  • ATC Authorization Transaction Counter
  • TEE Trusted Execution Environment
  • the server verifies the client request sent through the secure logical channel by verifying the Dmid, the ATC, and the client signature, where the client signature is signed by a hardware or TEE-backed private key of the electronic device.
  • the electronic device verifies the server response sent through the secure logical channel by verifying a server signature along with the nonce, where the server signature is signed by a server private key and the electronic device stores the ATC, the server certificate chain in a memory of the electronic device.
  • authenticating, by the server, the user of the electronic device using the established secure logical channel includes receiving, by the server, a user Personal Identification Number (PIN) with the Dmid, the nonce, and the ATC, validating, by the server, the secure logical channel by verifying the Dmid, the ATC, and the client signature, and generating, by the server, a client PIN secure object and a server PIN secure object on successful validation, where the client PIN secure object and the server PIN secure object are generated using the received user PIN to authenticate the user of the electronic device.
  • PIN Personal Identification Number
  • the client PIN secure object includes the user PIN, the Dmid, and a server binding parameter (R), where the client PIN secure object is wrapped with an authentication server certificate.
  • the server binding parameter (R) makes the server stateless (server must not store the user PIN.
  • the server authenticates the transaction by user-provided PIN and the PIN secure object, the proposed method makes the server less prone to attacks. Further, the server does not store the PIN as it wraps the user PIN by an authentication server certificate by forming the client PIN secure object and returning the same to the client making server is stateless)
  • the server PIN secure object includes the Dmid, the ATC, a server binding parameter (R), and a client PIN secure object digest.
  • the user PIN, the ATC the client PIN secure object is sent through the established secure logical channel to a cloud engine to authenticate the user of the electronic device, and where the server validates the client PIN secure object using the server PIN secure object, and the server validates the user PIN with the client PIN secure object.
  • the method further includes performing, by the server, a payment data binding, and transaction authorization.
  • performing, by the server, the payment data binding includes initiating, by the server, the payment data binding through the established secure logical channel with the client pin secure object and a One Time Passcode (OTP) along with the nonce, where the payment data binding is defined as payment data dependency on an authentication parameter (R) and the Dmid or payment server dependency on the cloud engine, validating, by the server, the established secure logical channel, the client pin secure object, and the OTP, generating, by the server, a payment token and a wallet secure object on successful validation, and sending, by the server, a Wallet Transaction Counter (WTC) to the electronic device, where the electronic device stores the WTC in the memory(persistent memory).
  • WTC Wallet Transaction Counter
  • the payment token includes the authentication parameter (R), the application parameter (Dmid), and a wallet token wrapped with a wallet server certificate.
  • the wallet secure object includes a payment token digest, the application parameter (Dmid), the WTC, and where the WTC is sent to the electronic device and is protected by hardware-backed key store and the WTC is incremented for a subsequent transaction request to avoid a replay attack.
  • Dmid application parameter
  • the WTC is sent to the electronic device and is protected by hardware-backed key store and the WTC is incremented for a subsequent transaction request to avoid a replay attack.
  • the transaction authorization is initiated through the established secure logical channel with the user PIN, transaction detail, the WTC, the payment token, and the PIN secure object.
  • the embodiment herein is to provide the electronic device for performing user authentication.
  • the electronic device includes a client authentication engine coupled with a processor and a memory.
  • the client authentication engine is configured to send the client request to the server, where the client request includes the plurality of device-specific parameters. Further, the client authentication engine is configured to receive the server response from the server in response to the client request, where the server response includes the plurality of server-specific parameters. Further, the client authentication engine is configured to verify the plurality of server-specific parameters received in the server response. Further, the client authentication engine is configured to establish the secure logical channel between the server and the electronic device using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server. Further, the client authentication engine is configured to authenticate the user of the electronic device using the established secure logical channel.
  • This invention provides a useful alternative for performing user authentication in electronic devices for the execution of secure payments.
  • FIG. 1 illustrates an architecture block diagram for performing user authentication during an execution of secure payments, according to the embodiments as disclosed herein;
  • FIG. 2 illustrates an architectural structure for establishing a secure logical channel between a server and an electronic device for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 3 illustrates an architectural structure for performing PIN enrollment and user authentication for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 4 is a sequence flow diagram illustrating a method for establishing the secure logical channel and the PIN enrollment for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 5 illustrates an architectural structure for performing payment data binding with authentication for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 6 is a sequence flow diagram illustrating a method for performing payment data binding with authentication for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 7 illustrates an architectural structure for performing a secure transaction using the PIN for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 8 is a sequence flow diagram illustrating a method for performing the secure transaction with authentication for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 9 illustrates an architectural structure for generating a fingerprint certificate during onboarding for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 10 illustrates an architectural structure for performing a secure transaction using a fingerprint for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 11 is a sequence flow diagram illustrating a method for performing the secure transaction with the fingerprint for the execution of the secure payments, according to the embodiments as disclosed herein;
  • FIG. 12 illustrates an example flow diagram of an existing payment method, according to a prior art disclosed herein.
  • FIG. 13A to FIG. 13I illustrates various operations for the execution of the secure payments with various example flow diagrams associated with a proposed payment method, according to the embodiments as disclosed herein.
  • circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.
  • circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.
  • a processor e.g., one or more programmed microprocessors and associated circuitry
  • Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.
  • the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.
  • cloud server used interchangeably and mean the same.
  • cloud authentication service and “cloud engine” are used interchangeably and mean the same.
  • payment server and “payment engine” are used interchangeably and mean the same.
  • client device and “electronic device” are used interchangeably and mean the same.
  • Enc and “encrypted” are used interchangeably and mean the same.
  • Pr and “public” are used interchangeably and mean the same.
  • Auth and “authentication” are used interchangeably and mean the same.
  • application parameter and “application-specific parameter” are used interchangeably and mean the same.
  • the embodiment herein is to provide a method for performing user authentication in an electronic device.
  • the method includes receiving, by a server, a client request from the electronic device, where the client request includes a plurality of device-specific parameters. Further, the method includes verifying, by the server, the plurality of device-specific parameters received in the client request. Further, the method includes sending, by the server, a server response to the electronic device, where the server response includes a plurality of server-specific parameters. Further, the method includes establishing, by the server, a secure logical channel between the server and the electronic device using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server. Further, the method includes authenticating, by the server, the user of the electronic device using the established secure logical channel.
  • the embodiment herein is to provide a method for performing user authentication in an electronic device.
  • the method includes sending, by the electronic device, the client request to the server, where the client request includes the plurality of device-specific parameters. Further, the method includes receiving, by the electronic device, the server response from the server in response to the client request, where the server response includes the plurality of server-specific parameters. Further, the method includes verifying, by the electronic device, the plurality of server-specific parameters received in the server response. Further, the method includes establishing, by the electronic device, the secure logical channel between the server and the electronic device using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server. Further, the method includes authenticating, by the electronic device, the user of the electronic device using the established secure logical channel.
  • the embodiment herein is to provide the server for performing the user authentication.
  • the server includes a cloud engine and a payment engine coupled with a processor and a memory.
  • the server is configured to receive the client request from the electronic device, where the client request includes the plurality of device-specific parameters. Further, the server is configured to verify the plurality of device-specific parameters received in the client request. Further, the server is configured to send the server response to the electronic device, where the server response includes the plurality of server-specific parameters. Further, the server is configured to establish the secure logical channel between the server and the electronic device using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server. Further, the server is configured to authenticate the user of the electronic device using the established secure logical channel.
  • the embodiment herein is to provide the electronic device for performing user authentication.
  • the electronic device includes a client authentication engine coupled with a processor and a memory.
  • the client authentication engine is configured to send the client request to the server, where the client request includes a plurality of device-specific parameters.
  • the client authentication engine is configured to receive the server response from the server in response to the client request, where the server response includes the plurality of server-specific parameters.
  • the client authentication engine is configured to verify the plurality of server-specific parameters received in the server response.
  • the client authentication engine is configured to establish the secure logical channel between the server and the electronic device using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between the electronic device and server.
  • the client authentication engine is configured to authenticate the user of the electronic device using the established secure logical channel.
  • a conventional secure channel heavily relies on a secure element(s) (Secure Element is a tamper-resistant hardware platform that can host applications and store private and encrypted data in a secure manner), an applet(s) (Applets are secure applications that operate within TEE (Secure Element), a One Time Password (OTP), and Subscriber Identity Module (SIM) detail whereas a proposed secure channel has relied on a hardware-backed key store, a server certificate(s), an application-specific parameter(s) (application instance (e.g. Dynamic identity (Dmid)), a server Authentication Counter (ATC) and a client nonce.
  • Secure Element is a tamper-resistant hardware platform that can host applications and store private and encrypted data in a secure manner
  • an applet(s) Applets are secure applications that operate within TEE (Secure Element), a One Time Password (OTP), and Subscriber Identity Module (SIM) detail
  • a proposed secure channel has relied on a hardware-
  • a conventional security binding depends on a user PIN, an application(s), the secure element(s), the applet(s), a location, a biometric feature whereas in a proposed security binding depends on the hardware-backed key store, the server certificate(s), the application instance dynamic id (Dmid), a random number (R), the server authentication counter and the user PIN and payment data. Furthermore, the conventional methods do not bind payment data with an authentication system whereas a proposed method makes sure that provisioned payment data must have authentication system binding information (e.g. R, Dmid).
  • the conventional methods allow a transaction after verifying a user authentication assurance level (e.g. determined by the user location, user ⁇ s behavior, last authentication time, etc.) at a cloud server (cloud engine). Whereas assurance level is defined by the cloud server and stored in secure storage.
  • the transaction is allowed after verifying the user PIN authentication, payment data binding with user authentication, server Transaction Counter (TC), Wallet Transaction Counter (WTC), and Dmid along with the secure logical channel.
  • TC Transaction Counter
  • WTC Wallet Transaction Counter
  • the conventional methods bind user ⁇ s card data after user ⁇ s authentication whereas the PIN for binding is provided by an issuer. It is the same as Payment Tokenization flow.
  • the user ⁇ s authentication does not mandate. Payment and authentication data binding is dependent on the secure logical channel, the OTP, and a PIN secure object.
  • the proposed method defines a fingerprint certificate onboarding and transaction authorization using the authentication system where a fingerprint certificate, the user PIN, a client PIN secure object, and authorization code is sent through the secure logical channel.
  • the server validates the secure logical channel, the user PIN, and then stores the fingerprint certificate.
  • To authorization transactions through a fingerprint the user provides the fingerprint in the electronic device using a fingerprint sensor and the electronic device generates a fingerprint result/data.
  • the fingerprint result/data, transaction data, and authorization code are sent through the secure logical channel.
  • the server validates the secure logical channel and the fingerprint result/data is verified through the stored fingerprint certificate.
  • FIGS. 1 through 11, and 13A to 13G where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.
  • FIG. 1 illustrates an architecture block diagram for performing user authentication during an execution of secure payments, according to the embodiments as disclosed herein.
  • the architecture block diagram includes an electronic device (100), a server (200), and a CIF (300).
  • the electronic device (100) includes a memory (110), a processor (120), a communicator (130), a display (140), a client authentication engine (150), a key store (160), and an application (170) (e.g. payment application).
  • the server includes a memory (210), a processor (220), a communicator (230), a cloud engine (201) (i.e. authentication server/engine), and a payment engine (202) (i.e. payment server).
  • Examples of the electronic device (100) include, but are not limited to a smartphone, a tablet computer, a Personal Digital Assistance (PDA), an Internet of Things (IoT) device, a wearable device, etc.
  • PDA Personal Digital Assistance
  • IoT Internet of Things
  • the memory (110,210) stores a plurality of device-specific parameters, a plurality of server-specific parameters, a client PIN secure object, a server PIN secure object, a user Personal Identification Number (PIN), a One Time Passcode (OTP), a payment token and a wallet secure object, a Wallet Transaction Counter (WTC), etc.
  • PIN personal Identification Number
  • OTP One Time Passcode
  • WTC Wallet Transaction Counter
  • the memory (110,210) stores instructions to be executed by the processor (120,220).
  • the memory (110,210) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.
  • the memory (110,210) may, in some examples, be considered a non-transitory storage medium.
  • the term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (110,210) is non-movable.
  • the memory (110,210) can be configured to store larger amounts of information than the memory.
  • a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).
  • the memory (110,210) can be an internal storage unit or it can be an external storage unit of the electronic device (100)/ server (200), a cloud storage, or any other type of external storage.
  • the processor (120) communicates with the memory (110), the communicator (130), the display (140), the client authentication engine (150), the key store (160), and the application (170).
  • the processor (120) is configured to execute instructions stored in the memory (110) and to perform various processes.
  • the processor (120) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).
  • a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like
  • a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).
  • GPU central processing unit
  • AP
  • the processor (220) communicates with the memory (210), the communicator (230), the cloud engine (201), and the payment engine (202).
  • the processor (220) is configured to execute instructions stored in the memory (210) and to perform various processes.
  • the processor (220) may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).
  • a general-purpose processor such as a central processing unit (CPU), an application processor (AP), or the like
  • a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).
  • AI Artificial intelligence
  • the communicator (130) is configured for communicating internally between internal hardware components and with external devices (e.g. server (200), CIF (300), etc.) via one or more networks (e.g. Radio technology).
  • the communicator (130) includes an electronic circuit specific to a standard that enables wired or wireless communication.
  • the communicator (230) is configured for communicating internally between internal hardware components and with external devices (e.g. electronic device (100), CIF (300), etc.) via one or more networks (e.g. Radio technology).
  • the communicator (230) includes an electronic circuit specific to a standard that enables wired or wireless communication.
  • the cloud authentication engine (150), the cloud engine (201), and the payment engine (202) are implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.
  • the circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.
  • the server (200) is configured to receive a client request from the electronic device (100), where the client request includes the plurality of device-specific parameters.
  • the plurality of device-specific parameters comprises an application parameter (Device master identifier (Dmid)), a nonce, and a client certificate chain, where the client certificate chain includes a list of certificates and a client signature generated by a device key (e.g. private key, public key).
  • the server (200) is configured to verify the plurality of device-specific parameters received in the client request.
  • the server (200) is configured to send a server response to the electronic device (100), where the server response includes the plurality of server-specific parameters.
  • the plurality of server-specific parameters includes a server certificate chain, an Authorization Transaction Counter (ATC), a client certificate chain attestation status, a client key store status as Trusted Execution Environment (TEE) hardware-based or mechanism based.
  • the server (200) is configured to establish a secure logical channel between the server (200) and the electronic device (100) using the plurality of device-specific parameters and the plurality of server-specific parameters to protect confidentiality, integrity, and availability of data exchanged between a user of the electronic device (100) and the server (200). Further, the server (200) is configured to authenticate the user of the electronic device (100) using the established secure logical channel.
  • the server (200) is configured to verify the client request sent through the secure logical channel by verifying the Dmid, the ATC, and the client signature, where the client signature is signed by a hardware or TEE backed private key of the electronic device (100).
  • the electronic device (100) verifies the server response sent through the secure logical channel by verifying a server signature along with the nonce, where the server signature is signed by a server private key and the electronic device (100) stores the ATC, the server certificate chain in the memory (110) of the electronic device (100).
  • the server (200) is configured to receive a user Personal Identification Number (PIN) with the Dmid, the nonce, and the ATC. Further, the server (200) is configured to validate the secure logical channel by verifying the Dmid, the ATC, and a client signature. Further, the server (200) is configured to generate the client PIN secure object and the server PIN secure object on successful validation, where the client PIN secure object and the server PIN secure object are generated using the received user PIN to authenticate the user of the electronic device (100).
  • the client PIN secure object includes the user PIN, the Dmid, and a server binding parameter (R), where the client PIN secure object is wrapped with an authentication server certificate.
  • the server PIN secure object includes the Dmid, the ATC, a server binding parameter (R), and a client PIN secure object digest.
  • the user PIN, the ATC the client PIN secure object is sent through the established secure logical channel to the cloud engine (201) to authenticate the user of the electronic device (100), and where the server (200) validates the client PIN secure object using the server PIN secure object, and the server (200) validates the user PIN with the client PIN secure object.
  • the server (200) is configured to perform a payment data binding and transaction authorization on the established secure logical channel. Further, the server (200) is configured to initiate the payment data binding through the established secure logical channel with the client pin secure object and a One Time Passcode (OTP) along with the nonce, where the payment data binding is defined as payment data dependency on an authentication parameter (R) and the Dmid or payment server dependency on the cloud engine (201). Further, the server (200) is configured to validate the established secure logical channel, the client pin secure object, and the OTP. Further, the server (200) is configured to generate the payment token and the wallet secure object on successful validation.
  • the payment token includes the authentication parameter (R), the application parameter (Dmid), and a wallet token wrapped with a wallet server certificate.
  • the wallet secure object includes a payment token digest, the application parameter (Dmid), the WTC, and where the WTC is sent to the electronic device (100) and is protected by a hardware-backed key store and the WTC is incremented for a subsequent transaction request to avoid a replay attack.
  • the server (200) is configured to send the WTC to the electronic device (100), where the electronic device (100) stores the WTC in the memory (100).
  • the transaction authorization is initiated through the established secure logical channel with the user PIN, transaction detail, the WTC, the payment token, and the PIN secure object.
  • the transaction authorization is authorized after validation of the established secure logical channel, the payment token and pin secure object integrity, the user PIN, the payment data binding, where the payment data binding is verified by a payment engine (202) by comparing authentication parameter (R) and the application parameter (Dmid) received from the cloud engine (201) with authentication of the payment token and the application parameter (Dmid) of the payment engine (202).
  • the server (200) is configured to perform a secure onboarding event of the electronic device (100) and a fingerprint-based transaction authorization. Further, the server (200) is configured to receive the PIN secure object, the user PIN, the Dmid, server binding parameter (R), and a fingerprint certificate through the established secure logical channel from the electronic device (100). Further, the server (200) is configured to validate the established secure logical channel, integrity of the pin secure object, the server binding parameter (R), and the user PIN. Further, the server (200) is configured to authorize the secure onboarding event on successful validation, where the server (200) stores the fingerprint certificate for the requested electronic device (100).
  • the fingerprint-based transaction is initiated from the electronic device (100) after authorization of a user fingerprint which results in the fingerprint certificate, where the fingerprint-based transaction is sent through the established secure logical channel containing the fingerprint certificate and transaction information.
  • the fingerprint-based transaction is authorized by the cloud engine (201) after validation of the established secure logical channel and the fingerprint certificate through the onboarded certificate.
  • the proposed method defines an architecture that leverages cloud-based authentication, without relying much on client capabilities. This is achieved primarily using 4 major operations,
  • client authentication engine (150) on the client-side (electronic device (100)) which is responsible for securely wrapping the PIN, storing the secure object(s) (e.g. client PIN secure object), wrapping PIN with transaction data, FP binding, dynamic pin-pad display and transaction data processing, server data processing.
  • secure object(s) e.g. client PIN secure object
  • server data processing e.g. server data processing
  • the cloud engine (201) Cloud Auth Service (CAS) module
  • CAS Cloud Auth Service
  • attestation verification generation of the secure object for user PIN and payment token
  • user PIN verification transaction authorization through binding verification and user PIN
  • payment engine (202) Payment service module
  • Payment service module is responsible for executing transactions.
  • the CIF (300) behaves like an Application Programming Interface (API) gateway. Access to cloud authentication service is granted by the CIF (300) only after verifying the user account parameter like Dmid and JSON Web Token (JWT) token issued by the CIF (300) to the client.
  • the key generator module i.e. key store (160)
  • the key generator module uses the android key store to generate the keys.
  • FIG. 1 shows various hardware components of the electronic device (100) and the server (200) but it is to be understood that other embodiments are not limited thereon.
  • the electronic device (100) and the server (200) may include less or more number of components.
  • the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention.
  • One or more components can be combined to perform user authentication for the secure payment transaction.
  • FIG. 2 illustrates an architectural structure for establishing the secure logical channel between the server (200) and the electronic device (100) for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the electronic device (100) and the server (200) For creating a secure cloud authentication system, trust needs to be established between the electronic device (100) and the server (200) so that confidentiality and integrity of data between them must be protected.
  • establish a trust through the secure logical channel e.g. TLS channel
  • the device-specific parameters e.g. Dmid (Device master id) and a hardware-backed attested certificate chain
  • the server-specific parameters like the server certificate ATC, the client certificate chain attestation status and the client key store status.
  • the Dmid is a device-specific parameter received through user account login.
  • the Dmid and the ATC make sure that secure logical channels cannot be spoofed.
  • the client i.e. electronic device (100) or a secure logical channel controller (181) of the electronic device (100) makes a secure logical channel request (203) to the server (200), the secure logical channel request (203) containing the Dmid, the nonce, and the client certificate chain (attested by vendor security (e.g. Google)) with a challenge as Dmid and encrypt it with the server pinned certificate.
  • the cloud engine (201) Authentication server
  • the server (200) responds (204) with its certificate (i.e. server certificate), the ATC, and the nonce.
  • the electronic device (100) verifies the client certificate chain, the nonce, and store the ATC, the server certificate in the memory (110) (e.g. DataBase (DB)).
  • DB DataBase
  • the server (200) validates the client request (203) sent through the secure logical channel by verifying the Dmid, the ATC and the client signature signed by the hardware/TEE backed private key.
  • the electronic device (100) validates the server response (204) sent through the secure logical channel by verifying the nonce, and the server signature signed by the server private key.
  • the electronic device (100) must have a TEE/Hardware backed key store.
  • Authentication server makes sure that the electronic device (100) key store is TEE/hardware-backed, on successful verification establish the secure logical channel with electronic device (100).
  • the proposed method is the hardware-independent solution for a cloud authentication system. So, the proposed method has a huge impact as a larger user base is attributed to the non-TEE category of devices.
  • two secure logical channel is defined one is between the electronic device (100) and the cloud engine (201) and another is between the electronic device (100) and the payment engine (202).
  • FIG. 3 illustrates an architectural structure for performing PIN enrollment and user authentication for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the proposed method includes two objects/parts for performing the PIN enrollment (301) and the user authentication (304) for the execution of the secure payments.
  • a first part is called the client PIN secure object (302) wrapped with the server public key and another part is called the server PIN secure object (303) stored at the server (200).
  • the server PIN secure object (303) is used to check the integrity and validity of the client PIN secure object (302) thereby making the server (200) as stateless as it does not store the user PIN.
  • the client PIN secure object (302) is bound to the electronic device (100) containing the user ⁇ s authentication information (PIN), the device information (Dmid), and the server validation parameter (R), and it is used for the user authentication.
  • the PIN enrollment (301) the user PIN, the Dmid, and authorization code (ATC) are sent, by a PIN enrollment engine (182), to the server (200) through the secure logical channel.
  • the server (200) validates the secure logical channel, form the client PIN secure object (302) containing the server random (R), the user PIN, the Dmid, and the server PIN secure object (303) containing the R, the authorization code (ATC), the Dmid and the client pin secure object digest.
  • the user PIN, the authorization code (ATC), the Dmid, and the client PIN secure object is sent, by an authentication engine (183) of the electronic device (100), through the secure logical channel.
  • the server (200) validates the secure logical channel, validates the client PIN secure object (302) using the server PIN secure object (303), and then validates the user PIN with the client PIN secure object (302).
  • FIG. 4 is a sequence flow diagram illustrating a method for establishing the secure logical channel and the PIN enrollment for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the application (170) of the electronic device (100) sends a request to the key store (160) to generate a Rivest-Shamir-Adleman (RSA) key pair (e.g. authentication key pair/ a private and a public key).
  • RSA Rivest-Shamir-Adleman
  • the application (170) receives the RSA key pair from the key store (160).
  • the application (170) sends a request to the key store (160) to get a certificate chain.
  • the application (170) receives the certificate chain from the key store (160).
  • the application (170) sends the client authentication public key using a Cryptographic Message Syntax (CMS) envelope (certificate chain digest, nonce) to the server (200).
  • CMS Cryptographic Message Syntax
  • the server (200) generates the RSA keys and stores the authentication certificate for the Dmid.
  • the server (200) sends the server certificate, Certificate Authority (CA) certificate using the CMS envelope (certificate chain digest, nonce, ATC) to the application (170).
  • CA Certificate Authority
  • the electronic device (100) encrypts the received ATC with the client authentication public key and stores the encrypted ATC in the memory (110).
  • the electronic device (100) receives the user PIN from the user of the electronic device (100).
  • the electronic device (100) sends the user PIN using the CMS envelope (PIN, Dmid, isfingerprintenabled+ ATC+ nonce) to the server (200).
  • the electronic device (100) receives the PIN secure object CMS envelop (Dmid+ status+ nonce+ Digest) from the server (200) and store the PIN secure object in the memory (110).
  • FIG. 5 illustrates an architectural structure for performing payment data binding with authentication for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the proposed method defines the payment data binding process (501) with the authentication system and the device (e.g. the electronic device (100), the server (200)), where binding defines as a dependency of the payment token usage to the authentication system and the device.
  • the binding is initiated, by a wallet provisioning (185), through the secure logic channel with the client PIN secure object (302) and the OTP (received from the payment server (i.e. payment engine (202))).
  • the binding requires verification of the secure logical channel and the PIN secure object by the cloud engine (201) (authentication server) and the OTP by the payment engine (202).
  • a first object is anti-spoofing and tamper-resistant payment token (502) containing the authentication system parameter (R), the device dependency parameter (Dmid), the wallet metadata (e.g. wallet ID, wallet token) wrapped with the server certificate and a second object is the server wallet secure object (503) containing the payment token digest, the Dmid, the wallet ID and a WTC.
  • the WTC is sent to the electronic device (100) through the secure logical channel and the electronic device (100) (client) verifies the secure logical channel and then stores it in the memory (110).
  • the WTC is protected by the hardware-backed key store.
  • the user of the electronic device (100) initiates wallet provisioning (185) after receiving the OTP from the payment server (202).
  • the OTP, the client PIN secure object (302) is sent through the secure logical channel.
  • FIG. 6 is a sequence flow diagram illustrating a method for performing payment data binding with authentication for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the application (170) of the electronic device (100) sends a request to the key store (160) to generate a Rivest-Shamir-Adleman (RSA) key pair (e.g. wallet key pair).
  • RSA Rivest-Shamir-Adleman
  • the application (170) receives the RSA key pair from the key store (160).
  • the application (170) sends a request to the key store (160) to get the certificate chain.
  • the application (170) receives the certificate chain from the key store (160).
  • the application (170) sends an ALLET_KEY_PAIR to the server (200).
  • the server (200) sends a server wallet certificate and CA certificate to the application (170).
  • the electronic device (100) initiates a wallet registration with the server (200) on receiving the server wallet certificate and CA certificate.
  • the application (170) sends a request to the memory (100) to get the PIN secure object.
  • the application (170) receives the PIN secure object from the memory (100).
  • the application (170) sends a request to the server (200) to verify OTP (PIN secure object, OTP, nonce).
  • OTP PIN secure object, OTP, nonce
  • the server (200) sends the payment token, the client CMS envelop (wallet authorization code, digest, nonce) to the application (170).
  • the application (170) sends a request to store the received payment token in the memory (100) and the memory (110) shares the status for of storing the payment token to the application (170).
  • the application (170) sends a request for an encrypted wallet authentication code to the key store (160) and the key store (160) sends the encrypted wallet authentication code to the application (170).
  • the application (170) send a request to store the received wallet authentication code in the server (200) and the server (200) shares the status for the same.
  • FIG. 7 illustrates an architectural structure for performing a secure transaction using the PIN for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the proposed method defines the secure transaction process with the authentication system (701) where the transaction authorization depends upon validation, by a pay (186), of the secure logical channel, the PIN secure object integrity check (i.e. client PIN secure object (302), server PIN secure object (303)), the user PIN verification, payment token (502) integrity check, payment token (502) binding verification with the authentication system and device and validation of wallet authorization counter.
  • the user i.e. pay (183)
  • FIG. 8 is a sequence flow diagram illustrating a method for performing the secure transaction with authentication for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the application (170) of the electronic device (100) sends a request to the key store (160) to get authentication key pair.
  • the application (170) receives the private key from the key store (160).
  • the application (170) sends a request to the memory (110) to get the payment token (502).
  • the application (170) receives the payment token (502) from the memory (110).
  • the application (170) sends a request to the memory (110) to get the PIN secure object (i.e. client PIN secure object (302), server PIN secure object (303)).
  • the application (170) receives the PIN secure object from the memory (110).
  • the user of the electronic device (100) enters the transaction details and the user PIN at the application (170).
  • the electronic device (100) sends a request to verify PIN (with Transaction CMS envelop, payment token, PIN secure object) to the server (200).
  • the server (200) sends a status report (e.g. Response: CMS envelop (transaction status + Digest), New PIN secure object, New payment token) to the electronic device (100) and the electronic device (100) unwrap the received status.
  • FIG. 9 illustrates an architectural structure for generating a fingerprint certificate during onboarding for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the proposed method defines the secure onboarding process of the fingerprint certificate (901) to the cloud engine (201) (authentication server) where the fingerprint certificate is used at the server (200) to validate the fingerprint authorization result signature received from the electronic device (100), where a fingerprint controller (187) receives the user ⁇ s fingerprint using sensor(s) of the electronic device (100) and stores it in the key store (160) and generates the onboarded fingerprint certificate (188).
  • the secure onboarding process is authorized only after validation of the secure logical channel, integrity check of PIN secure object (302,303), and then the user PIN.
  • the cloud engine (201) (authentication server) stores certificates for the requested electronic device (100).
  • a transaction can be authorized either through the user's PIN or the fingerprint.
  • Android provides a mechanism where the fingerprint result is verified in the normal world by verifying the fingerprint signature. In low-end devices verification of fingerprint signature is not much secure.
  • the electronic device (100) transferred the fingerprint verification process to the cloud engine (201) (authentication server) by onboarding the fingerprint certificates through the user PIN.
  • FIG. 10 illustrates an architectural structure for performing the secure transaction using the fingerprint for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the proposed method defines the fingerprint-based secure transaction (1001) where the fingerprint is provided at the user device (fingerprint controller (187)) and the fingerprint verification signature along with the payment token is sent to the server (200) through the secure logical channel.
  • Transaction authorization depends upon wallet secure logical channel verification, the payment token integrity check by the payment server (202), the authentication secure logical channel verification, and verification of the fingerprint signature by the authentication server (201).
  • the user by the pay (186) initiates the secure transaction by providing the fingerprint into the electronic device (100) using the fingerprint sensor. A transaction is initiated from the electronic device (100).
  • FIG. 11 is a sequence flow diagram illustrating a method for performing the secure transaction with the fingerprint for the execution of the secure payments, according to the embodiments as disclosed herein.
  • the application (170) of the electronic device (100) sends a request to the key store (160) to get authentication key pair.
  • the application (170) receives the private key from the key store (160).
  • the application (170) sends a request to the memory (110) to get the payment token (502).
  • the application (170) receives the payment token (502) from the memory (110).
  • the application (170) sends a request to the memory (110) to get the PIN secure object (i.e. client PIN secure object (302), server PIN secure object (303)).
  • the application (170) receives the PIN secure object from the memory (110).
  • the user of the electronic device (100) enters the transaction details and the user PIN at the application (170).
  • the electronic device (100) sends a request to verify the fingerprint (with Transaction CMS envelop, payment token) to the server (200).
  • the server (200) sends a status report (e.g. Response: transaction status, Dmid + nonce, server signature) to the electronic device (100) and the electronic device (100) unwrap the received status.
  • FIG. 12 illustrates an example flow diagram of an existing payment method, according to a prior art disclosed herein.
  • a user-1 (Alice) wishes to transfer money to a user-2 (Bob)
  • the existing payment method's example flow diagram is divided into 3 stages (highlighted in a dark box for references).
  • a first stage is associated with a setup of the PIN or fingerprint (FP)
  • FP PIN or fingerprint
  • FP PIN or fingerprint
  • FP PIN or fingerprint
  • the user-1 enrolls (1) the PIN/FP via the electronic device's application (170) (e.g., Samsung payment app).
  • the electronic device (100) then encrypts (2) the PIN using an authentication TA certificate (EncAuthTAPub ⁇ PIN, R ⁇ ), making it difficult for the rest of the world to extract the PIN.
  • the electronic device (100) then verifies (3) the PIN/FP EncAuthTAPub ⁇ PIN ⁇ .
  • user-1 provides a mobile number (4) and shares (5) it with the server (200). When the server (200) receives the mobile number (4), it sends a message (6) to the electronic device's application (170), which contains an OTP for verification.
  • the user-1 then provides the received OTP (7) to the server (200), and the server (200) provides a wallet token (8) to the electronic device's application (170) upon successful verification of the OTP.
  • the electronic device (100) then wraps the received wallet token (8) with a wallet TA and extracts (9) the received wallet token (8) and nonce, both of which are necessary for the transaction.
  • the electronic device (100) validates (10) the wallet TA authentication from the authentication TA, after which the electronic device (100) unlocks the wallet token and prepares for a transaction request (11) in which the user-1 inputs payment information (e.g., Alice to Bob $10).
  • the electronic device (100) then wraps the payment information (12) in the wallet TA and creates EncServerPub, which includes payment information (13) (Name: Alice to Bob, Amount: $10, Alice Wallet Token, Nonce).
  • the application (170) then sends (14) extracted token and payment information with the server (200), and the server (200) validates the received extracted token and payment information and executes the transaction for the requested payment information.
  • the TEE is found in high-end devices.
  • the TEE offers a safe environment for trusted applications to run in, including a secure processor and cryptographic engine, as well as secure storage.
  • the TEE is not available on low-cost devices.
  • the addition of the TEE to a low-cost device increases the device's cost.
  • a cloud-based authentication method has been developed.
  • FIG. 13A to FIG. 13G illustrates various operations for the execution of the secure payments with various example flow diagrams associated with a proposed payment method, according to the embodiments as disclosed herein.
  • the user of the electronic device (100) has to select an authentication option (e.g. PIN/FP) at the payment application (170) of the electronic device (100) to register the authentication option in the electronic device (100), where the register authentication option is used for execution the secure payments, wallet tractions, wallet addition, wallet deletion, etc.
  • an authentication option e.g. PIN/FP
  • the user has to enter the PIN/FP and verify the entered PIN/FP at the payment application (170).
  • FIG. 13B Corresponding technical flow diagram explains in FIG. 13B.
  • FIG. 13B illustrates a proposed system environment for low-tier or mid-tier electronic device (100) utilizing cloud authentication solution for step-up of the PIN/FP.
  • the application (170) receives (1) a request to retrieve the certificate chain from the key store (160) (i.e. hardware-backed key store).
  • the application (170) sends (2) the certificate chain to the key store (160).
  • the application (170) sends (3) EncPinnedServerPub ⁇ ClientPubKeyDigest +nonce +Dmid ⁇ and ClientPubKey to the cloud engine (201) and then the cloud engine (201) sends (4) EncClientPub ⁇ ServerPubKeyDigest +nonce +ATC ⁇ and ServerPubKey to the application (170), and then the key store (160) stores the ATC in the memory (110).
  • the application (170) receives the user PIN from the user of the electronic device (100) and retrieves the stored ATC from the memory (110).
  • the application (170) then sends (6) the user PIN using the CMS envelope (EncServerPub ⁇ PIN+dmid+Nonce+ATC ⁇ ) to the cloud engine (201).
  • the cloud engine (201) then sends (7) the CMS envelop (EncClientrPub ⁇ Status+ Dmid+ Nonce+ Digest ⁇ ) and the PIN secure object (EncServerPub ⁇ PIN+dmid+R ⁇ ) to the application (170).
  • the application (170) then stores (8) the received PIN secure object in the memory (110).
  • the application (170) receives the user PIN from the user of the electronic device (100) for the authentication, and retrieves (9), and increments the stored ATC.
  • the application (170) then sends (10) the CMS envelop (EncServerPub ⁇ PIN+dmid+Nonce+ATC ⁇ ) with the PIN secure object.
  • the application (170) then receives the PIN secure object (EncClientPub ⁇ Auth Status + Digest ⁇ ) upon successful authentication of the user PIN.
  • the user of the electronic device (100) has to enter a phone number (e.g. 9919x xxxxx) at the payment application (170) of the electronic device (100) to register the phone number with the payment server (200) to generate a new wallet on-boarding for the entered phone number to execute the secure payments.
  • the server (200) receives the phone number, the server (200) sends a message to the electronic device's application (170), which contains the OTP for verification.
  • the user of the electronic device (100) then enters the received OTP to the server (200), and the server (200) provides the wallet token to the electronic device's application (170) upon successful verification of the OTP.
  • FIG. 13D Corresponding technical flow diagram explains in FIG. 13D.
  • FIG. 13D illustrates a proposed system environment for low-tier or mid-tier electronic device (100) utilizing cloud authentication solutions for wallet onboarding.
  • the user of the electronic device (100) has to enter (1) a phone number at the application (170) of the electronic device (100) to register the phone number with the partner server via the payment engine (202) to generate a new wallet on-boarding for the entered phone number to execute the secure payments.
  • the server (200) receives (2) the phone number
  • the server (200) sends (3) a message to the electronic device's application (170), which contains the OTP for verification.
  • the user of the electronic device (100) then enters (4) the received OTP at the application (170) received from the partner server and the application (170) sends the CMS envelop (EncServerPub ⁇ OTP + nonce ⁇ ) and the PIN secure object ( ⁇ PIN+dmid+R ⁇ ) to the partner server via the payment engine (202).
  • the partner server provides (7) the wallet token to the payment engine (202) upon successful verification of the OTP (5, 6).
  • the payment engine (202) sends (8) EncServerPub ⁇ PIN+dmid+R ⁇ PIN secure object to the cloud engine (201) to check (9) integrity of the PIN secure object, and then the cloud engine (201) sends (10) the R and the Dmid to the payment engine (202) to generate (11) the wallet secure object.
  • the payment engine (202) then sends (12) CMS Envelop wallet secure object EncServerPub ⁇ R + Dmid + token ⁇ EncClientPub ⁇ WTC +nonce + wallet secure object digest ⁇ to the application (170) for onboarding status (13).
  • the application (170) then stores (13, 14) wallet secure object EncServerPub ⁇ R + Dmid + token ⁇ in the memory (110).
  • the user of the electronic device (100) has to enter a recipient phone number (e.g. 9033x xxxxx) and payment amount (e.g. 100) at the payment application (170) of the electronic device (100) to perform a wallet transaction.
  • the electronic device (100) displays the payment information and the authentication option on a screen (140) the electronic device.
  • the electronic device (100) verifies the entered PIN/FP at the payment application (170).
  • the electronic device (100) then transfers the entered amount to the entered recipient phone number and displays the payment status information on the screen (140) upon successful verification of the entered PIN/FP.
  • FIG. 13F Corresponding technical flow diagram explains in FIG. 13F.
  • FIG. 13F illustrates a proposed system environment for the low-tier or mid-tier electronic device (100) utilizing cloud authentication solutions for wallet transactions.
  • the user of the electronic device (100) has to enter the recipient phone number, the payment amount, and the PIN/FP at the application (170) of the electronic device (100) to perform the wallet transaction.
  • the application (170) then retrieves & increments (2) the ATC, retrieves & increments (3) the WTC, retrieves (4) the PIN Secure Object EncServerPub ⁇ PIN+ Dmid+ R ⁇ , and retrieves (5) the Wallet Secure Object EncServerPub ⁇ R + Dmid + token ⁇ from the key store (160).
  • the application (170) then sends (6) CMS Envelope EncServerPub ⁇ transaction + PIN + ATC ⁇ , the PIN secure object, and the wallet secure object to the payment engine (201).
  • the payment engine (201) retrieves (7) entities (client data, R, Dmid, token) and sends (8) CMS envelope EncServerPub ⁇ transaction + PIN ⁇ and the PIN secure object to the cloud engine (201).
  • the cloud engine (201) retrieves (9) entities (transaction, nonce, PIN, R, Dmid), verify (10) the received PIN, and sends (11) entities (R, Dmid, transaction) to the payment engine (201) upon successful verification of the PIN.
  • the payment engine (201) verifies binding and unlocks the token (12) and sends (13) the unlocked token and transaction details for validation.
  • the payment engine (201) receives approval from the partner server and sends (15, 16) transaction status to the application (170).
  • At 1315 generate the symmetric key (1) and the IV (2). Encrypt (3, 4) the content using the generated symmetric key and generate encrypted content. Encrypt the symmetric key (5, 6) using the server public key and signed the encrypted content using the server private key (7) and generate the server signature (8).
  • the embodiments disclosed herein can be implemented using at least one hardware device and performing network management functions to control the elements.

Landscapes

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

Abstract

Des modes de réalisation dans la description concernent un procédé et un système d'authentification d'utilisateur en ligne dans un dispositif électronique d'entrée de gamme. Le procédé consiste à établir un canal logique sécurisé entre un dispositif électronique client et un serveur. Le canal logique sécurisé établi entre le serveur et le dispositif électronique utilise la pluralité de paramètres spécifiques au dispositif et la pluralité de paramètres spécifiques au serveur pour protéger la confidentialité, l'intégrité et la disponibilité de données échangées entre un utilisateur du dispositif électronique et le serveur. En outre, le procédé consiste à authentifier un utilisateur du dispositif électronique à l'aide du canal logique sécurisé établi. En outre, le procédé consiste à effectuer une liaison de données de paiement, une autorisation de transaction, un événement d'intégration sécurisée du dispositif électronique et une autorisation de transaction basée sur une empreinte digitale sur le canal logique sécurisé établi.
PCT/KR2021/018243 2020-12-03 2021-12-03 Procédé, dispositif électronique et serveur permettant d'effectuer une authentification d'utilisateur WO2022119387A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041052709 2020-12-03
IN202041052709 2021-11-29

Publications (1)

Publication Number Publication Date
WO2022119387A1 true WO2022119387A1 (fr) 2022-06-09

Family

ID=81854922

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/018243 WO2022119387A1 (fr) 2020-12-03 2021-12-03 Procédé, dispositif électronique et serveur permettant d'effectuer une authentification d'utilisateur

Country Status (1)

Country Link
WO (1) WO2022119387A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110072274A1 (en) * 2009-03-31 2011-03-24 Topaz Systems, Inc. Distributed system for multi-function secure verifiable signer authentication
US8131865B2 (en) * 2003-02-24 2012-03-06 Realnetworks, Inc. Media service delivery system providing conditional access to media content from various client devices
US20130281058A1 (en) * 2012-04-20 2013-10-24 T-Mobile Usa, Inc. Secure Environment for Subscriber Device
EP3557835A1 (fr) * 2017-01-13 2019-10-23 Huawei Technologies Co., Ltd. Procédé de migration de justificatif d'identité pour autorisation, dispositif terminal et serveur de service
US10764752B1 (en) * 2018-08-21 2020-09-01 HYPR Corp. Secure mobile initiated authentication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8131865B2 (en) * 2003-02-24 2012-03-06 Realnetworks, Inc. Media service delivery system providing conditional access to media content from various client devices
US20110072274A1 (en) * 2009-03-31 2011-03-24 Topaz Systems, Inc. Distributed system for multi-function secure verifiable signer authentication
US20130281058A1 (en) * 2012-04-20 2013-10-24 T-Mobile Usa, Inc. Secure Environment for Subscriber Device
EP3557835A1 (fr) * 2017-01-13 2019-10-23 Huawei Technologies Co., Ltd. Procédé de migration de justificatif d'identité pour autorisation, dispositif terminal et serveur de service
US10764752B1 (en) * 2018-08-21 2020-09-01 HYPR Corp. Secure mobile initiated authentication

Similar Documents

Publication Publication Date Title
CN111213171B (zh) 用于安全离线支付的方法和装置
WO2018030707A1 (fr) Système et procédé d'authentification, et équipement d'utilisateur, serveur d'authentification, et serveur de service pour exécuter ledit procédé
WO2018012747A1 (fr) Système mandataire d'authentification à deux canaux permettant de détecter l'altération frauduleuse d'une application et procédé associé
WO2014175538A1 (fr) Appareil permettant d'utiliser un otp matériel basé sur puf et procédé permettant une authentification à 2 facteurs l'utilisant
US8112787B2 (en) System and method for securing a credential via user and server verification
WO2018124857A1 (fr) Procédé et terminal d'authentification sur la base d'une base de données de chaînes de blocs d'un utilisateur sans face-à-face au moyen d'un id mobile, et serveur utilisant le procédé et le terminal
US20080077592A1 (en) method and apparatus for device authentication
CN111431719A (zh) 一种移动终端密码保护模块、移动终端及密码保护方法
WO2017057899A1 (fr) Système d'authentification intégré pour authentification grâce à des nombres aléatoires à usage unique
KR20210133985A (ko) 새로운 인증기를 보증하기 위한 시스템 및 방법
WO2018021708A1 (fr) Procédé et système d'authentification de service basée sur une clé publique
KR20160032665A (ko) 안전한 전자 거래를 위한 네트워크 인증 방법
TWI776404B (zh) 生物支付設備的認證方法、裝置、電腦設備和儲存媒體
EP3206329B1 (fr) Procédé, dispositif, terminal et serveur de contrôle de sécurité
WO2020159328A1 (fr) Procédé et appareil de traitement d'informations d'authentification et terminal utilisateur comprenant un appareil de procédé de traitement d'informations d'authentification
WO2020032351A1 (fr) Procédé permettant d'établir une identité numérique anonyme
WO2019182377A1 (fr) Procédé, dispositif électronique et support d'enregistrement lisible par ordinateur permettant de générer des informations d'adresse utilisées pour une transaction de cryptomonnaie à base de chaîne de blocs
WO2019098790A1 (fr) Dispositif électronique et procédé de transmission et de réception de données d'après un système d'exploitation de sécurité dans un dispositif électronique
TW202207667A (zh) 通訊系統中改善安全性之認證及驗證方法
WO2020235933A1 (fr) Système et procédé d'authentification de paiement
KR20180087543A (ko) 키 관리 방법 및 ｆｉｄｏ 소프트웨어 인증장치
US20240113898A1 (en) Secure Module and Method for App-to-App Mutual Trust Through App-Based Identity
WO2022075563A1 (fr) Dispositif électronique pour générer et authentifier des informations d'identification d'un dispositif matériel et son procédé de fonctionnement
US11431514B1 (en) Systems for determining authenticated transmissions of encrypted payloads
WO2022119387A1 (fr) Procédé, dispositif électronique et serveur permettant d'effectuer une authentification d'utilisateur

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: 21901075

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: 21901075

Country of ref document: EP

Kind code of ref document: A1