产品书目录
一、执行摘要
1.1 市场正在发生什么变化
当前互联网和企业网络主要依赖 TLS 保护传输通道。TLS 1.3 仍是重要且成熟的行业标准,但企业面临的新问题已经不只是“链路是否加密”,还包括:
“先存后解”(Harvest Now, Decrypt Later)使后量子安全从远期研究课题变成需要提前规划的现实工程问题。金融交易、政企数据、医疗记录、知识产权和商业秘密的保密期,往往远长于系统更新周期。
1.2 πV9 提供什么
| 产品 | 核心定位 | 主要客户 |
|---|---|---|
| V9 SecureLink | 在现有 TLS 之上增加独立的应用层抗量子数据保护 | 企业客户、SaaS 平台、政企系统、金融与医疗机构 |
| V9 SDK | 将 πV9 加密、密钥封装、签名和数据保护能力嵌入第三方产品 | 软件厂商、安全厂商、系统集成商、设备厂商和开发团队 |
客户可以独立部署 V9 SecureLink,也可以独立采购 V9 SDK;对于需要完整能力的项目,两者可组合为“底层加密能力 + 安全传输协议 + 多端接入 + 商业授权”的整体方案。
1.3 客户获得的价值
- 在现有 HTTPS/TLS 体系之外建立独立数据安全层;
- 面向后量子迁移提前建设技术能力;
- 减少从零开发密码系统所需的时间、团队和安全工程成本;
- 为现有软件、平台或设备增加可销售的高等级安全能力;
- 支持企业部署、项目交付、SDK 授权、OEM 和联合解决方案;
- 通过统一 Rust 核心和多端绑定,降低跨平台实现不一致风险;
- 获得可测试、可集成、可升级、可持续维护的产品化交付。
隆相智能:公司文化与技术体系
隆相(上海)智能科技发展有限公司是英国 FREDERIC.LTD 于 2020 年 6 月 24 日在上海设立的全资智能科技公司。公司面向人工智能与后量子时代,持续推进数据安全、跨平台软件、企业智能化技术的研发、产品化与商业应用。
πV9 技术与安全产品工程体系
V9 SecureLink 是基于 V9-STP 协议构建的应用层抗量子安全传输产品;V9 SDK 是可独立采购和集成的加密开发包。两项产品可独立交付,也可组合形成完整方案。V9-STP 负责协议字段、握手、状态机、错误码和版本协商;V9 SecureLink 负责网关、代理、部署、运维和传输授权;V9 SDK 负责通用密码 API、多语言绑定和 SDK 授权。公司以统一密码核心、跨平台接口、安全授权、私有部署、验证体系和长期演进机制,支持企业对产品进行验证、集成、运营和升级。
二、市场需求与行业机会
2.1 从“通道安全”走向“数据本身安全”
随着业务云化、API 化、移动化和跨组织协同,数据会经过更多客户端、网关、服务和平台。企业需要把安全控制进一步下沉到数据载荷本身:即使外层通道或基础设施发生变化,业务数据仍然保持独立保护。
V9 SecureLink 不替代 TLS,而是与 TLS 协同工作:
这种方式既保留 TLS 的成熟生态,又增加一套能够独立演进的数据安全机制。
2.2 “先存后解”推动迁移提前发生
攻击者不一定需要今天破解密文。他们可以先截获、保存高价值数据,等待未来计算能力、算法研究或实现漏洞带来新的分析机会。
决定是否启动后量子迁移的关键,不只是量子计算何时成熟,还包括:
- 数据需要保密多少年;
- 数据泄露后是否可撤回;
- 当前系统升级需要多长周期;
- 行业监管和客户合同是否会提高密码能力要求;
- 企业是否需要建立密码敏捷和迁移路线。
2.3 企业落地障碍带来的产品机会
后量子安全并非简单替换一个算法。企业还要解决密钥生命周期、身份认证、会话状态、防重放、多端兼容、版本协商、错误处理、授权管理和持续升级等问题。
πV9 双核心产品将这些复杂能力转化为可采购、可集成、可授权和可持续维护的标准化产品,帮助客户缩短安全能力从研发到上线的距离。
三、双核心产品体系
3.1 产品一:V9 SecureLink
V9 SecureLink 是 V9-STP 的商业产品名称。它运行在现有 TLS 之上,在 HTTP/HTTPS 数据载荷层增加独立的 πV9 加密与会话保护。
核心目标:
- 不替代 TLS;
- 不改变 TCP/IP、DNS 和现有网络协议栈;
- 以应用层方式保护数据内容;
- 为现有 Web、桌面和服务端业务增加后量子安全能力;
- 提供统一协议、SDK、网关、授权和运维体系。
3.2 产品二:V9 SDK 开发包
V9 SDK 面向开发者和产品厂商。客户可以将其嵌入自己的应用、平台、设备或行业方案,建立自主的数据加密、解密、密钥封装、签名验证和安全数据包处理能力。
V9 SDK 的价值不只是一组算法接口,而是将底层密码能力封装为可开发、可测试、可授权和可交付的软件开发工具包。
3.3 采购与组合方式
| 采购方式 | 适用需求 | 交付结果 |
|---|---|---|
| 仅 V9 SecureLink | 快速升级现有通信和 API 安全 | STP 网关、客户端能力、部署与集成支持 |
| 仅 V9 SDK | 将加密能力嵌入自有产品 | SDK、API、示例、授权与技术支持 |
| 组合交付 | 同时需要底层密码能力和安全传输体系 | V9 SDK + SecureLink + 多端集成 + 联合测试 |
| OEM/白标合作 | 纳入合作伙伴品牌和产品体系 | OEM 授权、品牌适配、接口定制与联合交付 |
四、V9 SecureLink 技术能力
4.1 TLS 之上的独立数据保护与协议层次
外层继续使用标准 TLS 1.3,内层由 πV9 引擎保护业务载荷。客户可以保留现有证书、域名、反向代理和网络设施,同时在应用层独立升级密码机制。V9 SecureLink 不改变 TCP/IP、DNS、TLS 与 HTTP 的职责,而是在业务数据进入 HTTP 请求体之前完成安全封装,在接收端通过会话校验后恢复业务载荷。
| 层次 | 内容 | SecureLink 的处理边界 |
|---|---|---|
| 业务应用层 | JSON、Protobuf、CBOR 或二进制业务数据 | 应用提交明文载荷并接收解密后的业务数据 |
| πV9 应用安全层 | 握手、身份签名、混合 KEM、会话、四层管线与安全封包 | 本产品的核心控制层,输出版本化安全数据包 |
| HTTP/HTTPS 层 | REST API、Web 请求及现有服务接口 | 承载安全数据包,不要求改变业务网络协议 |
| TLS 1.3 层 | 标准通道加密、证书与既有反向代理 | 保留并继续使用,与应用安全层协同 |
| TCP/IP 与网络层 | 现有地址、路由、负载均衡和网络设施 | 不作替换,按客户现网继续运行 |
发送方向的逻辑顺序为“业务载荷 → πV9 安全封装 → HTTP 请求体 → TLS 1.3 → 网络”;接收方向按相反顺序处理。外层 TLS 与内层 πV9 会话分别承担通道保护和业务载荷保护,二者不是替代关系。
4.2 后量子与经典算法混合 KEM
默认密钥封装方案结合:
- ML-KEM-768:NIST FIPS 203 标准化的后量子密钥封装算法;
- RSA-4096-OAEP:经典密码体系中的兼容与冗余能力;
- HKDF-SHA256:组合共享秘密并派生封装密钥;
- AES-256-GCM:保护数据加密密钥(DEK)。
混合设计提高密码敏捷性和迁移稳健性,使系统不必把全部安全性押注在单一路径上。其处理结构如下:
混合 KEM 的目的在于提供迁移期间的算法异构性与可升级边界,不构成对任何单一路径或部署环境的无条件安全结论。
4.3 v1.1 服务端身份认证与 transcript 绑定握手
V9 SecureLink v1.1 在握手中引入 ML-DSA-65 服务端身份签名,并将签名绑定到完整握手 transcript。绑定信息包括协议版本、双方随机数、会话标识、协商 KEM、安全等级、算法套件、KEM 公钥和客户端能力声明。这有助于控制身份冒充、协商字段篡改和 KEM 降级风险。缺少可信固定公钥或验签失败时,客户端默认拒绝继续建立安全会话。
| 阶段 | 客户端动作 | 服务端动作 | 关键校验与输出 |
|---|---|---|---|
| 1. 发起协商 | 生成客户端随机数,声明协议版本、KEM、安全等级、算法套件与能力 | 校验版本和能力范围 | 创建待建立会话,不接受超范围参数 |
| 2. 身份响应 | 接收会话标识、服务端随机数、KEM 公钥和签名 | 生成会话材料,对完整 transcript 计算 ML-DSA-65 签名 | 客户端使用可信固定公钥验签;缺失或失败即拒绝 |
| 3. 密钥交换 | 执行混合 KEM,提交封装结果与 client proof | 解封共享材料,组合派生 DEK 并验证 client proof | 协商字段、随机数和会话标识保持绑定 |
| 4. 完成确认 | 验证 server proof,确认双方持有一致会话上下文 | 返回 server proof 与受控会话参数 | proof 失败、中间字段变化或降级均中止 |
| 5. 建立会话 | 保存会话标识、序号和到期边界 | 将会话从待建立切换为已建立 | 后续载荷必须引用正确会话并通过序号校验 |
transcript 不是单一字段,而是握手关键上下文的规范化集合。签名与 proof 分别承担服务端身份确认和双方会话材料一致性确认,避免只验证公钥却未绑定协商结果。
4.4 四层加密管线与双向数据流
| 顺序 | 处理层 | 主要作用 | 接收端处理 |
|---|---|---|---|
| 1 | AES-256-GCM | 标准对称认证加密,建立第一层机密性与完整性边界 | 验证认证信息后解密 |
| 2 | π-XOR 序列扰动层 | 增加独立的数据变换维度 | 按会话派生参数逆向恢复 |
| 3 | ChaCha20-Poly1305 | 使用不同设计路线的认证流密码形成异构保护 | 验证后解密 |
| 4 | HMAC-SHA3-512 | 对最终安全封包提供独立完整性检查 | 先校验,再进入其余逆向处理 |
发送数据流:
接收数据流:
多层设计强调纵深防御和算法异构性,通过多种标准算法、独立密钥处理和完整性机制提高攻击成本与系统韧性,但不替代安全部署、密钥治理、权限控制和持续评估。
4.5 会话状态、防重放与密钥生命周期
会话状态按“空闲/未建立 → 待建立 → 已建立 → 需要轮换、已过期或错误 → 关闭并清理”演进。只有完成身份验签、混合 KEM、双方 proof 校验的会话才能进入已建立状态。版本不兼容、固定公钥缺失、签名失败、协商降级、proof 不一致、会话超时或载荷越界均进入拒绝或错误路径。
| 控制对象 | 机制 | 处理原则 |
|---|---|---|
| 会话隔离 | 独立 session ID 与会话上下文 | 跨会话载荷拒绝处理 |
| 防重放 | 单调消息序号、已接收状态与双方随机数 | 重复、倒退或不连续序号按策略拒绝 |
| 有效期 | 会话 TTL、空闲边界与握手超时 | 到期后重新握手,不沿用旧状态 |
| 密钥轮换 | 按消息数量、持续时间或策略触发 DEK 更新 | 轮换通过新握手建立,不静默复用过期材料 |
| 资源控制 | 会话数、载荷大小、握手频率与运行指标 | 超限时受控拒绝、限速或退避 |
| 敏感材料 | 生命周期结束后的内存擦除 | 关闭、失败和过期路径均执行清理 |
密钥生命周期依次包括:使用密码学安全随机源生成会话材料;通过混合 KEM 交换和派生;在已建立会话中受控使用;达到策略边界后轮换;会话关闭、失败或过期后清理。身份固定公钥、临时 KEM 材料、共享秘密与 DEK 的职责不同,不应混用或以长期身份材料直接替代会话密钥。
4.6 威胁与控制映射
| 威胁或失效场景 | 主要控制 | 默认处置 |
|---|---|---|
| 服务端身份冒充 | ML-DSA-65 签名、可信固定公钥、完整 transcript 绑定 | 验签失败或信任根缺失时拒绝握手 |
| KEM 或算法套件降级 | 协商字段进入 transcript 与 proof | 字段变化或不受支持时中止 |
| 握手重放 | 双方随机数、会话标识、握手状态与时限 | 过期或重复上下文拒绝 |
| 消息重放与乱序 | 会话内消息序号和接收状态 | 重复、倒退或异常序号拒绝 |
| 密文或 proof 篡改 | 认证加密、HMAC 与双方 proof | 校验失败,不向应用释放载荷 |
| 跨会话注入 | 会话标识与会话密钥绑定 | 会话不匹配时拒绝 |
| 长期会话风险 | TTL、消息计数和 DEK 轮换 | 到达边界后重新握手 |
| 资源消耗与异常载荷 | 握手限速、会话与载荷限制、运行指标 | 限流、拒绝并记录受控指标 |
| 客户端实现差异 | 统一 Rust 核心与版本化协议 | 通过版本兼容策略和跨端验证控制 |
4.7 产品组件与成熟度
| 组件 | 产品作用 | 当前状态 |
|---|---|---|
| STP Core | 协议、握手、会话、封包和状态机 | 已完成 v1.1 |
| STP Server Gateway | 服务端安全会话与数据交换网关 | 已完成 |
| Browser WASM SDK | 浏览器侧真实 πV9 加密与握手 | 已完成 |
| TypeScript SDK / Web Worker | Web 应用集成与后台线程处理 | 已完成 |
| Tauri Desktop Plugin | Windows 桌面应用接入 | 已完成 |
| Desktop Proxy | 桌面代理式接入 | 已完成 |
| License System | 分层授权与功能门控 | 已完成 |
| Android SDK | Android 原生绑定与 AAR | 产品路线图 |
| iOS SDK | Swift 绑定与 XCFramework | 产品路线图 |
五、V9 SDK 开发包
5.1 核心能力
V9 SDK 可用于构建:
- 数据加密与解密;
- 数据加密密钥生成和管理;
- ML-KEM 与混合 KEM 密钥封装;
- AES-256-GCM、ChaCha20-Poly1305 和 HMAC-SHA3 数据保护;
- 数字签名与验签;
- 安全数据包序列化与跨端传递;
- 敏感密钥材料生命周期管理;
- 审计记录与完整性验证;
- Rust、C ABI、FFI 和 WebAssembly 等集成路径;
- 商业授权、功能门控和项目化交付。
5.2 为什么企业需要 SDK 产品
单独获得算法库并不等于获得可上线的安全产品。企业仍需组织数据包和算法元数据,设计密钥生成、封装、轮换和擦除,处理多语言兼容、错误、版本和安全测试。
V9 SDK 的商业价值在于缩短从密码算法到业务产品之间的工程距离。
5.3 SDK 交付形态
| 交付形态 | 适用对象 | 说明 |
|---|---|---|
| Rust Core Library | 高性能服务端、安全产品和系统软件 | 直接集成核心密码能力 |
| WebAssembly Binding | 浏览器和 Web 应用 | 在浏览器侧执行真实加密逻辑 |
| C ABI / FFI | C/C++、桌面端和跨语言场景 | 通过稳定接口接入原生能力 |
| Python Binding | 数据处理、自动化和服务集成 | 根据项目版本和平台提供 |
| 项目定制绑定 | Java、Kotlin、Swift、.NET 等 | 按项目范围评估和交付 |
| 源码授权 | OEM、安全审计和深度定制客户 | 依据商业协议和授权范围提供 |
> 具体平台、构建产物、发布渠道及交付形态,根据客户需求与双方确认的项目范围提供。
5.4 SDK 标准接入流程
| 阶段 | 客户与合作伙伴工作 | πV9 交付与支持 | 验收输出 |
|---|---|---|---|
| 1. 范围确认 | 明确平台、语言、部署方式、数据类型、并发和授权边界 | 提供能力矩阵与适配建议 | 经双方确认的接口、平台和授权清单 |
| 2. 包与环境准备 | 配置构建链、依赖、可信身份公钥和测试环境 | 提供约定 SDK 包、校验信息、快速入门和示例 | 包完整性与环境检查通过 |
| 3. 初始化 | 在应用生命周期中初始化核心、配置版本和授权 | 提供初始化接口与错误处理说明 | 可查询版本、能力和授权状态 |
| 4. 会话接入 | 将握手接入现有登录、API 或连接流程 | 提供 SecureLink 客户端、网关或绑定接口 | v1.1 身份验签和会话建立通过 |
| 5. 数据路径改造 | 在业务请求发送前加密,响应交付业务前解密 | 提供安全封包、序列化和线程模型指导 | 真实业务载荷往返通过 |
| 6. 异常与轮换 | 处理过期、重放、版本不匹配、限流和重新握手 | 提供错误分类与轮换策略 | 失败路径不泄露明文或敏感材料 |
| 7. 联合测试 | 执行功能、跨端、篡改、恢复和性能基线测试 | 提供测试清单、问题定位和版本说明 | 双方确认的测试与验收记录 |
| 8. 发布运维 | 固化版本、升级、回滚、审计和授权运营流程 | 提供发布包、变更记录和维护支持 | 可部署、可升级、可回滚的交付基线 |
SDK 接入不应只覆盖“调用加密函数”。正式接入还应明确密钥和会话由谁创建、可信身份公钥如何分发、错误如何映射到业务、日志中哪些字段允许记录、线程与 Web Worker 如何隔离、版本不兼容如何阻断、授权到期如何恢复,以及升级失败如何回滚。
5.5 多端接入结构
- 浏览器与 Web 应用:由 WebAssembly Binding 执行真实核心逻辑,TypeScript SDK 负责业务友好接口;计算密集操作可放入 Web Worker,避免阻塞界面线程。
- Windows 桌面应用:可通过 Tauri Desktop Plugin 将统一核心接入应用命令层,也可通过 Desktop Proxy 在较少改动业务代码的前提下完成代理式接入。
- 服务端和系统软件:Rust Core Library 适合直接集成;C ABI / FFI 适合 C/C++ 或其他原生宿主。
- 自动化和服务集成:Python Binding 是否提供以及提供范围,以对应项目版本和交付清单为准。
- 移动端和其他语言:Java、Kotlin、Swift、.NET 等移动端及其他语言绑定根据产品版本与项目范围评估交付。
5.6 SDK 接口与运维边界
SDK 输出应保持版本化安全数据包和明确错误类型,不要求业务层理解底层密钥材料。业务系统负责用户身份、业务权限、数据分类和调用时机;SDK 负责约定范围内的密码处理、会话状态、安全封包和敏感材料生命周期。部署团队负责可信公钥分发、配置保护、授权文件保管、升级回滚与运行监控。三方边界需在项目设计和验收清单中写明。
六、技术可信度与工程成熟度
6.1 统一 Rust 核心
πV9 采用 Rust 作为主要密码工程实现语言,利用所有权模型、类型系统和内存安全能力降低常见内存错误风险。Server、WASM、Tauri 和 Proxy 共享同一核心,减少多端重复实现造成的差异。
6.2 已验证基线
截至 2026 年 8 月,V9 SecureLink v1.1 已完成:
- 193 项 Rust 测试通过;
- 11 项 WASM Node 测试通过;
- 33 项真实 WASM HTTP 端到端测试通过;
- WASM 发布构建验证通过;
- Rust 静态代码检查通过;
- 覆盖正确身份、错误固定公钥、缺失固定公钥、签名篡改、KEM 降级、finished proof 篡改、重放、跨会话、过期会话、密文篡改和真实加密往返。
上述结果为 V9 SecureLink v1.1 的版本测试记录,不等同于第三方安全认证。正式项目可根据客户要求安排独立审计、渗透测试和合规评估。
6.3 标准与合规表述
产品采用或参考的公开标准包括 NIST FIPS 203(ML-KEM)、FIPS 204(ML-DSA)、AES、SHA-3、HKDF 和 IETF ChaCha20-Poly1305 等。
“采用标准化算法”不等于“已获得某项产品认证”。πV9 可以为客户的后量子迁移、密码敏捷和数据保护建设提供技术基础,具体合规结论应结合部署环境、管理制度及第三方评估确定。
七、典型应用场景
7.1 金融、支付与数字资产
保护交易指令、账户数据、支付接口和长期敏感记录;为金融科技平台增加应用层数据保护和后量子迁移能力。
7.2 政企数据交换
面向跨部门、跨组织和专网系统的数据交换,通过私有化部署、离线授权和项目定制形成自主可控的交付体系。
7.3 医疗与健康数据
保护具有长期隐私价值的病历、检验、影像索引和机构间接口数据。
7.4 企业 API 与 SaaS
在现有 HTTPS API 之上增加独立加密载荷,适用于客户资料、业务指令、商业秘密和多租户敏感数据。
7.5 即时通讯与协同办公
为消息、文件元数据、会话指令和企业协作数据提供统一加密能力,并支持桌面与 Web 产品集成。
7.6 安全厂商与系统集成商
通过 V9 SDK、STP Core、OEM 授权和联合交付,将 πV9 能力集成到零信任、SASE、安全网关、数据防泄漏或行业平台中。
7.7 工业与物联网
适用于需要长期安全生命周期的设备通信和工业数据。具体嵌入式平台、资源约束和绑定形式按项目评估。
八、客户商业价值
8.1 保护既有技术投资
V9 SecureLink 不要求客户替换 TLS 和整个网络体系,可在现有架构上分阶段接入,降低一次性迁移风险。
8.2 缩短上市周期
客户无需从零组建完整密码工程团队,即可获得协议、SDK、网关、测试、授权和文档体系。
8.3 增加产品差异化
软件厂商可以将抗量子数据保护作为企业版、高安全版或行业专版能力,形成新的授权与服务收入。
8.4 降低长期维护成本
统一核心、清晰接口和版本化协议,减少多平台分别维护密码逻辑的成本,并为后续算法升级保留空间。
8.5 支持自主部署
根据授权和项目范围,产品可支持企业内网、离线环境、私有化部署及受控升级,帮助客户掌握关键安全能力。
九、合作伙伴价值
合作伙伴不仅可以采购产品,还可以与 πV9 形成联合市场和联合交付关系:
- 将 V9 SecureLink 纳入现有网络安全或行业解决方案;
- 使用 V9 SDK 为自有产品增加加密模块;
- 获得 OEM、白标或区域合作授权;
- 面向终端客户开展 PoC、实施、培训和维护;
- 联合参与大型企业、政企和行业项目;
- 基于终端、平台、项目或年度授权形成持续收入;
- 通过定制绑定、接口适配和安全服务形成增值收入。
πV9 提供产品能力、技术支持和升级路线;合作伙伴发挥行业关系、场景理解、集成和交付优势,共同降低客户采用新安全技术的门槛。
十、商业模式
10.1 可选合作模式
| 模式 | 主要内容 | 适用对象 |
|---|---|---|
| 项目授权 | 按项目、系统或部署范围授权 | 单一业务系统和专项建设 |
| 企业年度授权 | 持续升级、维护和技术支持 | 中大型企业和平台客户 |
| SDK 商业授权 | 按产品、平台、终端或开发范围授权 | 软件厂商和开发团队 |
| OEM/白标授权 | 集成到合作伙伴品牌和产品 | 安全厂商、设备厂商、ISV |
| 私有化交付 | 内网部署、离线授权、受控升级 | 政企、金融、医疗等客户 |
| 技术服务 | PoC、集成、定制、培训、安全评估 | 有复杂系统和交付需求的客户 |
| 联合解决方案 | 联合品牌、联合销售、联合投标与交付 | 渠道伙伴和系统集成商 |
具体商务报价根据部署规模、平台范围、终端数量、源码权限、服务等级和定制需求确定。
10.2 授权边界
V9 SecureLink 与 V9 SDK 是两个独立产品,具有各自的授权范围。客户可按需求分别采购,也可获得组合授权。源码访问权、二次分发权、OEM 权利和品牌使用权需在商业协议中单独约定。
十一、交付体系
标准或项目化交付可包括:
- 产品软件包与授权文件;
- V9 SecureLink Server、WASM、Tauri 或 Proxy 组件;
- V9 SDK 开发包及约定的平台绑定;
- API 文档、快速入门、集成手册和示例代码;
- 部署、升级、回滚和密钥轮换操作手册;
- 测试结果、版本清单和交付验收表;
- PoC 支持、技术培训和联合调试;
- 维护期内的缺陷修复和版本升级;
- 可选的源码审计、定制开发和第三方评估支持。
十二、合作流程
十三、为什么选择 πV9
- 面向未来:围绕后量子迁移和长期数据安全进行产品设计;
- 双核心产品:既提供完整安全传输产品,也提供可嵌入式 SDK;
- 纵深防御:TLS 与应用层独立保护,多算法协同;
- 身份可信:v1.1 使用 ML-DSA-65 绑定完整握手上下文;
- 工程化交付:不仅提供算法,还提供协议、SDK、网关、授权和文档;
- 多端能力:Rust 核心、WASM、桌面插件和代理组件已形成闭环;
- 真实验证:具备 Rust、WASM 和 HTTP 端到端测试证据;
- 合作灵活:支持企业授权、私有化、OEM、白标和联合解决方案。
十四、产品概述与合作邀请
核心定位
产品概述
传统 TLS 主要保护网络传输通道,而企业还需要考虑数据本身的长期安全和未来后量子迁移。V9 SecureLink 在现有 TLS 之上增加独立的应用层加密与身份认证;V9 SDK 则让软件厂商可以把同一套加密能力嵌入自己的产品。两项产品可独立采购,也可组合交付,适用于企业 API、金融、政企、医疗、即时通讯和安全产品 OEM。
合作邀请
重要说明
- 本产品书用于介绍产品能力与合作方式,不披露密钥材料、客户部署拓扑、系统凭据或其他保密信息。
- 密码产品的安全性取决于算法、实现、配置、部署和管理的共同作用,不作无条件或绝对化安全承诺。
- 采用标准化算法不等同于已获得特定认证,认证与合规结论应以正式第三方评估为准。
- 规划能力、定制绑定和特定平台产物,以双方确认的项目范围与交付清单为准。
- 具体授权价格、源码权限、OEM 权利和服务等级,以正式商务协议为准。