William Cheswick
Johnny can obfuscate; Beyond Mother's Maiden Name,
HotSec'06: 1st USENIX Workshop on Hot Topics in Security, pp,31-36, 2006
論文は上記のWebサイトから入手可能
チャレンジアンドレスポンス認証は固定パスワード/暗証番号認証より安全な認証方法だが、人間の計算能力は微々たるものなので、大抵の場合はresponseを生成するためのデバイスか印刷物(print out)が必要となる．そこで大リーグの「サイン」を参考に、challengeとresponseの双方を曖昧化(難読化(?) 元はobfuscate)することで、その安全性を高められるのでは? という内容の論文．
以下は走り書き
◆ Abstract
- チャレンジ and レスポンス認証は既存のパスワード認証より安全性が高い．
- しかも、challengeを計算するためのデバイスが必要となる．
- しかし人間の計算能力は微々たるもので、単純な応答しかできない
- もしchallengeとそれに対応するresponseをおとり情報を利用して、わかりにくくする(曖昧にする/難読化する)ことができたなら多くのアプリケーションにとって十分な安全性を持つ認証になるだろう
- メジャーリーグで利用されているサインを参考に、この曖昧化に関する方法について考えてみる
◆ Introduction
- パスワード認証に対する問題: 盗聴(eavesdropping)、推測(guessing)、辞書攻撃(dictionary attack)
- 盗聴と辞書攻撃を脅威から除外できるならば、パスワード認証は受け入れられる余地があると考える．が、しかし実際はそうではない．malwareの多くは盗聴を行う
- challenge and response認証は、これに変わる有効な候補だが、ハードウェアか秘密情報を計算するための印刷物を持つ必要がある．このような所有物に依存した認証はそれらを紛失してしまうと認証不能になってしまい、知識による認証よりも利便性が低く、設置負担もかかる
- 支援なしに人間がchallengeに対してresponseを計算できる手法について提案する
- これが実現できれば、コストを下げることができるとともに、パスワード認証と同等かそれ以上の利便性を提供できる
- ユーザはchallengeに対して簡単なresponseを計算し、それをresponseの中に隠すことで、何が正しい答えなのかを特定しにくくする
- これは楽しみながらできて、パスワードやパスフレーズによる厳密なスペル入力に変わる方法になると考える
- たまにしか使用しない認証のresponseは一文字でも十分であろう．問題は、それを隠蔽するための手法が推測に対して十分な安全性を確保できるかである
- 隠蔽が不十分であれば、responseを拒絶する(認証失敗?)こともできる
- 認証の試行回数は制限されるべきであろう
- 動機; 銀行や対話手法による認証の改善
-- パスワード認証の代替、または母親の旧姓(MMN)に代表されるバックアップ認証のかわりを実現するため
◆ Related Work
- パスワード認証、ワンタイムパスワード、画像認証、PAM(Linux Pluggable Authentication Modules)による実装
- pass-algorithm and reconstructed passwords
- zero knowledge authentication
- human-computer cryptography
- HumanAut
- Secure Human-Computer Identification (secHCI)
- cognitive trapdoor games
- human interactive proofs(HIP)
- Text-based pass-algorithmsには2つのカテゴリ
-- ad hoc
-- information theoretic
- information theoreticは、安全性確保のための十分に長いパスワードと利便性(記憶可能性)とのトレードオフに取り組んでいる(もがいている)
- port knocking: あるポートに連続してアクセス、または特殊なパケットを送付することでサーバのロックを解除する方法 (参考文献[7]参照)
◆ Baseball Signs
- 野球の試合では多数のサインが使われている．
- 多数の人の監視の中でコーチと選手は重要な情報をやりとりしている
- 敵のチームが困惑するような様々な技術をサインのやりとりに使用している
◆ Pitcher/Catcher communication
- キャッチャーはピッチャーに複数のサインを出し、ピッチャーはそれに応じるか否かを答える
-- 2塁にランナーがいるとサインがばれるので、それを防ぐための技術が必要
- キャッチャーはサインを盗まれるのを防ぐために、いくつかの方法を利用する
[例]
-- 最初のn個のサインは無視する
-- Nに達するまでサインを加算し、Nを越えた次のサインをサインとする
-- indicator signが出るまでサインを無視し、その次のサインをサインとする
-- スコアボードの値を、与えられたサインに加算し、その値をサインとする
- などなど、パスワードのアルゴリズムと同様、多数の仕組みが作られている
◆ Signs from the third or first base coach
- 20以上のサインを使い分ける．しかもそれはgame毎にまたはinning毎に変更されることもある
- サインの大部分は意味がなく(おとりサイン)、indicator signがあって、その次のサインがhot sign．つまり指令となる
- 双眼鏡を持った人間をスコアボード付近や球場外の建物に潜ませたり、ブザー音を使ったり、近隣の宣伝を使用することもある
- 「サインを盗むのに一番大事なのは、そのサインの出所を見つけることだ」
◆ Experiments
◆ Unlocking a queue manager
- プリンタのキューのロック解除のための仕組みを作り、利用していた
- 時刻を基に、responseを計算する．おとり入力として適当に3文字を入力し、そのあと4文字目としてロック解除のためのresponseとして数字1桁を入力していた
- 利便性評価はしていないが、うまく利用されていて、文句を言われたことはなかった
- そして驚くことに、自分はそのアルゴリズムを20年経った今でも記憶していることだ
◆ Login Authentication Test
- 単純なhuman-computed challenge/response 用のPAMモジュールを生成し、自身で数ヶ月運用
- その認証のログが図1．ここから認証用のアルゴリズムが導出できるかが問題．実際の検証用コードは図2
- 時々困ることがあった、なのでbackdoor entryを用意していた => どうして、どんな時に困ったのだろう...
- 図1のresponseから、それら個々が正解なのか不正解なのかを計算するのは容易ではないだろう
- 自動解析も困難に見える
◆ Discussion
- ユーザに課される作業
-- challengeに対する正しいresponseの生成
-- 入力時に正解responseを隠すための曖昧化作業
- Indicatorかwipe-outサインがchallengeに隠蔽される方法も
- キーボードを利用して数字を文字にマッピングする方法も曖昧化の一つの手段
- 当たり前だが、年に数回しか使用しないような認証では、パスワードの記憶が困難であるのと同様パスワードアルゴリズムの記憶も困難である可能性が高い
- algorithmic passwordは万人向けの手法とは言いがたい
-- 認証手法を選択するような場面で、その選択肢の一つとしてはありかもしれない
- 若いユーザならば楽しんで使うかもしれない
- ユーザは複数のサイト(サービス)にわたって同一のパスワードを使用している．が、本手法で同じ検証用アルゴリズムを使用し、サイト毎に異なるIndicator または wipe-outシンボルを使用するならば、一カ所のパスワードが漏洩することで、複数のサービスへの不正利用が可能になるというような脅威に対する安全性を向上させることも可能であろう
◆ Open Question
- 曖昧化を用いながら、利便性と記憶可能性を両立できるパスワードアルゴリズムを生成できるだろうか? また生成できたとして、それが重要なアプリケーションで受け入れられる程度の安全性を実現できるか?
- brute-force攻撃はパスワードアルゴリズムのクラックを可能にしうる方法か?
- どの程度の割合のユーザが、パスワードアルゴリズムに肯定的で、かつ楽しんで使うだろうか?
- 単一のパスワードアルゴリズムで複数のindicator または wipe-outサインによる複数サイトの認証が、多数のWebサイトサービスに対する認証において同一のパスワードを使用することによる脆弱性への対策となりうるか
- ユーザによる曖昧化が時々盗聴している攻撃者に対して十分安全か?
- パスワードアルゴリズムは、通常の認証の代替になりうるか? または追加的な認証になりうるか?
- 自分自身でパスワードアルゴリズムを作ることが許されるべきか?
- ユーザが自身でパスワードアルゴリズムを作ったとした場合、適切な安全性を保持していることを確認するための自動化テストとしてはどのような方法があるべきか?
- 認証履歴が記録されるとして、これが攻撃者に渡ったら、明らかに危険である
◇ 私感
自前パスワード検証アルゴリズムによるchallenge/response認証を提案．responseは算出支援機器/情報なしに簡単に生成でき、かつそのresponseを曖昧化(おとり情報を利用して隠蔽)して返答することで、既存の認証手法の改善を試みる．
というか、検証用アルゴリズムにある種の秘密を仕込み、その検証用アルゴリズムで検証に成功するように、回答を曖昧化して回答すれば、より安全な認証システムになるという論文と理解．見方を変えれば、challengeなしでも運用は可能ではないかと考える．というか、パスワードアルゴリズム自体をがchallengeと見てもいいのではないだろうか? ようするに認証時に入力するパスワードは、正解情報を含む文字列なのだが、それはランダム(であるべき)文字列の中に隠蔽(Obfuscate)され、それは毎回異なる文字列であることが望ましい．そうすれば、仮に認証がplain textとして攻撃者に盗聴されたとしても、その記録から秘密情報を抽出するのは困難である．という仕組みと理解
個人的意見として、真の秘密情報以外にも余分な情報を入力しなければならない認証手法は、余分な入力と、「おとり情報入力」に関する思考を強いられるという点で否定的であった．が、うまくごまかせられるのであれば、こういう方法もありかもな．と、この論文を読んで考えるようになった．だとすると、松本先生が提案されているあの方法(参考文献[?])もありかもしれない．再検討の余地はあるなと
Posted by z at April 19, 2008 06:08 PM