QXJ Project DocumentationHarmonyOS NEXT Secure Browser — National Cryptography Authentication Solution

Project Introduction ​

The QXJ project is the companion technical documentation and engineering collection for the FY-4 02-Batch Meteorological Satellite Program C-Satellite Ground System — MCS Information Secure Transmission Control Software (project code: IIE-MCS-ISTCS), developed by the Second Research Division of the Institute of Information Engineering, Chinese Academy of Sciences, serving the secure meteorological data transmission business of the National Satellite Meteorological Center. The system is designed around three core security scenarios:

1. Mobile observation demand information transmission: Observers use the HarmonyOS NEXT tablet secure browser to access the meteorological center MCS system over the Internet, achieving mutual authentication between device and server plus full-path encryption of business data over untrusted networks.
2. Secure transmission between primary and disaster-recovery sites: Critical data such as mission schedules, dispatch orders, and public configuration parameters between the Beijing primary site and the Ulanqab disaster-recovery site are protected for confidentiality, integrity, and authenticity by the transmission encryption subsystem.
3. External data flow traceability: Tamper detection is provided for outbound L0-level meteorological data, and highly robust digital watermarking protects the copyright of image data, supporting accountability and forensic traceability after data leaves the system.

The core components of the system include:

• HarmonyOS NEXT Secure Browser: A native enterprise-grade secure browser built with ArkTS / ArkUI, with a built-in national-cryptography SDK, supporting SM2 device-level key agreement, SM4-GCM encrypted communication, multi-tab browsing, centralized server management, and website access control
• MCS National-Crypto Authentication Platform: A backend service based on Django + DRF, providing device registration and key management, four-step SM2 authenticated key agreement, SMS code + password multi-factor login, NSP-SM signed token issuance, user/role/device management, and fine-grained access control policies based on time rules and geographic scopes
• Security Interface Libraries: An image data copyright protection library (BCH + DCT highly robust watermarking) and an L0 data traceability & tamper-detection library, for integration by meteorological data business systems and image storage services
• Multi-Platform SDKs: ArkTS, Python, and JavaScript SDKs that package token verification, national-crypto encryption/decryption, and JSBridge secure login into ready-to-use components, enabling low-cost integration for business systems

Built on Chinese commercial cryptographic algorithms (SM2/SM3/SM4) and hardware support such as key asset storage, the system establishes an end-to-end security protection system spanning terminal devices, network transmission, and business services.

Core Features ​

For item-by-item completion of functional and performance indicators (SM2 sign/verify, SM3, SM4 throughput, cryptographic card progress, etc.), see Indicator Completion Status.

Quick Start ​

The entire QXJ workspace is managed by Google repo (10+ repositories). On first use, initialize and then sync.

repo is a multi-repository management tool developed by Google on top of Git: it uses a manifest (XML file) to declare the address, branch, and local path of multiple Git repositories. With just repo init + repo sync, dozens of repositories are pulled in one go with a unified layout; afterwards, repo forall can run Git commands in batch across all repositories. If you're new to it, read the official repo documentation first.

If repo is not installed on your machine:

# Debian / Ubuntu (same for WSL)
sudo apt update && sudo apt install -y repo

# Or manual installation via the official script
mkdir -p ~/.local/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.local/bin/repo
chmod a+rx ~/.local/bin/repo
# Make sure ~/.local/bin is in PATH

# First-time initialization (pull the manifest, using the intranet-hosted repo tool)
repo init \
  --repo-url=http://192.168.168.51:3000/qxj-project/git-repo.git \
  --repo-rev=v2.67 \
  -u http://192.168.168.51:3000/qxj-project/manifest.git

# Alternative: use the Nanjing University mirror of the repo tool
repo init \
  --repo-url=https://mirror.nju.edu.cn/git/git-repo \
  -u http://192.168.168.51:3000/qxj-project/manifest.git

# Update the local repo tool to the intranet version
sudo cp /home/nsp/Desktop/qxj-project/.repo/repo/repo /usr/bin/repo
repo --version

# Sync the all group (equivalent to every repository)
repo sync -c -j8
repo sync -c -g all -j8

# Pull only delivery projects
repo sync -c -g delivery -j8

# Sync multiple groups
repo sync -c -g all,frontend -j8

# Exclude a group
repo sync -c -g all,-backend -j8

# Sync a single project
repo sync -c qxj-backend-admin -j8

# Sync multiple specified projects
repo sync -c qxj-backend-admin qxj-frontend-admin qxj-backend-sdk -j8

# Show project status
repo status

# Show branches of all projects
repo branches

# Run a git command in every project
repo forall -c "git status"

# Pull the latest code in every project
repo forall -c "git pull"

# Full update workflow
repo sync -c -j8 && repo forall -c "git pull"

# Re-sync after switching remotes
repo sync -c --force-sync -j8

# Show help
repo help sync

# Mirror the repo tool itself to the intranet Gitea (admin only, one-time)
git remote add gitea http://192.168.168.51:3000/qxj-project/git-repo.git
git remote -v
# gitea   http://192.168.168.51:3000/qxj-project/git-repo.git (fetch/push)
# origin  https://gerrit.googlesource.com/git-repo (fetch/push)
git push --mirror gitea

# Show the current manifest
cat .repo/manifests/default.xml

# Re-sync after modifying the manifest
cd .repo/manifests && git pull && cd ../..
repo sync -c -j8

Common repo sync parameters:

The manifest is maintained centrally in the standalone manifest repository and will later be split into multiple files by role, so members with different roles pull different groups. The authoritative content is the file in the repository; this page intentionally does not enumerate the project list (to avoid drifting out of sync):

# Show the effective manifest
cat .repo/manifests/default.xml

Repository: manifest

The basic structure of a manifest (illustrative only; the actual project list evolves over time):

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- Root URL of the remote -->
  <remote name="origin" fetch="http://192.168.168.51:3000/" />
  <!-- Default remote and default branch -->
  <default remote="origin" revision="main" />
  <!-- Each project maps to one repository: name = repo path, path = local directory, groups = pull-by-group -->
  <project name="qxj-project/<repo-name>.git" path="<local-dir>" groups="all,delivery" />
</manifest>

For a more complete development environment setup guide, see Getting Started.

Project Architecture ​

The system adopts a layered architecture — client layer, server layer, and SDK layer — with clear responsibilities and standardized interfaces:

• Client layer: The HarmonyOS secure browser runs on observers' HarmonyOS tablets and is the main entry point for mobile observation, with a built-in crypto SDK; the Web admin console lets administrators centrally manage users, roles, devices, and access control policies; the Mock demo frontend is used for solution teaching and joint debugging.
• Server layer: The Django authentication backend handles device registration, SM2 key agreement, token issuance, and access control policy enforcement; the business backend carries observation-demand business logic and verifies request legitimacy locally via the backend SDK; Redis provides caching for sessions, SMS codes, and token blacklists.
• SDK layer: The ArkTS SDK provides national-crypto algorithms and handshake capability for HarmonyOS; the frontend SDK bridges WebView and the native secure area via JSBridge; the backend SDK offers token verification and encryption/decryption interfaces for Python business services.

For a more detailed architecture description, see Overall Architecture.

Technical Highlights ​

🔐 Four-Step Key Agreement ​

The system uses a custom binary protocol frame (64B v2 frame structure, major command code + sub-command codes 0x01~0x04) to complete SM2-based four-step authenticated key agreement between mobile devices and the MCS server: client and server each generate an ephemeral SM2 key pair, exchange public keys and random numbers via INIT / RESP / ACK frames, independently derive the same session key, and finally receive the NSP-SM signed token via the TOKEN frame. Each negotiation uses a fresh ephemeral key pair, so even if long-term keys leak, past sessions remain secure — providing forward secrecy. The negotiated session key is then used for SM4-GCM business encryption.

See SM2 Key Agreement for details; for frame formats and processing flow, see Technical Summary · Processing Flow & Protocols.

🛡️ Multi-Dimensional Access Control ​

The permission system is built on the CoAC (Condition-based Access Control) model. Beyond RBAC role authorization, three conditional checks — time rules, region scope (geofencing), and device binding — are executed in sequence when a user connects: access to MCS business is granted only when the access occurs within an allowed time window, inside a specified geographic region, and from a registered, activated device; any failure rejects the request and records an audit log. Policies are centrally defined and updated by administrators in the access control policy module.

See Access Control for details; for policy data structures, see Technical Summary · Module Design.

📊 Authentication, Authorization & Auditing ​

The business backend applies a unified security pipeline to every request: the request first passes through the authentication middleware, where the backend SDK's verify_access_token locally completes SM2 signature verification and validity checks of the NSP-SM token (no callback to the auth center required); then a permission check runs — on success the request proceeds to business handling, otherwise 401 / 403 is returned. Regardless of outcome, key operations such as login, authentication, and encryption/decryption are written to the security audit log, forming a complete operation trail.

See Backend Architecture for details; for error codes and handling, see Technical Summary · Error Handling.

Documentation Navigation Map ​

🚀 Quick Start ​

🏗️ Architecture ​

🔐 Core Features ​

📡 API Reference ​

📦 Repository Overview ​

📋 Delivery Documentation ​

💻 Development & Others ​