supermagnum/galdralag-firmwareBaochip-1x 用の暗号フレームワーク。
このプロジェクトは Open Invention Network (OIN) に登録されています。OIN は防御的な特許プールです。メンバーは Linux 関連特許を相互ライセンスし、参加者が特許リスクを低減した状態でオープンソースソフトウェアを提供・利用できるようにします。
ステータス: 待機中: https://github.com/betrusted-io/xous-core/pull/937
Xous マイクロカーネル上で動作する Baochip-1x (Dabao 評価ボード) デバイス向けファームウェアで、
riscv32imac-unknown-none-elf 向けに構築されています。
ここにあります: https://www.baochip.com/
このデバイスは、Nitrokey クラスのデバイスと同じカテゴリのハードウェアセキュリティトークンであり、OpenPGP スマートカードクラスの動作と暗号化ボールトを備えています。ハードウェアスタック全体 — RTL、回路図、ブートローダー、OS — はオープンソースで監査可能です。
ハードウェア仕様、ブートモデル、要件テーブル、および ComboHash/PKE の使用方法は Supermagnum/Baochip-1x-firmware に文書化されています。Dabao 評価ボード (KiCad、回路図、スイッチ、ピン配置) は baochip/dabao にあります。フラッシュ用にブートローダーモードに入るには、SW2 を押して切り替えます（そのリポジトリの回路図を参照）。このリポジトリのアーキテクチャノート: docs/ARCHITECTURE.md。
Galdra ホストツールは、受信者（連絡先）のローカル SQLite ディレクトリを保持します。保存された各 ID には公開鍵素材と、オプションのサイドカーラベル（下の表を参照）が含まれます。これらのタグはホストデータベースに存在し、Galdra 鍵の場合はオンチップの連絡先ストア (crates/contact-store) にも存在します。これらは、自分で整合させない限り OpenPGP ユーザー ID に魔法のように結び付けられるわけではなく、帯域外で確認しない限り暗号的に保証されるわけでもありません。オプションの galdra keyserver push は、エクスポートされた公開鍵とともに JSON として重複するフィールドをプロジェクトレジストリに送信できます。トークン上のフィールドごとの来歴は、SelfAttested、HostVerified、RegistrySync、OobVerified を使用します（メタデータ比較 (GnuPG vs Galdra) と docs/RRAM_LAYOUT.md の連絡先ストアレイアウトを参照）。
ホスト側の詳細と CLI 動作: docs/GALDRA-TOOL.md。ワイヤーレイアウトとスロット数: crates/contact-store/src/layout.rs と docs/RRAM_LAYOUT.md。
このファームウェアは、Baochip-1x 用のハードウェアセキュリティトークンです: USB CCID 上のOpenPGP カードアプリケーションであり、デバイス上のボールト、PIN ポリシー、およびリポジトリ固有の機能（暗号プロファイル — 1 つのカスケードに最大 4 つの異なる対称暗号をスタックでき、それぞれが独自の導出鍵を持ちます。主要機能 を参照）、Shamir 関連フロー、実装されている場合の認証付き一時 ECDH、および Galdra ホストツールを備えています。主な相互運用ターゲットは、市場のすべてのトークンプロトコルではなく、GnuPG スタイルの OpenPGP カード使用です。
このファームウェアは、以下ではありません:
同じ制約に沿ったクレートレベルの除外は、docs/future-todo.md の 明示的に除外されたクレート にリストされています。
CESS: このファームウェアは、ツリー内に実装された規範的構成（Mode A 外部 AEAD、K_outer 用の HKDF-BLAKE3、バイト単位の GF(2^8) Shamir 分割を含む）について CESS に準拠しています。完全な整合性声明、逸脱レジスタ、および認証レベル（たとえば完全な固定レイヤー用の CESS-CORE）は、docs/CESS_CONFORMANCE.md と以下の CESS (関連するオープン標準) に文書化されています。
OpenPGP / CCID アプリケーションロジックは crates/usb-personality にあります。Xous では、CCID を公開する USB サービスは usb-bao1x（xous-core チェックアウト内）であり、フィーチャー ccid-openpgp でビルドされ、OpenPGP RRAM ウィンドウとプロビジョニングに crates/baochip-openpgp を使用します。レイアウト: docs/RRAM_LAYOUT.md。量産前のギャップ（オペレーター PIN UX、プラットフォームマップの承認）: 既知の制限 / 未完了の作業。
全体的な目標は、完全でテスト済みのオープンソースハードウェアセキュリティトークンファームウェアのままです: CCID 上の GnuPG 用の OpenPGP カードスタイルの動作（OpenPGP と GnuPG の互換性 を参照）に加えて、現在 OpenPGP カード標準で定義されていない追加のデバイス上機能 — 前方秘匿性を備えた一時 ECDH、Shamir K-of-N、暗号非依存プロファイル、microSD デコイボリューム — を 標準規格とファームウェア固有機能 にまとめています。すべてオープンな RTL と再現可能なブートローダー上で動作します。
サーバー、ファイアウォール、医薬品ボールト、または暗号化ボリュームのロック解除前に2 つの別々の物理トークン（または K-of-N シェア保持者）が必要な導入では、主要機能 の下の デュアルハードウェア鍵クォーラム（インテグレーターパターン） を参照してください。各デバイスは1 つの資格情報ソースです。クォーラムの強制はあなたのアクセスゲートウェイ、PAM レイヤー、またはパネルであり、このファームウェアではありません。
Baochip-1x 用の出荷可能なファームウェアは Ed25519 で署名されています。ファームウェアイメージを Ed25519 秘密鍵で署名します。GnuPG は Ed25519 署名サブキーを使用した gpg --sign でこれを行うことができます（通常の OpenPGP 分離署名ワークフローを、ビルドが出力するパッケージングに合わせて調整したもの）。SoC 内の不変の boot0 ROM は、次のステージ — boot1 — の実行が許可される前に、その署名をデバイスに焼き付けられた対応する公開鍵（およびブートチェーン用のより広範な鍵マニフェスト）に対して検証します。boot1 はその後、署名付きアプリケーションイメージ（たとえばブートローダーモードで USB マスストレージ経由で配信される UF2 ブロブ）をロードします。デフォルト部品には4 つのオンチップ Ed25519 公開鍵（コード展開、ベータ、開発者などの役割）が搭載されています。boot0 / boot1 は Baochip とサードパーティ製署名鍵の間の相互不信ポリシーを強制します。完全なブートフロー、UF2 配信、コンソール、boot1 更新、およびセキュリティモデル: xous-core の Getting Started with Baochip Targets。
すべてのテストがすべてのコマンドで実行されるわけではありません。それは意図的です。
xtask はデフォルトのワークスペーステストに含まれません: 一般的なレシピは cargo test --workspace --exclude xtask です。xtask はビルドオーケストレーションクレートだからです。そのテストが必要な場合は cargo test -p xtask を実行してください。#[ignore] とマークされたテスト: --ignored（および必要なクレートフィルター）を渡さない限りスキップされます。理由には、フォーカスされたユニットテストですでにカバーされているもの（例: ドロップ後のゼロ化）、遅いケース（例: RSA 鍵生成）、および接続されたデバイスやフィクスチャが必要な galdra などのホストツールのハードウェアまたはトークン依存フローが含まれます。test-all --no-fuzz: CI やクイック実行を短く保ち、そのステップにナイトリーツールチェーンを必要としないようにするため cargo-fuzz ステップをスキップします。--no-fuzz なしで cargo run -p xtask -- test-all を実行するか、ファズターゲットを個別に呼び出してください（fuzz/README.md を参照）。test-all --no-dudect: タイミングスイート（約 15〜20 分）をスキップします。PR の CI はこのフラグを使用します。タイミングゲートには または なしの を実行してください。週次 CI () は引き続き dudect を実行します。PR がクローズされたときに、これを使用してクレートの整合性を確認することもできます: https://github.com/rust-lang/cargo/issues/16850
ステータス: 実ハードウェア上での人間によるテストの準備ができています — 本番対応リリースは存在しません。 検証済みおよび監査済みの暗号クレートを使用して Rust で書かれています。 暗号プリミティブは監査済みのワークスペース依存関係からのみ取得されています。 ポスト量子アルゴリズムはフィーチャーゲートされており、独立監査待ちとマークされています。ポスト量子ステータス を参照してください。
注記: このプロジェクトの一部は AI 支援（Claude、Anthropic）で開発されました。 設計、暗号選択、およびセキュリティ決定は、専門の暗号学者によってレビューされていません。 これを実験的なプロジェクトとして扱い、独自の批判的判断を適用してください。本番導入の前に独立した専門家によるレビューを強く推奨します。
人間によるテストの準備ができています。このソフトウェアをビルドまたは実行するかどうかはあなたが決定します。ユニットテスト、ファジング、その他のチェックで見つかっていないバグがある可能性があります。実験にオプションの仮想マシンを使用すると、ホストシステムへのリスクが軽減されますが、完全に排除されるわけではありません。詳細な結果は テスト結果 (docs/TEST_RESULTS.md#run-metadata) にあります。技術用語の平易な定義 (A–Z): 用語集。
主開発者は計算障害に関連する神経学的状態を持っています。計算障害は数感覚と関連する記号的処理に影響を与え、彼らにとって従来のプログラミング — 手書きのコード編集を唯一のワークフローとする方法 — は、支援ツール（たとえば会話型 AI エディター）なしでは機能しません。その制約は正確性とは別のものです。レビュアーは、このページの他の場所で文書化されているように、テスト、ファジング、および独立監査を引き続き評価する必要があります。
Galdralag をレビューする暗号学者や真剣な実装者は、通常、散文を読む前に crates/vault/tests/ と crates/cipher-profile/tests/ を開きます。テストスイートが成果の証明です。それは、物語だけでは代替できないドメイン知識をコード化しています。
だからといって、その点を他の人から隠す理由にはなりません。調達のためにプロジェクトを評価している人、貢献するかどうかを決定している人、または暗号テスト方法論の深い訓練なしでコードを出荷している人は、具体的な証拠へのポインターを得る価値があります。確認すべき内容: 適合性テスト資料には、crates/vault/tests/rfc_vectors/ 配下のChaCha20-Poly1305に関するRFC 8439の実例、crates/vault/tests/data/wycheproof/ 配下のChaCha20-Poly1305およびBrainpool ECDH/ECDSAのエッジケースに関するWycheproof JSON（ベンダー提供）、crates/vault/tests/bsi_vectors/ 配下のBrainpoolP256r1およびP384r1に関するBSI TR-03111ベクター、crates/vault/tests/blake3_vectors.json 配下の公式BLAKE3リファレンスベクター（全35入力長、全3モード）、crates/vault/tests/twofish_vectors.json 配下のTwofish仕様ベクター（モンテカルロを含む1203ケース）、そして crates/cipher-profile/tests/fixtures/cascade_cess_kat.json 配下の、独立して検証された中間値を含むプロジェクト独自のCESSカスケードKATフィクスチャが含まれます。これらを合わせて、ランナーとレビュアーが cargo test --workspace および python3 scripts/verify_cascade_kats.py で実行できる真実の基準（ground truth）となります。
RFC 8439 は、インターネットの相互運用性の多くを標準化している組織であるInternet Engineering Task Force（IETF）によって発行されています。RFC（Request for Comments）は、プロトコルおよび多くの暗号仕様の一般的な形式です。RFC 8439は、ChaCha20-Poly1305認証付き暗号化を定義し（Daniel Bernsteinの設計に基づく）、特定の入力と期待される出力を含む具体的な実例を提供しているため、独立した実装が標準とバイト単位で一致するかを確認できます。広く複製されている平文 Ladies and Gentlemen of the class of '99: wear sunscreen で始まるものは、RFCの付録の例に登場します。コードがAEAD出力を正確に再現できれば、構築を正しく実装したことの強力な確認になります。これは、公式の解答キーの暗号版に相当します。ChaCha20-Poly1305は、このファームウェアのすべての多層カスケードプロファイルの内側の層であるため、このチェックは暗号スタック全体の基盤に位置します。
Wycheproof は、Googleのセキュリティチーム（2017年）によってリリースされたテストコーパスです。この名前は、オーストラリアのワイチプルーフ山（世界最小の山としてよく引用される）に由来します。これは、このプロジェクトが、整数オーバーフロー、境界ケース、不正な入力、改ざんされた認証タグといった、小さくとも致命的なハードルをクリアすることに焦点を当てているためです。これらは、実際に展開された暗号で繰り返し発生する障害です。これはRFCスタイルのベクターを補完します。RFC 8439スタイルの例は、公開されたAEADに対する正確性を示します。Wycheproofは、実装が歴史的に破損する箇所での堅牢性を重視します。このリポジトリでは、Wycheproof JSONはChaCha20-Poly1305、AES-GCM、HMAC、HKDF、X25519、Ed25519、RSA、およびBrainpool ECDH/ECDSAのバリアントをカバーしています。
BSI TR-03111 は、ドイツ連邦情報セキュリティ庁（Bundesamt fur Sicherheit in der Informationstechnik）によって発行された、楕円曲線暗号に関する技術ガイドラインです。バージョン2.10が現在の改訂版です。このファームウェアで使用されているBrainpool曲線（P256r1およびP384r1）はBSI標準で規定されているため、TR-03111はそのテストベクターの自然なリファレンスとなります。各曲線にはECDHおよびECDSAのカバレッジがあります。ECDSA署名はさらに、cryptography ライブラリを使用した独立したPython実装と照合されました。
BLAKE3リファレンスベクター は、BLAKE3仕様とともに著者によって公開された公式のテストコーパスです。これらは、0〜102400バイトの35の入力長をカバーしており、短い入力テストでは見えないすべての内部チャンクおよびツリーハッシュ境界条件を実行するように特別に選択されています。デフォルトハッシュ、キー付きハッシュ、derive-keyの3つのBLAKE3モードすべてがカバーされています。BLAKE3は、このファームウェア全体でHKDF鍵導出およびカスケード暗号プロファイルの層間整合性チェックに使用されています。境界カバレッジが重要なのは、BLAKE3のツリー構造が1024バイトを超えるとアクティブになるためです。
テストスイートはサプライチェーンに対する改ざん検出でもあります。 このファームウェアのすべての暗号プリミティブは、監査済みのRustCryptoクレートから提供されており、ツリー内で暗号が実装されることはありません。上記の適合性ベクターは、すべての cargo test --workspace でこれらのクレートに対して実行されるため、改ざんまたは置換された依存関係は、侵害されたコードが展開されたシステムに到達する前に、既知解テスト（KAT）の失敗を生成します。python3 scripts/verify_cascade_kats.py は、2番目の独立したパスを追加します。Python実装がカスケードKATフィクスチャ内の同じ中間値をチェックするため、誤った出力を生成する侵害されたRustツールチェーンでも、クロスチェックによって検出されます。これは、すべての内部操作の同等の検証にかなり多くの労力と専門ツールを必要とするCライブラリにバインドするよりも、はるかに強力なサプライチェーン整合性のストーリーです。
これらの主張が誤りかどうかを判断するのは、今や読者次第です。
USBポートに差し込みます。ホストの観点から、ファームウェアは暗号モードまたはカモフラージュモードを提示できます。暗号モードでは、コンピュータはスマートカードを認識します。GnuPGまたは互換性のあるOpenPGPスタック（GnuPGとは？）を、他のハードウェアセキュリティトークンと同じように使用します。トークンが機密の暗号操作を処理するため、秘密鍵が保護されていない状態でコンピュータ上に存在することはありません。カモフラージュモードでは、無害に見えるファイルを含む通常のリムーバブルストレージとして列挙できるため、一目見ただけでは実際の役割が明らかになりません。ストレージカモフラージュを参照してください。
GnuPG は GNU Privacy Guard の略です。これは、GNUプロジェクトによるOpenPGPの実装です。OpenPGPは、鍵管理と暗号的に保護されたメッセージのためのオープン標準です（PGPと同じ概念ファミリーですが、RFC 4880などの文書およびコミュニティ更新で規定されています）。通常、Linux、BSD、macOS、またはWindowsで gpg コマンドとして実行します。多くのグラフィカルなメールおよび鍵ユーティリティは、これを内部でラップしています。
人々はGnuPGを以下の目的で使用します：
gpg-agent がスマートカードまたはローカルキーストアから認証鍵を公開する場合のSSHログイン。GnuPGと暗号化ドライブ（LUKS）。 Linuxには、ドライブまたはパーティション全体を暗号化する組み込みの方法があり、LUKSと呼ばれます。ドライブが暗号化されると、キーを持たない人には無意味なノイズのように見えるため、紛失または盗難されたラップトップはファイルを渡しません。
通常、このようなドライブのロックを解除するには、パスワードを入力します。GnuPGを使用すると、代わりにトークンを使用できます。アイデアは簡単です。ドライブのロック解除キー自体が、トークンのキーでロックされています。ドライブを開きたいとき、トークンはそのロック解除キーを解読しますが、それはトークンが差し込まれ、PINを入力した場合のみです。トークンを抜くと、同じコンピュータでもドライブを開くことができません。
つまり、これはトークンを暗号化ドライブの物理キーに変えます。セットアップ（およびトークンを紛失した場合に備えたバックアップ手段の追加）は、Linux独自のディスクツールで行います。トークンは単にキーを保持します。複数の人でドライブのロック解除機能を共有し、一人ではできないようにしたい場合は、Shamir秘密分散とドライブ暗号化を参照してください。
デフォルトでは、GnuPGはキーを ~/.gnupg に保存します。OpenPGPスマートカードを使用すると、機密の秘密キーはカード上に存在します。scdaemon（GnuPGスイートの一部）はカードとCCID/USBで通信し、gpg はホスト上でOpenPGPパケットを組み立て続けます。
使用用途。 暗号モードでは、トークンは他のOpenPGPスマートカードと同じ作業を目的としています。メールとファイルの署名と復号、認証（たとえば、通常どおり gpg-agent を使用する場合のSSH）、および長期的な秘密鍵を入力するマシンから離して保持することです。組織はこれをトークン上のShamirシェアと組み合わせて、単一の人物が秘密全体を保持しないようにできます（以下で詳しく説明）。GnuPGはホスト上の主要な相互運用性ターゲットです。このファームウェアは、CCIDを介してOpenPGPカードアプリケーションを実装しており、scdaemon がこれを駆動します（gpg --card-status、gpg --card-edit、およびカード上のキーを使用した通常の暗号化/署名/復号）。同じスマートカードプロトコルを話す他のソフトウェアも動作する可能性があります。コマンド、スロット、アルゴリズム、および現在の統合制限は、OpenPGPおよびGnuPG互換性にあります。NFCがハードウェアで起動された場合（計画中の統合 — ファームウェアにはまだありません）、同じデバイスクラスが物理アクセスをサポートできます。ドア、ゲート、またはロックパネルのNFCリーダーにタップすると、暗号チェック後にのみロックを解除するポリシーに参加できます（展開に応じて、PIN、生体認証、またはShamirスタイルのクォーラムと組み合わせられることがよくあります）。リーダーとパネル向けのPN532指向のスケッチは、docs/NFC_PN532_INTEGRATION.mdにあります。
これが短いバージョンです。これが、遭遇したかもしれない他のトークンと異なる点です。
ストレージカモフラージュ。 デバイスは通常のリムーバブルストレージとして動作できるため、一目見ただけでは実際の役割が明らかになりません。一般的なコンピュータに差し込むと、通常のUSBドライブまたはSDバックアップボリュームのように表示されます。可視のファイルシステムを、もっともらしい日常的なファイル（たとえば、休暇の写真）で満たすことができるため、カジュアルな閲覧はストレージのみであるという印象を強化します。これにより、机やチェックポイントでの表面的な検査を妨げます。実際にはセキュリティトークンであることを理解するには、通常、差し込むだけでなく、筐体を分解する必要があります。
キーはデバイス上に残ります。 メールに署名したり、ファイルを復号したりするとき、秘密鍵はトークンから離れることはありません。コンピュータはデータを送信し、トークンが作業を行い、結果が返されます。コンピュータを侵害した攻撃者は、有用なものを何も得られません。
トークンが盗まれても、過去のセッションは安全です。 ほとんどのハードウェアトークンは、鍵合意に長期的な秘密鍵を直接使用します。これは、セッションごとに新しい使い捨て鍵ペアを生成し、長期的な鍵で署名して本物であることを証明し、実際の交換には使い捨てペアを使用します。何年も後に誰かがトークンを盗み、なんとか長期的な鍵を抽出したとしても、過去のセッションから何も復号できません。この特性は前方秘匿性と呼ばれ、ハードウェアトークンでは珍しいものです。
キーを複数の人に分割できます。 トークンは長期的なキーをN個のシェアに分割でき、再構築にはそれらのシェアのうち任意のK個が必要ですが、単一のシェア保持者は単独では何もできません。これはShamir秘密分散と呼ばれます。これは、単一の人物が一方的なアクセスを持つべきではない組織キー、またはシェアが別々の場所に保存されるバックアップ戦略として役立ちます。これもハードウェアトークンでは珍しいことです。
暗号化は多層です。 単一の暗号でデータを暗号化するのではなく、トークンはデータを複数の独立した暗号で順番に実行できます。たとえば、ChaCha20、次にSerpent、次にTwofishなどです。それぞれが個別に導出されたキーを使用します。将来、1つの暗号を破る画期的な進歩があっても、他の暗号は破られません。特定の組み合わせは暗号プロファイルと呼ばれ、状況に必要な注意の度合いに応じて、組み込みのプロファイルから選択できます。
私の個人的なお勧めは、BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3 です。これは組み込みの standard プロファイルです。一時鍵合意にはBSI Brainpool P-256曲線、対称暗号化にはChaCha20-Poly1305、鍵導出と層間整合性にはBLAKE3を使用します。高速で、十分にテストされ、バッテリーに優しく（ChaCha20-Poly1305はAESアクセラレーションのないハードウェアで効率的になるように設計されており、CPU時間とホストの消費電力を削減します。P-256はこのファームウェアの3つのBrainpool曲線の中で最小です）、NIST設計のプリミティブに依存しません。単一の暗号に対する将来の暗号解読の突破に対してより高いマージンが必要な場合、conservative プロファイルはその上にSerpent-256層を追加します。
アルゴリズムの選択は意図的です。 使用される暗号（ChaCha20-Poly1305、Serpent、Twofish、Camellia）はすべて、政府の標準化団体から独立して設計されました。AESおよびNISTスイートは意図的に除外されています。これは、単一の国の標準化プロセスから暗号的に独立したいユーザーおよび組織のための意識的な選択です。Camelliaは、EUのNESSIEプロジェクトと日本のCRYPTRECプログラムによって独立して評価され、RFC 3713およびISO/IEC 18033-3で規定されています。
間違ったPINは適切にロックアウトします。 トークンは、PINが正しいかどうかをチェックする前に、失敗したPIN試行をカウントします。つまり、試行中のクラッシュや電力損失を利用してカウンタをリセットすることはできません。間違った試行が多すぎると、トークンは機密資料をゼロ化します。
まだできないこと。 ハードウェアはまだありません。これは活発に開発中のファームウェアです。実際のUSBハードウェアとGnuPGを使用したエンドツーエンドのテストは、将来のマイルストーンです。NFCトランスポートとドアスタイルのアクセスリーダーは、ドキュメントでは統合ターゲットとして説明されており、出荷される動作ではありません。ドキュメントで説明されている生体認証の第3要素はまだ実装されていません。実際のハードウェアを必要とするいくつかのタイミングサイドチャネルテストは、デバイスが存在するまで完了できません。
Galdralagは、2種類の非対称キーを同時に扱うことができます。これらはデバイス上とホスト上で異なる質問に答え、同じ人物に属していても交換可能ではありません。OpenPGPおよびGnuPG互換性、Web of Trustとキーサインパーティー、Galdra連絡先メタデータ、およびメタデータ比較（GnuPG vs Galdra）のセクションでは、各スタックについて詳しく説明します。ここでは、日常的な用語での違いを示します。
GnuPGが生成および使用する意味でのOpenPGPキーは、裸の公開番号ではなく、構造化されたパケットです。プライマリキー、署名および暗号化用のサブキー、および1つ以上のユーザーID（通常は表示名とメールアドレス、たとえば Alice Example <[email protected]>）をバンドルします。他の人は、そのアイデンティティの主張が本物であると信じていることを示すために、それらのユーザーIDに署名できます。その社会的グラフは、このREADMEの後半のWeb of Trustとキーサインパーティーで説明されているWeb of Trustの基盤です。GaldralagがOpenPGPスマートカードとして動作するとき、秘密キー資料をチップ上に保持し、そこで署名と復号を実行します。公開キー、ユーザーID、および他者からの署名はホスト上に存在し、通常の方法でGnuPGによって管理されます。トークンはワイヤ上のOpenPGPメッセージ形式を変更しません。GnuPGはそれを他のOpenPGPカードと同様に扱います。
Galdraキーは、裸の非対称鍵ペアです。Ed25519、X25519、またはファームウェアがサポートするBrainpoolまたはNIST曲線のいずれかです。キーバイト自体にはアイデンティティの主張は一切含まれません。ユーザーIDパケットも、組み込まれたメールも、キー構造に添付されたWeb of Trust署名もありません。Galdraキーのアイデンティティは、ホストのSQLiteデータベースとオンチップの連絡先ストア内のキーの隣に保存されている連絡先レコードから得られ、フィンガープリントによってキーに結び付けられます。
以下の表は、アイデンティティおよび連絡先メタデータをフィールドごとに比較しています。OpenPGP / GnuPG列は、通常の証明書とユーザーIDから得られるものを説明します（同じディレクトリにOpenPGP公開キーを保存する場合のGaldraのオプションのホスト側連絡先行に加えて）。Galdraキー列は、運用上の連絡先の構造化されたサイドカーフィールドを説明します（完全なホストおよびオンチップの詳細はGaldra連絡先メタデータにあります）。ダッシュは、そのスタックにその項目の標準的な個別フィールドがないことを意味します。
OpenPGPは名前と電子メールを1つのユーザーID文字列にまとめます。コールサイン、DMR、または郵便フィールドを個別の機械可読なものとして提供しません。Galdraはこれらを名前付き列として保持するため、無線および運用チームは証明書テキストを解析せずに検索および表示できます。
BrainpoolP512r1を提供したファームウェアからアップグレードされたトークンは、GET DATAでP-512属性を返す場合があります。その場合、それらのスロットでのGnuPG操作は一般的なカードエラーで失敗します。galdra device status を実行するか（またはdocs/OPENPGP_CARD.mdを参照）、古いスロットを特定してください。削除の背景はCHANGELOG.mdにあります。
| PW1 / PW3 | 保存されない | チップ上のベリファイア（最小5文字、デフォルト3回試行） |
| カードホルダーDO（ログイン、言語、URLなど） | GnuPGによってキャッシュされる | オプション（DOごとに最大254バイト） |
カードアプリケーション3.4.1、CCID、およびGnuPGワークフロー：docs/OPENPGP_CARD.mdおよびOpenPGPおよびGnuPG互換性。Galdralagが対象とするコミュニティで重要となる識別情報（コールサイン、DMR ID、無線ネットワークの所属）は、OpenPGPユーザーIDに自然に収まる場所がありません。ユーザーIDは名前とメールアドレスを想定しています。LA5XYZ <[email protected]> DMR:2345678のようなものをユーザーID文字列に書き込むのは、非公式で構造化されておらず、標準的な方法では機械可読ではありません。Galdraキーは暗号素材をクリーンに保ち、運用上の識別情報を、ホストツールとオンチップストアがネイティブに理解するレコード形式に格納します。
実際には、単一のデバイスが両方の種類のキーを競合なく保持できます。OpenPGPカードアプリケーションは、標準のSIG、DEC、AUTスロットを通じてGnuPGにサービスを提供します。コンタクトストアは、運用作業用のGaldraキーを保持します。例えば、コールサインで無線コンタクトに暗号化する、DMR加入者IDに対してメッセージを検証する、バッジ番号で同僚を検索する、といった用途です。この2つの経路は互いに干渉しません。
ホスト上のGnuPGで管理されるOpenPGP証明書とオンチップのコンタクトストア内のGaldraキーの両方を誰かが持っている場合、それらは2つの別々のキーであり、2つの別々のフィンガープリントを持ちます。Galdraフィンガープリント（G:プレフィックスが付き、生の公開キーバイトからBLAKE3で導出）は、その人のGnuPG証明書のOpenPGP v4フィンガープリントとは同じ値ではありません。ホストツールとデバイスは、それらを独立したアイデンティティとして扱います。両方を確認せずに、一方のフィンガープリントが他方を意味するとは想定しないでください。
どちらのキータイプも、その周囲のラベルを自動的に保証するものではありません。OpenPGPユーザーIDは、他の誰かが署名するまで自己主張に過ぎません。Galdraコンタクトレコード内のコールサインやDMRフィールドは、そのソース（キーサーバーからの取得、手動入力、または自分自身で行った帯域外チェック）と同じだけ信頼できます。来歴ラベル（SelfAttested、HostVerified、RegistrySync、OobVerified）は、フィールドがどのように到着したかを記録します。それらは、気にかけているアイデンティティを実際に検証する作業を置き換えるものではありません。
このファームウェアはRustで書かれています。Rustは、CやC++と同等に高速で低レベルなシステムプログラミング言語ですが、安全性に対する根本的に異なるアプローチを採用しています。
すべての依存関係は、変更なしのアップストリーム（公開されたcrates.io）、ツリー内で変更またはベンダリング（固定コピーまたはワークスペースパッチ）、またはこのプロジェクトが作成（ファームウェア、ホスト、ツーリングクレート）として分類されます。完全なインベントリ、役割、依存関係グラフは、docs/CRATE_DEPENDENCIES.md にあります。
業界のコードベースにおけるセキュリティ関連バグの大部分は、メモリ安全性の欠如（バッファオーバーフロー、use-after-free、ヌル参照など）に起因します。MicrosoftのMSRCは、自社製品で対処されたCVEの約70%がこのカテゴリに該当すると繰り返し報告しています。ChromeチームもChromeについて同様の割合を公表しています。これらの数値はそれらのベンダーの製品を説明するものであり、すべてのファームウェアに適用される普遍的な法則ではありませんが、メモリ安全な言語が重要である理由を示しています。
安全なRust（デフォルト）では、借用チェッカーが、ガベージコレクションに依存せずに、コンパイル時にデータ競合と通常の未定義動作メモリエラーを排除します。Unsafe RustとCへのFFIは、依然としてメモリバグを引き起こす可能性があります。それらは小さく保ち、レビューする必要があります。
Rustのスライスに対する境界チェックと所有権ルールは、C/C++組み込みコードで一般的ないくつかのクラスの障害モードを削減します。
unsafeブロックは明示的である必要があります。レジスタ用のMMIOと生ポインタはそこに存在するため、レビュー担当者は監査対象をgrepできます（unsafeは誤ったMMIOを不可能にするわけではなく、局所化を容易にするだけです）。Rustは、それ自体ではフラッシュを消耗させるタイトループや、誤ったレジスタ値の選択などのロジックバグを止めません。これらは依然としてエンジニアリングとレビューの問題です。
このコードベースは、シークレットに対する一般的なRustパターンを適用します。これらはすべての型に対して自動的ではありません。
zeroize::Zeroize / ZeroizeOnDrop などの型は、ドロップ時にバッファをクリアします。呼び出し側がオプトインします。subtle::ConstantTimeEq**（および類似のもの）を使用します。通常の==は魔法のように定数時間になるわけではありません。Copyなしは、偶発的な複製を減らします。ドメイン分離は、個別の型とHKDFラベル**を使用します（暗号依存関係ポリシー）。catch_unwindまたはabort戦略を使用します。unsafe はソース内で明示的に記述する必要があり、手動レビューを絞り込みます。依存関係: このプロジェクトの暗号ポリシーは、監査済みのRustクレート（RustCryptoなど）を優先します。暗号依存関係ポリシーの表を参照してください。すべての依存関係が単一の傘下プロジェクトからのものではありません。完全なクレートリストと、各依存関係が変更なし、変更/ベンダリング、またはプロジェクト作成のいずれであるかについては、docs/CRATE_DEPENDENCIES.md を参照してください。
Rustは、デッドロック（例：順序を誤ったMutexロック）、ロジックバグ、誤ったプロトコル、悪いループによるフラッシュ消耗、物理攻撃（グリッチング、電力解析）、または誤ったイメージの正しいビルドによるリスクを排除しません。また、注意深いコーディングなしにすべてのハードウェアで定数時間実行を保証するものでもありません。これらの領域は、設計、レビュー、テスト、およびこのREADMEの他の場所で説明されているプロジェクトの暗号およびサプライチェーンの実践に依存します。
検証（テストとファジング）: 言語に加えて、このリポジトリはユニットテスト、統合テスト、dudectタイミングハーネス、およびlibFuzzer（cargo-fuzz）ターゲットを使用します。概要とマトリックスは**テスト結果にあります。記録された実行メタデータはdocs/TEST_RESULTS.md#run-metadataから始まります。テストの合格は、本番環境への準備や脆弱性の不在を証明するものではありません。リスクを狭めるだけです。ビルドやテストの実行が自分の環境で許容できるかどうかはあなたが判断します。仮想マシンはオプションですが、マシン上の爆発半径を制限**します。
主要なVMプラットフォームはどれでも適しています — VirtualBox（無料、オープンソース）、QEMU（無料、オープンソース、コマンドライン）、またはVMwareです。ビルド環境が最もよくサポートされているため、Linuxゲストが推奨されます。
QEMUとUbuntuでのクイックスタート:```bash
sudo apt install qemu-system-x86 # Debian/Ubuntu host
brew install qemu # macOS host
qemu-system-x86_64 -m 2G -cdrom ubuntu-24.04-live-server-amd64.iso
VM 内では、標準のビルド手順が適用されます。VM は各実験の前に**スナップショット**を取得でき、問題が発生した場合は**クリーンにロールバック**できます。
### リスク評価とデプロイ
**最終的に、このファームウェアを自分の環境にデプロイして安全かどうかは、ご自身のリスク評価、保護対象の機密性、デプロイ前に独立した第三者監査を待つかどうかに基づいて、ご自身だけが下せる判断です**。このプロジェクトは、その判断を自分で下すために必要なすべての情報を提供することを目的としています。
資産、脅威 **T1–T14**、明示的な非目標、Q2 検証ギャップの構造化リストは **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md)** にあります。
---
## 名前について
**Galdr** は、古ノルド語で口頭または歌唱による魔法の実践です。束縛、保護、または啓示に使われる呪文です。サガでは、言葉だけでなく、呪文を唱える行為そのものを指します。[Kragehul I lance shaft](https://en.wikipedia.org/wiki/Kragehul_I)、[Lindholm amulet](https://en.wikipedia.org/wiki/Lindholm_amulet)、[Vadstena bracteate](https://en.wikipedia.org/wiki/Vadstena_bracteate)、その他の古フサルクの出土品のように、魔法のルーン碑文を活性化するためにも使われることがあります。
**Galdralag** は galdr に使われる韻律形式です。構造化され、正確で、規則に縛られた詩であり、そのパターンが呪文の力の一部となります。接尾辞 *lag* は「法」または「パターン」に似ています。
**ルーン文字**は文字通り秘密の、符号化された知識であり、シャーマン的な用法は理解している者だけに知られていました。
---
## ドキュメント
**用語集:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) — **平易な言葉**で説明された用語（A–Z 順）。README や他のドキュメントが専門用語だらけに感じる場合は、ここから始めてください。
**デバッグ:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) — バックトレース、`cargo test` の絞り込み、`xtask` ショートカット、ファームウェアのトリプルチェック、ファジング、問題を報告する前に収集すべきもの。
**AI アシスタント（Claude、Cursor）:** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) — コーディングエージェント向けのプロジェクト指示。Cursor 固有のルール: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules)。
**全ファイルを閲覧:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**ハードウェア（USB ドングルおよび関連）:** 2 つの KiCad ツリー: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) — `dabao_v3c`（micro-SD **なし**の USB-A トークン）; および [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) — `dabao_v3c_sdcard`（micro-SD ホルダー**付き**の同じ基本レイアウト）、ガーバー、BOM、製造出力、[ピン配置ドキュメント](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md)。USB-A ドングル PCB レイアウト（最小トークン vs Pico フォーマット評価）は [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) に記載されています。
| ドキュメント | 説明 |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) | **USB ドングル** KiCad プロジェクト `dabao_v3c`（micro-SD なし）; ガーバー、BOM、製造出力; [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) を補完 |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) | **USB ドングル** KiCad プロジェクト `dabao_v3c_sdcard`（micro-SD ホルダー）; ガーバー、BOM、[docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md) の下のピン配置; [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) を補完 |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CODE_MAP.md) | ワークスペースの**関数およびモジュールインデックス**（行アンカー付きのファイルごとの `pub fn` / 型） |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CRATE_DEPENDENCIES.md) | **アップストリーム vs プロジェクト**の Rust クレートとそれらの依存関係 |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/API_REFERENCE.md) | コードマップ + IETF/I-D/GnuPG/Sequoia の**付録**: Shamir GF(256) 構築、GALDRA SHARE アーマー、一時 ECDH ワイヤーフォーマット、HKDF ラベル、プリイメージ; `galdrad` ルート; rustdoc ヒント |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/ARCHITECTURE.md) | 高レベルファームウェアアーキテクチャと主要サブシステム |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md) | プロファイル監査レコード（`cipher-profile`）、OpenPGP `OpenPgpAudit` フック; **追加専用 RRAM ログはまだ実装されていません** |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md) | 生体認証プレゲート: アーキテクチャ、ワイヤーフォーマット、ボールトレイアウト; 統合は部分的に実装済み |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_DEVICE_GUIDE.md) | 新しい生体認証ハードウェアバックエンドのサポートを追加する方法 |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_TESTING.md) | テスト方法論: ISO/IEC 30107-3 PAD メトリクス、データセット、実行方法 |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/FINGERVEIN_DEVICE.md) | ESP32-CAM オープン指静脈デバイス: ハードウェア、プロトコルスケッチ、生体検知 |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SWEET_PLATFORM_INTEGRATION.md) | sweet プラットフォームハンドスキャナー: ハードウェア、統合、生体検知、データセット |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) | ホストツール（`galdra`、`galdrad`、`galdra-gtk`）: ワークフロー、プロビジョニング、PIN ポリシー、運用動作 |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: WoT 指向の OpenPGP 公開鍵レジストリ（サーバーリポジトリと実装）。**公開レジストリインスタンスはまだ実行されていません**; 1 つが計画されています。**`galdra keyserver push`** / **`galdra keyserver fetch`** およびオプションの **`[keyserver]`** 設定はこのエコシステムを対象としています—[Web of Trust とキーサイニングパーティー](#web-of-trust-and-key-signing-parties)も参照してください。補足設計ノートは [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/server.md) に残っています。 |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) | 非技術読者向けの**平易な言葉の用語集**（A–Z）; 技術的な詳細はリンクされたドキュメントに残っています |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) | **Claude** / AI コーディングエージェント向けの指示; **Cursor** については [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules) を参照 |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRALAG_DEV_REFERENCE.md) | ツールチェーン、`xtask` コマンド、ファジングおよび暗号テストのエントリポイント |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/dev-ref.md) | ワークスペースレイアウト、クレート、HAL トレイト、USB/PSRAM 動作、セキュリティ不変条件 |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) | デバッグ: `RUST_BACKTRACE`、冗長ビルド、スコープ付きテスト、`xtask` レシピ、組み込みターゲットチェック、ファジングポインタ、OpenPGP ホストチェック |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md) | 鍵生成、インポート、エクスポートポリシー、ローテーション、ゼロ化、Shamir（`vault` / OpenPGP に反映） |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) | OpenPGP カードアプリケーション、GnuPG/CCID ホスト設定、鍵スロット、アルゴリズム、udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) | 暗号プロファイルシステムと設定 |
| [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md) | Shamir と OpenPGP 上のインテグレーター拡張パターンとしての 2 つ（または N 個）のハードウェア鍵クォーラム; ファームウェアでは強制されません |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILE_SECURITY.md) | セキュリティ考慮事項: 平文プロファイル識別子、トラフィック分析、BrainpoolP384r1 外部ラッパーの根拠、暗号化識別子、ワイルドカードプロパティ |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) | [CESS](https://github.com/Supermagnum/CESS/tree/main) 整合性: Mode A ワイヤーレイアウト、[ALGORITHM-REGISTRY.md — ルックアップテーブル](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table) からの `suite_id`、逸脱レジスタ（保持された AES/SHA-2 vs CESS-CORE）、ロードマップ |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess) | CESS Mode A: HKDF-BLAKE3（`derive_k_outer`、`hkdf_blake3`）、ChaCha 外部シール/オープン、`suite_id \|\| inner_blob` レイアウト; [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) を参照 |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/EPHEMERAL_SESSION.md) | 認証済み一時 ECDH セッションプロトコル |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS**（*Cryptologically Enchanted Shamir's Secret*）— 認証付き暗号化、パスワードベースのシェアラッピング、オプションのポスト量子ハイブリッド鍵交換を備えた閾値秘密分散のオープン仕様（規範テキストとテストベクトル）; このファームウェアとは別ですが、ここでの Shamir と暗号プロファイルと同じ設計領域にあります |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PQ_SIGNATURES.md) | ポスト量子ステートフル署名（XMSS、LMS/HSS）、機能ゲーティング |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/Psram.md) | オプションの microSD デコイボリュームと関連動作 |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) | **4,194,304 バイト**のオンチップ RRAM: ソースからのボールトオフセット、HAL マッピング、摩耗 / ゼロ化ノート |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#run-metadata) | **実行メタデータ**で開きます; パイプライン概要、ベクトル、dudect、cargo-fuzz（[セクション 6](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)）、鍵ライフサイクル |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) | トークン + PIN + オプションの生体認証: このリポジトリが実装するもの vs プレースホルダー; 脅威スケッチ |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md) | 脅威モデル: 資産、脅威 T1–T14、防御されるものとされないもの、Q2 ハードウェア待ちの未検証項目、監査ステータス |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PERFORMANCE.md) | パフォーマンスノート |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Q2 初回ハードウェアブリングアップ: `galdralag-service` を含むイメージ、libccid `1D50:6197`、ATR → `gpg --card-status` APDU、Dabao ラボ PIN（`dabao-ccid` 上の CDC ではない） |
| [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md) | xous-core に属する変更（Persona A ドキュメント、ATR ポリシー、cratespec ノート）; Galdralag はそのツリーにパッチを適用しません |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_VERIFICATION.md) | ハードウェアゼロ化: シミュレーション vs シリコン検証 |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_TEST.md) | ハードウェア指向のテストノート |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc、Rust オプション、ドアパッシブ vs USB パネル、Shamir と PIN によるクォーラム |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + SPI microSD をオプションのバルクストレージとして; PSRAM の BOM 代替 |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) | Dabao リファレンスから USB-A ドングル PCB を作る方法: Pico フォーマット評価はファームウェアブリングアップ用; これは最小トークンのために GPIO ヘッダーを取り除きます; KiCad、FreeCAD、5 V / 500 mA vs USB-C PD、QSPI PSRAM ルーティング |
同じパスは GitHub の [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) と [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware) で解決されます。
---
## OpenPGP と GnuPG の互換性
ファームウェアは **OpenPGP カードアプリケーション**を実装しています（[docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) でバージョン **3.4.1** として文書化）。これは GnuPG が **CCID/USB** 経由で **OpenPGP スマートカード**に対して駆動するのと同じクラスのデバイスです。ホストは通常のスマートカードスタック（`pcscd`、`ccid` ドライバー、GnuPG の `scdaemon`）を必要とします。任意の OpenPGP カードに使用するもの以外の**カスタムホスト側暗号ドライバー**は必要ありません。
**これがホストで可能にすること（デバイスが CCID リーダーとして表示されたら）:**
| 領域 | ノート |
|------|--------|
| **GnuPG ワークフロー** | `gpg --card-status`、`gpg --card-edit`、カード上の鍵を使用した暗号化/復号化と署名 |
| **SSH** | `enable-ssh-support` と通常の `SSH_AUTH_SOCK` 設定を備えた `gpg-agent` |
| **メールとファイル** | GnuPG を使用するクライアント（例: Thunderbird、Evolution、Kleopatra）と標準の `gpg` ファイル暗号化 |
| **その他のツール** | GnuPG と同じ方法で OpenPGP カード + CCID と通信するもの |
**鍵スロット（一般的なデフォルト）:** **SIG**（署名）、**DEC**（復号化 / ECDH）、**AUT**（認証、例: SSH）。スロットごとの運用アルゴリズムは Brainpool 曲線、NIST P-256/P-384、Ed25519 / X25519 です。RSA アルゴリズム属性は PUT DATA で保存できますが、GENERATE、PSO:CDS、PSO:DECIPHER はすべて RSA 設定スロットで失敗します。完全なテーブルと `key-attr` 動作は [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) にあります。
**ここでの OpenPGP カード / GnuPG の対象外:** **WebAuthn / FIDO2** は異なるプロトコルであり、このカードアプリケーションの範囲外です（同じドキュメントを参照）。
**OpenPGP カード vs OpenPGP メッセージ:** **カード**仕様は、トークンが CCID 経由で PIN、鍵スロット、オンボード操作をどのように公開するかを定義します。**GnuPG** は `scdaemon` を通じてそれを使用します。ファイルとメールの **OpenPGP メッセージ形式**（RFC 4880 および後継）は**ホスト側**レイヤーです。カードが鍵を提供し、GnuPG は PC 上でメッセージ形式を適用します。カード仕様も RFC 4880 も **Shamir 分割**、**一時 ECDH セッション**、**暗号プロファイル**を定義していません — これらは[ファームウェア固有](#standards-vs-firmware-specific-features)です。
**統合ステータス:** OpenPGP と CCID ロジックは **`usb-personality`**、**`baochip-openpgp`**、および Xous の **`usb-bao1x`** サービスにあります（**`feature/usb-bao1x-ccid-openpgp`** の **xous-core** を参照）。オプションの **`galdralag-service`**（`services/galdralag`）は **CCID** IPC のために **`usb-bao1x`** に接続し、**XfrBlock** APDU に応答します; Dabao イメージは cratespec 経由でそれを必要とします（`scripts/build_dabao_ccid_image.sh`）。BaoSec は **PDDB** を **RRAM** にブリッジする場合があります。詳細: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md)。メモリレイアウト: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md)。**実ハードウェアでのエンドツーエンド GnuPG** には、Galdralag を含む完全なイメージ、ホスト **libccid** による **`1D50:6197`** の認識、および[既知の制限 / 未完了の作業](#known-limitations--open-work)の項目がまだ必要です。
## トークンセッションと鍵エクスポート
**物理的な切断（アンプラグ）:** ホストは USB デバイスを失います; 進行中の操作は、トークンが再度接続され再列挙されるまで失敗します。デバイス上では、OpenPGP **カードセッション**がクリアされます: **PIN 検証状態**は電源オフまたは取り外し後も存続しないため、他の OpenPGP スマートカードと同様に、再接続後は**署名、復号化、その他の保護された操作に VERIFY PIN が再度必要**になります。**秘密鍵マテリアルはシールされたボールトストレージにトークン上に残ります**; アンプラグは、別の**ゼロ化**またはワイプパスが実行されない限り、それを消去しません。
**デバイスから出る可能性があるもの:** 設計上、**公開鍵マテリアルのみ**が USB リンクを越えることが許可されています（例: OpenPGP **公開**鍵パケットと、カード仕様がホストに公開する関連データ）。**秘密**鍵、生の秘密スカラー、シールされた鍵ブロブは、通常のファームウェアパスを通じてデバイスから**出ません**; 秘密鍵操作は**トークン上で**実行されます。ホストは、標準コマンドが要求する場合に**暗号結果**（署名、カード支援復号化ワークフローの復号化された平文）を受け取りますが、秘密鍵のポータブルコピーは受け取りません。
**デバイスへの鍵のインポート:** トークンに**公開鍵**をインポートすることも可能です（例: トラストアンカー、ピア証明書、オンデバイス検証用の OpenPGP 公開パケット）。ファームウェアの**ボールト**は、非秘密マテリアル用の**公開鍵スロット**を提供します（`crates/vault/src/public_key_vault.rs`）。これらのスロットをロードするためのホストツールは、統合が成熟するにつれて [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) に記載されています。
---
## Web of Trust とキーサイニングパーティー
OpenPGP と **GnuPG** は分散型トラストモデル—**web of trust**—を使用して、誰がどの鍵を所有しているか、特定の**公開鍵**に依存すべきかを検証するのに役立てます。そのモデルは完全に**ホスト側**です。[ドイツの eID と Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys) などのチップバックの証明が利用できないか不適切な場合、それは通常の分散型代替手段（**キーサイニングパーティー**、証明書への署名）です; それらが**利用可能な**場合、両方のアプローチが補完的なパスとして共存できます。
**Galdralag フィンガープリント（`G:`）:** 対面検証ワークフローのために、**Galdra** はトークンの **SIG** 公開鍵から導出された**デバイスバインド**フィンガープリント（**BLAKE3-160**、`G:` プレフィックス）を表示できます。これは OpenPGP v4 証明書フィンガープリントでは**ありません**。アクティブな**暗号プロファイル**が **`ephemeral_ecdh: false`** の場合に**のみ**利用可能です; 組み込みプロファイルはデフォルトで **`ephemeral_ecdh: true`** であるため、通常は **`galdra profile add ... --no-ephemeral-ecdh`** でユーザープロファイルを追加して、**WoT** スタイルのホスト署名とともにこの識別子を必要とするワークフローに使用します。平易な言葉の定義と形式仕様: [Galdralag フィンガープリント](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md#g)。ライフサイクル、ローテーションポリシー、一時 ECDH ゲート: [KEY_LIFECYCLE.md — Galdralag フィンガープリント](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host)。
### Galdralag フィンガープリントの取得
ホストは**常に `G:` で始まる**文字列を出力します（SIG 公開鍵バイト上の BLAKE3-160、正規形式でプレフィックス後の**小文字 16 進 40 文字**）。
1. ホストに **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md)** をインストールし、**PC/SC** が動作することを確認します（**`pcscd`**、**`libpcsclite`**）。これによりツールがトークンと CCID で通信できます（[ホストツールのコンパイルとインストール](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)を参照）。
2. トークンを接続します（ワークフローで必要な場合はロック解除します）。
3. **`ephemeral_ecdh: false`** の**暗号プロファイル**を選択します。**`galdra profile show <name>`** で確認します（`ephemeral_ecdh: off`）。デフォルトのプロファイル名 **`standard`** は通常 **`ephemeral_ecdh: on`** です; 必要に応じて **`galdra profile add <name> ... --no-ephemeral-ecdh`** で作成します。
4. 実行します:```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>
機械可読な出力: galdra --emit json identity fingerprint（任意で --profile <name>）。
OpenPGP準拠の実装には、鍵の所有権の検証を支援するための証明書審査スキームが含まれており、その動作は信頼の輪と呼ばれています。OpenPGP 証明書（1つ以上の公開鍵と所有者/ユーザーID情報）は、他のユーザーによってデジタル署名されることができ、それによりその公開鍵と証明書に記載された人物または組織との関連性を承認します。
gpg --full-generate-key を使って生成したもの、またはOpenPGP対応トークンに格納したもの）。鍵署名パーティーとは、参加者が鍵のフィンガープリントを交換し、お互いの身元を確認した上で、後日証明書に署名する対面の会合です。
典型的な特徴:
これにより社会的グラフが生まれます。アリスがボブを信頼し、ボブがチャーリーの鍵に署名した場合、アリスは信頼の深さとポリシーに応じてチャーリーの鍵を信頼することを選択できます。
このようなイベントが重要な理由:
パーティーでは通常、身元交換中にコンピューターの使用を避けます。これにより、攻撃者が共有マシンに置き換えられた鍵やマルウェアを紛れ込ませる機会が減ります。
イベント前。 フィンガープリント（公開鍵から導出されたハッシュベースのダイジェストで、確実に比較できるほど短いもの）を計算して記録します。主催者が特に指定しない限り、この段階で紙に完全な鍵を交換することに依存しないでください。```bash
gpg --fingerprint YOUR_KEY_ID
紙または別の耐久性のある媒体にフィンガープリントを持参します（形状例: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`）。
**イベント当日（フィンガープリントのみ）。** **フィンガープリント**を交換し、IDを確認し、どのフィンガープリントがどの確認済みの人物に属するかを記録します。各参加者の申告された身元が確認済みの書類と一致することを確認します。
**イベント後。** **キーサーバー**または直接配布から完全な**公開鍵**を取得し、ダウンロードした鍵が紙に記録された**フィンガープリント**と一致することを確認し、検証した鍵に**署名**し、必要に応じて**アップロード**して他の人が利用できるようにします。
### イベントでは完全な鍵ではなくフィンガープリントを使用
- **運用上のセキュリティ。** イベント中に任意のマシンを信頼するのではなく、検証済みのフィンガープリントに基づいて置換攻撃を防ぎます。
- **シンプルさ。** フィンガープリントは紙に収まり、読み上げや比較が迅速に行えます。
- **検証。** ダウンロード後、フィンガープリントを再計算することで、エンドツーエンドの整合性を確認できます。
### キーサーバー
**キーサーバー**は、**公開**OpenPGP鍵（および署名や失効などの更新）を保存・複製するネットワーク型リポジトリです。**ユーザーID**、**鍵ID**、または**フィンガープリント**で鍵を検索可能にし、ウェブ・オブ・トラストの広域配布を支えます。
原則的な動作:
- **分散複製。** 同期メッシュに参加するサーバーへのアップロードは、多くの場合ピアに伝播します（従来の**SKS**スタイルのプールはこのように動作しました）。
- **同期。** 新しい鍵、署名、失効証明書は、各サーバーのポリシーと接続状況に応じて広がります。
- **公開読み取りアクセス。** **公開**情報のみが公開を目的としています。**秘密鍵**は決してアップロードしてはなりません。
**プライバシー。** 公開された鍵は**ユーザーID**（多くの場合メールアドレスを含む）を公開します。アップロードは多くのサーバーで**公開かつ長期保存**されるものとして扱ってください。鍵を廃止する必要がある場合は**失効証明書**をアップロードしてください。ポリシーは運営者によって異なります（[keys.openpgp.org](https://keys.openpgp.org/)は従来のプールとは異なります）。
**ピアトポロジー。** サーバー間の関係グラフは[spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/)で確認できます。SKS系のピア一覧は[spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers)にあります。
### キーサーバーの使用```bash
# Upload your signed key (after local signing)
gpg --send-keys YOUR_KEY_ID
# Search by mail or name (behaviour depends on keyserver configured in gpg.conf)
gpg --search-keys [email protected]
# Refresh imported keys from configured keyservers
gpg --refresh-keys
| サーバー | 備考 |
|---|---|
| keys.openpgp.org | 広く利用されている。メールに紐づくユーザーIDに対する同意ベースの検証を提供 |
| pgp.mit.edu | MITが運営するサーバー。歴史的にSKS時代のメッシュと関連 |
| pool.sks-keyservers.net | 旧SKSエコシステムに紐づくレガシープールのホスト名。現在の接続性は変動あり |
gpg --refresh-keys を実行する。galdra profile show <name> を実行し、ephemeral_ecdh: false であることを確認する。gpg の権威ある動作、信頼モデル、配布オプションについては、GnuPG マニュアルおよび上流のドキュメントを参照のこと。
Fulla プロジェクト（GitHub上のSupermagnum/Fulla）は、WoT準拠のレジストリサーバー実装をホストしている: 貢献者の公開鍵に加え、オプションのアマチュア無線ラベル、郵便のヒント、organisation（JSONスペル）、role、note、badge_number、phone_number、およびGaldra連絡先メタデータに整合する関連カラムを保存するための実装と進化する仕様。galdra keyserver push は POST /api/v1/keys JSON（armored_public_key、email、およびCLIフラグを渡した場合のオプションフィールドを含む）を送信する。galdra keyserver fetch と [keyserver] 設定スタンザは、その方向性に沿って galdra / に実装されている。。公開運用されるサービスは将来期待されている。追加の歴史的な設計文書は にある。
このプロジェクトの異なる部分は、異なる標準規格に整合している。GnuPG相互運用性は、OpenPGPカードアプリケーションとCCIDが定義する範囲に限定される。その他の機能はファームウェア（場合によってはGaldraホストツール）に実装されているが、標準の gpg カードワークフローを通じて呼び出すことはできない。
日常的なカード動作については、docs/OPENPGP_CARD.md を参照のこと。ボールト専用またはトークン固有の機能については、このリポジトリのファームウェアとGaldraツールのドキュメントを使用すること。
OpenPGPカードとGnuPGスタックは、鍵やディスクのロック解除のためのShamirの秘密分散（SSS）を定義していない。SSSは通常の暗号化と併用しても有用である: ディスク上の対称暗号を置き換えることはほとんどなく、その暗号化をロック解除する小さな秘密（マスターキーまたはパスフレーズ）を保護する。
パターン（常に同じ考え方）:
1. LUKS（Linux）と外部SSS
LUKS はマスターキーでボリュームを暗号化する。そのキー（または手順に応じてキースロットの秘密）を抽出し、SSSツールで分割し、シェアを別々に保存できる。ロック解除時には、K個のシェアを結合し、キー素材を再構成して、cryptsetup に供給する（ディストリビューションのドキュメントを参照。キーの取り扱いを誤るとアクセス不能になる可能性がある）。
ssss（"Shamir's Secret Sharing Scheme"）ユーティリティを使用した例の形（名前とパッケージはOSによって異なる）:```bash
ssss-split -t 3 -n 5 < luks_master.key
ssss-combine -t 3 | cryptsetup luksOpen /dev/sdX vault
**2. HashiCorp Vault**
[Vault](https://www.hashicorp.com/products/vault) は**アンシール**にShamirを使用します。ストレージ暗号化キーは初期化時に分割され（例：5人のオペレーターのうち3人がそれぞれシェアを保持）、再起動後は**K**個のシェアを入力してアンシールする必要があります。これはLUKSと同じ**マスターシークレットに対するK-of-N**パターンで、ブロックデバイスではなくシークレットエンジンに適用されます。
**3. Galdralagファームウェア（`vsss-rs`）**
このリポジトリは、デバイス上のShamirに[`vsss-rs`](https://crates.io/crates/vsss-rs)（RustCryptoエコシステム）を使用しています。バルク暗号化と組み合わせる場合も、同じ**レイヤリング**が適用されます：
- ランダムな256ビット（または適切なサイズ）のマスターキーを生成します。
- そのキーを使用して、ドライブまたはバルクストアを**AES-GCM**または**ChaCha20-Poly1305**で暗号化します（これはワークスペースの監査済み対称暗号クレートと一致します）。
- `vsss-rs`を使用して、マスターキーをしきい値**K**の**N**個のシェアに分割します。
- シェアをボールトスロット、他のデバイス、またはキーホルダーに保存します。
- 起動時またはリカバリ時に、**K**個のシェアを収集して再構築し、必要に応じて**HKDF**（またはポリシー）を使用してドメイン分離されたサブキーを生成します。
**4. VeraCrypt**
VeraCryptは内部でSSSを実装していません。同じ**外部**パターンが適用されます。SSSツールで**パスフレーズまたはキーファイルのマテリアル**を分割します。ボリュームの暗号文をShamir分割しようとしないでください。
### ハイブリッドパターン（大容量データ）
SSSは**小さなシークレット**（キーサイズ）向けです。数ギガバイトの暗号文にShamirを適用してはいけません。通常のレイヤリングは次のとおりです：```text
[Drive data]
encrypted by
[Symmetric master key, e.g. 32-byte AES-256]
split by SSS into
[Share 1] [Share 2] ... [Share N]
(each share may be wrapped with a recipient's PGP key, HSM, or offline media)
これは、このプロジェクトがすでに積み重ねているものと一致します。aes-gcm / chacha20poly1305 は保存データ用、vsss-rs はマスターシークレットの分割用、hkdf は再構築後の導出用です。
| 決定事項 | 一般的な選択肢 |
|---|---|
| しきい値 | 2-of-3（小規模チーム、ある程度の冗長性）; 3-of-5（組織で一般的） |
| シェアの保管 | ハードウェアトークン、別のマシン、紙、地理的に分散したサイト |
LUKSおよびフルディスク暗号化の運用上の鍵管理はセキュリティ上重要です。お使いの環境に応じて、ベンダーおよびディストリビューションのガイダンスと脅威モデルに従ってください。
2ハードウェア鍵 / クォーラム認可（重要な操作の前に2つの別々の物理トークンまたはシェア保持者を必要とする）は、サポートされている拡張パターンであり、ファームウェア機能ではありません。GaldralagはShamir K-of-Nプリミティブ（vault::shamir、galdra shamir）とシングルトークンのOpenPGP認証を提供します。ダウンストリームのLUKSラッパー、アクセスパネル、またはカスタムデーモンが、クォーラム、セッションウィンドウ、および安全な再構築を強制する必要があります。その境界、2-of-Nワークフローの参照、およびインテグレーター向けのセキュリティノートは、docs/DUAL_KEY_QUORUM.mdにあります。これは既存のプリミティブで今日可能です。オーケストレーションは意図的に消費者に委ねられています — このリポジトリからのロードマップ上のコミットメントではありません。
具体的なパターンの1つは、スタックで必要とされる場合にBrainpool曲線を使用して暗号化されたドライブまたはボリューム（たとえばマスターシークレットを中心としたECDH/ECDSA）と、その暗号化を解除する鍵素材に対するShamirの秘密分散を組み合わせたものです（上記の小シークレット階層化と同じ: SSSは鍵を保護し、ギガバイト単位の暗号文は保護しません）。そのワークフローを実装するファームウェアとホストソフトウェアが独立して監査された場合、そのような組み合わせは、クォーラムポリシーと国家暗号プロファイルの両方を同時に満たす必要がある組織にとって価値があります。
Brainpool曲線（例: BrainpoolP256r1、BrainpoolP384r1）がその文脈でしばしば議論される理由:
SSSとBrainpoolクラスの暗号を組み合わせることで制度的ニーズに対応するシナリオ（例示であり、法的またはコンプライアンス上の助言ではありません）:
GovernikusスタイルのOpenPGP署名または同等のチップベースの国家eID証明が、お住まいの法域またはワークフローで利用できないまたは実用的でない場合、Web of Trustと鍵署名パーティーでは、対面での検証と証明書への第三者署名に基づく代替のホスト側アプローチについて説明しています。
Governikus OpenPGP鍵認証は、BSI（ドイツ連邦情報セキュリティ庁）に代わって運営されるオンラインサービスです。提出者がドイツのeID対応IDカード、EU市民向けのEU eIDカード、または電子居住許可証で認証した後、サービスは認証された法的氏名がアップロードされた公開鍵のOpenPGP ユーザーIDと一致するかどうかを確認します。一致する場合、Governikusはその公開鍵にサービス署名鍵で署名し、第三者が証明を検証できるようにします。
このファームウェアでの実用的なワークフロー: トークン上でBrainpool非対称鍵を生成し（通常どおりOpenPGPカード生成）、公開鍵または証明書をホストにエクスポートし、eID認証（通常はAusweisAppとNFCカード読み取り）を含むGovernikus提出フローを完了し、サービスから返された署名済み公開鍵を使用します（たとえばメール配信から）。秘密鍵は常にGaldralag上に残ります。
どちらの経路も他方を置き換えるものではありません。eIDとGovernikusステップは、提出時に公開鍵をチップに対して検証された身元に結び付けます。これらは前方秘匿性、長期鍵素材のためのShamir K-of-N、またはバルクデータ用の暗号プロファイルを提供しません — これらはこのREADMEの他の場所で説明されているファームウェア固有の機能です。eIDチップとその周辺の発行プロセスも、それ自体ではトークンの一時的なECDHおよびカスケード動作を実装しません。逆に、デバイス上で生成されたBrainpool OpenPGP鍵は、Brainpoolの制度的利用で既に議論したBSI/EU展開コンテキストに適合しますが、外部の証明ステップがない場合、通信相手はフィンガープリントを法人に結び付けるために他の手段に依存する必要があります。
| レイヤー | 役割 |
|---|---|
| OpenPGP公開鍵（例: Galdralag上のBrainpool） | 暗号構造とトークン上の秘密鍵制御; 曲線の選択はBSI TR-03111クラスの期待に沿う（Brainpool機能行およびこれはAIスロップか?のTR-03111の議論を参照） |
| Governikus署名 | ユーザーがフローを完了したときに、証明書の氏名がチップ認証された身元と一致したことを確認 |
制限: 検証は氏名ベースです。サービスが比較するフィールドで2人が同じ法的氏名を共有する場合、証明はそれらを区別しません。これは証明時点でのその氏名への身元リンクを確認するものであり、グローバルな一意性ではありません。通常のOpenPGPの懸念事項（メールのバインド、鍵のロールオーバー、失効）は引き続き有効です。
ポリシーの整合性: Brainpool関連の技術ガイダンス（BSI TR-03111; crates/vault/tests/bsi_vectors/ の適合ベクトル）を定義するのと同じBSIが、Governikus eID署名プロセスも支援しており、これはBrainpoolがすでに要求または優先されているドイツおよびEUの設定でしばしば重要です — ShamirとBrainpool: 例と制度的適合性を参照してください。
より広い範囲（研究ノートであり、完成した調査ではありません）: OpenPGP公開鍵をチップ検証済みの身元にバインドする同じパターンは、国家eIDが存在する場所ならどこでも原則的に適用可能です。どのプロバイダーがGovernikusのような署名ステップを提供し、どのような規則の下で提供するかは、展開が拡大するにつれて調査する価値のある別の質問です。他のEU加盟国は、eIDASの下でカードベースのeIDエコシステムを運営しており、ドイツの経路単独よりも同等または強力なトラストアンカーをサポートする可能性があります。このREADMEはそれらをカタログ化していません。
エストニアとベルギーはどちらもBrainpoolではなくNIST P-384をオンチップで採用していますが、ドイツの公共部門BSIプロファイルはBrainpoolを中心としています（上記参照）。GaldralagはすでにOpenPGPカードでBrainpoolとNIST P-256/P-384をサポートしています（docs/OPENPGP_CARD.md）。このリポジトリのRSAはgaldr-vaultライブラリヘルパーであり、動作するカードスロットではありません（非対称 / 鍵合意）。同じトラストアンカーパターンは、ドイツの曲線の好みに一致することだけに依存するわけではありません。
EU/EEAの外では、カードベースのトラストアンカーパターンは適用が難しくなります。米国にはチップカード（PIV）がありますが、連邦職員に限定され、X.509/FPKIにあり、OpenPGPと統合されていません。カナダには上記の意味での国家レベルのオンチップ署名カードがありません。これにより、このパターンは主に普遍的に発行された政府チップ資格情報を持つ法域に限定されます — EU eIDAS地域が現在このモデルが最も強い場所です。
ハードウェアが消費者向けの状態に達した場合、Shamirの秘密分散と認証付き一時鍵交換を相互運用可能なOpenPGP / GnuPG動作の一部にしたい人々は（ファームウェア固有の機能だけでなく）、他の場所で標準と実装の変更を推進する必要があります。このリポジトリはIETFやGnuPGに代わって発言するものではありません。以下の場がそのような修正が通常追求される場所です。
CESS — Cryptologically Enchanted Shamir's Secret — は、しきい値秘密分散とともに、暗号非依存の認証付き暗号化、パスワードベースのシェアラッピング、およびオプションの耐量子ハイブリッド鍵交換のためのオープン暗号標準です。CESSリポジトリには、規範仕様、アルゴリズムレジストリ、テストベクトル、および適合性ランナーが含まれています。
このファームウェアは、ここで実装された構成についてCESSに適合します: 仕様の相互運用可能なシェアとエンベロープの規則は、このREADMEの他の場所で説明されている同じShamir、Brainpool、および暗号プロファイルのテーマと並んでいます。規範テキストはこのリポジトリとは別です。適合姿勢（仕様に一致するもの、プロファイル内でAESやSHA-256などのアルゴリズムを保持しながら異なるもの、およびより強力な相互運用性へのロードマップ）: docs/CESS_CONFORMANCE.md。
このGitHubリポジトリのメンテナーがイシュー、プルリクエスト、またはメールに応答しない場合でも、より広いエコシステムで新しい暗号、OpenPGP動作、および標準関連の作業を前進させることができます。Sequoia PGP は、独立したRustベースのOpenPGPスタック（メモリ安全性、ライブラリファーストの設計、活発なIETF/エコシステム参加）であり、多くの公開開発が行われています。これはこのプロジェクトではありません。ここでは、上流が沈黙している場合の実用的な代替経路として文書化されています。
Contributeページには、ライセンス（ほとんどのプロジェクトでLGPL 2.0以降）、Developer Certificate of Origin、およびより大きな商用機能には事前の合意と長期メンテナンスの取り決めが必要になる場合があることが記載されています — 多大な労力を投資する前にそのページを読んでください。
https://autocrypt2.org/#/ にも注目しておく価値があります。
このコードベースと関連アプリはmacOSまたはWindows用にコンパイルされません。 ホストツール（galdra、galdrad、galdra-gtk）およびサポートツールはLinuxをターゲットにしています。これは、この文書全体で述べられているプロジェクトの脅威モデルと監査可能性要件に基づく意図的な決定です。
_NSAKEY変数は大きな論争を引き起こしました。Microsoftはバックアップ鍵であると述べましたが、これはどちらの方向にも完全に証明されたことはありません。疑わしいが証明されていないもの:
main、restricted、universe、multiverseリポジトリのすべてのパッケージはCanonicalのGPG鍵で署名されています。security.ubuntu.comから提供されます。パッケージマネージャーは一般的に安全ですが、サードパーティの.deb / .rpm / AppImageインストールは安全でない可能性があります。信頼できるリポジトリからの署名付きパッケージを優先し、それ以外から取得したものはインストール前に署名を検証してください。
rust-toolchain.tomlで固定されている安定版Rustツールチェーンを使用してください。ファームウェアはriscv32imac-unknown-none-elfターゲットを使用し、ホストツールはホストトリプルを使用します。
test-hal が本番ビルドに漏れ込む場合は失敗します）： ```bash
cargo run -p xtask -- check-fw
オブジェクトコードとアーカイブは target/riscv32imac-unknown-none-elf/release/ に置かれます。特定のボード向けの完全な起動可能な Xous システムイメージは、その製品のビルドに従う場合、より広範な Baochip / Xous 統合フローによって生成されます。ここでの xtask は、xtask にリストされているファームウェアライブラリクレートに対して cargo build を実行します（それ自体は単一の書き込み可能なファイルではありません）。
Xous CCID デーモン（galdralag-service） — 上記のベアメタル riscv32imac-unknown-none-elf ファームウェアトリプルではなく、riscv32imac-unknown-xous-elf Xous ツールチェーンが必要です。
必要な xous-core ツリー: パス依存関係は Galdralag-firmware/xous-core/ を通じて解決されます。イメージビルドでは、ブランチ feature/usb-bao1x-ccid-openpgp（PR #937）上の兄弟チェックアウト（または XOUS_CORE=）を使用する必要があります。ネストされたツリーと兄弟ツリーは分岐する可能性があります。cargo run -p xtask -- check-xous-core は非ゼロで失敗し、コピー＆ペースト可能な ln -sfn <sibling> ./xous-core を出力します（./xous-core がまだシンボリックリンクでない場合は、まず実際のネストされたチェックアウトの名前を変更してください）。 ```bash
ln -sfn ../xous-core ./xous-core
cargo run -p xtask -- check-xous-core
Galdralag を含む Dabao CCID イメージ（単体の dabao-ccid はトランスポートのみです）： ```bash
scripts/build_dabao_ccid_image.sh
**BaoSec + PDDB:** **`cargo run -p xtask -- build-and-register release --xous-core /path/to/xous-core`**。詳細: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md)。アップストリームのみのギャップ: [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md)。
### フラッシュ
このリポジトリには、まだワンコマンドのフラッシャーは同梱されていません。**Baochip-1x** のプログラミング（JTAG、ROM/USBブート、またはベンダーツール）は、ボードおよびシリコンのドキュメントに従います。**[Supermagnum/Baochip-1x-firmware](https://github.com/Supermagnum/Baochip-1x-firmware)** から始めてください。**評価ボードのハードウェア**は **[baochip/dabao](https://github.com/baochip/dabao)** にあります — Dabao ボードでは、**SW2** が**ブートローダーモード**を切り替えます（その回路図を参照）。
**物理的なブートボタンなしで UF2 をコミットする:** **`loader.uf2`**、**`xous.uf2`**、**`apps.uf2`** を **BAOCHIP** ボリュームにコピーした後、物理的な**ブート**ボタンを押す**か**、**boot1** USB シリアルコンソール（1,000,000 ボー、例: `screen /dev/ttyACM0 1000000`）で **`boot`** と入力します。これにより、この手順のみ**ブート**ボタンに依存せずに済みます。**`boot`** と入力するとコンソールは**切断**されますが、これは**想定どおり**です（システムが次のステージに再起動します）。Linux では、`dmesg --follow` が USB の再列挙の確認に役立ちます。これは **PROG**（USB 接続中に押し続けて **BAOCHIP** マスストレージブートローダーに入る）とは異なります。**[baochip/dabao#2](https://github.com/baochip/dabao/issues/2)**（クローズ済み）を参照してください。
**Xous / Baochip フロー:** イメージは **Ed25519 署名**され、実行前に **boot0** によって検証されます。[署名付きファームウェア（Ed25519、boot0）](#signed-firmware-ed25519-boot0) を参照してください。**dabao** の **UF2** レイアウト、USB 接続中に **PROG** を押し続けてマスストレージモードに入る方法、および **boot1** の更新手順については、**[Getting Started with Baochip Targets](https://github.com/betrusted-io/xous-core/blob/dev/README-baochip.md)** を参照してください。
### ホストツールのコンパイルとインストール（`galdra`、`galdrad`、`galdra-gtk`）
ホストクレートはワークスペースのルートにあります: `galdra/`、`galdrad/`、`galdra-gtk/`。
**Ubuntu / Debian**（`cargo build` / `cargo install` の前にインストール）:```bash
sudo apt update
sudo apt install build-essential pkg-config libpcsclite-dev pcscd libssl-dev
# required only for `galdra-gtk`:
sudo apt install libgtk-4-dev
libpcsclite-dev は デフォルト の galdra PC/SC リンクパスを満たします。pcscd は実行時にスマートカードリーダーを提供するデーモンです。libssl-dev は openssl-sys がリンクできるようにするために必要です（sequoia-net のキーサーバー検索と ldap3 の TLS は現在 native-tls を使用します）。galdra-gtk をビルドしない場合は、libgtk-4-dev を省略してください。
GTK 4（galdra-gtk のみ）： pkg-config は gtk4（ワークスペースクレート gtk 0.9.x、パッケージ gtk4）を解決できる必要があります。Fedora では gtk4-devel、Arch では gtk4 を使用します。
| フィールド | 目的 | ホスト (galdra SQLite) | オンチップ連絡先ストア | 形式 / 制限 |
|---|
| 連絡先 ID | 安定したホスト主キー | あり | なし | テキスト (SQLite の id) |
| 表示名 | 人間が読めるラベル | あり | あり | UTF-8 文字列; チップ上のヒープフィールドあたり最大 240 バイト |
| 電子メール | 主なメールアドレス | あり | あり | UTF-8 文字列; 電子メールスキャンによるチップ上の検索 |
| コールサイン | アマチュア無線コールサイン | あり | あり | 12 バイト、NUL パディング; チップ上の検索 |
| DMR 加入者 ID | DMR 無線 ID | あり | あり | 32 ビット符号なし (0 = なし); チップ上の検索 |
| バッジ番号 | 従業員またはバッジ ID | あり | あり | UTF-8 文字列 |
| 組織 | 機関または雇用主 | あり | あり | UTF-8 文字列 |
| 部門 | チームまたは部署 | あり | あり | UTF-8 文字列 |
| 役割 | 職務または機能ラベル | あり | あり | UTF-8 文字列 |
| メモ | 自由形式のコメント | あり | あり | UTF-8 文字列 |
| 無線所属 | クラブ、ネット、または同盟ラベル | あり | あり | UTF-8 文字列 |
| 番地 | 住所の番地行 | あり | あり | UTF-8 文字列 |
| 国 | 国名またはコード | あり | あり | UTF-8 文字列 |
| 郵便番号 | ZIP または郵便番号 | あり | あり | UTF-8 文字列 |
| 地域 | 州、郡、または地域 | あり | あり | UTF-8 文字列 |
| Fluxer ID | Fluxer ハンドルまたは ID | あり | あり | UTF-8 文字列 |
| Discord ID | Discord ユーザー ID | あり | あり | UTF-8 文字列 |
| IRC ID | IRC ニックネームなど | あり | あり | UTF-8 文字列 |
| 電話番号 | 音声または SMS 連絡先番号 | あり | なし | UTF-8 文字列; ホスト上で最大 32 文字; 提出者申告であり、検証されていません |
| フィンガープリント | 鍵アンカー（検索、同期） | あり (pgp_fingerprint) | あり | 32 バイト; ワイヤー上では OpenPGP v4 スタイル; G: デバイスフィンガープリントとは異なります |
| 公開鍵 | 暗号化 / 検証素材 | あり (pgp_pubkey) | あり (鍵領域) | アルゴリズム: Ed25519、X25519、Brainpool P-256/P-384/P-512、NIST P-256/P-384、RSA-2048/3072/4096; チップ上で最大 768 バイトのブロブ |
| PIN 保護鍵 | 鍵は PIN ロック解除が必要 | ホストは OpenPGP 鍵を別途保存 | あり | チップ上の PIN 検証ダイジェスト + AES-GCM ラップメタデータ |
| 最終取得日 | 鍵素材が更新された日時 | あり (fetched_at) | あり (last_fetched) | ホスト上は UTC; チップ上は 32 ビットタイムスタンプ |
| 有効期限 | 鍵の有効期限 | あり | なし | SQLite のみの UTC 日時 |
| 鍵ソース | ホストレコードの作成方法 | あり (source) | なし | 例: manual、keyserver、WKD、LDAP、file、peer |
| フィールド来歴 | メタデータフィールドごとの信頼ラベル | なし | あり (source_map) | フィールドあたり 2 ビット: SelfAttested、HostVerified、RegistrySync、OobVerified |
| レコードフラグ | アクティブ、古い、自己 ID、失効 | 部分的 (ホストロジック) | あり | 例: チップ上の STALE、SELF_KEY |
cargo run -p xtask -- timing-test--no-dudecttest-alltest-all-fulldocs/TEST_RESULTS.md を参照してください。| メタデータフィールド | OpenPGP / GnuPG | Galdraキー（ホスト + 連絡先ストア） |
|---|
| 連絡先 / レコードID | なし（キーIDまたはフィンガープリントを使用） | あり（ホスト上のSQLite id、チップ上にはなし） |
| 表示名 | ユーザーIDテキスト内のみ（Name <email>） | あり（個別のUTF-8フィールド） |
| 電子メール | ユーザーIDテキスト内のみ | あり（個別フィールド、チップ上の電子メールによる検索） |
| 住所 | 標準フィールドなし | あり |
| 国 | 標準フィールドなし | あり |
| 郵便番号 / ZIPコード | 標準フィールドなし | あり |
| 地域 / 都道府県 | 標準フィールドなし | あり |
| 組織 | 標準フィールドなし | あり |
| 部門 | 標準フィールドなし | あり |
| 役割 / 役職 | 標準フィールドなし | あり |
| バッジ / 従業員ID | 標準フィールドなし | あり |
| コールサイン | 標準フィールドなし | あり（12バイト、チップ上ではNULパディング） |
| DMR加入者ID | 標準フィールドなし | あり（32ビット、チップ上で検索） |
| 無線所属 | 標準フィールドなし | あり |
| Fluxer ID | 標準フィールドなし | あり |
| Discord ID | 標準フィールドなし | あり |
| IRC ID | 標準フィールドなし | あり |
| 電話番号 | 標準フィールドなし | あり（ホストSQLiteのみ） |
| 自由形式のメモ | 標準フィールドなし | あり |
| OpenPGP v4フィンガープリント | あり（40桁の16進数） | 証明書をリンクする場合のホスト行のオプション（pgp_fingerprint）、Galdraキーのチップ上では32バイト |
G: デバイスフィンガープリント | なし | あり（SIG公開キー上のBLAKE3-160、ホストツール、OpenPGP v4値ではありません） |
| OpenPGPキーID | あり（短い/長い形式） | なし |
| 信頼 / 来歴 | ユーザーID上のWoT署名 | フィールドごとのラベル：SelfAttested、HostVerified、RegistrySync、OobVerified（チップ上） |
| キー有効期限 | あり（証明書 / サブキー） | ホストのみ（SQLiteの expires_at） |
| 最後のキー取得時刻 | ホストツール依存 | あり（fetched_at / last_fetched） |
| トークン上の秘密鍵 | SIG、DEC、AUTカードスロット | 個別のGaldraキー領域（ユーザーIDパケットではない） |
| 秘密鍵を使用するためのPIN | PW1 / PW3（OpenPGPカード） | Galdra連絡先レコードごとのオプションのPINラップ |
| OpenPGPカードオブジェクト（上記の表にはない） | ホスト（GnuPG） | トークン上 |
|---|
| プライマリ + SIG / DEC / AUTサブキー | キーリング内の公開 | シールされたスロット内の秘密 |
| 認証署名（WoT） | あり | なし |
| 失効証明書 | あり | なし |
| アルゴリズム属性（DO 0xC1 / 0xC2 / 0xC3） | gpg --card-edit | あり |
galdra-core-host| 範囲 | 代表的な標準 / 文書 | 標準のOpenPGPカード + GnuPGとして公開されるか? |
|---|
| OpenPGPカードアプリケーション — APDU、PIN、SIG/DEC/AUTスロット、カード上での生成/署名/復号 | OpenPGPカード仕様（docs/OPENPGP_CARD.md を参照） | はい — 他のOpenPGPスマートカードと同じホストスタック（gpg、scdaemon、CCID） |
| USB CCID — デバイスをスマートカードリーダーとして扱う | USB CCIDデバイスクラス | はい — クラスドライバ |
| OpenPGPメッセージ形式 — 暗号化ファイル、メール、鍵パケット | RFC 4880（および更新版） | ホスト上でははい — GnuPGがこれを使用。カードはメールを解析しない |
| Shamir K-of-N — ボールト内の長期鍵素材の分割 / 復元 | OpenPGPカード仕様にない。GnuPGにもない | いいえ — ファームウェアとプロビジョニングツールのみ。gpg --card-edit 操作ではない（Shamirとフルディスク暗号化 を参照） |
| デュアルハードウェア鍵 / クォーラム認可 — コンシューマーが動作する前に2つ（またはN個）のトークンが必要（ドライブのロック解除、ドアの解放、特権操作） | OpenPGPカード仕様にない | いいえ — Shamirおよび/または複数のOpenPGP認証を使用するインテグレーター向けのサポートされる拡張パターン。強制は下流システムに属する（docs/DUAL_KEY_QUORUM.md） |
| 認証付き一時ECDH — トークン上の前方秘匿セッションプロトコル | OpenPGPカード仕様にない | いいえ — トークン固有。GnuPGカードコマンドではない |
| 暗号プロファイルシステム — 名前付き対称カスケード（独立した暗号を互いに積み重ねる。最大4層、3層はサポートされる深さ）および関連ポリシー | OpenPGPカード仕様にない | いいえ — ファームウェア / ホストトークンツール |
| microSDデコイ / マスストレージペルソナ — 非情報ホストのUSB動作 | OpenPGPカード仕様にない | いいえ — 別のUSBペルソナコードパス |
| WebAuthn / FIDO2 | CTAP / WebAuthn | 未実装 — OpenPGPカードとは異なる標準規格 |
| 層 | 役割 |
|---|
| ドライブ | マスターキーで暗号化（例: LUKS、VeraCrypt、または生のブロック層を介したAES-256） |
| マスターキー | SSSでN個のシェアに分割、しきい値K-of-N |
| シェア | 人、デバイス、またはオフラインストレージが保持。K個のシェアが揃うとマスターキーを再構成 |
| ロック解除 | キーを再構成し、cryptsetup、veracrypt、または自分のスタックに渡す |
| シェアの保護 |
| 配布前に各シェアを特定の受信者向けに暗号化（例: 受信者のOpenPGP鍵を使用） |
| 再構築場所 | エアギャップマシン、HSMポリシー、または管理された環境 — 信頼できない共有ホスト上では不可 |
| シナリオ | SSSと強力でポリシーに沿った曲線が重要な理由 |
|---|
| 従業員の退職または死亡 | その人の排他的な秘密なしで復旧が可能なまま |
| 適正手続きに基づく合法的アクセス | クォーラムを要求可能 — 単一の当事者が完全な解除秘密を保持しない |
| 企業の鍵エスクロー | 監査可能な分割; 単一の管理者が完全なアクセスを持たない |
| ハードウェアの押収 | N個のシェアのうちK個を取得せずにメディアが押収される可能性 |
| 規制適合（EU / BSI） | Brainpoolは多くのドイツおよびEU政府の暗号要件を満たす |
| 法域 | この文書で触れられた状況 |
|---|
| ドイツ | 上記のGovernikus/BSIフロー |
| エストニア | チップベースのeID。2017〜2018年にROCA脆弱性によりRSAを完全に放棄せざるを得なくなった後、RSAからNIST P-384（secp384r1）ECDSAに移行（チップは安全なRSA鍵を生成できず、より大きな鍵サイズへの経路もなかった）。秘密鍵はハードウェアにバインドされており、カードから読み取ることはできない。GovernikusスタイルのOpenPGP署名サービスは見つかっていない。 |
| ベルギー | チップベースのeID。古いカードはRSA 1024ビットを使用。新しいカード（アプレット 1.8以降）はNIST P-384 ECDSAを使用。活発なオープンソースミドルウェアエコシステム（eid-mw、OpenSC）。GovernikusスタイルのOpenPGP署名サービスは見つかっていない。 |
| ノルウェー | 国民IDカードチップ（2020年以降発行）はICAO 9303互換で、旅行文書チップのみを実装。eID署名機能はない。署名eIDは別個: SEIDの下で認定された民間プロバイダー（Buypass、Commfides）が提供し、歴史的にはRSA 2048ビット、SEID 2.0でECCが導入されRSA 3072ビットに移行中。GovernikusスタイルのOpenPGP署名サービスは見つかっていない。旅行チップと署名eIDは別個 — カードチップのみを直接使用しようとする場合に関連。 |
| オーストリア | 部分的に調査済み。 eIDはECCを使用（確認済み）; 具体的な曲線は利用可能な情報源で確認されていない。単一カードではなくマルチトークンのBürgerkarteモデル。主にモバイルアプリに移行。曲線の詳細とOpenPGP署名サービスの有無についてはさらなる調査が必要。 |
| 米国 | PIVカード（Personal Identity Verification、FIPS 201 / NIST SP 800-78）: 連邦政府職員および請負業者にのみ発行 — 一般市民向けカードではない。アルゴリズム: 認証鍵にはNIST P-256が必須。署名/鍵管理にはP-256またはP-384。RSA 2048/3072も許可。NIST曲線のみで、Brainpoolはなし。トラストルートはFederal Common Policy CA（FCPCAG2）で、標準の商用トラストストアには含まれていない。GovernikusスタイルのOpenPGP署名サービスは見つかっていない。FPKIはOpenPGPとは別のX.509インフラストラクチャ。PIVが連邦限定であることは、ドイツのeIDのような市民トラストアンカーではないことを意味する。 |
| カナダ | オンチップ署名鍵を持つ国家レベルのチップベース身分証明カードはない。デジタルアイデンティティは州のスキーム（例: BC Services Card）、モバイルアプリ（例: eID-Me）、および進化する連邦デジタル資格情報フレームワークに断片化されている。ドイツ、エストニア、ベルギーのモデルに匹敵する単一カードはない。同等のカードインフラは見つからず — この意味での実行可能なトラストアンカーではない。 |
| その他の国 | 調査されていない |
| 目標 | 開始場所 |
|---|
| プロジェクト概要、ニュース、コミュニティ | sequoia-pgp.org |
| 貢献（イシュー、修正、機能、ドキュメント）; 大規模な作業の前に連絡 | Contribute、Contact |
開発者ドキュメント — 実装を拡張するためのAPIサーフェス（sequoia-openpgpおよび関連クレート） | Docs — 例: docs.rsのsequoia-openpgp |
| ソースとトラッカー | gitlab.com/sequoia-pgp（コアライブラリとツール）; github.com/sequoia-pgp（ミラー / 選択リポジトリ）; Projects |
| OpenPGP標準の新しいアルゴリズム | 依然として**IETF OpenPGPワーキンググループ**を経由します。Sequoiaおよび他の実装はドラフトとRFCを実装します。そこでプロトコル変更を提案し、動作が仕様と一致するように実装者（Sequoiaを含む）と調整します。 |