DEIM Forum 2016 F5-5

暗号化・署名機能の実装による RMX のセキュリティ向上
小坂 祐介†

遠山 元道 ††† 慶應義塾大学理工学部情報工学科 〒 223–8522 横浜市港北区日吉 3–14–1
E-mail: †kosaka@db.ics.keio.ac.jp, ††toyama@ics.keio.ac.jp
あらましRMX(Rule-based e-Mail eXchange system) とはあらかじめ設定されたルールに基づき, 自動的にメールを転送するメール転送エージェントである. 電子メールは改竄, なりすまし, そして盗聴といった問題を抱えている. 一
般的なメールでは暗号化や署名など, それらの問題への解決策が存在するが, 現状 RMX においてはそれらの問題への解決策がない. そこで, 著者らは RMX にメジャーなメーリングリストのうち, 暗号化・署名機能を持っている fml を参考にし, RMX に暗号化・署名機能の追加をした. ただし, 今回提案している RMX における 暗号化・署名機能は,RMX への拡張プラグインと しての提案であり, 本来 RMX の概念として存在しないユーザー登録 (ユーザーの鍵情報の登録) を前提とする.
キーワード

電子メール, RMX

1. は じ め に
RMX (Rule-based e-Mail eXchange System) とは管理者が< RM X のメール配信先指定 (関数形式) >:=< 配送ルール名 > {< パラメータ >}@ < サブドメイン > . < ドメイン>

あらかじめ設定したルールに基づき, 自動的にメールを転送するメール転送エージェントである [1] [2]. この RMX において,RMX はこのように, 配送範囲を記述するサブドメイン以前

先行研究ではスパムメールや誤送信の防止の為に送信者許可機の部分と, ドメイン移行が “.” によって組み合わされている. 配構を設けるなどして, セキュリティの対策が施されてきた [3].

送範囲の中でも＠以後のサブドメインの部分は後述する設定

しかし, この機構だけでは改竄やなりすまし, そして盗聴といっファイルの名前に相当する. また＠以前の部分は, “{}” の左側た電子メールに潜むセキュリティ上の問題へは対処しきれない.に示される配送ルールと, その “{}” 中に記述されるパラメータ

しかし, RMX 以外のメーリングリストにおいて, これらの問題という 2 つの部分に区別される. その内, パラメータは 1 つ以に暗号化・署名という方法で対処しているものは少なからず存上で構成される. サブドメインによって設定ファイル (後述) が在している [5].

選択され, 配送ルールの記述によって設定ファイル内のルール

メーリングリストにおいて, 暗号化・署名が必要になる場面部分が参照される. その後パラメータを用いてデータベースにの例として, 銀行が顧客に個人情報を送るようなケースが考え問い合わせを行い送信先のアドレスを取得する. 最終的に得らられる. これを送りたいのが, 特定の条件を満たしたユーザーれたメールアドレスに基づき, 配送が行われる. (図 1)のみで, それがデータベースで判定できるもの (例えば, 最終ログインの日時など) であれば, RMX を使うと簡単にメールを送ることができる. 一方, このメールは個人情報を含むので, なるべく暗号化・署名をしたいが, 今の RMX ではこれが出来ない.
よって, これに対処する手段の必要性を強く感じた.
以下, 本論文の構成を示す. まず 2 章で RMX について述べ,3 章で一般的なメールの暗号化・署名について述べる. 4 章では, RMX における暗号化・署名を実現する為の機構について述べ, 5 章でその具体的な使用方法を示し, 6 章で評価について述べ, 最後に 7 章で結論を示す.

2. RMX
Rule-based e-Mail eXchange(RMX) は遠山研究室が提案している電子メールの配信方式である. RMX ではメールアドレ

図 1 RMX におけるメール配信の流れ

以下, RMX の配送ルール (2.1), 複数の配送ルールの組み合
わせ (2.2), サブドメイン設定ファイル (2.3), (2.4) 拡張プラグイン機構について概説する.

スを下記のように記述することによって, 複数の送信先を指定する. RMX ではアドレスの記述方法は関数形式と自然形式の

2. 1 配送ルール

2 種類があり, これはそのうち関数形式の記述方式である.

配送ルールとは, 配送範囲記述と, それに基づき送信先のメールアドレスを取得するクエリを関連付けるルールである. 配送ルールは 以下のように定義する.

よって上記の例では, 学科が ics で研究室が遠山である学生に向けて, メールを配送することになる.

配送ルール名Type:パラメータの型
query: 送信先メールアドレスを得るためのクエリ
query は SQL によって記述する. 配送ルール名に対応するク
エリにパラメータを挿入し, データベース問い合わせを行うことで送信先メールアドレスの集合を取得する. このような配送ルールを用いることで, ユーザは簡潔な記述で配送範囲を記述することができる. 以下に配送ルールの定義の例を示す.

2. 2. 2 和 集 合Syntax: < name1 > {< par1 >} +... + < namen >{< parn >}@ < subdomain > . < domain >Semantics: name1 (par1 ) ∪ ... ∪ namen (parn )“+” は，論理和によって複数の配送ルール及びパラメータを指定する際に用いられる. 各パラメータをそれぞれの配送ルー
ルのクエリに代入し, 得られた結果の和集合から配送を行う. 論

dept

理和は, 同じ配送ルールでも異なる配送ルールでも使用が可能

deptType= Stringである.

dept[1]= select s.email from student s where s.dept= ‘$1’ ;上記の例では所属学科ごとにメールを送信することがで
き る, dept ル ー ル で あ る.

所 属 学 科 を String 型 で 受 け 取り, それに基づいて, メールの送信を行う. メールの宛先がdept{ics}@demo.krmx.jp の場合, 図 2 のように query の部分
で利用者のメールアドレスと所属学科が格納されているテーブ
ル student を参照し, そこから, 学科が ics の学生のメールアドレスを取得するクエリを記述している.

例：dept{ics}+grade{1}@demo.krmx.jp
よって上記の例では, 学科が ics である学生または学年が 1 年である学生に向けて, メールを配送することになる.
また, 配送ルール間の積集合をとる “.” と和集合をとる “+”が同時に使用された場合, 積集合をとる “.” の方が優先順位が高いものとする.
例：name{aoyama}+grade{4}.dept{ics}@demo.krmx.jp
例えばこの様なメールアドレスの場合, grade と dept の積集合をとった後, その結果と name との和集合をとる. つまりこの例の場合は, 学年が４年の情報工学科 (ics) に所属する学生,または青山という名前の学生にメールを送信するという結果になる.

2. 2. 3 多相 (ポリモルフィック)
図 2 dept ルールと配送例

2. 2 複数の配送ルールの組み合わせ (関数形式)

Syntax: < name1 > {< par1 > −...− < parn >}@ <subdomain > . < domain >Semantics: name1 (par1 , ..., parn )RMX では, 複数の配送ルールを組み合わせることが可能で“-” は，ポリモルフィックな考え方を導入して, １つのルールある. 複数の配送ルールを組み合わせてメールを送る際, RMXに対して複数のパラメータを指定するための演算子である. “-”で使用可能な演算子について説明する. To フィールドの配送によって与えられたパラメータの数により配送ルールから呼びルールに, 演算子を使用することによって, ユーザに対してより出すクエリが異なる．次の例ではルール grade に２つのパラ詳細な配送範囲の指定を可能にする.

メータ 1 と 3 を与えるため，2 引数の grade ルールを使用する．

2. 2. 1 積 集 合Syntax: < name1 > {< par1 >}. ... . < namen > {<parn >}@ < subdomain > . < domain >Semantics: name1 (par1 ) ∩ ... ∩ namen (parn )“.’ は，論理積によって複数の配送ルール及びパラメータを指例：grade{1-3}@demo.krmx.jp
これによって 2 つの引数をもつクエリが実行される. 引数が2 つの grade ルールがgrade
gradeType= integer

定する際に用いられる. 各パラメータをそれぞれの配送ルール

grade[2]= select s.email from student s whereのクエリに代入し, 得られた結果の積集合から配送を行う.

s.grade >= $1 AND s.grade <= $2;

例：dept{ics}.lab{toyama}@demo.krmx.jpとなっていた場合, 先ほどのメールアドレスから学年が 1 年から 3 年の学生にメールが送信される. 以上の３つの演算子は組み合わせて使用することもでき，ユーザが配送範囲を指定する

際の手助けを行う.
メールアドレスは以下の形式を取る．

インのみを記述する。

3. 公開鍵暗号と暗号化・署名
公開鍵暗号とは, 対になる 2 つの鍵を使って, データの暗号

ListOpe := −化・復号化を行う方式で, 電子メールの世界においてはこれら

U nionOpe := +の技術を用いて, 暗号化や署名といった機能が広く利用されて

RuleOpe := . | + | −いる (実際にはハイブリッド暗号と呼ばれるものが利用されてArg := string | integer

いるが, 利用者は公開鍵暗号を利用しているのと変わらない感

P ara := Arg | Arg ListOpe P ara

覚で, これを利用できるので, 広義の意味でこれも公開鍵暗号とP araList := P ara | P ara U nionOpe P araList

呼ばれることがある. また実際にこの後に説明するのはハイブ

Exp := rule { P araList }リッド暗号でなく, 公開鍵暗号の仕組みである). 対になる鍵のExpList := Exp | Exp RuleOpe ExpList

うち, 1 つは公開鍵, 他方は秘密鍵と呼ばれる. 秘密鍵は, 鍵ペ

Address := ExpList @ subdomain . domain

アの作成者が厳重に保管しておくもので, 公開鍵は誰にでも公

例：grade{1-3}.dept{ics}+grade{3-4}.

dept{sd}@demo.krmx.jp

開して良い鍵である. 以下では, 暗号化と署名の仕組みについて述べる.
まずメールにおける暗号化は, 送信者が自分の送りたいメッ

よって上記の例では, 学科が ics の 1,2,3 年生または学科が sd

セージを送信相手の公開鍵を使い, 送信相手しか内容が読めなの 3,4 年生に向けて, メールを配送することになる.

いようにメッセージを暗号化し, 受信者はそれを読む際に自分の秘密鍵で復号化し, 内容を知ることができるといった仕組み

2. 3 サブドメイン設定ファイルである. 一方, メールにおける署名は暗号化より少し複雑であサブドメイン設定ファイルでは, データベースへの接続, 使る. まずメッセージに対してハッシュ関数を利用して, メッセー用するルールの設定を管理する. ファイル名をサブドメイン

ジダイジェスト (ハッシュ値) を生成し, それを送信者の持つ秘名.properties とし, .properties の前をサブドメイン名として密鍵を使って暗号化し, メッセージと共に送る. そして, 受信者使用する. 例えば, rmx.properties というファイルを作成し,はメッセージから同じようにメッセージダイジェストを得る.

サブドメインが rmx となるメールアドレスを受信した場合,暗号化されて送られてきたメッセージダイジェストを復号化出

rmx.properties を参照し, 配送ルールを取得する. サブドメイ

来るのは送信者の公開鍵だけであるので, それによって復号さン設定ファイルでは以下の項目においてデータベース情報を設れたメッセージダイジェストが自分の側で作ったメッセージダ定する．

イジェストと一致していれば, そのメッセージが改竄されていない事が確認できる. これがメールにおける署名の仕組みであ•dbDriver = ＜データベースドライバ＞

る. よって, 暗号化機能を利用するには, 送信者は送信相手の公•dbUrl = ＜接続するデータベースの URL ＞

開鍵を持っている必要があり, 署名機能を利用するには, 送信者•

dbId = ＜データベース上のユーザ ID ＞

は送信相手に予め自分の公開鍵を渡している必要がある.

•dbPassword = ＜ユーザ ID に対応するパスワード＞

また本実装では, 暗号ソフトウェアとして, PGP を用いている [6] [7]. PGP の他にメジャーなものとして, S/MIME といっ使用するルールの設定もサブドメイン設定ファイルで行う．

た手段もあるが, 認証局という第三者的存在を必要とせず, 認証局のシステムの維持, 管理ということが必要ないので, 導入が容2. 4 拡張プラグイン機構

易であることから PGP を選択した. 以下で PGP と S/MIME

先行研究における RMX では, メール配送以外にも様々な機のそれぞれの特徴についてまとめる.

能を利用することが可能だった. 拡張プラグイン機構は, これらの機能を RMX 本体のメール配送機能から切り離して, 新たPGPに本体に機能を拡張プラグインとして, 第三者が自由に追加出•来るようにする機構である [4]. 拡張プラグイン機能を使用する
際には, 以下のような形式のアドレスを使用する.

#<plugin>.<command>.<arg1 >.….<argn >#<target><plugin> で は, 使 用 す る プ ラ グ イ ン の プ ラ グ イ ン 名,<command> では, 使用するコマンドを記述する. <arg>
は, 各コマンドで使用される引数を表している. 引数の数はコマンドによって異なり, 引数を 1 つも使用しないコマンドも存在する. <target> には, RMX 形式のアドレス, もしくはドメ認証局という第三者的存在を必要とせず, 認証局のシステムの維持, 管理ということが必要ないので, 導入が容易.k•

S/MIME と比べて, 公開鍵の信頼度が落ちる.

S/MIME•

認証局という第三者的機関を導入したことにより, 通信対象が広がり, 不特定多数の相手と安全に通信することが可能.

•普通認証局は有償で証明書を発行するので, 導入にコストが掛かる.

PGP において, 各鍵はその鍵が誰のものであるかがわかるよ

者の間で暗号化・復号化, 署名・検証というプロセスを 2 回行うにする為のユーザー ID(通常 [name] <[adress]> といった形うというもので, 送信者と受信者が 1 対 1 の時に使う自分の鍵式) と, 鍵を一意に識別する為の鍵 ID(16 進数の 8 桁の数字) をペア (図の橙の鍵, 以後 A とする) の他に RMX サーバーがサ持つ. 鍵 ID は厳密には一意ではないが, 意図して作らない限りブドメイン毎に作る鍵ペア (図の緑の鍵, 以後 B とする) を 1 つは鍵 ID とユーザー ID が同じ鍵は出来ず, 本機構では, 今回の作ることで, 実現可能である.

実装ではそういった鍵の偽造は起こらないと仮定し, 一意であ

またこの機構が, fml のそれと大きく異なる部分は, fml に備ると考える. しかし, 通常はこういった偽造を避ける為に, フィわっている署名機能はメーリングリストへの送信者制限の為ンガープリントを用いた方法をとる.に設けられているものなので, 送信者とメーリングリストサー

また前述の通り, PGP は S/MIME に比べ, 公開鍵の信用度が薄れるという問題点があり, 今回の実装では, 直接これにはバーの間でしか行われないが, 今回の機構はメーリングリストと受信者の間でもそれが行われる点である.

対処しきれていないが, これに対処する方法として, S/MIMEを導入する以外に RMX サーバーに送信ドメイン認証を組み込

4. 1 鍵データベース

み, なりすましの可能性のあるメールを弾くことが考えられる.

本機構を利用するには, 前章で述べたような送信者と受信者

この送信ドメイン認証のうち SPF と呼ばれる方法は, 送信元のが 1 対 1 であるような場合と違い, 送信相手に自分の公開鍵をサーバーと受信するサーバーの両方が対応している必要がある

渡しておく代わりに RMX サーバーに鍵ペア A の公開鍵を渡しが, 総務省の調査によると 94.31%と高い普及率となっており,ておく必要があり, また送信相手の公開鍵を受け取っておく代

これを RMX サーバーに導入することで, 完全ではないが初回わりに RMX サーバーから鍵ペア B の公開鍵を受け取っておくの鍵登録 (5 章で述べる) の際になりすましメールを防止するこ必要がある. 本実装においては, この鍵の管理を GNU Privacyとが出来る. しかしながら, これらの対策は公開鍵の信用度を上

Guard (GnuPG) という PGP の別実装として, 開発された暗げていることにはなっていないので 根本的な解決にはなってお号化ソフトで行っている [10]. また, この GnuPG で管理されらず, 将来的には S/MIME も使用可能にしていきたいと考えている鍵の集合を, 本論文では鍵データベースと呼ぶ. そして,ている. fml においては, 現在 PGP を用いているが, S/MIME

この鍵データベースから目的の鍵を取り出す為に, 鍵ペア A 用への導入の可能性を示唆する報告や実際にメーリングリストにのメールアドレスと 1 つ 1 つの鍵ペアが持っている鍵を一意にS/MIME を用いた暗号化・署名機能を実装したという報告も識別出来る ID を登録した通常のデータベースのテーブルをサある. しかし, 現在実際に広く使われているものは確認出来無

ブドメイン毎に, 鍵ペア B 用のサブドメイン名とそれに対応すかった.

る鍵の ID を登録したテーブルを用意する. 前者はテーブル名

4. RMX における暗号化・署名
前章で説明したように暗号化や署名の機能を利用するには,はサブドメイン名, 後者のテーブル名は subdomain key テーブルとした. 以下の図 4 では, 例としてサブドメイン info 用の鍵をを取得する際の流れを示す.

送信相手の公開鍵を予め持っていて, 尚且つ送信相手に自分の公開鍵を渡している必要があった. しかし, メーリングリストのように送信者が 1 通のメールを送り, それらが複数人に転送されるような場合, 送るメールが 1 通なのに対し, 実質的な送信相手は複数人存在してしまう. すると, 従来のようには暗号化や署名が行えない. そこで, 著者らは RMX にメジャーなメーリングリストのうち, 暗号化・署名機能を持っている fml を参考にし, fml で使われている機構を改変した図 3 のような機構を著者らは提案する [8] [9].
図 4 鍵取得までの流れ

4. 2 メールの配送
前節で述べたように本機構を利用するには, 2 種類の鍵が登録されている必要がある. これは送信者だけでなく, 受信者についてもである. しかし, RMX は本来ユーザー登録を行って,利用するものではないので鍵の登録を送信相手に強制することは出来ず, 送った人全員が鍵を持っていることは期待出来ない.
図3

提案機構

よって, 送れる相手と送れない相手が出てきてしまう. このよ
うな事は本機構を用いない通常の暗号化・署名でも起こり, い

この機構は送信者と RMX サーバー, RMX サーバーと受信くら送信者が暗号化・署名したくても相手が鍵を作っていない

と暗号化・署名が出来ない. よって今回の実装では, 鍵の登録を(1) 鍵ペア A の公開鍵の登録行っていないユーザーに対しては, メールのタイトル, 送信者の#PGPMAIL.regpub#@<subdomain>.<domain>

アドレス, 送信時間と, 鍵を登録していない為に内容を見ることが出来ないという旨をメール本文に記載し, 本来の送るメール(2) 鍵ペア B の生成・登録と公開鍵の返信の代わりに送るようにしている. 以下では, 送信相手全員が鍵#PGPMAIL.getkey#@<subdomain>.<domain>を登録していると仮定して, メールがどのように配送されるか
以下, 各々の鍵の登録について述べる.

を詳細に述べる.

4. 2. 1 送信者と RMX サーバー間
送信者は鍵ペア B の公開鍵でメッセージに対して暗号化を行い, 鍵ペア A の秘密鍵で署名を行う. こうして届いたメッセー

5. 1. 1 鍵ペア A の公開鍵の登録
鍵ペアの A の公開鍵の登録の様子を図 6 に示す.
この図にもあるように鍵の登録を行う際には, 上で述べたメージに対して, 今度は鍵ペア A の公開鍵で署名の検証を行い, 正しい事が確認出来たら, 次に鍵ペア B の秘密鍵を用いて復号化を行う.

4. 2. 2 RMX サーバーと受信者間
次に署名の検証・復号化が行われたメッセージに対して, 各送信相手の鍵ペア A の公開鍵で暗号化を行い, 各送信者の鍵ペア B の秘密鍵で署名を行う. こうして暗号化・署名が行われたメッセージは各ユーザーに送信され, 各ユーザーは鍵ペア B の公開鍵で署名の検証を行い, 正しい事が確認出来たら, 次に鍵ペ

図6

鍵ペア A の公開鍵の登録

ア A の秘密鍵を用いて復号化を行う.
ルアドレス宛に登録したい公開鍵を添付して, メールを送信す
最後に, プラグイン内でのメール配送の際の処理をまとめたるだけで, 登録が正常に完了した場合, その旨のメールが送られフローチャートを示す. プラグインは RMX 形式のアドレスをる. また RMX サーバー側ではこの添付されて送られてきた公解析し, 宛先を取得してから動くので, プラグインには配送先の開鍵を鍵 DB に登録し, 鍵 ID を鍵情報を管理するデータベーメールアドレスのリストが渡されている.

スへ登録している.

5. 1. 2 鍵ペア B の公開鍵の取得
鍵ペア B の公開鍵の取得 (初回) の様子を図 7 に示す.
この図にあるように鍵の生成・登録を行う際には, 上で述べた

図 5 配送処理のフローチャート

5. 本機構の使用方法
5. 1 鍵 の 登 録
4 章でも述べたように本機構を用いるには, まず送信者と受図 7 鍵ペア B の公開鍵の取得 (初回)

信者が 1 対 1 の時に使う自分の鍵ペアの公開鍵を鍵データベースに登録し, 鍵情報を格納するデータベースにその鍵の ID とメールアドレス宛にメールを送るだけで良い. 本システムでは,メールアドレスを格納する必要がある. そして, 次に RMX サー

初回のみこの鍵を要求された際に鍵ペアを生成し, 2 回目以降バーが各ユーザーとの間で作る鍵ペアを生成し, その秘密鍵をは生成を省く. RMX サーバー側ではこのようなメールが来る鍵データベースに登録し, 鍵情報を格納するデータベースにそと, 初回のみ鍵ペアを生成し, その鍵を鍵 DB に登録して, 鍵情の鍵の ID を格納し, 公開鍵は各ユーザーに送る必要がある. こ報を管理するデータベースに鍵 ID を登録した後に, 生成したの 2 種類の鍵の登録を本機構では, RMX の拡張プラグイン機

公開鍵をメールに添付して送り返す. そして 2 回目以降は, 公能を用いて行い, 以下のようなアドレスを用いる.

開鍵を取り出し, 送り返すだけになる.

5. 2 メールの送信の点では, どちらについても fml, RMX における機能の一部と次にメールの送信の方法について, 述べる. 全てのメールに対して, 定義しているので fml や RMX を導入していれば, 管理して暗号化・署名を行いたいということもあるだろうが, 暗号者側は導入の際に特別な作業は必要ないといえる. ユーザー側化や署名は普通オプションであるので, 鍵の登録と同様に RMXに関しても, 鍵を作ること以外にすることはないので, 大差はなの拡張プラグインを用いて, 以下のようなアドレスで送信を行いと言える.

うようにした.

#PGPMAIL.send#<target>

6. 1. 2 使用方法の比較
実際に暗号化・署名を行ったメールの送り方については, ど<target> には RMX のアドレスが入る.

ちらも大差はないが, fml ではメーリングリストのアドレスに送最後に具体的なメーラー等での利用方法の例として, Thunder-るだけで良いのに対し, RMX の場合は#PGPMAIL.send#とbird を用いて, メールを送る場合を流れを示す. Thunderbird

いうのを RMX 形式のアドレスの前に付けて送るので, 少々面で PGP を用いた暗号化・署名を簡単に行う為には, Enigmail

倒ではあるが, 大差はないと言える.という拡張プラグインを用いる. これを用いると鍵の生成をコマンドライン上でなく, GUI を用いて出来るほか, メッセージ

6. 1. 3 機能面での比較への暗号化や署名が使う鍵を選んで, 送信ボタンを押すだけのまず, 使える鍵の種類についての比較をする. 本機構では, 最簡単な作業のみで行うことができる. 本機構を Thunderbird でもよく使われる RSA のみを使用できるようにしたが, PGP が用いる場合は, 本機構を用いずに暗号化・署名を利用する時と対応しているものであれば, 何でも使用できるという点で fml

比べて, 暗号化の際に選択する鍵が個々の送信相手の鍵でなく,の方が優れている. fml で使用できる RSA 以外の暗号化方式

鍵ペア B の公開鍵であるだけでそれ以外は何も特別な事はせずは, 楕円曲線暗号などが挙げられる.に利用できる.

次にアーカイブについて, 比較する. fml の場合は, アーカイブ機能を用意しているが, 暗号化したメールの場合, 各個人に向け

6. 評

価

本システムの有用性を評価するため, fml の暗号化・署名機能と今回 RMX に実装したものについて, 比較を行う.て, 公開鍵で暗号化したものを保存しておくので, 何千人単位の人へ送る場合はその分だけ保存する必要があり, また後からメーリングリストに参加した人はアーカイブを閲覧できないという問題もある. 一方, RMX においては, 現在開発を進めているアーカイブ機能があるが, 今のところ暗号化されたメールに6. 1 fml の暗号化・署名機能との比較

対しては, 対応が追いついていない状況である.

ここでは, 利用までに必要なセッティングと使用方法, そして機能面や安全性について比較を, 同じように PGP を用いて暗6. 1. 4 セキュリティ面での比較

号化・署名機能を行うメーリグリストである fml と比較する.

セキュリティについての比較を行う. これに関しては, 4 章で述べたように S/MIME ではなく, PGP を用いている以上, 公6. 1. 1 セッティングの比較

開鍵を登録する際のなりすましなどは完璧には防ぎきれない.

まず, 鍵の登録について比較する. fml においては, 暗号化・そういった点においては, 両者共に不完全な部分はある. また 4署名を行う際はメーリングリストの管理者が, メンバー全員の章で述べたように fml における署名は, 投稿制限を行う為の手公開鍵を集めて, まとめてメーリングリストサーバーに登録す段として, 実装されているので, 電子署名が行われるのは送信者るといったことをする. 一方で RMX の暗号化・署名においてとメーリングリストサーバー間のみである. この点においては,は拡張プラグインを用いて個人で登録出来るようにしたことで,RMX で実装した物が優れていると言える.

メーリングリストの管理者 (RMX の場合, サブドメインの設定ファイルを書いた人が管理者にあたる) に負担が集中しないといった利点がある.

これらの比較をまとめたものを表 1 に示す.

7. お わ り に

次に暗号化・署名を行うのに必要な ML 側の設定について比較

本研究では, RMX に暗号化・署名機能を拡張プラグイン機する. fml では, メーリングリストの管理者がメーリングリスト能を用いて実装を行った. この機構の開発によって, 不完全での設定ファイルで$USE ENCRYPTED DISTRIBUTION のはあるがセキュアなメール配送が RMX において可能になり,変数に入れる値を変えることで, 暗号化・署名を行うかどうか

RMX に新たな利用方法を見出した. また本システムは実際にを変えることが出来る. これに対し, RMX では拡張プラグイン

運用されている暗号化・署名機能を有するメーリングリストでを用いて, 暗号化・署名を行うので, ML 側における設定が必要ある fml と比較しても, 劣る部分もあれば優れている部分もあない. 送信者が暗号化・署名を行うか否かを決めることが出来るが, 全体として大差のない物となっている.

る点が, 管理者主体でオンかオフのどちらか一方の状態でしか今後の課題としては, 前章でも述べたように, 本システムでは運用出来ない fml と大きく異なる.

暗号化の規格として, PGP を用いてる為, どうしても公開鍵の最後に, 暗号化・署名機能の導入のしやすさについて述べる. こ

信頼性が薄くなってしまい, セキュリティ面で少々の不安があ表 1 fml と RMX の暗号化・署名機能の比較

fml

RMX

鍵の登録×〜△◯

暗号化・署名を行う際に必要な設定△◯システムの導入◯◯

送信方法◯◯

使える鍵の種類◯△

アーカイブ

△×

盗聴◯◯

改竄&なりすまし△△るので, 暗号化規格として, S/MIME を用いた実装も RMX に行っていきたいと考えている.

文献[1] Kim Hanki, Sang-Gyu Shin, Motomichi Toyama. “A RuleBased Mailing System for an Organization”, International
Workshop on Information Processing over Evolving Networks, June 2006
[2] 高畑 理, 藤沼 健太郎, 石橋 玲, 遠山 元道. “Magic Mirror Mailing：個人情報データベースを利用する柔軟なメイル配送システム”, 情報処理学会データベースシステム研究報告 Pages:123-128
July 20[3] 安藤 翔, 遠山 元道. “RMX におけるルール記述に基づく送信許可機構”, DEIM2015[4] 松本 洋平, 北 和人, 遠山 元道. “RMX における拡張プラグイン機構の導入及び各種プラグインの開発”, DEIM2014[5] Williams, Henry. “A modification of the RSA public-key encryption procedure (Corresp.).” Information Theory, IEEETransactions on 26.6 (1980): 726-729.
[6] PGP. http://www.pgpi.org/[7] Garfinkel, Simson. “PGP: pretty good privacy.”, O’Reilly
Media, Inc. pp11-20 1995
[8] fml. http://www.fml.org/[9] 深町 賢一. “fml バイブル”, オライリー・ジャパン pp235-242
2001[10] GnuPG. https://www.gnupg.org/