A method, device and medium for signing and reinforcing a HAP (Harmony Advanced Protocol) packet

Abstract

The application discloses a kind of methods, equipment and media to the signing of HAP package is reinforced, comprising: executing the signing of original native, generates HAP application package;According to HAP application package, generates Manifest signature data, and is embedded into HAP Signing Block signature block;The verification of the signing of original native is executed;From HAP Signing Block signature block, obtain Manifest signature data;According to Manifest signature data, the verification of HAP application package is carried out;After verification, install HAP application package on POS terminal equipment, and save Manifest signature data;Periodically obtain the application list file signature that has been saved from installation position, and according to application list file signature, the self-checking of HAP application package that has been installed is carried out.The application can improve the security of HAP application package, satisfy the security requirement of financial POS industry.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and particularly relates to a method and device for signing and reinforcing a Harmony Application Package (HAP) and a medium. BACKGROUND

[0002] HAP (Harmony Application Package) is an application package format of the Harmony system, which is similar to the design of the APK package of the Android system. The HAP package is actually based on the ZIP file format specification, and the signed HAP is only inserted with the signature data block defined by the Harmony in the case of not destroying the original ZIP format.

[0003] A standard ZIP file is composed of the following five parts: a local file header (a local file header corresponding to each file), data (actual file data, which may be compressed or uncompressed), a data descriptor, a central directory file header (a central directory file header corresponding to each file), and an end of central directory record (the end position of the compressed file, hereinafter referred to as EOCD, which is globally only one).

[0004] When multiple files are compressed into a ZIP package, the multiple files are stored separately in the ZIP package, and each file generates an entry (record). The entry includes the local file header at the front, the data (actual file data, which may be compressed or uncompressed) in the middle, and the data descriptor (which is conditionally present) at the end, that is, a single entry includes: local file header + data + data descriptor.

[0005] After the entries of all files are stored, a central directory file header is generated. Each file corresponds to a central directory file header, and after all central directory file headers are ended, an EOCD is added. A ZIP file has only one EOCD. The central directory file header records the positioning information of each entry, and the ZIP file is quickly positioned according to the central directory during decompression, without reading the complete file for searching.

[0006] As an installation package of applications, in order to ensure the integrity and reliable source of OpenHarmony applications, the application needs to be signed when the application is built. Only the signed application can be installed, run and debug on the real machine device. The signature scheme of the standard HAP, that is, a HAP Signing Block signature block is added before the central directory file area on the basis of not destroying the record of the central directory file area, and the structure is as shown in Figure 1 The application signature verification installation process of the HAP package is divided into two parts: first, the HAP Singing Block signature block is taken out for signature verification, and then the ZIP file format is decompressed and installed.

[0007] The standard HAP signature of Harmony adopts PKI technology, supports RSA and ECC algorithm signature, and the HAP Signing Block signature block mainly consists of two parts:

[0008] 1. HAP SigningBlockData signature block specific data, including multiple different types of sub-blocks, such as profile block and signature block;

[0009] 2. HAP SigningBlockHeader signature block header, fixed as 32 bytes, including the judgment mark and length information of the entire signature block;

[0010] Among them, HAPSigningBlockData includes two standard pkcs#7 signature files, which are profile signature and application signature, and the application signature is the signature of the unsigned original ZIP compressed file package. In the installation stage of the application, the application installation is responsible for the application installation by the OpenHarmony user program framework subsystem. After receiving the application installation package, the application program framework subsystem needs to parse the signature data of the installation package, and then verify the signature using the API of the application integrity verification module. Only after the verification is successful, the application is allowed to be installed. The application integrity verification module will use the system preset public key certificate to verify the signature when verifying the signature data of the installation package. The signature verification process is as follows:

[0011] Parse the HAP Signing Block to obtain the Profile signature and the application signature;

[0012] Verify the signature of the Profile file by using the preset profile signature verification public key certificate;

[0013] Verify the application signature by using the preset application signature verification public key certificate;

[0014] Through the above process, it can be known that after the signature verification is passed, the HAP package will be processed according to the standard ZIP file, and is directly decompressed and installed to the specified position, and the original HAP installation package is no longer saved, and the signature information in the HAP Signing Block will no longer be reserved, that is, the signature verification of the application is only performed once in the application installation stage, and subsequent verification cannot be performed, so if the application is illegally tampered after installation, the system cannot identify and trace back.

[0015] In the financial POS industry, there are clear security standard requirements for the protection of the installed application. For example, according to the PCI security specification, the POS terminal payment device needs to perform system self-checking at system startup and every 24 hours, and needs to recheck the authenticity and integrity of the installed application. Through the above description of the original signature scheme of the Hongmeng, it can be known that since the original signature of the Hongmeng HAP is lost after the application is installed, the self-checking requirement of rechecking the integrity of the application at regular intervals after installation cannot be met. SUMMARY

[0016] Therefore, the purpose of the present application is to provide a method for signing and reinforcing the Hongmeng HAP package, which adds an application list file to save the file name and hash value of each application file of the HAP application package and its list signature file on the basis of the original signature of the Hongmeng HAP, so as to realize the security self-checking of the HAP application package, improve the security of the HAP application package, and meet the security requirements of the financial POS industry.

[0017] In order to achieve the above technical purposes, the technical scheme adopted by the present application is:

[0018] The present application provides a method for signing and reinforcing the Hongmeng HAP package, comprising the following steps:

[0019] Step 1, performing the original signature of Hongmeng to generate a Hongmeng standard HAP application package;

[0020] Step 2, generating Manifest signature data according to the HAP application package, and embedding the Manifest signature data into the HAP Signing Block signature block of the HAP application package;

[0021] Step 3, performing the signature verification of the original signature of Hongmeng, and after the signature verification is passed, entering step 4;

[0022] Step 4, obtaining the Manifest signature data from the HAP Signing Block signature block;

[0023] Step 5, verifying the HAP application package according to the Manifest signature data; after the signature verification is passed, installing the HAP application package on the POS terminal device, and saving the Manifest signature data at the installation position;

[0024] Step 6, periodically obtaining the saved application list file signature from the installation location, and performing self-checking on the installed HAP application package according to the application list file signature.

[0025] Further, the step 2 specifically comprises:

[0026] Step 21, parsing the HAP application package to obtain the file name of each application file in the HAP application package, and sequentially calculating the hash value corresponding to each application file in the HAP application package according to the hash algorithm;

[0027] Step 22, generating an application list file according to the file name and hash value corresponding to all application files in the HAP application package;

[0028] Step 23, signing the application list file using the application signature private key to generate a list signature file;

[0029] Step 24, embedding the Manifest signature data composed of the application list file and the list signature file into the HAP Signing Block signature block of the HAP application package to complete the signing.

[0030] Further, the list signature file adopts the PCKS#7 format, and the list signature file includes the digital signature information of the application list file and the used application signature certificate.

[0031] Further, the step 24 specifically comprises:

[0032] Step 241, the HAP Signing Block signature block of the HAP application package includes a HAP Signing Block Header signature block header and a HAP Signing Block Data signature block specific data;

[0033] Step 242, setting the corresponding header information and data information according to the Manifest signature data;

[0034] Step 243, embedding the header information into the HAP Signing Block Header; the header information includes type, length and offset, and the type includes the ID corresponding to the Manifest signature data;

[0035] Step 244, embedding the data information into the HAP Signing Block Data, and the data information includes the offset and the Manifest signature data.

[0036] Further, the step 4 of obtaining the Manifest signature data from the HAP Signing Block specifically comprises:

[0037] Step 41, obtaining the header information matched with the ID from the HAP Signing Block according to the ID corresponding to the Manifest signature data;

[0038] Step 42, obtaining the recorded offset from the header information;

[0039] Step 43, finding the corresponding data information from the HAP Signing Block Data according to the offset;

[0040] Step 44, obtaining the corresponding Manifest signature data from the data information to obtain the application manifest file and the manifest signature file.

[0041] Further, the step 5 specifically comprises:

[0042] Step 51, the manufacturer preinstalls the application signature certificate used for signature verification in the POS terminal device when the POS terminal device is manufactured;

[0043] Step 52, using the preinstalled application signature certificate to verify the manifest signature file;

[0044] Step 53, after the verification is passed, sequentially parsing the file name of each application file in the HAP application package, and sequentially calculating the hash value corresponding to each application file in the HAP application package according to the hash algorithm;

[0045] Step 54, comparing the file name and the hash value of each application file in the HAP application package with the file name and the hash value of each application file recorded in the application manifest file one by one, and judging whether each application file in the HAP application package is consistent with each application file recorded in the application manifest file, if yes, it proves that the HAP application package is legal, the verification is passed, and the step 55 is entered; if not, it is judged that the HAP application package is damaged, and the verification fails;

[0046] Step 55, decompressing the HAP application package, and installing the decompressed HAP application package under the corresponding installation directory;

[0047] Step 56, storing the application manifest file and the manifest signature file to the corresponding position of the installation directory.

[0048] Further, the step 6 specifically comprises:

[0049] Step 61, when the POS terminal device is started and reaches a set self-checking time, scanning all installation directories of applications in the POS terminal device;

[0050] Step 62, taking out a corresponding application list file and a list signature file from a corresponding position of the installation directory;

[0051] Step 63, using a pre-installed application signature certificate to verify the list signature file;

[0052] Step 64, after the verification is passed, sequentially analyzing a file name of each application file in the installation directory, and sequentially calculating a hash value corresponding to each application file in the installation directory according to a hash algorithm;

[0053] Step 65, one by one comparing the file name and the hash value of each application file in the installation directory with the file name and the hash value of each application file recorded in the application list file, judging whether each application file in the installation directory is consistent with each application file recorded in the application list file, if yes, proving that all application files in the installation directory are legal, and the verification is passed; if no, judging that all application files in the installation directory have been illegally tampered with, and the verification fails, and deleting and alarming.

[0054] Further, the set self-checking time is to perform self-checking once every 24 hours.

[0055] The application further provides an electronic device, including a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the method for signing and reinforcing the HAP package when executing the program.

[0056] The application further provides a computer readable storage medium, which stores a computer program, and the program is executable on the processor to implement the method for signing and reinforcing the HAP package.

[0057] Compared with the prior art, the application has the beneficial effects that:

[0058] 1. The signing verification scheme first generates an application list file according to the file name and the hash value of each application file in the HAP application package, then protects the application list file by signing, and generates a list signature file; the authenticity and integrity of the application list file are protected to ensure that the application file is tamper-proof, so that it is not necessary to perform individual signature verification on each application file, and the efficiency of application signing and the performance of system self-checking verification can be significantly improved.

[0059] 2. By embedding the Manifest signature data in the HAP Signing Block, the Manifest signing can be performed after the original HAP signing, without destroying the original HAP signature information and package format, ensuring the forward compatibility of the signed HAP application package, and the signed HAP application package can still be verified by the standard process of the Harmony.

[0060] 3. The Manifest signature data (including the application manifest file and the manifest signature file) can still be saved in the HAP application package after the installation of the Manifest signed HAP application package, thereby meeting the self-checking requirements of the tamper-proofing of the application. BRIEF DESCRIPTION OF DRAWINGS

[0061] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0062] Figure 1 is an execution flow diagram of a method for signing and hardening a Harmony HAP package provided by an embodiment of the present application.

[0063] Figure 2 is a signature position diagram provided by an embodiment of the present application.

[0064] Figure 3 is a schematic diagram of an electronic device provided by an embodiment of the present application.

[0065] Figure 4 is a schematic diagram of a computer readable storage medium provided by an embodiment of the present application. DETAILED DESCRIPTION

[0066] The present application will be further described in detail below in combination with the drawings and embodiments. It is particularly pointed out that the following embodiments are only used to illustrate the present application, but do not limit the scope of the present application. Similarly, the following embodiments are only some embodiments of the present application, but not all embodiments of the present application, and all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0067] Analysis of the native signature format of HarmonyOS applications reveals that HarmonyOS applications are actually based on ZIP format compressed files, with a signature data block added before the central directory file area. The design concept of this invention is to directly perform a secondary signature on the entire signed HarmonyOS HAP application package (the file itself has already been natively signed by HarmonyOS applications). A special application manifest file signature (Manifest signature data) is added to the HAP Signing Block of the HAP application package. This achieves the goal of adding signature information to the application manifest file while ensuring that the added signature information does not affect the original HarmonyOS application installation process. The generated Manifest signature data is embedded into the HAP Signing Block between the compressed file content source data and the directory source data.

[0068] Please see Figure 1 and Figure 2 The present invention provides a method for signature hardening of HarmonyOS HAP packets, comprising the following steps:

[0069] Step 1: Perform HarmonyOS native signing to generate a HarmonyOS standard HAP application package;

[0070] Step 2: Generate Manifest signature data based on the HAP application package, and embed the Manifest signature data into the HAP Signing Block of the HAP application package;

[0071] In this embodiment, step 2 specifically includes:

[0072] Step 21: Parse the HAP application package to obtain the filename of each application file in the HAP application package, and calculate the hash value corresponding to each application file in the HAP application package according to a hash algorithm (e.g., SHA-256). A hash value is a "data fingerprint" obtained through a hash algorithm. It is a set of binary values ​​obtained by encrypting a set of input information of arbitrary length. The main characteristic of a hash value is its uniqueness, that is, once the original data undergoes any slight change, its hash value will also change significantly. A hash value can be regarded as the DNA or ID card of a piece of data (such as a file or string), used for file verification or signing.

[0073] Step 22: Generate an application manifest file (MANIFEST.SF) based on the filenames and hash values ​​of all application files in the HAP application package;

[0074] Step 23: Sign the application manifest file using the application signing private key to generate a manifest signature file (CERT.SGN); calculate the digest of the application file to be signed using a hash function to generate a fixed-length hash value, and then encrypt this hash value using the application signing private key to generate a digital signature. The hash value and the signature together ensure the security and authenticity of the information.

[0075] In this embodiment, the manifest signing file adopts the PCKS#7 format, which includes the digital signature information of the application manifest file and the application signing certificate used. The PCKS#7 format is widely supported and used, and can provide a consistent signing and verification process across different systems and applications.

[0076] Step 24: Embed the Manifest signature data, consisting of the application manifest file and the manifest signature file, into the HAP Signing Block of the HAP application package to complete the signing.

[0077] This signature verification scheme first generates an application manifest file based on the filename and hash value of each application file in the HAP application package, and then signs and protects the application manifest file to generate a manifest signature file. By protecting the authenticity and integrity of the application manifest file, the scheme ensures that the application files are tamper-proof, thus eliminating the need for separate signature verification for each application file. This significantly improves the efficiency of application signing and the performance of system self-check verification.

[0078] The specific content design of MANIFEST.SF and CERT.SGN is as follows:

[0079]

[0080]

[0081]

[0082] In this embodiment, step 24 specifically includes:

[0083] Step 241: The HAP Signing Block of the HAP application package includes the HAP SigningBlockHeader header and the HAP SigningBlockData data.

[0084] Step 242: Set the corresponding header and data information according to the Manifest signature data;

[0085] Step 243: Embed the header information into the HAP SigningBlockHeader; the header information includes type, length and offset, and the type includes the ID corresponding to the Manifest signature data, for example: ID is 0x4e505420;

[0086] Step 244: Embed the data information into HAP SigningBlockData. The data information includes offset and Manifest signature data. The offset allows for the association between header information and data information, enabling quick location of the Manifest signature data within the data information.

[0087] By embedding Manifest signature data in the HAP Signing Block, Manifest signing can be performed after the native HarmonyOS signature, without destroying the original HAP signature information and package format. This ensures the forward compatibility of the signed HAP application package, and the signed HAP application package can still be verified through the HarmonyOS standard process.

[0088] After the HAP application package is signed by HarmonyOS natively, a Manifest signing is performed to embed the Manifest signature data described above into the HAP Signing Block. The HAP Signing Block format is designed as follows:

[0089]

[0090]

[0091]

[0092] The specific data format for writing to the custom data location in the HAP Signing Block is as follows: The signature data is encoded in DER format, stored in little-endian, and is named HapSigningBlockData:

[0093]

[0094] Step 3: Perform signature verification using HarmonyOS native signature. After successful verification, proceed to Step 4.

[0095] Step 4: Obtain the Manifest signature data from the HAP Signing Block;

[0096] In this embodiment, step 4, obtaining the Manifest signature data from the HAP Signing Block, specifically includes:

[0097] Step 41: Parse the header information matching the ID from the HAP SigningBlockHeader based on the ID corresponding to the Manifest signature data; that is, parse the header information with ID 0x4e505420 from the HAP SigningBlockHeader.

[0098] Step 42: Obtain the offset of the record from the header information;

[0099] Step 43: Find the corresponding data information from HAP SigningBlockData based on the offset;

[0100] Step 44: Obtain the corresponding Manifest signature data from the data information to obtain the application manifest file and manifest signature file.

[0101] Step 5: Verify the HAP application package based on the Manifest signature data; after successful verification, install the HAP application package on the POS terminal device and save the Manifest signature data in the installation location.

[0102] In this embodiment, step 5 specifically includes:

[0103] Step 51: When the POS terminal device leaves the factory, the manufacturer pre-installs the application signature certificate used for signature verification in the POS terminal device;

[0104] Step 52: Use the pre-installed application signing certificate to verify the manifest signing file, thereby verifying the authenticity and completeness of the application manifest file. If the verification passes, it means that the application manifest file is authentic and complete, and can be used as the basis for subsequent verification; if the verification fails, it means that the application manifest file is not authentic and / or incomplete, and cannot be used as the basis for subsequent verification.

[0105] Step 53: After the signature verification is successful, the filenames of each application file in the HAP application package are parsed out in sequence, and the hash values ​​corresponding to each application file in the HAP application package are calculated in sequence according to the hash algorithm.

[0106] Step 54: Compare the filename and hash value of each application file in the HAP application package with the filename and hash value of each application file recorded in the application manifest file. If they match, the HAP application package is valid and the verification is successful. Proceed to Step 55. If not, the HAP application package is corrupted and the verification fails.

[0107] Step 55: Unzip the HAP application package and install the unzipped HAP application package in the corresponding installation directory;

[0108] Step 56: Store the application manifest file and manifest signature file in the corresponding location in the installation directory (e.g., . / SIGN-INF / directory) for persistent storage, which will be used for signature verification during subsequent POS terminal device self-tests. HAP application packages signed with the Manifest will retain Manifest signature data (including the application manifest file and manifest signature file) after installation, thus meeting the application's tamper-proof self-test requirements.

[0109] Step 6: Periodically retrieve the saved application manifest file signatures from the installation location, and perform self-checks on the installed HAP application packages based on the application manifest file signatures.

[0110] In this embodiment, step 6 specifically includes:

[0111] Step 61: When the POS terminal device is powered on and reaches the set self-test time, the set self-test time is to perform a self-test once every 24 hours; scan the installation directory of all applications in the POS terminal device;

[0112] Step 62: Retrieve the corresponding application manifest file and manifest signature file from the corresponding location in the installation directory (e.g., . / SIGN-INF / directory);

[0113] Step 63: Use the pre-installed application signing certificate to verify the manifest signing file; thereby verifying the authenticity and completeness of the application manifest file. If the verification passes, it means that the application manifest file is authentic and complete and can be used as the basis for subsequent verification; if the verification fails, it means that the application manifest file is not authentic and / or incomplete and cannot be used as the basis for subsequent verification.

[0114] Step 64: After the signature verification is successful, the filenames of each application file in the installation directory are parsed out in turn, and the hash value corresponding to each application file in the installation directory is calculated in turn according to the hash algorithm.

[0115] Step 65: Compare the filename and hash value of each application file in the installation directory with the filename and hash value of each application file recorded in the application manifest file. If they match, all application files in the installation directory are valid and the verification is successful. If not, all application files in the installation directory have been illegally modified, the verification fails, and the files are deleted and an alarm is triggered.

[0116] like Figure 3As shown, embodiments of the present invention also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement one of the methods described above.

[0117] like Figure 4 As shown, embodiments of the present invention also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0118] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0119] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for signature reinforcement of HarmonyOS HAP packets, characterized in that, Includes the following steps: Step 1: Perform HarmonyOS native signing to generate a HarmonyOS standard HAP application package; Step 2: Generate Manifest signature data based on the HAP application package, and embed the Manifest signature data into the HAP Signing Block of the HAP application package; specifically including: Step 21: Parse the HAP application package, obtain the filename of each application file in the HAP application package, and calculate the hash value corresponding to each application file in the HAP application package in turn according to the hash algorithm; Step 22: Generate an application manifest file based on the filenames and hash values ​​of all application files in the HAP application package; Step 23: Sign the application manifest file using the application signing private key to generate a manifest signing file; Step 24: Embed the Manifest signature data, consisting of the application manifest file and the manifest signature file, into the HAP Signing Block of the HAP application package to complete the signing. Step 3: Perform signature verification using HarmonyOS native signature. After successful verification, proceed to Step 4. Step 4: Obtain the Manifest signature data from the HAP Signing Block; Step 5: Verify the HAP application package based on the Manifest signature data; after successful verification, install the HAP application package on the POS terminal device and save the Manifest signature data in the installation location. Step 6: Periodically retrieve the saved application manifest file and manifest signature file from the installation location, and perform a self-check on the installed HAP application packages based on the application manifest file and manifest signature file.

2. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 1, characterized in that, The manifest signing file uses the PCKS#7 format and includes the digital signature information of the application manifest file and the application signing certificate used.

3. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 2, characterized in that, Step 24 specifically includes: Step 241: The HAP Signing Block of the HAP application package includes the HAP SigningBlockHeader header and the HAP SigningBlockData data. Step 242: Set the corresponding header and data information according to the Manifest signature data; Step 243: Embed the header information into the HAP SigningBlockHeader; the header information includes type, length and offset, and the type includes the ID corresponding to the Manifest signature data; Step 244: Embed the data information into HAP SigningBlockData, the data information including offset and Manifest signature data.

4. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 3, characterized in that, Step 4, obtaining the Manifest signature data from the HAP Signing Block, specifically includes: Step 41: Parse the header information matching the ID from the HAP SingingBlockHeader based on the ID corresponding to the Manifest signature data; Step 42: Obtain the offset of the record from the header information; Step 43: Find the corresponding data information from HAP SigningBlockData based on the offset; Step 44: Obtain the corresponding Manifest signature data from the data information to obtain the application manifest file and manifest signature file.

5. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 4, characterized in that, Step 5 specifically includes: Step 51: When the POS terminal device leaves the factory, the manufacturer pre-installs the application signature certificate used for signature verification in the POS terminal device; Step 52: Verify the signature of the manifest signing file using the pre-installed application signing certificate; Step 53: After the signature verification is successful, the filenames of each application file in the HAP application package are parsed out in sequence, and the hash values ​​corresponding to each application file in the HAP application package are calculated in sequence according to the hash algorithm. Step 54: Compare the filename and hash value of each application file in the HAP application package with the filename and hash value of each application file recorded in the application manifest file. If they match, the HAP application package is valid and the verification is successful. Proceed to Step 55. If not, the HAP application package is corrupted and the verification fails. Step 55: Unzip the HAP application package and install the unzipped HAP application package in the corresponding installation directory; Step 56: Store the application manifest file and manifest signature file in the corresponding location in the installation directory.

6. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 5, characterized in that, Step 6 specifically includes: Step 61: When the POS terminal device is powered on and reaches the set self-test time, scan the installation directory of all applications in the POS terminal device; Step 62: Retrieve the corresponding application manifest file and manifest signature file from the corresponding location in the installation directory; Step 63: Verify the signature of the manifest signing file using the pre-installed application signing certificate; Step 64: After the signature verification is successful, the filenames of each application file in the installation directory are parsed out in turn, and the hash value corresponding to each application file in the installation directory is calculated in turn according to the hash algorithm. Step 65: Compare the filename and hash value of each application file in the installation directory with the filename and hash value of each application file recorded in the application manifest file. Determine if each application file in the installation directory matches the application file recorded in the application manifest file. If they match, all application files in the installation directory are valid and the verification passes. If not, all application files in the installation directory have been illegally modified, the verification fails, and the files are deleted and an alarm is triggered.

7. The method for signature reinforcement of HarmonyOS HAP packets as described in claim 6, characterized in that, The self-check time is set to be performed once every 24 hours.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements a method for signing and hardening HarmonyOS HAP packets as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements a method for signing and hardening HarmonyOS HAP packets as described in any one of claims 1 to 7.

Images