暗号化 ZIP メールはなぜダメ? PPAP 絶対殺すマン育成講座
— email, Security — 35 min read
PPAP 絶対殺す
不正メール絶対殺す
PPAP メール (暗号化 ZIP ファイル添付・パスワード後送メール) はダメです.という話をこの記事にたどり着くような人は一度はきいたことあると思いますが,なぜダメなのか説明できますか? 本稿では私の主観に基づいて複数の観点から PPAP がダメな理由を説明します. 「PPAP なんてピコ太郎しかきいたことがない」という方でも,この記事を最後まで読む頃には体の芯から PPAP がダメな理由を理解し,私と一緒に「PPAP 絶対殺す」「不正メール絶対殺す」と毎日口ずさむようになっています.
[本稿は限界開発鯖 Advent Calendar 2020 第 1 日目の記事です]
※本稿はセキュリティやメール運用のプロではない私の主観にてそれぞれの観点を評価したポエムです.個々の記述が業界標準というわけではないことにご留意ください.逆にいうと,プロの方はこんなことは理解されていると思うので,界隈の人にとっては駄文です... ※本稿で扱う PPAP は後述する伝統芸能をさすものであってピコ太郎氏の楽曲をさすものではありません.本稿ではかなりボロクソにいいますが,楽曲およびピコ太郎氏には一切非がないことをあらかじめ申し上げます.
そもそも・PPAP メールとは
言葉自体は JIPDEC の方 1 (当時) が最初に使い始めたもののようです.
Password つき zip 暗号化ファイルを送ります Password を送ります A ん号化 Protocol
つまり「パスワード別送メール」などと言われるものです. PPAP は技術的になんの実効力も伴わないので,本稿ではプロトコルや技術などとは呼ばずに伝統芸能と呼びます.
なぜ「なぜだめなのか」を知る必要があるのか・あるある勘違い
先日,霞が関で PPAP をなくすことになったという報道 2 がありました.これを見て「PPAP ってなんかしらんけどだめなんだ」と思った方も多いと思います.(なお,ITmedia の記事 23 を見る限りでは,デジタル担当大臣・行革担当大臣はじめ霞が関の皆様も「なぜダメなのか」が理解できていないようなので,ぜひ読んでいただきたいです.もしかしたら ITmedia がそう書いているだけかもしれませんが.)
しかし,なんでダメなのかを知らないと,次のような勘違いや悪い人に惑わされてしまいます.また,実際に惑わされている例もあるようです.
誤解「うちは霞が関みたいな重要な機密情報扱ってないからヨシ!」
- 扱っている情報の種類にかかわらず PPAP は悪影響を及ぼします.
誤解「ZIP はだめだから別のファイル形式にすればヨシ!」
- PPAP の悪影響はファイル形式に由来するものではありません.Word ファイルや Excel ファイルで PPAP する例も見られますが,本稿で説明するように全く意味はありません.Microsoft office を使っていればデフォルト設定で勝手に検疫してはくれますが,やはり意味はないのでやらないに越したことはありません.
誤解「パスワードの共有方法をちゃんと考えればヨシ!」 3
- PPAP の根本的な問題点はいくつかあり,パスワードの共有方法で解決できるものではありません.効率低下以外にもさらなる害をもたらします.
誤解「状況によって使い分ければヨシ!」 4
- PPAP は無駄なだけでなくセキュリティ上の脅威になります.PPAP して良いのは,潜在的に攻撃に加担する意思があるときだけです.
誤解「ISO/IEC 27001 や JIS Q 27001 (いわゆる ISMS 規格) で PPAP するよう定められている!」
- 2014 年版の JIS Q 27001 に準拠して策定された経産省の ISMS 5 を確認しましたが,そのような記述はありません.(JIS Q 27001 そのものは,すみません,手元にありませんでした.)
- それどころか,PPAP は同 ISMS 12.2.1.8-2 に定められる「マルウェア検出のための使用前の走査」を阻害します.
誤解「プライバシーマーク (P マーク) に必要!」
- プライバシーマークの運用機関である JIPDEC が公開している審査基準 6 にはそのようなことは一言も書かれていません.
- さらには,JIPDEC は「従来から推奨しておりません」と明確に否定しています 7 .
誤解「PPAP でむしろ日本のセキュリティ意識は高まっている!」 8
- この主張で引用されている数字 9 を素直に読むのであれば,経済水準が近い他国よりむしろ劣っていることになります.
- むしろこの数字から,ハイバリューで攻撃が成功しやすいターゲット を狙いたい攻撃者たちが,日本語のフィッシングメール・サイトやマルウェアを用意するのは当然であり,英国や北米と比べ狙われやすいとも捉えられます.
- しかし,PPAP をやめたあとを考える必要性については同意です.同じ過ちを繰り返さないためにも,みんなで PPAP がダメな理由を知る必要があると思います.
誤解「PPAP は誤送信対策にはなるから意味はある!」
- 下で紹介するとおり,自動化したら意味はありません.
- 誤送信した際に知らない人に突然攻撃を仕掛けるのが御社の評判を上げる善い行いだと思ってるならいいんじゃないでしょうか.
- 同じことは PGP や S/MIME でも可能です.むしろ Web of trust や PKI の仕組みを用いてよりトラストフルに誤送信対策をできます.PGP や S/MIME を導入せずとも,多くのファイル共有サービスではアカウントベースでの認可機能が備わっています.それらの点でも PPAP は劣っています.
などなど,ちゃんと理解しないと「歴史は繰り返す」「三歩進んで二歩下がる (二歩進んで三歩下がる?)」を生むことになります.本稿では PPAP がなぜダメなのかを理解し,どうすれば PPAP や類似する伝統芸能,不正メールを殺して健全な新しい生き方を歩めるのかを考えます.
PPAP メール撲滅のために私がやっていること
1. 記事を書く,日頃から話す
色んな人にやめようって言っています.「なんで?」と言われたらちゃんと理由を説明します.
2. PPAP しない
自分が PPAP しないのも当然重要です.社会に出たことがなく空気が読めないバカなのをいいことに,PPAP をお願いされても少なくともマシと思われる方法でデータを受け渡します.後半で詳しく紹介します.
3. PPAP メールを受け取らない
私が読むメールはすべて私が運用しているメールサーバ (MTA) を通すようにしています.MTA では rspamd というスパムフィルターを動かしており,様々な条件によってメールをスコアリングし,一定のスコア以上になるとそのメールをスパムとしてマークしたり,私の手元に送らず捨てたりします.
私の場合,暗号化された添付ファイル・MIME パートが含まれるメールについて,rspamd でスコアを加算するように設定しています.よって,場合によってはメールサーバに来た時点で止められて私の手元には届きません.本稿で紹介するとおり,PPAP メールは受け取る側もリスクにさらされる,怪しいメールなので,フィルタで弾かれて然るべきメールです.
弾いたら実運用上困らないか? 困ります.弾かれて然るべきなのに,弾いたら困るのです.だから皆さん PPAP しないでください.
受信者側も PPAP メールは受け取らない,そのポ リシーを適用することで悪しき伝統芸能をなくす社会貢献をしましょう.
ちなみに,私に PPAP メールが送られると「先ほどお送りしたファイルの復号化 ((笑)) パスワードをお送りします」と書いてあるメールだけが突然私のもとに届きます.当然,こんなことになるのは私がフィルタリングしているのが悪いのではなく PPAP して私に攻撃の意思を提示している先方が悪いので,なんの躊躇もなく再送を要求します.
「会社のポリシーで ZIP 暗号化しなくちゃいけないんです」そうですか,でも私のポリシーではそんなメールは受け取らないんですよ ^^
ダメな理由
1-3 でそもそも PPAP は期待される役割を全く果たしていないゴミであること,4-7 で PPAP がどんな害をもたらすか について説明します.
1. 同一チャネルで送っているからダメ
PPAP メールはデータの機密性を担保するために行われる伝統芸能だと考えています.仮に秘匿すべきデータを載せたメールが外に漏れ出してもパスワードがなければ中身が見えないと思われているのでしょう.ではどのような場合に暗号化 ZIP ファイルが漏れ出すのでしょう.
メールの通信チャネルが盗聴されていた場合 (MxA 間の MITM など) を想定しましょう.暗号化 ZIP ファイルが添付されたメールは盗聴されるのに,その後に送られるパスワードが載ったメールだけは盗聴されないと考えるのは虫が良すぎますね.
また,今では MTA の通信でも TLS を用いて通信路を暗号化する SMTPS が多く用いられますので,そもそも盗聴の危険は減っていると言えます.なのでそもそもこの観点では PPAP は必要ありませんね.
メールサーバ自体が信用できなかったらどうするか? そもそもそんなメールサーバは使うべきではないか,そんな情報はメールで送るべきでありません.なお,そのような場合でもメールで E2EE 通信できる方法を後述の PPAP の殺し方 4 つめで紹介します.
アカウントが乗っ取られていたらどうするか? アカウントが乗っ取られている場合はやはり PPAP しても乗っ取った人にパスワードがバレます.
2. 自動化しているからダメ
次に,メールを送るときに間違えて別の相手に送ってしまったことを想定します.しかし,PPAP を恒常的に行っている人たちは,どうやら添付ファイルを自動で暗号化 ZIP にして,ファイルを添付したメールを送信した直後に,同じ宛先にパスワードを載せたメールを自動で送るソフト (MUA や MTA) を使っていることがあるようです.これでは最初のメールを間違った相手に送った場合でももれなくパスワードが間違った相手に対し,それはそれは確実に,自動で送られてしまいます.
3. パスワードがなくても開く (COA 耐性が弱い) からダメ
(これはパスワードの強度によるところがあるとは思います.が,PPAP している方々がそこまで強力なパスワードをつけるでしょうか? 電話でパスワードを教えている 3 ところでは,読み上げやすい単語と日付の組み合わせくらいが関の山でしょうか.)
仮に,この伝統芸能の目論見通り,攻撃者 (盗聴者) には暗号化 ZIP ファイルしか手に入らなかったとしましょう.しかし,Web サービスなどとは違い,突破する対象 (暗号文) が手元に管理できる状態で存在するのですから,攻撃者は煮るなり焼くなり好きにして無理やりパスワードを突き止め復号できる,つまり暗号文単独攻撃 (COA) に脆弱なわけです.
この伝統芸能が始まった頃はそれも難しかったのかもしれませんが,今は誰でもクラウドに数千円から数万円払えば時間単位で大企業レベルの GPGPU が利用できる時代です.実際に,一定の複雑さまでのパスワードであれば,6 時間以内に 61% 以下の成功率で復号すると謳う Web サービス 10 まで出現しています.価格はなんと $29.企業が暗号化して送信したいような情報を得る対価としてこのコストはそんなに大きいでしょうか.
上記 3 点から,PPAP はそもそも期待される作用をしていない,全く意味のない伝統芸能であるのがわかるでしょう.
以降では,さらに PPAP が無意味なだけでなく有害である理由を説明します.
4. 受信者が暗号化 ZIP ファイルの検証を諦めるからダメ
(これは受信者の MUA や MTA の話なので,理由としては 薄いですが一応載せました.)
受信者は暗号化 ZIP ファイルを開かなければなりません.しかし,一部のマルウェア検知機能があるメールソフトなど (MUA) ではこれらのファイルの検証を諦めることがあります.例えば,Gmail は暗号化されたファイルのマルウェア検知を諦めます.
(ほかの方が言うように「マルウェアの検知ができない」と書きたいのですが,あまりにも現実的でないとはいえ 100% できないとも言い切れず,そんなことで反 PPAP にケチをつける阿呆が出てきたら困るのでこういう書き方で.)
5. 受信者が暗号化 ZIP を躊躇なく開くようになるからダメ
「中身がわからないように加工されている,もしかしたらウイルスが入っているかもしれないファイルをメールで送りつけられたら開きますか?」と聞かれたら,おそらく多くの人が No と答えるでしょう.しかしそれが Yes でまかり通ってしまうのがこの伝統芸能のある世界です.
幸いなことに現在多くの MUA では暗号化された添付ファイルを開く際には警告を表示してくれます.しかし,その警告を無視して開くのが常態化したのでは意味がありません.2020 年になっても未だにメールで媒介されるワームが健在である一因とも言えるでしょう.つまり,PPAP するだけで受信者に対するマルウェア攻撃の隠れ蓑作りに加担しているのです.本来であれば攻撃準備と捉えられても仕方ないでしょう (私はそう捉えます).
実際に,CISA によれば Emotet 型のワームでは暗号化された ZIP ファイルでマルウェアをばらまくケースが,Microsoft より報告 11されています.特に Emotet 型のワームに関して言えば日本語のビジネス書類に擬態したものも多く,一般のエンドユーザが PPAP と Emotet 型ワームを区別するのは困難です.
PPAP メールであるかどうかにかかわらず,そもそも中身を確認できないファイルを躊躇なく開くのはダメです.教育不足です.教育する側として「怪しいメールや添付ファイルは開かないようにしましょう」「機密情報はもれないように ZIP で固めて暗号化して送りましょう」と言っている人がいたら自己矛盾しています.
6. 自分の意識の低さを周りに知らしめてしまうからダメ
こんな欠陥しかなく受信者を危険に晒す伝統芸能をあえて続けることは,自分のセキュリティ意識が低いか,もしくは攻撃の意図があると周りに知らしめることになります.そんな人・企業が機密情報をやり取りする上で本当に信用できますか?
7. 相手方に手間をかけることになり失礼だからダメ
伝統芸能がお好きな方たちに刺さりそうな言い方にしてみました.
PPAP をすると受信者はメインのメールを受け取ったあと,パスワードが書かれたメールを探してパスワードをコピーしてきて暗号化 ZIP ファイルを復号・解凍する必要があります.大変手間ですね.
まして,送られてすぐ開封する時は良いものの,あとから見返したときに ZIP ファイルの載ったメールとそれに対応するパスワードが載ったメールのペアを探すのは困難を極めます 12.
こんな不要な手間を相手にかけさせて業務効率を低下させる伝統芸能を押し付けるのは大変失礼です.ビジネスマナーとして禁止されるべきだと思います.
ではどのように PPAP を殺す 脱 PPAP するのか
あなたがもし文化庁の方で,ここまで読んで「PPAP は技術的な意味はまったくないが,我が国にとって歴史上または芸術上価値の高い 13伝統芸能だ」と考えるのであればぜひ重要無形文化財にでも指定してください.
ですが,多くの方はそうではなく,日常生活やビジネスでメールを使いファイルをやり取りした経験のある方かと思います.そのような方にまで伝統芸能の日常的な実施を強制するのはきっと思想の自由か何かを侵害しています.たぶん.知らんけど.
そう思う方はぜひ下記を実施しましょう.
1. そもそもメールを使わない
今どきデフォルトでデータ転送・保存時の暗号化を行うコミュニケーションツールはいくらでもあります.
「外部のコミュ ニケーションツールは信用できない」???
- 私には麻痺した感覚で伝統芸能を続け周囲を危険にさらすことを推奨している人のほうが信用できません.
- コミュニケーションツールは危ないのに,PPAP ツールに脆弱性があり情報が漏れ出す危険性はまったくないのでしょうか?
- 御社が委託しているメールサーバは絶対安全なのでしょうか?
- 実は「新しいものを導入する」という見えない壁を作って,建前として信用できないことを理由に避けていませんか?
2. 普通にメールする
前半で述べた通り,PPAP は暗号化 (機密性や完全性の保持) の観点で言えば何もしていないに等しいです.ですから普通にファイルを添付して送るのと変わらないわけです.なら普通に添付すればいいじゃないですか.
3. ファイル共有サービスを使う
アカウントベースで認可ができるファイル共有サービスを使うという手もあります.Drive, OneDrive (SharePoint), Dropbox, Box などの定番クラウドサービスだけでなく,ownCloud, Nextcloud のようにオンプレミスで運用できる OSS もあります (これら 2 つはバンドルを買えば保守もついてきます).
「どのサービスを使えばいいかわからないから見送る」? ちゃんとビジネスとしてデータ保持契約を結べばどれを使っても PPAP よりはマシなんじゃないでしょうか (要出典) ?
「新しいサービスを導入するお金がない」? 今使っている PPAP ツールにいくら払ってらっしゃるんでしょう? そのようなツ ールを使っていなくとも PPAP している時点でセキュリティリスクですし信頼できないと見做されるので,潜在的によっぽどコストかと思います.
なお,ファイル共有サービスを使うにあたり,その上でまた ZIP 暗号化する,どの過程でもマルウェアスキャンが行われない,などという状況では本末転倒です.
4. PGP や S/MIME で署名・暗号化する
PGP や S/MIME などで暗号化と署名を両方行って送信すれば,パスワード別送する必要はないですし,受信者も送信者の公開鍵や CA を信頼する限りファイルの中身を検査しなくても安全だと言えます.
しかし,これらの技術は多少なりとも知識が必要で,一般ユーザには難しいかもしれません.
また,ウイルス・ワームに感染したデバイスからメールが送信された場合,自動的に暗号化/署名する設定になっていれば,暗号化 ZIP と同じく危険なファイルを検査無しで開くことになる可能性があります.例えば Yubikey に PGP 鍵を入れておく運用をしていれば (私の運用ですが) 仮に MUA (の動くデバイス・個人のパソコンなど) がその種のマルウェアに感染していてもマルウェアが勝手に署名することは (現実的に) 不可能です.しかし,送信者がこのような運用をしているかどうか受信者側には (個別に打ち合わせない限り) わかりません.そして,現実的にこのような運用をしている方はあまりいないでしょう.
理想的な PGP や S/MIME の運用が一般化すれば個人的には一番期待できる方法だと思いますが,普及までの道のりは険しいでしょう.
5. 受信者は PPAP メールを受け取らない
「PPAP メール撲滅のために私がやっていること」の 3 つ目で紹介したとおり,受信者にある程度自由がある場合,メールフィルタリングによって PPAP メールを受け取らないということができます.私は rspamd を使っていると紹介しましたが,ほかのソフトウェアやアプライアンスでも同様の設定が可能かと思います.受信者が PPAP メールを受け取らず「えーあの人 PPAP なんてやってるのープークスクス」とするのもまた,PPAP を殺すことに繋がります.
さあさ皆さんご一緒に「PPAP 絶対殺す」
本稿では不正なメールの使い方である PPAP がなぜダメなのか,その理由をご紹介し,どうすればそんなことをせずに生きられるのかをご提案しました (無論,私にとっては PPAP せずにどう生きればいいのかわからないという方が超理論ですが).
私は PPAP を含む不正メールの撲滅に微力ながら貢献するため,個人としてだけでなく研究室のメールサーバ運用適正化や所属するコンソーシアムなどでの BoF 開催・啓発活動を続けています.この世から不正なメール・メール運用を撲滅するにはみんなで協力する必要があります.その成果はきっと自分のメールボックスやメールサーバに帰ってきます (実際は成果として不正メールが"来なく"なるんですが).本稿を最後まで読んでくださった方はきっとそれに加担する意欲がある方だと思います.
ぜひ,一緒にこの世から不正なメールを撲滅しましょう.まずはここから,
「PPAP 絶対殺す」
あわせて読みたいページ
- その暗号化 ZIP ファイルの送付は「意味ないどころか有害」。セキュリティで信用失わないためには
- NIST SP800-45 Ver.2 Guidelines on Electronic Mail Security
- NIST SP800-63 Rev.3 Digital Identity Guidelines
- パスワード付き (暗号化) ZIP 廃止の考え方と対策 (古賀さんの書く迷惑メールレポートなどは ISP の中の人の見え方でのレポートになるためたいへんためになります)
Footnotes
-
大泰司 章. くたばれ PPAP! ~メールにファイルを添付する習慣を変えるところから始める働き方改革~. 第 52 回 ISP & クラウド事業者の集い in 旭川. 2019, available from <https://www.jaipa.or.jp/event/isp_mtg/asahikawa_190912-13/190913-3.pdf\>, (accessed 2020-11-15) ↩
-
ITmedia. 霞が関でパスワード付き zip ファイルを廃止へ 平井デジタル相. 2020, available from <https://www.itmedia.co.jp/news/articles/2011/17/news150.html\>, (accessed 2020-11-18) ↩ ↩2
-
ITmedia. パスワード付き zip、内閣府と内閣官房で 26 日から廃止へ 外部ストレージサービス活用 平井デジタル相. 2020, available from https://www.itmedia.co.jp/news/articles/2011/24/news097.html, (accessed 2020-11-24) ↩ ↩2 ↩3
-
ITmedia. 政府の「アイデアボックス」投稿を Twitter で共有 「パスワード ZIP 全廃」に危機感抱いた個人が開発. 2020, available from <https://www.itmedia.co.jp/news/spv/2011/18/news099.html\>, (accessed 2020-11-18) ↩
-
経済産業省. 情報セキュリティ管理基準 (平成 28 年改正版). 2014, available from <https://www.meti.go.jp/policy/netsecurity/downloadfiles/IS_Management_Standard_H28.pdf\>, (accessed 2020-11-18) ↩
-
一般財団法人日本情報経済社会推進協会 (JIPDEC) プライバシーマーク推進センター. プライバシーマーク付与適格性審査基準. 2018, available from <https://privacymark.jp/system/guideline/pdf/pm_shinsakijun.pdf\>, (accessed 2020-11-18) ↩
-
一般財団法人日本情報経済社会推進協会 (JIPDEC). メール添付のファイル送信について. 2020, available from <https://privacymark.jp/news/system/2020/1118.html\>, (accessed 2020-11-19) ↩
-
大元隆志. 2020. available from <https://news.yahoo.co.jp/profile/author/ohmototakashi/comments/posts/16061893010545.7669.07711/ >, (accessed 2020-11-25) ↩
-
Webroot. WEBROOT THREAD REPORT. 2020, available from <https://www-cdn.webroot.com/7015/8758/9578/2020_Webroot_Threat_Report_Japan.pdf\>, (accessed 2020-11-25) ↩
-
LostMyPass. Zip パスワードの復元, available from <https://www.lostmypass.com/ja/file-types/zip/\>, (accessed 2020-11-18) ↩
-
Cybersecurity & Infrastructure Security Agency. Alert (AA20-280A) Emotet Malware. 2020, available from <https://us-cert.cisa.gov/ncas/alerts/aa20-280a\>, (accessed 2020-11-18) ↩
-
楠 正憲. 2020, available from <https://twitter.com/masanork/status/1298040616740204544\>, (accessed 2020-11-15) ↩
-
文化庁. 無形文化財. available from <https://www.bunka.go.jp/seisaku/bunkazai/shokai/mukei/\>, (accessed 2020-11-14) ↩