← Cuadernos Lacre

コンセプト · 2026年5月23日

24の言葉:暗号学的アイデンティティとは何か

暗号学的アイデンティティはパスワードではありません。いかなるサーバーもそれを保存せず、復元も不可能です。BIP39メカニズムの解説、なぜ正確に24単語なのか、そしてそれを保持する者に課せられる真の重みについて。

パスワードとアイデンティティの違い

古典的なインターネットのモデルにおいて、パスワードはアイデンティティの証明である。ユーザーは名前、メールアドレス、顧客番号などのアイデンティティを持ち、自分がその人物であることをサーバーに証明するために、サーバーが保存している指紋と照合するためのパスワードを提示する。指紋が一致すれば、サーバーはセッションを許可する。パスワードを紛失しても、ユーザーは同じユーザーであり続ける。失われたのは証明書であり、それを復旧するための手続き(登録したアドレスへのメール送信、秘密の質問など)が存在する。

暗号化アイデンティティの仕組みは異なる。それは何よりもまず、それ自体で完結した数学的秘密であり、誰かが保存された指紋と照合するような認証情報ではない。紙の上、デバイス内、あるいは他人のサーバー上など、どこに存在するかは関係ない。アイデンティティは検証する者の有無ではなく、その数学的性質によって存在する。ここには、「SHA-256とは実際には何か」で見たものと似た特性が現れる。所有は秘密を提示することではなく、署名に使用することで証明される。そうして生成された署名は、秘密自体を知る必要もなく、第三者の仲介もなしに、秘密から数学的に派生した公開値を使って誰でも検証できる。秘密を持つ者がアイデンティティであり、それを失った者はアイデンティティでなくなる。この宣告は断固としている。アイデンティティを返してくれと頼める相手は誰もいない。そもそもそれを持っていた相手が存在しないからだ。

24の言葉が表すもの

暗号学的アイデンティティは通常、32バイト(256ビット)の数学的秘密で表されます。これは覚えるのが難しく、間違いなく書き写すのはさらに困難な数字です。暗号業界は2013年、BIP39という小さくエレガントな標準によってこの問題を解決しました。これは、256ビットを2048単語の公式リストから選ばれた24の言葉のシーケンスとして表現する方法です。その背後にある算術は見事に合致しています。詳細を知りたい方は、補足説明をご覧ください。

この計算は単なる飾りではありません。もし誰かが23単語を正しく書き写し、24単語目で間違えた場合、チェックサムがそれを検出し、ソフトウェアは「このシーケンスは無効です」と告げます。24単語すべてを正しく書き写せば、ソフトウェアは曖昧さなく同じアイデンティティを導き出します。単語リストの選択も意図的です。BIP39の単語は短く、互いに明確に異なり、アクセント記号もなく、音声的・綴り上の混乱を最小限に抑えるよう選ばれています。これは、人間が間違いなく記憶し、書き、読み上げられるように設計された語彙なのです。

フレーズから鍵へ

24個の単語は、メッセージに署名する暗号鍵そのものではありません。これらは元のエントロピーを復元可能な形で表現したものであり、PBKDF2と呼ばれる決定論的なプロセスを通じて、64バイトのシード(種)に変換されます。そのシードから、同じく決定論的に、ユーザーが使用する具体的な暗号鍵が導出されます。署名用の秘密鍵と、署名を検証するために公開される対応する公開鍵です。異なるシステムでも同じメカニズムが使われています。暗号資産(仮想通貨)ではsecp256k1曲線が使われ、Signalプロトコルや多くの現代的なシステムではCurve25519曲線上のEd25519が使われています。Ed25519のような特定の曲線の場合、BIP32やSLIP-0010といった標準規格が、その64バイトのシードを受け取り、決定論的に有効な署名鍵を構成する32バイトを導出します。これは、次のセクションのコード例が始まるのと同じ32バイトです。

これは業界全体がユーザーにメカニズムを提示する標準的な方法です。暗号資産ウォレット、分散型アイデンティティ管理、恒久的なアイデンティティ部分におけるSignal、そしてSolo2もその一つです。実務上、ユーザーがシードや導出された鍵を直接目にすることはありません。ユーザーはアイデンティティを作成する際に24個の単語を確認し、オプションでそれを紙に書き留めます。その後、アイデンティティを移行したいときに、それらの単語はデバイス間を移動します。新しいアプリに単語を入力すると、アプリは同じシード、同じ鍵、同じアイデンティティを導出します。これはポータブルで暗号学的に堅牢であり、合理的な範囲で記憶可能なメカニズムです。

鍵で署名する方法(Zigによる一筆)

Zigでは、24個の単語から導出された32バイトのシードがあれば、Ed25519によるメッセージへの署名はわずか数行で記述できます。

const std = @import("std");
const Ed25519 = std.crypto.sign.Ed25519;

// 'semilla' son los 32 bytes derivados de las 24 palabras.
const par = Ed25519.KeyPair.create(semilla);

// Firmar un mensaje con la clave privada:
const mensaje = "Este mensaje lo escribí yo.";
const firma = try par.sign(mensaje, null);

// Cualquiera con la clave pública del par puede verificar:
try Ed25519.Signature.verify(firma, mensaje, par.public_key);

署名操作は「署名」と呼ばれる64バイトを生成します。これは対応する秘密鍵からしか生成できません。検証は公開されています。公開鍵を持つ人なら誰でも、署名がメッセージに対応しているかを確認できます。秘密鍵がなければ、そのメッセージに対して有効な署名を作成することは誰にもできません。公開鍵があれば、署名が有効かどうかを誰もが検知できます。この非対称性こそが、秘密を共有することなく、署名者が作成者であることを証明できる理由です。

前の例はマニュアルの最小構成版です。Solo2の実際のコードでは、このチェーンは2つのファイルを通過します。1つはユーザーのブラウザ上で動作し24語の単語からエントロピーを再構築するJavaScriptファイル、もう1つは zcatcrypto ライブラリ内のZigファイルで、そのエントロピーを受け取って具体的な暗号鍵を導出します。ブラウザ側から見ていきましょう:

// solo2/web-app/js/lib/bip39.js
async function mnemonicToEntropy(mnemonic, lang) {
    const validation = await validateMnemonic(mnemonic, lang);
    if (!validation.valid) {
        return { entropy: null, valid: false, error: validation.error };
    }
    const wordlist = WORDLISTS[lang || 'en'];
    const words = mnemonic.trim().split(/\s+/);

    // Cada palabra aporta 11 bits (su índice en la lista de 2048).
    let bits = '';
    for (let i = 0; i < words.length; i++) {
        bits += wordlist.indexOf(words[i]).toString(2).padStart(11, '0');
    }

    // 24 palabras = 264 bits. Los primeros 256 son la entropía.
    const entropyBytes = new Uint8Array(32);
    for (let j = 0; j < 32; j++) {
        entropyBytes[j] = parseInt(bits.slice(j * 8, (j + 1) * 8), 2);
    }
    return { entropy: entropyBytes, valid: true };
}

その32バイトのエントロピーは、同じステップで導出された別の32バイトと共に、Ed25519鍵そのものを生成するZigのWebAssemblyモジュールへと送られます。最終的なメモリクリーニングを含む関数全体は、1つの画面に収まります:

// zcatcrypto/wasm/bindings/identity.zig
const Ed25519 = std.crypto.sign.Ed25519;
const X25519  = std.crypto.dh.X25519;

export fn identity_generate() ?*IdentityHandle {
    var seed: [64]u8 = undefined;
    if (!common.getRandomBytes(&seed)) return null;

    const handle = common.wasm_allocator.create(IdentityHandle) catch return null;

    // Bytes 0..31: semilla determinista del par Ed25519 (firma).
    const sign_kp = Ed25519.KeyPair.generateDeterministic(seed[0..32].*) catch {
        common.wasm_allocator.destroy(handle);
        return null;
    };
    handle.sign_secret = sign_kp.secret_key.toBytes();
    handle.sign_public = sign_kp.public_key.toBytes();

    // Bytes 32..63: secreto X25519 (para acordar claves de cifrado con el otro).
    handle.exchange_secret = seed[32..64].*;
    handle.exchange_public = X25519.recoverPublicKey(handle.exchange_secret) catch {
        common.wasm_allocator.destroy(handle);
        return null;
    };

    @memset(&seed, 0);  // Borra la semilla de la memoria.
    return handle;
}

注目すべき点が2つあります。1つ目は、同じシード(seed)からは常に同じ鍵ペアが生成されるということです。まさにこれによって、新しいデバイスで24語の単語を入力することでアイデンティティを回復できるのです。2つ目は、シードが関数の最後の行でメモリから明示的に消去されることです。その時点を過ぎると、関数自体でさえ鍵を再構築することはできません。ユーザーの単語だけが唯一のソースとなります。

ここで少し立ち止まる必要があります。チェーン全体をざっと見ただけでは、三羽烏の別のプリミティブであるハッシュと混同される可能性があるからです。ハッシュではありません。ハッシュは圧縮を行うユニークな関数です(多くのバイトが入力され、短い足跡が出力され、そこで道は終わります)。暗号アイデンティティは、数学的に補完し合うペアです。秘密は手元に残って署名し、それに対応する公開部分は公開されて検証されます。ハッシュが情報を一方向に崩壊させるのに対し、アイデンティティは2つの半分の間に非対称性を確立します。ハッシュは何が言われたかを証明し、アイデンティティは誰が言ったかを証明します。

フレーズではないもの

よくある3つの誤解を解いておく必要があります。第一に、フレーズは本来の意味でのパスワードではありません。サーバーに保存された指紋と比較されるのではなく、ユーザーのデバイスに入力されてアイデンティティを数学的に再構築するために使われます。第二に、フレーズは「復旧」できません。紛失しても、発行元に問い合わせることはできません。複製されれば、アイデンティティも複製されます。第三に、フレーズはアイデンティティから切り離せる認証情報ではありません。フレーズこそがアイデンティティなのです。それを持つ者は、追加の許可も、認証プロセスも、復旧の可能性もなく、そのアイデンティティとして振る舞うことができます。

この3つ目の特性こそが、事態の重みを変えるものである。パスワードの紛失は管理上の面倒事である。暗号化アイデンティティの紛失は、アイデンティティの喪失である。フレーズが書かれた紙を第三者に見つけられることは、アカウント盗難のリスクではない。それはアイデンティティ全体の引き渡しである。誰もあなたのアイデンティティを剥奪したり、恣意的にブロックしたりできないというシステムの約束には、他の誰も代わって復旧できないものの唯一の管理者であるという責任が不可分に伴う。

約束と重み

暗号アイデンティティのモデルは、しばしば自己主権型(英語ではself-sovereign)と呼ばれます。この言葉の選択は意図的なものであり、その状態を極めて正確に表しています。ユーザーは、ほぼ中世的な意味で自分のアイデンティティの主権者です。いかなる王も、発行者も、中央当局もそれを授けることはなく、またそれを取り消すこともできません。しかし、中世の君主と同様に、ユーザーは自分の過ちの結果をすべて背負います。印章を紛失した際、代わりに決定を下してくれる摂政は存在しません。

第三者が管理するアイデンティティと自己主権型アイデンティティのどちらを選ぶべきか、という問いに唯一の正解はありません。重要でないフォーラムのアカウントであれば、管理されたアイデンティティはおそらくリスクに見合っています。しかし、法的に拘束力のある文書に署名する専門的なアイデンティティや、個人の貯蓄を守る経済的なアイデンティティ、機密情報を預けているクライアントとの専門的なコミュニケーションのアイデンティティとなれば、話は別です。そこでは「便利かどうか」という問いは消え、「自分の代わりに振る舞う権限を自分以外に誰が持っているのか、そしてそれはどのような状況においてか」という問いに変わります。

実際のシステムでこのメカニズムが使われている場所

BIP39は2013年にBitcoinの世界で誕生し、暗号通貨エコシステム全体に急速に広がりました。現在、信頼できるウォレットであれば、所有者の経済的アイデンティティのバックアップとして、12語または24語のBIP39フレーズを受け入れます。暗号通貨以外でも、仲介者なしで著作者を証明する暗号ペアという同様の基本概念は、異なる構文を持つ他のシステムにも現れています。システム管理者がサーバーにアクセスするために使用するSSHキーはその典型的な例です。管理者が自分のマシンに保管する秘密鍵と、各サーバーにコピーされる公開鍵があり、中央集権的なサービスに相当するものは介在しません。Signalプロトコルはデバイス上の永続的な鍵素材にEd25519を使用し、欧州のeIDAS(適格署名部分)も同様の暗号原理に基づいています。ただし、鍵はユーザーではなく適格信頼サービスプロバイダーによって保管されるという点が異なります。

本誌の出版プラットフォームであるSolo2は、各ユーザーのアイデンティティとして24語のBIP39フレーズを使用しています。ユーザーはアカウント作成時に一度だけその言葉を目にします。それらはSolo2のサーバーや他の誰のサーバーにも保存されません。ユーザーがそれらをメモして保管すれば、自身のアイデンティティを永遠に保持できます。紛失すれば、それまでです。これは中間にオペレーターが存在しないアーキテクチャの論理的な帰結です。もしSolo2が紛失したユーザーにアイデンティティを返せるとしたら、Solo2に圧力をかける誰かにそれを渡すこともできてしまうからです。

官房なき印章

中世の君主は印章を通じて統治したが、印章だけで統治したわけではない。その背後には官房があり、記録を付ける書記がおり、偽造を見破り、紛失または盗難された印章が残した疑念を、証人と制度的記憶によって再構築できる宮廷があった。今日、24の言葉を保管する者は印章を持っているだけで、他には何も持っていない。紛争を解決したり、失われたものを回復したりできる官房も、書記も、制度的記憶もない。引き出しの中の折りたたまれた紙、刻まれた金属板、公証人役場に預けられた封をされた封筒は、一個人の道具を使って独自の官房を作り出そうとする、職人的で必然的に不完全な試みにすぎない。

官房を持たない王は、官房を持つ王と全く同じように統治する。ただし、印章を失う日までは。そしてその日、彼は統治することをやめ、訴え出るべき相手は誰もいなくなる。


この記事は、ハッシュ、暗号化、アイデンティティという、このサイクルを開始した概念のトリオを締めくくるものです。これら3つのアイデアは互いに積み重なっています。ハッシュは不変の指紋を与え、暗号化は信頼できる第三者なしで機密性を与え、アイデンティティは付与する第三者なしで著作者を与えます。これら3つは、イデオロギー적ではない共通の特性を共有しています。それは、伝統的にオペレーター側にあった技術的能力を、サービス管理者から利用者に移転させるということです。それとともに責任も移転されます。これら3つのいずれかについて誠実に語るには、他の2つについても語る必要があります。

参考文献および関連資料

  • Palatinus, M.; Rusnak, P.; Voisine, A.; Bowe, S. — BIP-0039: Mnemonic code for generating deterministic keys, 2013年のBitcoin改善提案。暗号業界におけるリカバリフレーズの事実上の標準。
  • RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA), Ed25519を含む。IETF, 2017年1月。現代の業界の大部分で使用されている署名スキームの規範的仕様。
  • RFC 2898 — PKCS #5: Password-Based Cryptography Specification, バージョン 2.0。IETF, 2000年9月。フレーズからシードへのBIP39派生で使用されるPBKDF2アルゴリズムを定義。
  • 規則 (EU) 910/2014 (eIDAS) および規則 (EU) 2024/1183 (eIDAS 2) によるその進化 — 電子アイデンティティおよび適格署名のための欧州の枠組み。自己主権型とは異なる制度だが、概念的には同じ暗号プリミティブに支えられている。
  • Allen, C. — The Path to Self-Sovereign Identity (2016)。自己主権型モデルの原則とコミットメントに関する標準的なテキスト。以前のものだが、現代のソリューション群を理解する上で重要。

最近の記事