S/MIME

S/MIME（Secure/Multipurpose Internet Mail Extensions）とは

S/MIMEは、MIME形式でカプセル化された電子メールに対して、公開鍵暗号方式を用いた暗号化とデジタル署名を提供する標準規格です。これにより、電子メールのセキュリティを大幅に向上させることができます。

歴史

S/MIMEは元々、RSA Data Security Inc.によって開発されました。初期の仕様では、PKCS #7という暗号メッセージ形式とIETFのMIME仕様が採用されていました。その後、S/MIMEの管理はIETFに移管され、現在はPKCS #7を拡張したIETF仕様であるCMS（暗号メッセージ構文）に準拠しています。S/MIMEの各バージョンはRFCで規定されており、RFC 8551がVersion 4.0、RFC 5751がVersion 3.2、RFC 3851がVersion 3.1、RFC 2633がVersion 3の仕様を定めています。

機能

S/MIMEは、電子メールソフトウェアに対して、認証、通信文の完全性（改竄防止）、発信元の否認防止（デジタル署名）、プライバシーとデータの機密保護（暗号化）といったセキュリティ機能を提供します。具体的には、`application/pkcs7-mime`というMIMEタイプを使用し、データを暗号化してデジタル封書のように扱います。これにより、メールの内容全体が暗号化され、CMS形式で格納されます。S/MIMEの機能は、多くの現代的なメールソフトに組み込まれており、相互運用が可能です。

S/MIME証明書

S/MIMEを使用するためには、自身の組織内認証局（CA）または公的な認証局（パブリックCA）から、個別の鍵ペアと証明書を取得し、インストールする必要があります。署名用と暗号化用には別々の鍵ペアを使用することが推奨されています。これにより、署名用の秘密鍵の否認防止特性を損なうことなく、暗号化されたメッセージを復号するための秘密鍵を安全に管理できます。暗号化には、送信相手（および通常は送信者自身）の証明書が証明書ストアに保存されている必要があります。一般的には、有効な署名付きの電子メールを受信した際に自動的に保存されます。デジタル署名には送信者自身の証明書が必要ですが、送信相手の証明書のみを用いて暗号化することは技術的には可能です。しかし、多くのS/MIMEクライアントは、暗号化を許可する前に送信者自身の証明書の設定を要求します。

個人証明書は通常、所有者の身元をメールアドレスにのみ結び付け、名前や職業は検証しません。より高度な検証が必要な場合は、電子公証やPKI管理サービスを提供する認証局を利用する必要があります。認証に関する詳細はデジタル署名を参照してください。認証局の方針によっては、証明書の内容が公開される場合があります。S/MIME証明書は、X.509v3の拡張属性に特定の値を設定して使用します。例えば、KeyUsage拡張属性にはDigital SignatureとNon Repudiationを、ExtendedKeyUsage拡張属性にはE-mail Protectionを、SubjectAltName拡張属性にはメールアドレスを指定します。また、NetscapeCertType拡張属性を設定する認証局もあります。

S/MIME展開時の課題

S/MIMEに対応していないメールソフトがあるため、`smime.p7m`や`smime.p7s`という添付ファイル形式に困惑するユーザーもいます。また、Webメールでの利用には課題があります。ブラウザからローカル端末の署名鍵にアクセスして署名を行うことは可能ですが、Webメールの利便性を損なう可能性があります。Webメールに安全に署名する方法は、ブラウザ上で署名プログラムを実行する必要があるため、S/MIMEに限らず同様の問題があります。一部の組織はWebメールサーバが安全であると考えますが、マルウェアの観点から懸念する組織もあります。また、復号鍵をサーバに格納して使用する場合、サーバが機密情報を扱うことを考えると、新たな懸念が生じる可能性があります。署名鍵と復号鍵を区別し、復号鍵を共有する方が、署名鍵を共有するよりも受け入れられることが多いです。特に、否認防止が重要視される場合には、署名鍵の管理がより厳格に行われる必要があります。

S/MIMEはエンドツーエンドのセキュリティを目的としていますが、暗号化によってマルウェア検査が困難になる場合があります。暗号化されたメールが途中でマルウェア検査を通過すると、マルウェアが検出されずに配信される可能性があります。この問題に対する解決策としては、エンドユーザーの端末でマルウェア検査を行う、ゲートウェイサーバで復号後にマルウェア検査を行う、または、通過中に暗号化されたコンテンツを検査できる特別なシステムを使用するなどが考えられます。

注意点

S/MIMEで暗号化されたメールの受信者の公開鍵は、受信者の証明書から取得されます。証明書が更新された場合、古い証明書で暗号化されたメールは復号できなくなる可能性があります。したがって、期限切れの証明書を削除する際には注意が必要です。また、暗号化に使用した証明書が削除されたり、無効になった場合、証明書の有効期間に関わらず、その証明書で暗号化されたメールは解読不可能になります。S/MIME署名は通常、添付型の署名（分離署名）で行われ、署名情報はメール本文から分離されています。このため、メール本文が変更されると署名が無効になるため、メーリングリストソフトウェアとの互換性には注意が必要です。

関連項目

• - Multipurpose Internet Mail Extensions（MIME）
• - TLS (Transport Layer Security、旧SSL)
• - Pretty Good Privacy (PGP)
• - GNU Privacy Guard (GnuPG)

外部リンク

• - RFC 8550: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
• - RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
• - S/MIME working group charter - S/MIME関連のRFCおよびインターネットドラフトへのリンクがあります。
• - How to forge an S/MIME signature - 一部のS/MIME実装に関する批判。
• - S/MIME IETF Working Group
• - S/MIME & IMAP
• - Mail .NET Library
• - S/MIME and OpenPGP
• - MIMEBlackbox - S/MIMEおよびPGP/MIMEをサポートするWindowsおよび.NETソフトウェア開発者向けのコンポーネント。
• - E-mail Client Testing for S/MIME Compliance
• - VeriSign's Public Directory (ldap://directory.verisign.com)
• - MozillaZine Knowledge Base: Getting an SMIME certificate
• - SMIME.org - メール暗号化の製品と標準に関するヘルプと参照を提供します。
• - How to secure email using S/MIME standard

もう一度検索