  |
はてなキーワード: 公開鍵とは
あの省の回答とか、あのブログの内容とかは論外だが
今回の用途で公開鍵を公開しなかったことと、あまねく公開鍵を公開してもセキュリティ上の問題が生じない(強度が足りている場合に限る)ことを一緒くたにしない方がいいと思った
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 124 | 19082 | 153.9 | 50 |
| 01 | 39 | 6485 | 166.3 | 51 |
| 02 | 41 | 3211 | 78.3 | 35 |
| 03 | 21 | 8839 | 420.9 | 72 |
| 04 | 11 | 6906 | 627.8 | 617 |
| 05 | 17 | 10089 | 593.5 | 629 |
| 06 | 23 | 5915 | 257.2 | 34 |
| 07 | 34 | 4258 | 125.2 | 65 |
| 08 | 51 | 2636 | 51.7 | 39 |
| 09 | 109 | 12173 | 111.7 | 44 |
| 10 | 125 | 12090 | 96.7 | 49 |
| 11 | 121 | 11421 | 94.4 | 48 |
| 12 | 178 | 10910 | 61.3 | 38.5 |
| 13 | 128 | 9653 | 75.4 | 40.5 |
| 14 | 194 | 12935 | 66.7 | 42 |
| 15 | 103 | 9477 | 92.0 | 31 |
| 16 | 122 | 9201 | 75.4 | 35.5 |
| 17 | 115 | 13852 | 120.5 | 53 |
| 18 | 150 | 14036 | 93.6 | 46 |
| 19 | 75 | 16848 | 224.6 | 60 |
| 20 | 73 | 9494 | 130.1 | 54 |
| 21 | 124 | 24064 | 194.1 | 51 |
| 22 | 78 | 16808 | 215.5 | 34 |
| 23 | 102 | 12828 | 125.8 | 41.5 |
| 1日 | 2158 | 263211 | 122.0 | 44 |
異世界転生(5), 公開鍵(4), 死産(4), ラグナロク(6), 7kg(5), 暴れん坊将軍(4), 素早(3), 幸三(3), tora(3), 飯塚(3), スコール(3), 上級国民(20), 時計(10), 拷問(8), 想像力(17), 交通事故(7), フェラ(9), 妊婦(13), 劇(6), 焼く(7), 池袋(6), 昭和時代(11), 夢見(8), 一貫(8), 整形(10), ターゲット(12), 毎週(9), 同年代(6), おしゃれ(6), 低能先生(13), 体験(21), 海(11), 妊娠(17), なろう(11), 発達障害(13), 気持ちいい(11), 運転(10), わかん(12), 出産(16)
■レイプにおける、犯人と被害者の認識の違いを見せつけられた /20190424005118(32), ■口淫って拷問並みに痛いってことを全人類に知ってほしい /20190424150849(25), ■自分の目論見が外れたのにシームレスに説教に移行する人間てどうなの /20190423101547(21), ■小説読んでる奴はバカ /20190424054053(11), ■トーストってさ /20190423202650(10), ■キャプテンアメリカがいるんなら /20190424084658(8), ■ダブスタチェックの時間です /20190424094618(8), ■文系は子供に空が青い理由を聞かれてどう答える？ /20190423112744(8), ■20代前半だが免許を返納しようと考えてる人へ。 /20190424130233(7), ■なぜ俺はVTuberにハマってないんだ /20190423180043(7), ■偉い人「女の子が戦う作品作りたいけど陸海は無理…残るは空だ！」 /20190423154556(7), ■昭和時代劇と異世界転生なろう系の違い /20190424111921(7), ■ひょっとして暴れん坊将軍って /20190422225235(6), ■ブスになにかけてもブス /20190424105436(6), ■ペニス！のかっこいい呼び方 /20190424163339(6), ■50人に振られても恋人は作れた /20190424153033(5), ■舞台PSYCHO-PASSがつまらなかった /20190423220740(5), ■婚活で男の奢り？ /20190424132640(5), ■anond：20190424121219 /20190424122506(5), ■anond：20190423101547 /20190424095007(5), ■絶望しかない /20190424102236(5), ■職場の先輩のお子さんが亡くなった /20190424174304(5), ■男性が安心して妊娠できる社会 /20190424120549(5), ■美白好きの男へ、美白のどこがいいのか教えて /20190424002301(5), ■すっげえ今更だけど、ゼルダつまんなかった /20190424120405(5)
6198983(0)
ホットウォレットとコールドウォレットの違いは、あらゆるトランザクションの発行に必要な秘密鍵が保管されたストレージが、
インターネット接続されているかインターネットから隔離されているかの違いでしかありません。
ウォレットからウォレットへの送金（取引所側から見ると入金）は取引所側のアドレス（公開鍵）の情報さえあれば、
全世界に公開されたフルノード（仮想通貨のサーバソフトウェア）がブロックチェーン上で完結・保持するので、
入金の頻度が高いからと言ってコールドウォレットかどうかは厳密には区別することができません。
では、出金頻度が高い場合はどうでしょうか。取引所におけるユーザからの出金処理の流れとしては、
となります。ホットウォレットの場合はこれらがすべてネットワークにつながったサーバ上で完結します。
コールドウォレットの場合は、1の情報を元に2でネットから隔離された環境でトランザクション命令を発行し3を行うためにネットワーク端末に戻す手続きが必要になります。
これらが律速になるため、一般的にはコールドウォレットからの出金頻度は低くなるというのが元増田も書いている見解になります。
しかし、1→2、2→3へのデータの移動を物理的・機械的に実行するシステムを用いることでこの律速を解消することができます。
現在のテクノロジーならこれを安価かつ安全に実現する自動化システムを構築することは可能でしょう。
つまり、送金頻度が高いからといってかならずしもコールドウォレットを使っていなかったということにはなりません。
itochan （苦笑）切り離せ！ ＞しかし、1→2、2→3へのデータの移動を物理的・機械的に実行するシステムを用いることでこの律速を解消することができます。現在のテクノロジーなら（略）自動化システムを構築
切り離されています。コールドウォレットの安全性のキモは秘密鍵にインターネット経由でアクセスが不可能であるという一点のみです。上で書いたのはトランザクションの発行までを人手でルーティーンで行うところを機械化し、効率化するという話でしかありません。秘密鍵が外部からアクセスできない状況なら、泥棒が仮想通貨を盗むためにはユーザアカウントを盗むか送金システム自体をハックする必要があるので、いずれにせよコールドウォレットのメリットは維持されます。
むかし別のサイトでブログをやっていて、久しぶりに書きたくなった。
ブログサービスは、はてなじゃなくてもどこでもよかった。特に何も考えずはてなにした。
登録する前のはてなのイメージって、小規模なブログサイトって感じだった。
で、実際始めてみたら、はてなの規模の大きさに驚いた。
まず、ブログ以外にもブックマークサービスとか、ニュースサイトとか、キーワードっていうユーザーが作る辞書みたいなサービスを展開していて、どれも活発に利用されていた。
インターネットに存在する、ありとあらゆるサイト、URLに誰かの読んだ足跡が記録されていた。
私は今ネットワークについて勉強しているんだけど、あるとき「公開鍵と共通鍵の違い」について調べていた。
で、わかりやすいサイトを見つけた。個人が作った感丸出しの、しかも更新日が確か2010年とかだった。
アレ、ブクマすると、そのサイトで他のはてなユーザーがブクマしたコメント見れるんだね。
ブクマ数が数百もついてた。コメントは50とか。しかも割と最近のコメもあった。
別に「公開鍵と共通鍵」がニッチなワードではなくとも、個人ブログの2010年更新のページにこんなにも、はてなユーザーが訪れているとは思わなくて、もしかしてはてなユーザーは想像を絶するほどいるんじゃないだろうか。
ゴキブリを1匹見たら100匹はいるじゃないけど、インターネットのいろんな場面ではてなユーザーを散見した。
有名なサイトには当たり前のように数千単位でブクマがついてるし、誰も見に来ないようなページにもかなりの確率でブクマがいくつかついていた。
多分、以上の話を驚かない人もいるんだと思う。
はてなのようなクラウドのようなものでブクマ管理している人が大勢いることがカルチャーショックだった。しかも、はてなという、自分が今まで単なるブログサイトだと思っていたところがそれをしていた。
はてな人口って、どれだけいるんだろう。
$
2046年。東京オリンピックの年に生まれた人間が三十路に差し掛かる頃。
餃子チェーン店のテーブル席で、野暮ったい女がビールを飲みながらノートパソコンに何か打ち込んでいる。ひどいクマと死んだ魚のような目はまるで亡者だ。亡者がスウェットを着て餃子をつまんでキーボードを叩いている。
老紳士が現れる。ボウシを取り、くすんだ色のトレンチコートを脱ぎ、女の対面に当然のように座る。老紳士は老いているからか、挙動がぎこちない。
「やあ、赤坂くん」
女は答えず、画面を見ながらチャーハンをゆっくり口に入れ、咀嚼する。
女、赤坂は無視し続ける。ポッケからイヤホンを取り出し、耳にはめ込む。無言の意思表示だ。老紳士はしばらく黙っておいて、それから何を思ったか、半分衝動的に赤坂のパソコンをパタンと閉じてしまう。
「おい」
乱暴に、短い抗議の意を示す赤坂。老紳士はとぼけて、それを意にも介さず用件を切り出した。
「ロシア上空に、GPS衛星と偽装されたアメリカ軍の偵察軍事衛星がある。それにちょっと侵入(はい)ってきてほしい」
手に折りたたまれたコートのポケットをさぐり、メモリードングルを取り出す老紳士。赤坂はそれをむしり取って、小さな機械に差し込み、それを有線でパソコンに繋いだ。
「あいかわらず厳重だな」
「パソコンに直接差し込むのは、信用できる機器だけにしてるんです。教授、あなたからそう習ったはずですけど」
呆れる老紳士に皮肉を返すと、赤坂はメモリードングルに入った資料を開いた。
「5ページ目にリストされているETN-G-129がそれだ。表向きは、商用オフザシェル化の一環として宇宙関連企業のパラジウム社が受託し打ち上げたBlockⅢ代替のGPS衛星だ。しかし、実態はちょいと違う」
ある資料には、膨大かつ一般人には意味不明な数列が延々列挙されていた。2桁の16進数が大量に連なっている。しかし、彼女にはこれらの意味が分かる。
「そうだ。しかも、暗号化されていたものをご丁寧に平文にして転送している。NSAも随分と腑抜けたものだよ」
注文を取りに来た店員にお冷を頼んで追い返す老紳士。彼がひどい下戸であることを赤坂は知っていた。
「まあそうだな。依頼主はアメリカ側からのアクセスを止めさせろと言っているがな、それじゃあんまりつまらんだろ」
店員が会話を中断させ、水を置いていく。老紳士は一口、いかにも老人といったしぐさで飲む。
「赤坂くんの好きにしていい。おそらくコントロール系統はNORADに接続されている。君の腕ならば、衛星を踏み台に使うのも良かろう」
「それだったら、もう少しマシな手があるし、だいたい軍やら何やらに侵入するのはあなたの持ってくる依頼のせいじゃないですか」
「はて。ワシはバス接続の危険性以外にもこう教えたはずだがな。『君たちは楽しい楽しいオモチャを手に入れたのだ』とな」
ーーーーーーーーーーーーーーーーーーー
帰る途中。コンビニに立ち寄り、ソフトクリームを食べるための座席に座り、キーボード付き携帯端末を公衆無線ネットに繋ぐ。会員登録をしろとせがむ画面を消し、スクリプトをいくつか走らせると、すぐに管理者権限が手に入る。
いくつかプログラムを自動インストールさせ、オニオンルーティングとVPNで秘密の回線を作り出す。これで発信元の特定が困難になる。
そこから接続するのはとあるアメリカ軍人の個人端末だ。以前とあるショッピングサイトから流出した情報を使って、たやすく乗っ取る。今、アメリカはだいたい朝の10時。運が良ければ、軍人は軍施設内にいるはずだ。果たして、軍人は施設内におり、乗っ取った端末から施設の無線ネットに接続出来た。
軍用のシステムはちょっと頑丈で、コンビニのサーバほど簡単に侵入らせてはくれない。辞書攻撃を仕掛けつつ、母校たる東京電波大学の誇るスーパーコンピュータを使って秘密鍵の推測を行う。
20分程度かかって、なんとか秘密鍵を割り出した。同じ公開鍵が無線ネットの接続に使いまわされていたのはラッキーだった。こうして米軍のシステムに侵入できた。
しかし、いくら同じ米軍のシステムと言えど、見たところこの施設はただの空軍基地。件のスパイ衛星のコントロールシステムはそこには無いようだ。
そんなことは赤坂も最初から分かっていた。赤坂の狙いは、空軍基地にある衛星通信用のアンテナだ。これを使い、標的の衛星の近くにいる衛星にアクセスし、乗っ取り、そこから標的の衛星にアクセスするのだ。
これをやってみると上手くいかない。アンテナから衛星が遠すぎたのだ。仕方なく他の米軍基地をまた乗っ取り、やっと標的にアクセスできた。早速データベースを覗きこむ。
中身は、ロシアと米NSAの秘密鍵などでギッシリだった。これだけ色々あれば、次また教授が何か言ってきても楽になんとかなるだろう。
『衛星はーーNORADに接続されている。ーー踏み台にするのも良かろう』
教授のほざいたことをふと思い出し、コントロールシステムへの信号に偽装フレームを紛れ込ませてみる。偽装パケットには小さなフレームが仕込んであり、相手システムが受け取ると即座に実行され、こちらに諸々の情報を返してくる。すると米空軍の心臓を掌握したも同然である。
いささか満足し、帰る準備として証拠の記録であるセキュリティログを隠滅しようとして気づいた。セキュリティログが明らかに不自然だ。誰かが一部を消したのだーー赤坂が今やろうとしているように。
「私以外に、誰かが侵入っていたんだ。しかも、私とほぼ同時に」
少し気味が悪かったが、適当に証拠を処分し、衛星は傍受したデータではなくランダムに生成したデータを送信するようにしておいて、その場は終わりにした。
ーーーーーーーーーーーーーーーーーーーーー
レジに座り、大きなあくびをした。普段、赤坂は平成商会でアルバイトをしている。平成商会は新横浜にある、電子パーツの問屋だ。マニアと業者だけがやって来て、一般人にとってはガラクタにしか見えない物を買い漁る、知る人ぞ知る店である。
声をかけられ、顔を上げた。教授だった。ふざけている。そんなもの、彼が探しているはずもない。依頼の成果物を取りに来たのだ。
「これ、衛星のコンソールへのリンクです。米軍施設にあるコントロールシステムの電源が付いている限りは、自由に例の衛星をコントロールできます」
事も無げに言い、携帯端末に二次元コードを表示して差し出す。教授はうなずき、コードを写真に撮る。
「報酬はこれだ」
教授は提げてきた紙袋から何か取り出した。大きくて古臭い、中世のコンピュータの周辺機器だ。
「ずいぶん探したんだぞ」
「そうそう。ウチの大学のスパコンあるだろ。あれが短時間何者かによって不正利用されてたらしくてな。学内大騒ぎだ」
「ワシの研究室にもちょっと来てね、誰がやったか調べてくれって言うもんだから見てみたら驚いたよ。RAMに公開鍵がたっくさん入っておったよ。あれがNORADの鍵かね」
「いや、あれはどっかの米軍基地の鍵でした。NORADの鍵は私が大事に保管してます」
「鍵は大事に保管ね。当然だ」
教授が帰った後。店主の勧めでペケ86kを店頭に展示すべくパソコンに繋いでいる時。
「あの……すみません」
どこかから女の声がするではないか。嫌だな、怖いな、と思いながら声の方向をたどると、一つの端末が音声通信をしていた。
これだからP2P通信は。無視して通信ソフトを落とす。が、何度やっても立ち上がる。
「ちょっとお尋ねしたいんですが……」
電源を落としても、もう一度つく。コンセントを引き抜くと、別な端末に移る。
「もう、やめてくださいよう。ちょっとぐらい話きいてくれたっていいじゃないですか。ひどい」
「いやいや、あなたこそ誰なんですか……？米空軍の迎撃システムに侵入したの、あなたでしょ」
「私はただのバイトだ。消えろ」
キーボードを叩き、スクリプトを走らせて回線を遮断しようとするが、文字が入力できない。
「ネット切ろうとしてますよね。それはボクが困るので、キーボードの接続を切りました。ははっ」
ここで赤坂は確信する。こいつがあの不自然なログの正体だと。赤坂と同時にNORADをクラックしたハッカーだと。
「気持ち悪い」
「心外だなあ。ボクはあなたに興味があってはるばるここまで来たんですよ。ちょっとぐらい相手してください……」
「よっと」
後ろで声がする。メイドロボだ。やつは消えなかった。それは淡い期待に終わった。やつはメイドロボを乗っ取った。
ここの店主はメイドとレトロPCが大好きだ。置いてあるロボは無駄に美形の機種を買い、無駄にフリフリでクラッシックでステレオタイプなメイド服を着せられていたのだった。
赤坂が呆然としていると、メイドロボは向き直り、はにかんで言った。
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か？主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
秘密鍵が盗まれるケースというのはどういう状況を想定していますか？ ウィルス感染？
パスワード認証やめろ公開鍵認証使えって風潮あるけどさ、この時代、
公開鍵ファイル＆パスフレーズ盗まれるリスクって、パスワード盗まれるリスクと大して違わなくね？
むしろ秘密鍵ファイルのみ盗まれたとときにローカルでフレーズクラックされやすいこと考えたら逆に危なくね？
もちろんパスワード認証オンにしてて、弱パスワードや使いまわしてたりするのは論外だし、
fail2banとかのリモートブルートフォースアタック避けは当然あるとしての話だけど
何が言いたいかというと、いまやsshの認証の安全性は、二段階認証＞＞＞＞公開鍵認証≒パスワード認証で、
原文：https://community.spiceworks.com/how_to/125475-teslacrypt-2-2-0-removal-and-decryption
原題：TeslaCrypt 2.2.0 Removal and Decryption
原著者：Isaac Rush's (hewhowearsascarf) Portfolio of IT Projects - Spiceworks 氏 (Thank you for your contribution! This article is a translation of your post.)
私たちのワークステーションのうちの一つがTeslacryptランサムウェアに感染しました。すべての文書が暗号化され、拡張子はvvvに変えられました。マルウェア感染のにおいて最も安全な回復方法はコンピューターをワイプしてバックアップから復元させることです。しかし、それは場合によっては選択肢にならないことがあります。私たちの場合、ユーザはローカルコンピュータに何のバックアップもとっていませんでした。それで、私たちはランサムウェアを取り除く方法とファイルを復号する方法を確認する必要がありました。復号を達成させてくれたPythonスクリプトの作者であるGoogulatorに大きな感謝を送ります。https://github.com/Googulator/TeslaCrack
そこに書いてある説明に従うといいです。引用していくつか説明を付けたものを以下に用意しました。元の記事にはたくさんの指示が書いてありますが、私たちが行った手順は以下の通りです。
セーフモードで再起動し、Malwarebytes scanを走らせて、見つかったすべてのマルウェアを削除します。私は複数の信頼できるマルウェアクリーナーを使ってこれが消えたか確認することをお勧めします。必要だと言われたら再起動します。これでウィルスはきれいになったはずです。次はドキュメントを復号します。
私たちはPythonスクリプトを使って、AES公開鍵を特定して、その数値を因数分解して、それから秘密鍵を特定して、そしてファイルを一つ復号します。一度復号に成功したら、コンピュータすべてを対象に実行できます。できるなら、多く速く処理するために他のコンピューターを使ってください。
インストールは管理者権限で行ってください。また、インストール中の操作で、Pythonをパスに追加するオプションを必ず選択すること。
python -c "import urllib2; print urllib2.urlopen('https://bootstrap.pypa.io/ez_setup.py').read()"; | python easy_install pip
pip install http://www.voidspace.org.uk/python/pycrypto-2.6.1/pycrypto-2.6.1-cp27-none-win_amd64.whl
pip install ecdsa
私の実行結果は以下の通りです:
Cannot decrypt ./VENDOR LISTING BY CATAGORY.xlsx.vvv, unknown key
Software has encountered the following unknown AES keys, please crack them first using msieve: A1373BCF4EDB39BCFEDD44FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0 found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
Alternatively, you can crack the following Bitcoin key(s) using msieve, and use them with TeslaDecoder: 5ECA19D475A313AC3DEF915CE6FA37BE012CD1676590C8F253135A3AD92345B78C32C46DB3246ED84A7B9A8C62F1A13D2AF08F09FFB3551701E7B75CCC79457C found in ./VENDOR LISTING BY CATAGORY.xlsx.vvv
私の場合は以下の値をコピーしました。 A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0
さっきの数値はこのようになります: 8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640
私の場合だと、8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640 を入力して「Factorize!」を押してみました。もしあなたがラッキーなら、画面の左端には「FF」と表示されるでしょう。これは完全に因数分解されていて、すべての因数がリストされていることを意味します。この場合、あなたは以下のyafuを使う手順を行う必要はありません。unfactor.pyのところ(訳者注：手順19)までスキップできます。
もし「CF」や「C」と表示された場合、私たちはまず因数分解をするためにyafuを実行する必要があります。因数分解ができたら、 factordb.com に戻ってその整数を下のほうにあるレポートフィールドからレポートしましょう。そうすることで、その数値が「FF」で表示されるようになります。因数分解は数値の複雑さによって数時間・数日間・数週間かかります。因数分解が終わったら、私たちは秘密鍵を得るのに使用するたくさんの数値(因数)を得ていることでしょう。私はmsieve, yafuとこれらのバリエーションを試しました。これを動かすのは結構大変でした。いくつかの問題は説明が不完全で、すべての構文を与えられていませんでした。しかし、ついに私はyafuを動かしました。私が何をしたか、以下に書きます。
例: yafu-x64.exe "factor(8443554284208758706290725803426642738777516291375882082881197977752270634322152168104703798454983966849000112082164921264407639940139993317228747401502640)" –v –threads 4
因数分解を始めると、小さな因数は素早く見つかり、このようにリストされるでしょう : 「div: found prime factor = x」。ログファイルの中から「found prime factor」を検索します。
さらに「prp」も検索します。このような行が見つかるでしょう。: prp32 = 25647545727466257054833379561743
これが私の実行結果です:
unfactor-ecdsa.py VENDOR.xlsx.vvv 2 2 2 2 3 5 367 12757 25647545727466257054833379561743 75938537910569673895890812481364802067167 3858259146292441335085163995598583072203543699186432807503634945432314399
Found AES private key: b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88' (BDA2543A2175B9F30DF6F30960EC082F3EC5EF61D403A35BC1477E10470A7C88)
'A1373BCF4EDB39BCFEDD484FA86A82498410A7E83456D8E80E52966F6717CB8B8E5846BBC7A540647AE770FEDEAA0E7F8A0466082156DB332A757407A12C9FB0': b'\xbd\xa2\x54\x3a\x21\x75\xb9\xf3\x0d\xf6\xf3\x09\x60\xec\x08\x2f\x3e\xc5\xef\x61\xd4\x03\xa3\x5b\xc1\x47\x7e\x10\x47\x0a\x7c\x88',
ファイルが復号されるはずです。
あなたの重要なファイルをバックアップしましょう！できればすべてのシステムで。同じようなことが起こった場合でも、回復するために無数の時間を使うかわりに、バックアップから復元できるようになるから。
きっとこれらの追加の手順は皆さんを助けます。自分がこの手順を行ったときはたくさんの問題がありました。それでもしあなたがこれを不完全だと思うなら、手順を更新するのでお知らせください。たぶん私たちはいっしょにこの手順をより完璧にすることができます。ありがとう！
https://community.norton.com/en/forums/how-decrypt-teslacrypt-vvv-files
http://www.mobilefish.com/services/big_number/big_number.php
http://gilchrist.ca/jeff/factoring/nfs_beginners_guide.html
http://www.mersenneforum.org/showthread.php?t=20779
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。
SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート（アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類）は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは（ほぼ）独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧：
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
なるべく皆が憧れるようなハッカーのことを調べて、知恵袋とかLINEQなどでフィールドワークをしてきた。
その結果分かったことはIPアドレスについては未だ価値があるということだ。
いいんだよwhoisしちゃえばいいんだよ。
そして住所抜いちゃえよ。
関連記事
http://anond.hatelabo.jp/20150219004340
OKOK、Whoisで相手を恐がらせることは出来ても、IPアドレスを奪取できなければ片手落ちだ。
『僕のIPは127.0.0.1です』という情報を鵜呑みにしてしまうことにもなる。
さてどうやって奪取するんだ？
まずは準備だ。
この準備は一回やればいい。
レンタルサーバーにすると比較的安くかつ1〜4の作業が簡略化されるぞ。
あとは実践だ。
メールアドレスを知っていて、相手がHTMLメールを許しているならば
別に公開サーバーを用意しなくても自分のパソコンを一時的にHTTPサーバーにすればいいが、
それだと相手にも自分のIP分かってしまう。（whoisされちゃうぞ！！）
（あ、ドメイン契約するときは本当にwhois気をつけろよ。お名前でorg取ると面白いことになるからね）
