ssh(1) にキーストロークタイミング難読化を追加
(undeadly.org)- Damien Miller が ssh(1) クライアントに、キー入力間の時間情報を隠す難読化機能をコミット
- 対話型トラフィックで送信データが少ない場合、固定間隔送信を使用し、デフォルト間隔は 20ms
- 最後の実際のキー入力の後には、ランダムな時間だけ偽の chaff キー入力を送ってタイミングパターンをさらにぼかす
- 動作は新しい
ssh_configキーワードObscureKeystrokeTimingで制御 - 実装には SSH 転送層の新しい PING/PONG 拡張が使われ、今後
openssh-portableを通じて他のシステムにも反映される可能性がある
ssh(1) クライアントのキー入力タイミング隠蔽
- Damien Miller が ssh(1) にキーストロークタイミング難読化のサポートをコミット
- この機能はキー入力間の時間間隔を隠すため、送信データが少ない対話型トラフィックを固定間隔で送信しようとする
- デフォルトの送信間隔は 20ms
- 最後の実際のキー入力以降は、ランダムな時間だけ偽の chaff キー入力を送信
- 新しい
ssh_configキーワードObscureKeystrokeTimingで動作を制御
SSH プロトコル拡張と展開経路
- 実装では、SSH プロトコルに追加された 2 つの新しい転送層メッセージを使用
SSH2_MSG_PINGSSH2_MSG_PONG
- これらのメッセージは local extensions の番号空間を使用し、
"ping@openssh.com"のext-infoメッセージと文字列バージョン"0"で通知される - この変更は「security by trickery」の一例として紹介され、次の OpenBSD リリースを期待する理由として挙げられている
- 他のシステムでも openssh-portable を通じてこの機能が近いうちに見られる可能性がある
1件のコメント
Hacker News のコメント
キー入力タイミングは1980年代から端末入出力で懸念されていた問題で、当時も stelnet や Kerberos のような初期の暗号化環境ですでに気にされていた部分です
ほとんどの端末アプリはパスワード入力にバッファリングされた入出力を使っており、これは今でも重要なセキュリティ機能です
このモードでは、ユーザーが Enter を押すまで何も相手側に送信されないため、パディングがあれば中間者攻撃者はパスワード長すら推測しにくくなります
しばらくの間、ユーザーが入力するたびに
*を表示しようとして、非バッファモードでパスワードを受け取るアプリは格好の標的でした見た目は良くフィードバックもありますが、パスワード入力で最も隠すべきキー入力速度を漏らしてしまいます
パスワード入力ではバッファリングされた入出力を維持し続けてほしいし、この方式は SSH が難読化しても追いつくのが難しいほど優れていると思います
それでも SSH がこの機能を追加したのは良いことで、シェルやエディタ入力のようにバッファリングできない内容の保護には役立ちます
「長さが違うから間違っているようだ」と考えて、保存済みパスワードの利点を台無しにし、自分で「正しい」パスワードを再入力しようとするかもしれません
昔は2桁のハッシュやスマイリーのような視覚的ハッシュを表示する方式もあったようですが、肩越しに覗き見る攻撃にはむしろ役立つ可能性があります
今ではタッチスクリーンのログインにも、指の圧力、接触面積、形状をユーザーと結びつける形で応用できます
スワイプやマウスの動きまでデスクトップ OS の文脈に含めれば、自分のデバイスやアカウントではないユーザーが使っているときにシステムをロックできるセキュリティアプリも可能です
少なくとも恋人が自分の携帯電話をあさった時点は記録できます
つまり、入力した内容が Enter や送信ボタンを押すまで送信されない方式です
以前 MUD を盛んにやっていた頃はこうした Telnet クライアントを使っていましたが、その後使った SSH クライアントでは見たことがありません
SSH のキー入力タイミング漏洩を防ぐ対策としては悪くなく、利用シナリオによっては記事に出ている 20ms 遅延方式より良い場合もありそうです
ただ、考えてみると Linux シェルの補完のために Tab を押すときも送信されるなら、より理想的だと思います
プロのブリッジを思い出します
チームを壁で分け、カードを窓口から同時に渡すことで、タイミングによる意思疎通を防ぎます
https://youtube.com/watch?v=RVZLNRmO3vo
https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
そしてこれは、私たちが知っているものにすぎません
以前、面接でブリッジを実際に役立てたことがあります
ブリッジには、パートナーがビッド以外の方法でヒントを与えた場合、論理的に可能なときは必ず逆方向を選ばなければならないという Active Ethics ルールがあります
デバッグ面接で面接官が答えへあまりに露骨に誘導しようとしたので、彼の言う通りにする前に、思いつくことをすべて止めて確認しました
面接後になぜそうしたのかを話し、さらに説明が必要なら Active Ethics を調べてほしいと言いました
そして合格しました
これは捕手が投手にサインを送ってはいけないと言っているのに似ています
情報伝達はゲームに次元を加える人間的なスキルであり、最も上手な側が勝つようにすればよいのです
1〜2ビット程度の情報を渡すのは、それほど難しくなさそうです
パートナーとの秘密の意思疎通が核心なのに、その意思疎通は秘密であってはいけません
コミュニケーションしてもよいが、コミュニケーションしてはいけない、という感じで非常に妙です
例えば小さなテーブルを障壁の向こうへ軽く押したり、ゆっくり押したりして何かを示せます
動画右上の人は1回目と2回目でそのように渡していました
こうしたタイミング攻撃を扱った2001年の論文を紹介した2008年の記事があります: https://lwn.net/Articles/298833/
引用されている論文は “Timing analysis of keystrokes and timing attacks on SSH” で、キー入力タイミング情報が入力されたキー列に関する情報を漏らすと分析しています
さらに詳しい分析では、キー入力のペアごとに内容について約1ビットの情報が漏れ、パスワードのエントロピーは1文字あたり4〜8ビット程度なので、この情報はかなり意味を持ち得るとのことです
ずっと前に修正されたと思っていて、2012年ごろに修正が入ったものだと思っていたので、まだ解決されていなかったとはかなり驚きです
いつかは、キー入力を隠すためにランダムデータであらかじめ埋めたパケットを使う必要が出てくるかもしれない
ステガノグラフィではないがかなり近い方法で、トラフィック解析をより難しく、あるいは不可能にする用途にも使えそうだ
専用線なら、回線を常に最大使用率で完全に暗号化したデータで流し続け、必要なときだけ実データを載せるのはそれほど難しくない
無害なカバーテキストを言語モデルに書き直させつつ、単語サンプリングに使う確率分布を、キーから導出した最小エントロピー歪みに変える研究がある
受信側で同じモデルとキーを使えば、カバーテキストを再び暗号文に復号でき、画像にも適用されている
https://openreview.net/forum?id=HQ67mj5rJdR
世界中に向けて数字を流し続け、その数字が誰かにとって意味を持つときだけ意味が生まれる
世界各国の情報機関が聴いているのは明らかなのに、それでもそうしている
macOS の Warp のような最近のターミナルエミュレータを思い出す
たとえば、すべての入力をローカルで受け取ってから、リモートホストへひとかたまりで送るのかが気になる
そうすると、リモートホスト上で実行される何らかの raw モード入力は壊れるかもしれないが、そうした状況を検出して生のキー入力ストリームへ切り替えることもできそうだ
[1]: https://warp.dev
リモート pty は行単位モードの場合も raw モードの場合もある
特殊なシェル統合を持つターミナルは、通常リモートホスト側にもその統合をインストールする必要があり、中にはそれをかなり透過的に処理するものもある
そのため mosh は、純粋な SSH よりも遅延の大きい接続でより良い挙動を見せることがある
ただしこの機能は mosh には適用されないだろう
タイミング攻撃対策のような特定のセキュリティ機能については、新しいツールのほうがうまく防げて、古い標準ツールにはない場合もあるかもしれない
しかし新しいツールでは他のセキュリティ機能が抜け落ちる可能性のほうがずっと高く、「AI」を追加すれば攻撃面も大幅に増える
Warp のプライバシーに関する主張も、正直信じがたい
最近の自然言語処理ツールはほとんどクラウドソリューション寄りで、そうなるとプライバシー保護の可能性はほぼ即座にゼロに近づく
これが緩和する脅威は何なのか気になる
対象のタイピングパターンを知っていれば、そのデータから内容を復元できる
対象に JavaScript が有効なブラウザでこちらが管理するウェブサイトに入力させたり、タイピング音を録音してパターンを収集したりできる
最近では、一部のオンライン配信者が、キーボードのタイピング音を学習した AI モデルでパスワードを盗む攻撃を受けたこともある
この機能はそれを防ぐためにノイズを追加するもののようだ
http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
機械学習が加わったことで音声復号の精度が大きく向上しているので、物理的に安全でない場所では静かなキーボードを使うのがよい
https://arstechnica.com/gadgets/2023/08/type-softly-research...
たとえばユーザーは通常、パスワードを他の入力より速く打つため、
sudoのような操作で一度にまとめて送信されたキー入力数を見てパスワード長を推測できるこの論文自体のユースケースはセキュリティ脅威ではないが、情報漏えいと解釈することはできる
どれくらい遅延が追加されるのか気になる
特に予測不能な遅延は、ソフトウェア開発作業で最大のストレス要因の一つだ
少量のデータだけが送信されるとき、対話型トラフィックを固定間隔で送る。デフォルトは 20ms
[1]
Mosh のようなツールは体感遅延を減らすのにかなり役立つ
Mosh はユーザーのキー入力がローカルで登録されるとすぐに表示し、往復が完了していないことを示すために薄い色で表示する
最後に見たときはそうだったし、もしかすると下線だったかもしれない
往復が完了すると文字が通常表示になる
[1] ソフトウェア開発で最大のストレス要因がキー入力遅延なら、かなり運がいいほうに聞こえる
[2]: https://mosh.org
実際のコミットリンク: https://github.com/openssh/openssh-portable/commit/7603ba712...
一部ではパケットのタイミングを測定して hands-on-keyboardシェル をネットワーク上で検知しているようですが、この変更がそうした検知をどれほど妨げるのか気になります
セキュリティへのアプローチとしては本当に間違っていると思います
自動化スクリプトが機器にログインしているかどうか分かると便利ではありますが、より良い設計なら、その情報が重要でなくなるようにできます