研究ブログ
論文紹介『Improving SSL Warnings: Comprehension and Adherence』
論文紹介の前に
このエントリは「ヒューマンコンピュータインタラクション論文紹介 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)などの専門性の高い用語は利用しないようにし、また文の量もシンプルなものにしました。変更前後の文章を和文・英文ともに見てみると、その違いがよくわかります。単純・簡潔にするだけでなく、パスワードやクレジットカードなど利用者が直観的にリスクを理解しやすいキーワードを利用していることもわかります。
変更後(和文):この接続ではプライバシーが保護されません。攻撃者が***上のあなたの情報(パスワード、メッセージ、クレジットカード情報など)を不正に取得しようとしている可能性があります。
変更後(英文):Your connection is not private. Attackers might be trying to steal your information from *** (for example, passwords, messages, or credit cards).
変更前(和文):このサイトのセキュリティ証明書は信頼できません。***にアクセスしようとしましたが、サーバーから提示された証明書の発行元は、お使いのパソコンのオペレーティングシステムで信頼されていない発行元です。サーバーで独自に生成されたセキュリティ認証情報が、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さんによる関連する話(ほぼ同じ?)の講演資料が公開されています。おそらくその資料を使ったのであろう別の場所での講演動画もあがっています。いやー便利な時代ですね。
これらの変更について、ユーザ実験でその効果を試しました。比較対象はChrome36(適用前)、Chrome37(適用後)、IE11、Firefox31、Safari7です。その結果、残念ながら「Comprehension」についてはこれまでの表示との有効な差はあまりみることができませんでした。一方で、Adherenceについては高い効果を出すことが示されました。まだまだ戦いは続きそうです。ただ、文言が簡単になったのはChromeだけで、現時点でIEやFirefoxはまだChromeと比較して難しい文章が並んでいます。このあたりも今後変わっていくのか、注目してもよさそうです。
関連データなど
論文はGoogleのページで公開されています。
またFeltさんによる関連する話(ほぼ同じ?)の講演資料が公開されています。おそらくその資料を使ったのであろう別の場所での講演動画もあがっています。いやー便利な時代ですね。
0
情報セキュリティ関連の大学研究室Webサイトをまとめてみた
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日追記・修正。
https://github.com/akirakanaoka/seclablist
2014年9月25日作成。順不同。
2014年9月30日追記。
2014年10月2日追記。
2015年6月5日追記・修正。
2016年4月4日追記・修正。
2016年4月6日追記・修正。
筑波大学 暗号・情報セキュリティ研究室 (岡本栄司先生、西出隆志先生、金山直樹先生)筑波大学 機械学習/データマイニング研究室 (佐久間淳先生)筑波大学 オペレーティングシステムとシステムソフトウェア研究室 (加藤和彦先生、阿部洋丈先生、長谷部浩二先生、杉木章義先生、岡瑞起先生、橋本康弘先生)東京電機大学 情報セキュリティ研究室 (佐々木良一先生、猪俣敦夫先生、柿崎淑郎先生)東京理科大学 金子研究室 (金子敏信先生) ※五十嵐保隆先生のお名前もメンバーに入っているが現在は鹿児島大学東京理科大学 岩村研究室 (岩村惠市先生、姜玄浩先生)神戸大学 情報通信研究室(ES3) (森井昌克先生、白石善明先生)明治大学 菊池研究室 (菊池浩明先生)明治大学 情報セキュリティ研究室 (齋藤孝道先生)静岡大学 西垣研究室 (西垣正勝先生)岩手県立大学 コミュニケーション学講座 (齊藤義仰先生、西岡大先生)岩手県立大学 分散システム学講座 (高田豊雄先生、ベッドB.ビスタ先生、王家宏先生、児玉英一郎先生、加藤貴司先生)岡山大学 山内(田端)研究室 (山内利宏先生)岡山大学 田野・山根・野上研究室 (田野哲先生、山根延元先生、野上保之先生)岡山大学 分散システム構成学研究室 (舩曵信生先生、栗林稔先生)奈良先端科学技術大学院大学 情報基盤システム学研究室 (藤川和利先生、新井イスマイル先生、猪俣敦夫先生)奈良先端科学技術大学院大学 インターネット工学研究室 (山口英先生、門林雄基先生、奥田剛先生、櫨山寛章先生、樫原茂先生、Doudou Fall先生)立命館大学 サイバーセキュリティ研究室 (上原哲太郎先生)立命館大学 毛利研究室 (毛利公一先生、瀧本栄二先生)横浜国立大学 情報・物理セキュリティ研究拠点 (松本勉先生、四方順司先生、吉岡克成先生)四方研究室 (四方順司先生)早稲田大学 森達哉研究室 (森達哉先生)東京大学 松浦研究室 (松浦幹太先生、Miodrag Mihaljevic先生)東京大学 山本-國廣研究室 (山本博資先生、國廣昇先生、本多淳也先生)東京大学 中川研究室 (中川裕志先生、佐藤一誠先生、荒井ひろみ先生)東京大学 品川研究室 (品川高廣先生)東京大学 関谷研究室 (関谷勇司先生)京都工芸繊維大学 情報セキュリティ研究室 (稲葉宏幸先生)名古屋大学 情報セキュリティ研究グループ (岩田哲先生)名古屋大学 村瀬・嶋田研究室 (村瀬勉先生、嶋田創先生、山口由紀子先生)東京工科大学 市村研究室 (市村哲先生)北陸先端科学技術大学院大学 宮地研究室 (宮地充子先生、面和成先生、布田裕一先生、蘇春華先生、田中覚先生)面研究室 (面和成先生)北陸先端科学技術大学院大学 篠田研究室 (篠田陽一先生、宮川晋先生、知念賢一先生、宇多仁先生、井上朋哉先生)情報セキュリティ大学院大学 田中研究室 (田中英彦先生、橋本正樹先生)情報セキュリティ大学院大学 後藤研究室 (後藤厚宏先生)情報セキュリティ大学院大学 有田研究室 (有田正剛先生)情報セキュリティ大学院大学 大久保研究室 (大久保隆夫先生)情報セキュリティ大学院大学 佐藤研究室 (佐藤直先生)情報セキュリティ大学院大学 土井研究室 (土井洋先生)情報セキュリティ大学院大学 原田研究室 (原田要之助先生)情報セキュリティ大学院大学 湯浅研究室 (湯淺墾道先生)情報セキュリティ大学院大学 林研究室 (林紘一郎先生)情報セキュリティ大学院大学 廣松研究室 (廣松毅先生)電気通信大学 沼尾研究室 (沼尾雅之先生)電気通信大学 太田・岩本研究室 (太田和夫先生、岩本貢先生)電気通信大学 﨑山研究室 (﨑山一男先生)電気通信大学 吉浦・市野研究室 (吉浦裕先生)電気通信大学 大山研究室 (大山恵弘先生、高橋一志先生)電気通信大学 高田研究室 (高田哲司先生)東京工業大学 小池研究室 (小池英樹先生、佐藤俊樹先生)東京工業大学 尾形研究室 (尾形わかは先生)東京工業大学 田中研究室 (田中圭介先生)広島大学 計算機基礎学研究室 (中西透先生、今井克暢先生)九州大学 櫻井研究室 (櫻井幸一先生、川本淳平先生、Samiran Bag先生)九州大学 高木研究室 (高木剛先生、安田雅哉先生、モロゾフ キリル先生、Duong Hoang Dung先生)大阪大学 藤原研究室 (藤原融先生、石原靖哲先生、矢内直人先生)福井大学 情報通信システム研究室 (廣瀬勝一先生、田辺英彦先生)東北大学 青木研究室 (青木孝文先生、本間尚文先生、伊藤康一先生)工学院大学 分散アルゴリズム研究室 (真鍋義文先生)京都大学 岡本・阿部研究室 (岡本龍明先生、阿部正幸先生)茨城大学 黒澤馨研究室 (黒澤馨先生)埼玉大学 暗号基盤研究室 (小柴健史先生)情報学研究所 越前研究室 (越前功先生)情報学研究所 曽根原研究室 (曽根原登先生)防衛大学校 コンピュータ工学研究室 (黒川恭一先生、田中秀磨先生、岩井啓輔先生)秋田大学 山村研究室 (山村明弘先生、Szilard Zsolt Fazekas先生、高谷眞弓先生)神奈川大学 松尾和人研究室 (松尾和人先生)広島市立大学 組み込みデザイン研究室 (中田明夫先生、島和之先生、双紙正和先生、村田佳洋先生、佐藤康臣先生)神奈川工科大学 マナブ研 (岡本学先生)慶應大学 河野研究室 (河野健二先生)慶應大学 笹瀬研究室 (笹瀬巌先生)名古屋工業大学 齋藤研究室 (齋藤彰一先生)はこだて未来大学 高橋・中村研究室 (高橋修先生、中村嘉隆先生)九州工業大学 光来研究室 (光来健一先生)金沢工業大学 千石靖研究室 (千石靖先生)鳥取大学 計算機工学(A|B)研究室 (菅原一孔先生、川村尚生先生、高橋健一先生、笹間俊彦先生)日本大学 栃窪研究室 (栃窪孝也先生)東海大学 大東研究室 (大東俊博先生)千葉大学 青木今泉研究室 (青木直和先生、今泉祥子先生)
東邦大学 金岡研究室 (金岡晃)
いくつか「あそこがない」「うちがない」と指摘をいただいたのですが、アタマで書いているとおり「研究室Webを持っている研究室」というリストになっています。
研究室Webの中には、学科などの部署単位でひとまとめで作っている(=研究室自身が立ち上げたわけではない)ページがあるのと、所属(たとえば○○センターなど)によっては教員が研究室を持たないケースもあります。そういう研究室や先生方は載っておりませんでした。
ただ、そういう情報もあったら嬉しいという方はいらっしゃるようなので、知ってる限り載せていこうと思います。こちらも順不同。
東京農工大学 山井研究室 (山井成良先生)法政大学 尾花賢先生
法政大学 金井敦先生慶應大学 武田圭史研究室 (武田圭史先生)早稲田大学 後藤研究室 (後藤滋樹先生)神奈川大学 森田光先生神奈川大学 暗号システム研究室 (藤岡淳先生、野崎隆之先生)はこだて未来大学 白勢政明先生東京工業大学 藤崎英一郎研究室 (藤崎英一郎先生)中央大学 趙研究室 (趙晋輝先生)中京大学 インターネット崩壊研究室 (鈴木常彦先生)東京大学 宮本大輔先生東京大学 山口利恵先生東京工科大学 インターネットセキュリティとOS研究室 (木下俊之先生)東京工科大学 情報セキュリティ研究室 (宇田隆哉先生)千葉大学 多田充先生筑波技術大学 岡本健先生富山大学 沖野浩二先生弘前大学 長瀬智行先生金沢大学 満保雅浩先生金沢大学 安永憲司先生宮崎大学 岡崎直宣先生関西大学 桑門秀典先生九州産業大学 下川俊彦先生信州大学 田中清先生佐賀大学 堀良彰先生静岡理工科大学 情報・物理セキュリティ研究室 (大石和臣先生)北九州市立大学 佐藤敬先生鳴門教育大学 曽根直人先生九州工業大学 中村豊先生国立情報学研究所 高倉弘喜先生東京理科大学 五十嵐保隆先生慶應義塾大学 手塚悟先生長崎県立大学 情報セキュリティ学科小松文子先生、チャットウィチェンチャイ ソムチャイ先生、山口文彦先生(あと業績ページあたりから他の先生の名前も見ることができますがそれは保留。それをやると他大学の分とか超めんどくさい)東京電機大学 稲村勝樹先生
あとはこのresearchmapに登録されている方のなかで自身の研究キーワードに「セキュリティ」を含んでいる方々のリストは…researchmapで探せばいいじゃない!
0
ユーザビリティ研究で実験をする時の落とし穴
セキュリティやプライバシーのユーザビリティ研究では、その提案手法の効果測定のために実際に人間に提案手法を試してもらい、その行動結果やその前後のインタビュー・ヒアリングを使って効果を測定するのが一般的です。
この効果測定はコツが必要というか作法がきちんとありまして、
セキュリティやプライバシではなくユーザビリティ、もっというと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.
助けを求めることを恐れないこと。
この研究に参加していない仲間・同僚に論文の草稿を読ませること。
この効果測定はコツが必要というか作法がきちんとありまして、
セキュリティやプライバシではなくユーザビリティ、もっというと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.
助けを求めることを恐れないこと。
この研究に参加していない仲間・同僚に論文の草稿を読ませること。
0
OpenSSLのECC最適化オプション
OpenSSLでは、1.0.1から楕円曲線暗号(ECC)の64ビット版の最適化実装を使えるオプションが加わりました。
その適用方法と、その効果について書いていこうと思います
下は1秒あたりの作業回数のグラフ。赤いバーが今回の最適化オプションの対象となっているパラメータです。
その適用方法と、その効果について書いていこうと思います
オプションの概要
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のspeedコマンドは各作業(署名、検証、鍵交換など)の1回あたりの時間と、1秒あたり何回作業されたかが表示されます。
今回はその「1秒当たりに何回作業されたか」を使います。
下の表は、1行目がオプションなし、2行目がオプションあり、3行目が1行目と2行目の数値の比率になっていてオプション付きがオプションなしの何倍高速かを示すものとなっています。
ECDSA:署名
nonPatch | Patch | Ratio | |
secp160r1 | 11003.45 | 10905.33 | 0.99 |
nistp192 | 9180.92 | 9208.06 | 1.00 |
nistp224 | 7310.17 | 11033.52 | 1.51 |
nistp256 | 6249.91 | 6299.78 | 1.01 |
nistp384 | 3259.22 | 3261.64 | 1.00 |
nistp521 | 1721.84 | 2318.08 | 1.35 |
nistk163 | 3331.4 | 3332.83 | 1.00 |
nistk233 | 1686.8 | 1680.49 | 1.00 |
nistk283 | 1104.12 | 1106.84 | 1.00 |
nistk409 | 478.5 | 478.6 | 1.00 |
nistk571 | 220.77 | 220.72 | 1.00 |
nistb163 | 3345 | 3347.82 | 1.00 |
nistb233 | 1697.11 | 1698.93 | 1.00 |
nistb283 | 1100.65 | 1101.89 | 1.00 |
nistb409 | 476.68 | 475.81 | 1.00 |
nistb571 | 220.92 | 220.71 | 1.00 |
ECDSA: 検証
nonPatch | Patch | Ratio | |
secp160r1 | 3187.54 | 3194.75 | 1.00 |
nistp192 | 2646.57 | 2635.95 | 1.00 |
nistp224 | 1874.64 | 5794.28 | 3.09 |
nistp256 | 1628.68 | 2683.33 | 1.65 |
nistp384 | 758.71 | 751.42 | 0.99 |
nistp521 | 348.76 | 1087.58 | 3.12 |
nistk163 | 1326.34 | 1330.8 | 1.00 |
nistk233 | 1035.62 | 1019.65 | 0.98 |
nistk283 | 548.64 | 545.47 | 0.99 |
nistk409 | 322.29 | 324.98 | 1.01 |
nistk571 | 137.37 | 138 | 1.00 |
nistb163 | 1275.3 | 1270.22 | 1.00 |
nistb233 | 991.96 | 985.07 | 0.99 |
nistb283 | 509.01 | 511.04 | 1.00 |
nistb409 | 297.78 | 299.43 | 1.01 |
nistb571 | 125.2 | 126.18 | 1.01 |
ECDH
nonPatch | Patch | Ratio | |
secp160r1 | 3854.54 | 3873.85 | 1.01 |
nistp192 | 3220.53 | 3241.47 | 1.01 |
nistp224 | 2280.8 | 8733.33 | 3.83 |
nistp256 | 1983.06 | 3644.72 | 1.84 |
nistp384 | 911.69 | 914.76 | 1.00 |
nistp521 | 419.13 | 1558.7 | 3.72 |
nistk163 | 2749.06 | 2758.97 | 1.00 |
nistk233 | 2172.31 | 2168.79 | 1.00 |
nistk283 | 1129.13 | 1131.22 | 1.00 |
nistk409 | 663.55 | 672.01 | 1.01 |
nistk571 | 281.52 | 282 | 1.00 |
nistb163 | 2619 | 2617.58 | 1.00 |
nistb233 | 2057.03 | 2052.78 | 1.00 |
nistb283 | 1049.04 | 1055.31 | 1.01 |
nistb409 | 614.94 | 617.24 | 1.00 |
nistb571 | 255.45 | 257.1 | 1.01 |
下は1秒あたりの作業回数のグラフ。赤いバーが今回の最適化オプションの対象となっているパラメータです。
ECDSA:署名
ECDSA:検証
ECDH
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は効果は無いと言い切っちゃっていいですね。
0