見出し画像

座談会 「社会からPPAP をなくすには？」Part2　～PPAP に代わる安全な方式 その1～

情報処理学会・学会誌「情報処理」

小特集「さようなら，意味のない暗号化ZIP添付メール」より

崎村夏彦（NAT コンサルティング）
大泰司章（PPAP 総研）
楠　正憲（国際大学Glocom） 
上原哲太郎（立命館大学）

背景はこちらの記事をご参照ください．

Part1に続いて．

SMTPS の強制

崎村：さて，ではPPAP に代わる安全な方式の議論したいと思います．
上原：相手とのSMTP の経路がSSL 対応になっているのだったら，もうそのまま送ればと思っています．安全という意味では十分安全．いまは通信区間にセキュリティリスクはあまりない．むしろ末端がこわい．マルウェアやフィッシングでID を取られ，メールボックスの中を盗み見られていることのほうが問題．そっちを守ることにエネルギーを使うべき．経路のことはあまり気にしなくていいんじゃないか．崎村：何を守ろうとしているかという部分ですよね．経路の安全性と到達先での安全性と2 つある．あとPPAP な人たちがよく言っている誤送信防止．
上原：誤送信防止対策は別の方法でやるべき．G メールは送信ボタンを押してからしばらくは取り消せるよ
うになった．PPAP で送ってから気が付くと主張する人たちは，このことをどう思っているのかなと．確かに僕も気が付くことがあるのですね，あっ，しまった，送り損ねた，戻そうみたいなのはたまにある．でも逆に言うと，あれで十分じゃんと．それが1 つ目ですね．

事前鍵交換共通鍵暗号化ファイル添付

崎村：次に，事前鍵交換の共通鍵暗号化ファイル添付．本来のPPAP の在り方としては，あらかじめオフラインで共通鍵を交換しておいて，以後，その鍵でファイルを暗号化してメールに添付する．そうすると，鍵の長さが十分であれば，強度は十分となる．そもそもの誤送信対策で，元々やられていた本来の暗号化ZIP の使い方．相手との間で事前に共有した鍵があるから，それ以外のところに送っても大丈夫，だから誤送信対策としても機能する．
楠：それこそが本来の誤送信対策なのですよ．
上原：ただ，十分長くて複雑な鍵じゃないといけない．某役所の仕事はこの事前共有鍵方式．UX 的にはしんどい．
楠：プロジェクトとか，研究会の数だけ覚えるのはまず困難．
崎村：こういうのは1Password みたいなパスワード管理ソフトを使うしかない．
大泰司：またはモニタのまわりが付箋だらけになると．それでも分からなくなるから，前は部下に開けてもらっていました．
崎村：1Password は企業モードがあって，こういうシークレットキーを複数人でシェアできる．まさにそういうためのものではないかと．
楠：その問題を公開鍵暗号でクリアしてくれて僕らは幸せな時代を生きているはずなのに，なんでこんなにシェアードシークレットのハンドリングにこの21 世紀に苦労しているんでしたっけ．70 年代にシャミアさまとかが解いてくれた大事な問題なはずなのだけれども．

公開鍵暗号化ファイル添付

崎村：その流れだと，次に出てくるのが公開鍵暗号化ファイル添付，アリスとボブがそれぞれの公開鍵を一定の場所に公開しておいて，その公開鍵を使ってファイルを暗号化して．PGPとか．
上原：PGP の鍵を公開しておいてやりましょうというのは，たとえば，IPAの届け出がその方式ですよね．
楠：PGP を使えないと届け出ができないというのはなかなかすごいハードルが高い感じで．
崎村：UI（User Interface）や，Windows やMac に最初から入っていないなどの問題ですよね．逆に言えば，皆が持っていて，UIも良いという状態になれば使えるということではある．エストニアはID カード配布と同時に署名・暗号化のためのソフトを配っています．

公開鍵メッセージ暗号化（S/MIME）

上原：私はまだ細々とS/MIME で抵抗を試みています．私のメールはS/MIME署名されているのですけれども，このS/MIME 署名している鍵はどこにあるかというと，G さまが保管しておられます（笑）．
楠：G Suite ですか．
上原：そうです．G Suite の中でやっています．
崎村：私もやれるのですけれども，やって意味があるのかどうか（笑）．
楠：だいぶ哲学的な問いですよね．
上原：ええ．
崎村：多くのメーラーが，特に携帯など，S/MIME で暗号化されてきているメッセージは読めない．
上原：暗号化は読めないですね．
楠：添付ファイルが読めるか微妙な感じ．
崎村：本文が表示されなくなってしまったとか．
上原：smime.p7s だって「ウイルスみたいなファイルが付いているけれども，何ですか」というお問合せをいただく（笑）．あるいは，ゲートウェイで削除しましたというメッセージ付きで向こうに届くとか（笑）．
大泰司：サニタイズされてしまうのですよ．
上原：そうなのですよね．まあでもS/MIME はやればやるほど普及しない理由はよく分かってしまって（笑）．昔はファイル名に日本語が交じると正規化アルゴリズムの実装が微妙に異なっていて，検証が失敗するとか互換性問題があった．それはだいぶ解決したのですが，一方で鍵管理の問題が解決しない．私はS/MIME で届いたメールが暗号化されていたらIMAP（Internet Message Access Protocol）のInbox に復号した状態で保存してほしいと思うのです．暗号化したまま置いていると，その古いファイルを取り出すために自分の古い証明書をずっと持っておかないといけないから．でも，これがすごく難しい．そういううまいUI を提供してくれているメーラーがない．署名にしても，古い証明書をずっと履歴管理できるメーラーじゃないと昔のメールの署名確認に困る．なので，両方の意味で，S/MIME はちょっとつらいのは実情かなと．
楠：やはり鍵管理そのものが人類に早すぎたのではないかと．鍵管理というのはやはり難しい．
崎村：でも，だとすると，暗号というのはすべての問題を鍵管理の問題に置き換える話・技術だから，暗号化は無理筋という話になってくるわけですね．
楠：まあだからよろしくGAFA（Google Apple Facebook Amazon）に守ってもらおうという流れになってしまう．

上原：それで，その古いメールを取り出すたびに思うのですけれども，さっきの楠さんの話ではないですけれども，なんでS/MIME というのは1 年ごとに証明書を更新しなくてはいけないんだっけと思うわけですよ（笑）．
大泰司：今，3 年．今度2 年になったのかな．
上原：だんだん縮んでいっているので．
大泰司：特に暗号化に期限の短いものを使う必要は全然なくて，署名のほうはまあしょうがない．実際に使っているとS/MIME の暗号化はすごい楽ですよ．もう普段，意識していないぐらいに．
上原：ただ，S/MIME の暗号化で普段，意識しないとおっしゃるのはすごくよく分かるのですが，意識せずに使えるというのは実は逆にネックになっているような気もしていて，ちゃんと自分は暗号化して送れているのかとか，暗号化したものをちゃんと受け取ったのかというのをちゃんと確認する習慣を削いでいくような気がするのですよね．それはそれでいいのかみたいな気がして．

DNS を使ったID ベース暗号

上原：一応そこもですね，私，ささやかながら抵抗を試みていて．学生さんにつくってもらって情報処理学会の研究会で発表したのですが，DNS（Domain Name System）ベースの公開鍵暗号をつくっています．公開鍵というか，いわゆるID ベース暗号なのですが，ID ベース暗号の公開パラメータをドメインごとにDNS で公開する．そうするとそのDNS の管理がちゃんとしている限りにおいては，そのドメインで使っているID ベース暗号のパラメータはDNS で入手できるから，それを使ってお互いにやりとりができる．有効期限の議論は，危殆化したことをドメインのほうが認識するまではエクスパイアしないという（笑）．そういう運用ルールで考えていて，危殆化したらDNS の鍵を入れ替える，その代わり古い鍵はあるルールで残して公開を続けるみたいな，そんな仕組みで設計しているところなのです．
　メールのセキュリティというのは，S/MIME の普及が進まない間に別の方向に進化していて，PKI（Public Key Infrastructure）ではSMTPS，POPS，IMAPS などの転送レイヤだけうまく技術が普及している．それより上位レイヤは，DKIM（DomainKeysIdentified Mail）など，ひたすらDNS に頼っているわけです．
楠：SPFも含めて．
上原：SPF（Sender Policy Framework）， さらにDMARC（Domain-based Message Authentication, Reporting and Conformance）ができて，それで今度，トランスポート層がSSL に強制されていることをMTA-STS（Mail Transfer Agent Strict Transport Security）で公告するようになってと．全部DNS に頼っていて，それをみんな信用できているのだったら，DNS に残ったリスクというのは，みんな目をつむれるのかなと．今のPKI はDNS を信頼できないものとして扱いますけれども，DNS を信頼する公開鍵暗号系を標準化できないのかなというのは今ちょっと思ってて．
楠：結局PGP が流行らなかったのは公開鍵の交換のところで，これをキー・サーバをつくるのではなくディレクトリをと考えたとき，インターネットでグローバルにスケールしているディレクトリはDNS という話に間違いなくなりますからね．
上原：そうなのですよね．キー・サーバがまったくスケールしないことが分かっていながら進むうち，やはりみんな使わなくなった．
楠：本当はあれってブロックチェーンも解になりそうな気もしたのですが，トラストレスと言っているからなのか，あまりこっちの用途には広がらなかったですね．
上原：そうですね．
崎村：まだちょっとその辺は頑張ってみたいなとか思っているのですけれども，その変形としてこの間，僕は自分の公開鍵をTwitter でツイートしたのですけれども（笑）．
上原：せっかく暗号技術も進んできたのだから，運用もUXもそんなにおかしくならない全体をデザインしたスマートな仕組みにしないとS/MIME の置き換えになるようなメッセージングは出てこないような気がしていて．それが進むまではPPAP がなかなか打ち倒せるようなものにならない．でもPPAPというのはUX 的には最低なのにどうして死なないんだとは思っています（笑）．
崎村：いや，あれはコンプラで強制されるから．
楠：あのコンプラ村の人たちのUXへの関心の低さって何なんでしょうね？
崎村：ユーザブル・セキュリティとか，ヒューマン・セントリック・セキュリティとかと対局にいる感じ．しかし，PPAP を強制する人たちって，本質的にセキュリティが分かってないんでしょうね．分かってたらあんなことしないはずだから．日本のローテーション人事の特質で，専門家を当てないというところにも問題があるかもしれない．だから日本だけでPPAP がはやるみたいな．
上原：1 つ確実に言えることは，ルールを決めて守らせる人が，エンジニアリングにもUX にも仕事の効率を保つことにも興味がない．本来は，どうやって効率を上げるかを考えてもらわなければならないはずなのに．
崎村：科学的理由がないところでのドグマがあって，そのドグマによって強制される儀式を踏んでいれば，科学的に間違っていてもそれが正当化されてしまう．科学的に安全を求めるのではなく，儀式によって安心を求めているように思える．
楠：安全なものをくださいと言っても，完璧に安全なものなどない．それが認知的不協和を呼ぶ．セキュリティに金をかければかけるほど不安になる病．だから安心を求めにいく．

認証連携ファイルアクセス制御

崎村：認証連携ファイルアクセス制御は，アクセスを許す相手の属性（通常はメールアドレスなど）を指定して，当該ファイルへのアクセス制御を行う仕組みです．それでそのファイルへのリンクをメールやチャットなどで送る．これが海外で割とメインストリームになってきているのかなという気がします．
大泰司：今，PPAP の自動化ソリューションを使っている企業はこれを簡単に導入できるはず．オプション料金がかかるところと，そのまま標準についているところがありますけど．
楠：やはり私の原稿でも書きましたが，結局，添付ファイルをやめてリンクを送ればいいんじゃないかと．そうすれば，添付ファイルにアクセスするというか，送りたかったものにアクセスするタイミングでもう1 回，認証認可も走るし，あとから取り消すこともできる．今，Office 365 も，G Suite も，大体そんな実装になってきている．添付ファイルではなく，クラウドなりでファイル共有サービスとの連携に寄せていけば，ストレージも余計に食わないし，メリットはでかい．
崎村：これが結構，実はメインストリームに今なってきている感じがしますよね．

Part3に続く．

（「情報処理」2020年7月号掲載）

■崎村夏彦（正会員）　nat@nat.consulting
　本会SC 27/WG 5 主査．OpenID Foundation 理事長．ディジタル・アイデンティティとプライバシに関する国際標準化が専門．著した規格にOpenID Connect, JWS, JWT など．

■大泰司章　otaishi@gmail.com
　三菱電機，日本電子計算，JIPDEC を経て，PPAP 総研設立．電子契約，電子署名，メールやWeb のなりすまし対策を普及．PPAP やハンコ等の非効率な取引慣行を変えて，真の働き方改革を目指すIT コンサルとして活動中．

■楠　正憲（正会員）　masanork@gmail.com
　マイクロソフト，ヤフーなどを経て2017 年からJapan Digital Design CTO．内閣官房 政府CIO 補佐官としてマイナンバー制度を支える情報システム等の構築に従事．

■上原哲太郎（正会員）　t-uehara@fc.ritsumei.ac.jp
　和歌山大学，京都大学，総務省を経て2013 年より立命館大学情報理工学部教授．専門はサイバーセキュリティ，システム管理，ディジタル・フォレンジック．入力しにくいだけのExcel 帳票や無駄な押印の撲滅にも興味を持つ．

※本小特集記事（全体）を入手するには以下の方法がございます。ぜひご利用ください。
1）情報処理学会会員になり（http://www.ipsj.or.jp/nyukai.html）、電子図書館（https://ipsj.ixsq.nii.ac.jp/ej/）に登録する。
2）fujisanで購入する。
　- 特集別刷（https://www.fujisan.co.jp/product/1281702304/）
　-「情報処理」本体（https://www.fujisan.co.jp/product/1377/b/1986578/）
3）Kindleで購入する。（https://www.amazon.co.jp/dp/B089N3VX86/）