Analysis of HarmonyOS NEXT Application Signature and Verification Mechanism

Background

HarmonyOS NEXT (released 2024‑10‑23) supports only native applications and drops Android compatibility. This article analyses the signing mechanism of single‑framework HarmonyOS apps, walks through each practical step, and explains the underlying verification logic based on public documentation and source code.

Signature Mechanism Overview

The signing workflow is implemented in the developtools_hapsigner repository (OpenHarmony‑v5.0.0‑Release). It consists of three grouped steps: (1) generate a developer signing certificate, (2) generate a signing profile, and (3) generate the signed app.

1. Generate Developer Signing Certificate

DevEco‑Studio can directly create a PKCS#12 file ( my.p12) that contains the developer’s public‑private key pair. The file follows RFC 7292 (PKCS#12) and can be inspected with OpenSSL:

openssl asn1parse -in my.p12 -inform DER   // decode DER and parse ASN.1
openssl pkcs12 -info -in my.p12          // view certificate and private key

The extracted PEM certificate begins with -----BEGIN CERTIFICATE----- and conforms to RFC 7468. The public key is an EC P‑256 key; its fingerprint is computed as SHA‑256 of the DER‑encoded public key, then Base64‑encoded.

2. Generate Certificate Signing Request (CSR)

DevEco‑Studio also creates a PKCS#10 CSR file ( my.csr) that contains the same public key and the subject fields supplied by the developer platform. The CSR can be examined with: openssl req -text -noout -verify -in my.csr The CSR’s subject initially appears as CN=testscr.

3. Obtain Developer Leaf Certificate

The CSR is uploaded to the Huawei developer portal, which issues a leaf certificate signed by Huawei’s intermediate certificate. The leaf certificate includes the public key from the CSR but its subject fields are replaced by the account information (similar to iOS Team ID). The certificate chain consists of root → intermediate → leaf. The leaf is valid for three years; renewal with the same CSR preserves the public‑key fingerprint.

Profile Generation

The profile (similar to iOS provisioning profile) describes the package name, signing certificate, permission list, distribution type, and validity period. It is stored in CMS (PKCS#7) format as defined in RFC 5652 and RFC 2315. The profile file ( my.p7b) can be inspected with:

openssl pkcs7 -in my.p7b -print -inform DER
openssl smime -verify -in my.p7b -inform DER -noverify   // configuration
openssl pkcs7 -in my.p7b -print_certs -inform DER       // certificates

A sample JSON representation of the profile includes fields such as version-name, app-distribution-type, validity, bundle-info, permissions, etc. The app-distribution-type can be app_gallery, enterprise, enterprise_mdm, enterprise_normal, os_integration, crowdtesting, or none.

Signing the App Package

The profile and leaf certificate are referenced in the project’s signingConfigs. Using DevEco‑Studio or the command‑line hap‑sign‑tool.jar produces a signed .app file. The signed package can be opened as a ZIP archive; it contains the .hap bundle and a pack.info file.

java -jar hap-sign-tool.jar verify-app -inFile my-signed.app -outCertChain my-signed.cer -outProfile my-signed.p7b

Signature Verification and Integrity Checks

Verification is performed by the security_appverify module. The VerifyHap function parses a custom HapSigningBlock placed before the ZIP Central Directory. The block contains two sub‑blocks: SignatureSchemeBlock – CMS‑encoded signature and certificate chain. SigningBlock – the profile (type 0x20000002).

The SignatureSchemeBlock is validated by reconstructing the hash of the leaf certificate using the algorithm indicated in the certificate (e.g., ECDSA‑with‑SHA‑384) and verifying the signature with the intermediate certificate’s public key, then up to the root certificate stored in /system/etc/security/trusted_root_ca.json:

{
  "C=CN, O=Huawei, OU=Huawei CBG, CN=Huawei CBG Root CA G2":"-----BEGIN CERTIFICATE-----
MIICGjCCAaGgAwIBAgIIShhpn519jNAwCgYIKoZIzj0EAwMwUzELMAkGA1UEBhMC...
-----END CERTIFICATE-----
"
}

After establishing trust, the leaf certificate’s subject determines the installation source. The source list is defined in /system/etc/security/trusted_apps_sources.json and includes entries for “huawei app gallery”, “huawei system apps”, and “third_party app preload”.

Profile validation differs by signing mode. For market‑distributed HAPs the profile is stored as plain JSON, so no additional signature verification is required. For other modes the profile is CMS‑signed; the leaf certificate’s public key verifies the signature, and the profile’s signing‑certificate subject must match the leaf’s subject.

Depending on the type field, the verifier checks:

Release mode – whether the distribution type is allowed (enterprise, MDM, crowd‑testing, etc.).

Debug mode – whether the device UDID appears in the device-ids list.

Successful validation yields two derived values: APP ID (public key), computed from the developer signing certificate’s public key, and Fingerprint, the hash of the entire developer certificate.

System APIs and Further Details

The SignatureInfo API returns three parameters: appId, fingerprint, and signingCertificate. The bundle manager builds the final appId by concatenating the bundle name, an underscore, and the APP ID (public key) value:

// bundle_install_checker.cpp
newInfo.SetProvisionId(provisionInfo.appId);
// inner_bundle_info.h
void SetProvisionId(const std::string &provisionId) {
    baseBundleInfo_->appId = baseBundleInfo_->name + "_" + provisionId;
}

Thus the API appId is effectively {bundleName}_{publicKeyId}.

Key Visuals

Conclusion

The HarmonyOS NEXT signing architecture combines Android‑style CMS signatures with iOS‑style double‑layer signing, enforcing strict certificate chains, profile validation, and package integrity checks. This pragmatic design improves security for native HarmonyOS applications while preserving a familiar developer workflow.