国产WLAN标准WAPI调研

了解国产无线“WIFI”么？

WAPI 技术概述

基本定义

WAPI (WLAN Authentication and Privacy Infrastructure) 是中国国家标准 GB 15629.11-2003，2003 年 5 月由国家质检总局强制执行。与 IEEE 802.11i (WPA/WPA2) 平行，WAPI 定义了独立的安全体系：

组件	WAPI	WPA/WPA2
鉴别协议	WAI (WLAN Authentication Infrastructure)	802.1X/EAPOL
加密算法	SMS4 (GB/T 32507-2016)	AES-CCMP/GCMP
以太网类型	`0x88B4` (WAI)	`0x888E` (EAPOL)
密钥协商	WKD 三步握手 (Type 4-5-6)	4-way handshake
密钥长度	256 bit (128B 加密 + 128B MIC)	128/256 bit
PN 长度	16 字节	6 字节 (CCMP)
控制帧加密	不加密 (WAPI 规定)	加密 (802.11w)

官网： http://www.wapia.org.cn/hyzx/cydt/detail_343121.shtml
更多可参看之前的介绍： https://notes.z-dd.online/2025/03/19/%E6%97%A0%E7%BA%BF%E5%B1%80%E5%9F%9F%E7%BD%91%E6%A0%87%E5%87%86%E4%B9%8BWAPI/
微信

认证模式

WAPI-CERT: 基于证书（AS 证书 + 用户证书），用于企业级部署，需 ASU (Authentication Server Unit) 基础设施
WAPI-PSK: 基于预共享密钥，用于个人/家庭场景

WAI 帧格式

WAI 分组格式（GB 15629.11-2016）：

+----------+----------+-----------+------------------+
| 协议版本 | 分组类型 | 分组序号  | 分组数据体       |
| 2 bytes  | 2 bytes  | 2 bytes   | variable         |
+----------+----------+-----------+------------------+

分组类型：Type 1-3 鉴别（请求/响应/确认），Type 4-6 密钥协商（请求/响应/确认），Type 7-8 密钥更新，Type 9 断连通知，Type 10 时间戳。

WPI-SMS4 帧格式

+----------+----------+------------------+-----------+
| 协议版本 | PN (16B) | 加密数据 (CBC)   | MIC (16B) |
| 2 bytes  | 16 bytes | variable         | 16 bytes  |
+----------+----------+------------------+-----------+

密钥结构：32 字节 = 16B 数据加密密钥 + 16B MIC 密钥
加密：SM4-CBC；完整性：SM4-CBC-MAC

WAPI技术演进

目前已迭代至2.0版本（面向后量子时代）

参考：WAPI 产业联盟《面向量子时代安全的 WAPI 2.0 技术标准与应用》白皮书 (2026.06)

演进背景

威胁	说明
APT/供应链攻击	组合攻击手段，要求更深防御纵深
量子计算颠覆性威胁	RSA/ECC 等经典数学难题面临”先存储后破解”风险

WAPI 代际对比

维度	WAPI 1.0 (2003)	WAPI 2.0 (2015 启动)
架构	三元对等安全架构	原子密钥建立与实体鉴别 (AKEA)
密码算法	SMS4 (对称)	SM2+SM3+SM4-GCM，支持 PQC 扩展
身份保护	无	内生身份保护（鉴别完成前身份不可见）
前向保密	无	强制 PFS
快速漫游	无	快速切换机制（<50ms 切换时延）
量子威胁	无缓解	混合设计策略，PQC 敏捷扩展
兼容性	—	向下兼容 WAPI 1.0，双模并存

WAPI 2.0 核心能力

长期安全与可升级 — 新增 WAI2 协议，AKEA 架构，密码算法敏捷接口
更强抗攻击能力 — 增强抵御接力攻击、离线字典攻击
身份信息保护 — 数字证书等长期身份标识在可信通道建立前隐藏
无缝快速切换 — 安全缓存与密钥衍生，降低漫游时延
合规性基础上性能更高 — SM2/SM3/SM4-GCM，更优传输效能
平滑演进与兼容互通 — 纯软件升级，与 WAPI 1.0 双模并存

工程化特点

纯软件升级：无需更换芯片/硬件平台，新增 WAI2 协议栈 + SM2/SM3 算法
双模并存：WAPI 1.0 与 2.0 终端同网络共存，渐进式替换
标准符合性测试：WAPI 产业联盟测试实验室已建立 WAPI 2.0 测试能力体系

标准编号	名称
GB 15629.11-2003	WAPI 基础标准 (1.0)
GB/T 32507-2016	SMS4 算法标准
GB/T 28455-2026	引入可信第三方的实体鉴别及接入架构规范 (2.0)
T/WAPIA 046-2021	WAPI 2.0 技术标准
ISO/IEC 9798-3	WAPI 核心技术国际标准

Linux主线对WAPI的支持现状

来自主线内核 v7.3-rc2 分析

Linux 内核对 WAPI 的支持是碎片化的”有算法无协议栈”状态：

加密算法层 — 完整

crypto/sm4.c + sm4_generic.c 提供 SM4 块密码（即 SMS4 的标准化名称）
ARM64-CE 有 SM4-GCM/CCM 硬件加速，x86/RISC-V 也有 ECB/CBC/CTR
但这些用于 TLS/IPsec，与 WAPI 的 WPI 模式（SMS4-OFB + HMAC-SM3）无关

常量层 — 最小定义

include/linux/ieee80211.h 定义了 WLAN_CIPHER_SUITE_SMS4（OUI 0x001472）和 WLAN_KEY_LEN_SMS4 = 32
WAPI IE 复用 Element ID 68（WLAN_EID_BSS_AC_ACCESS_DELAY），无专门别名

cfg80211 层 — 纯透传

无 WAPI IE 解析、无 WAPI AKM 定义
仅通过 cfg80211_supported_cipher_suite() 验证驱动是否声明了 SMS4

mac80211 层 — 完全空白

默认 cipher_suites[] 不含 SMS4
ieee80211_key_alloc() 的 switch 无 SMS4 case（不设 iv_len/icv_len）
ieee80211_key_enable_hw_accel() 中 SMS4 落入 default → 返回 -EINVAL
TX/RX 路径（tx.c/wpa.c/rx.c）零 SMS4 引用，无软件加密回退

驱动层 — 5 个完整实现 + 多个部分标记

驱动	支持程度
mwifiex / nxpwifi	最完整：WAPI IE 管理 + 密钥下发 + 扫描过滤
ath6kl	完整：cipher 声明 + WAPI_CRYPT 类型 + PN处理
cw1200	完整：WSM 密钥类型 + RX 状态
wfx	完整：HIF 命令 + 密钥填充
mt76 系列	部分：`.set_key()` 接受 SMS4，但 mac80211 框架缺失导致功能不完整
ath10k/ath11k	仅 RX PN 解析描述符
rtw89	仅 CAM 标志位
iwlwifi	仅 NVM SKU 标志

所有”完整实现”均为纯硬件卸载——密钥下发到固件，固件完成 SMS4 加解密。没有任何驱动或框架层实现 WAPI 的软件加密回退。

总结

层次	状态	说明
nl80211/cfg80211 API	✅ 就绪	CONTROL_PORT_ETHERTYPE + NO_ENCRYPT 足以支持 WAPI STA 模式
SMS4 算法 (crypto)	✅ 存在	SM4 CBC/CTR/GCM 在 crypto 子系统中可用
mac80211 软件加密	❌ 不存在	无 SMS4 软件加解密实现
驱动/固件支持	⚠️ 部分驱动	mwifiex、ath6kl、silabs/wfx、mt76 等有固件级 WAPI 支持
wpa_supplicant	❌ 不存在	主线 wpa_supplicant 无 WAPI 鉴别/密钥协商

用户能否用主线内核+常见网卡完成 WAPI 认证连接？

不能。 主线内核缺少两个关键组件：

wpa_supplicant 没有 WAPI 实现 — 无法发起 WAI 鉴别协议、协商 WPI-SMS4 密钥。这是最大障碍。
mac80211 没有 SMS4 软件加密 — 即使有 WAPI supplicant，使用依赖 mac80211 软件加密的网卡也无法完成数据加密。只有使用上述固件级 WAPI 支持的网卡（如 Marvell 88W8766/88W8897 via mwifiex、高通 QCA6174/9377 via ath6kl/ath10k、Silabs WF200）且配合厂商私有 WAPI supplicant 才可能工作。

要在中国使用 WAPI，需要：

厂商提供的私有 wpa_supplicant 补丁（如高通/联发科 SDK 中的 wapi supplicant 实现）
使用支持固件级 WAPI 的特定网卡
这些都不在主线内核和主线 wpa_supplicant 范围内

OpenHarmony对WAPI的支持现状

OpenHarmony 对 WAPI 的支持处于 “API 已定义、实现待适配” 阶段：

已完成的部分

API 层完整（API 12+）：WifiSecurityType 枚举定义了 WIFI_SEC_TYPE_WAPI_CERT(8) 和 WIFI_SEC_TYPE_WAPI_PSK(9)，配套 WifiWapiConfig 结构体支持 AS 证书、用户证书、PSK 类型配置
轻量系统早期预留：lite 系统 WifiDeviceConfig 从 v1.0 就有 wapiPskType 字段
网络设备层 EtherType：ETHER_TYPE_WAI 0x88b4 已定义
wpa_supplicant 基础设施：定制版 wpa_supplicant 2.11 + wpa_supplicant_lib 扩展层

依赖厂商适配的部分

WAPI 状态机依赖补丁：上游 wpa_supplicant 不原生包含 WAI 认证状态机（三步握手、SMS4 密钥派生）。需要厂商在 wpa_supplicant_lib 或通过补丁引入（类似 Nanoradio 的 wapi.c 实现）。OpenHarmony 公开仓库中未找到完整实现。
芯片固件依赖：SMS4 加解密需要芯片固件支持，主流 WiFi 芯片是否支持 WAPI 取决于厂商
WAPI-CERT 证书体系：需要完整 ASU 基础设施，文档中对证书格式和对接方式说明不足

数据流

连接流程：wifiManager.addDeviceConfig(WAPI配置) → WpaSupplicantAgent 映射为 wpa_supplicant 命令（proto=WAPI, key_mgmt=WAPI-PSK, pairwise=SMS4） → wpa_supplicant 发起关联（带 WAPI IE） → WAI 三步握手 → HDF 驱动设置 SMS4 加解密 → cfg80211 通过 CONTROL_PORT_ETHERTYPE=0x88b4 传递 WAI 帧

从内核维护者角度看，OpenHarmony 的 WAPI API 设计借鉴了 Android 模式，但实现深度不如 Android 成熟。要在 OpenHarmony 上实际跑通 WAPI，设备厂商需自行补齐 wpa_supplicant 的 WAI 状态机和芯片驱动适配。

硬件支持现状

综合评估与结论

现状总结

                  WAPI 全栈支持现状
┌──────────────────────────────────────────────────┐
│  标准/算法层    │ ✅ GB 15629.11 + SMS4/SM2/SM3    │
│  (国标/ISO)     │ ✅ WAPI 2.0 标准体系持续演进    │
├──────────────────────────────────────────────────┤
│  内核 API 层    │ ✅ nl80211 Control Port API 就绪 │
│  (cfg80211)     │ ✅ WLAN_CIPHER_SUITE_SMS4 已定义 │
├──────────────────────────────────────────────────┤
│  内核加密层     │ ✅ SM4 crypto 原语可用            │
│  (mac80211)     │ ❌ WPI-SMS4 软件加密未实现        │
├──────────────────────────────────────────────────┤
│  用户态协议栈   │ ❌ 主线 wpa_supplicant 无 WAPI    │
│  (wpa_supplicant)│ ⚠️ 厂商补丁存在 (Realtek 等)    │
├──────────────────────────────────────────────────┤
│  驱动/固件层    │ ⚠️ 部分驱动固件级支持            │
│  (各厂商驱动)   │ ⚠️ 无软件加密兜底                │
├──────────────────────────────────────────────────┤
│  产业落地       │ ✅ WAPI网卡			         │
│  (商用案例)     │ ✅ WAPI 2.0 示范网第一阶段完成   │
└──────────────────────────────────────────────────┘

关键发现

标准成熟度高，工程实现断层：WAPI 1.0 标准已发布 20 余年，WAPI 2.0 也在持续推进，但 Linux 主线内核和 wpa_supplicant 主线始终未合入完整实现。
厂商私有实现是当前唯一路径：WAPI网卡都是闭源/厂商私有，无法回溯主线。
内核侧两大缺失明确：mac80211 缺 WPI-SMS4 软件加密，wpa_supplicant 缺 WAI 状态机。crypto SM4 原语和 nl80211 Control Port API 已就绪，技术路径清晰。
WAPI 2.0 是未来方向：面向后量子威胁，引入 AKEA 架构、身份保护、快速漫游、PQC 敏捷扩展，纯软件升级且向下兼容 1.0。示范网已验证 <50ms 漫游、管理帧保护、双模共存。
OpenHarmony 处于”API 已定义、实现待适配”阶段：框架层 API 完整，但协议栈和驱动层依赖厂商补丁，缺少开箱即用方案。

可行路径建议

路径	适用场景	可行性
A. 使用WAPI认证厂商方案	国产化桌面/终端，急需 WAPI 功能	✅ 已验证，认证通过
B. Realtek 补丁移植	基于 Realtek 芯片的设备	⚠️ 需匹配芯片固件，适配内核及核外（补丁基于旧版内核/ wpa_supplicant）
C. 主线合入 WAPI-PSK	长期目标，惠及全社区	6-9 个月，需社区推动，阻力大
D. 跟进 WAPI 2.0	面向后量子安全需求	标准持续完善中，示范网已验证

国产WLAN标准WAPI调研

国产WLAN标准WAPI调研

目录

WAPI 技术概述

基本定义

认证模式

WAI 帧格式

WPI-SMS4 帧格式

WAPI技术演进

演进背景

WAPI 代际对比

WAPI 2.0 核心能力

工程化特点

相关标准

Linux主线对WAPI的支持现状

加密算法层 — 完整

常量层 — 最小定义

cfg80211 层 — 纯透传

mac80211 层 — 完全空白

驱动层 — 5 个完整实现 + 多个部分标记

总结

用户能否用主线内核+常见网卡完成 WAPI 认证连接？

OpenHarmony对WAPI的支持现状

已完成的部分

依赖厂商适配的部分

数据流

硬件支持现状

综合评估与结论

现状总结

关键发现

可行路径建议