V9 SECURELINK · V9-STP PROTOCOL

应用层后量子
安全传输
让每一次连接可验证。

V9 SecureLink 是基于 V9-STP 协议构建的商业安全传输产品;V9 SDK 是可独立采购和集成的密码开发包。本页完整展示握手、混合 KEM、认证加密、密钥生命周期与跨端交付路径。

193 / 11 / 33内部测试记录ML-KEM-768NIST FIPS 203ML-DSA-65身份签名Hybrid KEM混合迁移
🏷️ 产品概述 · πV9 后量子安全产品体系

V9-STP 是应用层抗量子安全传输协议;V9 SecureLink 是基于该协议构建的商业安全传输产品;V9 SDK 是可独立采购和集成的密码开发包。

🔗
V9 SecureLink
V9-STP · 传输安全
TLS 之上叠加四层加密
ML-KEM-768 + RSA-4096 混合 KEM
Data-in-Transit
🛡️
V9 SDK
独立密码开发包 · 多语言绑定
ML-KEM-768 + ML-DSA-65
Rust · C ABI · WASM · TypeScript
Standalone Cryptographic SDK
⚙️
πV9 加密引擎
piv9-core · 基础层
四层加密管线 + 混合 KEM
ZeroizeOnDrop · 常量时间
Data-in-Use
用途V9 SecureLinkV9 SDK
一句话基于 V9-STP 的应用层后量子安全传输产品可独立采购和集成的密码开发包
核心能力握手、状态机、网关、代理、浏览器与桌面组件KEM、签名、安全封包、密钥衍生与多语言绑定
应用范围浏览器、桌面与服务器之间的数据传输客户应用、设备、服务端与自有协议集成
标准算法ML-KEM-768 混合密钥建立与 AEAD 认证加密ML-KEM-768、ML-DSA-65、HKDF-SHA256 与 AEAD API
产品关系商业安全传输产品,V9-STP 是其协议基础独立商业产品,不等同于 SecureLink 客户端组件
交付方式网关、代理、跨端组件与授权系统组合交付Rust、C ABI、WASM、TypeScript 绑定独立授权
📐 πV9 与 SSL/TLS 的关系
πV9-STP 不是替代 TLS,而是在 TLS 之上叠加一层独立的应用层加密。
专业术语:Post-Quantum Application-Layer Secure Transport Protocol (PQ-ALSTP)
· TLS 保护传输层 → πV9 保护应用层 → 即使 TLS 被攻破,V9 层仍有效
· TLS 密码套件固定 → πV9 算法可独立升级 → 不依赖浏览器/服务器更新
· TLS 依赖 CA 信任链 → πV9 密钥协商独立于 CA → 防企业代理/国家级 MITM
🔐 为什么需要多层防护?
安全领域三大支柱:网络安全 × 数据安全 × 密码安全
· 网络安全(TLS/防火墙)→ 保护传输通道 → 可能被中间人/量子破解
· 数据安全(V9-DAP)→ 保护存储数据 → 即使拖库也是密文
· 密码安全(πV9 引擎)→ 使用最新抗量子算法 → 面向未来
三者叠加 = 纵深防御:任一层被攻破,其他层继续保护
📦 协议层次模型

V9-STP 在标准 TCP/IP → TLS → HTTP 协议栈之上增加一层 V9 加密层,不改变底层协议

不变
LAYER 5
应用层 Application
业务数据:JSON / Protobuf / CBOR / 二进制
⭐ 核心
LAYER 4 · V9-STP
V9 加密层 — πV9 Encryption Layer
加密流水线:AES-256-GCM → π-XOR → ChaCha20-Poly1305 → HMAC-SHA3-512
密钥封装:ML-KEM-768 ⊕ RSA-4096-OAEP(混合 KEM)→ DEK
输出:EncryptedPackage(JSON / CBOR 序列化)
不变
LAYER 3
HTTP 层
REST API / WebSocket / gRPC-Web
不变
LAYER 2
TLS 层
TLS 1.3 · ECDHE + AES-GCM / ChaCha20(标准传输加密)
不变
LAYER 1
TCP/IP 层
TCP · IPv4 / IPv6
四层加密流水线

L4TopSecret 安全等级下,数据依次经过四层独立加密处理,每层使用不同算法实现异构纵深防御

1
AES-256-GCM
对称加密 Layer 1
NIST FIPS 197
2
π-XOR 混淆
πV9 独有混淆层
不可预测 · 非周期
3
ChaCha20-Poly1305
对称加密 Layer 3
IETF RFC 8439
4
HMAC-SHA3-512
完整性校验 64B
NIST FIPS 202
即使某层算法被攻破 → 其他层继续保护 → 异构加密纵深防御
🤝 V9-KEM 握手流程

在 TLS 已建立的 HTTPS 连接上进行 4 步握手,协商一个 V9 会话 DEK(数据加密密钥)

👤 Client 客户端
🖥️ Server 服务端
1

🔹 握手请求

客户端声明协议版本、支持的 KEM 方案、安全等级偏好

发送 32 字节 client_nonce(防重放)

POST /v9/handshake

🔹 握手响应

服务端生成临时密钥对:ML-KEM-768 ek + RSA-4096 pub

返回 session_id、server_nonce、ttl_seconds

两套公钥用于客户端封装 DEK

2
3

🔹 密钥交换

客户端生成 32B DEK(OsRng 密码学安全随机数)

ML-KEM-768 + RSA-4096 混合 KEM 封装 DEK

附带 client_proof = HMAC-SHA3-256(DEK, nonces)

POST /v9/exchange

🔹 握手确认

服务端解封 DEK → 验证 client_proof → 缓存会话

返回 server_proof(nonce 顺序相反 → 防反射攻击)

会话参数:rekey_after_messages=1000, rekey_after_seconds=1800

4
✅ V9 安全会话已建立 · 双方持有相同 DEK · 后续所有数据均经 V9 加密传输
🔄 数据流向

数据从明文到网络传输的完整加密路径(发送/接收为逆向过程)

📤 发送方
Step 1 明文 Plaintext V9.encrypt(DEK) EncryptedPackage
Step 2 EncryptedPackage HTTP Body TLS 加密 TCP 发送
📥 接收方(逆向)
Step 1 TCP 接收 TLS 解密 HTTP Body
Step 2 EncryptedPackage V9.decrypt(DEK) 明文 Plaintext
🛡️ 威胁防御对比

V9-STP vs 仅 TLS 1.3 · 各类威胁场景下的防御能力

⚛️ 量子计算破解密钥交换
仅 TLS ❌ ECDHE/RSA 被 Shor 算法破解
+ V9-STP ✅ ML-KEM-768 抗量子安全
🕵️ 中间人攻击 (MITM)
仅 TLS ❌ CA 被攻破则失效
+ V9-STP ✅ V9 独立加密 · MITM 无法解读
📦 先存后解 (HNDL)
仅 TLS ❌ 未来量子可回溯
+ V9-STP ✅ ML-KEM + 临时密钥
💾 服务器内存窃取
仅 TLS ⚠️ 取决于实现
+ V9-STP ✅ ZeroizeOnDrop 自动擦除
✏️ 传输数据篡改
仅 TLS ✅ TLS MAC
+ V9-STP ✅✅ HMAC-SHA3-512 + AEAD 双重
🔁 重放攻击
仅 TLS ✅ sequence number
+ V9-STP ✅✅ timestamp + nonce + session
🔑 密钥泄漏
仅 TLS ⚠️ PFS (ECDHE)
+ V9-STP ✅ DEK 定期轮换 + 即时擦除
⏱️ 侧信道定时攻击
仅 TLS ⚠️ 取决于实现
+ V9-STP ✅ 常量时间比较
📊 安全能力对比

TLS 1.3 单独 vs TLS 1.3 + V9-STP 各维度安全强度可视化

仅 TLS
ECDHE · 量子可破
+ V9-STP
ECDHE + ML-KEM-768 + RSA-4096
仅 TLS
单层 AES-GCM
+ V9-STP
四层 AES + π-XOR + ChaCha20 + HMAC
仅 TLS
+ V9-STP
ML-KEM-768 · NIST FIPS 203 Level 3
仅 TLS
AEAD Tag
+ V9-STP
AEAD Tag + HMAC-SHA3-512
仅 TLS
ECDHE PFS
+ V9-STP
PFS + DEK 轮换 + ZeroizeOnDrop
仅 TLS
完全依赖 CA
+ V9-STP
V9 层独立密钥协商
🔐 混合 KEM 密钥封装

DEK 同时被 ML-KEM-768 和 RSA-4096 双重封装 → 任一算法被破也无法提取 DEK

🔷
ML-KEM-768
后量子密钥封装
NIST FIPS 203 · Level 3
公钥 1184B · 密文 1088B
基于模格 (Module-LWE)
混合封装
HKDF(kyber_ss ‖ rsa_ss)
→ combined_key
→ AES-GCM-wrap(DEK)
两者同时被破概率 ≈ 0
🔶
RSA-4096-OAEP
经典密钥封装
NIST FIPS 186-5
公钥 512B · 密文 512B
基于大整数分解
🔄 会话状态机

V9 会话从创建到销毁的完整生命周期

IDLE
空闲
—— handshake ——→
PENDING
握手中
↓ exchange
ESTABLISHED
已建立 · 数据传输中
⟲ rekey
↓ timeout / error / close
EXPIRED
已过期
ERROR
出错
CLOSED
已关闭
过期/出错 → 可发起新 handshake 重建会话 · 旧 DEK 即时 zeroize
会话参数默认值说明
ttl_seconds3600 (1h)会话最大存活时间
rekey_after_messages1000消息数阈值 → 轮换 DEK
rekey_after_seconds1800 (30min)时间阈值 → 轮换 DEK
idle_timeout300s (5min)空闲超时
handshake_timeout30s握手超时
📡 HTTP 头部约定

V9-STP 在标准 HTTP 请求/响应中增加 X-V9-* 自定义头部

POST /api/messages HTTP/1.1
Content-Type: application/piv9+json
X-V9-Session: 550e8400-e29b-41d4-a716-446655440000
X-V9-Version: v9-stp-1.0
X-V9-Sequence: 42
X-V9-Security-Level: 4
HTTP/1.1 200 OK
Content-Type: application/piv9+json
X-V9-Session: 550e8400-e29b-41d4-a716-446655440000
X-V9-Sequence: 43
X-V9-Rekey-Required: false
🗝️ 密钥生命周期

从生成到销毁的完整密钥管理流程,确保零残留

🎲
生成 Generate
OsRng 32B
密码学安全随机
📦
封装 Encapsulate
ML-KEM + RSA
混合 KEM 封装
🔐
使用 Encrypt/Decrypt
HKDF 派生子密钥
每次加密独立 nonce
🔄
轮换 Rekey
1000条 / 30分钟
自动触发新握手
🗑️
销毁 Zeroize
ZeroizeOnDrop
覆写 0 · 不可恢复
⚠️ 错误码

V9-STP 定义 13 个专用错误码,映射到标准 HTTP 状态码

错误码名称HTTP说明客户端动作
V9-1000HANDSHAKE_FAILED401握手失败(通用)重试 / 报错
V9-1001KEM_SCHEME_UNSUPPORTED401不支持的 KEM 方案降级 KEM 重试
V9-1002SESSION_EXPIRED401会话已过期重新握手
V9-1003SESSION_NOT_FOUND401会话不存在重新握手
V9-1004PROOF_MISMATCH401proof 校验失败中止 · 可能 MITM
V9-1005DECRYPTION_FAILED400解密失败重发 / 报错
V9-1006INTEGRITY_VIOLATION400完整性校验失败中止 · 数据被篡改
V9-1007SEQUENCE_ERROR400序号不连续/重复可能重放攻击
V9-1008REKEY_REQUIRED428需要 DEK 轮换发起新握手
V9-1009LICENSE_ERROR403SDK 授权问题检查 License
V9-1010RATE_LIMITED429握手频率超限退避重试
V9-1011PAYLOAD_TOO_LARGE413载荷过大分块传输
V9-1012VERSION_MISMATCH505协议版本不兼容升级 SDK
⚖️ 传统 SSL/TLS 传输 vs V9-STP 全维度对比

从协议架构到量子安全,逐项对比传统 HTTPS 与接入 V9-STP 后的安全能力差异

对比维度 传统 SSL/TLS 1.3 TLS 1.3 + V9-STP (πV9)
协议架构 单层传输加密
TLS Record Protocol
双层加密纵深防御
TLS 传输层 + V9 应用层独立加密
密钥交换算法 ECDHE (P-256 / X25519)
⚠ 量子计算机可用 Shor 算法破解
ECDHE (保留) + ML-KEM-768 ⊕ RSA-4096 混合 KEM
NIST FIPS 203 Level 3 · 抗量子安全
数据加密算法 AES-128/256-GCM 或 ChaCha20-Poly1305
单一算法 · 单层加密
四层异构流水线
AES-256-GCM → π-XOR → ChaCha20-Poly1305 → HMAC-SHA3-512
任一算法被破 → 其余层继续保护
抗量子能力 ❌ 无
ECDHE/RSA 在量子计算时代将全部失效
✅ 原生抗量子
ML-KEM-768 · NIST FIPS 203 后量子标准 · 混合方案兼容过渡
先存后解防护 (HNDL) ❌ 无法防御
今天录制的加密流量,未来量子时代可回溯解密
✅ 完全防御
ML-KEM 临时密钥 + DEK 短生命周期 → 即使录制也无法解密
完整性校验 AEAD Tag (128-bit)
仅 TLS 记录层校验
AEAD Tag + HMAC-SHA3-512 (512-bit) 双重校验
TLS 层 + V9 应用层独立完整性保护
前向安全 (PFS) ✅ ECDHE 临时密钥
⚠ 密钥可能残留内存
✅ PFS + ZeroizeOnDrop + DEK 轮换
DEK 每 1000 条或 30 分钟自动轮换 · 旧密钥即时覆零
密钥管理 TLS 会话恢复 (PSK)
密钥生命周期由 TLS 库管理
完整密钥生命周期管理
生成 → KEM 封装 → HKDF 派生 → 轮换 → ZeroizeOnDrop 销毁
CA 依赖 完全依赖 CA 信任链
CA 被攻破 → 全线崩溃
V9 层独立于 CA
即使 CA / TLS 被攻破 · V9 加密层仍有效保护数据
中间人攻击防护 依赖 CA 证书验证
⚠ 企业代理 / 国家级 MITM 可能绕过
✅ 双层独立防护
TLS 层 + V9 独立密钥协商 · MITM 只能看到 V9 密文
算法替换弹性 仅限 TLS 密码套件协商
更换困难 · 需等浏览器/服务器支持
V9 层算法可独立升级
不依赖底层 TLS 变更 · SDK 升级即可切换新算法
部署复杂度 ✅ 原生支持
浏览器/服务器内置 · 零额外成本
需集成 V9 SecureLink 客户端组件
服务端 + 客户端 SDK · 保留原有 TLS 不变 · 渐进式增强
性能开销 极低 (~1% CPU)
硬件加速 AES-NI
额外 2-5% CPU · 延迟增加 <3ms
V9 四层流水线并行优化 · WASM 浏览器端 ~5ms/KB
合规标准 NIST SP 800-52r2
PCI DSS · HIPAA
满足当前合规要求
NIST FIPS 203/197/202 · CNSA 2.0
PCI DSS · HIPAA · GDPR · 等保三级
同时满足当前 + 后量子合规要求
适用范围 所有 HTTPS 通信
通用互联网传输
高价值 / 长期敏感数据传输
金融 · 医疗 · 政务 · 军工 · 跨境数据 · 需未来安全性场景
结论:V9-STP 不是替代 TLS,而是在 TLS 之上叠加一层独立的应用层加密, 实现 零基础设施改动 + 抗量子纵深防御
🚀 一键部署 · 服务端安装

像安装宝塔面板一样简单 — 一行命令,V9-STP 服务端即可运行

🖥️ 服务端安装(一行命令)
# Linux / macOS(类似宝塔安装方式)
curl -fsSL https://install.lonxang.com/v9-stp | bash

# 或指定版本和安全等级
curl -fsSL https://install.lonxang.com/v9-stp | bash -s -- --version 1.0 --level L4

# Docker 一行启动
docker run -d -p 8443:8443 -e LICENSE_KEY=xxx lonxang/v9-stp:latest

# Windows (PowerShell)
irm https://install.lonxang.com/v9-stp.ps1 | iex
安装脚本自动完成:
1
检测环境
OS / 架构 / 端口
自动选择二进制
2
下载二进制
v9-stp-server
~15MB 静态链接
3
生成密钥对
ML-KEM-768 + RSA-4096
临时密钥自动管理
4
注册服务
systemd / launchd
开机自启
5
就绪
/v9/handshake
/v9/exchange 可用
📦 客户端 SDK 安装
Rust
cargo add piv9-stp
npm / Browser
npm i @piv9/stp-wasm
Python
pip install piv9-stp
PHP
composer require lonxang/v9-stp
Android
com.lonxang:piv9-stp-android
iOS
lonxang/piv9-stp-ios (SPM)
所有 SDK 包均发布到对应语言的 公共包注册表(crates.io / npm / PyPI / Packagist / Maven)· 开发者可直接安装
🌐 浏览器端 STP 工作方式

浏览器如何获得 V9-STP 保护?三种接入模式,按场景选择最合适的方案

📦
模式 A · WASM 嵌入
⭐ 推荐
原理:πV9 引擎编译为 WebAssembly,直接嵌入网页 JavaScript

用户体验零感知 · 无需安装任何东西
网站开发者引入 @piv9/stp-wasm 包 → 自动握手 + 加解密

优势:兼容所有现代浏览器 · 无需插件
体积:~300KB gzip · 首次加载后缓存
性能:~5ms/KB(加密)· 接近原生
// 开发者代码
import { V9StpClient } from '@piv9/stp-wasm'
const client = new V9StpClient({...})
await client.fetch('/api/data', {...})
🧩
模式 B · 浏览器扩展
企业级
原理:Chrome/Firefox/Edge 扩展,自动拦截指定域名的 HTTP 请求并加密

用户体验:安装扩展 → 配置企业域名 → 全站自动 V9 加密
网站无需改一行代码

优势:对现有网站零改动
适用:企业内部系统 · 合规审计
分发:Chrome Web Store 或 MDM 推送
用户安装扩展 → 自动注入 V9 加密层
→ 所有 AJAX/fetch 请求透明加密
🖥️
模式 C · 桌面端代理
最高安全
原理:本地运行 V9 代理进程,浏览器通过代理发请求,代理自动加密

用户体验:安装桌面客户端 → 自动设置系统代理 → 完全透明

优势:密钥完全在本地 · 不经过浏览器 JS 环境
适用:军工/政务 · 最高安全等级
平台:Windows / macOS / Linux
浏览器 → 本地代理(V9加密) → 服务器
密钥不暴露给浏览器 JS 运行时
对比项WASM 嵌入浏览器扩展桌面代理
用户安装不需要安装扩展安装客户端
网站改动引入 SDK零改动零改动
密钥位置浏览器内存(WASM)扩展沙箱本地进程
加密性能~5ms/KB~5ms/KB<1ms/KB
浏览器兼容所有现代浏览器Chrome/Firefox/Edge所有浏览器
推荐场景SaaS / 互联网企业内部军工 / 政务
结论:大多数场景选 WASM 嵌入 即可 · 用户无需安装任何东西 · 浏览器原生不支持 STP 但通过 WASM 完美替代
🛡️ V9-DAP 数据库透明加密

即使数据库被完整拖走,攻击者拿到的也只是乱码 — 没有 V9 解密环境 = 没有数据

📂 V9-DAP 已拆分为独立项目 → V9-DAP数据库加密/ · 完整文档请查阅该项目 README
📝 写入数据(自动加密)
应用层 明文 "张三" V9-DAP 中间件 密文 "v9:AQIDBAUGBwg..."
存储层 密文 → 数据库 🔒 数据库中只有密文 · DBA 看不到原始数据
📖 读取数据(自动解密)
存储层 数据库返回密文 V9-DAP 解密 明文 "张三"
对应用代码 完全透明 · 不需要改任何业务逻辑 · ORM 中间件自动处理
🔑 密钥层次
🔴
Master Key(主密钥)
存在应用服务器本地
文件 / 环境变量 / HSM
绝不在数据库中!
🟡
Table DEK(表密钥)
每个表独立 DEK
被 Master Key 加密后
存在数据库中
🟢
安全保证
拖库 → 只有密文
偷 MK → 仍需 DEK 与运行时授权
多层控制降低单点失陷风险
🔍 加密后怎么查询?— 盲索引 (Blind Index)
问题:字段加密后 WHERE phone = '13800138000' 怎么办?
解决:存储时同时生成 HMAC-SHA256(key, 原文) 作为盲索引列
查询:V9-DAP 自动将 WHERE 条件转为盲索引匹配
支持:精确匹配 ✅ · IN 查询 ✅ · 模糊查询 ❌(需应用层过滤)
攻击场景无 V9-DAP有 V9-DAP
SQL 注入拖库❌ 全部泄露(明文)✅ 拿到密文 · 无法解密
备份文件泄露❌ 全部泄露✅ 备份中也是密文
DBA 偷看数据❌ 可直接查看✅ 只看到密文
内部人员导出❌ 导出即明文✅ 导出也是密文
物理盗窃硬盘❌ 挂载即可读✅ 没有 Master Key 无法解密
暗网售卖数据❌ 直接可用✅ 密文无商业价值
🗄️ 支持的数据库 + 框架集成
MySQL / MariaDB
5.7+ / 10.5+
PostgreSQL
12+
SQLite
3.x
MongoDB
5.0+ (计划中)
集成方式:Laravel use V9Encrypted; · Django V9EncryptedCharField() · Sequelize V9.ENCRYPTED() · JPA @V9Encrypted
📋 授权体系 · 四级商业模式

V9 授权系统独立于 SDK · 基于 Ed25519 数字签名的轻量级离线验证 · 不依赖联网

Free
🆓 社区版
· 仅 AES-256-GCM 单层加密
· 单域名 · 10 QPS
· 无 SLA · 社区论坛支持
· 适用:个人学习 / 原型验证
Business
🏢 商业版
· 完整四层加密管线
· 多域名 · 不限 QPS
· 99.9% SLA · 工单支持
· 适用:中小企业 SaaS
Enterprise
🏦 企业版
· 全功能 + V9-DAP
· 私有部署 · 自定义算法
· 99.99% SLA · 专属工程师
· 适用:金融 / 医疗 / 上市公司
Government
🏛️ 政务版
· 全功能 + 源码审计权
· 等保三级 / CNSA 2.0
· 7×24 驻场支持
· 适用:政府 / 军工 / 央企
🔏 授权技术实现
签发:Ed25519 私钥签名 License Payload(域名绑定 + 并发限制 + 过期时间 + 功能开关)
验证:SDK 内置 Ed25519 公钥 → 启动时离线验证签名 → 无需联网授权服务器
格式:Base64URL(header.payload.signature) · 类似 JWT 但更紧凑
防滥用:域名绑定 + 硬件指纹 + 在线心跳(可选)+ 吊销列表
防滥用机制说明
域名绑定License 签发时写入允许的域名列表 · SDK 运行时校验当前域名
并发限制FREE: 10 QPS · BIZ: 不限 · 超限返回 V9-1009 LICENSE_ERROR
过期时间每个 License 有 exp 字段 · 过期后 SDK 停止工作
吊销列表可通过在线 CRL 推送即时吊销泄露的 License
硬件指纹ENT/GOV 版可绑定服务器 CPU + MAC 地址
🏢 应用场景

V9-STP 适用于任何需要增强数据传输安全的业务系统 · 获得授权后即可为您的产品接入抗量子安全保护

🏦
金融支付

银行核心交易系统、网上银行、移动支付、证券交易指令。保护资金流转数据免受量子威胁和中间人攻击,满足 PCI DSS 最高安全要求。

银行核心系统 移动支付 证券交易 PCI DSS
🏥
医疗健康

电子病历传输、远程诊疗数据流、医疗影像传输、药品溯源。患者隐私数据在传输链路上获得双层加密保护,符合 HIPAA 合规要求。

电子病历 远程诊疗 HIPAA 患者隐私
🏛️
政务军工

政府内部系统通讯、军事指挥数据、涉密文件传输、公安系统。抗量子加密确保长期机密性,防止"先存后解"攻击。满足 CNSA 2.0 和等保三级。

政务内网 军事通信 等保三级 CNSA 2.0
💬
企业即时通讯

企业 IM 聊天消息、音视频通话信令、文件传输。端到端加密之上叠加传输层 V9 保护,确保消息在传输过程中不被窃听或篡改。

企业 IM 音视频信令 文件传输 E2EE + V9
🔌
物联网 / 工业控制

智能设备数据上报、工业 SCADA 控制指令、车联网 V2X 通信。轻量级 SDK 适配嵌入式环境,保护关键基础设施传输安全。

IoT 设备 SCADA 车联网 边缘计算
☁️
云服务 / SaaS

云存储数据传输、SaaS 平台 API 通信、多租户数据隔离。为您的云产品增加一层抗量子安全卖点,提升产品竞争力。

云存储 SaaS API 多租户隔离 产品差异化
🌐
跨境数据传输

跨国企业数据同步、跨境电商交易、国际结算系统。在不同法域的网络环境中提供一致的端到端安全保护,满足 GDPR 数据跨境要求。

跨境合规 GDPR 国际结算 数据主权
⛓️
区块链 / 数字资产

数字钱包通信、DeFi 交易签名传输、NFT 元数据传输、交易所 API。保护高价值数字资产的传输链路免受量子攻击。

数字钱包 DeFi 交易所 API 资产保护
🔧 SDK 接入指南

获得 FREDERIC 授权后,按以下方式将 V9-STP 集成到您的系统中 · 支持多语言多平台

1
获取授权
联系 FREDERIC 获取
License Key 和 SDK 包
2
集成 SDK
服务端 + 客户端
引入 piv9-stp 依赖
3
激活 License
应用启动时调用
activate_license()
4
握手建立会话
调用 handshake()
协商 V9 安全会话
5
加密传输
使用 encrypt/decrypt
透明保护业务数据
// Cargo.toml
// [dependencies]
// piv9-stp = { version = "1.0", features = ["server"] }

use piv9_stp::{V9StpServer, License, SecurityLevel};

#[tokio::main]
async fn main() {
    // 1. 激活授权
    License::activate("YOUR-LICENSE-KEY").await?;

    // 2. 创建 V9-STP 服务端实例
    let server = V9StpServer::builder()
        .security_level(SecurityLevel::L4TopSecret)
        .rekey_after_messages(1000)
        .session_ttl_secs(3600)
        .build()?;

    // 3. 注册到 Axum 路由
    let app = axum::Router::new()
        .route("/v9/handshake", post(server.handshake_handler()))
        .route("/v9/exchange",  post(server.exchange_handler()))
        .route("/api/data",     post(handle_encrypted_data));

    // 4. 在业务处理函数中解密/加密
    axum::Server::bind(&"0.0.0.0:8443".parse()?)
        .serve(app.into_make_service()).await?;
}

async fn handle_encrypted_data(
    session: V9Session,
    body: Bytes,
) -> impl IntoResponse {
    // 自动解密请求体
    let plaintext = session.decrypt(&body)?;

    // 处理业务逻辑...
    let response_data = process_business(&plaintext);

    // 自动加密响应体
    session.encrypt(&response_data)
}
// npm install @piv9/stp-wasm

import { V9StpClient, initWasm } from '@piv9/stp-wasm';

// 1. 初始化 WASM 模块
await initWasm();

// 2. 创建客户端并激活授权
const client = new V9StpClient({
  licenseKey: 'YOUR-LICENSE-KEY',
  serverUrl:  'https://api.example.com',
  securityLevel: 4,  // L4TopSecret
});

// 3. 执行 V9-KEM 握手(自动 4 步)
await client.handshake();
console.log('V9 会话已建立, sessionId:', client.sessionId);

// 4. 发送加密请求(透明加密)
const response = await client.fetch('/api/data', {
  method: 'POST',
  body: JSON.stringify({ message: 'Hello V9-STP!' }),
});

// 5. 响应自动解密
const data = await response.json();
console.log('解密后的响应:', data);

// SDK 自动处理:
// - DEK 轮换(每 1000 条自动 rekey)
// - 会话过期自动重新握手
// - 序号管理和完整性校验
// - 内存中密钥自动擦除
# pip install piv9-stp

from piv9_stp import V9StpClient, SecurityLevel

# 1. 创建客户端并激活授权
client = V9StpClient(
    license_key="YOUR-LICENSE-KEY",
    server_url="https://api.example.com",
    security_level=SecurityLevel.L4_TOP_SECRET,
)

# 2. 执行握手
client.handshake()
print(f"V9 会话已建立: {client.session_id}")

# 3. 加密发送数据
response = client.post("/api/data", json={
    "message": "Hello V9-STP!",
    "amount":  10000.00,
})

# 4. 响应自动解密
data = response.json()
print("解密后的响应:", data)

# 5. 批量数据加密传输
with client.stream("/api/upload") as stream:
    for chunk in read_file_chunks("large_file.bin"):
        stream.send(chunk)  # 自动 V9 加密 + 分块

# SDK 自动处理 rekey / 会话管理 / 密钥擦除
// build.gradle.kts
// implementation("com.lonxang:piv9-stp-android:1.0.0")

import com.lonxang.piv9.stp.*

class SecureApiClient(context: Context) {

    private val client = V9StpClient.Builder(context)
        .licenseKey("YOUR-LICENSE-KEY")
        .serverUrl("https://api.example.com")
        .securityLevel(SecurityLevel.L4_TOP_SECRET)
        .build()

    suspend fun sendSecureMessage(message: String): ApiResponse {
        // 握手(首次自动执行,后续自动管理)
        client.ensureSession()

        // 发送加密请求
        val response = client.post("/api/data") {
            jsonBody(mapOf("message" to message))
        }

        // 自动解密响应
        return response.decode<ApiResponse>()
    }
}

// Activity 中使用
val api = SecureApiClient(applicationContext)
lifecycleScope.launch {
    val result = api.sendSecureMessage("Hello V9-STP!")
    Log.d("V9", "Response: ${result}")
}
// Swift Package Manager:
// .package(url: "https://github.com/lonxang/piv9-stp-ios", from: "1.0.0")

import PIV9STP

class SecureAPIManager {

    private let client: V9StpClient

    init() throws {
        client = try V9StpClient(
            licenseKey: "YOUR-LICENSE-KEY",
            serverURL: URL(string: "https://api.example.com")!,
            securityLevel: .l4TopSecret
        )
    }

    func sendSecureData(_ message: String) async throws -> APIResponse {
        // 自动握手 + 会话管理
        try await client.ensureSession()

        // 加密请求
        let response = try await client.post("/api/data", body: [
            "message": message,
        ])

        // 自动解密响应
        return try response.decode(APIResponse.self)
    }
}

// SwiftUI 中使用
let api = try SecureAPIManager()
let result = try await api.sendSecureData("Hello V9-STP!")
print("解密响应: \(result)")
📋 授权说明:V9 SecureLink 与 V9 SDK 均通过 FREDERIC.LTD / LONXANG 提供商业授权。 两项产品可独立采购或组合交付,具体授权范围以正式协议为准。
联系授权:license@lonxang.com · 技术支持:support@lonxang.com
🗺️ 版本演进路线

V9-STP 的功能演进计划

当前版本
v1.0
2026 Q2
  • 4 步握手协议 · 已纳入 193 / 11 / 33 内部测试基线
  • 混合 KEM (ML-KEM + RSA)
  • 四层加密流水线
  • Axum 网关 + 21 E2E tests
  • WASM SDK (浏览器端)
  • Tauri 桌面端插件 + 8 IPC + 4 HTTP E2E tests
  • MITM 代理 v0.4 (ALPN h2) + 15 unit tests
  • @lonxang/piv9-web TS SDK + Web Worker
  • 性能基准: 握手 322µs · seal 93MB/s
  • Ed25519 授权系统 + S2 降级
  • Feature gate: 9 功能 × 4 tier + 13 tests
  • CA 私钥 AES-256-GCM 加密持久化
  • Server guards: 并发/频率/载荷三重限制 + Prometheus
  • 安全验收: HMAC篡改/跨会话/过期/重放 4 项测试
  • 密钥轮换 SOP (Ed25519 8 步)
  • Windows 服务 + Code Signing 脚本
  • P6 全完成: 协议 v1.0.0 定稿 + API 文档 + 安全审计 95.9% + 运维手册
  • 当前能力、规划能力与认证状态按正式产品书分层披露
v1.1
2026 Q3
  • CBOR 紧凑格式
  • 0-RTT 快速重连
  • 会话恢复 (Session Resume)
v1.2
2026 Q3
  • 流式加密 API
  • 大文件分块标准化
  • 断点续传支持
v2.0
2026 Q4
  • ML-DSA 数字签名
  • Ascon-AEAD 轻量加密
  • gRPC 原生支持
  • IoT 轻量模式