製品 — Seal
Product — Seal
鍵ではなく、証明を送る。
秘密は端末から一歩も出ません。
サインインのとき、端末から出ていくのは鍵ではなく証明です。サーバーは鍵を受け取らず、保管もしません。どの鍵を使ったのかも、渡していません。
国際標準に対応しています
MCPA2Ax402W3C VC
@lemmaoracle/seal — v0.3.8
import * as seal from "@lemmaoracle/seal"; const { proof, publicSignals, nullifier } = await seal.prove({ secret: process.env.LEMMA_API_KEY, nonce: challengeNonce, }); // 鍵は端末に残る。送るのは proof だけ。
Unlinkable
同じ鍵でも、毎回ちがう印が押されます。
Seal が出すのは、鍵そのものでも鍵のハッシュでもなく、そのセッションだけの値（nullifier）です。サインインのたびに値が変わるため、証明を並べても同じ人のものだと突き合わせられません。
Session 01
0x4c1e…9ab3
Session 02
0xd07a…21f6
Session 03
0x91b4…5c08
同じ鍵から生成した3回分です。3つの値の間に、たどれる関係はありません。
（サインイン先のサービスは、受け取った証明を自分の登録済みの鍵と突き合わせて本人を確認します。）
What changes
保有を減らし、証明を増やす。
漏洩のほとんどは、本来保有する必要のなかったデータから起きます。Seal はそのデータを式から消します——サーバーから、ログから、AI エージェントのコンテキストから。
Seal なしでは
- API キーが AI エージェントのコンテキストに置かれ、ログやプロンプトインジェクションで露出する。
- サーバーが利用者の秘密を保管する。漏洩のたびに全員分が流出する。
- サインインの記録が、同じ利用者のものとして突き合わせられる。
Seal を使うと
- コンテキストに残るのは証明だけ。漏れて困るものがない。
- サーバーは鍵を保管しない。漏れるとしても、そのセッションの証明だけ。
- 証明はセッションごとに別の値になる。並べても関係がたどれない。
0
サーバーが保管する鍵の数保管されるのはハッシュだけで、鍵そのものは渡していません。
How it works
challenge → prove → verify。秘密は一度も動きません。
端末境界サーバー
01
Challenge
サーバーが使い捨ての識別子（nonce）を発行。
02
Prove
端末内で証明（proof）を生成。
※ 証明の生成はブラウザ内で完結。秘密鍵は端末から一歩も外に出ません。
03
Verify
サーバーが証明を検証し、本人を確認。
※ 鍵の受領・保管は一切不要です。
検証はオフチェーンで行われます（groth16-bn254-snarkjs）。チェーンには依存しません。