研究ブログ

2015/12/02

論文紹介『Improving SSL Warnings: Comprehension and Adherence』

Tweet ThisSend to Facebook | by akirakanaoka



論文紹介の前に

このエントリは「ヒューマンコンピュータインタラクション論文紹介 Advent Calendar 2015」の2日目のものです。Advent Calendarに参戦するのは初めてでよくわかりませんが、前日の湯村さんのエントリを参考にシコシコ書いてみます。

紹介するのはACM CHI 2015でFeltさんたちによって発表された"Improving SSL Warnings: Comprehension and Adherence"です。 Adrienne Porter Feltさんが筆頭著者で、そのほかにGoogleの方とUniversity of Pennsylvaniaの方による共著です。(共著者も大物ぞろいですが)

Adrienne Porter Felt

数年前まではAndroidのセキュリティ、特にPermissionに関する研究を多くされてきましたが、2012年を境にブラウザの研究にシフトしています。そのころにUCBからGoogleに移っているので、移ってからの研究ということなのでしょう。
http://www.adrienneporterfelt.com/

論文紹介


概要

ブラウザのSSL/TLSに関する警告は、利用者に適切に届いているとはまだ言えません。その警告をどうやって変えていくか。”Comprehension”と”Adherence”を達成することを目的として、現状の警告を「わかりやすい文章」「色使いを変えてみよう」というアプローチで変更し、その効果を測る実験を行いと、そして実際にChromeに搭載されたよ、というお話です。

ChromeのSSL/TLSに関する表示画面

現在のChrome46では、SSL/TLSが用いられていないときのアドレスバーの表示は以下の通りです。


SSL/TLSのサーバ証明書が適切に使われているときは、以下のように表示されます。

緑色をした錠前のアイコンと"https"の文字が見えます。

SSL/TLSのサーバ証明書には、さらにランクが高い(?)EV証明書があります。その証明書の場合、以下のように表示されます。


で、この論文で問題としている(いた)のは、サーバ証明書に問題があるときの警告画面です。Chrome46では冒頭に張り付けた画像のように表示されます。アドレスバーに赤い斜線がつくだけでなく、コンテンツ部分についても警告のアイコンと文言が出て接続先のコンテンツそのものは閲覧できないようになっています。
この画面はすでにこの論文で提案された手法が盛り込まれたものとなっています。Chrome36までは別の表示でした。同じようにコンテンツの閲覧は抑えるのですが、その画面は黄色がメインで、文言もより難しいものでした。

Feltらはここにメスを入れます。開発者がどのように利用者を行動させるべきかを考えたときに、彼らは「Comprehension(理解)」と「忠実さ(Adherence)」の2つが重要であると考えました。利用者はSSL/TLSの警告が出たらリスク・脅威を把握し、誤報(False Positive)の可能性があることを理解し、そしてその後の行動を決定するという「Comprehension」を持つ。またSSL/TLSの警告が出たらその先へは進まないという保守的な態度をとることに従う「Adherence」がある。しかしこれまでの他の研究から、いずれかあるいは双方とも満たしてこなかったということが示されてきました。

Feltさんたちの考えた手法はまず「Comprehension」の確立のためにより単純で簡潔そして非技術的で特化したメッセージが書かれるものにしようというものでした。そして「Adherence」の確立のために、利用者の次の行動への導線を明確にするようにしました。。文章の読みやすさの指標として、SMOGインデックスによる評価を用いた評価があります。3音節以上の単語数とセンテンス数から求められる数値で、その数値は米国の学年制度を基準としています。つまりSMOGインデックスが7の場合、日本で言う中学1年生が理解できるレベルであることを示しています。SSL/TLSのサーバ証明書に対する警告ページの最初の文章についてSMOGインデックスで評価したところ、Chrome 36では11.0だったものを提案手法(つまりChrome 37)では6.6に減少させました。そこには専門用語を使わない工夫を凝らしました。例えば証明書(Certificate)やオペレーティングシステム(Operating System)、セキュリティ認証情報(Security Credentials)などの専門性の高い用語は利用しないようにし、また文の量もシンプルなものにしました。変更前後の文章を和文・英文ともに見てみると、その違いがよくわかります。単純・簡潔にするだけでなく、パスワードやクレジットカードなど利用者が直観的にリスクを理解しやすいキーワードを利用していることもわかります。

変更前(和文):このサイトのセキュリティ証明書は信頼できません。***にアクセスしようとしましたが、サーバーから提示された証明書の発行元は、お使いのパソコンのオペレーティングシステムで信頼されていない発行元です。サーバーで独自に生成されたセキュリティ認証情報が、Chromeで認証情報として使用できないものであるか、悪意のあるユーザーが通信を傍受しようとしている可能性があります。先に進まないでください。このサイトについて今回初めてこの警告メッセージが表示された場合は特に注意が必要です。

変更前(英文):The site's security certificate is not trusted! Yor attempted to reach ***, but the server presented a certificate issued by an entity that is not trusted by your computer's operating system. This may mean that the server has generated its own security credentials, which Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications. You should not proceed, especially if you have never seen this warning before for this site.

変更後(和文):この接続ではプライバシーが保護されません。攻撃者が***上のあなたの情報(パスワード、メッセージ、クレジットカード情報など)を不正に取得しようとしている可能性があります。

変更後(英文):Your connection is not private. Attackers might be trying to steal your information from *** (for example, passwords, messages, or credit cards).

文章だけでなく、色についても変えました。他の文献や塔で、警告には赤色が向いているということが示されていますが、Chrome 37では赤色は警告画面上のアイコンだけにしました。それ以前では、文章部分では白色が使われていますが周辺の色を黄色にしていました。理由が2つあります。1つは、強く赤色を出すことは、他の脅威であるフィッシングサイトとマルウェアを含むサイトの警告画面で利用されていて、それらの脅威のほうがSSL/TLSの警告よりも強いと判断していることから、同じにすることを避けたというものです。もう1つは、ANSIでは赤色に次ぐ色としてオレンジ色・黄色を推奨していますが、オレンジは赤に色味が近く、また双方とも白・黒といった文字色とのコントラストが十分に得られないことなどから使用しないこととしました。

これらの変更について、ユーザ実験でその効果を試しました。比較対象はChrome36(適用前)、Chrome37(適用後)、IE11、Firefox31、Safari7です。その結果、残念ながら「Comprehension」についてはこれまでの表示との有効な差はあまりみることができませんでした。一方で、Adherenceについては高い効果を出すことが示されました。まだまだ戦いは続きそうです。ただ、文言が簡単になったのはChromeだけで、現時点でIEやFirefoxはまだChromeと比較して難しい文章が並んでいます。このあたりも今後変わっていくのか、注目してもよさそうです。

関連データなど


論文はGoogleのページで公開されています。
またFeltさんによる関連する話(ほぼ同じ?)の講演資料が公開されています。おそらくその資料を使ったのであろう別の場所での講演動画もあがっています。いやー便利な時代ですね。

16:02 | 投票する | 投票数(1) | コメント(0)
2014/09/25

情報セキュリティ関連の大学研究室Webサイトをまとめてみた

Tweet ThisSend to Facebook | by akirakanaoka
2016年8月26日: GitHubに移行しました!Pull requestがあれば修正追記対応できるように。
https://github.com/akirakanaoka/seclablist

情報セキュリティを大学や大学院で学びたい研究したい、という進学希望の方に向けて。Webページを持っていることが確認できた研究室だけ掲載していますので、このほかにもまだまだ研究室はあると思います。

2014年9月25日作成。順不同。
2014年9月30日追記。
2014年10月2日追記。
2015年6月5日追記・修正。
2016年4月4日追記・修正。
2016年4月6日追記・修正。
(9月30日追記)
いくつか「あそこがない」「うちがない」と指摘をいただいたのですが、アタマで書いているとおり「研究室Webを持っている研究室」というリストになっています。
研究室Webの中には、学科などの部署単位でひとまとめで作っている(=研究室自身が立ち上げたわけではない)ページがあるのと、所属(たとえば○○センターなど)によっては教員が研究室を持たないケースもあります。そういう研究室や先生方は載っておりませんでした。
ただ、そういう情報もあったら嬉しいという方はいらっしゃるようなので、知ってる限り載せていこうと思います。こちらも順不同。

あとはこのresearchmapに登録されている方のなかで自身の研究キーワードに「セキュリティ」を含んでいる方々のリストは…researchmapで探せばいいじゃない!

17:55 | 投票する | 投票数(7) | コメント(0)
2013/09/27

ユーザビリティ研究で実験をする時の落とし穴

Tweet ThisSend to Facebook | by akirakanaoka
セキュリティやプライバシーのユーザビリティ研究では、その提案手法の効果測定のために実際に人間に提案手法を試してもらい、その行動結果やその前後のインタビュー・ヒアリングを使って効果を測定するのが一般的です。

この効果測定はコツが必要というか作法がきちんとありまして、
セキュリティやプライバシではなくユーザビリティ、もっというとCHI(Computer Human Interaction)の世界での作法に近いようです。

その作法は、人間行動の観測手法や実験の対象となる母集団の特徴の記述といったことに加え、その実験をやるにあたって倫理的問題がないかの考察と倫理審査委員会での承認と、、、など多岐にわたります。

そこにセキュリティやプライバシの技術をずっと研究されてきた人たちがユーザビリティ研究に参入してくると、この作法から外れた評価をしてくるためにせっかくの提案がもったいないということが多々あるそうです。

そういったことをなくそうと、MicrosoftのStuart Schechterさんが”Common Pitfalls in Writing about Security and Privacy Human Subjects Experiments, and How to Avoid Them" という文書を作成し公開しています。

これは私みたいな技術だけをやってきた人間にとっては非常に勉強になる文書でしたので、Executive Summaryだけですが訳してみました。

----
1. State the hypothesis or hypotheses you are testing pre-
cisely.
あなたがテスト(検定)しようとしている仮説を正確に示すこと。

2. If testing a security hypothesis, have a clear and de-
fensible threat model.
セキュリティの仮説を検定する場合、明確かつ防御可能(弁護可能?)な脅威モデルを持つこと。

3. Avoid misleading yourself or your reader in any way,
especially in selling your contribution or in translating
results into conclusions.
著者自身や読者をミスリードすることを避けること。特に論文の貢献の売り込みや、結果からまとめを得るときの解釈の時に。

4. Carefully explain how participants' behaviors were ob-
served, scored, and then fed into statistical tests.
被験者の行動がいかに観察され、スコア化され、そして統計の検定に適用されたかについて注意深く説明すること。

5. Explain any ethical considerations of your experiment and disclose whether your study was approved by the ethics review board at your institution(s).
実験への倫理的な考察を説明すること。
そしてその研究は所属組織の倫理審査委員会の承認を得ているかどうか明らかにすること。


6. Disclose all limitations in your study design and results
that you are aware of.
ユーザスタディなどの設計や得られた結果についての制限で著者らが認識しているものはすべて開示すること。

7. Label all axes in graphs and add captions to ensure
figures are self explanatory.
グラフがそれ自身で説明されうるようにすべての軸にラベルを書き、説明文(キャプション)を加えること。

8. Do not assume that correlation implies causation
相関関係が因果関係を暗示すると思いこまないこと。

9. Do not conclude that a hypothesis is false because a statistical test failed to disprove the null hypothesis.
検定の結果、帰無仮説の棄却に失敗からといって
その仮説が間違っていると結論付けないこと。

10. Use a statistical test only when the requirements under which it is valid, such as data fitting a normal distribution or trials being independent, are met. (When in doubt, use a non-parametric test.)
正規分布への当てはめや試行が独立であることなど、要件が合致したときのみ統計テストを使うこと
(もし疑わしい場合はノンパラメトリック検定を使うこと。)

11. Don't be afraid to ask for help. Ask colleagues who were not involved in the research
to read an early draft of your paper.
助けを求めることを恐れないこと。
この研究に参加していない仲間・同僚に論文の草稿を読ませること。
17:39 | 投票する | 投票数(2) | コメント(0) | テクノロジー
2013/02/15

OpenSSLのECC最適化オプション

Tweet ThisSend to Facebook | by akirakanaoka
OpenSSLでは、1.0.1から楕円曲線暗号(ECC)の64ビット版の最適化実装を使えるオプションが加わりました。

その適用方法と、その効果について書いていこうと思います

オプションの概要

opensslのソースを展開して得られるファイル"CHANGE"の中身を見ると
以下のような記載があります。

  *) Add optional 64-bit optimized implementations of elliptic curves NIST-P224,
     NIST-P256, NIST-P521, with constant-time single point multiplication on
     typical inputs. Compiler support for the nonstandard type __uint128_t is
     required to use this (present in gcc 4.4 and later, for 64-bit builds).
     Code made available under Apache License version 2.0.

     Specify "enable-ec_nistp_64_gcc_128" on the Configure (or config) command
     line to include this in your build of OpenSSL, and run "make depend" (or
     "make update"). This enables the following EC_METHODs:

         EC_GFp_nistp224_method()
         EC_GFp_nistp256_method()
         EC_GFp_nistp521_method()

     EC_GROUP_new_by_curve_name() will automatically use these (while
     EC_GROUP_new_curve_GFp() currently prefers the more flexible
     implementations).
     [Emilia Käsper, Adam Langley, Bodo Moeller (Google)]

要約すると、
  • NIST-P224、NIST-P256、NIST-P521の楕円曲線用の64ビット版最適化実装をオプションだけど追加したよ
  • configするときに"enable-ec_nistp_64_gcc_128"ってやれば使えるよ

インストール


インストールはOpenSSLのLinuxでの通常インストールとほとんど変わりません。
configするときにenable-ec_nistp_64_gcc_128を追記すれば良いだけです。
"make depend してね"と言われるのでそれも実行します。


./config enable-ec_nistp_64_gcc_128
make depend
make
make test
make install


パフォーマンステスト

せっかくなのでその最適化オプションがどれほど効くのかを試してみました。

環境は以下の通り
  • マシン:Dell PowerEdeg R210 II
  • CPU : Intel Celeron G540 (2.40GHz)
  • RAM : 4GB
  • OS  : Linux (Ubuntu-12.10 desktop 64bit, kernel:3.5.0-17-generic)
テストは同じマシンにopensslの1.0.1dをオプション付きとオプションなしの2つを入れて、opensslのspeedコマンドを使って、ecdhとecdsaの2種類を10回ずつ行いました。

opensslのspeedコマンドは各作業(署名、検証、鍵交換など)の1回あたりの時間と、1秒あたり何回作業されたかが表示されます。
今回はその「1秒当たりに何回作業されたか」を使います。
下の表は、1行目がオプションなし、2行目がオプションあり、3行目が1行目と2行目の数値の比率になっていてオプション付きがオプションなしの何倍高速かを示すものとなっています。

ECDSA:署名

nonPatchPatchRatio
secp160r111003.4510905.330.99
nistp1929180.929208.061.00
nistp2247310.1711033.521.51
nistp2566249.916299.781.01
nistp3843259.223261.641.00
nistp5211721.842318.081.35
nistk1633331.43332.831.00
nistk2331686.81680.491.00
nistk2831104.121106.841.00
nistk409478.5478.61.00
nistk571220.77220.721.00
nistb16333453347.821.00
nistb2331697.111698.931.00
nistb2831100.651101.891.00
nistb409476.68475.811.00
nistb571220.92220.711.00

ECDSA: 検証

nonPatchPatchRatio
secp160r13187.543194.751.00
nistp1922646.572635.951.00
nistp2241874.645794.283.09
nistp2561628.682683.331.65
nistp384758.71751.420.99
nistp521348.761087.583.12
nistk1631326.341330.81.00
nistk2331035.621019.650.98
nistk283548.64545.470.99
nistk409322.29324.981.01
nistk571137.371381.00
nistb1631275.31270.221.00
nistb233991.96985.070.99
nistb283509.01511.041.00
nistb409297.78299.431.01
nistb571125.2126.181.01

ECDH

nonPatchPatchRatio
secp160r13854.543873.851.01
nistp1923220.533241.471.01
nistp2242280.88733.333.83
nistp2561983.063644.721.84
nistp384911.69914.761.00
nistp521419.131558.73.72
nistk1632749.062758.971.00
nistk2332172.312168.791.00
nistk2831129.131131.221.00
nistk409663.55672.011.01
nistk571281.522821.00
nistb16326192617.581.00
nistb2332057.032052.781.00
nistb2831049.041055.311.01
nistb409614.94617.241.00
nistb571255.45257.11.01

下は1秒あたりの作業回数のグラフ。赤いバーが今回の最適化オプションの対象となっているパラメータです。

ECDSA:署名


ECDSA署名の1秒当たりの回数

ECDSA:検証


ECDSA検証の1秒当たりの回数

ECDH

ECDHの1秒当たりの回数


ECDHで結構な効果が出ていますね。NIST-P224だと3.83倍、NIST-P521だと3.72倍。NIST-P256は1.84倍。
ECDSAだと、検証のほうが強く効果がでているのがわかります。NIST-P224だと3.09倍、NIST-P521は3.12倍、NIST-P256は1.65倍。署名のほうはNIST-P224で1.51倍、NIST-P256で1.01倍、NIST-P521で1.35倍。
署名に関してはNIST-P256は効果は無いと言い切っちゃっていいですね。

01:31 | 投票する | 投票数(3) | コメント(0) | テクノロジー