Twitter、暗号解読されても過去のデータが読めないようにするデータ保護技術を採用 16
ストーリー by hylom
ビッグデータの扱いには慎重さが必要なのです 部門より
ビッグデータの扱いには慎重さが必要なのです 部門より
あるAnonymous Coward 曰く、
Twitterが、同社のモバイルサイトとWebサイトとAPIのフィードの全域にわたって、Perfect Forward Secrecyを有効にしたと発表した。このPFSと呼ばれる守秘技術は、Twitterの暗号鍵が将来破られたとしても、過去に伝送されたデータは解読されないというものだそうだ（TechCrunch、Twitterブログ、ITmedia）。
過去のコンテンツに接続するためには長期に渡る公開鍵とプライベート鍵のセットが必要なため、攻撃者はいずれかの鍵を解読してもコンテンツのデコードができないとのこと。
PFSは暗号化に使用する鍵を定期的に異なるものに切り替えることで、1つの鍵だけでは一部のデータしか解読できない、といったような仕組みのようだ。
パーフェクトフォワードセキュリティとは (スコア:3)
通常、SSLでは最初だけ公開鍵/秘密鍵ペアを使って相手の確認と共有鍵の交換をして、その後は共有鍵暗号を使って通信します。
共有鍵の生成・交換方法はいくつかあるのですが、これが公開鍵/秘密鍵ペアから共有鍵を生成するような仕組みですと、後で秘密鍵を解読された場合に共有鍵もわかってしまいます。つまり、攻撃者に暗号通信を保存されて、あとで秘密鍵を解読されると全ての暗号通信が解読されてしまいます。
一方、毎回乱数などから生成して、しかも公開鍵/秘密鍵を使わずに交換するようにすると秘密鍵が解読されても過去の暗号通信の内容は解読できませんし、暗号通信の一部が解読されても他の部分は解読できません。このような性質をパーフェクトフォワードセキュリティと呼びます。
そのような交換方法としてはDiffie–Hellman鍵交換法があり、今回Twitterで採用されたのもその一種で、ほとんどのブラウザのSSL実装に含まれています(サポートしていないクライアントの場合は従来の方法が使われます)。
簡単に説明します。大きな数gとaについて、gのa乗(g^aと書きます)は簡単に計算できますが、gのa乗だけが与えられたときにaを計算するのは困難です。特に、大きな素数pと、ある性質を満たすgがあったときにg^aをpで割った余り(g^a mod p)とgからaを復元する効率的な方法は知られていません。
ここで例えばアリスとボブが鍵の交換(共有)をしたいとします。アリスとボブはそれぞれ乱数を1つずつ選びます。ここではそれをaとbとします。
アリスはボブにg^a mod pを送ります。ボブはアリスにg^b mod pを送ります。
そしてアリスはボブから貰ったg^b mod pから(g^b mod p)^a mod pを計算します。これは実は(g^b)^a mod pと等しいことが知られています。
ボブも同様に(g^a)^b mod pを計算します。
ところで(g^a)^b mod p = (g^b)^a mod pなので、これを共有鍵とすれば暗号通信ができます。
一方通信を傍受している人はg^a mod pとg^b mod pを傍受できますが、ここから(g^a)^b mod pは直接計算できません。(g^a mod p) * (g^b mod p)はg^(a+b) mod pであって(g^a)^b mod pになりません。また、aやbもわからないので結局(g^a)^b mod pは計算できません。
という訳で他の人に知られずに無事共有鍵を共有できたのでした。
Twitterで利用しているのは累乗を使う方法ではなく、楕円曲線を使う方法で、基本的な考え方は同じですが、これだと従来の方法と比べて15%ほどのオーバーヘッドで済んだそうです。累乗を使う方法では310%のオーバーヘッドがあったそうです。
ITmediaの記事はなんか変だ (スコア:2)
タレコミはITmediaの記事を引用してますが、この記事は変な文章ですね。
もう一つのリンク元TechCrunchの記事は分かりやすいです。こちらによれば、
HTTPSの公開鍵暗号をユーザーセッション毎に生成するので、
仮にどこかの誰かがTwitterのインターネットトラフィックを丸々保存していて、あるユーザーから現セッションの秘密鍵が漏れたとしても、
他のユーザーのセッションは解読できないし、そのユーザーの過去・将来のセッションも解読できないよ。
という技術のようです。
ITmediaはおそらく、どこかの「過去分のデータの中身(contents)に触れる(access)ことができない」というような感じの英文を見て、「コンテンツに接続できない」と誤訳しちゃったんじゃないでしょうか。
「長期の公開鍵とプライベート鍵のセットが必要」というのは、
長期間のトラフィックから中身を解読したかったら、その期間の各セッションの鍵セットがそれぞれ必要だよ。という意味ですね。
そうすると、その前の「長期にわたって解読されない」とは、暗号解読に長期間を要する、という意味ではなくて、「あるユーザーの暗号通信が長期間にわたって解読されっぱなしになることを防ぐ」という意味のようです。
紛らわしい書き方をしたものです。
# というか全体的に「コンテンツ」とか「デコード」とか「接続」とか、訳語の選び方がおかしい。
Re: (スコア:0)
techCrunchの記事も謎が多いですね。
HTTPSで配る公開鍵が毎回違うなら、オレオレ証明書みたいなのを
セッションの度に受け入れないといけないような気がします。
HTTPSの仕組みは崩さずに、ということになると、通常の公開鍵暗号に
もう一枚 公開鍵暗号フェーズを組み込むことになりますが、この場合、
プロトコルレベルでやろうとすると、クライアント側の対応が必要なように思えます。
となると、この一枚組み込んだ公開鍵暗号フェーズを、クライアントのjavascriptで
こなすことになりますが、まぁ無くはないんでしょうけど、強引ですよね。
というか こういう技術なのかな。
そんなに頻繁に行わない Webサービス間通信の場合は、毎回 公開鍵-秘密鍵を作って、
ワンタイムパスワードのやりとりを行うってことは普通にやりますのでその部分に
驚きはありませんが、
HTTPSに一枚膜を張って 150msの遅延ぐらいはいいでしょ、という強引さは なかなか
マネができない気がします。
Re: (スコア:0)
とりあえずPerfect Forward Secrecyのことを調べてからコメントしようぜ
他のコメントにもあるが日進月歩のＩＴ業界では古い技術（Ｇｏｏｇｌｅは２年前導入らしい）
無線LANの認証方式のアナロジーか (スコア:0)
いまいちよくわからないけど過去のデータにユーザがアクセスするときにはやはりその時点での鍵が必要で、
それがブルートフォースで発見できるなら異なる鍵であることによるセキュリティ強化の程度は限定的なのかな？
んでもって鍵生成マシンのシードが発見されたらセキュリティが完全に破綻する？
あるいは鍵管理システムのパスワードが破られるとか？
この仕組で今まで100年掛かってた解読時間が200年とか300年のスパンになるとしても、1万年とか1億年のスパンにならない限りは
量子コンピュータの登場までの防壁に過ぎなさそう。
Re: (スコア:0)
1万年とか1億年のスパンにならない限りは量子コンピュータの登場までの防壁に過ぎなさそう。
量子コンピュータが登場する頃には1万年とか1億年ののスパンになってたりするんじゃないの？
で、そんなになっても量子コンピュータの改良やポスト量子コンピュータで破れるようになるだろうし、
そんな先の事よりソーシャルな事に気を使ったほうがいいだろうし。
「量子コンピュータの登場までの防壁」になるなら実用上何の問題もないくらい十分だと思います。
なんだ (スコア:0)
うちの上司が手書き文書でやってることじゃないか。
Re:なんだ (スコア:1)
Re: (スコア:0)
しかもハードウェア実装の秘匿鍵暗号。
今更感漂う (スコア:0)
ブラウザ側ではIEですら7 on Vistaの頃から対応してるし、サーバ側でも程度の差こそあれ半分程度では採用済み(OpenSSLだと0.9.x時代からDHE対応済み、1.0.0からECDHE対応だったか？)
https://www.trustworthyinternet.org/ssl-pulse/ [trustworthyinternet.org]
Forward Secrecy Not supported 87,565 53.9%
Some FS suites enabled 67,847 41.8%
Used with modern browsers 6,016 3.7%
Used with most browsers 1,052 0.6%
Re: (スコア:0)
アレゲって言うよりアレですね。
Perfect Forward Secrecy? (スコア:0)
Perfect Forward Secrecy と Forward Secrecy の違いがわからないのですが、誰か教えてくれないでしょうか。
Re:Perfect Forward Secrecy? (スコア:3)
元々は、
Forward Secrecy=長期間復号されない強度の暗号（AES-128以上とか）
no FS=今この瞬間は大丈夫でも、近い将来復号される暗号（64bit暗号とか）
に加えて、
PFS=永続的なストレージ内の鍵は将来漏れることを前提とした上でなお通信は復号されない鍵共有を含めた暗号化
DH鍵共有はメモリ上で完結するのでPFSを満たしうる。RSA鍵共有は暗号文とサーバー側ストレージ内のRSA秘密鍵（長期間署名に使う）があれば復号できるので、FSは満たせてもPFSは満たさない。
Re: (スコア:0)
TLSではephemeralなDHE、ECDHEでの鍵交換のみがFSに該当する
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-de... [qualys.com]
> It's also sometimes called perfect forward secrecy, but, because it is possible to decrypt the communication by breaking the session keys, it's clearly not perfect
Re:Perfect Forward Secrecy? (スコア:2)
暗号自体がいつかは解読されるから文字通りのPerfectではないのはその通りなのでso called.
qualysはかつてのFSをno FSに格下げしてFS＝安全な鍵共有・破棄手続きを含む高強度暗号に再定義している。
# 将来的には異常に長いTTLのクッキーやクッキーの共有も減点対象になるかも。外部から検査が面倒だけど
あとTLSのstatic-static DHは鍵を明示的に再利用するオプションで、DH鍵共有自体の問題ではないのだけれど。
# opensslの出力綺麗にしたい時は!kDH:!kECDHしているけれどわざわざstatic DH実装しているブラウザってあるの？ セッションクッキーあるのに。
Re: (スコア:0)