> ## 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 ブラウザは非常に敵対的な環境であり、cookie、session、拡張機能の sandbox など、どれだけ対策をしても完全とは言えません。

攻撃者は XSS や悪意ある拡張機能を通じて任意のコードを注入できる可能性があります。そのため、ブラウザウォレットに大きな資産を保管することは推奨されず、日常的な少額利用向けであるべきです。そして **Session Keys は burner wallet ではない** という点を明確に理解することが重要です。

それでも、現在の web3 の大半は Web ブラウザ上にあり、ユーザーも主にブラウザ経由で dApp とやり取りしています。今の制約を前提に、私たちはそれに合わせて設計し、別の手段で安全性を**強化**していく必要があります。

1. 一時的な signer で実行できる範囲を大幅に制限し、強く文脈依存・用途依存にします。
2. これは web2 の典型的なクライアントサーバー構成における JWT の扱い方に近い考え方です。
3. たとえば Facebook、Twitter、銀行サイトなどの session や JWT token も同じ問題にさらされる可能性があります。一般的な対策は、**token で実行できることの範囲を制限**し、**賢い失効システム**を用意し、疑わしい操作には 2FA を追加することです。
4. 私たちも同様のモデルでスコープを制限しており、範囲外利用のような悪意あるトランザクションを検知した時点で侵害された token を失効できるインテリジェントな revocation system の追加も進めています。**資金損失における絶対的な最悪ケースは、ガス代のために top up された 0.01 SOL です。**
5. また、**現時点でも開発者は octane のような gasless relay と組み合わせ、`topUp` を `false` に設定することで回避策を取れます**。ただし、SDK から直接シームレスに扱う方法はまだなく、これは現在ロードマップに入っています。