電子署名技術

はじめに

情報システムへの電子署名の導入（暗号アルゴリズムと「資格」の基準、法律63-FZ 、第5条を参照せずに）の導入は、通常、システムで生成された情報フローとドキュメントの整合性と作成者を制御する必要があります。

カッターの下では、電子署名を操作するためのインターフェイスと、電子署名の一般的な形式が説明されています。

一般に受け入れられている用語によると、電子署名は電子文書の必要条件であり、電子文書の完全性の事実を確立し、署名が公開署名キーの所有者に属していることを確認できます。 電子署名は情報の機密性とはまったく関係がないことに注意してください。 つまり、署名された文書はまだ自由に読むことができます。

電子署名は、 非対称暗号方式または公開鍵暗号方式に基づいて実装されます。 非対称暗号化アルゴリズムは、パブリックとプライベートのキーペアを使用します。 秘密鍵は、電子署名（公開）の生成に使用され、検証されます。

電子署名での作業の問題では、署名の公開鍵とそれが直接属する人との間の通信を確立することに特別な注意を払う必要があります。 この問題を解決するには、「 電子署名用の公開鍵の証明書 」（または単に「デジタル証明書」）などがあります。 証明書を発行、検証、失効、管理するには、公開キー基盤が必要です。 公開鍵は電子署名の検証に役立つ識別可能な公開情報のセットではないため、公開鍵とその所有者を比較する問題は、非対称暗号化を使用する場合に最も重要かつ困難な問題の1つです。 また、所有者と直接この情報へのリンクがない場合、攻撃者はいつでも変更することができます。これにより、攻撃者は電子署名を生成し、他の人の電子署名としてそれを渡すことができます。

アプリケーションシステムに電子署名を埋め込む

国家標準または世界標準として受け入れられている暗号化アルゴリズムは、公開されています。 それらの暗号強度は、許容できる時間内に解決できない数学的問題に基づいています。

しかし、暗号化アルゴリズムの実装は、高速性、エラーがないこと、および数学的変換の要件を確実に満たすことを考慮して、資格のある開発者が関与する簡単なタスクではありません。

重要なアプリケーションで電子署名が使用される場合（たとえば、法的に重要なアクションを実行するため）、暗号化アルゴリズムの実装は、セキュリティ要件への準拠のために認証プロセスに必ず合格します。

「西側」世界では、Common Criteriaに準拠するソリューションの認証が広く使用されていますが、ロシアでは、暗号化手段の認証プロセスがロシアのFSBによって実行されています。

さらに、暗号情報保護の手段（CPSI、この用語はロシア連邦で広く使用されています）は、ソフトウェアライブラリから高性能の特殊な腺（Hardware Security Module、HSM）まで、まったく異なる考えを持つことができます。

このタイプの製品の実装と規制が複雑であるため、さまざまなプレーヤーが使用する暗号化情報保護ソリューションの市場が存在します。

さまざまな実装間の互換性、およびアプリケーションソフトウェアへの統合を簡素化することを目的として、暗号情報保護ツールおよび電子署名と直接連携するさまざまな側面に関連するいくつかの標準が開発されました。

暗号情報保護にアクセスするためのインターフェース

現在まで、暗号情報保護を扱うための1つの業界標準と、すべての既知のMicrosoft企業による1つの（実際2つの）独自のインターフェイスが広く使用されています。

PKCS＃11

PKCS＃11（Public-Key Cryptography Standard＃11）は、ハードウェアに実装された暗号情報保護デバイス（スマートカード、HSM、暗号トークン）を操作するためのプラットフォームに依存しないソフトウェアインターフェイスです。 PKCS＃11は、ソフトウェアで実装された暗号化ライブラリにアクセスするために使用される場合があります。

PKCS＃11は、RSA Laboratoriesによって公開されたかなり広範なドキュメントで、暗号化デバイスまたはライブラリを操作するための一連の機能、メカニズム、アルゴリズム、およびそれらのパラメーターについて説明しています。 このドキュメントでは、暗号化関数を呼び出すときにアプリケーションソフトウェアが動作するルールを明確に説明しています。

この標準は、暗号化を使用する多くのオープンソースプロジェクトでサポートされています。 たとえば、Mozilla Firefoxでは、トークン上のSSL / TLSを介した認証用の証明書と秘密キーを保存し、PKCS＃11でそれらを操作できます。

アプリケーションソフトウェアがPKCS＃11を使用する方法を「知っている」場合、SKZIの製造元は、外部の標準で説明されているインターフェイスを公開するソフトウェアライブラリを実装し、必要なSKZIロジックを内部で実装する必要があります。暗号化デバイスを直接使用するか、プログラムで必要な暗号化アルゴリズムを実装します。 この場合、アプリケーションソフトウェアは、必要なライブラリを「ピックアップ」し、標準の推奨事項に従って必要なアクションを実行する必要があります。 これにより、アプリケーションソフトウェアのさまざまなデバイスとライブラリの互換性と、さまざまなシステムでの暗号情報保護システムの透過的な使用が保証されます。



PKCS＃11の唯一の重大な欠点は、公開キー証明書を使用するための推奨事項がないことです。これには、標準に対する独自の拡張の使用、または証明書を使用するための他のツールの使用が含まれます。

Microsoft Crypto API 2.0

Microsoft Windowsオペレーティングシステムは、バージョンに関係なく、特にユーザーデータと企業データのセキュリティを扱うかなり複雑なシステムです。 これらのタスクでは、暗号化が伝統的に広く使用されています。

暗号化機能へのアクセスを統一するために、Microsoftは独自のAPIであるMicrosoft Crypto APIを開発しました。 Crypto API 2.0バージョンが広く普及しています。 Microsoft Crypto APIパラダイムは、いわゆる暗号化プロバイダー、またはロシア語では暗号化プロバイダーの使用に基づいています。



Crypto API仕様では、暗号化プロバイダーライブラリがオペレーティングシステムに提供する必要がある一連の関数、それとの統合方法、および仕様の呼び出しについて説明しています。 したがって、Crypto APIルールに準拠する暗号情報保護ベンダーは、Microsoft Windowsオペレーティングシステムにソリューションを統合することができ、アプリケーションソフトウェアは、統一されたインターフェイスを介して暗号機能にアクセスできます。

さらに、MicrosoftはCrypto APIを介して、証明書の操作、さまざまな種類の署名の生成、キー情報の操作など、アプリケーションタスクの実行を担当するかなり多数の機能を実装しています。また、Crypto APIは、オペレーティングシステムとその内部メカニズム。

しかし、利便性に対する見返りはプラットフォームに依存し、ソリューションをオペレーティングシステムに緊密に統合する必要があります。

Windows Vistaでは、Microsoftは暗号化プログラミングインターフェイスの新しいバージョンであるMicrosoft CNG（Cryptography API：Next Generation）を導入しました。 このインターフェイスは、暗号化プロバイダーではなく、アルゴリズムプロバイダーおよびキー情報ストレージプロバイダーに基づいています。 Windows XPの普及率は依然として非常に高いため、アプリケーションシステムで使用されるCNGはほとんどありません。

独自のインターフェース

標準化されたインターフェイスの存在は、独自のインターフェイスを備えた独自のライブラリの存在を妨げるものではありませんでした。 この例は、独自のルールに従って動作するOpenSSLライブラリです。

PKCS＃11標準では、独自の拡張機能を使用できます。 実際、これらはメーカーによって追加された機能であり、標準には記載されていません。 通常、製造業者によると、デバイスを使用して特定の操作を実行したり、必要な機能を実装したりします。

電子署名形式

暗号化機能にアクセスするための上記のインターフェイスを使用すると、Microsoftが「暗号化プロバイダー」とよく指摘しているように、さまざまな数学的変換の実装に適用できます。

しかし、電子署名を生成および検証するための多くのアルゴリズムがあります。 これらの各アルゴリズムには、開発および検証中に合意する必要がある一連のパラメーターがあります。 さらに、署名を適切な方法で検証するには、証明書が必要です。 これらのパラメータはすべて、アプリケーションシステムで合意するか、署名とともに転送する必要があります。
この問題を解決するために、いくつかの標準も提案されています。

PKCS＃7

PKCS＃7（公開鍵暗号化標準＃7）、またはCMS（暗号化メッセージ構文）は、同じRSA Laboratoriesによって公開およびサポートされている標準であり、暗号化メッセージの構文を説明しています。

PKCS＃7もRFC番号2315として公開されています。

CMS構文は、暗号化メッセージを生成する方法を記述します。その結果、メッセージはメッセージを開き、必要なすべての操作を実行するために完全に自給自足になります。

この目的のために、PKCS＃7には元のメッセージ（オプション）、ハッシュおよび署名アルゴリズム、暗号化アルゴリズムパラメーター、署名時間、電子キー署名証明書、証明書チェーンなどに関する情報が含まれています。

ほとんどのPKCS＃7属性はオプションですが、それらのバインディングはアプリケーションシステムによって決定できます。

それとは別に、PKCS＃7を使用すると、1つのドキュメントの下に複数の署名を入れて、メッセージに必要な情報をすべて保持できることに注意してください。

PKCS＃7の形成と検証は、上記で説明したMicrosoft Crypto APIの暗号化「アドオン」に実装されています。 しかし、フォーマット自体はかなり特殊化されており、そのサポートはネイティブに実装できます。

XML-DSig

W3Cは、署名されたXMLメッセージを作成するためのガイドラインを開発および公開しています。

実際、XML-DSigはPKCS＃7と同じ問題を解決します。 主な違いは、PKCS＃7では、データはANS.1マークアップに従って形成された構造（実際にはバイナリデータ）に格納され、XML-DSigデータはXML署名構文の規則に従ってテキスト形式で格納されることです。処理中。

XML-DSigの範囲は、WebアプリケーションとWebサービスです。

生の署名

署名されたメッセージの送信者に関する情報が最小限であるときに異種システムが相互作用する場合、上記の電子署名形式が必要です。

単一の情報システムのフレームワーク内でやり取りする場合、送信者、使用する暗号化アルゴリズム、およびそれらのパラメーターに関する情報が受信者に知られている場合、「生の」電子署名を使用する方が合理的です。

この場合、実際には、電子署名の意味のみがドキュメントとともに送信されます。 検証のための情報は、中央データベースから受信者によって取得されます。

これにより、任意の形式に従ってメッセージを生成および解析する手順がないため、署名の生成および検証プロセスを大幅に簡素化できます。

おわりに

結論として、ソフトウェアインターフェイスと電子署名形式のいずれかのアプリケーションソフトウェアの使用は、ユーザーに制限や追加要件を課すことなく、このソフトウェアの機能とタスクに対応する必要があることに注意してください。

参照資料

PKCS＃11：暗号化トークンインターフェース標準
暗号化リファレンス。 MSDN
暗号化API：次世代。 MSDN
PKCS＃7：暗号メッセージ構文標準
XML署名の構文と処理（第2版）