密钥保密要求

这页只讲一件事：TiRTC 接入里两个最敏感的密钥，应该怎么保管、怎么使用、哪些事情不要做。

如果你已经看过名词解释，这里可以直接把重点收成一句话：

• secret_key 是应用级密钥
• device_secret_key 是设备级密钥
• 这两个值都属于敏感信息，都不应该泄露

哪两个密钥需要重点保护

secret_key

secret_key 是应用级密钥。

它通常由你的业务服务端持有，用于签名和鉴权。

device_secret_key

device_secret_key 是设备级密钥。

它和 device_id 一起描述一台设备的身份，也会参与设备相关的签名或校验。

这两个密钥分别应该放在哪里

secret_key 只应放在服务端

secret_key 不应出现在下面这些位置：

• 客户端工程源码
• 客户端安装包
• 前端页面脚本
• 调试截图、聊天记录、工单内容

如果你的客户端能直接读到 secret_key，就说明边界已经错了。

device_secret_key 应放在设备端和服务端的受控位置

device_secret_key 不应被当成普通配置到处传递。

它只应出现在真正需要它的地方，例如：

• 设备端初始化或上线所需的受控存储位置
• 服务端执行相关签名或校验时的受控存储位置

除这些必要场景外，不应再让其他代码、工具或排查流程随意接触它。

哪些事情不要做

下面这些做法都属于高风险误用：

• 把 secret_key 写进客户端代码或示例工程
• 把 device_secret_key 当成普通字符串打印到日志
• 在群聊、邮件、工单、截图里直接发送完整密钥
• 把完整的 device_id + device_secret_key 组合字符串（某些 API、CLI 或配置项里写作 license）当成一个可以随手分享的整体字符串
• 为了排查方便，把密钥写入本地配置文件并提交到仓库

尤其要注意最后一条：

某些 API、CLI 或配置项里虽然把这段组合字符串写作 license，但它本质上仍然是 device_id 和 device_secret_key 的组合，不意味着它可以被当成无风险信息整体传播。

推荐做法

日志里只打印必要标识，不打印密钥

如果你需要排查设备问题，可以打印：

• device_id
• remote_id
• 连接状态
• 错误码

不要打印：

• secret_key
• device_secret_key
• 完整的 device_id + device_secret_key 组合字符串（某些 API、CLI 或配置项里写作 license）
• 可直接复用的完整 token

排查时默认做脱敏

如果必须展示相关字段，只展示排查需要的最小信息。

例如：

• 只展示前几位和后几位
• 只展示 device_id，不展示 device_secret_key
• 只说明“签名失败”或“凭证不匹配”，不要把原始密钥输出出来

权限按职责拆开

客户端、设备端、服务端只接触自己真正需要的那部分信息：

• 客户端主要接触 remote_id 和 token
• 设备端在必要场景接触 device_secret_key
• 服务端在必要场景接触 secret_key 和 device_secret_key

不要为了省事，把所有敏感字段一次性塞给所有端。

如果已经泄露了怎么办

如果你怀疑 secret_key 或 device_secret_key 已经泄露，应该优先做这几件事：

1. 先停止继续传播相关内容
2. 立刻确认泄露范围：代码仓库、日志、聊天记录、截图、工单
3. 按你的安全流程执行密钥轮换或重新下发
4. 回收或清理历史泄露副本
5. 检查文档、示例和排查脚本里是否还在继续暴露这些字段

相关文档

• 名词解释
• 连接