IPsec 事前共有鍵：入力した文字列の背後のバイト

二人の管理者が画面上のシークレットを比較し、一致していると同意しても、トンネルは認証に失敗します。彼らが比較した文字列は、どちらの端が鍵導出に入力する値でもありません。目に見える文字とプロトコルがハッシュするバイトの間には、フィールド型、テキストエンコーディング、エディタ、クリップボードがあり、その四つのどれでも見た目を変えずに入力を変えられます。バイトを比較すれば、不一致はたいてい数秒で現れます。

ゲートウェイが文字列に対して行うこと

事前共有鍵はネットワーク上に送られて比較されるのではありません。各端がローカルコピーを IKE 交換の鍵導出に入力し、その結果の認証ペイロードが検証されるか、されないかです。この設計は、二つのコピーが見た目に似ているのではなくバイト単位で同一でなければならないことを意味し、失敗が誤ったパスワードのメッセージではなく認証段階で報告されることも意味します。

したがって有用な問いは「これらは同じに見えるか」ではなく、「各実装がハッシュする正確なバイト列は何か」です。

余分なバイトはどこから来るか

末尾の改行が典型的な原因で、ほとんどのエディタがファイル保存時に目に見えない形で一つ追加するため、目の前に隠れています。チャットウィンドウから貼り付けた先頭や末尾のスペースも同じことをし、ワープロが直線引用符をスマート引用符に置き換えた場合も同様です。どれも人間が行う視覚的な比較を変えません。

グリフではなくバイトを表示するツールで比較します。printf '%s' "$PSK" | xxd | tail -2 は値の末尾を十六進数で出力し、迷入した 0a や 20 が明白になります。両端で実行し、二つのダンプを並べて比較します。生成したテスト資料で行い、その後シェル履歴に残す本番のシークレットでは行わないでください。

エンコードは暗号化ではない

構成のエクスポートはしばしばシークレットを基底エンコーディングで運び、六十文字か七十六文字ごとに改行が入ることも、パディングが付くこともあります。一方の端がデコードされたバイトを期待しているのにエンコードされたテキストを貼り付けた場合、別のパスワードを送ったのではなく、印刷可能な文字でできたはるかに長いパスワードを送ったことになります。Base64 は機密性をまったく提供しないため、エンコードされたシークレットを第二の意見のためにフォーラムへ貼ってはいけません。

Apple の IPSec 辞書は型が重要であることを示す良い例で、L2TP と Cisco IPsec のペイロードにおける共有シークレット認証方式のデータとして SharedSecret を記録しています。それは特定のペイロードにおける特定のプロパティであり、たまたまシークレットを要求する別のプロトコルに再利用できる汎用のテキストフィールドではありません。

主張された制限は一つの組み合わせに属する

一つの Apple クライアントにおける三十二文字の上限という古い報告は、一つのクライアントバージョン、プロトコル、プロファイル形状についての実際の報告です。すべての Apple プラットフォーム、すべてのプロバイダー、すべてのプロトコルに対する普遍的な制限ではありません。バージョン、ペイロード型、ゲートウェイの要件をまとめて確認し、スレッドから推測するのではなく承認された構成でテストしてください。次の人が同じスレッドを、それが値する以上の自信で引用することになるため、テストした組み合わせを変更記録に書いてください。

制限が本当に適用されるなら、答えはそれに合うサポートされた資格情報の設計であり、強力なシークレットを短くした版ではありません。推測された制限を満たすために本番鍵を切り詰めると、その強度が恒久的に低下し、ドキュメントがもはやセキュリティと一致しないシステムが生まれます。

強度ではなく表現を直す

表現を確認した後に認証が失敗する場合は、認証段階の有効なポリシーとして、どの方式が交渉されているか、どのピア ID が期待されているか、ゲートウェイが想定している接続と一致しているかを読んでください。徐々に弱い推測は診断ではなく、サポートチケットが添付されたゆっくりした格下げです。

必要な資格情報が組織の標準を満たせない場合は、満たせる設計に変更してください。十分なエントロピーを持つ共有シークレットを一度生成し、管理されたフィールドに保存し、決して公開しないことはまったく良い答えであり、それを短くした版はそうではありません。