An electronic voucher obtaining method, terminal device and system

Abstract

The application discloses an electronic certificate acquisition method, a terminal device and a system. The method comprises the following steps: acquiring a certificate element, generating a first signature value based on the certificate element through a security chip; sending a certificate generation request containing the first signature value and the certificate element to a cloud server; receiving a response returned by the cloud server, the response containing encrypted certificate data; processing the encrypted certificate data to return a data packet; receiving a response containing a certificate access portal; constructing an NDEF message according to the certificate access portal; activating a near field communication controller to enter an offline card simulation mode; and outputting the NDEF message through the near field communication controller, so that a user mobile device reads the NDEF message to acquire an electronic certificate. In the application, a user does not need to open any application program, manually input or scan, and only needs to place an NFC-supported user mobile device close to a card reading area of the terminal device to automatically acquire a certificate, so that the acquisition operation of the electronic certificate is greatly simplified.

Description

Technical Field

[0001] This application relates to the field of electronic credential technology, specifically to an electronic credential acquisition method, terminal device, and system. Background Technology

[0002] With the popularization of digital transactions, electronic vouchers (such as electronic invoices, fiscal receipts, payment vouchers, and electronic tickets) are gradually becoming a replacement for paper vouchers. In the traditional model, the generation and delivery of vouchers heavily rely on paper media: after a transaction is completed, merchants or service providers typically need to print receipts containing transaction details on paper using the printing module built into their terminal devices or a connected external printer, and then deliver the paper receipts to the user. For commercial scenarios with high transaction volumes and frequent invoicing, the long-term use of paper receipts leads to high costs for consumables such as paper and ink, and the maintenance and replacement of printers and related equipment also increases the operational burden. Furthermore, the storage, management, and destruction of large quantities of paper receipts require additional manpower and physical space costs, and are not in line with the trend of green and environmentally friendly development.

[0003] Therefore, there is an urgent need to provide an electronic voucher technology solution that can replace paper tickets electronically, reduce operating costs, and is environmentally friendly. Summary of the Invention

[0004] To address the problems existing in the prior art, this application provides an electronic credential acquisition method, terminal device, and system.

[0005] In a first aspect, this application provides a method for obtaining electronic credentials, the method being executed in a terminal device including an application program and a security chip, the method comprising: Step S1: The terminal device obtains the credential elements and generates a first signature value based on the credential elements through the security chip; Step S2: The terminal device sends a credential generation request containing the first signature value and the credential elements to the cloud server; Step S3: The terminal device receives a response from the cloud server containing encrypted credential data generated based on the credential elements, processes the encrypted credential data through the security chip, and returns the data packet processed by the security chip to the cloud server; Step S4: The terminal device receives a response from the cloud server containing a credential access entry, and constructs a near-field communication data exchange format message based on the credential access entry; Step S5: The terminal device activates the near-field communication controller to enter the offline card emulation mode, and outputs the near-field communication data exchange format message through the near-field communication controller, so that the user's mobile device can read the near-field communication data exchange format message to obtain the electronic certificate.

[0006] Secondly, this application provides an electronic credential acquisition terminal device, the terminal device comprising: The voucher acquisition module is used to acquire voucher elements; A signature module, which is used to generate a first signature value based on the credential elements via a security chip; The request sending module is used to send a credential generation request containing the first signature value and the credential elements to the cloud server; The response receiving module is used to receive a response from the cloud server containing encrypted credential data generated based on the credential elements, and also to receive a response from the cloud server containing a credential access entry. A data processing module is used to process the encrypted credential data through the security chip and return the data packet processed by the security chip to the cloud server; The message construction module is used to construct a near-field communication data exchange format message based on the credential access entry. The output control module is used to activate the near-field communication controller to enter the offline card emulation mode. The near-field communication controller outputs the near-field communication data exchange format message, which is then read by the user's mobile device to obtain an electronic certificate.

[0007] Thirdly, this application provides an electronic credential acquisition system, including the terminal device, cloud server, and user mobile device as described above, the system being used to execute the method steps described above.

[0008] Fourthly, this application provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method.

[0009] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method.

[0010] The present invention has the following beneficial effects: This application constructs a fully electronic closed-loop system through the collaborative operation of terminal devices, cloud servers, and user mobile devices, encompassing voucher generation, encrypted transmission, and NFC delivery and verification. Merchants do not need to purchase paper-based printing equipment, nor do they need to bear the costs of voucher storage, logistics, and manual distribution; users do not need to queue to print or receive physical vouchers, but can automatically obtain electronic vouchers by simply tapping their mobile phones against the POS terminal.

[0011] In the entire process of obtaining electronic vouchers in this invention, users do not need to open any applications, nor do they need to manually input or scan, which greatly simplifies the process of obtaining electronic vouchers, solves the problem of cumbersome operation in the prior art, and significantly improves user experience and efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the specific embodiments will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0013] Figure 1 This is a flowchart illustrating an electronic credential acquisition method provided by the present invention.

[0014] Figure 2 This is a structural block diagram of an electronic credential acquisition terminal device provided by the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0016] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described below do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0017] This application uses the example of obtaining electronic vouchers generated on a smart terminal for illustration, but the application of the present invention is not limited to this, and can also be applied to high-security scenarios such as electronic invoices, fiscal receipts, medical receipts, payment vouchers, and electronic ticketing. In the following description, the terminal device can be a smart POS terminal, or other embedded devices integrating a near-field communication controller and a security chip.

[0018] In this document, the term "security chip" refers to a chip unit with an independent hardware security environment, used to provide hardware-level security protection for electronic devices. It internally stores a device private key bound to the device's identity and provides the ability to perform cryptographic operations within the chip. The security chip can be implemented as an embedded secure element (eSE), a secure element (SE), or a chip unit with a trusted execution environment (TEE), and this application does not limit this to any particular implementation.

[0019] The term "Near Field Communication Controller" (NFC controller) refers to a hardware controller that supports the Near Field Communication protocol and can operate in card emulation mode to exchange data with external NFC reading devices via radio frequency fields.

[0020] The term "Off-Host Card Emulation Mode" refers to an operating mode of the near-field communication controller (NFC) in which the NFC controller can directly read data from its internal buffer in response to external read requests, without requiring data scheduling by the main processor and the main operating system.

[0021] The term "NFC" stands for Near Field Communication, which is a short-range, high-frequency wireless communication technology.

[0022] The term "NFC Data Exchange Format Message" (NDEF message) refers to a message that conforms to the data exchange format standard defined in the NFC specification and is used to exchange information between NFC devices. An NDEF message may contain one or more NDEF records, each of which carries a specific type of payload data.

[0023] The term "token string" refers to a string encoded by a cloud server after signing specific data related to a credential. It is used to uniquely identify a credential request-delivery session and serves as the basis for constructing a credential access point.

[0024] The term "credential access point" refers to the address information used to access and retrieve the original credential text. In one alternative implementation, this entry point is a Uniform Resource Locator (URL).

[0025] This application provides a method for obtaining electronic credentials, referring to... Figure 1 The method includes the following steps: Step S1: The terminal device obtains the credential elements and generates a first signature value based on the credential elements through the security chip; Step S2: The terminal device sends a credential generation request containing the first signature value and credential elements to the cloud server; Step S3: The terminal device receives a response from the cloud server containing encrypted credential data generated based on credential elements, processes the encrypted credential data through the security chip, and returns the data packet obtained by the security chip to the cloud server. Step S4: The terminal device receives a response from the cloud server containing a credential access entry, and constructs a near-field communication data exchange format message based on the credential access entry. Step S5: The terminal device activates the near-field communication controller to enter the offline card emulation mode, and outputs near-field communication data exchange format messages through the near-field communication controller, so that the user's mobile device can read the near-field communication data exchange format messages to obtain electronic credentials.

[0026] The method provided in this application initiates a credential generation request on the terminal device side using a secure chip as the root of trust, completes credential encryption and access point construction in the cloud, and finally delivers the access point to the user's mobile device seamlessly through an offline card emulation mode, thus constructing a complete closed loop for credential acquisition from the terminal to the cloud, back to the terminal, and finally to the user. Throughout the entire process, the user only needs to bring their mobile device close to the terminal device; they do not need to open any applications, manually enter any information, or scan any codes. Simultaneously, the output path of the near-field communication data is independent of the main operating system, forming a layered defense for security.

[0027] The following detailed explanation of each step is provided in conjunction with specific implementation methods.

[0028] Step S1: Obtain the credential elements and generate a first signature value based on the credential elements using the security chip.

[0029] A credential element is a set of data used to identify a credential generation request. In this application, the credential elements include: a unique device identifier, an order identifier, a transaction amount, a first timestamp, and a first random number.

[0030] Among them, the unique device identifier is a unique identity assigned by the cloud server to the terminal device during registration, used to distinguish different terminal devices. The order identifier is a unique number associated with the current transaction order. The transaction amount is expressed in the smallest currency unit (e.g., cents). The first timestamp is the current timestamp of the terminal device, and the format can be YYYYMMDDHHMMSS. The first random number is an unpredictable byte sequence.

[0031] In one alternative implementation, the first random number is generated by a true random number generator inside the security chip.

[0032] Because the pseudo-random number generator provided by the main operating system relies on software algorithms and system state, if the main operating system is compromised, attackers may be able to predict or control the output value of the pseudo-random numbers. In contrast, the true random number generator inside the security chip in this invention generates random numbers based on hardware entropy sources (such as thermal noise, oscillator jitter, and other physical phenomena), and does not depend on any software state of the main operating system. Even if the main operating system is completely controlled, the unpredictability of the first random number is still guaranteed. This makes signature and encryption operations using the first random number as input resistant to pre-computation attacks.

[0033] The specific steps for generating a first signature value based on credential elements using a security chip include: the security chip performing a hash calculation on the credential elements to obtain a first hash value, and using the device private key stored internally to sign the first hash value to obtain the first signature value.

[0034] In one optional implementation, the hash calculation uses the SHA-256 algorithm, and the signature algorithm uses ECDSA. In another implementation, the signature algorithm may also be RSA-PSS or SM2, and this application does not limit this choice.

[0035] The device private key is stored in the hardware security environment of the security chip. It is injected into a non-volatile secure storage area within the security chip during the chip manufacturing or device initialization phase. This storage area is physically isolated from the general-purpose storage area within the security chip and the external main operating system storage area through a hardware isolation mechanism. No software running on the main operating system (including the application itself) can directly read or export the complete value of the device private key through any interface. All intermediate results required for signature calculations do not leave the security chip; only the first signature value after calculation is returned to the application through a secure interface. In contrast to existing technologies that store the device private key in the file system or have it managed by the operating system, if the terminal device is infected with malware, the key stored in the file system can be completely stolen by an attacker. The attacker can then use the stolen device private key to forge any legitimate credential generation request. This solution encapsulates the signature operation within the security chip. Even if an attacker has complete control of the main operating system, they can only initiate signature requests through the limited interfaces provided by the security chip and cannot obtain the key itself.

[0036] Step S2: Send a credential generation request containing the first signature value and credential elements to the cloud server.

[0037] In this application, the application assembles the credential elements and the first signature value into credential request data and sends a credential generation request to a preset interface of the cloud server through an encrypted communication protocol.

[0038] In one alternative implementation, the credential request data is organized in JSON format, and the communication protocol is HTTPSPOST.

[0039] An example of credential request data is as follows: {"seid":"SEID_A1B2C3","order_id":"ORD202510310001","amount":2500,"ts_req":"20251031103000","req_nonce":"abc123...","sign_req":"3045..."}.

[0040] The first signature value, Sign_req, included in the credential request data is used to prove to the cloud server that the credential generation request was indeed initiated by a legitimate terminal device possessing the device's private key, and that the credential data elements have not been tampered with after the signature was generated. Only a secure chip holding a device private key corresponding to the device's public key held by the cloud server can generate a first signature value that can be verified through the device's public key.

[0041] Step S3: Receive the response from the cloud server containing encrypted credential data generated based on credential elements, process the encrypted credential data through the security chip, and return the data packet obtained from the security chip processing to the cloud server.

[0042] After sending a credential generation request, the application waits for and receives a response from the cloud server. In a preferred embodiment, the method further includes the following step before step S3: Step S21: The cloud server verifies the first signature value in the credential generation request; Specifically, verifying the first signature value in the credential generation request includes: the cloud server obtaining the corresponding device public key from the device registry based on the device unique identifier in the credential elements, and using the device public key to verify the first signature value.

[0043] The verification of the first signature value using the device's public key is as follows: the cloud server performs a hash calculation on the credential elements to obtain a second hash value, decrypts the first signature value using the device's public key to obtain a first hash value, and compares whether the first hash value and the second hash value are consistent. If they are consistent, the verification is successful.

[0044] If the first signature value is verified, it is confirmed that the credential generation request was initiated by a terminal device holding a legitimate device private key, and that the credential elements have not been tampered with.

[0045] In a preferred embodiment, the cloud server performs a timestamp validity check before verifying the first signature value in the credential generation request.

[0046] The timestamp validity check specifically includes checking whether the difference between the first timestamp in the credential element and the current time on the cloud server is within a preset time range. In one exemplary implementation, this preset time range is 5 minutes. If the difference exceeds this time range, it indicates that the credential generation request may have been generated a long time ago, intercepted, and attempted to be replayed; the cloud server rejects the request. The first timestamp check limits the valid lifespan of the credential generation request from a time perspective.

[0047] In a preferred embodiment, the cloud server performs a random number anti-replay check before verifying the first signature value in the credential generation request.

[0048] The random number replay protection check specifically includes: checking whether the first random number in the credential element already exists in a one-time random number blacklist maintained by the cloud server; if it exists, an error is returned; otherwise, verification continues. After successful verification, the first random number is added to the blacklist and an expiration time corresponding to the timestamp window is set. This blacklist can be implemented based on Redis or an in-memory hash table. The purpose of the first random number check is to ensure that even within the same time window, the same credential generation request data cannot be reused.

[0049] In practice, the first timestamp verification and the first random number verification constitute a dual anti-replay mechanism in both the time and spatial dimensions. With timestamp verification alone, an attacker can still intercept legitimate requests and immediately replay them within the effective time window; with only random number verification, an attacker could theoretically launch a collision attack by collecting a large number of already used random numbers. Dual verification superimposes constraints from both dimensions, requiring attackers not only to intercept requests within an extremely short time window but also to ensure that the random numbers in the request have never been used. Compared to a single verification scheme, dual verification provides an exponentially improved anti-replay effect with almost no increase in computational overhead.

[0050] Step S22: The cloud server generates the original voucher text, encrypts the original voucher text, and obtains encrypted voucher data; Specifically, the original document of the voucher is the core data content of the electronic voucher.

[0051] In one optional implementation, the cloud server generates the original voucher text by: generating a unique voucher identifier and a second random number; obtaining the current timestamp as the second timestamp; obtaining the merchant account based on the device unique identifier in the voucher elements; and concatenating the unique voucher identifier, the merchant account, and the order identifier, transaction amount, second timestamp, and second random number in the voucher elements to obtain the original voucher text.

[0052] The unique voucher identifier is a unique identifier assigned by the cloud server for each voucher generation operation, used to distinguish different voucher records in the cloud database. The second random number is a truly random number generated by the cloud server.

[0053] In scenarios where electronic invoices need to be generated, before the cloud server generates the original voucher, the process includes: the cloud server sending an invoice request to the tax control system, receiving the invoice code, invoice number, and tax control signature data returned by the tax control system, and verifying the tax control signature data using the tax control public key. After successful verification, the original voucher also includes the invoice code, invoice number, and tax control signature data.

[0054] In this application, the encryption process of the original credential text is implemented using an authentication encryption algorithm, which protects both the confidentiality of the original credential text and provides integrity protection.

[0055] In a preferred embodiment, the specific process by which the cloud server encrypts the original voucher to obtain encrypted voucher data includes: Step S221: The cloud server obtains the value of the first counter, the key version number, and the root key seed, and derives the device symmetric key based on the device unique identifier, the value of the first counter, the key version number, the root key seed, and the second random number. The first counter's value is the current value of a monotonically increasing counter corresponding to the device's unique identifier. This counter increments atomically after each key derivation and encryption operation. The key version number identifies the currently used key derivation scheme version for future key rotation. The root key seed is a high-entropy key material stored in the cloud-based hardware security module.

[0056] Using a monotonically increasing counter in key derivation ensures that the symmetric key used by the same terminal device in different encryption operations is different. Because the value of the first counter monotonically increases after each encryption, even if the device unique identifier, key version number, root key seed, and second random number all remain unchanged, the derived symmetric key will be completely different each time. Compared to fixed-key schemes, even if an attacker cracks the symmetric key corresponding to a certain credential, that key cannot be used to decrypt the ciphertext of other credentials, effectively limiting the scope of key leakage.

[0057] In one exemplary implementation, the input parameters of the key derivation function are: device unique identifier seid, first counter value counter, key version number key_ver, root key seed root_seed and second random number nonce_c, and the output is the device symmetric key K_enc.

[0058] Step S222: The cloud server generates an initialization vector IV based on the value of the first counter, uses the device unique identifier, the value of the first counter, and the key version number as additional authentication data, and uses the device symmetric key to authenticate and encrypt the original credential, the initialization vector, and the additional authentication data to obtain the first ciphertext C and the authentication tag Tag. The cloud server generates an initialization vector (IV) based on the value of the first counter. Specifically, it converts the current value of the first counter into a big-endian integer of a preset length (e.g., 12 bytes), padding the high-order bits with zeros. The initialization vector is used to provide a randomized starting state for the authentication encryption algorithm, so that the same credential plaintext will produce completely different ciphertext outputs when using different initialization vectors.

[0059] In one exemplary implementation, the authentication encryption algorithm employs AES-256-GCM. The AES-GCM mode provides both encryption and authentication functions. The first ciphertext protects the confidentiality of the original credential, while the authentication tag protects the integrity of the first ciphertext and the additional authentication data. During decryption, if the additional authentication data is inconsistent with the encryption data, the authentication tag verification will fail, thereby detecting whether the data has been tampered with during transmission.

[0060] Using the device's unique identifier, the value of the first counter, and the key version number as additional authentication data in the authentication encryption is to cryptographically bind the ciphertext to a specific device identity, a specific counter state, and a specific key version. If an attacker attempts to inject valid ciphertext from one terminal device into the communication channel of another, decryption will fail because the device's unique identifier in the additional authentication data does not match. Similarly, if an attacker attempts to use old ciphertext corresponding to an old counter state, decryption will also fail because both the additional authentication data and the initialization vector used during encryption do not match the current one.

[0061] After the encryption operation on the cloud server is completed, the value of the first counter is atomically incremented and written back to the database.

[0062] Step 223: The cloud server takes the device unique identifier, credential unique identifier, second timestamp, second random number, first counter value, key version number, first ciphertext and authentication tag as the first data to be signed, performs a hash operation on it, and signs the hash result using the private key to obtain the second signature value; The second signature value provides integrity protection for the first ciphertext and its associated encryption parameters, ensuring that the data is not tampered with or replaced throughout its journey from the cloud server through the application to the security chip. If any field in the first ciphertext, authentication tag, or associated parameters is modified, subsequent verification of the second signature value by the security chip will inevitably fail, thus immediately blocking further processing of the tampered data.

[0063] Step S224: The cloud server generates a token string based on the second signature value, creates a mapping table using the token string as an index value, and stores the device unique identifier, merchant account, credential unique identifier, second timestamp, second random number, initialization vector, value of the first counter, key version, first ciphertext, authentication tag and credential type in the mapping table; The cloud server generates a token string based on the second signature value, specifically by: using the device unique identifier, credential unique identifier, merchant account, second timestamp, second random number, first counter value, key version number, second signature value, and credential type as token to be signed data; using the private key to sign the token to be signed data to obtain the token signature value; and encoding the token to be signed data and the token signature value to obtain the token string.

[0064] In one exemplary implementation, Base64 encoding is used, where each field in the token's data to be signed is concatenated with a delimiter before encoding. The resulting token string serves as a core component of the credential access point, enabling subsequent processes to verify the authenticity and integrity of the access point by confirming the token signature.

[0065] A mapping table with the token string as the primary key organizes all relevant data for a single credential request-delivery session into a single record, facilitating quick retrieval of data in subsequent processes based on the token string.

[0066] Step S225: The cloud server uses the first ciphertext, authentication tag, initialization vector, second random number, first counter value, key version number and token string as encrypted credential data.

[0067] Step S23: The cloud server returns a response data packet containing encrypted credential data to the terminal device.

[0068] In this application, the data packet includes: a first ciphertext C, an authentication tag Tag, an initialization vector IV, a second random number nonce_c, a first counter value counter, a key version number key_ver, and a token string Token.

[0069] In one exemplary implementation, the data packet is organized in JSON format and sent via an HTTPS response.

[0070] In practice, the data packets from the cloud to the terminal have a nested security structure. The first ciphertext and the authentication tag constitute the inner layer of encryption protection, implemented using a device-bound symmetric key to protect the confidentiality and integrity of the original credential. The token signature value constitutes the outer layer of signature protection, realizing the overall signature of the data to be signed (including the first ciphertext) and verifying the integrity of the data packet during transmission. The second signature value (the signature of the first ciphertext and other data to be signed) constitutes the middle layer of signature protection, specifically protecting the ciphertext data from being tampered with by intermediate nodes in the transmission path. Compared with single-layer encryption or single-layer signature, this layered protection structure protects different data objects and addresses different attack surfaces at each layer, forming a defense-in-depth security architecture.

[0071] In this application, after receiving a response data packet containing encrypted credential data from the cloud server, the application does not parse or modify the data packet content. Instead, it passes the data packet to the security chip as is via the Secure Element API. This pass-through mechanism allows the application to act as a data channel rather than a data processing node. Even if the application is injected with malicious code, it cannot tamper with the content of the data packet sent from the cloud without being detected by the security chip.

[0072] In step S3 of this application, the processing of the encrypted credential data through the security chip specifically includes: Step S31: Pass the data packet through the security element API to the security chip; Step S32: The security chip verifies the encrypted credential data, and obtains the original credential text after successful verification; The security chip verifies the encrypted credential data in the following ways: Step S321: Parse the token string in the encrypted credential data to obtain the token to be signed data and the token signature value. Use the internally preset server public key to verify the token signature value. After the verification is successful, proceed to step S322. Parsing the token string in the encrypted credential data specifically includes: decoding the token string (e.g., Base64 decoding) to restore the token to be signed data and the token signature value.

[0073] The verification of the token signature value is as follows: the security chip performs a hash operation on the token to be signed data, decrypts the token signature value using the server's public key, and compares the decryption result with the hash value calculated by itself. If they are consistent, the verification passes, indicating that the token string was indeed generated by the cloud server holding the legitimate server private key and has not been tampered with during transmission. Otherwise, the verification fails, the security chip terminates the processing flow and returns an error message.

[0074] In a preferred embodiment, before verifying the token signature value, the security chip further includes checking the validity of the key version number in the data packet. The security chip internally stores a range of currently valid key version numbers. If the key version number in the data packet is not within this range, it indicates that the key has expired or is not yet valid, prompting an error and requesting an update to the key version from the cloud server via a secure channel. Key version verification ensures that the key material used for symmetric key derivation by the device is within its valid lifespan.

[0075] Step S322: Verify the second signature value in the token to be signed data. If the verification is successful, proceed to step S323. The verification of the second signature value in the token's pending signature data involves the following steps: The security chip performs a hash operation on the first ciphertext, authentication tag, device unique identifier, credential unique identifier, second timestamp, second random number, first counter value, and key version number in the data packet. It then decrypts the second signature value using the server's public key and compares the hash values ​​for consistency. The second signature value is specifically designed to prevent the first ciphertext from being replaced or tampered with during transmission and pass-through from the cloud server to the security chip. If an attacker intercepts the data packet at the application's intermediate node and replaces the first ciphertext, the verification of the second signature value will inevitably fail.

[0076] After the second signature value is verified, the process also includes: the security chip performing a counter rollback verification.

[0077] The security chip performs counter rollback verification as follows: The security chip retrieves the locally recorded counter value and determines whether the first counter value in the data packet is greater than the locally recorded counter value. If it is not greater, it indicates that the data packet is an old data packet that has already been processed, possibly a replay attack, and the security chip refuses to process it. Counter rollback verification utilizes the monotonically increasing characteristic of counters: the first counter value of a legitimate data packet must be greater than the counter value of previously processed data packets. Even if an attacker possesses a valid data packet from a past moment, they cannot make it pass the counter verification.

[0078] Step S323: Decrypt and verify the first ciphertext and authentication tag in the encrypted credential data; The specific steps for decrypting and verifying the first ciphertext and authentication tag in the encrypted credential data are as follows: The security chip obtains its internally preset root key seed. Based on the device's unique identifier, the first counter value in the encrypted credential data, the key version number, the root key seed, and the second random number in the data packet, it derives the device's symmetric key using the same key derivation function as the cloud server. The security chip uses the derived device symmetric key, along with the device's unique identifier, the first counter value in the encrypted credential data, and the key version number, as additional authentication data, to perform authentication and decryption on the initialization vector, additional authentication data, first ciphertext, and authentication tag in the encrypted credential data. If decryption is successful and the authentication tag is verified, the original credential text is output. If authentication tag verification fails or decryption fails, it indicates that the first ciphertext or additional authentication data has been tampered with during transmission. The security chip discards the decrypted data and returns an error.

[0079] Since the root key seed pre-installed in the security chip is the same as the root key seed used by the cloud server, and the derived parameters used (device unique identifier, first counter value, key version number, second random number) are the same as those used in cloud encryption, the device symmetric key derived by the security chip is exactly the same as the device symmetric key used in cloud encryption.

[0080] In one exemplary implementation, the decryption algorithm is AES-256-GCM.

[0081] In practice, token verification, second signature value verification, and counter rollback verification constitute a three-layer pre-verification defense. Each layer of verification targets different attack scenarios. Token verification prevents attackers from forging tokens or tampering with the data to be signed. Second signature value verification prevents the first ciphertext from being replaced during transmission. Counter rollback verification prevents the replay of old data packets. The three layers of verification proceed sequentially, and the security chip only proceeds to the key derivation and decryption stage after all three have passed. This design effectively reduces the waste of resources in performing costly cryptographic operations on invalid requests while ensuring security.

[0082] After the security chip is successfully decrypted and the original credential is obtained, the locally stored counter value last_counter is updated to the first counter value counter in the current data packet to ensure that the counter value of subsequent data packets must be greater than the current value in order to pass the counter rollback verification.

[0083] Step S33: The security chip performs a hash operation on the original credential to obtain the seventh hash value. The seventh hash value and the token string are used as the second data to be signed. The device private key stored inside the chip is used to sign the second data to be signed to obtain the third signature value.

[0084] The first signature value is used by the cloud server to verify the terminal's identity and the integrity of the requested data; its signature object is the credential element. The third signature value is used to establish an evidence anchor on the original credential text; its signature object is the data associated with the original credential text (the hash of the original credential text and the token string). After the third signature value is persistently stored in the cloud, it becomes non-repudiable evidence of the original credential text content for the terminal device, and can be used to prove that the terminal's security chip did indeed process the original credential text during subsequent credential verification or auditing.

[0085] Step S34: The security chip obtains the root key seed and the value of the local counter. Based on the value of the local counter, the root key seed, the key version number in the encryption credential data, the device unique identifier, and the second random number, it derives the session key K_ses. It obtains the current terminal timestamp and uses the session key K_ses to encrypt the third signature value, the token string, and the current terminal timestamp (e.g., HMAC operation) to obtain the session verification code hmac_req.

[0086] In this application, the application acts as an intermediary node in communication between the security chip and the cloud server. If only the plaintext of the third signature value is transmitted through the application, the application, which has been injected with malicious code, may tamper with the third signature value during the transmission process (e.g., replace it with a signature value controlled by the attacker). In this solution, since the session verification code is calculated based on the session key shared between the security chip and the cloud server, the application cannot forge a valid session verification code.

[0087] Step S35: The security chip organizes the token string, third signature value, seventh hash value, session checksum and current terminal timestamp into a data packet.

[0088] After receiving the returned data packet, the cloud server derives the session key and verifies the session checksum in the same way. Only after successful verification is the integrity of the third signature value trusted.

[0089] In this application, the terminal device transmits the data packets returned by the security chip to the cloud server through the application.

[0090] In this application, after the cloud server receives the data packet sent by the security chip through the application, it also includes: Step S36: The cloud server parses the token string in the data packet, queries the corresponding record in the mapping table, obtains the current cloud timestamp, and determines whether the difference between the cloud timestamp and the current terminal timestamp in the data packet meets the preset conditions. If yes, proceed to step S37; otherwise, return an error.

[0091] In one exemplary implementation, determining whether the difference between the cloud timestamp and the current terminal timestamp in the data packet meets the preset conditions specifically involves determining whether the difference between the cloud timestamp and the current terminal timestamp in the data packet is within a reasonable time window. Step S37: The cloud server derives a session key, verifies the session checksum in the data packet, and after successful verification, uses the device public key to verify the third signature value. After successful verification, the third signature value is stored in the mapping table.

[0092] In a preferred embodiment, after the third signature value is verified, the method further includes: the cloud server obtains the original hash value of the voucher stored in the mapping table (i.e., the hash value previously calculated by the cloud for the original voucher), compares it with the seventh hash value in the data packet, and if they match, persists the seventh hash value to the mapping table and marks the voucher status as "pending delivery".

[0093] At this point, the original credential has undergone two-way verification between the cloud and the terminal security chip, and the credential status has entered a deliverable, secure-ready state.

[0094] Step S38: The cloud server constructs a credential access entry based on the token string and sends a response containing the credential access entry to the terminal device.

[0095] In one alternative implementation, the credential access point is a Uniform Resource Locator carrying a token string, with a format such as: https: / / invoice.cloud / v?Token=XXXX, where XXXX is the token string.

[0096] Step S4: Construct a near-field communication data exchange format message based on the credential access entry.

[0097] After receiving the credential access entry returned by the cloud server, the near-field communication data exchange format message is constructed based on the credential access entry. Specifically, the near-field communication data exchange format message is encapsulated according to the credential access entry and conforms to the near-field communication data exchange format standard.

[0098] NDEF messages are a standardized data encapsulation format defined by the NFC specification for exchanging information between NFC devices. Each NDEF message consists of one or more NDEF records. Each NDEF record contains a header field and a payload field. The header field identifies the type and attributes of the record, while the payload field carries the actual data content.

[0099] In this application, constructing a near-field communication data exchange format message specifically includes: encapsulating the Uniform Resource Locator in the credential access entry into a URI type NDEF record conforming to the NFC standard.

[0100] URI is one of the record type names defined in the NFC standard, specifically used for identifying and transmitting Uniform Resource Identifiers. This NDEF record follows the record format defined by the NFC URI specification. The record header contains a record type name field (set to "U" to indicate a URI record) and a URI identifier code field. The record payload field is filled with the UTF-8 encoded byte sequence corresponding to the credential access entry.

[0101] The complete data flow for constructing an NDEF message is as follows: The application extracts the credential access entry (e.g., https: / / invoice.cloud / v?Token=XXXX) from the response sent by the cloud server and uses it as the payload input for the NDEF URI record; the application generates a URI identifier code according to the encoding rules specified in the NFC specification (mapping the URL protocol prefix, such as "https: / / ", to the corresponding abbreviation code 0x03), encodes the remaining part of the URL using UTF-8 as a payload byte array, and encapsulates it into a complete NDEF URI record; the NDEF URI record is packaged into an NDEF message according to the NDEF message format (multiple NDEF records may be included if necessary, such as attaching a text record containing credential summary information).

[0102] There is a close relationship between the token string received in step S4 and step S3. The token string received in step S3 is encoded by the cloud server after signing the token data to be signed, and carries a cryptographic hook containing key information such as the device's unique identifier, the credential's unique identifier, and the second signature value. Step S4 encapsulates the token string as a core parameter of the credential access entry into the NDEF message, so that the URI link delivered via NFC not only points to the address for obtaining the original credential, but also embeds verifiable identity information and integrity protection mechanisms. Subsequently, both the cloud server and the terminal security chip can restore the relevant security context through the token string and perform corresponding verification operations.

[0103] Step S5: Activate the near-field communication controller to enter the offline card emulation mode. The near-field communication controller outputs near-field communication data exchange format messages for the user's mobile device to read and obtain electronic credentials.

[0104] Activating the near-field communication controller to enter offline card emulation mode specifically includes: activating the near-field communication controller to enter offline card emulation mode, writing NDEF messages to the buffer of the near-field communication controller, enabling the terminal device to provide NDEF data reading services to the outside world in the form of a card emulation device.

[0105] The buffer is a storage area inside the near-field communication controller or connected via a dedicated interface. It is physically isolated from the general memory areas of the main processor and the main operating system, or isolated through hardware access control mechanisms. Write operations are performed through a secure interface provided by the near-field communication controller driver.

[0106] In one exemplary implementation, the activation process is achieved by sending a mode switching command to the near-field communication controller via the SWP / HCI protocol stack. The application calls the NFC controller's mode setting API, specifies the target operating mode as offline card emulation mode, and specifies the data source as the buffer. Upon receiving the command, the near-field communication controller switches its internal state machine to the card emulation ready state and configures the RF front-end to respond to the polling signals of the external NFC reader in a passive load modulation manner.

[0107] In offline card emulation mode, when the near field communication controller detects an external NFC read request, it does not report the request to the main processor for processing through the host interface. Instead, the state machine and data path inside the near field communication controller autonomously complete the recognition and response to the request.

[0108] Specifically, the near-field communication (NFC) controller continuously listens for polling commands from external NFC readers. Once it detects a select command or read command that conforms to the NDEF read specification, the NFC controller directly addresses and reads the pre-written NDEF message data from its connected buffer. Following the NFC specification, it modulates the NDEF message data block by block and returns it to the external NFC reader. Throughout this response process, the main processor's bus is not occupied, and the main operating system's NDEF service stack and application code do not participate in the data reading and sending process.

[0109] In offline card emulation mode, the near-field communication controller is configured to run independently of the main operating system: NDEF messages are pre-written into its buffer, and the firmware program inside the NFC controller directly manages the identification of read requests and the transmission of data. The entire response path does not involve any part of the main processor and the main operating system. Its technical effects are reflected in: (1) Data path isolation: Since the software stack of the main operating system does not participate in the NFC response process, even if the attacker obtains root privileges or kernel-level control of the main operating system, he cannot intercept or tamper with the NDEF data being transmitted by software means at the physical moment of NFC data delivery; (2) Timing determinism: The firmware of the near-field communication controller processes external polling and read commands in real time, and is not affected by the non-deterministic delay of the main operating system's task scheduling. It can ensure that data transmission is completed within the response time window specified by the NFC protocol, and avoid delivery failure due to timeout; (3) Applicability to special states: When the main operating system of the terminal device is in a state of not being fully started, running abnormally, or unstable after being attacked, as long as the near-field communication controller has been powered on and the offline card emulation mode has been activated, the credential delivery function is still available, which greatly improves the service availability of the system in abnormal situations.

[0110] When a user's mobile device is brought close to the terminal device, the specific interaction process is as follows.

[0111] The NFC chip in the user's mobile device acts as an NFC reader (operating in active mode), continuously transmitting radio frequency carriers and polling commands.

[0112] When a user's mobile device enters the radio frequency range of the terminal device's near-field communication controller, the terminal device's near-field communication controller responds to the polling via load modulation.

[0113] After the user's mobile device detects the response, it sends an NDEF read command to the terminal device.

[0114] In offline card emulation mode, the near-field communication controller of the terminal device directly reads the pre-written NDEF message data from its buffer and returns it to the user's mobile device.

[0115] After a user's mobile device receives an NDEF message, its operating system parses the NDEF record, identifies it as a URI type record, automatically launches the default browser application, and navigates to the credential retrieval address specified in the URI to initiate a credential retrieval request to the cloud server.

[0116] In a preferred embodiment, the user's mobile device does not need to have any specific application related to credential acquisition pre-installed before it is brought close to the terminal device; the mobile device only needs to support NFC and be in an unlocked state. Checking the mobile device's unlocked state is a system-level requirement (the operating system does not return NDEF data to external NFC readers while the screen is locked), but the unlocking operation itself does not involve any active behavior related to credential acquisition. After completing the transaction payment, the user only needs to bring the unlocked phone close to the designated NFC reading area of ​​the terminal device; the entire subsequent credential acquisition process is automatically completed in the background.

[0117] In one alternative implementation, the construction of NDEF messages and the writing of them to the buffer can be performed by the security chip of the terminal device, rather than by the application in the main operating system.

[0118] In this implementation, the application passes the credential access entry to the security chip via the Secure Element API. The security chip constructs an NDEF message internally according to the NDEF specification and writes the NDEF message directly into the buffer of the near-field communication controller through a dedicated secure data channel (e.g., a DWP / SWP single-wire protocol channel) between the security chip and the near-field communication controller.

[0119] The security chip activates the near-field communication controller via control commands to enter offline card emulation mode.

[0120] The security of the NDEF message, constructed by the security chip, further enhances the security of the credential delivery process. The plaintext form of the credential access point exists only within the security chip and the isolated buffer of the near-field communication controller throughout the entire process. The main operating system can never access the plaintext credential access point at any time. Even if the main operating system is recording the screen or sniffing memory during the NDEF construction and writing process, it cannot obtain the actual content of the credential access point. This implementation is particularly suitable for scenarios with extremely high requirements for terminal-side data security, such as fiscal receipts, medical receipts, and large-value payment vouchers.

[0121] In one optional implementation, after the cloud server receives the credential acquisition request initiated by the user's mobile device, the process further includes: the cloud server querying a mapping table based on the token string in the request, verifying the data in the mapping table, and if the verification passes, returning an HTML page carrying the original credential to the user's mobile device; otherwise, indicating that credential acquisition failed.

[0122] In this application, obtaining the mapping table based on the token string in the request specifically includes: querying the database to see if there is a corresponding token string based on the token string in the request; if so, obtaining the mapping table corresponding to the token string; validating the data in the mapping table; otherwise, returning an error. The data verification process in the mapping table specifically includes: the cloud server obtains the root key seed based on the device unique identifier, merchant account, and key version number stored in the mapping table; derives the device symmetric key based on the device unique identifier, the value of the first counter, the key version number, the second random number, and the root key seed; decrypts the first ciphertext in the mapping table using the device symmetric key, based on the device unique identifier, the value of the first counter, the key version number, and the initialization vector, and verifies the authentication tag; if the verification passes, the decrypted credential plaintext is output; the credential plaintext is hashed to obtain the eighth hash value; it is then compared with the seventh hash value in the mapping table; if they match, the eighth hash value and the token string are used to verify the third signature value in the mapping table; if they do not match, an error is displayed, and the process ends; if the third signature value verification passes, an HTML page carrying the credential plaintext is returned to the user's mobile device browser based on the ticket type in the mapping table; otherwise, an error is displayed, and the process ends. The cloud server obtains the root key seed based on the device unique identifier, merchant account, and key version number stored in the mapping table. Before this, the cloud server also verifies whether the difference between the timestamp ts stored in the mapping table and the current time is within a preset valid window, and checks whether the second random number nonce is already in the blacklist. If the difference is within the preset valid window and the second random number is not in the blacklist, the verification is successful. The cloud server then obtains the root key seed based on the device unique identifier, merchant account, and key version number stored in the mapping table.

[0123] In this application, the second random number is used to ensure that the voucher is issued repeatedly and that the same voucher can only be redeemed once. When checking that the second random number nonce does not exist in the blacklist, the cloud server also writes the second random number into the blacklist.

[0124] In this application, users can view the credentials in a browser and choose to download the credentials in PDF format or send the credentials to a designated email address.

[0125] It should be understood that the numbering and order of the above steps are merely illustrative and can be reasonably adjusted by those skilled in the art without departing from the core concept of the present invention. For example, the execution order of timestamp verification and random number verification can be interchanged; the order of token signature verification and second signature value verification can be interchanged; and some preprocessing steps can be executed in parallel.

[0126] Corresponding to the above method, this application also provides an electronic credential acquisition terminal device, as described above. Figure 2 The terminal device 100 includes a credential acquisition module 101, a signature module 102, a request sending module 103, a response receiving module 104, a data processing module 105, a message construction module 106, and an output control module 107.

[0127] The voucher acquisition module 101 is configured in the application and is used to acquire voucher elements.

[0128] The signature module 102 is configured to interact with the security chip and generate a first signature value based on the credential elements through the security chip.

[0129] The request sending module 103 is configured in the application to send a credential generation request containing a first signature value and credential elements to the cloud server.

[0130] The response receiving module 104 is configured in the application to receive a response from the cloud server containing encrypted credential data generated based on credential elements, and also to receive a response from the cloud server containing a credential access entry.

[0131] The data processing module 105 is used to process the encrypted credential data through the security chip and return the data packet processed by the security chip to the cloud server. The message construction module 106 can be configured in the application or security chip according to different implementations, and is used to construct near-field communication data exchange format messages based on the credential access entry.

[0132] The output control module 107 can be configured in the application or security chip according to different implementation methods. It is used to activate the near-field communication controller to enter the offline card emulation mode, and output near-field communication data exchange format messages through the near-field communication controller, so that the user's mobile device can read the near-field communication data exchange format messages to obtain electronic credentials.

[0133] Corresponding to the above method, this application also provides an electronic credential acquisition system, including a cloud server, a terminal device, and a user mobile device, which is used to perform the steps described in the electronic credential acquisition method.

[0134] In the above implementation, the process of the user's mobile device obtaining the original credential text depends on the confirmation that the original credential text has been decrypted in the terminal device's security chip (i.e., the generation and verification of the third signature value). Furthermore, the credential access point only returns to the application after the third signature value has been verified and the credential status has entered "pending delivery." This design strictly binds the security of credential delivery to the authorization of the original credential text processing, ensuring that only credentials that have been legally processed and authorized by the terminal security chip can enter the delivery stage.

[0135] Compared with existing technologies, the technical solution of this application realizes a full-link security protection system from the initiation of credential generation request to the delivery of credential to the user's mobile device. At the request initiation end, the first signature value is generated by the device private key built into the security chip, anchoring the authenticity of the request to the hardware root of trust, effectively preventing request forgery. At the data transmission and encryption end, counter and authentication encryption technologies are used to realize one-time encryption and ciphertext anti-tampering protection for device binding. At the same time, multi-layer signature mechanisms such as token signature and ciphertext signature ensure the integrity of data in multiple transmission links. At the security chip processing end, a triple verification defense and a dedicated key derivation path are set up to ensure that only data that has passed through layers of verification can enter the decryption environment of the security chip. At the credential delivery end, the independent response capability of the NFC controller is realized through the offline card emulation mode, completely isolating the delivery path of the credential access entry from the main operating system, and realizing hardware-level delivery security. In addition, the user interface is extremely simplified: in the entire credential acquisition process, the user does not need to install a specific application, does not need to actively initiate any operation, does not need to scan or input, and only needs to bring the mobile device close to the terminal to automatically complete the credential acquisition. This combination of a user-friendly interface and robust backend security mechanisms provides a solid technical foundation for the large-scale deployment and user acceptance of electronic credentials.

[0136] The present invention also provides an electronic device, including a memory and a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement an electronic credential acquisition method.

[0137] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements an electronic credential acquisition method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0138] It should be understood that the above embodiments are merely illustrative examples of the technical solutions of the present invention and are not intended to limit the present invention. For those skilled in the art, several improvements and substitutions can be made without departing from the principles of the present invention, and these improvements and substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A method for obtaining electronic vouchers, characterized in that, The method includes: Step S1: The terminal device obtains the credential elements and generates a first signature value based on the credential elements through the security chip; Step S2: The terminal device sends a credential generation request containing the first signature value and the credential elements to the cloud server; Step S3: The terminal device receives a response from the cloud server containing encrypted credential data generated based on the credential elements, processes the encrypted credential data through the security chip, and returns the data packet processed by the security chip to the cloud server; Step S4: The terminal device receives a response from the cloud server containing a credential access entry, and constructs a near-field communication data exchange format message based on the credential access entry; Step S5: The terminal device activates the near-field communication controller to enter the offline card emulation mode, and outputs the near-field communication data exchange format message through the near-field communication controller, so that the user's mobile device can read the near-field communication data exchange format message to obtain the electronic certificate.

2. The method according to claim 1, characterized in that, The step of generating a first signature value based on the credential elements using a security chip includes: The security chip performs a hash calculation on the credential element to obtain a first hash value, and signs the first hash value using the device private key to obtain the first signature value, wherein the device private key is stored in the security chip.

3. The method according to claim 1, characterized in that, Before receiving the response from the cloud server containing encrypted credential data generated based on the credential elements, the method further includes: The cloud server verifies the first signature value, and generates the original credential text upon successful verification. The cloud server encrypts the original credential text to obtain the encrypted credential data, and sends a response containing the encrypted credential data to the terminal device.

4. The method according to claim 3, characterized in that, Before the cloud server verifies the first signature value, the method further includes: The cloud server checks whether the difference between the first timestamp in the credential element and the current time of the cloud server is within a preset time range. If so, it continues to verify; otherwise, it returns an error.

5. The method according to claim 3, characterized in that, Before the cloud server verifies the first signature value, the method further includes: The cloud server checks whether the first random number in the credential element already exists in the random number blacklist. If it does not exist, the first random number is added to the random number blacklist and the verification continues; otherwise, an error is returned.

6. The method according to claim 3, characterized in that, The generated original voucher text specifically includes: the cloud server generating a unique voucher identifier and a second random number, obtaining the current time of the cloud server as a second timestamp, obtaining the merchant account based on the unique device identifier in the voucher elements, and concatenating the unique voucher identifier, merchant account, second timestamp, second random number, and order identifier and transaction amount in the voucher elements to obtain the original voucher text.

7. The method according to claim 6, characterized in that, The cloud server encrypts the original credential text to obtain the encrypted credential data, which includes: Step S221: The cloud server obtains the value of the first counter, the key version number, and the root key seed, and derives the device symmetric key based on the device unique identifier, the value of the first counter, the key version number, the root key seed, and the second random number. Step S222: The cloud server generates an initialization vector based on the value of the first counter, uses the device unique identifier, the value of the first counter, and the key version number as additional authentication data, and uses the device symmetric key to authenticate and encrypt the original credential, the initialization vector, and the additional authentication data to obtain the first ciphertext and the authentication tag; Step 223: The cloud server uses the device unique identifier, credential unique identifier, second timestamp, second random number, first counter value, key version number, first ciphertext and authentication tag as the first data to be signed, performs a hash operation on the first data to be signed, and signs the hash result using the private key to obtain the second signature value; Step S224: The cloud server generates a token string based on the second signature value, creates a mapping table using the token string as an index value, and stores the device unique identifier, merchant account, credential unique identifier, second timestamp, second random number, initialization vector, first counter value, key version, first ciphertext, authentication tag and credential type in the mapping table; Step S225: The cloud server uses the first ciphertext, authentication tag, initialization vector, second random number, value of the first counter, key version number and token string as encrypted credential data.

8. The method according to claim 1, characterized in that, The processing of the encrypted credential data via the security chip specifically includes: The security chip verifies the encrypted credential data, and obtains the original credential text upon successful verification. The security chip performs a hash operation on the original credential to obtain a seventh hash value, uses the seventh hash value and the token string in the encrypted credential data as the second data to be signed, and signs the second data to be signed using the internally stored device private key to obtain a third signature value. The security chip obtains the root key seed and the value of the local counter, and derives the session key based on the value of the local counter, the root key seed, the device unique identifier in the encrypted credential data, the key version number and the second random number. It also obtains the current terminal timestamp and uses the session key to encrypt the third signature value, the token string and the current terminal timestamp to obtain the session verification code. The security chip organizes the token string, the third signature value, the seventh hash value, the session verification code, and the current terminal timestamp into a data packet.

9. The method according to claim 8, characterized in that, The security chip verifies the encrypted credential data, specifically including: Step S321: The security chip parses the token string in the encrypted credential data to obtain the token to be signed data and the token signature value, and uses its internally preset server public key to verify the token signature value. After the verification is successful, step S322 is executed. Step S322: The security chip verifies the second signature value in the token to be signed data. After the verification is successful, step S323 is executed. Step S323: The security chip decrypts and verifies the first ciphertext and authentication tag in the encrypted credential data.

10. The method according to claim 1, characterized in that, After returning the data packet processed by the security chip to the cloud server, the method further includes: The cloud server parses the token string in the data packet, queries the corresponding record in the mapping table, obtains the current cloud timestamp, and determines whether the difference between the cloud timestamp and the current terminal timestamp in the data packet meets the preset conditions. If so, it derives a session key and verifies the session verification code in the data packet. After successful verification, it uses the device public key to verify the third signature value in the data packet. After successful verification, it stores the third signature value in the mapping table; otherwise, it returns an error. The cloud server constructs a credential access entry based on the token string and sends a response containing the credential access entry to the terminal device.

11. The method according to claim 1, characterized in that, The process of constructing a near-field communication data exchange format message based on the credential access entry includes: The Uniform Resource Locator in the credential access entry is encapsulated into a Uniform Resource Identifier type record conforming to the NFC standard, and the payload field of the record is a credential acquisition address containing a token string.

12. The method according to claim 1, characterized in that, Before the terminal device activates the near-field communication controller to enter the offline card emulation mode, the method further includes: writing the near-field communication data exchange format message into the buffer of the near-field communication controller; In the offline card emulation mode, the near-field communication controller directly accesses the buffer in response to external read requests.

13. The method according to claim 1, characterized in that, The specific steps for the terminal device to activate the near-field communication controller and enter the offline card emulation mode are as follows: the terminal device constructs the near-field communication data exchange format message through the security chip and writes it into the buffer of the near-field communication controller, thereby activating the near-field communication controller to enter the offline card emulation mode.

14. The method according to claim 1, characterized in that, The method further includes: when the user's mobile device is close to the terminal device, the near-field communication controller of the terminal device reads a pre-written near-field communication data exchange format message from the buffer in offline card emulation mode and returns it to the user's mobile device.

15. The method according to claim 14, characterized in that, After returning the information to the user's mobile device, the process further includes: the user's mobile device parsing the near-field communication data exchange format message to obtain the credential acquisition address, and initiating a credential acquisition request to the cloud server.

16. The method according to claim 15, characterized in that, The method further includes: the cloud server receiving a credential acquisition request initiated by the user's mobile device, querying a mapping table based on the token string in the request, verifying the data in the mapping table, and if the verification passes, returning the original credential text to the user's mobile device; otherwise, indicating that credential acquisition failed.

17. A terminal device, characterized in that, include: The voucher acquisition module is used to acquire voucher elements; A signature module, which is used to generate a first signature value based on the credential elements via a security chip; The request sending module is used to send a credential generation request containing the first signature value and the credential elements to the cloud server; The response receiving module is used to receive a response from the cloud server containing encrypted credential data generated based on the credential elements, and also to receive a response from the cloud server containing a credential access entry. A data processing module is used to process the encrypted credential data through the security chip and return the data packet processed by the security chip to the cloud server; The message construction module is used to construct a near-field communication data exchange format message based on the credential access entry. The output control module is used to activate the near-field communication controller to enter the offline card emulation mode. The near-field communication controller outputs the near-field communication data exchange format message, which is then read by the user's mobile device to obtain an electronic certificate.

18. An electronic credential acquisition system, comprising a cloud server, a terminal device, and a user mobile device, the system being used to perform the steps of the method as described in any one of claims 1-16.

19. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method according to any one of claims 1-16.

20. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-16.

Images