CN107705122B - Method and system for carrying out safe payment in android system - Google Patents
Method and system for carrying out safe payment in android system Download PDFInfo
- Publication number
- CN107705122B CN107705122B CN201710811468.2A CN201710811468A CN107705122B CN 107705122 B CN107705122 B CN 107705122B CN 201710811468 A CN201710811468 A CN 201710811468A CN 107705122 B CN107705122 B CN 107705122B
- Authority
- CN
- China
- Prior art keywords
- processor
- payment
- secure
- general
- payment service
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
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/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses a method and a system for carrying out safe payment in an android system, wherein the method comprises the following steps of S1: the safety processor and the general processor are connected through a serial bus; s2: adding a payment service manager interface for the android system; s3: adding payment service and corresponding payment authority statement for the android system; s4: and according to the payment service manager interface, the payment service and the permission statement thereof, the security processor and the general processor perform mutual authentication through a serial bus to obtain a communication key, so that the security payment is realized. By the method, the payment API of the POS terminal running in the secure processor can be ensured to be transparently and reliably called by the general android application, and the concurrent calling of multiple applications is supported, so that the application range of the intelligent operating system in the secure payment field is effectively expanded.
Description
Technical Field
The invention relates to the technical field of payment safety, in particular to a method and a system for carrying out safety payment in an android system.
Background
POS (point of sale terminal) is now being used by more and more merchants as an alliance card acceptance terminal, and POS security is also receiving more and more attention. As is well known, a merchant uses a POS to complete a receipt, a cardholder is required to present a bank card, a POS terminal inputs a password after finishing card reading, and data after filling and exclusive-or operation is performed on the password of the cardholder according to the ISO9564 specification is called plaintext pinbock. And the data obtained after encrypting the plaintext PINBLOCK using the acquirer working key is referred to as ciphertext PINBLOCK. And finally, the data is sent to the collection row background for verification. POS terminals are faced with various attacks: penetration, eavesdropping, peeping, camouflage, malicious programs and the like, and finally, an attacker aims to steal the data information of the cardholder.
Because of security requirements, POS products typically employ specialized security processors. The security processor passes the international or domestic security standard authentication, has a mature software and hardware security mechanism, a security starting and security firmware updating mechanism, an anti-attack, anti-detection and anti-monitoring function, an access protection and automatic erasure function of sensitive data and the like. However, the special security processor has lower performance, unfavorable multimedia expansion and poor universality, and is difficult to meet the requirements of the current intelligent operating system such as Android.
In addition, the general processor for running the Android system has the advantages of high performance, rich multimedia support and the like, but the general processor is not capable of providing a complete set of software and hardware security performance guarantee of a sufficient equivalent security processor level although the general processor is partially provided with software security mechanisms such as security startup and the like. Meanwhile, if the dual-processor architecture is simply built, the exposed communication bus has potential safety hazards of being monitored and tampered, and the data security still cannot reach the level of the secure processor.
Disclosure of Invention
The technical problems to be solved by the invention are as follows: the method and the system for carrying out the safe payment in the android system can ensure that the payment API of the POS terminal running in the safe processor can be transparently and reliably called by the general android application, support the concurrent calling of multiple applications and effectively expand the application range of the intelligent operating system in the safe payment field.
In order to solve the technical problems, the invention adopts the following technical scheme: the method for carrying out the safe payment in the android system at least comprises the following steps:
s1: the safety processor and the general processor are connected through a serial bus;
s2: adding a payment service manager interface for the android system;
s3: adding payment service and corresponding payment authority statement for the android system;
s4: the security processor and the general processor perform mutual authentication through a serial bus to obtain a communication key;
s5: and adding a secure payment interface for the secure processor, calling a payment service by using the payment service manager interface by using the android payment application, calling the secure payment interface of the secure processor by using the communication key in a remote interaction manner by using the payment service according to the payment authority statement, and realizing secure payment.
The security processor is internally provided with security information, a first RSA public key and a first RSA private key, and is set as an RPC server of a payment service API; the general processor runs the android system, a second RSA public key and a second RSA private key are built in the general processor, the payment service manager interface is set to be an IPC client of the payment service, and the payment service is set to be an IPC server and an RPC client.
The step S2 specifically includes:
s21: setting a payment service manager interface running in an android system application thread as an IPC client through an AIDL technology;
s22: the IPC client applies for connecting with the android system payment service manager interface, and detects whether the connection is successful,
if yes, step S23 is executed: the IPC client sends a secure payment API request to the payment service;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s24: and the IPC client obtains a feedback response of the payment service to analyze the secure payment API request.
The IPC server in step S3 operates in the android system and uses a synchronization technology to implement a concurrent request of multiple applications, specifically:
s31: the IPC server line Cheng Jieshou applies the IPC client payment service connection request for android payment;
s32: the IPC server judges whether the application end declares the payment authority from the android payment application context,
if yes, step S33 is executed: the IPC server receives the payment service API call request and enters a command synchronization block;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s34: the IPC server side sends an API command request to an API command queue of the RPC client side;
s35: and the IPC server receives the call response of the API command queue and exits the command synchronizing block.
In step S3, the RPC client communicates with the secure processor through the serial bus, and accesses the serial bus device node using the JNI, specifically:
s36: when the RPC client detects that an API command request exists in the API command queue, converting the API call request into an RPC request data packet, and performing DES encryption by using a communication key to generate an RPC request encryption packet;
s37: the RPC client sends an RPC request encryption packet to an RPC server of the security processor through a serial port;
s38: the RPC client receives the RPC response encryption packet of the security processor through the serial port and analyzes the RPC response encryption packet to obtain API call return data;
s39: and the RPC client sends the returned data to the IPC server of the payment service.
Wherein, between step S37 and step S38, the method further comprises the following steps:
s371: the method comprises the steps that a secure processor RPC server receives a request encryption packet sent by an RPC client;
s372: it is determined whether the data requesting the encrypted packet is valid,
if yes, step S373 is executed: decrypting the RPC request encryption packet by using the communication key to obtain a payment service API request;
otherwise, returning to the step S371;
s374: executing a payment service API in the secure processor to obtain API call return data;
s375: the RPC server converts the API call return data into a response packet, and encrypts the response packet into an RPC response encryption packet by using a communication key;
s376: and the RPC server side sends the RPC response encryption packet to the RPC client side.
The step S4 specifically includes:
s41: according to the payment service manager interface, the payment service and the permission statement thereof, the general processor sends a first general random number of 8 bytes to the security processor;
s42: the security processor generates an 8-byte security random number, then combines the security random number with the first general random number to generate a 16-byte first combined number, encrypts the first combined number by using a first RSA private key to generate a first combined number ciphertext, and sends the first combined number ciphertext and the first RSA public key to the general processor;
s43: the general processor decrypts the first combined number ciphertext according to the first RSA public key to obtain a first combined number of 16 bytes, judges whether the first 8 bytes of the first combined number are matched with the first general random number,
if not, executing step S6: displaying abnormality and terminating the flow;
if so, step S44 is performed: the general processor generates a second general random number with 8 bytes, generates a second combined number with 16 bytes by combining the second general random number with the secure random number, encrypts the second combined number by using a second RSA private key to generate a second combined number ciphertext, and sends the second combined number ciphertext and the second RSA public key to the secure processor;
s45: the security processor decrypts the second combined number ciphertext according to the second RSA public key to obtain a 16-byte second combined number, judges whether the first 8-byte number of the second combined number is matched with the security random number,
if not, executing step S6: displaying abnormality and terminating the flow;
if so, step S46 is performed: the secure processor and the general processor both set the second combination number as an encryption/decryption key for the RPC communication data as a secure payment communication key.
In order to solve the technical problems, the invention also provides a system for carrying out safe payment in the android system, which comprises a safe processor and a general processor which are connected through a serial bus, wherein the android system of the general processor is provided with a payment service manager interface, a payment service and a corresponding payment authority statement, the safe processor and the general processor carry out bidirectional authentication through the serial bus to obtain a communication key, the safe processor is provided with a safe payment interface, the android payment application uses the payment service manager interface to call a payment service, and the payment service uses the communication key to remotely and interactively call the safe payment interface of the safe processor according to the payment authority statement to realize safe payment.
The security processor is internally provided with security information, a first RSA public key and a first RSA private key, and is set as an RPC server of a payment service API; the general processor runs the android system, a second RSA public key and a second RSA private key are built in the general processor, the payment service manager interface is set to be an IPC client of the payment service, and the payment service is set to be an IPC server and an RPC client.
The general processor sends a first general random number of 8 bytes to the security processor according to the payment service manager interface, the payment service and the permission statement thereof;
the security processor generates an 8-byte security random number, then combines the security random number with the first general random number to generate a 16-byte first combined number, encrypts the first combined number by using a first RSA private key to generate a first combined number ciphertext, and sends the first combined number ciphertext and the first RSA public key to the general processor;
the general processor decrypts the first combined number ciphertext according to the first RSA public key to obtain a 16-byte first combined number, judges whether the first 8-byte number of the first combined number is matched with the first general random number,
if the first combination number is matched with the second combination number, the general processor generates 8 bytes of a second general random number, the second general random number is combined with the security random number to generate 16 bytes of a second combination number, the second combination number is encrypted by using a second RSA private key to generate a second combination number ciphertext, and the second combination number ciphertext and the second RSA public key are sent to the security processor;
the security processor decrypts the second combined number ciphertext according to the second RSA public key to obtain a 16-byte second combined number, judges whether the first 8-byte number of the second combined number is matched with the security random number,
if the two numbers match, the security processor and the general processor set the second combination number as an encryption/decryption key of the RPC communication data to be used as a security payment communication key.
The invention has the beneficial effects that: compared with the prior art, the invention ensures that the POS (point of sale terminal) safety related system call actually runs inside the safety processor through the double-processor architecture matched with RPC (remote procedure call) and a bidirectional authentication safety communication protocol, and the application program of the general processor can safely and conveniently call the payment service, particularly, the application program of the general processor can be connected with the safety processor and the general processor through a serial bus for bidirectional authentication to obtain a communication key; and the android payment application uses the payment service manager interface to call a payment service, and the payment service uses the communication key to remotely and interactively call a secure payment interface of the secure processor according to the payment authority statement to realize secure payment. By the method, the payment API of the POS terminal running in the secure processor can be transparently and reliably called by the general android application, and the multi-application concurrent calling is supported, so that the application range of the intelligent operating system in the secure payment field is effectively expanded.
Drawings
FIG. 1 is a schematic flow chart of step S2 of the method of the present invention;
FIG. 2 is a schematic flow chart of supporting multiple application concurrency requests by an IPC server using a synchronization technology in the present invention;
FIG. 3 is a schematic diagram of a specific flow of an RPC client accessing a serial bus device node using JNI technology in the present invention;
FIG. 4 is a schematic diagram of a specific flow of an RPC server for implementing a payment API call within a secure processor according to the present invention;
fig. 5 is a schematic diagram of a specific flow of performing two-way authentication and obtaining a communication key between a general processor and a secure processor according to the present invention.
Detailed Description
In order to describe the technical contents, the achieved objects and effects of the present invention in detail, the following description will be made with reference to the embodiments in conjunction with the accompanying drawings.
The invention ensures that the system call related to POS (point of sale terminal) safety actually runs in the safety processor through the double-processor architecture matched with RPC (remote procedure call) and a mutual authentication safety communication protocol, and the application program of the general processor can safely and conveniently call the payment service.
The invention provides a method for carrying out safe payment in an android system, which at least comprises the following steps:
s1: the safety processor and the general processor are connected through a serial bus;
s2: adding a payment service manager interface for the android system;
s3: adding payment service and corresponding payment authority statement for the android system;
s4: the security processor and the general processor perform mutual authentication through a serial bus to obtain a communication key;
s5: and adding a secure payment interface for the secure processor, calling a payment service by using the payment service manager interface by using the android payment application, calling the secure payment interface of the secure processor by using the communication key in a remote interaction manner by using the payment service according to the payment authority statement, and realizing secure payment.
Firstly, all safety related information in the system is only stored in a sensitive data area inside the safety processor, meanwhile, all payment service related API (application programming interface) calls are operated inside the safety processor, and an external interface of the safety processor is actually an RPC call server of the payment service API. And adding payment service and corresponding payment service authority for the system service in the android system running on the general processor. The payment service is used as a system service extension, and is actually a service end called by an application layer IPC and an RPC client called by a safety-related API. The security processor and the general processor are connected through a serial bus, only An Zhuoduan payment service with system authority can access the serial bus, the payment service limits the application of user authority to access the payment service API through a standard authority checking method, and only the application which declares the relevant payment authority can indirectly call the payment API through an IPC (inter-process communication) mode. After the system is powered on, the security processor and the general processor perform mutual authentication and acquire a communication DES key, and then RPC call data in the formal communication process are encrypted and transmitted by using the communication key to prevent sensitive data from being eavesdropped and tampered.
By the above method, the android application running on the general-purpose processor and claiming payment authority can transparently call related payment APIs in parallel, while actual security related API calls occur inside the secure processor.
The security processor used in the invention is a security processor passing the international and domestic security authentication requirements, and has security starting and security firmware updating mechanisms, anti-attack, anti-detection and anti-monitoring functions, and access protection and automatic erasure functions of sensitive data. The secure processor is provided with an RSA2048 public-private key pair 1 which comprises a first RSA public key and a first RSA private key.
The general processor has a safe starting function and can operate an android system, and firmware of the general processor is internally provided with an RSA2048 public-private key pair 2 comprising a second RSA public key and a second RSA private key.
The secure processor and the general processor are connected through a serial bus, and a user corresponding to the bus is set as a sysetm attribute 0660 in a linux drive of the android system at the general processor end, namely, only the system user can access the system.
In step S2, a payment service manager interface is added for the android system, and the payment service manager interface runs in a common android application thread, and is essentially an IPC client of the payment service, and the specific flow is as shown in fig. 1:
s21: setting a payment service manager interface running in an android system application thread as an IPC client through an AIDL technology;
s22: the IPC client applies for connecting with the android system payment service manager interface, and detects whether the connection is successful,
if yes, step S23 is executed: the IPC client sends a secure payment API request to the payment service;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s24: and the IPC client obtains a feedback response of the payment service to analyze the secure payment API request.
And in step S3, adding payment service and corresponding payment authority statement for the android system. The payment service runs in the android system Server process and has system permission, and the system permission comprises an IPC server of the payment service and an RPC client of the payment API call in the secure processor.
Specifically, the IPC server runs in a system process system server of the android system, and uses a synchronization technology to support concurrent requests of multiple applications, and the specific flow is shown in fig. 2:
s31: the IPC server line Cheng Jieshou pays the service connection request to the android system application end (i.e. the IPC client);
s32: the IPC server judges whether the application end declares the payment authority from the android payment application context,
if yes, step S33 is executed: the IPC server receives the payment service API call request and enters a command synchronization block;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s34: the IPC server side sends an API command request to an API command queue of the RPC client side;
s35: and the IPC server receives the call response of the API command queue and exits the command synchronizing block.
The RPC client for payment API call communicates with the secure processor through the serial bus, and uses JNI technology to access the serial bus device node in the linux operating system, the specific flow of which is shown in fig. 3:
s36: when the RPC client detects that an API command request exists in the API command queue, converting the API call request into an RPC request data packet, and performing DES encryption by using a communication key to generate an RPC request encryption packet;
s37: the RPC client sends an RPC request encryption packet to an RPC server of the security processor through a serial port;
s38: the RPC client receives the RPC response encryption packet of the security processor through the serial port and analyzes the RPC response encryption packet to obtain API call return data;
s39: and the RPC client sends the returned data to the IPC server of the payment service.
The specific flow of the RPC server for implementing payment API call in the secure processor is shown in fig. 4:
s371: the method comprises the steps that a secure processor RPC server receives an RPC request encryption packet sent by an RPC client;
s372: it is determined whether the data of the RPC request encryption packet is valid,
if yes, step S373 is executed: decrypting the RPC request encryption packet by using the communication key to obtain a payment service API request;
otherwise, returning to the step S371;
s374: executing a payment service API in the secure processor to obtain API call return data;
s375: the RPC server converts the API call return data into a response packet, and encrypts the response packet into an RPC response encryption packet by using a communication key;
s376: and the RPC server side sends the RPC response encryption packet to the RPC client side.
After the system is powered on, the general processor and the security processor perform mutual authentication and obtain a communication key, namely, the specific flow of step S4 is shown in fig. 5:
s41: at the general processor end, the general processor sends 8 bytes random numbers (first general random numbers) to the security processor;
s42: at the secure processor end, after receiving the 8-byte random number sent by the general processor, the secure processor generates an 8-byte random number (secure random number), combines the 8-byte random number to obtain a 16-byte first combined number, encrypts the first combined number by using an RSA private key 1 (namely a first RSA private key) and an RSA2048 algorithm, and then returns an encryption result (a first combined number ciphertext) and an RSA public key 1 (a first RSA public key) to the general processor;
s43: at the general processor end, the general processor decrypts the RSA encrypted data received from the security processor through the RSA public key 1, then judges whether the first 8 bytes random number of the decrypted 16 bytes random number (first combined number) is matched with the 8 bytes random number (first general random number) generated before the general processor (step S41), if not, authentication fails, the system stops starting and reports errors, and if so, the system enters S44;
s44: at the general processor end, the general processor generates 8 bytes random number (second general random number), combines the received safe random number and the second general random number to obtain 16 bytes second combined number, encrypts the second combined number by using RSA private key 2 (second RSA private key) and RSA2048 algorithm, and then sends the encryption result (second combined number ciphertext) and RSA public key 2 (second RSA public key) to the safe processor;
s45: at the secure processor side, the secure processor decrypts the RSA encrypted data received from the general purpose processor by the RSA public key 2, and compares the first 8 bytes of the decryption result (second combination number) with the 8-byte random number (secure random number) generated before the secure processor (step S42) for matching. If the result is not matched, the authentication fails, the security processor system stops starting and reports errors, and if the result is matched, S46 is entered;
s46: the authentication is successful, the security processor end and the general processor end both use the 8-byte random number generated by the security processor and the 8-byte random number generated by the general processor for the second time (namely the second combination number in the step S44) as encryption and decryption communication keys of the communication data of the security processor and the general processor RPC, so that the security of the communication process is ensured;
s47: the communication between the general purpose processor and the secure processor is thereafter 3DES encrypted using the communication key.
In summary, the invention provides a safe and convenient method, which ensures that the payment API of the POS terminal running in the secure processor can be transparently and reliably called by the general android application, supports the concurrent calling of multiple applications, and effectively expands the application range of the intelligent operating system in the secure payment field.
Correspondingly, the invention also provides a system for carrying out safe payment in the android system, which comprises a safe processor and a general processor which are connected through a serial bus, wherein the android system of the general processor is provided with a payment service manager interface, a payment service and a corresponding payment authority statement, the safe processor and the general processor carry out bidirectional authentication through the serial bus to obtain a communication key, the safe processor is provided with a safe payment interface, the android payment application uses the payment service manager interface to call a payment service, and the payment service uses the communication key to remotely and interactively call the safe payment interface of the safe processor according to the payment authority statement, so that safe payment is realized.
The security processor is internally provided with security information and a first RSA public-private key pair, and is set as an RPC server of a payment service API; the general processor runs the android system, a second RSA public-private key pair is built in the general processor, the payment service manager interface is set to be an IPC client of the payment service, and the payment service is set to be an IPC server and an RPC client.
The general processor sends a first general random number of 8 bytes to the security processor according to the payment service manager interface, the payment service and the permission statement thereof;
the security processor generates an 8-byte security random number, then combines the security random number with the first general random number to generate a 16-byte first combined number, encrypts the first combined number by using a first RSA private key to generate a first combined number ciphertext, and sends the first combined number ciphertext and the first RSA public key to the general processor;
the general processor decrypts the first combined number ciphertext according to the first RSA public key to obtain a 16-byte first combined number, judges whether the first 8-byte number of the first combined number is matched with the first general random number,
if the first combination number is matched with the second combination number, the general processor generates 8 bytes of a second general random number, the second general random number is combined with the security random number to generate 16 bytes of a second combination number, the second combination number is encrypted by using a second RSA private key to generate a second combination number ciphertext, and the second combination number ciphertext and the second RSA public key are sent to the security processor;
the security processor decrypts the second combined number ciphertext according to the second RSA public key to obtain a 16-byte second combined number, judges whether the first 8-byte number of the second combined number is matched with the security random number,
if the two numbers match, the security processor and the general processor set the second combination number as an encryption/decryption key of the RPC communication data to be used as a security payment communication key.
The foregoing description is only illustrative of the present invention and is not intended to limit the scope of the invention, and all equivalent changes made by the specification and drawings of the present invention, or direct or indirect application in the relevant art, are included in the scope of the present invention.
Claims (8)
1. A method for making secure payments in an android system, comprising at least the steps of:
s1: the safety processor and the general processor are connected through a serial bus;
s2: adding a payment service manager interface for the android system;
s3: adding payment service and corresponding payment authority statement for the android system;
s4: the security processor and the general processor perform mutual authentication through a serial bus to obtain a communication key; the method comprises the following steps:
s41: at the general processor end, according to the payment service manager interface, the payment service and the permission statement thereof, the general processor sends a first general random number of 8 bytes to the security processor;
s42: at the secure processor end, after receiving the 8-byte random number sent by the general processor, the secure processor generates an 8-byte secure random number, then the 8-byte secure random number is combined with the first general random number to obtain a 16-byte first combined number, the first combined number is encrypted by using a first RSA private key and an RSA2048 algorithm to generate a first combined number ciphertext, and then the first combined number ciphertext and the first RSA public key are returned to the general processor;
s43: at the general processor end, the general processor decrypts the first combined number ciphertext received from the security processor through a first RSA public key to obtain a first combined number of 16 bytes, then judges whether the first 8 bytes random number of the decrypted first combined number of 16 bytes is matched with the first general random number of 8 bytes generated before the general processor,
if not, step S6 is performed: displaying abnormality, failing authentication, stopping system starting and reporting error;
if a match will go to S44: at the general processor end, the general processor generates a second general random number of 8 bytes, combines the received safe random number with the second general random number to obtain a second combined number of 16 bytes, encrypts the second combined number by using a second RSA private key and an RSA2048 algorithm to generate a second combined number ciphertext, and then sends the second combined number ciphertext and a second RSA public key to the safe processor;
s45: at the secure processor end, the secure processor decrypts the second combined number ciphertext received from the general processor through the second RSA public key to obtain a 16-byte second combined number, compares the first 8 bytes of the second combined number with the secure random number generated before the secure processor to determine whether the first 8 bytes of the second combined number are matched,
if the results do not match, step S6 is performed: displaying abnormality, failing authentication, stopping starting and reporting error by the safety processor system;
if the result matches, S46 is entered: the authentication is successfully displayed, the security processor end and the general processor end both take the 8-byte random number generated by the security processor and the second combination number generated by the general processor for the second time as encryption and decryption communication keys of the communication data of the security processor and the general processor RPC, and the security of the communication process is ensured;
s47: the communication between the general processor and the safety processor adopts the communication key to carry out 3DES encryption;
s5: and adding a secure payment interface for the secure processor, calling a payment service by using the payment service manager interface by using the android payment application, and calling the secure payment interface of the secure processor by using the communication key in a remote interaction manner by using the payment service according to the payment authority statement to realize secure payment.
2. The method for performing secure payment in an android system according to claim 1, wherein the secure processor is internally provided with secure information, a first RSA public key and a first RSA private key, and the secure payment interface is set as an RPC server of a payment service API; the general processor runs the android system, a second RSA public key and a second RSA private key are built in the general processor, and the payment service is set to be an IPC server and an RPC client.
3. The method for making secure payments within the android system of claim 2, wherein step S2 is specifically:
s21: setting a payment service manager interface running in an android system application thread as an IPC client through an AIDL technology;
s22: the IPC client applies for connecting with the android system payment service manager interface, and detects whether the connection is successful,
if yes, step S23 is executed: the IPC client sends a secure payment API request to the payment service;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s24: and the IPC client obtains a feedback response of the payment service to analyze the secure payment API request.
4. The method for performing secure payment in an android system according to claim 3, wherein the IPC server in step S3 operates in the android system and uses a synchronization technology to implement a concurrent request of multiple applications, specifically:
s31: the IPC server line Cheng Jieshou applies the IPC client payment service connection request for android payment;
s32: the IPC server judges whether the application end declares the payment authority from the android payment application context,
if yes, step S33 is executed: the IPC server receives the payment service API call request and enters a command synchronization block;
otherwise, step S6 is executed: displaying abnormality and terminating the flow;
s34: the IPC server side sends an API command request to an API command queue of the RPC client side;
s35: and the IPC server receives the call response of the API command queue and exits the command synchronizing block.
5. The method for secure payment in an android system as recited in claim 4, wherein in step S3, the RPC client communicates with the secure processor through a serial bus, and uses JNI to access the serial bus device node, specifically:
s36: when the RPC client detects that an API command request exists in the API command queue, converting the API call request into an RPC request data packet, and performing DES encryption by using a communication key to generate an RPC request encryption packet;
s37: the RPC client sends an RPC request encryption packet to an RPC server of the security processor through a serial port;
s38: the RPC client receives the RPC response encryption packet of the security processor through the serial port and analyzes the RPC response encryption packet to obtain API call return data;
s39: and the RPC client sends the returned data to the IPC server of the payment service.
6. The method for secure payment within an android system as recited in claim 5, further comprising, between step S37 and step S38, the steps of:
s371: the method comprises the steps that a secure processor RPC server receives an RPC request encryption packet sent by an RPC client;
s372: it is determined whether the data of the RPC request encryption packet is valid,
if yes, step S373 is executed: decrypting the RPC request encryption packet by using the communication key to obtain a payment service API request;
otherwise, returning to the step S371;
s374: executing a payment service API in the secure processor to obtain API call return data;
s375: the RPC server converts the API call return data into a response packet, and encrypts the response packet into an RPC response encryption packet by using a communication key;
s376: and the RPC server side sends the RPC response encryption packet to the RPC client side.
7. The utility model provides a carry out system of safe payment in android system, its characterized in that includes safety processor and general processor that connects through serial bus, wherein the android system of general processor is equipped with payment service manager interface, payment service and corresponding payment authority statement, carries out the mutual authentication through serial bus between safety processor and the general processor, obtains the communication secret key, specifically is:
at the general processor end, according to the payment service manager interface, the payment service and the permission statement thereof, the general processor sends a first general random number of 8 bytes to the security processor;
at the secure processor end, after receiving the 8-byte random number sent by the general processor, the secure processor generates an 8-byte secure random number, then the 8-byte secure random number is combined with the first general random number to obtain a 16-byte first combined number, the first combined number is encrypted by using a first RSA private key and an RSA2048 algorithm to generate a first combined number ciphertext, and then the first combined number ciphertext and the first RSA public key are returned to the general processor;
at the general processor end, the general processor decrypts the first combined number ciphertext received from the security processor through a first RSA public key to obtain a first combined number of 16 bytes, then judges whether the first 8 bytes random number of the decrypted first combined number of 16 bytes is matched with the first general random number of 8 bytes generated before the general processor,
if the two types of information are not matched, displaying abnormality, failing authentication, stopping starting the system and reporting errors;
if the first combination number is matched with the second combination number, generating a second combination number of 8 bytes by the general processor, combining the received security random number with the second general random number to obtain a second combination number of 16 bytes, encrypting the second combination number by using a second RSA private key and an RSA2048 algorithm to generate a second combination number ciphertext, and then transmitting the second combination number ciphertext and a second RSA public key to the security processor;
at the secure processor end, the secure processor decrypts the second combined number ciphertext received from the general processor through the second RSA public key to obtain a 16-byte second combined number, compares the first 8 bytes of the second combined number with the secure random number generated before the secure processor to determine whether the first 8 bytes of the second combined number are matched,
if the result is not matched, displaying abnormality, failing authentication, stopping starting the safety processor system and reporting errors;
if the result matching shows that the authentication is successful, the security processor end and the general processor end both use the 8-byte random number generated by the security processor and the second combination number generated by the general processor for the second time as encryption and decryption communication keys of the communication data of the security processor and the general processor RPC, so that the security of the communication process is ensured;
the communication between the general processor and the safety processor adopts the communication key to carry out 3DES encryption;
and the secure processor is provided with a secure payment interface, the android payment application uses the payment service manager interface to call a payment service, and the payment service uses the communication key to remotely and interactively call the secure payment interface of the secure processor according to the payment authority statement, so that secure payment is realized.
8. The system for performing secure payment in an android system as recited in claim 7, wherein the secure processor is configured as an RPC server of the payment service API with secure information and the first RSA public key and the first RSA private key built in the secure processor; the general processor runs the android system, a second RSA public key and a first RSA private key are built in the general processor, the payment service manager interface is set to be an IPC client of the payment service, and the payment service is set to be an IPC server and an RPC client.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710811468.2A CN107705122B (en) | 2017-09-11 | 2017-09-11 | Method and system for carrying out safe payment in android system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710811468.2A CN107705122B (en) | 2017-09-11 | 2017-09-11 | Method and system for carrying out safe payment in android system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107705122A CN107705122A (en) | 2018-02-16 |
| CN107705122B true CN107705122B (en) | 2023-06-16 |
Family
ID=61172409
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710811468.2A Active CN107705122B (en) | 2017-09-11 | 2017-09-11 | Method and system for carrying out safe payment in android system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107705122B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111125667A (en) * | 2019-12-09 | 2020-05-08 | 北京握奇智能科技有限公司 | Roaming key calling method, device and system |
| CN114546536B (en) * | 2022-03-21 | 2022-07-05 | 北京麟卓信息科技有限公司 | Method for using same android application by multiple android applications on Linux platform |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102737311A (en) * | 2012-05-11 | 2012-10-17 | 福建联迪商用设备有限公司 | Internet bank security authentication method and system |
| CN104616148A (en) * | 2015-01-23 | 2015-05-13 | 恒银金融科技有限公司 | Payment terminal and paying method of wearable payment terminal |
| CN105761066A (en) * | 2016-02-04 | 2016-07-13 | 福建联迪商用设备有限公司 | Bank card password protection method and system |
| CN106529931A (en) * | 2016-11-30 | 2017-03-22 | 广州云移信息科技有限公司 | Intelligent POS payment safety management system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20080031965A (en) * | 2005-07-20 | 2008-04-11 | 베리메트릭스 인코퍼레이티드 | Network user authentication system and method |
| US9881300B2 (en) * | 2015-03-27 | 2018-01-30 | Intel Corporation | Technologies for split key security |
-
2017
- 2017-09-11 CN CN201710811468.2A patent/CN107705122B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102737311A (en) * | 2012-05-11 | 2012-10-17 | 福建联迪商用设备有限公司 | Internet bank security authentication method and system |
| CN104616148A (en) * | 2015-01-23 | 2015-05-13 | 恒银金融科技有限公司 | Payment terminal and paying method of wearable payment terminal |
| CN105761066A (en) * | 2016-02-04 | 2016-07-13 | 福建联迪商用设备有限公司 | Bank card password protection method and system |
| CN106529931A (en) * | 2016-11-30 | 2017-03-22 | 广州云移信息科技有限公司 | Intelligent POS payment safety management system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107705122A (en) | 2018-02-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3852338B1 (en) | Method and apparatus for verifying digital identity, device and storage medium | |
| US20210344495A1 (en) | Contactless card emulation system and method | |
| KR101544722B1 (en) | Method for performing non-repudiation, payment managing server and user device therefor | |
| US20240087394A1 (en) | Contactless card personal identification system | |
| US7571489B2 (en) | One time passcode system | |
| KR101878149B1 (en) | Device, system, and method of secure entry and handling of passwords | |
| US20150310427A1 (en) | Method, apparatus, and system for generating transaction-signing one-time password | |
| JP5006817B2 (en) | Authentication information generation system, authentication information generation method, client device, and program | |
| CN104217327A (en) | Financial IC (integrated circuit) card Internet terminal and trading method thereof | |
| CN114465726B (en) | Digital wallet security framework system based on security unit and trusted execution environment | |
| CN114070614B (en) | Identity authentication method, apparatus, device, storage medium and computer program product | |
| WO2018205456A1 (en) | Password input method, computer device, and storage medium | |
| CN104851206A (en) | USBKEY (universal serial bus key)-based online electric charge payment system | |
| KR102012262B1 (en) | Key management method and fido authenticator software authenticator | |
| KR20080087917A (en) | System for certify one-time password, system for issue a seed, and method for generating one-time password | |
| KR20090019576A (en) | Certification method and system for a mobile phone | |
| CN104835038A (en) | Networking payment device and networking payment method | |
| CN107705122B (en) | Method and system for carrying out safe payment in android system | |
| KR101494838B1 (en) | Account transfer method and system using transaction related otp | |
| TW201903678A (en) | Over-the-air card issuing method and apparatus | |
| JP2023547319A (en) | Data transmission methods, devices, systems, computer equipment and computer programs | |
| CN107563743B (en) | Method and system for improving POS transaction safety | |
| KR101604459B1 (en) | Method, apparatus and system for generating transaction related otp | |
| CN204066182U (en) | A kind of financial IC card internet terminal | |
| US20240144232A1 (en) | Systems and methods for terminal device attestation for contactless payments |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |