[go: up one dir, main page]
コンテンツにスキップ

S/MIME

出典: フリー百科事典『ウィキペディア（Wikipedia）』
インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

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）に拡張されている。

RFC 8551がVersion 4.0の、RFC 5751がVersion 3.2の、RFC 3851がVersion 3.1の、RFC 2633がVersion 3の、S/MIME仕様を規定している。

機能

[編集]

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証明書は、EX.509v3のKeyUsage拡張属性の値にDigital SignatureとNon Repudiation (11) を、ExtendedKeyUsage拡張属性の値にE-mail Protection (1.3.6.1.5.5.7.3.4) を、SubjectAltName拡張属性の値に電子メールのアドレスを指定する。認証局によってはNetscapeCertType拡張属性の値を指定するかもしれない。

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

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

警告

[編集]

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

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

通常、S/MIME署名は"添付型署名"で行われる（「分離署名」や「クリア署名」ともいう）。その署名情報は、署名されている本文から分離している。このMIMEタイプは2番目の部分にapplication/(x-)pkcs7-signatureのMIMEサブタイプを持つmultipart/signedである。メール本文の改変と、それによって署名が無効になることで、メーリングリストのソフトウェアとは相性が悪い。

関連項目

[編集]

外部リンク

[編集]
OpenPGP・S/MIME
セキュア通信
OTR（英語版）
SSH
TLS/SSL
VPN
ZRTP（英語版）
P2P
D R A（英語版）
匿名化
ディスク暗号化（英語版）
ファイルシステム
セキュアOS
Service providers
教育
暗号通貨
Related topics
関連人物
「https://ja.wikipedia.org/w/index.php?title=S/MIME&oldid=97693171」から取得