電子メールのセキュリティ編は多少難解でしたが、これからインターネットの世界に飛び込んでスキルを磨いていく方には必須の知識になります。

PKIは電子メールのみが対象ではなく、インターネット全体の信頼の基盤です。認証局が電子証明書によって個人（の公開鍵）を証明することで、公的な証明として法的な根拠を持ちます。

電子証明書は運転免許証で本人確認するのと同じように、インターネット上で本人証明として利用されています。このことは、これまでの学習でもう十分理解できていると思います。

本項では、電子メールのセキュリティ編の最後として、PKIの仕組みを理解したうえで、電子メールだけに特化したセキュリティの仕組みを学習していきたいと思います。

電子メールの暗号化についてこれまで学習してきましたが、それらの方法は完全なものだったでしょうか？

暗号通信には、電子メールの危険性 で学習のとおり、SMTP-AUTH、POP3S、SMTPS、STARTTLSといった規格があります。しかし、どれも完全ではありません。

これらは、メーラーから送信者側のメールサーバまでを暗号化しますが、相手側のメールサーバが対応していない場合は暗号化されません。そのため、相手のメーラーまで届くすべての経路が暗号化されているかどうか確認することができないのです。

したがって、

通信経路を暗号化するのではなく電子メールそのものを暗号化する

必要があります。

その方法はじつは簡単で、公開鍵暗号方式でメール自体を暗号化して送信すればよいだけです。なぜ経路を暗号化するような回りくどい方法がとられてきたのでしょうか。

なぜならそこに高いハードルが存在するからです。単純な理由ですが、その理由を学習する前に、まず電子メールの根本的な通信の仕組みを理解しておきましょう。

電子メールの仕組み で学習のとおり、電子メールは「テキストデータ」しかやり取りできません。同項ではそれより深く学習しませんでしたが、なぜテキストデータしかやり取りできないのでしょうか。

電子メールはインターネットのWWW以外の大きな要素の一つであり、インターネットの初期から利用されているサービスです。そのため、言わば古い仕組みがベースとなっています。

すなわち、多言語のやり取りは想定されておらず、

英語でのやり取りしか想定されていない

という大きな要因があります。

そもそも、電子メールに限らずデジタルデータは、アナログデータとデジタルデータ で学習のとおり、0と1の2進数でやり取りされています。英語であってもアルファベットなどの文字や記号は、2進数に対応させた「コード」に変換されます。

こうして、電子メールは「文字コード」というコード体系に置き換えられて送受信されます。この文字コードが英語だけの文字コードになるのです。（文字コードについては、文字コードとは で詳しく学習します）

要するに、アメリカで考えられた英語だけの使用を前提としたシステム体系で電子メールがやり取りされているということですが、この文字コードは、

ASCII（アスキー）

と呼ばれる文字コードになります。

ASCIIは1文字7ビットで表現されます。1文字7ビットということは、2⁷＝128文字を扱うことができます。したがって、ASCIIコードは「128種類」の英数字と記号が使えるコードになります。

この時点でもうおわかりだと思いますが、128文字では日本語などのカナや漢字を織り交ぜた言語になるととても表現しきれないのです。逆にアルファベットなら十分足りることになります。

ASCIIコードは他の文字コードに大きな影響を与えたコードで、ASCIIコードをもとに様々な文字コードが誕生してきました。

のちに誕生した文字コードは、1文字に8ビットを用いた256種類の文字を扱うコードが一般的です。（デジタルデータの単位 で学習のとおり、現在のコンピュータが扱うデータの最小単位は「8ビット」を1単位とする「1バイト」であるため）

多くの文字コードは、英数字の部分がASCIIコードをもとにつくられていて、残りの128文字分にその文字コード独自の文字を割り当てています。日本語の文字コードでは、1文字に2バイト（16ビット）を使用するコード（Shift_JISなど）があります。

こうして日本語などの文字数の多い言語に対応した文字コードが誕生してきましたが、

電子メールは7ビット体系の文字コードでやり取りすることがルール

になっています。

つまり、ASCIIコードの利用しか想定されていなかったため、ASCIIに代表される「7ビット」の文字コード以外で電子メールを送受信することができないのです。

であれば、8ビット以上の文字コードに対応すればよいだけの問題ですが、世界中に広がったインターネット上には7ビットコードにしか対応していないメールサーバが現在も存在しているのです。

英語だけでやり取りしていた当時はこれで問題なかったのですが、7ビットで表現できない言語を使用している国や地域では、このルールは非常に困ります。

日本語を扱うには、漢字を含めると8ビットの256文字でも到底足りません。前述のとおり、日本語は1文字を表現するのに2バイト（16ビット）以上を使用する文字コード（マルチバイトコード）を使用しています。

またメール本文の文字だけでなく、メールには画像ファイルやWordやExcelなどのファイルを添付することができるため、こうした添付ファイルも7ビットルールに合わせる必要があります。

したがって、

日本語の文字や添付ファイルはそのままでは送受信できない

ということになります。

そこで、ASCII以外の文字コードも扱えるように、既存の電子メールのシステムが拡張されました。

この拡張規格を、

MIME（マイム）

と言います。

MIMEは「Multipurpose Internet Mail Extension」の略で、

ASCII形式以外のデータも送受信の際にASCII形式（7ビットコード）に変換する

というものです。

送信時にデータを7ビットのASCIIコードに変換（エンコード）して送信し、ASCIIコードで受信して元のデータに復号化（デコード）して日本語で表示するというわけです。

つまり、電子メールはASCIIコードしか送信できないのではなく、ASCIIコードしかなかった頃の、ASCIIコードでのやり取りしか想定していないメールサーバシステムが世界中で構築されているために、7ビットのコード体系を使用せざるを得ないということです。

ここで重要なポイントは、

MIMEによって7ビットコードに変換処理するのはメーラーでありメールサーバではない

ということです。

このことによって、世界中にあるメールサーバの中に7ビットコードにしか対応していないサーバがあったとしても、日本語のメールを正確に届けることができるようになります。

そのため送受信どちらのメーラーもMIMEに対応していなければなりません。とは言っても、日本語を利用できるメーラーであれば当然MIMEに対応しており、普段我々が意識することはありません。

このように、なんとか日本語等のマルチバイトコードを7ビットルールに適用させようとして考えられた仕組みがMIMEなのです。

ただし、注意が必要なことはMIMEは規格であって、MIMEというプログラムでコード化する処理をかけるわけではありません。MIMEという手順書に掲載されているルールでコード化しましょうということになります。プロトコルと同義です。

実際のメールから、MIMEの規格で変換されたコード（ソース）を確認することができます。Outlookでは特定のメールをダブルクリックして別画面で表示し、その画面の「ファイル」タブの「プロパティ」ボタンを選択します。

すると、画面下の「インターネット ヘッダー」欄にメールのヘッダー情報が表示されます。

「MIME-Version：1.0」とあるように、MIME形式で送受信されていることを示しています。バージョンは現在のところ「1.0」しかありません。 ほぼすべての日本語のメールはMIMEによって変換されており「MIME-Version：1.0」と記載されています。

また「Content-Transfer-Encoding：7bit」とあるように、7ビットコードで送信されていることもわかります。

このほか、メールヘッダーからは他にも多くの情報を入手することができます。

常にこれらすべての情報が表示されるわけではなく、迷惑メールの設定がある場合などは他にも情報が表示されます。

こうした情報は、エンコードされた7ビットコードをメーラーがデコードするときに必要な情報になります。先述のとおり、メーラーが変換処理を行っているためです。

特に重要なのは「Content-Type」で、

MIMEタイプ

とも呼ばれる表示形式です。

これによって、メーラーは送られてきた7ビットコードがどのような形式なのか判断することができます。つまり、そのデータの形式を表現するための規格をMIMEと呼ぶわけです。

補足として「Content-Type」のところで登場した、

マルチパートメール

についてもう少し説明しておきます。

マルチパートメールは、メテキストメールとHTMLメールの両方を送信し、送信先の相手が利用しているメーラーの環境に合わせて、どちらか片方を表示させるという方法になります。

特に迷惑メール対策としてHTMLメールを非表示に設定している場合に有効で、営業やお知らせなどのメルマガ系で近年増加しているメール形式です。

こうした複雑な構造のメールが増えてくると「Content-Type」の表示も単純なものばかりではなくなってきています。ご自身に届いているメールのプロパティをぜひチェックしてみてください。

また、上表からもわかるとおり「ASCII」という文字はどこにもありません。かわりに、

ISO-2022-JP

という文字コードが登場しました。

ISO-2022-JPは、日本語のJISコードとASCIIを7ビットで切り替えることができる文字コードです。なぜASCIIの文字がないのか、ASCIIとの違いは何かを理解するためには文字コードの仕組みを理解する必要があるので割愛しますが、ここではASCIIに変換することができるコードという理解で問題ありません。つまり、ASCIIと同じコードとして扱えるということです。

もともと日本語はこのISO-2022-JPで7ビットのASCIIに変換するのが一般的でしたが、近年では「UTF-8」というコードも利用されるようになりました。このあたりは複雑なので、文字コードとは で詳しく学習します。

そしてさらにと混同しやすいのがエンコード方式です。

MIMEと文字コードとエンコード方式がごっちゃになってしまいがちなので、一度整理しておきましょう。

メールは、テキストだけのメールと、HTML形式や添付ファイルを含んだテキスト以外のメールに分けられます。ファイルとは で学習したとおり、データは「テキスト」と「バイナリ」に分類することができました。テキストは文字だけのデータでバイナリはテキスト以外のデータです。つまり、テキストのメールとバイナリのメールに分けることができます。

テキストメールの場合は、そのまま文字コードをASCIIに変換してやり取りすることが可能です。「iso-2022-jp」や「UTF-8」といった文字コードは、ASCIIコードと切り替えることが可能なため、そのまま利用することができるのです。

しかし、添付ファイルやHTML形式のメールなどのバイナリメールは、これらの文字コードを利用することができないため、どうにかしてASCIIにエンコードする必要があります。

このエンコードの方式が、

base64（ベース ロクジュウヨン）、quoted-printable（クォーテッド プリンタブル）

といった方式になります。

つまり、テキストの場合はMIMEの規格に定義されている文字コードを選択し、バイナリの場合はMIMEの規格に定義されているエンコード方式を選択してASCIIにエンコードするということです。

MIMEによってテキスト以外の添付ファイルも7ビットのASCIIに変換して送信できるので、MIMEは電子メールにとって必要不可欠なものになっています。（電子メール以外でもMIMEタイプが利用されています）

ただし、添付ファイルのデータサイズが大きくなればなるほど、エンコードされた文字列は膨大なものになっていきます。当然、処理時間がかかることになります。

現在ではあまり気しなくなりましたが、10MB以上のファイルを添付しないという暗黙のルールがあったり、この7ビットルールのために電子メールではいくつかのルールがあります。次項でも詳しく学習しますが、基本操作 メール編 も学習してみてください。

そして、いよいよ電子メール自体の暗号化についてもMIMEを利用することで可能になります。ここからはMIMEによるメールの暗号化について理解していきましょう。

まず、MIMEを利用してメールを暗号化するための方式を、

S/MIME（エス マイム）

と言います。

S/MIMEは「Secure Multipurpose Internet Mail Extensions」略で、これまで学習してきた公開鍵暗号化方式によってメールを暗号化します。当然、暗号化方式は同じになります。

異なるのは、これまでメーラーからサーバなどの経路を暗号化してそこを通るデータすべてを保護していましたが、S/MIMEはメール自体を暗号化するので、どこで誰に見られても解読される心配はありません。

つまり、

S/MIMEは電子メールのみに特化した方式

になります。

基本的にすべての経路を暗号化することは現実的ではなく、S/MIMEによって暗号化されたメールをやり取りするのがもっとも安全性が高いと言えます。

S/MIMEの仕組みは、PKIの仕組みを理解していれば簡単に理解することができます。暗号化と復号化の流れはハイブリッド暗号方式とまったく同じです。

まず、送信者が共通鍵を作成してメールを暗号化し、受信者が作成した公開鍵で共通鍵を暗号化してセットで送信します。受信者は自分の秘密鍵で共通鍵を復号化してメール本文を復号化するという流れです。

通常は、合わせて送信者がデジタル署名を付与し、「暗号化された本文」、「暗号化された共通鍵」、「デジタル署名」の3点セットで送信します。そして、受信者は送信者の本人確認と改ざんの検証を行い安全性を確認します。

ここで暗号化する本文というのは、MIMEの規定によってエンコードされたASCIIコードです。

まさにこれまで学習してきた電子メールの暗号化通信そのものがS/MIMEの仕組みになります。

S/MIMEを利用するには、認証局から電子メール用（S/MIME用）の電子証明書を購入し、OutlookなどのS/MIMEに対応したメーラーに設定するだけで利用することができます。自動的に暗号化と復号化は行われるので特に暗号化を意識する必要はありません。必要なのは、対応しているメーラーと電子証明書だけです。

Outlookでは上画面で電子証明書を選択して設定すると利用できるようになります。（S/MIMEの実際の利用方法、Outlookの設定方法は応用操作 メール編 で詳しく学習します）

ただし、暗号文を送信するためには、

相手の公開鍵が必要なる

わけです。

受信者の公開鍵で暗号化することが公開鍵暗号方式の原則なので、暗号文を送る前に、まず相手からデジタル署名等によって公開鍵を受け取っておかなければならないのです。

つまり、送信相手も電子証明書を取得していて、メーラーの設定が完了している必要があります。

このように電子証明書の購入に費用と面倒な手続きが必要なことに加え、こうした仕組みを理解するのが難しいために、S/MIMEはほとんど一般では利用されていないのが現状です。

そのため、通常はデジタル署名のみ利用するケースが多いです。差出人が本人であることの証明のためだけに利用し、メール本文を暗号化することはあまりありません。

下図はデジタル署名付きメールを受信したイメージです。Outlookでは「赤いリボン」のアイコンが表示されます。

アイコンをクリックするとデジタル署名の詳細を確認することができます。

双方が電子証明書を取得して暗号通信を行える環境であれば、相手の公開鍵でメールを暗号化して送ることができます。暗号化されたメールは、Outlookでは「鍵」のアイコンで表示されます。

流れとしては、相手からデジタル署名付きのメールを送信してもらい、相手の公開鍵を受け取ってからそのメールに返信するかたちで暗号化するのが一般的です。通常、メーラーが自動で公開鍵を取得するので、Outlookでは「暗号化」ボタンをクリックするだけで暗号化することができます。

一方、S/MIMEに対応していないメーラーやウェブメールなどでデジタル署名付きのメールを受信した場合は、こうしたアイコンではなく「smime.p7s」という名称の添付ファイルが届く場合があります。

これはデジタル署名のファイルになります。S/MIMEに対応していないメーラーでこのファイルはほとんど意味がなく、S/MIME対応のメーラーで検証することで安全性が確立できます。

いずれにしても、仕組みが難解なこと、電子証明書の購入にお金がかかること、有効期限があり更新が必要なことなど、利便性を求める電子メールではハードルが高いためにS/MIMEはあまり普及していません。これが経路の暗号化をすすめた理由です。

しかし、昨今のマルウェア（ウイルスを含む悪意あるプログラムを総称する用語）被害の拡大やセキュリティ意識の向上もあり、今後は普及してくるかもしれません。特に銀行のような資金に余裕がありセキュリティレベルが高い企業では導入が進んでいます。

せっかく個人に電子証明書が格納されたマイナンバーカードを配布しているのだから、こういったところで電子証明書を活用させてもらえないかと切に願います。

現在、電子メールを介した詐欺被害やマルウェア被害は後を絶ちません。ほとんどのマルウェアの進入は電子メールからと言われており、無防備なメール操作は被害者になるだけでなく遠隔操作によって加害者になる可能性すらあります。

これらはウイルス対策ソフトだけでは防ぐことができません。そのため、影響の大きい大企業は頭を悩ませています。メールのユーザーである職員全員に電子証明書を購入すると大変な金額になるからです。

こうした背景から、現代社会の実情としてはメールの内容を暗号化して盗聴を防ぐことより、なりすましメールによる詐欺や悪意あるプログラムの進入防止に重きを置いています。

すなわち、デジタル署名に代表される送信者が本人であることの証明が何より重要となっています。

そこで、S/MIMEとは別に、

送信ドメイン認証

という仕組みが注目されています。

送信ドメイン認証は、個人単位での認証ではなく、ドメイン単位で認証を行う技術です。ドメインは、クラスとドメイン で学習のとおり、メールアドレスでいう「@」以降の部分になります。

例えば「Yamanjo社」という会社があった場合、Yamanjo社は「yamanjo.net」というドメインを取得します。そして、このドメインを社員のメールアドレスに割り当てます。

すると「個人名@yamanjo.net」がメールアドレスとなり、例えば「ohtani@yamanjo.net」や「ichiro@yamanjo.net」といったアドレスを社員が利用します。

つまり、ドメインはその組織全員が利用するため、ドメイン単位で認証が可能になると、個別に電子証明書を購入する必要がなく、低コストでデジタル署名と同様の信用を相手に与えることができます。

本項では詳しく解説しませんが、送信ドメイン認証には「SPF」、「DKIM」、「DMARC」といった種類があります。

簡単に言うと「DKIM」では、ドメインを管理するDNSサーバで公開鍵を公開し、受信者はDNSサーバに問い合わせることで公開鍵を入手してデジタル署名を検証します。ドメイン単位でのデジタル署名になります。

更新履歴

2008年11月24日

ページを公開。

2009年6月8日

ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。

2018年1月30日

ページをSSL化によりHTTPSに対応。

2023年6月7日

内容修正。

参考文献・ウェブサイト

当ページの作成にあたり、以下の文献およびウェブサイトを参考にさせていただきました。

文献

図解入門 インターネットのしくみ

メールの構造を理解する：メールはなぜ届く

http://pc.nikkeibp.co.jp/article/NPC/20070405/267493/

8bitメールは問題ないのか？

http://www.securehtml.jp/utf-8/8bit.html

送信元アドレス偽装・表示名偽装など、メールの発信者偽装は簡単にできてしまう

https://local-note.com/security/sender/

multipartなメールの構造は通常どの程度まで複雑な入れ子になるか

https://www.softel.co.jp/blogs/tech/archives/5726

• 次ページ：「電子メールの書式とマナー」へ進む
• 前ページ：「電子メールのセキュリティ（6） ～ PKIの検証 ～」へ戻る
• 基礎知識：「メニューページ」へ戻る
• ホームへ戻る

管理人のつぶやき

Twitterのフォローお願いします！