Analysis of HarmonyOS NEXT Application Signature and Verification Mechanism

This article provides an in‑depth analysis of the signature mechanism used by HarmonyOS NEXT (single‑framework) applications, covering the complete workflow from developer certificate generation to app package signing and runtime verification.

1. Developer Certificate Generation – Using DevEco‑Studio a PKCS#12 file (p12) containing the developer’s public/private key pair is created. The certificate follows RFC 7292 (PKCS#12) and can be inspected with OpenSSL:

openssl asn1parse -in my.p12 -inform DER

openssl pkcs12 -info -in my.p12 -noout

The public key is exported in PEM format and its SHA‑256 fingerprint (Base64‑encoded) is calculated as the unique identifier for the key.

2. Certificate Signing Request (CSR) and Leaf Certificate – A CSR (PKCS#10) is generated and submitted to Huawei’s signing service, which issues a leaf certificate. The leaf certificate’s Subject is populated from the developer’s account rather than the CSR, and the certificate chain consists of root → intermediate → leaf.

openssl req -new -key dev_key.pem -out my.csr

openssl x509 -req -in my.csr -CA intermediate.pem -CAkey intermediate_key.pem -out leaf.pem -days 365

3. Profile File – The Profile (CMS/PKCS#7) describes the app’s bundle name, distribution type, validity period, permissions, and developer ID. It is signed with the leaf certificate and stored in the app’s SigningBlock (type 0x20000002).

Example JSON excerpt from a Profile:

{
  "version-name": "2.0.0",
  "bundle-name": "com.example.test",
  "app-distribution-type": "app_gallery",
  "validity": {"not-before": 1727096284, "not-after": 1821704284},
  "type": "release",
  "developer-id": "300**********7916"
}

4. App Package Signing – The final .app (or .hap) file is a ZIP archive. A custom HapSigningBlock is inserted before the ZIP Central Directory. It contains two sub‑blocks: the SignatureSchemeBlock (CMS signature of the package) and the Profile block. The block header includes a magic string "

" and a fixed size of 32 bytes.

5. Runtime Verification – When the system loads an app, it performs three verification steps:

Validate the SignatureSchemeBlock’s certificate chain (leaf → intermediate → built‑in root stored in /system/etc/security/trusted_root_ca.json).

Parse and verify the Profile using the leaf certificate’s public key; ensure the Profile’s signing certificate matches the trusted source defined in /system/etc/security/trusted_apps_sources.json (e.g., "huawei app gallery").

Check package integrity by recomputing the hash of the ZIP data plus the non‑signature part of the HapSigningBlock and comparing it with the CMS signature.

For release builds, the system also checks that the app’s distribution type is allowed (enterprise, MDM, crowd‑testing, etc.) and that the app ID derived from the Profile matches the bundle name.

6. Key Takeaways – HarmonyOS NEXT combines Android‑style APK signing (CMS) with iOS‑style double‑layer signing (app‑level signature plus a signed provisioning profile). The design enforces strict certificate chain validation, uses immutable root certificates baked into the OS, and ties the app’s identity to a fingerprint derived from the developer’s public key, providing a robust security foundation for the ecosystem.