エンコードされた VPN シークレットに「復号」はない

「エンコードされた鍵を復号する」という言い方は、存在しない単一の操作を前提にしています。保存された VPN シークレットは、base でエンコードされたバイト列、キーストアに結び付いた暗号化ブロブ、まったく逆変換できない一方向の検証器のいずれかであり、それぞれに別の対応が必要です。base エンコードは設計上、機密性を何も加えないため、デコードすると保護されたシークレットを明かすのではなく、使えるシークレットを取り戻せる可能性があります。フィールドと、それを書き込んだ製品から始めることが唯一の確実な特定方法です。

エンコードされたシークレットもシークレットですから、値は Web のデコーダーにも公開フォーラムの投稿にも出さないでください。

エンコード、暗号化、検証器は別物

RFC 4648 は base エンコードを制約環境でのデータ表現として定義し、その安全性の節では計算上の機密性を提供しないと明言しています。つまり Base64 フィールドは誰でもバイト列に戻せるので、これは暗号上の障壁ではなく復元リスクです。暗号化は別で、鍵素材がなければバイト列は不透明なままです。検証器はさらに別で、逆変換できないように設計されています。文書化されたフィールド名を読めば、三つのうちどれかがたいてい分かります。

文字列を Base64 と呼んでも、中身が何かは確定しません。鍵、シリアライズされた構造、ランダムなパディングのいずれかにデコードされ得ますが、見た目からはどれか分かりません。

触る前にフィールドを特定する

エクスポートした製品とバージョン、プロファイル形式、文書化されたフィールド名を記録します。次に、関与するシークレットの種類を分けますが、グループの事前共有鍵は個人アカウントのパスワードでも、秘密鍵のパスフレーズでも、認証トークンでもありません。これらは所有者も交換手順も異なり、混同すると間違った資格情報を変更してしまいます。まだ接続できるプロファイルも、他人に属する資格情報を取り出す許可にはなりません。

サポートに伝えると役立つ情報は、製品、フィールド、エラー、許可された目的です。シークレットそのものはその一覧に含まれません。

復旧は許可された手順であり、デコーダーではない

製品が許可された復旧のための可逆エクスポートを文書化しているなら、保護された環境でその製品自身のインポートまたは復旧手順を使ってください。元のファイルは保存し、デコードした素材はログ、シェル履歴、チケットの外に置きます。値が暗号化されているか保護されたストアに結び付いている場合、文書化された解除方法と必要な承認は、デコードが鍵も他人のアクセス文脈も与えない以上、所有者から得ます。フィールドが検証器を保持している場合は、デコーダーを試すのではなく文書化された交換経路に従ってください。

所有者が値を復旧できず安全に再発行できない場合、答えは新しい資格情報と更新されたピア設定です。それは切り替えを伴うプロジェクトであり、コマンドではありません。

共有シークレットの交換は調整された変更

本番の共有シークレットを片側だけで上書きすると、以前の値を持つ承認済みクライアントがすべて壊れます。切り替えを計画し、取り消すべきアクセスがあるか決め、どちらかの端点を変える前に復旧経路を用意しておきます。気づく人たちに時間枠を告知します。

元の値が露出したなら、ローテーションが正しい対応であり、デコードしても何も加わりません。露出したシークレットは、誰かがバイト列を復元したかどうかに関係なく侵害されています。

新しい値がどこにあり、誰が所有するかを記録します。次のインシデントが求めるのはそれであり、デコーダーではありません。