PPOP


公開 (UL): 2021-06-01
更新 (UD): 2021-06-01
閲覧 (DL): 2021-06-20

この記事のもくじ

→本文へ
当サイトは SNS の公式アカウントがないので,「議論ネタ」にする際は,皆さんのブログ,メーリングリスト,SNS や掲示板などで,適当にハッシュタグを付けたりリンクを掲載するなどしてご利用ください。

前の記事

2021-03-04
全角⇔半角の変換

次の記事

2021-06-01
Base54

最近の記事

2021-02-23
五十音の「辞書順」の処理
2020-12-22
年月日から曜日を求める数式
2020-05-04
UTF-8 文字(列)と UNICODE の変換
2020-06-07
存在不明のパス名からディレクトリを構築する
2020-05-04
エスケープ文字変換/復元
新着情報

新着情報 Recent docs.

Sorry, but almost these pages are only Japanese.
[TAB] キーの使い方 «What functions does [TAB] key have.»
様々な「切り替え機能」のほか,ワープロで同じ行に「左寄せと右寄せ」を混在させる方法など。
PPOP «Password encrypted file is sent and the Password is notified Otherway Protocol.»
一般的な暗号化ファイルのパスワードを安全に伝える方法。
「マイナンバー」が危険なこれだけの理由 «The reasons of "My-Number System" is danger.»
それでも「マイナンバー」を推す裏の理由を推察。
デジタル化なら「スタイル編集」すべき «Let's "Style-Editting" with word-processor application.»
ワープロで「書式設定」の代わりに「スタイル編集」することで使える様々な便利機能。

人気記事 Frequent view pages.

表計算で「令和」に対応する方法
How to adapt the Gengo era "Reiwa" on spreadsheet applicaiton.

古いアプリも OK。「表計算 令和」の検索結果上位御礼!
表計算ソフトで予定表を自動作成する超便利な方法 «How to make the schedule table automatically on spread-sheet.»
「毎月第○×曜日」的な法則は自動で作らせてラクしよう!
表計算ソフトに「個人情報保護機能」を仕込む方法 «Prevention to leak private-data with spread-​sheet macro function.»
「漏えい」のためのフェイルセーフ。「表計算 個人情報」の検索結果上位御礼!
Wary-Basher (ワリバッシャー)
DIY device that enables the handicapped to operate many things with a switch like push-button.

障害者の様々な操作をスイッチ操作で実現する器具。キットも発売中! 「作り方」PDF ダウンロード多数御礼!←地方教育委で人気。
NTT 東日本代理店の勧誘のあり方に対する疑問 «I feeled pretty doubt the solicitation of "Optical-fiber communication" from the agency of NTT-east corporation.»
「あえて」分かりにくい説明をする業者に儲けさせてはいないか?
貧乏人を殺す行政の構造 «Structurally, the administrators kill the poors in Japan.»
ヘタすると多摩川に流されるところだった台風 19 号

この記事に対する → 調布市の反応

おすすめ! Recommend

「事故防シート」について «Cared persons taking with "Jiko-​Bow-​Sheet" prevents from accidents.»
介護現場の負担軽減と事故防止のアイデア
【連載】 キーボードの「キー」の詳しい使い方 «The detial of usage each key on keybord.»
各キーの機能詳細。機能別五十音順一覧。
和易ゐ記 (WAI-WIKI) «WAI-WIKI is light­weight markup language for Japanese, and generates HTML on this server on-​demand.»
当サイトで開発/使用中の日本語向けに特化した軽量マークアップ言語

ご連絡 For contact safely.

当サイト管理者(石川)への連絡内容の機密保持には,こちらで取得できるパスワードをご利用ください。 Get password for file(s) encryption to send the admini­strator of this site M.Ishikawa.

ご支援 Support this site.

この活動をご支援いただける方はこちらへ Could you support this site, see here (but Japanese).

 PPOP とは,以下の略。

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

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

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

● 従来方式の限界

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

 略して 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 の対応アプリなどを使える環境を整えておく必要があり,その設定も必要。しかも,相手に見せたいファイルを暗号化する際は,暗号化の「鍵」に当たるものは「相手が」作ったものを手元に置いておく必要がある。両方がそれぞれ自分宛のデータ暗号化のための「鍵」を作り,相互に知れる状態でないといけない。しかもその「鍵」というのも,1つあたり数百バイトほどの大きさがあり,機密データをやりとりする相手が多くなると,管理もたいへんになってくるだろう。

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

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

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

▼ PPAP のリスク
PPAP のリスク

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

● PPOP の考え方

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

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

▼ PPOP の考え方
PPOP の考え方

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

● 使い方

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

▼ PPOP(取得ページ)
https://treeware.jp-help.net/ppop

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

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

◆ 文字数オーバーの場合

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

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

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

● 当サイトの PPOP

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

◆ セキュリティ

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

▼ Base54
http://treeware.jp-help.net/?ssss10

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

◆ プライバシー

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

● 短所

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

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

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

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

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

▼ 必要な「鍵(パスワード)」の総数
必要な「鍵(パスワード)」の総数

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

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

● 詳細

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

「詳細を知りたい」というご希望が多数寄せられるようであれば,ここに追記して行きたいと思います。

● おわりに

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

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


© M.Ishikawa; TREEWARE 2021.