アカウント名:
パスワード:
クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね?公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。
クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね? 公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。
「公開鍵」を悪意のある第三者の公開鍵にすり替えるなりすまし攻撃を防ぐためには、信頼できる第三者機関(Trusted Third party)が各人のID(LINE の場合、LINE ID)と公開鍵を対応付けて認証する必要があります。
SSL/TLS の場合には VeriSign などの認証局(CA)がそれを行っているため、VeriSign の中の人であれば(通
信頼されている認証局が公的に発行するのとLINEがLINEのために発行するのでは大違いです。
公的なCAも不正な証明書を発行すればなりすましできますが、それは現実的ではありません。CAがまがりなりにも信頼されているのは不正が技術的に可能・不可能ではなく、不正を第三者が検証できると考えられていることと、不正によって信頼を失ってブラウザベンダやユーザに失効させられるリスクを背負っているからです。
LINEがLINEの発行したIDに対してLINEのクライアントアプリでのみ検証可能な公的でない証明を与えるのでは意味がありません。またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。
え、他社を信用するなんてもってのほかでしょ? クラウドサービスで情報流出があるたびにみんなそう言ってるんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
その鍵はどうやって検証したの? (スコア:2)
クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね?
公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。
LINEの中の人は 「なりすまし」 が可能 (スコア:4, 興味深い)
「公開鍵」を悪意のある第三者の公開鍵にすり替えるなりすまし攻撃を防ぐためには、信頼できる第三者機関(Trusted Third party)が各人のID(LINE の場合、LINE ID)と公開鍵を対応付けて認証する必要があります。
SSL/TLS の場合には VeriSign などの認証局(CA)がそれを行っているため、VeriSign の中の人であれば(通
Re: (スコア:3)
信頼されている認証局が公的に発行するのとLINEがLINEのために発行するのでは大違いです。
公的なCAも不正な証明書を発行すればなりすましできますが、それは現実的ではありません。CAがまがりなりにも信頼されているのは不正が技術的に可能・不可能ではなく、不正を第三者が検証できると考えられていることと、不正によって信頼を失ってブラウザベンダやユーザに失効させられるリスクを背負っているからです。
LINEがLINEの発行したIDに対してLINEのクライアントアプリでのみ検証可能な公的でない証明を与えるのでは意味がありません。またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。
Re:LINEの中の人は 「なりすまし」 が可能 (スコア:0)
え、他社を信用するなんてもってのほかでしょ? クラウドサービスで情報流出があるたびにみんなそう言ってるんだけど。