  |
はてなキーワード: 公開鍵暗号方式とは
大企業ではほとんど採用されていると思うが、メールゲートウェイ型のセキュリティアプライアンスで、添付ファイルが
ついていたら暗号化解除して中に含まれるファイルに悪意があるマクロ、プログラムが含まれるものがないか検査して
OKだったら送信許可、NGなら削除されましたの通知だけを送るなどをしている。
従いスキャンできないと、一律でメールは削除、若しくは添付ファイルは削除されましたの通知のみ送られる。
企業のセキュリティポリシーとしてこうしているところはあります。ウイルス感染対策の検知対策確度を上げるため。
さらに、ローカルPCにウイルススキャンが入っていて添付ファイルをローカル保存するとき、開くときにスキャンが
メールゲートウェイ型アプライアンスで、企業のインバウンド/アウトバウンドメールを一律、
チェックしたいんじゃないのかな。それなりに意味はあると思いますが、例えばgmailだと、
これまで暗号化解除(解析&解除)でチェックしていたと思われるが、CPUリソース食いまくりな事
や実効性への疑問(ほかの対策若しくは、複数対策を組み合わせる事での効率化)があって、
添付ファイルはチェックされず送られるか、削除されて何も通知されないみたいです。
> 3、なんで毎回同じPWじゃないの？
同じパスワードだとそれが漏れたり、第三者に知れたら容易に暗号化解除して見れてしまうから。
> これは1の通り、プロキシサーバーでスキャンできる仕組みを作る必要があるってことでいい？
プロキシーサーバではなくてメールゲートウェイ型アプライアンス(古くはオンプレでInterscanなり、、最近は知らんけど)
> この場合既存の仕組みを使えないし、クラウドサービスにロックインされるし
> 腰が重いのもわかる気がする
なにか同等のサービスがあると思う。
とりあえず、G Suite(旧google apps)だとgmailのメールフィルタ機能が標準装備でゴミメールはだいぶ減る。
メールソフトへの実装があまりはやらなかったのもあるし、暗号化強度の問題もあったのでは。(推測)
公開鍵暗号方式の実装したもので使いやすいもの、若しくは この手の送り手/受け手が正しい人かつ、
悪意を持ったプログラムが含まれないことを担保できるメール送受信の仕組みを作ればよいと思う。
インターネット自体は、自律分散系システムなので送ったものが必ず届くという確証もないし、
元エントリーの人がどこまで理解しているか不明だけど、自分が初心者だったときこういう説明がほしかったという話をしてみる。
暗号方式、特に公開鍵暗号の理解が難しいのはいくつか理由がある。
②素朴な利用例が少なく応用的な利用がいくつもある
また、ざっくりした概念以上のものをきちんと理解しようと思うと
④何がどのくらい安全で何がどのくらい危険かセキュリティ的な概念の説明
ここでは自分的にこういう順番で概念を把握していったという流れを書いてみる。
まず、物理的な錠前や書留郵便をイメージするのはあきらめてほしい。
あくまでもデジタルデータを別のデジタルデータに変換して再び元に戻すためのものだ。
公開鍵暗号登場以前は、パスワードを使って変換（暗号化）して、同じパスワードを使って元に戻す（復号化）という共通鍵暗号の時代が長く続いた。
それが暗号化のパスワードと復号化のパスワードで異なるものを使うという技術だ。
・特殊な数学的アルゴリズムでパスワード１から、それと対になるパスワード２を生成する
・パスワード１で暗号化したものがパスワード２で復号できるだけでなく、その逆つまりパスワード２で暗号化したものがパスワード１で復号できる（※）
今はその数学的アルゴリズムまで理解する必要はない。ただそういうことが可能になったというだけでいい。
パスワード１（秘密鍵）を自分以外が見られないように保管して、パスワード２（公開鍵）を通信相手に渡せば暗号通信ができそうということは理解できると思う。
ちなみにこのパスワードの長さは、プログラムで生成した100桁以上の数字が使われることが多く、それを定型的な千文字程度のテキストにして使われるのが一般的。
ツールで生成すると千文字程度のテキストファイルが秘密鍵用と公開鍵用の2個できる。
これだけの桁数なので暗号化復号化の計算はそれなりに時間がかかる。（※）
（※） このあたりは一般的な公開鍵暗号というよりRSA公開鍵暗号特有の話も混ざってます。詳しくは専門書参照
次にこの発明を使ったらどういうことができるだろうか、応用できる先を考えてみよう。
誰でも最初に思いつく例だけどシンプルすぎて共通鍵と変わらなくありがたみがない。
(b)僕にメッセージを送るときは僕の公開鍵で暗号化してね（いわゆる公開鍵暗号）
メッセージの送信先を間違って別人に送ってしまっても他人は読めないし、経路のどこかで盗み見や内容の一部を改竄されたりすることがない。
メッセージに返信するときは今度は「僕」ではなく相手の公開鍵を使って暗号化する。
(c)本文を毎回全部暗号化すると時間がかかるから共通鍵を君の公開鍵で暗号化したものを送るね。それを君の秘密鍵で復号したら以降は高速な共通鍵暗号で通信しよう（鍵交換）
共通鍵暗号の高速性というメリットを利用できて、かつ生の共通鍵がネットに流れるリスクを排除した良いとこ取りの方式。
(d)暗号化しない本文と、本文から計算したハッシュ値を秘密鍵で暗号化したものを送るね。公開鍵で復号化したハッシュ値がそっちで計算したハッシュ値と同じなら本文は改竄されてないよ。
それからこの暗号化は僕しかできないから確かに僕から送られた文書、僕から送られた内容であると保証できるよ。（電子署名）
この「電子署名」の実現により、さらに次のような応用が可能になる。
(e)ログイン時に毎回パスワードを打つと見られたりして危険だからユーザ名等に署名したものを送るね。公開鍵で復号（検証）OKならログインさせて（公開鍵認証）
(f)僕は信頼できるよ。これがAさんの署名入りのお墨付き。検証してみて。
Aさんは信頼できるよ。これがBさんの署名入りのお墨付き。検証してみて。
Bさんは信頼できるよ。これが世界一信頼できる人の署名入りのお墨付き。検証してみて。
（サーバ証明書）
前項のようなやりとりはほとんどアプリが自動的にやってくれるので、コンピュータ技術者以外の人が公開鍵や秘密鍵を直接扱う機会は現状ほとんどないと思う。
ウェブブラウザのアドレス欄に鍵マークが表示されていたらそれは鍵交換やサーバ証明書技術が使われていて、鍵マークを右クリックすると証明書を表示できる。
メールアプリでも最近は自動的に鍵交換やサーバ証明書が使われている。
もしメールアプリにPGPの設定オプションがあればそこで公開鍵と秘密鍵を設定すると特定の相手と本格的な暗号化メールがやり取り可能になる。
サーバ操作するコンピュータ技術者だと公開鍵認証もよく使われていて、ツールで生成した公開鍵をサーバに登録してログインに利用してる。
最後に観たのは探偵たちの鎮魂歌だから、実に12年ぶりである。
地上波はそれ以上に観ていない。
まず、キャラの演技だいぶ変わってる気がする。
特にアガサ博士と少年探偵団、灰原に違和感。まぁ10年以上も経てば変わるか。
それと、声に老けを感じてしまい、少し寂しく。そのうちドラえもんみたいに世代交代もあるのだろうか。
おっちゃんは声優も変わって演技も違うのだけど、そんなに抵抗はなかった。
ストーリーについては、「いやいやそうはならんやろｗ」とか「なんでやねんｗ」って突っ込みどころが多くて、内心突っ込みながら楽しんでいたんだけど、世間一般的には重厚なストーリーという評判らしい。マジか。
安室さんは初見だけど、29歳で(恐らく年功序列が色濃く残っているであろう)公安の秘密組織で指示を出せるくらいの地位があるという日本中の才能とコネの特異点のような存在が、IoTテロの可能性に思い至らないものだろうか。あまつさえ、スマホにこっそり盗聴アプリを仕込む知識もあるというのに。
やたらコナン上げしていたのが気になった。（まぁ原作やら他のエピソードで理由が描かれてるんだろうけど）
ついでにNW経由で操作されるだけで電子機器が爆発炎上までしちゃうあの世界の安全基準はどうなってんだ。
探査機のパスワードを打ち込む瞬間、「よろしくおねがいしまあああす！」と聞こえた気がした。そういえばあれも人工衛星をGPS誘導によって落とす話だったか。
ていうか探査機との通信に使う暗号方式って、パスワードによる共通鍵暗号方式なん？公開鍵暗号方式とか使うんでないの？そこらへん詳しくないから誰か教えて。
RX-7の頑強さとかキック力増強シューズで蹴り出されたボールの威力とかはまぁ空想科学読本あたりで検証されるだろう。今も空想科学読本が残ってるかはわからないけど。
てな感じで、基本突っ込みながら楽しむ作品だと思ってるけど、100億に相当するかと言われたらちょっと微妙な感じ。
「量子コンピューターが一般化したら 」というと焦点がぼやけるから
という前提でいこう。
何か中央集権的な手段で、過去の取引履歴を保護してやらないかぎり
ビットコインでは過去の取引履歴から口座の残高を求めるので、取引履歴が捏造されると
ある人はあなたの口座には100BTCがあると言い、
別の人はあなたの口座には1BTCも入っていないと言う状況になる。
しかし、過渡期に量子コンピュータでも有効なハッシュ関数などを使って
「『正しい』過去の取引履歴」が中央集権的に確定させることはできる。
そうすれば前述の問題は発生しなくなる。
ブロック生成の仕様を、量子コンピュータでも解けない計算に切り替えれば、
運用も続けられる。
試験、受けました。
ことさら話題にするようなことでもないかもしれませんが、せっかくなので書きます。
これから受ける人などの参考になれば幸いです。
30代。
製造業。
プログラミング歴は数ヶ月。
それまではExcelWordがちょっと分かるくらいだった。
初受験。
内製のソフトがC++でできていて、これを色々弄くれるようになればあんなところやこんなところまで自動化できるなあ、でも何も知らないまま弄るのはちょっと怖いなあ…
そうだ、勉強しよう！
8月半ば、受験申込期間の締め切りギリギリに試験の存在を知り応募。
勉強期間は2ヶ月ほど。
平日は1日1〜2時間。土日は1日3〜5時間。まったく勉強しなかった日が10日ほど。
最初に、ネットで評価の高かった合格教本という本を買って読んでみた。
基本情報の知識もない状態だと、書いてあることがもうほんとにまったく分からず、挫折しそうになった。
方針を変えて、応用情報技術者試験ドットコムで過去問道場をひたすら回した。
分からない言葉はネットで調べて、これはと思う説明に出会ったらOneNoteにひたすらコピペした。
最後の2週間はドットコムでユーザー登録をし、理解度で問題を色分けするようにした。
最後の1週間でピヨ太くんのサイト(正式名称長い)を見つけ、分からない言葉はまずこのサイトで検索するようにした。
受験前は、
…のどれかを選ぼうかなと考えていた。
いわゆるストラテジ、マネジメント系科目だけで固めても良かったのだけど、組込みなんかは普段の生活からイメージしやすいし、2時間半の長丁場ならテクノロジ系科目を間に挟んだ方がほどよく頭のリフレッシュになるかなーと思っていた。
実際の試験では、
…を選んだ。
机上に置けるような時計は持っていなかったし、まあ午前だけなら時計が無くても大丈夫だろうとタカをくくっていた。
問題を順当に最後まで解いて、全て順番通りにマークされてることを確認してから、手を挙げて外へ出た。
15分ほど余っていた。
さすがに午後は時計が無いとマズイと思い、休憩中に買ってくる。
セキュリティ(必須問題)の設問1で長考してしまい、20分ほど経っても解答用紙の半分が埋まっていない状態。
とりあえず他の問に移り、最後に余った時間でセキュリティに戻る方針にシフト。
経営はぱっと見簿記の知識が生かせそうだと思い選んだのだけど、「固定長期適合率」がどういう計算式なのか見当がつかない。
早々に切り上げる。
組込みの設問1でまたも長考、ほぼ解答を埋められたものの、結局40分ほど費やす。
サビマネ、監査は焦りから問題文の通読ができず、設問を最初に読むようになり、結果読み返しが増えてしまった。
監査を終えたところで5分くらい余ったので、這々の体でセキュリティに戻る。
午前とは逆に、始終時間との戦いだった。
午前は78.75点。
午前は問題用紙に選んだ選択肢に○する余裕があったのだけど、午後はそれがなくなって、問題解くのに必死で自分が何を書いたかしっかり思い出せない。
色々と書いたけれど、そういう訳で正直受かってるかまったく分からない。
配点、部分点次第といったところ。
怖い。
午後の対策が難しい。
午後対策でよく見られるのは「国語の読解力をつける」というアドバイスだが、読解力というのは漠然としていてレベルの向上も分かりづらい。
今の私なら、以下の順番で勉強を進めるかもしれない。
そもそも、「試験に合格するための勉強」に終始して、最初の動機がなおざりになっちゃった感が否めません。
…でもそれらがなんなのかはよく知らない、みたいな。
一つ確実に「分かった」と胸を張って言えることは、
分からないことは、調べればいい。
分かる人に、聞けばいい。
ってことですかね。
受かってなかったとしても、もう受けないかもしれませんね。
はぁ…10万欲しいなぁ…
以上で終わりです。
最後まで読んでいただきありがとうございます。
お疲れ様でした。
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 サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
恥ずかしすぎてハンドルネームでやってる自分のブログにすら書けず、かと言ってどこかに吐き出したくはあったのでここに書いておく。
見た人は存分に笑い飛ばして欲しい。
先週、趣味で立てたVPSサーバー(CentOS 6.5)のCPU使用率が、気付くまでの9時間ずっと100%になっていた。
作動中のプロセスを見ると、2つのperlプロセスがその原因であることが分かった。
そのプロセスはユーザー「postgres」によって実行されたプロセスだった。
postgresは、PostgreSQLをインストールすると勝手に作られるユーザーだ。
先日自分でPostgreSQL9.4をインストールしたので、このユーザーの存在自体は問題無い。
その時このpostgresに、「postgres」という簡素なパスワードを、passwdコマンドで設定した。
「まぁ無いよりはマシなんじゃね？サーバー内でしか使わないユーザーだからハッキングの心配とかないしどうでも良いけど〜。」
と言ってたと思う。
その程度の認識だった。
これにより下記コマンドでpostgresとしてサーバーに入れてしまう状態になっていた。
$ ssh postgres@my.server.address.com
実行するとパスワードを求められるが、もちろんそれは前述のパスワード「postgres」だ。
それまではパスワードを設定していなかったので逆に助かっていた。
パスワードが設定されていないユーザーにはsshでは入れないからだ。
「もちろん」というが、それまではユーザーのパスワードがsshで入る時のパスワードになることを知らなかった。
そしてそれだけで接続可能になる可能性があることを知らなかった。
sshサーバーの設定はひと通り、自分が使っているVPSサービスがやってくれており、多分大丈夫だろうとそのまま使っていたからだ。
それでハッキングされ、そいつに謎のperlスクリプトを走らされていた。
具体的なスクリプトファイルや.bash_historyは消されていたようで、どんなものを走らせられていたのかよく分からない。
ハッキングであることを知ったのは、/var/log/secure を見たからだが、そもそもこの自体に陥るまで /var/log/secure の存在とその役割を知らなかった。
「ポスグレ(PostgreSQL)がなんかバグったわ〜でも原因がよく分からんわ〜ヒマだしハッキングの可能性も考えとくか〜でも絶対ポスグレがバグったんだわ〜」
でググって初めて知ったぐらいだ。
それで見たらパスワード設定してから9日間でそれぞれ別の端末23件から不正アクセスを受けていたことが分かった。
VPSサービスのコントロールパネルを見ると、その内の1件が侵入した3分後にCPU100%現象が始まったので、十中八九そいつの仕業だろう。
それ以外の連中が何をやったのかは分からない。
分からないのでOSを再インストールした。DoS攻撃だったらあとで攻撃先に訴えられるかもしれないので、全データを家のパソコンにDLする事で証拠（？）を保存してから。
/etc/ssh/sshd_config には、sshサーバーの設定が書かれている。
その中のPasswordAuthenticationをnoにし、公開鍵暗号方式による認証のみ受け付けるようにした。
他になんかやることとかある？おしえてぴょーん
もともとはUNIXに使われていたCrypt,DESのブロック長が８バイトだったのと
当時はそんなにディスク容量もなかったので便宜上バスワードは８バイトまで。（８バイトで切られる）
という歴史的仕様だった時の名残。今はSHA256かSHA512だから６４文字ぐらいまでなら何の問題もない。
もっとも、当のUNIXの世界ではとっくの昔に公開鍵暗号方式とワンタイムパスワードの組み合わせになってるので
直接パスワードを送信したりはしない。
３０年か４０年ぐらい昔の仕様が今でも残っているのが８文字なんじゃないかなぁ。いくらなんでも、時代に追いついてなさすぎだよね。
ちなみにDESなんてもう使わない。３DESですら脆弱、MD5,SHA-1ですら脆弱と呼ばれる時代っすからね。
ただ銀行系の人は、そんな知識もないでしょ（技術屋じゃないからね）。下手すりゃ証明書はベリサインだよね。とかまだ言ってるとおもう。
彼らの知識を更新するのは、とんでもない重労働だからSEは誰もやらないと思う。そんな事しなくても古い技術で金がもらえるのにわざわざ危険を犯してまで進言する奴はもう銀行業界にはいないだろ。
