> ## Documentation Index
> Fetch the complete documentation index at: https://docs.magicblock.gg/llms.txt
> Use this file to discover all available pages before exploring further.

# 安全

> 密钥管理与安全模型

## **密钥管理** 

密钥管理是安全性中极其重要的一部分。不过需要注意的是，密钥管理的安全程度取决于平台。例如，能够访问本地 keystore/keychain 的移动应用通常会比 Web 浏览器安全得多。\
\
我们当前的客户端密钥管理主要运行在 Web 环境中。在这些限制条件下，我们已经在浏览器端采取了适当的安全措施。
\
临时 keypair 会被加密，并通过浏览器内数据库 IndexedDB 安全地存储在用户浏览器中。当用户发起操作，例如签名并发送交易时，会话令牌会使用这个临时 keypair 对交易签名。随后智能合约可以验证该交易，确认用户的钱包已经授权这个会话令牌。\\

1. 使用 `web3.Keypair.generate()` 生成一个随机 keypair
2. 生成一个随机加密密钥
3. 使用该加密密钥对生成的 keypair 进行加密
4. 将加密后的密钥存储到 IndexedDB 中

## 安全模型

1\. Session keys 类似于适配到 web3 场景中的 JWT Token

2\. 这些密钥具备过期时间和作用范围

3\. 一旦密钥过期，就不能再在目标程序中重复使用，必须重新生成新的会话令牌。

4\. 它们也被设计为可撤销的，因此在最坏情况下如果出现问题，攻击面也会被限制在临时 keypair 及其中包含的资产范围内，也就是 **0.01 SOL**

### 关于 IndexedDB 的说明

Web 浏览器是一个极具对抗性的环境，无论从 cookies、session 到浏览器扩展沙箱，单靠任何一种安全措施都不足以完全防御。

攻击者始终可能通过 XSS 或恶意扩展注入任意代码。这也是为什么我们不建议用户在浏览器钱包中存放大额资金，它更适合日常小额使用。这里必须明确一点：**Session Keys 不是 burner wallet。**

不过，今天大多数 web3 应用仍然运行在 Web 浏览器里，用户也主要通过浏览器与 dApp 交互。在当前约束下，我们必须围绕这些限制进行设计，并通过其他方式持续强化安全性。

1. 尽可能缩小临时签名者的能力范围，因为它们本身就高度依赖具体上下文和使用场景。
2. 这和 web2 典型客户端-服务器架构中对 JWT 的处理方式很相似。
3. 例如 Facebook、Twitter，甚至银行网站中的 session 或 JWT token 也可能面临类似问题。它们的做法是**限制 token 可执行的操作范围**，部署**智能撤销机制**，并在可疑活动中进一步引入 2FA。
4. 我们采用了类似的模型来控制范围，并且也在开发智能撤销系统，一旦检测到超范围使用等恶意交易，就能尽快撤销受损 token。**在资金损失方面的绝对最坏情况，是补充用于支付 gas 的那 0.01 SOL。**
5. 此外，**开发者今天也可以通过将其与像 octane 这样的 gasless relay 结合使用，并把 `topUp` 设为 `false` 来进一步规避风险**。不过，我们目前还没有在 SDK 中提供无缝的一体化方式，但这已经在路线图上。