プライベートスペースの Access Key をより安全にする方法

私たち自身が Senvra を使う中で、何度も同じ素朴な問題に直面しました。プライベートスペースを作成した後、その Access Key をどこに保管すべきなのでしょうか。

同じ端末だけに残すと、復旧資格情報としての意味が弱くなります。一方、平文のキーをメール、メモ、パスワードマネージャー、別のドライブに置けば復旧できますが、スペースを開ける重要な資格情報が存在する場所も増えます。

実際に使うときの体験も良くありません。保存場所を探し、キーをコピーし、現在の端末へ移し、Senvra に貼り付ける必要があります。この流れは平文がクリップボードや他のシステムを通る機会を増やし、本来は簡単であるべき復旧操作を面倒にします。

この繰り返し発生する実利用上の問題から、Access Key の保存と利用方法を見直しました。今後の Senvra アップデートでは、別の6桁PINで保護された Access Key コピーとQR転送という2つの任意機能を追加します。6桁PINを高エントロピーな秘密に見せるのではなく、生の256-bit Access Keyが平文で現れる回数を減らし、不要なクリップボード経由を取り除くことが目的です。

問題は日常の保管と受け渡しに現れる

Senvra 内部では、各プライベートスペースはランダムな256-bitマスターキーと認証付きキーラッパーで保護されています。ここで扱う弱点は、Space Access Keyを外部へ保存した後に始まります。

フロー図図を準備しています

横にスワイプして図全体を表示

図のソースを表示

flowchart TB
    accTitle: Responsive flowchart
    subgraph R1[" "]
        direction LR
        A[平文 Access Key] --> B[メール、メモ、ドライブ] --> C[現在の端末へ取り込む]
    end
    C --> D[アクセスと復旧]
    C --> E[資格情報の管理]
    D --> F[プライベートスペースを開く]
    D --> G[バックアップを作成・復元]
    E --> H[パスワードを再設定・変更]
    E --> I[Access Key をローテーション]
    style R1 fill:transparent,stroke:transparent

Access Key は、パスワードを忘れたときだけ使う予備の文字列ではありません。プライベートスペースを開く、バックアップを作成または復元する、パスワードを再設定・変更する、Access Key 自体をローテーションするといった復旧と重要な管理操作の資格情報です。用途が重要だからこそ、保存と受け渡しにも専用の安全設計が必要です。

メールの下書きは同期され、メモは検索対象になり、クリップボード履歴が残ることがあります。これは保管庫内部の暗号化が失敗したという意味ではなく、復旧資格情報が元の境界を離れ、複数の仕組みを平文で通過したという意味です。

そこで、最初の要件を「生の Access Key を外部のすべての場所で読める状態にせず、持ち運べるコピーを保存できること」としました。

任意のPIN保護コピー

新しいフローでは、Access Key のコピーに別の6桁PINを追加できます。元の Access Key は均一にランダムな32バイト値のままです。Senvra は16バイトのランダム salt を生成し、PBKDF2-HMAC-SHA256 を600,000回実行してPINから材料を導出し、用途を分離した HKDF-SHA256 から32バイトのマスクを作ります。

Access Key のバイト列とマスクをXORします。持ち運び用エンベロープには、マスクされたバージョンヘッダーと0〜24バイトのランダムpaddingも含め、独自の64文字転送アルファベットで符号化します。出力にはメールアドレス、スペース名、アカウント識別子、読める「Senvra Access Key」ラベルは入りません。

フロー図図を準備しています

横にスワイプして図全体を表示

図のソースを表示

flowchart TB
    accTitle: Responsive flowchart
    subgraph R1[" "]
        direction LR
        A[Access Key + 別PIN] --> B[PBKDF2<br/>600,000回] --> C[HKDF<br/>32バイトマスク]
    end
    subgraph R2[" "]
        direction RL
        D[XOR + ランダム化エンベロープ] --> E[保護文字列またはQR] --> F[PINから候補キー]
    end
    subgraph R3[" "]
        direction LR
        G[対象スペースのラッパー] --> H{AES-GCMを開けるか} --> I[受理または拒否]
    end
    R1 --> R2
    R2 --> R3
    style R1 fill:transparent,stroke:transparent
    style R2 fill:transparent,stroke:transparent
    style R3 fill:transparent,stroke:transparent

独自アルファベットとランダムpaddingは転送上の難読化であり、暗号強度そのものではありません。保護はPIN由来のマスクから得られます。ただし6桁PINは100万通りしかないため、これは日常的な平文露出を減らす追加障壁であり、高エントロピー鍵の代替ではありません。

なぜ「PINが違う」とすぐ判定しないのか

最も分かりやすい実装は、Access Keyを認証付き暗号で包み、認証タグで復号成功を判定する方法です。しかし、漏えいした保護文字列自体がPIN確認器になり、攻撃者は候補を試すたびに正解かどうかを即座に知れます。

Senvra はこの性質を意図的に避けます。形式上有効な6桁PINは、どれも妥当な32バイト Access Key候補を生成します。改変された保護文字列も、外見上妥当な候補を生成し得ます。外側の保護層だけでは候補の正否を判断できません。

判断は、正しい文脈を持つ唯一の場所である対象プライベートスペースに委ねます。候補 Access Key から復旧ラッピング鍵を導出し、そのスペースIDに結び付けられた AES-256-GCM 認証済みマスターキーラッパーを開けるか試します。成功して初めて、その Access Key が本当に対象スペースのものだと分かります。

保護文字列だけが漏れても、自己完結した正解PINの信号はありません。
間違ったPINは外層で便利な認証エラーを返さず、誤った候補キーを生成します。
対象スペースの認証済みマスターキーラッパーを開けない時点で拒否されます。
攻撃者が対象保管庫のメタデータも入手していれば、それが検証対象になり得ます。6桁PINは別の場所に保管し、限定的な強度の保護として扱う必要があります。

コストは高くなるが、総当たりが不可能になるわけではない

600,000回のPBKDF2反復により、PIN候補を1つ試すたびに明確な計算コストが発生します。対象スペースの検証データも利用できる場合、6桁PINの全100万通りを確認するには、最大100万回の完全な導出、現在の設定では約6000億回のPBKDF2反復が必要です。平文保存や高速ハッシュより攻撃コストは大きく上がりますが、数学的に総当たりが不可能になるわけではありません。

通常は Senvra アプリが対象プライベートスペースを開く際に最終確認を行います。ただし、暗号学上必要なのは対象スペースの認証済みラッパーデータであり、公式アプリだけが実行できる秘密のロジックではありません。保護コピーと対象保管庫のメタデータを両方入手した人は、同等のオフライン検証器を実装できる可能性があります。保護コピーだけが漏れた場合は、その文字列だけからPIN候補の正否を確認できません。だからこそ、保護コピーとPINは別々に保管する必要があります。

短いPINを強いパスワードと呼ぶ代わりに、狭いが正確な安全特性を選びました。

QRは手作業を減らすが、公開情報にはしない

次のアップデートでは、Access KeyコピーをQR画像として表示・保存できます。別の端末では、カメラで読み取るか、選択した画像から読み取り、Access Key欄へローカルに入力できます。

これにより、コピー＆ペーストの回数を減らせます。保護されたQR画像を任意の保管場所に置き、必要なときに読み取り、別に保管したPINを入力できます。保護文字列とQR画像は同じ材料を運ぶため、QRは追加の暗号層ではなく転送形式です。

QR画像を読み取れる人は、その内容をコピーできます。平文 Access Key のQRは平文キーと同じように保護すべきです。より安全な運用は、PIN保護済みQRを保存し、6桁PINを別の場所に置くことです。

スキャナーは正規化された平文 Access Key または有効な保護エンベロープだけを受け入れ、任意のURLや無関係なQRを拒否します。画像サイズも制限し、アプリが非アクティブになると入力途中のPINを消去します。

既存のキーを交換する必要はない

保護コピーが変えるのは保存・転送形式であり、スペース自体の Access Key はローテーションしません。既存の平文キーは引き続き利用できます。

次のバージョンでは、新規 Access Key を保存前に保護し、Security → Password & Access Key で既存の平文キーをローカル変換し、結果を文字列またはQR画像で保存できます。後からスキャンまたは貼り付け、別の6桁PINを入力して利用できます。必要な場合は明示的に平文表現へ戻すこともできます。

変換ツールはキーを別のスペースへ追加せず、アップロードもしません。保護コピー作成後、平文キーとPINはツールの一時UI状態から消去されます。

実際の運用モデル

この機能は露出面を減らすものであり、保管責任をなくすものではありません。

保護コピーとPINは別々の場所に保管してください。メール、写真、メモが便利だからといって私的とは限りません。保護コピーが動作することを確認してから古い平文コピーを削除し、依存する前に復旧テストを行ってください。利用可能な Access Key とパスワードの両方を失えば、スペースは復旧できません。Senvra にサーバー側の復旧バックドアはありません。

より広い鍵モデルは、パスワード変更時に全ファイルを再暗号化しない理由で説明しています。

今後のリリースでは、従来の平文のみの復旧フローを選択可能にします。互換性が必要なら元の形式を使い、平文露出を減らしたい場合は別PINとQR受け渡しを利用できます。