SSL/TLSでBEASTを恐れてRC4を優先するのは危ない
前職のお仕事で電子政府推奨暗号リストの改定作業を行う暗号技術検討会の事務局をやってたのですが、それ関係の話。3/1付けで電子政府推奨暗号リストあらためCRYPTREC暗号リストが公表されたのですが…
電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)に対する意見募集の結果
今回の改定では、電子政府で広く使われているがすでに危殆化が始まっているものを「運用監視暗号リスト」にするということが行われたのですが、今回その扱いにされた暗号のうち代表的なものがストリーム暗号RC4です。この件、もう少し大きな話題になってもいいと思うのですが…
残った国産暗号はCamelliaとKCipher-2 他は消えたのではなく推奨候補暗号リストになった 今回のハイライトの一つはRC4の運用監視暗号リスト行きだと思うのだけど昨日のシンポジウムでは意外と話題にならなかったな / “1…” htn.to/imdZTf
— 上原 哲太郎さん (@tetsutalow) 2013年3月26日
…話題にならないのでちょっと解説。
RC4はストリーム暗号としては大変広く使われていますが、同時にいろんな脆弱性があることでも知られてきました。今回のCRYPTRECによる調査では「同一の平文を異なる(多数の)暗号鍵で暗号化した場合平文が復元できてしまう」という問題が明らかになり、運用監視暗号リスト行きの決め手の一つとなりました。このことを示す技術報告書はすでに公開されています。
これ、RC4の危殆化が一段と進んだことを表してて、危険な兆候だと思っております…なのに、そのことが話題にならないのは、その危機感が暗号業界以外で理解されにくいから、なんでしょうか。
RC4はWEPやSSL/TLSで広く使われてますが、WEPが脆弱であることが広く知られているのに比べ、SSL/TLSでのRC4はそれほど恐れられてきませんでした。SSL/TLSでは多くの暗号が選べますが、メジャーなのはRC4_128_SHAとかAES_128_CBC_SHAあたりでしょうか。通常の発想では、従来より脆弱性が指摘されているRC4よりはAESを優先にするべきとなるところですが、最近はむしろSSL/TLSではRC4を優先すべきという論調が増えていました。というのは、ここ1~2年のうちにSSL/TLSにおいてAESを含むブロック暗号をCBCモードで使っている際に有効なBEAST攻撃やLucky13攻撃などが報告されてきており、その対策としてRC4への移行が促されてきたからです。
MS12-006 SSL/TLS の脆弱性のちょっと詳しい解説(Microsoft TechNet Blog: 日本のセキュリティチームによるBEAST攻撃の解説)
Nadhem J. AlFardan and Kenneth G. Paterson: Lucky Thirteen: Breaking the TLS and DTLS Record Protocols (PDF)(Lucky13攻撃の原著論文:対処としてRC4の利用について言及されている)
実際、GoogleやFacebook、TwitterなどがRC4を優先にしているのもそういう事情があるようです(まぁ単純に負荷が低いからと言う事情もありそうですが、昨今はAES-NIが使えるCPUが増えてますからAESでも変わらないかむしろ負荷は下がるように思います)。
しかし今回、RC4の危殆化が明らかになったことでまた話が変わってきました。BEAST攻撃やLucky13攻撃は暗号学的には目新しいところはないのですが、技術の組み合わせの妙によって実際の攻撃が可能であることを示して見せたあたりに目新しさがある、というのが私の理解です。一方、RC4に関しては本体の暗号学的な脆弱性の進展がありましたので、ここにBEASTあたりで使われていた各種技法を取り入れることによって、かなりの現実味を持って平文を回復する攻撃を作り上げることができそうな状況にあると見ています。SSL/TLSにおける平文の回復で一番厄介なのはセッション等に使われているCookieを外部から読まれることで、そこまで可能になれば脅威はかなり大きなものとなります。
なので、少なくともSSL/TLSにおいてBEASTを恐れてRC4を優先にするのは脅威を軽減できていないという意味でかなりナンセンスな状況ですし、RC4に対する攻撃の脅威がBEASTを一気に飛び越しかねないと思います。なので、そうなってしまう前にBEASTをはじめとする各種攻撃の回避へのWorkaroundとしてRC4を推奨する記述を消して回った方がいいと思うんですけど、どうしたらいいんでしょうね??私も言えるところには言っていこうと思ってますけど、私一人では限界があるので、この話を理解して頂いて賛同頂いた方には是非、ご協力をお願いしたいのですが…
ついで。以下の記事はAlFardan, Bernstein, Paterson, Poettering and Schuldtの成果のように書いてますけど…
A Few Thoughts on Cryptographic Engineering: Attack of the week: RC4 is kind of broken in TLS
こちらの、五十部-渡邉-大東-森井の方が早いです。
転職のご挨拶
一日遅れになってしまいましたが、ご報告です。4月1日付けで立命館大学に採用していただき情報理工学部情報システム学科に教授として着任しました。
既に申し上げたとおり京大から総務省に出向していたわけですが、ちょっと我が儘をお願いしまして任期(といってもはっきりとはしていなかったのですが一応2年程度)の満了前に辞めさせて頂きまして立命に移ることにしました。そのため大変面倒な事務作業が発生してしまい大変ご迷惑をおかけしました。お骨折り頂いた各位に御礼申し上げます。
昨年、立命館の情報理工学部から4学科合わせて6人もの教授公募人事がでまして、求職中の私としては絶好のチャンスでした。昨今の情報系教授人事は、私と同世代の研究者が教授適齢期であることと、このごろの総合電機メーカーの不振で企業研究者の大学教員への転身が増えていることから倍率は本当に高くなってしまい、ある程度名の通った大学だとすぐに50倍100倍となってしまう(首都圏では200倍とかいう話もきいて目眩しました)状況でしたので、一気に複数のポストが公募されて倍率が下がると思われるこの機会を逃したくなかったのです。実際読みは当たったようで、なんとかうまく滑り込むことが出来ました。拾って頂いて感謝しております。
立命館大学では情報システムのセキュリティやインターネットセキュリティを中心に、コンテンツ管理とかデジタルフォレンジックとかいうあたりを掲げて研究していきたいと思ってます。情報システム学科というところは今時めずらしく、比較的基礎の情報科学、情報システム学をしっかり教えるところです。こういうカリキュラムで育つ学生は計算機の基本原理に詳しくなるはずです。そういう中から、ソフトウェア脆弱性といったようなセキュリティの根幹技術の話をきちんと理解できた上で、さらに幅広い知識を持つセキュリティ技術者をどのように育てるか、ということが私の一つのテーマになるのだろうと思います。
これまで京大でお世話になった皆様に感謝申し上げるとともに、今後ともご指導ご鞭撻を賜りますようよろしくお願い申し上げます。
震災から2年
あの日から2年経ちました。改めて亡くなられた方のご冥福をお祈りし、今も不自由な生活をされている多くの方々に心からお見舞いを申し上げたいと思います。
2年前のTwilogみてみると…なんか揺れた直後に津波を心配し、友人の身を一通り案じた後は、意識がひたすら原発にいってたなぁと。
上原 哲太郎(@tetsutalow)/2011年03月11日 - Twilog
私は原発の専門家ではないけど多分普通の人よりは原発の構造が理解できていたと思いますので、正確に状況を想像出来ていたと思います。2号機の圧力抑制室破損の報せには本当に涙を流して泣きました。事態は私が予想していた中でも最悪に近いシナリオで進みましたが、それでもなんとか原発の冷却状態を取り戻せたことは不幸中の幸いですし、残る山積する問題に真剣に取り組まれている人たちには本当に頭が下がる思いです。
あの日から数日経った頃には、私の頭の中にはこの国についてもっと辛いシナリオばかり渦巻いていました。端的には原発の風評被害で農水産物から工業製品に至るまで輸出が大打撃を受けたり、電力不足が深刻化してこの国の経済が痛み、一方復興と原発廃炉処理の負担が増して疲弊していくようなシナリオです。とはいえ、知恵を集めれば解決は少しは回避されるのではないかと思ってました。
IAEAや米国に協力を要請するのもいいがもう全電力会社と全大学の原子力専門家集めるべきじゃないの
— 上原 哲太郎さん (@tetsutalow) 2011年3月14日
もう誰も経験したことがない事態なんだから経験より知恵じゃないですか? もちろん経験者からの意見に聞く耳持たない専門家は有害ですが。 QT @kojiando: BWRはおそらく東電が一番詳しい。大学の先生は現場の運用には詳しくないと思われる。
— 上原 哲太郎さん (@tetsutalow) 2011年3月14日
リスクシナリオを複数考え今のうちにプランニングすること、リスクポイントをどんどん洗い直しておくことが重要かと思う。官邸と東電のあの本部はもちろんそれくらい考えていると思いたいが、知恵が足りないなら早く外に求めて欲しい。特にリスクポイントは、目玉が沢山あると気づきも多いはずだ。
— 上原 哲太郎さん (@tetsutalow) 2011年3月15日
ここでは原発のことばかり言ってますが、あらゆる問題について大学人の持つ知恵を集めることで解決が早まるのではないかと、そんなことを考えていました。なので、提案を受けてからずっと迷っていた霞ヶ関への出向に関して覚悟を決めました。私にも何か出来ることがあるんじゃないかと。
転職(出向)しました - 2011-10-03 Tetsu=TaLowの雑記
で、総務省に来てから1年半経ちました。
結果的に言うと私、正直なところ全く力が足りませんでした。残念無念です。
入省直後、一番やりたかったこと=震災復興に直接役立つ仕事には手が届いていないことははっきりしていました。まぁ専門家ではないのだから仕方がないかなとそれは早々に諦めて、ならば、代わりに与えられたことで自分の知見を生かして精一杯やればいいのかと思ったんですが…所詮官僚としてはポンコツなわけで、何でも出来るわけじゃありません。当初与えられた通信の標準化(しかも「セキュリティ関係は除く」)の仕事はどうにも専門から遠く力が出ません。すぐに「もう少し私の力が生きる部署に異動させてくれませんか」と波風を起こす要求に出てみました(前例がないことですから、当時、うちの組織は途方に暮れたでしょうね…)
幸い、ほぼ1年かけていろいろな方のご努力で、この状況の中で、私がこの組織の中で過ごす時間がより生きるよう、セキュリティ対策室への併任をかけてもらえました。そのおかげで特に電子政府推奨暗号の改定という難しい仕事の大詰めの部分に関われたことは自分でもよかったし、多少なりとも国のお役に立てたのではないかと自負しています。他にもいくつか興味深い仕事をさせていただけました。
ただ、そうして仕事を続けるうち、山積する重要課題を解決するために、あまりにも遠回りしているのではないかという思いも強くなりました。私個人も個々やっていることは決して無駄じゃないと思ってるし、霞ヶ関の住人の多くは自分の担当に真剣に取り組んでおられるのですが、そのままでいいとは思えませんでした。国として解決すべき問題の優先順位がある中で、予算や人的リソースの配分のバランスが必ずしもそれに合致しているように見えないのです。しかし私のような下っ端ではデシジョンメークの場にあまりに遠く、そのバランスを修正できる機会はありません。さりとて、自分自身で動いて重要課題(と私が感じている)仕事をしている組織内の他の部署の人たちに手伝いに行くのも、組織の仕組み上どうしても限界があります。
結局のところ、霞ヶ関の中で私が出来ることが大変限られていました。それは私自身の力不足もあるでしょうし、やり方のまずさもあるでしょうし…私にとっていいことがなかったわけでもなく、またお役に立てる機会が皆無だったとは言わないけれど、この1年半は総括すると私の中では「失敗」でした。選択ミスです。
ということで、ちょっと我が儘を通していただくことにしまして、少し早めに、今月をもって総務省を退職することにしています。立つ鳥跡を濁さずと言いますが、結局のところいろいろ組織を引っかき回してしまっただけに終わる気がしていて、大変申し訳ない思いがします。ホントにさまざまな制限のある中、私の我が儘を聞いて汗をかいていただいた皆さんに感謝します。そして申し訳ありませんでした。今後は別の形で、より私の知識や能力が生きやすい方法で、お役に立てる機会がないか探ってみようと思います。その機会があればそこでご恩をお返しいたしますので、よろしくお願い申し上げます。
なお、今後の身の振り方についてはまた改めてお知らせします。