JP2004523171A - トランザクション処理システムにおけるメッセージ暗号化及び署名のためのシステム及び方法 - Google Patents

Abstract

【課題】本発明は、トランザクション処理システムにおいて一つのパーティまたは処理から別のパーティまたは処理に送られたメッセージ（２２０）またはメッセージ・バッファ（２２０）のセキュリティ及び信憑性を確保するためにメッセージ-ベース暗号化及びメッセージ-ベースデジタル署名の組合せを利用するシステム及び方法を提供する。
【解決手段】一実施形態では、本発明は、メッセージ・バッファ（２２０）を暗号化する（２２０）ことによって暗号化エンベロープを生成する段階と、デジタル署名でメッセージ・バッファの暗号化されたコンテンツに署名するし段階と、暗号化エンベロープ（２３２）を送信側処理から受信側処理に送信する段階と、受信側処理で暗号化エンベロープを受信する段階と、メッセージ（２２０）を検索するために暗号化エンベロープ（２３２）を解読する段階と、及び暗号化エンベロープ（２３２）からデジタル署名を検索することによって送信側処理の識別を検証する段階と具備する方法を含む。本発明は、中間受信者にメッセージを検査させ、かつ通信されたメッセージ（２３２）の信頼できる認証、機密性、保全性、及び否認を提供する。
【選択図】図６

Description

【技術分野】
【０００１】
本出願は、２００１年２月２２日に出願され、かつその出願が参考文献としてここに採用される、特許出願番号６０/２７１、１０６号の仮出願“SYSTEM AND METHOD FOR MESSAGE ENCRYPTION AND SIGNING IN A TRANSACTION PROCESSING SYSTEM”からの優先権を主張する。
【０００２】
本発明は、一般的にトランザクション処理システムに関し、そして特にシステム及び方法に関する。
【背景技術】
【０００３】
今日の世界における電子通信に対する更に増大する依存性は、係る通信におけるセキュリティ(機密保護)の必要性に対するより大きな重要性を位置付けた。多くの人々は、電子メールまたはｅｍａｉｌのアイデアに通じておりかつ係るｅｍａｉｌを送るときにセキュリティの必要性を容易に認識するが、しかし、コンピュータ間、サーバ間、アプリケーション間、等の電子データ通信を保護する必要性をほとんど理解していない。この状況において、当事者（パーティ）は、人々ではなく、コンピュータ・ソフトウェア・アプリケーションであり、かつそれらの通信は、ｅｍａｉｌではなく、一連の電子メッセージである。メッセージの係る転送または“メッセージング”は、最新トランザクション処理サーバのコア・エレメントであり、その一例は、米国カリフォルニア州サンノゼにある、ＢＥＡ Ｓｙｓｔｅｍｓ、Ｉｎｃ．からのＢＥＡ Ｗｅｂｌｏｇｉｃ及びＢＥＡ Ｔｕｘｅｄｏ製品のシリーズである。
【０００４】
これらのシステムの全ては、セキュア・メッセージの伝送の一般的な必要性を共有する。また、このコンテキストにおけるセキュリティは、以下の機能にも拡大されうる：
認証(Authentication)：一当事者、例えば、クライアント-ベース・ソフトウェアまたはサーバ-ベース・ソフトウェアに対してそれが通信している別の当事者の識別を保証させるための機能。
機密性(Confidentiality)：通信処理中に無許可の当事者への情報の開示を防ぐための機能。
保全性(Integrity)：電子通信またはメッセージ伝送による故意のまたは偶発的な改竄のいずれかを検出するための機能。
否認(Non-repudiation)：一当事者がメッセージを送ることを阻止しかつ後でそれが通信されたメッセージから生起されたことを否定する機能。
【０００５】
従来、これらのセキュリティ・サービスは、推移信頼モデル(transitive trust model)、リアルタイム・ダイレクト・セキュリティ関係(real-time direct security relationship)、またはダイレクト認証モデル(direct authentication model)のいずれかの使用によって部分的に満たされていた。
【０００６】
推移信頼モデルでは、クライアントは、トランザクション処理システム・ゲートウェイ処理に対してそれ自体を認証し、それからゲートウェイ処理は、その他のシステム処理にユーザの識別を確認することによってユーザを“保証する”。これは、ユーザ及びサービスを分散させかつそれでもネットワークを通して容易にアクセス可能にさせるトラストを用いる、ウィンドウズ(Windows)ＮＴにおいて見出されるようなシステムの“シングル・サイン−オン”タイプに類似する。認証、機密性、及び保全性セキュリティ・サービスのインプリメンテーションは、中間システム処理の間の協調に依存する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
より古い種類のクライアント-サーバ・システムにおいて最も一般的に出会う、リアルタイム・ダイレクト認証モデルでは、クライアントは、全てのサーバ側処理とダイレクト・コネクション及びセキュリティ関係を確立する。この特定の認証モデルは、非常にリソース-インテンシブ（資源集約的）であり、かつ大きな構成に対してうまくスケール・アップしない。
【０００８】
上述したこれらのモデルのいずれも増大したメッセージング・セキュリティに対する最新の需要、特に否認特徴に対する要求に完全には応じていない。
【０００９】
本発明は、トランザクション処理システムにおけるメッセージの転送に対するセキュア・システムを生成するために、二つのよく確立された技術-公開キー暗号化及びトランザクション処理を組み合わせる。
【００１０】
トランザクション・サーバ内のセキュリティは、ネットワーキング及び分散コンピューティング技術が発達することにより益々重要になってきている。ユーザ・データ及びミッション-クリティカル・コンピューティング・システムは、非常に魅力的なターゲットであり、かつかなりケーパブルな敵対者からの潜在的な脅威は、現実である。インターネット接続性及び広域企業内イントラネットは、多くのシステムの基本構成部分である同じファシリティを介して侵入に対する基礎を築いた。
【００１１】
主に金融業における、多くのトランザクション・サーバ・カスタマは、プライバシー及び彼らのデータの保全性を保護するために、そしてまたユーザ識別及び責任能力を強化するために、公開キー-ベース・セキュリティを要求していた。メッセージ−ベース暗号化は、顧客データが指定された受信者以外のあらゆる当事者に明らかにされることを防ぐことによってトランザクション・サーバのセキュリティを強化する。二次的利益は、改竄及びリプレイ攻撃に対する保護であり、その理由は、クリア-テキスト・メッセージ・コンテントが利用可能でないときにこれらの攻撃が更に難しいからである。メッセージ-ベース・ディジタル署名は、送信処理にそれの識別を証明させ、かつその証明を特定のメッセージ・バッファに結び付けさせることによってセキュリティを更に強化する。あらゆる第三者は、将来のあらゆる地点において、署名の認証を確認することができる。見逃し改竄は、可能ではない、その理由は、デジタル署名がバッファのコンテンツ全体で計算された暗号的にセキュアなチェックサムを含むからである。また、デジタル署名は、発信マシンのローカル（及び非同期）クロックに基づく、耐改竄タイム・スタンプも含む。アプリケーション・プログラマは、このタイム・スタンプを調べかつリプレイ攻撃を抑止するためにセキュリティ・ポリシーをインプリメントすることができる。
【００１２】
発明者は、公開/秘密キー管理及び分配能力が、強化メッセージ・セキュリティを供給することに対する実行可能手段であることを結論づけた。キー管理の形態は、ドメイン・アドミニストレータ、エンド・ユーザ、及びアプリケーション開発者に可視である。システム・アドミニストレータは、クライアント、サーバ・マシン、及びサーバ・ドメインと対話するゲートウェイ・リンクに対するセキュリティ・ポリシーを設定することを担当する。アドミニストレータが一般的なポリシーを設定する間に、別の人または人々のグループは、セキュリティを管理することを担当しうる：例えば、ユーザ、許可、監査、ポリシー、等。
【００１３】
メッセージ-ベース暗号化及びデジタル署名が、最小のアプリケーション・コード変更でまたはアプリケーション・コード変更なしで、管理パラメータによってイネーブルされかつ制御されることがかなり望ましい。これは、既存のアプリケーションに、完全なアプリケーション・ソフトウェア開発サイクルを実行することなくこれらの機能から直ぐに利益を得られさせる。また、それは、セキュリティ・ラプスに導くアプリケーション・プログラミング・エラーの機会を低減することによってセキュリティを強化する。この要求に取り組むために、セキュリティ・サービスが、ビデオ用デバイス・ドライバまたはディスク格納用ファイル・システムに類似する、“プラットフォーム”サービスのようなオペレーティング・システムによって供給されるべく開始されている。この傾向は、アプリケーション・ソフトウェアと顧客の選択したセキュリティ・ハードウェア/ソフトウェア・プロバイダとの間に明確に規定されたインタフェースを供給することによって多種多様な顧客選択を可能にする。これは、マイクロソフトのウィンドウズ上のクリプトＡＰＩ（ＣｒｙｐｔｏＡＰＩ）、及びインテルのコモン・データ・セキュリティ・アーキテクチャ（Ｃｏｍｍｏｎ Ｄａｔａ Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＤＳＡ））を含みうる。
【００１４】
本発明の特定の進歩は、以下のものを含む：
１．公開キー暗号化及び公開キー・デジタル署名に関するセキュリティ・ポリシーのシステム強制。公開キー特性がアドミニストレータのセキュリティ・ポリシーを批准しない場合には、メッセージは、自動的に拒否されうる。特定のポリシー要件は、例えば、Ａ）少なくとも一つの有効公開キー・デジタル署名がメッセージにアタッチされることを必要とすること；Ｂ）をメッセージが機密性に対して暗号化されることを必要とすること；及びＣ）デジタル署名に関連付けられたタイム・スタンプの許容可能な範囲に制限を設けることを含みうる。
２．公開キー・デジタル署名を自動的に生成するための動作モード。
３．メッセージが配送される前のデジタル署名の自動検証。
４．公開キー暗号化を自動的に実行するための動作モード。
５．解読が失敗した場合の自動拒否を伴う、メッセージの自動解読。
６．残りのデータの機密性を維持すると同時に、システム処理が部分アプリケーション・コンテント・データに基づきメッセージを送ることができるように、部分暗号化を可能にする規定。
７．完全なアプリケーション・コンテント・データに基づくルーティング（経路指定）決定を行うために、メッセージ全体を解読するための一定のシステム処理に対する規定。
８．ディスクで待ち行列に入れられると同時に、アプリケーション・メッセージが暗号化されたまま残るように、高信頼ディスク-ベース・キューイング（待ち行列）による統合。
９．無許可加入者が機密データにアクセスできないように、出版（パブリッシュ）/加入（サブスクライブ）・メッセージングによる統合。
１０．公開キー・デジタル署名及び公開キー暗号化を保存する外部フォーマットにメッセージをエクスポートするための能力。対応インポート・ファシリティは、将来のあらゆる地点における、否認に対して、許可ソフトウェアに署名を解読させかつ検証させる。
１１．システム処理で実行された動作を含んでいる、システムの公開キー機能のカスタマイゼーションを許容するセキュリティ・プロバイダ・インタフェース（ＳＰＩ）。
１２．自動公開キー署名タイム・スタンプ生成及び検証。
１３．トランザクション処理に対する既存のアプリケーション・インタフェース標準と直観的にメッシュする公開キー暗号化及び公開キー・デジタル署名に対する高レベル・プログラミング・インタフェース。
１４．公開キー・アルゴリズム実行のかなりの部分をクライアントのデスクトップ・コンピュータで実行させる分散形処理技法。
【課題を解決するための手段】
【００１５】
一実施形態では、本発明は、トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージのセキュア通信のための方法であって、
暗号化のためにメッセージ・バッファにマークを付ける段階と、デジタル署名の添付のために前記メッセージ・バッファにマークを付ける段階と、前記メッセージ・バッファを暗号化することによって暗号化エンベロープを生成し、かつデジタル署名で前記メッセージ・バッファの暗号化されたコンテンツに署名する段階と、及び前記暗号化エンベロープを送信側処理から受信側処理に送信する段階を具備する方法を含む。
【００１６】
別の実施形態では、本発明は、トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージの秘密通信を検証する方法であって、暗号化エンベロープを送信側処理から受信する段階と、前記暗号化エンベロープを前記受信側処理によって読取可能なメッセージ・バッファ・コンテントにインポートする段階と、前記メッセージを検索するために前記暗号化エンベロープを解読する段階と、及び前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する段階とを具備する方法を含む。
【発明の効果】
【００１７】
本発明の効果は、エンド・ユーザが、トランザクション・サーバ・ファシリティまたはその他のクライアントと、専用の、相互的に認証された、セキュア・インタフェースを有することができることを含む。システム・アドミニストレータ及びシステム・オペレータは、特に会外から別のサーバ・ドメインまたは/ワークステーション・クライアントと対話するときに、増大したシステム・セキュリティから利益を得る。開発者は、データ暗号化及びデジタル署名に対する新しいプログラミング・インタフェースへのアクセスを有する。これらの能力は、セキュリティの問題により以前には実行可能でなかったインターネット・アプリケーションの新しいクラスを可能にしうる。セキュリティ・オフィサー及びセキュリティ・オーディターは、会社のソフトウェア・アプリケーションが会社のセキュリティ・ポリシーを効果的に強制するというより大きな保証を有する。
【実施例】
【００１８】
本発明は、トランザクション・サーバ、アプリケーション・サーバ、及びメッセージング・セキュリティ・システムで使用する多数の公開キー技術強化を画定する。
本発明は、二つの概念：メッセージ-ベース暗号化、及びメッセージ-ベース・デジタル署名を、高信頼でかつセキュアなメッセージング認証システムに一緒に結び付ける。本発明の主要構成部分は、各メッセージを“包むこと”の概念、メッセージ・バッファ、またはメッセージ付きトランザクションのコンテント、に関連付けられた公開/秘密キー及びデジタル署名の使用である。
【００１９】
ユーザまたはアドミニストレーション・アクセスを許容するこのセキュリティ機能の外部形態は、プログラミング・インタフェース、アドミニストレーティブ・パラメータ、及びアドミニストレーティブ・プログラミング・インタフェースを含む。
【００２０】
関連用語、頭辞語及び略語の用語集を参考のために以下に含む。
抽象構文記法１（ＡＳＮ．１）：Ｘ．２０８に規定された、データ・フォーマットを記述するための国際標準化機構（ＩＳＯ）標準。
次世代標準暗号方式（ＡＥＳ）：１２８、１９２、または２５６ビット・キー長による対称暗号化に対する提案米国政府標準。
基本エンコーディング規則（ＢＥＲ）：Ｘ．２０９に規定された、プラットフォーム・アーキテクチャとは独立のＡＳＢ．１自己識別データを表すためのＩＳＯ標準
認証局（ＣＡ）：公開キー証明書を発行するよく知られかつ高信頼のエンティティ。認証局は、ある程度公証人のように、ユーザの現実の識別を立証する。
認証廃棄リスト（ＣＲＬ）：受け入れられるべきでない証明書のリスト。証明書は、ユーザの秘密キーが疑われる場合、またはユーザが組織から去る場合に、一般的に取り消される。
暗号ブロック連鎖（方式）（ＣＢＣ）：前のブロックの暗号化された状態の出力が後続するブロックの暗号化に影響を与えるべくフィードバックされる動作のブロック暗号化モード。
コモン・データ・セキュリティ・アーキテクチャ（ＣＤＳＡ）：オープン、インターオペラブル、クロス・プラットフォーム・セキュリティ・インタフェースに対する業界基準アーキテクチャ。
複合署名状況：全ての添付されたデジタル署名の状況の分析に基づく、バッファの総括署名状況。
クリプトＡＰＩ（ＣｒｙｐｔｏＡＰＩ）：ウィンドウズ・オペレーティング・システムの一部としてインストールされうる暗号サービス供給型セキュリティ・モジュールに対するマイクロソフト・インタフェース。
解読：解読は、暗号化されたデータをそのオリジナル・フォーム（原型）に復元する処理である。
特殊エンコーディング規則（ＤＥＲ）：Ｘ．５０９に規定された、独特でかつ明瞭なファッションの、プラットフォーム・アーキテクチャとは独立のＡＳＮ．１自己識別データを表すためのＩＳＯ標準。
ＤＥＳ暗号化：ＤＥＳは、５６ビット・キー・サイズ対称ブロック暗号化アルゴリズムである。
ＤＳＡ：デジタル署名アルゴリズム。デジタル署名に対して米国政府が提案した標準アルゴリズム。
ＤＳＳ：デジタル署名標準。メッセージ・ダイジェストに対するＳＨＡ-１、及びデジタル署名に対するＤＳＡから構成されている、デジタル署名を計算するために米国政府が提案した標準。
ＥＤＥ：１１２ビット・キーに基づく動作のトリプル-ＤＥＳモード。
暗号化：暗号化は、許可されたユーザによるオリジナル・データへのアクセスを保存すると同時に、不許可の開示を防ぐためにデータをアルゴリズム的に変換する処理である。
国際データ暗号化アルゴリズム（ＩＤＥＡ）：Ａｓｃｏｍ-Ｔｅｃｈ ＡＧによる米国及び欧州で特許になった１２８ビット対称ブロック暗号化アルゴリズム。
キー：キーは、データを暗号化または解読するために用いられる２進数（バイナリ・バリュー）である。キーは、しばしば、しかし必ずしもそうではないが、パスワード・ストリングスから導き出される。
ＬＬＥＬｉｎｋ-レベル暗号化：ネットワーク・リンクにわたるトラフィックを暗号化する、米国カリフォルニア州、サンノセの、ＢＥＡシステム、Ｉｎｃ．からのＴＵＥＤＯ製品に共通な特徴（機能）。暗号化は、データがネットワークに伝送されるちょっと前に実行され、かつ解読は、データが受信されたちょっと後で実行される。
ミドル・アタックの人（Ｍａｎ ｉｎ Ｍｉｄｄｌｅ Ａｔｔａｃｋ）：敵がネットワークにマシンを挿入し、二つの当事者間で全てのメッセージを捕捉し、可能的に変更し、そして再送信するようなアタック。
ＭＤ５：１２８ビット出力を有するメッセージ・ダイジェスト・アルゴリズム。
メッセージ・ダイジェスト：メッセージのコンテンツで計算された固定サイズ・セキュア・ハッシュ値。メッセージ・ダイジェスト・アルゴリズムは、任意のダイジェスト値に対応するメッセージを生成すること、または同じタイジェスト値を有する二つの異なるメッセージを見付けることがかなり難しいという特性を有する。メッセージの一つのビットが変更された場合には、メッセージ・ダイジェスト計算は、かなり高い確率で、異なる結果をもたらす。
否認：原作者を誤って否定することのメッセージ発信者の無資格。
パス・フレーズ：識別を証明するために人間によって通常供給される、英数字及びその他の文字の秘密ストリング。パス・フレーズは、パスワードよりも一般的に長い。
ＰＡＣ：特権属性証明書：種々の資源へのアクセスを許可するための目的で、ユーザに関する役割、レベル、またはグループ・メンバーシップ情報を含む、ログオン・タイムによく用いられる、一時的デジタル証明書。
秘密キー：解読または署名生成のためにキーの所有者によって用いられる公開/秘密キー・ペアの一部。
公開キー：暗号化または署名検証のためにあらゆる人によって用いられる公開/秘密キー・ペアの一部。
公開キー証明書：関連識別情報を伴う公開キーを含んでいるデータ構造。情報は、ユーザの名前、組織、電子メール・アドレス、等、及び、その生成データ、有効期日、発信者ｉｄ、及び通し番号のようなキー特定情報を含みうる。発行認証局は、公開キーと特定のユーザとの間の証明可能かつ改竄防止バインディングを生成するために、公開キー及び関連情報の両方にデジタル的に署名する。
公開/秘密キー暗号化：暗号化のための公開キー、及び解読のための関連するが異なる秘密キーに基づく暗号化技術。
ＲＣ２暗号化：ＲＣ２は、ソフトウェアでインプリメントされたときに良好な性能を有する可変-キー-サイズ対称ブロック暗号化アルゴリズムである。
ＲＣ４暗号化：ＲＣ４は、ソフトウェアでインプリメントされたときに優れた性能を有する可変-キー-サイズ対称ストリーミング暗号化アルゴリズムである。
リプレイ攻撃：メッセージがインターセプトされそれから将来に（後で）システムに再挿入され、不正に再実行されるべく、お金を投入するような動作をもたらすような攻撃。
ＲＳＡ：Ｒｉｖｅｓｔ（リベスト）、Ｓｈａｍｉｒ（シャミール）、及びＡｄｌｅｍａｎ（アルドレマン）-暗号化及びデジタル署名に広く採用された公開キー・アルゴリズムの発明者。ＲＳＡアルゴリズムは、非対称である：秘密キーは、その所有者によって厳密に保持され、同時に対応する公開キーは、広く流布されうる。
ＲＳＡ Ｉｎｃ．：（それに限定されないが“ＲＳＡ”アルゴリズムを含んでいる）多くの暗号化アルゴリズムに対するソフトウェアをランセンスする、Ｓｅｃｕｒｉｔｙ Ｄｙｎａｍｉｃｓ Ｃｏｒｐｏｒａｔｉｏｎの子会社。
シール：プライバシーのためにメッセージを暗号化する。
セッション・キー：セッション・キーは、一つのセッション（ネットワーク接続）の持続（存続）時間に対してだけ生成されかつ用いられる一時的対称暗号化キーである。
ＳＨＡ-１：１６０ビット出力を有するメッセージ・ダイジェスト・アルゴリズム。
署名（サイン）：原作者認証及びメッセージ保全保護に対してメッセージにデジタル署名を添付する。
スマートカード：組込み型マイクロプロセッサ及び不揮発性メモリを含む、通常クレジット・カードと同じ大きさの、物理的装置。スマートカードは、認証、暗号化動作をよく実行し、かつ秘密キー及び証明書のような識別情報を保持する。
セキュリティ・サポート・プロバイダ・インタフェース（ＳＳＰＩ）：ウィンドウズ・セキュリティと対話するためのマイクロソフト・プログラミング・インタフェース。
対称キー暗号化：同じキーが暗号化及び解読の両方を実行する通常の暗号化技術。
二因子認証：（スマートカードまたは指紋のような）物理的エンティティ並びに（パスワードまたはピン・コードのような）秘密の所有を必要とする認証の強力な形式。
Ｘ．５０９：公開キー証明書フォーマット及び関連オペレーショナル・プロトコルに対する国際標準化機構仕様。第３版は、特定用途向け拡張を提供する。
【００２１】
ここで用いられるように用語“トランザクション・サーバ”は、クライアント、サービスまたは別のサーバとのトランザクション、または通信を実行するあらゆるコンピュータ・サーバを示すために用いられる。トランザクション・サーバは、必ずしも物理的ホスト・コンピュータである必要はないが、単にコンピュータ・システムまたは分散形ネットワークの多くの一つとしておそらく実行されるサーバ・ソフトウェア・アプリケーションでありうる。トランザクション・サーバは、メッセージング処理全体の１つのパーティと考えられうる-それは、一人の人間が別の人々に郵便を送信しかつそれらから受信するように、メッセージをその他のパーティに送信しかつそれらから受信する。この類比における重要な違いは、人々は、分離されかつ異なる電子メールを一般的に送信し、反対にトランザクション・サーバは、メッセージ・バッファのコンテンツをよく送信しかつ受信し、かつ連続ベースでそれを行いうるということである。そのように、メッセージ・バッファは、電子メール・パッケージのような正確にパッケージされかつ異なるデータのセットを含みえない。この理由でトランザクション・サーバは、メッセージ・バッファのセキュリティ通信を取り扱うためにそれら自身の専用システムを必要とする。
【００２２】
これは、秘密/公開キー暗号化、及び証明書署名の使用を通して、本発明が主な目標とする分野である。公開キー-ベース・セキュリティは、トランザクション・データのプライバシー及び保全性を保護し、かつユーザ識別及び責任能力を増強するために用いることができる。メッセージ-ベース暗号化は、指定された受信者以外のあらゆるパーティにデータが漏らされることを防ぐことによってトランザクション・サーバのセキュリティを強化する。暗号化の補助的利益は、改竄及びリプレイ攻撃に対する保護であり、なぜならばこれらの攻撃は、クリア-テキスト・メッセージ・コンテントが利用可能でないときにより難しいからである。メッセージ-ベース・デジタル署名は、送信処理に、受信者に対してその識別を証明させ、かつ特定のメッセージ・バッファに対してその証明をバインドさせることによってトランザクション・セキュリティを更に強化する。サード・パーティまたは仲介者は、署名の信憑性を次いで検証することができる。改竄は、容易に検出される、なぜならばデジタル署名は、バッファのコンテンツ全体で計算された暗号的にセキュアなチェックサムを含むからである。また、デジタル署名は、発信マシンのローカル・クロックに基づく、耐改竄タイム・スタンプを含みうる。アプリケーションは、このタイム・スタンプを検査しかつリプレイ攻撃を抑止するためにセキュリティ・ポリシーをインプリメントすることができる。
【００２３】
それゆえに公開/秘密キー・マネージメント及び分散能力は、強化メッセージ・セキュリティを供給することに対する実行可能な手段である。用いられるインプリメンテーションにより、キー・マネージメントの形態は、トランザクション・サーバまたはドメイン・アドミニストレータに対して、エンド・ユーザに対して、及びアプリケーション開発者に対して可視にすることができる。一般的に、システム・アドミニストレータは、クライアント、サーバ・マシン、及びそれらのサーバ・ドメインと対話するゲートウェイ・リンクに対するセキュリティ・ポリシーを設定する役目を担う。アドミニストレータが一般的なポリシーを設定する間、別の人または人々のグループは、セキュリティを管理する役目を担う：例えば、ユーザ、許可、監査、ポリシー、等。これらの必要性に適応させるために、本発明は、メッセージ-ベース暗号化及びデジタル署名を、最小のアプリケーション・コード変更またはアプリケーション・コード変更なしで、アドミニストレーティブ・パラメータによってイネーブルさせかつ制御させる。これは、既存のアプリケーションに、完全なアプリケーション・ソフトウェア開発サイクルを行うことなくこれらの機能から直ぐに利益をもたらさせる。本発明の実施形態は、アクセス及び統合の容易さが利用可能である、標準プラットフォーム・セキュリティＡＰＩｓを支援する。
【００２４】
図１は、公開キー１０及び秘密キー２０の記号的または絵的表現の図を示す。図１に示した記号は、本発明を説明することを容易にするためにここに示した公開及び秘密キーの単に記号的または絵的表現である。実際のキーは、ここでそれらを表すために用いた記号で表現されないことは、当業者にとって明らかであろう。公開/秘密キー・アルゴリズム（ときどき単に“公開キー・アルゴリズム”として示す）は、対応する公開キーが広く普及されると同時に、秘密キーがその所有者によって厳密に保持されるような非対称アルゴリズムを用いる、ＲＳＡ公開キー暗号化のようなシステムを含む。それゆえに秘密キーは、解読または署名生成に対してキーの所有者によって用いられる公開/秘密キー・ペアの一部である。公開キーは、暗号化または署名認証に対して所有者以外のあらゆる人によって用いられる公開/秘密キー・ペアの一部である。
【００２５】
図２は、デジタル証明書３０の記号的または絵的表現の図を示す。上述した公開/秘密キーと同様に、図２に示した証明書は、本発明を説明することを容易にするためにここに示した単に記号的または絵的表現である。実際の証明書は、図示した各構成部分を有することを必要としないし、またはそれらに限定されないし、或いは構成部分が図２に示したように分配されることを必要としない。証明書は、一般的に、関連識別情報を伴う公開キーを含んでいるデータ構造である。情報は、ユーザの名前、組織、電子メール・アドレス、等、及びその生成データ、有効期日、発行者ｉｄ、及び通し番号のようなキー特定情報を含みうる。発行認証局は、公開キーと特定ユーザとの間に検証可能かつ耐改竄バインディングを生成するために、公開キー及び関連情報の両方にデジタル的に署名する。図２に示すように、デジタル証明書は、ユーザ識別特性３１、割当証明書通し番号３２、発効日３３、満了日３４、証明書発行者識別３５、及びユーザの公開キー１０のコピーのような素子（エレメント）を含みうる。
【００２６】
図３は、デジタル証明書３０を生成するために公開キー１０がユーザ識別１２及びデジタル署名１４とマージ（併合）されるときのデジタル証明書の生成を示す。
【００２７】
図４は、証明書を生成するために用いられるステップを示す。図４のフローチャートに示すように、送信側パーティは、送信者の公開キーをまず検索し（ステップ２００）、それを送信側パーティの識別子と組合せ（ステップ２０２）かつデジタル署名と組合せて（ステップ２０４）デジタル証明書を生成する（ステップ２０６）。
メッセージまたはメッセージ・バッファ暗号化
【００２８】
メッセージ暗号化は、私設（プライベート）通信を可能にすることによってトランザクション・サーバ・セキュリティを強化する。データ・プライバシーは、会社間または会社と一般公衆との間のいずれかで、インターネット上でデータを移送するほとんどのアプリケーションに対して重要であると考えられる。また、安全でない内部ネットワーク上に配置されたアプリケーションに対しても重要である。また、メッセージ暗号化は、メッセージ保全性を確保することを支援する、なぜならばコンテンツが隠蔽されたときに攻撃者がメッセージを変更することがより難しいからである。ここの開示されたメッセージ-ベース暗号化機能は、公開キー暗号化技術を用いているデータ・プライバシーを提供する。メッセージ・バッファは、“オパーク（不透明）”デジタル・エンベロープ内にシールされて、指定された受信者だけがそれらを読み取りうる。プライベート・メッセージを交換するために二つの通信しているパーティが予め設定された共通の秘密を有することを必要としないし、リアルタイムで信頼できるサード・パーティに相談することを必要としない。メッセージ-ベース暗号化の適用範囲は、“エンド−トゥ−エンド”である。これは、メッセージが、それが発信処理のちょっと前に暗号化され、かつそれが最終目的処理によって受信されるまで暗号化されたままであるということを意味する。それは、オペレーティング・システム・メッセージ・キュー、システム処理、ディスク-ベース・キュー、及びサーバ間ネットワーク・リンクにわたるネットワーク伝送中を含んでいる、全ての中間通過点でオパークである。暗号化は、処理境界を横切るときに実行される。ネットワーク形通信とマシン内通信との間に違いは存在しない。
【００２９】
メッセージ・バッファをシールすることは、３つのステップを含む：
まず、ターゲット受信者の識別を識別することが必要である。このターゲット受信者だけがメッセージのコンテンツへのアクセスを有する。ターゲットは、クライアント、特定のサービス、サーバ・グループ、ゲートウェイ・グループ、特定のサーバ・マシン、またはサーバのドメイン全体でありうる。暗号化及びシーリング処理は、たぶん受信者-特定ベースで、システムによって自動的に取り扱われる処理、または必要に応じたベースで単に特定することができる処理として特定することができる。
第２のステップは、暗号化キーを特定のバッファに関連付けることである。
最後のステップは、メッセージ・バッファの実際の暗号化、及び指定受信者にメッセージを解読できるようにするデジタル暗号化エンベロープの添付である。これは、バッファが発信処理の外側に送信されようとしているちょっと前に行われる。“シールされた”バッファが二度以上送信される場合には、新しい暗号化処理がその度に実行される。これは、バッファをシールすることの願望が登録された後でバッファを変更させる。
【００３０】
図５は、本発明の一実施形態によるメッセージ暗号化処理の略図を示す。図５に示すようにメッセージ（またはメッセージ・バッファのコンテンツ）４０は、暗号化されたメッセージ６０を生成するために、メッセージ・キー５０と組み合わされる。メッセージ・キーは、あらゆる多くの方法で生成されうるが、一実施形態では各メッセージに対して実質的に異なるメッセージ・キーを生成するために擬似乱数発生器を用いて生成される。また、メッセージ及びメッセージ・キーは、解読キー７０を生成するために用いられる。同時に、受信者のデジタル証明書３１は、受信者の公開キー１１を検索するために用いられ、次いで公開キー１１は、暗号化エンベロープ８０を形成するために、解読キー７０及び暗号化されたメッセージ６０と組合せることができる。次いで、暗号化されたメッセージ・バッファを含む、暗号化エンベロープは、受信側パーティまたは受信者に送信される。
【００３１】
図６は、メッセージ暗号化処理のフローチャートを示す。ステップ２２０では、送信側パーティは、メッセージ・バッファを生成する。これは、メッセージ・キーと組合され（ステップ２２２）暗号化されたメッセージ・バッファを生成する（ステップ２２４）。同時に、送信側パーティは、受信者のデジタル証明書を検索し（ステップ２２６）、かつそれから受信者の公開キーを決定する（ステップ２２８）。次いで解読キーは、この公開キー及びステップ２２２で先に生成されたメッセージ・キーを用いてステップ２３０で生成することができる。次いで送信者は、暗号化されたメッセージ・バッファ、及び解読キーの両方を含んでいる暗号化エンベロープを準備する（ステップ２３２）。
【００３２】
図７は、本発明の一実施形態によるメッセージ解読処理の略図を示す。図７に示すように受信側パーティは、暗号化エンベロープ８０を受信する。受信者秘密キー２１は、エンベロープを開封しかつ解読キー７０を検索するために用いられる。次いでこの解読キーは、暗号化されたメッセージ６０をアンロックしかつオリジナル・メッセージまたはメッセージ・バッファ４０を生成するために用いることができる。
【００３３】
図８は、メッセージ解読処理のフローチャートを示す。ステップ２４０では受信側パーティは、暗号化エンベロープ内の、暗号化されたメッセージ、またはメッセージ・バッファのコンテンツを受信する。受信者は、エンベロープを開封し（ステップ２４２）かつ解読キーを検索するために（ステップ２４４）秘密キーを用いる。次いで、暗号化されたメッセージまたはメッセージ・バッファが抽出され（ステップ２４６）、かつ解読キーがそれを解読するために用いられ、オリジナル・メッセージを形成する（ステップ２４８）。
【００３４】
図９は、本発明の一実施形態によるメッセージ暗号化及び解読処理の概略である。図５に示すように、送信者の端ではメッセージ（またはメッセージ・バッファのコンテンツ）４０は、暗号化されたメッセージ６０を生成するために、メッセージ・キー５０と組合される。メッセージ・キーは、あらゆる多くの方法で生成されうるが一実施形態では各メッセージに対して実質的に異なるメッセージ・キーを生成するために擬似乱数発生器を用いて生成される。また、メッセージ及びメッセージ・キーは、解読キー７０を生成するために用いられる。同時に受信者のデジタル証明書３１は、受信者の公開キー１１を検索するために用いられ、次いで公開キー１１は、暗号化エンベロープ８０を形成するために、解読キー７０及び暗号化されたメッセージ６０と組合せることができる。次いで、暗号化されたメッセージ・バッファを含んでいる、暗号化エンベロープは、受信側パーティまたは受信者に送信される。受信者の端では、受信側パーティは、暗号化エンベロープ８０を受信する。受信者秘密キー２１は、エンベロープを開封しかつ解読キー７０を検索するために用いられる。次いでこの解読キーは、暗号化されたメッセージ６０をアンロックしかつオリジナル・メッセージまたはメッセージ・バッファ４０を生成するために用いることができる。図９によって記述された処理は、図６及び８に先に図示しかつ記述したそれらのステップの組合せと考えられうる、即ち、送信側パーティは、メッセージ・バッファを生成する。これは、暗号化メッセージ・バッファを生成するためにメッセージ・キーと組合される。同時に、送信側パーティは、受信者のデジタル証明書を検索し、かつ公開キーをそれから決定する。次いで解読キーは、この公開キー及び先に生成されたメッセージ・キーを用いて生成することができる。次いで送信者は、暗号化されたメッセージ・バッファ、及び解読キーの両方を含んでいる暗号化エンベロープを準備する。受信者は、暗号化エンベロープ内の、暗号化されたメッセージ、またはメッセージ・バッファのコンテンツを受信する。受信者は、エンベロープを開封しかつ解読キーを検索するために秘密キーを用いる。次いで、暗号化されたメッセージまたはメッセージ・バッファは、抽出され、かつ解読キーは、それを解読するために用いられ、オリジナル・メッセージを形成する。
【００３５】
メッセージまたはメッセージ・バッファ署名
メッセージ-ベース・デジタル署名は、メッセージ発信者にその識別を証明させ、かつその証明を特定のメッセージ・バッファにバインドさせることによってトランザクション・サーバ・セキュリティを強化する。相互的認証形でかつ耐改竄通信は、会社間または会社と大衆との間のいずれかで、インターネット上でデータを移送するほとんどのアプリケーションに対して重要であると考えられる。また、安全でない内部ネットワーク上に配置されたアプリケーションに対して重要である。この認証及び保全性チェッキングの適用範囲は、メッセージ・バッファがそれが発信処理から離れたときからそれが目的処理で受信されるときまで保護されるという点で、“エンド-トゥ-エンド”と考えられうる。この方法で、メッセージは、一時的メッセージ・キュー、ディスク-ベース・キュー、システム処理、サーバ間ネットワーク・リンク上の伝送、等を含んでいる、全ての中間通過点で保護される。本発明の一実施形態では、発信側ユーザは、メッセージ・バッファに署名する。次いで、署名は、単にメッセージ・エンベロープに注目することにより仲介者または最終ユーザまたはアプリケーションによって後で読み取ることができる。ユーザは、トランザクション・サーバ自体を用いている人でありうるか、または同様にユーザ・アプリケーション、または別のアプリケーションでありうる。署名は、メッセージ・バッファのコンテンツの暗号的に安全なチェックサムを含む。メッセージ・バッファへのアクセスを有するあらゆるパーティは、発信側ユーザの署名が認証され、かつメッセージ・バッファ・コンテンツが変更されていないということを検証しうる。サード・パーティによる時間独立認証は、否認として知られた特性を提供する。これは、発信者は、原作者を後で否定するかまたはメッセージが変更されていたことを主張することができないということを意味する。
【００３６】
メッセージ署名者のローカル・クロックに基づく、タイム・スタンプを署名に添付することができる。タイム・スタンプは、チェックサム計算において認証された属性として含まれるので、タイム・スタンプ値による改竄は、署名が検証されるときに検出される。署名タイム・スタンプは、非同期クロックに基づきうるし、そのような場合には、特に署名がＰＣまたはパーソナル・ワークステーションで生成される場合には、それは完全には信頼することができない。しかしながら、この特徴は、サーバが、あまりにも古いかまたは将来においてあまりにも先のタイム・スタンプにより要求を拒否することを選択しうることにおいて有用である。これは、リプレイ攻撃に対する保護の尺度を提供する。
【００３７】
署名は、処理境界を横切るときに生成されかつ検証される。ネットワーク通信とマシン間通信との間に違いはない。
【００３８】
バッファを署名することは、３つのステップを含む：
第１に、署名パーティは、秘密署名キーへのアクセスを有していなければならない。このキーは、高度に保護され、かつその所有は、署名パーティの識別を所有することに等しい。
第２に、バッファに署名するための要望または設定、および関連署名パラメータは、示されかつ記憶される。これは、システムによってまたはメッセージ・バッファ署名機能への呼出し（コール）を介して自動的に取り扱うことができる。署名パラメータは、後での使用に対して記憶されかつバッファに関連付けられる。
最後のステップは、実際の署名生成であり、バッファが発信元処理から外部に伝送されそうなころにはいつでも自動的実行される。“署名された”バッファが二度以上伝送される場合には、新しい署名が各通信に対して生成される。これは、バッファを、それに署名することの要望が登録された後で変更させる
【００３９】
図１０は、本発明の一実施形態によるデジタル署名生成処理の略図を示す。図９に示すように、メッセージ４０が生成され、かつメッセージ４０からメッセージ・ダイジェスト９０が生成される。このメッセージ・ダイジェストは、メッセージ署名１４を生成するために送信者２０の秘密キーと組合される。
【００４０】
これを行うために用いた処理を図１１に示す。ステップ２６０では、送信側パーティは、受信者に送信するためにメッセージ・バッファを準備し、メッセージ・ダイジェストが生成され（ステップ２６２）、そして送信側パーティの秘密キーが検索される（ステップ２６４）。秘密キーは、このメッセージに対するデジタル署名を生成するためにステップ２６６でメッセージ・ダイジェストと組合される。次いでデジタル署名は、受信側パーティに、ステップ２６８で、メッセージと一緒に送信される。
【００４１】
図１２は、本発明の一実施形態によるデジタル署名認証処理の略図を示す。図１１に示したように、メッセージ４０は、メッセージ・ダイジェスト９０を生成するために用いられる。同時に、メッセージ送信者の妥当性を決定するために送信者証明書３０は、送信者公開キー１０を検索するために用いられる。公開キーは、メッセージ・ダイジェスト９１の別のバージョンを決定するためにメッセージ署名１４と組合される。メッセージ・ダイジェスト９０とメッセージ・ダイジェスト９１が同じであることが分かった場合には、メッセージは、有効であると考えられかつ実際に識別された送信者から送信される。
【００４２】
図１３は、デジタル署名認証処理のフローチャートを示す。ステップ２８０において、受信側パーティは、署名されたメッセージを受信する。メッセージ・ダイジェストＡが生成される（ステップ２８２）。同時に受信者は、送信側パーティの証明書を読み（ステップ２８４）、送信者の公開キーを決定する（ステップ２８６）。次いで、受信者は、公開キー及びメッセージ署名を用いることによってメッセージ・ダイジェストの別のバージョンを生成しうる（ステップ２８８）。ステップ２９０においてメッセージ・ダイジェストＡ及びメッセージ・ダイジェストＢが比較され、かつそれらが同じであることが分かった場合には、メッセージは、正当識別送信者から到着したと考えられる（ステップ２９２）。それらが異なる場合には、送信側パーティの署名、即ちその識別は無効である。
【００４３】
インプリメンテーション詳細
以下のセクションは、本発明の実施形態で用いることができる特定のメッセージ・バッファ暗号化及びデジタル署名インプリメンテーションを詳述する。本発明が以下に記述する特定のインプリメンテーションに限定されないが、本発明の精神及び適用範囲内でその他のインプリメンテーションが開発されうるということは、当業者にとって明らかであろう。
【００４４】
メッセージ-ベース暗号化
メッセージ-ベース・データ暗号化は、プライベート通信をイネーブルすることによってトランザクション・サーバ・セキュリティを強化する。データ・プライバシーは、会社間または会社と公衆との間のいずれかで、インターネット上でデータを移送するほとんどのアプリケーションに対して重要であると考えられる。また、それは、安全ではない内部ネットワーク上に配置されたアプリケーションに対しても重要である。
【００４５】
また、メッセージ-ベース・データ暗号化は、メッセージ保全性を確保することを助ける、なぜならばコンテンツが隠蔽されたときにアタッカーがメッセージを変更することは、より難しいからである。
【００４６】
ここの開示されたメッセージ-ベース・データ暗号化機能は、公開キー暗号化技術を用いているデータ・プライバシーを提供する。メッセージ・バッファは、“オパーク”デジタル・エンベロープ内にシールされて、指定された受信者だけがそれらを読みうる。二つの通信しているパーティは、秘密メッセージを交換するために予め確立された共有の秘密を有することを必要としないし、リアルタイムで信頼できるサード・パーティに相談することも必要としない。
【００４７】
メッセージ-ベース・データ暗号化の適用範囲は、“エンド-トゥ-エンド”である。これは、メッセージがそれが発信元処理を離れるちょっと前に暗号化され、かつそれが最終目的処理によって受信されるまで暗号化されたままであるということを意味する。それは、オペレーティング・システム・メッセージ・キュー、システム処理、ディスク-ベース・キューを含む、全ての中間通過点において、及びサーバ間ネットワーク・リンク上でのネットワーク伝送中でオパークである。
【００４８】
暗号化は、処理境界を横切るときに実行される。ネットワーク通信とマシン間通信との間に違いは存在しない。
【００４９】
メッセージ・バッファをシールすることは、３つのステップを含む：
第１に、目標受信者の身分を識別することが必要である。この目標受信者だけがメッセージのコンテンツへのアクセスを有する。目標は、クライアント、特定のサービス、サーバ・グループ、ゲートウェイ・グループ、特定のサーバ・マシン、またはサーバのドメイン全体でありうる。目標受信者は、タイプＴＰＫＥＹ＿ＥＮＣＲＹＰＴ（離散暗号化及びシールに対して）またはＴＰＫＥＹ＿ＡＵＴＯＥＮＣＲＹＰＴ（自動暗号化及びシールに対して）のキーによって表される。
第２のステップは、暗号化キーを特定のバッファに関連付けることである。これは、ＴＰＫＥＹ＿ＡＵＴＯＥＮＣＲＹＰＴキーの場合に自動的に、またはＴＰＫＥＹ＿ＥＮＣＲＹＰＴキーの場合にはｔｐｓｅａｌ（）を介して明示的に生じる。
最終ステップは、メッセージ・バッファの実際の暗号化、及び指定受信者がメッセージを解読することができるようにするデジタル暗号化エンベロープの添付である。これは、バッファが発信元処理の外側に伝送されようとする少し前に実行される。“シールされた”バッファが二度以上伝送される場合には、新しい暗号化処理がその度に実行される。これは、バッファを、それをシールすることの要望が登録された後に変更させる。
【００５０】
一実施形態においてトランザクション・サーバは、
４０から１２８ビットのキー・サイズ・レンジを有する、ＲＣ２、可変キー-サイズ・ブロック・サイファー。
ＣＢＣモードで実行される、ＤＥＳ、５６ビット・ブロック・サイファー。
を含んでいるメッセージ・コンテンツのバルク暗号化に対して様々なアルゴリズムを支持する。
ＥＤＥモードで実行される、１４．ＴｒｉｐｌｅＤＥＳ、１１２-ビット・ブロック・サイファー。本発明の精神及び適用範囲内に残っている間、その他の暗号化アルゴリズムを用いうる。暗号化強度は、キー特性ＥＮＣＲＹＰＴ＿ＢＩＴＳによって制御され、かつアルゴリズムは、キー特性ＥＮＣＲＹＰＴ＿ＡＬＧによって制御される。アプリケーションは、ｔｐｋｅｙ＿ｇｅｔｉｎｆｏ（）を呼出すことによってキー特性を照会することができ、かつｔｐｋｅｙ＿ｓｅｔｉｎｆｏ（）をコールすることによってキー特性を設定することを試みることができる。
【００５１】
キー特性が、例えば、ライセンシング制限により、利用不可能である暗号化アルゴリズムまたはキー長を特定する場合には、そのキーで実行された暗号化動作は、失敗するであろう。
【００５２】
固定キー長を有するアルゴリズムがＥＮＣＲＹＰＴ＿ＡＬＧに設定されたときには、ＥＮＣＲＹＰＴ＿ＢＩＴＳキー特性は、適合すべく自動的に調整される。
【００５３】
メッセージ受信者が一定レベルの暗号化強度を検証することを必要とする場合には、キー・ハンドルを得るために受信したメッセージのｔｐｅｎｖｅｌｏｐｅ（）をコールすることが可能であり、それからｔｐｋｅｙ＿ｇｅｔｉｎｆｏ（）を介して暗号化アルゴリズム詳細を取得することが可能である。
【００５４】
二つ以上のデジタル暗号化エンベロープをメッセージ・バッファに関連付けることができる。これは、複数のパーティに、異なる秘密キーで、暗号化されたメッセージを受信させかつ解読させる。
【００５５】
暗号化エンベロープがｔｐｓｅａｌ（）を介して添付される一時的順番は、維持され、かつｔｐｅｎｖｅｌｏｐｅ（）によって報告することができる。ＴＰＫＥＹ＿ＡＵＴＯＥＮＣＲＹＰＴキーから、メッセージ・バッファに自動的に関連付けられた暗号化エンベロープは、明示的に要求された受信者の後に添付される。これらの自動的に生成された暗号化エンベロープの相対的な順番は、不確定である。ｔｐｅｎｖｅｌｏｐｅ（）によって報告された署名及び暗号化エンベロープの相対的順番は、不確定である。
【００５６】
別の受信者による追加メッセージ・サイズ・オーバーヘッドは、メッセージ・バッファのデータ・コンテント・サイズに無関係である。特に、メッセージが複数の受信者に対して暗号化されるときには、バッファのコンテンツの二つ以上の暗号化されたコピーを生成することは許容できない。
【００５７】
いくつかの暗号化エンベロープがメッセージ・バッファに関連付けられる場合には、それらは、バルク・データ暗号化アルゴリズム及びバルク・データ暗号化アルゴリズムのキー・サイズに一致しなければならない。
【００５８】
バッファが出力パラメータとして、ＡＴＭＩインタフェースのようなアプリケーション・インタフェースにパスされる場合には、先に添付された暗号化エンベロープ情報は、削除される。これは、ペンディング・シール、またはバッファの先の使用からのシールを含む。暗号化シール情報の新しいセットは、動作がうまく完了した後で、新しいバッファ・コンテントに関連付けられうる。
【００５９】
バッファが、例えばｔｐａｃａｌｌ（）を通して、入力パラメータとしてアプリケーション・インタフェースにパスされた場合には、先に添付された暗号化シール情報は無視されかつ破棄される。例えば、サーバ処理が入力として暗号化されたバッファを受信した場合には、サーバ処理へのその伝送に関連した暗号化シール情報が添付されかつｔｐｅｎｖｅｌｏｐｅ（）を介して試験のために利用可能である。しかしながら、バッファがサーバによって再伝送された場合には、それは、これらの受信者に対して暗号化されない。それは、サーバ自体によってなされたｔｐｓｅａｌ（）コールによって特定されたような、ペンディング・シールを有する新しい受信者に対してだけ暗号化される。これは、サーバの変更ではなく、オリジナル・メッセージだけを受信することが許可されたパーティへの情報の可能な漏洩を防ぐ。
【００６０】
暗号化されたバッファに対する具体化された(externalized)フォーマットは、暗号化されたデータの“通り抜け”、及び暗号化されたバッファの長期記憶を可能にする。
【００６１】
ｔｐｅｘｐｏｒｔ（）関数は、関連デジタル署名または暗号化エンベロープを含んでいる、メッセージ・バッファの具体化された表現を生成する。バッファは、暗号化及びデジタル署名処理を含んでいる、アプリケーション・インタフェースによってあたかも別の処理に伝送されたかのように処理される。ｔｐｉｍｐｏｒｔ（）関数は、具体化された表現をメッセージ・バッファに戻すように変換し、必要ならば解読及び署名認証を実行する。
【００６２】
具体化されたバッファＰＫＣＳ-７フォーマットで記憶される。また、ｔｐｅｘｐｏｒｔ（）及びｔｐｉｍｐｏｒｔ（）は、バッファの印刷可能なストリング表現が望ましい場合には、ＰＫＣ−７データのベース６４コード化を選択的に生成する/受け入れることができる。
【００６３】
ｔｐｅｎｖｅｌｏｐｅ（）関数は、メッセージ・バッファの添付された暗号化エンベロープに関する情報を戻す。
【００６４】
発信元処理において、ｔｐｓｅａｌ（）によって登録された暗号化要求は、記憶されかつメッセージに関連付けられる。これらの暗号化エンベロープは、状態ＴＰＳＥＡＬ＿ＰＥＮＤＩＮＧを有するｔｐｅｎｖｅｌｏｐｅ（）によって報告される。また、ＴＰＫＥＹ＿ＡＵＴＯＥＮＣＲＹＰＴキーからもたらされるペンディング暗号化エンベロープは、ＴＰＳＥＡＬ＿ＰＥＮＤＩＮＧ情報のｔｐｅｎｖｅｌｏｐｅ（）によって報告される。しかしながら、これらの暗号化エンベロープは、発信元処理がメッセージが実際に送信される前に自動暗号化キーを閉じた場合には添付されない。
【００６５】
受信処理において、発信者によって添付された暗号化エンベロープは、状態ＴＰＳＥＡＬ＿ＯＫを有するｔｐｅｎｖｅｌｏｐｅ（）によって報告される。暗号化エンベロープに関連付けられた公開暗号化キーは、ｔｐｅｎｖｅｌｏｐｅ（）によって戻される。このキーを用いて、事実上、バルク・データ暗号化アルゴリズムまたはバルク・データ暗号化ビット・サイズのようなものであった、暗号化パラメータを問合せうる。暗号化エンベロープは、それらに関連付けられたタイム・スタンプを有していない。
【００６６】
自動暗号化は、処理が行わなければならない関数コールの数を低減する。また、それは、プログラミング・エラーにより、メッセージが暗号化なしで伝送される可能性を低減することによってセキュリティを強化する。
【００６７】
暗号化されたメッセージ・バッファは、それがトランザクション処理に入力するときに自動的に解読することができる。これは、クライアント及びサーバ処理、及びメッセージのコンテンツへのアクセスを必要とする一定のシステム処理を含む。システム処理がメッセージのコンテンツを読むことなく、通り抜けコンジットとして動作している場合には、それは解読されない。
【００６８】
自動解読がうまくいくためには、受信側処理は、添付された暗号化エンベロープの一つに対応している解読キー（タイプＴＰＫＥ＿ＤＥＣＲＹＰＴ）を開らいていなければならない。
【００６９】
解読を可能にするために、処理は、目標プリンシパル(principal)の識別の下で動作するためのその権利を提供しかつプリンシパルの秘密キーにアクセスしなければならない。証明の一つの形式は、秘密パス語句（フレーズ）またはパスワードを供給することである。証明必要条件は、セキュリティ・プロバイダにより、変わりうる。
【００７０】
サービスは、アドミニストレーティブ・ポリシーに基づき、全ての入力要求メッセージが暗号化されるということを要求しうる。このポリシーが発効されている場合には、暗号化されていない入力されるサービス要求メッセージは、受け入れられない。
【００７１】
サービスは、ｔｐｃｏｎｎｅｃｔ（）またはｔｐｓｅｎｄ（）を介して送信された、全ての入力される会話的メッセージが、アドミニストレーティブ・ポリシーに基づき、暗号化されるということを要求しうる。このポリシーが発効されている場合には、入力される暗号化されていないサービス要求メッセージは、受け入れられない。
【００７２】
サブシステム及びゲートウェイ処理のあるものは、アドミニストレーティブ・ポリシーに基づき、全ての入力されるイベント・ポスティング・メッセージに対して暗号化を必要としうる。このポリシーが発効されている場合には、暗号化されていない入力されるポスティング・バッファは、受け入れられない。
【００７３】
メッセージ・バッファが署名されかつ暗号化されることが可能である。デジタル署名の数とメッセージ・バッファに関連付けられた暗号化エンベロープの数との間に要求される関係は存在しない。療法の処理がメッセージ・バッファで実行されるときに、暗号化されていないデータに、署名が最初に生成される。次いで、添付された署名の数及び署名パーティの識別は、暗号化エンベロープによって隠蔽される。
【００７４】
署名認証は、メッセージが署名されかつシールされたときに潜在的にさらに難しい。適切な解読キーは、署名が検証されうる前にメッセージ・データへアクセスすることが利用可能でなければならない。これは、署名要求に関してシステム・ポリシーを強制するためにシステム処理の機能を制限する。暗号化されたメッセージのコンテンツをアクセスすることができない場合には、複合署名状態は、ＴＰＳＩＧＮ＿ＵＮＫＮＯＷＮであると考えられる。
【００７５】
デジタル的に署名されたメッセージ・バッファは、“エンベロープド・データ（ＥｎｖｅｌｏｐｅｄＤａｔａ）”コンテント・タイプとして、ＰＫＣＳ−７フォーマットで表される。一実施形態では、選択された特定のオプションは、以下のものを含む：
ＰＫＣＳ−１７バージョン０エンベロープド・データ（ＥｎｖｅｌｏｐｅｄＤａｔａ）・フォーマット。
メッセージ・コンテントは、バッファ・タイプ・ストリング、バッファ・サブタイプ・ストリング、及びバッファ・データの複合である。
１５．メッセージ・コンテントは、暗号化の前に“デフレート（ｄｅｆｌａｔｅ）”アルゴリズムで圧縮されうる。
データ・コンテント・パディングがバルク暗号化アルゴリズム（即ち、ＤＥＳまたは３ＤＥＳ）によって要求される場合には、パディング・フォーマットは、ＰＫＣＳ−７によって特定されるようなものである。
【００７６】
ＰＫＣＳ−７署名及びＰＫＣＳ−７暗号化エンベロープの両方が必要な場合には、これらの手順は、順番に適用される：サインド・データ（ＳｉｇｎｅｄＤａｔａ）コンテント・タイプが圧縮されそれからエンベロープド・データ（ＥｎｖｅｌｏｐｅｄＤａｔａ）・コンテント・タイプによってエンベロープされる。あまり適応でない（レス・ケーパブル）サインド・アンド・エンベロープド・データ（ＳｉｇｎｅｄＡｎｄＥｎｖｅｌｏｐｅｄＤａｔａ）・コンテント・タイプは、用いられない。
【００７７】
多くのメッセージ変換は、デジタル署名及びメッセージ暗号化の処理中に行われる。メッセージが様々なマシン・タイプで実行される中間処理によって取り扱われうるので、これらの変換は、正しい順番で適用されることが重要である。一実施形態における処理シーケンスは、以下のようである：
１．バッファ・タイプ・スイッチによって特定されたようなその現在の動作を呼び出すことによって、伝送のためにメッセージ・バッファを準備する。
２．バッファ・タイプ・スイッチによって特定されたようなそのｅｎｃｄｅｃ動作を呼び出すことによって、マシン-ニュートラル・フォーマットでバッファをコード化する。署名されていない/暗号化されていないバッファによる通常の動作とは異なり、全ての介在マシンのマシン・タイプ及び最終受信者が発信者に知られていないし、かつ中間マシンが後でバッファをコード化するために必要な署名キーまたは必要な解読へのアクセスを有していないので、このステップは、強制的である。
３．バッファ・タイプ・ストリング、バッファ・サブタイプ・ストリング、及びステップ２からのコード化されたバッファ・コンテンツを連結する。
４．ＰＫＣＳ−７サインド・データ（ＳｉｇｎｅｄＤａｔａ）・フォーマットでゼロ、一つ、または複数のデジタル署名添付を生成する。
５．デフレート（Ｄｅｆｌａｔｅ）圧縮アルゴリズムを用いて、ＰＫＣＳ−７サインド・データ（ＳｉｇｎｅｄＤａｔａ）出力を圧縮する。それがほとんどのバルク・データ暗号化アルゴリズムの強度を潜在的に強化するので、圧縮は強制的である。また、圧縮は、署名及び暗号化エンベロープ添付の余分なオーバーヘッドをうまくゆけば補償する。
６．選択されたバルク・データ暗号化アルゴリズムに適する擬似ランダム・メッセージ暗号化キーを生成する。この一時的なキーは、一度採用されてそれから破棄される。
７．一以上の先に特定された受信者に対して、ＰＫＣＳ-７エンベロープド・データ（ＥｎｖｅｌｏｐｅｄＤａｔａ）・フォーマットでメッセージを暗号化する。
【００７８】
メッセージ-ベース暗号化ソフトウェア・インタフェース
以下に説明するソフトウェア及びアドミニストレーティブ・インタフェースは、本発明の一実施形態による暗号化処理の形態を制御するために用いることができる。その他及び/または追加のインタフェース及び関数を用いることができるということ、及び本発明は、以下に説明するインタフェースに限定されないということは当業者に明らかであろう。
【００７９】
ｔｐｓｅａｌ（）
ｔｐｓｅａｌ（）は、暗号化エンベロープの生成のためにメッセージ・バッファに印を付ける。暗号化処理は、メッセージ・バッファが処理から伝送されそうなときにはいつでも、将来に実際には実行される。
【００８０】
ｔｐｅｎｖｅｌｏｐｅ（）
ｔｐｅｎｖｅｌｏｐｅ（）は、メッセージ・バッファの添付されたデジタル署名及び暗号化エンベロープに関する状況情報を戻す。添付されたアイテム（項目）はゼロからＮ−１まで番号付けされ、そしてｔｐｅｎｖｅｌｏｐｅ（）は、特定の場所におけるアイテムに関する情報を戻す。また、それは、ｔｐｅｎｖｅｌｏｐｅ（）にＴＰＫＥＹ＿ＲＥＭＯＶＥフラグを特定することによってバッファの発生リストからアイテムを取り除くことも可能である。
【００８１】
ｔｐｅｘｐｏｒｔ（）
ｔｐｅｘｐｏｒｔ（）は、関連デジタル署名または暗号化エンベロープを含む、具体化された表現に、メッセージ・バッファを変換する。
【００８２】
ｔｐｉｍｐｏｒｔ（）
ｔｐｉｍｐｏｒｔ（）は、具体化された表現をメッセージ・バッファに戻すように変換する。必要な場合には、この処理中に解読が実行され、そして添付されたデジタル署名が検証される。
【００８３】
ｔｐｋｅｙ＿ｏｐｅｎ（）、ｔｐｋｅｙ＿ｇｅｔｉｎｆｏ（）、ｔｐｋｅｙ＿ｓｅｔｉｎｆｏ（）、ｔｐｋｅｙ＿ｃｌｏｓｅ（）
これらの関数は、アプリケーションに解読を実行するためのその秘密キー及び暗号化されたデータの受信者を表しているその公開キーを管理させる。キーは、ハンドルを介して表されかつ操作される。異なる目的に対して、異なるキー・タイプが存在する。キーは、以下の役割の一つ以上を演じうる：
暗号化：キーは、暗号化されたメッセージの意図した受信者を表しかつ識別する。
解読：キーは、プライベート・メッセージを解読することを許容するプリンシパルとして呼出し処理を識別し、かつ解読に必要なプリンシパルの秘密キーへのアクセスを提供する。
署名生成：キーは、プリンシパルの身分の下でデジタル署名を生成することを許可された特定のプリンシパルとして呼出し処理を識別し、かつ署名を生成するために必要なプリンシパルの秘密キーへのアクセスを提供する。
署名認証：キーはデジタル署名に関連付けられたプリンシパルを表しかつ識別する。
【００８４】
暗号化オプションは、ｔｐｋｅｙ＿ｇｅｎｔｉｎｆｏ（）で読みうるしかつｔｐｋｅｙ＿ｓｅｔｉｎｆｏ（）で設定しうる。ＥＮＣＲＹＰＴ＿ＡＬＧキー属性は、バルク・データ暗号化アルゴリズムを制御し、かつＥＮＣＲＹＰＴ＿ＢＩＴＳ属性は、バルク・データ暗号化アルゴリズムのキー長を制御する。
【００８５】
キーが、それが開かれた後で期限切れになるかまたは取消される場合には、キー保持者は、直ぐに通知される必要はない。全ての使用に対するキーの状況をチェックするための要求が存在しない。しかしながら、その他の処理は、期限切れキーで生成された署名または暗号化エンベロープを受け入れないことがある。
【００８６】
メッセージ-ベース暗号化アドミニストレーティブ・インタフェース
メッセージ-ベース暗号化ポリシーに関する多くのアドミニストレーティブ・パラメータを特性することができる：
【００８７】
入力されるメッセージ暗号化強制ポリシー：ＥＮＣＲＹＰＴＩＯＮ＿ＲＥＱＵＩＲＥＤ
これは、構成階層における複数のレベルで特定されうるＹ/Ｎパラメータである。このポリシーが特定された場合には、一つ以上のＹ構成値の対象となる入力されるメッセージは、暗号化エンベロープによって保護されなければならない。
ドメイン・レベル（Ｔ＿ＤＯＭＡＩＮクラスまたは^*ＲＥＳＯＵＲＣＥＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、ドメイン内に広告された全てのアプリケーション・サービスを含む。デフォルト値はＮである。
マシン・レベル（Ｔ＿ＭＡＣＨＩＮＥクラスまたは^*ＭＡＣＨＩＮＥＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、特定のマシンに広告された全てのアプリケーション・サービスを含む。デフォルト値はＮである。
グループ・レベル（Ｔ＿ＧＲＯＵＰクラスまたは^*ＧＲＯＵＰＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、特定のグループによって広告された全てのアプリケーション・サービスを含む。デフォルト値はＮである。
サービス・レベル（Ｔ＿ＳＥＲＶＩＣＥクラスまたは^*ＳＥＲＶＩＣＥセクション）では、このパラメータは、ゲートウェイ処理による広告を含む、ドメイン内で広告された特定のサービスの全てのインスタンスを含む。デフォルト値はＮである。
【００８８】
これらのポリシーは、アプリケーション・サービス、アプリケーション・イベント、またはアプリケーション・エンキュー要求にだけ適用される。それらは、システム-生成サービス呼出し、システム・イベント・ポスティング、タイムアウト・メッセージ、トランザクション管理メッセージ、またはその他のシステム・メッセージに適用されない。
【００８９】
関連メッセージ・バッファのデータ・プライバシーを保護するために、イベント・ポスティングに対して暗号化されたメッセージを要求することは、一定の顧客環境において望ましいことがある。ポストされたメッセージ・バッファが暗号化されるときに、暗号化エンベロープは、保存されかつ暗号化されたメッセージ・バッファ・コンテンツと一緒にそのイベントに対する加入者へ送付される。
【００９０】
Ｔｕｘｅｄｏシステムでは、ＴＭＵＳＲＥＶＴシステム・サーバ処理が暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、暗号化されていない入力されるポスティング・メッセージを拒否する。（システム自体によってポストされかつＴＭＳＹＳＥＶＴシステム・サーバ処理によって処理された）システム・イベントは、決して暗号化されないし、かつ暗号化に係わるアドミニストレーティブ・ポリシーは、ＴＭＳＹＳＥＶＴサーバに適用されない。
【００９１】
ＴＭＵＳＲＥＶＴサーバが取りうる可能な加入通知動作は、サービスを呼び出すことまたはメッセージをエンキューすることを含む。目標サービスまたはキューが暗号化された入力を必要とするが、ポストされたメッセージが暗号化されていなかった場合には、加入通知動作は失敗する。また、加入者が適切な解読キーを所有してない場合には、イベント通知動作は失敗する。
【００９２】
関連メッセージ・バッファのデータ・プライバシーを保護するために、高信頼ディスク-ベース・キューに記憶されたメッセージに対して暗号化を要求することは、一定の顧客環境において望ましいことがある。キューされたメッセージ・バッファが暗号化されるときに、この状況は、キューに保存されかつバッファは、デキューイング処理に暗号化されて戻される。メッセージがサービスを呼出すためにＴＭＱＦＯＲＷＡＲＤによって処理された場合には、暗号化状態も保存される。
【００９３】
ＴＭＱＵＥＵＥシステム・サーバ処理が暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、暗号化されていない入力されるエンキュー要求を拒否する。更に、そのようなポリシーがキュー空間に関連付けられたサービス・ネームに対して発効される場合には、ＴＭＱＵＥＵＥサーバ処理は、暗号化を必要とする。
【００９４】
リモート・ワークステーション・クライアントは、メッセージ捕捉攻撃に影響され易い。従って、システムがクライアントによって伝送された全てのメッセージ・バッファに対して暗号化を必要とするポリシーを強制することは、望ましいことがある。セキュリティの理由で、このポリシー要求は、クライアント・ライブラリ関数においてではなく、入力されるゲートウェイ処理で強制されなければならない。
【００９５】
ゲートウェイ処理が暗号化を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、暗号されていないアプリケーション・データ・バッファを含んでいる入力されるメッセージを拒否する。
【００９６】
メッセージ-ベース暗号化障害報告及び監視
処理が暗号化されたメッセージを受信するが、メッセージの暗号化エンベロープの一つに適合しているオープン解読キーを所有していない場合には、以下の動作が行われる：
ｕｓｅｒｌｏｇ（）エラー・メッセージが生成される。
セキュリティ侵害システム・イベントがポスト（掲示）される。
バッファは、あたかもそれが処理によって受信されなかったかのように破棄される。
【００９７】
アドミニストレーティブ・パラメータ設定に基づき、暗号化された入力を必要とする処理が、暗号化されていないメッセージを受信した場合には、以下の動作が行われる：
ｕｓｅｒｌｏｇ（）エラー・メッセージが生成される。
セキュリティ侵害システム・イベントがポストされる。
バッファは、あたかもそれが処理によって受信されなかったかのように破棄される。
【００９８】
メッセージ-ベース・デジタル署名
簡単に上述したように、メッセージ-ベース・デジタル署名は、メッセージ発信者にその身分を証明させ、かつその証明を特定のメッセージ・バッファに結び付けさせることによってトランザクション・サーバ・セキュリティを強化する。相互認証形改竄防止通信は、会社間または会社と公衆との間のいずれかで、インターネット上でデータを移送するほとんどのアプリケーションに対して重要であると考えられる。また、それは、安全でない内部ネットワーク上に配置されたアプリケーションに対しても重要である。この認証及び保全性チェッキングの適用範囲は、メッセージ・バッファが発信元処理を離れるときからそれが目的処理で受信されるときまで保護されるという点で、“エンド-トゥ-エンド”であると考えられうる。このようにして、メッセージは、一時的メッセージ・キュー、ディスク-ベース・キュー、システム処理、サーバ間ネットワーク・リンク上の伝送、等を含む、全ての中間通過点で保護される。
【００９９】
本発明の一実施形態では、発信元ユーザは、ｔｐｓｉｇｎ（）関数を用いてメッセージ・バッファに署名する。次いで署名は、ｔｐｅｎｖｅｌｏｐ（）関数を用いてユーザによって後で読み取ることができる。ユーザは、トランザクション・サーバ自体を用いている人間でありうるか、または同様に、ユーザ・アプリケーション、または別のアプリケーションでありうる。この署名は、メッセージ・バッファのコンテンツの暗号的にセキュアなチェックサムを含む。メッセージ・バッファへのアクセスを有するパーティは、発信元ユーザの署名が真正であるということ、及びメッセージ・バッファ・コンテンツが変更されていないということを検証しうる。サード・パーティによる時間独立認証は、否認として知られる特性を提供する。これは、発信者が後で原作者(authorship)を否定できないかまたはメッセージが変更されたことを主張できないということを意味する。
【０１００】
次いで、メッセージ署名者のローカル・クロックに基づき、タイム・スタンプが、署名に添付される。タイム・スタンプ値による改竄が署名が検証されるときに検出されるように、タイム・スタンプは、チェックサム計算に検証された属性として含まれる。署名タイム・スタンプは、非同期クロックに基づきうるし、そのような場合には、特に署名がＰＣまたはパーソナル・ワークステーションで生成される場合には、それは完全には信頼することができない。しかしながら、この機能は、サーバが、あまりにも古いかまたはあまりにも未来において先であるタイム・スタンプによる要求を拒否することを選択しうるということにおいて有用である。これは、リプレイ攻撃に対する保護測度を提供する。
【０１０１】
署名は、処理境界を横切るときに生成されかつ検証される。ネットワーク形通信とマシン間通信との間に違いは存在しない。
【０１０２】
バッファを署名することは、３つのステップを含む：
第１に、署名パーティは、秘密署名キーへのアクセスを有していなければならない。このキーは、高度に保護され、かつその所有は、署名パーティの識別を所有することに等しい。
第２に、バッファに署名するための要望または設定、および関連署名パラメータは、示されかつ記憶される。これは、自動的にまたはｔｐｓｉｇｎ（）関数への明示的な呼出しを介して発生しうる。署名パラメータは、後での使用に対して記憶されかつバッファに関連付けられる。
最後のステップは、実際の署名生成であり、バッファが発信元処理から外部に伝送されそうなころにはいつでも自動的実行される。“署名された”バッファが二度以上伝送される場合には、新しい署名が各通信に対して生成される。これは、バッファを、それに署名することの要望が登録された後で変更させる。
【０１０３】
デジタル的に署名されたメッセージ・バッファは、“サインド・データ（ＳｉｇｎｅｄＤａｔａ）”コンテント・タイプとして、ＰＫＣＳ−７フォーマットで表すことができる。この特定の実施形態では、特定のオプションは、以下のものを含みうる：
ＰＫＣＳ−７・バージョン１・フォーマット。
署名パーティのＸ．５０９ｖ３証明書が含まれうる。
メッセージ・ダイジェスト及び署名アルゴリズム識別子が含まれうる。
ローカル・クロックに基づくタイム・スタンプが検証された属性として含まれうる。
メッセージ・コンテントは、バッファ・タイプ・ストリング、バッファ・サブタイプ・ストリング、及びバッファ・データの複合でありうる。
【０１０４】
その他のデジタル署名コンテンツは、本発明の精神及び適用範囲内にそのままでいる間に用いられうる。
【０１０５】
署名が生成されるときにはいつでも、ローカル・システムのクロックからのタイム・スタンプが添付される。タイム・スタンプそれ自体は、検証された属性として署名のチャックサム計算に含まれ、従って、関連メッセージ・バッファ・データに結び付けられそしてまた改竄から保護される。時間分解能は、秒までであり、かつタイム・スタンプは、ＰＫＣＳ−９“署名時間（ＳｉｇｎｉｎｇＴｉｍｅ）”フォーマットで記憶される。
【０１０６】
一実施形態では、トランザクション・サーバは、以下のような、メッセージ・バッファ上で署名を計算するために様々な署名モードを支援しうる：
１．ＲＳＡ公開キー署名を有するＳＨＡ−１メッセージ・ダイジェスト・アルゴリズム。
２．ＤＳＡ公開キー署名を有するＳＨＡ−１メッセージ・ダイジェスト・アルゴリズム。
３．ＲＳＡ公開キー署名を有するＭＤ５メッセージ・ダイジェスト・アルゴリズム。
【０１０７】
デジタル署名及び関連ユーザ証明書は、同じアルゴリズムまたはキー・サイズに基づく必要はない。
【０１０８】
二つ以上の署名をメッセージ・バッファに関連付けることができる。異なる署名は、異なるメッセージ・ダイジェストまたは署名アルゴリズムに基づきうる。
【０１０９】
署名は、ｔｐｓｉｇｎ（）関数を用いて添付されかつｔｐｅｎｖｅｌｏｐｅ（）関数を用いて報告される。受信者は、署名が添付された時間順序で添付された署名を検査しうる。メッセージ・バッファに自動的に添付された署名は、その他の署名の後に追加される。これらの署名の相対順序は、不確定である。
【０１１０】
バッファが出力パラメータとしてアプリケーション・インタフェースにパスされた場合には、バッファに関連付けられた先に添付された署名情報は、削除される。これは、ペンディング署名、またはバッファの先の使用からの署名を含む。署名の新しいセットは、動作が正常に完了した後に、新しいバッファ・コンテントに関連付けられうる。ここで示すように、“アプリケーション・インタフェース”は、例えば、一つのプログラムから別のプログラムに要求を送信するために、一つの構成部分から別の構成部分に名前付けされたサービス要求を送信するために、または別のものによる後での検索のために安定記憶に対して一つのプログラムまたは構成部分エンキュー・データを有するために用いることができるプログラミング手順のセットまたはライブラリである。かかるアプリケーション・インタフェースの一例は、Ｏｐｅｎ Ｇｒｏｕｐ‘ｓ Ｘ/ＯＰＥＮ ＸＡＴＭＩインタフェースのスーパーセットでありかつＣ及びＣＯＢＯＬ手順に一貫性があるインタフェースを共有させる手順ライブラリである、米国カリフォルニア州、サンノセにある、ＢＥＡシステム、Ｉｎｃ．からのトランザクション・マネージャ・インタフェースへのアプリケーション（Ａｐｐｌｉｃａｔｉｏｎ ｔｏ Ｔｒａｎｓａｃｔｉｏｎ Ｍａｎａｇｅｒ Ｉｎｔｅｒｆａｃｅ（ＡＴＭＩ））である。
【０１１１】
バッファが入力パラメータとしてアプリケーション・インタフェースにパスされた場合には、先に添付された署名が検証されかつ伝送される。例えば、サーバ処理が入力として署名されたバッファを受信しそれに署名し、それから変更なしでそれを別のサービスに送る場合には、最初（オリジナル）の署名及び新しい署名の両方が伝送される。これは、複数の処理からの署名を有する情報の安全で、検証された、ハンド-オフを可能にする。
【０１１２】
しかしながら、サーバがバッファを変更した場合には、最初の署名は、もはや有効ではない。これは、伝送処理によって検出され、かつ無効署名は、アプリケーション・インタフェース動作の副作用として暗黙のうちに破棄される。
【０１１３】
署名されたバッファに対する具体化されたフォーマットは、署名されたデータの“通り抜け”伝送、とまた否認に対する署名されたバッファの長期記憶を可能にする。
【０１１４】
ｔｐｅｘｐｏｒｔ（）関数は、関連デジタル署名または暗号化エンベロープを含む、メッセージ・バッファの具体化された表現を生成する。バッファは、あたかもそれが、暗号化及びデジタル署名処理を含んでいるアプリケーション・インタフェースによって別の処理に伝送されたかのようにちょうど処理される。
【０１１５】
ｔｐｉｍｐｏｒｔ（）関数は、具体化された表現をメッセージ・バッファに戻すように変換し、必要ならば解読及び署名検証を実行する。
【０１１６】
署名パーティは、署名を生成するためにデジタル証明書及び秘密キーに関連付けられたキー・ハンドルを提示しなければならない。このキー・ハンドルは、署名パーティの身分を表す。メッセージ・バッファが添付されたデジタル署名を有する場合には、署名は、バッファが別のサーバ処理によって受取られたときに自動的に検証することができる。処理は、ｔｐｅｎｖｅｌｏｐ（）関数を呼び出すことによってバッファの添付された署名に関する詳細な情報を取得しうる。
【０１１７】
処理は、署名されたメッセージ・バッファを受け取り、それからバッファのコンテンツを変更しうるということが可能である。これは、添付された署名を無効にする副作用を有する。この場合にはｔｐｅｎｖｅｌｏｐｅ（）は、先に添付された署名を検証することができないし、かつＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＭＥＳＳＡＧＥとして署名状態を報告する。
【０１１８】
発信元処理では、ｔｐｓｉｇｎ（）によって登録された署名要求が記憶されかつメッセージに関連付けられる。これらの署名は、状態ＴＰＳＩＧＮ＿ＰＥＮＤＩＮＧを有するｔｐｅｎｖｅｌｏｐｅ（）によって報告される。また、ＴＰＫＥＹ＿ＡＵＴＯＳＩＧＮキーからもたらされるペンディング署名は、ＴＰＳＩＧＮ＿ＰＥＮＤＩＮＧ状態のｔｐｅｎｖｅｌｏｐｅ（）によっても報告される。しかしながら、これらの署名は、発信元処理が、メッセージが実際に送信される前に自動署名キーを閉じた場合には生成されないことがある。
【０１１９】
デジタル署名は、署名されたメッセージ・バッファがトランザクション処理に入るときにはいつでも検証される。これは、クライアント及びサーバ処理、及びあるシステム処理を含む。一般に、システム処理がメッセージのコンテンツへのアクセスを必要とするときにはいつでも、添付されたデジタル署名及びメッセージの保全性が検証される。システム処理が、メッセージのコンテンツを読むことなく、通り抜けコンジットとして動作する場合には、添付されたデジタル署名は、検証される必要がない。
【０１２０】
各個別の署名が検査されかつ以下の状態の一つに分離される：
ＴＰＳＩＧＮ＿ＯＫ：署名パーティの証明書が認知されたＣＡによって発行され、ＣＡの証明書署名が有効であり、証明書が（署名のタイム・スタンプに関して）期限切れではなく、タイム・スタンプがあまりにも古くもなく或いは将来においてあまりにも先でもなく、かつ関連デジタル署名が検証される。
ＴＰＳＩＧＮ＿ＵＮＫＮＯＷＮ：署名パーティの証明書が未知のＣＡによって発行され、従って証明書またはメッセージ・バッファ署名のいずれも信頼することができない。
ＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤ：署名は、それがあまりにも前に生成されたので認知されない。
ＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤ＿ＣＥＲＴ：署名パーティの証明書が有効であるように思えるが、（署名のタイム・スタンプに関して）期限切れしている。
ＴＰＳＩＧＮ＿ＰＯＳＴＤＡＴＥＤ：署名がそのタイム・スタンプが将来においてあまりにも先に日付が付されているので認知されない。
ＴＰＳＩＧＮ＿ＲＥＶＯＫＥＤ＿ＣＥＲＴ：署名パーティの証明書が取り消されている。
ＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＣＥＲＴ：署名パーティの証明書が認知されたＣＡによって発行されたものであることを主張するが、（例えば、ＣＡのデジタル署名が検証に失敗したので）改竄されたように思われる。
ＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＭＥＳＳＡＧＥ：署名パーティの証明書が有効であるがメッセージ・バッファ・コンテンツ（または関連ローカル・タイム・スタンプ）が改竄されたように思われる。
【０１２１】
ゼロ、一つ、または複数のデジタル署名が添付されることは、可能である。一実施形態では、メッセージ・バッファの複合署名状態は、各署名の状態を検査しかつ全体の状況を得るために（順番に）以下の規則を適用することによって決定される：
１．署名がＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＭＥＳＳＡＧＥである場合には、結果は、ＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＭＥＳＳＡＧＥである。
２．署名がＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＣＥＲＴである場合には、結果は、ＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＣＥＲＴである。
３．署名がＴＰＳＩＧＮ＿ＲＥＶＯＫＥＤ＿ＣＥＲＴである場合には、結果は、ＴＰＳＩＧＮ＿ＲＥＶＯＫＥＤ＿ＣＥＲＴである。
４．署名がＴＰＳＩＧＮ＿ＰＯＳＴＤＡＴＥＤである場合には、結果は、ＴＰＳＩＧＮ＿ＰＯＳＴＤＡＴＥＤである。
５．署名がＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤ＿ＣＥＲＴである場合には、結果は、ＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤ＿ＣＥＲＴである。
６．署名がＴＰＳＩＧＮ＿ＯＫである場合には、結果は、ＴＰＳＩＧＮ＿ＯＫである。
７．署名がＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤである場合には、結果は、ＴＰＳＩＧＮ＿ＥＸＰＩＲＥＤである。
８．それ以外は、結果は、ＴＰＳＩＧＮ＿ＵＮＫＮＯＷＮである。また、これは、添付された署名を有していないメッセージ・バッファに対する結果でもある。
【０１２２】
これらは、メッセージ・バッファの署名状態を決定するためのデフォルト規則である。その他の規則のセットは、その他の状況を説明するために用いることができる。より複雑な署名分析が必要な場合には、アプリケーションは、個々の署名を検査するためにｔｐｅｎｖｅｌｏｐｅ（）を呼び出すことがある。これは、期限切れでないかまたは未知でない、正確に３つの特定の署名に対するサーバの要求事項のような規則の強制を許容する。
【０１２３】
ある実施形態ではサーバ処理は、メッセージ・バッファが処理を離れるときにはいつでもメッセージ・バッファに自動的に署名するように構成することができる。セキュア・アプリケーションにおいてより少数のＡＰＩ呼出しが要求されるので、これはプログラマにとって都合がよく、かつ既存のアプリケーションに最小コーディング変更でデジタル署名技術に影響力を及ぼさせる。また、それは、安全ではないネットワーク上に送信される署名されていないバッファを結果としてもたらすプログラミング・エラーの可能性を低減することによってセキュリティを強化する。
【０１２４】
自動署名生成は、ＴＰＫＥＹ＿ＡＵＴＯＳＩＧＮフラグを有するキーを開くことによって可能にされる。デジタル署名を可能にするために、処理は、署名プリンシパルの身分の下で動作しかつプリンシパルの秘密キーにアクセスするためのその権利を証明しなければならない。証明の一つの形式は、秘密パス・フレーズまたはパスワードを供給することである。証明要件は、セキュリティ・プロバイダにより変化しうる。
【０１２５】
サービスは、アドミニストレーティブ・ポリシーに基づき、全ての入力される要求メッセージに対して有効なデジタル署名を必要としうる。このポリシーが発効されている場合には、入力されるサービス要求は、複合署名状態ＴＰＳＩＧＮ＿ＯＫを有していなければならないかまたはそれは処理されない。
【０１２６】
会話的サービスは、ｔｐｃｏｎｎｅｃｔ（）またはｔｐｓｅｎｄ（）を介して送信された、全ての入力されるメッセージが、アドミニストレーティブ・ポリシーに基づき、有効デジタル署名を有するということを必要としうる。このポリシーが発効されている場合には、入力されるメッセージは、複合署名状態ＴＰＳＩＧＮ＿ＯＫを有していなければならないかまたはそれは処理されない。
【０１２７】
いくつかの実施形態では、いくつかのサブシステムまたはゲートウェイ処理は、アドミニストレーティブ・ポリシーに基づき、全ての入力されるポシティング・メッセージに対して有効デジタル署名を必要としうる。このポリシーが発効されている場合には、入力されるポスティング要求は、複合署名状態ＴＰＳＩＧＮ＿ＯＫを有していなければならないかまたはそれは処理されない。
【０１２８】
メッセージ-ベースデジタル署名ソフトウェア・インタフェース
以下に説明するソフトウェア及びアドミニストレーティブ・インタフェースは、本発明の一実施形態によるデジタル署名処理の形態を制御するために用いることができる。その他の及び/または追加のインタフェース及び関数を用いることができるということ、及び本発明は、以下に説明するインタフェースに限定されないということは、当業者にとって明らかである。
【０１２９】
ｔｐｓｉｇｎ（）
ｔｐｓｉｇｎ（）は、デジタル署名で署名するためにメッセージ・バッファに印を付ける。署名は、メッセージ・バッファが処理から伝送されそうなときにはいつでも、将来に実際に生成される。
【０１３０】
ｔｐｅｎｖｅｌｏｐｅ（）
ｔｐｅｎｖｅｌｏｐｅ（）は、メッセージ・バッファの添付されたデジタル署名及び暗号化エンベロープに関する状況情報を戻す。添付されたアイテムはゼロからＮ−１まで番号付けされ、そしてｔｐｅｎｖｅｌｏｐｅ（）は、特定の場所におけるアイテムに関する情報を戻す。また、それは、ｔｐｅｎｖｅｌｏｐｅ（）にＴＰＫＥＹ＿ＲＥＭＯＶＥフラグを特定することによってバッファの発生リストからアイテムを取り除くことも可能である。
【０１３１】
ｔｐｅｘｐｏｒｔ（）
ｔｐｅｘｐｏｒｔ（）は、関連デジタル署名または暗号化エンベロープを含む、具体化された表現に、メッセージ・バッファを変換する。
【０１３２】
ｔｐｉｍｐｏｒｔ（）
ｔｐｉｍｐｏｒｔ（）は、具体化された表現をメッセージ・バッファに戻すように変換する。必要な場合には、この処理中に解読が実行され、そして添付されたデジタル署名が検証される。
【０１３３】
ｔｐｋｅｙ＿ｏｐｅｎ（）、ｔｐｋｅｙ＿ｃｌｏｓｅ（）、ｔｐｋｅｙ＿ｇｅｔｉｎｆｏ（）、ｔｐｋｅｙ＿ｓｅｔｉｎｆｏ（）
これらの関数は、アプリケーションに、デジタル署名を生成するためのその秘密キーを管理させる。キーは、ハンドルを介して表されかつ操作される。異なる目的に対して、異なるキー・タイプが存在する。キーは、以下の役割の一つ以上を演じうる：
暗号化：キーは、暗号化されたメッセージの意図した受信者を表しかつ識別する。
解読：キーは、プライベート・メッセージを解読することを許容するプリンシパルとして呼出し処理を識別し、かつ解読に必要なプリンシパルの秘密キーへのアクセスを提供する。
署名生成：キーは、プリンシパルの身分の下でデジタル署名を生成することを許可された特定のプリンシパルとして呼出し処理を識別し、かつ署名を生成するために必要なプリンシパルの秘密キーへのアクセスを提供する。
署名認証：キーは、デジタル署名に関連付けられたプリンシパルを表しかつ識別する。
【０１３４】
デジタル署名オプションは、ｔｐｋｅｙ＿ｇｅｎｔｉｎｆｏ（）で読みうるしかつｔｐｋｅｙ＿ｓｅｔｉｎｆｏ（）で設定しうる。各プロバイダは、動作のデフォルト・モードを供給することが期待されるが、異なるオプションを設定させうる。ＳＩＧＮＡＴＵＲＥ＿ＡＬＧキー属性は、署名アルゴリズムを制御する。ＤＩＧＥＳＴ＿ＡＬＧキー属性は、メッセージ・ダイジェスト・アルゴリズムを制御する。ＳＩＧＮＡＴＵＲＥ＿ＢＩＴＳ属性は、アルゴリズムのビット長を制御する。これらの属性のあるものは、署名キーが生成されたときに固定されうるし、プロバイダが複数のオプションを支持しても、それらを特定のキーに設定することができないことがあるということに注目する。キー・ハンドルは、いくつかの方法で開かれる：
ｔｐｋｅｙ＿ｏｐｅｎ（）に対する明示的呼出しによって。
ｔｐｅｎｖｅｌｏｐｅ（）からの出力として。
【０１３５】
ｔｐｋｅｙ＿ｃｌｏｓｅ（）を呼出すことによってキー・リソースを解放することは、アプリケーションの責任である。一度キーが閉じられたならば、ハンドルは、もはや用いられないことがある。自動特性を有するキー（自動署名のためのＴＰＫＥＹ＿ＡＵＴＯＳＩＧＮまたは自動暗号化のためのＴＰＫＥＹ＿ＡＵＴＯＥＮＣＲＹＰＴ）は、もはやキーが閉じられた後では将来の通信動作に適用されない。（署名または暗号化のために）特定のバッファに関連付けられたキーは、そのバッファに関連付けられたままでありかつそのまま処理される。閉じられたキーに関連付けられた最後のバッファが自由にされるかまたは上書きされたときに、キーに起因するリソースが解放される。
【０１３６】
キーが期限切れになるかまたはそれを開いた後で取り消された場合には、キー保持者は、直ぐに通知される必要がない。全ての使用に対するキーの状態をチェックするための必要条件が存在しない。しかしながら、その他の処理は、期限切れキーによって生成された署名または暗号化エンベロープを受け入れないことがある。
【０１３７】
メッセージングに関連したアドミニストレーティブ・パラメータの数及びデジタル署名の使用は、特定することができる。
【０１３８】
署名タイム・スタンプ・ウインドウ：ＳＩＧＮＡＴＵＲＥ＿ＡＨＥＡＤ
このパラメータは、有効署名タイム・スタンプが、検証システムのローカル・クロックにより、将来のどのくらい先（将来）でありうるかを制限する。署名のタイム・スタンプが将来へのこのオフセット以上である場合には、署名は無効であると考えられる。このパラメータは、非同期ローカル・クロックに対する一定量のリーウェイ（許容差）を許容すると同時に、事後日付の署名を拒否するために有用である。ＳＩＧＮＡＴＵＲＥ＿ＡＨＥＡＤパラメータの単位は秒である。
【０１３９】
署名タイム・スタンプ・ウインドウズ：ＳＩＧＮＡＴＵＲＥ＿ＢＥＨＩＮＤ
このパラメータは、有効署名タイム・スタンプが、検証システムのローカル・クロックにより、将来のどのくらい以前（過去）でありうるかを制限する。署名のタイム・スタンプが過去へのこのオフセット以上である場合には、署名は無効であると考えられる。このパラメータは、有効署名バッファが二度目にシステムに注入されるときに、リプライ攻撃に抵抗するために有用である。しかしながら、例えば、ディスク-ベース・キューを用いている、非同期通信を有するシステムでは、かなり以前に署名されたバッファは、有効であると考えられかつこのパラメータが増加されるべきである。ＳＩＧＮＡＴＵＲＥ＿ＢＥＨＩＮＤパラメータの単位は秒である。
【０１４０】
入力されるメッセージ署名施行ポリシー：ＳＩＧＮＡＴＵＲＥ＿ＲＥＱＵＩＲＥＤ
これは、構成階層における複数のレベルで特定されうるＹ/Ｎパラメータである。このポリシーが特定された場合には、一つ以上のＹ構成値の対象となる入力されるメッセージは、有効デジタル署名を含まなければならない。
ドメイン・レベル（Ｔ＿ＤＯＭＡＩＮクラスまたは^*ＲＥＳＯＵＲＣＥＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、ドメイン内に広告された全てのアプリケーション・サービスを含む（カバーする）。デフォルト値は、Ｎである。
マシン・レベル（Ｔ＿ＭＡＣＨＩＮＥクラスまたは^*ＭＡＣＨＩＮＥＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、特定のマシンに広告された全てのアプリケーション・サービスを含む。デフォルト値は、Ｎである。
グループ・レベル（Ｔ＿ＧＲＯＵＰクラスまたは^*ＧＲＯＵＰＳセクション）では、このパラメータは、ゲートウェイ処理によって広告されたものを含む、特定のグループによって広告された全てのアプリケーション・サービスを含む。デフォルト値は、Ｎである。
サービス・レベル（Ｔ＿ＳＥＲＶＩＣＥクラスまたは^*ＳＥＲＶＩＣＥセクション）では、このパラメータは、ゲートウェイ処理による広告を含む、ドメイン内で広告された特定のサービスの全てのインスタンスを含む。デフォルト値は、Ｎである。
【０１４１】
上述したポリシーは、アプリケーション・サービス、アプリケーション・イベント、またはアプリケーション・エンキュー要求にだけ適用される。それらは、システム-生成サービス呼出し、システム・イベント・ポスティング、タイムアウト・メッセージ、トランザクション管理メッセージ、またはその他のシステム・メッセージに適用されない。
【０１４２】
暗号化されたメッセージに関連付けられた署名を検証するために、処理は、有効解読キーを開いていなければならない。メッセージのコンテンツへのアクセスなしで、署名は、検証することができない。結果として、ＥｖｅｎｔＢｒｏｋｅｒのような中間システム処理が署名ポリシーを強制するように構成されている場合には、アクセス不能な暗号化されたメッセージは、拒否されることがある。
【０１４３】
メッセージのコンテンツのポスターの識別及び保全性保護の認証を提供するために、イベント・ポスティングに対してデジタル署名を要求することは、一定の顧客環境において望ましいことがある。ポストされたメッセージ・バッファがデジタル署名を有するときに、これらの署名は、保存されかつメッセージ・バッファと一緒にそのイベントに対する加入者へ送付される。
【０１４４】
例えば、Ｔｕｘｅｄｏシステムでは、ＴＭＵＳＲＥＶＴシステム・サーバ処理がデジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、ＴＰＳＩＧＮ＿ＯＫ複合署名状態なしで入力されるポスティングを拒否する。（システム自体によってポストされかつＴＭＳＹＳＥＶＴシステム・サーバ処理によって処理された）システム・イベントは、添付されたデジタル署名を有していない。デジタル署名を要求しているアドミニストレーティブ・ポリシーは、ＴＭＳＹＳＥＶＴサーバに適用されない。
【０１４５】
ＴＭＵＳＲＥＶＴサーバが取りうる可能な加入通知動作は、サービスを呼出すことまたはメッセージをエンキューすることを含む。目標サービスまたはキューが有効デジタル署名を必要とするが、それがポストされたメッセージに添付されていない場合には、加入通知動作は失敗する。
【０１４６】
メッセージのコンテンツの発信者の身分及び保全性保護の認証を提供するために、高信頼ディスク-ベース・キューに記憶されたメッセージに対してデジタル署名を要求することは、一定の顧客環境において望ましいことがある。キューされたバッファが添付されたデジタル署名を有するときに、これらの署名は、キューに保存されかつデキューイング処理に戻される。メッセージがサービスを呼出すためにＴＭＱＦＯＲＷＡＲＤによって処理される場合には、署名も保存される。
【０１４７】
ＴＭＱＵＥＵＥシステム・サーバ処理がデジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、ＴＰＳＩＧＮ＿ＯＫ複合署名状態なしで入力されるエンキュー要求を拒否する。更に、そのようなポリシーがキュー空間に関連付けられたサービス・ネームに対して発効される場合には、ＴＭＱＵＥＵＥサーバ処理は、デジタル署名を要求する。
【０１４８】
リモート・ワークステーション・クライアントは、セッション・ハイジャッキング攻撃またはメッセージ改竄攻撃に影響され易い。従って、システムがクライアントによって伝送された全てのメッセージ・バッファに対してデジタル署名を必要とするポリシーを強制することは、望ましいことがある。セキュリティの理由で、このポリシー要求は、クライアント・ライブラリ関数においてではなく、入力されるゲートウェイ処理で強制されなければならない。
【０１４９】
ゲートウェイ処理がデジタル署名を必要とするドメイン、マシン、またはサーバ・グループで実行されている場合には、それは、ＴＰＳＩＧＮ＿ＯＫ複合署名状態なしでアプリケーション・データを含んでいる入力されるメッセージ・バッファを拒否する。
【０１５０】
メッセージ-ベースデジタル署名障害報告及び監視
メッセージ改竄が検出された場合には（複合署名状態ＴＰＳＩＧＮ＿ＴＡＭＰＥＲＥＤ＿ＭＥＳＳＡＧＥまたはＴＰＳＧＮ＿ＴＡＭＰＥＲＥＤ＿ＣＥＲＴ）、以下の動作が行われる：
ｕｓｅｒｌｏｇ（）エラー・メッセージが生成される（Ｓｅｖｅｒｉｔｙ ＥＲＲＯＲ）。
セキュリティ侵害システム・イベントがポストされる。
バッファは、あたかもそれが処理によって受信されなかったかのように破棄される。
【０１５１】
期限切れ証明書、取消し証明書、期限切れ署名、または事後日付署名に関連付けられた個々の署名が検出された場合には、以下の動作が行われる：
ｕｓｅｒｌｏｇ（）警告メッセージが生成される。
セキュリティ侵害システム・イベントがポストされる。
バッファの複合署名状態がＴＰＳＩＧＮ＿ＯＫまたはＴＰＳＩＧＮ＿ＵＮＫＮＯＷＮではない場合には、それは、あたかもそれが処理によって受信されなかったかのように破棄される。
【０１５２】
有効デジタル署名を必要とする処理が複合署名状態ＴＰＳＩＧＮ＿ＵＮＫＮＯＷＮを受取った場合には、以下の動作が行われる：
ｕｓｅｒｌｏｇ（）警告メッセージが生成される。
セキュリティ侵害システム・イベントがポストされる。
バッファは、あたかもそれが処理によって受信されなかったかのように破棄される。
ｔｐｉｍｐｏｒｔ（）の場合には、それが署名問題を有していてもバッファを戻す必要がある。これは、インポーティング処理に添付された署名をより詳細に検査させる。
【０１５３】
追加機能
以下の能力は、本発明のその他の実施形態に含まれることもある：
１．サード・パーティ・セキュリティ製品との統合：スマートカード、ＬＤＡＰディレクトリ、等。
２．発信元処理は、その応答メッセージが署名されるかまたは暗号化されるということを要求または必要とすべく構成しうる。署名/暗号化状態は、システム・ポリシー・オプションによって暗黙的にまたはメッセージ・バッファの状態を問合せすることによって明示的に強制されることがある。
３．暗号化されたメッセージへのサード・パーティ・コバート・アクセスを容易にするための、キー供託（エスクロー）/キー回復準備。
４．メッセージ・コンテントの他に通信パラメータに署名すること。サービス名、イベント名、またはキュー名は、デジタル署名計算に含まれうる。デジタル署名を有する動作動詞にデータを結び付けることは、セキュリティを改善するが、そこには一つの重要な欠点が存在する：サーバ-階層の透過性及び推移動作の損失。例えば：サービスＡが署名されたメッセージをサービスＢに送った場合には、第２レベル・サービスは、メッセージのコンテンツ上のデジタル署名を受取りかつ検証することができるべきである。発信者の署名が異なるサービス名を含んでいたという理由でそれは失敗すべきではない。ある理由で意図した動作が含まれかつ署名されることを必要とする場合には、これは、アプリケーション-特定フィールドのメッセージ・コンテントに追加することができる。
５．コンテントの他にバッファ・タイプ及びサブタイプを署名すること。バッファ・タイプ・ストリング及びバッファ・サブタイプ・ストリングは、デジタル署名計算に含まれうる。仕様は、認証されたコンテント・データの一部としてバッファ・タイプ及びサブタイプを含む。
６．メッセージ・アーカイビング。関連署名及び/または暗号化エンベロープと一緒に、メッセージ・バッファのアーカイブ・コピーを作るための機能は、否認能力を強化しうる。また、それは、暗号化されたメッセージが解読キーへのアクセスなしで中間処理を通して移送される必要があるアプリケーション・アーキテクチャを可能にする。
７．業界メッセージ・フォーマット標準の遵守。いくつかの実施形態は、暗号化エンベロープ及びデジタル署名を添付するために業界標準データ・フォーマットを支持するように設計されうる。
８．ゲートウェイ処理は、単調に増加する署名タイム・スタンプ値を強制することによってリプレイ攻撃を抑止しうる。
９．特別証明書属性。トランザクション・サーバ発行証明書は、例えば、どのようにユーザの秘密キーが安全に記憶されるか、または署名のみのような証明書の使用に対する制約をユーザに記述する補足の、プロプラエタリー・ポリシー属性を含みうる。
１０．“完全自動”動作モードは、アドミニストレーティブ・パラメータだけに基づき、可能である。これは、クライアントまたはサーバ・コード変更なしでこの特徴の容易な配置に対して望ましい。プラグ-イン・アーキテクチャは、アプリケーション・コードとは別に秘密キーを“自動”モードで開かせる。これは、最小の変更で既存のシステムに公開キー機能からの利益をもたらさせる。
１１．“ＩＤＥＡ”対称バルク・データ暗号化アルゴリズムに対する支持。
１２．米国政府によって選択されかつ正式に標準化されたときに、“ＡＥＳ”対称バルク・データ暗号化アルゴリズムに対する支持。
１３．メッセージ・ヘッダー及びシステム・メッセージを保護すること。メッセージ-ベース暗号化は、トランザクション識別子のような、システム制御情報の開示を防ぐことができる。メッセージ-ベース・デジタル署名は、偽装攻撃及びシステム保全性による改竄、例えば、ＴＭＳコミット処理メッセージを捏造する攻撃に対して保護する。両方の脅威は、ネットワーク−ベース攻撃者からである場合には、リンク-レベル暗号化によって部分的に扱われる。インクリメンタル・セキュリティ・ベネフィットは、複雑性、キー分配問題、及び性能インパクトに対して価値がないことがある。
１４．アドミニストレーティブ・メッセージを保護すること。公開キー能力は、アドミニストレーティブ・メッセージを保護することによって、システムのアドミニストレーティブ・セキュリティ及びシステム処理保全性を強化することができる。しかしながら、複雑なキー分配、処理識別、及び性能問題が存在する。
１５．拡張された支援、例えばＣＯＢＯＬ支援は、次の（または前の）動作に暗黙的に関連付けられた公開キー動作にすることによって改善することができる。例えば、ＴＰＥＮＶＥＬＯＰＥは、処理によって受信された最後のメッセージに関する情報を戻すことができ、かつＴＰＳＩＧＮは、次のメッセージ発信に対して副作用を有することができる。しかしながら、このタイプの“副作用”インタフェースは、（非請求通知のような）非同期動作及びスレッドを伴う難しい意味問題を有する。
１６．更なるアドミニストレーティブ・ポリシーは、期限切れ署名を許容するかまたは許容しない。添付された署名を有していないメッセージと添付されているが認知されない署名を有するメッセージとを識別することにおいて値が存在しうる。受信者は、添付された署名を検査するためにｔｐｅｎｖｅｌｏｐｅ（）を呼出すことによってこれらの識別を行うことが可能である。
１７．更なるアドミニストレーティブ・パラメータは、応答署名を要求するために提供される。この提案は、要求と応答バッファとの間の関係を制御するアドミニストレーティブ・ポリシーを可能にする。例えば、要求バッファが特定のサーバ受信者に対して暗号化される場合には、応答メッセージは、その受信者によって署名されることが要求される。そのようなポリシーは、アプリケーション論理（ロジック）によって強制することができるが、しかしアドミニストレーティブ・ポリシーによって強制された場合には“より強力”である。そのようなポリシーは、特に複数の暗号化受信者が存在するかまたはイベント・ポスティングのようなクライアント/サーバ対話が存在しないときに、複雑でありうる。
１８．署名または暗号化ポリシーに関する更なるアドミニストレーティブ・パラメータがドメイン構成ファイルに追加される。別のアイデアは、ゲートウェイ処理に署名を追加させるかまたはそれら自体の識別下で暗号化エンベロープを追加/ストリップさせることである。ゲートウェイ宛先に対する制御は、サービス、グループ、マシン、またはドメイン-レベルアドミニストレーティブ・パラメータに基づき利用可能である。
１９．デジタル署名または暗号化を要求するためのクライアント・オプション。いくつかのｔｐｉｎｉｔ（）オプションは、暗号化及び署名ポリシーに対するクライアント制御を許容しうる。特に、クライアントは、暗号化されたメッセージだけ、及び/または署名されたメッセージだけを受け取ることの要求を表すことができる。
２０．アクセス制御決定は、デジタル署名に基づく。メッセージ・バッファが一つ以上の有効な添付されたデジタル署名を有する場合には、ＡＣＬ決定は、ユーザのｔｐｉｎｉｔ（）識別よりも、署名識別に基づくことができる。
２１．認証決定は、デジタル署名に基づく。認証サーバは、添付されたデジタル署名に基づき主張された識別を実証しうる。
２２．性能を高めるためにバルク暗号化キーを再使用する。二つ以上のメッセージに対してバルク・データ暗号化キーを再使用することは、高価な公開キー動作をセーブしうる。例えば、通常のクライアント/サーバ交換の間中に、同じバルク・データ暗号化キーを何回も用いることができる。一つの問題点は、総当り攻撃がより多くのメッセージをクラック（解読）するので、セキュリティが低減されうるということである。全てではないが、キーで暗号化されたいくつかのメッセージの受信者として指定された無許可のパーティにバルク・データ暗号化キーが“漏洩”されないということもまた重要である。
２３．秘密キーが必要なときにコールバック機能を呼出す。処理が署名生成または解読に対して一定の秘密キーを必要とするが、キーが先に開かれていないような状況がありうる。コールバック機能は、アプリケーションに失敗するまえにそれを開けるための“最後の機会”を許容しうる。
２４．バッファ・タイプ毎のカスタマイズされた圧縮アルゴリズムを許容するための機能。圧縮アルゴリズムは、バッファ・タイプ・スイッチ・フック機能に基づきカスタマイ可能でありうる。
２５．新しいＳ/ＭＩＭＥバッファは、クライアント/サーバとメール・ゲートウェイとの間の相互運用性（インターオペラビリティ）を強化することができる。
２６．副署。例えば、ＰＫＣＳ７フォーマッティング下でバッファ内の特定された署名に副署を割り当てることが可能である。副署は、あるエンティティは、（公証人の機能と同様に）別のエンティティバッファに署名をしたということに署名するということを示す。この機能性は、ｔｐｅｘｐｏｒｔ（）動詞で粗野的に達成することができる。
２７．更なる擬似ランダム・シード材料を供給するためのフック機能。アプリケーション環境がハードウェア-生成ランダム・シード材料、またはその他のグッド・ソース（優良供給源）へのアクセスを有する場合には、ＴＵＸＥＤＯのようなトランザクション・サーバは、それを受け入れうる。
【０１５４】
本発明の上記記述は、説明及び記述の目的で供給される。それは、網羅的であることを意図しないし或いは本発明を開示されたそのものずばりのフォームに限定することを意図しない。明らかに、多くの変更及び変形がこの当業者に理解されるであろう。実施形態は、本発明の原理及びその実用的アプリケーションを最も良く説明するために選択されかつ記述され、それによりその他の当業者が様々な実施形態に対してかつ予期された特定の使用に適する様々な変更を有する本発明を理解することを可能にする。本発明の適用範囲は、特許請求の範囲及びそれらの同等物によって確定されるということが意図される。
【図面の簡単な説明】
【０１５５】
【図１】図１は、説明目的でここに用いられる公開キー及び秘密キーの記号または絵表示である。
【図２】図２は、説明目的でここに用いられるデジタル証明書の記号または絵表示である。
【図３】図３は、デジタル証明書生成処理の概略図である。
【図４】図４は、デジタル証明書生成処理のフローチャートである。
【図５】図５は、本発明の一実施例によるメッセージ暗号化処理の概略図である。
【図６】図６は、本発明の一実施例によるメッセージ暗号化処理のフローチャートである。
【図７】図７は、本発明の一実施例によるメッセージ解読処理の概略図である。
【図８】図８は、本発明の一実施例によるメッセージ解読処理のフローチャートである。
【図９】図９は、本発明の一実施例によるメッセージ暗号化及び解読処理の概略図である。
【図１０】図１０は、本発明の一実施例によるデジタル署名生成処理の概略図である。
【図１１】図１１は、本発明の一実施例によるデジタル署名生成処理のフローチャートである。
【図１２】図１２は、本発明の一実施例によるデジタル署名検証処理の概略図である。
【図１３】図１３は、本発明の一実施例によるデジタル署名検証処理の概フローチャートである。

Claims (20)

1. トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージのセキュア通信のための方法であって、
   暗号化のためにメッセージ・バッファにマークを付ける段階と、
   デジタル署名の添付のために前記メッセージ・バッファにマークを付ける段階と、
   前記メッセージ・バッファを暗号化することによって暗号化エンベロープを生成し、かつデジタル署名で前記メッセージ・バッファの暗号化されたコンテンツに署名する段階と、及び
   前記暗号化エンベロープを送信側処理から受信側処理に送信する段階
   を具備することを特徴とする方法。
2. トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージの秘密通信を検証する方法であって、
   暗号化エンベロープを送信側処理から受信する段階と、
   前記暗号化エンベロープを前記受信側処理によって読取可能なメッセージ・バッファ・コンテントにインポートする段階と、
   前記メッセージを検索するために前記暗号化エンベロープを解読する段階と、及び
   前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する段階と
   を具備することを特徴とする方法。
3. トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージのセキュア通信のための方法であって、
   第２のサーバ処理または受信側処理への引渡しのために、第１のサーバ処理または送信側処理からのメッセージを、メッセージ・バッファにコンテントとして記憶する段階と、
   前記メッセージ・バッファのコンテンツを該メッセージ・バッファの外部表現にエクスポートする段階であり、
   暗号化のために前記メッセージ・バッファにマークを付ける副段階と、
   前記送信側処理を識別するデジタル署名の添付のために前記メッセージ・バッファにマークを付ける副段階と、
   前記メッセージ・バッファを暗号化することによって暗号化エンベロープを生成し、かつデジタル署名で前記メッセージ・バッファの暗号化されたコンテンツに署名する副段階と、
   を含む該エクスポートする段階と、
   前記暗号化エンベロープを送信側処理から受信側処理に送信する段階と、及び
   前記暗号化エンベロープを前記受信側処理によって読取可能なメッセージ・バッファ・コンテントにインポートする段階であり、
   前記メッセージを検索するために前記暗号化エンベロープを解読する副段階と、及び
   前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する副段階と
   を含む該インポートする段階と
   を具備することを特徴とする方法。
4. 前記送信側処理及び前記受信側処理は、コンピュータで実行されるトランザクション・ソフトウェア処理であることを特徴とする請求項３に記載の方法。
5. 前記メッセージは、前記送信側処理と前記受信側処理との間の通信のためにメッセージを保持するために用いられるメッセージ・バッファのコンテントの一部または全部であることを特徴とする請求項３に記載の方法。
6. 前記記憶する段階は、前記受信側処理への通信のために前記メッセージ・バッファのコンテントの前記一部または全部を準備する段階を含むことを特徴とする請求項５に記載の方法。
7. 前記暗号化の段階は、
   メッセージ・キーを前記送信側処理で生成する副段階と、
   暗号化されたメッセージ・バッファを生成するために前記メッセージ・キーを前記メッセージ・バッファのコンテンツと組合せる副段階と、
   前記受信側処理に関連付けられた公開キーから解読キーを生成する副段階と、及び
   前記暗号化されたメッセージ及び前記解読キーを前記暗号化エンベロープに配置する副段階と
   を含むことを特徴とする請求項３に記載の方法。
8. 前記署名する段階は、
   前記メッセージ・バッファからメッセージ・ダイジェストを生成する段階と、
   前記送信側処理に関連付けられた秘密キーを検索する段階と、
   デジタル署名を生成するために前記メッセージ・ダイジェストを前記秘密キーと組合せる段階と、及び
   前記デジタル署名を前記暗号化エンベロープに配置する段階と
   を含むことを特徴とする請求項３に記載の方法。
9. 前記解読する段階は、
   前記暗号化エンベロープを受信する段階と、
   前記暗号化エンベロープを前記受信側処理に関連付けられた秘密キーと組合わせる段階と、
   前記解読キーを検索する段階と、
   前記暗号化されたメッセージを検索するために前記解読キーを用いる段階と、及び
   前記メッセージを検索するために前記暗号化されたメッセージを解読する段階と
   を含むことを特徴とする請求項７に記載の方法。
10. 前記検証する段階は、
    前記デジタル署名を含んでいるメッセージを受信する段階と、
    前記デジタル署名から第１のメッセージ・ダイジェストを生成する段階と、
    第２のメッセージ・ダイジェストを生成する段階であり、
    前記送信側処理に関連付けられた公開キーを検索する段階と、
    第２のメッセージ・ダイジェストを生成するために前記送信側公開キーを前記デジタル署名と組合せる段階と
    を含んでいる該第２のメッセージ・ダイジェストを生成する段階と、及び
    前記メッセージで送信された前記デジタル署名の妥当性を決定するために前記第１及び第２のメッセージ・ダイジェストを比較する段階と
    を含むことを特徴とする請求項８に記載の方法。
11. 前記送信する段階は、中間受信者を介して前記メッセージを送信する段階を含み、中間受信者を介して前記メッセージを送信する前記段階は、
    前記送信側処理で前記暗号化エンベロープを第２の暗号化エンベロープに配置する副段階と、
    前記中間処理で前記暗号化エンベロープを受信する副段階と、
    前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する副段階と、及び
    前記識別が有効である場合には、前記暗号化エンベロープを前記受信側処理に送る副段階と
    を含むことを特徴とする請求項３に記載の方法。
12. トランザクション処理システムにおける第１のサーバ処理から第２のサーバ処理へのメッセージのセキュア通信のためのシステムであって、
    第２のサーバ処理または受信側処理への引渡しのために、第１のサーバ処理または送信側処理からのメッセージを、メッセージ・バッファにコンテントとして記憶する段階と、
    前記メッセージ・バッファのコンテンツを、ｔｐｅｘｐｏｒｔ（）関数を介して、該メッセージ・バッファの外部表現にエクスポートする段階であり、
    暗号化のために前記メッセージ・バッファに、ｔｐｓｅａｌ（）関数を用いて、マークを付ける副段階と、
    前記送信側処理を識別するデジタル署名の添付のために、ｔｐｓｉｇｎ（）関数を用いて、前記メッセージ・バッファにマークを付ける副段階と、
    前記メッセージ・バッファを暗号化することによって暗号化エンベロープを生成し、かつデジタル署名で前記メッセージ・バッファの暗号化されたコンテンツに署名する副段階と、
    を含む該エクスポートする段階と、
    前記暗号化エンベロープを送信側処理から受信側処理に送信する段階と、及び
    前記暗号化エンベロープを、ｔｐｉｍｐｏｒｔ（）関数を介して、前記受信側処理によって読取可能なメッセージ・バッファ・コンテントにインポートする段階であり、
    前記メッセージを検索するために前記暗号化エンベロープを解読する副段階と、及び
    前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する副段階と
    を含む該インポートする段階と
    を実行するためのコンピュータ読取可能命令を備えていることを特徴とするシステム。
13. 前記送信側処理及び前記受信側処理は、コンピュータで実行されるトランザクション・ソフトウェア処理であることを特徴とする請求項１２に記載のシステム。
14. 前記メッセージは、前記送信側処理と前記受信側処理との間の通信のためにメッセージを保持するために用いられるメッセージ・バッファのコンテントの一部または全部であることを特徴とする請求項１２に記載のシステム。
15. 前記記憶するための命令は、前記受信側処理への通信のために前記メッセージ・バッファのコンテントの前記一部または全部を準備する段階を含むことを特徴とする請求項１４に記載のシステム。
16. 前記暗号化するための命令は、
    メッセージ・キーを前記送信側処理で生成する副段階と、
    暗号化されたメッセージ・バッファを生成するために前記メッセージ・キーを前記メッセージ・バッファのコンテンツと組合わせる副段階と、
    前記受信側処理に関連付けられた公開キーから解読キーを生成する副段階と、及び
    前記暗号化されたメッセージ及び前記解読キーを前記暗号化エンベロープに配置する副段階と
    を含むことを特徴とする請求項１２に記載のシステム。
17. 前記署名する命令は、
    前記メッセージ・バッファからメッセージ・ダイジェストを生成する段階と、
    前記送信側処理に関連付けられた秘密キーを検索する段階と、
    デジタル署名を生成するために前記メッセージ・ダイジェストを前記秘密キーと組合せる段階と、及び
    前記デジタル署名を前記暗号化エンベロープに配置する段階と
    を含むことを特徴とする請求項１２に記載のシステム。
18. 前記解読する命令は、
    前記暗号化エンベロープを受信する段階と、
    前記暗号化エンベロープを前記受信側処理に関連付けられた秘密キーと組合せる段階と、
    前記解読キーを検索する段階と、
    前記暗号化されたメッセージを検索するために前記解読キーを用いる段階と、及び
    前記メッセージを検索するために前記暗号化されたメッセージを解読する段階と
    を含むことを特徴とする請求項１６に記載のシステム。
19. 前記検証する命令は、
    前記デジタル署名を含んでいるメッセージを受信する段階と、
    前記デジタル署名から第１のメッセージ・ダイジェストを生成する段階と、
    第２のメッセージ・ダイジェストを生成する段階であり、
    前記送信側処理に関連付けられた公開キーを検索する段階と、
    第２のメッセージ・ダイジェストを生成するために前記送信側公開キーを前記デジタル署名と組合せる段階と
    を含んでいる該第２のメッセージ・ダイジェストを生成する段階と、及び
    前記メッセージで送信された前記デジタル署名の妥当性を決定するために前記第１及び第２のメッセージ・ダイジェストを比較する段階と
    を含むことを特徴とする請求項１７に記載のシステム。
20. 前記送信する命令は、中間受信者を介して前記メッセージを送信する段階を含み、中間受信者を介して前記メッセージを送信する前記段階は、
    前記送信側処理で前記暗号化エンベロープを第２の暗号化エンベロープに配置する副段階と、
    前記中間処理で前記暗号化エンベロープを受信する副段階と、
    前記暗号化エンベロープから前記デジタル署名を検索することによって前記送信側処理の識別を検証する副段階と、及び
    前記識別が有効である場合には、前記暗号化エンベロープを前記受信側処理に送る副段階と
    を実行するためのコンピュータ読取可能命令を含むことを特徴とする請求項１２に記載のシステム。

Images