QXJ 项目文档鸿蒙NEXT安全浏览器国密鉴权认证解决方案

项目简介 ​

QXJ 项目是 风云四号02批气象卫星工程C星地面系统 MCS信息安全传输控制软件（项目编号：IIE-MCS-ISTCS）的配套技术文档与工程集合，由中国科学院信息工程研究所第二研究室研制，服务于国家卫星气象中心的气象数据安全传输业务。系统围绕三类核心安全场景设计：

1. 移动设备观测需求信息传输：观测人员使用鸿蒙 NEXT 平板安全浏览器经互联网访问气象中心 MCS 系统，在不可信网络环境下实现设备与服务器之间的双向身份认证和业务数据的全程加密。
2. 主站与灾备站间安全传输：北京主站与乌兰察布灾备站之间的任务时间表、调度令、公共配置参数等关键数据，通过传输加密子系统实现机密性、完整性和真实性保护。
3. 数据外部流转溯源：面向外发的 L0 级气象数据提供篡改检测能力，面向图像数据提供高鲁棒数字水印版权保护，支撑数据流出后的责任认定与溯源取证。

系统的核心组成包括：

• 鸿蒙 NEXT 安全浏览器：基于 ArkTS / ArkUI 开发的原生企业级安全浏览器，内置国密加密 SDK，支持 SM2 设备级密钥协商、SM4-GCM 加密通信、多标签浏览、服务器集中管理与网站访问控制
• MCS 国密认证平台：基于 Django + DRF 的后端服务，提供设备注册与密钥管理、四步 SM2 身份认证密钥协商、短信验证码 + 口令多因子登录、NSP-SM 签名令牌签发、用户/角色/设备管理、基于时间规则与区域范围的细粒度访问控制策略
• 安全接口库：图像数据版权保护接口库（BCH + DCT 高鲁棒水印）与 L0 数据溯源及篡改检测接口库，供气象数据业务系统和图片存储服务集成调用
• 多端 SDK：提供 ArkTS、Python、JavaScript 多语言 SDK，将令牌验签、国密加解密、JSBridge 安全登录等能力封装为开箱即用的组件，方便业务系统低成本接入

整个系统以国产商用密码算法（SM2/SM3/SM4）为基础，结合关键资产存储等硬件支撑，构建了从终端设备、网络传输到业务服务的端到端安全防护体系。

核心特性 ​

功能指标与性能指标（SM2 签验签 / SM3 / SM4 吞吐、密码卡进度等）的逐项完成情况，见 指标完成情况。

快速开始 ​

整个 QXJ 工作区由 Google repo 统一管理（共 10+ 个仓库），首次使用需先初始化再同步。

repo 是 Google 基于 Git 开发的多仓库管理工具：它用一份 manifest（XML 文件）声明多个 Git 仓库的地址、分支与本地路径，只需 repo init + repo sync 两条命令，就能一次性把几十个仓库按统一结构批量拉取下来，后续还能通过 repo forall 在所有仓库中批量执行 Git 命令。不熟悉的同学可以先阅读 repo 官方使用文档（或 中文介绍 中关于 repo 的部分）。

如果本机还没有安装 repo：

# Debian / Ubuntu（WSL 同理）
sudo apt update && sudo apt install -y repo

# 或官方脚本手动安装
mkdir -p ~/.local/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.local/bin/repo
chmod a+rx ~/.local/bin/repo
# 确认 ~/.local/bin 在 PATH 中

# 首次初始化（拉取 manifest，使用内网托管的 repo 工具）
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

# 备选：使用南京大学镜像的 repo 工具
repo init \
  --repo-url=https://mirror.nju.edu.cn/git/git-repo \
  -u http://192.168.168.51:3000/qxj-project/manifest.git

# 更新本地 repo 工具到内网版本
sudo cp /home/nsp/Desktop/qxj-project/.repo/repo/repo /usr/bin/repo
repo --version

# 同步 all 组（等同于全部仓库）
repo sync -c -j8
repo sync -c -g all -j8

# 只拉取交付项目
repo sync -c -g delivery -j8

# 同步多个组
repo sync -c -g all,frontend -j8

# 排除某个组
repo sync -c -g all,-backend -j8

# 只同步某个项目
repo sync -c qxj-backend-admin -j8

# 同步多个指定项目
repo sync -c qxj-backend-admin qxj-frontend-admin qxj-backend-sdk -j8

# 查看项目状态
repo status

# 查看所有项目分支
repo branches

# 在所有项目中执行 git 命令
repo forall -c "git status"

# 在所有项目中拉取最新代码
repo forall -c "git pull"

# 完整更新流程
repo sync -c -j8 && repo forall -c "git pull"

# 换源后重新同步
repo sync -c --force-sync -j8

# 查看帮助
repo help sync

# 将 repo 工具本身镜像到内网 Gitea（仅管理员操作一次）
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

# 查看当前 manifest 内容
cat .repo/manifests/default.xml

# 修改 manifest 后重新同步
cd .repo/manifests && git pull && cd ../..
repo sync -c -j8

常用 repo sync 参数：

Manifest 由独立的 manifest 仓库统一维护，后续将按角色拆分为多个文件，不同角色成员拉取不同的组。当前完整内容以仓库中的文件为准，本文档不再罗列具体项目清单（避免与实际不同步）：

# 查看当前生效的 manifest
cat .repo/manifests/default.xml

仓库地址：manifest

Manifest 的基本结构如下（仅示意，实际项目清单会持续调整）：

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- 远程仓库根地址 -->
  <remote name="origin" fetch="http://192.168.168.51:3000/" />
  <!-- 默认远程与默认分支 -->
  <default remote="origin" revision="main" />
  <!-- 每个 project 对应一个仓库：name 为仓库路径，path 为本地目录，groups 控制可按组拉取 -->
  <project name="qxj-project/<仓库名>.git" path="<本地目录>" groups="all,delivery" />
</manifest>

更完整的开发环境搭建说明见 快速开始指南。

项目架构 ​

系统采用分层架构，自上而下分为客户端层、服务端层、SDK 层，各层职责清晰、通过标准化接口交互：

• 客户端层：鸿蒙安全浏览器运行于观测人员的鸿蒙平板，是移动观测业务的主入口，内置加密 SDK；Web 管理端供管理员进行用户、角色、设备与访问控制策略的集中管理；Mock 演示前端用于方案教学与联调验证。
• 服务端层：Django 认证后端负责设备注册、SM2 密钥协商、令牌签发与访问控制策略执行；业务后端承载观测需求等业务逻辑，通过后端 SDK 本地验签即可校验请求合法性；Redis 提供会话、短信验证码、令牌黑名单等缓存服务。
• SDK 层：ArkTS SDK 为鸿蒙端提供国密算法与握手能力，前端 SDK 通过 JSBridge 桥接 WebView 与原生安全区，后端 SDK 为 Python 业务服务提供令牌验签与加解密接口。

更详细的架构说明见 整体架构。

技术亮点 ​

🔐 四步密钥协商 ​

系统采用自定义二进制协议帧（64B v2 帧结构，主命令码 + 子命令码 0x01~0x04），在移动设备与 MCS 服务器之间完成基于 SM2 的四步身份认证密钥协商：客户端与服务器各自生成 SM2 临时密钥对，通过 INIT / RESP / ACK 帧交换公钥与随机数，双方独立推导出相同的会话密钥，最后由 TOKEN 帧返回 NSP-SM 签名令牌。每次协商均使用新的临时密钥对，即使长期密钥泄露，历史会话依然安全，具备前向安全性；协商得出的会话密钥随后用于 SM4-GCM 业务加解密。

详见 SM2 密钥协商，协议帧格式与处理流程见 技术总结 · 处理流程与协议。

🛡️ 多维访问控制 ​

系统基于 CoAC（基于条件的访问控制）模型构建权限体系，除 RBAC 角色授权外，还支持在用户接入时依次执行时间规则、区域范围（地理围栏）、设备绑定三类条件检查：仅在允许的时间段、指定的地理区域内、使用已注册激活的设备，三者全部通过才允许访问 MCS 业务，任一不满足即拒绝并记录审计日志。策略由管理员在访问控制策略模块统一制定与更新。

详见 访问控制，策略数据结构见 技术总结 · 模块设计。

📊 认证鉴权与审计 ​

业务后台对每一个请求执行统一的安全管道：请求首先经过认证中间件，使用后端 SDK 的 verify_access_token 在本地完成 NSP-SM 令牌的 SM2 验签与有效期校验（无需回调鉴权中心）；随后进行权限检查，通过后进入业务处理，失败则返回 401 / 403。无论成功与否，登录、认证、加解密等关键操作都会写入安全审计日志，形成完整的操作留痕。

详见 后端架构，错误码与处理对策见 技术总结 · 出错处理。

文档导航地图 ​

� 快速上手 ​

🏗️ 架构设计 ​

🔐 核心功能 ​

📡 API 参考 ​

📦 仓库总览 ​

📋 交付文档 ​

💻 开发与其他 ​