PPOP とは，以下の略。

• Password（パスワード）付きのファイルをメールなどで送る時
• Password そのものは
• Otherway（他の）符号と方法でやりとりする
• Protocol（プロトコル＝手順）

　無理やり英訳するなら，Password encrypted file is sent and the Password is notified by the Otherway Protocol といったところか。なお，当サイトの管理者である筆者が勝手に考えた方式で，この記事の公開時点では一般に通用する用語ではないので注意。

　特徴としては，以下のような感じ。

• ファイルを対称鍵暗号化（開けなく）するために使うパスワードと番号の対を生成し，番号だけ通知に使うことで盗み見を防ぐ。「対」はアクセスごとに異なり，第三者が知ることはできない。
• 従来の PPAP（本文参照）と同様な使い方ができ，S/MIME や PGP（GPG）のような対応アプリや複雑な設定／登録など一切不要。
• メール添付の場合，パスワード保護ファイルと番号を一緒に送ってもセキュリティ上問題なく，送信が一回で済み手間が省ける。
• 【用途】リモートワークでの機密保持，内外からの告発など受付時の匿名性の確保，外部からの「応募作品」の模倣防止など。
• 任意パスワードを使いたい時に，それを伝えるための事前手段としても使える。

　ここでは，そんなデータセキュリティ方式 PPOP を考えてみたい。

　これまでよくやりがちだった PPAP とは，以下のような方式。

• Password（パスワード）付きのファイルをメールでまず送り
• Password そのものを
• Atokara（あとから）メールで送る
• Protocol（プロトコル＝手順）

　略して PPAP と言うんだそーだ。言うならば Password locked file send by mail, and the Password send After that Protocol 的な感じだろうか。「パスワード付きファイル」としては，よく ZIP が使われるとか。ある企業で「PPAP 禁止！」とお達しが出たというニュースを見て，一部のネット民は「そりゃ，みんなで豹柄の服着てペンやリンゴ持って踊っている場合じゃなかろう」などと解釈されていたようだが，そうではない。そもそもセキュリティ上，ほとんど意味の無いやり方のためだ。暗号化したファイルとそのパスワードの両方が同じメールサーバやソフトで扱われるのだから，漏れる時は両方が同時に漏れる可能性が高く，漏れた先で簡単に開いて読めてしまうことになるからだ。

　ではメールなどで使う機密保護の方法として何があるのかというと，S/MIME とか GPG と呼ばれるものが一般的らしい。が，どちらも一筋縄ではない。まず S/MIME のほうは，「認証局」と呼ばれる業者に登録料を支払って「証明」してもらう必要があり，それもそれなりの「投資」になるらしい。その点，GPG は無料という点では気軽に使えるが，どちらにしてもその手の方法は，セキュリティは堅固であるものの取扱いが複雑。調べた筆者が未だに本格的に手をつけあぐねるレベル。古くからあるワリにあまり使われない原因は，その辺りではないだろうか。

　原理的には，前述した PPAP のような一般的な方法……たとえば ZIP や PDF などのファイルを「パスワード」で保護してメールする場合，暗号化の時も開いて見る時も同じパスワードのデータを使うが，これは「対称鍵」と呼ばれる。だから，メールで送るデータを暗号化したら，「パスワードはこれを使ってください」と知らせれば済むという取扱い易さはあるが，同じメールの宛先に送ると，「盗み見」された時に両方が漏れてしまうため，セキュリティ的にはあまり意味がない。

　一方，メールでこのリスクを避けるように考えられた S/MIME や GPG などの方法は「非対称鍵」と呼ばれるもので，「暗号化」に使う「鍵」となるデータと，それを開く時「復号（元の読めるデータに戻す）」に使うデータが別々になっている。この一対の鍵ペアのうち，暗号化鍵は公開しておき，受信者以外の人に読まれたくないデータを送りたい人が誰でも暗号化できるようにしておく。復号鍵側は公開しないので，その暗号を復号して読めるのは受信者だけ……といった仕組み。
　「初めてメールする相手」はどうするのか？ そうした時のために，「暗号化鍵」に当たるデータ公開用のサーバがある。もしそのサーバで相手の名前で検索などして「鍵」が見つかれば，それを使って暗号化することで，初めて出す相手でも本人しか読めないようにすることができる。逆に言えば，サーバに見つからなければ，少なくとも初回は暗号化していないメールを送り，その「鍵」データを知らせてもらう……などの手間がかかることになる。一方，サーバで見つけた「鍵」データも，相手のメールアドレスが確実に分かっていればいいものの，そうでない場合，同姓同名の別人のものである可能性も否定できない。最悪，別人が「なりすまし」て偽の「鍵データ」を先にサーバ登録してしまっている可能性もある。別人の「鍵」の使用を防止するため「ハッシュ値」と呼ばれるものを公開している人も居るが，それは「確実にその人が管理していると分かるサイト」などで確認できない限り，「誰でも」確実な暗号化データを作れるというわけではないことになる。
　もちろん「返信」を望むなら，自分も暗号化のための「鍵」を作り，何らかの方法……たとえば同じようにサーバに公開するなどして，相手に知られるようにしておく必要がある。
　つまり，従来のメールの機密保持の方法は，送受信と受信者双方が，その S/MIME や GPG の対応アプリなどを使える環境を整えておく必要があり，その設定も必要。しかも，相手に見せたいファイルを暗号化する際は，暗号化の「鍵」に当たるものは「相手が」作ったものを手元に置いておく必要がある。両方がそれぞれ自分宛のデータ暗号化のための「鍵」を作り，相互に知れる状態でないといけない。しかもその「鍵」というのも，１つあたり数百バイトほどの大きさがあり，機密データをやりとりする相手が多くなると，管理もたいへんになってくるだろう。

　いずれにせよ，メールで使う本格的なデータ暗号化方式は，送受信者双方がそれらを使える環境……つまり「暗号化」と「復号化」ができるソフトを備え，暗号化鍵データを公開していて，確実に当人が管理するサイトでハッシュ値などを確認可能……などの条件が揃っている必要があり，あまり「気軽に」使えるシロモノではないわけだ。
　結局，ファイルの暗号化と復号に同じパスワードを使う方法のほうが分かり易く，扱い易い面も多々ある……ということになる。とはいえ，最初に述べた PPAP のような従来のやり方だと，ファイルとパスワードが同じメールアカウントに送られてくるのだから，盗み見られれば一緒に漏れる可能性が高く，セキュリティとしての意味はほとんどない。

◆ メール暗号化が必要な理由

　とはいえ，当初はなぜメールに暗号化が必要なのか少々疑問も感じていた。というのも，だいたいメールというのは自分のアカウントに届いたものを読む時は，受信サーバで「認証」が必要……つまり，読もうとしている人がアカウントの持ち主本人であることを確認するのだから，原則として本人以外が読むことなどないはずだからだ。メールソフトを設定する時に「パスワード」が必要なのはそのためで，メールソフトが本人に代わって「認証」する仕組みになっているのだ。
　しかし，事情は違って来ている。特に Gmail や Yahoo! メールなどでは，サービスを提供する Google や Yahoo! 社などが，メール内容に関連する広告を利用者に向けて発信できるようにするために，サーバにあるメールをコンピュータが読み取り，登録されている広告に関係するキーワードが書かれていないか「探り」を入れて来る仕組みになっているらしい。つまり，読むのはコンピュータとはいえ「本人以外が読んでいる状態」だということだ。省官庁などお役所サービスでメールの利用が進まないのは，こうした点への懸念もあるのではないかと思われる。
　しかも，Gmail や Yahoo! メールのアカウント所有者だけではなく，そこで受信した他者のメールも対象とされる可能性が高い。するとたとえば，たまたま迷惑メールで「エロい」ものがドカドカ入ってきちゃったりすると……「エロい」広告がバカスカ表示されてしまったりことも起こりうるのではないか。迷惑千万！ 子供には使わせられんわな。
　とはいえ，コンピュータが自動でパスワード保護された添付ファイルの中身まで読む可能性は低いから，そういう意味では，PPAP のような方式でも，「とりあえず」の保護にはなるのかもしれない。が，そこまで「絶対にやらない」という保証もされていない。あるいは，外部から調べようがないのをいいことに，既に「こっそり」そうしている可能性も否定できない。

▼ PPAP のリスク

　だが，「通信の秘密」は憲法で保証されているはず。だから，これはある意味「違憲状態」が黙認されているようなものではないかと思う。しかし，どーせ目先の「儲け」しか考えていない Google や Yahoo! 社がヤめるとは思えない。ではどうするか……「自衛」する手段は，といえば，それはもうパスワードをメール以外の方法で伝えるしかないのではないかと思う。
　ここでは，これら従来方式に代わる，手軽な方法を考えてみたい。

　要するに，ZIP や PDF など「対称鍵」で暗号化したファイルのパスワードを同じアドレスにメールすると，「同じサーバ」や「同じ管理ソフト」で扱われ「一緒に流出」するリスクが高まるのが問題なわけだ。ならば，せめてパスワードを別の方法で受け渡しできればマシだろう。
　とはいえ，電話や FAX，郵送などでは手間がかかる。できればメール同様「ネットで」完結できたほうがラク。しかも「誰でも使える方法」……と考えると，思い当たるのはウェブページくらいだ。だが，ウェブページというのは「誰でも同じ内容を見れる」のが特徴。GPG のように暗号化と復号する鍵が別々なら，暗号化鍵だけでは「復号できない」から，「同じ鍵データ」を誰でも読めるよう公開しても差し支えないが，ZIP のような「対称鍵」……つまり，暗号化鍵と復号鍵が同一の場合，パスワードを公開すると復号もできてしまうから，そうもいかない。

　ただ，CGI というものを使うと違ってくる。CGI というのはサーバ上で動作するプログラムのことで，アクセスごとに異なるデータを作って送る……といったことも可能になる。昔の記事にはよく「アクセスカウンタ」と呼ばれる数字の画像が掲載されていたが，それも CGI の一種だ。それは「アクセスされる度に１ずつ大きな数の画像を作って送る」もの。マサにアクセスの度に異なるデータを送ってくる仕組みだったわけだ。すると，CGI を使えば，「誰でも同じ内容を見る」ためのものではないウェブページも作ることが可能になる。

▼ PPOP の考え方

　というわけで，ここでは CGI をうまく使い，「A＝あとでメール」で送るのではなく，「O＝Otherway 他の方法で」対称鍵をやりとりすることで，簡単で安全に暗号化してやりとりできる方法を考えてみたい。

　ここでご案内するツールでは，当サイトの管理者（石川）へ送りたいメッセージやデータを他者が見れないよう保護したい時，ZIP や PDF，ワープロなどのファイルでパスワードとして使う文字の並びを生成します。他からのアクセスで同じ番号とパスワードは表示しないため，他者がそのパスワードを知ることはできない仕組みです。
　たとえばそのデータを監理者にメールでお送りいただくような場合，パスワードと共に表示される「PPOP 番号」だけ本文などに記載していただければ，パスワードは伝えなくても番号から分かるためファイルを開くことができます。パスワードそのものを記載していなければ，そのメールがなんらかの原因で外部に知られても，ファイルの内容まで知られることを防止できます。
　以下のページより，番号とパスワードの対を取得できます。

　記事内のボタンを押した後に表示される「パスワード（Password）」の文字の並びをパスワードとして使って，ZIP や PDF などのファイルを保護してください。管理者には，一緒に表示される「PPOP 番号」だけを伝えます。ファイルをメール添付で送る場合は，同じメールに番号を記載しても構いません。
　得られたパスワードは，引き続き使用する可能性があります。少なくとも，当サイト管理者側からの返信などでパスワード保護する時は同じものを使いますので，保存／スクショ／印刷するなどで保管して，パスワードの側をメールに記載したり，他人に知れる状態に置かないようご注意ください。なお，メールサーバやソフトから漏えいする可能性がゼロではないので，自分宛メールで保存するのは避けたほうが無難です。

　ただ，当サイトで採用している SSL に未対応なブラウザでは表示できないことがあります。未対応ブラウザのご報告が多数あれば，回避策を検討いたしますので，管理者までご一報ください。

◆ 文字数オーバーの場合

　安全性を考えて 20 文字とちょっとのパスワードが生成されますが，使用するアプリの制限によってそれより少ない文字数しか使えない場合は，先頭から使える文字数分だけをパスワードとして，その旨メールなどに記載して伝えてください。

◆ 特定のパスワードを使いたい場合

　「部署内（あるいは『企画上』など）で統一して使っているパスワードがあるから，それに合わせたい」といった事情がある場合，その旨を共通パスワードと共に記載したファイルを作り，上記 PPOP のパスワードで保護して，メール本文のほうに PPOP 番号を記載して添付で送っていただければ，それ以降こちらから送信するファイルには，その「共通パスワード」を使うことができます。送信の際に，同時にその共通パスワードで保護したファイルを添付することも可能です。ただ，どちらも「パスワードそのもの」はメール本文などに記載しないようにします。

　ここでは，当サイトで開発して使っている PPOP システムについて，少し詳しく述べてみる。

◆ セキュリティ

　パスワードそのもののデータはサーバに保存していません。そのため「データファイルが流出してパスワードが漏れる」こともありません。パスワードは「ハッシュ」という方法で番号を元に作られていて，その「作る」部分は HTTP ではアクセスできない場所に置かれています。
　とりあえず，生成される「パスワード」は，数字と，アルファベットから（大／小文字を含め）数字と紛らわしい I（アイ），L（エル），O （オー），S（エス）を除いた 54 文字を使用し，「見間違い」による誤入力防止も図っています（「コピペ」が確実ですが）。ハッシュなど任意のバイト列を文字列にする方法として Base64 がありますが，記号類（+，/，= など）も使わないため，アプリによるパスワードで使える文字の制限を受けることもありません。Base64 より少ない 54 文字を使うため，筆者は「Base54」と呼んでいます。詳しくは，以下を参照。

　POPP 番号は，cookie を利用してブラウザに保存していますが，パスワードのほうは保存されないため，cookie を見ただけでは分からない仕組みです。
　通常ブラウザでは，他者が勝手に他人の PPOP 番号を自分のブラウザに設定することはできませんが，まれに可能な場合があります。ただ，「パスワード」を全て再表示するためには，パスワードの一部（４文字以上）を覚えていて入力する必要があるため，cookie を設定しただけでパスワードが知られてしまうことはありません。入力を何度か間違えると該当番号の再表示機能は凍結され，以降の入力は受け付けないことで，「総当たり攻撃」を防止しています。

◆ プライバシー

　個人情報登録のため入力を求める内容もありません。ただし，番号とパスワードの対を取得した IP アドレスは記録されます。これは，無闇に取得を繰り返して機能の妨害を狙う攻撃を防止するためです。特定の IP から頻繁に「取得」があると，その IP から新規の「取得」を当面凍結します。

　PPOP は，「堅固さ」では，従来のメールで使われる S/MIME や GPG （PGP）などには適わないものの，PPAP とほぼ同じ取り扱いの容易さでセキュリティを強化できる点は最大の「長所」と言えるんじゃないかと思う。では，セキュリティ強度以外の短所は何が考えられるだろうか。現段階で思いつくのは，以下の二点。次節以降で個々に考察してみる。

• 提供には「サーバ」が必要
• パスワードが多く必要

◆ 提供には「サーバ」が必要

　PPOP では，パスワードそのものはメールなどで伝えず，ウェブサーバを経由させるわけだから，当然ながらサーバの設定が必要になる。つまりこれは，サーバ設定のできる人でないと「受け取り手になれない」ことを意味する。
　ただ，「サーバが必要」という点は，考えようによっては S/MIME や GPG などもそうではある。長く使われてきた方法であるだけに「専用のサーバ」が用意されているため，「専用サーバ」がまだない PPOP ほど困難ではないが，専用のツールで，時として「公開鍵（暗号化鍵）」を公開用の専用サーバにアップロードする必要はある。

◆ パスワードの数が多くなる

　S/MIME や GPG などの「非対称暗号化」では，「暗号化鍵」と「復号化鍵」を使う。すると全体としては，やりとりする人がそれぞれ２つずつ「鍵」を持つことになり，人数×２だけの「鍵」データが要る。
　ではこの PPOP では？ 人数によってはかなりの数になる。「暗号化鍵」と「復号鍵」が同一の「対称鍵」だから，自分も相手も同じ「パスワード」を使うため，２人の間で使うなら「１つ」で済む。が，「やりとりする人ごとに別々のパスワードが必要になる」ため，人数が増えると二次曲線的に増える。たとえば，Ｎ人が PPOP でやりとりする場合，Ｎ×（Ｎ－１）÷2 だけのパスワードが必要になる。これは，５人までは GPG など従来方式以下の数で済むが，６人以上になるとグンと増えることになる。

▼ 必要な「鍵（パスワード）」の総数

　上記の表を見ると，９人の間でやりとりするのに必要になる「鍵データ」はちょうど倍で，以降は人数が増えるごとに増え方も大きくなる。
　ただ，「１人が管理すべき鍵の数」を考えると，相手の人数分だけで済むため，考えようによっては GPG などの既存の方法とそんなに変わらない。というのは，９人で互いにやりとりする場合，自分以外の８人の相手分だけパスワードを手元に置いておけばいいだけだからだ。
　なぜ数が増えるかというと，GPG などでは，特定の人に送信するデータには全て同じ「暗号化鍵」を使える。９人の間でやりとりする場合，ある人に送信するための「暗号化鍵」は，他の８人が同じものを持っている。それを「１つ」として数えるから「数」としては少なく見えるだけの話だ。「復号」は「復号鍵」を持つ受取人本人しかできない仕組みだから，「暗号化鍵」が同一でもいいわけだが，結局同じ「暗号化鍵」を，（８人の）送信者が別々に手元に置いて管理することになる。これを「８つ」と数えると，PPOP と変わらなくなる。
　 PPOP でも，相手が８人なら８つのパスワードを手元で管理するという点は同じだから，管理手間的には大きく変わらないとも考えられる。GPG では，特定の人宛に使う「暗号化鍵」は同一だが，PPOP では全て異なるため，パスワードの「総数」を見ると多くなるわけだ。POPP は自分用の「復号鍵」の管理が不要な分，取扱いは容易かもしれない。

　しかも，述べた例は，データをやりとりする２人の間で，全て別々の「鍵（パスワード）」を使うことを前提としているが，たとえば特定の「企画（プロジェクト）」に関わる複数人数で，統一したパスワードを使うような場合，多人数間でもパスワードは「１つ」で済む。この場合 PPOP なら，元々が対称鍵のため直ぐそれができるが，GPG などでは，それ用の「対称鍵」を別に作る必要が生じるだろう。

　アクセスの度に異なる「文字の並び」を作って表示するだけなら簡単だが，それを「パスワード」としてファイルの暗号化に使う場合，ファイルを受け取った側でその「パスワード」が分からないと意味がない。完全なデタラメでは分かりっこない。番号と「パスワード」との間に，何らかの「結びつけ」が必要になる。どのように結びつけるか……その辺りも含めて考えてみたい。

　この方法（PPOP）は，今のところサーバに直接設定する方法のみなので，PPOP を組織的に導入したい場合は，当サイト管理者（石川）までご相談ください。

▼ このサイト監理者の連絡先