「RSA暗号」を含む日記 RSS

はてなキーワード: RSA暗号とは

2019-10-19

アニメ「ぬるぺた」で物理数学

アニメ見てたら3話で物理数学ネタが出てきてすごく嬉しい。

ぬるぺたにはこの調子ディープネタを続けてほしい



唐突位相幾何ネタNewtonを読んでイキる大学1年生には鉄板ネタだよね。

2019-10-03

anond:20191003011208

RSA暗号簡単に解けると思うならそうなんだろうな

2019-04-03

セキュリティクラスタって性格悪いよなあ

徳丸さんとか高木さんとか、いつまでも武雄市長に粘着して息吸って吐いてるだけで文句わめいてるし。

なーにがこんにちわ~~だよクソが

2014-02-27

Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleSSL/TLSバグの件、日本語情報がなかったので意訳しました。

Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。

Apple's SSL/TLS bug (22 Feb 2014)

https://www.imperialviolet.org/2014/02/22/applebug.html

(Hi Adam Langley, Than you for your blog! We really appreciate you.)

-----

昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。
それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。

その答えは既にハッカーニューストップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Applebugがあるんだ。:
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
 OSStatus        err;
 ...

 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
  goto fail;
 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
 if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;
 ...

fail:
 SSLFreeBuffer(&signedHashes);
 SSLFreeBuffer(&hashCtx);
 return err;
}(Quoted from Apple's published source code.)
(訳者注:(Quoted from Apple's published source code)→sslKeyExchange.c)

2行のgotoがあるだろ。
2行目のgotoは、見て分かる通り常に発動する。
変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。
それって成功したのと同じなんだよね!

この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージ署名検証するものだ。
このServerKeyExchangeでは、"the ephemeral key"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。
そのサーバーは言うんだ。
「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」

今、もし"the ephemeral key"と証明書関係が破たんしているならば、すべては無意味なんだ。
これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイク署名しなかったりってことができるってことなんだよ!

そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵秘密鍵を持っているってことの証明が、何もないんだ。

これはSecureTransport(というライブラリ)に入っていて、以下に影響する。
・iOS 7.0.6より前(俺は7.0.4で確認した)
・OS X 10.9.2より前(10.9.1で確認した)
(訳者注:つまりiOS 7.0.6、OS X 10.9.2で解決した)

これはSecureTransportを使っているすべてに影響するけど、ChromeFirefoxはそうじゃない。
ChromeFirefoxSSL/TLSのためにNSSを使っている。
でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね)


超特急テストサイト作ってみたよ。https://www.imperialviolet.org:1266
ポート番号に気を付けてね。(テストサイトCVE番号になってるよ)
443は通常通りに動いているからね。

ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキー署名しているんだ。
君がもしポート1266のHTTPSサイトアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:)


それってつまり証明書チェーンは正しいってことで、そしてハンドシェイク証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。

またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。
攻撃者は、この暗号スイートを使うサーバー自分で建てるようになるだろう。

また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。
でも攻撃者は使うプロトコルをある程度選ぶことができるから安心できないよ。
(訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。)
でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。
同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。
(2つのうち、1つ目のほうがだいぶ好ましい。)

俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。
(更新:このバグOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。)

こんなような微妙バグって、悪夢だ。
俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。


ここに、今回の問題を明らかにするコードがある。:
extern int f();

int g() {
 int ret = 1;

 goto out;
 ret = f();

out:
 return ret;
}
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。
本当にビックリだよ!!!

ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。
(ピーターネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!)

if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。
でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。

テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。
TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。
俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも)

コードレビューはこの種類のバグについて効果的でありえる。
ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。
Appleコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。
でも、誰もがそんなにいい仲間を持てるわけじゃないよね。


最後に。昨日、Apple証明書ホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、
それは OS Xコマンドラインcurlを使うと、IPじゃない証明書でもIPHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

2009-09-13

サマーウォーズ真犯人

サマーウォーズの鑑賞中、セキュリティ描写が気になって映画を半分(主にカズマパート)しか楽しめなかった。

その後、はたしてどのような描写であれば納得感を得られたのかと妄想していたら、妙な答えに行き着いた。

まぁ、妄想ネタであることを承知置きください。

http://d.hatena.ne.jp/LM-7/20090831/1251727185

ここにあるように、もしあの2056桁の数列がRSA暗号における鍵であるとして、健二が素因数分解により平文(おそらくアバターの操作や仮想建物への入室のためのパスワード)の復号をマトモに暗算で行っているということは考えにくい。そこには何らかのショートカットが存在するはず。おそらく、OZ暗号鍵生成アルゴリズムに実装上のバグがあり、何らかの推察(法nに規則性、乱数が甘いとか)を許してしまうような物だろう。これは、おそらくOZ技術者の中では既知のもので、対応中のものだったのではないだろうか。そう、だいたい55人くらいにはそのショートカット法を知られていたくらいには。

ここで思い出してほしいのは、健二はOZメンテナンスアルバイトをしていたということ。

メンテナンスのため管理棟(だっけ?)と言われる領域へログインし、何か作業を行っている様子が見られる。どんな作業かは分からないが、物理部の彼らのこと、そうした暗号への興味もあるだろうし、知ってしまっていたとしてもおかしくはない。(こんな危険バグの対応をバイト学生に任せるなんてありえないが、あるいはバイトとはこの問題への対応のためのテストであり、その過程で知ってしまったのかもしれない。)

健二が上田へ向かい、ラブマシーンが暴れだす。

だが、ラブマシーンの描写を見ると、できることはアバターを乗っ取ることだけで、OZの基幹系システムそのものを乗っ取ったわけではない。あくまでアバターの可能な範囲での権限の行使に限られていて、たとえば花札ルールに介入したり、配られる札を操作したりするようなことはできない。

ラブマシーンが米軍によりOZに放たれたとき、彼にできることは相当限られていたはず。

彼が暴れるためには、多くのユーザ秘密鍵管理を行う管理棟へ入れるアバターを乗っ取ることが必要だった。

ラブマシーンは何かのきっかけで上記の脆弱性を知り、OZ管理者に近いアバターの鍵をなぜか知り、その解を解けそうな人物へ送付する。メールでその鍵の復号を知る。

それを手がかりに秘密鍵へのアクセスを可能にし、あとは選択平文攻撃によってアバターを次々に乗っ取っていく。でも、最初の一歩、管理棟への出入りのための鍵はどこから?

その、最初の鍵は、どうやって手に入れたんだろう?

ここで、一人の傷心の人物が浮かび上がる。

OZバイトしていた、物理に興味のある、あまり目立たなかった人物。

彼は暗号を自力で解くほど数学の才に恵まれていたわけではなかったが、秘密鍵のありかと、脆弱性があることは知っていた。

じゃん拳に負け、東京に一人残った彼。

傷心の彼はその日、管理塔のまわりをうろつくラブマシーンに気がついた。何でも知ろうとし何でも吸収しようとするbot

本当は、知識を吸収して報告するだけの何も権限のないbot

そう、佐久間敬君、きみ、あれに何か渡さなかったかい?その見返りとして健二のアバターを使うように申し出たり?

暴走したラブマシーンとは、あれは君?

2007-07-09

http://anond.hatelabo.jp/20070708222412

暗号の鍵が問題って事でいいんじゃないの。

スタンドアローンでなく共有された仮想空間において、空間の整合性のためにオブジェクト暗号化されて管理されているとするわな。一方でアルゴリズム上の問題で暗号の鍵は正規のものと別に「偶然」開錠できてしまうものがあるとする。(RSA暗号の問題から着想)

その未発見の「合鍵」が各ハッキングツールの「違法な処理」を可能にしているものだと解釈すればどうか。未発見合鍵は管理者に発見サッチーに処理)されると対策されて使えなくなる。

2006-11-13

[]『水からの伝言』の世界

昔、妖精現実のトップにあった記事。探しても見つからないや。

水からの伝言」…水は否定的な言葉を見せたときと肯定的な言葉を見せたときで異なる結晶を作る。

(念のために言うが、↑は科学事実ではない。しかしネタとして、あえて) これが成り立つ世界を考える。ただし、次の公準も仮定する。

公準: 悪意・うそ・いつわりの言明は否定的である。

考古学的応用: 水は世界中言語を理解できるので、 未解読文字の解読に役立つ。 少なくとも、お礼を言っているのか、宣戦布告の文章か、といった程度の判別はつく。 「正しい解読結果をアルファベットで表記したとき1文字目は大文字小文字を区別せずにAである」「…Bである」…と書いてある30枚弱の紙を水に見せて、どれが肯定的かを判断することを、結果の文字列長(この整数値も水に問い合わせることができる)だけ繰り返せば、あらゆる謎の古文書が解読できる。 水さん、ありがとう

問1: 解読結果が1万文字以内であることは分かっている文がある。 解読結果の文字列長を表す整数値を必ず確定させるのに必要な最小の「水への問い合わせ回数」はいくつか。

問2: 現在は不治の病であるXについて、それを根治する薬品があると仮定する。 その有効成分をIUPAC等の標準的な化合物命名法で記述して1万文字以内であると仮定せよ。 以上によって、水が肯定否定を判断できるなら、難病のいくつかが克服できることを説明せよ。

問3: 水に問い合わせられるときP=NP問題は肯定的に解決されるか。

軍事的応用1: ゆえにRSA暗号楕円曲線暗号、その他、いかなる未知の暗号であっても、ダイレクトに高速にクラックできる。 上記同様、解読結果のどれが肯定的か1文字ずつ判断させるだけで良い。量子通信・量子暗号さえ解読できてしまうだろう。

軍事的応用2: さらに、暗号に限らず、情報一般に応用できるから、チャフによる妨害や、敵の欺まん電波を見破るように水を結晶させる装置を弾頭に装着することで、電子妨害を受けない強力な兵器を構築できる。

あらゆるプライバシーは破られ、あらゆる外交機密はばれる。水さん、ちょっと漏れすぎです。

DRMも破られるので、水は著作権を侵害する。

このように、情報を「絶対的」に評価できるデバイス存在する世界では、社会の秩序が保てない。

こういうの、大好きだ。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん