S/MIMEで考える電子署名の基本機能

S/MIMEの署名機能の保証する範囲には実は注意が必要っぽい、というのと、基本に立ち返ると電子署名は「改ざん検出が目的」という説明では不十分だよね、という話。 ※2020/1/25 規格について調べた話を追加
6

まずは検証後の話から

angel as ㌵㌤の猫 @angel_p_57

さてと。ということで簡単に検証終了。 あれだね。S/MIME署名って、やっぱりToの内容は署名対象じゃないのね。次の図のように、Toだけ書き換えて「誰宛か」を誤魔化すことができちゃう。 pic.twitter.com/FT92WfHHul

2020-01-21 23:43:37
拡大
拡大

S/MIMEは署名によるメール送信内容の保証・否認(しらばっくれ)防止機能があるはずなんだけど、ToやCcで「誰宛に発信した」かは、実は保証対象外になってた、ということ。
今まで知らなかったし、この点に注意するような話も見たことない。それなりに重要なポイントだと思うんだけど…? ということで、詳しい情報をお持ちの方は是非ご教示ください。

angel as ㌵㌤の猫 @angel_p_57

【募集】この挙動ってS/MIMEを使う上で常識なんでしょうか? 詳しい方教えてください。 twitter.com/angel_p_57/sta…

2020-01-21 23:46:41

なぜ検証してみたかというと、こういう話で不意に気付いたから。

angel as ㌵㌤の猫 @angel_p_57

なんか、ちょっとS/MIME見てみたけど、これ署名の仕様バグってないか? …バグというより考慮不足か。運用で回避できるとは言え。

2020-01-21 12:46:29
angel as ㌵㌤の猫 @angel_p_57

何がまずいかというと、「誰が」署名したかの情報は ( 当然ながら ) 載るんだけど、「誰宛か」の情報は署名の対象外になっている。 メール本文に明示すればいいんだけど、To で宛先指定しただけだと含まれない。 …これ、実装の問題? でも、メールのヘッダ構成上、どうしてもこうなるよね。

2020-01-21 12:50:15
angel as ㌵㌤の猫 @angel_p_57

宛先が含まれないと何がまずいかというと、文面を ( 変更できないとは言え ) 流用できてしまうこと。例えば A→B で「○円あげます」とAの署名付きメールが送られたとして、それを別人のCが入手してAに「メールの通り金くれ!」と要求できちゃう。

2020-01-21 12:53:35
angel as ㌵㌤の猫 @angel_p_57

Aが「いやいや、B宛なのでCには関係ないよ」とは抗弁できない。署名の保護範囲外だから、立証できない。逆にC宛じゃないことを認めちゃうと、同じ理屈でB宛であることすら否定できちゃう。署名の基本機能「否認防止」の否定で、何やってんだか分からない。

2020-01-21 12:56:39
angel as ㌵㌤の猫 @angel_p_57

もちろんそれを前提として「本文に宛名がなかったら意味ないですよ」が常識化してれば良いけど、多分そんなことないよね。 何より、わざわざメールソフトで To とか情報入れてるのに、なんで別に入れなきゃいけないんだと。

2020-01-21 12:59:05
angel as ㌵㌤の猫 @angel_p_57

PGPメールってどうなってんだろ。

2020-01-21 12:59:59

PGPもS/MIMEと同じようにMIMEとしてメッセージを構成するから、似たような話になると想像。

angel as ㌵㌤の猫 @angel_p_57

なんでこんなことを考えたかと言うと、電子署名のよくある説明で「改ざん防止」とあるの、ホントはよくないよなー、というところからの思考実験で。

2020-01-21 13:02:21
angel as ㌵㌤の猫 @angel_p_57

さてと。昼間の続き。 いくつかの記事で電子署名のことを説明してるけど、「改ざん検知/防止が目的」とは、私は言ってないし、考えてもいなかったりする。世間一般的な説明と違って。

2020-01-21 19:07:15
angel as ㌵㌤の猫 @angel_p_57

「いやそれはおかしい。改ざん検知に使えるじゃないか」と突っ込みが来るかも知れない。 そこは、こう説明している。 「データの改ざんがあれば、検証時に不整合として検出することもできます」 qiita.com/angel_p_57/ite…

2020-01-21 19:10:46

「そういう機能を実現している」と「そういう目的で使う」には差があるよ、ということ。

angel as ㌵㌤の猫 @angel_p_57

なんと言うか、「守るのがナイトではない。守ってしまうのがナイトだ」みたいな感じだろうか。 敢えてそう言ってるのは、もちろん意味的に全然違うからなんだけど、多分大多数の人には些細な言葉遣いの違いにしか見えないだろうから、あんまり積極的にアピールはしていない。

2020-01-21 19:14:13
angel as ㌵㌤の猫 @angel_p_57

代わりに「同意や保証を示す証跡」「否認(しらばっくれ)防止」と説明してる。簡単に言うと「ホンモノだということや、その内容を自分が認めてますよ」という「保証」が目的。 …これでもまだ「改ざん防止とどう違うの?」という声が出そうな気がする。

2020-01-21 19:31:31
angel as ㌵㌤の猫 @angel_p_57

なので、もっと突っ込んで言うと「第三者へも立証できる保証があるかどうか」ということになる。 ときに電子署名と対比されるメッセージ認証コード ( 共通鍵を使う技術 )、こちらは改ざん検知に使われるけど、この保証がない。

2020-01-21 19:41:37

なので、それなりに「公開鍵暗号(暗号化)⇔共通鍵暗号」「電子署名⇔メッセージ認証コード」の対比で説明しようとするのを見かけるけど、筋が悪いと思っていて好みではない。

angel as ㌵㌤の猫 @angel_p_57

現実でもこの違いは経験したことあるはず。 伝言ゲームを嫌って誰かからサシで話を聞けば、内容が誤って伝わることはない。だけど、その内容を第三者には立証できない。保証が欲しければ、録音するとか、議事録を残してサインを貰うことになる。( 前者の場合は「声紋」が天然の印鑑の役割を果たす )

2020-01-21 19:50:02
angel as ㌵㌤の猫 @angel_p_57

なので、この「保証」というのは単なる改ざん防止よりも遥かに大きな意味を持つことになるし、同時に悪用されないように気を使う必要がある。 簡単に言うと、署名の流用に気をつけると言うこと。 ※現実でも、白紙にハンコついちゃダメとか、言われるでしょ? 流用を許しちゃうから

2020-01-21 19:54:32
angel as ㌵㌤の猫 @angel_p_57

ただこれ、「不特定多数あての情報発信やデータ配布」だと、気をつける点は少ない。せいぜい、「『データを分割してそれぞれに署名する』ことを避ける」くらい。 これは、コード署名であったり、認証局の発行する公開鍵証明書であったり、多くのケースが該当する。

2020-01-21 19:58:28
angel as ㌵㌤の猫 @angel_p_57

なんで問題にならないかと言うと、別にどんなルートで、誰にデータが渡っても「流用」されるおそれがないから。「自分が保証してる」状況には変わりがない。 ※著作権なんかの話ではないので、念の為

2020-01-21 20:22:27
残りを読む(21)

コメント

たくさん@yet25% @takusan5555 2020年1月22日
S/MIME、こういう検証すれば保証範囲とか分かるんですね。もっと深めねば。
0