2021年02月16日に初出の投稿

Last modified: 2021-02-16

さらに、利用者に「暗号化されてて安心」という印象を与えてしまい、設定ファイルの保護に意識が向かなくなるので、そこが運用上のセキュリティ脆弱性となってしまいます。

wpa_supplicant.conf に書く PSK を wpa_passphrase コマンドで暗号化する意味はあんまし無い

Qiita にばらまかれている、一見すると技術者の知見みたいなものに見えるものの大半がクズみたいなデタラメであり、僕が殆ど Qiita を調査のリソースとして信用していない理由は、こういう記事が多すぎるからだ。情報セキュリティのプロが正確に解説してやるから、技術者気取りのコーディング小僧はありがたく読むと良い。

まず第一に、wpa_passphrase は「暗号化」ツールなどではない。暗号化とハッシュ化の区別もできない人間が『伽藍とバザール』を持ち出してセキュリティを語るなど笑止と言わざるをえない。

そして第二に、情報資産の保護ではペリメーター・モデルという考えがあり、少なくとも資産の内部で安全性を前提してよければ、保護のレベルは資産の外側から最も脆弱なポイントで測るという原則がある。よって、OS の内部に侵入されて root を取られているなどという、根本的に情報保護の施策を〈全て破られてしまった後の最終局面〉を前提に対策を語るのは、ただの論点先取である。危篤に陥っている状況の癌患者に向かって、大声で「体調が良くなったら、体力づくりにルーム・ランナーで1時間ほど走りましょうねー!」と話しかけるようなものだ。

第三に、ペリメーター・モデルの外側から対策すると、内部でファイルのパーミッションなどの管理が疎かになるなどと言うが、たとえば /etc/ssh/sshd_conf のようなファイルを # chmod 0666 で保存するようなバカがサーバの管理を仕事としてやってる方がおかしい。逆に、意図してそんなことをしない限り、サーバ内で運用されるたいていの設定ファイルは、ディフォールトで適正なパーミッションに設定されて実装されている筈である。wpa_supplicant.conf は、Raspberry Pi OS がインストールされたら /boot から /etc/wpa_supplicant/wpa_supplicant.conf に移されて、一般ユーザではアクセスできなくなる。

よって、そもそも情報セキュリティの技術やマネジメントの知識が殆どないからこそ、暗号化とハッシュ化の区別ができていないせいで、入力値からハッシュ化した値とストアされているハッシュ値を比較することを「我々が暗号化して保存していると思っていたものは、実はモロ平文だった」などと書くわけである。ハッシュ値を「平文」などとミスリードするような人間の語るセキュリティの話は、security theatre どころか security 漫才くらいだろう。

ハッシュ値の比較で認証処理するなんてシステムはどこにでもあるわけで、確かに第三者が外から知りうる SSID を salt にしてハッシュ化することは好ましくない仕様だと思うが、一般的な実装では salt をサービス全体で固定しているような、もっと脆弱な仕様もある。それでも固定した salt で生成されたハッシュ値の比較という認証フローが普及しているのは、誰でも知りうる salt 値であろうと、それとパスフレーズの値とで十分に桁が大きければ、そこからハッシュ関数を使ってパスフレーズを試しに出力しまくるとか、あるいは既に出力した値を使ってのレインボー・テーブルを参照することに膨大なコストがかかるからなのだ。この〈コストがかかる〉ことでセキュリティ対策としての有効性を測るのが現実の技術者の態度であり、ハッシュ値を(なぜか)知っている前提で比較することが復号化と比べて見た目が単純だからというだけで、弱いのどうのと騒ぐのは子供である。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook