项目概览

项目背景

QXJ 项目全称为风云四号 02 批气象卫星工程 C 星地面系统 MCS 信息安全传输控制软件 （项目编号 IIE-MCS-ISTCS），由北京华云星地通科技有限公司委托中国科学院信息工程研究所 第二研究室研制，最终用户为国家卫星气象中心。

FY-4C MCS 是风云四号 C 星星地系统的指挥控制中心，承担星地一体化指挥控制、任务管理、调度控制、运行状态监视与数据传输管理等职责。在气象观测数据及控制指令的外部交互过程中，数据的完整性、机密性和可用性需要专门的安全保障，本项目重点覆盖三类业务场景：

移动设备观测需求信息传输：移动终端（Pad）通过互联网向 MCS 请求气象数据时，严格验证终端身份与访问权限，仅限授权设备获取数据，并全程加密防止数据被窃取或篡改
主站与灾备站间信息传输：北京主站与乌兰察布灾备站之间传输任务时间表、调度令、公共配置参数等关键数据时，建立全程加密、完整无损的安全可信通道
数据外部流转溯源：气象数据对外共享前嵌入可验证的身份标识与来源信息，支持全流程溯源，为版权保护和责任界定提供依据

📖 相关阅读：技术栈总览 · 获取项目工作区 · 验收技术总结 · 项目概况

项目组成

MCS 信息安全传输控制软件由 5 个子系统、2 个安全接口库和多端 SDK 组成：

1. 鸿蒙安全浏览器（Pad Browser）

基于 HarmonyOS NEXT 开发的企业级安全浏览器，部署在观测需求专用 Pad 上，是用户访问 MCS 业务系统的入口。

核心功能：

SM2 密钥协商与会话管理
SM4-GCM 加密登录与业务数据加解密
浏览器形态：main 稳定线为单页模式（4.1.x），dev 功能线为多标签 v2（5.2.x）
服务器配置管理（支持扫码导入）、网站访问白名单
国际化支持（6 种语言）、深色模式与 10 套工具栏主题

技术栈：

ArkTS / ArkUI（"一多"自适应架构，多 HAR + 多 HAP）
@nsp/qxj-sdk（内置 HAR，AKI + C 国密库）
targetSdkVersion 6.1.1(24)，compatibleSdkVersion 5.0.5(17)

📖 相关阅读：鸿蒙应用架构 · 浏览器功能 · 仓库详解 · harmony-browser

2. 国密认证平台（Backend Admin）

基于 Django 的后端认证与管理系统，部署在国家卫星气象中心 DMZ 区，负责用户认证、密钥管理、设备管理和访问控制。

核心功能：

SM2 密钥协商服务端处理
NSP-SM Token 签发（access + refresh）
用户 / 角色 / 权限管理（CoAC 模型 + RBAC）
时间规则与地理围栏等访问控制策略
短信 / 邮箱验证码服务
安全审计日志记录

技术栈：

Django 4.2 + Django REST Framework
自定义 NSP-SM 令牌（alg: NSP-SM，签名算法 SM2withSM3），仅复用 SimpleJWT 的异常类
MySQL（业务数据）、Redis（会话密钥 / 验证码 / Token 黑名单，django-redis）
默认服务端口 4607，API 前缀 /api/v3/

📖 相关阅读：后端架构 · 访问控制策略 · 仓库详解 · backend-admin

3. 安全接口库

图像数据版权保护接口库

BCH 纠错编码 + DCT 中频域高鲁棒不可见水印的嵌入与提取
兼容 JPG / PNG，水印图像 PSNR 达 38.10 dB、SSIM 0.9815
部署在图片存储服务器，为图像数据共享提供版权标识

L0 数据溯源及篡改检测接口库

L0 数据唯一标识的封装 / 解封装
数据来源真实性验证与篡改检测
部署在气象数据业务系统服务器

📖 相关阅读：技术总结 · 图像水印关键技术（PSNR/SSIM 实验） · 接口设计详录

4. 多端 SDK

ArkTS SDK（@nsp/qxj-sdk）

鸿蒙原生加密能力封装（C++ MIRACL + NAPI/AKI，ETS 接口）
SM2/SM3/SM4 算法实现与四步握手协议封装

JavaScript SDK（qxj-frontend-sdk）

网页端国密加密封装与 JWT 解析
JSBridge 通信封装，与鸿蒙浏览器安全区桥接

Python SDK（qxj-backend-sdk）

Token 本地校验（SM2 验签 + HMAC）
SM4-GCM 加解密与会话密钥管理，业务后端可脱离鉴权中心独立验签

📖 相关阅读：API 参考总览 · 后端 SDK · 前端 SDK

5. Mock 演示与配套站点

Mock 演示：包含前端 Mock Demo 和后端 Mock Demo，各提供 Before（传统账密、无加密）与 After（完整国密接入）两种模式，用于教学和联调
NSP 应用商店（apps.nsp.ac.cn）： HarmonyNext 应用按设备分发站点
NSP-SM JWT Inspector（jwt-inspector.qxj.nsp.ac.cn）：自定义令牌在线解析工具
打包工具链：hpack（HAP 重签名 + 多渠道分发通知）、Wireshark 二进制协议解析器等辅助工具

📖 相关阅读：Mock Demo 仓库详解 · 辅助工具汇总 · NSP 应用商店

核心特性

🔐 四步 SM2 密钥协商

QXJ 采用自定义二进制协议帧，通过主子命令码 0x01~0x04 的四步握手，实现前向安全的密钥协商：

协议特点：

使用二进制协议帧（application/octet-stream），握手四包由子命令码区分
会话密钥不经过网络传输，由双方独立推导
双方均使用临时密钥对，具备前向安全，并以 SigA/SigB 防止中间人攻击
协商出的 K_session 用于后续业务通信的 SM4-GCM 加解密

📖 相关阅读：SM2 密钥协商详解 · SM4-GCM 加密通信 · 技术总结 · 处理流程与协议

🛡️ NSP-SM Token（双层校验令牌）

QXJ 自定义的联合令牌格式，标准 JWT 三段式结构叠加内层 HMAC：

NSP-SM Token = Header.Payload.Signature

Header    = {"alg": "NSP-SM", "typ": "JWT"}   // NSP-SM 为自定义标识，实际签名算法 SM2withSM3
Payload   = {
  "sub": "用户 ID",
  "exp": 过期时间, "iat": 签发时间,
  "custom": {
    "device_id": "设备唯一标识",
    "hmac": "SM3-HMAC 值"
  }
}
Signature = SM2 签名（r‖s，64 字节）

验证流程：

外层（SM2 签名）：用服务器公钥做 SM2withSM3 验签，确认令牌由合法系统签发
内层（SM3-HMAC）：按 custom.device_id 从 Redis 取出会话密钥，重算 HMAC 与 custom.hmac 比对，确认令牌与当前会话绑定
验签由业务后端调用 Python SDK 本地完成，完全脱离鉴权中心；也可通过 skip_hmac=True 仅做外层验签

📖 相关阅读：后端 SDK · verify_access_token · API 参考 · Token 校验返回码 · NSP-SM JWT Inspector（在线解析）

📱 "一多"设备适配

工程按"一次开发、多端部署"设计，当前包含三个产品形态：

设备类型	状态	说明
Tablet	✅ 完整实现	主交付形态，侧边栏 + Chrome 式标签条
Phone	✅ 完整实现	顶部标签栏 + 卡片式管理，同一份 ArkUI 代码自适应
PC	🚧 骨架模块	窗口化布局，含 PcAbility 占位

🌍 国际化支持

支持 6 种语言环境：

语言	代码	状态
简体中文	zh_CN	✅
繁体中文（台湾）	zh_TW	✅
繁体中文（香港）	zh_HK	✅
繁体中文（澳门）	zh_MO	✅
英语	en_US	✅
日语	ja_JP	✅

📖 相关阅读：国际化实现 · 主题定制与深色模式 · 服务器集中管理

技术难点

1. 二进制协议帧设计

QXJ 采用自定义的二进制协议帧格式，而非传统的 JSON：

帧结构（64 字节帧头，大端）：
┌────────┬──────┬──────┬──────────┬──────┬──────────┬──────────┬──────┬─────────┐
│ version│ main │ sub  │ total_len│ seq  │  sender  │ enc_auth │  IV  │ reserved│
│  1B    │  1B  │  2B  │   2B     │ 2B   │   36B    │   1B     │ 16B  │   3B    │
└────────┴──────┴──────┴──────────┴──────┴──────────┴──────────┴──────┴─────────┘
  偏移0    1      2      4          6      8          44         45     61

主命令码 main：
- 0x00: 密钥协商帧
- 0x01: 报警帧
- 0x02: 加密完保帧

握手四包由 sub / total_len 区分：
- INIT（280B）/ RESP（162B）/ ACK（98B）/ TOKEN（146B）

设计原因：

减少网络传输开销，提高解析效率
便于 C 库 / 硬件实现，字段定长、对齐固定
避免 JSON 解析中的注入与数据类型歧义

2. ArkUI 状态管理约束（V1 / V2）

项目同时存在两套状态管理：传统页面大量使用 V1（@Component + @State），新功能逐步采用 V2（@ComponentV2 + @ObservedV2/@Trace）。两者装饰器不能混用：

typescript

// V1：@Component 内不使用计算属性，派生值用普通方法
@Component
struct MyComponentV1 {
  @State count: number = 0

  getDoubleCount(): number {
    return this.count * 2
  }
}

// V2：@ComponentV2 才支持 @Computed
@ComponentV2
struct MyComponentV2 {
  @Local count: number = 0

  @Computed
  get doubleCount(): number {
    return this.count * 2
  }
}

其他约束：

禁止使用 any 类型
ForEach 必须包含 key
@Builder 必须直读状态而非按值传参
内置属性名（enabled、visible 等）不能用作 @StorageLink/@State 属性名

3. hvigor 多 Target 构建

鸿蒙项目使用 hvigor 构建系统，需要处理多产品、多 target 的复杂场景：

json5

// build-profile.json5
{
  "app": {
    "products": [
      {
        "name": "default",
        "signingConfig": "default",
        "compileSdkVersion": "6.1.1(24)",
        "compatibleSdkVersion": "5.0.5(17)"
      },
      {
        "name": "release",
        "signingConfig": "release",
        "compileSdkVersion": "6.1.1(24)",
        "compatibleSdkVersion": "5.0.5(17)"
      }
    ]
  },
  "modules": [
    {
      "name": "tablet",
      "srcPath": "./products/tablet",
      "targets": [
        { "name": "default", "applyToProducts": ["default"] },
        { "name": "release", "applyToProducts": ["release"] }
      ]
    }
  ]
}

构建挑战：

Debug/Release 使用不同的资源（如 map3d 模块与定位 native 库）
模块间的 target 与产品匹配规则复杂
需要确保 release 构建排除调试信息与敏感资源

4. 跨端密钥状态同步

QXJ 需要在客户端、鉴权服务器、业务后端和 SDK 之间保持密钥状态一致：

同步挑战：

密钥协商任一步失败时，双方残留状态的清理策略
多服务器配置切换时的密钥隔离与重新协商
多设备、多会话间的密钥隔离（按 device_id 独立存储）

📖 相关阅读：部署架构与端口规划 · 部署文档（完整版） · 开发指南

项目数据

指标	数值
工作区仓库数	10+ 个（由 Google repo 按 manifest 统一管理）
鸿蒙工程模块	6 HAR（含 @nsp/qxj-sdk）+ 3 entry HAP（tablet / phone / pc）
后端业务 app 数	14 个（apps/）
浏览器版本	main 4.1.54（单页）/ dev 5.2.89（多标签 v2）
支持语言	6 种
密码算法	SM2（签名 / 密钥协商）、SM3（杂凑 / KDF / HMAC）、SM4-GCM（传输）、SM4-ECB（密钥存储）
水印性能	PSNR 38.10 dB / SSIM 0.9815

下一步

🚀 快速开始 - 获取工作区并运行项目
🏗️ 架构设计 - 深入了解系统架构
🔐 SM2 密钥协商 - 国密握手协议详解
📋 交付文档 - 用户手册、部署文档与技术总结

项目概览 ​

项目背景 ​

项目组成 ​

1. 鸿蒙安全浏览器（Pad Browser） ​

2. 国密认证平台（Backend Admin） ​

3. 安全接口库 ​

4. 多端 SDK ​

5. Mock 演示与配套站点 ​

核心特性 ​

🔐 四步 SM2 密钥协商 ​

🛡️ NSP-SM Token（双层校验令牌） ​

📱 "一多"设备适配 ​

🌍 国际化支持 ​

技术难点 ​

1. 二进制协议帧设计 ​

2. ArkUI 状态管理约束（V1 / V2） ​

3. hvigor 多 Target 构建 ​

4. 跨端密钥状态同步 ​

项目数据 ​

下一步 ​