CMSとは何ですか？
CMS標準は、保護されたデータとその正しいオープンまたは使用に必要な情報を含む暗号化メッセージの構造を記述しています。 たとえば、メッセージには保護されたデータ、ハッシュと署名アルゴリズムに関する情報、署名時間、公開鍵証明書、証明書チェーンなどが含まれます。 これらの属性の一部はオプションですが、アプリケーション自体が可用性の必要性を判断できます。 各アルゴリズムには、両側で一貫している必要があるパラメーターのセットがあります。GOST34.10-2001の場合、公開鍵に加えて、モジュールp 、楕円曲線aおよびbの係数、楕円曲線qの点の循環サブグループの順序です。 そして、これらすべてを何らかの形でメッセージ受信者に伝える必要があります。
RSA Laboratoriesは、一連の公開キー暗号化標準（PKCS）で、次の標準で安全なメッセージの構文を定義することにより、この問題の解決策を提案しています。
これらの標準の開発は、CMS標準になりました。
合計で、CMSは6つのデータタイプをサポートします。
- ただのデータ
- 電子署名付きデータ（署名付きデータ）、
- パックデータ
- ハッシュデータ（ダイジェストデータ）、
- 暗号化されたデータ
- 認証済みデータ
この記事の枠組みでは、電子署名付きデータ（署名付きデータ）のみを詳細に検討します。
用語で混乱しないように、さらに安全な方法で送信したい初期データはdataと呼ばれ、結果の安全なCMSメッセージは単にmessageと呼ばれます 。
CMS標準（PKCS＃7およびRFC 5652）：理論
ちょっとした歴史
暗号メッセージ構文（CMS）は最初にPKCS＃7で定義され、後にRFC 2315「PKCS＃7：Cryptographic Message Syntax Version 1.5」として公開されました 。 さらにいくつかのRFCバージョンの後、2009年9月に、 RFC 5652「Cryptographic Message Syntax（CMS）」が採用されました。これは現在の標準です。
ネタバレは規格の厳しい運命を示しています。
見る 
PKCS＃7 / CMSの進化
PKCS＃7 / CMSの進化
CMS形式の署名（署名付きデータ型）
CMS標準で記述されている署名は、次の機能によって特徴付けられます。
- データは複数の関係者によって署名できます（複数の署名）。 この場合、メッセージには、署名者に関する情報（署名の値とその真正性を検証するために必要な情報）を含むいくつかのSignerInfo構造が含まれます。
- データ型はいかなる形でも規制されていません。データがCMS形式のメッセージになり得ること、つまり、アリスによって署名されたメッセージはボブによって完全に署名できることのみを明確にします。
- データだけでなく、一部のメッセージ属性（メッセージハッシュ（ダイジェストメッセージ）、署名時間（署名時間）、別の署名の値（副署名））にも署名できます。
- 署名者の公開鍵は認証されていない場合があります。
- まったく署名がない場合があります。
電子署名データはコンテンツの署名に使用されるだけでなく、多くの場合、証明書と証明書失効リスト（CRL）の配布に使用されます。 この場合、署名されたデータは利用できず、逆に証明書とCRLフィールドが存在します。
アリスがCMS形式で署名したメッセージは次のようになります（オプションの属性はグレー表示されます）。
- CMSバージョンの構文バージョンは、証明書、署名するデータのタイプ、および署名者に関する情報に依存します
- ダイジェストアルゴリズムには、使用されるハッシュアルゴリズムの識別子とそれに関連付けられたパラメーターが含まれます。
- カプセル化されたコンテンツには、署名されたデータ（コンテンツ）とそのタイプ（コンテンツタイプ）が含まれます。 コンテンツは存在しないかもしれませんが、タイプは存在しないかもしれません。
- 証明書は、証明書を発行した認証機関から各署名者への認証パスを反映した証明書チェーンを対象としています。 署名証明書も存在する場合があります。
- CRL（証明書失効リスト）は、署名証明書の有効性を判断するのに十分な証明書失効ステータス情報を提供します。
- 各署名者に関する情報は、署名者情報タイプの構造に含まれています。これは、ゼロ（署名がない場合）を含む任意の数です。
- CMSバージョンの構文バージョンは、署名者ID値によって決定されます。
- 署名者IDは、署名者の公開鍵（subjectKeyIdentifier）または署名認証に必要な公開鍵の証明書（issuerAndSerialNumber）を定義します。
- ダイジェストアルゴリズムは、署名者が使用するハッシュアルゴリズムとすべての関連パラメーターを定義します。
- 署名付き属性には、署名が必要な属性が含まれます。 フィールドは、単純なデータ（コンテンツタイプ= id-data）に署名する場合のみ存在しない場合がありますが、他のデータ（たとえば、コンテンツタイプ= id-SignedData）への署名には、少なくとも2つの必須属性-タイプ（コンテンツタイプ）とデータハッシュ（メッセージダイジェスト）。
- 署名アルゴリズムには、署名アルゴリズムの識別子とそのパラメーターが含まれます。
- 署名値には、データの秘密キー（コンテンツ）と署名の属性（署名された属性）によって署名されたハッシュの値が含まれます。
- 署名されていない属性には、署名を必要としない残りの属性が含まれます。
ボブがアリスから受信したメッセージに完全に署名することを決定した場合、カプセル化メカニズムが使用され、メッセージは次のようになります。
CMSは、従来の署名の機能を拡張する2つの興味深い属性を提供します。署名時間と副署名です。 最初の属性は署名の推定時間を決定し、2番目の属性は別の署名に署名するために使用されます（署名値のハッシュが署名されます）。 Countersignature属性は、署名済み属性にコンテンツタイプ属性を持たない署名者情報構造であり、必要なメッセージダイジェスト属性です。 Countersignature属性は、独自のCountersignature属性を持つことができます。
BobがAliceによって送信されたデータのみに署名すると同時に、Aliceの署名に署名することを決定した場合、メッセージは次のようになります。
ヨーロッパの残りのタイプのギャロップ
CMSは、この記事のトピックでは扱っていない他の興味深いタイプのメッセージを提供します。 したがって、全体像の残りのタイプに関する文字通りの単語。
パックデータ（エンベロープデータ）は、暗号化されたデータと、このデータが暗号化された1人以上の受信者に対して暗号化されたキーです。 暗号化されたメッセージと1人の受信者の1つの暗号化された暗号化キーの組み合わせは、デジタルエンベロープと呼ばれます。 このタイプは、1人以上の受信者の（署名された）データを含むエンベロープとして使用されます。
ハッシュされたデータ（ハッシュ付きのデータ）は、メッセージの整合性を検証するために使用され、多くの場合、パックされたデータのコンテンツです。
暗号化されたデータは、多くの場合、ローカルストレージのデータを暗号化するために使用され、パスワードで生成された暗号化キーを使用することもあります。
認証されたソースからのデータ（認証されたデータ）には、1つまたは複数の受信者のMACコードおよび暗号化された認証キーと共にデータが含まれます。 無制限の数の受信者のメッセージ整合性を保護するために使用されます。
次の記事では、ロシアの暗号化アルゴリズムを使用したエンベロープデータなどのメッセージについて詳しく説明します。
現実のCMS
CMS標準には、現代のITの世界に多くの化身があります-それは以下に基づいています：
- S / MIMEセキュアメール標準（ RFC 3851 ）
- S / MIMEの高度なセキュリティサービス（ RFC 2634 、ところで、複数のカプセル化に基づく追加のCMS属性とトリプルラッピングテクノロジーについて説明します。データに署名してから、暗号化して再度署名する）
- 失効した証明書（ RFC 5940 ）などに関する情報を表示するための拡張形式
電子署名付きメッセージのCMSアイデアの自然な発展は、CMS署名付きメッセージの拡張標準であるCAdES（CMS Advanced Electronic Signature）になりました。
実践する方法は？
ロシアの暗号化アルゴリズムをサポートするCMS / PKCS＃7標準は、パートナーのCIPFによる認定で実装されています。
- CryptoPro CSP Crypto-Pro
- VipNet CSP企業Infotex
- SignalCom CSPまたはSignalComなどのMessage-PRO 。
さらに、ロシアの暗号化を使用したCMS標準は、オープンソースOpenSSLアプリケーションに実装されています。
当社は、 Rutoken Plug- in製品でロシアの暗号化を使用してCMSをサポートしました。 Rutokenプラグインはブラウザでの使用を目的としており、すべての暗号化操作はハードウェア、つまりUSBトークンの「オンボード」で実行されます。