A smart ring-based NFC payment method and system, and a storage medium

Abstract

The application relates to the technical field of intelligent rings, in particular to an NFC payment method and system based on an intelligent ring and a storage medium.The method comprises the following steps: an NFC chip built in the intelligent ring senses a radio frequency field emitted by a payment terminal, collects a near field communication original signal, and generates an NFC handshake characteristic vector; dynamic key negotiation and a secure channel are established for the NFC handshake characteristic vector, a session key and a device identity authentication token are extracted, and an encrypted payment voucher is generated; the encrypted payment voucher is injected into a load field and returned to the payment terminal, the terminal analyzes the encrypted payment voucher to generate a transaction authorization request; a remote payment gateway is called based on the transaction authorization request to complete fund transfer, and a transaction confirmation code is returned to generate a payment completion receipt; the payment completion receipt is written into a secure storage area, a local transaction log and a remaining balance counter are updated, and account state synchronization data are generated.The application can greatly improve the anti-cracking capability of the payment voucher.

Description

Technical Field

[0001] This invention relates to the field of smart ring technology, and in particular to an NFC payment method, system, and storage medium based on a smart ring. Background Technology

[0002] With the continued popularization of mobile near-field payment technology, NFC payment is widely used in various scenarios such as supermarkets, public transportation, and access control due to its advantages of convenient operation and rapid interaction. Smartphone NFC payment is currently the mainstream solution, but smartphones have limitations such as being cumbersome to carry, requiring unlocking and screen activation, touchscreen malfunction in low temperatures, and inability to pay when temporarily out of power. Against this backdrop, smart rings, as lightweight wearable devices, with the characteristics of being wearable all day, hands-free, and always on standby, have become a new hardware carrier for near-field payment. Achieving NFC contactless payment based on smart rings is gradually becoming an important development direction in the wearable financial payment field. Most existing NFC payment solutions based on wearable devices follow the traditional interaction architecture of mobile phone NFC. The device simply completes the transmission and reception of standard NFC protocol frames, lacking feature mining of the original handshake signals during the NFC radio frequency interaction phase. Traditional solutions rely solely on a fixed hardware ID for identity verification, lacking a dynamic security negotiation mechanism in the radio frequency interaction process. The key remains fixed for a long time, and once the device's identity information is stolen or intercepted, it can easily lead to financial security risks such as counterfeit devices, fraudulent transactions, and credit card fraud. Summary of the Invention

[0003] Therefore, the present invention needs to provide an NFC payment method, system and storage medium based on a smart ring to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, an NFC payment method based on a smart ring includes the following steps: Step S1: The NFC chip built into the smart ring senses the radio frequency field emitted by the payment terminal, collects the raw near-field communication signal containing carrier amplitude fluctuations and phase jitter, and generates an NFC handshake feature vector. Step S2: Perform dynamic key negotiation and secure channel establishment on the NFC handshake feature vector, extract the session key and device authentication token, and generate encrypted payment credentials; Step S3: Inject the encrypted payment credential into the payload field of the NFC data frame and transmit it back to the payment terminal via the modulated radio frequency signal. The terminal parses the data and generates a transaction authorization request. Step S4: Based on the transaction authorization request, call the remote payment gateway to complete the fund transfer. The gateway returns a transaction confirmation code and generates a payment completion receipt. Step S5: Write the payment completion receipt to the secure storage area of ​​the smart ring, update the local transaction log and remaining balance counter, and generate account status synchronization data.

[0005] Furthermore, step S1 includes the following steps: Step S11: Activate the NFC front-end circuit of the smart ring to enter polling mode, detect the 13.56MHz carrier signal emitted by the payment terminal, collect the carrier amplitude change curve over time, and generate a carrier envelope sequence; Step S12: Perform differential operation on the carrier envelope sequence to extract amplitude abrupt change points and stable interval boundaries, and generate a carrier modulation edge feature set; Step S13: Separate the query request frame header sent by the terminal from the carrier modulation edge feature set, parse the protocol version and command type fields in the frame header, and generate the terminal capability description vector; Step S14: Determine the NFC data exchange format supported by the payment terminal based on the terminal capability description vector, select the corresponding encoding mapping table, and generate a handshake parameter configuration set; Step S15: The handshake parameter configuration set and the phase jitter features extracted from the carrier envelope sequence are fused and encoded to generate the NFC handshake feature vector.

[0006] Furthermore, step S2 includes the following steps: Step S21: Extract the terminal public key certificate and random challenge number from the NFC handshake feature vector, call the private key in the smart ring's security element to digitally sign the challenge number, and generate a signature response data block; Step S22: Concatenate the signature response data block with the ring identity identifier and send it to the terminal. After verifying the signature's validity, the terminal generates a session key seed and encrypts and sends it back to the smart ring. Step S23: After receiving the encrypted session key seed, the smart ring uses the derived function within the secure element to calculate the symmetric encryption key and generate the session key; Step S24: Encrypt the user payment account index stored in the smart ring based on the session key to generate an encrypted account index block; Step S25: Assemble the encrypted account index block and the device authentication token into a structured data packet to generate an encrypted payment credential.

[0007] Furthermore, step S23 includes the following steps: Step S231: Input the encrypted session key seed into the hardware true random number generator in the secure element, extract the entropy source component in the seed, and generate the initial key material; Step S232: Perform key derivation operation based on SM3 hash algorithm on the initial key material to generate a 256-bit intermediate key; Step S233: XOR the intermediate key with the ring's unique serial number to eliminate the statistical correlation between the key and the seed, and generate a hybrid key vector; Step S234: Perform key verification on the hybrid key vector, calculate its Hamming distance with the preset verification mode, and if the distance is less than the threshold, the verification is passed and a verification pass flag is generated; Step S235: Encapsulate the confirmation flag and the hybrid key vector into a key object, store it in the temporary key slot of the secure element, and generate a session key.

[0008] Furthermore, step S233 includes the following steps: The intermediate key is split into sixteen 16-byte sub-blocks to generate a sub-block sequence; Read the unique serial number pre-programmed within the secure area of ​​the smart ring, split it into segments of equal length and align them with the sub-block sequence to generate aligned serial number fragments; Perform a byte-by-byte XOR operation on each sub-block and its corresponding alignment sequence number segment to generate the XORed sub-block; The XORed sub-blocks are concatenated in their original order, and a cyclic shift operation is applied to them. The number of shifts is determined by the lower four bits of the current timestamp, generating the shifted key vector. The shifted key vector is subjected to byte diffusion permutation, and the byte order is shuffled by table lookup and replacement to generate a hybrid key vector.

[0009] Furthermore, step S3 includes the following steps: Step S31: Load the encrypted payment credential into the payload field of the NFC data frame, fill in the start flag, length field and CRC check code according to the frame structure specified in the ISO14443 protocol, and generate the data frame to be sent; Step S32: Perform Manchester encoding on the data frame to be sent, convert the binary bit stream into a load modulation signal, and generate a baseband modulation waveform; Step S33: The baseband modulation waveform is superimposed on the carrier signal through the load modulation circuit of the NFC antenna to generate the return radio frequency signal; Step S34: After the antenna coil of the payment terminal senses the returned radio frequency signal, it demodulates and decodes it to recover the encrypted payment certificate and generate the terminal-side decryption input. Step S35: The terminal uses the previously negotiated session key to decrypt the decryption input, extracts the user's payment account index and transaction amount, and generates a transaction authorization request.

[0010] Furthermore, step S4 includes the following steps: Step S41: The payment terminal sends the transaction authorization request to the acquiring institution's server through an encrypted network channel. The server parses the account index and amount fields in the request and generates a clearing instruction. Step S42: The acquiring institution's server forwards the clearing instruction to the issuing bank's payment gateway. The gateway verifies the account balance and transaction limit, and generates an authorization approval code or a rejection code. Step S43: The issuing bank's payment gateway encapsulates the authorization approval code or rejection code into a response message and sends it back to the payment terminal along the original path, generating terminal-side response data; Step S44: The payment terminal parses the terminal-side response data. If it is an approval code, it extracts the transaction serial number and timestamp to generate a transaction confirmation code. Step S45: Combine the transaction confirmation code with the transaction amount and merchant number to form a payment completion receipt, and write it to the smart ring via NFC reverse link.

[0011] Furthermore, step S42 includes the following steps: Step S421: The issuing bank's payment gateway parses the account index in the clearing instruction, maps it to the corresponding user account database record, extracts the account balance and daily cumulative transaction amount, and generates an account status snapshot; Step S422: Compare the transaction amount with the available balance in the account status snapshot. If the balance is sufficient, proceed to the next step; otherwise, generate a rejection code and generate a balance determination result. Step S423: If the balance determination result is sufficient, further check whether the transaction amount triggers risk control rules, including single transaction limit and frequency limit, and generate a risk control compliance mark; Step S424: Concatenate the risk control compliance flag with the account activity score obtained based on the account status snapshot into a two-dimensional feature vector, and input it into the pre-trained decision tree model; the decision tree model traverses from the root node to the leaf node, and each internal node selects a branch according to the feature threshold to generate a path encoding sequence; the authorization probability value stored in the leaf node is activated. If the authorization probability value is greater than the preset threshold, it is determined to be authorized; otherwise, it is determined to be rejected, generating a preliminary authorization conclusion; perform a logical AND operation between the preliminary authorization conclusion and the account's historical default records. If there are default records, it is forcibly converted to rejection, generating a final authorization conclusion; encode the final authorization conclusion into a binary vector, and attach the path encoding sequence of the decision tree as the audit basis to generate an authorization decision vector; Step S425: Encode the authorization decision vector into an authorization approval code or a rejection code, and attach the issuing bank's digital signature to prevent tampering, thereby generating the authorization approval code or rejection code.

[0012] Furthermore, the present invention also provides an NFC payment system based on a smart ring, including a processor, a memory, and a computer program stored in the memory and executable on the processor, for performing the NFC payment method based on a smart ring as described above.

[0013] Furthermore, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the NFC payment method based on a smart ring as described above.

[0014] The beneficial effects of this invention are: The NFC payment method, system, and storage medium based on a smart ring proposed in this invention offer several advantages over existing technologies. Firstly, by using the NFC chip embedded in the smart ring to sense the radio frequency field of the payment terminal, the invention collects raw near-field communication signals containing carrier amplitude fluctuations and phase jitter, constructing a unique NFC handshake feature vector. This step fully captures the unique dynamic radio frequency changes during NFC near-field interaction, transforming the physical layer fluctuation information of hardware interaction into a multi-dimensional handshake feature vector. This forms a unique bio-radio frequency feature base for each interaction scenario, overcoming the security deficiencies of traditional static identifiers and providing irreplaceable original feature support for subsequent dynamic key negotiation and device security authentication. Secondly, dynamic key negotiation and secure channel establishment are carried out based on the NFC handshake feature vector. Real-time session keys and device authentication tokens are extracted to generate dynamic encrypted payment credentials. This step utilizes the unique handshake feature vector generated by each interaction to complete real-time key negotiation, ensuring that the session key and authentication token for each transaction have dynamic change characteristics. This overcomes the security vulnerabilities of fixed key systems, constructs a temporary dedicated secure transmission channel, significantly improves the anti-cracking capability of payment credentials, and avoids the risk of counterfeiting and fraudulent transactions from the source of interaction. The dynamically generated encrypted payment credential is filled into the payload field of the NFC data frame and transmitted back to the payment terminal via radio frequency signal. The terminal parses the data frame to generate a compliant transaction authorization request. This step integrates the dynamically negotiated encrypted credential into the data frame payload, ensuring that every transaction carries real-time security verification information. This enhances the integrity and confidentiality of NFC interaction data, guarantees the authenticity and validity of the data received by the terminal, prevents external data tampering from initiating fraudulent transactions, and standardizes the pre-transaction process for transaction authorization. Based on the terminal's transaction authorization request, the system connects to a remote payment gateway to complete the fund transfer. The system receives the transaction confirmation code returned by the gateway and generates a payment completion receipt. This step establishes a link between the front-end NFC secure interaction and the back-end financial gateway verification. The remote gateway completes standardized fund transfer and transaction legality verification. A second comparison of the back-end key and transaction parameters confirms the transaction result, forming a closed-loop transaction system with front-end encryption and back-end verification. This effectively avoids the security risks of unauthorized transactions passing verification. By writing the payment completion receipt to the secure storage area of ​​the smart ring, the local transaction log and remaining balance counter are updated synchronously, generating real-time account status synchronization data. This step completes the closed-loop update of local data after the transaction is completed, retains a complete record of the transaction process, and synchronizes the account remaining balance status in real time. This enables each transaction to be traceable and the account status to be updated in real time, improving the back-end management and security traceability capabilities of wearable payment devices. Attached Figure Description

[0015] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the steps of the NFC payment method based on a smart ring according to the present invention; Figure 2 for Figure 1 A detailed flowchart of step S1; Figure 3 for Figure 1 A detailed flowchart of step S2. Detailed Implementation

[0016] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0017] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0018] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0019] To achieve the above objectives, please refer to Figure 1 This invention provides an NFC payment method based on a smart ring, comprising the following steps: Step S1: The NFC chip built into the smart ring senses the radio frequency field emitted by the payment terminal, collects the raw near-field communication signal containing carrier amplitude fluctuations and phase jitter, and generates an NFC handshake feature vector. In this embodiment, when the NFC chip built into the smart ring senses the radio frequency field emitted by the payment terminal, the RF front-end circuit inside the NFC chip continuously monitors the presence or absence of a 13.56MHz carrier signal. The RF front-end circuit includes a peak detector, whose output DC voltage value is proportional to the carrier amplitude. When acquiring the raw near-field communication signal containing carrier amplitude fluctuations and phase jitter, the analog-to-digital converter samples the DC voltage output by the peak detector at a rate of 20 mega-samples per second. Sampling lasts for 300 microseconds, generating a discrete-time sequence consisting of 6000 sample points. Simultaneously, the phase-locked loop inside the NFC chip locks the carrier frequency and outputs a phase error signal. The phase error signal is digitized at the same sampling rate after passing through a low-pass filter, generating a phase jitter sequence. The amplitude sequence and the phase jitter sequence are aligned in time and merged into a dual-channel raw signal matrix. This matrix is ​​normalized by dividing the value of each channel by its maximum absolute value, so that the value range falls between -1 and 1. The normalized matrix is ​​subjected to Fourier transform to extract spectral features, retaining the amplitude spectral coefficients in the 0 to 1 MHz frequency band. These amplitude spectral coefficients are concatenated with the original time-domain sequence to form an 8192-dimensional feature vector. This feature vector is the NFC handshake feature vector.

[0020] Step S2: Perform dynamic key negotiation and secure channel establishment on the NFC handshake feature vector, extract the session key and device authentication token, and generate encrypted payment credentials; In this embodiment, during dynamic key negotiation on the NFC handshake feature vector, the first 4096 dimensions of the NFC handshake feature vector are fed into the elliptic curve key generation engine within the secure element. The key generation engine extracts the entropy source from the feature vector and generates a 256-bit temporary private key through hashing. The temporary private key is exchanged with the terminal public key broadcast by the payment terminal using elliptic curve Diffie-Hellman key exchange to calculate the shared secret. The shared secret is processed by a key derivation function to generate a 256-bit session key. The device authentication token is read from the read-only storage area of ​​the secure element and contains the SHA-256 hash value of the ring serial number. The session key is used to encrypt the user payment account index stored on the smart ring. The user payment account index is a 128-bit binary string pointing to the default payment account. The encryption algorithm uses AES-256-GCM mode, and the initialization vector is provided by a hardware counter. The encrypted ciphertext is combined with the authentication tag to form an encrypted account index block. The encrypted account index block is concatenated with the device authentication token, with a total length of 512 bits. The concatenated data block is the encrypted payment credential.

[0021] Step S3: Inject the encrypted payment credential into the payload field of the NFC data frame and transmit it back to the payment terminal via the modulated radio frequency signal. The terminal parses the data and generates a transaction authorization request. In this embodiment, when the encrypted payment credential is injected into the payload field of the NFC data frame, the frame structure of the NFC data frame includes a 1-byte start flag (0x7E), a 1-byte length field (0x20), a 32-byte payload field, and a 2-byte CRC-16 checksum. The encrypted payment credential is filled into the payload field. The start flag, length field, payload field, and CRC checksum are arranged sequentially to generate a 36-byte data frame to be sent. The data frame to be sent is Manchester encoded, with each bit converted into a signal unit. Bit 0 corresponds to a high level in the first half-cycle and a low level in the second half-cycle, and bit 1 corresponds to a low level in the first half-cycle and a high level in the second half-cycle. The encoded baseband modulation waveform is superimposed onto the 13.56MHz carrier signal through the payload modulation circuit of the NFC antenna. The payload modulation circuit uses a MOSFET switch to control the parallel resistance of the antenna coil, and the modulation depth is set to 10%. After the antenna coil of the payment terminal senses the return RF signal, the baseband waveform is demodulated by the envelope detector, and the Manchester decoder reconstructs the data frame. The terminal extracts the 32-byte data from the payload field, which is the encrypted payment credential. The terminal uses the previously negotiated session key to decrypt the encrypted payment credential using AES-256-GCM, recovering the user's payment account index. The user's payment account index is then combined with the transaction amount to generate a transaction authorization request.

[0022] Step S4: Based on the transaction authorization request, call the remote payment gateway to complete the fund transfer. The gateway returns a transaction confirmation code and generates a payment completion receipt. In this embodiment, when a remote payment gateway is invoked based on a transaction authorization request, the request is sent to the acquiring institution's server via a TLS 1.3 encrypted network channel. The acquiring institution's server parses the user's payment account index and transaction amount in the request and generates a clearing instruction. The clearing instruction is forwarded to the issuing bank's payment gateway via a dedicated financial network. The issuing bank's payment gateway verifies the account balance against the transaction limit. The account balance verification compares the available balance with the transaction amount using a subtraction operation. The transaction limit verification checks the single transaction limit of 500,000 points and the frequency limit of 3 transactions within 60 seconds. After successful verification, the issuing bank's payment gateway generates an authorization approval code. The authorization approval code is a 6-digit decimal number, generated by encoding the authorization decision vector and attaching an RSA digital signature. The authorization approval code is encapsulated into an ISO 8583 response message and transmitted back to the payment terminal along the original path. The payment terminal parses the response message and extracts the transaction serial number and timestamp from the authorization approval code. The transaction serial number and timestamp are combined to generate a transaction confirmation code. The transaction confirmation code, combined with the transaction amount and merchant number, forms a payment completion receipt.

[0023] Step S5: Write the payment completion receipt to the secure storage area of ​​the smart ring, update the local transaction log and remaining balance counter, and generate account status synchronization data.

[0024] In this embodiment, when writing the payment completion receipt to the secure storage area of ​​the smart ring, the secure storage area is located in the non-volatile memory of the secure element and has a capacity of 64KB. The payment completion receipt data is 320 bits long and is written to a specified address space. Before the write operation, the secure element performs an erase operation, resetting the storage unit at the target address to an all-1 state. After erasure, the write enable signal is activated, and the data is written byte by byte. After the write is completed, a read verification operation compares the written data with the original data to ensure consistency. When updating the local transaction log, the transaction log is stored in another independent area of ​​the secure element, using a circular buffer structure. The buffer size is 128 records, and each record contains a transaction serial number, transaction amount, timestamp, and merchant number. New records are appended to the end of the buffer; if the buffer is full, the oldest record is overwritten. When updating the remaining credit counter, the remaining credit counter is stored in the register of the secure element, with an initial value of 10,000,000 points. After each transaction, the counter is deducted from the transaction amount. The subtraction operation is performed by the arithmetic logic unit of the secure element. The updated counter value is written back to the register. The account status synchronization data consists of the latest record in the transaction log and the remaining balance counter value, with a total length of 512 bits. This synchronization data is used by the smart ring and payment terminal to verify the status during the next transaction.

[0025] Furthermore, as an embodiment of the present invention, reference is made to... Figure 2 As shown, Figure 1 A detailed flowchart of step S1 is shown below. In this embodiment, step S1 includes the following steps: Step S11: Activate the NFC front-end circuit of the smart ring to enter polling mode, detect the 13.56MHz carrier signal emitted by the payment terminal, collect the carrier amplitude change curve over time, and generate a carrier envelope sequence; Step S12: Perform differential operation on the carrier envelope sequence to extract amplitude abrupt change points and stable interval boundaries, and generate a carrier modulation edge feature set; Step S13: Separate the query request frame header sent by the terminal from the carrier modulation edge feature set, parse the protocol version and command type fields in the frame header, and generate the terminal capability description vector; Step S14: Determine the NFC data exchange format supported by the payment terminal based on the terminal capability description vector, select the corresponding encoding mapping table, and generate a handshake parameter configuration set; Step S15: The handshake parameter configuration set and the phase jitter features extracted from the carrier envelope sequence are fused and encoded to generate the NFC handshake feature vector.

[0026] In this embodiment, the NFC front-end circuit of the smart ring is activated to enter polling mode. This polling mode is achieved by periodically activating the radio frequency field detection function, with the detection frequency set to repeat 50 times per second. When detecting the 13.56MHz carrier signal emitted by the payment terminal, the envelope detector built into the NFC front-end circuit demodulates the amplitude of the received radio frequency signal. The envelope detector outputs an analog voltage value, which is proportional to the carrier amplitude. When acquiring the carrier amplitude variation curve over time, the analog-to-digital converter samples the output voltage of the envelope detector at a rate of 10 mega-samples per second, generating a discrete-time sequence. This discrete-time sequence constitutes a carrier envelope sequence with a length of 2000 sampling points, covering the complete time window required for the payment terminal to send a single query command. When performing differential operations on the carrier envelope sequence, the differential operation module calculates the amplitude difference between adjacent sampling points. The differential operation formula is as follows: ,in Indicates the first The amplitude value of each sampling point Indicates the first The differential results are analyzed. When extracting amplitude abrupt change points and stable interval boundaries, an amplitude change threshold is set. The amplitude change threshold is 15% of the maximum amplitude of the carrier envelope sequence. When the absolute value of the differential result exceeds this threshold, the corresponding sampling point is marked as an amplitude abrupt change point. The stable interval boundary is defined as the start and end point of the interval where the differential results of 5 consecutive sampling points are all below the threshold. The coordinates of all marked amplitude abrupt change points and stable interval boundary coordinates are combined to form a carrier modulation edge feature set. This feature set contains the rising edge, falling edge, and plateau region location information of the signal transmitted by the payment terminal. When separating the query request frame header issued by the terminal from the carrier modulation edge feature set, the frame header identification logic matches according to the frame start delimiter pattern defined by the NFC protocol. The frame start delimiter pattern consists of a low-level interval of a specific length followed by a high-level transition. The length of the low-level interval is limited to 10 microseconds to 20 microseconds. The duration of the high-level transition is limited to 2 microseconds to 5 microseconds. When two consecutive edge points in the carrier modulation edge feature set satisfy the above timing constraints, the interval between these two edge points is determined as the frame start delimiter. The eight consecutive bits following the frame start delimiter constitute the frame header content. When parsing the protocol version and command type fields in the frame header, the first four bits of the frame header are mapped to the protocol version number, and the last four bits are mapped to the command type number. The protocol version number and command type number are converted into binary values ​​through a lookup table. The binary values ​​are compared with the pre-stored protocol version library and command type library. If the comparison is successful, a terminal capability description vector is generated. The terminal capability description vector is a 16-dimensional binary vector, with each dimension corresponding to a functional feature supported by the terminal, such as whether it supports the ISO / IEC 14443A protocol, whether it supports the MIFARE Classic encryption algorithm, and whether it supports the NFC data exchange format NDEF, etc. When determining the NFC data exchange format supported by the payment terminal based on the terminal capability description vector, the judgment logic traverses each dimension of the terminal capability description vector. When a certain dimension indicates support for a certain data exchange format, the encoding mapping table corresponding to that format is used as a candidate. The encoding mapping table defines the byte order, field length, and padding rules for various fields in the payment account information. For example, for the bank card number field, the encoding mapping table specifies that the card number is arranged from left to right, each decimal digit is represented by a 4-bit BCD code, and the total field length is fixed at 16 bytes. After selecting the corresponding encoding mapping table, a handshake parameter configuration set is generated. The handshake parameter configuration set includes the index number of the selected encoding mapping table, the data block size, the verification method, and the number of timeout retransmissions. The data block size is set to 256 bytes. The verification method is Cyclic Redundancy Check (CRC-16). The number of timeout retransmissions is set to 3. When fusing the handshake parameter configuration set with the phase jitter features extracted from the carrier envelope sequence, the phase jitter feature extraction method is as follows: Perform a Hilbert transform on the carrier envelope sequence to obtain the instantaneous phase sequence.The phase deviation sequence is obtained by subtracting the ideal carrier phase from the instantaneous phase sequence. The standard deviation of the phase deviation sequence is used as the phase jitter feature value. The fusion coding process converts each parameter value in the handshake parameter configuration set into a binary string, and then interleaves and concatenates the binary string with the binary representation of the phase jitter feature value. The concatenation rule is: the first bit of the handshake parameter configuration set is alternated with the first bit of the phase jitter feature value, and subsequent bits are placed in the same manner. The final generated binary string is 512 bits long, and this binary string is the NFC handshake feature vector.

[0027] Furthermore, as an embodiment of the present invention, reference is made to... Figure 3 As shown, Figure 1 A detailed flowchart of step S2 is shown below. In this embodiment, step S2 includes the following steps: Step S21: Extract the terminal public key certificate and random challenge number from the NFC handshake feature vector, call the private key in the smart ring's security element to digitally sign the challenge number, and generate a signature response data block; Step S22: Concatenate the signature response data block with the ring identity identifier and send it to the terminal. After verifying the signature's validity, the terminal generates a session key seed and encrypts and sends it back to the smart ring. Step S23: After receiving the encrypted session key seed, the smart ring uses the derived function within the secure element to calculate the symmetric encryption key and generate the session key; Step S24: Encrypt the user payment account index stored in the smart ring based on the session key to generate an encrypted account index block; Step S25: Assemble the encrypted account index block and the device authentication token into a structured data packet to generate an encrypted payment credential.

[0028] In this embodiment, when extracting the terminal public key certificate and random challenge number from the NFC handshake feature vector, the first 256 bits of the NFC handshake feature vector are decoded into a digest of the terminal public key certificate. This digest is used to locate the corresponding complete certificate file in the smart ring's local certificate cache. The certificate cache pre-stores 10 certified payment terminal public key certificates. The found complete certificate file contains the elliptic curve parameters of the terminal public key and the coordinates of the public key points. The last 256 bits of the NFC handshake feature vector are decoded into a random challenge number. The random challenge number is a 128-bit pseudo-random number generated by the payment terminal during the handshake phase. When the private key within the smart ring's secure element is used to digitally sign the challenge number, the elliptic curve digital signature algorithm engine integrated within the secure element performs the signature operation. The signature operation first calculates the hash value of the random challenge number using the SHA-256 hash algorithm. Then, the private key stored in the secure element's non-volatile memory is used to perform elliptic curve multiplication on the hash value. The private key is 256 bits long, corresponding to the secp256k1 elliptic curve. The signature operation generates two integers, r and s, each 256 bits long. r and s are packaged in DER encoding format to generate a signature response data block. The total length of the signature response data block is 72 bytes. When the signature response data block is concatenated with the ring identifier (a 64-bit unique number written to the read-only area of ​​the secure element at the factory) and sent to the terminal, the ring identifier is concatenated first, followed by the signature response data block, without any separator. The total length of the concatenated data packet is 80 bytes. The smart ring sends the concatenated data packet to the payment terminal via the NFC front-end circuit's data transmission channel. After receiving the data packet, the payment terminal extracts the ring identifier and retrieves the corresponding ring public key from its local database. The payment terminal uses the ring public key to verify the legitimacy of the signature response data block. The verification process includes recalculating the hash value of the random challenge number and verifying the r and s values ​​in the signature using the ring public key. After successful verification, the payment terminal generates a 256-bit session key seed. The session key seed is generated by the payment terminal's hardware true random number generator. The payment terminal uses the ring's public key to perform elliptic curve cryptography on the session key seed, generating encrypted ciphertext. The encrypted ciphertext is 512 bytes long. The payment terminal sends the encrypted ciphertext back to the smart ring. After receiving the encrypted session key seed, the smart ring calculates the symmetric encryption key using a derived function within the secure element. The secure element first decrypts the encrypted ciphertext using its own private key to recover the original session key seed. The derived function is implemented based on the HMAC-SHA256 algorithm. The input to the derived function includes the session key seed and a fixed context label. The context label is set to the string "SESSION_KEY". The derived function performs two HMAC operations.The first HMAC operation uses the session key seed as the key and the context tag as the message to generate a 256-bit intermediate value. The second HMAC operation uses the intermediate value as the key and an empty string as the message to generate the final 256-bit symmetric encryption key. This symmetric encryption key is the session key. When encrypting the user payment account index stored in the smart ring based on the session key, the user payment account index is a 128-bit binary string pointing to the default payment account record bound to the user in the smart ring's storage space. The encryption algorithm uses AES-256-GCM mode. AES-256-GCM mode requires a session key, an initialization vector, and additional authentication data. The initialization vector is generated by a counter inside the secure element, which increments by 1 each time. The additional authentication data is set as the ring's identity identifier. The encryption process takes the user payment account index as plaintext input, and the AES-256-GCM encryption engine outputs ciphertext and an authentication tag. The ciphertext length is 128 bits, and the authentication tag length is 128 bits. The ciphertext and authentication tag are merged to generate an encrypted account index block. The total length of the encrypted account index block is 256 bits. When assembling the encrypted account index block and the device authentication token into a structured data packet, the device authentication token is generated by the secure element during the startup phase. The device authentication token contains a hash of the ring serial number, production batch number, and firmware version number. During assembly, the encrypted account index block is placed at the beginning of the data packet, and the device authentication token is placed at the end. A 4-byte length field is added to the data packet header, indicating the total length of the entire data packet. A 2-byte checksum field is added to the data packet tail, with the checksum value being the XOR sum of all bytes in the data packet. The assembled data packet constitutes the encrypted payment credential.

[0029] Furthermore, step S23 includes the following steps: Step S231: Input the encrypted session key seed into the hardware true random number generator in the secure element, extract the entropy source component in the seed, and generate the initial key material; Step S232: Perform key derivation operation based on SM3 hash algorithm on the initial key material to generate a 256-bit intermediate key; Step S233: XOR the intermediate key with the ring's unique serial number to eliminate the statistical correlation between the key and the seed, and generate a hybrid key vector; Step S234: Perform key verification on the hybrid key vector, calculate its Hamming distance with the preset verification mode, and if the distance is less than the threshold, the verification is passed and a verification pass flag is generated; Step S235: Encapsulate the confirmation flag and the hybrid key vector into a key object, store it in the temporary key slot of the secure element, and generate a session key.

[0030] In this embodiment, when the encrypted session key seed is input into the hardware true random number generator within the secure element, the encrypted session key seed is injected into the entropy pool of the hardware true random number generator as an external entropy source. The hardware true random number generator integrates a ring oscillator array. The ring oscillator array contains 32 independent oscillator rings, each with a slightly different frequency due to process variations. The output signals of the oscillator rings are combined through an XOR gate to generate a random bit stream. Bits in the encrypted session key seed are used to perturb the bias voltage of the oscillator rings, altering their phase noise characteristics. When extracting the entropy source component from the seed, the hardware true random number generator continuously samples the output of the oscillator rings. The sampling frequency is set to 100 MHz. After 1000 consecutive sampling cycles, the collected random bit stream constitutes the initial entropy source data. The initial entropy source data is processed by a von Neumann corrector to remove bias, generating a uniformly distributed random bit sequence. This random bit sequence is the initial key material. The initial key material is 1024 bits long. When performing key derivation operations based on the SM3 hash algorithm on the initial key material, the SM3 hash algorithm engine receives the initial key material as input. The SM3 algorithm groups the input message into 512-bit message blocks. Each message block is processed by a 64-round iterative compression function. The iterative compression function includes message expansion, permutation, XOR, and modulo addition operations. The initial key material is divided into two 512-bit message blocks. The first message block undergoes the first round of SM3 operation to generate a 256-bit intermediate hash value. The second message block is concatenated with the intermediate hash value and then subjected to SM3 operation again to generate the final 256-bit hash value. This hash value is the 256-bit intermediate key. When XORing the intermediate key with the ring's unique serial number, the ring's unique serial number is a 256-bit binary string stored in the fuse unit of the secure element. The XOR operation is performed bit by bit. For each bit, the bit of the intermediate key is XORed with the corresponding bit of the ring's unique serial number. The result of the XOR operation replaces the original bit of the intermediate key. After XOR mixing, each bit in the intermediate key depends on the corresponding bit of the ring's unique serial number. This operation eliminates the statistical correlation between the key and the seed. The XOR mixing generates a mixed key vector. The mixed key vector remains 256 bits long. When performing key verification on the mixed key vector, the key verification module reads a preset verification pattern from within the secure element. The preset verification pattern is a fixed 256-bit binary string stored in the secure element's read-only memory. The content of the verification pattern is a sequence of all 1s. To calculate the Hamming distance between the mixed key vector and the preset verification pattern, the two binary strings are compared bit by bit. For each bit, if the bit in the mixed key vector matches the bit in the preset verification pattern, the count is incremented by 0; otherwise, the count is incremented by 1. The Hamming distance value is obtained after counting all 256 comparison results. The Hamming distance value ranges from 0 to 256. A threshold of 128 is set. If the Hamming distance is less than 128, the verification passes.After successful verification, a confirmation flag is generated. The confirmation flag is a Boolean value, taking the value true. When encapsulating the confirmation flag and the hybrid key vector into a key object, the encapsulation format of the key object is defined as follows: The first 8 bytes of the key object store the binary representation of the confirmation flag. The true value of the confirmation flag is mapped to the hexadecimal number 0x01. Bytes 9 to 40 of the key object store the 256-bit binary data of the hybrid key vector. The last 4 bytes of the key object store the CRC-32 value. The CRC-32 value is calculated from the first 40 bytes of the key object. The total length of the encapsulated key object is 44 bytes. This key object is stored in the temporary key slot of the secure element. The temporary key slot is a static random access memory area within the secure element, with a capacity of 512 bytes. After the storage operation is completed, the session key can be used for subsequent encryption processes.

[0031] Furthermore, step S233 includes the following steps: The intermediate key is split into sixteen 16-byte sub-blocks to generate a sub-block sequence; Read the unique serial number pre-programmed within the secure area of ​​the smart ring, split it into segments of equal length and align them with the sub-block sequence to generate aligned serial number fragments; Perform a byte-by-byte XOR operation on each sub-block and its corresponding alignment sequence number segment to generate the XORed sub-block; The XORed sub-blocks are concatenated in their original order, and a cyclic shift operation is applied to them. The number of shifts is determined by the lower four bits of the current timestamp, generating the shifted key vector. The shifted key vector is subjected to byte diffusion permutation, and the byte order is shuffled by table lookup and replacement to generate a hybrid key vector.

[0032] In this embodiment, when the intermediate key is split into sixteen 16-byte sub-blocks, the total length of the intermediate key is 256 bits, or 32 bytes. The splitting operation is performed byte by byte. The first sub-block contains bytes 1 to 16 of the intermediate key, and the second sub-block contains bytes 17 to 32. The length of each sub-block is fixed at 16 bytes. The sixteen sub-blocks are numbered sequentially from 0 to 15. The sub-block sequence is stored in a temporary register group of the secure element, with a capacity of 256 bytes. When reading the pre-programmed unique serial number within the secure area of ​​the smart ring, the unique serial number is stored in the fuse array of the secure element. The fuse array is programmed and written once during the chip manufacturing stage and cannot be changed afterward. The unique serial number is 128 bits long, or 16 bytes. When splitting the unique serial number into sub-blocks of the same length, since the unique serial number itself is only 16 bytes, no further splitting is required. The unique serial number is aligned as a whole with the sub-block sequence. The alignment method is: a one-to-one correspondence between the unique serial number and each sub-block. For sub-block number 0, the corresponding alignment sequence number segment is the unique sequence number itself. For sub-blocks numbered 1 to 15, the corresponding alignment sequence number segment is also the same unique sequence number. The alignment sequence number segment sequence contains sixteen identical 16-byte segments. When performing a byte-by-byte XOR operation on each sub-block and its corresponding alignment sequence number segment, the XOR operation is performed at the byte level. For each byte in the sub-block, the byte at the same position in the alignment sequence number segment is extracted, and the two bytes are XORed bitwise. The result of the XOR operation is a new byte. For example, if the first byte in the sub-block is 0xA5 and the first byte in the alignment sequence number segment is 0x3C, the XOR result is 0x99. The XOR results of all bytes are combined to form the XORed sub-block. The length of the XORed sub-block is the same as that of the atomic block, which is 16 bytes. The sixteen XORed sub-blocks are stored in independent address spaces of temporary register groups. When concatenating the XORed sub-blocks in their original order, the concatenation operation connects the sixteen XORed sub-blocks sequentially. The first XORed sub-block occupies the first 16 bytes of the concatenated result, the second XORed sub-block occupies the next 16 bytes, and so on. The total length of the concatenated result is 256 bytes. When applying a circular shift operation to the concatenated result, the shift amount is determined by the lower four bits of the current timestamp. The current timestamp is taken from the smart ring's internal real-time clock module. The real-time clock module counts in seconds and outputs a 32-bit unsigned integer. The lower four bits of this integer range from 0 to 15. The circular shift operation is performed byte by byte. If the shift amount is set to 7, the first 7 bytes of the concatenated result are moved to the end, and the remaining bytes fill the gaps. After the circular shift operation is completed, a shifted key vector is generated. The length of the shifted key vector remains unchanged at 256 bytes. When performing byte spread permutation on the shifted key vector, the byte spread permutation shuffles the byte order through a lookup table replacement. The lookup table replacement uses a pre-generated permutation table. The permutation table is stored in the secure element's read-only memory and is 256 bytes in size.Each entry in the substitution table is a byte value ranging from 0 to 255. The index of the substitution table represents the position of the original byte, and the entry value represents the target position to which the original byte should be moved. For the i-th byte in the shifted key vector, the entry value j at index i in the substitution table is read, and this byte is written to the j-th position of the new vector. After traversing all 256 bytes of the shifted key vector, the order of all bytes in the new vector is completely shuffled. The shuffled new vector is the mixed key vector. The length of the mixed key vector remains 256 bytes.

[0033] Furthermore, step S3 includes the following steps: Step S31: Load the encrypted payment credential into the payload field of the NFC data frame, fill in the start flag, length field and CRC check code according to the frame structure specified in the ISO14443 protocol, and generate the data frame to be sent; Step S32: Perform Manchester encoding on the data frame to be sent, convert the binary bit stream into a load modulation signal, and generate a baseband modulation waveform; Step S33: The baseband modulation waveform is superimposed on the carrier signal through the load modulation circuit of the NFC antenna to generate the return radio frequency signal; Step S34: After the antenna coil of the payment terminal senses the returned radio frequency signal, it demodulates and decodes it to recover the encrypted payment certificate and generate the terminal-side decryption input. Step S35: The terminal uses the previously negotiated session key to decrypt the decryption input, extracts the user's payment account index and transaction amount, and generates a transaction authorization request.

[0034] In this embodiment, when the encrypted payment credential is loaded into the payload field of the NFC data frame, the total length of the encrypted payment credential is 256 bits, or 32 bytes. The structure of the NFC data frame follows the frame format specified by the ISO14443 protocol. The frame format includes four parts: a start flag, a length field, a payload field, and a CRC checksum. The start flag is set to a fixed 8-bit binary sequence 0x7E. The length field is set to an 8-bit binary number, representing the number of bytes in the payload field. The payload field has 32 bytes, therefore the length field value is 0x20. The CRC checksum is calculated using the CRC-16 algorithm, covering all bytes of the start flag, length field, and payload field. The generator polynomial of the CRC-16 algorithm is set to 0x8005. The calculated CRC checksum is 16 bits long, or 2 bytes. All parts are assembled in sequence: the start flag occupies 1 byte, the length field occupies 1 byte, the payload field occupies 32 bytes, and the CRC checksum occupies 2 bytes. The total length of the assembled data frame to be sent is 36 bytes. When Manchester encoding is performed on the data frame to be transmitted, each binary bit is converted into a signal unit with a specific transition pattern. For binary bit 0, the first half of the signal unit is high and the second half is low. For binary bit 1, the first half of the signal unit is low and the second half is high. The duration of each bit is 1 microsecond. The data frame to be transmitted consists of 288 bits, which are encoded into 288 signal units. The transition time of each signal unit is located at the midpoint of the unit. All signal units are connected in series to form a continuous baseband modulation waveform. The voltage swing of the baseband modulation waveform is set from 0 volts to 3.3 volts. When the baseband modulation waveform is superimposed on the carrier signal through the load modulation circuit of the NFC antenna, the load modulation circuit consists of a pair of MOSFET switches. The gate of the MOSFET switches receives the baseband modulation waveform signal. When the baseband modulation waveform is high, the MOSFET switches are turned on, connecting an additional resistive load in parallel with the antenna coil. When the baseband modulation waveform is low, the MOSFET switches are turned off, removing the additional resistive load. The impedance of the antenna coil changes with the load, causing amplitude modulation of the carrier signal. The carrier signal frequency is 13.56MHz. The modulation depth is set to 10%. The modulated carrier signal is the return RF signal. The return RF signal is radiated into the surrounding space through the antenna coil. After the payment terminal's antenna coil senses the return RF signal, it performs demodulation and decoding. The demodulation process is implemented through an envelope detector. The envelope detector extracts the baseband modulation waveform from the return RF signal. The baseband modulation waveform is filtered by a low-pass filter to remove high-frequency noise. The filtered waveform is sent to the Manchester decoder. The Manchester decoder detects the direction of level transitions at the midpoint of each signal unit. If a transition from high to low is detected, it is decoded as bit 0. If a transition from low to high is detected, it is decoded as bit 1.The decoded bitstream is restored to the binary content of the data frame to be sent. The 32-byte payload field is extracted from the restored data frame, which is the encrypted payment credential. This encrypted payment credential becomes the decryption input on the terminal side. When the terminal decrypts the input using the previously negotiated session key, it stores the previously negotiated 256-bit session key. The decryption algorithm uses AES-256-GCM mode. The decryption input consists of two parts: ciphertext and authentication tag. The ciphertext is 128 bits long, and the authentication tag is 128 bits long. The terminal uses the session key, initialization vector, and additional authentication data for decryption. The initialization vector is recorded by the terminal during previous interactions. The additional authentication data is a ring identifier. The AES-256-GCM decryption engine outputs the plaintext and verification result. The plaintext is 128 bits long, which is the user payment account index. The terminal extracts the current transaction amount field from the local transaction database. The user payment account index and the transaction amount are combined to generate a transaction authorization request.

[0035] Furthermore, step S4 includes the following steps: Step S41: The payment terminal sends the transaction authorization request to the acquiring institution's server through an encrypted network channel. The server parses the account index and amount fields in the request and generates a clearing instruction. Step S42: The acquiring institution's server forwards the clearing instruction to the issuing bank's payment gateway. The gateway verifies the account balance and transaction limit, and generates an authorization approval code or a rejection code. Step S43: The issuing bank's payment gateway encapsulates the authorization approval code or rejection code into a response message and sends it back to the payment terminal along the original path, generating terminal-side response data; Step S44: The payment terminal parses the terminal-side response data. If it is an approval code, it extracts the transaction serial number and timestamp to generate a transaction confirmation code. Step S45: Combine the transaction confirmation code with the transaction amount and merchant number to form a payment completion receipt, and write it to the smart ring via NFC reverse link.

[0036] In this embodiment, when the payment terminal sends a transaction authorization request to the acquiring institution's server via an encrypted network channel, the encrypted network channel is established based on the TLS protocol. The TLS protocol version is set to 1.3. The data structure of the transaction authorization request includes three fields: user payment account index, transaction amount, and merchant number. The user payment account index is a 128-bit binary string. The transaction amount is a 64-bit binary string, in cents. The merchant number is a 128-bit binary string. The three fields are concatenated into a 384-bit data block. The data block is encrypted using a TLS session key. The encrypted data block is sent to the designated IP address and port number of the acquiring institution's server via a TCP / IP network. After receiving the encrypted data block, the acquiring institution's server decrypts it using the TLS session key, recovering the user payment account index, transaction amount, and merchant number. The server parses the account index and amount fields in the request and generates a clearing instruction. The clearing instruction includes the issuing bank identification code, account index, transaction amount, and merchant number. The issuing bank identification code is extracted from the first 6 decimal digits of the user payment account index. When the acquiring institution's server forwards a clearing instruction to the issuing bank's payment gateway, the forwarding path is implemented through a dedicated financial network. This dedicated financial network uses the ISO8583 message format. The clearing instruction is encapsulated within a bitmap and data elements of the ISO8583 message. The bitmap indicates which data elements are included. Data elements include the primary account number, transaction amount, transaction type, merchant type, and acquirer identifier. The primary account number is parsed from the user's payment account index. The transaction amount remains unchanged. The transaction type is set to "consumption." The merchant type is obtained by querying the database based on the merchant number. The acquirer identifier is set to the acquiring institution's unique code. The encapsulated ISO8583 message is sent to the issuing bank's payment gateway via a dedicated line. Upon receiving the message, the issuing bank's payment gateway parses out the primary account number and transaction amount. The gateway verifies the account balance against transaction limits. Account balance inquiries are performed by accessing the issuing bank's core accounting system. Transaction limit verification checks the single transaction limit and daily cumulative limit. If the account balance is sufficient and the transaction limit is not exceeded, the gateway generates an authorization approval code. The authorization approval code is a 6-digit decimal number. If the account balance is insufficient or the transaction limit is exceeded, the gateway generates a rejection code. The rejection code is a 4-digit decimal number. When the issuing bank payment gateway encapsulates the authorization approval code or rejection code into a response message, the response message follows the ISO8583 format. The bitmap of the response message indicates the location of the data element containing the authorization approval code or rejection code. The authorization approval code or rejection code is filled into the specified data element field. The response message also includes the original transaction serial number, the response timestamp, and the issuing bank processing code. The original transaction serial number is copied from the clearing instruction. The response timestamp is generated by the gateway's internal clock. The issuing bank processing code is set to 000000. The encapsulated response message is transmitted back to the payment terminal along the original path. After receiving the response message, the payment terminal parses out the authorization approval code or rejection code.When the payment terminal parses the terminal-side response data, if the response data contains an authorization approval code, it extracts the transaction serial number and timestamp. The transaction serial number is obtained from the original transaction serial number field of the response message. The timestamp is obtained from the response timestamp field. The transaction serial number and timestamp are combined to generate a transaction confirmation code. The generation rule for the transaction confirmation code is: transaction serial number first, timestamp second, separated by a separator. The separator is set to a colon character. The total length of the transaction confirmation code does not exceed 64 bytes. When combining the transaction confirmation code with the transaction amount and merchant number to form a payment completion receipt, the combination order is: transaction confirmation code first, transaction amount in the middle, and merchant number last. No separator is inserted between the three fields. The total length of the combined payment completion receipt is 320 bits. The payment completion receipt is written to the smart ring via the NFC reverse link. The NFC reverse link uses the same load modulation mechanism as before. After receiving the receipt data, the NFC front-end circuit of the smart ring stores it in the non-volatile memory of the secure element for subsequent transaction reconciliation.

[0037] Steps S31 and S42 include the following steps: The issuing bank's payment gateway parses the account index in the clearing instruction, maps it to the corresponding user account database record, extracts the account balance and daily cumulative transaction amount, and generates an account status snapshot. The transaction amount is compared with the available balance in the account status snapshot. If the balance is sufficient, proceed to the next step; otherwise, a rejection code is generated directly, and a balance determination result is generated. If the balance is deemed sufficient, further checks are conducted to determine whether the transaction amount triggers risk control rules, including single transaction limits and frequency limits, and a risk control compliance flag is generated. The risk control compliance flag and the account activity score obtained based on the account status snapshot are concatenated into a two-dimensional feature vector, which is then input into a pre-trained decision tree model. The decision tree model traverses from the root node to the leaf node, and each internal node selects a branch based on a feature threshold to generate a path encoding sequence. The authorization probability value stored in the leaf node is activated. If the authorization probability value is greater than a preset threshold, it is determined as authorization; otherwise, it is determined as rejection, generating a preliminary authorization conclusion. The preliminary authorization conclusion is logically ANDed with the account's historical default records. If a default record exists, it is forcibly converted to rejection, generating a final authorization conclusion. The final authorization conclusion is encoded into a binary vector and appended with the path encoding sequence of the decision tree as the audit basis to generate an authorization decision vector. The authorization decision vector is encoded into an authorization approval code or a rejection code, and the issuing bank's digital signature is attached to prevent tampering, thereby generating the authorization approval code or rejection code.

[0038] In this embodiment, when the issuing bank's payment gateway parses the account index in the clearing instruction, the clearing instruction contains a 128-bit account index field. The first 64 bits of the account index field are the issuing bank's identification code, and the last 64 bits are the user account serial number. The issuing bank's payment gateway internally maintains an account index mapping table. The account index mapping table is stored in a high-speed solid-state drive array and organized using a B+ tree data structure. The key of the B+ tree is the hash value of the account index, and the value is a pointer to a user account database record. The issuing bank's payment gateway calculates the SHA-256 hash value of the account index and extracts the first 128 bits of the hash value as the lookup key. The lookup key is used for a binary search in the B+ tree. After finding the corresponding pointer, the user account database record is read through the pointer. The user account database record contains multiple fields: account balance, daily cumulative transaction amount, account creation date, account activity score, and historical default records. The account balance field is a 64-bit unsigned integer in cents. The daily cumulative transaction amount field is a 64-bit unsigned integer in cents. The account activity score field is an 8-bit unsigned integer, ranging from 0 to 255. The historical default record field is a 256-bit bitmap, with each bit representing a default event. After extracting the account balance and daily cumulative transaction amount, these two fields are combined with the account creation date, account activity score, and historical default records to generate an account status snapshot. The total length of the account status snapshot is 512 bits. When comparing the transaction amount with the available balance in the account status snapshot, the transaction amount field is a 64-bit unsigned integer in cents. The available balance field is read directly from the account status snapshot. The comparison operation is performed in the arithmetic logic unit of the payment gateway. The arithmetic logic unit performs a subtraction operation, subtracting the transaction amount from the available balance. If the subtraction result is positive or zero, the balance is considered sufficient. If the subtraction result is negative, the balance is considered insufficient. If the balance is sufficient, proceed to the next processing step. If the balance is insufficient, a rejection code is generated directly. The rejection code is a 4-digit decimal number, fixed at 1001. The rejection code means that the account balance is insufficient. After generating the rejection code, all subsequent steps are skipped, and the process proceeds directly to the authorization decision vector generation stage. If the balance determination result is sufficient, the transaction amount is further checked to see if it triggers risk control rules. Risk control rules include single-transaction limit rules and frequency limit rules. The single-transaction limit rule sets the maximum allowed amount for a single transaction to 500,000 points, or 5,000 yuan. The transaction amount is compared with the single-transaction limit; if the transaction amount exceeds the single-transaction limit, the risk control rule is triggered. The frequency limit rule sets a maximum of 3 transactions allowed per account within 60 seconds. The payment gateway queries the transaction record count for the account over the past 60 seconds. The transaction record count is stored in a sliding window counter in memory. The sliding window counter is divided into time slots in seconds, and each time slot records the number of transactions within that second. The query operation summarizes the sum of the counts from the most recent 60 time slots. If the sum of the counts is greater than or equal to 3, the risk control rule is triggered. After the risk control rule is triggered, a risk control compliance flag is generated.The risk control compliance flag is a Boolean value, with a value of false. If no risk control rules are triggered, the risk control compliance flag is true. When concatenating the risk control compliance flag with the account activity score obtained from the account status snapshot to form a two-dimensional feature vector, the account activity score is directly extracted from the account status snapshot. The account activity score is an 8-bit unsigned integer representing the frequency with which the user has used the account for transactions in the past 30 days. The risk control compliance flag is converted to a binary value, with true values ​​mapped to 1 and false values ​​mapped to 0. The first dimension of the two-dimensional feature vector is the risk control compliance flag, and the second dimension is the account activity score. The two-dimensional feature vector is represented in the form of (1, 180) or (0, 90), etc. The two-dimensional feature vector is input into a pre-trained decision tree model. The decision tree model is stored in the read-only memory of the payment gateway, and the training phase has been completed. The root node of the decision tree model contains a split condition. The split condition is judged based on the first dimension. If the value of the first dimension is less than 0.5, the user proceeds to the left subtree; otherwise, they proceed to the right subtree. The internal nodes of the left subtree are judged based on the second dimension. If the value of the second dimension is less than 150, proceed to the next level's left child node; otherwise, proceed to the next level's right child node. When the decision tree model traverses from the root node to the leaf node, it records the splitting direction and threshold of each internal node it passes through. The splitting direction is recorded as 0 or 1, where 0 represents left and 1 represents right. The threshold is recorded as a specific numerical value. The splitting directions and thresholds of all traversed internal nodes are concatenated to generate a path encoding sequence. The length of the path encoding sequence is equal to twice the depth of the decision tree. The decision tree depth is set to 5 levels, therefore the path encoding sequence length is 10 values. When the authorization probability value stored in the leaf node is activated, the authorization probability value is a floating-point number, ranging from 0.0 to 1.0. The authorization probability value represents the percentage of authorized transactions in the historical transaction samples under that leaf node. The authorization probability value is pre-calculated and stored in the leaf node. For example, the authorization probability value of a certain leaf node is 0.85. The authorization probability value is compared with a preset threshold. The preset threshold is set to 0.7. If the authorization probability value is greater than the preset threshold, it is determined as authorization; otherwise, it is determined as rejection. The judgment result generates a preliminary authorization conclusion. The preliminary authorization conclusion is a Boolean value; a true value represents authorization, and a false value represents rejection. When performing a logical AND operation between the preliminary authorization conclusion and the account's historical default records, the historical default records are extracted from the account status snapshot. The historical default record is a 256-bit bitmap, with each bit representing a default event. If any bit in the bitmap is 1, it indicates the existence of a default event. The rules for the logical AND operation are: if the preliminary authorization conclusion is true and there are no default events, the final authorization conclusion is true. If the preliminary authorization conclusion is true but there are default events, the final authorization conclusion is forcibly changed to false. If the preliminary authorization conclusion is false, the final authorization conclusion is false regardless of whether there are default events. After the final authorization conclusion is generated, it is encoded as a binary vector. The first bit of the binary vector represents the final authorization conclusion, and the second bit represents the preliminary authorization conclusion.The binary vector is 2 bits long. It is appended to the path encoding sequence of the decision tree. The path encoding sequence serves as the audit basis for subsequent dispute resolution. The binary vector and path encoding sequence are combined to generate the authorization decision vector. The total length of the authorization decision vector is 12 bits. When encoding the authorization decision vector as an authorization approval code or rejection code, the encoding rules are as follows: If the first bit of the authorization decision vector is 1, it is encoded as an authorization approval code. The authorization approval code is a 6-digit decimal number. The authorization approval code is calculated by treating the last 11 bits of the authorization decision vector as a binary number, converting it to decimal, and then adding 100000. If the first bit of the authorization decision vector is 0, it is encoded as a rejection code. The rejection code is a 4-digit decimal number. The rejection code is calculated by treating the last 11 bits of the authorization decision vector as a binary number, converting it to decimal, and then adding 4000. After encoding, an issuing bank digital signature is appended to prevent tampering. The issuing bank digital signature uses the issuing bank's RSA private key to sign the authorization approval code or rejection code. The RSA private key is 2048 bits long. The signature algorithm used is RSASA-PSS. The signature result is appended to the authorization / approval code or rejection code. The signature result is 256 bytes long. The authorization / approval code or rejection code, together with the signature result, forms the final authorization / approval code or rejection code data packet. The total length of the data packet is 262 bytes.

[0039] Furthermore, the present invention also provides an NFC payment system based on a smart ring, including a processor, a memory, and a computer program stored in the memory and executable on the processor, for performing the NFC payment method based on a smart ring as described above.

[0040] Furthermore, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the NFC payment method based on a smart ring as described above.

[0041] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0042] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. An NFC payment method based on a smart ring, characterized in that, Includes the following steps: Step S1: The NFC chip built into the smart ring senses the radio frequency field emitted by the payment terminal, collects the raw near-field communication signal containing carrier amplitude fluctuations and phase jitter, and generates an NFC handshake feature vector. Step S2: Perform dynamic key negotiation and secure channel establishment on the NFC handshake feature vector, extract the session key and device authentication token, and generate encrypted payment credentials; Step S3: Inject the encrypted payment credential into the payload field of the NFC data frame and transmit it back to the payment terminal via the modulated radio frequency signal. The terminal parses the data and generates a transaction authorization request. Step S4: Based on the transaction authorization request, call the remote payment gateway to complete the fund transfer. The gateway returns a transaction confirmation code and generates a payment completion receipt. Step S5: Write the payment completion receipt to the secure storage area of ​​the smart ring, update the local transaction log and remaining balance counter, and generate account status synchronization data.

2. The NFC payment method based on a smart ring according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Activate the NFC front-end circuit of the smart ring to enter polling mode, detect the 13.56MHz carrier signal emitted by the payment terminal, collect the carrier amplitude change curve over time, and generate a carrier envelope sequence; Step S12: Perform differential operation on the carrier envelope sequence to extract amplitude abrupt change points and stable interval boundaries, and generate a carrier modulation edge feature set; Step S13: Separate the query request frame header sent by the terminal from the carrier modulation edge feature set, parse the protocol version and command type fields in the frame header, and generate the terminal capability description vector; Step S14: Determine the NFC data exchange format supported by the payment terminal based on the terminal capability description vector, select the corresponding encoding mapping table, and generate a handshake parameter configuration set; Step S15: The handshake parameter configuration set and the phase jitter features extracted from the carrier envelope sequence are fused and encoded to generate the NFC handshake feature vector.

3. The NFC payment method based on a smart ring according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Extract the terminal public key certificate and random challenge number from the NFC handshake feature vector, call the private key in the smart ring's security element to digitally sign the challenge number, and generate a signature response data block; Step S22: Concatenate the signature response data block with the ring identity identifier and send it to the terminal. After verifying the signature's validity, the terminal generates a session key seed and encrypts and sends it back to the smart ring. Step S23: After receiving the encrypted session key seed, the smart ring uses the derived function within the secure element to calculate the symmetric encryption key and generate the session key; Step S24: Encrypt the user payment account index stored in the smart ring based on the session key to generate an encrypted account index block; Step S25: Assemble the encrypted account index block and the device authentication token into a structured data packet to generate an encrypted payment credential.

4. The NFC payment method based on a smart ring according to claim 3, characterized in that, Step S23 includes the following steps: Step S231: Input the encrypted session key seed into the hardware true random number generator in the secure element, extract the entropy source component in the seed, and generate the initial key material; Step S232: Perform key derivation operation based on SM3 hash algorithm on the initial key material to generate a 256-bit intermediate key; Step S233: XOR the intermediate key with the ring's unique serial number to eliminate the statistical correlation between the key and the seed, and generate a hybrid key vector; Step S234: Perform key verification on the hybrid key vector, calculate its Hamming distance with the preset verification mode, and if the distance is less than the threshold, the verification is passed and a verification pass flag is generated; Step S235: Encapsulate the confirmation flag and the hybrid key vector into a key object, store it in the temporary key slot of the secure element, and generate a session key.

5. The NFC payment method based on a smart ring according to claim 4, characterized in that, Step S233 includes the following steps: The intermediate key is split into sixteen 16-byte sub-blocks to generate a sub-block sequence; Read the unique serial number pre-programmed within the secure area of ​​the smart ring, split it into segments of equal length and align them with the sub-block sequence to generate aligned serial number fragments; Perform a byte-by-byte XOR operation on each sub-block and its corresponding alignment sequence number segment to generate the XORed sub-block; The XORed sub-blocks are concatenated in their original order, and a cyclic shift operation is applied to them. The number of shifts is determined by the lower four bits of the current timestamp, generating the shifted key vector. The shifted key vector is subjected to byte diffusion permutation, and the byte order is shuffled by table lookup and replacement to generate a hybrid key vector.

6. The NFC payment method based on a smart ring according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: Load the encrypted payment credential into the payload field of the NFC data frame, fill in the start flag, length field and CRC check code according to the frame structure specified in the ISO14443 protocol, and generate the data frame to be sent; Step S32: Perform Manchester encoding on the data frame to be sent, convert the binary bit stream into a load modulation signal, and generate a baseband modulation waveform; Step S33: The baseband modulation waveform is superimposed on the carrier signal through the load modulation circuit of the NFC antenna to generate the return radio frequency signal; Step S34: After the antenna coil of the payment terminal senses the returned radio frequency signal, it demodulates and decodes it to recover the encrypted payment certificate and generate the terminal-side decryption input. Step S35: The terminal uses the previously negotiated session key to decrypt the decryption input, extracts the user's payment account index and transaction amount, and generates a transaction authorization request.

7. The NFC payment method based on a smart ring according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: The payment terminal sends the transaction authorization request to the acquiring institution's server through an encrypted network channel. The server parses the account index and amount fields in the request and generates a clearing instruction. Step S42: The acquiring institution's server forwards the clearing instruction to the issuing bank's payment gateway. The gateway verifies the account balance and transaction limit, and generates an authorization approval code or a rejection code. Step S43: The issuing bank's payment gateway encapsulates the authorization approval code or rejection code into a response message and sends it back to the payment terminal along the original path, generating terminal-side response data; Step S44: The payment terminal parses the terminal-side response data. If it is an approval code, it extracts the transaction serial number and timestamp to generate a transaction confirmation code. Step S45: Combine the transaction confirmation code with the transaction amount and merchant number to form a payment completion receipt, and write it to the smart ring via NFC reverse link.

8. The NFC payment method based on a smart ring according to claim 7, characterized in that, Step S42 includes the following steps: Step S421: The issuing bank's payment gateway parses the account index in the clearing instruction, maps it to the corresponding user account database record, extracts the account balance and daily cumulative transaction amount, and generates an account status snapshot; Step S422: Compare the transaction amount with the available balance in the account status snapshot. If the balance is sufficient, proceed to the next step; otherwise, generate a rejection code and generate a balance determination result. Step S423: If the balance determination result is sufficient, further check whether the transaction amount triggers risk control rules, including single transaction limit and frequency limit, and generate a risk control compliance mark; Step S424: Concatenate the risk control compliance flag with the account activity score obtained based on the account status snapshot into a two-dimensional feature vector, and input it into the pre-trained decision tree model; the decision tree model traverses from the root node to the leaf node, and each internal node selects a branch according to the feature threshold to generate a path encoding sequence; the authorization probability value stored in the leaf node is activated. If the authorization probability value is greater than the preset threshold, it is determined to be authorized; otherwise, it is determined to be rejected, generating a preliminary authorization conclusion; perform a logical AND operation between the preliminary authorization conclusion and the account's historical default records. If there are default records, it is forcibly converted to rejection, generating a final authorization conclusion; encode the final authorization conclusion into a binary vector, and attach the path encoding sequence of the decision tree as the audit basis to generate an authorization decision vector; Step S425: Encode the authorization decision vector into an authorization approval code or a rejection code, and attach the issuing bank's digital signature to prevent tampering, thereby generating the authorization approval code or rejection code.

9. An NFC payment system based on a smart ring, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, for performing the NFC payment method based on a smart ring as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the NFC payment method based on a smart ring as described in any one of claims 1-8.

Images