S/MIME

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

S/MIME(エスマイム、Secure / Multipurpose Internet Mail Extensions)とは、MIMEでカプセル化した電子メール公開鍵方式による暗号化デジタル署名に関する標準規格である。

歴史[編集]

元々S/MIMEは米国RSA Data Security Inc.によって開発された。元の仕様は暗号メッセージ形式に関する事実上の業界標準であるPKCS #7を使い新開発のIETF MIME仕様を採用した。

S/MIMEへの変更管理はそれ以来IETFの手に委ねられ、また現在その仕様はあらゆる点でPKCS #7と全く同じIETF仕様である暗号メッセージ構文(CMS)に拡張されている。

機能[編集]

S/MIMEは電子メールソフトのために暗号技術を使ったセキュリティ機能(認証、通信文の完全性(改竄防止)、発信元の否認防止(デジタル署名使用)、プライバシーとデータの機密保護(暗号化使用))を提供する。S/MIMEはapplication/pkcs7-mime(smime-type "enveloped-data")というMIMEタイプを用いて、データが封印(暗号化)されたデジタル封書を実現する。(あらかじめ準備された)封印される通信文全体は暗号化され、続いてapplication/pkcs7-mimeのMIMEエンティティに挿入されるCMSの書式に格納される。

S/MIMEの機能は現代のメールソフトの大多数に組み込まれ、それらの間で相互運用される。

S/MIME証明書[編集]

上記のアプリケーションでS/MIMEを使う前に、自身の組織内認証局(CA: Certificate Authority)から、または以下に挙げているような公的な認証局(パブリックCA)から、個別の鍵/証明書の両方を入手しインストールしなければならない。最も効果的な方法は、署名用と暗号化用に別々の鍵(および関連する証明書)を使う事である。こうする事により署名用の鍵の否認防止という特性を危険にさらす事なく、暗号文を復号する鍵を預託できる。暗号化には証明書の保存場所(証明書ストア)に送信相手の証明書が保存されている必要がある(一般的には有効な署名がされた証明書と一緒にメールを受信した時に自動的に保存される)。デジタル署名のための送信者自身の証明書を持たずに、(送信相手の証明書を用いて)暗号文を送信する事は技術的には可能だが、実際には、S/MIMEクライアントは他者への暗号化を可能にする前に送信者自身の証明書を組み込むように要求するであろう。

よくある基本的な個人証明書は所有者を電子メールアドレスに結び付ける観点でのみ所有者の身元を検証し、その人の名前や職業は検証しない。もし必要ならば(例えば契約書へ署名するため)、後者はより一層の検証(電子公証)サービスやPKI管理サービスを提供する認証局を通して入手できる。認証に関するさらに詳しい点については、デジタル署名を参照の事。

認証局の方針に従い、証明書およびその全ての内容は、参照と検証のために公に掲示される可能性が有る。これはあなたの名前とメールアドレスを全ての人が参照したり、あるいは検索できるようにする。それ以外の認証局は通し番号と破棄状態しか掲示せず、個人情報は何も掲示しない。最低限、後者は公開鍵基盤の完全性を維持するために必須である。

実際にS/MIMEを展開する場合の障害[編集]

  • S/MIMEを扱えないメールソフトも有るため、"smime.p7m"という添付ファイルは人を困惑させる事が多い。
  • S/MIMEは厳密にはWebメールソフト経由の利用に適していないという意見もある。ブラウザーからローカルな端末にある署名鍵にアクセスしてメールに署名を添付することは、やろうと思えば実現可能ではあるが、どこからでもアクセスできるというWebメールの重要な長所を複雑にする。この問題はS/MIMEに限定したものではない - Webメールに安全に署名するどの方法も、署名を実現するプログラムをブラウザで実行する必要が有る。
    • 幾つかの組織はWebメールサーバが「秘密に通じている」事を容認できると考えるが、そう考えない組織もある。考慮する点の幾つかは下記の悪用ソフト(マルウェア)に関してである。もう一つの議論は、どのみちサーバは組織に機密のデータを含む事が多いという事である。つまり、もし追加データ(暗号文を復号するための復号鍵など)もまたそのようなサーバに格納され使用されるなら、どのような違いを作るのか。
    • 多くの場合は復号鍵とデジタル署名の生成に用いる署名鍵を区別する。そして、署名鍵を共有するより復号鍵を共有する方が、はるかに受け入れられると考えられる。デジタル署名の否認防止面が懸念されている時、これは特に傾向が強い。署名鍵は、そのライフサイクル全体において所有者唯一の制御下に有る事が、否認防止には必要とされるという極めて普遍的な合意が有る。ゆえに、Webメールサーバで復号が実施される事は、デジタル署名より受け入れられる可能性が有る。
  • S/MIMEは末端から末端(エンド・トウ・エンド)のセキュリティに合わせて設定される。暗号化は通信文だけでなくマルウェアにも行われるだろう。従ってメールが、(企業のゲートウェイなど)終端以外のどこかでマルウェアについての検査をされても、暗号化はマルウェアの検出システムを破り、首尾よくマルウェアを配布するだろう。解決策:
    • 復号にエンドユーザの端末上でマルウェア検査を実行。
    • ゲートウェイのマルウェア検査に先立ち復号処理が起動するように、ゲートウェイサーバ上に復号鍵を格納(これは見方によっては暗号化の目的を無にするにもかかわらず、もう一方のユーザのメールを読むためにゲートウェイサーバへのアクセスを誰でも可能にする)。
    • エンド・トウ・エンドの署名と暗号化を維持しながら、通過中に暗号文の内容を検査するために特に設計された通信内容検査システムを使用。そのような解決策は、通信文の復号に用いる双方の復号鍵および一時的に復号された内容の、保護機能が内蔵されていなければならない。

警告[編集]

通信文がS/MIME(またはPKCS#7)を用いて暗号化されている時、通信文の対象とする受信者の公開鍵は受信者の証明書から展開される。また受信者の証明書は通信文の中で発行者と通し番号で識別される。この結果の内の一つは次のような問題になる。もし証明書が更新される場合、すなわち新しい証明書、同じ鍵ペアで、それ以上必要でないと考えられる古い証明書が削除される場合、鍵ペアは変更されていないにもかかわらず、S/MIMEクライアントは証明書の更新前に送信された通信文の復号鍵を探せないだろう。言い換えれば、期限切れ証明書の削除は予期しない結果になる可能性が有る。

更にほとんどの場合は、もし暗号化に用いられた証明書が削除されたか有効でない場合、証明書の有効期間に関わらず、S/MIMEクライアントが暗号化された書式に格納したあらゆる通信文は解読不可能だろう。

通常、S/MIME署名は"添付型署名"で行われる。その署名情報は署名されている本文から分離している。このMIMEタイプは2番目の部分にapplication/(x-)pkcs7-signatureのMIMEサブタイプを持つmultipart/signedである。メーリングリストソフトは原文部分を改変する事と、それによって署名を無効にする事で評判が悪い。

関連項目[編集]

外部リンク[編集]