本文へスキップ
このページは機械翻訳されたものです。不正確な箇所が含まれる可能性があります。英語の原文を読む

YubiKey用KeeChallengeと、避けるべき理由

KeeChallenge は、KeePass 2にYubiKey対応を追加するプラグインです。ただし、いくつもの問題を抱えています。この記事では、その問題点と代替となる解決策について説明します。

KeeChallengeの仕組み

KeeChallengeは、秘密のHMACキー(S)でデータベースを暗号化します。このキーはYubiKeyに保存され、レスポンスの生成に使用されます。さらにKeeChallengeは、事前に計算したチャレンジ・レスポンスのペアで S を暗号化し、暗号化された秘密鍵とチャレンジを補助的なXMLファイルに保存します。

データベースのロックを解除するとき:

  1. KeeChallengeはXMLファイルからチャレンジ C を読み込み、YubiKeyに送信します
  2. YubiKeyは(キー内に保存された秘密鍵 S を使って)チャレンジを変換し、レスポンス R を返します
  3. レスポンス R を使って、XMLファイルに保存された暗号化済みの秘密鍵 Senc を復号します。
  4. 復号された秘密鍵 S を使ってデータベースを復号します。重要なのは、これはYubiKeyに保存されているものと同じ秘密鍵であるという点です。
  5. KeeChallengeはXMLファイルを再生成します(新しいランダムなチャレンジ C を生成し、新しいレスポンス R を計算し、R' を使って S を暗号化し、更新された CSenc をXMLファイルに保存します)

詳細については、ワークフロー全体の図をご覧ください。

KeeChallengeの問題点

KeeChallengeのアプローチには、いくつかのセキュリティ上の問題があります:

  • 秘密鍵は決して変わらず、再暗号化されるだけです。KeePassから見れば、KeeChallengeは毎回同じバイト列を提供する静的なキーファイルと何ら変わりません。
  • 上記の結果として、KeeChallengeはリプレイ攻撃に対して完全に無防備です。過去のXMLファイルのどれでもデータベースの復号に使えてしまいます。つまり、チャレンジをランダム化して秘密鍵を再暗号化することに意味はなく、単なるセキュリティシアターにすぎません。
  • 秘密鍵はYubiKeyの外に出るべきではありません — それこそが書き込み専用ハードウェアキーの存在意義です。KeeChallengeは秘密鍵をコンピュータに持ち出すことで、この原則に違反しています。理論的には、攻�者はプロセスメモリからSをコピーし、所有者に気づかれずにYubiKeyを複製し、(秘密鍵が静的であるため)データベースの将来のあらゆるバージョンを復号できます。

さらに、関連する問題もいくつかあります:

より良い代替手段

代替アプローチがKeePassXCで導入され、すべての互換アプリでサポートされています:

KeePassXCでは、HMACシークレットの知識を一切必要としません。データベースのマスターシード(データベースの一部であるランダムなバイト列)をチャレンジとして使用し、そのレスポンスを使ってデータベースを暗号化します。これにより、余分なファイルが不要になるだけでなく、保存のたびに必要となるレスポンスが変化するという利点もあり、より本物の二要素認証に近い形になります。

このアプローチには、KeeChallengeに対する重要な利点がいくつかあります:

  • YubiKeyから導出されるキーは動的で、データベースを保存するたびに変化します。(KeeChallengeでは暗号化キーが変わらないため、事実上、静的なキーファイルをシミュレートしているにすぎません。)
  • HMACシークレットがハードウェアキーの外に出ることは決してないため、YubiKeyをひそかに複製することはできません。
  • 補助的なXMLファイルは不要で、必要なのはデータベース本体だけです。
  • このアプローチをサポートする活発な開発チームが複数存在します。

以上の理由により、KeePassiumはKeePassXCのアプローチを実装しています。KeeChallengeで暗号化されたデータベースをサポートする予定はありません。

KeeChallengeで保護されたデータベースをお使いの場合は、KeePassXCとKeePassiumへの移行をご検討ください。この組み合わせなら、より安全で、互換性が高く、継続的にメンテナンスされているソリューションを利用できます。

関連情報