oddmakeの日記: Paul Kocher(7)
いよいよ週末です。いえ、土曜日ですが。
Wikiにもあげるべし。
6) SSL and Forward Security
6)SSLとForward Security
by Effugas
Effugasによる質問
Paul,
First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.
Paul、第一に、ここでインタビューを受けることを承諾してくれたことに感謝します。非常に嬉しいことです。
I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.
私はRSAの秘密鍵の妥協のためのSSLのセキュリティアーキテクチャーが破滅的な失敗をあなたがちっとも気にしないとしたら好奇に思います。攻撃者は文字通り、一年の間全てのトラフィックを監視して、一回だけ解読し鍵を盗み、そしてその年の全てのトラフィックだけでなく次の年のぶんも全て労をかけずに解読することができるのです。そしてもし彼がもっと能動的な攻撃をしたければ --セッションハイジャックとか、悪意あるデータの挿入とか、その他いろいろ -- それもたやすいことなのです。
In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.
つまり、なぜでしょう? とても多くの努力がセッションごとの秘密鍵をセキュアにすることに払われているというのに、何が非対称暗号(公開鍵)を脆弱なままにしているのでしょうか? ええ、PGPはこうした故障に対して同じように脆弱です。しかしPGPは他のホストへのソケットといった特長を持たないのです。
More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?
より重要なことは、この他は賞賛すべきアーキテクチャーのこの欠点に神経質な人々にたいして何ができるでしょうか? 私はDSAモードを見ましたが、何もそれらを加速していないように見えます(それはもっともそれを必要としているサイトにとっての妥当性を殺しています)短期的RSAは興味深くみえますが、Rascolaのドキュメントによると最大でも512ビットのセッションごとの非対称鍵(不十分です)をサポートしているに過ぎないのです。もしVerisignが毎日新しく生成した鍵に署名するのなら、それは機能するでしょう - ですが、おそらくそのサービスを得るために会社の一部を売って署名する必要があることでしょう。一個の完全修飾ドメイン名に結びついた一個の長い鍵にサインし、長時間の証明書から割り振った時間割の中の一時的な鍵にいくつでも署名できるようにするというのは可能でしょうか?
Thanks again for any insight on the matter you may be able to provide!
あなたの示してくださるであろうご明察に重ねて感謝もうしあげます。
Yours Truly,
敬具
Dan Kaminsky
DoxPara ResearchPaul:
I specifically designed the ephemeral Diffie-Hellman with DSA option in SSL 3.0 to provide perfect forward secrecy (PFS). While it used to be true that DSA's performance was a concern, it shouldn't be a problem anymore.私はSSL3.0のDSAオプションつきの一時的Diffie-Hellmanを特にperfect forward secrecy(PFS)を提供するように設計した。DSAのパフォーマンスが懸念だったことはだが、それはもう問題ではない。
[*] If you want to avoid DSA, you can also do a normal RSA handshake then immediately renegotiate with an uncertified ephemeral Diffie-Hellman handshake. (SSL 3.0 and TLS 1.0 allow either party to request a renegotiation at any time, with the renegotiation process protected underneath the first handshake.) As your question mentions, short-lived certificates would work if a suitable CA provided them.
[*]もし君がDSAを避けたいなら、君は通常のRSAハンドシェイクをしてそれから認証されていない一時的Diffie-Hellmanハンドシェイクでネゴシエートすればいい(SSL3.0とTLS1.0はいずれの通信者にも、再ネゴシエート任意の時期にネゴシエーションする要求を出すことを認めている)君の質問にもあるとおり、一時的な証明書はもし適切な認証局が提供すれば機能するだろう。Making PFS mandatory wasn't feasible in SSL 3.0 because of performance requirements, the need to maintain compatibility with legacy RSA certificates, and licensing issues. (Back in 1996, RSA was patented and most companies only had limited RSA toolkit licenses, not patent licenses.)
PFSを義務づけることはパフォーマンス上の必要条件や、レガシーRSA証明書との互換性の維持の必要性や、ライセンス問題(1996年当時、RSAは特許になっておりほとんどの会社は特許のライセンスではなく限られたRSAツールキットのライセンスを持っているだけだった)のためにSSL3.0ではできることではなかった。
Overall, I'm delighted so see how many ways SSL 3.0 is being used and that it's become the most widely deployed cryptographic protocol in the world. While there are reasons to debate design choices I made, I don't know that the protocol's handling of PFS is one of them. Although some implementations have had bugs and guidelines had to be added to address error-analysis attacks, the overall protocol has held up well.
全体として、私はSSL3.0がとてもたくさんの方法で使われ、世界でもっとも広く展開されている暗号プロトコルとなっているのを見て喜んでいる。私のした設計上の選択について討論すべき理由があるものの、私はプロトコルのPFSの扱いがその一つであるとは思わない。いくつかの実装についてはバグがありerror-analysis攻撃を扱うガイドラインが付加されるべきだが、全体としてプロトコルはよくできている。
[*] In 1996 (when the SSL 3.0 spec came out), computers were only 4% of their current speed. (Moore's Law predicts 4.67 speed doublings in 7 years.) Today, any modern CPU should give well beyond 200 2048-bit DSA verifies/second. Averaging 10 handshakes/second (5% load) = 864K connections daily per CPU. Unless you are running one of the largest web sites (or have your server misconfigured to disable session resumption), this isn't likely to be a problem. For really high-volume servers, SSL accelerators are affordable and very fast. In general, it's rare these days to find a situation where the speed of standard cryptographic operations is actually a problem.
[*]1996年(SSL3.0仕様が出来た時)、コンピュータは現在の速度の4%しかなかった。(ムーアの法則は7年間で速度の倍増が4.67回あると予測している)今日、どんな現代のCPUも毎秒200個以上の2048ビットDSA認証を十分にする。平均で毎秒10ハンドシェイク(負荷5%)はCPUあたり毎日864,000コネクションに等しい。君が最大級のWebサイトのひとつを動かしているので無い限り(あるいはセッションの再開を無効にするように設定ミスしていない限り)、これは問題にはなりにくい。本当に大容量サーバのためには、SSLアクセラレータが入手できてとても高速だ。概して、今日標準的な暗号操作のスピードが実際に問題となる状況となることは稀だ。
ともうひとつは
9) Is the Technology ahead of us?
9)テクノロジーは私達を追い越しているのでしょうか?
by Coz
Cozによる質問
Thanks for letting us ask you these questions.
質問をする機会を与えてくださってありがとうございます。
Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.
最近20年間で、暗号技術は主要な政府、ビッグビジネス、変わり者ホビイストや研究者のものから、新しいアルゴリズムや新しいアプリケーションはほとんど毎週のように出てくる誰も参加できる(そしてしている)大きな公共的な産業となりました。他方、私達はさまざまな暗号システムの実装の脆弱性を、暗号システムそれ自身の原理的欠陥を発見する人々の話より頻繁に聞いています。
Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?
これらの事実から、あなたは焦点を変え、暗号システムの実装(あなた自身のSSLとか)を検証し「推奨」するべきだと思いますか? それとも「暗号コミュニティ」の重点が暗号システムの原理上の革新と新しいアプリケーションにあるべきだと思いますか? 誰かが暗号システムがきちんと実装されていると確認することはどのくらい重要なことでしょうか?
Paul:
Validation is by far the most critical unsolved problem in security.
検証ははるかにもっとも重大なセキュリティにおける未解決問題だ。
I view security as probabilistic: there is always some chance of failure, and validation is the only way to reduce the odds of failure. For example, a well-tested piece of code is more secure than an identical piece of code that hasn't been tested.
私はセキュリティを確率的問題と見ている:常にある失敗の確率があり、検証は失敗のオッドを減らす唯一の方法だ。たとえば、よくテストされたコードはテストされる前のコードよりもセキュアだ。
Although innovation is great on the research side, real-world systems should use well-tested techniques wherever possible. For example, on the algorithm side, we use RSA, triple DES, AES, and SHA-1 at Cryptography Research unless we have to use something else. (This is rare.) We use these algorithms because they are well reviewed, making the risk of an unexpected cryptanalytic attack low. In contrast, catastrophic flaws in new schemes are very common.
革新は研究側にとって偉大なことであるが、現実世界のシステムは可能な限りよくテストされた技術を使うべきだ。たとえば、アルゴリズムでは、私達は何か別のものを使わなければならない(稀だ)のでなければRSA、triple DES、AESやSHA-1をCryptography Research社では使う。私達はこれらのアルゴリズムを全てよくレビューして、予測できない暗号解析的な攻撃のリスクを低くしてあるから使う。対して、新しいスキームの破滅的欠陥はとてもよくあることだ。
When you move beyond the basic algorithms, validation unfortunately becomes extremely difficult for many reasons:
君が基本的アルゴリズムの段階を超えると、検証は不幸にも多くの理由により極端に難しくなる。
The complexity of software is increasing exponentially, but the number of skilled security experts (and their intelligence and productivity) is staying roughly constant.
Many designs are so poorly architected or implemented that they are infeasible to validate.
Validation is much more difficult than writing new code (and it's less fun), so many people avoid it.
Engineers are cranking out such vast quantities of code that testing can't possibly keep up.
Existing validation tools are really quite poor.
The cost of security testing can be hard to justify because most users won't pay extra for better security.
There is no easy way for users to distinguish between well-tested products and those that aren't.
Testing takes a long time, slowing down product launches.
There is no easy way to standardize security evaluations because attackers don't limit themselves to standard attacks.
Catching 90% of the flaws doesn't help if attackers are willing to look 10 times harder to find flaws.
Developers don't have much incentive to make painful sacrifices for security because they aren't the ones who incur the risk.
Long-term, I expect security will become like the pharmaceutical and aviation industries. Regulations and liability would improve safety, but would also make product development hugely expensive. Regardless of whether this would be better or worse than the current state of affairs, it looks inevitable.ソフトウェアの複雑さは指数関数的に増加するが、熟練のセキュリティ専門家(と彼らの知性と生産性)はおおむね一定のままだ。
多くの設計は貧弱に構築もしくは実装されており検証できない。
検証は新しいコードを書くよりもっとずっと難しい(そして楽しくない)だからほとんどの人々はそれを避ける。
技術者はテストしきれないほどの多量のコードを書いていく。
今ある検証ツールは本当に貧弱なものだ。
ほとんどのユーザはより良いセキュリティに余分の金を支払わないため、セキュリティテストのコストは正当化し難いだろう。
ユーザにとってよくテストされた製品とそうでない製品の区別をつける簡単な方法はない。
テストには長い時間がかかり、製品の立ち上げを遅くする。
攻撃者は標準的な攻撃だけするとは限らないため、セキュリティ評価を標準化する簡単な方法はない。
90%の欠陥を捕捉する事は、もし攻撃者が欠陥を見つけるのに10倍の努力を集中する気があるなら役に立たない。
開発者はリスクの結果を引き受ける者ではないから、セキュリティのために苦痛に満ちた犠牲をはらう動機に乏しい。
長い目で見て、私はセキュリティが薬品もしくは航空産業のようになるだろうと思っている。法規制と保障責任が安全を課すが、製品開発を非常に高くつくものになるだろう。現在行われている状況よりどれだけいいか悪いかに関わらず、それは避けられないものと映る。
…オープンソース的バザール翻訳というのは素晴らしいものでしね!(突然)
Paul Kocher(7) More ログイン